Update to r44500:

Finish editorial review of HAST chapter.

Reviewed by:	bcr
Differential Revision:	https://reviews.freebsd.org/D5661
This commit is contained in:
Bjoern Heidotting 2016-03-16 20:30:45 +00:00
parent cf914d2ff9
commit f307cfe43e
Notes: svn2git 2020-12-08 03:00:23 +00:00
svn path=/head/; revision=48423

View file

@ -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
-->
<chapter xmlns="http://docbook.org/ns/docbook" xmlns:xlink="http://www.w3.org/1999/xlink" version="5.0" xml:id="disks">
<info><title>Speichermedien</title>
@ -3814,34 +3814,35 @@ Device 1K-blocks Used Avail Capacity
<para>Das Ziel dieses Beispiels ist, ein robustes
Speichersystem zu bauen, welches Fehlern auf einem
beliebigen Knoten widerstehen kann. Das Szenario besteht
darin, dass der <literal>primary</literal>-Knoten des
Clusters ausfällt. Sollte das passieren, ist der
beliebigen Knoten widerstehen kann. Wenn der
<literal>primary</literal>-Knoten ausfällt, ist der
<literal>secondary</literal>-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.</para>
<para>Um diese Aufgabe zu bewerkstelligen, wird eine
weitere Eigenschaft von &os; benutzt,
<acronym>CARP</acronym>, welches ein automatisches Failover
auf der IP-Schicht ermöglicht.
<acronym>CARP</acronym> (Common Address Redundancy Protocol)
erlaubt es mehreren Rechnern im gleichen Netzsegment, die
gleiche IP-Adresse zu verwenden. Setzen Sie
<para>Um diese Aufgabe zu bewerkstelligen, wird das
<foreignphrase>Common Address Redundancy
Protocol</foreignphrase> (<acronym>CARP</acronym>)
benutzt, welches ein automatisches Failover auf der
<acronym>IP</acronym>-Schicht ermöglicht.
<acronym>CARP</acronym> erlaubt es mehreren Rechnern im
gleichen Netzsegment, die gleiche
<acronym>IP</acronym>-Adresse zu verwenden. Setzen Sie
<acronym>CARP</acronym> auf beiden Knoten des Clusters
anhand der Dokumentation in <xref linkend="carp"/> auf.
Nach der Konfiguration wird jeder Knoten seine eigene
<filename>carp0</filename>-Schnittstelle, mit der geteilten
IP-Adresse <replaceable>172.16.0.254</replaceable> besitzen.
Der primäre <acronym>HAST</acronym>-Knoten des Clusters muss
der <acronym>CARP</acronym>-Masterknoten sein.</para>
In diesem Beispiel hat jeder Knoten seine eigene
Management <acronym>IP</acronym>-Adresse und die geteilte
<acronym>IP</acronym>-Adresse
<replaceable>172.16.0.254</replaceable>. Der primäre
<acronym>HAST</acronym>-Knoten des Clusters muss der
<acronym>CARP</acronym>-Masterknoten sein.</para>
<para>Der <acronym>HAST</acronym>-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 <acronym>NFS</acronym> oder <application>Samba</application>
erreicht werden, indem die geteilte IP-Addresse
erreicht werden, indem die geteilte <acronym>IP</acronym>-Addresse
<replaceable>172.16.0.254</replaceable> verwendet wird. Das einzige
ungelöste Problem ist der automatische Failover, sollte der
primäre Knoten einmal ausfallen.</para>
@ -3877,23 +3878,28 @@ notify 30 {
action "/usr/local/sbin/carp-hast-switch slave";
};</programlisting>
<note>
<para>Wenn auf dem System &os;&nbsp;10 oder höher eingesetzt
wird, ersetzen Sie <filename>carp0</filename> durch den
Namen der konfigurierten Schnittstelle für
<acronym>CARP</acronym>.</para>
</note>
<para>Starten Sie &man.devd.8; auf beiden Knoten neu, um
die neue Konfiguration wirksam werden zu lassen:</para>
<screen>&prompt.root; <userinput>service devd restart</userinput></screen>
<para>Wenn die <filename>carp0</filename>-Schnittstelle
<para>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,
<filename>/usr/local/sbin/carp-hast-switch</filename>.
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;.</para>
<para>Ein Beispiel für ein solches Skript könnte so
aussehen:</para>
<para>Es folgt ein Beispiel für ein automatisches
Failover-Skript:</para>
<programlisting>#!/bin/sh
@ -3902,7 +3908,7 @@ notify 30 {
# and Viktor Petersson &lt;vpetersson@wireload.net&gt;
# The names of the HAST resources, as listed in /etc/hast.conf
resources="test"
resources="<replaceable>test</replaceable>"
# delay in mounting HAST resource after becoming master
# make your best guess
@ -3980,8 +3986,7 @@ case "$1" in
esac</programlisting>
<para>Im Kern führt das Skript die folgenden Aktionen durch,
sobald ein Knoten zum <literal>master</literal> /
<literal>primary</literal> wird:</para>
sobald ein Knoten zum Master wird:</para>
<itemizedlist>
<listitem>
@ -3993,13 +3998,11 @@ esac</programlisting>
<acronym>HAST</acronym>-Pool erstellt wurde.</para>
</listitem>
<listitem>
<para>Es hängt die Pools an die richtige Stelle im System
ein.</para>
<para>Es hängt den Pool ins System ein.</para>
</listitem>
</itemizedlist>
<para>Wenn ein Knoten zum <literal>backup</literal> /
<literal>secondary</literal> ernannt wird:</para>
<para>Wenn ein Knoten zum Sekundären ernannt wird:</para>
<itemizedlist>
<listitem>
@ -4013,25 +4016,29 @@ esac</programlisting>
</itemizedlist>
<caution>
<para>Bitte beachten Sie, dass dieses Skript nur ein Beispiel
für eine mögliche Lösung darstellt. Es behandelt
<para>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.</para>
</caution>
<tip>
<para>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.</para>
<para>Für dieses Beispiel wurde ein
<acronym>UFS</acronym>-Dateisystem verwendet. Um die Zeit
für die Wiederherstellung zu verringern, kann ein
<acronym>UFS</acronym> mit Journal oder ein
<acronym>ZFS</acronym>-Dateisystem benutzt werden.</para>
</tip>
<para>Weitere detaillierte Informationen mit zusätzlichen
Beispielen können auf der <link xlink:href="http://wiki.FreeBSD.org/HAST">HAST Wiki</link>-Seite
abgerufen werden.</para>
Beispielen können unter <link
xlink:href="http://wiki.FreeBSD.org/HAST">
http://wiki.FreeBSD.org/HAST</link> abgerufen
werden.</para>
</sect3>
</sect2>
<sect2>
<title>Fehlerbehebung</title>
@ -4040,18 +4047,17 @@ esac</programlisting>
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.</para>
Zeit für alle Knoten im Cluster synchron läuft.</para>
<para>Für die Fehlersuche bei Problemen mit
<acronym>HAST</acronym> sollte die Anzahl an
Debugging-Meldungen von &man.hastd.8; erhöht werden. Dies
kann durch das Starten des &man.hastd.8; mit
<literal>-d</literal> 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
<literal>-F</literal> in Erwägung ziehen, die
&man.hastd.8; im Vordergrund startet.</para>
<para>Für die Fehlersuche bei <acronym>HAST</acronym> sollte
die Anzahl an Debugging-Meldungen von &man.hastd.8; erhöht
werden. Dies kann durch das Starten von
<command>hastd</command> mit <literal>-d</literal> erreicht
werden. Diese Option kann mehrfach angegeben werden, um die
Anzahl an Meldungen weiter
zu erhöhen. Sie sollten ebenfalls die Verwendung von
<literal>-F</literal> in Erwägung ziehen, was
<command>hastd</command> im Vordergrund startet.</para>
<sect3 xml:id="disks-hast-sb">
<title>Auflösung des Split-brain-Zustands</title>
@ -4066,17 +4072,16 @@ esac</programlisting>
vom Systemadministrator händisch bereinigt werden.</para>
<para>Der Administrator muss entscheiden, welcher Knoten die
wichtigsten Änderungen von beiden besitzt (oder diese
manuell miteinander vermischen) und anschliessend den
<acronym>HAST</acronym>-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:</para>
wichtigeren Änderungen besitzt, oder die Zusammenführung
manuell durchführen. Anschließend kann
<acronym>HAST</acronym> 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:</para>
<screen>&prompt.root; <userinput>hastctl role init &lt;resource&gt;</userinput>
&prompt.root; <userinput>hastctl create &lt;resource&gt;</userinput>
&prompt.root; <userinput>hastctl role secondary &lt;resource&gt;</userinput></screen>
<screen>&prompt.root; <userinput>hastctl role init <replaceable>test</replaceable></userinput>
&prompt.root; <userinput>hastctl create <replaceable>test</replaceable></userinput>
&prompt.root; <userinput>hastctl role secondary <replaceable>test</replaceable></userinput></screen>
</sect3>
</sect2>
</sect1>