なぜ共有ストレージキューは複数のホームサーバーVMの速度を遅くするのか?

エヴァ・ウォンテクニカルライター であり ZimaSpaceの常駐ティンカーでもあります。 生涯のオタクであり、 ホームラボとオープンソースソフトウェアに情熱を持っています。彼女は複雑な技術的概念をわかりやすく、 実践的なガイドに翻訳することを専門としています。エヴァはセルフホスティングは楽しくあるべきで、怖がるものではないと信じています。彼女のチュートリアルを通じて、コミュニティが ハードウェアのセットアップを解明する手助けをしています。初めてのNAS構築からDockerコンテナの習得まで。

共有ストレージキューは複数のホームサーバーVMを遅くします。なぜなら、独立した仮想ディスクが最終的に同じホストアダプタ、コントローラ、ネットワーク経路、物理ドライブにリクエストを送るからです。各VMは独自の仮想キューを持っていても、より下位の共有層で他のVMが生成した作業の後ろで待機していることがあります。

したがって、遅延は1つのVMのIOPSだけで決まるわけではありません。リクエストサイズ、読み書きの比率、同期動作、キューの深さ、ストレージメディア、隣接するすべてのVMのバーストタイミングが1つの物理的なサービス順序と有限のレイテンシ予算に組み合わさります。

別々のVMキューはどこで共有されるのか?

各ゲストは仮想コントローラを通じてI/Oを送信しますが、VMのリクエストはゲストの境界下の共有物理リソースで収束します。ハイパーバイザー、ホストファイルシステム、ストレージアダプタ、バックアップデバイスが複数の仮想ディスクからの作業を統合します。

VMは内部キューが短いと報告しても、そのリクエストはゲストが見えないホストやデバイスのキューで待機していることがあります。これが、ゲストのディスク使用率だけでは長いアプリケーションレイテンシを説明できない理由です。

完全な経路が重要です:ゲストスケジューラ、仮想コントローラ、ホストキュー、ネットワークストレージプロトコル、RAIDコントローラ、物理メディアのそれぞれが待機を追加する可能性があります。最も狭く飽和した層が共有の制限となります。

1つのVMがストレージの騒がしい隣人になるのはどういう場合か?

共有インフラストラクチャでは、1つのワークロードがストレージキューを独占し、他の静かなワークロードのレイテンシを上げることがあります。バックアップ、データベースの圧縮、更新、大きなファイルのスキャンがバーストを引き起こすことがあります。

騒がしいVMは、仮想ディスクサイズやCPU割り当てを超える必要はありません。ストレージがリクエストを完了するよりも速く、共有サービス経路を占有するのに十分な未完了のI/Oを発行するだけでよいのです。

隣接するVMは、平均スループットの要求が小さくても、テールレイテンシが高くなります。DNSサーバー、ホームオートメーションのデータベース、認証サービスは、メディアVMがスキャンや大量の書き込みを行っているために遅く感じることがあります。

キューの深さはいつ待機状態に変わるのか?

ある程度の未処理I/Oは有用であり、能力のあるストレージを稼働させますが、深いキューはストレージのボトルネックを示します。デバイスの有用な並列性を超えると、追加のリクエストは完了した作業の割合を増やす代わりに滞留時間を増加させます。

キュー深度は一つのレイヤーでのカウントであり、VMの普遍的な特性ではありません。ゲストの深度が8、ホストアダプターの深度が数百、NVMeのハードウェアキューは異なる場所で異なる制限を持ちます。

キュー深度は飽和後にレイテンシを上げます。スループットは高いままでも、インタラクティブなVMリクエストは同じ持続的なストリームの後ろでより長く待つことがあります。

なぜキューアーキテクチャがVMのスケーリングを変えるのか?

レガシーパスは多くの操作をより少ないコマンドレーンに強制するかもしれませんが、シングルキューのストレージはより多くの作業を直列化します。複数のVMはリクエストが同時に到着するため、そのアーキテクチャの違いを増幅します。

