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