Detailierte Informationen zur Netzwerkeinrichtung siehe Netzwerkkarten bündeln - Bonding
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto eth1
iface eth1 inet manual
# DRBD Kommunikations-Interface
auto eth2
iface eth2 inet static
address 172.16.0.1
netmask 255.255.255.0
network 172.16.0.0
broadcast 172.16.0.255
# Heartbeat Kommunikations-Interface
auto eth3
iface eth3 inet static
address 172.16.1.1
netmask 255.255.255.0
network 172.16.1.0
broadcast 172.16.1.255
# openQRM Kommunikations-Interface
auto bond0
iface bond0 inet static
address 10.10.1.101
netmask 255.255.255.0
network 10.10.1.0
broadcast 10.10.1.255
gateway 10.10.1.1
slaves eth0 eth1
bond_mode 1
bond_miimon 100
bond_updelay 200
bond_downdealy 200
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet manual
auto eth1
iface eth1 inet manual
# DRBD Kommunikations-Interface
auto eth2
iface eth2 inet static
address 172.16.0.2
netmask 255.255.255.0
network 172.16.0.0
broadcast 172.16.0.255
# Heartbeat Kommunikations-Interface
auto eth3
iface eth3 inet static
address 172.16.1.2
netmask 255.255.255.0
network 172.16.1.0
broadcast 172.16.1.255
# openQRM Kommunikations-Interface
auto bond0
iface bond0 inet static
address 10.10.1.102
netmask 255.255.255.0
network 10.10.1.0
broadcast 10.10.1.255
gateway 10.10.1.1
slaves eth0 eth1
bond_mode 1
bond_miimon 100
bond_updelay 200
bond_downdealy 200
... 10.10.1.101 speicher01 10.10.1.102 speicher02 ...
Detailierte Konfigurationsanleitung siehe DRBD
... filter = [ "r|/dev/cdrom|", "r|/dev/sdb|", "a|/dev/drbd1|" ] ...
/etc/drbd.d/global_common.conf
global {
usage-count yes;
# minor-count dialog-refresh disable-ip-verification
}
common {
protocol C;
handlers {
pri-on-incon-degr "/usr/lib/drbd/notify-pri-on-incon-degr.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
pri-lost-after-sb "/usr/lib/drbd/notify-pri-lost-after-sb.sh; /usr/lib/drbd/notify-emergency-reboot.sh; echo b > /proc/sysrq-trigger ; reboot -f";
local-io-error "/usr/lib/drbd/notify-io-error.sh; /usr/lib/drbd/notify-emergency-shutdown.sh; echo o > /proc/sysrq-trigger ; halt -f";
# fence-peer "/usr/lib/drbd/crm-fence-peer.sh";
# split-brain "/usr/lib/drbd/notify-split-brain.sh root";
# out-of-sync "/usr/lib/drbd/notify-out-of-sync.sh root";
# before-resync-target "/usr/lib/drbd/snapshot-resync-target-lvm.sh -p 15 -- -c 16k";
# after-resync-target /usr/lib/drbd/unsnapshot-resync-target-lvm.sh;
}
startup {
# wfc-timeout degr-wfc-timeout outdated-wfc-timeout wait-after-sb;
wfc-timeout 0;
degr-wfc-timeout 120; # 2 Minuten
}
disk {
# on-io-error fencing use-bmbv no-disk-barrier no-disk-flushes
# no-disk-drain no-md-flushes max-bio-bvecs
on-io-error detach;
}
net {
# sndâbuf-size rcvbuf-size timeout connect-int ping-int ping-timeout max-buffers
# max-epoch-size ko-count allow-two-primaries cram-hmac-alg shared-secret
# after-sb-0pri after-sb-1pri after-sb-2pri data-integrity-alg no-tcp-cork
after-sb-0pri discard-zero-changes;
after-sb-1pri discard-secondary;
after-sb-2pri disconnect;
}
syncer {
# rate after al-extents use-rle cpu-mask verify-alg csums-alg
### 100Mbps - Beispiel
#rate 40M;
### 1Gbps - Beispiel
#rate 110M;
#al-extents 255;
### 10Gbps - Beispiel
rate 2048M;
al-extents 511;
}
}
resource data {
on speicher01 {
device /dev/drbd1;
disk /dev/sdb;
address 172.16.0.1:7788;
meta-disk internal;
}
on speicher02 {
device /dev/drbd1;
disk /dev/sdb;
address 172.16.0.2:7788;
meta-disk internal;
}
}
Diese beiden Einstellungen haben wir mit "drbd8-utils 8.4.3" getestet,
sie sollten aber auch mit "drbd8-utils 8.3.x" funktionieren.
Die hier entscheidenden Parameter heißen "sndbuf-size 0;" und "c-plan-ahead 0;":
> vi /etc/drbd.d/global_common.conf
global {
usage-count no;
}
common {
startup {
degr-wfc-timeout 0;
}
net {
...
sndbuf-size 0;
}
disk {
...
c-plan-ahead 0;
}
}
/dev/sda1 on / type jfs (rw,errors=remount-ro) /dev/mapper/data-configs on /opt/etc type jfs (rw) /dev/mapper/data-nfsdata on /data type jfs (rw) /dev/mapper/data-openqrm on /usr/share/openqrm type jfs (rw)
Die VolumeGroup liegt auf dem Device /dev/drbd1 (data). Das DRBD wurde direkt auf /dev/sdb gelegt.
# vgs VG #PV #LV #SN Attr VSize VFree data 1 14 0 wz--n- 3,54t 3,52t
# lvs LV VG Attr LSize Origin Snap% Move Log Copy% Convert configs data -wi-ao 52,00m nfsdata data -wi-ao 20,00m openqrm data -wi-ao 52,00m
Detailierte Konfigurationsanleitung siehe Heartbeat
#Logging logfacility local0 autojoin none # Heartbeart communication timing keepalive 2 deadtime 30 warntime 10 initdead 60 mcast eth3 239.0.0.43 694 1 0 # Don't fail back automatically auto_failback off # Heartbeat cluster members node speicher01 node speicher02 # Monitoring of network connection to default gateway ping 10.10.1.1 respawn hacluster /usr/lib/heartbeat/ipfail
speicher02 \
IPaddr::10.10.1.100/24/bond0 \
mydrbd \
drbddisk::data \
LVM::data \
fsck_jfs::/dev/data/configs \
fsck_jfs::/dev/data/nfsdata \
fsck_jfs::/dev/data/openqrm \
Filesystem::/dev/data/configs::/opt/etc/::jfs \
Filesystem::/dev/data/nfsdata::/data::jfs \
Filesystem::/dev/data/openqrm::/usr/share/openqrm \
vblade_stop
Die Einbindung eines vblade_stop Scripts ist notwendig, da openQRM sich beim initialen Start der vblade Prozesse nicht an die Syntax des Pakets aus dem Ubuntu Repository hält. Beim Start durch die openQRM-Management-Oberfläche, z.B. im Rahmen des Neuanlegens eines AOE Devices wird das sonst übliche PID File für den vblade Prozess nicht angelegt. Beim regulären Stop der vblade Prozesse orientiert sich das normale Initscript allerdings an eben diesen PID-Files. Da diese nicht existieren, werden einige vblade-Prozesse nicht gestoppt und Heartbeat würde im Falle eines kontrollierten Clusterschwenks einen kill des init-Prozesses und somit einen harten reboot auslösen. Das eingebundene Script ist eine Kopie des normalen Init-Scripts (vblade muss natürlich bereits installiert sein um eine Kopie des Initscripts anzufertigen). Bei Übergabe des Parameters Start werden allerdings keine Aktionen ausgelöst und der Aufruf mit dem Parameter Stop wurde um eine Schleife erweitert, welche alle verbleibenden vblade Prozesse beendet, auch wenn für diese kein PID-File existiert.
#!/bin/bash
set -e
# set -x
# /etc/init.d/vblade start and stop the vblade daemon
test -x /usr/sbin/vblade || exit 0
. /lib/lsb/init-functions
RETVAL=0
prog=vblade
stop() {
log_daemon_msg "Stopping vblade daemons" "vblade"
log_progress_msg "vblade"
if [ -x /var/run/$prog/*.pid]
then
for pidfile in `ls /var/run/$prog/*.pid`
do
kill -9 `cat $pidfile`
rm -f $pidfile
done
else
for VBLADE_PID in `ps ax | grep vblade | grep -w "bond0:0 /dev/mapper" | awk {' print $1 '}`
do
kill -9 $VBLADE_PID
done
sync
fi
echo
}
case "$1" in
start)
;;
stop)
stop
;;
restart|force-reload)
;;
reload)
;;
*)
echo $"Usage: $0 {start|stop|restart|reload|restart|force-reload}"
RETVAL=1
esac
exit 0
Nachdem die Konfigs auf beiden Server publiziert wurden sollte zunächst auf dem ersten Knoten Heartbeat gestartet werden.
root@speicher01:/# scp -r /etc/ha.d/authkeys /etc/ha.d/ha.cf /etc/ha.d/haresources /etc/ha.d/resource.d speicher02:/etc/ha.d/
root@speicher01:/# /etc/init.d/heartbeat start && tailf /var/log/syslog
Wenn der Start des Heartbeat Daemons ohne Probleme verläuft, sollte ebenfalls geprüft werden, ob der Stop der Dienste ohne Probleme verläuft.
root@speicher01:/# /etc/init.d/heartbeat stop && tailf /var/log/syslog
Wenn auch hier keine Probleme angezeigt werden, kann ein Schwenk auf den anderen Clusterknoten getestet werden.
Also zunächst den Hearbeat auf dem ersten Knoten starten.
root@speicher01:/# /etc/init.d/heartbeat start && tailf /var/log/syslog
Nachdem dieser alle Ressourcen gestartet hat, den Heartbeat Daemon ebenfalls auf dem zweiten Knoten starten und einen manuellen Schwenk initiieren.
root@speicher02:/# /etc/init.d/heartbeat start && tailf /var/log/syslog root@speicher01:/# /etc/init.d/heartbeat standby && tailf /var/log/syslog
Nach prüfung der ordnungsgemäßen Übernahme aller Ressourcen kann zurückgeschwenkt werden.
root@speicher01:/# tailf /var/log/syslog root@speicher02:/# /etc/init.d/heartbeat standby && tailf /var/log/syslog
Nachdem Heartbeat konfiguriert wurde und der Server der erste Knoten mit seiner HA-IP-Adresse zur verfügung steht, kann mit der Integration in die openQRM Umgebung begonnen werden.
# aptitude udate && aptitude install nfs-kernel-server vblade # update-rc.d -f nfs-kernel-server remove && update-rc.d -f vblade remove
Leider fehlt auch nach integration des openqrm-client das Tool /usr/bin/lockfile, welches eigentlich zusammen mit dem Paket procmail ausgeliefert wird. Da dieses Paket auf dem System aber unnötigt ist, reicht es aus das Binary vom openqrm01 zu übertragen.
root@openqrm01:/# scp /usr/bin/lockfile speicher01:/usr/bin/ && scp /usr/bin/lockfile speicher02:/usr/bin/
In der GUI des openQRM-Servers findet sich unter Misc→Local-Server→About ein kleines How-To zur Integration eines Local-Server.
Zur Integration sind also folgende Befehle nötig. Bitte beachten, dass hier bereits das HA-Interface des Clusters zur Verfügung stehen muss. Im ersten Schritt wird das Integrationsscript auf das Zielsystem kopiert. Im Anschluss wird es ausgeführt, der automatische Start des Init-Scripts wird verhindert, da der Start über Heartbeat erfolgt.
root@openqrm01:/# scp /usr/share/openqrm/plugins/local-server/bin/openqrm-local-server 10.10.1.101:/tmp/ root@openqrm01:/# ssh 10.10.1.101 /tmp/openqrm-local-server integrate -u openqrm -p openqrm -q 10.10.1.80 -i bond0:0 root@openqrm01:/# ssh 10.10.1.101 update-rc.d -f openqrm-client remove
Der Link des Initscripts wird nun ebenfalls auf dem zweiten Knoten angelegt. Eine Integration des zweiten Knotens per Script ist nicht notwendig, da relevante Verzeichnisse im DRBD liegen.
root@openqrm01:/# ssh 10.10.1.102 ln -s /usr/share/openqrm/etc/init.d/openqrm-client /etc/init.d/openqrm-client
Damit die Konfigurationen von vblade und nfs auf beiden Systemen zur Verfügung stehen, sind entsprechende Konfigurationsdateien ins DRBD zu verlinken.
root@openqrm01:/# ln -s /opt/etc/vblade.conf /etc/vblade.conf root@openqrm02:/# ln -s /opt/etc/vblade.conf /etc/vblade.conf root@openqrm01:/# ln -s /opt/etc/exports /etc/exports root@openqrm02:/# ln -s /opt/etc/exports /etc/exports
Um ein Problem bei der Bereitstellung von AOE Storages zu vermeiden ist es notwendig die Netzwerkschnittstelle zur Bereitstellung AOEs festzulegen. Im Standard wird versucht automatisch eine Schnittstelle zu ermitteln, was aber häufig daneben geht. Es wird oftmals das erste eth0 Interface gewählt, was in unserem Fall nicht korrekt ist.
root@speicher01:/# echo "OPENQRM_SERVER_INTERFACE=bond0:0" > /usr/share/openqrm/etc/openqrm-server.conf root@speicher02:/# echo "OPENQRM_SERVER_INTERFACE=bond0:0" > /usr/share/openqrm/etc/openqrm-server.conf
Da im Script zunächst die Konfigdatei durchsucht wird und erst dann eine automatische Ermittlung der Schnittstelle stattfindet, wird nun dauerhaft bond0:0 für die Bereitstellung von AOEs genutzt.
Weitere Anpassungen zur redundanten Anbindung des Storage erfolgten durch Anpassungen an den von openQRM ausgelieferten Scripts. Da diese vom openQRM Server bereitgestellt werden, sind die Änderungen im Bereich der openQRM Management Einrichtung Dokumentiert openqrm_-_anpassungen_zur_integration_des_redundanten_local-server_storage dokumentiert
Nach der Installation kann der openqrm-client in die Heartbeat Konfiguration aufgenommen werden:
/etc/ha.d/haresources
speicher02 \
IPaddr::10.10.1.100/24/bond0 \
mydrbd \
drbddisk::data \
LVM::data \
fsck_jfs::/dev/data/configs \
fsck_jfs::/dev/data/nfsdata \
fsck_jfs::/dev/data/openqrm \
Filesystem::/dev/data/configs::/opt/etc/::jfs \
Filesystem::/dev/data/nfsdata::/data::jfs \
Filesystem::/dev/data/openqrm::/usr/share/openqrm \
vblade_stop \
openqrm-client