ミニPC NASにおけるストレージOSとハイパーバイザー：ディスクを管理すべきレイヤーはどちらか？

エヴァ・ウォン

IceWhale author

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

Storage OS vs Hypervisor on a Mini PC NAS: Which Layer Should Own the Disks? - Zima Store Online

信頼性の高いストレージ運用がMini PCの主な用途である場合は、ベアメタルにストレージOSをインストールしてください。実際のVM境界によって追加の障害および復旧レイヤーが正当化される場合に限り、先にハイパーバイザーを配置します。

重要なのは、どちらの構成でも動作するかどうかではありません。物理ディスクを認識し、ディスクの状態を報告し、プールを制御し、ブートデバイスやマザーボードが故障した後に復旧できるのがどのレイヤーかという点です。小型NASでは、1つのSATAコントローラーやUSBブリッジが複数のデバイスに接続されている場合があるため、答えは図ではなく実際のハードウェア経路によって決まります。

ディスクの所有権を1つのレイヤーに明確に与える

ベアメタルのストレージOSは、ドライブ、シリアル番号、エラーカウンター、温度、プールのメンバーを直接認識します。そのため、ファイルシステムと、それを裏付けるハードウェア情報の両方を同じレイヤーが管理することになり、アラートやディスク交換の判断が容易になります。

ハイパーバイザーを先に配置する構成でも、HBA全体またはSATAコントローラーをストレージVMにパススルーすれば、その可視性を維持できます。一方、仮想ディスクを提示すると、状態データが隠れたり変換されたりする可能性があり、ゲストのプールを起動する前にホストのストレージ構成へ依存することになります。

データを作成する前に、所有者を決めてください。ホストとゲストの両方が同じ物理デバイスをパーティション分割、マウント、キャッシュ、監視できる状態なら、パフォーマンスにかかわらず、その設計は最初の条件を満たしていません。

Mini PCがデバイスをクリーンにパススルーできるか確認する

内部SATA、NVMeスロット、USB-SATAブリッジ、PCIeアダプターなど、すべてのディスク経路を一覧にします。次に、どのデバイスがハイパーバイザーのブートドライブ、ネットワークインターフェース、またはホストが保持する必要のある別のデバイスと、同じコントローラーやIOMMUグループを共有しているかを確認します。

ホストと共有されているオンボードSATAコントローラーに関するコミュニティの事例は、実際に起こり得る落とし穴を示しています。そのコントローラーをストレージゲストに割り当てると、ハイパーバイザー自身のディスク経路も失われる可能性があります。個々の仮想ディスクをパススルーすればクラッシュは回避できましたが、物理ドライブのテレメトリーは減少しました。

ハイパーバイザー構成を採用できるのは、ストレージゲストがコントローラー全体、または明示的にサポートされた別の安定したデバイス経路を受け取り、ホストが独立したブートデバイスと管理デバイスを維持できる場合に限ります。その分離が不可能なら、ベアメタルでストレージを所有する方がすっきりした結果になります。

仮想化が解決する具体的な問題を決める

ハイパーバイザーを使うと、Windowsゲスト、ラボネットワーク、独自のカーネルを必要とするアプリケーションを分離できます。また、ゲスト単位のスナップショットや再構築も便利になります。ワークロードが実際に存在し、保守や信頼境界が異なる場合には、こうしたメリットが重要です。

しかし、ストレージサービス1つと少数のコンテナだけを運用する計画なら、その重要性は低くなります。その場合、ホスト、ストレージVM、仮想ネットワーク、ゲストの起動順序を追加しても、ファイル共有に必要なコンポーネントが増えるだけで、役立つ新たな境界が生まれない可能性があります。

想定しているゲストワークロードを稼働させた状態で、最も負荷の高いファイル転送を使って試験運用を行います。CPU競合、メモリ不足、またはゲストの再起動によって、ベアメタル構成なら避けられる形でストレージが中断される場合は、ハイパーバイザー構成を不採用にしてください。

Featured

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

ZimaCube2

機能を比較する前に復旧経路を比較する

HBAと既存のTrueNASプールに関する別のパススルー事例は、起動順序とファームウェアの挙動を復旧計画に含める必要性を示しています。プール自体は無傷でも、仮想マシンが予期しない起動経路に従う場合があります。

重要でないディスクを使って、構成の復元とプールのインポートの両方をテストしてください。失敗した同じホストに依存していたり、デバイスマッピングを再現できなかったりする場合、ハイパーバイザーのスナップショットだけでは不十分です。交換用ハードウェアでプールをインポートした経験がない場合、ストレージOSの構成エクスポートだけでも不十分です。

復旧イベント	ストレージOSがディスクを管理	ハイパーバイザーがプラットフォームを管理
ブートデバイスの故障	再インストールし、プールをインポートして、構成を復元	ホストを再構築し、VM定義を復元してから、ストレージをインポートまたは接続
コントローラーの故障	ディスクを互換性のある経路へ移動してインポート	ゲストがディスクを認識する前に、互換性のあるパススルー経路へ交換
ストレージゲストの故障	該当なし	物理プールの所有権を変更せずにゲストを復元
ホスト更新の失敗	ストレージOSをロールバックまたは再インストール	ストレージとすべてのゲストがホストの復旧を待つ可能性がある
ハードウェア移行	サポート対象のストレージホストでプールをインポート	最初にパススルーとゲストの依存関係を再構築

主な障害ドメインに合ったレイヤーを選ぶ

ファイルサービスが主な役割であり、ディスクの状態を直接確認できることや、簡単なプールインポートが重要である場合、またはMini PCでコントローラーをきれいに分離できない場合は、ベアメタルでストレージOSを管理してください。そのストレージホストと障害を連動させてもよいアプリケーションだけを実行します。

複数の独立したゲストを運用する明確な理由があり、ホストとデータデバイスの経路が分離され、パススルー、起動順序、ホスト更新、復旧をすでにテスト済みである場合は、ハイパーバイザーを先に配置してください。より広いソフトウェアの役割については、NAS OSと汎用Linuxの選択が次に検討すべき境界になります。

ハードウェアによって1つのコントローラーがホストとデータディスクの両方に割り当てられているなら、機能一覧の比較をやめてください。Mini PC NASでは、利便性やダッシュボードの品質を検討する前に、物理トポロジーがソフトウェアアーキテクチャを決めることがあります。