Was verursacht Paketverluste nur bei großen Schreibvorgängen auf einem Heim-NAS?

Packetverlust bei großen NAS-Schreibvorgängen weist in der Regel auf eine Schwäche im Netzwerkpfad vom Client zum NAS unter Dauerlast hin, nicht nur auf die Festplatten allein.

Ein kurzer Ping oder das Durchsuchen eines Verzeichnisses kann sauber bleiben, da wenig Datenverkehr erzeugt wird, während ein mehrgigabytegroßer SMB-Schreibvorgang den Client kontinuierlich senden lässt, Switch-Warteschlangen füllt, das Kabel mit voller Leitungsgeschwindigkeit belastet und die NAS-Netzwerkkarte sowie CPU zum kontinuierlichen Empfang zwingt. Die Diagnose sollte daher Leerlauf- und Belastungsmessungen vergleichen, die Schreibrichtung Hop für Hop verfolgen und jeweils nur ein Kabel, einen Port, eine Treiberfunktion oder eine Senderbedingung ändern.

Beweisen, dass der Verlust nur unter Schreiblast auftritt

Führen Sie vor dem Kopieren, während eines anhaltenden großen Datei-Schreibvorgangs und nach dem Stopp der Kopie einen kontinuierlichen kleinen Ping vom schreibenden Client zum NAS durch. Zeichnen Sie gleichzeitig SMB-Durchsatz, belastete Latenz, erneute Übertragungen und Schnittstellen-Fehlerzähler an beiden Endpunkten auf.

Packetverlusttests sollten Ping, Iperf und Schnittstellenstatistiken kombinieren, da ein einzelner Vier-Paket-Ping einen kurzzeitigen, lastbedingten Ausfall übersehen kann. Das nützliche Muster ist, ob Verluste oder Fehler mit dem Schreibvorgang beginnen und verschwinden, wenn das Schreiben stoppt.

Wenn nur die Latenz steigt, die Pakete aber letztlich zurückkommen, untersuchen Sie Warteschlangenbildung und Bufferbloat, bevor Sie von Packetverlust sprechen. Wenn das NAS-Speichergerät pausiert, aber Pings und Schnittstellenzähler sauber bleiben, liegt der Engpass eher im Schreibpfad, Dateisystem, Cache-Flush, Parität oder der Anwendung als in der Ethernet-Übertragung.

Folgen Sie der Schreibrichtung, bevor Sie Hardware tauschen

Während eines Client-zu-NAS-Schreibvorgangs ist die Client-Netzwerkkarte der Sender, der Switch leitet zum NAS-Port weiter, und die NAS-Netzwerkkarte ist der Empfänger. Diese Richtung zeigt, welche Zähler und Austauschmaßnahmen den Fehler isolieren können.

Ein sauberer Sendeszähler des NAS beseitigt nicht automatisch Fehler auf der Empfangsseite des NAS, und ein sauberer Empfangszähler des Clients sagt wenig über die vom Client gesendeten Frames aus. Vergleichen Sie Client-TX-Fehler und -Verluste, Switch-Eingangs- und Ausgangszähler, NAS-RX-Fehler und -Verluste sowie TCP-Neuübertragungen im gleichen Testzeitraum.

Setzen Sie die Zähler vor jedem Durchlauf zurück oder notieren Sie sie, übertragen Sie dieselbe große Datei und berechnen Sie, welcher Zähler nur während des Fehlers ansteigt. Das erste Gerät, das physische Fehler, Warteschlangenausfälle, verlorene Pakete oder Empfangsverluste aufzeichnet, wird zum nächsten Testpunkt.

Prüfen Sie, ob physische Fehler bei Dauerleitungsgeschwindigkeit zunehmen

Ein marginales Kabel, ein Stecker, ein Transceiver oder ein Switch-Port kann leichten Datenverkehr passieren lassen und dennoch während eines langen Schreibvorgangs CRC-, Frame-, Träger- oder Symbolfehler ansammeln. Große Übertragungen „überlasten“ ein korrekt ausgehandeltes Kabel nicht; sie erzeugen einfach genug Frames, um einen schwachen physischen Pfad schnell sichtbar zu machen.

Reale Fehlerbeispiele bei Dateiübertragungen zeigen, dass Schnittstellenfehler bei großen Kopien eher auf Kabel, Netzwerkkarte, Port oder Zwischengeräte als auf die Dateigröße selbst hinweisen.

Ersetzen Sie pro Testlauf nur eine Komponente: zuerst das Patchkabel, dann den Switch-Port, anschließend den Client-Adapter oder NAS-Port, wenn möglich. Eine Diagnose auf physikalischer Ebene ist bestätigt, wenn das Fehlerwachstum einer Komponente folgt oder nach deren Austausch verschwindet.

Featured

ZimaCube 2 Persönliche Cloud Home NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

Prüfen Sie, ob der NAS-Empfänger Frames verwirft, bevor SMB sie verarbeiten kann

