4.4 Virtualisatieoplossing voor datacentra met SLES 11 Xen

Integratie

10/4.4 Virtualisatieoplossing voor datacentra met SLES 11 Xen 10/4.4.1 Inleiding Als het gaat om de virtualisatie van serverbesturingssystemen, kiest meer dan 90 procent van de markt voor VMware. Hiervoor zijn verschillende redenen aan te wijzen, waarvan de angst dat andere oplossingen niet goed beheerd kunnen worden misschien wel een van de belangrijkste is. U maakt hier kennis met een alternatief, namelijk virtualisatie op basis van SuSE Linux Enterprise Server 11. Laten we met de deur in huis vallen: de virtualisatieoplossing op basis van SLES 11 is niet zo eenvoudig en toegankelijk als de oplossing die u met VMware kunt bouwen. Als u zoekt naar een oplossing waarmee iedereen op de ICTafdeling eenvoudig even een server kan migreren, bent u met de combinatie SuSE-Xen aan het verkeerde adres. Zoekt u echter een oplossing die haar werk gewoon doet en zelden down zal gaan als deze eenmaal geïnstalleerd is, dan is de combinatie SuSE-Xen de juiste keuze. U moet echter wel de nodige kennis in huis hebben om een dergelijke oplossing zelf te bouwen en als u zelf niet over deze kennis beschikt, zult u die moeten inhuren. Betekent dit dat SuSE-Xen bij voorbaat afvalt? Geenszins! Ook een oplossing op basis van VMware heeft een specialist nodig om goed geïnstalleerd te worden en ook bij VMware-oplossingen komt het veel te vaak voor dat de welwillende systeembeheerder er zelf een potje van heeft gemaakt. In alle gevallen geldt dus dat u voordat u een virtualisatieproject begint, ervoor moet zorgen goed beslagen ten ijs te komen.

Novell Netwerkoplossingen, aanvulling 33

10/4.4-1

Virtualisatie

Waarom Xen? Voordat u begint met een Xen-virtualisatieproject, moet u op zijn minst voor uzelf een antwoord hebben op de vraag waarom u dit met Xen zou willen doen. Xen heeft namelijk de reputatie marginaal te zijn en daarom niet zo betrouwbaar als VMware. Het is waar dat Xen een veel kleiner marktaandeel heeft, maar u zou Xen tekortdoen door het te beschouwen als een open-source project van een paar welwillende zolderkamerprogrammeurs. Laten we het eerst eens hebben over de bedrijven die achter Xen staan. Xen is ontwikkeld aan de Universiteit van Cambridge in het Verenigd Koninkrijk. De wetenschappers die de Xen-hypervisor ontwikkelden, hebben deze vervolgens ondergebracht in hun XenServer, die ze met hun eigen bedrijf XenSource gingen verkopen. Op dat moment al waren in het Xenproject medewerkers betrokken van verschillende grote namen uit de ICT-markt. Denk aan chipontwikkelaars AMD en Intel, maar ook aan softwaremakers op de Linux-markt, zoals Red Hat en Novell. Daarnaast is ook Microsoft er op de achtergrond bij betrokken geweest en is de huidige HyperV-oplossing voor een groot deel gebaseerd op Xen. Xen kan zich dus wel degelijk verheugen op voldoende ondersteuning vanuit de markt. Ook de overname van XenSource door Citrix heeft het project geen windeieren gelegd. Sinds de ontwikkeling van Xen is er echter het nodige gebeurd op de markt van virtualisatiesoftware. Zoals gezegd is XenSource overgenomen door Citrix. Betekent dat nu dat Xen van Citrix is? Geenszins! Xen is nog steeds een opensource project waarbij verschillende belangrijke spelers op de ICT-markt betrokken zijn. Toegegeven, Citrix is een prominente speler met zijn XenServer, maar niet de enige. Ook verschillende Linux-leveranciers, waaronder de twee be10/4.4-2


Integratie

langrijkste op enterpriseniveau (Novell en Red Hat), bieden een volledig ondersteunde Xen-stack. En juist het gegeven dat Xen open source is biedt veel voordelen, waaronder het feit dat iedereen kan profiteren van de vorderingen die op het gebied van Xen door een bepaalde partij gemaakt worden. Als Citrix dus een belangrijke wijziging aanbrengt in de Xen-hypervisor, komt deze in het opensource project terecht en kan iedereen ervan profiteren. Er zijn echter ook verschillen tussen de Citrix XenServeroplossing en de Novell Xen-oplossing, die we in deze paragraaf bespreken. Deze verschillen hebben vooral betrekking op het beheer. Met Citrix XenServer wordt XenCenter geleverd, een eenvoudig toegankelijke beheerinterface waarmee het beheer van virtuele machines gemakkelijker wordt gemaakt. Voor die beheerinterface moet echter ook apart worden betaald, terwijl de open-source tool virt-manager die bij Novell geleverd wordt, inbegrepen is in SuSE Linux Enterprise Server. Hieruit volgt dat wie wil profiteren van de voordelen van Xen maar daarnaast ook een eenvoudige beheeroplossing wil, er goed aan doet gebruik te maken van Citrix Xen. Schrikt u echter niet terug voor beheer vanaf de commandline en met behulp van een iets minder uitgebreide beheertool, dan kunt u met Novell Xen een degelijke oplossing bouwen en tegelijkertijd een hoop geld besparen. Naast Xen is er nog een andere speler in de virtualisatiemarkt op Linux en dat is KVM, de Kernel Virtual Machine. Het grote onderscheid tussen KVM en Xen is dat KVM geïntegreerd is in de Linux-kernel zelf. Om met KVM te kunnen virtualiseren hebt u welgeteld een kernelmodule nodig. Om met Xen te virtualiseren moet u de Xen-hypervisor laden, die er op zijn beurt verantwoordelijk voor wordt dat de Novell Netwerkoplossingen, aanvulling 33

10/4.4-3

Virtualisatie

Linux-kernel geladen wordt. Kort samengevat: Xen is veel ingewikkelder dan KVM. KVM is momenteel echter wat ontwikkeling betreft nog niet zo ver als Xen en daarom is het niet aan te raden uw virtualisatieoplossing te bouwen op basis van KVM. Zelfs Red Hat, het bedrijf dat momenteel eigenaar is van de KVM-technologie, maakt gebruikt als standaard nog steeds Xen-virtualisatie.

Paravirtualisatie

Dan hebben we het nog niet gehad over wat nu eigenlijk de voordelen zijn van Xen. Deze betreffen met name de manier waarop Xen virtualisatie aanpakt. De makers van Xen hebben namelijk voor virtualisatie een revolutionaire nieuwe techniek geïntroduceerd die bekendstaat als paravirtualisatie. Bij paravirtualisatie wordt gebruikgemaakt van een software-interface voor virtuele machines. Deze interface is vergelijkbaar met de onderliggende hardware; door gebruik te maken van deze software-interface wordt het voor virtuele machines een stuk eenvoudiger te communiceren met de onderliggende hardware. Zonder paravirtualisatie moeten nogal wat vertalingen worden gedaan op de instructies die door virtuele machines worden uitgevoerd, met paravirtualisatie is dat niet nodig en kan een virtuele machine zonder noemenswaardig performanceverlies haar werk doen. Paravirtualisatie maakt virtuele machines dus veel sneller. Tot op heden is Xen de enige speler op de virtualisatiemarkt die paravirtualisatie succesvol en volledig doorgevoerd heeft. Voordat u nu echter te enthousiast wordt, is het wel tijd voor een kleine nuance. Om volledig van paravirtualisatie te kunnen profiteren is een aangepaste kernel nodig voor het besturingssysteem dat u wilt gaan virtualiseren. Dit betekent dat paravirtualisatie niet zonder meer voor elk besturingssysteem werkt. Linux en Novell NetWare bieden standaard ondersteuning voor paravirtualisatie, Windows

10/4.4-4


Integratie

doet dat niet en dat betekent dat Windows minder kan profiteren van de voordelen van paravirtualisatie. Dit betekent overigens niet dat het zinloos is om Windows in Xen te virtualiseren, want u hebt nog steeds het voordeel van het veel aantrekkelijker kostenplaatje. Windows doet echter niet aan paravirtualisatie en daarom zal het besturingssysteem niet zo snel reageren as een gevirtualiseerde Linux- of NetWare-machine. Om dit leed enigszins te verzachten biedt Novell overigens wel het Virtualization Driver Pack, een set drivers die u in de Windows virtuele machine installeert om ervoor te zorgen dat in elk geval de I/O-devices gebruik kunnen maken van paravirtualisatie. Benodigde hardware U weet nu wat de voordelen zijn van een virtualisatieoplossing die gebaseerd is op Xen. Laten we het nu eens hebben over de hardware die u nodig hebt om een dergelijke oplossing te bouwen. Om te beginnen hebt u een SAN nodig. De enige mogelijkheid om ervoor te zorgen dat de virtuele harde schijven die door de virtuele machines gebruikt worden altijd beschikbaar zijn, is ervoor te zorgen dat deze schijven op het SAN staan. We gaan ervan uit dat u al een SAN-oplossing hebt. Is dit niet het geval, lees dan hoofdstuk 6/4 over het aanmaken van uw eigen opensource SAN op basis van iSCSI. Voor de verdere werking van de Xen HA-oplossing maakt het overigens niet uit wat voor soort SAN u gebruikt, zowel iSCSI als Fibre Channel kan worden gebruikt. Het neerzetten van een SAN alleen is niet genoeg. U moet er vervolgens voor zorgen dat het SAN op de juiste wijze aan uw virtualisatiehosts verbonden wordt. Een enkelvoudige verbinding is hiervoor niet genoeg, u wilt waarschijnlijk wel dat de oplossing gewoon doordraait als er een kabel uitvalt. Om die reden moet alles redundant worden Novell Netwerkoplossingen, aanvulling 33

