On Feb 4, 2008 7:13 AM, Lars Marowsky-Bree <[EMAIL PROTECTED]> wrote:
> On 2008-02-01T13:12:53, Michael Schwartzkopff <[EMAIL PROTECTED]> wrote: > > > HA! Even better solution: > > 8 virtual machines on 2 physical servers form one cluster. heartbeat in > that > > cluster can monitor application resources. > > Layered heartbeat clusters don't work well right now. > > Your best bet really is to run the 8 virtual machines on the two > physical nodes, and have heartbeat+PaceMaker/CRM run directly on the > physical machines (managing the guests) - service availability can be > checked by connecting to the guests via TCP and seeing whether their > hosted service is still available. > > That is the least complex solution to your problem. Actually, we are in the process of setting up something similar: 2 guest Xen hosts (each having separate function) on each physical machine, with heartbeat directly between the Xen guests and their tweens on another physical machine. The guests share data partitions via DRBD. I too was wondering whether I should do the HA at the host level but it looks much simpler to do the heartbeat directly between the guests because, for instance, it looks much simpler to manage the DRBD access (primary/secondary, mount/umount) directly from inside the Xen guests than from the host (the Xen guest can't even access the DRBD'ed Logical Volume). So far it works well in my tests. Still have to finish the setup and see the performance, though. How should I go about if I wanted to do this at the host level? I though maybe DRBD'ing the data partition while the stand-by guest is in "xm save", then if the Xen hosts decide to take over the resources then it should "xm restore" the Xen guest? I don't have enough experience with that side of Xen, only reading the docs about this. Setup is Intel Xeon 5130, CentOS 5, Xen 3.0.3, heartbeat 2.1.2 using haresources (the new CRM-style config kept crashing on me, as I asked here a few weeks ago). Cheers, --Amos _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
