10/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 VM ware. 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 Su SE 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 VM ware kunt bouwen. Als u zoekt naar een oplossing waarmee iedereen op de ICT - afdeling eenvoudig even een server kan migreren, bent u met de combinatie Su SE -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 Su SE -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 Su SE -Xen bij voorbaat afvalt? Geenszins! Ook een oplossing op basis van VM ware heeft een specialist nodig om goed geïnstalleerd te worden en ook bij VM ware-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 VM ware. 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 Xen- Source 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 be- 10/4.4-2 Novell Netwerkoplossingen, aanvulling 33

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 Su SE 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 Novell Netwerkoplossingen, aanvulling 33

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 i SCSI. Voor de verdere werking van de Xen HA -oplossing maakt het overigens niet uit wat voor soort SAN u gebruikt, zowel i SCSI 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 Novell Netwerkoplossingen, aanvulling 33

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. Novell Netwerkoplossingen, aanvulling 33 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 Su SE 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 Novell Netwerkoplossingen, aanvulling 33

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 i SCSI 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 i SCSI 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 i SCSI -verbinding opzetten Als u gebruikmaakt van i SCSI, kunt u vanuit Su SE de i SCSI - verbinding 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 Ya ST de optie Network Services gevolgd door i SCSI Initiator. Waarschijnlijk meldt Ya ST nu dat i SCSI 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 i SCSI -configuratiescherm. Geef hierin om te beginnen aan dat i SCSI automatisch gestart moet Novell Netwerkoplossingen, aanvulling 33 10/4.4-9

Virtualisatie Figuur 10/4.4-1 Specificeer om te beginnen dat de i SCSI -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 Novell Netwerkoplossingen, aanvulling 33

Integratie 3. 4. worden tijdens het opstarten van de server (zie figuur 10/4.4-1). 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). Activeer nu het tabblad Connected Targets. Op dit tabblad ziet u de huidige i SCSI -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 i SCSI -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 i SCSI -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 VM ware, VM ware Virtual S 1.0 /dev/sda [2:0:0:0] cd/dvd NECVMW ar VM ware IDE CDR 10 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 i SCSI worden aangeboden. Novell Netwerkoplossingen, aanvulling 33 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 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. 10/4.4-12 Novell Netwerkoplossingen, aanvulling 33

Integratie Om de multipath-driver op Su SE 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. Novell Netwerkoplossingen, aanvulling 33 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 Novell Netwerkoplossingen, aanvulling 33

Integratie devices { device { vendor DELL product MD 3000i 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 Ya ST, 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 Novell Netwerkoplossingen, aanvulling 33

Integratie te configureren als bonding device. Voer de volgende stappen uit om uw netwerkkaart op deze wijze in te stellen: 1. Start Ya ST, 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 Ya ST kunt u eenvoudig een netwerkkaart instellen om in een bond gebruikt te worden. Novell Netwerkoplossingen, aanvulling 33 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 = 82575 GB 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 Novell Netwerkoplossingen, aanvulling 33

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: Ya ST begrijpt het niet als u geen IP -adres aan het bonding device toewijst, dus vul hier maar tijdelijk Novell Netwerkoplossingen, aanvulling 33 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 Ya ST -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 Novell Netwerkoplossingen, aanvulling 33

Integratie BONDING _ MASTER = yes BONDING _ MODULE _ OPTS = mode=active-backup BONDING _ SLAVE 0= eth0 BONDING _ SLAVE 1= 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 Ya ST op. Vervolgens selecteert u in Ya ST 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 Ya ST 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, Novell Netwerkoplossingen, aanvulling 33 10/4.4-21

Virtualisatie Figuur 10/4.4-6 Ook de netwerkbridge maakt u eenvoudig vanuit Ya ST 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 Novell Netwerkoplossingen, aanvulling 33

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 HW addr 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 HW addr 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 Novell Netwerkoplossingen, aanvulling 33 10/4.4-23

Virtualisatie RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) eth1 Link encap:ethernet HW addr 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 HW addr 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 HW addr 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 HW addr 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 Novell Netwerkoplossingen, aanvulling 33

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 Ya ST 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 OpenSu SE. 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 Ya ST uitvoert. 1. Leg de installatie-cd in de lade van het optische schijfstation van uw server. 2. Start Ya ST 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 Novell Netwerkoplossingen, aanvulling 33

Integratie 5. 6. bepalingen. Kies nu in Ya ST 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). Klik nu op Accept om uw keuze te bevestigen. Als gevraagd wordt of u de bijbehorende software dependencies wilt installeren, klikt u op Continue. 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 Ya ST 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 Novell Netwerkoplossingen, aanvulling 33

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 Open AIS 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 Novell Netwerkoplossingen, aanvulling 33 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 Novell Netwerkoplossingen, aanvulling 33

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. Novell Netwerkoplossingen, aanvulling 33 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 Novell Netwerkoplossingen, aanvulling 33

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 STONITH - agents 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 Novell Netwerkoplossingen, aanvulling 33 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 Novell Netwerkoplossingen, aanvulling 33

Integratie 4. 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. 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..... Novell Netwerkoplossingen, aanvulling 33 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 Novell Netwerkoplossingen, aanvulling 33

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 STONITH - resource 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. Novell Netwerkoplossingen, aanvulling 33 10/4.4-37