Die Datenmenge in Unternehmen wächst unaufhaltsam und auch deren notwendige Verfügbarkeit steht längst außer Frage. Deshalb befasst sich IT-Administrator im ... (mehr)

Einrichtung von Corosync

Zunächst suchen Sie in der Datei nach einer Sektion namens "interface". Hier tragen Sie bei der Einstellung "bindnetaddr" die Netzwerk-IP-Adresse des Netzes ein, in dem unsere beiden Hosts sich befinden:

totem {
...
    interface {
    ...
       bindnetaddr: 172.16.14.0
    }
}

Wichtig ist, hier nicht die Host-IP-Adressen der Nodes einzutragen – diese sind nämlich nicht identisch. Durch die Verwendung der Netz-IP kann die Konfiguration auf beiden Systemen identisch erfolgen. Um Corosync starten zu können, ändern wir in der Datei die Zeile "START=no" auf "START=yes".

Corosync benutzt zur Absicherung seiner Kommunikation einen Autorisierungsschlüssel, der auf allen Nodes identisch sein muss. Diesen Schlüssel erzeugen Sie auf dem ersten Node und kopieren ihn auf den zweiten:

root@oa01:~$ corosync-keygen -l
root@oa01:~$ scp /etc/corosync/authkey 172.16.14.61:/etc/corosync

Die Option "-l" führt dazu, dass der erzeugte Schlüssel zwar weniger sicher ist, dafür aber deutlich schneller generiert wird. Auf Produktivsystemen sollten Sie diese Option allerdings nicht verwenden. Jetzt können Sie Corosync starten:

$ service corosync start
    * Starting corosync daemon corosync

Konfiguration von Pacemaker

Nachdem Corosync läuft, beginnen Sie mit der Konfiguration von Pacemaker. Pacemaker kümmert sich um die Verwaltung aller Ressourcen, die im Fehlerfall eines Knoten die Seiten wechseln müssen. Zunächst starten Sie Pacemaker mit dem Befehl . Der Befehl zeigt den Zustand unseres Clusters und sieht anfangs ziemlich leer aus. Das sollte sich allerdings nach ein paar Sekunden ändern, wenn die beiden Nodes erkannt haben, dass sie miteinander reden können:

Last updated: Fri Aug 15 16:12:42 2014
Last change: Fri Aug 15 14:51:43 2014 via cibadmin on oa02
Stack: corosync
Current DC: oa02 (739249725) - partition with quorum
Version: 1.1.10-42f2063
2 Nodes configured
0 Resources configured
 
Node oa01 (739249726): online
Node oa02 (739249725): online
 
Inactive resources:
Migration summary:
* Node oa02:
* Node oa01:

Wenn der zweite Node aufgetaucht ist, können Sie "crm_mon" durch Drücken von "Strg + C" beenden. Anschließend geben Sie folgende Befehle für die grundlegende Pacemaker-Konfiguration ein:

root@oa01:~$ crm configure
crm(live)configure# property default-resource-stickiness=100
crm(live)configure# property stonith-enabled=false
crm(live)configure# property no-quorum-policy=ignore
crm(live)configure# commit
crm(live)configure# exit

Eine Anmerkung zum Parameter "stonith-enabled=false": STONITH ist ein Dienst, über den der Cluster im Fall, dass ein Node nicht mehr reagiert, sicherstellen kann, dass der Node ausgeschaltet ist und keine Gefahr für die Konsistenz der Daten des Clusters darstellt. Ein solcher Mechanismus ist sinnvoll für Produktivsysteme, weil ein amoklaufender Zombie-Node sehr eigenartige Effekte auf produktive Daten haben kann [2]. Die Konfiguration ist von der jeweiligen Hardware und Umgebung abhängig und daher nie gleich. Wir können deshalb im Rahmen dieses Artikels nicht näher darauf eingehen. Für Produktivsysteme ist STONITH aber auf jeden Fall Pflicht.

Als Nächstes erfolgt die Konfiguration einer DRBD-Ressource, um unser gespiegeltes Volume mit Pacemaker bekannt zu machen. Auf die DRBD-Ressource bauen weitere Ressourcen auf, die über entsprechende Abhängigkeiten an sie gebunden werden, damit Pacemaker die richtigen Schritte in der richtigen Reihenfolge durchführt (siehe Listing 2: Konfiguration einer DRBD-Ressource).

Diese Konfiguration weist Pacemaker an, die DRBD-Verbindung auf einem Node auf Primary zu schalten, das Volume nach "/var/lib/postgresql" zu mounten, PostgreSQL zu starten und auf dem aktiven Node eine zusätzliche IP-Adresse zu konfigurieren, über die auf die Datenbank zugegriffen werden kann. Die einzelnen Dienste und die zusätzliche IP-Adresse werden immer automatisch auf einem der beiden Knoten aktiviert, sodass die Verfügbarkeit der Datenbank sichergestellt ist.

Listing 2: Konfiguration einer DRBD-Ressource



root@oa01:~$ crm configure
crm(live)configure# primitive drbd_oa_database ocf:linbit:drbd \
    params drbd_resource="oa_database" \
    op start interval="0" timeout="240" \
    op stop interval="0" timeout="100"
crm(live)configure# ms ms_drbd_oa_database drbd_oa_database \
    meta master-max="1" master-node-max="1" clone-max="2" \ clone-node-max="1" notify="true" interleave="true"
crm(live)configure# primitive fs_oa_database ocf:heartbeat:Filesystem \
    params device="/dev/drbd/by-res/oa_database" \ directory="/var/lib/postgresql" fstype="xfs" \
    op monitor interval="10s" timeout="20s" \
    op start interval="0" timeout="60" \
    op stop interval="0" timeout="60"
crm(live)configure# primitive ip_oa_database ocf:heartbeat:IPaddr2 \
    op monitor interval="10s" timeout="20s" \
    params ip="172.16.14.251" nic="eth0" cidr_netmask="24"
crm(live)configure# primitive rcpgsql lsb:postgresql \
    op monitor interval="10s" timeout="20s" \
    op start interval="0" timeout="60" \
    op stop interval="0" timeout="60"
crm(live)configure# group oa_database \
    fs_oa_database rcpgsql ip_oa_database
crm(live)configure# colocation oa_database-on-drbd_oa_database \
    inf: oa_database ms_drbd_oa_database:Master
crm(live)configure# order drbd_oa_database-then-oa_database \
    inf: ms_drbd_oa_database:promote oa_database:start
crm(live)configure# commit
crm(live)configure# exit

Ähnliche Artikel

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

Ausgabe /2020