Galera Cluster mit Ubuntu 12.04 64bit und MySQL 5.5 – Teil 3 IP Failover

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.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.