Hoge beschikbaarheid onder Linux

ArticleCategory:

System Administration

AuthorImage:

TranslationInfo:

AboutTheAuthor:

Atif is een kameleon. Hij verandert van rol, van systeembeheerder naar programmeur naar leraar naar projectleider, al naar gelang het werk vereist.
Soms zul je hem zien programmeren op zijn draagbare computer terwijl hij in de bioskoop een film bekijkt. Atif is van mening dat hij veel aan Linux en de opensource gemeenschap met zijn projecten te danken heeft vanwege de leerzame ervaringen.
Je kunt meer over hem vinden op zijn homepage.

Abstract:

Wanneer je aan het ontwerp van een kritisch systeem werkt, hetzij tijdens het uitdenken of bij het configureren van de hardware, moet je jezelf de volgende vragen stellen:

Hoe belangrijk is voor jou de applicatie die erop moet draaien?
Hoeveel andere applicaties zijn afhankelijk van degene die jij gaat draaien (denk aan NIS/NFS/DB/LDAP)?
Wat zijn de gevolgen als een onderdeel van de machine uitvalt (voeding, netwerkverbinding, harde schijf, enz.)?
Wat als de machine het in zijn geheel begeeft?

Als ik mezelf die vragen stel luid het antwoord meestal: "Dan word ik ontslagen!"

Als ik mezelf daarentegen afvraag "Zal het besturingssysteem het begeven?" dan is het antwoordt altijd: Nee.
"You are not running 32 bit extensions for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company, that can't stand 1 bit of competition". (deze aanhaling heb ik eens in een .sig gelezen).

Maar nu even serieus.

ArticleIllustration:

ArticleBody:

Waarom hoge beschikbaarheid?

Hoewel ik een grenzeloos vertrouwen heb in Linux, heb ik dat niet in de machines waarop het draait: de voedingen, netwerkverbindingen, insteekkaarten enz. En ik ben altijd bang dat, mocht er iets stuk gaan, ik word opgezadeld met een instabiel systeem. Gevolg is dat de applicatie niet beschikbaar is, en bovendien een aantal andere applicaties binnen het bedrijf, hoewel deze applicaties waarschijnlijk niet direct iets met de mijne te maken hebben. Bijvoorbeeld:

Een applicatie waar ik niets van wist en ik ook niets mee van doen heb, begint zich te misdragen omdat het het domein billingSys106.company.com niet meer kan vinden. Hmmmm, wat kan daarvan de oorzaak zijn? Oh ja, ik had het beheer van DNS en had besloten, tegen de bedrijfsreglementen in, om dit op Linux te doen. :)
Of iemand kan SAP niet meer gebruiken omdat LDAP plat ligt. Wacht eens even, heb ik niet drie maanden lang gepleit om het inloggen in SAP via LDAP af te handelen?
Of een aantal zeurpieten kunnen niet op hun Windows PC inloggen. Hoho, er is een Unix doos plat, wat gaat dat NT aan? Oh ja, toen niemand even keek heb ik vlug het NT domeinbeheer onder Linux en Samba gebracht met authenticatie via LDAP.

Exact hetzelfde overkomt natuurlijk een Windows Server maar daar maakt men zich niet echt druk om, de druiloren zijn er tenslotte aan gewend. Maar wees gewaarschuwd; als dit een Linux-doos overkomt dan vliegen de opmerkingen in de trant van "Dat Linux is toch nooit echt betrouwbaar geweest" je vanuit het hogere echelon om de oren.

In één van de bedrijven waar ik heb gewerkt stelde de NFS Server data beschikbaar aan de bedrijfs-webserver, de Intranet server, de database server en talloze andere applicaties die het bedrijf kunnen stilleggen.
De keuze voor het gebruik van NFS is natuurlijk een slechte maar laten we dit even terzijde in het belang van het voorbeeld.
De Server werd een hoge beschikbaarheid gegeven via een peperdure Sun cluster-oplossing.
Een andere belangrijke applicatie was het Intranet wat door meer dan 1500 mensen werd gebruikt.

Laten we dit concept nu eens in detail gaan bekijken.

Wat is hoge beschikbaarheid?

Precies wat het zegt. "Iets wat bijna altijd beschikbaar is". Ook bekend als high availability.

Voorbeelden van belangrijke applicaties die het bedrijf gaande houden:

Intranet server
Bestandsserver
Mail server
DNS

Het niet beschikbaar zijn van dergelijke applicaties kan twee oorzaken hebben:

De software misdraagt zich
De hardware misdraagt zich

Het hogere management is erg voorzichtig als het gaat om falende hardware. Iedere machine wordt besteld met dubbele voeding, RAID 5 opslagsystemen enz. Waar men vaak aan voorbij gaat is falende software.
Geloof het of niet, ik heb Linux-dozen zien bevriezen door onverwachte problemen met netwerkkaarten, oververhitte processoren enz.