10/4.4-5

Virtualisatie

uitgevoerd. Concreet betekent dit dat u de volgende zaken redundant moet uitvoeren: • diskcontrollers in het SAN; • netwerkkaarten in het SAN; • switches om met het SAN te verbinden; • netwerkkaarten of HBA’s die u gebruikt om met het SAN te verbinden. Naast het SAN en de bijbehorende infrastructuur hebt u uiteraard ook een paar hostmachines nodig om de virtuele machines op te draaien. Omdat u een HA-omgeving wilt maken, moeten dit minimaal twee machines zijn, maar het is aan te raden uit te gaan van drie machines. Met twee machines loopt u namelijk het risico dat de overblijvende machine overbelast wordt als er een host down gaat en dit risico maakt u kleiner als u drie hosts inzet. De derde host functioneert dan in feite in zijn geheel als back-up host zodat ook bij het falen van een host alles nog gewoon kan doordraaien. Bij de inrichting van de hosts is het belangrijk dat u voorziet in voldoende werkgeheugen. Het is niet echt moeilijk uit te rekenen hoeveel werkgeheugen u nodig hebt: u telt gewoon de totale geheugenbehoefte van alle afzonderlijke virtuele machines bij elkaar op, rondt dat af naar boven en dan hebt u in principe genoeg. Als u vier Windows-servers wilt draaien die elk 4 GB nodig hebben, drie OES-servers met 2 GB per stuk en acht Linux-servers met elk 2 GB per stuk, dan komt u dus op een totaal van 34 GB. Aangezien u deze werklast zult verspreiden over drie verschillende hosts, is het een goed idee om elke host met in elk geval 24 GB werkgeheugen uit te rusten. Wellicht is het aan te raden om hier gelijk maar 32 GB per server van te maken.

10/4.4-6


Integratie

NIC-bonding

Nadat u hebt nagedacht over de geheugenbehoefte, is het ook de moeite waard te denken over de netwerkkaarten die u in de servers zet om met de eindgebruikers te interfacen. Het is verstandig deze netwerkkaarten dubbel uit te voeren, zodat u ook aan deze kant iets kunt doen aan redundantie. Met andere woorden, u gaat in Linux een bonding interface aanmaken. Voor NIC-bonding zijn er normaliter twee technieken die u kunt toepassen. U kunt in theorie de netwerkkaarten bundelen zodat ze samen een grote trunk vormen met verdubbelde of wellicht zelfs verviervoudigde bandbreedte. Dit werkt (momenteel) echter niet goed samen met de Xen-bridge die u moet aanmaken in de virtuele machines en heeft dus geen zin. Doe daarom geen moeite en beperk u tot twee netwerkkaarten per bond. Niets weerhoudt u er overigens van om meerdere bonds aan te maken zodat u bonds kunt toewijzen aan afzonderlijke virtuele machines. Zo kunt u ervoor zorgen dat uw zwaar bezochte webserver een eigen interface heeft, terwijl de andere virtuele servers de andere bonding interface met elkaar moeten delen. Tot slot is het ook belangrijk na te denken over CPU-power. In de ideale situatie hebt u voor elke virtuele machine een CPU-core te beschikking. Dit betekent dat u in de meeste gevallen prima uit de voeten kunt met een systeem met twee quad-core CPU’s. De overige hardware die u in uw server aanbrengt is minder van belang. Zorg ervoor dat u een redelijke lokale storage beschikbaar hebt, dan hebt u daar ruimte om in noodgevallen even een image of een ISO-bestand op te plaatsen. De bulk van de opslag zal echter op het SAN plaatsvinden.


10/4.4-7

Virtualisatie

10/4.4.2 Inrichting van het cluster Op dit punt gaan we ervan uit dat u alle hardware op zijn plaats heeft en klaar bent om de softwarematige instellingen te doen. Hiervoor moeten de volgende stappen doorlopen worden: 1. Installatie van de hostservers en aanmaken van de LUN’s. 2. Koppelen van de hostservers aan het SAN, inclusief configuratie van multipath. 3. Configuratie van de LAN-netwerkkaarten van de hostservers, inclusief NIC-bonding en bridge. 4. Inrichting van het cluster. 5. Aanmaken van Xen virtuele machines. 6. Aanmaken van clusterresources. 1.

Installatie van hostservers en aanmaken van LUN’s U begrijpt dat er software op de hostmachines geïnstalleerd moet worden. Voor dit doel gebruikt u SuSE Linux Enterprise Server (SLES) 11. Tijdens de installatie kunt u aangeven hoe u SLES wilt installeren; u hebt de keuze tussen een volledige machine, een paravirtuele machine of een installatie als Xen-host. Vanwege het gemak van een lokale GUI, gaan wij ervan uit dat u een volledige installatie van SLES uitvoert. Zorg ervoor dat de Xen-packages geselecteerd zijn, alle overige componenten kunt u later toevoegen. Omdat de installatie van SLES niet echt moeilijk is, zullen we deze hier niet verder bespreken. Een andere taak die u in de voorbereiding moet uitvoeren, is de inrichting van de LUN’s. Deze taak voert u uit op uw SAN. Omdat elke SAN-oplossing met betrekking tot LUN’s anders te werk gaat, kunnen wij er hier niet verder op ingaan. U moet er in elk geval voor zorgen dat er een LUN bestaat dat als storage back-end functioneert voor elke 10/4.4-8


Integratie

virtuele machine die u wilt gaan installeren. Dit betekent dat het LUN zo groot moet zijn als de volledige hoeveelheid opslag die u aan de virtuele machine beschikbaar wilt stellen. Het is overigens geenszins verplicht om alle opslag nu al aan te maken en toe te wijzen, u kunt dat uiteraard ook doen op het moment dat u de opslag echt nodig hebt. 2.

Koppelen van hostservers aan SAN, inclusief configuratie van multipath Als het hostbesturingssysteem overal geïnstalleerd is, kunt u de servers aan het SAN verbinden. We gaan uit van twee netwerkkaarten die door middel van iSCSI naar het SAN toe gaan. Hoewel de daadwerkelijke configuratie in specifieke omstandigheden anders zal zijn, geeft de hier besproken procedure wel een indruk wat er moet gebeuren. Deze procedure moet uitgevoerd worden als u met gewone netwerkkaarten of speciale HBA’s naar het iSCSI SAN toe gaat. Als u met Fibre Channel HBA’s in uw server contact maakt met het SAN, is er namelijk helemaal geen netwerkconfiguratie nodig. Een iSCSI-verbinding opzetten Als u gebruikmaakt van iSCSI, kunt u vanuit SuSE de iSCSIverbinding opzetten. De volgende procedure beschrijft hoe u hiervoor te werk gaat, nadat u de netwerkkaarten van de IP-adressen hebt voorzien die nodig zijn om met het SAN te communiceren. 1. Selecteer in YaST de optie Network Services gevolgd door iSCSI Initiator. Waarschijnlijk meldt YaST nu dat iSCSI nog niet geïnstalleerd is en vraagt of u dat op dit moment wilt doen. Het spreekt voor zich dat u op deze vraag een positief antwoord geeft. 2. U ziet nu het iSCSI-configuratiescherm. Geef hierin om te beginnen aan dat iSCSI automatisch gestart moet


10/4.4-9

Virtualisatie

Figuur 10/4.4-1 Specificeer om te beginnen dat de iSCSI-service automatisch moet starten op alle nodes.

Figuur 10/4.4-2 Voer nu elk IP-adres in waarop het SAN benaderd kan worden.

10/4.4-10


Integratie

worden tijdens het opstarten van de server (zie figuur 10/4.4-1). 3. Ga nu naar het tabblad Discovered Targets en klik daar op de knop Discovery. Voer hier vervolgens het eerste IP-adres in waarop het SAN benaderd wordt. Als uw SAN op twee verschillende IP-adressen benaderd wordt, voert u vervolgens ook het tweede IP-adres in door deze procedure nogmaals uit te voeren (zie figuur 10/4.4-2). 4. Activeer nu het tabblad Connected Targets. Op dit tabblad ziet u de huidige iSCSI-connecties staan, met daarbij een status On Boot. Dit betekent dat de driver tijdens het opstarten geladen wordt, maar verder zal er niets gebeuren. Om ervoor te zorgen dat de iSCSI-sessie ook automatisch wordt opgebouwd, selecteert u elke connectie en klikt u vervolgens op Toggle Startup, totdat de startupstatus op Automatic staat. Hiermee zorgt u dat de iSCSI-sessie tijdens opstarten ook daadwerkelijk tot stand gebracht wordt, zodat u een aantal additionele diskdevices zult zien nadat u de computer hebt aangezet. In listing 10/4.4-1 ziet u hoe deze diskdevices met het commando lsscsi zichtbaar gemaakt kunnen worden en vervolgens als type VIRTUAL-DISK verschijnen. node2:/ # lsscsi [0:0:0:0]

disk

VMware, VMware Virtual S 1.0

/dev/sda

[2:0:0:0]

cd/dvd

NECVMWar VMware IDE CDR10 1.00 /dev/sr0

[3:0:0:0]

disk

IET

VIRTUAL-DISK

0

/dev/sdb

[3:0:0:1]

disk

IET

VIRTUAL-DISK

0

/dev/sdc

[4:0:0:0]

disk

IET

VIRTUAL-DISK

0

/dev/sdd

[4:0:0:1]

disk

IET

VIRTUAL-DISK

0

/dev/sde

Listing 10/4.4-1 Met lsscsi ziet u de diskdevices die door iSCSI worden aangeboden.


