У меня есть кластерная установка с 3 узлами [с узлами A, B (VIP), C ] с помощью кардиостимулятора и corosync. Когда я намеренно тяну сетевой кабель за один из узлов B
(в качестве теста аварийного восстановления), узел A
или C
принимает VIP, но когда я вставляю кабель обратно B включается через некоторое время, затем VIP переключается на B
, чего не должно быть.
Я ожидаю, что A
или C
сохранят VIP, ниже мой Конфигурация pacemaker
configure
primitive baseos-ping-check ocf:pacemaker:ping params host_list="1.2.3.4" multiplier="1000" dampen="0" attempts="2" \
op start interval="0s" timeout="60s" \
op monitor interval="2s" timeout="60s" \
op stop interval="0s" timeout="60s" on-fail="ignore"
primitive baseos-vip-master ocf:heartbeat:IPaddr2 \
params ip="192.67.23.145" iflabel="MR" cidr_netmask="255.255.255.0" \
op start interval="0s" \
op monitor interval="10s" \
op stop interval="0s"
clone cl_baseos-ping-check baseos-ping-check meta interleave="true"
location loc-vip-master vip-master \
rule $id="loc-vip-master-rule" $role="master" 100: #uname eq ECS01 \
rule $id="loc--vip-master-rule-0" $role="master" -inf: not_defined pingd or pingd lte 0
property expected-quorum-votes="1"
property stonith-enabled="false"
property maintenance-mode="false"
property cluster-recheck-interval="5min"
property default-action-timeout="60s"
property pe-error-series-max="500"
property pe-input-series-max="500"
property pe-warn-series-max="500"
property no-quorum-policy="ignore"
property dc-version="1.1.16-94ff4df"
property cluster-infrastructure="corosync"
rsc_defaults resource-stickiness="150"
rsc_defaults migration-threshold="3"
commit
quit
Моя конфигурация corosync выглядит так:
quorum {
provider: corosync_votequorum
expected_votes : 3
}
totem {
version: 2
# How long before declaring a token lost (ms)
token: 3000
# How many token retransmits before forming a new configuration
token_retransmits_before_loss_const: 10
# How long to wait for join messages in the membership protocol (ms)
join: 60
# How long to wait for consensus to be achieved before starting a new round of membership configuration (ms)
consensus: 3600
# Turn off the virtual synchrony filter
vsftype: none
# Number of messages that may be sent by one processor on receipt of the token
max_messages: 20
# Limit generated nodeids to 31-bits (positive signed integers)
clear_node_high_bit: yes
# Disable encryption
secauth: on
# How many threads to use for encryption/decryption
threads: 0
# Optionally assign a fixed node id (integer)
# nodeid: 1234
# This specifies the mode of redundant ring, which may be none, active, or passive.
rrp_mode: none
interface {
# The following values need to be set based on your environment
ringnumber: 0
bindnetaddr: 10.98.4.0
#mcastaddr: 0.0.0.0
mcastport: 5876
member {
memberaddr: 10.98.4.103
}
member {
memberaddr: 10.98.4.173
}
}
transport: udpu
}
amf {
mode: disabled
}
service {
# Load the Pacemaker Cluster Resource Manager
ver: 0
name: pacemaker
}
aisexec {
user: root
group: root
}
logging {
fileline: off
to_stderr: yes
to_logfile: no
to_syslog: yes
syslog_facility: daemon
debug: off
timestamp: on
logger_subsys {
subsys: AMF
debug: off
tags: enter|leave|trace1|trace2|trace3|trace4|trace6
}
}
Мой cib.xml выглядит следующим образом:
<cib crm_feature_set="3.0.11" validate-with="pacemaker-2.6" epoch="4" num_updates="0" admin_epoch="0" cib-last-written="Wed Sep 11 14:33:08 2019" update-origin="testje" update-client="cibadmin" update-user="root" have-quorum="1" dc-uuid="183387233">
<configuration>
<crm_config>
<cluster_property_set id="cib-bootstrap-options">
<nvpair id="cib-bootstrap-options-have-watchdog" name="have-watchdog" value="false"/>
<nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="1.1.16-94ff4df"/>
<nvpair id="cib-bootstrap-options-cluster-infrastructure" name="cluster-infrastructure" value="corosync"/>
<nvpair name="expected-quorum-votes" value="1" id="cib-bootstrap-options-expected-quorum-votes"/>
<nvpair name="stonith-enabled" value="false" id="cib-bootstrap-options-stonith-enabled"/>
<nvpair name="maintenance-mode" value="false" id="cib-bootstrap-options-maintenance-mode"/>
<nvpair name="cluster-recheck-interval" value="5min" id="cib-bootstrap-options-cluster-recheck-interval"/>
<nvpair name="default-action-timeout" value="60s" id="cib-bootstrap-options-default-action-timeout"/>
<nvpair name="pe-error-series-max" value="500" id="cib-bootstrap-options-pe-error-series-max"/>
<nvpair name="pe-input-series-max" value="500" id="cib-bootstrap-options-pe-input-series-max"/>
<nvpair name="pe-warn-series-max" value="500" id="cib-bootstrap-options-pe-warn-series-max"/>
<nvpair name="no-quorum-policy" value="ignore" id="cib-bootstrap-options-no-quorum-policy"/>
</cluster_property_set>
</crm_config>
<nodes>
<node id="183387233" uname="testje"/>
<node id="183387244" uname="0060E057BC25"/>
<node id="183387230" uname="d66c4b1997a0"/>
</nodes>
<resources>
<primitive id="baseos-vip-master" class="ocf" provider="heartbeat" type="IPaddr2">
<instance_attributes id="baseos-vip-master-instance_attributes">
<nvpair name="ip" value="10.238.68.134" id="baseos-vip-master-instance_attributes-ip"/>
<nvpair name="iflabel" value="MR" id="baseos-vip-master-instance_attributes-iflabel"/>
<nvpair name="cidr_netmask" value="24" id="baseos-vip-master-instance_attributes-cidr_netmask"/>
</instance_attributes>
<operations>
<op name="start" interval="0s" id="baseos-vip-master-start-0s"/>
<op name="monitor" interval="10s" id="baseos-vip-master-monitor-10s"/>
<op name="stop" interval="0s" id="baseos-vip-master-stop-0s"/>
</operations>
</primitive>
<clone id="cl_baseos-ping-check">
<meta_attributes id="cl_baseos-ping-check-meta_attributes">
<nvpair name="interleave" value="true" id="cl_baseos-ping-check-meta_attributes-interleave"/>
</meta_attributes>
<primitive id="baseos-ping-check" class="ocf" provider="pacemaker" type="ping">
<instance_attributes id="baseos-ping-check-instance_attributes">
<nvpair name="host_list" value="10.238.68.1" id="baseos-ping-check-instance_attributes-host_list"/>
<nvpair name="multiplier" value="1000" id="baseos-ping-check-instance_attributes-multiplier"/>
<nvpair name="dampen" value="0" id="baseos-ping-check-instance_attributes-dampen"/>
<nvpair name="attempts" value="2" id="baseos-ping-check-instance_attributes-attempts"/>
</instance_attributes>
<operations>
<op name="start" interval="0s" timeout="60s" id="baseos-ping-check-start-0s"/>
<op name="monitor" interval="2s" timeout="60s" id="baseos-ping-check-monitor-2s"/>
<op name="stop" interval="0s" timeout="60s" on-fail="ignore" id="baseos-ping-check-stop-0s"/>
</operations>
</primitive>
</clone>
</resources>
<constraints>
<rsc_location id="loc-baseos-vip-master" rsc="baseos-vip-master">
<rule id="loc-baseos-vip-master-rule" role="master" score="100">
<expression attribute="#uname" operation="eq" value="testje" id="loc-baseos-vip-master-rule-expression"/>
</rule>
<rule id="loc-baseos-vip-master-rule-0" role="master" score="-INFINITY" boolean-op="or">
<expression attribute="pingd" operation="not_defined" id="loc-baseos-vip-master-rule-0-expression"/>
<expression attribute="pingd" operation="lte" value="0" id="loc-baseos-vip-master-rule-0-expression-0"/>
</rule>
</rsc_location>
</constraints>
<rsc_defaults>
<meta_attributes id="rsc-options">
<nvpair name="resource-stickiness" value="150" id="rsc-options-resource-stickiness"/>
<nvpair name="migration-threshold" value="3" id="rsc-options-migration-threshold"/>
</meta_attributes>
</rsc_defaults>
</configuration>
</cib>
Сценарий, который я описал выше, происходит только тогда, когда я тяну сетевой кабель узла, чтобы отключить его, однако, если я перезагружаюсь узел (то есть B), то VIP привязан к текущему узлу, то есть либо A
, либо C
.
Одна вещь, которую я заметил, когда я вставлял сетевой кабель узла B
, то ресурс IPaddr2 вызывает findif
, что дает сбой, поскольку я не использую параметр имени nic
, но я предоставляю cidr_netmask
, поэтому в идеале [1 177694] findif должен разрешить IP-адрес узла B
.
Есть ли способ избежать сбоя findif
?
Как мы выяснили в комментариях к вашему вопросу: когда узел снова подключается к сети, он снова присоединяется к кластеру, обнаруживается, что VIP работает более чем на одном узле, поэтому кластер должен восстановить службу (остановите виртуальный IP-адрес везде, а затем снова запустите его) и он выбирает узел B.
В производственном кластере вы должны использовать Fencing / STONITH и не игнорировать кворум. Когда вы отключаете узел B от сети в этой конфигурации, внешний агент STONITH принудительно отключит узел B, что заставит узел B повторно присоединиться к кластеру в «новом состоянии» без запущенных служб, и VIP не будет переключаться на узел. B.