De grote baas wil niet weten of er sprake is van een kapotte voeding of een falende netwerkkaart.
Het enige wat je baas, je collegae en klanten interesseert is dat de "applicatie" beschikbaar is. Merk hierbij op dat ik "applicatie" vet heb gedrukt.
Deze draait natuurlijk op een machine en het overzetten van een dergelijke applicatie met het bijhorende dataverkeer is waar het allemaal om draait bij hoge beschikbaarheid.

Toepassingsvoorbeelden van beschikbaarheid

In dit voorbeeld gaan we een cluster maken met een actieve en passieve machine waarop een Apache server draait voor het Intranet.
Voor het maken van dit kleine cluster gebruiken we een dikke machine met veel geheugen en processoren en een tweede goedkope machine met nét genoeg geheugen en processorkracht om de applicatie te laten draaien.
De eerste machine wordt de master node (primaire machine), de tweede de backup node (reserve machine).
De taak van de backup node is om de applicatie te gaan draaien en daarmee de functie over te nemen zodra hij denkt dat de master node niet meer reageert.

Hoe gaat dat in zijn werk?

Laten we eens nagaan hoe een gebruiker het Intranet benadert.

Zij tikt http://intranet in in haar bladerprogramma en de DNS applicatie verwijst dit door naar adres 10.0.0.100 (voorbeeld IP-adres).

Wat dacht je ervan om de twee machines met een verschillend IP-adres uit te rusten en gewoon de DNS applicatie te vragen om het tweede adres te gebruiken als de master node plat gaat?
Het is zeker een optie maar er spelen subtielere problemen zoals DNS caching op machines van gebruikers en wellicht wil je deze applicatie zélf wel een hoge beschikbaarheid op het cluster geven.
Een andere mogelijkheid is dat de backup node (of slave node) het IP-adres overneemt van de master node wanneer deze plat gaat en begint met het verlenen van de service. Dit heet IP takeover (IP adresovername) en dit is de methode die we zullen gebruiken in onze voorbeelden.
Men zal dus nog steeds http://intranet benaderen, wat wordt vertaald naar 10.0.0.100, óók als de master node plat gaat en zónder de instellingen van DNS te wijzigen.

Hoe communiceren clusters?

Hoe kan een machine in het cluster weten dat een andere plat is gegaan? Ze staan in nauw contact met elkaar via een seriële kabel én een Ethernet verbinding (ook hier meer hardware dan strikt noodzakelijk, de seriële verbinding zou het kunnen begeven óf de netwerkverbinding) en controleren elkaars hartslag (Jazeker, dezelfde hartslag als die van jou). Als je hart stopt met kloppen dan ben je waarschijnlijk dood. Het programma om de hartslag binnen een cluster te controleren heet... drie keer raden... "heartbeat" en is van het net te halen bij http://www.linux-ha.org/download/.
Het programma voor IP takeover heet fake en is inbegrepen bij heartbeat.

Indien je geen extra netwerkkaart ter beschikking hebt voor de beide machines dan kan het ook via alleen de seriële kabel (null modem). Netwerkkaarten zijn echter goedkoop dus het is aan te bevelen om deze extra aanschaf toch te doen.

De cluster machines prepareren

Zoals gezegd zullen we een Ferrari-PC gebruiken en een 2CV-PC. Beide machines hebben twee netwerkkaarten en tenminste één seriële poort. Verdere benodigdheden zijn een cross link cat 5 RJ45 (Ethernet) kabel en een null modem (cross link seriële kabel).

De eerste netwerkkaart op beide machines gebruiken we voor de toegang tot het Internet (eth0), de twee secundaire (eth1) kaarten vormen het privé-netwerk voor het heartbeat (udp-)verkeer tussen de nodes.

Beide machines krijgen hun IP-adressen en namen, bijvoorbeeld op eth0 op beide machines:
clustnode1 met IP-adres 10.0.0.1
clustnode2 met IP-adres 10.0.0.2

Vervolgens reserveren we een verhuisadres (waar we het al eerder over hebben gehad), te weten 10.0.0.100 (Intranet). Deze hoeven we nu nog niet aan een machine toe te wijzen.

Ook de tweede kaart moet voor beide machines worden geconfigureerd. Gebruik hiervoor willekeurige andere IP-adressen die nog niet in gebruik zijn. Voor beide machines bijvoorbeeld op eth1 met het masker 255.255.255.0:
clustnode1 met IP-adres 192.168.1.1
clustnode2 met IP-adres 192.168.1.2

