Index: head/de_DE.ISO8859-1/books/handbook/disks/chapter.xml =================================================================== --- head/de_DE.ISO8859-1/books/handbook/disks/chapter.xml +++ head/de_DE.ISO8859-1/books/handbook/disks/chapter.xml @@ -5,7 +5,7 @@ $FreeBSD$ $FreeBSDde: de-docproj/books/handbook/disks/chapter.xml,v 1.187 2012/04/26 19:32:48 bcr Exp $ - basiert auf: r44488 + basiert auf: r44500 --> Speichermedien @@ -3814,34 +3814,35 @@ Das Ziel dieses Beispiels ist, ein robustes Speichersystem zu bauen, welches Fehlern auf einem - beliebigen Knoten widerstehen kann. Das Szenario besteht - darin, dass der primary-Knoten des - Clusters ausfällt. Sollte das passieren, ist der + beliebigen Knoten widerstehen kann. Wenn der + primary-Knoten ausfällt, 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 geht. - Um diese Aufgabe zu bewerkstelligen, wird eine - weitere Eigenschaft von &os; benutzt, - CARP, welches ein automatisches Failover - auf der IP-Schicht ermöglicht. - CARP (Common Address Redundancy Protocol) - erlaubt es mehreren Rechnern im gleichen Netzsegment, die - gleiche IP-Adresse zu verwenden. Setzen Sie + Um diese Aufgabe zu bewerkstelligen, wird das + Common Address Redundancy + Protocol (CARP) + benutzt, welches ein automatisches Failover auf der + IP-Schicht ermöglicht. + CARP 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 auf. - Nach der Konfiguration wird jeder Knoten seine eigene - carp0-Schnittstelle, mit der geteilten - IP-Adresse 172.16.0.254 besitzen. - Der primäre HAST-Knoten des Clusters muss - der CARP-Masterknoten sein. + In diesem Beispiel hat jeder Knoten seine eigene + Management IP-Adresse und die geteilte + IP-Adresse + 172.16.0.254. Der primäre + HAST-Knoten des Clusters muss 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 oder Samba - erreicht werden, indem die geteilte IP-Addresse + 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. @@ -3877,23 +3878,28 @@ action "/usr/local/sbin/carp-hast-switch slave"; }; + + Wenn auf dem System &os; 10 oder höher eingesetzt + wird, ersetzen Sie carp0 durch den + Namen der konfigurierten Schnittstelle für + CARP. + + Starten Sie &man.devd.8; auf beiden Knoten neu, um die neue Konfiguration wirksam werden zu lassen: &prompt.root; service devd restart - Wenn die carp0-Schnittstelle + Wenn die Schnittstelle aktiviert oder deaktiviert wird, erzeugt das System eine Meldung, was es dem &man.devd.8;-Subsystem ermöglicht, ein - beliebiges Skript zu starten, in diesem Fall also + automatisches Failover-Skript zu starten, /usr/local/sbin/carp-hast-switch. - Dieses Skript führt den automatischen Failover durch. - Weitere Informationen zu der obigen - &man.devd.8;-Konfiguration, finden Sie in + Weitere Informationen zu dieser Konfiguration finden Sie in &man.devd.conf.5;. - Ein Beispiel für ein solches Skript könnte so - aussehen: + Es folgt ein Beispiel für ein automatisches + Failover-Skript: #!/bin/sh @@ -3902,7 +3908,7 @@ # and Viktor Petersson <vpetersson@wireload.net> # The names of the HAST resources, as listed in /etc/hast.conf -resources="test" +resources="test" # delay in mounting HAST resource after becoming master # make your best guess @@ -3980,8 +3986,7 @@ esac Im Kern führt das Skript die folgenden Aktionen durch, - sobald ein Knoten zum master / - primary wird: + sobald ein Knoten zum Master wird: @@ -3993,13 +3998,11 @@ HAST-Pool erstellt wurde. - Es hängt die Pools an die richtige Stelle im System - ein. + Es hängt den Pool ins System ein. - Wenn ein Knoten zum backup / - secondary ernannt wird: + Wenn ein Knoten zum Sekundären ernannt wird: @@ -4013,25 +4016,29 @@ - Bitte beachten Sie, dass dieses Skript nur ein Beispiel - für eine mögliche Lösung darstellt. Es behandelt + Dieses Skript ist nur ein Beispiel für eine mögliche + Lösung. Es behandelt nicht alle möglichen Szenarien, die auftreten können und sollte erweitert bzw. abgeändert werden, so dass z.B. benötigte Dienste gestartet oder gestoppt werden. - Für dieses Beispiel wurde ein Standard-UFS Dateisystem - verwendet. Um die Zeit für die Wiederherstellung zu - verringern, kann ein UFS mit Journal oder ein ZFS-Dateisystem - benutzt werden. + Für dieses Beispiel wurde ein + UFS-Dateisystem verwendet. Um die Zeit + für die Wiederherstellung zu verringern, kann ein + UFS mit Journal oder ein + ZFS-Dateisystem benutzt werden. Weitere detaillierte Informationen mit zusätzlichen - Beispielen können auf der HAST Wiki-Seite - abgerufen werden. + Beispielen können unter + http://wiki.FreeBSD.org/HAST abgerufen + werden. + Fehlerbehebung @@ -4040,18 +4047,17 @@ 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. + Zeit für alle Knoten im Cluster synchron läuft. - Für die Fehlersuche bei Problemen mit - HAST sollte die Anzahl an - Debugging-Meldungen von &man.hastd.8; erhöht werden. Dies - kann durch das Starten des &man.hastd.8; mit - -d erreicht werden. Diese Option kann - mehrfach angegeben werden, um die Anzahl an Meldungen weiter - zu erhöhen. Auf diese Weise erhalten Sie viele nützliche - Informationen. Sie sollten ebenfalls die Verwendung von - -F in Erwägung ziehen, die - &man.hastd.8; im Vordergrund startet. + Für die Fehlersuche bei HAST sollte + die Anzahl an Debugging-Meldungen von &man.hastd.8; erhöht + werden. Dies kann durch das Starten von + hastd mit -d erreicht + werden. Diese Option kann mehrfach angegeben werden, um die + Anzahl an Meldungen weiter + zu erhöhen. Sie sollten ebenfalls die Verwendung von + -F in Erwägung ziehen, was + hastd im Vordergrund startet. Auflösung des Split-brain-Zustands @@ -4066,17 +4072,16 @@ vom Systemadministrator händisch bereinigt werden. Der Administrator muss 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 folgende - Befehle auf dem Knoten ein, der neu synchronisiert werden - soll: - - &prompt.root; hastctl role init <resource> -&prompt.root; hastctl create <resource> -&prompt.root; hastctl role secondary <resource> + wichtigeren Änderungen besitzt, oder die Zusammenführung + manuell durchführen. Anschließend kann + HAST die volle Synchronisation mit + dem Knoten durchführen, der die beschädigten Daten enthält. + Um dies zu tun, geben Sie folgende Befehle auf dem Knoten + ein, der neu synchronisiert werden muss: + + &prompt.root; hastctl role init test +&prompt.root; hastctl create test +&prompt.root; hastctl role secondary test