PowerFlex 3.5: Desconexão de par ao usar a replicação

Esse problema pode ocorrer imediatamente após a configuração da replicação do PowerFlex, mas também pode ser visto após algumas alterações de rede ou quando o MDM principal em ambos os lados é alterado para um nó específico. 

scli --query_replication_peer_system de um lado (SiteA) retorna:

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

A saída "netstat" é semelhante a:

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.

Observe que há quatro conexões de saída para a porta 7611 no par do MDM, mas não há conexões de entrada do Local B para a porta 7611 no host local.

Outro lado (SiteB) aparece como Decoupled, NOT_CONN, por exemplo:

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

A saída "netstat" nesse lado pode ser semelhante 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

Há conexões provenientes do SiteA (192.168.89.14) e os números da porta de origem correspondem à saída "netstat" no SiteA, mas as conexões de saída estão em SYN_SENT estado, o que significa que não conseguem concluir o handshake TCP com o SiteA e, na verdade, não conseguem estabelecer o emparelhamento do MDM.

Impacto
A replicação não funciona Dependendo da causa raiz, ela pode não funcionar ou somente quando um nó específico se torna MDM mestre em um dos lados.

Esse problema é causado pela configuração incorreta do endereço IP do MDM ou por problemas de rede entre locais. Por exemplo, se o SiteA estiver configurado com endereços IP corretos, mas o SiteB tiver sido configurado com IPs que não pertencem aos MDMs do SiteA, esse problema poderá ocorrer.

Se houver qualquer problema de conectividade de rede (firewall, roteamento etc.) entre os locais, o cliente também pode enfrentar um problema semelhante. Outro motivo são IPs duplicados em qualquer um dos lados (ou seja, há dois MDMs em execução com o mesmo IP) ou algum tipo de dispositivo de rede interceptando sessões TCP de saída (proxy).

Nesse caso específico, o SiteB MDM manteve os soquetes TCP abertos em relação a um dos MDMs no SiteA, mas não estava conectado a esse MDM, em vez disso, a conexão foi mantida artificialmente viva por um dos roteadores no caminho entre os locais:

Esta é a aparência da saída do netstat em ambos os sites:

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

Observe que o SiteB (192.168.89.14) mostra quatro conexões ESTABELECIDAS com o endereço IP do SiteA (192.168.86.19) na porta 7611, mas não vemos o mesmo na saída "netstat" no SiteA - algum tipo de proxy de rede manteve essas sessões TCP vivas.

Corrija a configuração de IP do MDM par. Teste a conectividade entre locais na porta TCP/7611. Alterne a propriedade do MDM principal para diferentes nós no cluster e/ou reinicie o serviço MDM para fechar os soquetes antigos.

Versões afetadas

PowerFlex 3.5 e superior

Correção feita na versão

N/D — problema não é do PowerFlex