Linux als server. High Availiability

Linux als server draait vaak services waarvan het belang binnen een organisatie groot is. Soms kan een downtijd van een paar minuten al in de duizenden euro’s lopen, of zelfs meer. Als dat voor jouw organisatie ook geldt, is het de moeite waard iets te doen met High Availability. In dit artikel lees je wat het is.

Zoals de naam al suggereert zorg je met High Availability (HA) voor een betere beschikbaarheid van kritische services. Dit doe je door naast de lokale service manager (meestal systemd) een tweede service manager toe te voegen in de vorm van de HA stack. Deze HA stack bestaat uit twee onderdelen: Corosync en Pacemaker. Samen zorgen deze onderdelen ervoor dat de beschikbaarheid van services in de gaten gehouden wordt, en dat actie wordt ondernomen als er iets niet goed gaat. Wat die actie precies inhoudt, kan ingesteld worden. Maar meestal komt het erop neer dat de service op een andere node in het cluster opnieuw gestart wordt, waardoor deze na een korte afwezigheid weer beschikbaar is om diensten te verlenen aan de clients.

Architectuur

In principe is het helemaal niet zo moeilijk om even een clustertje op te brengen. Als je het echter goed wilt doen, komt er nogal wat bij kijken om daadwerkelijk alle componenten redundant uit te voeren. Je moet er bijvoorbeeld voor zorgen dat de gegevens van de applicatie na een fail-over nog steeds beschikbaar zijn. Dat zou je kunnen doen door de gegevens regelmatig met rsync te synchroniseren, maar dat werkt alleen voor toepassingen die niet zo actief zijn. Als het gaat om applicaties die regelmatig of continu wijzigingen aanbrengen in hun gegevens, is het handig om shared storage in te zetten in de vorm van een SAN of NAS, en het cluster er zorg voor te laten dragen dat na een fail-over de toegang tot de storage mee migreert naar de andere node.

Een ander punt waar je rekening mee moet houden is wie er wint in geval van split brain. Dit is een situatie waarbij het cluster in tweeën gedeeld wordt door een of andere storing, en beide overblijvende delen denken dat ze het enige overgebleven deel van het cluster zijn en dus services moeten gaan aanbieden. Als dat tot gevolg heeft dat jouw database server vanaf twee nodes tegelijk naar hetzelfde bestandssysteem gaat schrijven, kan dat tot gevolg hebben dat er corruptie ontstaat en zit je aardig in de problemen. Om dergelijke problemen tegen te gaan moet het Quorum geconfigureerd worden, en daarnaast STONITH (Shoot The Other Node In The Head) devices, die ervoor zorgen dat falende nodes niet meer beschikbaar zijn.

Welk platform

Als je dan je basis architectuur een beetje in orde hebt, wordt het tijd om na te denken over de software die je wilt gaan gebruiken. Die is op moderne Linux-distributies in principe overal hetzelfde en bestaat uit Corosync en Pacemaker. Van deze twee onderdelen draagt Corosync zorg voor de membership layer, de laag die in de gaten houdt of alle nodes in het cluster nog beschikbaar zijn. Pacemaker is de service manager die in de gaten houdt of alle geclusterde services nog wel draaien en als dat nodig is deze services gaat migreren naar een andere  node.

Hoewel de componenten overal hetzelfde zijn, zijn er wel degelijk twee manieren van aanpak op de markt. Er is de SUSE manier, die op de meeste distributies gebruikt wordt, waarbij het cluster met ha-cluster-bootstrap opgebouwd wordt en vervolgens vanuit crmsh beheerd wordt. En er is de Red Hat manier, waarop dezelfde softwarecomponenten beheerd worden vanuit de pcs command line interface. In de rest van dit artikel lees je hoe je eenvoudig een cluster opzet op basis van de SUSE manier.

Je eerste eigen cluster

Omdat de ruimte beperkt is, zullen we het eenvoudig houden en ga je aan de hand van de instructies een High Available IP-adres opzetten op een 2 node cluster. Dat is niet spectaculair, maar laat wel zien hoe een HA cluster nu eigenlijk werkt. Om deze instructies uit te kunnen voeren, gaan we ervan uit dat je twee computers (of virtuele machines) geïnstalleerd hebt met SUSE Leap 42.2. Andere versies zullen waarschijnlijk ook werken, maar de werking daarvan kan niet gegarandeerd worden. Zorg er bij voorkeur voor dat deze twee machines een vast IP-adres hebben en dat ze elkaar kunnen pingen op basis van FQDN en korte hostnaam. Voer vervolgens de volgende stappen uit:

1.      Typ zypper in ha-cluster-bootstrap op beide nodes. Door installatie van dit package worden alle benodigde packages geïnstalleerd en kun je in de volgende stap op eenvoudige wijze je basis cluster aanmaken.

2.      Typ nu op één node ha-cluster-init. Dit commando zal het basis cluster voor je opzetten waarbij een aantal vragen gesteld wordt.

·         Network address to bind: dit is het netwerk dat door het cluster gebruikt zal worden. Zorg ervoor dat beide nodes op hetzelfde netwerk zitten.

·         Multicast address: de Corosync membership laag communiceert standaard door middel van multicast. Je kunt hier gewoon het standaardadres accepteren.

·         Configure SBD: in een echt cluster zou je absoluut SBD op willen zetten, omdat het de integriteit van je cluster zeer ten goede komt. Het heeft echter shared storage nodig, dus hier antwoord je ‘no’.

·         Configure Administration IP address: dit is een IP-adres dat door het cluster beheerd gaat worden. Maak dit aan, dan heb je namelijk gelijk ook je eerste hoog beschikbare service

3.      Nadat je alle vragen beantwoord hebt, wordt de cluster software geïnstalleerd en heb je een één-node cluster. Dit cluster kun je beheren door met een browser naar poort 7630 te gaan. Je krijgt dan toegang tot de Hawk console. Voordat het echter zo ver is, gaan we nu eerste de 2e node in het cluster hangen.

4.      Typ op de tweede node ha-cluster-join -c node1. Let op: gebruik in plaats van ‘node1’ de naam van de andere node. Dit commando zorgt ervoor dat de tweede node aan het cluster toegevoegd wordt.

Eerste stappen in het cluster

Nadat je de tweede node toegevoegd hebt, kun je controleren of alles naar behoren werkt. Typ nu op een van beide nodes de opdracht crm_mon. Dit toont je uitvoer als in figuur 1, waaruit blijkt dat het HA IP-adres werkt en er inderdaad een 2 node cluster is. 

Het is natuurlijk de bedoeling van je cluster dat de diensten die het aanbiedt ook inderdaad beschermd zijn door High Availability. Dit kun je doen door het cluster IP-adres te verwijderen met de opdracht ip addr del dev eth0 192.168.4.240 (wel even opletten dat je het juiste IP-adres gebruikt en dat ‘dev eth0’ verwijst naar de juiste netwerkkaart.) Typ nu een paar keer achter elkaar de opdracht ip a s, je zult zien dat eerst het IP-adres verwijderd was, maar dat het na een paar seconden ook weer automatisch terugkomt. Voldoende bewijs dat je High Availability cluster werkt!

Enthousiast geworden door je eerste eigen HA cluster? Dan is het een goed idee om de High Availability Web Konsole (HAWK) te benaderen op poort 7630. Daar mag je overigens het cluster IP-adres voor gebruiken. Je kunt in HAWK inloggen als gebruiker hacluster, nadat je daar een wachtwoord voor ingesteld hebt, en je wellicht eens wagen aan meer geavanceerde configuraties.