<xref linkend="metadatereplay"/>. For information on recovering from a
corrupt file system, see <xref linkend="commitonshare"/>. For
information on resolving orphaned objects, a common issue after recovery,
- see <xref linkend="dbdoclet.50438225_13916"/>. For information on
+ see <xref linkend="orphan_objects"/>. For information on
imperative recovery see <xref linkend="imperativerecovery"/>
</para>
<section remap="h3">
<para>If multiple MDTs are in use, active-active failover
is possible (e.g. two MDS nodes, each actively serving one or more
different MDTs for the same filesystem). See
- <xref linkend="dbdoclet.mdtactiveactive"/> for more information.</para>
+ <xref linkend="mdtactiveactive"/> for more information.</para>
</section>
<section remap="h3">
<title><indexterm><primary>recovery</primary><secondary>OST failure</secondary></indexterm>OST Failure (Failover)</title>
</section>
<section xml:id="imperativerecovery">
<title><indexterm><primary>imperative recovery</primary></indexterm>Imperative Recovery</title>
- <para>Large-scale Lustre file system implementations have historically experienced problems
- recovering in a timely manner after a server failure. This is due to the way that clients
- detect the server failure and how the servers perform their recovery. Many of the processes
- are driven by the RPC timeout, which must be scaled with system size to prevent false
- diagnosis of server death. The purpose of imperative recovery is to reduce the recovery window
- by actively informing clients of server failure. The resulting reduction in the recovery
- window will minimize target downtime and therefore increase overall system availability.
+ <para>Large-scale Lustre filesystems will experience server hardware
+ failures over their lifetime, and it is important that servers can
+ recover in a timely manner after such failures. High Availability
+ software can move storage targets over to a backup server automatically.
+ Clients can detect the server failure by RPC timeouts, which must be
+ scaled with system size to prevent false diagnosis of server death in
+ cases of heavy load. The purpose of imperative recovery is to reduce
+ the recovery window by actively informing clients of server failure.
+ The resulting reduction in the recovery window will minimize target
+ downtime and therefore increase overall system availability.</para>
+ <para>
Imperative Recovery does not remove previous recovery mechanisms, and client timeout-based
recovery actions can occur in a cluster when IR is enabled as each client can still
independently disconnect and reconnect from a target. In case of a mix of IR and non-IR
</itemizedlist>
<section remap="h3">
<title><indexterm><primary>pings</primary><secondary>suppress_pings</secondary></indexterm>"suppress_pings" Kernel Module Parameter</title>
- <para>The new option that controls whether pings are suppressed is implemented as the ptlrpc kernel module parameter "suppress_pings". Setting it to "1" on a server turns on ping suppressing for all targets on that server, while leaving it with the default value "0" gives previous pinging behavior. The parameter is ignored on clients and the MGS. While the parameter is recommended to be set persistently via the modprobe.conf(5) mechanism, it also accept online changes through sysfs. Note that an online change only affects connections established later; existing connections' pinging behaviors stay the same.</para>
+ <para>The new option that controls whether pings are suppressed is
+ implemented as the ptlrpc kernel module parameter "suppress_pings".
+ Setting it to "1" on a server turns on ping suppressing for all
+ targets on that server, while leaving it with the default value "0"
+ gives previous pinging behavior. The parameter is ignored on clients
+ and the MGS. While the parameter is recommended to be set persistently
+ via the modprobe.conf(5) mechanism, it also accept online changes
+ through sysfs. Note that an online change only affects connections
+ established later; existing connections' pinging behaviors stay the same.
+ </para>
</section>
<section remap="h3">
<title><indexterm><primary>pings</primary><secondary>evict_client</secondary></indexterm>Client Death Notification</title>
- <para>The required external client death notification shall write UUIDs of dead clients into targets' "evict_client" procfs entries like</para>
- <screen>
-/proc/fs/lustre/obdfilter/testfs-OST0000/evict_client
-/proc/fs/lustre/obdfilter/testfs-OST0001/evict_client
-/proc/fs/lustre/mdt/testfs-MDT0000/evict_client
- </screen>
- <para>Clients' UUIDs can be obtained from their "uuid" procfs entries like</para>
- <screen>
-/proc/fs/lustre/llite/testfs-ffff8800612bf800/uuid
- </screen>
+ <para>The required external client death notification shall write UUIDs
+ of dead clients into targets' <literal>evict_client</literal> procfs
+ entries in order to remove stale clients from recovery.</para>
+ <para>A client UUID can be obtained from their <literal>uuid</literal>
+ procfs entry and that UUID can be used to evict the client, like:
+ </para>
+<screen>
+client$ lctl get_param llite.testfs-*.uuid
+llite.testfs-ffff991ae1992000.uuid=dd599d28-0a85-a9e4-82cd-dc6357a42c77
+oss# lctl set_param obdfilter.testfs-*.evict_client=dd599d28-0a85-a9e4-82cd-dc6357a42c77
+mds# lctl set_param mdt.testfs-*.evict_client=dd599d28-0a85-a9e4-82cd-dc6357a42c77
+</screen>
</section>
</section>
git://git.whamcloud.com / doc / manual.git / blobdiff