Corosync permite recursos en dos sistemas

Corosync permite recursos en dos sistemas

Estamos utilizando marcapasos/corosync para HA. Esto incluye tanto las IP virtuales como el software. El otro día tuvimos una falla y corosync mostró que la dirección IP se inició en ambos nodos, lo que en mi humilde opinión nunca debería suceder. Cada vez que sacaba un nodo de servicio, primero detenía la IP en el nodoA antes de pasar al nodoB. Mi pregunta es esto un error o una mala configuración? Entiendo que es posible que deseemos que los recursos se ejecuten en más de un servidor (por ejemplo, httpd), pero ¿en qué situación querría que la misma IP se ejecutara en más de una PC en la misma LAN? A continuación se muestra mi configuración de ejecución actual.

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

Respuesta1

Sin STONITH adecuado configurado y habilitado ( stonith-enabled=false), no hay nada que impida que una red dividida entre los nodos provoque que los servicios se inicien en ambos nodos.

Una vez que se resuelva la división de la red, Pacemaker debe comenzar un proceso de recuperación deteniendo el grupo en ambos nodos y luego reiniciándolo en un nodo. Si hay un error de detención de la operación durante ese proceso de recuperación, la recuperación se bloqueará. STONITH también te salvaría aquí.

información relacionada