Management Services
5/9.2 PlateSpin Protect 5/9.2.1 Businessredenen voor Protect Onderzoeken van Gartner en IDC tonen aan dat veel organisaties eigenlijk niet voldoende voorbereid zijn op echte problemen en de dagelijkse praktijk onderstreept wat deze onderzoeken ook aangeven: voor veel organisaties is het onderwerp ‘disaster recovery’ iets waar ofwel weinig over wordt nagedacht, ofwel waarbij als antwoord wordt gegeven: ‘We maken iedere avond een back-up’. Tekortkomingen tape-back-up
Laat duidelijk zijn: het maken van een tape-back-up is zeker een vorm van disaster recovery, maar een die in slechts heel weinig gevallen nog als een echte optie kan gelden (zeker als het de enige maatregel is die is genomen). Het meest voor de hand liggende argument tegen het gebruik van tapes is de tijd die het kost om in het geval van een disaster (alles is weg, u hebt alleen uw tapes nog) terug te komen naar een werkende situatie. Hopelijk hebt u als organisatie in ieder geval de tapes offsite opgeslagen, zodat in het geval van een brand in de serverruimte alleen uw servers en niet ook uw tapes vernietigd zijn. Offsite opslaan is vanuit het oogpunt van recovery een goede gedachte, maar zorgt er ook voor dat wanneer zich een probleem voordoet, het meer tijd kost om systemen weer up te krijgen. In een recent praktijkvoorbeeld waarbij een datavolume corrupt was geraakt, zou het terugzetten van data in totaal ruim 72 uur geduurd hebben! Afhankelijk van het type gegevens en de aard van de organisatie zou dat wellicht nog acceptabel kunnen zijn, maar in dit specifieke geval was dat absoluut niet zo. Het probleem was dat niemand ooit over de doorlooptijd van een restore had nagedacht. Gelukkig waren we in dit specifieke geval in staat de corruptie van het
Novell Netwerkoplossingen, aanvulling 33
5/9.2-1
PlateSpin
volume te herstellen, waardoor de restore uiteindelijk niet nodig was. Dat brengt ons direct bij een tweede probleem met tapeback-ups: blijkbaar was er in het bovengenoemde geval nooit een echt goede test gedaan hoe lang het terugzetten van een tape zou duren en was er een duidelijke discrepantie tussen de tijd die een restore zou kosten en de tijd dat de organisatie zonder data zou kunnen. Een gouden uitgangspunt voor iedere disaster-recoveryprocedure is dat die opgezet moet worden met de restore als uitgangspunt, niet de back-up. Het is daarom beter om nooit meer de term ‘back-upprocedure’ te gebruiken, maar ‘restoreprocedure’, of beter nog ‘disaster-recoveryprocedure’. Een derde tekortkoming van tape-back-ups en van heel veel restoreprocedures is dat een tape-back-up, als u geluk hebt, één keer per dag (meestal in de nacht) gedaan wordt. Als u geluk hebt, want door de almaar groeiende hoeveelheid data zijn steeds minder organisaties in staat iedere nacht nog een volledige back-up te maken van alle data en maken zij gebruik van incremental of differential back-ups. Begrijp goed: mits alles goed is ingesteld en de software zijn werk doet, is er geen reden om een incremental of differential back-up als ‘minder goed’ te zien dan een volledige back-up, maar de praktijk wijst ook hier uit dat alleen de theorie eenvoudig is en de praktijk toch soms lastiger. Los van deze constatering moet u zich realiseren dat alle data sinds de laatste back-up verloren zijn gegaan. Dat betekent dat u acht uur werk kwijt zou kunnen raken. Ook hier geldt dat het wellicht voor bepaalde data geen echt probleem is als er ‘iets’ weg is, maar hoe dan ook moet iedereen in de organisatie na de restore nagaan wat nog wel beschikbaar is en wat niet.
5/9.2-2
Novell Netwerkoplossingen, aanvulling 33
Management Services
Steeds meer organisaties hebben inmiddels ook te maken met compliancy-eisen en kunnen het zich vanwege deze regels ook niet veroorloven om ‘een dag productie’ kwijt te raken. Zelfs als de frequentie van de back-ups binnen de organisatie is afgestemd op de maximaal mogelijke uitval, dan nog zullen de systemen in praktijk bij een disaster minder gemakkelijk terug te brengen zijn dan wordt aangenomen. In situaties waarin we in praktijk uitwijkscenario’s hebben getest (‘hier is een tape en een nieuwe server’), was het zelfs met NetWare pas na een tweede of derde poging mogelijk de machine daadwerkelijk binnen een redelijke termijn weer in de lucht te brengen: door het ontbreken van installatiesoftware of eenvoudigweg drivers voor de nieuwe machine is het lastiger om (onder druk) een machine te installeren dan u zou verwachten, en dan is NetWare nog heel gemakkelijk als het gaat om hardware. Windows en Linux zijn veel kieskeuriger wat betreft hardware en met het uitfaseren van NetWare nemen onze problemen dus alleen maar toe. En dan hebben we het nog niet eens over de patches die kort geleden geïnstalleerd zijn maar (nog) niet gedocumenteerd, waardoor de database op een verse nieuwe installatie opeens niet meer werkt of (nog erger) niet correct werkt! Kortom: tape-back-ups hebben absoluut nut, maar vanuit het oogpunt van een snel en gemakkelijk herstel bij een disaster is het eigenlijk alleen een ‘laatste redmiddel’ en moeten we kijken naar oplossingen die alle bovengenoemde issues slimmer, efficiënter en sneller kunnen oplossen. Om te kijken naar oplossingen voor disaster recovery moesten we voorheen een duidelijk onderscheid maken tussen enerzijds fysieke systemen en anderzijds gevirtualiseerde Novell Netwerkoplossingen, aanvulling 33
5/9.2-3
PlateSpin
systemen. De terminologie die gebruikt wordt binnen zowel de virtualisatiewereld als het vakgebied van disaster recovery is ‘workload’ en die term zullen wij vanaf nu dus ook gebruiken. Een workload is de combinatie van het OS, de applicatie en de data van die applicatie.
Figuur 5/9.2-1 Een workload is de combinatie van OS, applicatie en data van die applicatie.
Vanuit het oogpunt van disaster recovery is het verstandig voor iedere workload een profiel op te stellen waarin wordt beschreven waar de workload toe dient en hoe belangrijk dit systeem is. Los van tape-back-ups (een technologie waar we zeker niet mee moeten stoppen, maar die voor een snelle recovery niet voldoende is) is het maken van een image van systemen een van de meest gebruikte manieren om weer snel online te zijn. Virtuele systemen zijn in dit geval vaak de eenvoudigste workloads om te beveiligen: het is voldoende om de disk images en de configuratiebestanden veilig te stellen om weer een werkend systeem te kunnen hebben. In bijvoorbeeld een VMware-omgeving kunnen deze bestanden eenvoudig naar een andere server gekopieerd worden en zullen daar zonder enig probleem kunnen draaien. De meeste 5/9.2-4
Novell Netwerkoplossingen, aanvulling 33
Management Services
nieuwe, grote virtualisatieoplossingen zijn zelfs in staat dit te doen zonder het systeem down te hoeven brengen. Zelfs zonder al te ingewikkelde tools is het hierdoor mogelijk regelmatig (afhankelijk van het workloadprofiel) een kopie te maken naar een andere server en u hebt dan een redelijk disaster-recoveryplan. Zeker als u dit kunt automatiseren (en liefst) zonder de workload offline te halen, kunt u in alle redelijkheid de meeste disasters redelijk aan (even nog niet denkend aan het offsite hebben van die images, wat in principe alleen bandbreedte en een beetje kennis van IP vergt). Het leven van een disaster recovery engineer in de virtuele wereld is redelijk goed. Voor fysieke systemen is het vaak al een groter probleem. Ook hier wordt vaak imagesoftware gebruikt (zoals ZENworks Imaging, Ghost, Acronis of Clonezilla) die een image maakt van de workload. Afhankelijk van de gekozen oplossing, het gebruikte OS en de gebruikte applicatie kan ook dit soms zonder de workload down te hoeven brengen voor het maken van de image. Bij een hardwarestoring is een bijkomende complicerende factor echter dat deze image eigenlijk alleen op dezelfde hardware teruggezet kan worden. Kleine verschillen zijn vaak nog wel op te lossen (andere netwerkkaart bijvoorbeeld, hoewel velen niet zullen weten hoe ze onder Linux die nieuwe kaart ook eth0 laten heten), maar zodra u probeert een image van (bijvoorbeeld) Windows Server 2003 die gemaakt is op een server van drie jaar oud, terug te zetten op de splinternieuwe vervanger, dan kunt u toch voor behoorlijke verrassingen en uitdagingen komen te staan. Een oplossing is natuurlijk om een aantal servers tegelijk te kopen en een (of enkele) van die serie ‘op de plank’ te houden. Vanuit disaster recovery is dit ook zeker geen vreemde oplossing, maar ze is vooral werkbaar voor grote organisaties, die gemakkelijk een extra server mee kunnen bestellen in een grote order. Novell Netwerkoplossingen, aanvulling 33
5/9.2-5
PlateSpin
PlateSpin Protect levert een totaaloplossing voor disaster recovery die rekening houdt met alle hierboven genoemde problemen en organisaties een flexibele en efficiënte disaster recovery kan bieden. 5/9.2.2 Mogelijkheden van PlateSpin Protect PlateSpin maakt het mogelijk migraties uit te voeren van de ondersteunde besturingssystemen, waarvan de meeste zonder dat het systeem down hoeft te gaan. Het doel van het maken van de kopieën is om in het geval van een disaster de kopie in de lucht te kunnen brengen en de taak te kunnen laten overnemen van de originele server. PlateSpin ondersteunt X2X-migraties, waarbij X kan staan voor een fysieke workload, een virtuele workload of een image.
Figuur 5/9.2-2 PlateSpin ondersteunt X2X-migraties.
5/9.2-6
Novell Netwerkoplossingen, aanvulling 33
Management Services
Soorten migraties
Kopieën maken kan binnen PlateSpin op een aantal manieren: file-based, block level of VSS-based. Welke optie de meest geschikte is (en welke überhaupt mogelijk is), hangt af van een aantal dingen, waaronder het target-OS en de manier waarop de applicatie het bestandssysteem gebruikt. In alle gevallen is PlateSpin in staat om na een initiële kopieerslag daarna alleen veranderingen te kopiëren, waardoor het maken van updates van de back-upworkload heel snel kan gaan. Als PlateSpin-images gebruikt worden, kunnen er zelfs maximaal 32 snapshots worden bijgehouden en kunnen individuele bestanden uit de image worden hersteld. • File-based migraties lezen initieel de diskinformatie en alle bestanden van de disks van de targetsystemen en slaan deze op. Daarna wordt bijgehouden welke bestanden worden aangepast en worden alleen die bestanden (als ze geüpdatet en weer afgesloten zijn) opnieuw gekopieerd. File-based migratie is een goede oplossing voor workloads zoals homedirectory’s waar steeds enkele bestanden veranderen. • Block-based migratie werkt op basis van disk blocks. Het systeem houdt nu de status van ieder storage block op de disk bij en als een block gewijzigd wordt, wordt die geüpdatet. Deze vorm van synchronisatie is vooral geschikt voor databases en voor synchroniseren over trage verbindingen (denk aan internet). Het ‘nadeel’ van deze methode is dat op het hostsysteem een driver geïnstalleerd moet worden die in de gaten houdt welke blocks veranderen en die informatie doorzendt naar PlateSpin. Na de installatie moet het systeem een keer rebooten om de driver actief te maken, maar werkt voor de rest onzichtbaar op het targetsysteem. • VSS is een technologie die Microsoft heeft toegevoegd aan server-OS’en vanaf Windows Server 2003. VSS staat voor ‘volume snapshot system’ en gebruikt een snap-
Novell Netwerkoplossingen, aanvulling 33
5/9.2-7
PlateSpin
shottechnologie die embedded is in het OS. PlateSpin kan samenwerken met deze software en op basis van de VSS-technologie updates maken van het back-upsysteem. Dit is vooral belangrijk voor workloads waarop Microsoft SQL of Microsoft Exchange draait, aangezien die nu niet langer offline hoeven om een image te kunnen maken of te updaten. PlateSpin ondersteunt een aantal besturingssystemen als target-OS: • Windows Server 2008, Vista, Server 2003, XP, 2000 Server en NT4; Windows 7-ondersteuning komt in de volgende release; • Red Hat 7.3, 8, Enterprise 2, 3, 4, 5; • SuSE Linux 8, 9, 10, 11; • Solaris 10. Niet al deze besturingssystemen worden op dezelfde manier ondersteund. Zo is het niet altijd mogelijk om een image te maken of te updaten zonder dat de machine down hoeft en wordt op Linux bijvoorbeeld wel LVM ondersteund, maar niet EVMS. Een mogelijk scenario voor een disaster-recoveryoplossing zou kunnen zijn om fysieke servers regelmatig (bijvoorbeeld iedere vijftien minuten of één keer per dag) te updaten naar een kopie die draait binnen een virtuele omgeving. PlateSpin heeft op dit punt een unieke positie in de markt omdat het zich niet beperkt tot een enkele virtualisatieoplossing, maar kan werken met alle grote virtualisatieoplossingen: • ESX 3 & 4; • Citrix Xen 4.1, 5 & 5.5; • Xen draaiend op SLES 10 & 11; • HyperV en HyperVr2; 5/9.2-8
Novell Netwerkoplossingen, aanvulling 33
Management Services
Virtual Iron; • Microsoft VS. •
Componenten
5/9.2.3 Architectuur PlateSpin Protect werkt met een aantal componenten: • De PlateSpin-server. Op deze server worden de taken bijgehouden, wordt logging gedaan en wordt de scheduling gedaan. • De PlateSpin-client. Dit is de machine waarop de beheerder daadwerkelijk de jobs aanmaakt en beheert. De client mag op dezelfde machine geplaatst worden als de server, maar er kan ook voor worden gekozen dit deel op een ander systeem te installeren. • Protected workloads. Dit zijn de workloads die PlateSpin beveiligt. 5/9.2.4 Scenario’s PlateSpin Protect kan op een aantal manieren worden ingezet om workloads van de organisatie te beschermen. De meest voor de hand liggende zijn: • Offsite Protect. Hierbij wordt de image (of eventueel zelfs de implementatie op een virtuele server) gemaakt op een andere locatie om zodoende bescherming te bieden tegen het meest drastische disaster dat kan voorkomen: een kantoor brandt volledig uit. U kunt hierbij denken aan organisaties met kleine branches die op de hoofdlocatie een centrale back-up hebben van alle workloads van de kleine vestigingen, of een situatie waarin de workloads van een bedrijf in bijvoorbeeld een datacenter worden bewaard. • Herstellen van virusinfecties. Als er meerdere snapshots zijn gemaakt (en bedenk: we kunnen er tot 32 per workload bewaren), kunt u eenvoudig de laatste snapshot die gemaakt is voor de uitbraak terugplaatsen op de server(s) die aangetast is (zijn) en u bent snel weer
Novell Netwerkoplossingen, aanvulling 33
5/9.2-9
PlateSpin
in productie. Doordat ook het terugzetten van de images werkt op basis van verschillen en niet de hele image terug hoeft te worden gezet, kan dit een kwestie van minuten zijn (afhankelijk van de situatie en grootte van de image en snapshot). • Testen van aanpassingen (instellingen/patches). Door een kopie van een productieomgeving te maken en deze op een geïsoleerd LAN in de lucht te brengen, kunt u perfect testen of patches en andere aanpassingen het gewenste resultaat hebben, zonder enig risico of downtime in de productieomgeving.
5/9.2-10
Novell Netwerkoplossingen, aanvulling 33
