Hochverfügbarkeit mit Pacemaker und Corosync
Einleitung: Hochverfügbarkeit mit Pacemaker und Corosync
Mit Pacemaker und Corosync können mehrere Linux-Hosts eine einfache Form der Hochverfügbarkeit (engl. High availability, kurz HA) erreichen. So können mit Pacemaker IP-Adresse, ganze Webserver oder auch File-Systeme hoch-verfügbar gemacht werden.
Anhand einer so genannten Service-IP-Adresse beschreiben wir nachfolgend das Prinzip von Pacemaker und Corosync. Pacemaker übernimmt dabei die Verwaltung der Cluster-Resourcen. Corosync kümmert sich um die Kommunikation zwischen den Hosts.
Auf diese Weise lassen sich zum Beispiel mit einer Master-Master-Replikation von mariadb/mysql hochverfügbare Datenbank-Lösungen erstellen. Mit der OpenSource-Software glusterfs lassen sich zusammen mit Pacemaker und Corosync ganze Dateisysteme als HA-Lösung konfigurieren.
Alle nachfolgend genutzten Software-Pakete (Centos, Pacemaker und Corosnyc) sind genauso wie maysql und mariadb OpenSource Produkte.
Versuchsaufbau für Corosync und HA
Für unser nachfolgendes Tutorial erstellen wir zwei identische Linux-Hosts mit CentOS die jeweils einen Netzwerkanschluss sowie eine eigene statische IPv4-Adresse im selben IP-Subnetz haben. Die Linux-Rechner sollen anschließend eine dritte IP-Adresse (nachfolgend Service-IP genannt) erhalten, die entweder auf dem einen oder dem anderen Linux-Server „gehostet“ wird.
Ziel ist es, diese Service-IP-Adresse immer erreichbar zu haben und dennoch einen der beiden Hosts für Wartungszwecke herunter fahren zu können. Auf diese Weise kann mit einfachen Mitteln eine einfache Form der Hochverfügbarkeit erreicht werden.
Hinweis: Auch wenn wir Pacemaker und Corosync hier exemplarisch unter Centos 7 einrichten, so geht das natürlich auch auf anderen Linux-Distributionen wie debian, Ubuntu oder Redhat . Hier unterscheiden sich lediglich die Kommandos für die Installation der Pakete (apt-get bei debian).
Unser Setup für das Pacemaker Tutorial:
- 2 CentOS 7.5 Hosts mit je einer statischen IP-Adresse
- Host 1: testdb01, 168.0.113
- Host 2: testdb02, 168.0.114
- Service-IP-Adresse: 168.0.115
Für alles weitere installieren wir CentOS 7.x (z.B. auf einer Vitualisierungsplattform wie VMWare oder Proxmox). Die Linux-Hosts benötigen im produktiven Betrieb 1-2 CPU-Kerne, 2 GB RAM und 20 -30 GB an Festplatte. Wer einfach nur testen will, kommt auch mit einem CPU-Kern, 1 GB RAM und 3-4 GB HDD aus.
Wir richten pro Host die statische IP-Adresse ein und lassen mit „yum-y update“ alle Updates durchlaufen. Für alles weitere deaktivieren wir den CentOS Firewalld (systemctl disable firewalld) und deaktivieren „selinux“ ( In der Datei /etc/sysconfig/selinux ersetzen Sie das die Zeile, die mit „SELINUX“ beginnt durch SELINUX=disabled )
Installation von Corosync bzw. Pacemaker
Die Softwarepakete pacemaker, pcs und corosync müssen unter Centos auf allen Hosts installiert werden die später Mitglieder des Clusters werden. Die Installation erledigen wir mit:
1 | yum -y install pacemaker pcs |
In der Standard-Version werden hier gleich ca 25-30 weitere anhängige Pakete mit installiert, die für den Betrieb notwendig sind. Im Anschluss daran aktivieren wir den pcsd Dienst und starten ihn:
1 2 | systemctl enable pcsd.service systemctl start pcsd.service |
Damit die unterschiedlichen Hosts bzw. die Dienste auf den Hosts mit einander sprechen können, benötigen Sie einen Benutzer mit Kennwort. Während der Installation wird automatisch ein neuer User namens „hacluster“ angelegt: Diesem geben wir nun noch ein Passwort:
1 | passwd hacluster |
Achten Sie darauf, daß auf beiden Hosts das Passwort für den benutzer „hacluster“ nach Möglichkeit identisch ist
Cluster Dienst einrichten
Damit die Knoten miteinander kommunizieren können, tauschen wir nun erst einmal die Authentifizierungen aus:
1 2 3 4 5 | [root@testdb01 mysql<strong>]# pcs cluster auth testdb01 testdb02</strong> Username: hacluster Password: testdb01: Authorized testdb02: Authorized |
Die Meldung von beiden Knoten muss “Authorized” lauten – dann kommunizieren die Hosts erfolgreich miteinander.
Cluster – alte Pacemaker Konfiguration löschen
Zur Sicherheit „zerstören“ bzw. löschen wir alle bisherigen Konfigurationen auf den beiden Hosts.
Hinweis: Bei einer brandneuen Installation ist dieser Schritt nicht nötig.
1 2 3 4 5 6 | [root@testdb01 mysql]# pcs cluster destroy --all Warning: Unable to load CIB to get guest and remote nodes from it, those nodes will not be deconfigured. testdb01: Stopping Cluster (pacemaker)... testdb02: Stopping Cluster (pacemaker)... testdb02: Successfully destroyed cluster testdb01: Successfully destroyed cluster |
Neues Pacemaker Cluster erstellen.
Nun erstellen wir in neues “Cluster” aus zwei Knoten bzw. Hosts. Die Hosts heißen bei uns „testdb01“ und „testdb02“. Das Cluster selbst nennen wir „testdb. Direkt nach dem Abschicken des Befehls „pcs cluster setup“ werden zuerst die Zertifikate ausgetauscht.
Voraussetzung ist, daß die beiden Hosts sich im vorherigen Schritt (pcs cluster auth) erfolgreich gegenseitig authentifiziert haben.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | [root@testdb01 ~]# pcs cluster setup --name testdb testdb01 testdb02 Destroying cluster on nodes: testdb01, testdb02... testdb02: Stopping Cluster (pacemaker)... testdb01: Stopping Cluster (pacemaker)... testdb01: Successfully destroyed cluster testdb02: Successfully destroyed cluster Sending 'pacemaker_remote authkey' to 'testdb01', 'testdb02' testdb01: successful distribution of the file 'pacemaker_remote authkey' testdb02: successful distribution of the file 'pacemaker_remote authkey' Sending cluster config files to the nodes... testdb01: Succeeded testdb02: Succeeded Synchronizing pcsd certificates on nodes testdb01, testdb02... testdb01: Success testdb02: Success Restarting pcsd on the nodes in order to reload the certificates... testdb01: Success testdb02: Success |
Konfiguration von Corosync prüfen:
Zur Sicherheit werfen wir einen Blick in die nun auf beiden Hosts vorhandene Konfig-Datei unter /etc/corosync/. Sie heißt dort „corosync.conf“
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 | [root@testdb01 ~]# more /etc/corosync/corosync.conf totem { version: 2 cluster_name: filecluster secauth: off transport: udpu } nodelist { node { ring0_addr: testdb01 nodeid: 1 } node { ring0_addr: testdb02 nodeid: 2 } } quorum { provider: corosync_votequorum two_node: 1 } logging { to_logfile: yes logfile: /var/log/cluster/corosync.log to_syslog: yes } |
Corosync Cluster starten
Mit dem Befehlt “pcs cluster start –all” starten wir auf einem Knoten corosync auf allen zum Cluster gehörenden Hosts.
Wichtig: Das muss nur an auf einem Host/Knoten erfolgen.
1 2 3 | [root@testdb01 ~]# pcs cluster start --all testdb02: Starting Cluster... testdb01: Starting Cluster... |
Corosync und Pacemaker aktivieren und starten
Damit wir nun etwas Praktisches tun können, müssen sowohl der corosync-Dienst als auch Pacemaker aktiviert und gestartet werden.
Auf testdb01 und testdb02 führen wir also aus
1 2 3 4 | systemctl enable corosync.service systemctl start corosync.service systemctl enable pacemaker.service service pacemaker start |
Anschließend prüfen wir den Status mit “pcs status“. Nun sollte ‚pcs status‘ etwas sinnvolles ausgeben , auch wenn noch keine Resource vorhanden ist
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | [root@testdb01 ~]# pcs status Cluster name: testdb Stack: corosync Current DC: testdb01 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum Last updated: Wed Jun 13 12:50:58 2018 Last change: Wed Jun 13 12:50:55 2018 by root via cibadmin on testdb01 2 nodes configured resources configured Online: [ testdb01 testdb02 ] No resources Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled |
Wir sehen: Auf dem Knoten testdb01 sind alle drei Dienste (corosync, pacemaker und pcsd) aktiv und gestartet. Der Hinweis „no resources“ bedeutet, daß wir noch keine Resource (etwa eine IP) definiert haben.
Corosync anpassen (2 Host Szenario)
In unserem Fall von 2 Hosts mach weder ein Quorum (die Mehrheit unter den Servern) noch Stonith (Mechanismus zum „Abschiessen“ von schwächelnden Hosts) inhaltlich Sinn. Für ein Quorum bräuchten wir mindestens 3 Hosts. Mit den beiden folgenden Befehlen stellen wir sowohl das Quorum als auch stonith dauerhaft ab.
1 2 | pcs property set stonith-enabled=false pcs property set no-quorum-policy=ignore |
Virtuelle Resource / Virtuelle IP anlegen
Wir möchten nun eine einfache IPv4-Adresse als einzige Resource anlegen und auf einem der beiden Hosts verfügbar machen. Mit dem folgenden Befehl wird die Service-IP für das Cluster angelegt:
1 | pcs resource create <Resource-Name> ocf:heartbeat:IPaddr2 ip=<IP-Addr> cidr_netmask=<Netmask> op monitor interval=5s |
Die Variable <Resource-Name>, <IP-Addresse> und <Netmask> ersetzen wir natürlich durch die tatsächlichen Werte.
Wichtig hierbei: Die IP-Adresse muss zum Netzwerk bzw. IP-Subnetz passen, in dem der Hosts seinen Netzwerkanschluss hat.
Wir legen nun also eine zusätzliche IP-Adresse mit dem Namen „testdb-ip“, der Nummer 192.168.0.115 sowie der Netzmaske 24 (entspricht 255.255.255.0) an, die entweder auf testdb01 oder auf testdb02 gehostet wird. Sie soll außerdem vom Cluster alle 5 Sekunden geprüft werden.
1 | [root@testdb01 ~]# pcs resource create testdb-ip ocf:heartbeat:IPaddr2 ip=192.168.0.115 cidr_netmask=24 op monitor interval=5s |
Anschließend prüfen wir ob die IP-Adresse auch erfolgreich vom Cluster verwaltet wird:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 | [root@testdb01 ~]# pcs status Cluster name: testdb Stack: corosync Current DC: testdb01 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum Last updated: Wed Jun 13 12:52:35 2018 Last change: Wed Jun 13 12:52:32 2018 by root via cibadmin on testdb01 2 nodes configured <strong>1 resource configured</strong> Online: [ testdb01 testdb02 ] Full list of resources: testdb-ip (ocf::heartbeat:IPaddr2): Starting testdb01 Daemon Status: corosync: active/enabled pacemaker: active/enabled pcsd: active/enabled |
Ergebnis: Die Resource “testdb-ip” startet direkt auf dem Host testdb01
Nun prüfen wir noch am Adapter nach, ob dort ebenfalls die Service-IP vorhanden ist:
1 2 3 4 5 6 7 8 9 10 | [root@testdb01 ~]# ip addr (..) 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000 link/ether 76:f3:cc:53:fa:6b brd ff:ff:ff:ff:ff:ff inet 192.168.0.113/24 brd 192.168.0.255 scope global noprefixroute eth0 valid_lft forever preferred_lft forever inet <strong>192.168.0.115/24</strong> brd 192.168.0.255 scope global secondary eth0 valid_lft forever preferred_lft forever inet6 fe80::3522:f3f3:80cd:7aae/64 scope <a class="wpil_keyword_link" href="https://www.biteno.de/was-ist-ein-hyperlink/" title="link" data-wpil-keyword-link="linked">link</a> noprefixroute valid_lft forever preferred_lft forever |
Ergebnis: Der Netzwerkadapter eth0 hat zusätzlich zu seiner festen IP (192.168.0.113) noch die IP-Adresse 192.168.0.115 die wir vorher als Cluster-Reosurce erstellt haben.
Empfehlung: Um im Fehlerfall die Konfiguration von Pacemaker bzw. Corosync schnell wieder anlegen zu können, empfiehlt es sich auf einem der beiden Linux-Hosts die Befehle vom Anlegen des Clusters bis hin zu Einrichtung der Cluster-Resource(n) in einer Bash-Datei abzuspeichern.
Damit kann im Fehlerfall durch einfaches Löschen und neu Anlegen der Konfiguration sowie der Resourcen in 20 bis 30 Sekunden eine Cluster-Einrichtung erfolgen.
Verwaltung von Corosync / Pacemaker
Cluster-Resourcen manuell verschieben.
In der Praxis wechselt die IP-Adresse nur dann von einem Host, wenn der aktive Host herunter fährt oder der Corosync-Dienst angehalten wird. Möchte man die Cluster-Resource von Hand von einem Host auf den anderen verschieben, so geht das mit:
pcs resource move <resource-name> <nodename>
Beispiel:
1 | pcs resource move testdb-ip testdb02 |
Cluster-Resource entfernen
So wie eine Cluster-Resource angelegt wird, so kann sie natürlich auch gelöscht bzw. entfernt werden:
Syntax: pcs resource delete <Resource-Name>
Bsp.:
1 | pcs resource delete testdb-ip |
Fehler / Troubleshooting von Corosync / Pacemaker /pcsd
Sofern immer ein Host online ist, sind Fehler bei Corosync/Pacemaker eher selten. Wenn doch einmal etwas nicht geht, dann empfiehlt sich folgende Vorgehensweise:
Dienste (Pacemaker/Corosync/pcsd) stoppen und neu starten
Alle relevanten Dienste stoppen:
1 | service corosync stop; service pacemaker stop; service pcsd stop; |
Alle relevanten Dienste starten:
1 | service pcsd start; service pacemaker start; service corosync start; |
Danach ermitteln Sie auf beiden Hosts einzeln mit “pcs status” ob die Hosts sich gegenseitig als “online” sehen und ob die Cluster-Resource(n) vorhanden sind.
Die harte Tour: Konfig neu anlegen.
Für den unwahrscheinlichen Fall, dass ein Fehler hartnäckiger ist, kann aus Zeitgründen die Konfiguration auch kurzerhandgelöscht und neu gestartet werden.
Dazu stoppen Sie auf beiden Hosts alle Dienste und löschen anschließend die Konfigurationsdateien auf beiden Hosts. Danach legen Sie die Konfiguration (wie oben beschrieben) neu an.
Das ist in vielen Fällen einfacher und vor allem schneller als eine langwierige Fehlersuche.
Vorgehen:
1 2 3 4 5 6 | # Dienste stoppen service corosync stop; service pacemaker stop; service pcsd stop; # Konfig Dateien löschen /etc/corosync/corosync.conf löschen /etc/pacemaker -> Dateien löschen. #Ggf. Dienste deaktivieren |
Danach noch mal neu aufsetzen wie oben beschrieben. (geht in der Regel schneller als eine lange Fehlersuche)
Weiterführende Infos
- http://clusterlabs.org/
- https://de.wikipedia.org/wiki/Corosync_Cluster_Engine
- https://de.wikipedia.org/wiki/Pacemaker
- glusterfs -> siehe separate Anleitung
- mariadb/mysql Master-Master-Setup
- Über den Autor
- Aktuelle Beiträge
Matthias Böhmichen ist Geschäftsführer des IT-Dienstleisters Biteno GmbH. Neben seinem Job blogt und schreibt er auf den Webseiten der Biteno GmbH über technische und unternehmerische Themen.
