大容量のホームNAS書き込み時にのみパケットロスが発生する原因は何ですか？

大容量NAS書き込み時のパケットロスは、通常ディスク単体の問題ではなく、クライアントからNASへのネットワーク経路の持続負荷に弱点があることを示しています。

短いpingやディレクトリの参照はトラフィックが少ないため問題が出にくいですが、数ギガバイトのSMB書き込みはクライアントが継続的に送信し、スイッチのキューを満たし、ケーブルをラインレートで駆動し、NASのNICとCPUに連続受信を強いるためです。診断はアイドル時と負荷時の測定を比較し、書き込み方向をホップごとに追跡し、ケーブル、ポート、ドライバ機能、送信条件を一つずつ変更して行うべきです。

書き込み負荷時のみロスが発生することを証明する

コピー前、持続的な大容量ファイル書き込み中、コピー停止後に、書き込みクライアントからNASへの連続小pingを実行します。同時に、両端点でSMBスループット、負荷時レイテンシ、再送、インターフェースエラーカウンタを記録します。

パケットロスのテストはping、iperf、インターフェース統計を組み合わせて行うべきです。単一の4パケットpingでは短時間の負荷誘発障害を見逃す可能性があるためです。重要なのは、ロスやエラーが書き込み開始時に発生し、書き込み停止時に消えるかどうかのパターンです。

パケットが最終的に戻るがレイテンシだけ上昇する場合は、パケットロスと判断する前にキューイングやバッファブロートを調査してください。NASストレージが一時停止してもpingやインターフェースカウンタが正常なら、ボトルネックはイーサネット伝送ではなく書き込み経路、ファイルシステム、キャッシュフラッシュ、パリティ、アプリケーションの可能性が高いです。

ハードウェア交換前に書き込み方向を追跡する

クライアントからNASへの書き込み中は、クライアントNICが送信側、スイッチがNASポートへ転送し、NAS NICが受信側です。この方向により、どのカウンタや交換が故障の特定に役立つかがわかります。

NASの送信カウンタが正常でも受信側はクリアされず、クライアントの受信カウンタが正常でもクライアントから出るフレームについてはほとんど情報がありません。クライアントのTXエラー・ドロップ、スイッチの入力・出力カウンタ、NASのRXエラー・ドロップ、TCP再送を同じテスト期間で比較してください。

各実行前にカウンタをリセットまたは記録し、同じ大容量ファイルを転送して、障害時のみ増加するカウンタを特定します。物理エラー、キューディスカード、パケット見逃し、受信ドロップを最初に記録した機器が次のテストポイントになります。

持続的なラインレートで物理エラーが増加するか確認する

限界的なケーブル、コネクタ、トランシーバ、スイッチポートは軽いトラフィックは通すものの、長時間の書き込み中にCRC、フレーム、キャリア、シンボルエラーを蓄積することがあります。大容量転送は正しくネゴシエートされたケーブルを「過負荷」にはしません。単に弱い物理経路を早期に露呈させるだけです。

実際のファイル転送トラブル事例では、大容量コピー中のインターフェースエラーはファイルサイズ自体ではなく、ケーブル、NIC、ポート、中間機器の問題を示しています。

1回の実行で交換する部品は1つだけにしてください。まずパッチケーブル、次にスイッチポート、可能ならクライアントアダプタやNASポートの順です。エラー増加が特定の部品に連動するか、その交換後に消える場合は物理層の診断が支持されます。

Featured

ZimaCube 2 パーソナルクラウドホームNAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

SMBが処理する前にNAS受信側がフレームをドロップしていないか確認する

ネットワークは電気的に正常でも、受信ホストのNICキュー、ドライバ、割り込み処理、CPU、仮想スイッチが到着レートに対応できずパケットを失うことがあります。特に暗号化、コンテナ、インデックス作成、パリティ処理を行う小型NASで書き込み中に起こりやすいです。

直接接続の高速イーサネット事例では、混雑のないマルチホップネットワークでもホストのパケット処理過負荷が報告されています。重要な違いは、ホストのRXドロップやパケット見逃しカウンタが増加する一方で、ケーブルのCRCカウンタは正常なことです。

不要なNASサービスを停止して書き込みを繰り返し、ディスク書き込みを除いたメモリ間ネットワーク負荷をテストしてください。ストレージI/Oなしで受信ドロップが続く場合は、ファイルシステムではなくNICドライバ、キュー深度、割り込み分配、仮想スイッチ、ホストCPUに注目してください。

遅いまたは共有された送信ポートでのマイクロバーストを探す

高速クライアントが遅いNASポートに送信する場合、複数クライアントが同時に書き込む場合、複数の入力ポートからのトラフィックが1つの送信キューに集中する場合、スイッチ内部でパケットロスが発生することがあります。平均利用率は安全に見えても、短時間のバーストがキュー容量を超えることがあるためです。

ストレージ書き込みの例では、マイクロバーストによるパケットロスが、2つの高速送信元が一時的に宛先ポートの帯域幅とバッファ容量を超える様子を示しています。

1つの送信元を1つのスイッチ経由でテストし、直接接続や同等リンク速度の経路と比較してください。競合送信元、遅いアップリンク、中間スイッチを除去してロスが消える場合は、NASディスクを交換するのではなく送信側のドロップやキュー挙動を調査してください。

障害が局所化した後にEEEやオフロードをテストする

Energy Efficient Ethernet、チェックサムオフロード、大容量送信オフロード、フロー制御、割り込み制御は特定のNICとドライバの組み合わせに影響を与えることがありますが、すべての機能を一度に無効化すると原因特定に必要な証拠が失われます。

Raspberry Piのイーサネット問題では、Energy Efficient Ethernetを無効化することでそのコントローラとリンクパートナーでの深刻なパケットロスが止まった事例があります。これはカウンタや交換がエンドポイントを指し示した後の有効なA/Bテストです。

機能を1つずつ変更し、同じ大容量書き込みを繰り返し、結果が変わらなければ元に戻してください。ドライバ機能の回避策は、アダプタモデル、ドライババージョン、スイッチポート、正確な症状とともに記録し、後のアップデートで検証できるようにしてください。

結果パターンを使って次の修理を選ぶ

最終診断は、小さなトラフィックは正常で持続的な書き込みが失敗する理由を説明すべきです。物理エラーは信号経路の問題を示し、スイッチの送信ドロップはキュー圧力を示し、NASの受信ドロップは受信過負荷を示します。ネットワークカウンタが正常でコピーが停止する場合はストレージやアプリケーションの挙動に原因があります。

ZimaSpaceのパケットロスが有効スループットを低下させる仕組みの説明は、ネゴシエートされたリンク速度がフルスピードのままSMB書き込みが遅くなったり停止したり再送を繰り返す理由を理解するのに役立ちます。

同じ大容量書き込みが安定したレイテンシ、物理エラーゼロ、受信ドロップや送信ドロップの増加なし、宛先チェックサム正常で繰り返し完了するまで問題解決とは宣言しないでください。ネットワークとストレージ経路の区別がつかない場合は設定変更をやめ、ディスクI/Oを除いたテストを再実行してください。