[DRBD-user] Syncer question

Doug Lochart dlochart at gmail.com
Fri Feb 15 20:18:13 CET 2008

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.


Thank you so much for that synopsis.  You made it very clear and now I
see the correlation.  Once I finish I *hope* to be able to write a
tutorial that covers heartbeat, drbd, stonith, etc.  With permission I
would like to include your detailed synopsis.  Of course with proper
recognition.

regards,

Douglas Lochart

On Fri, Feb 15, 2008 at 7:09 AM, Lars Ellenberg
<lars.ellenberg at linbit.com> wrote:
> On Thu, Feb 14, 2008 at 10:07:39AM -0500, Doug Lochart wrote:
>  > >  > I am using DRBD to mirror a 1 terrabyte device.  I will be syncing
>  > >  > over a gigabit switch so I assume I can use 100M to 150M as a rate
>  > >  > safely.  There will be other traffic on the switch.  However I do not
>  > >  > seem to understand how the al-extents parameter is used.  Most
>  > >  > examples leave it set to 257 and that is good for an active set of 1
>  > >  > Gig.  Could someone explain what the active set implies AND what are
>  > >  > the pros/cons of increasing the active set size or do I need to woory
>  > >  > about.
>  > >
>  > >  please read
>  > >  http://www.drbd.org/fileadmin/drbd/publications/drbd8.linux-conf.eu.2007.pdf
>  > >
>
> > Forgive me if I am obviously too stupid to understand but I did read
>  > that document and it did not help.  It makes no mention of the
>  > parameters in question nor enough information for me to relate the
>  > information in the document to drbd.conf file entries.
>  >
>  > I can understand (not really) but I can accept not being offered a
>  > high level and simplified explanation of my questions.  I do ask
>  > however help on correlating the config file parameters in question to
>  > the contents of the this  document.
>  >
>  > To others I would accept a high level synopsis of what the parameters
>  > affect and how to use them to tune my replication.  Armed with a high
>  > level view I hope to be able to correlate them back to the technical
>  > details on this document.
>
>  ok, sorry.
>  section 6 explains the problem of finding which blocks might have been
>  modified independently during different degraded situations.
>
>  6.1 explains the easy part, where we have just a network hickup:
>     we can use the in-memory dirty-bitmap on the Primary.
>
>  6.2 explains why the bitmap alone does not suffice when we think of
>     Primary node crash.
>
>  6.3 argues against synchronous "write intent bitmap writes"
>
>  6.4 explains what we do to reliably keep track of the
>     target blocks of in-flight IO, while minimizing
>     the frequency of housekeeping meta data transactions.
>
>  it summarizes:
>     The number of slots in the activity-log is tunable
>  [this is the al-extents configuration parameter you asked for],
>  the trade-of is larger activity-log, less frequent meta data
>  transactions, less likely to introduce maximum latency because of
>  activity-log starvation, but also longer minimum resync time after
>  Primary crash.
>
>  say you have 2.5 TByte of storage.
>
>  |-- 2.5 TB of storage ---------------------------------------------|
>  |- 4MB -|- 4MB -|-~~ // ~~-|- 4MB -|- 4MB -|- 4MB -|- 4MB -|- 4MB -|
>    0         1 extent numbers ....   655356  655357  655358  655359
>
>  you have 655360 extents/areas/regions/whatever of 4MB each.
>  the al-extent parameter tunes how many of them may be target of
>  in-flight writes at the same time.
>
>  you set al-extents = 7
>
>  you have a set of
>   [ 0, 1, 2, 17, 35, 270, 87 ] in the activity log.
>
>  you want to write to somewhere in 37, which is not in the al.
>  so you wait for any of the regions in the set to become unused,
>  put that region out of the active set, put the 37 into the active set,
>  and write that transaction to disk, which takes some time.
>  only after that has happened, the original write to the 37 extent
>  may continue.
>
>  if a crashed primary comes up again, the active set at the time of the
>  crash will be reconstructed from these meta data transactions (the
>  on-disk activity log), and all bits corresponding to any active set will
>  be dirtied (reason given in section 6.2).
>
>  so again:
>   you go up with al-extents, you have less frequent meta data
>  transactions, less frequently interruption of your IO stream
>  for it, you less frequently introduce this additional latency.
>  but if your primary crashes, it has to resync all extents that have been
>  in the active set, you have to resync more if the set is larger.
>
>  does that help at all?
>
>  --
>
>
> : Lars Ellenberg                           http://www.linbit.com :
>  : DRBD/HA support and consulting             sales at linbit.com :
>  : LINBIT Information Technologies GmbH      Tel +43-1-8178292-0  :
>  : Vivenotgasse 48, A-1120 Vienna/Europe     Fax +43-1-8178292-82 :
>  __
>  please use the "List-Reply" function of your email client.
>  _______________________________________________
>  drbd-user mailing list
>  drbd-user at lists.linbit.com
>  http://lists.linbit.com/mailman/listinfo/drbd-user
>



-- 
What profits a man if he gains the whole world yet loses his soul?



More information about the drbd-user mailing list