Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
----- Original Message ----- > From: "Eric Robinson" <eric.robinson at psmnv.com> > To: "Jake Smith" <jsmith at argotec.com> > Cc: drbd-user at lists.linbit.com > Sent: Tuesday, December 11, 2012 4:39:19 PM > Subject: RE: [DRBD-user] FileSystem Resource Won't Start > > Jake, > > > I believe it goes a little something like this... > > collocate resource B on A. > > Once the cluster has determined where to start A then B can > > start regardless of whether or not A has completed its start > > action. > > Think of resource A as something that takes 30 seconds to start. > > Then assume resource B requires it to be completely started > > before it can successfully start up. > > Now resource B fails to start... with an exit code that > > non-standard because something it's looking for is missing > > (since resource A isn't started yet) = infinity failure on > > current node. > > This will cause the cluster to move resource B to another > > node except no other nodes have resource A running which > > results in resource B being unable to run on any node. > > > > Add ordering A then B. > > Now the cluster will wait till A finishes starting (or for > > multi-state/DRBD promoting) before starting B on the same node. > > Everyone is happy. > > > > Does that make sense? > > > > > It does indeed by confirming and bringing definition to the foggy > notion that was bouncing around in my head. Thanks for going the > extra mile. > > FYI, following is what my cluster currently looks like in crm_mon. My > next goal is to get a bunch of mysql instances running. About half > of the instances will run on each node unless a node fails, in which > case one node will run all instances. The mysql instances are all > dependent on the underlying filesystem and VIP, but they are not > dependent on each other. So I do want the filesystem and VIP to > start before any mysql instances do, but I do not especially care > what order the mysql instances start in. > I would recommend checking out this link and the next page after it: http://clusterlabs.org/doc/en-US/Pacemaker/1.1-plugin/html/Pacemaker_Explained/s-resource-sets-ordering.html It get's confusing the first dozen times reading through it but you can write ordering and collocation statements that have sets of resources that are not started sequentially and dependent on each other. That way you can have 3 mysql's that are not dependent on each other but are dependent on the FS in one statement instead of writing 3 statement. If doing that be especially careful with the collocation statements because once you have a set (more than 2 resources with same action) the "order" of dependency is reversed - this only applies to collocation statements. You can see the way it is actually going to be enforced by the cluster by running "crm configure show xml" - the XML will display the actual order of the collocation. Couple quick examples then I'm off for the day :-) mysql's all have to run on same node as g_clust08 but are not affected by changes in the other mysql instances. Parenthesis indicates resources do don't depend on each others state. collocation c_example inf: (mysql_1 mysql_2 mysql_3) g_clust08 mysql's all have to wait for g_clust08 to start but they can all start simultaneously once g_clust08 is done. If one mysql is stopped the others are not affected. Parenthesis indicate the resource can be started in parallel. order o_example inf: g_clust08 (mysql_1 mysql_2 mysql_3) Jake