10/4.4-11

Virtualisatie

Nadat u de netwerkkaarten geconfigureerd hebt om contact op te nemen met het SAN en indien nodig ook de adressen op die kaarten hebt ingesteld, zult u merken dat u de LUN’s die het SAN aanbiedt twee keer ziet. Als op uw SAN contact gemaakt wordt met twee verschillende controllers, zal dit zelfs vier keer zijn. Concreet betekent dit in de meeste gevallen dat voor elke keer dat uw server het LUN op het SAN ziet, een sdx-device wordt toegevoegd. Bij twee LUN’s ziet u momenteel dus waarschijnlijk een sdb, sdc, sdd en sde. Deze devices kunt u echter niet gebruiken omdat ze niet specifiek genoeg zijn: als een van de verbindingen naar het SAN uitvalt, zal ook het bijbehorende device verdwijnen. Wat u nodig hebt is een device dat niet afhankelijk is van een specifiek pad naar het LUN toe, maar dat meer algemeen is en ook blijft werken als er toevallig een keer een pad down gaat. Deze oplossing wordt aangeboden door multipath. Multipath

10/4.4-12

Voordat u aan het werk gaat met multipath, is het eerst zaak te bepalen welke soort multipath u wilt gebruiken. Er is namelijk Linux-multipath en daarnaast heeft de vendor van uw server of SAN waarschijnlijk ook een multipath. U zult dus moeten bepalen welke multipath-oplossing u wilt gebruiken. Wij hebben een voorkeur voor Linux-multipath. De multipath-driver die momenteel beschikbaar is, is stabiel en biedt alle mogelijkheden die nodig zijn. Daarnaast – en dat is de belangrijkste overweging – zit de Linux-multipath-driver in de distributie zelf. Dit betekent dat de driver automatisch bijgewerkt wordt als uw server gepatcht wordt. Bij gebruik van de multipath-driver van de vendor loopt u het risico dat u na elke kernelupgrade de multipath-driver opnieuw moet compileren. Dat kan niet de bedoeling zijn.


Integratie

Om de multipath-driver op SuSE Linux aan te zetten voert u de volgende opdrachten uit: 1. Waarschijnlijk is de multipath-driver al geïnstalleerd, maar toch moet u hier zeker van zijn. Gebruik daarom de opdracht zypper search multipath. In listing 10/4.4-2 ziet u het resultaat van deze opdracht. Het gaat in deze listing om de eerste regel van het resultaat, de i aan het begin van de regel geeft aan dat het multipathpackage geïnstalleerd is. Is multipath op uw server nog niet geïnstalleerd, gebruik dan zypper search multipath om het alsnog te installeren. 2. Nadat u gecontroleerd hebt dat multipath geïnstalleerd is, moet u ervoor zorgen dat het ook automatisch gestart wordt vanuit de run-levels. Geef hiervoor de opdrachten insserv boot.multipath en insserv multipathd. Deze twee commando’s bewerkstelligen dat multipath automatisch geactiveerd wordt als de computer weer opstart. Om de driver nu handmatig te starten kunt u de opdracht /etc/init.d/multipath start gebruiken. 3. Op dit moment is uw multipath als het goed is operationeel. Dit controleert u met de opdracht multipath -l. U ziet de uitvoer van dit commando in listing 10/4.4-3. De configuratie in deze listing geeft aan dat de verbindingen succesvol zijn opgezet. Op de eerste regel ziet u de namen van de devices die gemaakt zijn, het gaat hier om de lange hexadecimale getallen. Deze getallen vindt u ook terug in de directory /dev/disk/by-id, waar een unieke representatie voor elk diskdevice aangemaakt wordt. U kunt deze verwijzingen gebruiken om naar het LUN op het SAN te verwijzen, ongeacht de status van de individuele paden zullen deze verwijzingen het namelijk altijd gewoon doen.


10/4.4-13

Virtualisatie

Listing 10/4.4-2 Gebruik zypper search multipath om te achterhalen of de multipath-driver al is geïnstalleerd.

node2:/ # multipath -l 149455400000000000000000001000000950500000f000000 dm-1 IET,VIRTUAL-DISK [size=10.0G][features=0][hwhandler=0][rw] \_ round-robin 0 [prio=-1][active] \_ 3:0:0:1 sdc 8:32 [active][undef] \_ round-robin 0 [prio=-1][enabled] \_ 4:0:0:1 sde 8:64 [active][undef] 1494554000000000000000000010000008e0500000f000000 dm-0 IET,VIRTUAL-DISK [size=10G][features=0][hwhandler=0][rw] \_ round-robin 0 [prio=-1][enabled] \_ 3:0:0:0 sdb 8:16 [active][undef] \_ round-robin 0 [prio=-1][enabled] \_ 4:0:0:0 sdd 8:48 [active][undef] Listing 10/4.4-3 De opdracht multipath -l laat zien of het opzetten van multipath-connecties geslaagd is.

Soms kan het voorkomen dat de standaard-multipath-configuratie het niet goed doet. Er is dan additionele configuratie nodig. Dit regelt u via het configuratiebestand /etc/ multipathd.conf (zie listing 10/4.4-4).

10/4.4-14


Integratie

devices { device { vendor

“DELL”

product

“MD3000i”

path_grouping_policy “group_by_prio” getuid_callout

“/lib/udev/scsi_id -g -u -d /dev/%n”

prio_callout

“/sbin/mpath_prio_rdac /dev/%n

hardware_handler

“1 rdac”

path_checker

rdac

prio

rdac

path_selector

“round-robin 0”

failback

immediate

rr_weight

priorities

no_path_retry

queue

rr_min_io

100

product_blacklist

LUN_Z

} } Listing 10/4.4-4 Voor meer specifieke instellingen maakt u gebruik van /etc/multipathd.conf.

De instellingen die u gebruikt in het configuratiebestand, zijn afhankelijk van de manier waarop uw SAN communiceert. Mocht het niet goed gaan met de standaardinstellingen, dan doet u er goed aan te zoeken naar een voorbeeldconfiguratie voor uw specifieke device. Mocht u er op basis daarvan ook niet uitkomen, dan is het een goed idee de main pagina van multipath.conf te raadplegen voor meer specifieke informatie. Kijk vooral naar de mogelijkheden van de path_checker variabele; deze geeft namelijk aan welke kernelmodule gebruikt moet worden voor een specifiek SAN en hier geldt dat niet elke module werkt voor elk SAN. Novell Netwerkoplossingen, aanvulling 33

10/4.4-15

Virtualisatie

3. Configuratie van LAN-netwerkkaarten Tot nu toe hebben we gekeken naar de SAN-kant van de configuratie. Tijd om te kijken naar de LAN-configuratie. Voor een Xen-configuratie hebt u hier te maken met de complicerende factor dat u een bridge zult moeten configureren. Deze bridge functioneert als een soort virtuele switch waarmee elke virtuele machine contact zal maken, inclusief het hostbesturingssysteem. Daarnaast is het vanuit de optiek van fouttolerantie raadzaam om netwerkkaarten samen te brengen in een trunk, waarmee u feitelijk meerdere netwerkkaarten bundelt tot een device. Het grote voordeel dat u hiermee bereikt is redundantie: in een trunk kan er een device uitvallen en het andere netwerkdevice neemt het dan gewoon over. Trunkingprotocollen staan ook toe om meerdere devices samen te brengen zodat er een snelle verbinding gemaakt wordt (2-gigabit netwerkkaarten maken zo bijvoorbeeld een 2-gigabit interface). Deze configuratie verloopt onder Linux echter niet probleemloos en daarom raden we aan deze niet te gebruiken.

YaST

Waar u dus naartoe moet werken, is een configuratie waar de netwerkkaarten ondergebracht worden in een bonding device (de trunk). Vervolgens moet dit bonding device gekoppeld worden aan de virtuele bridge. Om deze configuratie te maken kunt u voor een groot deel gebruikmaken van YaST, maar u zult ook handmatig in de configuratiebestanden wat aanpassingen moeten doen om de puntjes op de i te zetten. Als eerste moet u de configuratie van de netwerkkaarten regelen die u aan de LAN-kant wilt configureren. Dit is vrij eenvoudig: in SLES 11 is er een optie om een netwerkkaart

10/4.4-16


Integratie

te configureren als bonding device. Voer de volgende stappen uit om uw netwerkkaart op deze wijze in te stellen: 1. Start YaST, selecteer Network Devices en vervolgens Network Settings. Kies dan de eerste netwerkkaart die u wilt gebruiken en klik op Edit om de instellingen hiervan aan te passen. U ziet nu het venster uit figuur 10/4.4-3. 2. Kies nu de optie No IP Address (for Bonding Devices) en klik op Next om de configuratie op te slaan. U ziet nu in het hoofdvenster dat de netwerkkaart als configuratie de aanduiding NONE heeft. 3. Herhaal deze procedure voor alle netwerkkaarten die u in de bond wilt opnemen.

Figuur 10/4.4-3 Vanuit YaST kunt u eenvoudig een netwerkkaart instellen om in een bond gebruikt te worden.


10/4.4-17

Virtualisatie

Ter controle kunt u de configuratiebestanden die bij uw netwerkkaarten horen nakijken. U vindt deze bestanden in /etc/sysconfig/network en herkent ze aan de namen /etc/ sysconfig/network/ifcfg-ethX. In listing 10/4.4-5 ziet u hoe een dergelijk bestand eruit hoort te zien nadat het geconfigureerd is voor gebruik in een bonding device. BOOTPROTO=’none’ BROADCAST=’’ ETHTOOL_OPTIONS=’’ IPADDR=’’ MTU=’’ NAME=’82575GB Gigabit Network Connection’ NETMASK=’’ NETWORK=’’ REMOTE_IPADDR=’’ STARTMODE=’off’ USERCONTROL=’no’ Listing 10/4.4-5 Voorbeeldconfiguratie eth-interface.

