Fri, 15 Apr 2011 12:27:21 +0200 On 15/04/2011, at 12.20, Gordan Bobic wrote: > Jon Bendtsen wrote: >> On 15/04/2011, at 01.01, Martin Fick wrote: >>> --- On Thu, 4/14/11, Gordan Bobic <gordan@bobich.net> wrote: >>>>> --- On Thu, 4/14/11, Gordan Bobic<gordan@bobich.net> >> [cuuuuuut] >>>> However >>>> - what use-case do you have where one guest will fail >>>> unrecoverably on one machine but resumes working on another >>>> machine with the exact same FS? In what case would a single >>>> guest fail without all of them failing? >>> Think load balancing. Say 10 vservers, split them >>> so that 5 run on each host normally. If either host >>> goes down, the other one picks up the slack. >>> Everything runs slower, but at least it still runs. >> I think about the same considerations at the moment, planning >> a new setup. >> Why not make 2 DRBD shares, A and B, put half of the vserver >> guests on the A storage, unify, them, and then put the other >> half on the B share. All the vserver guests on the A DRBD >> share runs on the A-host, and like wise with the B host. In >> daily usage you have no open files from the B share on the A >> host, so all the memory would be unified. In case of a split >> brain you can keep the guests running, and once you get >> connection again easily resync the DRBD. >> In case of 1 vserver host failing then you can just start >> all the vserver guests in DRBD share A on the vserver host >> B. Yes that will not unify both groups of hosts, but that >> should only be until you get the A host up again. >> So, what do you think? > > I still don't see the advantage of using DRBD for block-level replication here. The extra complication of having to deal with FS level fail-over doesn't seem to buy you anything compared to the lsyncd mirroring setup. can you guide me to a good lsyncd howto? can lsyncd replicate ACL? Can it replicate non linux vserver guests? (i'd rather have one sync system that does it all, than having multiple systems) JonB