Op zoek naar de heilige graal

Transcriptie

1 virtualisatie DOOR bram dons VMware High Availability & Fault Tolerance Op zoek naar de heilige graal 48 Al enkele jaren biedt VMware met VMware High Availability (HA) een manier om de downtime van applicaties tot een minimum te beperken. Met vsphere 4, vorig jaar mei verschenen, is daar een nieuwe optie bijgekomen: VMware Fault Tolerance (FT). VMware FT brengt continuous availability naar de ESX-omgeving, zo klinkt het. Tijd om te zien wat er waar is van die mooie woorden. Dat servervirtualisatie tot een flinke efficiëntieslag kan leiden in datacenters en computerruimtes, zal geen verrassing heten. Het is een ideale manier om meer te doen met minder. Maar hoe meer we consolideren en hoe efficiënter we de aanwezige bronnen gebruiken, des te afhankelijker we worden van het feilloos functioneren van al die technologie. Eén storinkje, één verkeerde handeling, en voor je het weet knalt de ene na de andere cruciale dienst eruit. Toch is het onverstandig dan maar meteen de portemonnee te trekken voor allerhande dure beschermingstechnieken. Niet alle applicaties zijn even belangrijk voor een onderneming. Het bieden van een continue beschikbaarheid voor elke applicatie in elk denkbare situatie is dan ook onnodig. Beter is het om per applicatie te bekijken welk beschikbaarheidsniveau we financieel en praktisch gezien nog kunnen verantwoorden. Daarbij funge- ren meetwaarden als de RTO, RPO en TCO meestal als leidraad. Bovendien is het in veel gevallen mogelijk om dure Figuur 1: Architectuur VMware HA (bron: VMware) Niet alle applicaties zijn even belangrijk voor een onderneming serverclusters en remote mirroring te vervangen door slimme combinaties van standaardhardware met specialistische software. Een woord van waarschuwing: wie zich gaat verdiepen in deze materie moet goed oppassen. In de wereld van de high availability worden namelijk verschillende benamingen gehanteerd die soms naar hetzelfde verwijzen. Onderzoeksbureau

2 Figuur 2: Werking VMware vlockstep (bron: VMware) IDC maakt in elk geval onderscheid tussen vijf verschillende niveaus: continuous availability, high availability, disaster recovery, reliability en unprotected. Disaster recovery gaat over het herstel van IT-diensten na een catastrofe. High availability betekent dat applicaties vrijwel geen downtime kennen. Continuous availability, het niveau dat VMware Fault Tolerance (FT) ons moet brengen, is de heilige graal van deze industrie: het hoogst haalbare beschermingsniveau, waarbij applicaties gegarandeerd non-stop beschikbaar zijn. failover. Bij verwijdering van een primary host promoveert een van de andere hosts naar het elitegroepje. Willen we dat VMware HA naar behoren functioneert, Nadeel van VMware HA is dat de VM enige tijd inactief is dan moet er minstens één primaire host aanwezig zijn. Een van die primaire hosts krijgt de rol van opperhoofd toebedeeld. Deze host beslist waar een virtuele machine wordt herstart. Daarnaast houdt hij het aantal mislukte herstartpogingen bij en bepaalt hij of het zinvol is om te blijven proberen een VM te herstarten. De agents communiceren continu met elkaar en houden de beschikbaarheid van de clusternodes in de gaten. Dit gebeurt door elke seconde een zogeheten heartbeat uit te wisselen. Als er een periode van vijftien seconden verstrijkt zonder dat er een heartbeat is ontvangen en de host in kwestie ook niet kan worden gepingd, dan wordt de host als uitgevallen beschouwd. De op dat moment actieve virtuele machines worden dan op de hosts met de grootste capaciteitsreserve herstart. Als een host zelf geen heartbeats meer ontvangt van de andere hosts in het cluster, zal hij na twaalf seconden proberen zijn isolation addresses te pingen. Mocht dat niet baten, dan verklaart de host zichzelf geïsoleerd van het netwerk. Ligt de netwerkverbinding van de geïsoleerde host er langer dan vijftien seconden uit, dan zullen de andere hosts proberen zijn virtuele machines over te nemen. De VM Monitoring-service evalueert of de virtuele machines in het cluster nog functioneren door te kijken naar de heartbeats van het VMware Tools-proces dat in de gast draait. Bij problemen is er waarschijnlijk iets aan de hand met het gast- OS. Ook kan het zo zijn dat VMware Tools niet genoeg tijd krijgt om zijn taken af te ronden. De VM Monitoring-service zal dan tot de conclusie komen dat de virtuele machine eruit ligt, om vervolgens een reboot te initiëren. Lukt dat niet, dan worden er standaard nog twee pogingen ondernomen. Daarna geeft VMware HA het op. 49 VMware High Availability Het al langer verkrijgbare VMware High Availability (HA) biedt basale bescherming voor virtuele machines door ze bij uitval van een ESX-server op een andere ESX-server te herstarten (zie figuur 1). Door twee of meer ESX/ESXi-hosts in een clusterconfiguratie op te nemen, creëren we een niveau van beschikbaarheid dat hoger is dan mogelijk zou zijn met een enkele ESX/ESXi-host. Het werkt als volgt: bij toevoeging van een server aan een HA-cluster wordt er een agent naar de host geüpload. Die wordt vervolgens geconfigureerd voor de communicatie met de andere clusteragents. De eerste vijf toegevoegde hosts fungeren als primary host, alle daarop volgende krijgen de rol van secondary host toebedeeld. De primaire hosts onderhouden en repliceren de clusterstatus en starten indien nodig een Figuur 3: Testconfiguratie VMware HA en FT

