On May 21, 2008, at 8:10 AM, Nitin wrote:
On Wed, 2008-05-21 at 11:13 +0800, Xinwei Hu wrote:
We had a deployment of this kind running for more then a half year.
2 lessons we had so far:
1. Start a "standalone" heartbeat inside VM is the best option so
far.
i.e "ucast lo 127.0.0.1" in ha.cf
It's the simplest way to have monitoring and restarting inside VM.
Yes. we thought of that but want to use it as the last resort.
2. Manage VMs as Xen resources in a cluster of all dom0.
However,
a. VMs might be migrated between dom0s anytime, so set dom0 as a
parameter to STONITH plugin is not ideal in practice. (The same
problem applies to VMware ESX server also.)
Why even set a dom0 name?
Just have a clone that only runs on physical machines (use a node
attribute) and have the STONITH plugin examine its own list of nodes
it can fence (the vmware STONITH plugin does something like this).
It makes no sense for VMs to run a STONITH resource (assuming they're
part of the cluster - I'm not 100% sure what you're proposing), since
the only method of communication to the STONITH device (dom0) is
inherently unreliable (ie. ssh/telnet).
Sidenote: Yes, I have been known to advocate using ssh-based STONITH
plugins - but only in cases where there is no alternative.
In this case there is a viable alternative, the dom0 hosts.
Writing a STONITH plugin is not the hard part of having a mixed
physical+VM cluster... it gets "interesting" when you start thinking
about cases like: what happens when a cluster split happens and a
minority of the physical nodes are able to shoot the larger set of
physical nodes because they have enough VMs to steal quorum, or: Can
VMs shoot physical machines? How does it know not to shoot the one
it's running on!
b. VM is a typical example that we'd better support "inheritance"
for RA. VM's RA can only tell whether it's running, but there're
different ways to tell if the OS (Linux, BSD, Windows, Netware)
inside
is health.
I don't understand how attribute inheritance could possibly hide the
differences between operating systems.
If this "inheritance" implementation can bring proportionate value
then
let us implement it. Lon Hohberger has already shown interest in this.
May I request to Andrew Beekhof and other veterans :) to advise on
implementation complexity versus use of this feature.
Thanks for sharing your valuable experience.
My .2c
2008/5/19 Andrew Beekhof <[EMAIL PROTECTED]>:
On May 19, 2008, at 7:14 AM, Nitin wrote:
On Fri, 2008-05-16 at 15:08 +0200, Andrew Beekhof wrote:
On May 16, 2008, at 3:04 PM, Nitin wrote:
Hello,
I would like to make my virtual machines (DomUs) resources to
participate in the HA cluster. Dom0 (Physical Host) may or may
not
have
resources.
To do this I would like to treat DomUs as *resource* in the
cluster as
opposed to treating them as *nodes*. I am planning to write OCF
resource
agents for virtual machines. But I am not very sure about how to
make a
resource's resource to participate in the cluster.
Is there any configuration in existing structure to achieve
this??
If no
then please tell me how to go about creating a "container"
resource in
CRM.
Why not just use the Xen agent if you don't want them to be
cluster
nodes?
Or do you mean that you want them to both be resources and to run
other resources too?
Yes. Please advise me how to go about it.
Thanks a lot for reply.
We don't have a clean way to do that yet
Possible options:
a) start the services at VM boot (you don't get monitoring)
b) start the services at VM boot and modify the Xen agent to
monitor the
services inside the VM (ugly)
c) add a proxy resource to start/stop/monitor the services inside
the VM
(complex)
d) implement a generic version of c)
e) have the VM join the cluster (makes stonith and quorum
"interesting")
f) wait for us to implement clusters-of-clusters which also solves
this
scenario "for free"
g) something else i've not thought of
_______________________________________________
Pacemaker mailing list
Pacemaker@clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker
_______________________________________________
Pacemaker mailing list
Pacemaker@clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker
_______________________________________________
Pacemaker mailing list
Pacemaker@clusterlabs.org
http://list.clusterlabs.org/mailman/listinfo/pacemaker
