O que causa perda de pacotes apenas durante grandes gravações em NAS domésticos?

A perda de pacotes durante grandes gravações em NAS geralmente revela uma fraqueza na carga sustentada no caminho de rede do cliente para o NAS, e não apenas nos discos.

Um ping curto ou uma navegação por diretórios pode permanecer limpa porque gera pouco tráfego, enquanto uma gravação SMB de vários gigabytes mantém o cliente a transmitir, enche as filas do switch, exerce o cabo à taxa da linha e força a NIC e a CPU do NAS a receber continuamente. O diagnóstico deve, portanto, comparar medições em repouso e sob carga, seguir a direção da gravação hop a hop e alterar um cabo, porta, funcionalidade do driver ou condição do emissor de cada vez.

Comprove Que a Perda Aparece Apenas Sob a Carga de Gravação

Execute um ping contínuo pequeno do cliente que grava para o NAS antes da cópia, durante uma gravação sustentada de ficheiros grandes e após a cópia parar. Ao mesmo tempo, registe o débito SMB, latência sob carga, retransmissões e contadores de erros da interface em ambos os pontos finais.

O teste de perda de pacotes deve combinar ping, iperf e estatísticas de interface porque um único ping de quatro pacotes pode não detectar uma falha breve desencadeada pela carga. O padrão útil é verificar se a perda ou erros começam com a gravação e desaparecem quando a gravação para.

Se apenas a latência aumentar enquanto os pacotes eventualmente retornam, investigue enfileiramento e bufferbloat antes de considerar perda de pacotes. Se o armazenamento NAS pausar mas os pings e contadores de interface permanecerem limpos, o gargalo é mais provavelmente o caminho de gravação, sistema de ficheiros, limpeza de cache, paridade ou aplicação em vez da entrega Ethernet.

Siga a Direção da Gravação Antes de Trocar Hardware

Durante uma gravação do cliente para o NAS, a NIC do cliente é o transmissor, o switch encaminha para a porta do NAS, e a NIC do NAS é o recetor. Essa direção indica quais contadores e substituições podem realmente isolar a falha.

Um contador de transmissão limpo no NAS não elimina a possibilidade de problemas no lado de receção do NAS, e um contador de receção limpo no cliente diz pouco sobre os quadros que saem do cliente. Compare erros e descartes de transmissão do cliente, contadores de entrada e saída do switch, erros e descartes de receção do NAS, e retransmissões TCP durante o mesmo intervalo de teste.

Reinicie ou registe os contadores antes de cada teste, transfira o mesmo ficheiro grande e depois calcule qual contador aumenta apenas durante a falha. O primeiro dispositivo que registar erros físicos, descartes de fila, pacotes perdidos ou descartes de receção torna-se o próximo ponto de teste.

Verifique Se os Erros Físicos Aumentam à Taxa de Linha Sustentada

Um cabo, conector, transceptor ou porta de switch marginal pode passar tráfego leve e ainda assim acumular erros CRC, de quadro, de portadora ou de símbolo durante uma gravação longa. Transferências grandes não “sobrecarregam” um cabo negociado corretamente; simplesmente criam quadros suficientes para revelar rapidamente um caminho físico fraco.

Casos reais de resolução de problemas de transferência de ficheiros mostram que erros de interface durante cópias grandes apontam para o cabo, NIC, porta ou equipamento intermédio em vez do tamanho do ficheiro em si.

Substitua apenas um componente por teste: primeiro o cabo de patch, depois a porta do switch, depois o adaptador do cliente ou a porta do NAS quando possível. Um diagnóstico da camada física é suportado quando o crescimento dos erros segue um componente ou desaparece após essa substituição única.

Featured

ZimaCube 2 NAS Pessoal Cloud para Casa

ZimaCube2

$799.00 - $2,499.00

Buy Now

Verifique Se o Recetor do NAS Descarta Quadros Antes Que o SMB os Possa Processar

