Home Assistantに専用のコンピュート、ストレージ、ネットワークが必要になるのはいつですか？

明確なサービス目標の範囲内で制御遅延、容量、復旧時間、依存関係の障害を管理できる間は、Home Assistantを1台のホストに置いておきます。

名前の付いたワークロードが制御予算を圧迫した場合はコンピュートを、アクティブ状態と大容量データで必要な遅延や復旧ポリシーが異なる場合はストレージを、1つの共有経路が実証済みの障害ドメインを形成する場合はネットワークを専用化します。分割するたびに、別のマシン、リンク、認証情報、起動順序、バックアップ対象が増えるため、ほかのものを移動する前に新しい境界を検証してください。

測定された限界が現れるまでは役割をまとめておく

単一ホストでは、Home Assistant Core、データベース、無線機器、アドオン、バックアップ、監視を、既知の1つのシステムとして起動・復旧できる距離に保てます。統合されたワークロードが、アクション遅延のp95、再起動時間、バックアップ時間枠、ストレージ余裕、復元目標を満たしている間は、このシンプルさに価値があります。

高可用性に関する議論では、ノードを追加してもアプリケーションレベルの可用性が自動的に生まれるわけではないことが繰り返し示されています。Home Assistantの障害ドメインの限界に関するコミュニティ分析は、単に別のマシンを稼働させることと、サービス状態や無線機器の所有権を分けることを区別しており、有用です。

平均使用率が低いから、または一般的な将来への備えだけを理由に分割しないでください。監視によって、あるリソース、容量、メンテナンス時間枠、または障害がサービス目標の未達に結び付いた場合にのみ、トポロジーの変更を開始します。

1つのワークロードが制御予算を圧迫したらコンピュートを分ける

動画解析、ローカル音声処理、モデル推論、コンパイル、負荷の高いデータベース処理など、分離可能な付随サービスがCPU、メモリ、または熱容量を飽和させ、同時に重要な自動化の速度低下や失敗を引き起こす場合は、専用コンピュートが正当化されます。

反射的にHome Assistantを移動するのではなく、まず重いサービスを移動します。そのAPIエンドポイント、認証情報、タイムアウト、フォールバック動作を維持し、同じ混合ワークロードを再度実行してください。イベントからアクションまでの遅延と復旧余力が改善すれば、その分割は測定された競合境界の解消に成功しています。

リソースのピークと遅延が相関しない場合や、遅い経路の原因が無線、クラウド、DNS、クライアント、ストレージの遅延である場合は、コンピュートをまとめておきます。新しいホストを追加しても、そのホストが所有していない依存関係を修復することはできません。

容量または復旧のライフサイクルが異なる場合はストレージを分ける

アクティブな設定とRecorderの状態に低遅延で一貫性のあるスナップショットが必要である一方、メディア、テレメトリのエクスポート、バックアップ世代には低コストの容量と異なる保持期間が必要な場合は、ストレージを分離します。デバイスやプールを変更してもアプリケーションのパスが維持されるよう、安定した論理マウントを使用してください。

Docker Composeの設計レビューでは、永続ボリューム、ネットワークモード、バックアップ境界を明示することが重視されています。その永続ストレージの設計上のトレードオフは、分離では単にバイト列を移動するだけでなく、権限と復元順序も維持する必要がある理由を示しています。

NASへの依存関係を作成する前に、内部のメタデータ増加の境界を使って、容量問題の原因が実際にアクティブ状態、履歴、大容量データのどれなのかを特定してください。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

実証済みの共有障害を取り除く場合にのみネットワークを分ける

ブロードキャスト負荷、アドレス枯渇、スイッチ障害、RF干渉、安全性の低いデバイスの信頼関係、または必須のメンテナンス時間枠によって、現在の設計では許容できない停止が発生する場合は、ネットワークに専用ハードウェアやセグメントを用意する価値があります。ただし、セグメンテーションによってルーティング、ファイアウォール、マルチキャスト、DNS、ディスカバリーの依存関係も増えます。

セキュリティ境界を維持しながら、Home Assistant、無線機器、重要なローカルデバイスが最小限の経路で到達可能になるようにします。VLANや専用スイッチを導入する場合は、必要なディスカバリーおよび制御トラフィックを明示的に許可し、ルーティング、インターネット、DNSが利用できない場合にも何が動作するのかを文書化してください。

不要なネットワーク依存関係を1つずつ取り除いた状態で、ローカルアクション、再起動、ディスカバリー、通知、復旧のテストに合格するまで、セグメンテーションを信頼性の高いものとは呼ばないでください。

別の役割を移動する前に新しい境界を検証する

最新のバックアップとロールバック手順を用意し、一度に1つの分割だけを段階的に実施します。移動の前後で、元のバージョン、サービスID、エンドポイント、マウント所有権、ファイアウォールルール、起動順序、遅延、リソース負荷、バックアップ時間、復元時間を記録してください。

1. 最も負荷の高い時間帯のワークロードを再現します。
2. 1つの依存関係を取り除き、劣化時の動作を記録します。
3. 影響を受ける各サービスを依存関係の順序に従って再起動します。
4. 変更した役割をクリーンなターゲット上に復元します。
5. 文書化されたメンテナンス時間枠内にロールバックします。

専用化した境界による目標の改善が、ネットワークとライフサイクルのリスク増加を上回る場合にのみ、その境界を採用します。次の変更を開始できる別の独立した測定結果が得られるまでは、残りの役割をまとめておきます。