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
Received on Fri Apr 15 11:27:40 2011