A rede pode estar eletricamente limpa enquanto o host recetor ainda perde pacotes porque as filas da sua NIC, driver, tratamento de interrupções, CPU ou switch virtual não conseguem atender à taxa de chegada. Isto é especialmente plausível num NAS pequeno a executar encriptação, contentores, indexação ou trabalho de paridade durante a gravação.

Um caso direto de Ethernet de alta velocidade descreve sobrecarga de processamento de pacotes no host mesmo sem uma rede multi-hop congestionada. A distinção chave é que os contadores de descartes RX do host ou pacotes perdidos aumentam enquanto os contadores CRC do cabo permanecem limpos.

Repita a gravação com serviços NAS não essenciais pausados, depois teste uma carga de trabalho de rede memória-a-memória que elimina gravações em disco. Se os descartes de receção persistirem sem I/O de armazenamento, concentre-se no driver da NIC, profundidade da fila, distribuição de interrupções, switch virtual e CPU do host em vez do sistema de ficheiros.

Procure Microexplosões numa Porta de Saída Mais Lenta ou Partilhada

A perda de pacotes pode ocorrer dentro do switch quando um cliente mais rápido envia para uma porta NAS mais lenta, vários clientes escrevem ao mesmo tempo, ou o tráfego de várias portas de entrada converge numa fila de saída. A utilização média pode parecer segura mesmo que uma explosão curta exceda a capacidade da fila.

Um exemplo de gravação de armazenamento de perda de pacotes por microexplosão mostra como dois emissores de alta taxa podem exigir brevemente mais largura de banda e espaço de buffer de saída do que a porta de destino fornece.

Teste um emissor através de um switch, depois compare uma ligação direta ou um caminho com velocidades de ligação iguais. Se a perda desaparecer quando emissores concorrentes, um uplink mais lento ou o switch intermédio forem removidos, inspecione descartes de saída e comportamento da fila em vez de substituir os discos do NAS.

Teste EEE e Offloads Apenas Após a Localização da Falha

Energy Efficient Ethernet, descarregamento de checksum, descarregamento de envio grande, controlo de fluxo e moderação de interrupções podem afetar combinações específicas de NIC e driver, mas desativar todas as funcionalidades de uma vez destrói a evidência necessária para identificar a causa real.

Um problema documentado de Ethernet no Raspberry Pi descobriu que desativar Energy Efficient Ethernet parou a perda severa de pacotes para esse controlador e parceiro de ligação. Este é um teste A/B útil apenas depois de contadores ou substituições indicarem o ponto final em vez do cabo ou fila do switch.

Altere uma funcionalidade, repita a mesma gravação grande e restaure a configuração original se o resultado não mudar. Uma solução alternativa de funcionalidade do driver deve ser documentada com o modelo do adaptador, versão do driver, porta do switch e sintoma exato para que uma atualização posterior possa ser testada em vez de deixar um ajuste inexplicado.

Use o Padrão de Resultados para Escolher a Próxima Reparação

O diagnóstico final deve explicar por que o tráfego pequeno permanece limpo e as gravações sustentadas falham. Erros físicos indicam um problema no caminho do sinal; descartes de saída do switch indicam pressão na fila; descartes RX do NAS indicam sobrecarga do recetor; e contadores de rede limpos com uma cópia bloqueada apontam para comportamento do armazenamento ou aplicação.

A explicação da ZimaSpace sobre como a perda de pacotes reduz o débito útil ajuda a interpretar por que a ligação negociada pode permanecer à velocidade total enquanto a gravação SMB desacelera, pausa ou retransmite repetidamente.

Não declare o problema resolvido até que a mesma gravação grande seja concluída repetidamente com latência estável, zero novos erros físicos, sem crescimento de descartes de receção ou de saída, e um checksum de destino intacto. Se a evidência não conseguir distinguir a rede do caminho de armazenamento, pare de alterar configurações e repita o teste com I/O de disco removido.