19.18. Highly Available Storage (HAST)

19.18.3.1. Synchronisatie- en replicatiemodi

HAST probeert om een snel herstel van fouten te leveren. Om deze reden is het heel belangrijk om de synchronisatietijd te verkorten nadat een knooppunt is hersteld van een uitval. Om een snelle synchronisatie te leveren, beheert HAST op de schijf een bitmap van gebruikte extents en synchroniseert het die alleen tijdens een reguliere synchronisatie (met uitzondering van de initiëe synchronisatie).

Er zijn vele manieren om synchronisatie af te handelen. HAST implementeert meerdere replicatiemodi om verschillende synchronisatiemethodes af te handelen:

• memsync: rapporteer een schrijfbewerking als voltooid wanneer de plaatselijke schrijfbewerking klaar is en wanneer het verre knooppunt de gegevensaankomst bevestigt, maar voordat het de gegevens daadwerkelijk heeft opgeslagen. De gegevens op het verre knooppunt zullen meteen na het versturen van de bevestiging worden opgeslagen. Deze modus is bedoeld om latency te verminderen en nog steeds een zeer goede betrouwbaarheid te bieden. De replicatiemodus memsync is momenteel niet geïmplementeerd.

• fullsync: rapporteer een schrijfbewerking als voltooid wanneer zowel de plaatselijke en de verre schrijfbewerking voltooid zijn. Dit is de veiligste en traagste replicatiemodus. Dit is de standaardmodus.

• async: rapporteer de schrijfbewerking als voltooid wanneer de plaatselijke schrijfbewerking klaar is. Dit is de snelste en gevaarlijkste replicatiemodus. Het dient gebruikt te worden wanneer er naar een ver knooppunt wordt gerepliceerd en de latency te hoog is voor andere modi. De replicatiemodus async is momenteel niet geïmplementeerd.

19.18.4.1. Failover-configuratie

Het doel van dit voorbeeld is om een robuust opslagsysteem te bouwen dat resistent is tegen het falen van alle knooppunten. Het scenario is dat een primair knooppunt van het cluster faalt. Als dit gebeurt, dan neemt het secundaire knooppunt het feilloos over, controleert het het bestandssysteem en koppelt het het bestandssysteem aan, en gaat het verder zonder dat er een bit aan gegevens ontbreekt.

Om dit voor elkaar te krijgen, is er een andere eigenschap die beschikbaar is op FreeBSD dat voorziet in automatische failover van de IP-laag — CARP. CARP (Common Address Redundancy Protocol) maakt het mogelijk dat meerdere hosts in hetzelfde netwerksegment een IP-adres delen. Stel CARP in op beide knooppunten van het cluster volgens de documentatie die beschikbaar is in Paragraaf 32.14. Nadat de opzet voltooid is, heeft elk knooppunt een eigen interface carp0 met een gedeeld IP-adres 172.16.0.254. Het primaire HAST-knooppunt van het cluster moet het meester-CARP-knooppunt zijn.

De HAST-pool die in de vorige sectie is gemaakt is nu klaar om geëxporteerd te worden naar de andere hosts op het netwerk. Dit kan gedaan worden door het te exporteren over NFS, Samba, etc., door gebruik te maken van het gedeelde IP-adres 172.16.0.254. Het enige overgebleven probleem is een automatische failover in het geval dat het primaire knooppunt het begeeft.

Als een CARP-interface aan- of uitgaat, genereert FreeBSD een devd(8)-gebeurtenis, wat het mogelijk maakt om toestandsveranderingen op de CARP-interfaces in de gaten te houden. Een toestandsverandering op het CARP-interface geeft aan dat een van de knooppunten het begaf of weer online kwam. Deze toestandsveranderingen maken het mogelijk om een script te draaien dat automatisch de HAST-failover afhandelt.

Voeg, om toestandsverandering op de CARP-interfaces af te vangen, het volgende toe aan het bestand /etc/devd.conf op elk knooppunt:

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";
};

Herstart devd(8) op beide knooppunten om de nieuwe configuratie te laten gelden:

# /etc/rc.d/devd restart