Bonding device aanmaken Nadat de netwerkkaarten geconfigureerd zijn, maakt u – nog steeds vanuit de Overview-interface onder Network Settings – het bonding device aan. Dit proces behelst een paar stappen. Om te beginnen maakt u het device zelf aan. Vervolgens geeft u aan welke netwerkkaarten onderdeel mogen zijn van het device. Als laatste stap configureert u het protocol dat het bonding device moet gebruiken. Hieronder worden de te volgen stappen uitgelegd. 1. Start Yast en selecteer Network Devices, Network Settings, Overview. Klik nu op Add om een nieuwe interface aan te maken. 2. Kies in de vervolgkeuzelijst Device Type het type Bond en houd als Configuration Name de standaardsuggestie 10/4.4-18


Integratie

0 aan (zie figuur 10/4.4-4). Dit zorgt ervoor dat het device aangemaakt wordt als bond0; u zult het als dusdanig ook te zien krijgen met tools als ifconfig.

Figuur 10/4.4-4 Selecteer in de vervolgkeuzelijst Device Type het type Bond om een bonding device aan te maken.

3. Nu volgt de daadwerkelijke configuratie van het device. Als eerste wijst u netwerkkaarten toe die door het bonding device gebruikt mogen worden. U zult alleen kunnen kiezen uit de netwerkkaarten die nog niet voorzien zijn van hun eigen IP-configuratie. Vervolgens geeft u aan welk bondingprotocol gebruikt mag worden (zie figuur 10/4.4-5). Zeker voor een eerste test is het raadzaam de standaardkeuze te laten staan. Als later bewezen is dat deze goed werkt, kunt u altijd nog kijken of de andere opties in uw omgeving ook werken. Even opletten: YaST begrijpt het niet als u geen IP-adres aan het bonding device toewijst, dus vul hier maar tijdelijk


10/4.4-19

Virtualisatie

Figuur 10/4.4-5 Zorg er nu voor dat de te gebruiken netwerkkaarten in het bonding device geselecteerd zijn en dat het bondingprotocol geselecteerd is.

een IP-adres in (wat u vervolgens in de volgende stap weer gaat verwijderen). 4. Sluit nu de YaST-procedure af om ervoor te zorgen dat de configuratie opgeslagen wordt. Dit heeft als resultaat dat het bijbehorende configuratiebestand wordt aangemaakt. U vindt het terug onder de naam /etc/ sysconfig/network/bond0 en de inhoud ziet er ongeveer uit als in listing 10/4.4-6. 5. In het configuratiebestand dat voor uw bonding device is aangemaakt, staan nu nog een IP-adres en een netmask. Verwijder deze en geef dan de opdracht ifdown bond0, gevolgd door ifup bond0. De configuratie is nu dusdanig dat u verder kunt met de configuratie van de netwerkbridge.

10/4.4-20


Integratie

BONDING_MASTER=’yes’ BONDING_MODULE_OPTS=’mode=active-backup’ BONDING_SLAVE0=’eth0’ BONDING_SLAVE1=’eth1’ BOOTPROTO=’none’ BROADCAST=’’ ETHTOOL_OPTIONS=’’ IPADDR=’’ MTU=’’ NAME=’’ NETMASK=’’ NETWORK=’’ REMOTE_IPADDR=’’ STARTMODE=’auto’ USERCONTROL=’no’ Listing 10/.4.4-6 Voorbeeldconfiguratie bond0-interface.

Netwerkbridge aanmaken Nu wordt het tijd voor de laatste stap: u moet de netwerkbridge configureren. Ook hiervoor start u om te beginnen YaST op. Vervolgens selecteert u in YaST de optie Network Settings, Overview en klikt u op Add. Deze keer kiest u als Device Type Bridge, als Configuration Name laat u de 0 staan. In figuur 10/4.4-6 ziet u hoe dit er in YaST uitziet. Nu komt u in een interface die veel lijkt op de interface van waaruit u het bonding device geconfigureerd hebt. U geeft nu in deze interface op welke netwerkkaart deel uitmaakt van de bridge (dat wordt dus bond0) en vervolgens wijst u een IP-adres en subnetmasker toe aan de bridge. Klik nu op Next om de configuratie naar uw systeem weg te schrijven. Ook nu wordt er weer een configuratiebestand aangemaakt,


10/4.4-21

Virtualisatie

Figuur 10/4.4-6 Ook de netwerkbridge maakt u eenvoudig vanuit YaST aan.

ditmaal met de naam /etc/sysconfig/network/br0. In dit configuratiebestand moet u een aantal parameters toevoegen, het gaat om de parameters waarvan de naam begint met ‘bridge’ die u in listing 10/4.4-7 kunt zien. BOOTPROTO=’static’ BRIDGE=’yes’ BRIDGE_FORWARDDELAY=’0’ BRIDGE_PORTS=’bond0’ BRIDGE_STP=’off’ BROADCAST=’’ ETHTOOL_OPTIONS=’’ IPADDR=’192.168.1.101/24’ MTU=’’ NAME=’’ NETWORK=’’ REMOTE_IPADDR=’’ STARTMODE=’auto’

10/4.4-22


Integratie

USERCONTROL=’no’ PREFIXLEN=’24’ DEVICE=’switch’ TYPE=’Bridge’ BRIDGE_HELLOTIME=’2’ BRIDGE_MAXAGE=’20’ BRIDGE_PATHCOST=’19’ Listing 10/4.4-7 Voorbeeldconfiguratie br0 interface.

Nadat u het configuratiebestand gewijzigd hebt, kunt u de bridge opnieuw opstarten. Dit doet u met de opdrachten ifdown br0, gevolgd door ifup br0. De volledige netwerkconfiguratie is nu operationeel en als er externe nodes beschikbaar zijn, zou u deze nu moeten kunnen pingen. U kunt nu de opdracht ifconfig gebruiken om uw netwerkconfiguratie te controleren. Deze zou er nu ongeveer uit moeten zien als in listing 10/4.4-8. node1:/ # ifconfig bond0 Link encap:Ethernet HWaddr 00:0C:29:5C:88:70 UP BROADCAST RUNNING MASTER MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) br0

Link encap:Ethernet HWaddr 00:0C:29:5C:88:70 inet addr:192.168.1.10 Bcast:192.168.1.255

Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0


10/4.4-23

Virtualisatie

RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth1

Link encap:Ethernet HWaddr 00:0C:29:5C:88:5C inet addr:10.0.0.10 Bcast:10.0.0.255

Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:3735 errors:0 dropped:0 overruns:0 frame:0 TX packets:3562 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:4333074 (4.1 Mb) TX bytes:292172 (285.3 Kb) Interrupt:19 Base address:0x2024 eth2

Link encap:Ethernet HWaddr 00:0C:29:5C:88:66 inet addr:10.0.0.11 Bcast:10.0.0.255

Mask:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:6 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:360 (360.0 b) TX bytes:0 (0.0 b) Interrupt:19 Base address:0x20a4 th3

Link encap:Ethernet HWaddr 00:0C:29:5C:88:70 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:16 Base address:0x2424

eth4

Link encap:Ethernet HWaddr 00:0C:29:5C:88:70 UP BROADCAST RUNNING SLAVE MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0

10/4.4-24


Integratie

collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:17 Base address:0x24a4 lo

Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:4 errors:0 dropped:0 overruns:0 frame:0 TX packets:4 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:200 (200.0 b) TX bytes:200 (200.0 b)

Listing 10/4.4-8 De netwerkconfiguratie wordt door ifconfig weergegeven.

U kunt nu controleren dat uw bridge functioneert en in staat is te communiceren met externe nodes. Als dit het geval is, kunt u vervolgens de andere nodes instellen. Heeft de bridge communicatieproblemen, dan hebt u iets verkeerd gedaan. Lees in dat geval de voorgaande tekst nog eens aandachtig door en corrigeer het probleem voordat u verdergaat met het inrichten van het cluster. Noot: een erg vaak gemaakte fout is dat men toch probeert het bond0-device te configureren met de optie No IP Address (for Bonding Devices) die YaST biedt. Deze optie zorgt ervoor dat het device ook niet automatisch geactiveerd wordt, dus niet bruikbaar is. Controleer of dit het geval is: in het configuratiebestand /etc/sysconfig/network/ifcfg-bond0 moet de parameter startmode de waarde auto hebben. 4. Inrichting van het cluster Nu de netwerkkaarten op de juiste wijze geconfigureerd zijn, is het tijd om met het cluster bezig te gaan. Hiervoor maken we gebruik van de SLES High Availability Extension Novell Netwerkoplossingen, aanvulling 33

10/4.4-25

Virtualisatie

