Home Assistantのパフォーマンス、消費電力、復旧のバランスを取る方法

まず測定可能な制御性能と復旧目標を満たしてから、重要なサービスを高負荷のワークロードと結び付けずにアイドル時の消費電力を削減することで、Home Assistant のバランスを取ります。

常時稼働するホームサーバーは、通常の自動化処理が最も集中する時間帯にも応答し、ホストやストレージの障害に耐え、運用コストを手頃に保つ必要があります。ハードウェアを選ぶ前にそれらの成果を定義し、実験的なワークロードを重要な処理経路の外に置き、プロセッサーの定格に頼らずシステム全体の消費電力を測定してください。

性能目標と復旧目標を同時に設定する

イベントからアクションまでの遅延、再起動後にダッシュボードが使用可能になるまでの時間、データベース保守の完了時間、バックアップ所要時間、許容できる最大復旧時間など、観測可能な目標を設定します。本番環境で想定するデバイス数、インテグレーション、共有ワークロードと同じ条件でテストしてください。

コミュニティのハードウェアガイドでは、単一の万能な仕様ではなく、ワークロードと拡張性に基づいてプラットフォームを比較しています。そのワークロード優先のハードウェア選定により、応答性を維持すべきサービスを基準にサイジングできます。

健全でないデータベース、故障しかけたストレージ、または制御されていないアドオンを補うために、より高性能なコンピューティングを購入してはいけません。目標は、安定したサービス範囲と、把握済みの復旧手順です。

重要なワークロードと任意のワークロードを役割ごとに分ける

ローカル自動化、デバイス制御、認証情報、稼働中のデータベースは重要な役割に置きます。カメラ推論、メディア処理、実験、バルク処理は、ピーク時に制御処理を遅延させる可能性があるため、リソース制限を設けた任意の役割、または別ノードに配置します。

任意の処理が重要な役割を停止させずに失敗または一時停止できるなら、共有ホストでも問題ありません。すべての更新やストレージ処理で共通の再起動が必要になる場合、統合によるわずかな省電力と引き換えに、より大きな停止範囲を受け入れることになります。

再現可能なワークロードのベンチマークを使い、アイドル状態のダッシュボードを比較するのではなく、同じピーク負荷の下で役割分担を検証してください。

稼働状態ごとにシステム全体のエネルギーを測定する

アイドル、通常の活動、バックアップ、データベース保守、最も重い任意のワークロードの各状態で、壁面コンセントから測定します。ネットワークスイッチ、外付けドライブ、選択した構成のためだけに存在する冗長デバイスも含めてください。年間の消費電力量は、主に各状態がどれだけ長く続くかで決まります。

低消費電力ミニ PC の稼働状態について公開されている壁面電力の測定結果は、アイドル時と負荷時の挙動を分けて評価する必要がある理由を示しています。CPU の TDP から推測するのではなく、測定したシステム全体の値を使用してください。

適切なサイズのハードウェア、適切な場合のドライブのスピンダウン方針、バルク処理のスケジュール設定、未使用サービスの削除によって電力を削減します。アイドル時の数値を下げるためだけに、ログ、バックアップ、冷却、ストレージチェックを無効にしてはいけません。

Featured

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

ZimaCube2

$799.00 - $2,499.00

Buy Now

主要な障害ドメインの外に復旧手段を構築する

少なくとも1つの使用可能なバックアップを Home Assistant のシステムディスクから離れた場所に保存し、ネットワーク識別情報、無線機器、シークレット、外部データベースを復元する手順を文書化します。同じホスト上のスナップショットはロールバックには便利ですが、ホストやストレージの喪失には対応できません。

運用者向けのバックアップ設計では、Home Assistant のスナップショットを追加の保持コピーから分離し、ハードウェア障害からの復旧を重視しています。その多層バックアップ方式により、復旧手段を常時稼働のコンピューティングノードから独立して保持できます。

分離した環境で復旧時間を計測します。低消費電力設計が復旧目標を満たさない場合は、本番用のコンピューティングを増やす前に、より高速な復旧媒体またはより単純な待機系の構成を追加してください。

3つのバランスを検証して終了する

当初のピークワークロードを実行し、1日全体のエネルギー使用量を記録し、主要インスタンスの喪失をシミュレーションして、復元または文書化した復旧リハーサルを完了します。性能、電力、復旧は、最終的に同じ構成で評価しなければなりません。

サービスと復旧の目標を達成し、さらなる省電力化によって共有依存関係、手動介入、または不十分な冷却が生じるなら、最適化を止めます。測定したワークロードが繰り返し目標を超えた場合にのみ拡張してください。

アイドル時にだけ効率的、任意のサービスを停止した後にだけ高速、または障害が発生したホストからしか復旧できない設計は失敗です。デフォルトでトポロジー全体を置き換えるのではなく、原因となっている役割を修正してください。