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. De hoofdtaak is het oplossen van een scenario waarin een primair knooppunt van het cluster faalt. Mocht dit gebeuren, dan neemt het secundaire knooppunt het feilloos over, controleert en koppelt het het bestandssysteem aan, en gaat het verder zonder dat er een bit aan gegevens ontbreekt.

Om deze taak voor elkaar te krijgen, is het nodig om een andere eigenschap te gebruiken die beschikbaar is op FreeBSD en dat voorziet in automatische failover van de IP-laag -- CARP. CARP staat voor Common Address Redundancy Protocol en 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 deze taak voltooid is, zou elk knooppunt een eigen interface carp0 met een gedeeld IP-adres 172.16.0.254 moeten hebben. 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. In zulke gevallen is het mogelijk om een script te draaien dat automatisch de failover afhandelt.

Om de toestandsverandering op de CARP-interfaces af te vangen, dient de volgende configuratie te worden toegevoegd 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";
};

Draai het volgende commando 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).

Het volgende zou een voorbeeld van zo'n script kunnen zijn:

#!/bin/sh
# Origineel script door Freddie Cash <fjwcash@gmail.com>
# Gewijzigd door Michael W. Lucas <mwlucas@BlackHelicopters.org>
# en Viktor Petersson <vpetersson@wireload.net>

# 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 doet het script het volgende 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 de juiste plaats aankoppelen.

Wanneer een knooppunt backup / 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, maar 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.

Het debug-niveau van hastd(8) dient verhoogd te worden wanneer problemen met HAST worden verholpen. Dit kan gedaan 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. Het is ook de moeite te overwegen 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

Het gevolg van de situatie waarin beide knooppunten van het cluster niet met elkaar kunnen communiceren en beide als primaire knooppunten zijn ingesteld wordt split-brain genoemd. Dit is een gevaarlijke situatie omdat het beide knooppunten in staat stelt om incompatibele veranderingen aan de gegevens te maken. Deze situatie dient handmatig door de systeembeheerder te worden afgehandeld.

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

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