Grote hoeveelheid data verplaatsen/backuppen in korte tijd

[Blaater]

Het volgende 'probleem' hebben we bij ons op onze afdeling met geeks nog geen oplossing voor gevonden, zonder dat het over ons theoretische budget (250.000) heen zouden gaan.

Uitgangspunten:

• Tussen de 500TB en 1PB aan uncompressed data. Dit kan van alles zijn, databases, images, strings etc. etc.
• Data staat in SAN storage en voor de uitgangspunten gaan we er even vanuit dat deze 2 x 10Gbit aansluitingen heeft, maar heeft de mogelijkheid om onbeperkt qua aansluitingen/read snelheid te upgraden.
• We hebben een timeframe van +/- 12 uur waarbij we alle data naar een andere fysieke locatie moeten dupliceren voordat de locatie weer sluit
• We hebben remote 36 uur voorbereidingstijd voorafgaand deze timeframe
• Er is alleen infrastructuur tussen de twee locaties tijdens de 12 uur timewindow mogelijk
• Na de twaalf uur sluit de locatie en kunnen we er niet meer bij (en eventuele hardware die we hebben meegenomen kunnen we niet retourneren voor de volgende keer)
• De data is kritisch, een enkel corrupt of missend bestand zou maanden aan werk teniet doen

Nu de catch; tapes mogen niet gebruikt worden in deze oplossing vanwege betrouwbaarheidsissues.

Enkele ideeën waar wij aan hebben gedacht maar waar we tegen problemen aanliepen.

IDEE 1: HDD ARRAYS

• In dit geval kunnen we gebruik maken van de 12 uur plus de 36 uur voorbereidingstijd om alle data over te zetten op een tweede storage.
• Deze storage zouden we dan fysiek verplaatsen naar de tweede locatie waar ze kunnen beginnen met het dupliceren van de data op de storage
• Nadeel: Dupliceren van deze data zou langer duren dan de 12 uur timeframe die we hebben en we zouden de HDD arrays niet kunnen retourneren naar locatie 1. We zouden dan ook twee van dit systemen moeten hebben, waarbij er altijd 1 op locatie 1 is, omdat we anders de volgende keer nooit alle data op de HDD arrays kunnen krijgen.
• Nadeel: Twee systemen kost veel geld

IDEE 2: Overzetten via verbinding tussen de twee locaties

• In dit geval maken we verbinding tussen locatie 1 en locatie 2, dit kan alleen tijdens de 12 uur timeframe, buiten dit timeframe kan er geen verbinding worden gemaakt.
• Lage kosten, geen extra hardware nodig voor opslag
• Nadeel: Met (lagen we zeggen 750TB aan data) zou alles in 12 uur overgezet moeten worden. Dan moeten we een theoretisch optimale snelheid halen tussen de locaties van zo'n 150Gbit/s om alles te dupliceren in 12 uur, dit loopt op tot 200Gbit/s in geval van 1PB aan data
• Bestaan dit soort systemen überhaupt die 150Gbit/s kunnen webschrijven?
• Nadeel: Een 200Gbit/s verbinding opbouwen is ook niet zomaar gedaan, ook hoge kosten

Wat zien wij over het hoofd wat wel gebruikt kan worden?

TLDR; Grote hoeveelheid data moet in korte tijd naar een fysiek andere plek gebracht worden zonder dat de data van locatie 1 weg gaat.

[Vorkie]

Dus het storage systeem van locatie 2 eerst op locatie 1 neerzetten en laten repliceren in een aantal dagen is niet mogelijk?

Dan heb je daarna 12 uur de tijd om die storage voor locatie 2 daar neer te zetten...

[Blaater]

Vorkie schreef op dinsdag 18 juli 2017 @ 10:10:
Dus het storage systeem van locatie 2 eerst op locatie 1 neerzetten en laten repliceren in een aantal dagen is niet mogelijk?

Dan heb je daarna 12 uur de tijd om die storage voor locatie 2 daar neer te zetten...

Niet mogelijk helaas, locatie 1 is hermetisch afgesloten voorafgaand aan de 12 uur. Remote kunnen we er wel bij, maar fysiek niet.