3 50 Figuur 4: De compliance van het HA-cluster wordt gecheckt VMware Fault Tolerance Het al in VMware Infrastructure 3 ondersteunde VMware HA voorziet in een basisbescherming tegen uitval van virtuele machines ten gevolge van het uitvallen van een host. Nadeel van deze aanpak is dat de virtuele machine enige tijd inactief is. VMware FT, een van de features van VMware vsphere 4, moet een stokje steken voor dergelijke tijdelijke downtime. Hierdoor geniet elke virtuele machine bescherming tegen uitval van een host zónder dat er data, transacties of netwerkverbindingen verloren gaan. Om tot deze vorm van continuous availability te komen, vertrouwt VMware FT op de zogeheten vlockstep-technologie (zie kader VMware vlockstep ). Deze techniek zorgt ervoor dat de x86-instructies van een primaire VM worden bijgehouden op een tweede, identieke VM. De primaire VM vangt alle inputs en events af (afkomstig van processors en virtuele I/O-devices), die daarna identiek op de secundaire VM worden uitgevoerd. In feite voert de secundaire VM dus dezelfde opeenvolgende instructies uit als de primaire VM, met dien verstande dat de hypervisor de output van de secundaire VM zal onderdrukken. Valt de host waarop de primaire VM draait uit, dan vindt er een transparante failover plaats, waarbij de nog werkende host ongemerkt de rol van primaire host op zich neemt. Wanneer de uitgevallen host weer online komt, dan zal de VM die eerst actief was automatisch gestart worden en is de redundante serverconfiguratie weer hersteld. Het totale failover- en failbackproces verloopt volkomen transparant en automatisch, zonder merkbare gevolgen voor de gebruiker. Contact met vcenter Server is niet nodig. Beperkingen en aanbevelingen Om VMware HA en FT in de praktijk te testen, configureren we een VM-cluster bestaande uit twee nodes. Beide ESX-servers zijn verbonden via een drietal 1 GbEnetwerken: een iscsi-netwerk, een netwerk voor de FT-logging en een managementnetwerk. Binnen de HA-clusters worden de netwerken gebruikt voor het uitwisselen van heartbeats en natuurlijk voor de noodzakelijke HA-communicatie. Deze communicatie vindt plaats over alle serviceconsolenetwerken. Met het oog op redundantie adviseert VMware dan ook om per server twee serviceconsolenetwerken te definiëren. Het VMkernel-netwerk wordt door de hosts niet gebruikt voor HA-communicatie. Zoals gezegd moeten de servers zijn uitgerust met processors die FT-compatibel zijn. Daarnaast is het nodig hardwarevirtualisatie (HV) te activeren in de server- BIOS. De VM-bestanden moeten op een gedeelde opslag staan (Fibre Channel, hardware- of software-iscsi, NFS of NAS). In onze test maken we gebruik van een software-shared iscsi-disk op basis van StarWind 5.0 High Availability Storage. StarWind biedt mirrored storage tussen twee iscsi-targets (Windows Server 2008), waardoor het VMware-cluster beschermd is tegen uitval van de shared storage (zie figuur 3). Beide iscsi-storagetargets zijn verbonden via een 10 GbEnetwerk. De twee ESX-servers zijn uitgerust met een Intel Xeon E5520-CPU Valt de primaire host uit, dan vindt er een transparante failover plaats Figuur 5: Activatie VMware FT op virtuele machine (quad-core) en 8 GB intern RAM. Voor het beheer van het VMware-cluster installeren we vsphere 4 Enterprise Plus op een