(HAE), een aparte product-cd die los van SLES 11 verkocht wordt. Dat betekent inderdaad dat u extra moet betalen, maar daar staat tegenover dat de prijs van de HAE alleszins redelijk is en dat u in ruil voor uw geld software krijgt die ondersteund is en waarin een compleet ecosysteem zit dat ervoor zorgt dat u zo snel mogelijk weer up en running bent als u tegen problemen aanloopt. U kunt overigens de software die op deze cd geleverd wordt ook kosteloos gebruiken, alle componenten zijn namelijk gewoon te downloaden via www.clusterlabs.org. We gaan er echter van uit dat u support belangrijk vindt en om die reden ook in de eerste instantie al SLES geïnstalleerd hebt in plaats van OpenSuSE. Daarom leest u hier hoe te werken met de software uit de High Availability Extension. We gaan ervan uit dat u de software inmiddels gedownload en op cd gebrand hebt en dat u de installatie-cd beschikbaar hebt. U leest nu hoe u de volgende stappen uitvoert: a. De clustersoftware installeren. b. De clusterbasis configureren. c. STONITH opzetten. d. Resources aanmaken voor de virtual machine storage back-end. a. Clustersoftware installeren Om te beginnen moet u ervoor zorgen dat de clustersoftware geïnstalleerd is. De onderstaande procedure beschrijft hoe u deze taak vanuit YaST uitvoert. 1. Leg de installatie-cd in de lade van het optische schijfstation van uw server. 2. Start YaST en kies hier Software, Add-on Products. 3. Klik op Add, selecteer de optie CD en klik vervolgens op Next om aan te geven dat de installatie-cd beschikbaar is. 4. Lees de licentie, als u daar zin in hebt, en klik dan op Accept om aan te geven dat u akkoord gaat met de 10/4.4-26


Integratie

bepalingen. Kies nu in YaST de softwarecategorie High Availability en klik op Details om de packages uit deze categorie te bekijken. Selecteer hier alle software die wordt aangeboden (zie figuur 10/4.4-7). 5. Klik nu op Accept om uw keuze te bevestigen. Als gevraagd wordt of u de bijbehorende software dependencies wilt installeren, klikt u op Continue. 6. Als aan het eind van de procedure gevraagd wordt of u Novell Customer Center wilt configureren, geeft u aan dit later te doen. Sluit vervolgens de installatieprocedure af.

Figuur 10/4.4-7 Installeer alle softwarepackages uit de High Availability Extension.

b. Basiscluster configureren Nu de softwarepackages geïnstalleerd zijn, kunt u de clusterbasis aanmaken. Hierin zorgt u ervoor dat de nodes in het cluster elkaar zien en met elkaar kunnen communiceren. De volgende procedure beschrijft hoe u hiervoor te werk gaat. Novell Netwerkoplossingen, aanvulling 33

10/4.4-27

Virtualisatie

1. Kies in YaST de optie Miscellaneous, Cluster. U ziet nu het hoofdvenster van waaruit u het cluster aanmaakt (zie figuur 10/4.4-8).

Figuur 10/4.4-8 Vanuit dit venster moet u het cluster verder definiëren.

2. Selecteer om te beginnen in de vervolgkeuzelijst het Bind Network Address. U kunt hier kiezen uit alle netwerkadressen die momenteel op uw computer geconfigureerd zijn. Dit netwerk wordt door het cluster gebruikt om de clusterpakketjes over te verzenden. Het is handig als u hiervoor een netwerk selecteert dat representatief is voor de ervaringen van de gebruiker. Kies daarom het netwerk waarop ook het LAN-verkeer verstuurd wordt. Daarbij moet u opgeven op welk multicastadres op dit netwerk gecommuniceerd moet worden. In principe kunt u elk IP-adres gebruiken dat begint met een getal tussen 224 en 239, zolang het maar uniek is. Mocht het zo zijn dat op uw netwerk meerdere clusters naast elkaar leven, dan zorgt u dat 10/4.4-28


Integratie

3.

4.

5.

6.

elk cluster zijn eigen unieke multicastadres heeft. In dit voorbeeld gebruiken we het adres 224.13.14.15. Voordat u verdergaat, moet u op zijn minst nog nadenken of u een redundant kanaal wilt configureren voor de communicatie van clusterpakketjes. Er is iets voor te zeggen om dit wel te doen, maar ook om dit niet te doen. Wij kiezen ervoor geen redundant kanaal op te zetten. Het cluster moet naar onze mening actie ondernemen als de primaire netwerkverbinding wegvalt. Dit gebeurt niet als u ook een tweede medium configureert. Voorstanders van de visie om een redundante netwerkverbinding te configureren zullen hiertegen inbrengen dat u dit probleem kunt oplossen door een ping-resource te configureren. De ping-resource wordt geconfigureerd om periodiek te pingen naar een node die altijd bereikbaar zou moeten zijn en zorgt ervoor dat het cluster actie onderneemt als dit niet lukt, zodat de node waarop de ping-resource faalt zijn werk te doen, alsnog automatisch down gebracht kan worden. Wij vinden dit nodeloos complex en maken daarom geen gebruik van deze optie. Uiteraard mag u zelf uw keuze maken. Activeer nu de optie Service. Hier selecteert u onder de optie Booting het keuzerondje On (zie figuur 10/4.4-9). Dit zorgt ervoor dat het cluster toegevoegd wordt aan de run-levels. Klik daarna op Start OpenAIS now om het cluster ook nu op te starten. Klik dan op Finish om het cluster op te starten. Gefeliciteerd, de clustersoftware is nu op de eerste node actief. Herhaal deze procedure op alle andere nodes die deel uitmaken van het cluster. Voor alle duidelijkheid, dit zijn de servers waarop u uiteindelijk de virtuele machines beschikbaar wilt maken. Als u klaar bent met de configuratie van de clustersoftware op alle nodes, start u op een van de nodes de


10/4.4-29

Virtualisatie

Figuur 10/4.4-9 Geef hier aan dat het cluster vanuit de run-levels gestart moet worden en dat het nu gestart moet worden.

opdracht crm_mon -i 1. Crm_mon is de zogenaamde Cluster Resource Manager (crm)-monitor. De Cluster Resource Manager is het hart van het cluster dat bepaalt waar op clusterresources gestart kunnen worden. Met de opdracht crm_mon -i 1 vraagt u het cluster met een interval van een seconde (vandaar de 1) een update te geven van de status van het cluster op dit moment. Het resultaat zou eruit moeten zien als in listing 10/4.4-9. ============ Last updated: Fri Dec 18 13:37:34 2009 Current DC: node1 – partition with quorum Version: 1.0.3-0080ec086ae9c20ad5c4c3562000c0ad68374f0a 2 Nodes configured, 2 expected votes

10/4.4-30


Integratie

0 Resources configured. ============ Online: [ node1 node2 ] Listing 10/4.4-9 Met crm_mon -i 1 monitort u de huidige status van het cluster.

7. Rest ons nog een stap: u moet er nu voor zorgen dat de grafische clusterbeheertool hb_gui gebruikt kan worden. Hiertoe is een gebruiker met de naam hacluster aangemaakt. Als u deze gebruiker een wachtwoord geeft, kunt u straks met dit gebruikersaccount inloggen om clusterresources aan te maken en te beheren. Geef daarom nu de opdracht passwd hacluster en voer vervolgens het wachtwoord in dat u wilt gebruiken. Als dat gebeurd is, kunt u configureren of het inderdaad werkt. Geef vanuit een shell de opdracht hb_gui. U ziet vervolgens het scherm in figuur 10/4.4-10.

Figuur 10/4.4-10 Het aanmeldscherm van hb_gui.


10/4.4-31

Virtualisatie

8. Om het cluster vanuit hb_gui te bekijken moet u zich nu eerst aanmelden. Klik daarvoor op Connection, selecteer dan de optie Login en voer het wachtwoord in dat u zojuist aan de gebruiker hacluster hebt gegeven. Vervolgens duurt het even voordat hb_gui alle informatie van het cluster heeft ingelezen en ziet u het venster uit figuur 10/4.4-11, met daarin een overzicht van de huidige status van het cluster.

Figuur 10/4.4-11 Na inloggen ziet u een overzicht van de huidige status van het cluster.

c. STONITH opzetten Voordat u in het cluster resources gaat aanmaken die toegang moeten geven tot de shared storage op het SAN, moet u eerst zorgen voor een belangrijk veiligheidsmechanisme. De naam van dit mechanisme is STONITH, wat staat voor ‘Shoot The Other Node In The Head’.

10/4.4-32


Integratie

In een HA-cluster is het van groot belang dat het cluster zeker weet dat een node ook daadwerkelijk down is voordat de resources van die node worden overgenomen. U moet hiervoor zorgen om corruptie op resources – met name het bestandssysteem – te voorkomen. Zonder STONITH zou het kunnen gebeuren dat bijvoorbeeld een bestandssysteem op twee nodes tegelijk gemount is. Daar kunnen bestandssystemen niet tegen: als twee nodes tegelijkertijd proberen te schrijven naar een bestandssysteem dat daarvoor niet ontworpen is, leidt dat onherroepelijk tot een crash van het betreffende systeem. Daarom hebt u STONITH nodig. Het principe van STONITH is eenvoudig: voordat een resource weggemigreerd wordt van een node waarvan verondersteld wordt dat daar iets mis mee is, verzekert STONITH zich ervan dat die node ook echt down is. Dit gebeurt door de node botweg uit te zetten. Om dit te kunnen doen is echter een mechanisme nodig waarmee u een node uit kunt zetten. Typisch is dit een hardwaremechanisme, denk bijvoorbeeld aan een manageable power switch zoals de APC Master of een remote-beheerkaart zoals ILO in HP of DRAC in Dell. Het cluster stuurt dan via de STONITH resource agent een opdracht naar het STONITH-device waarop deze wordt uitgezet.

SSH

STONITH is afhankelijk van de hardware die u gebruikt. Om deze beschrijving zo algemeen mogelijk toepasbaar te maken, maken we hier gebruik van een van de STONITHagents die niet ontwikkeld zijn als duurzame oplossing, namelijk de SSH-agent. U dient zich echter te realiseren dat er nogal wat nadelen zijn aan de configuratie van SSH als STONITH-oplossing. Ten eerste heeft SSH een netwerkverbinding nodig die actief is en daarnaast heeft SSH een werkend besturingssysteem nodig. Als aan een van deze condities niet voldaan is, zal STONITH er nooit in slagen


10/4.4-33