Vervolgens sluiten we de seriële kabel aan op poort 1 of 2 van de machines en vergewissen ons ervan dat ze zo met elkaar kunnen communiceren (het is aan te raden op beide machines dezelfde poort te gebruiken, dat is makkelijker). Zie ook: http://www.linux-ha.org/download/GettingStarted.html

`heartbeat` installeren

Installeren hiervan is eenvoudig, het is beschikbaar in rpm-formaat (binair) of in .tar.gz-formaat (broncode).
Als je problemen hebt met het installeren hiervan dan is het wellicht af te raden om überhaupt een cluster te gaan bouwen (hoog beschikbaar wordt dan waarschijnlijk niet beschikbaar). Er is een prima beschrijving Getting Started with Linux-HA op het net te verkrijgen dus dat ga ik hier niet herhalen.

Configureren van het cluster

Configureer heartbeat:

Wijzig het bestand /etc/ha.d/authkeys indien de configuratiebestanden in /etc/ha.d staan volgens onderstaand voorbeeld:

#/etc/ha.d/authkeys
auth 1
1 crc
#end /etc/ha.d/authkeys

Later kun je md5 of sha gebruiken voor de verificatie wanneer je een beetje gewend bent maar laat deze voor nu maar even op 1 staan.

Wijzig /etc/ha.d/ha.cf als volgt:

debugfile /var/log/ha-debug
logfile /var/log/ha-log
logfacility     local0
deadtime 10
serial  /dev/ttyS3  # wijzig in juiste poort en haal dit commentaar weg
udp     eth1        # verwijder deze regel als je geen tweede netwerkkaart gebruikt
node    clustnode1
node    clustnode2

Wijzig /etc/ha.d/haresources als volgt:

#masternode ip-address service-name
clustnode1 10.0.0.100 httpd

Hierin staat nu dat de master node clustnode1 is. Wanneer deze plat gaat zal clustnode2 het overnemen, totdat clustnode1 weer in de lucht komt. Daarom gebruiken we een goede en een minder goede machine (clustnode1 is de goede machine).

Het tweede woord geeft het IP-adres wat over moet worden genomen en het derde geeft de naam van de over te nemen applicatie.
Als de eerste machine de applicatie weer terugneemt zal deze proberen

$ /etc/ha.d/httpd start

uit te voeren en als het deze niet kan vinden zal het

$ /etc/rc.d/init.d/httpd start

proberen uit te voeren.

Idem als de tweede machine de applicatie weer wil teruggeven zal geprobeerd worden

$ /etc/ha.d/httpd stop

uit te voeren. Indien het bestand niet wordt gevonden zal het op zoek gaan naar

$ /etc/rc.d/init.d/httpd stop

Wanneer je klaar bent met het configureren op clustnode1 kun je de configuratiebestanden naar clustnode2 kopiëren.
In /etc/ha.d/rc.d staat een script ip-request die het toekennen van IP-adressen enz. voor zijn rekening neemt.
Start nu /etc/rc.d/init.d/heartbeat op beide machines. Maak verschillende index-pagina's aan op de machines voor de httpd server. Bijvoorbeeld op clustnode1:

$ echo hallo, dit is clustnode1 >/jouWwwDocRoot/index.html

en op clustnode2:

$ echo hallo, dit is clustnode2 >/jouWwwDocRoot/index.html

Vergewis je ervan dat op beide machines httpd niet standaard wordt aangeroepen tijdens opstarten. Verwijder links uit de rc.N directories of, nog beter, verplaats het httpd of apache opstartscript van /etc/rc.d/init.d naar /etc/ha.d/rc.d.

Als alles correct is ingesteld en heartbeat actief is dan zal clustnode1 het adres 10.0.0.100 hebben en zal het reageren op verzoeken tot httpd toegang. Probeer het een aantal keren en verifieer de werking. Als alles goed lijkt te functioneren, stop dan clustnode1 en binnen 10 seconden zal clustnode2 de applicatie en het IP-adres over nemen. De applicatie is dus maximaal 10 seconden niet beschikbaar.

Hoe zit het met data-opslag?

Als httpd wordt overgenomen vanaf machine 1 naar machine 2 dan verlies ik alle data die ik met mijn CGI-scripts heb aangemaakt.

Twee oplossingen:
1. Schrijf nooit naar lokale bestanden vanuit CGI's (gebruik in plaats daarvan een netwerkdatabase. MySQL is aan te bevelen).
2. Je kunt de twee machines aan centrale SCSI-opslag koppelen. Doe het zó dat je zeker weet dat de twee machines de opslag nooit tegelijk benaderen en zorg er ook voor dat de SCSI- identificatie op de kaart van beide machines niet dezelfde is (bijvoorbeeld een machine met identificatie 6 en de andere met 7).

