2008/5/21 Andrew Beekhof <[EMAIL PROTECTED]>: > > 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 <[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 > _______________________________________________ Pacemaker mailing list Pacemaker@clusterlabs.org http://list.clusterlabs.org/mailman/listinfo/pacemaker