Het zou wel kunnen om het daar maanden te laten staan vooraf, en pas te gebruiken op het dat de 36 uur voorbereiding ingaan, maar dat kan maar eenmalig, omdat de data op locatie 2 moet achterblijven en het een paar maanden later weer zal moeten gebeuren, en dan is het storage system niet meer op locatie 1 aanwezig.

(misschien moet ik het uittekenen want dit is wel heel onduidelijk?)

[Vorkie]

Blaater schreef op dinsdag 18 juli 2017 @ 10:13:
[...]


Niet mogelijk helaas, locatie 1 is hermetisch afgesloten voorafgaand aan de 12 uur. Remote kunnen we er wel bij, maar fysiek niet.

Het zou wel kunnen om het daar maanden te laten staan vooraf, en pas te gebruiken op het dat de 36 uur voorbereiding ingaan, maar dat kan maar eenmalig, omdat de data op locatie 2 moet achterblijven en het een paar maanden later weer zal moeten gebeuren, en dan is het storage system niet meer op locatie 1 aanwezig.

(misschien moet ik het uittekenen want dit is wel heel onduidelijk?)

Maar, als je data verloop niet heel groot is (dus voornamelijk statisch) kan je voorafgaand, dus zegge maand 8 van de 12 maanden die je ervoor uittrekt, al een hele grote bulk aan statische data preloaden / synchroniseren op de nieuwe storage voor locatie 2. Dan rest er in de periode van 12 uur / 36 uur alleen nog maar een synchronisatie van 4 maanden aan data, welke hoogstwaarschijnlijk nooit zoveel is als de complete data.

Alleen het punt van "storage locatie 1 niet meer aanwezig" is mij enigszins onduidelijk.

[MAX3400]

De data is kritisch, een enkel corrupt of missend bestand zou maanden aan werk teniet doen

Forget it dus maar.

Je gaat in je hele timeframe geen enkele error-correctie vinden die dit rechttrekt. Tenzij je al langere tijd (weken/maanden) CRC hebt van je bestanden.

Maar aangezien je over SAN praat; neem aan dat je een dedup & snapshot hebt lopen? Die data is bijna realtime te "mirroren" naar extra shelves en snapshots zijn al gecontroleerd en in principe zonder fouten.

In ander nieuws: bedrijven als IBM hebben rijdende datacenters met hogere capaciteiten dan de initieel aanwezige 20Gbit. Kosten onbekend maar als het goed genoeg is voor het UWV (overheid) en banken, lijkt het me ook goed genoeg voor jouw data.

More info needed, denk ik zo; interessante case

[jeroen3]

Is er niet de mogelijkheid om de redundancy eerst uit te breiden, zodat je op het moment supreme gewoon de helft van de disks mee kan nemen?

[Blaater]

Vorkie schreef op dinsdag 18 juli 2017 @ 10:18:
[...]

Maar, als je data verloop niet heel groot is (dus voornamelijk statisch) kan je voorafgaand, dus zegge maand 8 van de 12 maanden die je ervoor uittrekt, al een hele grote bulk aan statische data preloaden / synchroniseren op de nieuwe storage voor locatie 2. Dan rest er in de periode van 12 uur / 36 uur alleen nog maar een synchronisatie van 4 maanden aan data, welke hoogstwaarschijnlijk nooit zoveel is als de complete data.

Alleen het punt van "storage locatie 1 niet meer aanwezig" is mij enigszins onduidelijk.

Ik zal proberen om het zo duidelijk mogelijk te maken, het is nogal een onduidelijk en heel specifiek verhaal voor deze situatie.

- Beginsituatie: We kunnen bij de locatie en er is 0 data aanwezig en er is een storage oplossing aanwezig.
- Locatie sluit voor een aantal maanden waarna er voor XXXTB aan data wordt gemaakt
- 36 uur voordat we fysiek bij de locatie kunnen kunnen we er remote bij en kunnen we duplicaties beginnen etc. (indien er apparatuur voor aanwezig is)
- Locatie gaat open en we hebben 12 uur voor de locatie weer sluit voordat we weer bij de beginsituatie aankomen.

In die twaalf uur moet de data bij locatie 2 komen, hoeft nog niet gedupliceerd te zijn of wat dan ook, als we het hele proces maar weer opnieuw kunnen beginnen na die twaalf uur.


