[root@logos root]# /etc/init.d/heartbeat start
Starting High-Availability services:
[ OK ]
Der Status der Kolab-Dienste kann mittels einer Prozessabfrage überprüft werden:
[root@logos root]# ps -afe |grep kolab
root 31926 1 0 15:55 ? 00:00:00 /kolab/libexec/openldap/slapd
root 31930 1 0 15:55 ? 00:00:00 /kolab/libexec/openldap/slurpd
root 32031 1 0 15:55 ? 00:00:00 /kolab/sbin/saslauthd -a ldap -n 2
root 32035 32031 0 15:55 ? 00:00:00 /kolab/sbin/saslauthd -a ldap -n 2
root 32133 1 0 15:55 ? 00:00:00 /kolab/sbin/apache
kolab-r 32231 1 0 15:55 ? 00:00:00 /kolab/bin/cyrmaster
kolab-n 32526 32133 0 15:55 ? 00:00:00 /kolab/sbin/apache
kolab-n 32527 32133 0 15:55 ? 00:00:00 /kolab/sbin/apache
kolab-n 32528 32133 0 15:55 ? 00:00:00 /kolab/sbin/apache
kolab-n 32529 32133 0 15:55 ? 00:00:00 /kolab/sbin/apache
kolab-n 32530 32133 0 15:55 ? 00:00:00 /kolab/sbin/apache
root 332 1 0 15:55 ? 00:00:00 /kolab/libexec/postfix/master
kolab 336 332 0 15:55 ? 00:00:00 pickup -l -t fifo -u
kolab 337 332 0 15:55 ? 00:00:00 qmgr -l -t fifo -u
kolab-n 433 1 0 15:55 ? 00:00:00 proftpd: (accepting connections)
root 532 1 1 15:55 ? 00:00:00 /kolab/bin/perl /kolab/sbin/kolabd
kolab-r 541 32231 0 15:55 ? 00:00:00 imapd -C /kolab/etc/imapd/imapd.conf
kolab-r 546 32231 0 15:55 ? 00:00:00 imapd -C /kolab/etc/imapd/imapd.conf
root 547 532 0 15:55 ? 00:00:00 /kolab/bin/perl /kolab/sbin/kolabd
root 548 532 0 15:55 ? 00:00:00 /kolab/bin/perl /kolab/sbin/kolabd
überpüfung der eingehängten Ressource mit Hilfe des Befehls mount:
[root@logos root]# mount
[...]
/dev/sdb1 on /kolab type ext3 (rw)
überprüfung auf die aktivierte Cluster IP-Adresse:
[root@logos root]# ifconfig -a
[...]
eth0:0 Link encap:Ethernet HWaddr [...]
inet addr:10.20.30.3 Bcast:10.20.30.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 b) TX bytes:0 (0.0 b)
Interrupt:18 Memory:f6410000-f6420000
[...]
Zusätzlich ist eine überprüfung der belegten Ports sinnvoll; die Vorgehensweise wurde bereits in Kapitel 4.2.4 erläutert. Eine zusätzliche Informationsquelle zur überprüfung der Clusterfunktionalität bietet das heartbeat-Ereignisprotokoll /var/""log/""ha-log:
[...] info: **************************
[...] info: Configuration validated. Starting heartbeat 1.0.4
[...] info: nice_failback is in effect.
[...] info: heartbeat: version 1.0.4
[...] info: Heartbeat generation: 13
[...] info: Starting serial heartbeat on tty /dev/ttyS0 (19200 baud)
[...] info: UDP Broadcast heartbeat started on port 694 (694) interface eth1
[...] info: UDP multicast heartbeat started for group 225.0.0.7 port 694 interface
eth1 (ttl=1 loop=1)
[...]
[...] info: Local status now set to: 'up'
[...] info: pid 31491 locked in memory.
[...] info: pid 31483 locked in memory.
[...] info: Link logos.matrix.com:eth1 up.
[...] info: Link logos.matrix.com:eth1 225.0.0.7 694 1 1 up.
[...] WARN: node osiris.matrix.com: is dead
[...] WARN: No STONITH device configured.
[...] WARN: Shared resources (storage!- ) are not protected!-
[...] info: Resources being acquired from osiris.matrix.com.
[...] info: Local status now set to: 'active'
[...] Running /etc/ha.d/rc.d/status status
[...] info: /usr/lib/heartbeat/mach_down: nice_failback: acquiring foreign
resources
[...] info: mach_down takeover complete.
[...] info: mach_down takeover complete for node osiris.matrix.com.
[...] info: Resource acquisition completed.
[...] info: Running /etc/ha.d/rc.d/ip-request-resp ip-request-resp
[...] received ip-request-resp 10.20.30.3/24/eth0 OK yes
[...] info: Acquiring resource group: logos.matrix.com 10.20.30.3/24/eth0
Filesystem::/dev/sdb1::/kolab::ext3 kolab
[...] info: Running /etc/ha.d/resource.d/IPaddr 10.20.30.3/24/eth0 start
[...] info: /sbin/ifconfig eth0:0 10.20.30.3 netmask 255.255.255.0 broadcast
10.20.30.255
[...] info: Sending Gratuitous Arp for 10.20.30.3 on eth0:0 [eth0]
[...] /usr/lib/heartbeat/send_arp eth0 10.20.30.3 0030054625AD 10.20.30.3
ffffffffffff
[...] info: Running /etc/ha.d/resource.d/Filesystem /dev/sdb1 /kolab ext3 start
[...] info: Running /etc/init.d/kolab start
[...] /usr/lib/heartbeat/send_arp eth0 10.20.30.3 0030054625AD 10.20.30.3
ffffffffffff
[...] /usr/lib/heartbeat/send_arp eth0 10.20.30.3 0030054625AD 10.20.30.3
ffffffffffff
[...] /usr/lib/heartbeat/send_arp eth0 10.20.30.3 0030054625AD 10.20.30.3
ffffffffffff
[...] /usr/lib/heartbeat/send_arp eth0 10.20.30.3 0030054625AD 10.20.30.3
ffffffffffff
[...] info: Local Resource acquisition completed. (none)
[...] info: local resource transition completed.
[...] WARN: TTY write timeout on [/dev/ttyS0] (no connection or bad cable?
[see documentation])
Nun kann auf dem zweiten Clusterknoten ebenfalls der heartbeat-Dienst gestartet werden:
[root@osiris root]# /etc/init.d/heartbeat start
Starting High-Availability services:
[ OK ]
Im heartbeat-Ereignisprotokoll des zweiten Knoten ist ersichtlich, dass der Cluster nun über die verschiedenen Interconnect-Schnittstellen kommuniziert und der Cluster einen aktiven Zustand erreicht:
[root@osiris root]# cat /var/log/ha-log
[...]
[...] info: Starting serial heartbeat on tty /dev/ttyS0 (19200 baud)
[...] info: UDP Broadcast heartbeat started on port 694 (694) interface eth1
[...] info: UDP multicast heartbeat started for group 225.0.0.7 port 694 interface
eth1 (ttl=1 loop=1)
[...] info: Local status now set to: 'up'
[...] info: Link logos.matrix.com:eth1 up.
[...] info: Status update for node logos.matrix.com: status active
[...] info: Link logos.matrix.com:eth1 225.0.0.7 694 1 1 up.
[...] WARN: process_clustermsg: node [logos] failed authentication
[...] info: Local status now set to: 'active'
[...] info: Link osiris.matrix.com:eth1 up.
[...] info: Link osiris.matrix.com:eth1 225.0.0.7 694 1 1 up.
[...] info: Running /etc/ha.d/rc.d/status status
[...] info: remote resource transition completed.
[...] info: remote resource transition completed.
[...] info: Local Resource acquisition completed. (none)
[...] info: Link logos.matrix.com:/dev/ttyS0 up.
Die in dem Protokoll angezeigte Warnung
WARN: process_clustermsg: node [logos] failed authentication
ist nach Angaben der Linux-HA FAQ[][vgl. ]LHFQ zu ignorieren; hierbei handelt es sich um ein korruptes Datenpaket, das üblicherweise beim Start von heartbeat entsteht und die Warnmeldung auslöst.
Nachdem der Cluster erfolgreich initialisiert wurde, kann nun mit einem Failover-Test die Funktionalität des Clusters bei Ausfall eines Knotens überprüft werden. Dazu wird auf dem aktiven Knoten der heartbeat-Dienst heruntergefahren und das Ereignisprotokoll auf dem passiven Knoten überprüft. Um ein realistisches Ausfallszenario nachzustellen, kann der aktive Clusterknoten von der Stromversorgung getrennt werden um so die Funktionalität des Clusters zu prüfen. Nach dieser Prozedur können die zu Beginn dieses Kapitels genannten Methoden zur überprüfung der korrekten übernahme der Cluster-Ressourcen auf den zweiten, nun aktiven Knoten angewandt werden.