NetOpus: November 2007 Thema: Hardware Special Rubriek: Serie Titel: High Availability en DRS Auteur: Bram Dons & Jan Reinders Pagina’s: 40 - 44
High Availability en DRS
Virtueel beheer met VMware deel 2
Na de installatie van onze proefopstelling is de eerste wens High Availability (HA) en daarnaast het beheer van de Distributed Resource Scheduler (DRS). Dit zijn ook zonder meer de belangrijkste innovaties van VMware 3.0.x. Met het eerder beschreven iscsi kun je snel resultaten bereiken, maar voor deze test heb je ook kennis nodig van Virtual Center om de clusters te kunnen beheren. Bram Dons & Jan Reinders
E
Schema 1. Virtual Center 2.0 architectuur. De Virtual Center Server (links) bevat meestal ook de benodigde licentieserver. Servergroepen (van ESX hosts) zijn clusters voor de VC beheeromgeving
en op Windows geïnstalleerde Virtual Center module (VC) maakt deel uit van de VMware Infrastructure, waarmee de virtuele omgeving wordt beheerd. Windows XP kan ook als basis gebruikt worden. Het is handig om de ‘licence server’ op hetzelfde systeem te installeren. Die is met de introductie van VMware versie 3.0.x geïntroduceerd en verplicht voor het gebruiken van DRS en VMotion. Het oude op een host gebaseerde licentiemodel is nog steeds bruikbaar, maar dan kunnen de HA/DRS opties niet worden gebruikt.
Infrastructuur IT-beheerders hebben via een Windows VI-client toegang tot alle opgenomen ESX Servers en Virtual Center. De remote toegang tot de gedistribueerde virtualisatieservices VMotion, DRS en HA worden via Virtual Center aangesproken. De VM-migratiefunctie VMotion maakt het mogelijk om virtuele machines realtime over te zetten van de ene naar de andere fysieke (host) ESX Server. Een VI client-module is op elk (Windows) systeem te installeren. Door met een browser naar een willekeurige VMwareESX-host te gaan, kan de software worden geïnstalleerd. De webinterface van de host is voornamelijk geschikt om de VI client-software op te halen van een host. Verder kun je er VM’s mee benaderen. In Schema 1 zijn drie groepen opgenomen met daarin 8 hosts. Voor onze proefopAfbeelding 1. Virtual Center bekeken via de Windows VI client software
stelling maken we van slechts twee sys temen gebruik in een groep (cluster1). Virtual Center is eigenlijk een set van Windows services met database op een Windows machine. Voor het opslaan van alle configuratiegegevens ondersteunt
Virtual Center Microsoft SQL Server 2000 (SP4 alleen), Oracle 9iR2, 10gR1 (versie 10.1.0.3 en hoger) en 10gR2, en Microsoft MSDE (niet voor productieomgevingen). De installatie van Virtual Center 2.0 kan op systemen met Windows 2000 SP4, Windows 2003 (voorlopig alleen 32-bit) of op Windows XP Professional. In Afbeelding 1 zien we een de belangrijkste componenten (REINcentre) met daaronder de clusters. De hosts waarvan er één in de cluster zit en één in maintenance mode buiten
High Availability en DRS • Serie
de cluster. Hosts hoeven niet in een cluster te zitten, maar dan verwerken ze slechts VM’s zonder DRS en HA. De cluster heeft in dit beperkte voorbeeld 3 Ghz tot zijn beschikking en 2 GB aan intern geheugen. Dit is natuurlijk ruim voldoende om de Windows Server 2003 actief te houden er zijn dan ook geen Migration recommendations in het rechter gedeelte te zien. Hoe meer hosts we toevoegen, hoe meer VM’s de cluster kan verwerken. Op de cluster is DRS actief, waarbij handmatig gekozen kan worden (via recommendations) of een VM verplaatst moet worden naar een andere host die het wat rustiger heeft in dezelfde cluster.
Hosts toevoegen Om DRS te kunnen gebruiken moeten er op de licentieserver per processor licenties beschikbaar zijn. Voor DRS zijn uiteraard minimaal twee hosts nodig in een cluster. DRS zorgt ervoor dat VM’s op een drukke host verhuizen naar een minder drukke host of geeft daarvoor eerst een advies. Zodra nieuwe ESX hosts worden geïnstalleerd in het netwerk dan kunnen deze met VI en VC worden toegevoegd aan de cluster. DRS is net als HA een clustereigenschap, en daarom zal de nieuwe host een licentie verbruiken na configuratie van de licentie feature op de nieuwe host. In het Configuratie-tabblad Licensed Features van de host kan gekozen worden om DRS aan te zetten. In het licentiescherm is het verbruik direct te zien, het aantal ‘in use’ neemt toe met het aantal processors op de host. Een dualcore processor is overigens gewoon één processor voor het licentiesysteem.
Kernel netwerk Naast het regelen van licenties moet op elke host ook nog een ‘kernel netwerk’ worden gemaakt. Dit is bij voorkeur een aparte virtuele en fysieke switch waarover het besturingssysteem van host1 praat met dat van host2 in een cluster. Ook communicatie met de iscsi-target verloopt over dat speciaal gereserveerde netwerk. Als een virtu-
Afbeelding 2. Om VMotion te kunnen gebruiken moeten de hosts over een eigen netwerk kunnen communiceren (VMkernel – Vswitch1). Ook een aparte 1000 Mbps adapter is nodig
ele machine met VMotion realtime wordt verplaatst, wordt het kernel netwerk gebruikt voor het overzettten van geheugenblokken zonder het normale netwerk te belasten. Bij de kernelpoort moet VMotion actief zijn om DRS te kunnen laten werken, en dat moet op een nieuwe host ook expliciet worden aangezet. (Afbeelding 2). Hierna moet iscsi-initiator worden geactiveerd bij Storage in het Configuratie-tabblad. Geef hiervoor het ip-adres op van de iscsi-target en ip-poort (meestal 3260). Alle hosts hebben zo toegang tot de shared storage. We hebben nu minimaal twee ESX-servers per cluster. Als een cluster met voldoende DRS-licenties overbelast raakt op één over meerdere hosts, dan doet DRS (bij een ‘handmatige’ geconfigureerde migratie) aanbevelingen over de migratie van VM’s. Ook onderhoud kan een reden zijn voor een verplaatsing. Door een host in met VI-client in maintenance mode te zetten (rechtsklik host) kunnen geen nieuwe VM’s worden gestart en kunnen de bestaande VM’s worden afgesloten. Als er licenties zijn voor High Availability, dan worden de VM’s op de host in maintenance mode opnieuw actief op een overblijvende host in de cluster, indien de i/o-configuratie van zo’n VM ook beschikbaar is op een doelhost in de cluster.
Afbeelding 3. Een clustereigenschap is het aanzetten van DRS met verschillende opties
VMotion en DRS maken het nu mogelijk om na de migratie wel of niet (gedeeltelijk) automatisch de aan de VM’s toegewezen bronnen aan te passen aan de nieuwe serveromgeving (Afbeelding 3). De ‘manual’ of ‘partially automated’ instelling biedt de beheerder een aantal aanbevelingen over de meest efficiënte verdeling van de belasting, met een keuze in prioriteit wat betreft server-, cpu- en geheugenbelasting. Redenen voor een nieuwe verdeling kunnen uiteenlopend zijn. Je kunt denken aan het balanceren van gemiddelde cpu- en geheugenbelastingen, maar ook aan het in overeenstemming brengen van de gedefinieerde ‘affinity rules’. Hiermee kun je bijvoorbeeld twee VMs op dezelfde server houden, of ze juist gescheiden houden voor HA. Deze regels zijn volkomen verschillend van de individuele server ‘CPU affinity’ regels, waarin voor elke VM de toewijzing van beschikbare processors wordt bepaald. Dit speelt een rol bij multi-
DRS: tips en toepassingen In principe is is het testen met onze proefopstelling niet lastig. Er zijn wel een aantal belangrijke stappen en tips te geven voor het testen en spelen met DRS. 1. De configuratie moet goed worden ondersteund met dns. Falen van dns-resolutie geeft lastige en onverwachte problemen. Statische resolutie met hosts-bestanden op de clusternodes kan een tijdelijke optie zijn. 2. Het netwerk moet beslist zijn uitgerust met 1000 Gbps interfaces. Vooral voor de kernel-2-kernel verbindingen en iscsi is dat erg belangrijk. Voor een productieomgeving nemen we altijd drie netwerkinterfaces voor de console, de vm’s en de kernel. Een aanrader zijn de Intel kaarten met twee of vier poorten op één kaart. Deze worden allemaal ondersteund door VMWare. 3. Met shared iscsi is het eenvoudig om een host te formatteren en opnieuw te beginnen. Nemen we een host definitief weg (volledige crash zonder dat HA aanstaat), dan staan
in VC incorrecte verwijzingen naar één of meerdere VM’s. Verwijder eerst de VM’s uit de VC database en dan pas de (defecte) host zelf. Met de rechter muisknop kan op de andere host kan via ‘opslag’ een browser op de files van de iSCSI target worden geopend. Met rechtsklik op de VMX config-file van de VM kan de omgeving nu op de overgebleven host worden geactiveerd. 4. Twee hosts in een cluster is wat krap. Voor het testen met DRS is drie eigenlijk beter. Zorg in ieder geval voor een gemiddelde belasting van 50% voor cpu en geheugen. Dit kan met de performance-grafieken duidelijk worden gemaakt over perioden die het gemiddelde van enkele weken kunnen laten zien. Als een host uitvalt kunnen alle VM’s migreren met HA naar de overblijvende hosts, die dan voor 100% worden belast. 5. VI heeft een uitgebreide voorziening met betrekking tot het maken van snapshots van een VM. Zorg dat bij het testen van HA en DRS de i/0 devices (floppy, cd) van de VM’s op elke host vergelijkbaar zijn en dat tussen de snapshots geen verschillende settings zijn met betrekking tot deze i/o-instellingen.
Willen we VMware HA combineren met de MSCS dan zijn er wel enige beperkingen. Zo ondersteunt VMware alleen MSCS met Fibre Channel en (nog) niet met iscsi. VMware geclusterde VM’s (Microsoft clusternodes) kunnen ook geen deel uitmaken van VMware clusters (DRS of HA) en VMotion is bovendien niet toepasbaar op VM’s waarop Microsoft clustersoftware draait. De traditionele clusteroplossingen garanderen weliswaar een snel herstel, maar zijn behoorlijk arbeidsintensief. VMware’s HA biedt echter het voordeel van een eenvoudige setup en bespaart op hardware omdat, in tegenstelling tot de traditionele clusteroplossing, er geen dubbele hardware en software meer nodig is. Alle aanwezige actieve VM’s op een uitvallende host worden onmiddellijk op een andere server(s) binnen de cluster herstart. Na de failover (het wordt drukker op een nog werkende host) geeft DRS natuurlijk ook weer aanbevelingen over de migratie van VM’s om de juiste balans binnen de cluster te herstellen. VMotion komt dus in actie na een calamiteit waarbij HA VM’s heeft verplaatst.
Zowel VMware HA als de traditionele clusteroplossingen (bijvoorbeeld Microsoft Cluster Services) ondersteunen automatisch een herstel bij uitval van een server. De twee oplossingen verschillen toch wezenlijk in hard- en software-eisen, hersteltijd en de mate van applicatieafhankelijkheid. Een vergelijking van VMware HA (voor een hele server) en traditionele clusters is voor een service of applicatie niet zo zinvol. Een traditionele clusteroplossing zoals Microsoft Cluster Service (MSCS) of Veritas Clustering Service heeft als doel om direct herstel te bieden met een minimale downtime voor applicaties bij uitval van een server. Bij Microsoft worden functies zoals dhcp of sharing fouttolerant. Bij VMware HA wordt een hele server opnieuw op een andere host gestart, waardoor veel minder hoeft te worden nagedacht over het concept.
Om te zien hoe de nieuwe functies DRS, HA en iscsi functioneren, gebruiken we de proefopstelling van de eerste aflevering op basis van ESX Servers met daaraan gekoppeld een iscsi storage array (EqualLogic PS3800). Op de servers (twee identieke Dell Xeon SC440’s) wordt ESX Server 3.0.2 geïnstalleerd. VMware geeft aan dat voor ESX Server een systeem nodig is met minimaal twee processors van de volgende types: 1,5 GHz Intel Xeon (of later) of AMD Opteron (32bit mode), 1,5 GHz Intel Viiv of AMD A64 x 2 dual-core processors, 1 GB RAM, een of meer nic’s, scsi, FC of iscsi lun of raid lun. VMware stelt verder als eis dat voor het iscsi-dataverkeer en management twee aparte 1 GbE netwerken nodig zijn. Wij hebben voor het kernel- en het iscsiverkeer een aparte interface genomen en een tweede interface voor het verkeer naar de VM’s en console.
Testomgeving DRS processersystemen, NUMA-systemen, Pentium IV en Xeon Hyperthreading. Als de cluster op ‘fully automatic’ staat ingesteld (voor DRS), dan plaatst Virtual Center automatisch de VM’s binnen de cluster op de meest geschikte server en migreert de draaiende VM’s naar een andere server. Probeer proefondervindelijk een juiste combinatie te vinden.
High Availability De nieuwe HA cluster-feature biedt de mogelijkheid om de op een bepaalde ESX Server draaiende VM’s automatisch te herstellen als die uitvallen. HA is beslist iets anders dan VMotion/DRS. Bij VMotion kan een werkende server dank zij het kernel netwerk zonder verstoring overgaan op een andere host. Bij HA is er wel degelijk verstoring voor de gebruikers van het virtuele systeem.
High Availability en DRS • Serie
Afbeelding 4. Alle hosts in de cluster hebben toegang nodig tot het shared device ‘opslag’, een lun
Met behulp van de standaard VMware iscsi software-initiator wordt een verbinding gemaakt met de iscsi storage array. Via de storage managers moeten eerst een aantal lun’s worden gecreëerd. Met de Equallogic array gaat dat eenvoudig met een webinterface. We controleren in het configuratietabblad of alle lun’s zichtbaar zijn (Afbeelding 4).
Installatie VM’s Na de installatie van de ESX-servers en Virtual Center controleren we met ping het adres en domeinnaam en of alle netwerkverbindingen functioneren. Voor een goede werking van VMotion, DRS en HA is het nodig om dns te installeren of bij kleine aantallen ESX-servers handmatig de hosts-bestanden op elke ESX-server te configureren. Dns is een belangrijke voor de resolutie tussen de verschillende interfaces, en fouten in dns geven veel zoekwerk en falende clusterfuncties. Voor onze test installeren we een flink aantal Windows machines. Voor het gemak klonen we enkele Windows servers. Klonen is een functie die door VC wordt ondersteund met een wizard. Kies hierbij voor klonen zonder customization. De kloon kan eenvoudig met newsid.exe (www.microsoft.com/technet/sysinternals/Utilities/NewSid.mspx) van een nieuwe computernaam en securityID worden voorzien. Na de configuratie van alle VM’s starten we alle Windows-systemen op, waarbij DRS en HA nog zijn uitgeschakeld. Die kunnen te allen tijde in bedrijf worden aan- en afgeschakeld via de clustereigenschappen. Hier kan DRS ook het advies geven om ‘seabree-
ze’ met VMotion (handmatig) te migreren naar een andere host om het geheugen meer te gelijkmatig te belasten. Verder is hier af te lezen hoeveel migraties automatisch uitgevoerd zijn, en de status van een aantal machines wordt in een kader uitvergroot weergegeven. Als eerste testen we een migratie van een draaiende VM. We kunnen zien of de handmatige migratie is gelukt bij ‘history’. Bij deze test is het mogelijk dat de Migratie VM Wizard aangeeft dat er sprake is van incompatibele cpu’s als de hosts op verschillende hardware zijn gebaseerd. In het Advanced Options menu van de host-configuratie kunnen bepaalde features van de cpu worden gemaskeerd om de cpu compatible te maken. Bij volstrekt indentieke servers als host is dat natuurlijk niet nodig (Afbeelding 5). Nu is het tijd om HA en DRS te activeren. Dit kan bijvoorbeeld ‘fully automated’, zodat de VM’s binnen de cluster netjes worden verdeeld voor wat betreft geheugen en processor. Meestal blijkt het
geheugen krapper dan de hoeveelheid cpu’s. Schakelen we tijdens de benchmark de DRS aan, dan zien we hoe de beschikbare capaciteit van de andere systemen wordt aangesproken en DRS de belasting gelijkmatig over de ESXservers wordt verdeeld. Het blijkt dat de geheugenbezetting bij de servers meestal in het bereik van 50 tot 80 % ligt en de cpu-belasting enkele tientallen procenten. Zeker de eerste keer is het prachtig om te zien hoe servers van host verhuizen om ruimte te maken op een te drukke host. Uiteraard valt er nog veel meer te tunen aan de eigenschappen van DRS bij volledige automatisering. We schakelen nu HA in om te zien welke gevolgen de uitschakeling van een server heeft op draaiende VM’s. Eerst verbreken we de beide netwerkverbindingen met de ESX Server en zien hoe de draaiende VM’s daarop worden overgeheveld naar de resterende ESXservers. Daarbij zorgt DRS er voor dat automatisch de VM’s van de uitgevallen ESX-servers over de andere servers wordt verdeeld en op een zodanige wijze dat de belasting weer evenredig wordt verdeeld. Na het weer herstellen van de netwerkverbindingen voegt de ESX-server zich weer keurig bij de cluster en kan de beheerder eventueel de VM’s weer handmatig terugzetten. Ook hier zien we dat de andere servers alle draaiende VM’s overnemen en de belasting ver-
Afbeelding 5. Meer dan tien actieve VM’s (voornamelijk servers) draaien op twee hosts
VM’s die niet actief zijn te migreren naar een overblijvende host en vervolgens de maintenance mode te kiezen. Alle VM’s die nog actief zijn verhuizen dan naar de andere omgeving.
Direct beschikbaar
Afbeelding 6. Cpu Identification Mask als de source en target cpu verschillen
deeld wordt. De HA fungeert daarbij als een echte ‘seamless’ failover-voorziening. Bij een uitvallende VMware host zullen echter wel alle VM’s crashen. Gebruikers hebben hier dus wel dege-
lijk last van. Zonder beheer komen de machines wel weer terug en DRS zal vervolgens de last weer balanceren over de overige hosts in de cluster. Een meer elegante manier om te testen is alle
- Continue beschikbaar, geen downtime ! - Voor bedrijfskritische applicaties - Complete hardware redundancy - Verzekert u van 99,999 % beschikbaarheid - Behoud van alle data ! - Ondersteunt elke Windows applicatie - Geen kostbare cluster-aware versies nodig - Standaard server hardware voldoende - Geen SAN noodzakelijk
Marathon everRun™ de wereld ná Clusters Voor een test of een demo bel: 0416-365141 of kijk op www.raxco.nl en overtuig u van de mogelijkheden van Marathon everRun™
Na installatie van minimaal twee hosts in een VI-cluster kan direct gewerkt worden met DRS en HA. De opties zijn met de VI GUI eenvoudig te configureren als gelet wordt op de punten die we in dit artikel hebben genoemd. DRS verstoord de werking van een individuele virtual server niet en de performance wordt direct verbeterd doordat de virtuele server op een host komt te draaien die minder is belast. De optie HA is er uitsluitend voor noodgevallen en geeft ook verstoring. Na een herstart van de virtuele server op een andere host komt het systeem ook in dit geval weer terug. «
