Skip to end of metadata
Go to start of metadata

1. Einrichtung

Die folgenden Schritte müssen jeweils auf den Knoten durchgeführt werden. Am einfachsten ist es, wenn man einen Knoten konfiguriert und dann klont. So erspart man sich z.B. das Kopieren der Schlüssel für die Totem-Verbindung.

1.1. Netzwerk

Alle Knoten müssen über ihre Hostnamen auch ohne DNS erreichbar sein, also entsprechende Einträge in /etc/hosts:

10.0.0.238      jake3.local.site jake3
192.168.50.238  jake3.local.site jake3
10.0.0.239      elwood3.local.site elwood3
192.168.50.239  elwood3.local.site elwood3

1.2. Zeitdienst

Knoten eines Clusters müssen dringend zeitsynchronisiert sein, also ntp auf den Knoten einrichten "/etc/ntp.conf":

## vmware-spezifisch
tinker panic 0
# dont panic on large drifts
restrict default kod nomodify notrap
restrict 127.0.0.1

server ptbtime1.ptb.de minpoll 4 maxpoll 4

driftfile /var/lib/ntp/drift/ntp.drift # path for drift file

logfile   /var/log/ntp          # alternate log file

keys /etc/ntp.keys              # path for keys file
trustedkey 1                    # define trusted keys
requestkey 1                    # key (7) for accessing server variables
# controlkey 15                 # key (6) for accessing server variables

Neustart von ntpd:

rcntpd restart
chkconfig -a ntpd

Status von ntp inklusive Zeitdifferenz zwischen den beiden Knoten prüfen:

ntpq -p jake3 elwood3

Pacemaker ist nicht sehr anspruchsvoll bzgl. der Zeitdifferenzen zwischen den Knoten: Unterschiede von einer Sekunde sind kein Problem. Andere Dienste (z.B. OpenLDAP Replikation) benötigen im Vergleich Genauigkeiten im ms-Bereich.

1.3. Corosync

Basis Corosync-Konfiguration "/etc/corosync.conf":

# Please read the corosync.conf.5 manual page
compatibility: whitetank

#aisexec {
#       user: root
#       group: root
#}

service {
        name: pacemaker
        ver: 0
        use_mgmtd: yes
}

totem {
        rrp_mode: passive
        version: 2
        secauth: on
        threads: 2
        interface {
                ringnumber: 0
                bindnetaddr: 192.168.50.0
                mcastaddr: 226.94.5.1
                mcastport: 5404
        }
        interface {
                ringnumber: 1
                bindnetaddr: 10.0.0.0
                mcastaddr: 226.94.6.1
                mcastport: 5406
        }
}

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: on
        }
}

amf {
        mode: disabled
        #mode: enabled
}

rrp_mode passive bewirkt, dass die Informationen vom anderen Knoten abgerufen werden (Poll). Im Vergleich dazu werden bei active die Informationen aktiv an die anderen Knoten übertragen (Push). passive ist die schnellere Übertragungsvariante zwischen den Knoten, active erkennt dafür Fehler schneller.

Multicast-Ports müssen immer 2 auseinander liegen, da bei der Angabe von Port 5404 auch noch der Port 5405 implizit verwendet wird.

Direkt auf der Maschine (nicht per SSH) Keys für Totem erstellen:

corosync-keygen

Hacluster Benutzerpasswort für crmgui setzen:

passwd hacluster

1.4. Inbetriebnahme

Cluster starten:

rcopenais start

1.5. Übersicht der Test-Umgebung

1.5.1. System

Die Arbeits/Testumgebung besteht aus zwei VMWare Server 1 virtualisierten OpenSuSE 11.3 x86 Systemen, Kernel 2.6.34.7:

jake3:~ # cat /etc/SuSE-release
openSUSE 11.3 (i586)
VERSION = 11.3

jake3:~ # uname -r
2.6.34.7-0.7-pae

Die Hosts heißen 'jake3' (erster Knoten) und 'elwood3' (zweiter Knoten).

1.5.2. Netzwerk

Netzwerkkonfiguration für jake3:

jake3:~ # cat /etc/sysconfig/network/ifcfg-eth0
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.50.238/24'
MTU=''
NAME='79c970 [PCnet32 LANCE]'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
jake4:~ # cat /etc/sysconfig/network/ifcfg-eth2
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='10.0.0.238/24'
MTU=''
NAME='79c970 [PCnet32 LANCE]'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'

Für elwood:

elwood3:~ # cat /etc/sysconfig/network/ifcfg-eth1
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='10.0.0.239/24'
MTU=''
NAME='79c970 [PCnet32 LANCE]'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'
elwood3:~ # cat /etc/sysconfig/network/ifcfg-eth3
BOOTPROTO='static'
BROADCAST=''
ETHTOOL_OPTIONS=''
IPADDR='192.168.50.239/24'
MTU=''
NAME='79c970 [PCnet32 LANCE]'
NETWORK=''
REMOTE_IPADDR=''
STARTMODE='auto'
USERCONTROL='no'

1.5.3. Versionen

Versionen des Cluster-Stack:

jake4:~ # rpm -qi openais | egrep "(Version|Release)"
Version : 1.1.2 Vendor: openSUSE
Release : 2.1.1 Build Date: Tue Aug 24 01:25:43 2010
jake4:~ # rpm -qi corosync | egrep "(Version|Release)"
Version : 1.2.1 Vendor: openSUSE
Release : 1.2 Build Date: Mon Jul 5 14:42:41 2010
jake4:~ # rpm -qi pacemaker | egrep "(Version|Release)"
Version : 1.1.2.1 Vendor: openSUSE
Release : 2.1.1 Build Date: Tue Aug 24 01:30:28 2010
jake4:~ # rpm -qi cluster-glue | egrep "(Version|Release)"
Version : 1.0.5 Vendor: openSUSE
Release : 1.4 Build Date: Tue Jul 6 00:03:36 2010

DRBD wird in Version 8.3.7 verwendet:

jake4:~ # rpm -qi drbd | egrep "(Version|Release)"
Version : 8.3.7 Vendor: openSUSE
Release : 2.5 Build Date: Mon Jul 5 23:24:30 2010

OCFS2 liegt in Version 1.4.3 vor:

jake4:~ # rpm -qa | grep ocfs
ocfs2-tools-o2cb-1.4.3-1.4.i586
ocfs2-tools-1.4.3-1.4.i586
ocfs2console-1.4.3-1.4.i586

LVM in Version 2.02.84:

jake4:~ # rpm -qi lvm2 | egrep "(Version|Release)"
Version : 2.02.84 Vendor: obs://build.opensuse.org/Base
Release : 74.1 Build Date: Sat Apr 30 02:21:18 2011
# rpm -qa|grep lvm
lvm2-clvm-2.02.84-74.1.i586
lvm2-2.02.84-74.1.i586

2. Konfiguration

2.1. Cluster-Konfiguration prüfen

Prüfen der Cluster-Konfiguration:

crm_verify -LV

2.2. Globale Einstellungen (Pacemaker Parameter)

