Inhaltsverzeichnis

Pacemaker, OpenAIS und Corosync auf SLES11

Informationen

Autoren: Grether, Grunwald und Müller
Erstellung: 20.08.2012


Einleitung

Diese Dokumentation behandelt den Aufbau eines auf Linux basierenden Hochverfügbarkeitssystem unter SLES11 mit einem „Shared-Root“ Cluster und alternativ mit 2 Standalone-Systemen.

Zu beachten gilt, dass sich diese Dokumentation nicht mit der Grundlegenden Installation des Betriebssystems oder des Clusters befassen wird. Die Kenntnisse werden daher vorausgesetzt.


Projekt-Beschreibung

Um einen Shared-Root Cluster hochverfügbar zu machen, muss als erstes die benötigte Software installiert werden. Unter SLES 11 werden Pacemaker, OpenAIS und Corosync eingesetzt. Pacemaker ist eine freie Software für Ressourcenverwaltung unter Linux-Systemen und der direkte Nachfolger von „Heartbeat“. Hierbei werden Server-Dienste, Server oder Dienstprogramme zur Gewährleistung der jeweils höchstmöglichen Verfügbarkeit überwacht. Für die Kommunikation der Knoten wird Pacemaker in Verbindung mit „OpenAIS“, „Corosync“ oder „Heartbeat“ verwendet, wobei OpenAIS und „Corosync“ zusammen verwendet werden. Die verschiedenen Einsatzszenarien der Software, werden im Folgekapitel erläutert.


Einsatzszenarien

Für die Ressourcenverwaltung gibt es verschiedene Einsatzszenarien:

Active/ Passive Cluster Bei einem Active/ Passive Cluster wird mithilfe eines Master-Systems (aktives System), welches primär die Ressourcen verwaltet, und einem passiven „Standbysystem“ oder mehreren „Standbysystemen“ eine Hochverfügbarkeit angestrebt. Wenn der Fall eintreten sollte, dass bestimmte Ressourcen auf dem aktiven System nicht mehr, oder nur unzuverlässig funktionieren, werden die Ressourcen von dem passiven Knoten übernommen und dort gestartet. Es findet ein Failover statt.

Active/ Activ Cluster Bei einem Active/ Active Cluster steht die Performance im Vordergrund. Dadurch dass mehrere Knoten gleichzeitig „Active“ geschaltet sind, kann eine Leistungsverteilung stattfinden und dadurch die Performance beliebig skaliert werden. Bei einem Ausfall eines Knotens übernimmt ein anderer aktiver Knoten die laufenden Ressourcen des Systems, wodurch keine Downtime entsteht.
Hinweis: In dieser Dokumentation wird hauptsächlich auf die Activ/ Passiv Konfiguration eingegangen.


Allgemeine Installation

Vorbereitung

Die Installationsbeschreibung bezieht sich zum Einen auf ein Zwei-Node-Cluster und zum Anderen auf ein Shared-Root-Cluster, wobei beide auf SuSE Linux Enterprise Server 11 basieren. Dabei werden die relevanten Unterschiede erläutert. Auf die Installation des SLES 11 Systems wird dabei nicht eingegangen.

Zu Beginn sollten die Netzwerkeinstellungen für beide Knoten angepasst werden, da diese bei Teilen der Installation wichtig sind. In dieser Beispielkonfiguration werden folgende Einstellungen verwendet:

Node1 Node2
Hostname node1 node2
FQDN node1.site node2.site
IP-Adresse 11.0.0.228 11.0.0.229

Als nächstes wird die CD der SuSE Linux Enterprise High Availability Extension benötigt. Diese wird als ISO in der Virtuellen Maschine (VM) eingehängt. Anschließend müssen auf Node 1 die Ordner /mnt/temp und /mnt/ha angelegt werden. Auf Node 2 muss nur der Ordner /mnt/ha angelegt werden. Dann wird die HA-CD in den Ordner temp gemountet und der Inhalt der CD in den Ordner ha kopiert:

mkdir /mnt/temp /mnt/ha
mount /dev/cdrom /mnt/temp/
mount: block device /dev/sr0 is write-protected, mounting read-only
cp -ax /mnt/temp/* /mnt/ha/


Jetzt muss der Inhalt des Ordners ha auf den zweiten Node kopiert werden, da so das Einhängen und Mounten der ISO-Datei auf Node 2 ausgelassen werden kann.

scp -r /mnt/ha root@11.0.0.229:/mnt/


Bei der Shared-Root Lösung entfällt das kopieren des ha Ordners, da die Nodes auf die selbe Festplatte zugreifen.

Nun wird YaST mit folgendem Befehl gestartet um das Software Repository hinzuzufügen:

YaST


Anschließend unter dem Punkt Software management den Unterpunkt Software Repositories auswählen. Jetzt Add auswählen und im nächsten Fenster local directory markieren und mit Next bestätigen. Jetzt muss der Pfad des Ordners (in diesem Fall /mnt/ha) eingetragen und es kann ein Name für das Repository vergeben werden. Zum Schluss muss die SLES 11 Installations DVD wieder in die VM eingehängt werden.


Installation

Mit folgendem Befehl wird das Software Management von YaST geöffnet:

YaST sw_single


Anschleißend wird in der Suche nach “pacemaker” gesucht und folgende Pakete für die Installation markiert:

  • libpacemaker3
  • pacemaker-mgmt
  • pacemaker
  • pacemaker-mgmt-devel
  • libpacemaker
  • pacemaker-mgmt-client

Hinweis: Dieser Vorgang muss bei einem Stand-Alone System auf allen Nodes wiederholt werden. Bei der Installation von Pacemaker werden Corosync und OpenAIS automatisch mit installiert.


Zwei-Node-Cluster

In den folgenden Unterpunkten wird beschrieben, wie Pacemaker in einem Zwei-Node-Cluster konfiguriert wird.


Konfiguration Pacemaker

Nun wird auf die Konfiguration von Pacemaker und der benötigten Software eingegangen.

1. Um die spätere Konfiguration zu erleichtern, muss der zweite Knoten zur /etc/hosts Datei hinzugefügt werden:

echo "11.0.0.229      node2.site node2" >> /etc/hosts


Durch den Befehl wird die Zeile
11.0.0.229 node2.site node2
in das Ende der hosts Datei eingefügt.

2. Anschließend werden die gewünschten Ports und Netzwerk Adressen gesetzt:

export ais_port=5000
export ais_mcast=226.94.1.1
export ais_addr=11.0.0.60


Wichtig: Wenn sich mehrere Cluster im gleichen Netzwerk befinden müssen sich die AIS-Ports unterscheiden!


3. Im Anschluss darauf können die gewählten Einstellungen wie folgt überprüft werden:

node1:~ # env | grep ais_
ais_mcast=226.94.1.1
ais_port=5000
ais_addr=11.0.0.60


4. Nachdem alles konfiguriert wurde, werden die Einstellungen für die Corosync.conf übernommen:

cp /etc/Corosync/Corosync.conf.example /etc/Corosync/Corosync.conf
sed -i.bak "s/.*mcastaddr:.*/mcastaddr:\ $ais_mcast/g" /etc/Corosync/Corosync.conf
sed -i.bak "s/.*mcastport:.*/mcastport:\ $ais_port/g" /etc/Corosync/Corosync.conf
sed -i.bak "s/.*bindnetaddr:.*/bindnetaddr:\ $ais_addr/g" /etc/Corosync/Corosync.conf


Dabei wird die Beispielkonfiguration kopiert und in Corosync.conf umbennant. Anschließend werden die zuvor gesetzten Ports und Netzwerkadressen in die Datei eingefügt.

5. Nun werden zwei Einträge zur /etc/Corosync/Corosync.conf hinzugefügt:

cat <<-END >>/etc/Corosync/Corosync.conf

aisexec {
   user: root
   group: root
}

service {
   # Load the Pacemaker Cluster Resource Manager
   name: pacemaker
   ver: 0
}     
END


Der erste Eintrag startet den aisexec deamon mit dem Benutzer root.
Durch den zweiten Eintrag wird festgelegt dass Pacemaker beim Start von OpenAIS bzw. Corosyc gestartet wird.

6. Als nächstes werden die /etc/Corosync/Corosync.conf und die /etc/hosts auf den zweiten Node kopiert:

node1:~ # for f in /etc/Corosync/Corosync.conf /etc/hosts; do scp $f node2:$f ; done
The authenticity of host 'node2 (11.0.0.229)' can't be established.
RSA key fingerprint is d5:3b:bf:3c:78:31:e3:71:25:fe:d3:a7:9f:50:f9:c1.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'node2' (RSA) to the list of known hosts.
Password:
Corosync.conf                                  100%  560     0.6KB/s   00:00
Password:
hosts                                          100%  729     0.7KB/s   00:00


7. Im Anschluss wird der Cluster gestartet:

rcOpenAIS start

Dieser Befehl wird anschließend auch auf Node 2 ausgeführt.
8. Danach wird überprüft ob die Cluster Kommunikation fehlerfrei ist:
Node 1:

node1:~ # Corosync-cfgtool -s
Printing ring status.
Local node ID -419430390
RING ID 0
        id      = 11.0.0.228
        status  = ring 0 active with no faults


Node 2:

node2:~ # Corosync-cfgtool -s
Printing ring status.
Local node ID -402653174
RING ID 0
        id      = 11.0.0.229
        status  = ring 0 active with no faults


9. Anschließend wird überprüft, ob der Corosync Dienst ausgeführt wird:

node1:~ # grep -e "Corosync Cluster Engine" -e "configuration file" /var/log/messages
May 29 10:05:44 node1 smartd[13277]: Opened configuration file /etc/smartd.conf
May 29 10:07:13 node1 smartd[3756]: Opened configuration file /etc/smartd.conf
Jul 20 11:10:37 node1 smartd[3813]: Opened configuration file /etc/smartd.conf
Jul 20 11:19:43 node1 smartd[3534]: Opened configuration file /etc/smartd.conf
Jul 20 11:52:26 node1 smartd[3701]: Opened configuration file /etc/smartd.conf
Jul 20 12:51:13 node1 smartd[3717]: Opened configuration file /etc/smartd.conf
Jul 20 13:32:03 node1 Corosync[4567]:  [MAIN  ] Corosync Cluster Engine ('1.2.1'): started and ready to provide service.
Jul 20 13:32:03 node1 Corosync[4567]:  [MAIN  ] Successfully read main configuration file '/etc/Corosync/Corosync.conf'.


10. Nun wird geprüft ob Corosync auf der richtigen Netzwerkarte gestartet ist:

node1:~ # grep TOTEM /var/log/messages
Jul 20 13:32:03 node1 Corosync[4567]:  [TOTEM ] Initializing transport (UDP/IP).
Jul 20 13:32:03 node1 Corosync[4567]:  [TOTEM ] Initializing transmit/receive security: libtomcrypt SOBER128/SHA1HMAC (mode 0).
Jul 20 13:32:03 node1 Corosync[4567]:  [TOTEM ] The network interface [11.0.0.228] is now up.
Jul 20 13:32:03 node1 Corosync[4567]:  [TOTEM ] A processor joined or left the membership and a new membership was formed.
Jul 20 13:38:25 node1 Corosync[4567]:  [TOTEM ] A processor joined or left the membership and a new membership was formed.


11. Zum Schluss wird geprüft ob der Pacemaker Dienst fehlerfrei ausgeführt wird:

node1:~ # grep pcmk_startup /var/log/messages
Jul 20 13:50:58 node1 Corosync[4611]:  [pcmk  ] info: pcmk_startup: CRM: Initialized
Jul 20 13:50:58 node1 Corosync[4611]:  [pcmk  ] Logging: Initialized pcmk_startup
Jul 20 13:50:58 node1 Corosync[4611]:  [pcmk  ] info: pcmk_startup: Maximum core file size is: 18446744073709551615
Jul 20 13:50:58 node1 Corosync[4611]:  [pcmk  ] info: pcmk_startup: Service: 9
Jul 20 13:50:58 node1 Corosync[4611]:  [pcmk  ] info: pcmk_startup: Local hostname: node1


Hinweis: Die oben aufgeführten Logfiles müssen ebenfalls auf Node 2 überprüft werden


Shared-Root

Konfiguration Pacemaker mit "Shared-Root"

In der Konfiguration der Software werden die verschiedenen Schritte meistgehend auf einem Knoten vorgenommen, weil das Shared-Root System die Konfigurationen repliziert. Außer hostabhängige Dateien, welche auf beiden Knoten konfiguriert werden müssen.


Konfiguration über die Konsole

Konfiguration Node1

1. Sind im selben Netzwerk mehrere Pacemaker/Corosync Instanzen vorhanden, muss der Port variieren.

export ais_port=4000
export ais_mcast=226.94.1.1
export ais_addr=`ip address show eth0 | grep "inet " | tail -n 1 | awk '{print $4}' | sed s/255/0/`


2. Die im vorherigen Schritt eingegebene Daten, wie folgt überprüfen:

env | grep ais_

Hinweis: Die Variable ais_addr muss mit der Netzwerkadresse des Clusters übereinstimmen. In der Testinstallation der Dokumentation ist es die 11.0.0.0 .


3. Anschließend die Corosync Datei erstellen:

cp /etc/Corosync/Corosync.conf.example /etc/Corosync/Corosync.conf
sed -i.gres "s/.*mcastaddr:.*/mcastaddr:\ $ais_mcast/g" /etc/Corosync/Corosync.conf
sed -i.gres "s/.*mcastport:.*/mcastport:\ $ais_port/g" /etc/Corosync/Corosync.conf
sed -i.gres "s/.*bindnetaddr:.*/bindnetaddr:\ $ais_addr/g" /etc/Corosync/Corosync.conf


4. Folgenden Inhalt der Datei hinzufügen:

cat <<-END >>/etc/Corosync/Corosync.conf 
service { 
# Load the Pacemaker Cluster Resource Manager 
name: pacemaker 
ver: 0 
} 
END
cat <<-END >>/etc/Corosync/Corosync.conf
aisexec { 
user: root 
group: root 
} 
END 


5. Vollständiger Inhalt der Datei /etc/Corosync/Corosync.conf: Hier muss gegebenenfalls die bindnetaddr angepasst werden, wenn sich mehrere Pacemaker /Corosync Instanzen in der Umgebung befinden, da sonst ein Konflikt zwischen den Instanzen entsteht.

totem {
   version: 2
   secauth: off
   threads: 0
   interface {
       ringnumber: 0
       bindnetaddr: 11.0.0.51
       mcastaddr: 226.94.1.1
       mcastport: 4000
   }
}

logging {
   fileline: off
   to_stderr: yes
   to_logfile: yes
   to_syslog: yes
   logfile: /var/log/Corosync.log
   debug: off
   timestamp: on
   logger_subsys {
      subsys: AMF
      debug: off
   }
}

amf {
   mode: disabled
}
aisexec {
   user: root
   group: root
}
service {
   # Load the Pacemaker Cluster Resource Manager
   name: pacemaker
   ver: 0
}     


Konfiguration Node 1+2

Erstellen eines hostabhängigen Verzeichnisses, zum vermeiden von Datenüberschreibung:

mkdir /var/log/cluster/


Konfiguration Node 1

1. Starten des Corosync Dienstes durch OpenAIS:

rcopenais start


2. Kontrolle ob die Dienste soweit „ok“ sind

grep -e "Corosync Cluster Engine" -e "configuration file" /var/log/messages