- Data is echt compleet nieuw na elke offload, de data wordt gewiped en we beginnen weer vanaf 0 vanaf dat moment.
- Dan wordt er binnen een paar maanden weer voor XXXTB aan data 'gemaakt' terwijl we niet bij de locatie kunnen

[Blaater]

MAX3400 schreef op dinsdag 18 juli 2017 @ 10:21:
[...]

Forget it dus maar.

Je gaat in je hele timeframe geen enkele error-correctie vinden die dit rechttrekt. Tenzij je al langere tijd (weken/maanden) CRC hebt van je bestanden.

Maar aangezien je over SAN praat; neem aan dat je een dedup & snapshot hebt lopen? Die data is bijna realtime te "mirroren" naar extra shelves en snapshots zijn al gecontroleerd en in principe zonder fouten.

In ander nieuws: bedrijven als IBM hebben rijdende datacenters met hogere capaciteiten dan de initieel aanwezige 20Gbit. Kosten onbekend maar als het goed genoeg is voor het UWV (overheid) en banken, lijkt het me ook goed genoeg voor jouw data.

More info needed, denk ik zo; interessante case

De data bouwt op, dus als de hardware er voor is, dan is het gewoon mogelijk om de duplicate/mirroring met de data mee te laten lopen op locatie maanden lang. Enkel in de laatste 36 uur wordt er geen nieuwe data meer gemaakt en is de tijd gekomen om de 'final' mirror te maken voor de 12 uur offload window.

Nadeel is; de backup moet van locatie 1 af worden gehaald, en is niet in twaalf uur naar locatie 2 te dupliceren. Dan zouden er dus twee van deze backup systemen nodig zijn, om altijd een compleet backup systeem op locatie 1 aanwezig te hebben om de mirrors maanden lang te laten lopen etc.

jeroen3 schreef op dinsdag 18 juli 2017 @ 10:21:
Is er niet de mogelijkheid om de redundancy eerst uit te breiden, zodat je op het moment supreme gewoon de helft van de disks mee kan nemen?

Is een mogelijkheid, maar dan moeten we een kopie maken op locatie 2 van onze storage solution? En is dit niet vrij 'gevoelig' voor corrupte data etc.

[jeroen3]

Je moet dit vaker doen?

[MAX3400]

Blaater schreef op dinsdag 18 juli 2017 @ 10:35:
[...]


De data bouwt op, dus als de hardware er voor is, dan is het gewoon mogelijk om de duplicate/mirroring met de data mee te laten lopen op locatie maanden lang. Enkel in de laatste 36 uur wordt er geen nieuwe data meer gemaakt en is de tijd gekomen om de 'final' mirror te maken voor de 12 uur offload window.

Nadeel is; de backup moet van locatie 1 af worden gehaald, en is niet in twaalf uur naar locatie 2 te dupliceren. Dan zouden er dus twee van deze backup systemen nodig zijn, om altijd een compleet backup systeem op locatie 1 aanwezig te hebben om de mirrors maanden lang te laten lopen etc.


[...]


Is een mogelijkheid, maar dan moeten we een kopie maken op locatie 2 van onze storage solution? En is dit niet vrij 'gevoelig' voor corrupte data etc.

Je zoekt problemen en stelt daarna relatief simpele vragen over gevoeligheid en/of kopie maken?

Gezien het budget en de kritische inhoud van de data; welke bedrijven, gespecialiseerd in data-migration, heb je hier al over gesproken, welke kosten/uitdagingen zagen ze en in hoeverre is de topicstart hier nu op gebaseerd?

Ik vind de vraag nogal vrijblijvend en eerlijk gezegt ietwat n00b overkomen?

[Blaater]

jeroen3 schreef op dinsdag 18 juli 2017 @ 10:37:
Je moet dit vaker doen?

Dit herhaalt zich elke paar maanden.

MAX3400 schreef op dinsdag 18 juli 2017 @ 10:38:
[...]

Je zoekt problemen en stelt daarna relatief simpele vragen over gevoeligheid en/of kopie maken?

Gezien het budget en de kritische inhoud van de data; welke bedrijven, gespecialiseerd in data-migration, heb je hier al over gesproken, welke kosten/uitdagingen zagen ze en in hoeverre is de topicstart hier nu op gebaseerd?

