On Fri, May 30, 2008 at 5:39 PM, Alain St-Denis <[EMAIL PROTECTED]> wrote: > Hello, > > Since nobody paid attention to my first post, here I am again with more > details...
Sorry about that - It was still in my queue of emails to process. Alas sometimes the simpler emails get answered first because one can do so quickly. > > I modified the LVM RA so it works on logical volumes instead of volume groups > and made it a master/slave RA. The goal is to use heartbeat to control > logical volume activation (we are using shared disks and gave up on cluster > lvm) to guard ourselves against human or software error. My RA makes the > logical volumes it controls available on one node only (one master, x > slaves). It is working as I expect in situations involving start and stop > actions, but I am scratching my head trying to figure out how to take > advantage of the xen live migration feature. Given a cluster resource(A) resource(B) resource(C) colocate(A with B) colocate(B with C) order(A needs B) order(B needs C) Then only C can ever be migrated. The reason being that for a service to be migrated, its dependancies need to be available on both nodes. Of course if C is a clone, then now B can be migrated without violating the ordering or colocation constraints (but A still needs to be stopped). In your scenario, B=Xen and C=LVM (your master/slave RA) - So far so good. The problem, as others have recently pointed out, is that only one node ever has the volume mounted and so the "its dependancies need to be available on both nodes" requirement fails and (at least for now) you'll never get this to work properly (at least not without a high degree of trickery that may not even exist). We hope to implement freeze/thaw "this year", which might allow migration in more cases. But until then, you'll need to look at storing the images on OCFS2 and/or using a clustered volume manager. Hope this helps, and sorry for the delay. Andrew > The following constraints don't > do the job: > > <rsc_order id="order_xen_start" from="resource_xen" to_action="promote" > to="master_lvs"/> > <rsc_order id="order_xen_migrate" from="resource_xen" to_action="promote" > to="master_lvs" action="migrate_to" symmetrical="false"/> > <rsc_colocation id="xen_with_master_lvs" to_role="Master" > from="resource_xen" to="master_lvs" from_role="Started" score="INFINITY" > symmetrical="false"/> > > If I issue a migrate on resource_xen, I see this from pengine > > pengine: [13220]: notice: complex_migrate_reload: Migrating resource_xen from > sss4 to sss3 > > which is encouraging. But at the same time, tengine says: > > tengine: [13219]: ERROR: te_graph_trigger: Transition failed: terminated > > which can't be a good sign. > > The master_lvs resource has > > clone_max = 2 > clone_node_max = 1 > master_max = 1 > master_node_max =1 > > I have the feeling "master_max = 1" is not helping. If I set master_max to 2 > and remove the colocation constraint above, live migration works. But this is > not what I want. Is there a way to tell a master/slave resource that its > master_max is 2 but only 1 will be promoted most of the time? > > BTW, this is with 2.1.3 and pacemaker 0.6.2. > > Thanks > > Alain > > Le lundi 26 mai 2008 12:44, Alain St-Denis a écrit : >> Hello Linux-HA, >> >> I would like to set up two resources, one of which is a xen guest and the >> other is a LVM2 logical volume, lets call them xenA and resB, where xenA >> depends on resB. I can figure out how to set up the appopriate co-location >> and order constraints for the start and stop actions, but what about >> migrate_to and migrate_from? While live migration occurs, two instances of >> resB must be running. The RA associated with resB only does "lvchange -a y >> LV" on start and "lvchange -a n LV" on stop. >> >> If anyone can send pointers on how to achieve the following: >> >> xenA and resB are running on node1 >> a live migration is initiated to node2 >> resB starts on node2 but keeps running on node1 >> xenA migrates to node2 >> resB is stopped on node1 >> xenA and resB are running on node2 >> >> I'd appreciate it. Any information on how the migrate_to and migrate_from >> actions are implemented would also be useful. It seems to me defining those >> actions for the resB RA may be the thing to do, as long as co-location and >> order constraints can be set for those actions. >> >> Thanks in advance, >> >> Alain > > -- > Alain St-Denis > Supercomputing, Systems and Storage > Canadian Meteorological Centre > Meteorological Service of Canada > Environment Canada > Tel: +1 514 421 4697 > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems > _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
