PowerFlex 3.5: Peer-Verbindungstrennung bei Verwendung der Replikation

Dieses Problem kann sofort nach der Konfiguration der PowerFlex-Replikation auftreten, kann aber auch nach einigen Netzwerkänderungen auftreten oder wenn der Master-MDM auf einer Seite auf einen bestimmten Node geändert wird. 

scli --query_replication_peer_system auf der einen Seite (SiteA) gibt Folgendes zurück:

query-all-Replication Peer System returned 1 Replication Peer System nodes.
Replication Peer System ID: 045a1aa61167b20f Replication Peer System internal ID: eef8648500000000 Name: SiteB State: Decoupled, REMOTE_PEER_MDM_DENIED_MESSAGE_AS_NO_WORKING_CLIENT_CONNECTION_TO_THIS_PEER IP: 192.168.89.14,192.168.89.13,192.168.89.18 Port: 7611 Version: N/A
SDR-SDR connectivity status: All connected

Die Ausgabe von "netstat" sieht in etwa so aus:

tcp        0      0 192.168.86.19:50470     192.168.89.14:7611      ESTABLISHED 36766/mdm-3.5.1100.
tcp        0      0 192.168.86.19:50464     192.168.89.14:7611      ESTABLISHED 36766/mdm-3.5.1100.
tcp        0      0 192.168.86.19:50216     192.168.89.14:7611      ESTABLISHED 36766/mdm-3.5.1100.
tcp        0      0 192.168.86.19:50458     192.168.89.14:7611      ESTABLISHED 36766/mdm-3.5.1100.

Beachten Sie, dass es vier ausgehende Verbindungen zu Port 7611 auf dem Peer-MDM gibt, aber es gibt keine eingehenden Verbindungen von SiteB zu Port 7611 auf dem localhost.

Eine andere Seite (Standort B) wird als entkoppelt angezeigt, NOT_CONN Beispiel:

Query-all-Replication Peer System returned 1 Replication Peer System nodes.
Replication Peer System ID: 0966250f2fae770f Replication Peer System internal ID: c0f3862b00000000 Name: SiteA State: Decoupled, NOT_CONN IP: 192.168.86.20,192.168.86.13,192.168.86.19 Port: 7611 Version: 3.5.1100
SDR-SDR connectivity status: All connected

Die Ausgabe "netstat" auf dieser Seite könnte ähnlich aussehen wie:

B -> A
 
tcp       0    157 192.168.89.14:7611      192.168.86.19:50470     ESTABLISHED 446371/mdm-3.5.1100
tcp       0      0 192.168.89.14:7611      192.168.86.19:50216     ESTABLISHED 446371/mdm-3.5.1100
tcp       0      0 192.168.89.14:7611      192.168.86.19:50464     ESTABLISHED 446371/mdm-3.5.1100
tcp       0      0 192.168.89.14:7611      192.168.86.19:50458     ESTABLISHED 446371/mdm-3.5.1100
 
tcp        0      0 192.168.89.14:54460     192.168.86.19:7611      SYN_SENT 446371/mdm-3.5.1100
tcp        0      0 192.168.89.14:54456     192.168.86.19:7611      SYN_SENT 446371/mdm-3.5.1100
tcp        0      0 192.168.89.14:54458     192.168.86.19:7611      SYN_SENT 446371/mdm-3.5.1100
tcp        0      0 192.168.89.14:54454     192.168.86.19:7611      SYN_SENT 446371/mdm-3.5.1100

Es gibt Verbindungen von Standort A (192.168.89.14) und die Quellportnummern stimmen mit der "netstat"-Ausgabe an Standort A überein, aber ausgehende Verbindungen befinden sich im Status SYN_SENT, was bedeutet, dass sie den TCP-Handshake mit Standort A nicht abschließen können und somit das MDM-Peering nicht einrichten können.

Aufprall
Replikation funktioniert nicht Je nach Ursache funktioniert sie möglicherweise gar nicht oder nur, wenn ein bestimmter Node auf einer der Seiten Master-MDM wird.

Dieses Problem wird entweder durch eine Fehlkonfiguration der MDM-IP-Adresse oder Netzwerkprobleme zwischen Standorten verursacht. Beispiel: Wenn Standort A mit korrekten IP-Adressen konfiguriert ist, Standort B jedoch mit IPs konfiguriert wurde, die nicht zu Standort A MDMs gehören, kann dieses Problem auftreten.

Wenn es ein Problem mit der Netzwerkverbindung (Firewall, Routing usw.) zwischen den Standorten gibt, kann beim Kunden ein ähnliches Problem auftreten. Ein weiterer Grund sind doppelte IPs auf einer der Seiten (d. h. es werden zwei MDMs mit derselben IP ausgeführt) oder eine Art von Netzwerkgerät, das ausgehende TCP-Sitzungen abfängt (Proxy).

In diesem speziellen Fall hielt Standort B MDM TCP-Sockets für einen der MDMs an Standort A offen, war aber nicht mit diesem MDM verbunden, sondern die Verbindung wurde künstlich von einem der Router auf dem Pfad zwischen Standorten am Leben erhalten:

So sah die netstat-Ausgabe auf beiden Seiten aus:

A -> B
tcp        0      0 192.168.86.19:50470     192.168.89.14:7611      ESTABLISHED 36766/mdm-3.5.1100.
tcp        0      0 192.168.86.19:50464     192.168.89.14:7611      ESTABLISHED 36766/mdm-3.5.1100.
tcp        0      0 192.168.86.19:50216     192.168.89.14:7611      ESTABLISHED 36766/mdm-3.5.1100.
tcp        0      0 192.168.86.19:50458     192.168.89.14:7611      ESTABLISHED 36766/mdm-3.5.1100.
 
B -> A
 
tcp        0      0 192.168.89.14:54460     192.168.86.19:7611      ESTABLISHED 446371/mdm-3.5.1100
tcp        0      0 192.168.89.14:54456     192.168.86.19:7611      ESTABLISHED 446371/mdm-3.5.1100
tcp        0      0 192.168.89.14:54458     192.168.86.19:7611      ESTABLISHED 446371/mdm-3.5.1100
tcp        0      0 192.168.89.14:54454     192.168.86.19:7611      ESTABLISHED 446371/mdm-3.5.1100
tcp6       0    157 192.168.89.14:7611      192.168.86.19:50470     ESTABLISHED 446371/mdm-3.5.1100
tcp6       0      0 192.168.89.14:7611      192.168.86.19:50216     ESTABLISHED 446371/mdm-3.5.1100
tcp6       0      0 192.168.89.14:7611      192.168.86.19:50464     ESTABLISHED 446371/mdm-3.5.1100
tcp6       0      0 192.168.89.14:7611      192.168.86.19:50458     ESTABLISHED 446371/mdm-3.5.1100

Beachten Sie, dass SiteB (192.168.89.14) vier ESTABLISHED Verbindungen zur IP-Adresse von SiteA (192.168.86.19) auf Port 7611 anzeigt, aber wir sehen nicht dasselbe in der "netstat"-Ausgabe auf SiteA - eine Art Netzwerkproxy hat diese TCP-Sitzungen am Leben gehalten.

Korrigieren Sie die Peer-MDM-IP-Konfiguration. Testen Sie die Konnektivität zwischen Standorten auf Port TCP/7611. Wechseln Sie die Master-MDM-Eigentumsrechte auf andere Nodes im Cluster und/oder starten Sie den MDM-Service neu, um alte Sockets zu schließen.

Betroffene Versionen

PowerFlex 3.5 und höher

Behoben in Version

Nicht zutreffend – kein PowerFlex-Problem