新しいホームサーバーには、ハイパーバイザー優先とコンテナ優先のどちらが適している？

初年度の計画が信頼できるLinuxアプリケーションスタック1つなら、コンテナ優先で始めましょう。計画にすでに別々のオペレーティングシステム、頻繁に変更するラボ環境、またはゲスト全体で分離する必要がある信頼境界が含まれるなら、ハイパーバイザー優先で始めましょう。

これはサーバーの管理プレーンをどうするかという選択であり、コンテナと仮想マシンが共存できるかどうかの話ではありません。ハイパーバイザー優先のホストはVM内でDockerを実行できますし、コンテナ優先のLinuxホストにも後からKVMを追加できます。適切なデフォルトは、現在具体的に挙げられるワークロードに対して、バックアップと障害の単位が一致するレイヤーです。

管理プレーンを選ぶ前にワークロードを洗い出す

予定している各サービスについて、必要なオペレーティングシステム、データの保存場所、ハードウェアへのアクセス、外部への公開範囲、許容できる再起動の範囲を書き出してください。WindowsまたはBSDのゲスト、実験的なカーネル、信頼できないコード、侵害されてもアプリケーションホストと共有すべきでない公開サービスがあれば、印を付けてください。

リストのほとんどが、1つのLinuxカーネル上で保守されているDockerイメージなら、コンテナでパッケージ化、ネットワーク、再起動ポリシー、リソース制御をすでに実現できます。複数のオペレーティングシステムや頻繁に変更するラボ環境が含まれるなら、ハイパーバイザーのほうがライフサイクルの境界として自然です。

アイデアをワークロードとして数えないでください。VMの管理プレーンに伴うメモリ、ストレージ、保守のコストを負担する前に、コンテナでは適切に対応できない実際の用途が少なくとも1つあることを確認してください。

実際に運用する単位で分離を比較する

コンテナはホストカーネルを共有し、アプリケーションを依存関係とともにパッケージ化します。仮想マシンにはゲストカーネルが含まれ、ハードウェアをエミュレートするか割り当てます。コンテナとVMの境界に関する技術的な比較では、コンテナのオーバーヘッドの低さとゲストの分離の強さが、異なるアーキテクチャから生じるものであり、普遍的な品質評価ではない理由を説明しています。

サービスが1つのパッチ適用済みLinuxホストを共有でき、Composeファイルなどの宣言的な定義から再作成できるなら、コンテナ優先が効率的です。あるゲストを、すべてのサービスを同じオペレーティングシステムのインスタンスの一部として扱わずに再構築、ファイアウォール設定、ロールバックできるなら、ハイパーバイザー優先のほうが明確です。

別のカーネルが必要なサービスや、ホストカーネルの共有を信頼モデル上認められないサービスがある場合は、コンテナ優先ではなくなります。すべてのゲストが、同じ信頼済みコンテナを起動するだけの同一のLinux環境を含む場合は、ハイパーバイザー優先ではなくなります。

バックアップと再構築の単位を選ぶ

コンテナ優先の再構築が速いのは、定義、シークレット、バージョン、永続ボリュームを分離してバックアップしている場合に限られます。ハイパーバイザー優先の復元が速いのは、ゲストのバックアップが障害の発生したホストに依存せず、ホストのネットワーク設定やデバイスマッピングが文書化されている場合に限られます。

予備のVMまたは交換用メディアで、破壊を伴う復旧テストを1回行いましょう。必要な入力をすべて洗い出して復元できる方式を選びます。ダッシュボードやスナップショットのボタンがあっても、ホスト外のコピーがなければ補えません。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

ハードウェアとネットワークの依存関係から、隠れた作業を洗い出す

コンテナ優先のホストでもGPU、USB、HBA、特殊なNICに直接アクセスできますが、特権コンテナや広範なデバイスマッピングは、アプリケーションの境界を弱めます。ハイパーバイザーならゲストにデバイスを割り当てられますが、IOMMUグループ、リセット時の動作、ホスト側のドライバー管理によって、その方法が不安定になる場合があります。

ネットワークも同様です。信頼できるアプリケーションゾーンが1つなら、コンテナブリッジでシンプルに構成できます。ゲスト用ブリッジとファイアウォールを複数用意すれば、ラボ、公開用、インフラ用のゾーンを明確にできますが、復旧時にも維持しなければならないインターフェースやルーティング設定が増えます。

参加者の多い、ProxmoxではなくDebianとDockerを選ぶことについての議論から、実用上の分かれ目がわかります。VMが本当に必要ならハイパーバイザーは有用ですが、サーバーでコンテナしか動かさない場合は、余計な仕組みに感じられることがあります。

まずはシンプルに始め、移行のきっかけを明確にする

計画しているサービスがすべて単一の信頼できるLinuxカーネル上で動作し、メモリに余裕がなく、アプリケーションデータとデプロイファイルをテスト済みの復旧単位として扱える場合は、コンテナ優先を選びましょう。後から仮想化を追加または移行できるよう、ベースホストは最小限に保ちます。

初年度の計画で、カーネル、信頼ゾーン、ロールバックのスケジュール、またはハードウェア割り当てが異なるゲストを2つ以上挙げている場合は、ハイパーバイザー優先を選びましょう。ホームサーバーOS選定ガイドを参考に、サービス一覧で実際に必要となるホスト機能を確認できます。

互換性のないOS、リスクの高い公開ワークロード、再現可能なラボ環境、またはゲスト全体の復旧要件が生じたときに、選択を見直しましょう。流行しているというだけで移行せず、具体的な境界条件が変わったときに移行してください。