#!/bin/bash
crm configure property no-quorum-policy=ignore
crm configure property stonith-enabled=false
crm configure property default-resource-stickiness=100
crm configure property stonith-action=poweroff
# debug:
crm configure show
  • Bei einem Cluster mit nur 2 Knoten macht ein Quorum kein Sinn: no-quorum-policy=ignore
  • default-resource-stickiness=100 ist vergleichbar mit autofailback=false aus den alten heartbeat-Systemen, die Dienste bleiben bei einem Failover beim aktuellen Knoten förmlich "kleben". default-resource-stickiness=0 entspricht autofailback=true.
  • stonith-action=poweroff bewirkt, dass der über STONITH abgeschossene Server auch aus bleibt (standardmäßig fährt der Server wieder hoch = sinnlos).

2.3. Dokumentation der Agenten Parameterisierung

Die verfügbaren Parameter für Agenten bei der Konfiguration von Primitiven (nächster Abschnitt) lassen sich wie folgt ermitteln:

man 7 ocf_heartbeat_IPaddr2
man 7 ocf_heartbeat_apache

2.4. Primitive

IP-Primitive (floating-IP) erstellen:

crm(live)configure# primitive Service_IP ocf:heartbeat:IPaddr2 params ip=192.168.50.240 \
  op monitor interval=10s timout=20s meta target-role=started
crm(live)configure# commit

Agent IPaddr2 verwendet ip und IPaddr ifconfig im Hintergrund. Ersteres ist schneller und bevorzugt.

(SUSE-spezifisch) Apache Status-Modul aktivieren in /etc/sysconfig/apache2:

APACHE_MODULES="actions alias auth_basic authn_file authz_host authz_groupfile authz_default authz_user autoindex cgi dir env expires include log_config mime negotiation setenvif ssl userdir php5 status"
APACHE_EXTENDED_STATUS="on"

Primitive Apache (ocf:heartbeat:apache) anlegen:

primitive myapache2 ocf:heartbeat:apache \
        op monitor interval="10" timeout="20" on-fail="restart" \
        meta migration-threshold="2" \
        params configfile="/etc/apache2/httpd.conf" httpd="/usr/sbin/httpd2-prefork"

2.5. Migration-Threshold und on-fail Action

Für jede Ressource lassen sich ein Grenzwert (Threshold) für eine forcierte Migration und eine Aktion bei einem Fehler festlegen:

primitive myapache2 ocf:heartbeat:apache \
 op monitor interval="10" timeout="20" on-fail="restart" \
 meta migration-threshold="3" \
 params configfile="/etc/apache2/httpd.conf" httpd="/usr/sbin/httpd2-prefork"

In diesem Fall versucht der Cluster, den Apache 2x neuzustarten (on-fail="restart") , wenn ein Fehler auftritt. Beim dritten Mal wird der Apache dann auf einen anderen Knoten migriert (migration-threshold="3").

2.6. Order

Der Apache-Dienst soll nach der IP gestartet werden (order)

order ord_ip_ap : Service_IP myapache2

2.7. Colocation

Die IP-Adresse soll immer auf dem selben Knoten laufen, auf dem auch der Apache-Dienst betrieben wird (colocation):

colocation col_ip_app +inf: Service_IP myapache2

2.8. Clone-Sets

Der Apache soll als "Clone-Set" maximal 2x im Cluster laufen (Knoten=2) und maximal 1x pro Server laufen:

crm configure clone apache_clone myapache2 meta clone-max="2" clone-node-max="1" globally-unique="true"

globally-unique="true" bedeutet, dass der Dienst auf beiden Serverknoten identisch konfiguriert ist.

Vorteil der Clone-Sets ist, dass der Apache nun auf beiden Server schon läuft und im Fehlerfall nur noch die IP-Adresse umgezogen werden muss.

2.9. Groups (am Beispiel von Samba)

In diesem Abschnitt soll an Hand des Samba-Dienstes die Gruppen in Pacemaker veranschaulicht werden. Die folgenden Schritte sind auf beiden Knoten durchzuführen.

Samba konfigurieren mit /etc/samba/smb.conf:

[global]
        workgroup = CLUSTER3
        netbios aliases = server3
[daten]
        path = /daten
        read only = no
        comment = Default-Datenshare auf elwood3/jake3

Vorbereitungen auf dem System:

mkdir /daten
chmod 777 /daten
useradd -m snoopy
smbpasswd -a snoopy

Zwei neue Primitive als LSB-Agenten für die Samba-Dienste einrichten:

crm configure primitive res_nmb lsb::nmb op monitor interval="15" timeout="15" start-delay="15"
crm configure primitive res_smb lsb::smb op monitor interval="15" timeout="15" start-delay="15"

Diese Dienste mit der IP-Adresse in eine Gruppe setzen:

crm configure group samba-group Service_IP res_nmb res_smb

Alle Dienste in einer Gruppe werden in der angegebenen Reihenfolge gestartet (IP, nmb, smb) und gestoppt (smb, nmb, IP). Zudem werden alle Dienste in einer Gruppe auf einem Knoten gestartet, sie sind also mit colocations miteinander verbunden.

2.10. Multi-State-Resource (am Beispiel von DRBD/Samba)

Eine Multi-State-Resource verhält sich wie ein Clone-Set (Klonen von Diensten auf mehreren Knoten gleichzeitig), jedoch unterstützt sie neben den Start- und Stop-Status zusätzlich noch die Status Master und Slave, daher auch der Name "Multi-State".

In diesem Beispiel bereiten wir zunächst eine DRBD-Resource auf beiden Knoten ein.

DRBD auf beiden Knoten mit /etc/drbd.conf konfigurieren:

global {
   dialog-refresh       1;
   minor-count  5;
   usage-count no;
}
common {
}
resource r0 {
   protocol     C;
   disk {
      on-io-error       pass_on;
   }
   syncer {
        rate 100M;
   }
   net {
   }
   startup {
   }
   on jake3 {
      device    /dev/drbd0;
      address   10.0.0.238:7788;
      meta-disk internal;
      disk      /dev/sdb1;
   }
   on elwood3 {
      device    /dev/drbd0;
      address   10.0.0.239:7788;
      meta-disk internal;
      disk      /dev/sdb1;
   }
}

Auf beiden Knoten nacheinander DRBD-Metadaten anlegen, DRBD-Modul laden und DRBD-Resource starten:

drbdadm create-md r0
modprobe drbd
drbdadm up r0

DRBD-Status abrufen. Knoten sind verbunden, jedoch noch inkonsistent, da die Devices noch nicht synchronisiert sind:

# cat /proc/drbd
version: 8.3.7 (api:88/proto:86-92)
srcversion: 04F43AA72D62F7D4F0CB048
 0: cs:Connected ro:Secondary/Secondary ds:Inconsistent/Inconsistent C r----
    ns:0 nr:0 dw:0 dr:0 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:10482024

# drbd-overview
  0:r0  Connected Secondary/Secondary Inconsistent/Inconsistent C r----

Initialen Sync überspringen, da noch keine Daten auf den Devices vorhanden sind, die gesynced werden müssten:

drbdadm -- --clear-bitmap new-current-uuid r0

DRBD-Primary auf einem Knoten setzen:

drbdadm primary r0

Dort ein Dateisystem auf dem DRBD-Device erstellen:

mkfs.ext4 /dev/drbd0

Mounten und Test-Datei anlegen:

mount /dev/drbd0 /daten/
touch /daten/TEST

Die DRBD-Resourcre "r0" als Pacemaker Multi-State-Resource anlegen:

crm configure primitive drbd_r0 ocf:linbit:drbd params drbd_resource="r0" op monitor interval="15s"
crm configure ms ms_drbd_r0 drbd_r0 meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"

Resource für das Mounten und Unmounten des darauf befindlichen Dateisystem erstellen:

crm configure primitive fs_r0 ocf:heartbeat:Filesystem params device="/dev/drbd0" directory="/daten" fstype="ext4"

Eine Gruppe aus IP und Dateisystem erstellen:

crm configure group samba-group fs_r0 Service_IP res_nmb res_smb

Diese Gruppe immer auf dem Knoten mounten, auf dem die DRBD-Resource als Master gesetzt ist:

crm configure colocation samba-group_on_drbd inf: samba-group ms_drbd_r0:Master

Schließlich noch eine Reihenfolge definieren, die besagt, dass erst das DRBD-Device auf Master gesetzt werden muss (promoten), bevor die Samba-Gruppe gestartet werden darf:

crm configure order samba-group_after_drbd inf: ms_drbd_r0:promote samba-group:start

2.11. Konfiguration eines STONITH-Device

Das externe SSH-STONITH-Plugin muss in den meisten Fällen nachinstalliert werden:

zypper install libglue-devel

Wie folgt lassen sich alle STONITH Plugins auflisten:

# stonith -L
** INFO: Cannot get rhcs plugin subplugins
apcmaster
apcmastersnmp
apcsmart
baytech
bladehpi
cyclades
drac3
external/drac5
external/dracmc-telnet
external/hmchttp
external/ibmrsa
external/ibmrsa-telnet
external/ipmi
external/ippower9258
external/kdumpcheck
external/rackpdu
external/riloe
external/sbd
external/ssh
external/vmware
external/xen0
external/xen0-ha
ibmhmc
ipmilan
meatware
null
nw_rpc100s
rcd_serial
rps10
ssh
suicide
wti_mpc
wti_nps

Parameter eines Plugins abfragen:

stonith -t external/ssh -n

SSH-Key auf den Knoten erstellen:

jake3# ssh-keygen -t rsa
jake3# cat /root/.ssh/id_rsa.pub | ssh elwood3 "cat >> .ssh/authorized_keys"
elwood3# ssh-keygen -t rsa
elwood3# cat /root/.ssh/id_rsa.pub | ssh jake3 "cat >> .ssh/authorized_keys"

STONITH Daemon testen - es sollte "Connection to STONITH successful" erscheinen:

/usr/lib/heartbeat/stonith-test -V

Kommunikation zwischen den STONITH Daemons prüfen:

# stonith -t external/ssh hostlist="jake3 elwood3" -S
stonith: external/ssh device OK.

Nun kann man ein STONITH manuell durchführen:

stonith -t ssh -p jake3,elwood3 -T reset elwood3

Abschließend wird das STONITH als Klone auf allen Knoten wie folgt im Cluster konfiguriert:

crm configure primitive stonith stonith:external/ssh op monitor interval=15 timeout=15 start-delay=15 \
  params hostlist="jake3 elwood3"
crm configure clone stonith_clone stonith meta clone clone-max=2 target-role="Started"
crm configure property stonith-enabled="true" stonith-action="reboot" stonith-timeout=30 

Das hier als Beispiel aufgeführte External/SSH-STONITH ist für den Produktiveinsatz nicht geeinigt und empfohlen. Besser ist immer eine Hardwarelösung wie z.B. eine Managementkarte im physikalischen Server (DELL -> DRAC oder HP -> Integrated Lights-Out), mit dem unabhängig von der normalen Netzwerkverbindung der Server "hart" ausgeschaltet werden kann. Eine andere Alternative ist die Nutzung eines Split-Brain-Detector über ein Shared Storage. Die Knoten schreiben dabei kontinuierlich auf ein separate LUN eines Shared Storage. Bleibt der Schreibzugriff eines Knotens länger aus, wird er vom Cluster ausgegrenzt (Nodefencing).

2.12. Spezielle Resourcen und andere Beispiele

2.12.1. Ping-Resource

Ping-Resource erstellen und auf allen Serverknoten klonen:

crm configure primitive pingnet1 ocf:pacemaker:ping params dampen="5s" multiplier="1000" host_list="\"192.168.198.113 192.168.198.114 192.168.198.35\"" op monitor interval="30s"
crm configure clone pingnet_clone pingnet1

Regel definieren: "Auf dem Serverknoten, auf dem pingd gar nicht läuft oder nur eine Punktzahl <= 1000 erreicht, darf Apache2 niemals (-inf) gestartet werden":

crm configure location apache-on-pingnet1 myapache2 rule -inf: not_defined pingd or pingd lte 1000

Aktuellen Punktstand im Cluster ermitteln:

# cibadmin -Q | grep status | grep pingd
          <nvpair id="status-elwood3-pingd" name="pingd" value="3000"/>
          <nvpair id="status-jake3-pingd" name="pingd" value="3000"/>

Wenn wir nun mittels netfilter die ICMP-Pakete auf einem Knoten sperren...:

iptables -A INPUT -p icmp -j DROP

...fallen auch entsprechend die Werte und die Dienste werden auf den Knoten mit in diesem Beispiel 2000 Punkten umgezogen:

# cibadmin -Q | grep status | grep pingd
          <nvpair id="status-elwood3-pingd" name="pingd" value="2000"/>
          <nvpair id="status-jake3-pingd" name="pingd" value="0"/>

2.12.2. Dual-Primary-DRBD mit OCSF2 Cluster-Dateisystem

DRBD-Konfiguration für Multi-Primary-Setup in /etc/drbd.conf:

global {
   dialog-refresh       1;
   minor-count  5;
   usage-count no;
}
common {
}
resource r0 {
   protocol     C;
   handlers {
    split-brain "/usr/lib/drbd/notify-split-brain.sh root";
  }

   disk {
      on-io-error       pass_on;
   }
   syncer {
        rate 100M;
   }
   net {
        allow-two-primaries;
        after-sb-0pri discard-younger-primary;
        after-sb-1pri call-pri-lost-after-sb;
        after-sb-2pri call-pri-lost-after-sb;

   }
   startup {
        become-primary-on both;
   }
   on jake3 {
      device    /dev/drbd0;
      address   10.0.0.238:7788;
      meta-disk internal;
      disk      /dev/sdb1;
   }
   on elwood3 {
      device    /dev/drbd0;
      address   10.0.0.239:7788;
      meta-disk internal;
      disk      /dev/sdb1;
   }
}

Auf beiden Knoten DRBD-Device erstellen, aktivieren und auf Primary setzen:

drbdadm create-md r0
drbdadm up r0
drbdadm primary r0

Beide sind verbunden, auf dem aktuellsten Stand und Primary:

# cat /proc/drbd
version: 8.3.7 (api:88/proto:86-92)
srcversion: 04F43AA72D62F7D4F0CB048
 0: cs:Connected ro:Primary/Primary ds:UpToDate/UpToDate C r----
    ns:0 nr:0 dw:0 dr:208 al:0 bm:0 lo:0 pe:0 ua:0 ap:0 ep:1 wo:b oos:0

DRBD-Primitive und Multi-State-Resource anlegen (master-max="2" bewirkt, dass die DRBD-Resource auf beiden Knoten auf den Master-Status gesetzt werden darf):

