Cluster: Dienst nur einmal im Netzwerk starten

[fork]

Hallo zusammen,

ich habe hier ein Cluster-Setup und verwendet da SFS/FUSE(Siehe https://github.com/immobiliare/sfs) zur Dateireplikation. D. h. auf mehreren gleichberechtigten HTTP-Nodes werden Dateien repliziert. SFS ist noch im Bastelstadium, ist aber sehr leichtgewichtig, deswegen habe ich mir das ausgesucht. SFS benötigt dabei eine Client-Komponente und eine aktive Sync-Komponente. Letztere darf aber nur einmal gestartet werden. Jetzt frage ich mich, wie ich das ganz simpel hinbekomme.

Erster Gedanke war da, UCARP zu verwenden. UCARP hat damit zwar erst mal nur indirekt zu tun, da ich keine dedizierte IP für den Dienst benötige. Denn es geht bei UCARP nur darum, dass im Netzwerk eine Dienste-IP gesichert nur einem Server zuzuweisen. Und das geht halt super einfach und funktioniert. Über das up-script von UCARP würde ich dann den Dienst starten bzw. über das down-script diesen dann wieder beenden. Das, was ich noch nicht weiss, ist ob das auch mit mehr als 2 Nodes funktioniert - UCARP ist grundsätzlich erstmal auf 2 Nodes ausgelegt.

Als nächstes würde mir noch ein Locking auf einem NFS-Share einfallen. Das wäre aber wieder ein Single-Point-Of-Failure(SPOF).

Habt Ihr vielleicht noch eine bessere Idee?

[marce]

Heartbeat + Stonith?

[nopes]

Alternativ:
Eine simple Netz-API schaffen und beim starten von Active Sync halt prüfen, ob schon einer läuft. Allerdings lande ich hier immer bei dem Problem, dass die Netz-API dann der SPOF wäre, was man wiederum durch einen HTTP-Cluster lösen könnte, was dann aber alles andere als leichtgewichtig ist - wobei, als Unterbau für die Kommunikation könnte man zB auf sowas wie Thrift setzen, was dann wiederum sogar ein relatives einfaches Clustering erlauben würde und dann wohl doch wieder ziemlich einfach zu realisieren wäre.
Weitere:
Evt läuft ja schon irgendwo Nagios und NRPE ist ohnehin gewünscht, ist dann zwar nicht so wirklich Rest, ich weiss auch nicht, wie viel sich da bei NRPE getan hat, aber früher, war es ziemlich einfach so zu tun, als wäre man Nagios.

[fork]

Heartbeat + Stonith?

Mist, ich hatte es schon erfolgreich verdrängt, weil's mir zu anstrengend war. Aber vielen Dank für den Wink mit dem Zaunpfahl!

Danke auch nopes für Deine Mühe. Ich konnte es nicht lassen, Deinen Text mal im Bullshit-Score-Meter zu testen. Hast absolut bestanden

Ich werde berichten, welche Lösung meine Faulheit am besten unterstützt und wie ich es umgesetzt habe(Das nutze ich doch gerade mal als Stichwort für diese grandiose Simpsons Video: Lay-Z).

[fork]

Testsetup mit UCARP + 3 Nodes(Debian Jessie) hat geklappt. Wie zuverlässig UCARP jetzt da wirklich ist, weiss ich nicht. Eine robuste und cluster-würdige Lösung wäre dann doch eher heartbeat bzw. corosync/pacemaker.

Das ist mal die Netzwerkkonfig:

Node 1

# generated by FAI
auto lo 
auto eth0
iface lo inet loopback
iface eth0 inet static
  address 192.168.1.10
  netmask 255.255.255.0
  gateway 192.168.1.1
  ucarp-vid      1
  ucarp-vip      127.19.19.19
  ucarp-password mypass32
  ucarp-advskew  1
  ucarp-advbase  1
  ucarp-master   yes

iface eth0:ucarp inet static
        address 127.19.19.19
        netmask 255.255.255.255

Node 2

# generated by FAI
auto lo 
auto eth0
iface lo inet loopback
iface eth0 inet static
  address 192.168.1.11
  netmask 255.255.255.0
  gateway 192.168.1.1
  ucarp-vid      1
  ucarp-vip      127.19.19.19
  ucarp-password mypass32
  ucarp-advskew  2
  ucarp-advbase  1
  ucarp-master   no

iface eth0:ucarp inet static
        address 127.19.19.19
        netmask 255.255.255.255

Node 3

# generated by FAI
auto lo 
auto eth0
iface lo inet loopback
iface eth0 inet static
  address 192.168.1.12
  netmask 255.255.255.0
  gateway 192.168.1.1
  ucarp-vid      1
  ucarp-vip      127.19.19.19
  ucarp-password mypass32
  ucarp-advskew  3
  ucarp-advbase  1
  ucarp-master   no

iface eth0:ucarp inet static
        address 127.19.19.19
        netmask 255.255.255.255

Zusätzlich noch die beiden Hilfsskripte auf allen Rechnern:

/usr/share/ucarp/vip-up

#!/bin/sh

/sbin/ifup $1:ucarp

# Zu Testzwecken mal den Apache als Single-Instance genommen
systemctl start apache2.service

/usr/share/ucarp/vip-down

#!/bin/sh

/sbin/ifdown $1:ucarp

# Zu Testzwecken mal den Apache als Single-Instance genommen
systemctl stop apache2.service

Bei den Netzwerkkonfigurationen ist wichtig, dass der Wert ucarp-advskew unterschiedlich ist - der Server mit dem kleinsten Wert hat die höchste Priorität. Und ucarp-master sollte auch nur einer haben. Kleine Stolperfalle ist auch das Passwort: Das darf nur 16 Zeichen lang sein!

Der Master wechselt dabei dynamisch. D. h. wenn ich das Gerät mit der höchsten Priorität abschalte und wieder einschalte oder wenn es ausfällt und ist dann wieder da, wechselt der Master immer wieder zum Gerät mit der höchsten Priorität(Will man meist eher nicht haben).

[fork]

SFS funktioniert leider gar nicht so gut. Wenn ich z. B. einen grösseren Teildateibaum lösche, dann bleibt das wegen irgendwelchen rsync-Fehlern schon hängen.

Ich teste jetzt ein simples master/slave-nfs mit ucarp.

[fork]

So, jetzt habe ich das per ucarp+nfs+lsyncd gelöst. Wenn die virtuelle IP auf einem Server aktiviert wird startet sowohl der NFS-Server, als auch ein lsyncd-Prozess(basiert auf rsync+inotify).

Und gelernt habe ich auch noch, dass Übernahme mittels NFS nur dann 100%ig geht, wenn die Dateisysteme exakt gleich sind(was z. B. beim Einsatz von DRBD der Fall ist, bei meiner Methode jedoch nicht.) Deswegen musste ich auf den Clients noch ein Script schreiben, das in kurzen Intervallen prüft, ob das NFS-Share noch erreichbar ist und falls nicht(d. h. bei Ausfall oder Wartung des Masters), einen remount durchführt. Klappt auch gut. NFS downtime beträgt ca. 20 Sekunden.

Für das bisschen Synchronisation hat sich echtes Clustering nicht gelohnt. Es geht um ein paar File-Uploads einer Wikibasierten Webanwendung, bei der nur ca. 20 Autoren Artikel verfassen und der Rest lesend zugreift, also sehr wenig Upload-Traffic.

Nachtrag

Wenn man bei UCARP den Wert ucarp-advskew auf allen Nodes identisch wählt und ucarp-master überall auf no stellt, dann wechselt das nach Reaktivierung eines Servers mit hoher Priorität auch nicht wieder zurück zu diesem: So will man das haben.

Nachtrag 21.6.2016

Einen manuellen failover kann man auf der Masternode mit dem Signal SIG_USR2 auslösen.

pkill -SIGUSR2 -f /usr/sbin/ucarp