Ik vind de vraag nogal vrijblijvend en eerlijk gezegt ietwat n00b overkomen?

Ik zoek geen problemen, helaas niks hiervan is verzonnen eigenlijk. Ik ben geen storage expert zelf, dus wellicht dat sommige vragen inderdaad wat noob over kunnen komen uiteindelijk.

Er was een oplossing bedacht welke voldeed aan de eisen, totdat de eisen werden veranderd (tape niet mogelijk en maar 12 uur tijd). Deze oplossing was relatief low-cost, vandaar ons theoretische budget.

Leverancier van de tape drive/storage heeft nog geen update gegeven hoe zij nu verder willen gaan nu de eisen zijn veranderd. Grote organisaties die bewegen langzaam. We vermoeden echter dat we doorschuiven naar een totaal andere prijsklasse nu met de nieuwe eisen, vandaar dat we onszelf weer zijn geen inlezen in de mogelijkheden nu met de nieuwe eisen en mee kunnen denken. En we willen de mogelijkheid voor 'out of the box' denken niet direct opgeven, dus het hoeft geen ready-made systeem te zijn o.i.d. als het maar betrouwbaar is.

---

Oftewel, er was een oplossing, eisen zijn veranderd, en nu beginnen we weer vanaf nul en staan we open voor ideeën zonder ons meteen te beperken doordat we er niet zelf aan hebben gedacht.

[GEi]

Wanneer dit proces in de toekomst vaker gaat voorkomen, op locatie 1 alles gespiegeld opslaan. In de 12 uur die je hebt één dataset afkoppelen en schone / lege set aankoppelen. Verder gaan met data verzamelen op de schone set, gespiegeld naar de reeds bestaande set (bestaande data overschrijven of eerst deleten).
De afgekoppelde set meenemen naar locatie 2 en daar je ding er mee doen. Deze set neem je een paar maanden later mee naar locatie 1 om het hele proces te herhalen.
Bovenstaande is ingegeven, niet gehinderd door enige kennis of budget .

Wat doe je als in tussentijds storage corrupt raakt? Kan je er dan ook niet bij op locatie 1?

[jeroen3]

@GEi Ja precies. Ik ben er geen expert in, maar op basis van de demonstraties van 45Drives kun je hele racks redundant maken. Dus dan wissel je gewoon een heel rack uit voor een lege.
Dan heb je een volledige kopie, inclusief redundant disks. En dan heeft het systeem weer maanden om dit te herstellen.

Het is weliswaar niet te tillen, maar daar is vast ook een oplossing voor.

[ Voor 11% gewijzigd door jeroen3 op 19-07-2017 12:05 ]

[Blaater]

GEi schreef op woensdag 19 juli 2017 @ 11:48:
Wanneer dit proces in de toekomst vaker gaat voorkomen, op locatie 1 alles gespiegeld opslaan. In de 12 uur die je hebt één dataset afkoppelen en schone / lege set aankoppelen. Verder gaan met data verzamelen op de schone set, gespiegeld naar de reeds bestaande set (bestaande data overschrijven of eerst deleten).
De afgekoppelde set meenemen naar locatie 2 en daar je ding er mee doen. Deze set neem je een paar maanden later mee naar locatie 1 om het hele proces te herhalen.
Bovenstaande is ingegeven, niet gehinderd door enige kennis of budget .

Wat doe je als in tussentijds storage corrupt raakt? Kan je er dan ook niet bij op locatie 1?

Het is inderdaad 1 van de mogelijkheden om alles inderdaad gespiegeld op te slaan. Het lijkt er een beetje op dat we die kant op moeten gaan.

De storage bestaat al uit een gedeeld gespiegelde opslag, de opslag is verdeeld over twee locaties binnen locatie 1. Waarbij gedeeltes van de data (operationele data) gespiegeld opgeslagen wordt zodat er altijd doorgewerkt kan worden. De 'grove' data waar we het over hebben die wordt op dit systeem niet gespiegeld, het is niet erg als die data even niet toegankelijk is, als de data maar niet verloren gaat.

De vraag staat open bij de leverancier hoe zij erover denken, en of dit inderdaad in budget de goedkoopste optie is.