May 29 10:05:44 sles11tpl smartd[13277]: Opened configuration file /etc/smartd.conf
May 29 10:07:13 sles11tpl smartd[3756]: Opened configuration file /etc/smartd.conf
Jun 15 08:46:06 sles11tpl smartd[3812]: Opened configuration file /etc/smartd.conf
Jun 15 08:53:50 sles11tpl smartd[3766]: Opened configuration file /etc/smartd.conf
Jun 15 09:07:54 sabnode1 smartd[3781]: Opened configuration file /etc/smartd.conf
Jun 15 10:21:52 sabnode1 smartd[3746]: Opened configuration file /etc/smartd.conf
Jun 15 11:44:42 sabnode1 smartd[4359]: Opened configuration file /etc/smartd.conf
Jun 15 12:25:08 sabnode1 smartd[4354]: Opened configuration file /etc/smartd.conf
Jun 15 14:07:50 sabnode1 smartd[4396]: Opened configuration file /etc/smartd.conf
Jun 15 14:32:37 sabnode1 smartd[4367]: Opened configuration file /etc/smartd.conf
Jun 15 16:11:41 sabnode1 smartd[4374]: Opened configuration file /etc/smartd.conf
Jun 15 16:29:40 sabnode1 smartd[4359]: Opened configuration file /etc/smartd.conf
Jun 18 08:15:58 sabnode1 smartd[4363]: Opened configuration file /etc/smartd.conf
Jun 18 08:41:52 sabnode1 smartd[4341]: Opened configuration file /etc/smartd.conf
Jun 18 10:11:36 sabnode1 smartd[20264]: Opened configuration file /etc/smartd.conf
Jun 18 10:23:17 sabnode1 smartd[20219]: Opened configuration file /etc/smartd.conf
Jun 18 11:44:26 sabnode1 smartd[20164]: Opened configuration file /etc/smartd.conf
Jun 18 13:11:30 sabnode1 smartd[20225]: Opened configuration file /etc/smartd.conf
Jun 18 13:56:15 sabnode1 smartd[21599]: Opened configuration file /etc/smartd.conf
Jun 18 15:30:51 sabnode1 smartd[21596]: Opened configuration file /etc/smartd.conf
Jun 18 15:39:49 sabnode1 smartd[21661]: Opened configuration file /etc/smartd.conf
Jun 19 09:05:10 sabnode1 smartd[21667]: Opened configuration file /etc/smartd.conf
Jun 19 09:13:01 sabnode1 smartd[21611]: Opened configuration file /etc/smartd.conf
Jun 19 10:07:43 sabnode1 smartd[21749]: Opened configuration file /etc/smartd.conf
Jun 19 10:50:34 sabnode1 smartd[21611]: Opened configuration file /etc/smartd.conf
Jun 19 10:58:25 sabnode1 smartd[21777]: Opened configuration file /etc/smartd.conf
Jun 19 11:26:51 sabnode1 smartd[21753]: Opened configuration file /etc/smartd.conf
Jun 19 11:36:51 sabnode1 smartd[21752]: Opened configuration file /etc/smartd.conf
Jun 19 11:47:09 sabnode1 smartd[21776]: Opened configuration file /etc/smartd.conf
Jun 19 12:16:21 sabnode1 smartd[21750]: Opened configuration file /etc/smartd.conf
Jun 19 13:29:07 sabnode1 smartd[21769]: Opened configuration file /etc/smartd.conf
Jun 19 13:38:31 sabnode1 smartd[21749]: Opened configuration file /etc/smartd.conf
Jun 19 14:01:01 sabnode1 smartd[21768]: Opened configuration file /etc/smartd.conf
Jun 19 14:13:21 sabnode1 smartd[21746]: Opened configuration file /etc/smartd.conf
Jun 19 14:38:56 sabnode1 smartd[21772]: Opened configuration file /etc/smartd.conf
Jun 19 14:51:36 sabnode1 smartd[21778]: Opened configuration file /etc/smartd.conf
Jul  9 10:08:51 sabnode1 smartd[21769]: Opened configuration file /etc/smartd.conf
Jul 10 08:32:46 sabnode1 smartd[21769]: Opened configuration file /etc/smartd.conf
Jul 10 12:02:29 sabnode1 smartd[20062]: Opened configuration file /etc/smartd.conf
Jul 10 12:09:05 sabnode1 smartd[21762]: Opened configuration file /etc/smartd.conf
Jul 10 12:13:48 sabnode1 smartd[20540]: Opened configuration file /etc/smartd.conf
Jul 10 15:01:19 sabnode1 smartd[20566]: Opened configuration file /etc/smartd.conf
Jul 13 10:50:56 sabnode1 smartd[20530]: Opened configuration file /etc/smartd.conf
Jul 13 12:13:25 sabnode1 smartd[19264]: Opened configuration file /etc/smartd.conf
Jul 16 16:16:37 sabnode1 smartd[19266]: Opened configuration file /etc/smartd.conf
Jul 18 16:23:53 sabnode1 smartd[19204]: Opened configuration file /etc/smartd.conf
Jul 18 16:33:23 sabnode1 smartd[19215]: Opened configuration file /etc/smartd.conf
Jul 18 16:40:37 sabnode1 Corosync[20469]:  [MAIN  ] Corosync Cluster Engine ('1.2.1'): started and ready to provide service.
Jul 18 16:40:37 sabnode1 Corosync[20469]:  [MAIN  ] Successfully read main configuration file '/etc/Corosync/Corosync.conf'.


3. Testen ob Corosync den richtigen Netzwekadapter verwendet:

grep TOTEM /var/log/messages

Jul 18 16:40:37 sabnode1 Corosync[20469]:  [TOTEM ] Initializing transport (UDP/IP).
Jul 18 16:40:37 sabnode1 Corosync[20469]:  [TOTEM ] Initializing transmit/receive security: libtomcrypt SOBER128/SHA1HMAC (mode 0).
Jul 18 16:40:37 sabnode1 Corosync[20469]:  [TOTEM ] The network interface [11.0.0.212] is now up.
Jul 18 16:40:37 sabnode1 Corosync[20469]:  [TOTEM ] A processor joined or left the membership and a new membership was formed.
Jul 18 16:40:46 sabnode1 Corosync[20469]:  [TOTEM ] A processor joined or left the membership and a new membership was formed.
Jul 18 16:40:52 sabnode1 Corosync[20469]:  [TOTEM ] A processor joined or left the membership and a new membership was formed.


4. Testen ob der Pacemaker Dienst läuft:

grep pcmk_startup /var/log/messages

Jul 18 16:40:37 sabnode1 Corosync[20469]:  [pcmk  ] info: pcmk_startup: CRM: Initialized
Jul 18 16:40:37 sabnode1 Corosync[20469]:  [pcmk  ] Logging: Initialized pcmk_startup
Jul 18 16:40:37 sabnode1 Corosync[20469]:  [pcmk  ] info: pcmk_startup: Maximum core file size is: 18446744073709551615
Jul 18 16:40:37 sabnode1 Corosync[20469]:  [pcmk  ] info: pcmk_startup: Service: 9
Jul 18 16:40:37 sabnode1 Corosync[20469]:  [pcmk  ] info: pcmk_startup: Local hostname: sabnode1


5. Testen ob Corosync läuft

ps axf

(should contain something like this)

20469 ?  Ssl  0:00 /usr/sbin/Corosync
20474 ?  S    0:00   \_ /usr/lib64/heartbeat/stonithd
20475 ?  S    0:00   \_ /usr/lib64/heartbeat/cib
20476 ?  S    0:00   \_ /usr/lib64/heartbeat/lrmd
20477 ?  S    0:00   \_ /usr/lib64/heartbeat/attrd
20478 ?  S    0:00   \_ /usr/lib64/heartbeat/pengine
20479 ?  S    0:00   \_ /usr/lib64/heartbeat/crmd


Konfiguration Node 2
rcopenais start


Konfiguration Beliebiger Node

Cluster Konfiguration wie folgt anpassen um Fehler zu vermeiden:

crm_mon -i 2

crm configure property no-quorum-policy=ignore
crm configure property stonith-enabled=false
crm configure rsc_defaults resource-stickiness=100 
crm configure show
crm configure show


node sabnode1
node sabnode2
property $id="cib-bootstrap-options" \
        dc-version="1.1.2-2e096a41a5f9e184a1c1537c82c6da1093698eb5" \
        cluster-infrastructure="openais" \
        expected-quorum-votes="2" \
        stonith-enabled="false" \
        no-quorum-policy="ignore"
rsc_defaults $id="rsc-options" \ 
        resource-stickiness="100"


Pacemaker GUI

Konfiguration belibiger Node

Gnome-YaST-Patterns installieren Den Folgenden Teil der Datei /etc/Corosync/Corosync.conf

service {
	# Load the Pacemaker Cluster Resource Manager
	name: pacemaker
	ver:  0
}


wie folgt anpassen:

service {
	# Load the Pacemaker Cluster Resource Manager
	name: pacemaker
	ver:  0

	# mgmtd-Dienst starten, der für die Pacemaker GUI benoetigt wird
	use_mgmtd: 1
}


