From owner-svn-doc-head@FreeBSD.ORG Fri Mar 13 21:26:53 2015 Return-Path: Delivered-To: svn-doc-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C584CCBA; Fri, 13 Mar 2015 21:26:53 +0000 (UTC) Received: from svn.freebsd.org (svn.freebsd.org [IPv6:2001:1900:2254:2068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF43E9C8; Fri, 13 Mar 2015 21:26:53 +0000 (UTC) Received: from svn.freebsd.org ([127.0.1.70]) by svn.freebsd.org (8.14.9/8.14.9) with ESMTP id t2DLQrwu018216; Fri, 13 Mar 2015 21:26:53 GMT (envelope-from bhd@FreeBSD.org) Received: (from bhd@localhost) by svn.freebsd.org (8.14.9/8.14.9/Submit) id t2DLQrfc018215; Fri, 13 Mar 2015 21:26:53 GMT (envelope-from bhd@FreeBSD.org) Message-Id: <201503132126.t2DLQrfc018215@svn.freebsd.org> X-Authentication-Warning: svn.freebsd.org: bhd set sender to bhd@FreeBSD.org using -f From: Bjoern Heidottin Date: Fri, 13 Mar 2015 21:26:53 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r46341 - head/de_DE.ISO8859-1/books/handbook/disks X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the doc tree for head List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2015 21:26:53 -0000 Author: bhd Date: Fri Mar 13 21:26:52 2015 New Revision: 46341 URL: https://svnweb.freebsd.org/changeset/doc/46341 Log: Update to r38003: Improve the HAST section of the Handbook. Approved by: bcr (mentor) Modified: head/de_DE.ISO8859-1/books/handbook/disks/chapter.xml Modified: head/de_DE.ISO8859-1/books/handbook/disks/chapter.xml ============================================================================== --- head/de_DE.ISO8859-1/books/handbook/disks/chapter.xml Fri Mar 13 06:28:33 2015 (r46340) +++ head/de_DE.ISO8859-1/books/handbook/disks/chapter.xml Fri Mar 13 21:26:52 2015 (r46341) @@ -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: 1.315 + basiert auf: r38003 --> Speichermedien @@ -4695,11 +4695,11 @@ Device 1K-blocks Used Av DNS. - Da nun die Konfiguration auf beiden Rechnern vorhanden ist, sind - Sie in der Lage, den HAST-Pool zu erstellen. Lassen - Sie die folgenden Kommandos auf beiden Knoten ablaufen, um die - initialen Metadaten auf die lokale Platte zu schreiben und starten Sie - anschliessend den &man.hastd.8;-Dienst: + Da nun die Konfiguration auf beiden Rechnern vorhanden + ist, kann ein HAST-Pool erstellt werden. + Lassen Sie diese Kommandos auf beiden Knoten ablaufen, um die + initialen Metadaten auf die lokale Platte zu schreiben und + starten Sie anschliessend den &man.hastd.8;-Dienst: &prompt.root; hastctl create test &prompt.root; /etc/rc.d/hastd onestart @@ -4713,93 +4713,93 @@ Device 1K-blocks Used Av zur Verfügung stehen wird. - HAST ist nicht dafür verantwortlich, die Rolle - (primary oder secondary) für - den jeweiligen Knoten festzulegen. Die Rolle des Knotens muss vom - Administrator oder einer anderen Software wie - Heartbeat mittels des - &man.hastctl.8;-Werkzeugs festgelegt werden. Auf dem primären - Knoten (hasta) geben Sie - nun den folgenden Befehl ein: + Die Rolle eines HAST Knotens (primary + oder secondary) wird vom einem + Administrator, oder einer Software wie + Heartbeat, mittels des + &man.hastctl.8;-Werkzeugs festgelegt. Auf dem primären + Knoten (hasta) geben Sie diesen Befehl + ein: &prompt.root; hastctl role primary test - Geben Sie nun, ähnlich wie zuvor, das folgende Kommando auf - dem sekundären Knoten - (hastb) ein: + Geben Sie folgendes Kommando auf dem sekundären + Knoten (hastb) ein: &prompt.root; hastctl role secondary test - Es kann passieren, dass beide Knoten nicht in der Lage sind, - miteinander zu kommunizieren und dadurch beide als primäre - Knoten konfiguriert sind; die Konsequenz daraus wird als - split-brain bezeichnet. Um diese Situation zu - bereinigen, folgen Sie den Schritten, die in beschrieben sind. + Es kann passieren, dass beide Knoten nicht in der Lage + sind, miteinander zu kommunizieren und dadurch beide als + primäre Knoten konfiguriert sind; die Konsequenz daraus wird + als split-brain bezeichnet. Um diese + Situation zu bereinigen, folgen Sie den Schritten, die + in beschrieben sind. - Es ist möglich das Ergebnis des &man.hastctl.8;-Werkzeugs auf - jedem Knoten zu überprüfen: + Überprüfen Sie das Ergebnis mit &man.hastctl.8; auf beiden + Knoten: &prompt.root; hastctl status test - Der wichtigste Teil ist die status-Textzeile der - Ausgabe, die auf jedem Knoten complete lauten - sollte. Falls der Status als degraded - zurückgemeldet wird, ist etwas schief gegangen. Zu diesem - Zeitpunkt hat die Synchronisation zwischen den beiden Knoten bereits - begonnen. Die Synchronisation ist beendet, wenn das Kommando - hastctl status meldet, dass die - dirty-Bereiche 0 Bytes betragen. - - Der letzte Schritt ist, ein Dateisystem auf dem - /dev/hast/test - GEOM-Provider anzulegen und dieses ins System einzuhängen. Dies - muss auf dem primary-Knoten durchgeführt werden - (da /dev/hast/test nur - auf dem primary-Knoten erscheint). Dies kann ein - paar Minuten dauern, abhängig von der Grösse der - Festplatte: + Der wichtigste Teil ist die + status-Textzeile, die auf jedem Knoten + complete lauten sollte. Falls der Status + als degraded zurückgemeldet wird, ist etwas + schief gegangen. Zu diesem Zeitpunkt hat die Synchronisation + zwischen den beiden Knoten bereits begonnen. Die + Synchronisation ist beendet, wenn + hastctl status meldet, dass die + dirty-Bereiche 0 Bytes betragen. + + Der nächste Schritt ist, ein Dateisystem auf dem + /dev/hast/test GEOM-Provider anzulegen + und dieses ins System einzuhängen. Dies muss auf dem + primary-Knoten durchgeführt werden, da + /dev/hast/test nur auf dem + primary-Knoten erscheint. Die Erstellung + des Dateisystems kann ein paar Minuten dauern, abhängig von + der Grösse der Festplatte: &prompt.root; newfs -U /dev/hast/test &prompt.root; mkdir /hast/test &prompt.root; mount /dev/hast/test /hast/test - Sobald das HAST-Framework richtig konfiguriert - wurde, besteht der letzte Schritt nun darin, sicherzustellen, dass - HAST während des Systemstarts automatisch - gestartet wird. Die folgende Zeile sollte zur Datei - /etc/rc.conf hinzugefügt werden: + Sobald das HAST-Framework richtig + konfiguriert wurde, besteht der letzte Schritt nun darin, + sicherzustellen, dass HAST während des + Systemstarts automatisch gestartet wird. Fügen Sie diese + Zeile in /etc/rc.conf hinzu: hastd_enable="YES" 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 &os; 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 auf. Nachdem dieser Schritt - abgeschlossen ist, sollte jeder Knoten seine eigene - carp0-Schnittstelle mit der geteilten + 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 + 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, + welche ein automatisches Failover auf der IP-Schicht + ermöglicht: CARP. + CARP (Common Address Redundancy Protocol) + 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. - Selbstverständlich muss der primäre - HAST-Knoten des Clusters der - CARP-Masterknoten sein. + 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 @@ -4810,21 +4810,22 @@ Device 1K-blocks Used Av ungelöste Problem ist der automatische Failover, sollte der primäre Knoten einmal ausfallen. - Falls die CARP-Schnittstelle aktiviert oder - deaktiviert wird, generiert das &os;-Betriebssystem ein - &man.devd.8;-Ereignis, was es ermöglicht, - Zustandsänderungen auf den + Falls die CARP-Schnittstelle + aktiviert oder deaktiviert wird, generiert das + &os;-Betriebssystem ein &man.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 + Zustandsänderung auf der + CARP-Schnittstelle ist ein Indiz dafür, + dass einer der Knoten gerade ausgefallen oder wieder + verfügbar ist. Diese Zustandsänderungen machen es möglich, + ein Skript zu starten, welches automatisch den HAST-Failover 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: + Um Zustandsänderungen auf der + CARP-Schnittstelle abzufangen, müssen + diese Zeilen in /etc/devd.conf auf + jedem Knoten hinzugefügt werden: notify 30 { match "system" "IFNET"; @@ -4840,9 +4841,8 @@ notify 30 { action "/usr/local/sbin/carp-hast-switch slave"; }; - Um diese neue Konfiguration zu aktivieren, starten Sie - &man.devd.8; auf beiden Knoten neu, um die neue Konfiguration - wirksam werden zu lassen: + Starten Sie &man.devd.8; auf beiden Knoten neu, um + die neue Konfiguration wirksam werden zu lassen: &prompt.root; /etc/rc.d/devd restart @@ -4857,7 +4857,7 @@ notify 30 { genauere Informationen zu der obigen &man.devd.8;-Konfiguration, lesen Sie die &man.devd.conf.5;-Manualpage. - Ein Beispiel für ein solches Skript könnte wie folgt + Ein Beispiel für ein solches Skript könnte so aussehen: #!/bin/sh @@ -5010,37 +5010,38 @@ esac 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 &man.hastd.8; sollte - erhöht werden, wenn Fehler von HAST bereinigt - werden. Dies kann durch das Starten des &man.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 &man.hastd.8;-Dienst in den Vordergrund - bringt. + 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;-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 + &man.hastd.8;-Dienst in den Vordergrund bringt. 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 + split-brain bezeichnet eine + Situation, in der beide Knoten des Clusters nicht in der + Lage sind, miteinander zu kommunizieren und dadurch beide + als primäre Knoten fungieren. 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 + Änderungen an den Daten vorzunehmen, die miteinander nicht + in Einklang gebracht werden können. Diese Situation muss + 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>