PowerFlex 3.5: Verbinding met collega's verbroken bij gebruik van replicatie

Dit probleem kan zich meteen voordoen na het configureren van PowerFlex-replicatie, maar kan zich ook voordoen na enkele netwerkwijzigingen of wanneer de Master MDM aan beide zijden wordt gewijzigd in een specifiek knooppunt. 

scli --query_replication_peer_system aan de ene kant (SiteA) retourneert:

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

De uitvoer van "netstat" ziet er ongeveer zo uit:

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.

Merk op dat er vier uitgaande verbindingen zijn naar poort 7611 op de peer MDM, maar er zijn geen inkomende verbindingen van SiteB naar poort 7611 op de localhost.

Een andere kant (SiteB) wordt weergegeven als Ontkoppeld, NOT_CONN, bijvoorbeeld:

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

"netstat"-uitvoer aan deze kant kan er ongeveer zo uitzien als:

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

Er zijn verbindingen afkomstig van SiteA (192.168.89.14) en de nummers van de bronpoort komen overeen met de "netstat"-uitvoer op SiteA, maar uitgaande verbindingen zijn in SYN_SENT staat, wat betekent dat ze de TCP-handshake met SiteA niet kunnen voltooien en in feite niet in staat zijn om de MDM-peering tot stand te brengen.

Impact
Replicatie werkt niet Afhankelijk van de hoofdoorzaak werkt het mogelijk helemaal niet of alleen wanneer een specifiek knooppunt aan een van de zijden Master MDM wordt.

Dit probleem wordt veroorzaakt door een verkeerde configuratie van het MDM IP-adres of netwerkproblemen tussen sites. Als SiteA bijvoorbeeld is geconfigureerd met de juiste IP-adressen, maar SiteB is geconfigureerd met IP's die niet tot de MDM's van SiteA behoren, kan dit probleem optreden.

Als er een probleem is met de netwerkconnectiviteit (firewall, routering enz.) tussen de sites, kan de klant ook een soortgelijk probleem ondervinden. Een andere reden zijn dubbele IP's aan een van de zijden (dat wil zeggen dat er twee MDM's met hetzelfde IP-adres worden uitgevoerd) of een soort netwerkapparaat dat uitgaande TCP-sessies onderschept (proxy).

In dit specifieke geval hield SiteB MDM TCP-sockets open tegen een van de MDM's op SiteA, maar was niet verbonden met die MDM, maar de verbinding werd kunstmatig in stand gehouden door een van de routers op het pad tussen sites:

Dit is hoe de output van netstat er op beide sites uitzag:

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

Merk op dat SiteB (192.168.89.14) vier GEVESTIGDE verbindingen toont met het IP-adres van SiteA (192.168.86.19) op poort 7611, maar we zien niet hetzelfde in de "netstat"-uitvoer op SiteA - een soort netwerkproxy hield deze TCP-sessies in leven.

Corrigeer de MDM IP-configuratie van de peer. Test de connectiviteit tussen locaties op poort TCP/7611. Schakel het Master MDM-eigendom over naar verschillende knooppunten in het cluster en/of start de MDM-service opnieuw om oude sockets te sluiten.

Versies waarop dit van toepassing is

PowerFlex 3.5 en hoger

Opgelost in versie

N.v.t. - geen PowerFlex-probleem