PowerFlex: Häufige MDM-Verbindungstrennungen

In diesem Szenario meldet der primäre MDM häufig Trennungen zwischen verschiedenen MDMs, was darauf hinweist, dass alle MDMs im Cluster betroffen sind.

2023-10-25 14:24:06.740 MDM_CLUSTER_NODE_DEGRADED ERROR           MDM cluster node is now DEGRADED and is in offline node node05 (ID 0411f6fe38bf3103); IPs: [14.14.14.105,15.15.15.105], Port: 9011 .
2023-10-25 14:24:06.845 MDM_CLUSTER_CONNECTED     INFO            The MDM, node05 (ID 0411f6fe38bf3103), connected after 100ms
2023-10-25 14:24:06.952 MDM_CLUSTER_NODE_NORMAL   INFO            MDM cluster node node05 (ID 0411f6fe38bf3103); IPs: [14.14.14.105,15.15.15.105], Port: 9011 is now in NORMAL state.
2023-10-25 14:24:06.952 MDM_CLUSTER_NORMAL        INFO            MDM cluster is now in NORMAL mode.
2023-10-25 14:24:42.060 MDM_CLUSTER_LOST_CONNECTION WARNING       The MDM, node02 (ID 6176009c2159e002), has lost connection to the cluster.
2023-10-25 14:24:42.060 MDM_CLUSTER_LOST_CONNECTION WARNING       The MDM, node05 (ID 0411f6fe38bf3103), has lost connection to the cluster.
2023-10-25 14:24:42.162 MDM_CLUSTER_CONNECTED     INFO            The MDM, node05 (ID 0411f6fe38bf3103), connected after 100ms
2023-10-25 14:24:42.162 MDM_CLUSTER_CONNECTED     INFO            The MDM, node02 (ID 6176009c2159e002), connected after 100ms
...

Die trc-Protokolle des primären MDM melden möglicherweise die folgenden Fehler.

2023/10/25 14:24:42.161854 7fb3d978adb0:netPath_StartAsClient_CK:00920:  :: Disconnected Live CLIENT path 0x7fb3e8113bb0 of portal 0x7fb3e8111650 net 0x7fb3e8010420 socket -1 infl
ights 0 HS:0 Start connection from conID 79b6776f71a29e00 to 0411f6fe38bf3103, to IP 15.15.15.105:9011
2023/10/25 14:24:42.161902 7fb3d978adb0:netPath_StartAsClient_CK:00920:  :: Disconnected Live CLIENT path 0x7fb3e8120b30 of portal 0x7fb3e8120930 net 0x7fb3e8010420 socket -1 infl
ights 0 HS:0 Start connection from conID 79b6776f71a29e00 to 6176009c2159e002, to IP 14.14.14.102:9011
2023/10/25 14:24:42.161919 7fb3d978adb0:netPath_StartAsClient_CK:00920:  :: Disconnected Live CLIENT path 0x7fb3e8122f90 of portal 0x7fb3e8120a30 net 0x7fb3e8010420 socket -1 infl
ights 0 HS:0 Start connection from conID 79b6776f71a29e00 to 6176009c2159e002, to IP 15.15.15.102:9011
2023/10/25 14:24:42.161934 7fb3d978adb0:netPath_StartAsClient_CK:00920:  :: Disconnected Live CLIENT path 0x7fb3e8111750 of portal 0x7fb3e8111550 net 0x7fb3e8010420 socket -1 inflights 0 HS:0 Start connection from conID 79b6776f71a29e00 to 0411f6fe38bf3103, to IP 14.14.14.105:9011

SAR-Daten können Spitzen bei erneuten TCP-Übertragungen aufweisen.

Linux 5.4.225-200.el7.x86_64                10/25/2023      _x86_64_        (64 CPU)
11:56:11 AM  atmptf/s  estres/s retrans/s isegerr/s   orsts/s
12:23:38 PM      0.00      0.00      0.00      0.00      0.00
12:23:39 PM      0.00      0.00    284.00      0.00      0.00
12:23:40 PM      0.00      0.99    123.76      0.00      0.00
12:23:41 PM      0.00      1.00    501.00      0.00      0.00
12:23:42 PM      0.00      0.00    275.25      0.00      0.00
12:24:37 PM      0.00      0.00    274.00      0.00      0.00
12:24:38 PM      0.00      0.00    122.77      0.00      0.00
12:24:39 PM      0.00      0.00    276.00      0.00      0.00
12:24:40 PM      0.00      0.00    159.00      0.00      0.00
12:24:41 PM      0.00      0.00    439.00      0.00      0.00
12:24:42 PM      0.00      7.92    249.50      0.00      8.91
12:24:43 PM      0.00      0.00    109.00      0.00      2.00
12:24:44 PM      0.00      0.99    102.97      0.00      0.99
12:24:45 PM      0.00      0.00     84.00      0.00      0.00
12:24:46 PM      0.00      0.00     63.37      0.00      0.00
12:24:47 PM      0.00      0.00      0.00      0.00      0.00
12:24:48 PM      0.00      0.00    124.75      0.00      0.00
12:24:49 PM      0.00      0.00    321.00      0.00      0.00
12:24:50 PM      0.00      0.00    346.00      0.00      0.00
12:24:51 PM      0.00      0.00    316.00      0.00      0.00