並列キューはロック競合を減らし、異なるCPUコアがより少ない直列化で作業を送信・完了できるようにします。これにより無制限のストレージ性能が生まれるわけではなく、コントローラー、ネットワーク、NAND、またはディスクが物理的な上限を課します。

したがって、プロトコルとドライバパスはシステムが飽和に達する際の挙動に影響します。より並列なパスはスループットを維持しCPU負荷を低減できますが、古いパスはより早く一つの支配的なキューを形成するかもしれません。

なぜHDDとNVMeは異なる反応を示すのか?

フラッシュとNVMeはNVMeがより多くの並列コマンドをサポートできる一方で、HDDのアクチュエーターは依然として主に機械的な動きで物理的な位置をサービスします。

複数のVMは、個別の連続的なワークロードをランダムな物理パターンに変えることができます。HDDでは、インターリーブされたリクエストがシークと回転遅延を増加させますが、SSDでは同じ並行性が内部コントローラーやNANDが飽和するまで利用率を向上させる場合があります。

高速メディアはサービス時間を短縮しますが、キューイングをなくすわけではありません。同期書き込み、ガベージコレクション、RAID作業、ネットワーク遅延、いくつかの大きなリクエストは依然として小さなレイテンシに敏感な操作を遅延させる可能性があります。

QoSとワークロード分離はどのように干渉を減らしますか?

最も強力な制御は、1つのVMが作成できる共有作業量を制限することです。ワークロードの分離はレイテンシに敏感なサービスに別のリソース境界を与え、テナント間の競合を防ぎます

ホームサーバーでは、VMごとのIOPS制限、優先度、別々の仮想ディスク、データベース用の専用SSDプール、インタラクティブ時間外のバックアップやスキャンのスケジューリングなどを意味します。

ホストレベルの遅延とキュー占有率をVMごとのメトリクスと共に測定します。公平性制御は忙しいVMのピークスループットを減らすことがありますが、1つのバッチワークロードがすべてのサービスの応答時間予算を消費するのを防ぎます。

共有レイヤー 複数のVMが競合するもの 典型的な症状
ハイパーバイザースケジューラー サブミッションスロットと仮想コントローラーの処理 ゲストは一貫しない完了時間を認識する
ホストアダプターまたはネットワーク経路 コマンドキューと転送帯域 複数のVMが一緒に遅くなる
RAIDまたはストレージコントローラー キャッシュ、パリティ作業、デバイスのディスパッチ 書き込みバーストが読み取り遅延を増加させる
物理メディア 機械的なサービス時間またはフラッシュの並列性 飽和後にテールレイテンシが上昇する

よくある質問

各VMは独自のストレージキューを持っていますか?

仮想キューは持てますが、それらのキューは最終的に共有ホスト、アダプター、コントローラー、物理デバイスのキューに統合されます。

1つのバックアップVMが無関係なデータベースVMを遅くすることはありますか?

はい。継続的なバックアップは共有キューを満たし、ディスク帯域を消費して、CPUやメモリが利用可能でもデータベースVMの遅延を増加させる可能性があります。

キュー深度が高いことは常に悪いことですか?

いいえ。ある程度の深さは並列性を引き出しスループットを向上させますが、未処理の作業が有効な並列容量を超え、リクエストが主に長時間待機する場合は有害になります。

NVMeはノイジーネイバーのストレージ問題を解消しますか?

いいえ。NVMeはより多くの並列キューと低いサービス時間を提供しますが、有限のNAND、コントローラー、CPU、RAID、ネットワークリソースは依然として飽和する可能性があります。

最終的な結論

複数のホームサーバーVMは、独立した仮想ディスクが見えても独立した物理ディスクを所有しているわけではありません。リクエストは共有キューに統合され、バーストや混合アクセスパターン、限られたデバイスの並列性によりノイジーネイバー遅延が発生します。キュー認識の監視、VMごとの制限、スケジューリング、別々のストレージ層により、共有容量を有効活用しつつ、1つのVMがすべてのアプリケーションの応答時間を支配することを防ぎます。

テック&AIハブ

もっと読む

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.