新しいホームサーバーではハイパーバイザー優先かコンテナ優先か

初年度の計画が、信頼できる1つのLinuxアプリケーションスタックで構成されるならコンテナファーストから始め、計画に複数のオペレーティングシステム、頻繁に変化するラボ環境、またはゲスト全体に適用する必要がある信頼境界がすでに含まれているならハイパーバイザーファーストから始めましょう。

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

コントロールプレーンを選ぶ前にワークロードを洗い出す

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

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

アイデアをワークロードとして数えてはいけません。VMのコントロールプレーンに必要なメモリ、ストレージ、保守コストを負担する前に、コンテナではきれいに満たせない現在の作業が少なくとも1つあることを確認してください。

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

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

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

サービスに別のカーネルが必要な場合、またはホストカーネルの共有を信頼モデルが受け入れない場合は、コンテナから離れる判断になります。逆に、すべてのゲストが同一の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が実際の要件である場合、ハイパーバイザーには価値がありますが、サーバーがコンテナだけを実行する場合は、余分な仕組みのように感じられることがあります。

シンプルに始めつつ、移行のきっかけを定義する

計画しているすべてのサービスが1つの信頼できるLinuxカーネルに収まり、メモリが限られており、アプリケーションデータとデプロイファイルがテスト済みの復旧単位を形成しているなら、コンテナファーストを選びましょう。後から仮想化を追加または移行できるよう、ベースホストは最小構成に保ちます。

初年度の計画に、異なるカーネル、信頼ゾーン、ロールバック予定、またはハードウェア割り当てを持つ2つ以上のゲストが含まれるなら、ハイパーバイザーファーストを選びましょう。ホームサーバーOSの選択ガイドを使えば、サービス一覧が実際に必要とするホスト機能を確認できます。

互換性のないオペレーティングシステム、リスクの高い公開ワークロード、再現可能なラボ環境、またはゲスト全体の復旧要件が現れたら、選択を見直してください。どちらかが流行しているという理由だけで移行するのではなく、名前を付けられる境界が変わったときに移行しましょう。