Virtualisatie

de andere node uit te zetten. Sterker nog, u zult de betreffende node handmatig moeten resetten. Als de node die een probleem had vervolgens weer up komt, zult u waarschijnlijk merken dat hij gelijk weer wordt uitgezet. De reden? De STONITH-agent die in het cluster zijn opdracht voor een reset klaar had staan, is er eindelijk in geslaagd de opdracht bij de betreffende node af te leveren. Kortom, STONITH op basis van SSH is aardig om te bewijzen dat STONITH werkt, als noodoplossing als u er nog niet in geslaagd bent hardware in te zetten voor STONITH of als back-up-STONITH-oplossing, maar het kan nooit een definitieve oplossing zijn. Om SSH-STONITH te kunnen gebruiken moet u eerst op de nodes in het cluster wat voorbereidend werk doen. U moet host name resolving opzetten, u moet ervoor zorgen dat SSH op basis van key-based authenticatie werkt en het atd-proces moet gestart worden. Deze stappen worden hieronder besproken en moeten op alle nodes worden uitgevoerd. 1. Idealiter wordt name resolving geregeld vanuit DNS. Als u geen DNS beschikbaar hebt, moet u er in /etc/hosts voor zorgen dat een entry wordt aangemaakt voor alle nodes in het cluster. Hierbij wordt het IP-adres gebruikt waaraan de clustersoftware gebonden is, niet het IP-adres dat door het SAN gebruikt wordt. 2. Maak nu op beide hosts een SSH-sleutelpaar aan. Dit doet u met de opdracht ssh-keygen -t dsa. Accepteer op alle vragen die vervolgens gesteld worden de default door op Enter te drukken. Let er vooral op dat u geen passphrase instelt op de keys! In listing 10/4.4-10 ziet u hoe de uitvoer van ssh-keygen eruitziet. 3. Nu moet u de public key van de hosts naar de andere hosts kopiëren. Hiervoor gebruikt u de opdracht sshcopy-id, gevolgd door de naam van de host waarnaar u 10/4.4-34


Integratie

de sleutels wilt kopiëren. U zult dit per host moeten doen (of een eenvoudig script moeten schrijven dat de betreffende hostnamen een voor een afloopt). Gebruik bijvoorbeeld ssh-copy-id node1 om de key van de huidige node te kopiëren naar node1. In listing 10/4.4-11 ziet u hoe het resultaat van deze opdracht eruitziet. Nadat de sleutels met succes gekopieerd zijn, bent u in staat om van de ene node in te loggen op de andere node zonder een wachtwoord in te voeren. 4. Tot slot moet u de atd-service opstarten en ervoor zorgen dat deze automatisch opgestart wordt vanuit de run-levels. Gebruik hiervoor de onderstaande twee opdrachten: insserv atd rcatd start node2:~/Desktop # ssh-keygen -t dsa Generating public/private dsa key pair. Enter file in which to save the key (/root/.ssh/id_dsa): Created directory ‘/root/.ssh’. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /root/.ssh/id_dsa. Your public key has been saved in /root/.ssh/id_dsa.pub. The key fingerprint is: d5:3f:88:ff:f7:54:a1:e1:64:8f:57:0c:89:d3:a0:74 root@node2 The key’s randomart image is: +–-[ DSA 1024]––--+ |

. E+.. |

|

. +o oo |

|

o .= .o|

|

. .+o= o|

|

S . .+oo.|

|

. ...|


10/4.4-35

Virtualisatie

|

. .|

|

. ..|

|

..o|

+––––––––-––––––––-+ Listing 10/4.4-10 Gebruik ssh-keygen om een sleutelpaar aan te maken.

node2:~/Desktop # ssh-copy-id node1 The authenticity of host ‘node1 (192.168.150.10)’ can’t be established. RSA key fingerprint is 8e:4b:ed:2b:2a:15:34:5e:54:50:14:35: 20:2c:29:b5. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added ‘node1,192.168.150.10’ (RSA) to the list of known hosts. Password: Now try logging into the machine, with “ssh ‘node1’”, and check in: .ssh/authorized_keys to make sure we haven’t added extra keys that you weren’t expecting. Listing 10/4.4-11 Met ssh-copy-id kopieert u de keys van de huidige host naar de andere hosts.

U bent nu klaar met het voorbereidende werk om STONITH te kunnen gebruiken. Nu moet u de STONITH-resources zelf aanmaken in het cluster. Hiervoor maakt u gebruik van de hb_gui. Zorg er dus voor dat deze gestart is en u bent ingelogd. Om STONITH te kunnen uitvoeren moet er per node in het cluster een STONITH-agent geconfigureerd zijn. De taak 10/4.4-36


Integratie

van deze agent is de falende node uit te zetten. Met andere woorden, om ervoor te zorgen dat node1 uitgezet kan worden in geval van problemen, moet er ergens in het cluster een STONITH-agent zijn die deze node uit kan zetten. In sommige configuraties wordt hiervoor gewerkt met clone resources. Dit zijn resources die meer dan eens gestart kunnen worden. Het idee is dan dat elke andere node in het cluster in staat moet zijn om node1 uit te zetten in geval van problemen. Wij doen dit niet door middel van clone resources, omdat we ervan uitgaan dat het normaliter nooit gebeurt dat er spontaan meerdere nodes in het cluster tegelijkertijd uitvallen. Daarnaast is het de aard van het cluster dat resources altijd gestart worden op een andere node als de betreffende node uitvalt. Concreet betekent dit dat als op node2 een STONITH-resource voor node1 actief is en node2 uitvalt, de betreffende STONITHresource overgezet wordt naar een andere node. U zult alleen begrijpen dat we ervoor moeten zorgen dat de betreffende resource nooit op node1 mag komen te draaien, het zou namelijk vrij zinloos zijn als node1 op deze manier probeert zichzelf uit te zetten. De onderstaande procedure beschrijft hoe we op node1 een STONITH-resource aanmaken die node2 kan uitschakelen. Omdat er mogelijkerwijs meer dan twee nodes in het cluster beschikbaar zijn, configureren we bovendien een regel (een zogenaamde constraint) die ervoor zorgt dat deze resource overal mag draaien, behalve op node2. 1. Selecteer in de Linux HA Management Client onder de optie Configuration de optie Resources en klik op Add om een nieuwe resource toe te voegen. U ziet nu een menu waarin u opgeeft wat voor type resource u wilt aanmaken. Kies in dit menu de optie Primitive om een ‘normale’ resource aan te maken.


10/4.4-37

Virtualisatie

2. In het venster Add Primitive (zie figuur 10/4.4-12) geeft u vervolgens aan hoe de resource geconfigureerd wordt. Geef die om te beginnen een naam, bij voorkeur een naam die u helpt te herkennen wat de resource ook maar weer doet. Wij kiezen hier voor Stonith-node2, de bedoeling van deze resource is immers om node2 uit te zetten. Bij Class selecteert u STONITH en als type kiest u External/SSH. Tot slot geeft u onder opties als Initial State of Resource aan dat deze gestart moet worden. Klik dan op Forward om verder te gaan en andere parameters op te geven.

Figuur 10/4.4-12 De STONITH-resource aanmaken.

3. U ziet nu een venster dat uit drie tabbladen bestaat. Als standaard is het tabblad Instance Attributes geopend. Hierop ziet u standaard het attribuut hostlist. Selecteer dit attribuut, klik vervolgens op Edit en voer dan de naam in van de host die door deze STONITH10/4.4-38


Integratie

agent beheerd moet worden. Klik dan op Apply om de resource op te slaan in het cluster. Noot: krijgt u een foutmelding zonder dat het cluster erin slaagt de wijzigingen op te slaan? Waarschijnlijk hebt u dan nog geen update uitgevoerd van de software op uw computer. Stop wat u aan het doen bent om nu een update uit te voeren. Zonder updates zult u er niet in slagen de clustersoftware werkend te krijgen. 4. Nu moet u ervoor zorgen dat de STONITH-agent die u zojuist geconfigureerd hebt, overal gestart mag worden, behalve op de node die hij uit moet zetten. Dus de resource die aangemaakt is voor node1, mag overal behalve op node1 gestart worden. Dit regelen we door een zogenaamde location constraint. Door deze constraint (letterlijk: regel) een score van -INFINITY te geven voor node1, zorgen we ervoor dat hij nooit op node1 gestart zal worden. Selecteer hiertoe in hb_gui de optie Constraints, klik op Add en kies dan de Resource Location. Als ID geeft u deze constraint een unieke naam. Kies vervolgens bij Resource de resource die u hebt aangemaakt voor SSH van node1. Dan geeft u deze resource een score -INFINITY en tot slot bepaalt u dat deze score gekoppeld wordt aan node1 (zie figuur 10/4.4-13). Klik op OK om de constraint op te slaan en direct toe te passen. Vervolgens voert u dezelfde stappen uit voor node2. 5. De resources moeten nu aangemaakt zijn en beschikbaar zijn voor het cluster. U ziet in figuur 10/4.4-14 hoe de situatie er op dit punt uit hoort te zien. U doet er overigens verstandig aan de nodes nu opnieuw op te starten zodat de clusterconfiguratie schoon ingeladen kan worden. Als dat gebeurd is, wordt het tijd voor de volgende fase in de configuratie, het aanmaken van resources voor de shared storage. Novell Netwerkoplossingen, aanvulling 33

10/4.4-39

Virtualisatie

Figuur 10/4.4-13 Door een location constraint aan te maken zorgt u dat een bepaalde resource nooit op een gespecificeerde node gestart kan worden.

Figuur 10/4.4-14 De STONITH-resources zijn klaar voor gebruik (maar nog niet gestart).

10/4.4-40


Integratie

