PowerScale: Problemi di replica SyncIQ quando i frame jumbo sono abilitati nei cluster PowerScale
Summary: I lavori di replica SyncIQ potrebbero avere esito negativo in modo intermittente a causa di riavvii del worker SyncIQ ed errori correlati alla rete. Questi problemi si osservano spesso negli ambienti in cui le subnet PowerScale sono configurate per l'utilizzo di frame jumbo. La Knowledge Base (KB) descrive le procedure per convalidare se l'infrastruttura di rete end-to-end supporta i frame jumbo quando i pacchetti IP vengono trasmessi con il flag "Non frammentare" (DF) impostato nell'intestazione IP. Quando il bit DF è abilitato, i dispositivi intermedi non sono in grado di frammentare i pacchetti di dimensioni eccessive. Se un segmento del percorso di rete non supporta le dimensioni MTU configurate (in genere, 9.000 byte per i frame jumbo), questi pacchetti potrebbero essere ignorati, causando potenzialmente errori del processo di worker SyncIQ e instabilità del processo di replica. ...
Symptoms
La replica SyncIQ potrebbe non riuscire con il seguente errore: "SyncIQ policy failed. A work item has been restarted too many times."
- I lavori SyncIQ che replicano dataset di piccole dimensioni in genere vengono completati correttamente.
- I job SyncIQ che coinvolgono dataset più grandi potrebbero non riuscire durante l'esecuzione.
- I lavori di replica SyncIQ senza crittografia hanno esito positivo, mentre quelli che utilizzano la crittografia hanno esito negativo immediatamente.
Cause
Questo problema può verificarsi in modo intermittente o casuale negli ambienti in cui è abilitato il routing dinamico. In questi casi, il traffico SyncIQ può occasionalmente essere instradato attraverso un percorso di rete che non supporta la frammentazione dei pacchetti, causando errori.
Risoluzione dei problemi:
- Utilizzare il comando ping per verificare se l'infrastruttura di rete supporta i frame jumbo testando la compatibilità MTU end-to-end.
ping comando dall'interfaccia di replica del cluster di origine all'interfaccia di replica del cluster di destinazione, specificando una dimensione di payload di 8.972 byte senza impostare il flag "Non frammentare" (DF).
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
L'output mostra che larete passa correttamente i pacchetti quando il flag "Do Not Fragment" (DF) non è impostato, suggerendo che i pacchetti potrebbero essere frammentati durante il transito.
Per verificare il supporto dei pacchetti jumbo inviando un ping dall'interfaccia di replica del cluster di origine all'interfaccia di replica del cluster di destinazione con il flag "Do Not Fragment" abilitato, attenersi alla seguente procedura:
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
L'output mostra che la trasmissione dei pacchetti non riesce quando è impostato il bit "Do Not Fragment" (DF), suggerendo possibili vincoli MTU o problemi con il rilevamento MTU del percorso.
- Utilizzare
traceroutecon test MTU per identificare hop di rete intermedi che potrebbero non supportare i frame jumbo.
Test della specifica di una dimensione di payload di 8972 byte con il flag "Non frammentare" (DF) non impostato.
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
L'output mostra che il test traceroute è stato completato correttamente quando il flag "Do Not Fragment" (DF) non era impostato.
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
L'output mostra che il test traceroute è stato completato correttamente quando il flag "Do Not Fragment" (DF) non era impostato, ma sono stati osservati indicatori di frammentazione lungo il percorso di rete .
Test della specifica di una dimensione di payload di 8972 byte con il flag "Non frammentare" (DF) impostato.
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
*
L'output indica che traceroute alla destinazione non è riuscito, suggerendo potenziali limitazioni MTU o problemi di frammentazione lungo il percorso di rete.
Resolution
Soluzione alternativa:
- Se la subnet PowerScale designata per il traffico SyncIQ è configurata con una MTU di 9.000 byte, è fondamentale garantire che l'intero percorso di rete tra i cluster PowerScale partecipanti supporti completamente i frame jumbo.
- Se il percorso di rete tra i cluster PowerScale partecipanti non supporta i frame jumbo, assicurarsi che la subnet PowerScale dedicata al traffico SyncIQ sia configurata con una MTU di 1500 byte su entrambi i sistemi di origine e di destinazione.