4 VMware vlockstep VMware vlockstep werkt op basis van een record/replay-mechanisme (zie afbeelding 2). Daarbij worden de uitgevoerde instructies op de primaire VM opgeslagen in een logbestand. Dezelfde technologie werd al eerder toegepast in VMware Workstation, waardoor je naar een bepaalde gebeurtenis kon terugspringen. Lockstepping, oftewel het synchroon bijhouden van CPU-instructies, is dus geen nieuwe technologie. Stratus Technologies doet het al enkele jaren met succes op hardwareniveau, en ook Marathon Technologies zit met het product everrun 2G in de lockstephoek. De output van de secundaire VM wordt door de hypervisor onderdrukt De met vlockstep opgenomen informatie wordt op een andere (secundaire) VM afgespeeld zodat er een replica van de originele VM ontstaat. Beide VM s maken daarbij gebruik van dezelfde gedeelde virtuele diskfile. Hoewel de VM s dezelfde input ontvangen, produceert alleen de primaire VM output in de vorm van diskwrites en netwerktransport. De output van de secundaire VM wordt door de hypervisor onderdrukt en is niet op het netwerk aangesloten. Dat gebeurt pas op het moment dat het de rol van de primaire VM moet overnemen. In feite werken beide VM s dus als een enkele VM. Overigens worden niet alle veranderingen op de primaire VM naar de secundaire VM gekopieerd: er zijn nu eenmaal bepaalde acties en instructies die niet relevant zijn voor de secundaire VM. De opslag van een complete replica zou ook te veel beslag leggen op de beschikbare hoeveelheid opslagruimte en procesvermogen. In plaats daarvan worden alleen zogeheten non-deterministic gebeurtenissen opgeslagen, waaronder de inputs naar de VM en bepaalde CPU-events. Hoewel niet strikt noodzakelijk, is het raadzaam een dedicated Gigabit-NIC (liefst 10 GbE) in te zetten voor het loggingverkeer. De hoeveelheid uitgewisselde informatie kan, afhankelijk van de activiteit op de VM, namelijk behoorlijk intensief zijn. Vooral de diskreads nemen aardig wat bandbreedte in beslag. De record/replay-functionaliteit leunt op bepaalde instructies van de nieuwe processors van Intel en AMD. Voor gebruik van VMware FT is verder nog vcenter Server nodig. VMware FT draait alleen op de Advanced, Enterprise en Enterprise Plus Editions van vsphere 4. afzonderlijke Windows-server (niet getoond in figuur 3). Bij het configureren van VMware FT moeten we rekening houden met een aantal beperkingen ten aanzien van virtuele machines. Zo is het niet mogelijk snapshots te gebruiken in combinatie met VM s. Sterker nog, snapshots dienen te worden verwijderd of committed voordat we FT kunnen activeren op een VM. Ook is er geen ondersteuning voor Storage VMotion. Voor de migratie van storage moeten we VMware FT tijdelijk uitschakelen, waarna de VMotion-actie wordt uitgevoerd en VMware FT weer kan worden ingeschakeld. Verder wordt de functie Distributed Resource Scheduling (DRS) automatisch uitgeschakeld bij het configureren van een fouttolerante VM. Ook moeten we rekening houden met het feit dat FT alleen compatibel is met VM s die een enkele vcpu ondersteunen. Gelukkig helpt VMware ons een eindje op weg met een paar aanbevelingen. Zo zegt het bedrijf dat het onverstandig is om meer dan vier fouttolerante VM s (primaire of secundaire) op een enkele host te zetten. Ook is het goed om een maximum van zestien virtuele disks per fouttolerante VM aan te houden. Omdat fouttolerante VM s de volledige geheugenreservering in beslag nemen, dient de resourcepool meer geheugen te hebben dan de geheugengrootte van de VM s. Tot slot meldt VMware dat het met het oog op redundantie een goed idee is om minimaal drie hosts in een cluster te hebben. In failoversituaties kan er dan altijd een nieuwe secundaire VM worden gecreëerd. Configuratie VMware FT wordt toegepast binnen de context van een VMware HA-cluster. Haal het maximale uit uw ICT omgeving met de unieke Telindus-ISIT Audits. Registreer nu een Audit via (Advertentie) Voorafgaand aan de activatie van FT in een cluster moeten we drie stappen doorlopen: de optie Host Certificate Checking aanzetten, het netwerk configureren voor elke host en tot slot het HA-cluster aanmaken, de hosts toevoegen en de compliance checken. Op elke host die we willen toevoegen aan een HA-cluster, moeten we twee verschillende netwerkswitches configureren. Daarvoor hebben we twee VMkernel Gigabit-NIC s nodig: eentje voor FT-logging en eentje voor VMotion. Deze NIC s moeten zich op verschillende subnetten bevinden. Extra NIC s worden aanbevolen voor het netwerkverkeer dat gegenereerd wordt door VM s en beheertaken. Nadat het netwerkgedeelte is geconfigureerd, is er niets wat ons nog tegenhoudt het HA-cluster aan te maken en de hosts toe te voegen. Vervolgens kunnen we controleren of het cluster correct is geconfigureerd en alles voldoet aan de gestelde eisen. Daartoe beschikt de inventory van vcenter Server over een speciale Profile Compliance-tab, waar we de actie Check Compliance Now kunnen starten. In versie 4 van vcenter Server vindt deze controle automatisch plaats. Bij het upgraden van een oudere versie moet dit handmatig gebeuren. Als de compliancetest is voltooid (zie figuur 4), kunnen we het cluster activeren via de actie Turn On VMware HA. 51

