On 9/22/07, Joseph Lamoree <[EMAIL PROTECTED]> wrote: > I have a two-node cluster that has two multi-state resources, each of > which contain a DRBD primitive. These two resources must be promoted > to master on the same node, but that's not always the case -- > especially after one or the other nodes go to standby and back online. > Currently constraints exist like so: > > <rsc_colocation from="drbd1" to="drbd0" to_role="master" score="INFINITY"/> > <rsc_order from="nfs1_fs_nfsmd" action="start" to="drbd0" > to_action="promote"/> > <rsc_order from="nfs1_fs_ss" action="start" to="drbd1" to_action="promote"/> > <rsc_colocation from="nfs1_fs_nfsmd" to="drbd0" to_role="master" > score="INFINITY"/> > <rsc_colocation from="nfs1_fs_ss" to="drbd1" to_role="master" > score="INFINITY"/> > > The meaning that I intended is this: > Always have drbd0 and drbd1 run as master on the same node.
i'm not very familiar with drbd, is this some sort of requirement it has? > Start drbd0 and drbd1 before mounting their filesystems > Always make drbd0 and drbd1 master before mounting their filesystems sounds reasonable > However, in reading through the information on multi state clone > resources, I believe it may be better to assert the negative > conditions. shouldn't be required. where did you read that? > I'm sure this is a common requirement for systems with two > DRBD resources that need to be masters on the same node. I would > appreciate guidance from users that have this type of configuration > working properly. > > I don't know if this is by design, but when a node comes back from > standby, the other node will stop all its resources and then restart > them -- even though the resources should stay in place on the node > acting as master. what version do you have? some older versions had trouble with this. > I increased the default resource stickiness in an > effort to prevent this, but it didn't make a difference. In the > process, the second DRBD gets all confused: > > Master/Slave Set: drbd0 > drbd0_nfsmd:0 (heartbeat::ocf:drbd): Master teri > drbd0_nfsmd:1 (heartbeat::ocf:drbd): Started eve > Master/Slave Set: drbd1 > drbd1_ss:0 (heartbeat::ocf:drbd): Slave teri (unmanaged) FAILED looking at the CIB you attached, this is because it failed to stop on teri > drbd1_ss:1 (heartbeat::ocf:drbd): Started eve > > In this state, I thought I could use drbdadm up ss && drbdadm primary > ss, then crm_resource -R, but that doesn't fix it up. try -C instead > I've attached > the CIB when in this state, if it'll help. somewhat can you attach the logs too? i'd like to see how we got into this state. > > I know that's a whole lot. Thanks for your patience. > > -- > Joseph Lamoree > > _______________________________________________ > 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