Tussentijds corrupt is 'geen probleem', de locatie is wel bemand in al die maanden tijd, de locatie is alleen afgesloten. maar werkzaamheden kunnen wel gedaan worden.

jeroen3 schreef op woensdag 19 juli 2017 @ 12:04:
@GEi Ja precies. Ik ben er geen expert in, maar op basis van de demonstraties van 45Drives kun je hele racks redundant maken. Dus dan wissel je gewoon een heel rack uit voor een lege.
Dan heb je een volledige kopie, inclusief redundant disks. En dan heeft het systeem weer maanden om dit te herstellen.

Het is weliswaar niet te tillen, maar daar is vast ook een oplossing voor.

45Drives ben ik onbekend mee, ik zal de demonstraties is gaan kijken om te zien wat voor oplossingen zij bedacht hebben.

(edit: ziet eruit als een no-nonsense ding dat doet waarvoor het gemaakt is, deze optie ga ik onderzoeken).

Tillen/gewicht is niet direct een probleem. Gewicht is een issue dat alles zo licht mogelijk moet, maar is een secundaire eis om me rekening te houden, daar wordt de beslissing niet op gebaseerd. Tillen maakt ook niet uit, we hebben desnoods de mogelijkheid om mobiele racks te maken etc. en met kranen eruit te tillen.

[MAX3400]

Tillen maakt ook niet uit, we hebben desnoods de mogelijkheid om mobiele racks te maken etc. en met kranen eruit te tillen.

Nee hoor; want de vloerbelasting is vooralsnog niet gepost in het topic.

Datacenter 1 en datacenter 2 kunnen verschillen hebben in vloerbelasting. En dan moet je ook nog rekening houden met draaicirkels van, bijvoorbeeld, een kleine heftruck als je uit een willekeurige corridor een rack moet weghalen.

/edit: sommige racks kan je niet eens verplaatsen omdat de static load rating hoger is dan de "moving load". Vergeet ook niet dat heleboel mounting kits (rails, schroeven, etc) helemaal niet geschikt zijn om meer dan een paar graden uit het lood te staan; grote kans dat je ze sloopt.

@Question Mark AWS (en andere partijen) bieden inderdaad dit soort opties aan. Blijft het dat de huidige throughput 20Gbit is van de opstelling in het datacenter; nog steeds zie ik geen enkele berekening van "hoeveel files / average throughput / IOPS / whatever" om te garanderen dat de laatste stappen van data-migratie tijdig zijn verlopen.

[ Voor 42% gewijzigd door MAX3400 op 19-07-2017 14:14 ]

[Question Mark]

Ik zou serieus kijken naar een oplossing als AWS snowmobile

https://aws.amazon.com/snowmobile/

AWS Snowmobile is an Exabyte-scale data transfer service used to move extremely large amounts of data to AWS. You can transfer up to 100PB per Snowmobile, a 45-foot long ruggedized shipping container, pulled by a semi-trailer truck. Snowmobile makes it easy to move massive volumes of data to the cloud, including video libraries, image repositories, or even a complete data center migration. Transferring data with Snowmobile is secure, fast and cost effective.

After an initial assessment, a Snowmobile will be transported to your data center and AWS personnel will configure it for you so it can be accessed as a network storage target. When your Snowmobile is on site, AWS personnel will work with your team to connect a removable, high-speed network switch from Snowmobile to your local network and you can begin your high-speed data transfer from any number of sources within your data center to the Snowmobile. After your data is loaded, Snowmobile is driven back to AWS where your data is imported into Amazon S3 or Amazon Glacier.

Snowmobile uses multiple layers of security designed to protect your data including dedicated security personnel, GPS tracking, alarm monitoring, 24/7 video surveillance, and an optional escort security vehicle while in transit. All data is encrypted with 256-bit encryption keys managed through the AWS Key Management Service (KMS) and designed to ensure both security and full chain-of-custody of your data.

nieuws: Amazon gaat 100PB-containers per truck vervoeren voor klanten

D'r staat mij nog bij dat IBM vroeger ook complete tijdelijke DC's in een vrachtwagen had waar je tijdelijk je infra op kon laten draaien.