Passwort für den Benutzer hacluster, der Gruppe haclient setzen:

passwd hacluster

Changing password for hacluster.
New Password:
Reenter New Password:
Password changed.


Nach einem Neustart, kann die Pacemaker GUI in Gnome gestartet werden.


Allgemeine Einführung in die GUI


Um sich in der GUI einloggen zu können, muss der Dienst openAIS gestartet sein und dem Benutzer hacluster ein Passwort zugewiesen sein. Das Passwort für diesen Account kann als root-Benutzer in der Konsole über folgenden Befehl geändert bzw. gesetzt werden:

passwd hacluster


Nun kann die Anmeldung in der GUI über localhost, 127.0.0.1 oder der IP eines Knotens durchgeführt werden.



Direkt nach dem Login wird diese Übersicht mit den aktuell laufenden Knoten angezeigt. Werden später Ressourcen hinzugefügt, erscheinen diese ebenfalls hier in der Anzeige.



Im Menü Nodes können ebenfalls alle Nodes angezeigt und bearbeitet werden.



Sollen Ressourcen hinzugefügt oder bearbeitet werden, so kann dies im gleichnamigen Menü durchgeführt werden. Da eine Gruppe auch als Ressource verstanden wird, müssen diese ebenfalls im Resources Menü angelegt bzw. bearbeitet werden.



Da Ressourcen kontrolliert gestartet, gestoppt und bei einem Ausfall kontrolliert umgezogen werden sollen, sind sogenannte Constraints nötig. Constraints werden als Einschränkungen oder Regeln angesehen und können im gleichnamigen Menü angelegt und bearbeitet werden.



Wurden einige Ressourcen und Gruppen angelegt, so kann der Status im Menü Management eingesehen werden. Alle Ressourcen und Nodes die Online und somit verfügbar sind, werden hier als grün angezeigt. Alle Ressourcen und Nodes die nicht Online sind, werden hier grau dargestellt.


Apache 2

Installation

Unter folgenden Pfad wird der Apache2 Webserver in Yast installiert: Yast→ Software installieren oder löschen → Pakete suchen → Pakete auswählen und installieren
Wird der Apache auf einem Shared-Root System installiert, so muss ein Ordner, wie Folgt, angelegt werden:

mkdir /var/log/apache2 && chmod 750 /var/log/apache2


GUI

Soll ein Apache2 Webserver Hochverfügbar (HA) gemacht werden, so stellt dies eine Ressource dar, die hinzugefügt werden muss.

In der GUI können unter dem Punkt Resources neue Ressourcen, wie z.B.: der Apache2 Webserver, hinzugefügt werden. Ein Klick auf Add, um mit dem hinzufügen des Webservers zu beginnen.


Nun muss der Typ der Ressource gewählt werden, die hinzugefügt werden soll. Da es sich bei einem Programm um eine einfache Primitive Ressource handelt, muss dies entsprechend ausgewählt werden.


Im folgenden Fenster müssen die Basiseinstellungen für die Ressource angegeben werden. Die Konfiguration wird dem folgenden Listing bzw. der Grafik entnommen:

ID: Beliebiger Name oder Bezeichnung der Ressource
Initial state of resource: Legt fest, ob die Ressource beim Start der Nodes gestartet werden soll oder nicht
Wurde alles entsprechend eingetragen, so kann die Konfiguration mit einem Klick auf Forward gespeichert und fortgefahren werden.


Da für die Verwaltung des Apache2 einige weitere Daten benötigt werden, müssen diese zusätzlich bekannt gemacht werden. Um diese Daten nun anzugeben, wird ein Klick auf Add im Menüpunkt Instance Attributes ausgeführt.

Die drei benötigten Angaben werden nach den folgenden Grafiken entsprechend, eingetragen:



Wurden alle Daten richtig angegeben, sollte das Fenster wie unten aufgeführt aussehen:

Um die Konfiguration abzuschließen und die Einstellungen der Ressource zu speichern, muss ein Klick auf Apply durchgeführt werden.

Wurden beim Anlegen der Ressource keine Fehler gemacht, sollte der Menüpunkt Resources in der Pacemaker GUI nun wie folgt aussehen:


Eine Ressource benötigt für eine fehlerfreie Funktion sogenannte Constraints. Ein Constraint legt fest, wie sich eine Ressource beim Starten oder einem Ausfall eines Nodes verhalten soll. Man spricht auch von sogenannten Einschränkungen der Ressourcen. Da diese Einstellungen sehr wichtig sind, wird nun wie folgt ein Constraints angelegt:

Um nun eine Regel oder auch Einschränkung anzulegen, wird im Menüpunkt Constraints der Pacemaker GUI auf Add geklickt.


Anschließend muss der Constraints-Typ ausgewählt werden, welcher für die Erstellung benötigt wird. Eine “Einschränkung”, die im Bezug zur Resource und Location steht, muss entsprechent ausgewählt werden.


Im folgenden Fenster werden die Einstellungen zum Node und der dazugehörigen Ressource angegeben. Die Einstellungen sind wie folgt, bzw. entsprechend der vorhergehenden Abbildung, anzugeben:

ID: Beliebiger Name der Constraints-Regel
Resource: Legt die Ressource fest, auf welche sich die Regel beziehen wird
Node: Legt den Node fest, auf welchen sich die Regel beziehen wird
Wurden alle, ggf. angepassten, Einstellungen übertragen, so kann die Regel mit einem Klick auf OK gespeichert und geschlossen werden.

Wurden alle Einstellungen zur Regel richtig übernommen, sollte das Fenster wie folgt aussehen:



War das Starten der Ressource erfolgreich, so sollte die eben angelegte Ressource mit einem grünen Icon im Menüpunkt „Management“ auftauchen.

Zu einem weiteren Test kann die IP des Nodes mit einem Webbrowser geöffnet werden. Sind auch hier keine Fehler aufgetreten und eine Standardseite hinterlegt, so antwortet der Webserver wie folgt:


Zusammenfassung
  1. In der Pacemaker GUI
  2. Resources → Add
    1. Primitive → OK
    2. ID → Einen Namen vergeben
    3. Class → ocf
    4. Provider → heartbeat
    5. Typ → apache
    6. Initial state of resource → Started
    7. Instance Attributes → Add
      1. Name → configfile
      2. Value → /etc/apache2/httpd.conf
    8. Instance Attributes → Add
      1. Name → httpd
      2. Value → /usr/sbin/httpd2-prefork
    9. Instance Attributes → Add
      1. Name → statusurl
      2. Value → http://localhost
  3. Constraints → Add
    1. Resource Location → OK
      1. ID → Name vergeben
      2. Resource → den Apache auswählen
      3. Score → INFINITY
      4. Node → Standard-Node auswählen


Konsole

Zuerst muss der Apache als Ressource hinzugefügt werden:

crm configure primitive matApache ocf:heartbeat:apache \
params configfile="/etc/apache2/httpd.conf" \
params httpd="/usr/sbin/httpd2-prefork" \
op start interval="0s" timeout="60s" \
op monitor interval="5s" timeout="20s" \
op stop interval="0s" timeout="60s"


Hinweis: Zum Schluss muss der Apache gestartet werden. Falls Fehler im Cluster Monitor für die Apache Ressource angezeigt werden, sollte die Ressource „gesäubert“ werden.

crm resource cleanup matApache


Dabei werden Fehlermeldungen im Cluster Monitor für die Ressource “matApache” bereinigt, sofern der Fehler nicht mehr auftritt.


Temp-Verzeichnis für jeden Node

Haben die Nodes kein eigenes /tmp Verzeichnis, so überschreiben sie gegenseitig ihre Temp-Dateien (Host abhängige Daten). Hieraus resultieren schwerwiegende Fehler in der OpenAIS-Software. Diese lässt sich dann meistens nicht sauber beenden.


Beide Nodes

Jeder Node muss eine weitere Festplatte mit 1GB unter „/tmp“ mounten.


Festplatte partitionieren
#Wenn an Controller 1.0
fdisk /dev/sdb

Device contains neither a valid DOS partition table, nor Sun, SGI or OSF disklabel
Building a new DOS disklabel with disk identifier 0x96ceebdf.
Changes will remain in memory only, until you decide to write them.
After that, of course, the previous content won't be recoverable.

