<div dir="auto">How would I have to adjust my configuration? </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">śr., 20.03.2019, 07:34 użytkownik Jan Friesse <<a href="mailto:jfriesse@redhat.com">jfriesse@redhat.com</a>> napisał:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">> On Tue, 2019-03-19 at 21:49 +0100, Adam Budziński wrote:<br>
>> Not sure I got “or (due to two_node / wait_for_all in corosync.conf)<br>
>> waits until it can see the other node before doing anything” right. I<br>
>> mean according tohttps://<a href="http://access.redhat.com/solutions/1295713 " rel="noreferrer noreferrer" target="_blank">access.redhat.com/solutions/1295713 </a>“Th<br>
>> e 'two_node' parameter sets the quorum to '1' and allows one node to<br>
>> remain quorate and continue cluster operations after the second one<br>
>> is fenced.”<br>
> <br>
> You've got a great setup now. There's nothing wrong with qdevice not<br>
> being enabled, it just means you have to start it manually along with<br>
> corosync and pacemaker.<br>
> <br>
> With qdevice, I'm not sure two_node or wait_for_all is relevant; a<br>
<br>
two_node is nonsense with qdevice. For 2 node clusters it will add <br>
"third" node (so cluster is no longer 2 nodes and simple majority <br>
calculations can be used). And hypothetical 1 node + qdevice doesn't <br>
make any sense, because qdevice is not full node where resources can run.<br>
<br>
wait_for_all may be relevant, but I'm really not aware about any real <br>
use case.<br>
<br>
> corosync dev would have to jump in to say for sure.<br>
> <br>
> At least without qdevice, two_node implies wait_for_all (in addition to<br>
> the quorum effect mentioned by that article). With wait_for_all, the<br>
> cluster can go down from two nodes to one node without a problem -- but<br>
> it can't start with just one node. At start-up, each node will wait<br>
> until it has seen the other before assuming everything is OK.<br>
> <br>
>> <br>
>> Exactly the same parameters are set for my cluster:<br>
>> <br>
>> [root@srv1 ~]# corosync-quorumtool -s<br>
>> Quorum information<br>
>> ------------------<br>
>> Date: Tue Mar 19 16:15:50 2019<br>
>> Quorum provider: corosync_votequorum<br>
>> Nodes: 2<br>
>> Node ID: 1<br>
>> Ring ID: 1/464<br>
>> Quorate: Yes<br>
>> <br>
>> Votequorum information<br>
>> ----------------------<br>
>> Expected votes: 2<br>
>> Highest expected: 2<br>
>> Total votes: 2<br>
>> Quorum: 1<br>
>> Flags: 2Node Quorate WaitForAll<br>
>> <br>
>> Membership information<br>
>> ----------------------<br>
>> Nodeid Votes Name<br>
>> 1 1 srv1cr1 (local)<br>
>> 2 1 srv2cr1<br>
>> <br>
>> I was testing fencing (I’m using fence_vmware_soap) and followed<br>
>> <a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-stonithtest-haarand" rel="noreferrer noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-stonithtest-haarand</a><br>
>> could in each case see that when:<br>
>> <br>
>> a) Fencing the passive node the active remained active *<br>
>> b) Fencing the active node caused the passive node to take over<br>
>> the active role*<br>
>> *in all cases pacemaker and corosync was not configured to start on<br>
>> boot<br>
>> <br>
>> <br>
>> <br>
>> Yes you are absolutely right regarding the fence condition when both<br>
>> shoot at the same time and I even tried option 3 from your list that<br>
>> is corosync qdevice. Here I followed<br>
>> <a href="https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-quorumdev-haar#s2-managequorum-HAAR" rel="noreferrer noreferrer" target="_blank">https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/high_availability_add-on_reference/s1-quorumdev-haar#s2-managequorum-HAAR</a><br>
>> <br>
>> So here’s quorum runtime status before adding the qdevice:<br>
>> <br>
>> [root@srv1 ~]# pcs quorum status<br>
>> Quorum information<br>
>> ------------------<br>
>> Date: Tue Mar 19 16:34:12 2019<br>
>> Quorum provider: corosync_votequorum<br>
>> Nodes: 2<br>
>> Node ID: 1<br>
>> Ring ID: 1/464<br>
>> Quorate: Yes<br>
>> <br>
>> Votequorum information<br>
>> ----------------------<br>
>> Expected votes: 2<br>
>> Highest expected: 2<br>
>> Total votes: 2<br>
>> Quorum: 1<br>
>> Flags: 2Node Quorate WaitForAll<br>
>> <br>
>> Membership information<br>
>> ----------------------<br>
>> Nodeid Votes Qdevice Name<br>
>> 1 1 NR srv1cr1 (local)<br>
>> 2 1 NR srv2cr1<br>
>> <br>
>> <br>
>> And here’s the one after adding it:<br>
>> <br>
>> [root@srv1 ~]# pcs quorum status<br>
>> Quorum information<br>
>> ------------------<br>
>> Date: Tue Mar 19 16:35:06 2019<br>
>> Quorum provider: corosync_votequorum<br>
>> Nodes: 2<br>
>> Node ID: 1<br>
>> Ring ID: 1/464<br>
>> Quorate: Yes<br>
>> <br>
>> Votequorum information<br>
>> ----------------------<br>
>> Expected votes: 3<br>
>> Highest expected: 3<br>
>> Total votes: 3<br>
>> Quorum: 2<br>
>> Flags: Quorate WaitForAll Qdevice<br>
>> <br>
>> Membership information<br>
>> ----------------------<br>
>> Nodeid Votes Qdevice Name<br>
>> 1 1 A,V,NMW srv1cr1 (local)<br>
>> 2 1 A,V,NMW srv2cr1<br>
>> 0 1 Qdevice<br>
>> <br>
>> <br>
>> <br>
>> I got some while adding the quorum device to the cluster because as<br>
>> mentioned I have on both nodes pacemaker and corosync set to not<br>
>> start at boot:<br>
>> <br>
>> [root@srv1 ~]# pcs quorum device add model net host=otrs_db<br>
>> algorithm=ffsplit<br>
>> Setting up qdevice certificates on nodes...<br>
>> srv2cr1: Succeeded<br>
>> srv1cr1: Succeeded<br>
>> Enabling corosync-qdevice...<br>
>> srv2cr1: not enabling corosync-qdevice: corosync is not enabled<br>
>> srv1cr1: not enabling corosync-qdevice: corosync is not enabled<br>
>> Sending updated corosync.conf to nodes...<br>
>> srv2cr1: Succeeded<br>
>> srv1cr1: Succeeded<br>
>> Corosync configuration reloaded<br>
>> Starting corosync-qdevice...<br>
>> srv2cr1: corosync-qdevice started<br>
>> srv1cr1: corosync-qdevice started<br>
>> <br>
>> <br>
>> <br>
>> Is this a problem ? what can I do now, how can I test it ?<br>
>> <br>
>> Thank you !<br>
>><br>
>> wt., 19.03.2019, 19:01 użytkownik Ken Gaillot <<a href="mailto:kgaillot@redhat.com" target="_blank" rel="noreferrer">kgaillot@redhat.com</a>><br>
>> napisał:<br>
>>> On Tue, 2019-03-19 at 15:55 +0100, Adam Budziński wrote:<br>
>>>> Hello Ken,<br>
>>>><br>
>>>> Thank you.<br>
>>>><br>
>>>> But if I have a two node cluster and a working fencing mechanism<br>
>>>> wouldn't it be enough to disable the corosync and pacemaker<br>
>>> service<br>
>>>> on both nodes so when it fence they won't come up?<br>
>>><br>
>>> There's actually no problem when a fenced node comes back. Either<br>
>>> it<br>
>>> joins the remaining cluster normally, or (due to two_node /<br>
>>> wait_for_all in corosync.conf) waits until it can see the other<br>
>>> node<br>
>>> before doing anything.<br>
>>><br>
>>> Disabling or enabling the services is a personal preference based<br>
>>> on<br>
>>> whether you'd rather investigate why a node was shot before letting<br>
>>> it<br>
>>> back in the cluster, or get the cluster back to full strength as<br>
>>> quickly as possible.<br>
>>><br>
>>> The fence delay is for when both nodes are running and<br>
>>> communicating<br>
>>> correctly, then suddenly they lose communication with each other.<br>
>>> From<br>
>>> each node's point of view, the other node is lost. So, each will<br>
>>> attempt to fence the other. A delay on one node in this situation<br>
>>> makes<br>
>>> it less likely that they both pull the trigger at the same time,<br>
>>> ending<br>
>>> up with both nodes dead.<br>
>>><br>
>>>> Thank you<br>
>>>><br>
>>>> pon., 18.03.2019, 16:19 użytkownik Ken Gaillot <<br>
>>> <a href="mailto:kgaillot@redhat.com" target="_blank" rel="noreferrer">kgaillot@redhat.com</a>><br>
>>>> napisał:<br>
>>>>> On Sat, 2019-03-16 at 11:10 +0100, Adam Budziński wrote:<br>
>>>>>> Hello Andrei,<br>
>>>>>><br>
>>>>>> Ok I see your point. So per my understanding if the resource<br>
>>> is<br>
>>>>>> started successfully in that case fence vmware it will be<br>
>>>>> monitored<br>
>>>>>> indefinitely but as you sad it will monitor the current<br>
>>> active<br>
>>>>> node.<br>
>>>>>> So how does the fence agent gets aware of problems with the<br>
>>>>> slave? I<br>
>>>>><br>
>>>>> The fence agent doesn't monitor the active node, or any node --<br>
>>> it<br>
>>>>> monitors the fence device.<br>
>>>>><br>
>>>>> The cluster layer (i.e. corosync) monitors all nodes, and<br>
>>> reports<br>
>>>>> any<br>
>>>>> issues to pacemaker, which will initiate fencing if necessary.<br>
>>>>><br>
>>>>> Pacemaker also monitors each resource and fence device, via any<br>
>>>>> recurring monitors that have been configured.<br>
>>>>><br>
>>>>>> mean if in a two node cluster the cluster splits in to two<br>
>>>>> partitions<br>
>>>>>> each of them will fence the other or does that happen because<br>
>>>>> both<br>
>>>>>> will assume they are the only survivors and thus need to<br>
>>> fence<br>
>>>>> the<br>
>>>>>> other node which is in a unknow state so to say?<br>
>>>>><br>
>>>>> If both nodes are functional but can't see each other, they<br>
>>> will<br>
>>>>> each<br>
>>>>> want to initiate fencing. If one of them is quicker than the<br>
>>> other<br>
>>>>> to<br>
>>>>> determine this, the other one will get shot before it has a<br>
>>> chance<br>
>>>>> to<br>
>>>>> do anything itself.<br>
>>>>><br>
>>>>> However there is the possibility that both nodes will shoot at<br>
>>>>> about<br>
>>>>> the same time, resulting in both nodes getting shot (a "stonith<br>
>>>>> death<br>
>>>>> match"). This is only a problem in 2-node clusters. There are a<br>
>>> few<br>
>>>>> ways around this:<br>
>>>>><br>
>>>>> 1. Configure two separate fence devices, each targeting one of<br>
>>> the<br>
>>>>> nodes, and put a delay on one of them (or a random delay on<br>
>>> both).<br>
>>>>> This<br>
>>>>> makes it highly unlikely that they will shoot at the same time.<br>
>>>>><br>
>>>>> 2. Configure a fencing topology with a fence heuristics device<br>
>>> plus<br>
>>>>> your real device. A fence heuristics device runs some test, and<br>
>>>>> refuses<br>
>>>>> to shoot the other node if the test fails. For example,<br>
>>>>> fence_heuristics_ping tries to ping an IP address you give it;<br>
>>> the<br>
>>>>> idea<br>
>>>>> is that if a node can't ping that IP, you don't want it to<br>
>>> survive.<br>
>>>>> This ensures that only a node that passes the test can shoot<br>
>>> (which<br>
>>>>> means there still might be some cases where the nodes can both<br>
>>>>> shoot<br>
>>>>> each other, and cases where the cluster will freeze because<br>
>>> neither<br>
>>>>> node can see the IP).<br>
>>>>><br>
>>>>> 3. Configure corosync with qdevice to provide true quorum via a<br>
>>>>> third<br>
>>>>> host (which doesn't participate in the cluster otherwise).<br>
>>>>><br>
>>>>> 4. Use sbd with a hardware watchdog and a shared storage device<br>
>>> as<br>
>>>>> the<br>
>>>>> fencing device. This is not a reliable option with VMWare, but<br>
>>> I'm<br>
>>>>> listing it for the general case.<br>
>>>>><br>
>>>>><br>
>>>>>><br>
>>>>>> Thank you and Best Regards,<br>
>>>>>> Adam<br>
>>>>>><br>
>>>>>> sob., 16.03.2019, 07:17 użytkownik Andrei Borzenkov <<br>
>>>>>> <a href="mailto:arvidjaar@gmail.com" target="_blank" rel="noreferrer">arvidjaar@gmail.com</a>> napisał:<br>
>>>>>>> 16.03.2019 9:01, Adam Budziński пишет:<br>
>>>>>>>> Thank you Andrei. The problem is that I can see with 'pcs<br>
>>>>> status'<br>
>>>>>>> that<br>
>>>>>>>> resources are runnin on srv2cr1 but its at the same time<br>
>>> its<br>
>>>>>>> telling that<br>
>>>>>>>> the fence_vmware_soap is running on srv1cr1. That's<br>
>>> somewhat<br>
>>>>>>> confusing.<br>
>>>>>>>> Could you possibly explain this?<br>
>>>>>>>><br>
>>>>>>><br>
>>>>>>> Two points.<br>
>>>>>>><br>
>>>>>>> It is actually logical to have stonith agent running on<br>
>>>>> different<br>
>>>>>>> node<br>
>>>>>>> than node with active resources - because it is the *other*<br>
>>>>> node<br>
>>>>>>> that<br>
>>>>>>> will initiate fencing when node with active resources<br>
>>> fails.<br>
>>>>>>><br>
>>>>>>> But even considering the above, active (running) state of<br>
>>> fence<br>
>>>>> (or<br>
>>>>>>> stonith) agent just determines on which node recurring<br>
>>> monitor<br>
>>>>>>> operation<br>
>>>>>>> will be started. The actual result of this monitor<br>
>>> operation<br>
>>>>> has no<br>
>>>>>>> impact on subsequent stonith attempt and serves just as<br>
>>> warning<br>
>>>>> to<br>
>>>>>>> administrator. When stonith request comes, agent may be<br>
>>> used by<br>
>>>>> any<br>
>>>>>>> node<br>
>>>>>>> where stonith agent is not prohibited to run by (co-<br>
>>> )location<br>
>>>>>>> rules. My<br>
>>>>>>> understanding is that this node is selected by DC in<br>
>>> partition.<br>
>>>>>>><br>
>>>>>>>> Thank you!<br>
>>>>>>>><br>
>>>>>>>> sob., 16.03.2019, 05:37 użytkownik Andrei Borzenkov <<br>
>>>>>>> <a href="mailto:arvidjaar@gmail.com" target="_blank" rel="noreferrer">arvidjaar@gmail.com</a>><br>
>>>>>>>> napisał:<br>
>>>>>>>><br>
>>>>>>>>> 16.03.2019 1:16, Adam Budziński пишет:<br>
>>>>>>>>>> Hi Tomas,<br>
>>>>>>>>>><br>
>>>>>>>>>> Ok but how then pacemaker or the fence agent knows<br>
>>> which<br>
>>>>> route<br>
>>>>>>> to take to<br>
>>>>>>>>>> reach the vCenter?<br>
>>>>>>>>><br>
>>>>>>>>> They do not know or care at all. It is up to your<br>
>>> underlying<br>
>>>>>>> operating<br>
>>>>>>>>> system and its routing tables.<br>
>>>>>>>>><br>
>>>>>>>>>> Btw. Do I have to add the stonith resource on each of<br>
>>> the<br>
>>>>> nodes<br>
>>>>>>> or is it<br>
>>>>>>>>>> just enough to add it on one as for other resources?<br>
>>>>>>>>><br>
>>>>>>>>> If your fencing agent can (should) be able to run on any<br>
>>>>> node,<br>
>>>>>>> it should<br>
>>>>>>>>> be enough to define it just once as long as it can<br>
>>> properly<br>
>>>>>>> determine<br>
>>>>>>>>> "port" to use on fencing "device" for a given node.<br>
>>> There<br>
>>>>> are<br>
>>>>>>> cases when<br>
>>>>>>>>> you may want to restrict fencing agent to only subset on<br>
>>>>> nodes<br>
>>>>>>> or when<br>
>>>>>>>>> you are forced to set unique parameter for each node<br>
>>>>> (consider<br>
>>>>>>> IPMI IP<br>
>>>>>>>>> address), in this case you would need separate instance<br>
>>> of<br>
>>>>> agent<br>
>>>>>>> in each<br>
>>>>>>>>> case.<br>
>>>>>>>>><br>
>>>>>>>>>> Thank you!<br>
>>>>>>>>>><br>
>>>>>>>>>> pt., 15.03.2019, 15:48 użytkownik Tomas Jelinek <<br>
>>>>>>> <a href="mailto:tojeline@redhat.com" target="_blank" rel="noreferrer">tojeline@redhat.com</a>><br>
>>>>>>>>>> napisał:<br>
>>>>>>>>>><br>
>>>>>>>>>>> Dne 15. 03. 19 v 15:09 Adam Budziński napsal(a):<br>
>>>>>>>>>>>> Hello Tomas,<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Thank you! So far I need to say how great this<br>
>>> community<br>
>>>>> is,<br>
>>>>>>> would<br>
>>>>>>>>>>>> never expect so much positive vibes! A big thank you<br>
>>> your<br>
>>>>>>> doing a great<br>
>>>>>>>>>>>> job!<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Now let's talk business :)<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> So if pcsd is using ring0 and it fails will ring1 not<br>
>>> be<br>
>>>>> used<br>
>>>>>>> at all?<br>
>>>>>>>>>>><br>
>>>>>>>>>>> Pcs and pcsd never use ring1, but they are just tools<br>
>>> for<br>
>>>>>>> managing<br>
>>>>>>>>>>> clusters. You can have a perfectly functioning cluster<br>
>>>>> without<br>
>>>>>>> pcs and<br>
>>>>>>>>>>> pcsd running or even installed, it would be just more<br>
>>>>>>> complicated to set<br>
>>>>>>>>>>> it up and manage it.<br>
>>>>>>>>>>><br>
>>>>>>>>>>> Even if ring0 fails, you will be able to use pcs (in<br>
>>>>> somehow<br>
>>>>>>> limited<br>
>>>>>>>>>>> manner) as most of its commands don't go through<br>
>>> network<br>
>>>>>>> anyway.<br>
>>>>>>>>>>><br>
>>>>>>>>>>> Corosync, which is the actual cluster messaging layer,<br>
>>>>> will of<br>
>>>>>>> course<br>
>>>>>>>>>>> use ring1 in case of ring0 failure.<br>
>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> So in regards to VMware that would mean that the<br>
>>>>> interface<br>
>>>>>>> should be<br>
>>>>>>>>>>>> configured with a network that can access the<br>
>>> vCenter to<br>
>>>>>>> fence right?<br>
>>>>>>>>>>>> But wouldn't it then use only ring0 so if that fails<br>
>>> it<br>
>>>>>>> wouldn't switch<br>
>>>>>>>>>>>> to ring1?<br>
>>>>>>>>>>><br>
>>>>>>>>>>> If you are talking about pcmk_host_map, that does not<br>
>>>>> really<br>
>>>>>>> have<br>
>>>>>>>>>>> anything to do with network interfaces of cluster<br>
>>> nodes.<br>
>>>>> It<br>
>>>>>>> maps node<br>
>>>>>>>>>>> names (parts before :) to "ports" of a fence device<br>
>>> (parts<br>
>>>>>>> after :).<br>
>>>>>>>>>>> Pcs-0.9.x does not support defining custom node names,<br>
>>>>>>> therefore node<br>
>>>>>>>>>>> names are the same as ring0 addresses.<br>
>>>>>>>>>>><br>
>>>>>>>>>>> I am not an expert on fence agents / devices, but I'm<br>
>>> sure<br>
>>>>>>> someone else<br>
>>>>>>>>>>> on this list will be able to help you with configuring<br>
>>>>> fencing<br>
>>>>>>> for your<br>
>>>>>>>>>>> cluster.<br>
>>>>>>>>>>><br>
>>>>>>>>>>><br>
>>>>>>>>>>> Tomas<br>
>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Thank you!<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> pt., 15.03.2019, 13:14 użytkownik Tomas Jelinek <<br>
>>>>>>> <a href="mailto:tojeline@redhat.com" target="_blank" rel="noreferrer">tojeline@redhat.com</a><br>
>>>>>>>>>>>> <mailto:<a href="mailto:tojeline@redhat.com" target="_blank" rel="noreferrer">tojeline@redhat.com</a>>> napisał:<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Dne 15. 03. 19 v 12:32 Adam Budziński napsal(a):<br>
>>>>>>>>>>>> > Hello Folks,____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __ __<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > Tow node active/passive VMware VM cluster.____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __ __<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > /etc/hosts____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __ __<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > 10.116.63.83 srv1____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > 10.116.63.84 srv2____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > 172.16.21.12 srv2cr1____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > 172.16.22.12 srv2cr2____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > 172.16.21.11 srv1cr1____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > 172.16.22.11 srv1cr2____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __ __<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __ __<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > I have 3 NIC’s on each VM:____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __ __<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > 10.116.63.83 srv1 and 10.116.63.84 srv2<br>
>>> are<br>
>>>>>>> networks used<br>
>>>>>>>>>>> to<br>
>>>>>>>>>>>> > access the VM’s via SSH or any resource<br>
>>> directly<br>
>>>>> if<br>
>>>>>>> not via a<br>
>>>>>>>>>>>> VIP.____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __ __<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > Everything with cr in its name is used for<br>
>>>>> corosync<br>
>>>>>>>>>>>> communication, so<br>
>>>>>>>>>>>> > basically I have two rings (this are two no<br>
>>>>> routable<br>
>>>>>>> networks<br>
>>>>>>>>>>>> just for<br>
>>>>>>>>>>>> > that).____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __ __<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > My questions are:____<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __ __<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __1.__With ‘pcs cluster auth’ which interface<br>
>>> /<br>
>>>>>>> interfaces<br>
>>>>>>>>> should<br>
>>>>>>>>>>>> I use<br>
>>>>>>>>>>>> > ?____<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Hi Adam,<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> I can see you are using pcs-0.9.x. In that case<br>
>>> you<br>
>>>>>>> should do:<br>
>>>>>>>>>>>> pcs cluster auth srv1cr1 srv2cr1<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> In other words, use the first address of each<br>
>>> node.<br>
>>>>>>>>>>>> Authenticating all the other addresses should not<br>
>>>>> cause<br>
>>>>>>> any issues.<br>
>>>>>>>>>>> It<br>
>>>>>>>>>>>> is pointless, though, as pcs only communicates<br>
>>> via<br>
>>>>> ring0<br>
>>>>>>> addresses.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __2.__With ‘pcs cluster setup –name’ I would<br>
>>> use<br>
>>>>> the<br>
>>>>>>> corosync<br>
>>>>>>>>>>>> interfaces<br>
>>>>>>>>>>>> > e.g. ‘pcs cluster setup –name MyCluster<br>
>>>>>>> srv1cr1,srv1cr2<br>
>>>>>>>>>>>> srv2cr1,srv2cr2’<br>
>>>>>>>>>>>> > right ?____<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Yes, that is correct.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > __3.__With fence_vmware_soap<br>
>>>>>>>>> inpcmk_host_map="X:VM_C;X:VM:OTRS_D"<br>
>>>>>>>>>>>> which<br>
>>>>>>>>>>>> > interface should replace X ?____<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> X should be replaced by node names as seen by<br>
>>>>> pacemaker.<br>
>>>>>>> Once you<br>
>>>>>>>>>>>> set up<br>
>>>>>>>>>>>> and start your cluster, run 'pcs status' to get<br>
>>>>> (amongs<br>
>>>>>>> other info)<br>
>>>>>>>>>>> the<br>
>>>>>>>>>>>> node names. In your configuration, they should be<br>
>>>>> srv1cr1<br>
>>>>>>> and<br>
>>>>>>>>>>> srv2cr1.<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Regards,<br>
>>>>>>>>>>>> Tomas<br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> > __ __<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > Thank you!<br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> ><br>
>>> _______________________________________________<br>
>>>>>>>>>>>> > Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a><br>
>>>>>>>>>>>> <mailto:<a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a>><br>
>>>>>>>>>>>> ><br>
>>>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> > Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>>>>>>>>>>>> > Getting started:<br>
>>>>>>>>>>>> <br>
>>>>> <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
>>>>>>>>>>>> > Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
>>>>>>>>>>>> ><br>
>>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>>> Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a><br>
>>> <mailto:<br>
>>>>>>>>>>> <a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a>><br>
>>>>>>>>>>>> <br>
>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>>>>>>>>>>>> Getting started:<br>
>>>>>>>>>>><br>
>>> <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
>>>>>>>>>>>> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>>> Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a><br>
>>>>>>>>>>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>>>>>>>>><br>
>>>>>>>>>>>> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>>>>>>>>>>>> Getting started:<br>
>>>>>>>>> <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
>>>>>>>>>>>> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
>>>>>>>>>>>><br>
>>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>>> Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a><br>
>>>>>>>>>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>>>>>>>><br>
>>>>>>>>>>> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>>>>>>>>>>> Getting started:<br>
>>>>>>>>> <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
>>>>>>>>>>> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
>>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>><br>
>>>>>>>>>> _______________________________________________<br>
>>>>>>>>>> Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a><br>
>>>>>>>>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>>>>>>><br>
>>>>>>>>>> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>>>>>>>>>> Getting started:<br>
>>>>>>> <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
>>>>>>>>>> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
>>>>>>>>>><br>
>>>>>>>>><br>
>>>>>>>>> _______________________________________________<br>
>>>>>>>>> Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a><br>
>>>>>>>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>>>>>><br>
>>>>>>>>> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>>>>>>>>> Getting started:<br>
>>>>>>> <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
>>>>>>>>> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
>>>>>>>>><br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> _______________________________________________<br>
>>>>>>>> Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a><br>
>>>>>>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>>>>><br>
>>>>>>>> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>>>>>>>> Getting started:<br>
>>>>>>> <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
>>>>>>>> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
>>>>>>>><br>
>>>>>>><br>
>>>>>>> _______________________________________________<br>
>>>>>>> Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a><br>
>>>>>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>>>><br>
>>>>>>> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>>>>>>> Getting started:<br>
>>>>>>> <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
>>>>>>> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
>>>>>><br>
>>>>>> _______________________________________________<br>
>>>>>> Users mailing list: <a href="mailto:Users@clusterlabs.org" target="_blank" rel="noreferrer">Users@clusterlabs.org</a><br>
>>>>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>>><br>
>>>>>> Project Home: <a href="http://www.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org</a><br>
>>>>>> Getting started:<br>
>>>>>> <a href="http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf" rel="noreferrer noreferrer" target="_blank">http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf</a><br>
>>>>>> Bugs: <a href="http://bugs.clusterlabs.org" rel="noreferrer noreferrer" target="_blank">http://bugs.clusterlabs.org</a><br>
>>>>> _______________________________________________<br>
>>>>> Manage your subscription:<br>
>>>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>>>><br>
>>>>> ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
>>> _______________________________________________<br>
>>> Manage your subscription:<br>
>>> <a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
>>><br>
>>> ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer noreferrer" target="_blank">https://www.clusterlabs.org/</a></blockquote></div>