Home Assistantの障害ドメイン:依存関係が停止に与える影響

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

Home Assistantの停止範囲は、一見別々に見える機能が、電源、ホスト、ストレージ、ネットワーク、認証、ゲートウェイのいずれかの共通依存関係を共有し、それが障害を起こしたときに拡大します。

ダッシュボード、自動化エンジン、データベース、ブローカー、無線コーディネーター、DNSリゾルバー、モバイルクライアントは、それぞれ独立したコンポーネントとして動作していても、共通のホストや経路が失われると一緒に停止することがあります。障害ドメイン分析では、家庭内で起きる各結果を依存関係に沿って追跡し、相関した損失を特定して、復旧の順序を定めます。冗長化は、代替経路が同じ隠れた原因を共有していない場合にのみ効果を発揮します。

コンテナではなく、家庭内の結果から始める

照明のローカル制御、暖房の安全性、アラームの可視性、リモートアクセス、履歴の保持などの結果を定義します。各結果について、センサーまたはクライアントからネットワーク、Home Assistant、インテグレーション、ブローカー、データベース、アクチュエーターまで、必要なコンポーネントを追跡します。稼働中のコンテナでも、家庭内の結果が障害のあるゲートウェイに依存しているなら意味はありません。

高可用性について議論すると、プロセスを稼働させ続けることと、自動化経路を利用可能な状態に保つことの違いが繰り返し明らかになります。この高可用性に関する議論では、単純に2つ目のインスタンスを用意するだけでは解決できない、状態同期、無線の所有権、フェイルオーバーに関する問題が取り上げられています。

結果に影響を与えるコンポーネントでマップを止めます。照明制御の障害ドメインに、任意の分析機能を含める必要はないかもしれません。一方、データベースのホスト名を解決するためにDNSが不可欠な場合もあります。この境界を設けることで、障害を実際に決定する少数の依存関係が、大量のインベントリに埋もれるのを防げます。

共有インフラは相関した損失を生む

1台のホスト上にある2つのコンテナは、そのカーネル、電源、ストレージコントローラー、そして多くの場合同じファイルシステムを共有します。2台のホストであっても、スイッチ、UPS、リゾルバー、認証情報プロバイダーを共有している可能性があります。レプリカは、対策対象の障害によってすべてのレプリカと、どれを選択するかに必要な調整データが失われない場合にのみ、リスクを低減します。

実用的なHome Assistantのクラスタリング設計は、実際のフェイルオーバーに関わるレイヤーの多さを示します。このレプリケートクラスタ設計では、レプリケートされたストレージ、サービス配置、クライアントアクセスを分離しており、アプリケーションプロセスを1つ追加するだけでは独立した障害ドメインにならない理由がわかります。

相関したリスクは、その影響が家庭の許容範囲に収まり、復旧が速い場合には許容できます。しかし、同じホストに稼働中のサービス、その唯一のデータベース、唯一のバックアップが置かれている場合は危険です。冗長化を購入または設定する前に、共有している物理的および管理上の依存関係をすべて記録してください。

依存関係が復旧の順序を決める

復旧は、基盤サービスから外側へ向かって進めます。つまり、電源とストレージ、ホストとネットワーク、DNSと認証、データベースとブローカー、Home Assistant、インテグレーション、最後にクライアントと自動化の順です。依存先の準備が整う前に利用側を起動すると、誤解を招くエラー、リトライ、部分的な可用性が発生し、診断が複雑になることがあります。

停電に関する報告からは、1つの事象が後になってストレージ、ネットワーク、アプリケーションの症状として現れることがわかります。この停電後の症状に関する記録は、下流の警告を個別にすべて修復するのではなく、最初に障害が発生したレイヤーを特定する必要があることを思い出させてくれます。

障害境界とは、破壊的な変更なしには復元または検証できない依存関係です。そこではログと正常時の状態を保持してください。データベース、ブローカー、ネームサービスが安定する前に下流のインテグレーションを再構築すると、実際の障害原因を解決できないまま証拠を消してしまう可能性があります。

障害ドメインのテストカードを作成する

家庭内の結果ごとに1行を作り、必要なコンポーネント、共有依存関係、検知シグナル、縮退時の動作、復旧担当者、最大停止時間の列を設けます。依存関係を一度に1つずつ安全に停止し、どの結果が失敗し、どれがローカルで継続し、どの程度自動的に復旧するかを記録するテストを追加します。

マップによって、必要な結果の多くが1つの依存関係に結び付いていることがわかった場合は、ローカル制御コンポーネントマップを使用してください。

すべての重要な結果について、既知の障害範囲、それを検知するアラート、目標に合った復旧手順が用意されていれば、そのアーキテクチャを受け入れます。許容範囲を超える障害がテストで確認された場合にのみ、トポロジーを変更します。制御された障害テストのない図は、レジリエンスの証拠ではなく、単なる仮定です。

テック&AIハブ

もっと読む

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.