Ik heb dit uitgeprobeerd met Adaptec 2940 SCSI kaarten die je de mogelijkheid geven de identificatie te veranderen. De meeste goedkope kaarten hebben die mogelijkheid niet.
Sommige RAID-controllers worden verkocht als zijnde "cluster-bewust" maar vergewis je ervan dat je de HOST-ID hiervan kunt veranderen zonder dat je de Microsoft cluster kit hoeft te kopen.
Ik had twee NetRaid controllers van HP en deze ondersteunen Linux zeker niet. Ik heb ze maar gemold om toch nog enig "waar voor m'n geld"- gevoel te krijgen.

De volgende stap is om Fibrechannel (via glasvezel dus) kaarten te kopen, tezamen met een Fibrechannel hub en Fibrechannel opslag om zo een klein SAN (Storage Area Network) te bouwen. Dit is uiteraard duurder dan gedeelde SCSI maar een goede investering.
Hier overheen kun je GFS (Global File System, zie ook de referenties) draaien die toegang geeft tot opslag voor alle machines als ware het een lokale schijf.

Op dit moment gebruiken we GFS in een productie-omgeving met 8 machines waarvan 2 geconfigureerd voor hoge beschikbaarheid zoals boven beschreven.

Hoe zit dat met een cluster van gelijkwaardige machines?

Dat is eenvoudig in elkaar te zetten als je ook beschikt over een opslagsysteem wat parallelle toegang toelaat (zoals Fibrechannel en GFS). Als je met NFS al tevreden bent is dat ook prima maar ik raad het niet aan.

Hoe dan ook, je kunt dan serviceA aan clustnode1 toewijzen en serviceB aan clustnode2. Een voorbeeld van mijn haresources bestand:

clustnode2 172.23.2.13 mysql
clustnode1 172.23.2.14 ldap
clustnode2 172.23.2.15 cyrus

Ik gebruik GFS voor de opslag dus ik heb geen problemen met parallelle schijftoegang en kan dus zoveel applicaties op de machines draaien als ze aan kunnen.
clustnode2 is in dit geval de master node voor mysql en cyrus, terwijl clustnode1 de master node is voor ldap. In het geval van een crash zullen ze elkaars applicaties over nemen.

Referenties

Linux-HA.org: De site van hoge beschikbaarheid voor Linux
kimberlite clustering technology: Een KimberLite Cluster ondersteunt cluster configuraties van twee gelijkwaardige machines met gedeelde SCSI-opslag of Fibrechannel opslag. De software detecteert wanneer een machine uit het cluster valt en zal automatisch herstel-scripts starten voor overname van applicaties op de andere machine. Wanneer de machine terugkeert in het cluster kan handmatig of automatisch de applicatie terug worden gezet indien gewenst. Voorbeeld-scripts worden meegeleverd
ultra monkey: Ultra Monkey is een project voor het realiseren van hoog beschikbare clusters met werkverdeling op een lolaal netwerk via open source software op Linux. Op dit moment concentreert men zich op een schaalbaar en hoog beschikbare webkudde (web farm). Deze techniek is eenvoudig uit te breiden naar andere applicaties zoals email en FTP.
Linux Virtual Server: De Linux Virtual Server is een zeer schaalbare, hoog beschikbare server, gebaseerd op een cluster van meerdere machines, waarbij de werkverdeler op Linux draait. Hoe het cluster in elkaar zit is transparant voor de gebruiker. Gebruikers zien slechts de ene server.
4U cluster / 4U SAN (schaamteloze reclame): 4U cluster en 4U SAN is een clusterimplementatie van ons bedrijf 4Unet.
Als je een ISP bent of telecommunicatiebedrijf en je hebt behoefte aan hoog beschikbare oplossingen dan is 4Unet het juiste bedrijf om bij aan te kloppen. Let wel, 4Unet verkoopt oplossingen, geen systemen of clusters. Deze worden voor de klanten geïmplementeerd. De technieken die hierbij worden gebruikt zijn allemaal gebaseerd op open source. 4Unet bedient alleen ISP's en telecommunicatiebedrijven.
Global File System: Het Global File System (GFS) is een opslagsysteem met schijfclusters voor parallelle toegang vanaf meerdere Linux systemen. GFS ondersteunt journalling en herstellen bij uitvallen van clients. GFS cluster machines delen de toegang naar dezelfde schijven via glasvezel of via gedeelde SCSI. Het bestandssysteem lijkt voor iedere machine alsof het lokale opslag is, waarbij GFS de toegang tot de schijven regelt voor het gehele cluster. GFS is geheel symmetrisch, wat betekent dat alle machines gelijk worden behandeld en dat een server geen obstakel mag vormen voor andere machines. GFS gebruikt hiervoor caching van lees- en schrijfoperaties waarbij volledig het gedrag van een Unix bestandssysteem wordt gehandhaafd.