Tactieken bij 'Disaster Recovery'

Op de site Enterprise Storage Forum hebben ze zich verdiept in de tactieken die van pas komen wanneer een opslagmedium is gecrashed. Disaster Recovery richt zich hierbij op data-integriteit en beschikbaarheid van de gegevens. Zo werd jaren lang verkondigd dat het bewaren van back-up tapes in kluizen - die niet op het bedrijfsterrein stonden - een adequate oplossing was tegen uitval. De tapes konden namelijk makkelijk worden ingeladen voor een restore wanneer een systeem was uitgevallen en eventueel voor een sneller herstel werd er gekozen voor het beheren van twee gelijke systemen tegelijk. Het zogenaamde 'mirroring', waarbij het secundaire systeem de taken van het primaire systeem kan opvangen als deze uitvalt en op basis van dezelfde gegevens.

Deze filosofie was gebaseerd op uitvallen door redelijk onschuldige oorzaken, zoals onderhoud, een hardwaredefect of een fout van de beheerder. Er werd geen rekening gehouden met grootschalige gebeurtenissen, zoals stroomuitval in de hele regio en terroristische aanslagen. Nu deze gebeurtenissen zich ook voordoen, heeft de filosofie van de Disaster Recovery een ander pad moeten inslaan om de continuïteit van data-integriteit en beschikbaarheid te blijven waarborgen.

Vandaar dat er nu wordt gedacht aan datarecovery-mogelijkheden op lange afstand. Niet de afstand van New York naar New Jersey, maar afstanden verder dan 160 kilometer. Iets wat nu mogelijk is dankzij IP SAN-technologie, waarmee via glasvezel data ver voorbij de 160 kilometer kunnen worden verzonden. Hiermee is één probleem opgelost, maar er komt meteen een ander probleem om de hoek kijken, latentie. Voor elke 160 kilometer die wordt afgelegd door de gegevens komt er vanwege de lichtsnelheid 1ms aan latentie bij. En dat is alleen voor de heenweg, op de terugweg geldt het principe uiteraard ook.

Vandaar dat voor synchrone programma's aangeraden wordt om de afstand niet op te laten lopen en een maximum aan te houden van 320 kilometer. Dubbele afstanden worden in de praktijk weliswaar toegepast, maar de eventuele problemen die daaruit vloeien worden niet ondersteund door de leveranciers. Voor asynchrone applicaties is het latentieprobleem natuurlijk niet van toepassing, vandaar dat een datarecoverycentrum van zo'n bedrijf dan ook duizenden kilometers van het kantoorpand verwijderd kan zijn.

Het nadeel van zo'n grote afstand kan zijn dat een bewerking niet is overgekomen tijdens de uitval op de werkplek, waardoor de integriteit van de gegevens op het spel staat. Er wordt dan meestal ook gekozen voor een combinatie van beide mogelijkheden. Een regionaal centrum voor real-time en dus synchrone applicaties en vanaf het regionale centrum een verbinding met een stuk verder gelegen Disaster Recovery-centrum voor het asynchrone herstel.

Enkele nieuwe technieken die toegepast worden ter aanvulling van de nieuwe DR-filosofie zijn Fibre Channel over SONet (Synchronous Optical Network), Fibre Channel over IP (FCIP) en SAN Routing met behulp van het Internet Fibre Channel Protocol (iFCP). Zowel glasvezel via SONet als FCIP passen dezelfde methode toe als DWDM (dense wavelength division multiplexing) om gegevens over te brengen, alleen is de afstand een stuk groter. Daarnaast zijn de kosten ook een stuk lager in vergelijking met DWDM, vandaar dat de keuze niet is gevallen op het al langer bestaande DWDM.

Op het gebied van benodigde bandbreedte voor datarecovery op afstand, wordt er minimaal 45Mbps (T3) aangeraden. Hiermee kan bij volledige benutting van de capaciteit ongeveer 700MB per uur worden overgepompt, iets wat meer dan genoeg is voor de meeste synchrone datareplicatiesystemen. Echter, er wordt altijd gezocht naar een betere oplossing en die is er dan ook. Met behulp van datacompressie - zoals Fast Write - kan een tienvoudige hoeveelheid aan data worden verstuurd in dezelfde tijdsspanne.