5 52 Figuur 6: Actieve applicaties op een fouttolerante VM Figuur 7: Opstarten van de secundaire VM Pas als we alle stappen hebben doorlopen die nodig zijn om ons cluster voor te bereiden op de komst van VMware FT, kunnen we deze feature inschakelen voor afzonderlijke VM s. Dat doen we door in vsphere Client met de rechtermuisknop de gewenste VM aan te klikken en de optie Turn On Fault Tolerance te selecteren (zie figuur 5). Voordat alles ook echt gaat draaien, wordt de VM eerst nog onderworpen aan een aantal controles. Zo moet de optie SSL Certificate Checking zijn aangevinkt in de instellingen van vcenter Server, moet de host zich in een HA-cluster of een gemengd HA/DRS-cluster bevinden, mag de VM slechts één vcpu en geen snapshots hebben, mag de VM geen template zijn en mag VMware HA niet uitgeschakeld zijn op de VM. Nadat de VM deze controles met succes heeft doorlopen, wordt de secundaire VM aangemaakt en de complete status van de primaire VM gekopieerd. De plaatsing en de directe status van de secundaire VM hangen af van het feit of de primaire VM was in- of uitgeschakeld bij het starten van FT. Als alle checks zijn afgerond, worden de primaire en secundaire VM s opgestart en op aparte, compatibele hosts geplaatst. Op dat moment is onze virtuele machine daadwerkelijk beschermd. Testrondje Om de werking van VMware FT te testen, installeren we twee applicaties op een Windows 2003 x64-server die binnen een VM draait. De ene applicatie is een TPC- C-databasebenchmark, de andere een streaming video die wordt afgespeeld met Windows Media Player (zie figuur 6). Via Windows Remote Desktop op een standalone Windows-server loggen we in op de Windows Server 2003-VM en starten beide applicaties. Eerst proberen we via vsphere Client de primaire ESX-server uit te schakelen waarop bovengenoemde applicaties draaien (zie figuur 7). We constateren dat beide applicaties geen krimp geven en de VM automatisch wordt overgezet naar de andere ESX-server. Vervolgens booten we de uitgeschakelde server. Meteen komt vsphere met de mededeling dat de configuratie van VMware HA is mislukt. Na HA handmatig te hebben geactiveerd, herhalen we de test door de ESX-server in één klap zonder stroom te zetten. Ook nu draaien beide applicaties rustig door. Dit klinkt natuurlijk geruststellend, maar bedenk wel dat als zich een fatale fout voordoet in het besturingssysteem (zoals de bekende Blue Screen of Death), dit ook gevolgen heeft voor de secundaire VM. De HA-monitor zal dit detecteren om vervolgens te proberen de primaire VM en dan de secundaire VM te herstarten. Een ander belangrijk punt is dat FT natuurlijk niet beschermt tegen uitval van het storagesysteem ook niet als men de storageinfrastructuur voorziet van redundante datapaden. Daarom is het een goed idee om het storagesysteem zelf ook redundant te maken, bijvoorbeeld door middel van storagemirroring. In onze testconfiguratie hebben we dat gedaan door het inzetten van StarWind. Conclusie Natuurlijk hangt het van de specifieke bedrijfssituatie af of VMware FT de juiste keus is. FT zou in sommige gevallen de bestaande Microsoft Cluster Server (MSCS)-implementaties kunnen vervangen. In elk geval is het belangrijk te begrijpen wat FT níét doet: beschermen tegen applicatiefouten op een VM. FT beschermt een VM alléén tegen uitval van de onderliggende hosthardware. Willen we ons indekken tegen applicatiefouten, dan is MSCS waarschijnlijk een betere keus. En willen we bescherming tegen fouten in het besturingssysteem, dan zal de keus eerder op VMware HA vallen. We kunnen VMware FT en HA ook samen inzetten. Als zowel de primaire als de secundaire host op hetzelfde moment uitvallen, dan zal HA de virtuele machine op een andere werkende host opstarten om vervolgens een nieuwe secundaire VM in te schakelen. Of dat echt nodig is, hangt af van het belang dat we hechten aan de applicaties die we willen beschermen. p bram dons is onafhankelijk it-analist (info@it-trendwatch.nl)

