Corosync permitindo recursos em dois sistemas

Corosync permitindo recursos em dois sistemas

Estamos usando marca-passo/corosync para HA. Isso inclui IPs virtuais e software. Outro dia tivemos uma falha e o corosync mostrou que o endereço IP foi iniciado em ambos os nós, o que IMHO nunca deveria acontecer. Cada vez que tirei um nó de serviço, ele primeiro interrompeu o IP no nóA antes de passar para o nóB. Minha pergunta é um bug ou configuração incorreta? Entendo que podemos querer que recursos sejam executados em mais de um servidor (por exemplo, httpd), mas em que situação você desejaria que o mesmo IP fosse executado em mais de um PC na mesma LAN? Abaixo está minha configuração atual em execução.

node 1: s1.site.example.org \
        attributes standby=off
node 2: s2.site.example.org
primitive vendor_blfd systemd:vendor_blfd \
        op monitor interval=10s \
        meta target-role=Started
primitive vendor_sipd systemd:vendor_sipd \
        op monitor interval=10s \
        meta target-role=Started
primitive opensips systemd:opensips \
        op monitor interval=10s \
        meta target-role=Started
primitive public_222 IPaddr2 \
        params ip=XX.XX.XX.222 cidr_netmask=27 \
        op monitor interval=30s
primitive public_NYC_10 IPaddr2 \
        params ip=XX.XX.XX.10 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_19 IPaddr2 \
        params ip=XX.XX.XX.19 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_23 IPaddr2 \
        params ip=XX.XX.XX.23 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_40 IPaddr2 \
        params ip=XX.XX.XX.40 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_41 IPaddr2 \
        params ip=XX.XX.XX.41 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_42 IPaddr2 \
        params ip=XX.XX.XX.42 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_43 IPaddr2 \
        params ip=XX.XX.XX.43 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_44 IPaddr2 \
        params ip=XX.XX.XX.44 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_45 IPaddr2 \
        params ip=XX.XX.XX.45 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_46 IPaddr2 \
        params ip=XX.XX.XX.46 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_47 IPaddr2 \
        params ip=XX.XX.XX.47 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_48 IPaddr2 \
        params ip=XX.XX.XX.48 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_49 IPaddr2 \
        params ip=XX.XX.XX.49 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_50 IPaddr2 \
        params ip=XX.XX.XX.50 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_51 IPaddr2 \
        params ip=XX.XX.XX.51 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_52 IPaddr2 \
        params ip=XX.XX.XX.52 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_53 IPaddr2 \
        params ip=XX.XX.XX.53 cidr_netmask=25 \
        op monitor interval=10s
primitive public_NYC_54 IPaddr2 \
        params ip=XX.XX.XX.54 cidr_netmask=25 \
        op monitor interval=10s \
        meta target-role=Started
primitive public_NYC_55 IPaddr2 \
        params ip=XX.XX.XX.55 cidr_netmask=25 \
        op monitor interval=10s
group vendor public_NYC_10 public_NYC_19 public_NYC_23 public_NYC_40 public_NYC_41 public_NYC_42 public_NYC_43 public_NYC_44 public_NYC_45 public_NYC_46 public_NYC_47 public_NYC_48 public_NYC_49 public_NYC_50 public_NYC_51 public_NYC_52 public_NYC_53 public_NYC_54 public_NYC_55 public_222 opensips vendor_sipd vendor_blfd \
        meta target-role=Started
property cib-bootstrap-options: \
        have-watchdog=false \
        dc-version=1.1.23-1.el7_9.1-9acf116022 \
        cluster-infrastructure=corosync \
        cluster-name=vendor \
        stonith-enabled=false \
        no-quorum-policy=ignore \
        last-lrm-refresh=1650666825

Responder1

Sem o STONITH adequado configurado e habilitado ( stonith-enabled=false), nada impede que uma divisão de rede entre os nós faça com que os serviços sejam iniciados em ambos os nós.

Assim que a divisão da rede for resolvida, o Pacemaker deverá iniciar um processo de recuperação parando o grupo em ambos os nós e, em seguida, iniciando-o novamente em um nó. Se houver uma falha na operação de parada durante o processo de recuperação, a recuperação será interrompida. STONITH salvaria você aqui também.

informação relacionada