On Feb 3, 2008, at 10:39 PM, Amos Shapira wrote:
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).
Crashing?
What was the subject? I don't recall this.
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
