実験と安定したサービス運用を両立したい開発者のための2ノードホームラボ構成

エヴァ・ウォン

IceWhale author

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

A Two-Node Homelab Setup for Developers Who Want Experiments and Stable Services - Zima Store Online

1台のノードには退屈でも安定したサービスの役割を担わせ、もう1台は実験後に日常業務を中断せず再構築できるほど使い捨て可能にします。

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

安定サービスと実験サービスのクラスを定義する

サービスを技術ではなく影響度で分類します。DNS、パスワード管理、Gitホスティング、コンテナーレジストリ、監視、ホームオートメーションは、他の人や日常のワークフローが依存しているなら安定サービスにできます。同じコンテナーランタイムを使っていても、Kubernetesラボ、新しいストレージドライバー、ナイトリービルド用イメージ、テストデータベース、使い慣れていないファイアウォールは実験サービスになり得ます。

過剰なセルフホスティング保守についてのコミュニティでの議論では、運用上のルールが明確に示されています。本番と遊びを分けることです。安定サーバーと試行錯誤用サーバーのパターンにより、夜の実験が翌朝の復旧時間を奪う可能性を減らせます。

各サービスについて、担当者、許容できる停止時間、データの場所、復元元、更新時間帯を決めます。それらが不明なら、安定ノードに載せる準備ができていません。コードと使い捨てデータから再作成できるものは、運用負担を把握するまで実験ノードに置きます。

各ノードに固定の役割を割り当てる

安定ノードでは、保守的な更新、ミラーリングまたは別の方法で復旧可能なブートおよびアプリケーションデータの構成、予測可能なDNS、通常のピークに耐えられる十分な余剰メモリを使用します。常時稼働しているからといって、あらゆるUSBデバイスやパススルー実験の受け皿にしてはいけません。

実験ノードでは、ネストされた仮想化、別ディストリビューション、ビルドランナー、一時データベース、GPUまたはUSBパススルー、クラスターエージェントを動かせます。インフラストラクチャーファイル、スクリプト、文書化された手順によって、プロビジョニングを再現可能に保ちます。再構築は危機対応ではなく、計画された作業であるべきです。

詳細なホームラボ計画の例でも、安定したワークロードを一方のホストに、壊してもよい作業をもう一方に置いています。このストレージ、コンピュート、実験用ホストの分離からは、監視とネットワーク分離を、再インストールされる可能性が最も高いノードだけでなくシステム全体にまたがって構成すべき理由も分かります。

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

固定の管理アドレス、ローカルDNS名、管理ネットワーク、または厳格に範囲を限定したファイアウォールルールを使用します。実験ノードからパッケージミラー、レジストリ、テストネットワークへの接続は開始できても、安定したアプリケーション状態への無制限の書き込みアクセスは与えないでください。ラボブリッジ、オーバーレイ、VPN構成が壊れても、管理アクセスは利用できる状態にします。

コントロールプレーン	安定ノード	実験ノード	境界
更新	スケジュール化され、元に戻せる	頻繁に更新し、再構築可能	両方の再起動を決して連動させない
ID	主要な秘密情報とサービスアカウント	短期間だけ有効なテスト認証情報	管理者トークンをコピーしない
ストレージ	所有するアプリケーション状態	一時用および交換可能なデータセット	バックアップはデフォルトで書き込み可能な状態でマウントしない
ネットワーク	制限されたサービスVLANと固定DNS	ラボVLAN、オーバーレイ、パススルーのテスト	管理経路を独立させる
デプロイ	固定バージョンと変更履歴	ブランチ、ナイトリーイメージ、一時的なクラスター	昇格は明示的に行う

実験ノードを、安定ノードにとって唯一のルーター、DNSサーバー、バックアップコントローラー、秘密情報ストアにしないでください。それでは意図した依存関係が逆転します。共有オブザーバビリティは安定ノードに置いても構いませんが、その構成をエクスポートし、どちらか一方のマシンが故障しても到達できる場所にアラートを送信します。

-15% OFF

ZimaBoard 2 - あなたの大きなアイデアのためのミニホームサーバー

Single board computer zimaboard2

共有障害を生じさせずに状態をバックアップする

安定サービスの構成とデータベースを、どちらのノードとともに消去されることもないストレージにバックアップします。同じホスト上のVMのスナップショットはロールバックには便利ですが、ホスト喪失に対するバックアップではありません。安定ノードを信頼できるものと判断する前に、少なくとも1回のファイル復元と1回のデータベース復元をテストします。

実験ノードでは、ソースコード、インフラストラクチャー定義、ライセンスファイル、再作成にコストがかかるテストデータセットを保護します。使い捨て可能なVM全体をデフォルトでバックアップするのは避けてください。再現可能なイメージと復元スクリプトによって境界が明確になり、保持容量の増加も抑えられます。

また、2台のノードを自動的なクラスターと説明してはいけません。ZimaSpaceによる1台の大規模サーバーと複数の小規模ノードの比較の分析では、複数の筐体によって可用性が実現する前に、クォーラム、データの移動性、独立した障害経路が重要である理由が説明されています。

障害の封じ込めと拡張のきっかけを検証する

実験ノードを停止し、安定したDNS、認証、リポジトリ、ダッシュボード、バックアップが引き続き機能することを確認します。次に安定ノードを隔離し、そこにある文書化されていないファイルを読み取らなくても、ラボを管理または再構築できることを確認します。最後に、余剰容量または一時VMに安定サービスを1つ復元し、復旧手順が実証されていることを確認します。

実験ノードを破棄しても、明示された依存関係を除きデータ損失や日常サービスの停止が発生せず、安定ノードへのパッチ適用でもラボネットワークの解体が必要なければ、この設計は合格です。共有スイッチ、UPS、NAS、インターネットの依存関係は正直に記録してください。1本の電源タップに2台のサーバーを接続しても、2つの電源障害ドメインにはなりません。

クォーラム、ローリングメンテナンス、またはテスト済みのフェイルオーバーを必要とする名前付きワークロードがある場合にのみ、3台目のノードを追加します。データの増加や復元時間がどちらかのホストの役割を超えたら、専用ストレージを追加します。それまでは非対称な2ノードモデルを維持します。安定サービスの変更はゆっくり行い、実験は簡単に破棄でき、復旧を支えるのは筐体の台数ではなくバックアップです。