Als het interface carp0 aan of uit gaat (i.e., de toestand van het interface verandert), genereert het systeem een notificatie wat het subsysteem devd(8) in staat stelt om een willekeurig script te draaien, in dit geval /usr/local/sbin/carp-hast-switch. Dit is het script dat de automatische failover afhandelt. Raadpleeg de handleidingpagina devd.conf(5) voor verdere uitleg over de bovenstaande configuratie van devd(8).

Dit zou een voorbeeld van zo'n script kunnen zijn:

#!/bin/sh
# Origineel script door Freddie Cash <[email protected]>
# Gewijzigd door Michael W. Lucas <[email protected]>
# en Viktor Petersson <[email protected]>

# De namen van de HAST-hulpbronnen, zoals vermeld in /etc/hast.conf
resources="test"

# vertraging voor het aankoppelen van de HAST-hulpbron na het worden van meester
# doe een gok
delay=3

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

# einde van gebruiker-instelbare dingen

case "$1" in
	master)
		logger -p $log -t $name "Omschakelen naar primaire aanbieder voor ${resources}."
		sleep ${delay}

		# Wacht totdat de "hastd secondary" processen zijn gestopt
		for disk in ${resources}; do
			while $( pgrep -lf "hastd: ${disk} \(secondary\)" > /dev/null 2>&1 ); do
				sleep 1
			done

			# Verwissel de rol voor elke schijf
			hastctl role primary ${disk}
			if [ $? -ne 0 ]; then
				logger -p $log -t $name "Omschakelen van rol naar primair voor hulpbron ${disk} mislukt."
				exit 1
			fi
		done

		# Wacht totdat de apparaten /dev/hast/* verschijnen
		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-aanbieder /dev/hast/${disk} is niet verschenen."
				exit 1
			fi
		done

		logger -p $log -t $name "Rollen van HAST-hulpbronnen ${resources} omgeschakeld naar primair."


		logger -p $log -t $name "Schijven aankoppelen."
		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 "Omschakelen naar secundaire aanbieder voor ${resources}."

		# Schakel de rollen van de HAST-hulpbronnen om
		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 "Omschakelen van rol naar secundair voor hulpbron ${disk} mislukt."
				exit 1
			fi
			logger -p $log -t $name "Rol van hulpbron ${disk} omgeschakeld naar secundair."
		done
	;;
esac

In een notendop neemt het script deze acties wanneer een knooppunt meester / primair wordt:

• De HAST-pools opwaarderen naar primair op een gegeven knooppunt.

• Het bestandssysteem onder de HAST-pool controleren.

• De pools op een juiste plaats aankoppelen.

Wanneer een knooppunt back-up / secundair wordt:

• De HAST-pools afkoppelen.

• De HAST-pools degraderen naar secundair.

Meer gedetailleerde informatie met aanvullende voorbeelden kunnen gevonden worden op de HAST Wiki-pagina.

19.18.5.1. Algemene tips om problemen op te lossen

HAST zou over het algemeen zonder problemen moeten werken. Net als met elk ander software-product zijn er momenten waarop het anders werkt dan het zou moeten. De oorzaken van de problemen kunnen verschillen, maar de vuistregel is om ervoor te zorgen dat de klokken zijn gesynchroniseerd op alle knooppunten in het cluster.

Wanneer problemen met HAST worden verholpen, dient het debug-niveau van hastd(8) verhoogd te worden door het daemon hastd(8) met het argument -d op te starten. Merk op dat dit argument meerdere malen kan worden opgegeven om het debug-niveau nog verder op te hogen. Op deze manier kan veel nuttige informatie worden vergaard. Overweeg ook om het argument -F te gebruiken, dat het daemon hastd(8) in de voorgrond zal starten.

19.18.5.2. Herstellen van de Split-brain-conditie

Split-brain treedt op waneer de knooppunten van het cluster niet met elkaar kunnen communiceren, en beide als primair zijn geconfigureerd. Dit is een gevaarlijke situatie omdat het beide knooppunten in staat stelt om incompatibele veranderingen aan de gegevens te maken. Dit probleem dient handmatig door de systeembeheerder te worden gecorrigeerd.

De beheerder moet besluiten welk knooppunt de belangrijkere veranderingen bevat (of ze handmatig samenvoegen) en HAST een volledige synchronisatie op het knooppunt dat de kapotte gegevens heeft laten uitvoeren. Voer hiervoor deze commando's uit op het knooppunt dat opnieuw gesynchroniseerd moet worden:

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