Server & Storage special

Voor elk business continuity probleem een eigen oplossing

Hoewel storage-systemen zelf al verschillende interne beveiligingen bevatten - denk aan RAID en redundante hardware - worden er ook op LUN-niveau meestal meerdere copieën van de data bewaard of zelfs real-time bijgehouden. Afhankelijk van het doel en het belang kan uit verschillende typen snapshots en replica's worden gekozen.

De ondersteuning van replicatie is het belangrijkste verschil tussen de low-end MSA en de mid-range EVA storage -producten van HP. De beheerders van EVA-systemen zullen hieraan gerelateerde werkzaamheden meestal uitvoeren in de Replication Solutions Manager, een stand-alone tool speciaal voor het opzetten en onderhouden van replicatie-configuraties en snapshots.

Dezelfde functionaliteit is weliswaar ook beschikbaar via de EVA command line. Maar het handmatig uitvoeren van scripts en commando's gebeurt in het algemeen slechts bij uitzondering. Bijvoorbeeld als een telecom-aanbieder er om veiligheidsredenen op staat alleen een ssh-ingang (Secure Shell) aan te bieden.

Rampen

De EVA storage-producten ondersteunen verschillende soorten snapshots en replicatie. Het belangrijkste onderscheid ligt tussen de Business Copy en de Continuous Access, ook gekoppeld aan twee verschillende licenties. De eerste vorm blijft beperkt tot copieer-opdrachten binnen het storage array zelf. Daarmee kan men zich beschermen tegen logische fouten. De Business Copy moet dan ook worden gezien als de eerste trap in de totale backup-hiërarchie (vergelijk online disk-to-disk backup).

Bij de tweede vorm wordt alle data naar een andere locatie gecopieerd (remote replicatie), zodat de gegevens beschermd zijn tegen rampen. Door in dat tweede datacenter ook voor reserve server-systemen te zorgen - bijvoorbeeld in de vorm van blades - kunnen processen gewoon worden overgenomen als het eerste datacenter niet meer beschikbaar is, bijvoorbeeld door een overstroming, een aardbeving of een brand.

Snapshot

De meest eenvoudige en snelste vorm van de Business Copy is de Snapshot. Daarbij worden alleen de pointers naar de datablokken gecopieerd. Op die manier wordt een instant copie gemaakt van de huidige inhoud. In de EVA-producten kunnen per LUN (Logical Unit Number) maximaal zestien van die copieën naast elkaar bestaan. Normaal gesproken is dat aantal meer dan voldoende.

Wordt naar een snapshot geschreven, dan mag die data natuurlijk niet in de originele blokken terecht komen. In dat geval wordt een nieuw blok in de vrije ruimte geplaatst en de pointer in de snapshot aangepast. Naarmate dat vaker gebeurt, lopen de twee copieën natuurlijk steeds meer uiteen en zal de snapshot steeds meer datablokken voor zichzelf opeisen. Hiervoor hoeft echter geen ruimte te worden gereserveerd (als de vrije ruimte "vol" is, dan stopt de snapshot gewoon).

De snapshot is dan ook niet bedoeld als een echte copie om verder mee aan de slag te gaan, maar als een snelle en efficiënte bescherming tegen logische fouten, vooral bedoeld voor de kortere termijn. Een restore is slechts een kwestie van unmounten en weer mounten. De datablokken worden vervolgens op de achtergrond gecopieerd.

Kloon

De SnapClone begint als een Snapshot maar gaat een stap verder. Nadat de pointers zijn gecopieerd worden de datablokken op de achtergrond overgenomen. Voordeel van deze aanpak is dat het een echte copie oplevert, maar dan wel een die direct beschikbaar is.

Tenslotte is er nog de MirrorClone. Dit is in feite een synchrone replicatie, maar dan locaal. Je kunt dat over verschillende disk-groepen doen, bijvoorbeeld van een snellere (duurdere) groep naar een langzamere (goedkopere) groep. Alle veranderingen in de ene groep worden dan direct overgenomen door de andere.

Business Continuity

En daarmee zijn we aanbeland bij de Continuous Access, ofwel remote replicatie. Deze configuratie wordt opgezet tussen twee identieke copieën, meestal in verschillende datacenters. Valt het storage-systeem in het operationele rekencentrum uit, dan kan de replica het overnemen.

Om de twee disk-groepen in sync te houden, worden alle transacties door de controllers naar het netwerk gecopieerd. Omdat deze copie op LUN-niveau plaatsvindt, is ze onafhankelijk van het onderliggende medium. Daarvoor wordt meestal een Direct Fibre Channel (Dark Fiber) verbinding of een FC-IP-gateway (een transparante tunnel voor Fibre Channel over IP) gebruikt. De keuze is afhankelijk van wat men al in huis heeft. Grotere bedrijven hebben vaak al Dark Fiber tussen hun locaties liggen. Denk aan een campus-omgeving of verschillende kantoren in dezelfde stad. Daarbuiten wordt meestal gekozen voor een FC-IP-gateway. Waar Direct Fibre Channel op basis van long-distance laser optics beperkt is tot 35 kilometer, heeft FC-over-IP die beperking niet. Op langere afstanden gaat wel de vertraging op de lijn zelf een rol spelen.

Consistent startpunt

Is het netwerk of het tweede storage-systeem om wat voor reden dan ook niet beschikbaar, dan kan de verdere verwerking van transacties automatisch worden gestopt. Dat gebeurt bijvoorbeeld bij banken, waarbij de twee systemen altijd precies in sync moeten zijn. Maar meestal worden de veranderingen gebufferd in de Write History log (vergelijk asynchrone replicatie), totdat het tweede systeem weer beschikbaar is. Op die manier kan men in - ieder geval voorlopig - doordraaien en ondertussen proberen de problemen op te lossen voordat de Write History volloopt of een onaanvaardbare achterstand bereikt.

Gaat niet het tweede maar het primaire storage-systeem plat, dan moet (handmatig) worden overgeschakeld naar de fail-over opstelling. Meestal heeft men in het tweede datacenter de servers al voorgeconfigureerd (pre-setup). Vaak worden deze bijvoorbeeld gebruikt als OTA-omgeving (Ontwikkeling, Test en Acceptatie). Voor wat betreft de storage wordt simpelweg de richting van de replicatie omgedraaid. Daarmee gaan weliswaar de transacties in de cache van storage array nummer één verloren, maar hebben de applicaties wel een consistent startpunt.

Gecontroleerd

Dat voor het overschakelen naar de fail-over opstelling de interventie van de beheerder vereist is, gebeurt om de consistentie te waarborgen en het systeem gecontroleerd weer op te brengen. Automatische fail-over kan ook, maar dan in een zogenaamde stretched-cluster omgeving. Daarbij zijn de cluster-nodes ook over de twee datacenters verspreid.

In de praktijk worden lokale en remote replicatie vaak gecombineerd. Dan wordt op de uitwijk-locatie een Snapshot gemaakt, die vervolgens weer naar tape wordt geschreven. Op die manier zijn de backup-tapes ook gelijk off-site.