crm configure primitive drbd_r0 ocf:linbit:drbd params drbd_resource="r0" op monitor interval="20" role="Master" timeout="60" op monitor interval="30" role="Slave" timeout="60"
crm configure ms ms_drbd_r0 drbd_r0 meta resource-stickiness="100" master-max="2" notify="true" interleave="true"

Die unterschiedlichen Intervalle in der ersten Zeile bewirken, dass die Initialisierung der Rollen nacheinander durchgeführt wird.

Nun erstellen wir eine Primitive für den dlm (distributed lock manager):

crm configure primitive dlm ocf:pacemaker:controld op monitor interval=120s

Aus der Primitiven wird ein Clone-Set erzeugt, so dass der Dienst auf allen Knoten läuft:

crm configure clone dlm-clone dlm meta globally-unique=false interleave=true

Über die Colocation definieren wir, dass der dlm Dienst nur auf den Knoten betrieben wird, auf dem die DRBD-Resource im Master-Status läuft:

crm configure colocation col_dlm_drbd inf: dlm-clone ms_drbd_r0:Master

Schließlich bestimmen wir noch mit einem order, dass erst die DRBD-Resource zum Master promoten sein muss, bevor der dlm gestartet werden kann:

crm configure order ord_drbd_dlm 0: ms_drbd_r0:promote dlm-clone

Parallel zur Einrichtung des dlm wird nun noch der o2cb-Dienst im Pacemaker konfiguriert. Hier gilt, der o2cb wird auf den Knoten gestartet, auf dem auch dlm betrieben wird und o2cb wird nach dlm gestartet:

crm configure primitive o2cb ocf:ocfs2:o2cb op monitor interval=120s
crm configure clone o2cb-clone o2cb meta globally-unique=false interleave=true
crm configure colocation col_o2cb_dlm inf: o2cb-clone dlm-clone
crm configure order ord_o2cb_after_dlm 0: dlm-clone o2cb-clone

In OpenSUSE kann es zu Problemen mit einer zu hohen cluster local id kommen, die dann nicht vom ocfs2 Kernel-Modul unterstützt wird. Folgende Fehlermeldung erscheint in der /var/log/messages:

ocfs2_controld: Error opening control device: I/O error on channel

Dann sollte in der "corosync.conf"-Konfiguration folgender Parameter innerhalb der totem-section eingefügt werden, der bewirkt, dass mit einem führendem Nullbit die cluster local id kleiner ausfällt:

