Nun haben wir unseren 4 Node Mysql Galera Cluster (hier sollte man besser eine ungerade Zahl wählen, wegen des Quorum Problems). Wir haben auch einen Loadbalancer auf 2 VMs laufen. Nun wollen wir aber noch einen IP Failover haben, falls eine der LB VMs ausfällt, sei es geplant oder ungeplant. Pacemaker ist meiner Meinung nach ein fantastisches Stück Software. Basis Funktionen, wie IP Failover bekommt man relativ unkompliziert ans Laufen, will man jedoch etwas mehr, wird schnell klar, wie komplex Pacemaker/Corosync ist, aber auch welche sinnvollen Funktionen zur Verfügung stehen. Ich beschränke mich auf das Nötigste, weil ich 1. noch nicht mehr weiß und 2. es für mein Projekt vollkommen ausreicht. Die Links am Ende sollte man sich auf jeden Fall anschauen, ich verspreche es lohnt sich. Ich spare mir in die Tiefe zu gehen, da die angefügten Links eigentlich alles erklären und dies deutlich besser tun, als ich es hier kurz zusammenfassen kann.
Fangen wir also mit den Zutaten an:
- 3 IPs
- 2 Server minimum (lb1, lb2)
- Zeit
Nun gehen wir auf einen der Server, nehmen wir lb1:
aptitude install pacemaker
Danach passen wir /etc/corosync/corosync.conf an:
interface {
# The following values need to be set based on your environment
ringnumber: 0
bindnetaddr: 123.123.123.0
mcastaddr: 226.94.1.1
mcastport: 5405
}Wobei bindnetaddr ein Netz angibt und keine Rechneradresse. Danach führen wir
corosync-keygen
aus. Das dauert etwas und kann durch etwas i/o beschleunigt werden. Danach
chown root:root /etc/corosync/authkey chmod 400 /etc/corosync/authkey scp /etc/corosync/authkey lb2:/etc/corosync/authkey /etc/init.d/corosync start
Sollte corosync seltsamerweise nicht starten, hat bei mir bei ein reboot geholfen. Wo der Fehler dabei lag, kann ich nicht sagen. Schauen wir uns erst mal den aktuellen Zustand an
crm_mon --one-shot -V
Dabei sollte nicht viel erscheinen.
Legen wir also unsere erste Ressource an:
crm configure primitive FAILOVER-ADDR ocf:heartbeat:IPaddr2 params ip="123.123.123.123" nic="eth0" op monitor interval="10s" meta is-managed="true"
Wobei 123.123.123.123 hier die Cluster IP ist.
Stonit und Quorum brauchen wir bei zwei Hosts eigentlich nicht, besonders wenn beide Maschinen auf gleicher Hardware virtualisiert sind ;-).
crm configure property stonith-enabled=false crm configure property no-quorum-policy=ignore
Soll die IP automatisch wieder auf den aktiven Host zurückspringen oder beim aktuellen bleiben?
crm_attribute --type rsc_defaults --attr-name resource-stickiness --attr-value 100
default-resource-stickiness=100 ist vergleichbar mit autofailback=false. Default ist der Wert auf 0 gesetzt, bedeutet die Ressource, bei uns FAILOVER-ADDR, springt automatisch wieder auf den ursprünglichen Host zurück, sobald dieser verfügbar, bzw. Pacemaker gestartet ist.
Das Thema mit der Stickiness ist etwas komplexer, daher verweise ich auf diesen Link, wo der Punkt ausführlich erklärt wird. Der Punkt ist sehr wichtig, da man eventuell nicht immer will, dass die IP sofort wieder auf den Host zurückspringt der z. B. grad rebootet werden musste.
Verschiebt man die IP jedoch von Hand, setzt Pacemaker eine Location Regel für den jeweiligen Host
crm configure show ... location cli-prefer-FAILOVER-ADDR FAILOVER-ADDR \ rule $id="cli-prefer-rule-FAILOVER-ADDR" inf: #uname eq lb1 ...
Diese muss man dann von Hand wieder löschen. Ansonsten wird die Ressource wieder auf den node aus der Location Regel springen, wenn dieser verfügbar ist.
Ein
crm resource unmigrate FAILOVER-ADDR
Löscht die Location Regel.
Mit
crm configure show
können wir uns die Konfiguration anzeigen lassen. Und mit
crm_mon --one-shot -V
sehen wir den aktuellen Zustand unseres Pacemaker Systems
crm_mon --one-shot -V ============ Last updated: Fri Nov 2 14:09:16 2012 Last change: Mon Sep 10 13:34:26 2012 via crm_attribute on lb1 Stack: openais Current DC: lb1 - partition with quorum Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c 2 Nodes configured, 2 expected votes 2 Resources configured. ============ Online: [ lb1 lb2 ] Resource Group: Balancer FAILOVER-ADDR (ocf::heartbeat:IPaddr2): Started lb1 GLBD (lsb:glbd): Started lb1
Nun testen wir mit
crm resource migrate FAILOVER-ADDR lb2
Ob sich unsere Ressource verschieben lässt. Danach sollte in etwa folgendes erscheinen:
crm_mon --one-shot -V ============ Last updated: Fri Nov 2 14:15:16 2012 Last change: Fri Nov 2 14:15:12 2012 via crm_resource on lb1 Stack: openais Current DC: lb1galera - partition with quorum Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c 2 Nodes configured, 2 expected votes 2 Resources configured. ============ Online: [ lb1 lb2 ] Resource Group: Balancer FAILOVER-ADDR (ocf::heartbeat:IPaddr2): Started lb2 GLBD (lsb:glbd): Started lb2
Unsere FAILOVER-ADDR Ressource wurde also erfolgreich auf lb2 migriert. Mit dem Befehl
ip addr show
auf beiden Maschinen, können wir das nochmal unabhängig von Pacemaker überprüfen.
Dies GLBD, was erscheint, kann vorerst ignoriert werden. GLBD ist bei mir der MySQL Loadbalancer, der mit FAILOVER-ADDR zu der Gruppe „Balancer“ hinzugefügt wurde. Wie man den glbd Loadbalancer mit in das Konstrukt aufnimmt, schreibe ich dann hoffentlich in Teil 4 (Pacemaker, Loadbalancer und Nagios) .
Pacemaker bitte eine ganze Reihe von praktischen Befehlen, Funktionen und Möglichkeiten zum anpassen der Konfiguration. Ich spare mir das mal alles und verweise auf die Links am Ende und auf google.
Link zu Teil 1:
http://exdc.net/2012/08/15/galera-cluster-mit-ubuntu-12-04-64bit-und-mysql-5-5-teil-2-loadbalancerproxy/
Links, die man sich auf jeden Fall anschauen will:
http://earlruby.org/corosync-pacemaker-notes/
http://blog.foaa.de/2010/10/intro-to-pacemaker-on-heartbeat/
http://blog.foaa.de/2010/10/intro-to-pacemaker-part-2-advanced-topics/
http://www.clusterlabs.org/doc/en-US/Pacemaker/1.1/html/Pacemaker_Explained/
http://wiki.techstories.de/display/IT/Pacemaker+HA-Cluster+Schulung+GFU+Koeln
update:
glbd kann sich auch an jedes beliebige Interface binden. Dazu reicht es einfach nur den listening Port anzugeben oder 0.0.0.0:port.