d. Resources aanmaken voor shared storage Nu wordt het tijd om even na te denken wat u precies wilt met uw virtuele machines, en dan met name op het gebied van opslag. Een virtuele machine heeft een harde schijf nodig en deze moet op de hostcomputer door iets vertegenwoordigd worden. U kunt hierbij kiezen uit twee opties: ofwel u zet een OCFS2-bestandssysteem in om daarop voor elke virtuele machine een afzonderlijk bestand te maken, ofwel u geeft de afzonderlijke virtuele machines direct toegang tot een device dat ze kunnen gebruiken als storage back-end.

cLVM

De oplossing om gebruik te maken van een bestand als storage back-end heeft als grootste voordeel dat het wat flexibeler is. Het is nu eenmaal eenvoudiger om een kopie te maken van een bestand dan van een compleet device. Er is echter ook een nadeel. In een geclusterde omgeving zult u dit bestand moeten plaatsen op een bestandssysteem dat door meerdere nodes tegelijkertijd benaderd kan worden. Dit kan door middel van het OCFS2-bestandssysteem, maar hiermee voegt u een extra laag complexiteit toe aan het cluster. Om die reden heeft deze oplossing niet onze voorkeur. Onze voorkeur gaat uit naar de methode waar gebruikgemaakt wordt van een device als storage back-end. Voor dit device kan gebruik worden gemaakt van cLVM, de cluster-aware versie van de LVM volume manager. cLVM maakt deel uit van de HAE, u hebt hier dus gewoon beschikking over. In de onderstaande procedure leert u hoe u cLVM-volumes aanmaakt. Deze procedure bestaat uit twee onderdelen: eerst moet u in het cluster de benodigde resources aanmaken, vervolgens maakt u de LVM-volumes op uw storage devices aan.


10/4.4-41

Virtualisatie

Voor wat betreft de configuratie in het cluster zijn er twee onderdelen die u moet configureren. Als eerste hebt u een resource nodig voor de Distributed Lock Manager (DLM). Deze component zorgt ervoor dat locking tussen de nodes succesvol plaatsvindt. Als dit gebeurd is, moet u als tweede een resource aanmaken voor de cLVM-volumes. Beide resourcetypen moeten aangemaakt worden als clone resource en moeten gestart worden op alle hostcomputers. De volgende procedure beschrijft hoe u te werk gaat. 1. Voordat u de resources in het cluster aanmaakt, moet u op elke hostmachine aangeven dat locking in het cluster zal plaatsvinden. Dit doet u door een instelling in het configuratiebestand /etc/lvm/lvm.conf op te nemen. U vindt hier de standaardoptie locking_type = 1, deze moet veranderd worden in lockin_type = 3. 2. Start de hb_gui-interface, selecteer vervolgens Configuration, Resources en klik op Add. De interface om nieuwe resources toe te voegen wordt nu gestart. Omdat u een resource wilt aanmaken die op meerdere nodes tegelijk gestart moet worden, selecteert u hier het type Clone. Geef de clone de naam dlm-clone en verzeker u ervan dat de Initial state of resource op Started staat (zie figuur 10/4.4-15). Klik dan op Forward om door te gaan naar de volgende stap. 3. Nu wordt gevraagd welk type subresource u wilt aanmaken. Het gaat hier om het daadwerkelijke proces dat op de afzonderlijke nodes gestart wordt. Kies hier de optie Primitive en klik dan op OK. 4. Geef de aan te maken resource als ID dlm, kies dan de class ocf, de provider pacemaker en het type controld (zie figuur 10/4.4-16). Klik dan op Forward om verder te gaan. 5. Klik nu op Apply. U komt hiermee terug in het venster waarin u de eigenschappen van de clone zelf opgeeft.

10/4.4-42


Integratie

Figuur 10/4.4-15 Maak een clone resource aan met de naam dlm-clone en zorg ervoor dat deze automatisch gestart wordt.

Figuur 10/4.4-16 Configuratie van de DLM clone subresource.

Selecteer hier het tabblad Meta Attributes en klik op Add. Voeg nu de attributen ordered en interleave toe Novell Netwerkoplossingen, aanvulling 33

10/4.4-43

Virtualisatie

Figuur 10/4.4-17 Geef de clone resource de attributen ordered en interleave, beide met de waarde true.

Figuur 10/4.4-18 De dlm-resources moeten operationeel zijn voordat u verder kunt gaan.

10/4.4-44


Integratie

en zorg ervoor dat beide de waarde true hebben (zie figuur 10/4.4-17). Klik vervolgens op Apply om de clone resource toe te voegen. 6. Ga naar het Management-gedeelte van de hb_gui (zie figuur 10/4.4-18). U moet hier nu de clone resources zien en beide zouden door het cluster gestart moeten zijn. Ga niet verder voordat dit inderdaad het geval is! 7. Nu gaat u verder met het aanmaken van de cLVM-resources. Selecteer hiervoor in Heartbeat wederom de optie Configuration, Resources, Add en geef aan dat u een clone resource wilt aanmaken. Vergeet ook hier niet de initiële status op Started te zetten. Geef de clone resource de naam clvm-clone en specificeer dan dat u een primitive wilt aanmaken als subresource. 8. Geef de primitive resource om te beginnen de ID clvm, Kies dan de class ocf, de provider lvm2 en het type clvm. Het resultaat hoort er nu zo uit te zien als in figuur 10/4.4-19. Verifieer dat dit inderdaad het geval is en klik dan op Forward om verder te gaan.

Figuur 10/4.4-19 De cLVM-resource aanmaken.


10/4.4-45

Virtualisatie

9. Activeer nu het tabblad Instance Attributes en klik daar op Add om een nieuw attribuut toe te voegen. Dit moet het attribuut daemon_timeout worden en dit attribuut moet de waarde 30 krijgen (zie figuur 10/4.420). Hiermee geeft u de cLVM-daemon 30 seconden de tijd om op te komen. Klik dan op Apply om deze instelling op te slaan.

Figuur 10/4.4-20 Het attribuut daemon_timeout wordt gebruikt om het cLVM-proces wat langer de tijd te geven om op te komen.

10. Nu bent u weer terug in het venster met de eigenschappen van de clone zelf. Klik hier op het tabblad Meta Attributes. Voeg ook voor deze resource de attributen ordered en interleave op. Beide moeten de waarde true hebben. Klik dan op Apply om de wijzigingen op te slaan. Activeer vervolgens het Management-gedeelte van de hb_gui en verifieer dat alle resources opgekomen zijn (zie figuur 10/4.4-21). Als dit niet het geval is, heeft het geen zin om verder te gaan, dus los eventuele problemen op voordat u doorgaat naar de volgende stap.

10/4.4-46


Integratie

Figuur 10/4.4-21 Controleer dat de resources opgekomen zijn voordat u verdergaat.

11. Nu moet u twee constraints toevoegen. Als eerste is dat een order constraint, die ervoor zorgt dat de cLVMclone alleen gestart mag worden als de DLM-clone opgekomen is. Daarnaast hebt u een colocation constraint nodig die bepaalt dat DLM en cLVM altijd samen op een machine gestart worden. Klik in hb_gui op Configuration, Constraints, Add en selecteer de optie Resource colocation. 12. Geef nu een ID aan de constraint, bijvoorbeeld DLMCloneWithcLVMClone. Selecteer dan in de vervolgkeuzelijst Resource de dlm-clone-resource en in de vervolgkeuzelijst With Resource de clvm-clone die u eerder hebt aangemaakt. Tot slot geeft u deze constraint als score de waarde INFINITY, wat betekent dat ze altijd samen Novell Netwerkoplossingen, aanvulling 33

10/4.4-47

Virtualisatie

gestart worden (zie figuur 10/4.4-22). Klik nu op OK om deze instellingen op te slaan.

Figuur 10/4.4-22 De colocation constraint zorgt ervoor dat beide clone resources altijd samen gestart worden.

13. Nu moet u ook een constraint aanmaken die bepaalt dat eerst de DLM gestart wordt en pas daarna de cLVM. Klik hiervoor in hb_gui op Configuration, Constraints, Add en selecteer de optie Resource order. 14. Geef de constraint om te beginnen een ID, DLMCloneBeforecLVMClone is bijvoorbeeld een aardige ID omdat u zo duidelijk kunt zien wat de constraint precies doet. Kies dan bij First de clone resource DLMClone, en bij Then de resource cLVMClone (zie figuur 10/4.4-23). Klik vervolgens op OK om deze instellingen op te slaan.

10/4.4-48


Integratie

Figuur 10/4.4-23 De order constraint is noodzakelijk om ervoor te zorgen dat eerst de DLM-clone gestart wordt en daarna de cLVMclone.

Logical volumes aanmaken Nu aan alle voorwaarden is voldaan, kunt u de logische volumes zelf aanmaken. Dat betekent dat u eerst pvcreate, vgcreate en lvcreate moet gebruiken om de volumes aan te maken. Wanneer dat gebeurd is, maakt u in het cluster de bijbehorende resources aan die ervoor zorgen dat er geen conflicten ontstaan in de toegang tot de logische volumes. Het aanmaken van de logische volumes gaat echter niet zomaar zonder meer, we zullen een truc uit moeten halen om voor elkaar te krijgen dat dit toch werkt. Het probleem is namelijk dat u niet rechtstreeks een multipath-device kunt aanwijzen voor gebruik in LVM. U zult dus eerst multipath uit moeten zetten, dan het hele cluster opnieuw opstarten, vervolgens op het onderliggende device een markering aanbrengen voor LVM en multipath weer aan moeten zetten voordat u verder kunt. De onderstaande stappen beschrijven hoe u te werk gaat. 1. Geef de opdracht multipath -l. Deze opdracht laat zien welke multipath-devices er zijn en welke lokale devices daaraan gekoppeld zijn (zie listing 10/4.4-12). In ons Novell Netwerkoplossingen, aanvulling 33

