[Pacemaker] Manging Virtual Machine's resource

[Xinwei Hu]

2008/5/21 Andrew Beekhof <beekhof at gmail.com>:
>
> 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).

I'm not talking about a mixed cluster of VM and physical servers. ;)
So yes, you still have to set dom0 name for STONITH.
Plus, I didn't managed to run pacemaker on VMware ESX server. :P

> 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!
>
Yes, and that's why I switch back to the simplest solution :)

>
>>>  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.
>
I mean function inheritance and override.
>>>
>>
>> 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 <beekhof at gmail.com>:
>>>>
>>>> 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 at clusterlabs.org
>>> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>>
>>
>> _______________________________________________
>> Pacemaker mailing list
>> Pacemaker at clusterlabs.org
>> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>