6 Adv_Comparex83x252-08cl BOUWSTENEN hr.pdf :38:20 (Advertentie) vendors & resellers BedrijvenNIEUWS Iron Mountain neemt Mimosa Systems over Iron Mountain, aanbieder van information management services, heeft Mimosa Systems overgenomen voor ongeveer 112 miljoen dollar in contanten, onder voorbehoud van eventuele contractaanpassingen. Mimosa Systems, gevestigd in het Amerikaanse Santa Clara, is aanbieder van oplossingen voor contentarchivering. Mimosa NearPoint is een archiveringsplatform met applicaties voor het opslaan en ordenen, classificeren, herstellen en terugzoeken van gegevens, evenals voor e-discovery en compliancetoezicht. Deze archiveringsoplossing op locatie is volgens Iron Mountain een aanvulling op de bestaande cloudgebaseerde archieven. De mogelijkheid om gegevens te archiveren en te beheren, zowel binnen als buiten de firewall van de klant en op afstand in de cloud, maakt Iron Mountain volgens eigen zeggen een one-stopshop voor dataopslag, -archivering en -beheer. Door de overname is Iron Mountain in staat een breder pakket van bedrijfsinformatie op te slaan en te beheren vanaf zogenaamde perifere netwerkapparaten, zoals pc s en laptops, evenals uit bedrijfsbronnen, zoals de opslag van , SharePoint-servers en archiveringssystemen. Veel grotere bedrijven geven nog steeds de voorkeur aan het C intern opslaan van gegevens. Daarnaast biedt deze overname Iron M Mountain de mogelijkheid belangrijke bedrijfsinformatie uit de opgeslagen en beheerde bestanden te destilleren, zowel op Y locatie als in de cloud. Iron Mountain voegt NearPoint toe aan het brede CM portfolio van Iron Mountain Digital van contentarchiverings-, databeschermings-, dataherstel- en MY ediscovery-oplossingen. 53 CY Double-Take Software werkt samen met Amazon Double-Take Software en Amazon hebben samen een realtime workloadrecoveryplatform ontwikkeld: de Double-Take Cloud. Dit platform beschermt bedrijven tegen rampen en zorgt ervoor dat ze kunnen blijven functioneren zonder dat daar vooraf investeringen aan verbonden zijn. Double-Take Cloud maakt hierbij gebruik van Amazon s Elastic Compute Cloud (EC2). Traditionele oplossingen voor disaster recovery zijn vaak slechts toegankelijk voor bedrijven die de mogelijkheid hebben een tweede datacenter met stand-by back-up servers te bouwen en te beheren. Is dit niet het geval, dan is er slechts de mogelijkheid om gebruik te maken van een lokale tapeback-up. Deze manier van back-uppen heeft slechts gelimiteerde mogelijkheden en vraagt een grote tijdsinvestering. Met Double-Take Cloud kunnen klanten hun gegevens, applicaties en besturingssystemen herstellen en een workload gemakkelijk opnieuw opstarten vanaf Amazon s cloudplatform. Op hetzelfde moment wordt de originele fysieke workload hersteld op de oorspronkelijke locatie. Hierdoor hebben gebruikers toegang tot hun systemen en hoeven ze niet te wachten tot de fysieke workload hersteld is om weer aan de slag te gaan. Dankzij de oplossing beschikken bedrijven over een apart disasterrecoverydatacenter met cloudrecovery. In tegenstelling tot online back-upoplossingen die louter de gegevens beschermen, kunnen bedrijven met Double-Take Cloud ook hun applicaties en besturingssystemen heel gemakkelijk in de cloud herstellen. Dankzij de samenwerking met Amazon kunnen bedrijven gebruikmaken van de rekenkracht-, netwerk- en storagecapaciteiten wanneer dat nodig is. CMY K