Een andere mogelijkheid is om meerdere opslagprogramma's over dezelfde IP-structuur tegelijkertijd hun werk te laten doen, waardoor efficiënter gebruikt wordt gemaakt van de verbinding en ook meer flexibiliteit in de keuze voor IP-netwerkdiensten is. Momenteel zijn ongeveer duizend bedrijven bezig met het installeren van de verbeterde DR-techieken, waarbij er verbindingen tussen Europa, Noord-Amerika en Azië worden aangelegd. Met de verbetering én de komst van nieuwe IP-opslagtechnieken kunnen bedrijven in de toekomst nog beter bepalen hoe zij de datarecovery intern gaan toepassen en aan de hand van welke strategieën natuurlijk.

Reacties (46)

[dingstje]

Op het gebied van benodigde bandbreedte voor datarecovery op afstand, wordt er minimaal 45Mbps (T3) aangeraden. Hiermee kan bij volledige benutting van de capaciteit ongeveer 700MB per uur worden overgepompt

Eeh, volgens mij zit er hier een foutje in? 45 Mbps = ongeveer 5,5 MB/s, dus op twee minuten is die 700 MB al overgepompt.

[procyon]

Voor elke 160 kilometer die wordt afgelegd door de gegevens komt er vanwege de lichtsnelheid 1ms aan latentie bij

Latentie?
Latency is beter, sommige dingen moet je niet in het nederlands zeggen
Btw licht legt 299.792 KM af in een seconde, dus ruim 300KM in een ms.

[tweakerbee]

Licht doet dat alleen door een vacuum. Dan is het 299.792.458 meter per seconde om precies te zijn. Dat zal door glas echter wel niet gehaald worden

[Verwijderd]

Het licht beweegt zich altijd even snel door ieder materiaal.

Het licht (photonen) wordt echter door de atomen geabsorbeerd en weer uitgezonden. Dit zorgt voor een vertraging waardoor het licht langzamer lijkt te gaan:

http://www.physicsclassroom.com/mmedia/waves/em.html

i.a.o. aartdeheus en anderen: hier brengt men ook het licht niet echt tot stilstand

Physicists say they have brought light to a complete halt for a fraction of a second and then sent it on its way, an achievement that could someday help scientists develop powerful new computers.

The research differs from work published in 2001 that was hailed at the time as having brought light to standstill.

In that work, light pulses were technically "stored" briefly when individual particles of light, or photons, were taken up by atoms in a gas.

Het licht (de photonen) gaan dus altijd even snel breking ontstaat doordat verschillende atomen er verschillende tijd over doen om een photon weer uit te zenden nadat deze geabsorbeerd is.

Licht dat bounced in een glas vezel is ook evensnel, het doet er langer over om aan het andere eind te komen als licht dat niet bounced omdat het een landere weg moet afleggen.

Licht tot stilstand brengen is dus eigenlijk een foute term. Het licht wordt omgezet in een andere vorm en opgeslagen om op een later tijdstip weer te worden uitgezonden. Als je dit geheel kan controleren kan je dus geheugen maken gebaseerd op licht Dat zal sneller gaan dan met het huidige geheugen, wat gebaseerd is op electron migration als ik het me goed herinner.

[_Thanatos_]

Misschien, maar door glasvezel gaat het effectief dan toch langzamer

[Verwijderd]

re: Omega Supreme:

Het licht beweegt zich altijd even snel door ieder materiaal.

Maar eh,
http://www.tweakers.net/nieuws/30092/?highlight=licht+
Volgens mij zijn er al een paar jaar piepols bezig om photonen te remmen en te vertragen. Waarmee ik wil aangeven at licht du sniet door alles even snel beweegt, anders kan het niet dat er wetenschappers zijn die licht al eens tot onder de 50 mph hebben weten te vertragen, en in bovenstaand artikel zelfs tot stilstand hebben gebracht.

[Major 7]

Het licht beweegt zich altijd even snel door ieder materiaal.

Dat is niet waar.
Wel eens van brekingsindex gehoord?
Dat getal geeft aan hoeveel het licht langzamer gaat in glas dan in vacuüm.
Dus bij n=1,5 gaat het licht met ca. 200000km/s.
Afgezien nog van licht in glasvezel, dat zich "stuiterend' door de binnenkern beweegt, en daardoor effectief meer tijd kwijt is om aan de andere kant te komen.

[TheDataDude]

Het licht beweegt zich alleen op volle snelheid in een vacuum. Onder water gaat het "slechts" 200km/sec. Het is zelfs zo dat sommige deeltjes daar dan sneller dan het licht gaan, en dus een 'sonic boom' van licht achterlaten, waarmee ze gedetecteerd en gelokaliseerd kunnen worden.

