19.18. Highly Available Storage (HAST)

19.18.3.1. Synchronisation und Replikationsmodi

HAST versucht, eine schnelle Fehlerbereinigung zu gewährleisten. Aus diesem Grund ist es sehr wichtig, die Synchronisationszeit nach dem Ausfall eines Knotens zu reduzieren. Um eine schnelle Synchronisation zu ermöglichen, verwaltet HAST eine Bitmap von unsauberen Bereichen auf der Platte und synchronisiert nur diese während einer regulären Synchronisation (mit Ausnahme der initialen Synchronisation).

Es gibt viele Wege, diese Synchronisation zu behandeln. HAST implementiert mehrere Replikationsarten, um unterschiedliche Methoden der Synchronisation zu realisieren:

• memsync: meldet Schreiboperationen als vollständig, wenn die lokale Schreiboperation beendet ist und der entfernt liegende Knoten die Ankunft der Daten bestätigt hat, jedoch bevor die Daten wirklich gespeichert wurden. Die Daten werden auf dem entfernt liegenden Knoten direkt nach dem Senden der Bestätigung gespeichert. Dieser Modus ist dafür gedacht, Latenzen zu verringern und zusätzlich eine gute Verlässlichkeit zu bieten. Der memsync-Replikationsmodus ist momentan noch nicht implementiert.

• fullsync: meldet Schreiboperationen als vollständig, wenn die lokale Schreiboperation beendet ist und die entfernte Schreiboperation ebenfalls abgeschlossen wurde. Dies ist der sicherste und zugleich der langsamste Replikationsmodus. Er stellt den momentanen Standardmodus dar.

• async: meldet Schreiboperationen als vollständig, wenn lokale Schreibvorgänge abgeschlossen wurden. Dies ist der schnellste und gefährlichste Replikationsmodus. Er sollte verwendet werden, wenn die Latenz zu einem entfernten Knoten bei einer Replikation zu hoch ist für andere Modi. Der async-Replikationsmodus ist zum gegenwärtigen Zeitpunkt nicht implementiert.

19.18.4.1. Failover-Konfiguration

Das Ziel dieses Beispiels ist, ein robustes Speichersystem zu bauen, welches Fehlern auf einem beliebigen Knoten widerstehen kann. Die Schlüsselaufgabe in diesem Szenario besteht darin, zu verhindern, dass der primary-Knoten des Clusters ausfällt. Sollte es dennoch passieren, ist der secondary-Knoten da, um nahtlos einzuspringen, das Dateisystem zu prüfen, einzuhängen und mit der Arbeit fortzufahren, ohne dass auch nur ein einzelnes Bit an Daten verloren ging.

Um diese Aufgabe zu bewerkstelligen, ist es nötig, eine weitere Eigenschaft zu nutzen, die unter FreeBSD verfügbar ist, welche ein automatisches Failover auf der IP-Schicht ermöglicht: CARP. CARP steht für Common Address Redundancy Protocol und erlaubt es mehreren Rechnern im gleichen Netzsegment, die gleiche IP-Adresse zu verwenden. Setzen Sie CARP auf beiden Knoten des Clusters anhand der Dokumentation in Abschnitt 32.13 auf. Nachdem dieser Schritt abgeschlossen ist, sollte jeder Knoten seine eigene carp0-Schnittstelle mit der geteilten IP-Adresse 172.16.0.254 besitzen. Selbstverständlich muss der primäre HAST-Knoten des Clusters der CARP-Masterknoten sein.

Der HAST-Pool, welcher im vorherigen Abschnitt erstellt wurde, ist nun bereit für den Export über das Netzwerk auf den anderen Rechner. Dies kann durch den Export über NFS, Samba etc. erreicht werden, indem die geteilte IP-Addresse 172.16.0.254 verwendet wird. Das einzige ungelöste Problem ist der automatische Failover, sollte der primäre Knoten einmal ausfallen.

Falls die CARP-Schnittstelle aktiviert oder deaktiviert wird, generiert das FreeBSD-Betriebssystem ein devd(8)-Ereignis, was es ermöglicht, Zustandsänderungen auf den CARP-Schnittstellen zu überwachen. Eine Zustandsänderung auf der CARP-Schnittstelle ist ein Indiz dafür, dass einer der Knoten gerade ausgefallen oder wieder verfügbar ist. In diesem Fall ist es möglich, ein Skript zu starten, welches den Failover automatisch durchführt.

Um diese Zustandsänderungen auf der CARP-Schnittstelle abzufangen, müssen die folgenden Zeilen in der Datei /etc/devd.conf auf jedem Knoten eingefügt werden:

notify 30 {
	match "system" "IFNET";
	match "subsystem" "carp0";
	match "type" "LINK_UP";
	action "/usr/local/sbin/carp-hast-switch master";
};

notify 30 {
	match "system" "IFNET";
	match "subsystem" "carp0";
	match "type" "LINK_DOWN";
	action "/usr/local/sbin/carp-hast-switch slave";
};

Um diese neue Konfiguration zu aktivieren, starten Sie devd(8) auf beiden Knoten neu, um die neue Konfiguration wirksam werden zu lassen:

# /etc/rc.d/devd restart

Für den Fall, dass die carp0-Schnittstelle aktiviert oder deaktiviert wird (sich also der Status der Schnittstelle ändert), erzeugt das System eine Meldung, was es dem devd(8)-Subsystem ermöglicht, ein beliebiges Skript zu starten, in diesem Fall also /usr/local/sbin/carp-hast-switch. Dies ist das Skript, dass den automatischen Failover durchführt. Für genauere Informationen zu der obigen devd(8)-Konfiguration, lesen Sie die devd.conf(5)-Manualpage.

