On Tue, Oct 23, 2012 at 11:03:14AM +0200, Thilo Uttendorfer wrote:
> Hi,
> 
> the man-page of drbd.conf says about protocol B "...completed, if it has 
> reached local disk and remote buffer cache".
> 
> How can I determine the size of the remote buffer cache? Is this cache also 
> limited by the "max-buffers" option?

DRBDs max-buffers settings has something to do with it,
but that does not change between DRBD protocols.

There are pictures somewhere in those "papers" linked from the
documentation page. iirc.

Anyways, I'll try some ascii art:

Protocol C:
===========

  Primary                               Secondary
   incoming
  |         .
 t|         |\     data transfer latency
 i|  local  | `------>>-->>-->>-->>-->>-->>---. <- received the data
 m|  submit |                                 |
 e|         - local completion                | remote IO subsystem latency
  |                                           |
  |                                           |
  |                                          ,- remote completion
  |                 remote write ACK        /
  | COMPLETE <------<<--<<--<<--<<--<<--<<-´
  v

  If some client has seen a sucessful "commit",
  the cluster may even have a simultaneous power outage/crash,
  in which the primary is destroyed, still nothing is lost.

Protocol B:
===========

  Primary                               Secondary
   incoming
  |         .
 t|         |\     data transfer latency
 i|  local  | `------>>-->>-->>-->>-->>-->>---. <- received the data
 m|  submit |                                 |
 e|         - local completion               /| remote IO subsystem latency
  |               remote receive ACK        / |
  | COMPLETE <------<<--<<--<<--<<--<<--<<-´  |
  |                                           - remote completion
  |
  |
  v

  If some client has seen a sucessful "commit",
  the primary node may fail, and nothing is lost,
  as long as the other node stays up and takes over.

Protocol A:
===========

  Primary                               Secondary
   incoming
  |         .
 t|         |\     data transfer latency
 i|  local  | `------>>-->>-->>-->>-->>-->>---. <- received the data
 m|  submit |                                 |
 e| COMPLETE- local completion                | remote IO subsystem latency
  |                                           |
  |                                           |
  |                                           - remote completion
  |
  |
  v

  If some client has seen a sucessful "commit",
  if the primary node fails,
  that commit may or may not have made it to the peer.

Of course, the real thing is a bit more complex,
there are also the "DRBD Epochs" separated by "DRBD Barriers",
which are answered by "DRBD Barrier ACKs";
neither disk latency nor network latency is constant; ...
various other things that may have impact on latency and/or bandwidth.
In short, estimating the impact on performance is not always "intuitive".

Hth,

-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
_______________________________________________
drbd-user mailing list
drbd-user@lists.linbit.com
http://lists.linbit.com/mailman/listinfo/drbd-user

Reply via email to