Da ich diverse Nodes in letzter Zeit geupdatet habe, teile ich meine Erkenntnis für die eine Person.
14.04 mit 16.04 ist nicht kompatibel. Die Nodes sehen sich nicht.
16.04 mit 18.04 ist kompatibel. Ressourcen können hin und her migriert werden.
Bei 18.04 muss man noch die crm shell „crmsh“ nachinstallieren. Ansonsten ist das Pacemaker Update aber problemlos.
Da sich bei Ubuntu 16.04 auch die Namen der NICs ändern (z.B. von eth0 zu ens192) muss man auch die Konfiguration der Ressourcen anpassen. Das kann man sicherlich innerhalb der Konfiguration via crm anpassen, aber löschen der Ressource und neu anlegen geht natürlich auch. Was dann in etwa so ausieht:
crm resource stop FAILOVER-ADDR crm configure delete FAILOVER-ADDR crm configure primitive FAILOVER-ADDR ocf:heartbeat:IPaddr2 params ip="1.2.3.4" nic="ens192" op monitor interval="10s" meta is-managed="true"
Nur ein paar Notizen für mich für ein Update von Ubuntu 12.04 zu 14.04 und von MySQL 5.5 zu 5.6.
MySQL
table_cache gibt es bei MySQL 5.6 nicht mehr, das heißt nun table_open_cache. Am besten vorher in der my.cnf ändern
ln -s /etc/apparmor.d/usr.sbin.mysqld /etc/apparmor.d/disable
invoke-rc.d apparmor restart
schadet auch nicht.
Pacemaker
apt-get install haveged
braucht man
Pacemaker komplett löschen. Purgen reicht nicht
rm -rf /var/lib/pacemaker
rm -rf /var/lib/heartbeat
rm -rf /var/lib/pengine
Nachdem Update Pacemaker einfach neu installieren. Das sollte inklusive Konfiguration maximal 5 Minuten dauern. Eventuell kurz root via key zwischen den Nodes erlauben.
update-rc.d pacemaker defaults
kann auch nicht schaden
ssh
Match Blocks werden nicht mehr mit „Match“ geschlossen und müssen immer am Ende der sshd_config stehen. Eventuell hilft „Match all“
$ crm ra info pengine
...
is-managed-default (boolean, [true]):
Should the cluster start/stop resources as required
maintenance-mode (boolean, [false]):
Should the cluster monitor resources and start/stop them as required
Ein kleiner Unterschied, aber nur ein kleiner.
Damit setzen wir den Cluster in den Maintenance Mode:
$ crm configure property maintenance-mode=true
Link:
http://oss.clusterlabs.org/pipermail/pacemaker/2011-March/009429.html
Reset status und fail-count:
crm(live)resource# cleanup resource node
Grund war ein
„check_crm WARNING – : failover_ip failure detected, fail-count=1000000“
vom nagios plugin für Pacemaker. Eigentlich dachte ich, daß
crm configure rsc_defaults failure-timeout="10min"
reicht, damit der failcount nach 10 Minuten resetet wird, das hat aber leider nicht funktioniert.
Ein paar Informationen zur Umgebung und zu den Konfigurationsdateien:
Zwei nodes (lb1,lb2) via ESX virtualisiert. Jeweils nur ein Interface je node.
Meine alte corosync.conf:
...
interface {
ringnumber: 0
bindnetaddr: 192.168.1.0
mcastport: 5405
mcastaddr: 226.94.1.10
}
...Folgendes Problem:
Zwei nodes lb1 und lb2 und eine Ressource FAILOVER-ADDR (Cluster IP). Auf beiden läuft Pacemaker. Beide sehen sich und eigentlich sieht alles ok aus. Mache ich nun ein
lb1$ crm resource migrate FAILOVER-ADDR lb2
Wird FAILOVER-ADDR auf lb2 geschwenkt. Alles wunderbar, aber sobald die Aktion vollzogen ist sehen sich lb1 und lb2 nicht mehr via multicast. Ich habe nicht herausfinden können warum, falls jemand Ideen hat immer her damit.
lb1$ ping 226.94.1.10 64 bytes from 192.168.1.11: icmp_req=878 ttl=64 time=0.021 ms 64 bytes from 192.168.1.11: icmp_req=879 ttl=64 time=0.020 ms
wird nur noch von der IP des jeweiligen nodes beantwortet. Vor dem Schwenk tauchte dort noch richtigerweise die IP des anderen nodes auf.
lb1$ ping 226.94.1.10 64 bytes from 192.168.1.11: icmp_req=878 ttl=64 time=0.021 ms 64 bytes from 192.168.1.12: icmp_req=879 ttl=64 time=0.020 ms
Das ganze hat mich schon sehr (sehr) genervt.
Nun zur recht „einfachen“ Lösung.
Die corosync.conf wird folgendermaßen angepasst:
...
interface {
member {
memberaddr: 192.168.1.11
}
member {
memberaddr: 192.168.1.12
}
# The following values need to be set based on your environment
ringnumber: 0
bindnetaddr: 192.168.1.0
mcastport: 5405
}
transport: udpu
...ttl habe ich dabei extra nicht gesetzt. Multicast wird so nicht mehr genutzt und ein broadcast ins ganze Netz findet (hoffentlich) nicht statt. Seit den Anpassungen gab es keinerlei Probleme mehr mit schwenken von Ressourcen.
Notizen:
echo "0" > /proc/sys/net/ipv4/icmp_echo_ignore_broadcasts
nicht vergessen
„Wenn sich mehrere HA-Cluster im selben Netz befinden müssen die mulitcast-adressen und multicast-ports aller cluster/clustermember unterschiedlich sein.“
http://www.borgmann.tv/pages/startseite/linux-zeug/howto-linux-ha-cluster.php
The multicast addresses are in the range 224.0.0.0 through 239.255.255.255. Address assignments are listed below.
The range of addresses between 224.0.0.0 and 224.0.0.255, inclusive, is reserved for the use of routing protocols and other low-level topology discovery or maintenance protocols, such as gateway discovery and group membership reporting.
http://www.iana.org/assignments/multicast-addresses/multicast-addresses.xml
Links:
http://www.hastexo.com/resources/hints-and-kinks/whats-totem-retransmit-list-all-about-corosync
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:
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.
Für zwischendurch.
Linux Cluster Management Console is a GUI that helps to configure Pacemaker, DRBD and KVM clusters.
Damit ist eigentlich alles gesagt. Habe ich nicht zum Einrichten von Pacemaker genutzt, ist aber nett um sich das Ergebnis anzuschauen. Bei größeren Umgebungen, kann so ein Tool sicherlich sehr nützlich sein. Bei mir läuft auf den Nodes nur Pacemaker&co und glbd als MySQl Proxy. Bei der 1.3er Version war das Anlegen der Hosts nicht besonders intuitiv, vielleicht ist es bei der neuen 1.4er verbessert worden. DRBD ist natürlich nicht nötig, aber möglich.
httpvh://youtu.be/nEPn5RJA1Ig
p.s. damit teste ich auch gleich mal ob der osbn feed funktioniert