MAX3400 schreef op woensdag 19 juli 2017 @ 14:08:
[...]
@Question Mark AWS (en andere partijen) bieden inderdaad dit soort opties aan. Blijft het dat de huidige throughput 20Gbit is van de opstelling in het datacenter; nog steeds zie ik geen enkele berekening van "hoeveel files / average throughput / IOPS / whatever" om te garanderen dat de laatste stappen van data-migratie tijdig zijn verlopen.

True... Een snowmobile heeft een theoretische snelheid van 1 TB/s naar zijn interne storage. Daar zal de bottleneck niet zo snel liggen. Die 2x 10 Gbit en achterliggende storage wordt wat krapper.

[ Voor 23% gewijzigd door Question Mark op 19-07-2017 14:24 ]

[Blaater]

Question Mark schreef op woensdag 19 juli 2017 @ 14:12:
Ik zou serieus kijken naar een oplossing als AWS snowmobile

https://aws.amazon.com/snowmobile/


[...]

Cloudoplossingen zijn in zijn geheel niet mogelijk. Data mag fysiek niet van de locaties af.

MAX3400 schreef op woensdag 19 juli 2017 @ 14:08:
[...]

Nee hoor; want de vloerbelasting is vooralsnog niet gepost in het topic.

Datacenter 1 en datacenter 2 kunnen verschillen hebben in vloerbelasting. En dan moet je ook nog rekening houden met draaicirkels van, bijvoorbeeld, een kleine heftruck als je uit een willekeurige corridor een rack moet weghalen.

/edit: sommige racks kan je niet eens verplaatsen omdat de static load rating hoger is dan de "moving load". Vergeet ook niet dat heleboel mounting kits (rails, schroeven, etc) helemaal niet geschikt zijn om meer dan een paar graden uit het lood te staan; grote kans dat je ze sloopt.

@Question Mark AWS (en andere partijen) bieden inderdaad dit soort opties aan. Blijft het dat de huidige throughput 20Gbit is van de opstelling in het datacenter; nog steeds zie ik geen enkele berekening van "hoeveel files / average throughput / IOPS / whatever" om te garanderen dat de laatste stappen van data-migratie tijdig zijn verlopen.

De racks die worden in dit geval al speciaal gemaakt, zijn gemaakt voor hoge trillingen en uit lood staan etc. Dit was ook een reden dat de tapeoplossing niet meer voldeed, deze kon op geen enkele manier voldoen (garanderen dat het bleef werken) aan deze eisen uiteindelijk. Vloerbelasting is niet ons probleem om het maar simpel te zeggen. Desnoods wordt er inderdaad een zeecontainer buiten geplaatst en wordt de ruimte geconditioneerd speciaal hiervoor.

Specificaties van de storage zal ik opzoeken (IOPS etc.) die gegevens heb ik niet bij de hand nu. Hoeveelheid files is echt totaal onbekend wel.

[Question Mark]

Blaater schreef op woensdag 19 juli 2017 @ 14:33:
[...]


Cloudoplossingen zijn in zijn geheel niet mogelijk. Data mag fysiek niet van de locaties af.

Ik zeg ook niet dat de data naar een cloudoplossing moet, maar je zou wel een dergelijke oplossing kunnen gebruiken om de data naar je nieuwe DC te transporteren.

1. Kopieer data naar mobiel Datacenter
2. Rij mobiel Datacenter naar nieuwe Datacenter
3. Kopieer data vanaf mobiel DC naar nieuwe Datacenter

Bovendien gaat met zo'n oplossing de data niet van het DC af (die blijft daar beschikbaar). Je kopieert hem simpelweg naar storage die in het mobiele DC zit. Als de data in het geheel niet van het DC af mag, zou je deze ook niet mogen kopieren.

Zolang stap 1 binnen de 12 uur kan, voldoe je aan de uitgangspunten. Je noemt immers niet dat de data na die 12 uur direct weer beschikbaar moet zijn. Je hebt alleen genoemd dat je 12 uur lang toegang hebt tot de brondata.

Welke fysieke lokaties hebben we het eigenlijk over, en wat voor soort verbindingen zijn daar af te monteren (en te leveren binnen de tijdsframes).

[ Voor 4% gewijzigd door Question Mark op 19-07-2017 15:34 ]

[Tortelli]

