実験環境と安定したサービスを求める開発者向けの2ノードホームラボ構成

1台には堅実で安定したサービスの役割を持たせ、もう1台は実験後に日々の業務を中断せず再構築できるよう、使い捨てにできる構成にしましょう。

マシンが2台あっても、高可用性、共有ストレージ、安全なクォーラムが自動的に実現するわけではありません。現実的な設計は、変更を管理し、アプリケーションの状態を保護する安定ノードと、カーネル、ハイパーバイザー、クラスター、GPU、ネットワークを頻繁に変更できるラボノードを組み合わせた非対称構成です。各サービスを意図的にレプリケーションしない限り、復旧はバックアップに依存します。

安定サービスと実験用サービスの区分を定義する

サービスは技術ではなく、停止した場合の影響で分類しましょう。DNS、パスワード管理、Gitホスティング、コンテナレジストリ、監視、ホームオートメーションは、ほかの人や日々の業務に依存されているなら、安定運用の対象となる場合があります。Kubernetesラボ、新しいストレージドライバー、ナイトリービルド用イメージ、テストデータベース、使い慣れていないファイアウォールは、同じコンテナランタイムを使っていても、実験用にできます。

セルフホストの保守負担が大きすぎることについてのコミュニティでの議論では、運用ルールが明確に示されていました。本番環境と実験環境を分けることです。安定サーバーと実験用サーバーのパターンを採用すれば、夜の実験で翌朝の復旧時間が失われるリスクを減らせます。

すべてのサービスについて、担当者、許容できる停止時間、データの保存場所、復元元、アップデートの時間帯を決めましょう。それらが不明なら、安定ノードで稼働させる準備はできていません。コードと使い捨てのデータから再作成できるサービスは、運用負荷がわかるまでは実験ノードに置きましょう。

各ノードに恒久的な役割を割り当てる

安定ノードでは、慎重にアップデートを適用し、ミラーリングするか、ほかの方法で復旧可能なブート領域とアプリケーションデータの構成を採用し、予測しやすいDNSを設定し、通常のピーク時にも耐えられるだけのメモリを確保しましょう。常時稼働しているというだけで、あらゆるUSBデバイスやパススルー実験の受け入れ先にしてはいけません。

実験ノードでは、ネストされた仮想化、別のディストリビューション、ビルドランナー、一時的なデータベース、GPUやUSBのパススルー、クラスターエージェントを稼働できます。インフラ設定ファイル、スクリプト、または文書化した手順を使って、プロビジョニングを再現可能にしておきましょう。再構築は危機的な事態ではなく、計画的な作業であるべきです。

ホームラボの詳細な計画例でも、安定稼働のワークロードを一方のホストに、壊れる可能性のある作業をもう一方に分けています。このストレージ、コンピュート、実験用ホストの分離は、再インストールされる可能性が最も高いノードだけに監視やネットワークのセグメンテーションを担わせず、システム全体に行き渡らせるべき理由も示しています。

ネットワーク、ID管理、更新経路を分離する

固定の管理用アドレス、ローカルDNS名、管理ネットワーク、または対象を厳密に限定したファイアウォールルールを使用してください。実験用ノードからパッケージミラー、レジストリ、テストネットワークへの接続を開始してもかまいませんが、安定稼働しているアプリケーションデータへの無制限の書き込みアクセスは許可しないでください。ラボ用ブリッジ、オーバーレイ、VPNの構成が壊れても、管理アクセスを確保できるようにしてください。

実験用ノードを、安定ノード唯一のルーター、DNSサーバー、バックアップコントローラー、またはシークレットストアにしないでください。それでは意図した依存関係が逆転してしまいます。監視機能は安定ノード上で共有してもかまいませんが、その構成をエクスポートし、どちらかのマシンが故障しても到達できる場所にアラートを送信してください。

Featured

ZimaBoard 2 - 大きなアイデアを実現するミニホームサーバー

Single board computer zimaboard2

$339.00 - $529.00

Buy Now

共有障害を招かずに状態をバックアップする

安定稼働しているサービスの構成とデータベースは、どちらのノードを消去しても影響を受けないストレージにバックアップします。同じホスト上のVMのスナップショットはロールバックに役立ちますが、ホストの障害に備えるバックアップにはなりません。安定ノードを信頼できると判断する前に、ファイルとデータベースをそれぞれ少なくとも1回復元してテストしてください。

実験用ノードでは、ソースコード、インフラストラクチャの定義、ライセンスファイル、再作成にコストがかかるテストデータセットを保護します。破棄可能なVM全体をデフォルトでバックアップするのは避けましょう。再現可能なイメージと復元スクリプトを用意すると、保護する範囲が明確になり、保持データの増加も抑えられます。

2ノードを自動的にクラスターと呼ぶべきではありません。ZimaSpaceの大型サーバー1台と小型ノード複数台の比較では、複数台の機器で可用性を実現する前に、クォーラム、データの移動性、独立した障害経路が重要である理由を解説しています。

障害の封じ込めと拡張の判断基準を検証する

実験用ノードをシャットダウンし、安定したDNS、認証、リポジトリ、ダッシュボード、バックアップが引き続き機能することを確認します。次に安定稼働ノードを隔離し、そこにある未記録のファイルを参照せずにラボを管理または再構築できることを確認します。最後に、安定稼働サービスの1つを余剰リソースまたは一時的なVMに復元し、復旧手順を実証します。

実験用ノードを破棄しても、明示された依存関係を除いてデータ損失や日常サービスの停止が起きず、安定稼働ノードのパッチ適用時にもラボのネットワークを解体する必要がないなら、この設計は合格です。共有スイッチ、UPS、NAS、インターネットへの依存関係を正確に記録してください。同じ電源タップにつないだサーバーが2台あっても、電源障害の影響範囲が2つになるわけではありません。

クォーラム、ローリングメンテナンス、またはテスト済みのフェイルオーバーを必要とするワークロードが明確になった場合にのみ、3台目のノードを追加します。データの増加量または復元時間がいずれかのホストの役割に見合わなくなった場合に、専用ストレージを追加します。それまでは、非対称な2ノード構成を維持します。安定稼働サービスの変更は慎重に行い、実験環境は簡単に破棄できる状態にし、復旧は機器の台数ではなくバックアップで実現します。

最終構成のルール

この2台は小規模な高可用性クラスターではなく、2つの運用ゾーンとして扱います。安定稼働ゾーンでは保護された状態と管理された変更を担い、実験ゾーンでは破棄可能なコンピューティングリソースを担います。複雑さを加えるのは、テスト済みの復旧要件または可用性要件で必要になった場合だけにします。