Warning: invalid flag 0x0000 of partition table 4 will be corrected by w(rite)

Command (m for help): n
Command action
   e   extended
   p   primary partition (1-4)
p
Partition number (1-4): 1
First cylinder (1-130, default 1):
Using default value 1
Last cylinder, +cylinders or +size{K,M,G} (1-130, default 130):
Using default value 130

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.


Partitionstabelle auslesen
cat /proc/partitions

major  minor    #blocks  name

8        0     31457280  sda
8        1       313236  sda1
8        2     31142002  sda2
8       16      1048576  sdb
8       17      1044193  sdb1


Partition formatieren
mkfs.ext3 -L<LABEL> /dev/sdb1

mke2fs 1.41.9 (22-Aug-2009)
Filesystem label=tmp
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
65280 inodes, 261048 blocks
13052 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=268435456
8 block groups
32768 blocks per group, 32768 fragments per group
8160 inodes per group
Superblock backups stored on blocks:
        32768, 98304, 163840, 229376

Writing inode tables: done
Creating journal (4096 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 25 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.


Festplatte automatisch nach /tmp mounten
cp /etc/fstab /etc/fstab.back
echo "LABEL=tmp      /tmp   ext3   defaults      0 0" >> /etc/fstab


Allgemeine Konfiguration

vIP

Konfiguration über GUI


Da eine virtuelle IP eine Ressource darstellt, muss diese auch als solche hinzugefügt werden. Hierzu in der Pacemaker GUI in den Punkt Resources wechseln. Hier können neue Ressourcen angelegt und bereits existente bearbeitet bzw. die Konfiguration überprüft werden. Um eine neue Ressource anzulegen, muss auf Add geklickt werden.



Im darauf erscheinenden Dialog muss der Ressourcentyp ausgewählt werden. Hier wird Primitive gewählt, da eine einfache Ressource erstellt werden soll.



Nun muss die Basiskonfiguration für die Ressource angegeben werden.
Die hier erscheinenden Felder werden entsprechend der Grafik oben ausgefüllt:
ID: Name der Ressource
Initial state of resource: Legt fest, ob die Ressource beim Start der Nodes gestartet werden soll oder nicht.



Da die IP-Adresse nicht zur Basiskonfiguration einer Ressource gehört, muss diese nun nachträglich hinzugefügt werden. Im folgenden Fenster wird unter Instance Attributes der Tabelleneintrag ip gewählt und auf Edit geklickt.



Im nun erscheinenden Dialog kann die spätere IPv4-Adresse der Ressource im Feld Value eingegeben und mit einem Klick auf OK gespeichert werden. Da die Ressourcenkonfiguration nun abgeschlossen ist, kann das folgende Fenster mit Apply geschlossen und die Konfiguration abgespeichert werden.
Anschließend wird festgelegt, auf welchem Node die Ressource gestartet werden soll. Dies geschieht über sogenannte Constraints, die im gleichnamigen Menüpunkt bearbeitet bzw. erstellt werden können.



Um nun eine entsprechende Regel zu erstellen, genügt ein Klick auf Add im Menü Constraints.



Auch hier muss der Typ der Regel angegeben werden. Da es sich hier um die Bindung einer Ressource mit einem Node (Location) handelt, muss der entsprechend Punkt Resource Location ausgewählt werden.



Wie auch bei der Ressource, müssen hier die Basiskonfigurationen für die Constraints angegeben werden. Die Konfiguration wird entsprechend dem folgenden Listing bzw. der vorhergehenden Grafik übernommen:
ID: Name der Constraints-Regel
Resource: Hier wird die Ressource gewählt, auf die die Regel angewandt werden soll
Node: Hier wird der Node gewählt, auf dem die Ressource später starten soll
Abschließend kann auf OK geklickt und damit die Constraints gespeichert werden.



Wurde die Ressource in Verbindung mit den Constraints richtig konfiguriert und auf autostart gesetzt, so wird diese in der Management-Ansicht als grün dargestellt.



Läuft auf dem Node, auf dem die virtuelle IP konfiguriert wurde ein Webserver, so kann dieser mit der vorhergehend konfigurierten virtuellen IP aufgerufen werden.


Konfiguration über die Konsole

Virtuelle IP-Adresse als Ressource hinzufügen:

crm configure primitive matIP ocf:heartbeat:IPaddr2 \ 
params ip=11.0.0.80 cidr_netmask=24 \ 
op monitor interval=30s


Hierbei wird eine zweite virtuelle IP-Adresse mit dem Namen “matIP” hinzugefügt und die IP-Adresse 11.0.0.80 zugewiesen.


Node hinzufügen

Cluster-Datei bearbeiten

Die Cluster-Datei /etc/cluster/cluster.conf im Beispiel:

<?xml version="1.0"?>
<cluster config_version="1" name="ocfs2" type="gfs">
	<clusternodes>
		<clusternode name="sabnode1" nodeid="1">
			<com_info>
				<rootvolume name="/dev/sda2" fstype="ocfs2"/>
				<eth name="eth0" ip="11.0.0.212" mask="255.255.255.0" gateway="11.0.0.1" mac="00:50:56:85:36:9F"/>
			</com_info>
		</clusternode>
		<clusternode name="sabnode2" nodeid="2">
			<com_info>
				<rootvolume name="/dev/sda2" fstype="ocfs2"/>
				<eth name="eth0" ip="11.0.0.213" mask="255.255.255.0" gateway="11.0.0.1" mac="00:50:56:85:36:9E"/>
			</com_info>
		</clusternode>
		<clusternode name="sabnode3" nodeid="3">
			<com_info>
				<rootvolume name="/dev/sda2" fstype="ocfs2"/>
				<eth name="eth0" ip="11.0.0.214" mask="255.255.255.0" gateway="11.0.0.1" mac="00:50:56:85:76:53"/>
			</com_info>
		</clusternode>
	</clusternodes>
</cluster>


Um einen weiteren Node hinzuzufügen, muss der folgende Block wie folgt hinzugefügt werden:

<clusternode name="sabnode3" nodeid="3">
	<com_info>
		<rootvolume name="/dev/sda2" fstype="ocfs2"/>
		<eth name="eth0" ip="11.0.0.214" mask="255.255.255.0" gateway="11.0.0.1" mac="00:50:56:85:76:53"/>
	</com_info>
</clusternode>


Hosts-Datei bearbeiten

Die Datei /etc/hosts um einen weiteren Block wie folgt erweitern:

11.0.0.214      sabnode3.site sabnode3


Initrd neu erzeugen

Wurde die Datei cluster.conf bearbeitet, so muss das Initrd neu erzeugt werden, um mit den aktualisierten Einstellungen starten zu können. Wird dieser Vorgang nicht ausgeführt, so haben Änderungen in der cluster.conf keine Auswirkungen auf das System.

Bevor das Initrd neu erzeugt werden kann, muss das Boot Volume gemountet werden. Dies kann über folgenden Befehl durchgeführt werden:

mount /boot


Zur Sicherheit, sollte ein Backup des aktuellen Initrd’s erstellt werden, bevor dies neu erzeugt wird. Dies kann über folgenden Befehl realisiert werden:

cp /boot/Initrd-xxxx /boot/backup/.


Wurden beide Befehle ausgeführt, so kann das Initrd mit folgendem Befehl neu erzeugt werden:

/opt/atix/comoonics-bootimage/mkinitrd /boot/initrd-$(uname -r) $(uname -r)


Ressource synchron migrieren

Es können mehrere Ressourcen synchron migriert werden. Beispiel: eine virtuelle IP und eine Apache2-Instanz.


Mit Resource Colocation

Ressourcen müssen vorher angelegt werden


Zusammenfassung Ressource Colocation über GUI
  1. In der Pacemaker GUI
  2. Constraints → Add
    1. Resource Colocation → OK
      1. ID → Name vergeben
      2. Resource → Primärinstanz auswählen
      3. With Resource → Ressource wählen die mit migriert werden soll
      4. Score Attribute → INFINITY
      5. Node Attribute →
      6. Resource Role → Started
      7. With Resource Role → Started
        1. OK


Mit einer Gruppe

Konfiguration über GUI

GUI im „Hack Mode“ ausführen (View → Hack Mode).
Hinweis: Laufen beide Ressourcen auf dem 3. Node und fällt dieser aus, so werden die Ressourcen auf den Node mit dem höchsten Score umgezogen. Wurden die anderen Nodes nicht bewertet, so wird auf den ersten Node umgezogen. Startet der 3. Node wieder und ist somit der Node mit dem höchsten Score, so zieht die Ressource wieder zurück.

  1. In der Pacemaker GUI
  2. Resources → Add
    1. Group → OK
    2. Wizard → OK
      1. ID → Namen für die Gruppe vergeben
      2. Initial state of resource → Start
      3. OK
        1. ID → Namen für erste Resource vergeben
        2. Class → Ocf
        3. Provider → heartbeat
        4. Type → IPaddr2
        5. Forward
          1. Instance Attributes → Element selektieren → Edit
          2. ip → Edit
            1. Value → IP-Adresse eingeben → OK
            2. Apply
    3. OK
      1. ID → Namen für zweite Resource vergeben
      2. Class → Ocf
      3. Provider → heartbeat
      4. Type → Apache
      5. Forward
        1. Add → Instance Attributes → OK
        2. Add → Add
        3. Nvpair → OK
          1. Name → configfile
          2. Value → /etc/apache2/httpd.conf
          3. OK
        4. Add → Nvpair → OK
          1. Name → httpd
          2. Value → /usr/sbin/httpd2-prefork
          3. OK
        5. Add → Nvpair → OK
          1. Name → statusurl
          2. Value → http://localhost
          3. OK
          4. OK
        6. Apply
      6. Cancle
    4. Apply
  3. Constraints → Add
    1. Resource Location → OK
    2. ID → Namen für die Constraints vergeben
    3. Resource → Angelegte Gruppe wählen
    4. Score → INFINITY
    5. Node → PimaryHost auswählen
    6. OK


Konfiguration über die Konsole

Eine Ressourcen Gruppe wird mit folgendem Befehl erstellt:

crm configure group matWebServer matIP matApache \
meta target-role="Started"


Hierbei wird die Gruppe matWebServer, bestehend aus den Ressourcen matIP und matApache, angelegt. Der Parameter meta target-role=„Started“ bewirkt, dass die Gruppe automatisch beim Start von OpenAIS gestartet wird.
Mit folgendem Befehl wird der Masternode festgelegt:

crm configure location cli-prefer-matWebServer matWebServer rule role=master 100: \#uname eq node1

Durch den Befehl wird die Regel mit dem Namen cli-prefer-matWebServer angelegt. Die Ressourcen Gruppe welche die Regel betrifft heißt matWebServer. Diese bevorzugt den Node node1.


Fehlermeldungen und Lösungen

Falls beim Hinzufügen einer Ressource folgender Fehler erscheint:

crm_verify[28659]: 2012/07/23_13:05:48 ERROR: unpack_resources: Resource start-up disabled since no STONITH resources have been defined
crm_verify[28659]: 2012/07/23_13:05:48 ERROR: unpack_resources: Either configure some or disable STONITH with the stonith-enabled option
crm_verify[28659]: 2012/07/23_13:05:48 ERROR: unpack_resources: NOTE: Clusters with shared data need STONITH to ensure data integrity
Errors found during check: config not valid
Do you still want to commit? yes


muss STONITH mit dem folgenden Befehl deaktiviert werden:

crm configure property stonith-enabled=false


Anschließend muss mit folgendem Befehl die Konfiguration auf weitere Fehler überprüft werden:

crm_verify -L


Wenn dabei keine weiteren Fehler auftauchen, wurde alles richtig konfiguriert.


Node Scoring

Das Scoring beschreibt das Umzugsverhalten der Ressourcen beim Starten, Stoppen und dem Ausfall eines Nodes. Durch einem höheren Score wird ein Node beim Starten und dem Umzug der Ressourcen bevorzugt (Logik variabel, siehe Testfälle 3 u. 4).


Scoring Konfigurieren

  1. In der Pacemaker GUI
  2. Constraints → Add
    1. Resource Location → OK
    2. ID → Namen vergeben
    3. Gruppe bzw. Ressource auswählen auf die das Scoring bezogen werden soll
    4. Score → Score festlegen
    5. Node: Default-Start Node auswählen, auf diesen Node wird auch das Scoring bezogen
    6. OK


Testfälle

Testfall 1
Startwerte
Node 2:
   Score: 100
Node 3:
   Score: 150
   Default

Ausfall (N3)
Node 2:
   Active
Node 3:

Back online
Node 2:
Node 3:
   Active
Testfall 2
Startwerte
Node 2:
   Score: 100
Node 3:
   Score: 100
   Default

Ausfall (N3)
Node 2:
   Active
Node 3:

Back online
Node 2:
   Active
Node 3:


Testfall 3
Startwerte
Node 2:
   Score: 200
Node 3:
   Score: 100
   Default

Node 2: Offline
Node 3: Offline
Resource: Offline

Node 2: Offline
Node 3: Online
Resource: Offline

Node 2: Online
Node 3: Online
Resource: Online -> Node 2

Mit Verwendung der Scores, kann der PrimaryHost überschrieben werden

Vor Ausfall
Node 2:
   Active
Node 3: -

Ausfall (N2)
Node 2:
Node 3:
   Active

Back online
Node 2:
   Active
Node 3:


Testfall 4
Startwerte
Node 1:
   Score: -
Node 2:
   Score: 200
Node 3:
   Score: 100
   Default

Node 1: Offline
Node 2: Offline
Node 3: Offline
Resource: Offline

Node 1: Online
Node 2: Offline
Node 3: Offline
Resource: Offline

Node 1: Online
Node 2: Offline
Node 3: Online
Resource: Online -> Node 3

Node 1: Online
Node 2: Online
Node 3: Online
Resource: Online -> Node 2

Mit Verwendung der Scores, kann der PrimaryHost überschrieben werden

Vor Ausfall
Node 2:
   Active
Node 3: -

Ausfall (N2)
Node 2:
Node 3:
   Active

Back online
Node 2:
   Active
Node 3:


Beispiel Konfiguration 1

Beispielkonfiguration für eine Konfiguration, bei der die Ressourcen nach einem Ausfall, auf ihren ursprünglichen Node zurückzieht.

<cib>
	<configuration>
 
		<!-- CRM / Cluster- Konfiguration -->
		<crm_config>
			<cluster_property_set id="cib-bootstrap-options">
				<nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="1.1.2-2e096a41a5f9e184a1c1537c82c6da1093698eb5"/>
				<nvpair id="cib-bootstrap-options-cluster-infrastructure" name="cluster-infrastructure" value="openais"/>
				<nvpair id="cib-bootstrap-options-expected-quorum-votes" name="expected-quorum-votes" value="3"/>
				<nvpair id="cib-bootstrap-options-stonith-enabled" name="stonith-enabled" value="false"/>
				<nvpair id="cib-bootstrap-options-last-lrm-refresh" name="last-lrm-refresh" value="1343050254"/>
			</cluster_property_set>
		</crm_config>
 
		<!-- Auflistung der Nodes -->
		<nodes>
			<node id="sabnode1" uname="sabnode1" type="normal"/>
			<node id="sabnode2" uname="sabnode2" type="normal"/>
			<node id="sabnode3" uname="sabnode3" type="normal"/>
		</nodes>
 
		<!-- Verfuegbare Resourcen -->
		<resources>
 
			<!-- Gruppenname -->
			<group id="ApacheVIPGrp">
 
			<!-- Grupenparameter -->
				<meta_attributes id="ApacheVIPGrp-meta_attributes">
					<nvpair id="ApacheVIPGrp-meta_attributes-target-role" name="target-role" value="started"/>
				</meta_attributes>
 
				<!-- Ressource in der Gruppe -->
				<primitive class="ocf" id="vIP" provider="heartbeat" type="IPaddr2">
					<operations id="vIP-operations">
						<op id="vIP-op-monitor-10s" interval="10s" name="monitor" timeout="20s"/>
					</operations>
					<instance_attributes id="vIP-instance_attributes">
						<nvpair id="vIP-instance_attributes-ip" name="ip" value="11.0.0.71"/>
					</instance_attributes>
				</primitive>
				<pritive class="ocf" id="vIP2" provider="heartbeat" type="IPaddr2">
					<operations id="vIP2-operations">
						<op id="vIP2-op-monitor-10s" interval="10s" name="monitor" timeout="20s"/>
					</operations>
					<instance_attributes id="vIP2-instance_attributes">
						<nvpair id="vIP2-instance_attributes-ip" name="ip" value="11.0.0.72"/>
					</instance_attributes>
				</primitive>
				<primitive class="ocf" id="apache" provider="heartbeat" type="apache">
					<operations id="apache-operations">
						<op id="apache-op-monitor-10" interval="10" name="monitor" timeout="20s"/>
					</operations>
					<instance_attributes id="apache-instance_attributes">
						<nvpair id="apache-instance_attributes-configfile" name="configfile" value="/etc/apache2/httpd.conf"/>
						<nvpair id="apache-instance_attributes-httpd" name="httpd" value="/usr/sbin/httpd2-prefork"/>
						<nvpair id="apache-instance_attributes-statusurl" name="statusurl" value="http://localhost"/>
					</instance_attributes>
				</primitive>
			</group>
 
			<!-- Weitere gruppe -->
			<group id="SingleVIPGrp">
				<meta_attributes id="SingleVIPGrp-meta_attributes">
					<nvpair id="SingleVIPGrp-meta_attributes-target-role" name="target-role" value="started"/>
				</meta_attributes>
				<primitive class="ocf" id="vIP3" provider="heartbeat" type="IPaddr2">
					<operations id="vIP3-operations">
						<op id="vIP3-op-monitor-10s" interval="10s" name="monitor" timeout="20s"/>
					</operations>
					<instance_attributes id="vIP3-instance_attributes">
						<nvpair id="vIP3-instance_attributes-ip" name="ip" value="11.0.0.73"/>
					</instance_attributes>
				</primitive>
			</group>
 
		</resources>
 
		<!-- Einschaenkungen -->
		<constraints>
			<!-- Legt fest, wie sich die ressourcen bei Ausfaellen verhalten sollen -->
			<rsc_location id="vIPapacheResLoc"  node="sabnode3" rsc="ApacheVIPGrp" score="INFINITY"/>
			<rsc_location id="vIPapacheResLoc2" node="sabnode1" rsc="SingleVIPGrp" score="INFINITY"/>
		</constraints>
 
		<op_defaults>
			<meta_attributes id="op_defaults-options">
				<nvpair id="op_defaults-options-record-pending" name="record-pending" value="false"/>
			</meta_attributes>
		</op_defaults>
	</configuration>
</cib>

Hinweis: vIP und vIP2 Starten je auf den Nodes 1 und 3. Bei einem Ausfall ziehen die Ressourcen auf einen zufälligen Node um. Startet der ursprüngliche Node wieder, so ziehen die Ressourcen jeweils auf ihren initialen Node zurück. Für den rückwärtigen Umzug sind hier die INFINITY Scores der Start-Nodes verantwortlich.


Beispiel Konfiguration 2

Um eine Konfiguration zu erzeugen, bei der die Nodes nach einem Ausfall NICHT wieder auf ihre Start-Nodes zurückziehen, muss bei der vorhergehenden Konfiguration folgender Teil entfernt werden:

<!-- Einschaenkungen -->
<constraints>
	<!-- Legt fest, wie sich die ressourcen bei Ausfaellen verhalten sollen -->
	<rsc_location id="vIPapacheResLoc"  node="sabnode3" rsc="ApacheVIPGrp" score="INFINITY"/>
	<rsc_location id="vIPapacheResLoc2" node="sabnode1" rsc="SingleVIPGrp" score="INFINITY"/>
</constraints>


Multicast Adressen

Testen mehrerer, verschiedener Multicastadressen. Die Multicastadresse, wird in der /etc/Corosync/Corosync.conf Datei im Bereich „totem“ festgelegt:

totem {
        version: 2
        secauth: off
        threads: 0
        interface {
                ringnumber: 0
bindnetaddr: 11.0.0.51
mcastaddr: 226.94.1.1
mcastport: 4000
        }
}


Test 1

Testvorgaben
totem {
        version: 2
        secauth: off
        threads: 0
        interface {
                ringnumber: 0
bindnetaddr: 11.0.0.51
mcastaddr: 11.0.0.52
mcastport: 4000
        }
}


Resultat

OpenAIS startet nicht mehr korrekt und es wurden 94,5% CPU-Leistung beansprucht. Das System lies sich nicht mehr steuern.
Ergebnis: FEHLGESCHLAGEN


Test 2

Testvorgaben
totem {
        version: 2
        secauth: off
        threads: 0
        interface {
                ringnumber: 0
bindnetaddr: 11.0.0.51
mcastaddr: 226.94.1.2
mcastport: 4000
        }
}


Resultat

OpenAIS startet ohne erhöhten Ressourcenverbrauch.
Ergebnis: ERFOLGREICH


XML-Konfiguration einlesen

Beispiel XML-Konfigurationsdatei

/var/lib/hearbeat/crm/cib.xml

<cib>
	<configuration>
		<!-- CRM / Cluster- Konfiguration -->
		<crm_config>
			<cluster_property_set id="cib-bootstrap-options">
				<nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="1.1.2-2e096a41a5f9e184a1c1537c82c6da1093698eb5"/>
				<nvpair id="cib-bootstrap-options-cluster-infrastructure" name="cluster-infrastructure" value="openais"/>
				<nvpair id="cib-bootstrap-options-expected-quorum-votes" name="expected-quorum-votes" value="3"/>
				<nvpair id="cib-bootstrap-options-stonith-enabled" name="stonith-enabled" value="false"/>
				<nvpair id="cib-bootstrap-options-last-lrm-refresh" name="last-lrm-refresh" value="1343050254"/>
			</cluster_property_set>
		</crm_config>
 
		<!-- Auflistung der Nodes -->
		<nodes>
			<node id="sabnode1" type="normal" uname="sabnode1"/>
			<node id="sabnode2" type="normal" uname="sabnode2"/>
			<node id="sabnode3" type="normal" uname="sabnode3"/>
		</nodes>
 
		<!-- Verfuegbare Resourcen -->
		<resources>
			<group id="ApacheVIPGrp">
				<!-- Gruppenparameter -->
				<meta_attributes id="ApacheVIPGrp-meta_attributes">
					<nvpair id="ApacheVIPGrp-meta_attributes-target-role" name="target-role" value="started"/>
				</meta_attributes>
 
				<!-- Konfiguration fuer virtuelle IP -->
				<primitive class="ocf" id="vIP" provider="heartbeat" type="IPaddr2">
					<operations id="vIP-operations">
						<op id="vIP-op-monitor-10s" interval="10s" name="monitor" timeout="20s"/>
					</operations>
					<instance_attributes id="vIP-instance_attributes">
						<nvpair id="vIP-instance_attributes-ip" name="ip" value="11.0.0.71"/>
					</instance_attributes>
				</primitive>
 
				<!-- Konfiguration fuer Apache Webserver 2 -->				
				<primitive class="ocf" id="apache" provider="heartbeat" type="apache">
					<operations id="apache-operations">
						<op id="apache-op-monitor-10" interval="10" name="monitor" timeout="20s"/>
					</operations>
					<instance_attributes id="apache-instance_attributes">
						<nvpair id="apache-instance_attributes-configfile" name="configfile" value="/etc/apache2/httpd.conf"/>
						<nvpair id="apache-instance_attributes-httpd" name="httpd" value="/usr/sbin/httpd2-prefork"/>
						<nvpair id="apache-instance_attributes-statusurl" name="statusurl" value="http://localhost"/>
					</instance_attributes>
				</primitive>
			</group>
		</resources>
 
		<!-- Gibt an, auf welchem Node welche Resource mit welchem Score starten soll -->
		<constraints>
			<rsc_location node="sabnode3" rsc="ApacheVIPGrp" id="vIPapacheResLoc" score="INFINITY"/>
		</constraints>
 
		<op_defaults>
			<meta_attributes id="op_defaults-options">
				<nvpair id="op_defaults-options-record-pending" name="record-pending" value="false"/>
			</meta_attributes>
		</op_defaults>
	</configuration>
</cib>


Einlesen

Um eine Konfiguration einlesen zu können, muss die erste Zeile bearbeitet werden.


Änderungen

Vorher

<cib validate-with="pacemaker-1.2" crm_feature_set="3.0.2" have-quorum="1" dc-uuid="sabnode1" admin_epoch="0" epoch="93" num_updates="0" cib-last-written="Mon Jul 23 15:58:24 2012">
	<configuration>
	...


Nachher

<cib>
	<configuration>
	...


Anschließend muss die Konfiguration mit folgendem Befehl importiert werden:

EINFACH
cibadmin -U -x <Pfad zur Konfigurations XML-Datei>
cibadmin -U -x /root/configuration.xml

KOMBINIERT
cibadmin -E --force && cibadmin -U -x <Pfad zur Konfigurations XML-Datei>
cibadmin -E --force && cibadmin -U -x /root/CorosyncConfiguration.xml


XML-Konfiguration erweitern

Erweiterung einer Ressource innerhalb einer Gruppe

Um den markierten Bereich erweitern und ID's entsprechend anzupassen

<cib>
	<configuration>
		<!-- CRM / Cluster- Konfiguration -->
		<crm_config>
			<cluster_property_set id="cib-bootstrap-options">
				<nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="1.1.2-2e096a41a5f9e184a1c1537c82c6da1093698eb5"/>
				<nvpair id="cib-bootstrap-options-cluster-infrastructure" name="cluster-infrastructure" value="openais"/>
				<nvpair id="cib-bootstrap-options-expected-quorum-votes" name="expected-quorum-votes" value="3"/>
				<nvpair id="cib-bootstrap-options-stonith-enabled" name="stonith-enabled" value="false"/>
				<nvpair id="cib-bootstrap-options-last-lrm-refresh" name="last-lrm-refresh" value="1343050254"/>
			</cluster_property_set>
		</crm_config>
 
		<!-- Auflistung der Nodes -->
		<nodes>
			<node id="sabnode1" type="normal" uname="sabnode1"/>
			<node id="sabnode2" type="normal" uname="sabnode2"/>
			<node id="sabnode3" type="normal" uname="sabnode3"/>
		</nodes>
 
		<!-- Verfuegbare Resourcen -->
		<resources>
			<group id="ApacheVIPGrp">
				<!-- Gruppenparameter -->
				<meta_attributes id="ApacheVIPGrp-meta_attributes">
					<nvpair id="ApacheVIPGrp-meta_attributes-target-role" name="target-role" value="started"/>
				</meta_attributes>
 
				<!-- Konfiguration fuer virtuelle IP 1 u. 2 -->
				<primitive class="ocf" id="vIP" provider="heartbeat" type="IPaddr2">
					<operations id="vIP-operations">
						<op id="vIP-op-monitor-10s" interval="10s" name="monitor" timeout="20s"/>
					</operations>
					<instance_attributes id="vIP-instance_attributes">
						<nvpair id="vIP-instance_attributes-ip" name="ip" value="11.0.0.71"/>
					</instance_attributes>
				</primitive>
<!-- DIESEN BEREICH HINZUFUEGEN (START) -->
				<primitive class="ocf" id="vIP2" provider="heartbeat" type="IPaddr2">
					<operations id="vIP2-operations">
						<op id="vIP2-op-monitor-10s" interval="10s" name="monitor" timeout="20s"/>
					</operations>
					<instance_attributes id="vIP2-instance_attributes">
						<nvpair id="vIP2-instance_attributes-ip" name="ip" value="11.0.0.72"/>
					</instance_attributes>
				</primitive>
<!-- DIESEN BEREICH HINZUFUEGEN (ENDE) -->
				<!-- Konfiguration fuer Apache Webserver 2 -->				
				<primitive class="ocf" id="apache" provider="heartbeat" type="apache">
					<operations id="apache-operations">
						<op id="apache-op-monitor-10" interval="10" name="monitor" timeout="20s"/>
					</operations>
					<instance_attributes id="apache-instance_attributes">
						<nvpair id="apache-instance_attributes-configfile" name="configfile" value="/etc/apache2/httpd.conf"/>
						<nvpair id="apache-instance_attributes-httpd" name="httpd" value="/usr/sbin/httpd2-prefork"/>
						<nvpair id="apache-instance_attributes-statusurl" name="statusurl" value="http://localhost"/>
					</instance_attributes>
				</primitive>
			</group>
		</resources>
 
		<!-- Gibt an, auf welchem Node welche Resource mit welchem Score starten soll -->
		<constraints>
			<rsc_location node="sabnode3" rsc="ApacheVIPGrp" id="vIPapacheResLoc" score="INFINITY"/>
		</constraints>
 
		<op_defaults>
			<meta_attributes id="op_defaults-options">
				<nvpair id="op_defaults-options-record-pending" name="record-pending" value="false"/>
			</meta_attributes>
		</op_defaults>
	</configuration>
</cib>


Anhänge

Änderungen zur Knotenkommunikation und Verschlüsselung

secauth:        on
corosync-keygen
/etc/corosync/authkey -> auf den zweiten Note kopieren


Bei der vIP sollte noch weitere Parameter hinterlegt werden:

-	Netzmaske
-	Interface


        interface {

                member {
                        memberaddr: 192.168.232.15
                }
                member {
                        memberaddr: 192.168.232.16
                }
                ringnumber: 0
                bindnetaddr: 192.168.232.0
                mcastport: 5405
                ttl: 1
        }
        transport: udpu


Konsolenbefehle

Befehl Funktion
crm configure show Zeigt die Ressourcen Konfiguration an
crm_verify -L Überprüft die Ressourcen Konfiguration auf Fehler
crm_mon –i 2 Zeigt die Übersicht über den Cluster mit zwei sekundigem Update-Intervall
crm configure property no-quorum-policy=ignore Quorum wird ignoriert
crm configure property stonith-enabled=false Deaktiviert STONITH
crm configure rsc_defaults resource-stickiness=100 Setzt die Default-Gewichtung der Ressourcen auf 100
crm_resource -D -r matApache -t primitive Löscht die Ressource matApache
crm resource cleanup matApache “Säubert” die Ressource matApache
crm resource migrate matApache node2.site Migriert die Ressource matApache auf node2
crm resource unmigrate matApache Macht die Migration Rückgängig
crm resource stop matApache Stoppt die Ressource matApache
crm resource start matApache Startet die Ressource matApache
cibadmin -E –force Löscht die komplette HA-Konfig
cibadmin -U –x /var/lib/heartbeat/crm/FailoverIpApache.xml Fügt die Einstellungen der Datei FailoverIpApache.xml zur Ressourcen Konfiguration hinzu


Pfade und Dateien

Pfad/Datei Funktion
/usr/share/pacemaker/
/var/lib/heartbeat/crm/cib.xml Ressourcen Konfigurationsdatei
/etc/Corosync/Corosync.conf Cluster Konfigurationsdatei
/var/log/cluster/ Verzeichnis für Logdateien
/var/log/apache2/ Dieser Ordner muss bei einem Shared-Root Cluster angelegt werden
/etc/fstab Diese Datei muss bei einem Shared-Root Cluster bearbeitet werden. Hier werden die Hostabhängigen Log-Disks gemountet
/etc/cluster/cluster.conf Hier müssen in einem Shared-Root Cluster die Nodes hinzugefügt werden
/boot/ Hier muss das Initrd bei einem Shared-Root erzeugt werden
/etc/apache2/httpd.conf Konfigurationsdatei des Apache2 Webservers
/usr/sbin/httpd2-prefork Modul des Apache2 Webservers
http://localhost Über diese URL wird geprüft, ob der Apache erreichbar ist
/var/log/messages Hier werden Allgemeine Fehlermeldungen protokolliert


URL Beschreibung
http://de.wikipedia.org/wiki/Pacemaker Allgemeine Beschreibung der Software
http://www.clusterlabs.org/mwiki/index.php?title=Install Installationsanleitung des Herstellers
http://www.clusterlabs.org/wiki/Initial_Configuration Konfigurationsanleitung des Herstellers
http://www.howtoforge.com/installation-and-setup-guide-for-drbd-OpenAIS-pacemaker-xen-on-openSuSE-11.1Weitere Konfigurationsanleitung

linux/pacemakeropenaiscorosyncaufsles11.txt · Zuletzt geändert: 2015/07/06 22:32 (Externe Bearbeitung)