Date: Wed, 9 Apr 2014 14:04:20 +0000 (UTC) From: Dru Lavigne <dru@FreeBSD.org> To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r44501 - head/en_US.ISO8859-1/books/handbook/disks Message-ID: <201404091404.s39E4Kgk062447@svn.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dru Date: Wed Apr 9 14:04:20 2014 New Revision: 44501 URL: http://svnweb.freebsd.org/changeset/doc/44501 Log: White space fix only. Translators can ignore. Sponsored by: iXsystems Modified: head/en_US.ISO8859-1/books/handbook/disks/chapter.xml Modified: head/en_US.ISO8859-1/books/handbook/disks/chapter.xml ============================================================================== --- head/en_US.ISO8859-1/books/handbook/disks/chapter.xml Wed Apr 9 13:44:05 2014 (r44500) +++ head/en_US.ISO8859-1/books/handbook/disks/chapter.xml Wed Apr 9 14:04:20 2014 (r44501) @@ -3675,21 +3675,20 @@ Device 1K-blocks Used Av <para>The goal of this example is to build a robust storage system which is resistant to the failure of any given node. - If the primary node - fails, the - secondary node is there to take over - seamlessly, check and mount the file system, and continue to - work without missing a single bit of data.</para> - - <para>To accomplish this task, the Common - Address Redundancy Protocol - (<acronym>CARP</acronym>) is used to provide for automatic failover at - the <acronym>IP</acronym> layer. <acronym>CARP</acronym> allows multiple hosts on the - same network segment to share an <acronym>IP</acronym> address. Set up - <acronym>CARP</acronym> on both nodes of the cluster - according to the documentation available in - <xref linkend="carp"/>. In this example, each node will - have its own management <acronym>IP</acronym> address and a + If the primary node fails, the secondary node is there to + take over seamlessly, check and mount the file system, and + continue to work without missing a single bit of + data.</para> + + <para>To accomplish this task, the Common Address Redundancy + Protocol (<acronym>CARP</acronym>) is used to provide for + automatic failover at the <acronym>IP</acronym> layer. + <acronym>CARP</acronym> allows multiple hosts on the same + network segment to share an <acronym>IP</acronym> address. + Set up <acronym>CARP</acronym> on both nodes of the cluster + according to the documentation available in <xref + linkend="carp"/>. In this example, each node will have + its own management <acronym>IP</acronym> address and a shared <acronym>IP</acronym> address of <replaceable>172.16.0.254</replaceable>. The primary <acronym>HAST</acronym> node of the cluster must be the @@ -3699,10 +3698,11 @@ Device 1K-blocks Used Av section is now ready to be exported to the other hosts on the network. This can be accomplished by exporting it through <acronym>NFS</acronym> or - <application>Samba</application>, using the shared <acronym>IP</acronym> - address <replaceable>172.16.0.254</replaceable>. The only - problem which remains unresolved is an automatic failover - should the primary node fail.</para> + <application>Samba</application>, using the shared + <acronym>IP</acronym> address + <replaceable>172.16.0.254</replaceable>. The only problem + which remains unresolved is an automatic failover should the + primary node fail.</para> <para>In the event of <acronym>CARP</acronym> interfaces going up or down, the &os; operating system generates a @@ -3714,9 +3714,8 @@ Device 1K-blocks Used Av which will automatically handle the HAST failover.</para> <para>To catch state changes on the - <acronym>CARP</acronym> interfaces, add this - configuration to - <filename>/etc/devd.conf</filename> on each node:</para> + <acronym>CARP</acronym> interfaces, add this configuration + to <filename>/etc/devd.conf</filename> on each node:</para> <programlisting>notify 30 { match "system" "IFNET"; @@ -3743,16 +3742,16 @@ notify 30 { <screen>&prompt.root; <userinput>service devd restart</userinput></screen> - <para>When the specified interface state - changes by going up or down , the system generates a - notification, allowing the &man.devd.8; subsystem to run the - specified automatic failover script, + <para>When the specified interface state changes by going up + or down , the system generates a notification, allowing the + &man.devd.8; subsystem to run the specified automatic + failover script, <filename>/usr/local/sbin/carp-hast-switch</filename>. - For further - clarification about this configuration, - refer to &man.devd.conf.5;.</para> + For further clarification about this configuration, refer to + &man.devd.conf.5;.</para> - <para>Here is an example of an automated failover script:</para> + <para>Here is an example of an automated failover + script:</para> <programlisting>#!/bin/sh @@ -3857,8 +3856,7 @@ esac</programlisting> </listitem> </itemizedlist> - <para>When a node becomes - secondary:</para> + <para>When a node becomes secondary:</para> <itemizedlist> <listitem> @@ -3872,16 +3870,18 @@ esac</programlisting> </itemizedlist> <caution> - <para>This is just an example script which - serves as a proof of concept. It does not handle all the - possible scenarios and can be extended or altered in any - way, for example, to start or stop required services.</para> + <para>This is just an example script which serves as a proof + of concept. It does not handle all the possible scenarios + and can be extended or altered in any way, for example, to + start or stop required services.</para> </caution> <tip> - <para>For this example, a standard <acronym>UFS</acronym> file system was used. - To reduce the time needed for recovery, a journal-enabled - <acronym>UFS</acronym> or <acronym>ZFS</acronym> file system can be used instead.</para> + <para>For this example, a standard <acronym>UFS</acronym> + file system was used. To reduce the time needed for + recovery, a journal-enabled <acronym>UFS</acronym> or + <acronym>ZFS</acronym> file system can be used + instead.</para> </tip> <para>More detailed information with additional examples can @@ -3902,21 +3902,21 @@ esac</programlisting> <para>When troubleshooting <acronym>HAST</acronym>, the debugging level of &man.hastd.8; should be increased by - starting <command>hastd</command> with <literal>-d</literal>. This - argument may be specified multiple times to further increase - the debugging level. Consider also using - <literal>-F</literal>, which starts <command>hastd</command> in the - foreground.</para> + starting <command>hastd</command> with <literal>-d</literal>. + This argument may be specified multiple times to further + increase the debugging level. Consider also using + <literal>-F</literal>, which starts <command>hastd</command> + in the foreground.</para> <sect3 xml:id="disks-hast-sb"> <title>Recovering from the Split-brain Condition</title> - <para><firstterm>Split-brain</firstterm> occurs when the nodes of the - cluster are unable to communicate with each other, and both - are configured as primary. This is a dangerous condition - because it allows both nodes to make incompatible changes to - the data. This problem must be corrected manually by the - system administrator.</para> + <para><firstterm>Split-brain</firstterm> occurs when the nodes + of the cluster are unable to communicate with each other, + and both are configured as primary. This is a dangerous + condition because it allows both nodes to make incompatible + changes to the data. This problem must be corrected + manually by the system administrator.</para> <para>The administrator must decide which node has more important changes or merge them manually. Then, let
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201404091404.s39E4Kgk062447>