[..]
totem {
[..]
        clear_node_high_bit: yes
        interface {
[..]

Schließlich kann das OCFS2-Dateisystem mit 2 Knoten (-N 2) erstellt werden:

# mkfs.ocfs2 -N 2 /dev/drbd0
mkfs.ocfs2 1.4.3
Cluster stack: pcmk
Cluster name: pacemaker

Wichtig ist, dass als Clusterstack "pcmk" und nicht "o2cb" angezeigt wird, da ansonsten der alte, eigenständige Oracle-Cluster-Stack in Benutzung ist.

Zum Mounten des Cluster-Dateisystems erstellen wir eine neue Pacemaker-Primitive. Das Clone-Set stellt wieder sicher, dass es auf allen Knoten gleichzeitig gestartet, sprich gemounted wird:

crm configure primitive fs ocf:heartbeat:Filesystem params device="/dev/drbd0" directory="/daten" fstype="ocfs2" op monitor interval="120s"
crm configure clone fs-clone fs meta interleave="true" ordered="true"

Mit der folgenden colocation und order wird wieder sichergestellt, dass es auf den selben Knoten gestartet wird, wie die o2cb-Dienste und auch nach dem erfolgreichen Start von o2cb:

crm configure colocation col_fs_o2cb inf: fs-clone o2cb-clone
crm configure order ord_o2cb_fs 0: o2cb-clone fs-clone

2.12.3. Samba-HA mit OpenLDAP auf OCFS2

Auf Basis des im vorherigen Abschnitt eingerichteten Clusterdateisystem OCFS setzen wir nun eine hochverfügbares Samba mit OpenLDAP ein. Die Daten, die von Samba bereitstellt werden, liegen im Clusterdateisystem. Der Inhalt der OpenLDAP-Datenbank wird per OpenLDAP-Replikation zwischen den beiden Knoten abgeglichen.

Floating-IP für ldapmirror3 im Pacemaker einrichten:

crm configure primitive Service_IP ocf:heartbeat:IPaddr2 op monitor interval=3s timeout=5s params ip=192.168.50.240 meta target-role=started

Die folgenden Änderungen auf beiden Knoten durchführen:

/etc/slapd.conf:

include         /etc/openldap/schema/core.schema
include         /etc/openldap/schema/cosine.schema
include         /etc/openldap/schema/nis.schema
include         /etc/openldap/schema/inetorgperson.schema
include         /etc/openldap/schema/samba3.schema

pidfile         /var/run/slapd/slapd.pid
argsfile        /var/run/slapd/slapd.args

modulepath      /usr/lib/openldap/modules
moduleload      syncprov.la

access to dn.base=""
        by * read

access to dn.base="cn=Subschema"
        by * read

access to attrs=userPassword,userPKCS12
        by self write
        by * auth

access to attrs=shadowLastChange
        by self write
        by * read

access to *
        by * read

ServerID        1       "ldap://jake3.local.site"
ServerID        2       "ldap://elwood3.local.site"

database        config
rootdn          cn=config
rootpw          {SSHA}4PvZLcpQ7s1CyQG+yworyl5DcrFTn78q

syncrepl        rid=003
                provider="ldap://jake3.local.site"
                searchbase="cn=config"
                type=refreshAndPersist
                retry="5 +"
                bindmethod=simple
                binddn="cn=config"
                credentials="linux"
                filter="(!(olcDatabase={0}config))"

syncrepl        rid=004
                provider="ldap://elwood3.local.site"
                searchbase="cn=config"
                type=refreshAndPersist
                retry="5 +"
                bindmethod=simple
                binddn="cn=config"
                credentials="linux"
                filter="(!(olcDatabase={0}config))"

overlay syncprov
MirrorMode      On

database        hdb
suffix          "dc=local,dc=site"
rootdn          "cn=ldapadmin,dc=local,dc=site"
rootpw          {SSHA}iLwhoppdqOjJ+0HUroiScDJ3cpbOgo4u
directory       /var/lib/ldap/
index   objectClass     eq
index   entryUUID,entryCSN eq

overlay         syncprov
syncprov-checkpoint 10 1
syncprov-sessionlog 100

limits dn.exact="cn=replicator,dc=local,dc=site"
   size=unlimited time=unlimited

access to *
   by dn.exact="cn=replicator,dc=local,dc=site" read
   by * break

syncrepl        rid=001
                provider="ldap://jake3.local.site"
                type=refreshAndPersist
                retry="5 +"
                searchbase="dc=local,dc=site"
                bindmethod=simple
                binddn="cn=replicator,dc=local,dc=site"
                credentials="linux"

syncrepl        rid=002
                provider="ldap://elwood3.local.site"
                type=refreshAndPersist
                retry="5 +"
                searchbase="dc=local,dc=site"
                bindmethod=simple
                binddn="cn=replicator,dc=local,dc=site"
                credentials="linux"

MirrorMode      On

/etc/openldap/ldap.conf:

BASE    dc=local,dc=site
URI ldap://ldapmirror3.local.site

Zusätzlicher Eintrag in der /etc/hosts für die floating-IP:

192.168.50.240  ldapmirror3.local.site ldapmirror3

Konfigurationsorder initialisieren:

slaptest -f /etc/openldap/slapd.conf -F /etc/openldap/slapd.d/ -d 1

/etc/sysconfig/openldap:

OPENLDAP_CONFIG_BACKEND="ldap"

Rechte für den Konfigurationsordner anpassen:

chown -R ldap:ldap /etc/openldap/slapd.d/

OpenLDAP starten und offenen LDAP-Port prüfen:

rcldap start

netstat -tulpen | grep 389

Erste Datensätze importieren:

ldapadd -xWD cn=ldapadmin,dc=local,dc=site -H ldap://jake3 -f samba-base.ldif

samba-base.ldif:

dn: dc=local,dc=site
objectClass: dcObject
objectClass: Organization
dc: local
o: Brainstorm

dn: cn=replicator,dc=local,dc=site
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: replicator
userPassword: {SSHA}Kq2vTqyFSopY7N1MRGBBtLrY1U2EPwri

dn: cn=ldapadmin,dc=local,dc=site
objectClass: organizationalRole
objectClass: simpleSecurityObject
cn: ldapadmin
userPassword: {SSHA}pQioyEKuaVCAcYrN0GqefhwzNRf7Ikze

dn: ou=users,dc=local,dc=site
objectClass: organizationalUnit
ou: users

dn: ou=groups,dc=local,dc=site
objectClass: organizationalUnit
ou: groups

dn: ou=idmap,dc=local,dc=site
objectClass: organizationalUnit
ou: idmap

dn: ou=computers,dc=local,dc=site
objectClass: organizationalUnit
ou: computers

Mittels Replikation müssten jetzt auf beiden Knoten die selben Daten verfügbar sein:

ldapsearch -x cn=replicator -H ldap://jake3
ldapsearch -x cn=replicator -H ldap://elwood3

Nun wird der Samba in *"/etc/samba/smb.conf" konfiguriert:

[global]
workgroup = CLUSTER3
netbios aliases = server3

domain logons = yes
domain master = yes
local master = yes
preferred master = yes
os level = 65

log level = 3

passdb backend = ldapsam:ldap://ldapmirror3.local.site
ldapsam:trusted = yes
ldapsam:editposix = yes
ldap admin dn = cn=ldapadmin,dc=local,dc=site
ldap suffix = dc=local,dc=site
ldap user suffix = ou=users
ldap group suffix = ou=groups
ldap idmap suffix = ou=idmap
ldap machine suffix = ou=computers
ldap passwd sync = Yes
ldap ssl = no

idmap backend = ldap:ldap://ldapmirror3.local.site
idmap uid = 1000000-1999999
idmap gid = 1000000-1999999
idmap alloc backend = ldap
idmap alloc config:ldap_base_dn = ou=idmap,dc=local,dc=site
idmap alloc config:ldap_user_dn = cn=ldapadmin,dc=local,dc=site
idmap alloc config:ldap_url     = ldap://ldapmirror3.local.site/

[daten]
        path = /daten
        read only = no
        comment = Default-Datenshare auf JAKE3

/etc/ldap.conf:

host    ldapmirror3.local.site

Passwort für die Kommunikation zwischen Samba und OpenLDAP konfigurieren:

# smbpasswd -w linux
Setting stored password for "cn=ldapadmin,dc=local,dc=site" in secrets.tdb
# net idmap secret alloc linux
Secret stored

Name Service Cache Daemon stoppen und Winbind starten:

rcnscd stop
rcwinbind start

Rudimentäre NT4 PDC-Struktur erstellen:

net sam provision

Passwort für den Administrator erstellen, dieses wird im OpenLDAP abgelegt und zwischen den beiden Knoten repliziert:

smbpasswd Administrator

Samba starten:

rcnmb start && rcsmb start

Wir gewähren dem Administrator volle Domainadminrechte:

net rpc rights grant Administrator seAddUsersPrivilege -U Administrator
net rpc rights grant Administrator seMachineAccountPrivilege -U Administrator

Nun erstellen wir für unsere 4 Dienste neue Primitiven, setzen diese in eine Gruppe und klonen sie auf alle Clusterknoten:

crm configure primitive ldap lsb:ldap op monitor interval="15" timeout="15" start-delay="5"
crm configure primitive nmb lsb:nmb op monitor interval="15" timeout="15" start-delay="15"
crm configure primitive smb lsb:smb op monitor interval="15" timeout="15" start-delay="15"
crm configure primitive winbind lsb:winbind op monitor interval="15" timeout="15" start-delay="15"
crm configure group samba-group ldap winbind nmb smb
crm configure clone samba-clone samba-group meta target-role="Started"

2.12.4. DRBD Dual Primary mit OCFS2 und CLVM

/etc/lvm/lvm.conf:

locking_type = 3

Lock-Manager und Cluster LVM-Daemon in Gruppe, geklont auf beiden Knoten erstellen. Mit order sicherstellen, dass DRBD zu erst als Master promotet wurde:

crm configure primitive dlm ocf:pacemaker:controld
crm configure primitive clvm ocf:lvm2:clvmd params daemon_timeout="30"
crm configure group dlm-clvm dlm clvm
crm configure clone dlm-clvm-clone dlm-clvm meta interleave="true" ordered="true"

crm configure order ord_drbd_cluster_fs inf: ms_drbd_r0:promote dlm-clvm-clone

LVM-PV auf DRBD-Device, geclusterte VG1 auf PV und schließlich 5GB große LV in VG1 erstellen:

pvcreate /dev/drbd0
vgcreate --clustered y VG1 /dev/drbd0
lvcreate -L 5GB -n LV1 VG1

VG1 im Cluster geklont auf allen Knoten konfigurieren:

crm configure primitive vg1 ocf:heartbeat:LVM params volgrpname="VG1"
crm configure clone vg1-clone vg1 meta interleave="true" ordered="true"

Oracle Pacemaker Clusterstack hinzufügen, Reihenfolge der Dienste dlm, clvm, o2cb und vg1 konfigurieren:

crm configure primitive o2cb ocf:ocfs2:o2cb op monitor interval=120s
crm configure clone o2cb-clone o2cb meta globally-unique=false interleave=true
crm configure order ord_o2cb_after_dlm-clvm 0: dlm-clvm-clone o2cb-clone
crm configure order ord_vg1_after_o2cb inf: o2cb-clone vg1-clone

Oracle Cluster Filesystem erstellen:

mkfs.ocfs2 -N2 /dev/VG1/LV1

Schließlich noch das Dateisystem ins Cluster aufnehmen:

crm configure primitive fs ocf:heartbeat:Filesystem params device="/dev/VG1/LV1" directory="/daten" fstype="ocfs2" op monitor interval="120s"
crm configure clone fs-clone fs meta interleave="true" ordered="true"
crm configure order ord_fs-clone_after_vg1-clone inf: vg1-clone fs-clone

Alternativ kann auch folgende einfachere Konfiguration mit einer Gruppe angewendet werden:

primitive drbd_r0 ocf:linbit:drbd \
        params drbd_resource="r0" \
        op monitor interval="20" role="Master" timeout="60" \
        op monitor interval="30" role="Slave" timeout="60" \
        meta is-managed="true"
primitive dlm ocf:pacemaker:controld
primitive clvm ocf:lvm2:clvmd \
        params daemon_timeout="30"
primitive o2cb ocf:ocfs2:o2cb \
        op monitor interval="120s"
primitive vg1 ocf:heartbeat:LVM \
        params volgrpname="VG1" \
        meta is-managed="true"
primitive fs ocf:heartbeat:Filesystem \
        params device="/dev/VG1/LV1" directory="/daten" fstype="ocfs2" \
        op monitor interval="120s" \
        meta target-role="started"

ms ms_drbd_r0 drbd_r0 \
        meta resource-stickiness="100" master-max="2" notify="true" interleave="true" is-managed="true" target-role="started"

group cluster_fs dlm clvm o2cb vg1 fs
clone cluster_fs-clone cluster_fs \
        meta interleave="true" ordered="true"

order ord_drbd_cluster_fs inf: ms_drbd_r0:promote cluster_fs-clone

Live Vergößern des Clustered LVMs und des OCFS2-Dateisystems:

lvextend -v -L+2GB VG1/LV1
tunefs.ocfs2 -S /dev/VG1/LV1

2.12.5. HA ISCSI-Target

Die Konfiguration ist noch fehlerhaft und muss noch überarbeitet werden. Bitte nicht verwenden.

Wieder eine Standard Master/Slave-DRBD-Konfiguration auf beiden Knoten mit /etc/drbd.conf:

global {
   dialog-refresh       1;
   minor-count  5;
   usage-count no;
}
common {
}
resource r0 {
   protocol     C;
   disk {
      on-io-error       pass_on;
   }
   syncer {
        rate 100M;
   }
   net {
   }
   startup {
   }
   on jake3 {
      device    /dev/drbd0;
      address   10.0.0.238:7788;
      meta-disk internal;
      disk      /dev/sdb1;
   }
   on elwood3 {
      device    /dev/drbd0;
      address   10.0.0.239:7788;
      meta-disk internal;
      disk      /dev/sdb1;
   }
}

Auf beiden Knoten Metadaten erstellen, aktivieren, sync überspringen:

drbdadm create-md r0
drbdadm up r0
drbdadm -- --clear-bitmap new-current-uuid r0

Auf einem Knoten Master setzen und Dateisysteme erstellen:

drbdadm primary r0
mkfs.ext4 /dev/drbd0

DRBD in typischer Master/Slave-Konfiguration in Pacemaker hinterlegen:

crm configure primitive drbd_r0 ocf:linbit:drbd params drbd_resource="r0" op monitor interval="15s"
crm configure ms ms_drbd_r0 drbd_r0 meta master-max="1" master-node-max="1" clone-max="2" clone-node-max="1" notify="true"

Auf beiden Knoten ISCSI-Pakete unter OpenSUSE nachinstallieren:

zypper install iscsitarget iscsitarget-kmp-pae

Wieder auf beiden Knoten die ISCSI-Target-Konfiguration "/etc/ietd.conf" anpassen:

Target iqn.2010-08.site.local:dev.drbd0
   Lun 0 Path=/dev/drbd0,Type=fileio

Clone-Set für den ISCSI-Target Daemon einrichten:

crm configure primitive ietd lsb:iscsitarget op monitor interval="15" enabled="true" start-delay="0" role="Started" timeout="15" on-fail="restart"
crm configure clone ietd_clone ietd

Primitiven für floating IP, ISCSI-Konfiguration (itarget und ilun) erstellen, diese in eine Gruppe setzen. Über colocation und order sicherstellen, dass der ISCSI-Dienst auf dem Knoten betrieben wird, auf dem DRBD auf Master läuft und die richtige Start- und Stopreihenfolge (drbd -> ietd -> iscsi) eingehalten wird:

crm configure primitive Service_IP ocf:heartbeat:IPaddr2 params ip="192.168.50.240"
crm configure primitive itarget ocf:heartbeat:iSCSITarget params iqn="iqn.2010-08.site.local:dev.drbd0"
crm configure primitive ilun ocf:heartbeat:iSCSILogicalUnit op monitor interval="15" enabled="true" start-delay="2" role="Started" timeout="10" on-fail="restart" params target_iqn="iqn.2010-08.site.local:dev.drbd0" lun="0" path="/dev/drbd0"
crm configure group iscsi_group itarget ilun Service_IP
crm configure colocation col_iscsi_drbd inf: iscsi_group:Started ms_drbd_r0:Master
crm configure order ord_ietd_iscsigroup inf: ietd_clone iscsi_group
crm configure order ord_iscsi_drbd inf: ms_drbd_r0:promote iscsi_group:start

2.12.6. Snapshots eines OCFS2-Dateisystems unter LVM und Dual-Primary DRBD

Dual-Primary /etc/drbd.conf:

global {
   dialog-refresh       1;
   minor-count  5;
   usage-count no;
}
common {
}
resource r0 {
   protocol     C;
   handlers {
    split-brain "/usr/lib/drbd/notify-split-brain.sh root";
  }

   disk {
      on-io-error       pass_on;
   }
   syncer {
        rate 100M;
   }
   net {
        allow-two-primaries;
        after-sb-0pri discard-younger-primary;
        after-sb-1pri call-pri-lost-after-sb;
        after-sb-2pri call-pri-lost-after-sb;

   }
   startup {
        become-primary-on both;
   }
   on jake3 {
      device    /dev/drbd0;
      address   10.0.0.238:7788;
      meta-disk internal;
      disk      /dev/sdb1;
   }
   on elwood3 {
      device    /dev/drbd0;
      address   10.0.0.239:7788;
      meta-disk internal;
      disk      /dev/sdb1;
   }
}

Dual-Primary DRBD in Pacemaker konfigurieren:

crm configure primitive drbd_r0 ocf:linbit:drbd params drbd_resource="r0" op monitor interval="20" role="Master" timeout="20" op monitor interval="30" role="Slave" timeout="20"
crm configure ms ms_drbd_r0 drbd_r0 meta resource-stickiness="100" master-max="2" notify="true" interleave="true"

LVM auf DRBD erstellen:

pvcreate /dev/drbd0
vgcreate VG1 /dev/drbd0
lvcreate -L 9GB -n LV1 VG1

Dienste für Locking und OCFS2 als geklonte Gruppe in Pacemaker konfigurieren:

primitive dlm ocf:pacemaker:controld op monitor interval="120s"
primitive o2cb ocf:ocfs2:o2cb op monitor interval="120s"
group dp_group dlm o2cb
clone clone_dp_group dp_group

Falls auf einem der Knoten die LVs nicht verfügbar sind, folgende Schritte durchführen:

vgscan
vgchange -a y

OCFS2 erstellen:

mkfs.ocfs2 -N2 /dev/VG1/LV1

Dateisystem erstellen und mit in die Gruppe dp_group aufnehmen:

primitive fs ocf:heartbeat:Filesystem op monitor interval=120s params device=/dev/VG1/LV1 fstype=ocfs2 directory=/daten
edit dp_group

Testdaten erzeugen

dd if=/dev/zero of=/daten/trash bs=1M count=50

Snapshot erzeugen:

lvcreate -L 300MB -s -n SNAP VG1/LV1

Weitere Testdaten erzeugen

dd if=/dev/zero of=/daten/trash2 bs=1M count=50

Status des OCFS2-Dateisystem kann wie folgt geprüft werden:

# mounted.ocfs2 -d

Device                FS     Stack  UUID                              Label
/dev/mapper/VG1-LV1   ocfs2  pcmk   58C7D55153EC42E5A78A1B21DC674D5F
/dev/mapper/VG1-SNAP  ocfs2  pcmk   58C7D55153EC42E5A78A1B21DC674D5F
/dev/mapper/VG1-LV1-real  ocfs2  pcmk   58C7D55153EC42E5A78A1B21DC674D5F

Das Problem ist nun, dass der OCFS2-Snapshot nicht gemounted werden kann:

# mount /dev/VG1/SNAP /test
mount.ocfs2: Configuration error discovered while trying to join the group

Dafür muss die UUID des Snapshot angepasst und als geklont markiert werden:

# tunefs.ocfs2 --cloned-volume /dev/VG1/SNAP
Updating the UUID and label on cloned volume "/dev/VG1/SNAP".
DANGER: THIS WILL MODIFY THE UUID WITHOUT ACCESSING THE CLUSTER SOFTWARE.  YOU MUST BE ABSOLUTELY SURE THAT NO OTHER NODE IS USING THIS FILESYSTEM BEFORE MODIFYING ITS UUID.
Update the UUID and label? yes

# mounted.ocfs2 -d
Device                FS     Stack  UUID                              Label
/dev/mapper/VG1-LV1   ocfs2  pcmk   58C7D55153EC42E5A78A1B21DC674D5F
/dev/mapper/VG1-SNAP  ocfs2  pcmk   0E0F9EB4CD394F1EB33A1B32A4886F27  -cloned
/dev/mapper/VG1-LV1-real  ocfs2  pcmk   58C7D55153EC42E5A78A1B21DC674D5F

# mount /dev/VG1/SNAP /test

2.12.7. Xen Live-Migration mit DRBD

Folgende Anleitung basiert auf dem vorherigen Kapitel mit OCFS2.

Netzwerkkartenreihenfolge und -belegung auf beiden Knoten angleichen:

# cd /etc/sysconfig/network
# mv ifcfg-eth3 ifcfg-eth0
# vi /etc/udev/rules.d/70-persistent-net.rules
NAME="eth3" --> NAME="eth0"

System mit Xen-Kernel neustarten.

LVM deaktivieren:

chkconfig -d boot.lvm

DRBD-Module automatisch laden lassen in /etc/sysconfig/kernel:

MODULES_LOADED_ON_BOOT="drbd"

Primitive für LVM einrichten und in Gruppe einfügen:

primitive lvm ocf:heartbeat:LVM params volgrpname=VG1 op monitor interval=30s timeout=30s
edit dp_group

Die Gruppe sollte nach dem Editieren wie folgt ausschauen:

group dp_group dlm o2cb lvm fs

/etc/xen/xend-config.sxp:

(xend-http-server yes)
(xend-unix-server yes)

(xend-relocation-server yes)
(xend-port            8000)
(xend-relocation-port 8002)
(xend-relocation-address '')
(xend-relocation-hosts-allow '^localhost$ ^localhost\\.localdomain$ elwood3 jake3')

(network-script network-bridge)
(vif-script vif-bridge)

(dom0-min-mem 512)
(enable-dom0-ballooning yes)
(dom0-cpus 0)

(vnc-listen '0.0.0.0')
(vncpasswd '')

Xen-Daemon neustarten:

rcxend restart

Pakete nachinstallieren:

zypper install libvirt openssh-askpass-gnome

Wir legen eine vorbereite OpenSUSE11-VM als Xen-VM ab:

# ls -la /daten/xen/oss113xen/
total 8388620
drwxr-xr-x 2 root root       3896 Oct 21 14:08 .
drwxr-xr-x 3 root root       3896 Oct 21 13:47 ..
-rw-r--r-- 1 root root      12288 Oct 21 14:08 .oss113xen.swp
-rw-r--r-- 1 root root        458 Oct 21 13:47 oss113xen
-rw-r--r-- 1 root root       1202 Oct 21 13:46 oss113xen.xml
-rw-r--r-- 1 root root 8589934592 Oct 21 13:46 xvda

Und verlinken die dortige Konfiguration aus dem OCFS2-Dateisystem (/daten) in das lokale "etc"-Verzeichnis:

ln -s /daten/xen/oss113xen/oss113xen /etc/xen/vm/oss113xen

Die Xen-Konfiguration oss113xen stellt sich wiefolgt dar:

name="oss113xen"
description="None"
uuid="51322fc4-a8bc-9eb3-8cbd-913032a07ad0"
memory=512
maxmem=512
vcpus=1
on_poweroff="destroy"
on_reboot="restart"
on_crash="destroy"
localtime=0
keymap="de"
builder="linux"
bootloader="/usr/bin/pygrub"
bootargs=""
extra=" "
disk=[ 'file:/daten/xen/oss113xen/xvda,xvda,w' ]
vif=[ 'mac=00:16:3e:5f:6f:a0,bridge=eth0', ]
vfb=['type=vnc,vncunused=1']

Melden die neue Xen-Konfiguration an:

xm new oss113xen

Live-Migration testen, indem wir die VM auf jake3 starten und dann auf elwood3 livemigrieren:

xm create oss113xen
xm migrate --live oss113xen elwood3

Schließlich können wir eine Primitive für das Management der Xen Domain in Pacemaker einrichten:

crm configure primitive oss113xen ocf:heartbeat:Xen meta target-role="started" allow-migrate="true" op monitor interval="10" op start interval="0" timeout="45" op stop interval="0" timeout="300" op migrate_from interval="0" timeout="240" op migrate_to interval="0" timeout="240" params xmfile="/etc/xen/vm/oss113xen" name="oss113xen"

Wichtig sind die hohen Timeout-Werte für die Migration, da diese sonst bei den Default-Werten fehlschlägt.

3. Verwaltung

3.1. Resourcen migrieren

Resource Service_IP von aktuell Knoten elwood3 auf jake3 migrieren:

crm(live)# resource
crm(live)resource# migrate Service_IP jake3

Migration wird an Hand einer automatisch eingetragenen Location-Regel durchgeführt:

location cli-prefer-Service_IP Service_IP \
        rule $id="cli-prefer-rule-Service_IP" inf: #uname eq jake3

Rückgängig machen mit dem Befehl "unmigrate" oder dem Löschen der Location-Regel.

3.2. Manuellen Failover durchführen

Knoten deaktivieren und damit Failover aller Dienste auf andere Knoten durchführen:

crm(live)# node
crm(live)node# standby elwood3

Wieder reaktivieren, Dienste bleiben aber auf den anderen Knoten (s. default-resource-stickiness):

crm(live)node# online elwood3

3.3. Fehlerstand kontrollieren und zurücksetzen

Fehlerstand (fail-count) des Clusterknotens jake3 ermitteln:

crm resource failcount myapache2 show jake3

oder

cibadmin -Q | grep status-jake3 | grep fail-count

Hier ist z.B. der max-failcount erreicht:

crm_verify -LV
crm_verify[20335]: 2011/10/17_15:29:53 WARN: unpack_rsc_op: Processing failed op myapache2_start_0 on elwood3: unknown exec error (-2)
crm_verify[20335]: 2011/10/17_15:29:53 WARN: unpack_rsc_op: Processing failed op myapache2_start_0 on jake3: unknown exec error (-2)
crm_verify[20335]: 2011/10/17_15:29:53 WARN: common_apply_stickiness: Forcing myapache2 away from elwood3 after 1000000 failures (max=1000000)
crm_verify[20335]: 2011/10/17_15:29:53 WARN: common_apply_stickiness: Forcing myapache2 away from jake3 after 1000000 failures (max=1000000)

Fehlerstand zurücksetzen:

crm resource cleanup myapache2

oder

crm resource failcount myapache2 set jake3 0

oder

crm_resource -C -r myapache2

3.4. Kopie der CIB erstellen und damit arbeiten

Neue erstellen:

crm(live)cib# new shadow
INFO: shadow shadow CIB created

oder bestehende benutzen:

crm(live)cib# use shadow

Shadow-Konfiguration commiten, die Shadow- und Live-Konfiguration werden dann gemergt:

cib commit shadow

3.5. Konfigurationsanpassungen grafisch prüfen

ptest

3.6. CIB-Templates

templates
list templates

3.7. Status der Corosync-Ringe prüfen

# corosync-cfgtool -s
Printing ring status.
Local node ID -298669888
RING ID 0
        id      = 192.168.50.238
        status  = ring 0 active with no faults
RING ID 1
        id      = 10.0.0.238
        status  = ring 1 active with no faults

3.8. Corosync-Ringe zurücksetzen

Falls ein Ring als fehlerhaft (faulty) markiert wurde und damit nicht mehr genutzt wird, kann man diese wie folgt versuchen zu restorieren:

# corosync-cfgtool -r

3.9. Debug-Informationen von Corosync/Totem abrufen

# corosync-objctl runtime.totem
runtime.pg.mrp.srp.orf_token_tx=4
runtime.pg.mrp.srp.orf_token_rx=106187
runtime.pg.mrp.srp.memb_merge_detect_tx=40736
runtime.pg.mrp.srp.memb_merge_detect_rx=40736
runtime.pg.mrp.srp.memb_join_tx=3
runtime.pg.mrp.srp.memb_join_rx=8
runtime.pg.mrp.srp.mcast_tx=792
runtime.pg.mrp.srp.mcast_retx=19
runtime.pg.mrp.srp.mcast_rx=2980
runtime.pg.mrp.srp.memb_commit_token_tx=9
runtime.pg.mrp.srp.memb_commit_token_rx=7
runtime.pg.mrp.srp.token_hold_cancel_tx=181
runtime.pg.mrp.srp.token_hold_cancel_rx=605
runtime.pg.mrp.srp.operational_entered=3
runtime.pg.mrp.srp.operational_token_lost=0
runtime.pg.mrp.srp.gather_entered=3
runtime.pg.mrp.srp.gather_token_lost=0
runtime.pg.mrp.srp.commit_entered=3
runtime.pg.mrp.srp.commit_token_lost=0
runtime.pg.mrp.srp.recovery_entered=3
runtime.pg.mrp.srp.recovery_token_lost=0
runtime.pg.mrp.srp.consensus_timeouts=0
runtime.pg.mrp.srp.mtt_rx_token=189
runtime.pg.mrp.srp.avg_token_workload=43662614
runtime.pg.mrp.srp.avg_backlog_calc=0
runtime.pg.mrp.srp.rx_msg_dropped=0

4. Management-Tools

4.1. Pacemaker CRM-Shell

CRM-Shell aufrufen:

crm

Clusterkonfiguration bearbeiten:

crm conf

Verschiedene Befehle:

crm(live)configure# edit 
crm(live)configure# edit resource
crm(live)configure# delete

4.2. CRM Kommandozeilentools

Gut zum Scripten sind die Kommandozeilentools, die teilweise über bestimmte Parameter zusätliche Möglichkeiten der Verwaltung bieten:

# crm_
crm_attribute  crm_failcount  crm_master     crm_node       crm_shadow     crm_standby    crm_verify
crm_diff       crm_gui        crm_mon        crm_resource   crm_simulate   crm_uuid

4.3. Grafische Pacemaker GUI

Die grafische Pacemaker GUI verbindet sich über folgenden, auf allen IPs lauschenden TCP-Port mit dem Managementdienst (mgmtd):

tcp        0      0 0.0.0.0:5560            0.0.0.0:*               LISTEN      0          49960      7039/mgmtd

4.4. CRM-Monitor

CRM-Monitor aufrufen (-n gruppiert Ressourcen nach Cluster-Knoten):

crm_mon -n

Nützliche Parameter:

 -f, --failcounts               Display resource fail counts
 -o, --operations               Display resource operation history

4.5. Andere Tools

5. Hinweise

  • Änderungen an der Clusterkonfiguration niemals über cib(admin) durchführen
    • Höchstens für vollständige Backups und Wiederherstellung kann es verwendet werden.
    • Lieber die crmshell oder crmgui nutzen. Beide werden von den Pacemaker-Machern entwickelt und sind am aktuellsten. Die Shell hat jedoch die meisten Funktionen.
  • Man sollte keine laufenden Resourcen löschen, da es sonst zu "orphaned resource" (verweiste Einträge) kommen kann. CIB-Status prüfen mit "crm_verify -LV"
  • Jede Änderung wird erst von der policy engine an Hand der globalen Regeln geprüft (Prozess: pengine), dann geht die Änderung zur transition engine auf dem designated coordinator (DC), schließlich wird die Änderung vom local resource manager (Prozess: lrmd) auf dem entsprechenden Knoten propagiert. Der ganze Vorgang kann etwas dauert. In dieser Zeit sollte nicht unnötig refresh oder cleanup durchgeführt werden.
  • Bei Problemen als erstes die Cluster-Konfiguration mit "crm_verify -LV" prüfen. Hier gibt es häufig Hinweise auf die Ursache der Probleme.

6. Wichtige Pfade

  • Agent-Skripte (heartbeat, OCF, stonith): /usr/lib/ocf/resource.d
  • CIB-Datenbank: /var/lib/heartbeat/crm/

7. Backup der Cluster-Konfiguration

Aktueller Stand der Konfiguration aus dem Speicher:

cibadmin -Q > cluster-XYZ.xml 

XML-Konfigurationen im Verzeichnissen (nicht manuell bearbeiten!):

/var/lib/heartbeat/crm/

8. Weitere Dokumentationen

  File Modified
PDF File corosync-kernel-org-ols2008v1-pages-85-100.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File corosync-datasheet-2009.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File book_sleha.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File Cluster_from_Scratch.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File Cluster_Logical_Volume_Manager.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File ha_ordering_explained.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File ha_fencing_and_stonith.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File Crm_cli.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File gfs2.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File ha_colocation_explained.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File stor_admin.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File Pacemaker-1.1-Pacemaker_Explained-en-US.pdf 20. Oct 2011 by Benjamin Kendinibilir
PDF File ha_pacemaker_openais_config.pdf 20. Oct 2011 by Benjamin Kendinibilir

9. Quellen

  • No labels