ミニPC NASではストレージOSとハイパーバイザーのどちらがディスクを管理すべき?

Eva Wong は テクニカルライター であり、 生粋の技術好き としてZimaSpaceで活動しています。ホームラボやオープンソースソフトウェア をこよなく愛する生粋のギークで、複雑な技術概念をわかりやすく、実践的なガイド にまとめることを得意としています。Evaは、セルフホスティングは難しいものではなく、楽しむものだと考えています。チュートリアルを通じて、初めてのNAS構築からDockerコンテナの使いこなしまで、コミュニティがハードウェアのセットアップをわかりやすく理解できるよう 支援しています。、初めてのNAS構築からDockerコンテナの習得まで。

安定したストレージ運用がミニPCの主な用途なら、ストレージOSをベアメタルにインストールします。実際のVM分離が、障害や復旧のレイヤーが増えることを正当化できる場合に限り、ハイパーバイザーを先に起動します。

重要なのは、どちらの設計でも動作するかどうかではありません。どのレイヤーが物理ディスクを認識し、状態を報告し、プールを管理し、起動デバイスやマザーボードの故障後に復旧できるかです。コンパクトなNASでは、1つのSATAコントローラーやUSBブリッジが複数のデバイスにつながっていることがあります。そのため、判断は構成図ではなく、実際のハードウェアパスに基づいて行う必要があります。

ディスクの管理主体を一つのレイヤーに明確に定める

ベアメタルのストレージOSは、ドライブ、シリアル番号、エラーカウンター、温度、プールのメンバーを直接認識します。ファイルシステムと、その背後にあるハードウェアの状態を同じレイヤーが管理するため、アラートへの対応やディスク交換の判断がしやすくなります。

ハイパーバイザーを先に起動する設計でも、HBAまたはSATAコントローラー全体をストレージVMにパススルーすれば、ドライブの可視性を確保できます。代わりに仮想ディスクを提示すると、ヘルスデータが隠されたり変換されたりする可能性があります。また、ゲストのプールを起動する前に、ホスト側のストレージ構成が必要になるという依存関係も生じます。

データを作成する前に、管理主体を決めます。ホストとゲストの両方が同じ物理デバイスのパーティション作成、マウント、キャッシュ、監視を行える設計なら、パフォーマンスに関係なく、最初の関門で失敗です。

ミニPCでデバイスを適切にパススルーできるか確認する

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

ホストと共有されたオンボードSATAコントローラーに関するコミュニティの事例から、実際に起こりうる落とし穴がわかります。そのコントローラーをストレージゲストに割り当てると、ハイパーバイザー自身のディスクパスも使えなくなることがあります。個々の仮想ディスクをパススルーすればクラッシュは避けられましたが、物理ドライブのテレメトリーが減少しました。

ストレージゲストに、ホストが独立した起動用デバイスと管理用デバイスを維持したまま、コントローラー全体、または明示的にサポートされた別のデバイスパスを確実に割り当てられる場合に限り、ハイパーバイザーを使う構成が適しています。この分離が不可能なら、ベアメタルでストレージを管理するほうがすっきりします。

仮想化で解決できる具体的な問題があるか判断する

ハイパーバイザーを使えば、Windowsのゲスト、ラボ用ネットワーク、独自のカーネルを必要とするアプリケーションを分離できます。また、ゲスト単位でスナップショットを作成したり、再構築したりするのも簡単になります。実際のワークロードがあり、メンテナンスや信頼の境界が異なる場合、こうしたメリットが役立ちます。

ストレージサービスが1つとコンテナが数個という構成では、重要性は低くなります。その場合、ホスト、ストレージVM、仮想ネットワーク、ゲストの起動順序を追加しても、新たな有用な境界を作らずに、同じファイル共有に必要なコンポーネントが増えるだけかもしれません。

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

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

HBAと既存のTrueNASプールを使う別のパススルー事例は、起動順序とファームウェアの動作を復旧計画に含めるべき理由を示しています。プール自体は無事でも、仮想マシンが予期しない起動経路をたどることがあります。

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

復旧イベント ストレージOSがディスクを管理 ハイパーバイザーがプラットフォームを管理
起動デバイスの障害 再インストールしてプールをインポートし、設定を復元する ホストを再構築し、VM定義を復元してから、ストレージをインポートまたは接続する
コントローラーの障害 ディスクを互換性のある経路に移して、インポートする ゲストがディスクを認識する前に、互換性のあるパススルー経路に置き換える
ストレージゲストの障害 該当なし 物理的なプールの所有者を変更せずにゲストを復元する
ホストの更新に失敗 ストレージOSのロールバックまたは再インストール ホストの復旧が終わるまで、ストレージとすべてのゲストが停止する可能性がある
ハードウェアの移行 対応するストレージホストでプールをインポートする まずパススルーとゲストの依存関係を再構築する

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

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

複数の独立したゲストを想定でき、ホスト用とデータ用デバイスの経路が分かれていて、パススルー、起動順序、ホストの更新、復旧をすでにテスト済みなら、まずハイパーバイザーを選びましょう。より広いソフトウェアの役割分担については、NAS OSと汎用Linuxの選択を次の判断基準として検討してください。

ハードウェアがホスト用ディスクとデータ用ディスクの両方に同じコントローラーを割り当てるなら、機能一覧の比較はやめましょう。Mini PC NASでは、使いやすさやダッシュボードの品質を検討する前に、物理トポロジーによってソフトウェア構成が決まることがあります。

製品比較

続きを読む

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.