/usr/share/doc/drbd-doc/users-guide/s-activity-log.html is in drbd-doc 8.4~20140825-1.
This file is owned by root:root, with mode 0o644.
The actual contents of the file can be viewed below.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 | <?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>17.3. The Activity Log</title><link rel="stylesheet" type="text/css" href="default.css" /><meta name="generator" content="DocBook XSL Stylesheets V1.78.1" /><link rel="home" href="drbd-users-guide.html" title="The DRBD User’s Guide" /><link rel="up" href="ch-internals.html" title="Chapter 17. DRBD Internals" /><link rel="prev" href="s-gi.html" title="17.2. Generation Identifiers" /><link rel="next" href="s-quick-sync-bitmap.html" title="17.4. The quick-sync bitmap" /></head><body><div class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="3" align="center">17.3. The Activity Log</th></tr><tr><td width="20%" align="left"><a accesskey="p" href="s-gi.html">Prev</a> </td><th width="60%" align="center">Chapter 17. DRBD Internals</th><td width="20%" align="right"> <a accesskey="n" href="s-quick-sync-bitmap.html">Next</a></td></tr></table><hr /></div><div class="section"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="s-activity-log"></a>17.3. The Activity Log</h2></div></div></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="s-al-purpose"></a>17.3.1. Purpose</h3></div></div></div><p><a id="idp54409008" class="indexterm"></a>During a write operation DRBD forwards the
write operation to the local backing block device, but also sends the
data block over the network. These two actions occur, for all
practical purposes, simultaneously. Random timing behavior may cause a
situation where the write operation has been completed, but the
transmission via the network has not yet taken place.</p><p>If, at this moment, the active node fails and fail-over is being
initiated, then this data block is out of sync between nodes — it has
been written on the failed node prior to the crash, but replication
has not yet completed. Thus, when the node eventually recovers, this
block must be removed from the data set of during subsequent
synchronization. Otherwise, the crashed node would be "one write
ahead" of the surviving node, which would violate the "all or
nothing" principle of replicated storage. This is an issue that is not
limited to DRBD, in fact, this issue exists in practically all
replicated storage configurations. Many other storage solutions (just
as DRBD itself, prior to version 0.7) thus require that after a
failure of the active, that node must be fully synchronized anew after
its recovery.</p><p>DRBD’s approach, since version 0.7, is a different one. The <span class="emphasis"><em>activity
log</em></span> (AL), stored in the meta data area, keeps track of those blocks
that have "recently" been written to. Colloquially, these areas are
referred to as <span class="emphasis"><em>hot extents</em></span>.</p><p>If a temporarily failed node that was in active mode at the time of
failure is synchronized, only those hot extents highlighted in the AL
need to be synchronized, rather than the full device. This drastically
reduces synchronization time after an active node crash.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="s-active-extents"></a>17.3.2. Active extents</h3></div></div></div><p><a id="idp54416400" class="indexterm"></a>The activity log has a configurable parameter,
the number of active extents. Every active extent adds 4MiB to the
amount of data being retransmitted after a Primary crash. This
parameter must be understood as a compromise between the following
opposites:</p><p><strong>Many active extents. </strong>Keeping a large activity log improves write throughput. Every time a
new extent is activated, an old extent is reset to inactive. This
transition requires a write operation to the meta data area. If the
number of active extents is high, old active extents are swapped out
fairly rarely, reducing meta data write operations and thereby
improving performance.</p><p><strong>Few active extents. </strong>Keeping a small activity log reduces synchronization time after active
node failure and subsequent recovery.</p></div><div class="section"><div class="titlepage"><div><div><h3 class="title"><a id="s-suitable-al-size"></a>17.3.3. Selecting a suitable Activity Log size</h3></div></div></div><p><a id="idp54422128" class="indexterm"></a>The definition of the number of extents should
be based on the desired synchronization time at a given
synchronization rate. The number of active extents can be calculated
as follows:</p><div class="figure"><a id="eq-al-extents"></a><p class="title"><strong>Figure 17.6. Active extents calculation based on sync rate and target sync time</strong></p><div class="figure-contents"><div class="mediaobject"><img src="al-extents.png" alt="al-extents" /></div></div></div><br class="figure-break" /><p><span class="emphasis"><em>R</em></span> is the synchronization rate, given in MB/s. <span class="emphasis"><em>t<sub>sync</sub></em></span> is the target
synchronization time, in seconds. <span class="emphasis"><em>E</em></span> is the resulting number of active
extents.</p><p>To provide an example, suppose our cluster has an I/O subsystem with a
throughput rate of 90 MiByte/s that was configured to a
synchronization rate of 30 MiByte/s (<span class="emphasis"><em>R</em></span>=30), and we want to keep our
target synchronization time at 4 minutes or 240 seconds
(<span class="emphasis"><em>t<sub>sync</sub></em></span>=240):</p><div class="figure"><a id="eq-al-extents-example"></a><p class="title"><strong>Figure 17.7. Active extents calculation based on sync rate and target sync time (example)</strong></p><div class="figure-contents"><div class="mediaobject"><img src="al-extents-example.png" alt="al-extents-example" /></div></div></div><br class="figure-break" /><p>The exact result is 1800, but since DRBD’s hash function for the
implementation of the AL works best if the number of extents is set to
a prime number, we select 1801.</p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="s-gi.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="ch-internals.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="s-quick-sync-bitmap.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">17.2. Generation Identifiers </td><td width="20%" align="center"><a accesskey="h" href="drbd-users-guide.html">Home</a></td><td width="40%" align="right" valign="top"> 17.4. The quick-sync bitmap</td></tr></table></div></body></html>
|