Login
Login-Name Passwort


 
Newsletter
Werbung

Mo, 13. Juli 2009, 00:00

High Availability Computer Center (hacc-) - Update, Teil 3

Teil 3: Hochverfügbarkeit und Web-Oberfläche

Die Steuerknoten mit Heartbeat hochverfügbar machen

Nun ist es an der Zeit, die Hochverfügbarkeit der Steuerknoten und die Nagios-Überwachung zu realisieren.

Für die Hochverfügbarkeit der Steuerknoten wird Heartbeat V2 eingesetzt (Siehe [5] und [6]). Auch Samba4 bietet hier sicherlich interessante Möglichkeiten in Zukunft. Aber ich möchte es jetzt noch nicht einsetzen.

Heartbeat V2

Zunächst wird also heartbeat und heartbeat-2 installiert. Weiterhin wird zum Aktivieren des Watchdog-Mechanismus softdog nach /etc/modules geschrieben (ergänzt).

Probleme bereiten auch die nicht unbedingt LSB konformen System-V-Init-Skripte bei Ubuntu, ganz zu schweigen von OCF-Scripten. Deshalb wird ein eigenes, universelles OCF-Skript /usr/lib/ocf/resource.d/local/Uni eingesetzt. Es wird benutzt, um LSB-konform programmierte Start- und Stop-Skripte zu starten, zu stoppen und mit eigenen Mitteln das Monitoring des Dienstes zu organisieren (zum Beispiel bei Web-Services mit einem wget-Aufruf oder mit dem Aufruf eines Nagios-Service-Check-Kommandos). Per Parameter initscript wird der Pfad eines LSB-konformen Start/Stop-Skriptes übergeben. Der Parameter mod_cmd enthält das Test-Kommando für die Monitoring-Funktion.

Skript: /usr/lib/ocf/resource.d/local/Uni

#!/bin/bash
#
# OCF Script: Uni
#
# Universelles Script zum Starten von lsb Ressourcen
# und zum Monitoring mit eigenen (Nagios-Plugin) Kommandos.
#######################################################################
# Initialization:
. ${OCF_ROOT}/resource.d/heartbeat/.ocf-shellfuncs
#######################################################################
meta_data() {
 cat <<END
<?xml version="1.0"?>
<!DOCTYPE resource-agent SYSTEM "ra-api-1.dtd">
<resource-agent name="Uni">
<version>0.3</version>
<longdesc lang="en">
This is a Self devel Resource Agent.
</longdesc>
<shortdesc lang="en">Self devel Resource Agent</shortdesc>
<parameters>
<parameter name="initscript" unique="1" required="1">
<longdesc lang="en">
LSB Start, Stop and restart Script
</longdesc>
<shortdesc lang="en">LSB Start Script</shortdesc>
<content type="string" default="/etc/init.d/script" />
</parameter>
<parameter name="mon_cmd" unique="1" required="1">
<longdesc lang="en">
Monitor Command (Kommando, z.B Nagios Plugin)
</longdesc>
<shortdesc lang="en">Monitor Command</shortdesc>
<content type="string" default="wget" />
</parameter>
</parameters>
<actions>
<action name="start" timeout="90" />
<action name="stop" timeout="100" />
<action name="monitor" timeout="60" interval="30" depth="0"
start-delay="30" />
<action name="meta-data" timeout="5" />
<action name="verify-all" timeout="30" />
</actions>
</resource-agent>
END
}
#######################################################################
# don't exit on TERM, to test that lrmd makes sure that we do exit
trap sigterm_handler TERM
sigterm_handler() {
 ocf_log info "They use TERM to bring us down. No such luck."
 return
}
self_usage() {
 cat <<END
usage: $0 {start|stop|monitor|validate-all|meta-data}
Expects to have a fully populated OCF RA-compliant environment set.
END
}
self_start() {
 # ERR ${OCF_RESKEY_initscript} restart
 ${OCF_RESKEY_initscript} start
 self_monitor
 if &#91; $? = $OCF_SUCCESS &#93;; then
 return $OCF_SUCCESS
 fi
}
self_stop() {
 ${OCF_RESKEY_initscript} stop
 return $OCF_SUCCESS
}
self_monitor() {
 # Monitor _MUST!_ differentiate correctly between running
 # (SUCCESS), failed (ERROR) or _cleanly_ stopped (NOT RUNNING).
 # That is THREE states, not just yes/no.
 ${OCF_RESKEY_mon_cmd} >/dev/null 2>&1
 status=$?
 if &#91; $status -eq 0 &#93; ; then
 return $OCF_SUCCESS
 fi
 return $OCF_NOT_RUNNING
}
self_validate() {
 # Is the state directory writable?
 for P in ${OCF_RESKEY_mon_cmd}
 do
 if &#91; -f $P &#93; ;then
 if &#91; -x $P &#93; ;then
 return $OCF_SUCCESS
 else
 return $OCF_ERR_ARGS
 fi
 fi
 done
 return $OCF_ERR_CONFIGURED
}
case $__OCF_ACTION in
meta-data) meta_data
 exit $OCF_SUCCESS
 ;;
start) self_start;;
stop) self_stop;;
monitor) self_monitor;;
validate-all) self_validate;;
usage|help) self_usage
 exit $OCF_SUCCESS
 ;;
*) self_usage
 exit $OCF_ERR_UNIMPLEMENTED
 ;;
esac
rc=$?
ocf_log debug "${OCF_RESOURCE_INSTANCE} $__OCF_ACTION : $rc"
exit $rc

Heartbeat V2 wurde in /etc/ha.d/ha.cf so konfiguriert, dass Multicast für die Verbindungsüberwachung eingesetzt wird.

/etc/ha.d/ha.cf

crm on
autojoin any
watchdog /dev/watchdog
mcast bond0 225.0.0.1 694 1 0
initdead 120
keepalive 2
warntime 10
deadtime 30
apiauth mgmnt uid=hacluster
respawn hacluster /usr/lib/heartbeat/mgmtd -v
# Ping-Check für Quorum am Gateway
ping <ip-GW>
respawn hacluster /usr/lib/heartbeat/ipfail
apiauth ipfail gid=haclient uid=hacluster

Nicht vergessen werden sollte, auf beiden Knoten eine identische Datei /etc/ha.d/authkeys (mit chmod 600) einzurichten. Dadurch finden sich die Server des Clusters. Ebenso sollte ein Nutzer hacluster mit sudo passwd hacluster auf beiden Hosts ein identisches Passwort erhalten, damit man mit der GUI hb_gui zugreifen kann (wobei die Zeilen-Kommandos von heartbeat teilweise bessere Dienste leisten, zum Beispiel crm_mon).

Die übrigen Server-Dienste der Steuerknoten

Bevor die erste Ressource in die Heartbeat-Überwachung aufgenommen wird, sollte der Service dieser Ressource funktionstüchtig sein. Erste Ressource ist Apache2, an den Nagios angebunden wird und mit dem eine Web-Oberfläche für die Administration des hacc- bereitgestellt wird. Deshalb ist zunächst Apache2 folgendermaßen vorzubereiten (Siehe auch [1], [2], [3]):

Kommentare (Insgesamt: 0 || Kommentieren )
Pro-Linux
Pro-Linux @Facebook
Neue Nachrichten
Werbung