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.
You have two similar servers, and the data on them is mirrored. For
databases, you use replication. Everything else (except logs and things
you don't want mirrored) you set lsyncd at, on host level. Obviously,
you exclude /vserver/.hash. You handle hashifying separately and
independently on both machines.
This will give you close()-level consistency in near real-time, and you
don't have to worry about failing over file systems. It makes your
heartbeat configuration much simpler, you just have to fail over IP
addresses. _AND_ your hashified files will work correctly WRT memory
savings on both of the machines, even in case of fail-over (i.e. the
surviving server won't get hit for the extra memory overhead when it
gets hit for running the guests from the failed host).
Gordan
Received on Fri Apr 15 11:20:40 2011