Corosync ermöglicht Ressourcen auf zwei Systemen

Corosync ermöglicht Ressourcen auf zwei Systemen

Wir verwenden Pacemaker/Corosync für HA. Dies umfasst sowohl virtuelle IPs als auch Software. Neulich hatten wir einen Fehler und Corosync zeigte an, dass die IP-Adresse auf beiden Knoten gestartet war, was meiner Meinung nach nie passieren sollte. Jedes Mal, wenn ich einen Knoten außer Betrieb nahm, wurde zuerst die IP auf Knoten A gestoppt, bevor sie zu Knoten B überging. Meine Frage ist, ob dies ein Fehler oder eine schlechte Konfiguration ist? Ich verstehe, dass wir möglicherweise Ressourcen auf mehr als einem Server ausführen möchten (z. B. httpd), aber in welcher Situation möchten Sie, dass dieselbe IP auf mehr als einem PC im selben LAN ausgeführt wird? Unten ist meine aktuelle Konfiguration.

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

Antwort1

Ohne die ordnungsgemäße Konfiguration und Aktivierung von STONITH ( stonith-enabled=false) gibt es keine Möglichkeit, eine Netzwerkaufteilung zwischen den Knoten daran zu hindern, dass Dienste auf beiden Knoten gestartet werden.

Sobald die Netzwerkaufteilung behoben ist, sollte Pacemaker einen Wiederherstellungsprozess starten, indem die Gruppe auf beiden Knoten gestoppt und dann auf einem Knoten erneut gestartet wird. Wenn während dieses Wiederherstellungsprozesses ein Stoppvorgang fehlschlägt, bleibt die Wiederherstellung hängen. STONITH würde Sie auch hier retten.

verwandte Informationen