Hi
Got back to this..
Another quick question, if no true "Master/Slave" service is present, does
crm status list ip failover active and passive nodes as Slaves ?
Sill have the same two issues.. One node does not become "master" and yes I
do know it is active/passive, I citing the "crm status" report.
And if node 2 is on standby, 70% of the ssh requests to not make to ssh (i
think). I do know the packets are reaching the interfaces..
Just as a reminder.. The operation is node-1 is master/active and node-2
is slave/passive. And again just to clarify I do know the difference..
thanks
============
Last updated: Mon Aug 12 14:17:37 2013
Last change: Mon Aug 12 14:17:10 2013 via crm_attribute on u-hb-ha-node-1
Stack: Heartbeat
Current DC: u-hb-ha-node-2 (23855a88-342a-48a8-818b-669f23f6f126) -
partition with quorum
Version: 1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c
2 Nodes configured, unknown expected votes
4 Resources configured.
============
Online: [ u-hb-ha-node-1 u-hb-ha-node-2 ]
Master/Slave Set: ms_IPaddr2_1 [res_IPaddr2_1]
Slaves: [ u-hb-ha-node-1 u-hb-ha-node-2 ]
Master/Slave Set: ms_SendArp_1 [res_SendArp_1]
Slaves: [ u-hb-ha-node-1 u-hb-ha-node-2 ]
And the config
node $id="23855a88-342a-48a8-818b-669f23f6f126" u-hb-ha-node-2 \
attributes standby="off"
node $id="8d0ec7e0-13c6-41b7-aaf6-cd18e326108c" u-hb-ha-node-1 \
attributes standby="off"
primitive res_IPaddr2_1 ocf:heartbeat:IPaddr2 \
params ip="192.168.100.1" nic="eth3" cidr_netmask="24"
flush_routes="true" \
operations $id="res_IPaddr2_1-operations" \
op start interval="0" timeout="20" \
op stop interval="0" timeout="20" \
op monitor interval="10" timeout="20" start-delay="0" \
meta target-role="master"
primitive res_SendArp_1 ocf:heartbeat:SendArp \
params ip="192.168.100.1" nic="eth3" \
operations $id-ref="res_IPaddr2_1-operations" \
meta $id-ref="res_IPaddr2_1-meta_attributes"
ms ms_IPaddr2_1 res_IPaddr2_1 \
meta clone-max="2" notify="true" ordered="true"
target-role="started"
ms ms_SendArp_1 res_SendArp_1 \
meta clone-max="2" notify="true" ordered="true" interleave="true"
target-role="master"
location loc_ms_IPaddr2_1-ping-prefer ms_IPaddr2_1 \
rule $id="loc_ms_IPaddr2_1-ping-prefer-rule" pingd: defined pingd
location loc_ms_IPaddr2_1_U-HB-HA-NODE-1 ms_IPaddr2_1 inf: U-HB-HA-NODE-1
location loc_ms_IPaddr2_1_U-HB-HA-NODE-2 ms_IPaddr2_1 inf: U-HB-HA-NODE-2
property $id="cib-bootstrap-options" \
stonith-enabled="false" \
dc-version="1.1.6-9971ebba4494012a93c03b40a2c58ec0eb60f50c" \
no-quorum-policy="ignore" \
cluster-recheck-interval="15" \
cluster-infrastructure="Heartbeat" \
last-lrm-refresh="1375902370"
On Fri, Aug 9, 2013 at 1:15 PM, Gary Mazzaferro <[email protected]> wrote:
> Hi Marcus,
>
> A quick update.. both nodes are seeing ping requests at the interface as
> suspected using a broadcast mac address.
>
> The proxy as you provided, resolves issue with assigned mac addresses..
>
> There is something going awry . local route tables for the network are
> good, ssh connects 70% of the time. The other 30% no response. to the
> interface.
>
> I'm just posting to improve the documentation of the condition for
> others.. I'll post a full 'solved' when completed.
>
>
>
>
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
