Quelles sont les causes de la perte de paquets uniquement lors de grosses écritures sur un NAS domestique ?

La perte de paquets lors de grosses écritures NAS révèle généralement une faiblesse du chemin réseau client-vers-NAS sous charge soutenue, et non uniquement des disques.

Un ping court ou une navigation dans un répertoire peut rester propre car il génère peu de trafic, tandis qu’une écriture SMB de plusieurs gigaoctets maintient le client en transmission, remplit les files d’attente du switch, sollicite le câble à la vitesse de ligne et force la carte réseau (NIC) et le CPU du NAS à recevoir en continu. Le diagnostic doit donc comparer les mesures au repos et en charge, suivre la direction de l’écriture étape par étape, et changer un câble, un port, une fonction du pilote ou une condition d’envoi à la fois.

Vérifiez que la perte n’apparaît qu’en charge d’écriture

Lancez un ping continu de petite taille depuis le client qui écrit vers le NAS avant la copie, pendant une écriture soutenue de gros fichiers, et après l’arrêt de la copie. En même temps, enregistrez le débit SMB, la latence en charge, les retransmissions et les compteurs d’erreurs d’interface sur les deux points.

Le test de perte de paquets doit combiner ping, iperf et statistiques d’interface car un simple ping de quatre paquets peut manquer une défaillance déclenchée par la charge. Le schéma utile est de voir si la perte ou les erreurs commencent avec l’écriture et disparaissent quand elle s’arrête.

Si seule la latence augmente tandis que les paquets finissent par revenir, examinez la mise en file d’attente et le bufferbloat avant de conclure à une perte de paquets. Si le stockage NAS marque une pause mais que les pings et compteurs d’interface restent propres, le goulot d’étranglement est plus probablement le chemin d’écriture, le système de fichiers, la vidange du cache, la parité ou l’application plutôt que la livraison Ethernet.

Suivez la direction de l’écriture avant de changer le matériel

Lors d’une écriture client-vers-NAS, la carte réseau du client est l’émetteur, le switch transmet vers le port NAS, et la carte réseau du NAS est le récepteur. Cette direction indique quels compteurs et substitutions peuvent réellement isoler la faute.

Un compteur de transmission propre sur le NAS ne garantit pas que la réception NAS est correcte, et un compteur de réception propre sur le client ne renseigne pas sur les trames quittant le client. Comparez les erreurs et pertes TX du client, les compteurs d’entrée et de sortie du switch, les erreurs et pertes RX du NAS, et les retransmissions TCP sur le même intervalle de test.

Réinitialisez ou enregistrez les compteurs avant chaque test, transférez le même gros fichier, puis calculez quel compteur augmente uniquement pendant la défaillance. Le premier équipement qui enregistre des erreurs physiques, des rejets en file d’attente, des paquets manqués ou des pertes de réception devient le point de test suivant.

Vérifiez si les erreurs physiques augmentent à la vitesse de ligne soutenue

Un câble, connecteur, transceiver ou port de switch marginal peut passer un trafic léger tout en accumulant des erreurs CRC, trame, porteuse ou symbole lors d’une longue écriture. Les gros transferts ne « surcharge » pas un câble correctement négocié ; ils créent simplement assez de trames pour révéler rapidement un chemin physique faible.

Des cas réels de dépannage de transfert de fichiers montrent que les erreurs d’interface lors de grosses copies pointent vers le câble, la carte réseau, le port ou l’équipement intermédiaire plutôt que la taille du fichier elle-même.

Remplacez un seul composant par test : d’abord le câble patch, puis le port du switch, puis l’adaptateur client ou le port NAS si possible. Un diagnostic de couche physique est confirmé lorsque la croissance des erreurs suit un composant ou disparaît après cette substitution unique.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

$799.00 - $2,499.00

Buy Now

Vérifiez si le récepteur NAS perd des trames avant que SMB ne puisse les traiter

