PowerFlex 3.5: Disconnessione peer quando si utilizza la replica

Questo problema può verificarsi subito dopo la configurazione della replica PowerFlex, ma può anche essere visualizzato dopo alcune modifiche alla rete o quando l MDM master su entrambi i lati viene modificato in un nodo specifico. 

scli --query_replication_peer_system su un lato (SiteA) restituisce:

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

L'output di "netstat" è simile al seguente:

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.

Si noti che sono presenti quattro connessioni in uscita alla porta 7611 sull MDM peer, ma non sono presenti connessioni in ingresso dal sito B alla porta 7611 sul localhost.

Un altro lato (SiteB) viene visualizzato come Disaccoppiato, NOT_CONN, ad esempio:

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

L'output "netstat" su questo lato potrebbe essere simile a:

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

Sono presenti connessioni provenienti dal sito A (192.168.89.14) e i numeri delle porte di origine corrispondono all'output "netstat" sul sito A, ma le connessioni in uscita sono in SYN_SENT stato, il che significa che non sono in grado di completare l'handshake TCP con il sito A e di fatto non sono in grado di stabilire il peering MDM.

Impatto
Replica non funzionante A seconda della root cause, potrebbe non funzionare affatto o solo quando un nodo specifico diventa Master MDM su uno dei lati.

Questo problema è causato da una configurazione errata dell'indirizzo IP dell MDM o da problemi di rete tra i siti. Ad esempio, se il Sito A è configurato con indirizzi IP corretti, ma il Sito B è stato configurato con IP che non appartengono agli MDM del Sito A, questo problema potrebbe verificarsi.

Se si verificano problemi di connettività di rete (firewall, routing e così via) tra i siti, il cliente può riscontrare un problema simile. Un altro motivo è la presenza di IP duplicati su uno dei lati (ovvero due MDM in esecuzione con lo stesso IP) o di un qualche tipo di dispositivo di rete che intercetta le sessioni TCP in uscita (proxy).

In questo caso particolare, l MDM del sito B ha mantenuto i socket TCP aperti su uno degli MDM sul sito A, ma non è stato connesso a tale MDM, piuttosto la connessione è stata mantenuta attiva artificialmente da uno dei router nel percorso tra i siti:

Ecco come appariva l'output di netstat su entrambi i siti:

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

Si noti che il sito B (192.168.89.14) mostra quattro connessioni STABILITE all'indirizzo IP del sito A (192.168.86.19) sulla porta 7611, ma non viene visualizzato lo stesso nell'output "netstat" sul sito A: un qualche tipo di proxy di rete ha mantenuto attive queste sessioni TCP.

Correggere la configurazione IP dell MDM peer. Testare la connettività tra i siti sulla porta TCP/7611. Trasferire la proprietà di Master MDM su nodi diversi nel cluster e/o riavviare il servizio MDM per chiudere i socket precedenti.

Versioni interessate

PowerFlex 3.5 e versioni successive

Risolto nella versione

N/D - non è un problema di PowerFlex