PowerScale: SyncIQ-Replikationsprobleme bei aktivierten Jumbo Frames auf PowerScale-Clustern
Summary: SyncIQ-Replikationsjobs können aufgrund von SyncIQ-Worker-Neustarts und netzwerkbezogenen Fehlern zeitweise fehlschlagen. Diese Probleme treten häufig in Umgebungen auf, in denen PowerScale-Subnetze für die Verwendung von Jumbo Frames konfiguriert sind. In der Wissensdatenbank (KB) werden Verfahren beschrieben, mit denen überprüft wird, ob die End-to-End-Netzwerkinfrastruktur Jumbo Frames unterstützt, wenn IP-Pakete mit dem im IP-Header festgelegten Flag "Do Not Fragment" (DF) übertragen werden. Wenn das DF-Bit aktiviert ist, können Zwischengeräte übergroße Pakete nicht fragmentieren. Wenn ein Segment des Netzwerkpfads die konfigurierte MTU-Größe (in der Regel 9.000 Byte für Jumbo Frames) nicht unterstützt, können diese Pakete verworfen werden, was möglicherweise zu Fehlern im SyncIQ-Arbeitsprozess und Instabilität des Replikationsjobs führt. ...
Symptoms
Die SyncIQ-Replikation kann mit dem folgenden Fehler fehlschlagen: "SyncIQ policy failed. A work item has been restarted too many times."
- SyncIQ-Jobs, mit denen kleine Datenvolumen repliziert werden, werden in der Regel erfolgreich abgeschlossen.
- SyncIQ-Jobs mit größeren Datenvolumen können während der Ausführung fehlschlagen.
- SyncIQ-Replikationsjobs ohne Verschlüsselung sind erfolgreich, während Jobs mit Verschlüsselung sofort fehlschlagen.
Cause
Dieses Problem kann gelegentlich auftreten oder zufällig in Umgebungen auftreten, in denen dynamisches Routing aktiviert ist. In solchen Fällen kann der SyncIQ-Datenverkehr gelegentlich über einen Netzwerkpfad geleitet werden, der keine Paketfragmentierung unterstützt, was zu Ausfällen führt.
Troubleshooting:
- Verwenden Sie den Befehl ping, um zu überprüfen, ob die Netzwerkinfrastruktur Jumbo Frames unterstützt, indem Sie die durchgängige MTU-Kompatibilität testen.
ping Befehl von der Replikationsschnittstelle des Quellclusters an die Replikationsschnittstelle des Zielclusters unter Angabe einer Payload-Größe von 8972 Byte, ohne das Flag "Do Not Fragment" (DF) festzulegen.
isi_for_array -n<lnn> 'ping -S <source-ip> -s 8972 <target-ip>'
source-1# isi_for_array -n1 'ping -c 4 -S xxx.xxx.xxx.xxx -s 8972 yyy.yyy.yyy.yyy'
source-1: PING yyy.yyy.yyy.yyy (10.0.1.231) from xxx.xxx.xxx.xxx: 8972 data bytes
source-1: 1528 bytes from yyy.yyy.yyy.yyy: icmp_seq=0 ttl=64 time=0.944 ms
source-1: 1528 bytes from yyy.yyy.yyy.yyy: icmp_seq=1 ttl=64 time=0.797 ms
source-1: 1528 bytes from yyy.yyy.yyy.yyy: icmp_seq=2 ttl=64 time=0.912 ms
Die Ausgabe zeigt, dass dasNetzwerk erfolgreich Pakete weiterleitet, wenn das Flag "Do Not Fragment" (DF) nicht gesetzt ist, was darauf hindeutet, dass Pakete während der Übertragung fragmentiert werden können.
Gehen Sie folgendermaßen vor, um die Jumbo-Paketunterstützung zu überprüfen, indem Sie einen Ping von der Replikationsschnittstelle des Quellclusters an die Replikationsschnittstelle des Zielclusters mit aktiviertem Flag "Do Not fragment" senden:
isi_for_array -n<lnn> 'ping -S <source-ip> -D -s 8972 <target-ip>'
source-1# isi_for_array -n1 'ping -c 4 -S xxx.xxx.xxx.xxx -D -s 8972 yyy.yyy.yyy.yyy'
source-1: ping: sendto: Message too long
source-1: ping: sendto: Message too long
source-1: ping: sendto: Message too long
source-1: ping: sendto: Message too long
source-1: ping: sendto: Message too long
Die Ausgabe zeigt, dass die Paketübertragung fehlschlägt, wenn das DF-Bit (Do Not Fragment) gesetzt ist, was auf mögliche MTU-Einschränkungen oder Probleme bei der Pfad-MTU-Erkennung hindeutet.
- Verwenden Sie
traceroutemit MTU-Tests zur Identifizierung zwischengeschalteter Netzwerkhops, die möglicherweise keine Jumbo Frames unterstützen.
Der Test legt eine Payload-Größe von 8.972 Byte fest und das Flag "Do Not Fragment" (DF) ist nicht gesetzt.
isi_for_array -n<lnn> 'traceroute -s <source-ip> -p 5667 <target-ip> 8972'
source-1# isi_for_array -n1 'traceroute -s xxx.xxx.xxx.xxx -p 5667 yyy.yyy.yyy.yyy 8972' traceroute to yyy.yyy.yyy.yyy (yyy.yyy.yyy.yyy) from xxx.xxx.xxx.xxx, 64 hops max, 8972 byte packets 1 example.name.internal (aaa.aaa.aaa.aaa) 0.577 ms 0.470 ms 0.472 ms 2 bbb.bbb.bbb.bbb (bbb.bbb.bbb.bbb) 24.810 ms ccc.ccc.ccc.ccc (ccc.ccc.ccc.ccc) 23.418 ms 23.366 ms 3 yyy.yyy.yyy.yyy (yyy.yyy.yyy.yyy) 23.639 ms 23.596 ms 23.608 ms
Die Ausgabe zeigt, dass der Traceroute-Test erfolgreich abgeschlossen wurde, wenn das Flag "Do Not Fragment" (DF) nicht festgelegt wurde.
source-1# isi_for_array -n1 'traceroute -s xxx.xxx.xxx.xxx -p 5667 yyy.yyy.yyy.yyy 8972' traceroute to yyy.yyy.yyy.yyy (yyy.yyy.yyy.yyy) from xxx.xxx.xxx.xxx, 64 hops max, 8972 byte packets 1 * * * 2 * * * 3 yyy.yyy.yyy.yyy (yyy.yyy.yyy.yyy) 23.661 ms 23.618 ms 23.743 ms
Die Ausgabe zeigt, dass der Traceroute-Test erfolgreich abgeschlossen wurde, wenn das Flag "Do Not Fragment" (DF) nicht festgelegt war, aber Fragmentierungsindikatoren entlang des Netzwerkpfads beobachtet wurden .
Der Test legt eine Payload-Größe von 8972 Byte mit festgelegtem Flag "Do Not Fragment" (DF) fest.
isi_for_array -n<lnn> 'traceroute -F -s <source-ip> -p 5667 <target-ip> 8972'
source-1# isi_for_array -n1 'traceroute -F -s xxx.xxx.xxx.xxx -p 5667 yyy.yyy.yyy.yyy 8972'
traceroute to yyy.yyy.yyy.yyy (yyy.yyy.yyy.yyy) from xxx.xxx.xxx.xxx, 64 hops max, 8972 byte packets
traceroute: sendto: Message too long
1 traceroute: wrote yyy.yyy.yyy.yyy 8972 chars, ret=-1
*traceroute: sendto: Message too long
traceroute: wrote yyy.yyy.yyy.yyy 8972 chars, ret=-1
*traceroute: sendto: Message too long
traceroute: wrote yyy.yyy.yyy.yyy 8972 chars, ret=-1
*
traceroute: sendto: Message too long
2 traceroute: wrote yyy.yyy.yyy.yyy 8972 chars, ret=-1
*traceroute: sendto: Message too long
traceroute: wrote yyy.yyy.yyy.yyy 8972 chars, ret=-1
*traceroute: sendto: Message too long
traceroute: wrote yyy.yyy.yyy.yyy 8972 chars, ret=-1
*
Die Ausgabe weist darauf hin, dass die Traceroute zum Ziel fehlgeschlagen ist, was auf potenzielle MTU-Einschränkungen oder Fragmentierungsprobleme entlang des Netzwerkpfads hindeutet.
Resolution
Problemumgehung:
- Wenn das für den SyncIQ-Datenverkehr vorgesehene PowerScale-Subnetz mit einer MTU von 9.000 Byte konfiguriert ist, muss unbedingt sichergestellt werden, dass der gesamte Netzwerkpfad zwischen den teilnehmenden PowerScale-Clustern Jumbo Frames vollständig unterstützt.
- Wenn der Netzwerkpfad zwischen teilnehmenden PowerScale-Clustern keine Jumbo Frames unterstützt, stellen Sie sicher, dass das PowerScale-Subnetz, das für den SyncIQ-Datenverkehr vorgesehen ist, sowohl auf den Quell- als auch auf den Zielsystemen mit einer MTU von 1.500 Byte konfiguriert ist.