Was brauchen wir?
Wir benötigen zwei Knotenrechner (Nodes). Beide Server sind vollständig einsatzbereite Debian Server in der Minimalinstallation. Beide haben jeweils eine feste IP-Adresse und können sich gegenseitig erreichen.
Warum Pacemaker?
Das Problem an Heartbeat ist, dass es mit Systemd nicht richtig klar kommt. Es klemmt beim Starten/Stoppen von Diensten. Blöde ist, dass die Entwickler von Pacemaker im Tiefschlaf zu sein scheinen. Nachzulesen hier: https://wiki.debian.org/Debian-HA/FAQ
Diese Info ist seit Strech obsolet. In Debian 9 ist Pacemaker wieder dabei.
Was brauche ich?
Zwei funktionierende Nodes mit erfolgreicher und funktionierender Installation von DRBD. Die Replikation muss schon lauffähig sein!
Wie installiere ich Pacemaker?
Die Entwickler von Pacemaker haben wohl offensichtlich ihren Tiefschlaf und so ist das gute Stück Software aus den Quellen geflogen. Aber es ist immer noch über die Backports zu beziehen. Darum muss die /etc/apt/source.list um folgenden Eintrag erweitert werden:
deb http://http.debian.net/debian jessie-backports main
Danach Apt "updaten" und die Installation starten:
apt-get install -t jessie-backports libqb0 fence-agents pacemaker corosync pacemaker-cli-utils crmsh drbd-utils
Bei Stretch:
apt-get install libqb0 fence-agents pacemaker corosync pacemaker-cli-utils crmsh
Bei Jessie:
apt-get install -t jessie-backports libqb0 fence-agents pacemaker corosync pacemaker-cli-utils crmsh
Wie konfiguriere Corosync?
Die Konfiguration ist in der Datei /etc/corosync/corosync.conf zu machen. Den Inhalt der Originaldatei sollte sichern und eine neue leere Datei beginnen und mit folgendem Inhalt füllen:
totem {
version: 2
token: 3000
token_retransmits_before_loss_const: 10
clear_node_high_bit: yes
crypto_cipher: none
crypto_hash: none
transport: udpu
interface {
ringnumber: 0
bindnetaddr: 192.168.2.0
}
}
logging {
to_logfile: yes
logfile: /var/log/corosync/corosync.log
debug: off
timestamp: on
logger_subsys {
subsys: QUORUM
debug: off
}
}
quorum {
provider: corosync_votequorum
two_node: 1
wait_for_all: 1
}
nodelist {
node{
ring0_addr: 192.168.2.170
}
node{
ring0_addr: 192.168.2.171
}
}
Diese Datei nun auf den anderen Server übertragen.
Danach muss der Auth-Key erstellt werden. Eine ziemlich nervige Sache, wenn man das so macht wie die meisten Tutorials das vorschlagen. Das Problem: /dev/random generiert nicht von selbst Zufallswerte sondern nimmt Eingaben von Tastatur, Maus, IDE-Zeitwerte und weiß der Geier noch alles, um damit einen Zufallswert zu generieren. Das bedeutet also, dass Aktion von uns Verlangt wird.
Das wäre dann so:
Das kann man sich aber sparen, wenn man corosync-keygen -l (das ist ein L) verwendet. Es holt sich Zufallswerte aus dem Random Data Source. Ist aber ein wenig unsicherer. Jetzt liegt eine neue Datei (auth-key) unter /etc/corosync/.
Auch diese Datei nun auf den anderen Server übertragen.
Wenn also die corosync.conf und auth-key Datei erstellt und auch auf den anderen Server übertragen wurde, dann einfach Pacemaker und Corosync nacheinander neu starten. Begonnen wird mit Corosync.
service corosync start
service pacemaker start
Nun ein bisschen warten und dann folgende Zeile ausführen:
crm status (beide Nodes sollten nun drin sein.)
Wenn das gut geklappt hat, dann steht das Cluster. Beide Server sind miteinander verbunden. Allerdings wissen sie noch nichts mit sich anzufangen. Pacemaker weiß noch von keinen Diensten, die es starten/stoppen soll.
Kleines Cluster mit Apache:
Damit wir uns das selbst demonstrieren können und die Funktion erleben installieren wir jetzt einfachheithalber mal den Apache mit apt-get install apache2 -y
Wir testen auf beiden Nodes, ob der Apache die Apache-Testseite auch anzeigt. Ein http://hier.die.IP.Node1 sollte die Website des Server anzeigen. Ebenso bei Node2 ausprobieren.
Nun müssen wir dem Cluster Resource Manager (das ist Pacemaker nämlich) irgendwie erklären, dass ein Knoten aktiv ist und auf diesem bestimmte Dienste (Apache und Cluster-IP) gestartet werden sollen. Fällt dieser aktive Server (wird inaktiv) aus, dann wird der andere Knoten aktiv geschaltet und auf ihm die gewünschten Dienste (Apache und Cluster-IP) gestartet.
Pacemaker spricht immer von Resourcen. Jeder Dienst ist eine Resource. Um Pacemaker nun zu sagen was es tun soll, ist das CLI (Command Line Interface) "crm" zu verwenden.
root@server01# crm configure
property stonith-enabled=false
property no-quorum-policy=ignore
primitive failover-ip IPaddr params ip=192.168.2.199 op monitor interval=10s
primitive Apache ocf:heartbeat:apache params configfile=/etc/apache2/apache2.conf op monitor interval=1min
colocation WebServer-with-FO-IP inf: Apache failover-ip:Master
commit
Wir haben die Resource failover-ip und Apache angelegt und haben festgelegt, dass die Resource Apache da gestartet wird wo die Resource failover-ip gestartet wurde.
Ein "crm status" sollte aufschluss darüber geben auf welchem Knotenrechner gerade die Resourcen gestartet sind. Ein "ifconfig" müsste nun eine neue Netzwerkschnittstellt eth0:0 mit der Cluster-IP ausgeben.