On 06/02/2008, at 05.19, Christian Balzer wrote:
>
> On Tue, 5 Feb 2008 14:00:23 +0100 Jon Bendtsen wrote:
>> On 03/02/2008, at 11.07, Christian Balzer wrote:
>>
>>>
>>> Hello,
>>>
>>> 2 hosts, shared storage (SAN, DRBD, iSCSI, it doesn't really matter)
>>> and Linux HA aka heartbeat as a CRM. The obvious goal is to have the
>>> vservers on host A to fail over to B if need be.
>>> The equally obvious problem is that util-vserver is expecting the
>>> configs
>>> in /etc/vservers and the vserver command has no command line
>>> option to
>>> specify the config directory.
>>
>> If you use a different mark in /etc/vservers/*/apps/init/mark
>> Like A or B, and then start the respective vserver guests
>> for the respective real servers. Should the other server fail,
>> just start the vservers with that servers mark.
>>
>> That way you should be able to keep all /etc/vservers/* copied
>> on all servers without problems.
>>
> That is thought, but it requires to keep /etc/vservers in sync
> between the nodes. Which do share the storage, but don't have
> active/active mounted cluster filesystems (none of them have
> impressed me in the past in terms of feature completeness and/or
> speed and adding them into the mix with vserver sounds too much like
> a giant headache to me)
How often do you change /etc/vservers/* ? my guess is rarely. So
just rsync it often. Maybe make all changes on a master and rsync
it to the other vserver hosts.
>> You might also be able to keep the "home" dirs in /var/lib/vservers/*
>> copied.
>>
> And mount them individually below there? Which reminds me to
> thank Martin Fick for the Fail-over link on the vserver wiki.
> It was a good read, but I'm not planning to have individual
> partitions for each vserver, too much overhead and too rigid
> when it comes to disk quotas.
I was not thinking about mouting them individual. I was thinking of
having one big filespace and then sync between the hosts.
> So what I'm planning to do is ideally to just have one partition
> per cluster node, which gets mounted on the other one in case of
> node failure. With a structure something like:
>
> /data-a/etc/vservers/
> /data-a/vservers/vserver-001/
> [...]
>
> and /etc/vservers and /var/lib/vservers pointing to the respective
> directories on the node that is the default host for these. So
> with nothing failed over, vserver-utils will work just fine and
> out of the box. In a fail-over case (lets say node B to A), the OCF
> script
> will just have to do a "vserver /data-b/etc/vservers vserver-n
> start" for
> each vserver, the list of which it of course could determine by a
> "mark".
>
> In case I go with a uniform/shared config in /etc/vservers, I would
> still
> have to mount the actual vserver partition like:
> /var/lib/vserver/data-a/ [vserver-001...]
> /var/lib/vserver/data-b/ [vserver-050...]
>
> to avoid barrier issues, right?
Not if they are already mounted. It should not be too hard to parse
/etc/vservers/<NAME>/apps/init/mark
and see what host is the homeserver of this particular guest, and then
often sync this guests directory from /var/lib/vservers/<NAME>/ to the
other server. Keeping 1. extra backup.
JonB
Received on Mon Feb 18 09:17:39 2008