[DRBD-user] stacked primaries-scenarios and drbd proxy size

Nils Stöckmann N.Stoeckmann at demetec.de
Thu Sep 27 17:09:37 CEST 2012

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

Am 27.09.2012 15:41, schrieb Lars Ellenberg:
> On Thu, Sep 27, 2012 at 01:08:37PM +0200, Nils Stöckmann wrote:
>> Hi Lars,
>> I more or less recognized drbd is not what I need on monday and
>> unsubscribed today from drbd-users just minutes before I saw you answer
>> to my mail. I somehow missed it in a block of unread mail, sorry about that.
>> I will be giving CODA a try, a distributed file system.
>> If you feel my response could be helpful to others, please forward it to
>> the drbd-users list.
> I have a few more comments inline.
>> Am 21.09.2012 10:16, schrieb Lars Ellenberg:
>>>> To accomplish this,  I had the idea to build this:
>>>> MAIN SITE            ||          Small Office Site
>>>> A           B                    C
>>>> |           |                    |
>>>> RAID        RAID                 RAID
>>>> |
>>>> DRBD1-Gbit--DRBD1       
>>>> |             | 
>>>> |           DRBD2------VPN-------DRBD2
>>>> |             |                    |
>>>> LVM          LVM                  LVM
>>>> Nodes A and B shall be used for load balancing and shall be able to
>>>> dynamically switch tasks and active services.
>>> What exactly do you want to load-balance,
>>> and why do you think you need to load-balance it?
>> Actually no single service needs to be load-balanced, however a lot of
>> services will be running on the machines, and having all run on one
>> would reduce its responsiveness in an extent, that it is noticeable to
>> the users. Not bad, but still noticeable.
>> The resulting configuration is more like high availibility.
> So you don't need cluster file systems or multi-primary at all.
> At least not for "load balancing".
> You can have some DRBD Primary on A, some on B, and if you chose so,
> even a few on C, and move them around as needed.
You are totally right in this point. For the *service-backends* there is
no need for multiple primaries at all.
However, what I didn't write out is that the mentioned change-rates and
data volumes are normal shared files which are being worked on at the
same time on both sides of the VPN tunnel B---C.
To avoid version problems between the sites, I intended mutliple
primaries with cluster filesystem.

> Fortunately, if I understand correctly, you don't even need your data
> everywhere at the same time, but only on service migration? 
Unfortunatley, I do need most of the data at the same time writeable in
two spots (say: B;C).
The third spot (say: A) is - considering the main volume of the data -
for high availibility / disaster recovery purposes.

As I stated previously: As an alternative in the stacked primaries
scenario, it would be possible to have one of the main site servers
(A,B) be secondary and have it awarded the primary role in case the
other one of those two fails.
>> What I really need is a way for three-way live read/write
>> data-synchronization, including the internet.
> *why*
> What for.
Because there are two groups of people in two sites working on the same
set of network-shared files.

> Probably many people wish for this,
> but few actually *need* it.
>> rsync is not really an option because of the lacking liveness and the
>> deleted/new-problem
>> At the moment i continouusly run into csync-errors (permission denied
>> and "format error while receiving data", i posted that one on
>> csync2-users, that's one reason I don't take that as an alternative.
>> Plus: It's not really live. It has to scan the filesystem for changes
>> each time.
> There is an inotify daemon for csync2...
Sounds interesting...

More information about the drbd-user mailing list