[smokalot]

Ik denk dat de lichtsnelheid in glas dus ongeveer de helft is.

edit:
vergeten te refreshen

[tweakerbee]

Denk dat ze bedoelde ~ 16GB/uur. Overigens houd je dankzij ATM van die 45Mbps niet meer dan 4,5MB/s over. Tant pis.

[VisionMaster]

Over lange afstanden te samen met gebruik van TCP/IP is een hele hoop in de ontwikkeling.
Netherlight (vooral onder de hoede van SurfNET) doet hier erg veel aan met Lambda technieken. Eerst voor de wetenschap, later voor de gewone mens.

Als je Linux gebruikt dan is het misschien leuk om nog wat meer hier (http://archives.internet2...S/log200301/msg00005.html)
en (http://nikhef.antony.nl/writing/10-wan-phy-cern.pdf) en (http://carol.wins.uva.nl/%7Edelaat/techrep-2003-2-tcp.pdf)

[Verwijderd]

Tweakers.net zal er ook goed aan doen om hier eens over na te denken

(Gezien al die uitval de laatste tijd )

[Verwijderd]

De vergelijking tussen de oude en deze nieuwe manier ontgaat me enigzins. Het gepraat over latency van NAS. Wat is de latency van een bankkluis wel niet?
Het lijkt alsof men het maken van backups aan het vergelijken is met mirroring, en dat zijn toch twee verschillende zaken.

[Verwijderd]

Ik snap die opmerking over Fast write in het artikel niet helemaal... Bij backup tapes kom je meestal al niet eens meer aan een factor 2 compressie. Hoe wil je dan een factor 10 halen???

[4VAlien]

Alsof die tapes onbruikbaar zijn bij stroomuitval of een terroristische aanslag. Die computers doen dan ook niks dus dat lijkt me geen probleem.

[Verwijderd]

Nee, maar zoals bij het WTC gedoe toen. Daar was weinig van over van alle pc's en servers die daar gestaan hebben.

Opzich vind ik het verzenden van data naar een andere locatie wel een goed idee. Vooral bij internationale bedrijven zou dat een oplossing kunnen zijn. Zo hoef je je data niet bij een externe partij neer te leggen ivm beveiliging enzo.

Het bedrijf waar ik werkt heeft vestigingen in bijv. Frankrijk, Duitsland, Zweden, UK, Italie, US, Brazillie, etc (nu zijn die laatste twee wat ver voor een goeie overdracht) maar bijvoorbeeld Amsterdam zou de data best in Duitsland ergens kunnen backuppen.

Er zal dan alleen wel een dikke pijp naast moeten komen voor je backups, want die wil je niet over dezelfde lijn VPN laten gaan zodat voor de remote vestigingen het hele zooitje traag als dikke stront word. (Zitten nu nog met een 2Mbit lijn in ASD).

Leuk item om eens te bespreken.

[Verwijderd]

Als je gebruik maakt van bv ' Intelligent Data Flow Optimization ' van SystemV (http://www.systemv.nl) valt het best mee met de bandbreedte die je nodig hebt.

[Pwigle]

En jij bent zeker de grote baas van SystemV® ?

[Roland684]

En toch was er nog flink wat data te recoveren. Ongelofoelijk als je ziet hoe sommige schijven er aan toe weren.

http://www.convar.com/pdf/Focus.pdf

[mjtdevries]

Die tapes zijn niet onbruikbaar, maar de computers wel. En dat is WEL een probleem.
En als je uitwijk centrum in het gebied van de stroomuitval zit, dan zijn die dus ook onbruikbaar.

En ondanks dat je een goede disaster recovery strategy lijkt te hebben heb je dan ineens een dag downtime.

Moet je je voorstellen dat dat bedrijf als amazon of bol of zo gebeurd. Dan is dat een flinke strop, aangezien de klanten wel buiten het stroomuitval gebied zitten.

[Roflmao]

Voor elke 160 kilometer die wordt afgelegd door de gegevens komt er vanwege de lichtsnelheid 1ms aan latentie bij

1ms latency voor elke 160 km, dat is toch errug weinig, wat is eigenlijk het probleem dan

[DeBolle]

Bij synchrone mirroring hebben we het meestal over near-real time applicaties die van het disk subsystem een gegarandeerde response verwachten bij een write, iets tussen 2 en 4 ms - dus elke ms extra is 25 tot 50% trager dan wat je wilt.
Als je naast het main systeem een synchrone mirror neerzet - dus de applicatie wacht tot de mutatie daadwerkelijk naar disk is geschreven - zal de mirror bij grotere afstanden het hele systeem vertragen. Niemand accepteert een vertraging
Denk daarbij aan applicaties als vluchtreserveringssystemen, elke terminal waar ook ter wereld moet een gegarandeerde responsetijd hebben bij een write. Hoewel het stamt uit de mainframe wereld worden deze inderdaad erg lage responsetijden ook meer en meer geeist bij andere platformen.

[SoNoS]

Ik vraag mij af of dit soort backup methodes gebruikt gaat worden in Nederland. 320 km.. dan moet je al een pand hebben in duitsland of belgie. Niet iets wat elke bedrijf heeft lijkt mij.

[Olaf van der Spek]

Ja. Sara heeft bijvoorbeeld een lokatie in Almere en een in Amsterdam. Is niet zo ver (50 km gok ik), maar gebruikt wel dit soort technieken.
Daar ligt echter 1 gbit/s tussen dacht ik.

[Ma_rK]

KPN doet het al jaren. Alle telefoon gegevens worden in groningen gemirror opgeslagen over 2 lokaties die fysiek tussen de 10 en 30 km van elkaar gescheiden zijn. Het 2de centra is tevens zo ingericht dat deze het bij uitval van de eerste, zo over kan nemen. Als je ooit een kans krijgt om erheen te gaan moet je dat doen. Was eens het grootste NT netwerk van NL, en Microsoft is langsgeweest omdat ze niet geloofden dat dit in de lucht bleef.

[FreshMaker]

Same here, een redelijk forse fabriek in het zuiden ( nee, niet de lampenmeneer) heeft de backup's op verschillende datadragers bij de portier buiten het pand, en om de 2 dagen en elke vrijdag komt een koerier deze halen, en de data van de collega's in het oosten des land brengen.

mocht er iets gebeuren dan rijdt deze koerier weer 'even' op en neer

( ze doen dan al aardig modern mee , was het dan maar gem. 80 Km p/u, en niet op lichtsnelheid )

[Parody]

Wat was het ook alweer? Onderschat nooit de bandbreedte van een busje met backup-tapes? Maar goed, erg real-time is deze oplossing natuurlijk niet. En in het ergste geval ben je 2 dagen werk kwijt.

[Verwijderd]

Voor rampen als 11 sept, lijken me die 2 dagen werk niet zo significant meer....

[Verwijderd]

een belangrijk dit waar volgens mij niet over wordt gepraat zijn de gebruikers,
Heel fijn dat je al je data nog hebt ergens anders maar als er een boeing naar binnen vliegt zijn er niet al te veel medewerkers die die data nog kunnen gebruiken.
of ze zijn dood of hun pc is dood..
Het CUC in lelystad is een Bunker met hoofdletter B waar ontzettend veel servers gemirrored staan en waar ook werkplekken staan...
dat begint er al meer op te lijken he Getronics rules

[Verwijderd]

Werk jij in die bunker dan? Je idee slaat nergens op. Die mensen die zojuist bv. een brand hebben gehad denken echt niet aan werken (ook al zet je ze in een bunker). Men praat hier over backup oplossingen van bv. internationale bedrijven met meerdere vestingingen die door moeten kunnen werken als er een datacenter uitvalt.

[mjtdevries]

Het idee slaat wel degelijk ergens op. Na 11 september waren namelijk ook een heleboel omliggende kantoren voor zeer lange tijd onbruikbaar. Die mensen hadden niets, en konden wel weer relatief snel aan de slag.

Helaas is de capaciteit van uitwijkcentra er totaal niet op berekend dat er ineens zoveel kantoren tegelijkertijd kapot gaan.

En dat betekent dus dat die mensen moeten uitwijken naar overvolle resterende kantoren en met zijn vieren 1 telefoon op een kamer op kantoor moeten delen.
Iedereen moet ineens webmail krijgen want de computerfabrikanten konden niet al die bedrijven zo snel van nieuwe computers voorzien en je moet toch je mail kunnen lezen etc etc. (moet je dan maar thuis vanaf je eigen computer doen)

Dat soort zaken zijn wel degelijk ook van belang bij disaster recovery.