Le réseau peut être électriquement propre alors que l’hôte récepteur perd encore des paquets parce que ses files d’attente NIC, pilote, gestion des interruptions, CPU ou switch virtuel ne peuvent pas gérer le débit d’arrivée. Cela est particulièrement plausible sur un petit NAS exécutant chiffrement, conteneurs, indexation ou travail de parité pendant l’écriture.

Un cas Ethernet direct à haute vitesse décrit une surcharge de traitement des paquets par l’hôte même sans réseau multi-sauts congestionné. La distinction clé est que les compteurs de pertes RX ou de paquets manqués de l’hôte augmentent tandis que les compteurs CRC câble restent propres.

Répétez l’écriture avec les services NAS non essentiels en pause, puis testez une charge réseau mémoire-à-mémoire qui supprime les écritures disque. Si les pertes de réception persistent sans I/O stockage, concentrez-vous sur le pilote NIC, la profondeur des files, la distribution des interruptions, le switch virtuel et le CPU hôte plutôt que sur le système de fichiers.

Recherchez des micro-bursts sur un port de sortie plus lent ou partagé

La perte de paquets peut survenir à l’intérieur du switch lorsqu’un client plus rapide envoie vers un port NAS plus lent, plusieurs clients écrivent simultanément, ou le trafic de plusieurs ports d’entrée converge sur une file de sortie. L’utilisation moyenne peut sembler sûre même si une rafale courte dépasse la capacité de la file.

Un exemple d’écriture de stockage avec perte de paquets par micro-burst montre comment deux émetteurs à haut débit peuvent brièvement nécessiter plus de bande passante et d’espace tampon en sortie que le port de destination ne peut fournir.

Testez un émetteur via un switch, puis comparez une connexion directe ou un chemin avec des vitesses de lien égales. Si la perte disparaît lorsque les émetteurs concurrents, un uplink plus lent ou le switch intermédiaire sont retirés, inspectez les rejets en sortie et le comportement des files plutôt que de remplacer les disques NAS.

Testez EEE et les déchargements seulement après avoir localisé la faute

Energy Efficient Ethernet, déchargement de somme de contrôle, déchargement de gros envoi, contrôle de flux et modération des interruptions peuvent affecter certaines combinaisons NIC et pilote, mais désactiver toutes les fonctions en même temps détruit les preuves nécessaires pour identifier la cause réelle.

Un problème Ethernet documenté sur Raspberry Pi a montré que désactiver Energy Efficient Ethernet arrêtait une perte sévère de paquets pour ce contrôleur et partenaire de lien. C’est un test A/B utile uniquement après que les compteurs ou substitutions pointent vers le point final plutôt que le câble ou la file du switch.

Changez une fonction, répétez la même grosse écriture, et restaurez le réglage initial si le résultat ne change pas. Une solution de contournement au niveau pilote doit être documentée avec le modèle d’adaptateur, la version du pilote, le port du switch et le symptôme exact afin qu’une mise à jour ultérieure puisse être testée plutôt que de laisser un réglage inexpliqué en place.

Utilisez le schéma des résultats pour choisir la réparation suivante

Le diagnostic final doit expliquer pourquoi le trafic léger reste propre et les écritures soutenues échouent. Les erreurs physiques indiquent un problème de chemin de signal ; les rejets en sortie du switch indiquent une pression sur la file ; les pertes RX NAS indiquent une surcharge du récepteur ; et des compteurs réseau propres avec une copie bloquée renvoient au stockage ou au comportement de l’application.

L’explication de ZimaSpace sur la façon dont la perte de paquets réduit le débit utile aide à comprendre pourquoi le lien négocié peut rester à pleine vitesse alors que l’écriture SMB ralentit, marque une pause ou retransmet plusieurs fois.

Ne déclarez pas le problème résolu tant que la même grosse écriture ne s’achève pas de manière répétée avec une latence stable, zéro nouvelle erreur physique, aucune perte RX ou rejet en sortie croissant, et une somme de contrôle destination intacte. Si les preuves ne permettent pas de distinguer le réseau du chemin de stockage, cessez de modifier les réglages et refaites le test sans I/O disque.