Kurztipp: Pacemaker und Ubuntu

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.

Kurztipp: Pacemaker nach Update auf Ubuntu 16.04

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" 

 

von 12.04 zu 14.04 und von MySQL 5.5 zu 5.6

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“

 

 

Notiz: Pacemaker resource disable migration

$ 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

Pacemaker – Nodes sehen sich nicht nach IP takeover

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

Mulitcasting Pacemaker

„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

 

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.

Linux Cluster Management Console

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