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.

Mehr zum Thema:
Was ist Ubuntu?

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 &lt;Resource-Name&gt; ocf:heartbeat:IPaddr2 ip=&lt;IP-Addr&gt; cidr_netmask=&lt;Netmask&gt; 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:

Mehr zum Thema:
Was ist Icinga?
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: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; 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.com/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 -&gt; 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