[DRBD-user] Can't Get DRBD Master/Slave out of secondary/secondary using pacemaker

Florian Haas florian at hastexo.com
Fri Oct 7 13:26:19 CEST 2011

Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.

On 2011-10-07 10:00, Arnold Krille wrote:
> On Friday 07 October 2011 09:50:47 Felix Frank wrote:
>> On 10/07/2011 09:41 AM, Arnold Krille wrote:
>>> The order on a colocation doesn't matter.
>> funny you should mention "order" in this context. You do in fact want to
>> add an order constraint for these resources.
> I know, but some people didn't want to believe me and said that the order of 
> elements inside the colocation was of any importance.

I'll make one more attempt at explaining. If your opinion is set and you
prefer not to be confused with facts, don't read on.

colocation foo_on_bar inf: foo bar

means that
1. foo is to run wherever bar runs;
2. if bar is not started, then foo won't run at all;
3. if bar fails and cannot recover, then foo will shut down;
4. if foo is not started, bar will of course run;
5. if foo fails and cannot recover, bar will continue to run.

In contrast,

colocation bar_on_foo inf: bar foo

means that
1. bar is to run wherever foo runs (_that_ part you can consider
semantically identical);
2. if bar is not started, foo will of course run;
3. if bar fails and cannot recover, foo will continue to run.
4. if foo is not started, then bar won't run at all;
5. if foo fails and cannot recover, then bar will shut down.

To make the point again with a sledge hammer, of the five (5) aspects
with which a colocation affects resource management, one (1) is
identical irrespective of the order in which the resources are listed in
the colocation definition. The other four (4) are not.

Hope this helps.

Need High Availability training?

More information about the drbd-user mailing list