Denk dat de data fysiek verplaatsen je meest realistische oplossing is. Als je data werkelijk wilt koppieren zul je hier echt een exotische oplossing voor moeten verzinnen;

Uitgaande van 500TB, welke in 12 uur verplaatst moet worden heb je volgende snelheid nodig;
500/12 = 42TB / uur = 700GB / minuut = 12GB / seconden
(heb geen echte rekening gehouden met 1.024 factor...)

Met een 10Gbit netwerk haal je maximaal zo'n 1,1GB / seconden in het gunstigste geval. Je zult een 100Gbit netwerk moeten hebben om dit te kunnen halen.
edit zie dat je zelf al een berekening had gemaakt van de benodigde verbinding

Hou er ook rekening mee dat je netwerk waarschijnlijk niet altijd vol zal trekken. Vooral kleine bestanden gaan meestal vrij traag, weet niet hoe dit op 100Gbit werkt .

[ Voor 20% gewijzigd door Tortelli op 19-07-2017 16:10 ]

[Tijntje]

Zelfs met een 100Gbit netwerk is net maar net aan.
Dan kom je zonder overhead uit op 12.5 GB/s maar dan moet je storage dat ook continu kunnen leveren en ook niet onbelangrijk de ontvangende storage ook kunnen wegschrijven.
Dat zijn serieuze doorvoersnelheden die je zelfs bij Enterprise class storage niet vaak tegenkomt, hooguit als een burst naar cache maar niet 12 uur achterelkaar.

[Blaater]

Question Mark schreef op woensdag 19 juli 2017 @ 15:33:
[...]

Ik zeg ook niet dat de data naar een cloudoplossing moet, maar je zou wel een dergelijke oplossing kunnen gebruiken om de data naar je nieuwe DC te transporteren.

1. Kopieer data naar mobiel Datacenter
2. Rij mobiel Datacenter naar nieuwe Datacenter
3. Kopieer data vanaf mobiel DC naar nieuwe Datacenter

Bovendien gaat met zo'n oplossing de data niet van het DC af (die blijft daar beschikbaar). Je kopieert hem simpelweg naar storage die in het mobiele DC zit. Als de data in het geheel niet van het DC af mag, zou je deze ook niet mogen kopieren.

Zolang stap 1 binnen de 12 uur kan, voldoe je aan de uitgangspunten. Je noemt immers niet dat de data na die 12 uur direct weer beschikbaar moet zijn. Je hebt alleen genoemd dat je 12 uur lang toegang hebt tot de brondata.

Welke fysieke lokaties hebben we het eigenlijk over, en wat voor soort verbindingen zijn daar af te monteren (en te leveren binnen de tijdsframes).

Aah ok, ik had hem begrepen als zijnde dat het vanuit de 'container' naar een AWS omgeving zou worden geupload.

Als de data in het geheel niet van het DC af mag, zou je deze ook niet mogen kopieren. <-- Je hebt gelijk, ik had moeten formuleren: Data mag niet van het separate netwerk van de klant af, het mag de locatie verlaten, maar dan wel op een gecontroleerde manier totaal in beheer van de klant.

De data hoeft inderdaad niet direct toegankelijk te zijn, het gaat er enkel om dat de data na die 12 uur op locatie 2 is aangekomen.

- To do list voor morgen:
Maximale throughput van storage systeem gaan opzoeken en vastleggen.

Welke fysieke lokaties hebben we het eigenlijk over, en wat voor soort verbindingen zijn daar af te monteren (en te leveren binnen de tijdsframes).
Vanwege een NDA kan ik niet alles zeggen en heb ik ook enkele gegevens al wat moeten verdraaien etc. Maar deze case vonden wij zo interessant dat we het probleem wilden delen.
Locatie 1 moet nog gebouwd worden en het soort verbindingen is nog mogelijk om te wijzigen indien dit nodig is, het netwerk wordt door ons geleverd, er zijn SFP+ switches aanwezig in het design op dit moment, maar geen 200gbit/s.

Tortelli schreef op woensdag 19 juli 2017 @ 16:08:
Denk dat de data fysiek verplaatsen je meest realistische oplossing is. Als je data werkelijk wilt koppieren zul je hier echt een exotische oplossing voor moeten verzinnen;