Das Netzwerk kann elektrisch sauber sein, während der empfangende Host dennoch Pakete verliert, weil seine NIC-Warteschlangen, der Treiber, die Interrupt-Verarbeitung, CPU oder virtueller Switch die Ankunftsrate nicht bewältigen können. Dies ist besonders plausibel bei einem kleinen NAS, das während des Schreibens Verschlüsselung, Container, Indexierung oder Paritätsarbeit ausführt.

Ein direkter Hochgeschwindigkeits-Ethernet-Fall beschreibt Überlastung der Paketverarbeitung im Host, selbst ohne ein überlastetes Multi-Hop-Netzwerk. Der entscheidende Unterschied ist, dass Host-RX-Verluste oder Zähler für verpasste Pakete steigen, während Kabel-CRC-Zähler sauber bleiben.

Wiederholen Sie den Schreibvorgang mit pausierten nicht wesentlichen NAS-Diensten und testen Sie dann eine Speicher-zu-Speicher-Netzwerklast, die Festplattenschreibvorgänge entfernt. Wenn Empfangsverluste ohne Speicher-I/O bestehen bleiben, konzentrieren Sie sich auf NIC-Treiber, Warteschlangentiefe, Interrupt-Verteilung, virtuellen Switch und Host-CPU statt auf das Dateisystem.

Suchen Sie nach Mikrospitzen an langsameren oder geteilten Ausgangsports

Packetverlust kann im Switch auftreten, wenn ein schnellerer Client an einen langsameren NAS-Port sendet, mehrere Clients gleichzeitig schreiben oder Verkehr von mehreren Eingangsports auf eine Ausgangswarteschlange trifft. Die durchschnittliche Auslastung kann sicher erscheinen, obwohl eine kurze Spitze die Warteschlangen-Kapazität überschreitet.

Ein Beispiel für Mikrospitzen-Paketverlust bei Speicher-Schreibvorgängen zeigt, wie zwei Hochgeschwindigkeitssender kurzzeitig mehr Ausgangsbandbreite und Pufferplatz benötigen können, als der Zielport bereitstellt.

Testen Sie einen Sender über einen Switch und vergleichen Sie dann eine direkte Verbindung oder einen Pfad mit gleichen Linkgeschwindigkeiten. Wenn der Verlust verschwindet, wenn konkurrierende Sender, ein langsamerer Uplink oder der Zwischenswitch entfernt werden, prüfen Sie Ausgangsverluste und Warteschlangenverhalten, anstatt die NAS-Festplatten auszutauschen.

Testen Sie EEE und Offloads erst, nachdem der Fehler lokalisiert ist

Energy Efficient Ethernet, Checksum-Offload, Large-Send-Offload, Flusskontrolle und Interrupt-Moderation können bestimmte NIC- und Treiberkombinationen beeinflussen, aber das gleichzeitige Deaktivieren aller Funktionen zerstört die Beweise, die zur Identifikation der tatsächlichen Ursache nötig sind.

Ein dokumentiertes Raspberry-Pi-Ethernet-Problem zeigte, dass das Deaktivieren von Energy Efficient Ethernet bei diesem Controller und Linkpartner schweren Packetverlust stoppte. Dies ist ein nützlicher A/B-Test, aber nur nachdem Zähler oder Austauschmaßnahmen auf den Endpunkt und nicht auf Kabel oder Switch-Warteschlange hinweisen.

Ändern Sie jeweils eine Funktion, wiederholen Sie denselben großen Schreibvorgang und stellen Sie die ursprüngliche Einstellung wieder her, wenn sich das Ergebnis nicht ändert. Eine Treiber-Feature-Umgehung sollte mit Adaptermodell, Treiberversion, Switch-Port und genauem Symptom dokumentiert werden, damit ein späteres Update getestet werden kann, anstatt unerklärte Anpassungen beizubehalten.

Nutzen Sie das Ergebnis-Muster, um die nächste Reparatur auszuwählen

Die abschließende Diagnose sollte erklären, warum kleiner Datenverkehr sauber bleibt und anhaltende Schreibvorgänge fehlschlagen. Physische Fehler deuten auf ein Signalpfadproblem hin; Switch-Ausgangsverluste auf Warteschlangendruck; NAS-RX-Verluste auf Überlast des Empfängers; und saubere Netzwerkkontenzähler bei einem gestoppten Kopiervorgang weisen auf Speicher- oder Anwendungsverhalten hin.

Die Erklärung von ZimaSpace, wie Packetverlust den nutzbaren Durchsatz reduziert, hilft zu verstehen, warum der ausgehandelte Link trotz verlangsamtem, pausierendem oder wiederholt neu übertragenem SMB-Schreibvorgang volle Geschwindigkeit halten kann.

Erklären Sie das Problem nicht als behoben, bevor derselbe große Schreibvorgang wiederholt mit stabiler Latenz, null neuen physischen Fehlern, keinem Anstieg von Empfangsverlusten oder Ausgangsverlusten und intakter Zielprüfsumme abgeschlossen wird. Wenn die Beweise Netzwerk und Speicherpfad nicht unterscheiden können, stoppen Sie das Ändern von Einstellungen und führen Sie den Test ohne Festplatten-I/O erneut durch.