On 23/08/2013, at 5:15 PM, Ulrich Windl <[email protected]> 
wrote:

>>>> Andrew Beekhof <[email protected]> schrieb am 23.08.2013 um 02:14 in 
>>>> Nachricht
> <[email protected]>:
> 
>> On 22/08/2013, at 7:31 PM, Ulrich Windl <[email protected]> 
>> wrote:
>> 
>>> Hi!
>>> 
>>> Suppose you have an application A that needs two filesystems F1 and F2. The 
>> filesystems are on separate LVM VGs VG1 and VG2 with LVs L1 and L2, 
>> respectively. The RAID R1 and R2 provide the LVM PVs.
>>> 
>>> (Actually we have one group that has 58 primitives in them with both 
>> dimensions being wider than in this example)
>>> 
>>> So you can configure
>>> "group grp_A R1 R2 VG1 VG2 F1 F2 A" (assuming the elements are primitives 
>> already configured)
>>> 
>>> Now for example if R2 has a problem, the cluster will restart the whole 
>> group of resources, even that sequence that is unaffected (R1 VG1 F1). This 
>> causes extra operations and time for recovery what you don't like.
>> 
>> So don't put them in a group?
>> 
>>> 
>>> What you can do now is having parallel execution like this
>>> "group grp_A (R1 R2) (VG1 VG2) (F1 F2) A"
>> 
>> You're saying this is currently possible?
> 
> As it turned out: "not yet" ;-) It only works for explicit "ordering".

That makes more sense.

> 
> 
>> If so, crmsh must be re-writing this into something other than a group.
> 
> This should not be much of a problem; the problem seems to be: How to convert 
> such structures back to the original notation?

Quite hard to know what the original form was

> 
>> 
>>> (Note that this is probably a bad idea as the RAIDs and VGs (and maybe 
>>> mount 
>> also) most likely use a common lock each that forces serialization)
>>> 
>>> For the same failure scenario R2 wouldn't be restarted, so the gain is 
>> small. A better approach seems to be
>>> "group grp_A (R1 VG1 F1) (R2 VG2 F2) A"
>>> 
>>> Now for the same failure R1, VG1, and F1 will survive; unfortunately if R1 
>> fails, then everything will be restarted, like in the beginning.
>>> 
>>> So what you really want is
>>> "group grp_A ((R1 VG1 F1) (R2 VG2 F2)) A"
>>> 
>>> Now if R2 fails, then R1, VG1, and F1 will survive, and if R1 fails, then 
>> R2, VG2 and F2 will survive
>>> 
>>> Unfortunately the syntax of the last example is not supported.
>> 
>> I'm surprised the one before it is even supported. Groups of groups have 
>> never been supported.
> 
> I know, and the PDP-8 had 128kB RAM. But things can change.

Not groups of groups.
Hell, I'd get rid of groups completely if I could

> 
>> 
>>> This one isn't either:
>>> 
>>> group grp_1 R1 VG1 F1
>>> group grp_2 R2 VG2 F2
>>> group grp_A (grp_1 grp_2) A
>>> 
>>> So a group of groups would be nice to have. I thought about that long time 
>> ago, but only yesterday I learned about the syntax of "netgroups" which has 
>> exactly that: a netgroup can contain another netgroup ;-)
>>> 
>>> Regards,
>>> Ulrich
>>> 
>>> 
>>> _______________________________________________
>>> 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

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to