Uitgaande van 500TB, welke in 12 uur verplaatst moet worden heb je volgende snelheid nodig;
500/12 = 42TB / uur = 700GB / minuut = 12GB / seconden
(heb geen echte rekening gehouden met 1.024 factor...)

Met een 10Gbit netwerk haal je maximaal zo'n 1,1GB / seconden in het gunstigste geval. Je zult een 100Gbit netwerk moeten hebben om dit te kunnen halen.
edit zie dat je zelf al een berekening had gemaakt van de benodigde verbinding

Hou er ook rekening mee dat je netwerk waarschijnlijk niet altijd vol zal trekken. Vooral kleine bestanden gaan meestal vrij traag, weet niet hoe dit op 100Gbit werkt .

Wij vermoeden hetzelfde nu dat we echt naar een systeem toe zullen moeten van fysieke verplaatsing van data. De backup solution zal een soort van swap systeem moeten worden, backup van locatie af en 'reserve' backup plaatsen en weer gaan met de boel. En een paar maanden later weer andersom.

Vandaag gesprek gehad hierover met een andere leverancier ook en die komen op korte termijn met hun ideeën hierover.

To do list morgen:
- Moet de backup solution na die 12 uur weer meteen werken of is er een start-up periode?

Tijntje schreef op woensdag 19 juli 2017 @ 16:20:
Zelfs met een 100Gbit netwerk is net maar net aan.
Dan kom je zonder overhead uit op 12.5 GB/s maar dan moet je storage dat ook continu kunnen leveren en ook niet onbelangrijk de ontvangende storage ook kunnen wegschrijven.
Dat zijn serieuze doorvoersnelheden die je zelfs bij Enterprise class storage niet vaak tegenkomt, hooguit als een burst naar cache maar niet 12 uur achterelkaar.

Dit idee hadden wij ook nu. Om het mogelijk te maken moeten we een redelijk infrastructuur aanleggen.
- Storage unit moet 200 Gbit/s aankunnen (zal een redelijke prijsverhoging zijn)
- Netwerk moet 200 gbit aankunnen (zal aardig prijzig zijn)
- Receiving end moet 200gbit aankunnen (zal er niet zijn nu)

Ik denk dat deze optie gewoon niet realistisch is en dat we moeten kijken naar de betrouwbare oplossing voor 'moving storage'.

Ik hou jullie op de hoogte met wat voor ideeën de leveranciers komen, en bedankt voor de input tot nu toe allen.

[Question Mark]

Blaater schreef op woensdag 19 juli 2017 @ 20:33:
[...]
- To do list voor morgen:
Maximale throughput van storage systeem gaan opzoeken en vastleggen.

Let erop dat dit een erg lastige is, en sterk afhankelijk is van het aantal en grootte van de files, alsmede het aantal simultane kopieeracties die je mogelijk kunt starten. Dat een storagesysteem een theoretische snelheid heeft, zegt lang niet alles. Real World kan dat namelijk enorm verschillen.

[Tijntje]

@Blaater Sorry voor de kick maar ik was toch wel benieuwd of jullie al een oplossing hadden gevonden?

[Blaater]

@Tijntje

Geen probleem, ik had hier al lang een update op moeten geven.

Het 'probleem' is iets minder groot geworden, we zijn nog steeds met onze supplier en klant bezig maar technisch gezien zijn de problemen opgelost. Het is nu enkel nog maar een performance en financieel plaatje waar we over praten.

De hoeveelheid data die uiteindelijk gebackupped dient te worden is nog maar 1/3e van waar we mee begonnen, de rest van de data hoeft niet geoffload te worden, en de locatie is ook niet meer afgesloten. Weliswaar met hele lage snelheden maar de backup zal nu ook direct naar de externe locatie gebeuren waardoor we niet meer met de 12 uur offloading zitten.

De eisen van de klant waren gewoon niet haalbaar, vandaar dat na overleg de eisen een stuk soepeler zijn geworden nu en er concessies van beide kanten zijn gedaan.

Enerzijds jammer dat we niet meer met een technisch dilemma zitten waar wellicht hele mooie oplossingen voor bedacht moesten worden, aan de andere kant was dit echt een hoofdpijndossier aan het worden in het grote geheel van het contract.