Ein Beispiel für ein solches Skript könnte wie folgt aussehen:

#!/bin/sh

# Original script by Freddie Cash <[email protected]>
# Modified by Michael W. Lucas <[email protected]>
# and Viktor Petersson <[email protected]>

# The names of the HAST resources, as listed in /etc/hast.conf
resources="test"

# delay in mounting HAST resource after becoming master
# make your best guess
delay=3

# logging
log="local0.debug"
name="carp-hast"

# end of user configurable stuff

case "$1" in
	master)
		logger -p $log -t $name "Switching to primary provider for ${resources}."
		sleep ${delay}

		# Wait for any "hastd secondary" processes to stop
		for disk in ${resources}; do
			while $( pgrep -lf "hastd: ${disk} \(secondary\)" > /dev/null 2>&1 ); do
				sleep 1
			done

			# Switch role for each disk
			hastctl role primary ${disk}
			if [ $? -ne 0 ]; then
				logger -p $log -t $name "Unable to change role to primary for resource ${disk}."
				exit 1
			fi
		done

		# Wait for the /dev/hast/* devices to appear
		for disk in ${resources}; do
			for I in $( jot 60 ); do
				[ -c "/dev/hast/${disk}" ] && break
				sleep 0.5
			done

			if [ ! -c "/dev/hast/${disk}" ]; then
				logger -p $log -t $name "GEOM provider /dev/hast/${disk} did not appear."
				exit 1
			fi
		done

		logger -p $log -t $name "Role for HAST resources ${resources} switched to primary."


		logger -p $log -t $name "Mounting disks."
		for disk in ${resources}; do
			mkdir -p /hast/${disk}
			fsck -p -y -t ufs /dev/hast/${disk}
			mount /dev/hast/${disk} /hast/${disk}
		done

	;;

	slave)
		logger -p $log -t $name "Switching to secondary provider for ${resources}."

		# Switch roles for the HAST resources
		for disk in ${resources}; do
			if ! mount | grep -q "^/dev/hast/${disk} on "
			then
			else
				umount -f /hast/${disk}
			fi
			sleep $delay
			hastctl role secondary ${disk} 2>&1
			if [ $? -ne 0 ]; then
				logger -p $log -t $name "Unable to switch role to secondary for resource ${disk}."
				exit 1
			fi
			logger -p $log -t $name "Role switched to secondary for resource ${disk}."
		done
	;;
esac

Im Kern führt das Skript die folgenden Aktionen durch, sobald ein Knoten zum master / primary wird:

• Es ernennt den HAST-Pool als den primären für einen gegebenen Knoten.

• Es prüft das Dateisystem, dass auf dem HAST-Pool erstellt wurde.

• Es hängt die Pools an die richtige Stelle im System ein.

Wenn ein Knoten zum backup / secondary ernannt wird:

• Hängt es den HAST-Pool aus dem Dateisystem aus.

• Degradiert es den HAST-Pool zum sekundären.

Weitere detaillierte Informationen mit zusätzlichen Beispielen können auf der HAST Wiki-Seite abgerufen werden.

19.18.5.1. Allgemeine Tipps zur Fehlerbehebung

HAST sollte generell ohne Probleme funktionieren. Jedoch kann es, wie bei jeder anderen Software auch, zu gewissen Zeiten sein, dass sie sich nicht so verhält wie angegeben. Die Quelle dieser Probleme kann unterschiedlich sein, jedoch sollte als Faustregel gewährleistet werden, dass die Zeit für beide Knoten im Cluster synchron läuft.

Die Anzahl an Debugging-Meldungen von hastd(8) sollte erhöht werden, wenn Fehler von HAST bereinigt werden. Dies kann durch das Starten des hastd(8)-Dienstes mit der Option -d erreicht werden. Wichtig zu wissen ist, dass diese Option mehrfach angegeben werden kann, um die Anzahl an Meldungen weiter zu erhöhen. Sie können viele nützliche Informationen auf diese Art bekommen. Sie sollten ebenfalls die Verwendung der Option -F in Erwägung ziehen, die den hastd(8)-Dienst in den Vordergrund bringt.

19.18.5.2. Auflösung des Split-brain-Zustands

Die Konsequenz aus der Situation, wenn beide Knoten des Clusters nicht in der Lage sind, miteinander zu kommunizieren und dadurch beide als primäre Knoten fungieren, wird als split-brain bezeichnet. Dies ist ein gefährlicher Zustand, weil es beiden Knoten erlaubt ist, Änderungen an den Daten vorzunehmen, die miteinander nicht in Einklang gebracht werden können. Diese Situation sollte vom Systemadministrator händisch bereinigt werden.

Um diese Situation zu beheben, muss der Administrator entscheiden, welcher Knoten die wichtigsten Änderungen von beiden besitzt (oder diese manuell miteinander vermischen) und anschliessend den HAST-Knoten die volle Synchronisation mit jenem Knoten durchführen zu lassen, welcher die beschädigten Daten besitzt. Um dies zu tun, geben Sie die folgenden Befehle auf dem Knoten ein, der neu synchronisiert werden soll:

# hastctl role init <resource>
# hastctl create <resource>
# hastctl role secondary <resource>