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

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

Galera Cluster mit Ubuntu 12.04 64bit und MySQL 5.5 – Teil 2 Loadbalancer/Proxy

Nun da Galera mittlerweile auf vier Nodes läuft, wäre ein Loadbalancer eine gute Sache. HAProxy fand ich etwas zu mächtig für mein Anliegen, obwohl er  von vielen Benutzern als Option präferiert wird . Getestet habe ich mysql-proxy direkt von Mysql und glbd von Galera. Beides scheint größtenteils problemlos zu laufen. Bei einfachen Benchmarks, konnte ich bisher keine gravierenden Unterschiede erkennen, dazu aber mehr in Teil 4. Mysql-proxy ist seit längerer Zeit im Alphastatus und glbd liegt in der Version 0.7.5 vor. Also beides ausbaufähig ;-). Mein Favorit ist glbd, weil er genau das tut, was er soll und nicht unnötig viele Einstellung benötigt oder bietet. Die Syntax ist recht einfach:

glbd --daemon --threads 8 --control 127.0.0.1:4041 123.123.123:4040 node1:3306:3 node2:3306:3 node3:3306:3 node4:3306:1 

Ein –help zeigt alle Optionen:

glbd --help
Usage:
glbd [OPTIONS] LISTEN_ADDRESS [DESTINATION_LIST]
OPTIONS:
--help                  this help message.
--daemon                run as a daemon.
--fifo <fifo name>      name of the FIFO file for control.
--control [HOST:]PORT   listen for control requests on this address.
--threads N             number of working threads (connection pools).
--source_tracking       turn on source tracking: route connections from one
source to the same destination.
--verbose               turn on verbose reporting.
--version               print program version.
LISTEN_ADDRESS:
[IP:]PORT               where to listen for incoming TCP connections.
DESTINATION_LIST:
[H1[:P1[:W1]]] [H2[:P2[:W2]]]...  - a space-separated list of destinations
in the form address:port:weight.

Die Optionen nach Bedarf anpassen. Meiner Meinung nach empfiehlt es ich das weight eines nodes relativ niedrig anzusetzen. Dieser kann dann primär für Backups oder als Donor  fuer zusätzliche Nodes dienen, da er während des Syncs mit einem neuen Node im readonly mode ist. Statusabfragen von glbd macht man z.B. mit:

# echo "getinfo" | nc -q 1 127.0.0.1 4041
Router:
----------------------------------------------------
Address       :   weight   usage   conns
node1:3306  :    3.000   0.000     0
node2:3306  :    3.000   0.000     0
node3:3306  :    3.000   0.000     0
node4:3306  :    1.000   0.000     0
----------------------------------------------------
Destinations: 4, total connections: 0

Weiter Informationen finden sich im Readme.  Sehr gute Informationen und eine deutlich detaillierte Anleitung zu glbd findet man unter fromdual.com/mysql-and-galera-load-balancer. Dort ist auch ein Skript hinterlegt um glbd zu administrieren. Bricht ein Node weg, leitet glbd die Anfrage transparent an einen verfügbaren Node weiter. Leider ist die Dokumentation von glbd etwas dürftig, daher werden sich viele Verhaltensweisen erst im Laufe von diversen Tests zeigen. Probleme können eventuell auftauchen wenn man mit Pacemaker/Corosync arbeitet, da glbd sich (zu Recht) weigert,  an ein nicht existierendes Interface gebunden zu werden (Stichwort „crm colocation“), dazu mehr in Teil 3.

Mysql-Proxy ist als Paket bei Ubuntu 12.04 dabei, zwar „nur“ die 0.8.1, dafür  genießt man die Vorteile der Paketverwaltung. Konfiguriert wird mysql-proxy in der

/etc/default/mysql-proxy:

ENABLED="true"
OPTIONS="--proxy-skip-profiling --proxy-address=123.123.123.123:4040 --proxy-backend-addresses=node1:3306 --proxy-backend-addresses=node2:3306 --proxy-backend-addresses=node3:3306 --proxy-backend-addresses=node4:3306 --admin-username=superadmin --admin-password=imnotshyijustdontlikeu --admin-lua-script=/usr/lib/mysql-proxy/lua/admin.lua"

Damit läuft  erst mal die Proxyfunktion. Mysql-proxy kann deutlich mehr als nur  Proxy sein. So kann er zum Beispiel die Mysqlanfragen nach read-write selektieren und mit der --proxy-read-only-backend-addresses Option auf dedizierte Readonly „Slaves“ leiten. Die Dokumentation ist sehr gut, dank auch der  MySQL Integration. MySQL Anfragen können mit Hilfe von Lua Skripten direkt manipuliert  werden. Zum lesen nochmal zwei Links zu mysql-proxy, hier und hier. Der Beitrag von mysqlperformanceblog.com  ist von Juni 2009, daher wurde noch die 0.7.1 getestet. Zu eigenen Benchmarks komme ich in Teil 4.

Ob nun glbd, mysql-proxy, pen oder haproxy, hängt vom Einsatzzweck und System ab. Sicherlich gibt es noch etliche andere Lösungen für ein Mysql Proxy/Loadbalancer Szenarien. Schaut man sich kommerzielle Anbieter an, wird man sicherlich hinter all den Webinterfaces, Firmenlogos und Gedöhns, häufig ein Programm aus der Open Source Welt finden, was dort still und unscheinbar seinen Dienst verrichtet. Teil 3 handelt von Pacemaker und IP Failover und Teil 4 schließlich von Benchmaks zu unterschiedlichen Konfigurationen. Ein wesentlicher Faktor beim Einrichten einer solchen Umgebungen ist natürlich die Zeit, die man dafür zur Verfügung hat. Sollte ich komplett auf dem Holzweg sein, sind Kommentare natürlich willkommen, ansonsten natürlich auch.

Link zu Teil 1:

http://exdc.net/2012/08/06/galera-cluster-mit-ubuntu-12-04-64bit-und-mysql-5-5-teil-1/