Category Archives: osbn

osbn feed

Kurztipp: Galera 2.2 mehrere connect nodes

Um bei Galera 2.2 mehre Nodes als “first connect” anzugeben, reicht es die IPs durch Komma getrennt in die wsrep.cnf einzutragen.

wsrep_cluster_address="gcomm://192.168.178.10,192.168.178.11,192.168.178.12"

Ob Galera  prüft ob die Nodes tatsächlich aktiv im Cluster sind, muss noch getestet werden. Ich gehe aber davon aus. Dies ist eine der sinnvollsten Verbesserungen der neuen Version.

Kurztipp: Nagios Reports als PDF

Das geht tatsächlich relativ einfach:

wkhtmltopdf --username nagiosadmin --password blabla "http://mynagiosserver/nagios3/cgi-bin/avail.cgi?show_log_entries=&host=HOST&service=SERVICE&timeperiod=thismonth" /tmp/report.pdf

Und fertig. Gibt da sicherlich noch komplexere Lösungen, aber für den einen oder anderen reicht sicherlich diese Lösung.

Nagios Plugin Slave Status

Wer ein gutes Nagiosplugin zur Überwachung einer MySQL Slave Instanz sucht, sollte sich mal das Plugin von Claudio Kuenzler unter

http://www.claudiokuenzler.com/nagios-plugins/check_mysql_slavestatus.php

anschauen. Gefällt mir deutlich besser als alle bisherigen Slave Status Plugins, die ich dafür genutzt habe. Alternativ kann man natürlich die Percona Plugins nutzen.  Dazu ist das Plugin noch recht kurz und verständlich geschrieben. Ich teste das mal auf vier Instanzen und falls es gut läuft wird es auch für den Rest genutzt.

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.

MySQL 5.5 Replikation

Bei MySQL 5.5 haben sich 1-2 Sachen im Bezug auf die “normale” Replikation geändert:

master-host
master-user
master-password
master-port

werden nicht mehr in der my.cnf gesetzt, sondern müssen direkt via MySQL gesetzt werden. Das fällt schnell auf, da MySQL ansonsten mit

unknown variable master-host

den Start verweigert.

Ansonsten alles wie immer:

Master:

create user 'slave_user'@'slavehost' identified by 'slavepassword';
GRANT REPLICATION SLAVE ON *.* to 'slave_user'@'slavehost' identified by 'slavepassword';
GRANT REPLICATION CLIENT ON *.* to 'slave_user'@'slavehost' identified by 'slavepassword';
FLUSH PRIVILEGES;
FLUSH TABLES WITH READ LOCK;
SHOW MASTER STATUS;
UNLOCK TABLES;

Slave:

change master to  MASTER_HOST='masterhost', MASTER_PORT=3306, MASTER_USER ='slave_user', MASTER_PASSWORD='slavepassword', MASTER_LOG_FILE='mysql-bin.000045', MASTER_LOG_POS=730;
START SLAVE;
SHOW SLAVE STATUS \G;

Das GRANT REPICATION CLIENT ist nicht unbedingt nötig. Tatsächlich sind das sinnige Änderungen, auch wenn es sich nicht sofort erschließt.

nagios – check dell warranty

Es gibt ein größeres Update vom check_dell_warranty Skript für Nagios. Seit den letzten Versionen hat es immer wieder Probleme gemacht, aber nun scheint es wieder sauber zu laufen.

ChangeLog:
2012-10-27 3.0.1: Dell dropped the counter for days left from their site, this is now calculated internally. Add patch for European style dates with periods between that numbers.

Das Datum lässt auf eine preAir Version schließen ;-).

Die Ausgabe sieht in etwa so aus, falls es jemand noch nicht kennt:

#/usr/lib/nagios/plugins/check_dell_warranty.py
OK: Service Tag: XYXYXY Warranty: 4 Hour ProSupport, Provider: Dell, Start: 2012-07-18, End: 2014-07-17, Days left: 632 Warranty: Next Business Day, Provider: Dell, Start: 2009-07-18, End: 2010-07-17, Days left: -829

 

wtf is md0 oder wenn sich mal einfach so die UUID ändert

Alle kennen und keiner mag sie, Probleme mit dem Softraid. Betreiben wir doch leider ein Raid5 als Softraid und mussten erstaunt feststellen, dass nach einem Tausch einer HD, unser feines /dev/md0 plötzlich verschwunden war. Die HD wurde vorher ordnungsgemäß als faulty markiert und aus dem Raidverbund entfernt. Leider war unser Softraid nach dem Reboot nicht mehr verfügbar. Geholfen hat schließlich folgendes:

Die UUID bekommen wir mit:

mdadm --examine /dev/sdc
/dev/sdc:
Magic : a92b4efc
Version : 0.90.00
UUID : 12345ecd:fc03887b:db1fe20b:ec7c96b5

wobei sdc zum Raidverbund gehören muss. Starten tun wir das Raid schließlich mit:

mdadm /dev/md0 --assemble -u 12345ecd:fc03887b:db1fe20b:ec7c96b5

Eigentlich hätte auch ein

mdadm --assemble --scan

reichen sollen, da alles in der /etc/mdadm.conf eingetragen war:

cat /etc/mdadm.conf
ARRAY /dev/md0 level=raid5 num-devices=8 UUID=17b8e7f5:50c0331a:367a44be:d51f00a4

Hat es aber nicht, da, warum auch immer, die UUID nicht gestimmt hat.
Damit die mdadm.conf wieder stimmt

mdadm --detail --scan >> /etc/mdadm.conf
cat mdadm.conf
ARRAY /dev/md0 level=raid5 num-devices=8 metadata=0.90 UUID=12345ecd:fc03887b:db1fe20b:ec7c96b5

Bleibt schließlich die Frage, warum in der mdadm.conf eine andere UUID eingetragen war. Eventuell wurde das Raid irgendwann mal neu aufgesetzt und vergessen die mdadm.conf anzupassen.

Unter http://www.tcpdump.com/kb/os/linux/starting-and-stopping-raid-arrays.html findet man nochmal eine genauere Anleitung zum Thema Softraid starten und stoppen.

Wichtig bei solchen Aktion ist immer: Ruhig bleiben, keine übereilten und unüberlegten Befehle in die Konsole eingeben.

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.

p.s. damit teste ich auch gleich mal ob der osbn feed funktioniert