Re: [Pacemaker] [Question]About "sequential" designation of resource_set.
Hi Andrew,
Thank you for comments.
We demand time and the same movement that appointed ordered=false of the group
resource.
* Case 0 - group : orderded=false
* At the time of orderded=false, it takes start of vip-rep. > We
demand!!
{{{
(snip)
(snip)
[root@rh64-heartbeat1 ~]# grep "Initiating action" /var/log/ha-log
Mar 22 21:45:01 rh64-heartbeat1 crmd: [2625]: info: te_rsc_command: Initiating
action 2: probe_complete probe_complete on rh64-heartbeat1 (local) - no waiting
Mar 22 21:46:36 rh64-heartbeat1 crmd: [2625]: info: te_rsc_command: Initiating
action 4: monitor vip-master_monitor_0 on rh64-heartbeat1 (local)
Mar 22 21:46:36 rh64-heartbeat1 crmd: [2625]: info: te_rsc_command: Initiating
action 5: monitor vip-rep_monitor_0 on rh64-heartbeat1 (local)
Mar 22 21:46:36 rh64-heartbeat1 crmd: [2625]: info: te_rsc_command: Initiating
action 3: probe_complete probe_complete on rh64-heartbeat1 (local) - no waiting
Mar 22 21:46:36 rh64-heartbeat1 crmd: [2625]: info: te_rsc_command: Initiating
action 6: start vip-master_start_0 on rh64-heartbeat1 (local)
Mar 22 21:46:36 rh64-heartbeat1 crmd: [2625]: info: te_rsc_command: Initiating
action 8: start vip-rep_start_0 on rh64-heartbeat1 (local)
Mar 22 21:46:37 rh64-heartbeat1 crmd: [2625]: info: te_rsc_command: Initiating
action 1: stop vip-master_stop_0 on rh64-heartbeat1 (local)
Mar 22 21:46:37 rh64-heartbeat1 crmd: [2625]: info: te_rsc_command: Initiating
action 5: stop vip-rep_stop_0 on rh64-heartbeat1 (local)
}}}
I tried an all combination of ordering_set and colocation_set.
However, start of vip-rep was not carried out by all combinations.
* I do not do the "ordered=false" designation of the group resource.
* Case 1 : true/true
{{{
(snip)
(snip)
[root@rh64-heartbeat1 ~]# grep "Initiating action" /var/log/ha-log
Mar 22 21:30:26 rh64-heartbeat1 crmd: [2076]: info: te_rsc_command: Initiating
action 2: probe_complete probe_complete on rh64-heartbeat1 (local) - no waiting
Mar 22 21:33:36 rh64-heartbeat1 crmd: [2076]: info: te_rsc_command: Initiating
action 8: monitor vip-master_monitor_0 on rh64-heartbeat1 (local)
Mar 22 21:33:36 rh64-heartbeat1 crmd: [2076]: info: te_rsc_command: Initiating
action 9: monitor vip-rep_monitor_0 on rh64-heartbeat1 (local)
Mar 22 21:33:36 rh64-heartbeat1 crmd: [2076]: info: te_rsc_command: Initiating
action 7: probe_complete probe_complete on rh64-heartbeat1 (local) - no waiting
Mar 22 21:33:36 rh64-heartbeat1 crmd: [2076]: info: te_rsc_command: Initiating
action 10: start vip-master_start_0 on rh64-heartbeat1 (local)
Mar 22 21:33:36 rh64-heartbeat1 crmd: [2076]: info: te_rsc_command: Initiating
action 1: stop vip-master_stop_0 on rh64-heartbeat1 (local)
}}}
* Case 2 : true/false
{{{
(snip)
(snip)
[root@rh64-heartbeat1 ~]# grep "Initiating action" /var/log/ha-log
Mar 22 21:36:38 rh64-heartbeat1 crmd: []: info: te_rsc_command: Initiating
action 2: probe_complete probe_complete on rh64-heartbeat1 (local) - no waiting
Mar 22 21:36:49 rh64-heartbeat1 crmd: []: info: te_rsc_command: Initiating
action 8: monitor vip-master_monitor_0 on rh64-heartbeat1 (local)
Mar 22 21:36:49 rh64-heartbeat1 crmd: []: info: te_rsc_command: Initiating
action 9: monitor vip-rep_monitor_0 on rh64-heartbeat1 (local)
Mar 22 21:36:49 rh64-heartbeat1 crmd: []: info: te_rsc_command: Initiating
action 7: probe_complete probe_complete on rh64-heartbeat1 (local) - no waiting
Mar 22 21:36:49 rh64-heartbeat1 crmd: []: info: te_rsc_command: Initiating
action 10: start vip-master_start_0 on rh64-heartbeat1 (local)
Mar 22 21:36:50 rh64-heartbeat1 crmd: []: info: te_rsc_command: Initiating
action 1: stop vip-master_stop_0 on rh64-heartbeat1 (local)
}}}
* Cse 3 : false/true
{{{
(snip)
(snip)
[root@rh64-heartbeat1 ~]# grep "Initiating action" /var/log/ha-log
Mar 22 21:38:51 rh64-heartbeat1 crmd: [2358]: info: te_rsc_command: Initiating
action 2: probe_complete probe_complete on rh64-heartbeat1 (local) - no waiting
Mar 22 21:39:07 rh64-heartbeat1 crmd: [2358]: info: te_rsc
Re: [Pacemaker] [Question]About "sequential" designation of resource_set.
On Fri, Mar 22, 2013 at 1:02 PM, wrote:
> Hi Andrew,
>
> Thank your for comment.
>
>> Sorry, I'm not sure I understand the question.
>
> Sorry
>
> When we use resource_set in substitution for ordered of a thing of group
> resource, do we use "colocation set"?
> Or do we use "ordering set "?
If you want ordering, use an ordering set.
If you want colocation, use a colocation set.
In both cases you want sequential=true.
"sequential=false" is only useful when there are multiple sets.
Ie. you want A and B colocated with C _but_ you want A to continue
running if B is stopped (and B to keep running if A is stopped).
Then you'd have two sets, { A, B } colocated with { C } where the A,B
set has sequential=false.
>
> It does not seem to do work same as "group ordered=fase" if it is right to
> use "ordering set".
Correct. A group with ordered=false is only providing colocation - so
you want a colocation set.
A group with colocate=false is only providing ordering - so you'd
want an order set.
> Best Regards,
> Hideo Yamauchi.
>
> --- On Fri, 2013/3/22, Andrew Beekhof wrote:
>
>> On Fri, Mar 22, 2013 at 12:34 PM, wrote:
>> > Hi Andrew,
>> >
>> > Thank your for comments.
>> >
>> >> > > You use the resource sets _instead_ of a group.
>> >> > > If you want group.ordered=false, then use a colocation set (with
>> >> > > sequential=true).
>> >>
>> >> In "colocation", I used "resource_set".
>> >> However, a result did not include the change.
>> >> Will this result be a mistake of my setting?
>> >>
>> >> Case 1) sequential=false
>> >> (snip)
>> >>
>> >>
>> >> > >> id="test-colocation-resource_set">
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> What are trying to achieve with this? It doesn't do anything because
>> >> there is nothing to collocate master or rep with.
>> >> The only value here is to show that rep would not be stopped when master
>> >> is.
>> >
>> > However, you made next reply.
>> > I used colocation_set in substitution for ordered=false.
>> >
>> >>>You use the resource sets _instead_ of a group.
>> >>>If you want group.ordered=false, then use a colocation set (with
>> >>>sequential=true).
>> >>>If you want group.colocated=false, then use an ordering set (with
>> >>>sequential=true).
>> >
>> > After all is it right that the substitute for ordered=false of group sets
>> > order_set?
>>
>> Sorry, I'm not sure I understand the question.
>>
>> >
>> > Best Regards,
>> > Hideo Yamauchi.
>> >
>> >
>> >
>> > --- On Fri, 2013/3/22, Andrew Beekhof wrote:
>> >
>> >>
>> >>
>> >> On Thursday, March 7, 2013, wrote:
>> >> Hi Andrew,
>> >>
>> >> > > You use the resource sets _instead_ of a group.
>> >> > > If you want group.ordered=false, then use a colocation set (with
>> >> > > sequential=true).
>> >>
>> >> In "colocation", I used "resource_set".
>> >> However, a result did not include the change.
>> >> Will this result be a mistake of my setting?
>> >>
>> >> Case 1) sequential=false
>> >> (snip)
>> >>
>> >>
>> >> > >> id="test-colocation-resource_set">
>> >>
>> >>
>> >>
>> >>
>> >>
>> >>
>> >> What are trying to achieve with this? It doesn't do anything because
>> >> there is nothing to collocate master or rep with.
>> >> The only value here is to show that rep would not be stopped when master
>> >> is.
>> >> (sip)
>> >> [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log
>> >> Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command:
>> >> Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 -
>> >> no waiting
>> >> Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command:
>> >> Initiating action 3: probe_complete probe_complete on rh63-heartbeat2
>> >> (local) - no waiting
>> >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command:
>> >> Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1
>> >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command:
>> >> Initiating action 7: monitor vip-master_monitor_0 on rh63-heartbeat2
>> >> (local)
>> >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command:
>> >> Initiating action 5: monitor vip-rep_monitor_0 on rh63-heartbeat1
>> >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command:
>> >> Initiating action 8: monitor vip-rep_monitor_0 on rh63-heartbeat2 (local)
>> >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command:
>> >> Initiating action 6: probe_complete probe_complete on rh63-heartbeat2
>> >> (local) - no waiting
>> >> Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command:
>> >> Initiating action 3: probe_complete probe_complete on rh63-heartbeat1 -
>> >> no waiting
>> >> Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command:
>> >> Initiating action 5: start vip-master_start_0 on rh63-heartbeat1
>> >> Mar 8 00:20:58 rh63-heartbeat2 crmd:
Re: [Pacemaker] pacemaker node stuck offline
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/21/2013 11:15 AM, Andreas Kurz wrote: > On 2013-03-21 14:31, Patrick Hemmer wrote: >> I've got a 2-node cluster where it seems last night one of the nodes >> went offline, and I can't see any reason why. >> >> Attached are the logs from the 2 nodes (the relevant timeframe seems to >> be 2013-03-21 between 06:05 and 06:10). >> This is on ubuntu 12.04 > > Looks like your non-redundant cluster-communication was interrupted at > around that time for whatever reason and your cluster split-brained. > > Does the drbd-replication use a different network-connection? If yes, > why not using it for a redundant ring setup ... and you should use STONITH. > > I also wonder why you have defined "expected_votes='1'" in your > cluster.conf. > > Regards, > Andreas But shouldn't it have recovered? The node shows as "OFFLINE", even though it's clearly communicating with the rest of the cluster. What is the procedure for getting the node back online. Anything other than bouncing pacemaker? Unfortunately no to the different network connection for drbd. These are 2 EC2 instances, so redundant connections aren't available. Though since it is EC2, I could set up a STONITH to whack the other instance. The only problem here would be a race condition. The EC2 api for shutting down or rebooting an instance isn't instantaneous. Both nodes could end up sending the signal to reboot the other node. As for expected_votes=1, it's because it's a two-node cluster. Though I apparently forgot to set the `two_node` attribute :-( - -Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJRS8RSAAoJED0CF0ckHb4J5/4IAIBTh92ySD9NatBjanOtvwIZ G7ldoPD/o//pOD8A76ZzJnbN+m5PQ1cykpwuC6j+l+fHbkYlDHYEnjbrdRS2dJFY i1PibEIIOjeEAiK9PmCphKQ2qbkrKJXB0QdFD0EZjFFeatNfx/MBHInTBVdFa5MI wZ19qcNELxHZHsrAfgFxYGzKvA1mCVZuRhFXpMoZJ9vo3RUFT1GaLbLA/k8+NHgQ qPbmiYR0RI1cB+HqWl/Hn+PpWnV9zrF/vcZXISHp+cWpZ+IxzmDowR6iIHP+tC7N AslkXAfz4BlH0cuM2kjA9ZdkApzGttH7GkMyOrOQ4Rv8rV4teQjMtPogMcqdFuc= =lYXu -END PGP SIGNATURE- ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] [Question]About "sequential" designation of resource_set.
Hi Andrew, Thank your for comment. > Sorry, I'm not sure I understand the question. Sorry When we use resource_set in substitution for ordered of a thing of group resource, do we use "colocation set"? Or do we use "ordering set "? It does not seem to do work same as "group ordered=fase" if it is right to use "ordering set". Best Regards, Hideo Yamauchi. --- On Fri, 2013/3/22, Andrew Beekhof wrote: > On Fri, Mar 22, 2013 at 12:34 PM, wrote: > > Hi Andrew, > > > > Thank your for comments. > > > >> > > You use the resource sets _instead_ of a group. > >> > > If you want group.ordered=false, then use a colocation set (with > >> > > sequential=true). > >> > >> In "colocation", I used "resource_set". > >> However, a result did not include the change. > >> Will this result be a mistake of my setting? > >> > >> Case 1) sequential=false > >> (snip) > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> What are trying to achieve with this? It doesn't do anything because > >> there is nothing to collocate master or rep with. > >> The only value here is to show that rep would not be stopped when master > >> is. > > > > However, you made next reply. > > I used colocation_set in substitution for ordered=false. > > > >>>You use the resource sets _instead_ of a group. > >>>If you want group.ordered=false, then use a colocation set (with > >>>sequential=true). > >>>If you want group.colocated=false, then use an ordering set (with > >>>sequential=true). > > > > After all is it right that the substitute for ordered=false of group sets > > order_set? > > Sorry, I'm not sure I understand the question. > > > > > Best Regards, > > Hideo Yamauchi. > > > > > > > > --- On Fri, 2013/3/22, Andrew Beekhof wrote: > > > >> > >> > >> On Thursday, March 7, 2013, wrote: > >> Hi Andrew, > >> > >> > > You use the resource sets _instead_ of a group. > >> > > If you want group.ordered=false, then use a colocation set (with > >> > > sequential=true). > >> > >> In "colocation", I used "resource_set". > >> However, a result did not include the change. > >> Will this result be a mistake of my setting? > >> > >> Case 1) sequential=false > >> (snip) > >> > >> > >> > >> > >> > >> > >> > >> > >> > >> What are trying to achieve with this? It doesn't do anything because > >> there is nothing to collocate master or rep with. > >> The only value here is to show that rep would not be stopped when master > >> is. > >> (sip) > >> [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log > >> Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > >> Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 - no > >> waiting > >> Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > >> Initiating action 3: probe_complete probe_complete on rh63-heartbeat2 > >> (local) - no waiting > >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > >> Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1 > >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > >> Initiating action 7: monitor vip-master_monitor_0 on rh63-heartbeat2 > >> (local) > >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > >> Initiating action 5: monitor vip-rep_monitor_0 on rh63-heartbeat1 > >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > >> Initiating action 8: monitor vip-rep_monitor_0 on rh63-heartbeat2 (local) > >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > >> Initiating action 6: probe_complete probe_complete on rh63-heartbeat2 > >> (local) - no waiting > >> Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > >> Initiating action 3: probe_complete probe_complete on rh63-heartbeat1 - no > >> waiting > >> Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > >> Initiating action 5: start vip-master_start_0 on rh63-heartbeat1 > >> Mar 8 00:20:58 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > >> Initiating action 1: stop vip-master_stop_0 on rh63-heartbeat1 > >> > >> > >> Case 2) sequential=true > >> (snip) > >> > >> > >> > >> > >> > >> > >> > >> > >> (snip) > >> [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log > >> Mar 7 23:54:44 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > >> Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 - no > >> waiting > >> Mar 7 23:54:44 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > >> Initiating action 3: probe_complete probe_complete on rh63-heartbeat2 > >> (local) - no waiting > >> Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > >> Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1 > >> Mar 7 23:54:48 rh63-heart
Re: [Pacemaker] [Question]About "sequential" designation of resource_set.
On Fri, Mar 22, 2013 at 12:34 PM, wrote: > Hi Andrew, > > Thank your for comments. > >> > > You use the resource sets _instead_ of a group. >> > > If you want group.ordered=false, then use a colocation set (with >> > > sequential=true). >> >> In "colocation", I used "resource_set". >> However, a result did not include the change. >> Will this result be a mistake of my setting? >> >> Case 1) sequential=false >> (snip) >> >> >> >> >> >> >> >> >> >> What are trying to achieve with this? It doesn't do anything because there >> is nothing to collocate master or rep with. >> The only value here is to show that rep would not be stopped when master is. > > However, you made next reply. > I used colocation_set in substitution for ordered=false. > >>>You use the resource sets _instead_ of a group. >>>If you want group.ordered=false, then use a colocation set (with >>>sequential=true). >>>If you want group.colocated=false, then use an ordering set (with >>>sequential=true). > > After all is it right that the substitute for ordered=false of group sets > order_set? Sorry, I'm not sure I understand the question. > > Best Regards, > Hideo Yamauchi. > > > > --- On Fri, 2013/3/22, Andrew Beekhof wrote: > >> >> >> On Thursday, March 7, 2013, wrote: >> Hi Andrew, >> >> > > You use the resource sets _instead_ of a group. >> > > If you want group.ordered=false, then use a colocation set (with >> > > sequential=true). >> >> In "colocation", I used "resource_set". >> However, a result did not include the change. >> Will this result be a mistake of my setting? >> >> Case 1) sequential=false >> (snip) >> >> >> >> >> >> >> >> >> >> What are trying to achieve with this? It doesn't do anything because there >> is nothing to collocate master or rep with. >> The only value here is to show that rep would not be stopped when master is. >> (sip) >> [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log >> Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: >> Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 - no >> waiting >> Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: >> Initiating action 3: probe_complete probe_complete on rh63-heartbeat2 >> (local) - no waiting >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: >> Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1 >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: >> Initiating action 7: monitor vip-master_monitor_0 on rh63-heartbeat2 (local) >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: >> Initiating action 5: monitor vip-rep_monitor_0 on rh63-heartbeat1 >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: >> Initiating action 8: monitor vip-rep_monitor_0 on rh63-heartbeat2 (local) >> Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: >> Initiating action 6: probe_complete probe_complete on rh63-heartbeat2 >> (local) - no waiting >> Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: >> Initiating action 3: probe_complete probe_complete on rh63-heartbeat1 - no >> waiting >> Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: >> Initiating action 5: start vip-master_start_0 on rh63-heartbeat1 >> Mar 8 00:20:58 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: >> Initiating action 1: stop vip-master_stop_0 on rh63-heartbeat1 >> >> >> Case 2) sequential=true >> (snip) >> >> >> >> >> >> >> >> >> (snip) >> [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log >> Mar 7 23:54:44 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: >> Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 - no >> waiting >> Mar 7 23:54:44 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: >> Initiating action 3: probe_complete probe_complete on rh63-heartbeat2 >> (local) - no waiting >> Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: >> Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1 >> Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: >> Initiating action 7: monitor vip-master_monitor_0 on rh63-heartbeat2 (local) >> Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: >> Initiating action 5: monitor vip-rep_monitor_0 on rh63-heartbeat1 >> Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: >> Initiating action 8: monitor vip-rep_monitor_0 on rh63-heartbeat2 (local) >> Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: >> Initiating action 6: probe_complete probe_complete on rh63-heartbeat2 >> (local) - no waiting >> Mar 7 23:54:49 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: >> Initiating action 3: pr
Re: [Pacemaker] [Question]About "sequential" designation of resource_set.
Hi Andrew, Thank your for comments. > > > You use the resource sets _instead_ of a group. > > > If you want group.ordered=false, then use a colocation set (with > > > sequential=true). > > In "colocation", I used "resource_set". > However, a result did not include the change. > Will this result be a mistake of my setting? > > Case 1) sequential=false > (snip) > > > > > > > > > > What are trying to achieve with this? It doesn't do anything because there > is nothing to collocate master or rep with. > The only value here is to show that rep would not be stopped when master is. However, you made next reply. I used colocation_set in substitution for ordered=false. >>You use the resource sets _instead_ of a group. >>If you want group.ordered=false, then use a colocation set (with >>sequential=true). >>If you want group.colocated=false, then use an ordering set (with >>sequential=true). After all is it right that the substitute for ordered=false of group sets order_set? Best Regards, Hideo Yamauchi. --- On Fri, 2013/3/22, Andrew Beekhof wrote: > > > On Thursday, March 7, 2013, wrote: > Hi Andrew, > > > > You use the resource sets _instead_ of a group. > > > If you want group.ordered=false, then use a colocation set (with > > > sequential=true). > > In "colocation", I used "resource_set". > However, a result did not include the change. > Will this result be a mistake of my setting? > > Case 1) sequential=false > (snip) > > > > > > > > > > What are trying to achieve with this? It doesn't do anything because there > is nothing to collocate master or rep with. > The only value here is to show that rep would not be stopped when master is. > (sip) > [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log > Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 - no > waiting > Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 3: probe_complete probe_complete on rh63-heartbeat2 (local) > - no waiting > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1 > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 7: monitor vip-master_monitor_0 on rh63-heartbeat2 (local) > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 5: monitor vip-rep_monitor_0 on rh63-heartbeat1 > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 8: monitor vip-rep_monitor_0 on rh63-heartbeat2 (local) > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 6: probe_complete probe_complete on rh63-heartbeat2 (local) > - no waiting > Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 3: probe_complete probe_complete on rh63-heartbeat1 - no > waiting > Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 5: start vip-master_start_0 on rh63-heartbeat1 > Mar 8 00:20:58 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 1: stop vip-master_stop_0 on rh63-heartbeat1 > > > Case 2) sequential=true > (snip) > > > > > > > > > (snip) > [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log > Mar 7 23:54:44 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 - no > waiting > Mar 7 23:54:44 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 3: probe_complete probe_complete on rh63-heartbeat2 (local) > - no waiting > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1 > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 7: monitor vip-master_monitor_0 on rh63-heartbeat2 (local) > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 5: monitor vip-rep_monitor_0 on rh63-heartbeat1 > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 8: monitor vip-rep_monitor_0 on rh63-heartbeat2 (local) > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 6: probe_complete probe_complete on rh63-heartbeat2 (local) > - no waiting > Mar 7 23:54:49 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 3: probe_complete probe_complete on rh63-heartbeat1 - no > waiting > Mar 7 23:54:49 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 5: start vip-master_start_0 on rh63-heartbeat1 > Mar 7 23:
Re: [Pacemaker] [Question]About "sequential" designation of resource_set.
On Thursday, March 7, 2013, wrote: > Hi Andrew, > > > > You use the resource sets _instead_ of a group. > > > If you want group.ordered=false, then use a colocation set (with > > > sequential=true). > > In "colocation", I used "resource_set". > However, a result did not include the change. > Will this result be a mistake of my setting? > > Case 1) sequential=false > (snip) > > > > > > > > What are trying to achieve with this? It doesn't do anything because there is nothing to collocate master or rep with. The only value here is to show that rep would not be stopped when master is. > (sip) > [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log > Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 - no > waiting > Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 3: probe_complete probe_complete on rh63-heartbeat2 > (local) - no waiting > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1 > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 7: monitor vip-master_monitor_0 on rh63-heartbeat2 (local) > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 5: monitor vip-rep_monitor_0 on rh63-heartbeat1 > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 8: monitor vip-rep_monitor_0 on rh63-heartbeat2 (local) > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 6: probe_complete probe_complete on rh63-heartbeat2 > (local) - no waiting > Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 3: probe_complete probe_complete on rh63-heartbeat1 - no > waiting > Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 5: start vip-master_start_0 on rh63-heartbeat1 > Mar 8 00:20:58 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > Initiating action 1: stop vip-master_stop_0 on rh63-heartbeat1 > > > Case 2) sequential=true > (snip) > > > > > > > > > (snip) > [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log > Mar 7 23:54:44 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 - no > waiting > Mar 7 23:54:44 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 3: probe_complete probe_complete on rh63-heartbeat2 > (local) - no waiting > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1 > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 7: monitor vip-master_monitor_0 on rh63-heartbeat2 (local) > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 5: monitor vip-rep_monitor_0 on rh63-heartbeat1 > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 8: monitor vip-rep_monitor_0 on rh63-heartbeat2 (local) > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 6: probe_complete probe_complete on rh63-heartbeat2 > (local) - no waiting > Mar 7 23:54:49 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 3: probe_complete probe_complete on rh63-heartbeat1 - no > waiting > Mar 7 23:54:49 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 5: start vip-master_start_0 on rh63-heartbeat1 > Mar 7 23:54:51 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > Initiating action 1: stop vip-master_stop_0 on rh63-heartbeat1 > > You set target-role=stopped for master but rep did not stop? If so that is certainly a bug. > > Best Regards, > Hideo Yamauchi. > > > ___ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] [Question]About "sequential" designation of resource_set.
Hi Andrew, I registered this question with Bugzilla. * http://bugs.clusterlabs.org/show_bug.cgi?id=5147 Best Regards, Hideo Yamauchi. --- On Thu, 2013/3/14, renayama19661...@ybb.ne.jp wrote: > Hi Andrew, > > > In "colocation", I used "resource_set". > > However, a result did not include the change. > > Please, about the result that I tried, give me comment. > > Best Regards, > Hideo Yamauchi. > > --- On Thu, 2013/3/7, renayama19661...@ybb.ne.jp > wrote: > > > Hi Andrew, > > > > > > You use the resource sets _instead_ of a group. > > > > If you want group.ordered=false, then use a colocation set (with > > > > sequential=true). > > > > In "colocation", I used "resource_set". > > However, a result did not include the change. > > > > Will this result be a mistake of my setting? > > > > Case 1) sequential=false > > (snip) > > > > > > > > > > > > > > > > > > (sip) > > [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log > > Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > > Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 - no > > waiting > > Mar 8 00:20:52 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > > Initiating action 3: probe_complete probe_complete on rh63-heartbeat2 > > (local) - no waiting > > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > > Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1 > > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > > Initiating action 7: monitor vip-master_monitor_0 on rh63-heartbeat2 (local) > > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > > Initiating action 5: monitor vip-rep_monitor_0 on rh63-heartbeat1 > > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > > Initiating action 8: monitor vip-rep_monitor_0 on rh63-heartbeat2 (local) > > Mar 8 00:20:55 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > > Initiating action 6: probe_complete probe_complete on rh63-heartbeat2 > > (local) - no waiting > > Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > > Initiating action 3: probe_complete probe_complete on rh63-heartbeat1 - no > > waiting > > Mar 8 00:20:56 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > > Initiating action 5: start vip-master_start_0 on rh63-heartbeat1 > > Mar 8 00:20:58 rh63-heartbeat2 crmd: [22372]: info: te_rsc_command: > > Initiating action 1: stop vip-master_stop_0 on rh63-heartbeat1 > > > > > > Case 2) sequential=true > > (snip) > > > > > > > > > > > > > > > > > > (snip) > > [root@rh63-heartbeat2 ~]# grep "Initiating action" /var/log/ha-log > > Mar 7 23:54:44 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > > Initiating action 2: probe_complete probe_complete on rh63-heartbeat1 - no > > waiting > > Mar 7 23:54:44 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > > Initiating action 3: probe_complete probe_complete on rh63-heartbeat2 > > (local) - no waiting > > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > > Initiating action 4: monitor vip-master_monitor_0 on rh63-heartbeat1 > > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > > Initiating action 7: monitor vip-master_monitor_0 on rh63-heartbeat2 (local) > > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > > Initiating action 5: monitor vip-rep_monitor_0 on rh63-heartbeat1 > > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > > Initiating action 8: monitor vip-rep_monitor_0 on rh63-heartbeat2 (local) > > Mar 7 23:54:48 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > > Initiating action 6: probe_complete probe_complete on rh63-heartbeat2 > > (local) - no waiting > > Mar 7 23:54:49 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > > Initiating action 3: probe_complete probe_complete on rh63-heartbeat1 - no > > waiting > > Mar 7 23:54:49 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > > Initiating action 5: start vip-master_start_0 on rh63-heartbeat1 > > Mar 7 23:54:51 rh63-heartbeat2 crmd: [4]: info: te_rsc_command: > > Initiating action 1: stop vip-master_stop_0 on rh63-heartbeat1 > > > > > > Best Regards, > > Hideo Yamauchi. > > > > > > ___ > > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > > > Project Home: http://www.clusterlabs.org > > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > > Bugs: http://bugs.clusterlabs.org > > > > ___ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting starte
Re: [Pacemaker] CMAN, corosync & pacemaker
On Fri, Mar 22, 2013 at 1:28 AM, Leon Fauster wrote: > Am 21.03.2013 um 13:32 schrieb Ron Kerry : >> I believe I understand how to configure CMAN to work with corosync and >> pacemaker, but I do not really understand what roles these three packages >> all play. Perhaps this information is exposed in the written documentation >> that is available in various places, but I have not been able to discern it. > > It seems you are in the same situation like me (last week) :-) So far i will > provide my big picture. Deeper insights must be provided from the experts > here. > > > >> You can run the corosync/pacemaker (either ver=0 or ver=1) combination and >> get fully functioning HA clusters. What does adding CMAN to the mix add to >> the functionality? Or perhaps a better question, what functions does CMAN >> take over from either corosync or pacemaker and why is this considered a >> better combination? What are the deficiencies in corosync that running CMAN >> on top of it resolves? > > > AFAIK - the architecture should be seen mainly as a stack. Yep. > On top of all is the so called > "cluster resource manager (crm)" like pacemaker or rgmanager. Lets call it > crm-layer and > we use pacemaker for it (check "pacemaker internals" in the documentation). > > Under the crm-layer is the communication layer (corosync) that checks e.g. > cluster membership. > > Membership is the keyword here when we take a look at cman - the > quorum-concept handles > the active cluster/members and this can be also done by pacemaker/corosync. > cman can do > this (quorum handling) very well (mature code) and is doing this in the lower > layers > (extending corosync) - so thats the difference. When the lower level has some > information > (e.g. about the quorum status) then all upper levels have the same > information. If pacemaker > is doing this then they might be situations where different informations > exists in the different > levels/layers. > > >> I believe the preferred pacemaker based HA configuration in RHEL 6.4 uses >> all three packages and the preferred configuration in SLES11 SP2 is just >> corosync/pacemaker (I do not believe CMAN is even available in SLE-HAE). >> Why the different approaches and what is the advantage of each configuration? > > cman is part of the RH cluster suite - the motivations of the different ha > approaches for > both vendors are for sure more based in strategic/marketing needs. Basically convergence takes a long time. In both stacks there is corosync, pacemaker and a plugin that bridges the gap (they both expose an API that provides membership and quorum). On SLES that plugin comes from pacemaker, on RHEL it is CMAN. - resource management (pacemaker) - quorum/membership plugin (cman's or pacemaker's) - cluster messaging (corosync) - The Pacemaker plugin should never have existed, but back then we didn't understand "CMAN" as well as we thought we did. There may have also been some changes to the way it worked since then that allow us to use it more easily today. We all make mistakes, but that was one of my bigger ones. Thankfully it will no longer matter eventually, as corosync 2.x provides the necessary APIs natively so both plugins go away. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] pacemaker node stuck offline
On 2013-03-21 14:31, Patrick Hemmer wrote: > I've got a 2-node cluster where it seems last night one of the nodes > went offline, and I can't see any reason why. > > Attached are the logs from the 2 nodes (the relevant timeframe seems to > be 2013-03-21 between 06:05 and 06:10). > This is on ubuntu 12.04 Looks like your non-redundant cluster-communication was interrupted at around that time for whatever reason and your cluster split-brained. Does the drbd-replication use a different network-connection? If yes, why not using it for a redundant ring setup ... and you should use STONITH. I also wonder why you have defined "expected_votes='1'" in your cluster.conf. Regards, Andreas -- Need help with Pacemaker? http://www.hastexo.com/now > > # crm status > > Last updated: Thu Mar 21 13:17:21 2013 > Last change: Thu Mar 14 14:42:18 2013 via crm_shadow on i-a706d8ff > Stack: cman > Current DC: i-a706d8ff - partition WITHOUT quorum > Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c > 2 Nodes configured, unknown expected votes > 5 Resources configured. > > > Online: [ i-a706d8ff ] > OFFLINE: [ i-3307d96b ] > > dns-postgresql(ocf::cloud:route53):Started i-a706d8ff > Master/Slave Set: ms-drbd-postgresql [drbd-postgresql] > Masters: [ i-a706d8ff ] > Stopped: [ drbd-postgresql:0 ] > fs-drbd-postgresql(ocf::heartbeat:Filesystem):Started i-a706d8ff > postgresql(ocf::heartbeat:pgsql):Started i-a706d8ff > > > # cman_tool nodes > Node Sts Inc Joined Name > 181480898 M 4 2013-03-14 14:25:27 i-3307d96b > 181481642 M 5132 2013-03-21 06:07:40 i-a706d8ff > > > # cman_tool status > Version: 6.2.0 > Config Version: 1 > Cluster Name: cloudapp-servic > Cluster Id: 63629 > Cluster Member: Yes > Cluster Generation: 5132 > Membership state: Cluster-Member > Nodes: 2 > Expected votes: 1 > Total votes: 2 > Node votes: 1 > Quorum: 2 > Active subsystems: 4 > Flags: > Ports Bound: 0 > Node name: i-3307d96b > Node ID: 181480898 > Multicast addresses: 255.255.255.255 > Node addresses: 10.209.45.194 > > > > # cat /etc/cluster/cluster.conf > > > syslog_priority='debug' /> > > > > > > > > > > > > > > > > > > > > > > > > > > > > ___ > Pacemaker mailing list: Pacemaker@oss.clusterlabs.org > http://oss.clusterlabs.org/mailman/listinfo/pacemaker > > Project Home: http://www.clusterlabs.org > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf > Bugs: http://bugs.clusterlabs.org > signature.asc Description: OpenPGP digital signature ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] CMAN, corosync & pacemaker
Am 21.03.2013 um 13:32 schrieb Ron Kerry : > I believe I understand how to configure CMAN to work with corosync and > pacemaker, but I do not really understand what roles these three packages all > play. Perhaps this information is exposed in the written documentation that > is available in various places, but I have not been able to discern it. It seems you are in the same situation like me (last week) :-) So far i will provide my big picture. Deeper insights must be provided from the experts here. > You can run the corosync/pacemaker (either ver=0 or ver=1) combination and > get fully functioning HA clusters. What does adding CMAN to the mix add to > the functionality? Or perhaps a better question, what functions does CMAN > take over from either corosync or pacemaker and why is this considered a > better combination? What are the deficiencies in corosync that running CMAN > on top of it resolves? AFAIK - the architecture should be seen mainly as a stack. On top of all is the so called "cluster resource manager (crm)" like pacemaker or rgmanager. Lets call it crm-layer and we use pacemaker for it (check "pacemaker internals" in the documentation). Under the crm-layer is the communication layer (corosync) that checks e.g. cluster membership. Membership is the keyword here when we take a look at cman - the quorum-concept handles the active cluster/members and this can be also done by pacemaker/corosync. cman can do this (quorum handling) very well (mature code) and is doing this in the lower layers (extending corosync) - so thats the difference. When the lower level has some information (e.g. about the quorum status) then all upper levels have the same information. If pacemaker is doing this then they might be situations where different informations exists in the different levels/layers. > I believe the preferred pacemaker based HA configuration in RHEL 6.4 uses all > three packages and the preferred configuration in SLES11 SP2 is just > corosync/pacemaker (I do not believe CMAN is even available in SLE-HAE). > Why the different approaches and what is the advantage of each configuration? cman is part of the RH cluster suite - the motivations of the different ha approaches for both vendors are for sure more based in strategic/marketing needs. -- LF ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
[Pacemaker] CMAN, corosync & pacemaker
I believe I understand how to configure CMAN to work with corosync and pacemaker, but I do not really understand what roles these three packages all play. Perhaps this information is exposed in the written documentation that is available in various places, but I have not been able to discern it. You can run the corosync/pacemaker (either ver=0 or ver=1) combination and get fully functioning HA clusters. What does adding CMAN to the mix add to the functionality? Or perhaps a better question, what functions does CMAN take over from either corosync or pacemaker and why is this considered a better combination? What are the deficiencies in corosync that running CMAN on top of it resolves? I believe the preferred pacemaker based HA configuration in RHEL 6.4 uses all three packages and the preferred configuration in SLES11 SP2 is just corosync/pacemaker (I do not believe CMAN is even available in SLE-HAE). Why the different approaches and what is the advantage of each configuration? -- Ron Kerry ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
Re: [Pacemaker] Exchanging data between resource agent instances
Sorry for spamming :) Il 19/03/2013 10:43, Lars Ellenberg ha scritto: > > Is that so. What for? > Can you explain in more detail? I'm writing a resource agent for handling SCST in master/slave with ALUA multipath support. On Master node it has to create a SCSI LUN mapped to a real device, and map the path as active. On Slave node (and even on Master when the resource starts) ot has to create a dummy lun (with specific null handler) in the same size of real device, and map path as standby. When switching roles, it simply puts path both in standby, replaces on Master node the lun with null lun, replaces on the slave node the null lun with real device, put in active state the Slave node. ___ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
