Wer sein System permanent überwacht, hat den Grundstein dafür gelegt Engpässe zu vermeiden und Fehler frühzeitig zu erkennen. Neben dem Platzhirsch Nagios ... (mehr)

Vorarbeit

Auf Ubuntu 10.04 und Debian Squeeze sowie auf SLES sind wie erwähnt die "alten" Daemons zu verwenden, die diesen Distributionen beiliegen. Sie finden sich in den Paketen »gfs-pcmk« und »dlm-pcmk« , die auf dem System vorhanden sein sollten. In SLES finden sich die benötigten Pakete über die Paketsuche. Der Artikel geht im Folgenden davon aus, dass DRBD installiert und mindestens eine DRBD-Ressource vorhanden ist.

Diese Ressource sollte so eingerichtet sein, dass sie im Dual-Primary-Modus laufen darf (Abbildung 1). Ausgehend von einer "normalen" Ressource, wie sie im Artikel zu DRBD in der HA-Serie [3] beschrieben ist, sind in der Konfiguration der Ressource dazu zwei Dinge zu ändern. Einerseits ist dem »net« -Absatz in der Ressourcen-Konfiguration der Eintrag »allow-two-primaries yes;« hinzuzufügen. Andererseits sollte DRBD auch erfahren, was es tun soll, falls eine Split-Brain-Situation eintritt. Das passiert mit

Abbildung 1: Um DRBD in den Dual-Primary-Modus zu verfrachten, ist es nötig, den Modus im
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;

ebenfalls im »net« -Absatz der Ressource.Überdies sollte Pacemaker installiert und grundlegend konfiguriert sein. Es sei an dieser Stelle darauf hingewiesen, dass Pacemaker unbedingt über eine funktionierende STONITH-Konfiguration verfügen sollte; nur diese gibt dem Cluster-Manager die Möglichkeit, amoklaufende Cluster-Knoten aus dem Cluster zu schießen. Schließlich setzt der Artikel voraus, dass die vormals erwähnte DRBD-Ressource bereits als solche in Pacemaker konfiguriert ist und als »ms_drbd_gfs« zur Verfügung steht. Zu beachten ist dabei, dass die »ms« -Ressource etwas anders anzulegen ist, als bei einem DRBD, das im Primary-Secondary-Modus läuft:

ms ms_drbd_gfs p_drbd_gfs meta master-max=2 clone-max=2notify=true

Wenn diese Voraussetzungen erfüllt sind, sollte die DRBD-Ressource auf beiden Clusterseiten mit »drbdadm primary Ressource« in den Modus »Primary« geschaltet werden (Abbildung 2).

Abbildung 2: Ist DRBD richtig konfiguriert, klappt's auch mit dem Dual-Primary, wie hier gut zu erkennen.

GFS2 im Cluster

Dann folgt die Ressourcen-Konfiguration in Pacemaker. Für GFS braucht der Cluster zwei Dienste: »dlm_controld« , der die Kommunikation mit dem Distributed Lock Manager übernimmt, und »gfs_controld.pcmk« , der die Steuerung des GFS2-Daemons übernimmt. Die beiden Dienste werden über den Ressource-Agent »ocf:pacemaker:controld« gesteuert. Die Konfiguration in der CRM-Shell für dieses Beispiel sollte also so aussehen wie in Listing 1. Die genannten Einträge sorgen dafür, dass der Pacemaker grundsätzlich weiß, dass die Control-Daemons laufen sollen und dass sie stets auf allen Knoten des Clusters laufen – dies stellen die »clone« -Einträge sicher. Durch die Constraints ist sichergestellt, dass der DLM-Daemon immer bloß dort gestartet wird, wo die jeweilige DRBD-Ressource im Primary-Modus läuft und dass erst im Anschluss an den DLM-Start auch der GFS-Controld startet.

Listing 1

Ressourcen-Konfiguration

 

Wenn der DLM und der GFS-Controld laufen, dann kann auch das GFS-Dateisystem auf der DRBD-Ressource landen:

sudo mkfs.gfs2 -p lock_dlm -j2 -t pcmk:pcmkRessource

Ressource ist der Device Node der DRBD-Ressource, zum Beispiel »/dev/drbd/by-res/disk0/0« .

Dann fehlt noch die Dateisystem-Ressource in Pacemaker, die das GFS auf den Clusterknoten mountet. »ocf:heartbeat:Filesystem« kommt mit GFS2 zurecht, die passende Ressourcen-Konfiguration sieht dann so aus wie in Listing 2.

Listing 2

GFS2-Dateisystem-Ressource

 

Die Primitive-Ressource sorgt in Kombination mit dem Clone-Eintrag dafür, dass das Dateisystem auf allen Clusterknoten läuft. Durch die Constraints ist aber festgelegt, dass die Ressourcen nur laufen dürfen, wenn der GFS-Controld einsatzbereit ist.

Nach einem »commit« in der CRM-Shell sollte der Cluster aussehen wie im Abbildung 3.

Abbildung 3: Die Ausgabe von
comments powered by Disqus

Artikel der Woche

Eigene Registry für Docker-Images

Wer selber Docker-Images herstellt, braucht auch eine eigene Registry. Diese gibt es ebenfalls als Docker-Image, aber nur mit eingeschränkter Funktionalität. Mit einem Auth-Server wird daraus ein brauchbares Repository für Images. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Konfigurationsmanagement

Ich konfiguriere meine Server

  • von Hand
  • mit eigenen Skripts
  • mit Puppet
  • mit Ansible
  • mit Saltstack
  • mit Chef
  • mit CFengine
  • mit dem Nix-System
  • mit Containern
  • mit anderer Konfigurationsmanagement-Software

Google+

Ausgabe /2020