Es kommt zu einem Paketverlust, wenn mit Jumbo Frames gegen die Datennetzwerke gepingt wird, der zeitweilig auftritt, wie der anfängliche Paketverlust von 12 % bei der Adresse 14.14.14.102 zeigt, der in nachfolgenden Tests nicht repliziert wurde.

[root@node01 ~]# for x in {102..105}; do echo "Testing .$x"; ping -c100 -Mdo -i .01 -s 8972 14.14.14.$x |grep -i packet; done
Testing .102
100 packets transmitted, 88 received, 12% packet loss, time 1089ms
Testing .103
100 packets transmitted, 100 received, 0% packet loss, time 1088ms
Testing .104
100 packets transmitted, 100 received, 0% packet loss, time 1088ms
Testing 105
100 packets transmitted, 100 received, 0% packet loss, time 1088ms
 
 
[root@node01 ~]# for x in (102..105); do echo "Testing .$x"; ping -c100 -Mdo -i .01 -s 8972 14.14.14.$x |grep -i packet; done
Testing .102
100 packets transmitted, 100 received, 0% packet loss, time 1089ms
Testing .103
100 packets transmitted, 100 received, 0% packet loss, time 1088ms
Testing .104
100 packets transmitted, 100 received, 0% packet loss, time 1088ms
Testing -105
100 packets transmitted, 100 received, 0% packet loss, time 1088ms

Der MDM-Cluster meldet konstante heruntergestufte Zustände und MDMs werden häufig getrennt oder wieder verbunden. In diesem Szenario hatten der intermittierende Paketverlust oder die Spitzen bei TCP-Neuübertragungen keine Auswirkungen auf den SDS. 

Auswirkungen

Der MDM-Cluster meldet konstant Heruntergestufte Zustände und MDMs werden häufig getrennt und wieder verbunden. In diesem Szenario hatten der intermittierende Paketverlust oder die Spitzen bei TCP-Neuübertragungen keine Auswirkungen auf den SDS. 

Die Netzwerkinstabilität und der zeitweilige Paketverlust hängen anscheinend mit der IPv6-Handhabung innerhalb des Netzwerks zusammen. Durch Ändern der Konfiguration der IPv4-/IPv6-Adressverarbeitung und Deaktivieren von IPv6 wurde das Problem behoben, was auf einen Konflikt oder eine Fehlkonfiguration mit IPv6 hindeutet oder darauf hindeutet, dass das Netzwerk durch den ausschließlichen Betrieb mit IPv4 stabiler und effizienter ist.

Führen Sie den folgenden Befehl auf einem beliebigen Node aus:

echo ""precedence ::ffff:0:0/96 100"" >>/etc/gai.conf

echo "net.ipv6.conf.lo.disable_ipv6=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.all.disable_ipv6=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.default.disable_ipv6=1" >> /etc/sysctl.conf

sed -i 's/IPv6_rpfilter=yes/IPv6_rpfilter=no/g' /etc/firewalld/firewalld.conf

echo "net.ipv6.conf.eth0.disable_ipv6=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.eth1.disable_ipv6=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.eth2.disable_ipv6=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.eth3.disable_ipv6=1" >> /etc/sysctl.conf
echo "net.ipv6.conf.eth4.disable_ipv6=1" >> /etc/sysctl.conf

Versetzen Sie den Node in den Wartungsmodus (IMM oder PMM) und starten Sie ihn dann neu. 

Betroffene Versionen

Kein PowerFlex-Problem

Behoben in Version

Obwohl es sich nicht um ein PowerFlex-Problem handelt, deaktiviert PowerFlex Manager 3.8.7 und höher IPv6 in neuen Bereitstellungen.

Siehe zugehörigen Artikel: PowerFlex: Häufige MDM-Trennungen