10/4.4-49

Virtualisatie

geval zijn er twee multipath-devices, /dev/dm-0 en /dev/dm-1. Onder dm-0 vallen de schijven sdb en sdd, onder dm-1 de schijven sdc en sde. node2:~ # multipath -l 1494554000000000000000000010000009c0500000f000000 dm-1 IET,VIRTUAL-DISK [size=10.0G][features=0][hwhandler=0][rw] \_ round-robin 0 [prio=-1][active] \_ 3:0:0:1 sdc 8:32 [active][undef] \_ round-robin 0 [prio=-1][enabled] \_ 4:0:0:1 sde 8:64 [active][undef] 1494554000000000000000000010000008f0500000f000000 dm-0 IET,VIRTUAL-DISK [size=10G][features=0][hwhandler=0][rw] \_ round-robin 0 [prio=-1][active] \_ 3:0:0:0 sdb 8:16 [active][undef] \_ round-robin 0 [prio=-1][enabled] \_ 4:0:0:0 sdd 8:48 [active][undef] Listing 10/4.4-12 Maak voordat u begint een notitie van uw huidige multipath-configuratie.

2. Geef op alle hostservers in het cluster de opdracht insserv -r multipathd. Start vervolgens de servers opnieuw op. Gebruik hiervoor eerst de opdracht pkill aisexec, gevolgd door het commando reboot. Als dit te lang duurt, mag u ook de powerknop op de servers gebruiken om deze opnieuw op te starten. 3. Nadat de servers weer opgekomen zijn, opent u op een van de servers als root een terminalvenster. Hierin moet u met de opdracht pvcreate de devices die normaal deel uitmaken van een multipath-device, markeren als LVM physical volume. U hoeft dit echter maar op één device per multipath-device te doen. Dat betekent dat u de dm-0 instelt met de opdracht pvcreate /dev/ 10/4.4-50


Integratie

sdb en dat u de dm-1 instelt met pvcreate /dev/sdc. U zult hierbij een aantal foutmeldingen voorbij zien komen, maar deze kunt u negeren. 4. Zet nu op alle servers multipath weer aan met de opdracht insserv multipathd en start de servers opnieuw op. 5. Als de servers weer opgekomen zijn, geeft u de opdracht pvs om te kijken welke LVM physical volumes er op dit moment beschikbaar zijn. U zult ook zien dat u op maar één server logische volumes hebt op dit moment; dit is normaal en daar hoeft u zich geen zorgen over te maken. De cLVM-resource in het cluster zorgt er namelijk standaard voor dat er maar één server tegelijk is die de logische volumes kan zien. Het resultaat van de opdracht pvs ziet eruit als in listing 10/4.4-13. node1:~ # pvs PV VG Fmt Attr PSize PFree /dev/dm-0 vm1 lvm2 a- 10,00G 10,00G /dev/dm-1 lvm2 – 9,99G 9,99G Listing 10/4.4-13 Gebruik de opdracht pvs om een overzicht te krijgen van devices die bruikbaar zijn voor LVM.

Ga nu verder op de server waar pvs een resultaat gaf en maak hier de LVM volume groups aan. Het uiteindelijke doel wordt dat elke virtuele machine toegang krijgt tot een LVM-volume als storage back-end voor de virtuele harde schijf, en dit volume moet in een volume group per virtuele machine aangemaakt worden. Gebruik bijvoorbeeld vgcreate vm1 /dev/dm-0 om een volume group aan te maken met de naam vm1 voor uw eerste virtuele machine. (U mag uiteraard ook een naam kiezen die meer betekenis heeft voor uw omgeving.)


10/4.4-51

Virtualisatie

6. Maak voor elke virtuele machine een LVM-volume aan dat zo groot is als de hele volume group. Gebruik bijvoorbeeld lvcreate -L 10G -n vm1 /dev/vm1 om in volume group vm1 een LVM-volume aan te maken met de naam vm1 en een grootte van 10 G. Herhaal deze procedure totdat u de volumes hebt aangemaakt waarvan u gebruik wilt maken. 7. Nu u op het bestandssysteem de volumes hebt aangemaakt, moet u in het cluster resources aanmaken die bepalen hoe en waar de volumes geladen mogen worden. Voordat u dit doet, moet u echter bepalen hoe u wilt dat de volumes uiteindelijk gemount worden. U hebt hiervoor twee mogelijkheden: exclusief of toegankelijk door meerdere nodes tegelijk. Omdat het erg verkeerd kan aflopen met virtuele machines die op twee nodes tegelijkertijd geactiveerd worden, is het een goed idee de volumes exclusief te laden. Dit regelt u overigens met resources voor volume groups. 8. Selecteer in hb_gui de optie Configuration, Resources, Add en kies vervolgens het resourcetype Primitive. Gebruik als ID een naam die duidelijk aangeeft waarvoor de resource gebruikt wordt, bijvoorbeeld LVMforVM1. Selecteer vervolgens als class ocf, als provider heartbeat en als type LVM. Geef aan dat de resource een initiële status Started krijgt en klik dan op Forward (zie figuur 10/4.4-24). 9. Nu moet u nog twee attributen meegeven voor het volume. Om te beginnen is dat het verplichte attribuut volgrpname, waar u de devicenaam van de LVM volume group invoert. In het geval van dit voorbeeld wordt dat /dev/vm1. Vervolgens voegt u de parameter Exclusive toe met de waarde yes (zie figuur 10/4.4-25). Klik dan op Apply om de resource aan het cluster toe te voegen.

10/4.4-52


Integratie

Figuur 10/4.4-24 Een clusterresource aanmaken voor LVM.

Figuur 10/4.4-25 Voordat de LVM-resource het kan gaan doen, voert u twee parameters in.


10/4.4-53

Virtualisatie

10. Klik nu op Apply om de LVM-resource aan het cluster toe te voegen. Verifieer dan in de hb_gui dat de resource ook opkomt en werkt (zie figuur 10/4.4-26).

Figuur 10/4.4-26 Controleer voordat u verdergaat dat de LVM-resource operationeel is.

11. Nu moet u nog twee constraints aanmaken. Als eerste een colocation constraint die bepaalt dat de cLVM-resource en de LVM-resource die u zojuist hebt aangemaakt samen geladen worden, en daarnaast een order constraint die bepaalt dat eerst cLVM geladen wordt en dan pas de LVM-resource. Instructies voor het aanmaken van deze constraints hebt u eerder in deze paragraaf gelezen.

10/4.4-54


Integratie

Op dit moment bent u klaar met de configuratie in het cluster van de LVM-volumes. Nu kunt u verder met de volgende stappen, het aanmaken van de Xen virtuele machines zelf. 5. Xen virtuele machines aanmaken Nu u de resources voor de LVM-volumes operationeel hebt, kunt u verder met de volgende stap: het configureren van de Xen virtuele machines. Dit is een taak die u zonder veel problemen vanuit de utility virt-manager zou moeten kunnen uitvoeren. We gaan ervan uit dat u eerder een virtuele machine aangemaakt hebt en gaan daarom niet in op de details daarvan. Wel zijn er twee zaken die u in de gaten moet houden. Als eerste moet u de virtuele machine aanmaken op de host waar op dit moment ook het LVM-volume beschikbaar is. Dit kunt u via de hb_gui achterhalen. Als u bijvoorbeeld momenteel de volume group vm1 op de host node1 actief hebt, is dit ook de enige node waarop u de virtuele machine kunt definiëren. Voer de installatie van de virtuele machine op dit logische volume uit. Daarna moet u het cluster configureren om de virtuele machine te beheren. Dit komt erop neer dat u een resource aanmaakt voor de virtuele machine en deze resource door middel van een colocation constraint altijd samen laat zijn met het bijbehorende logische volume. Daarnaast moet u er met een order constraint voor zorgen dat eerst het volume geladen wordt en daarna de virtuele machine. We gaan ervan uit dat u inmiddels begrepen hebt hoe u een constraint aanmaakt, daarom vindt u hieronder alleen uitleg over het aanmaken van de resources voor de Xen virtuele machines.


10/4.4-55

Virtualisatie

1. Maak een resource aan met de ID XenVM1, class ocf, provider heartbeat en type Xen. Zorg ervoor dat de initiële status van de resource op Started staat en klik dan op Forward om verder te gaan. 2. In het venster Instance Attributes ziet u een attribuut staan met de naam xmfile. Dit attribuut moet als waarde de exacte locatie hebben van het configuratiebestand waarmee de virtuele machine gestart wordt. Dit zou bijvoorbeeld /etc/xen/vm/vm1kunnen zijn, afhankelijk van de configuratie die u gebruikt. Daarnaast is het raadzaam de parameter allow_migrate de waarde true te geven. 3. Sla nu de wijzigingen op. Dit zorgt ervoor dat de virtuele machine gestart wordt. Gefeliciteerd! U hebt nu een geclusterde Xen virtuele machine. 10/4.4.3 Tot slot U kunt ervoor kiezen een dure VMware HA-oplossing aan te schaffen om er verzekerd van te zijn dat virtuele machines up blijven als er zich problemen voordoen. U kunt zo’n oplossing ook zelf maken. U hebt geleerd hoe u uw eigen Xen HA-omgeving maakt, dat alles met software die beschikbaar is voor SLES 11. Deze oplossing stelt u in staat aanzienlijk te besparen op de kosten van uw eigen virtuele omgeving.

10/4.4-56


4.4 Virtualisatieoplossing voor datacentra met SLES 11 Xen

Recommend Documents