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...