Home Assistantはネットワーク共有上のデータで安定して動作しますか？

エヴァ・ウォン

IceWhale author

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

Can Home Assistant Run Reliably With Its Data on a Network Share? - Zima Store Online

Home Assistantはバックアップ、メディア、一部の共有ファイルにネットワークストレージを安定して利用できますが、稼働中の設定ディレクトリやデフォルトのSQLite RecorderデータベースをSMBまたはNFS上に置く設計は、はるかに高度な要件を伴います。より安全なデフォルトは、Home Assistantのアクティブな状態をローカルの永続ストレージに保存し、リモート容量や独立したバックアップのメリットがあるデータにはネットワーク共有を使うことです。

違いを生むのは、トランザクション動作と起動時の依存関係です。バックアップアーカイブはNASの準備を待てますが、Home Assistantの設定やデータベースは、ネットワーク共有がマウントされる前、または正常な状態になる前に必要になる場合があります。NASの短時間の停止によって、正常なローカルコントローラーが空のインストール状態や破損状態になるべきではありません。

バックアップやメディア用の共有を稼働中のアプリケーション状態から分離する

まず、何を移動したいのかを明確にしましょう。バックアップアーカイブやメディアファイルはサイズが大きく、転送可能なオブジェクトであり、Home Assistant Coreによる継続的なトランザクション書き込みのために常時開かれている必要もないため、NASに適しています。

稼働中のアプリケーション状態は異なります。設定ツリーには、UIで管理されるストレージなど、Home Assistantが通常の動作中に読み取りや更新を行うファイルが含まれます。一方、Recorderは状態やイベントの履歴を継続的に書き込みます。

ZimaSpaceのプライベートクラウドの例では、Home Assistantの復旧を大容量NASストレージから分離しています。ここで有用なのはこの構成です。ネットワーク容量を個別に拡張でき、すべての制御操作がストレージ共有に依存することを避けられます。

SQLiteではロックと整合性に関する要件が加わる

Home Assistant RecorderのデフォルトデータベースはSQLiteです。このデータベースは、ローカルストレージでは簡単に提供できる一方、ネットワークファイルシステム、再接続、マウント実装によっては予測が難しいファイルシステムの動作を前提としています。

SQLiteはネットワークデータベースサーバーとして設計されておらず、プラットフォームによってはネットワークファイルシステムのロックが不安定または不完全になる可能性があります。そのため、リモートのSQLiteファイルは、SMB経由でメディアを読み取るだけの場合とは異なるリスクを伴います。

別のホスト上にデータベースが必要な場合は、サポートされているクライアント・サーバー型データベースを使用し、外部依存に伴う運用上の責任を受け入れてください。SQLiteファイル自体を移動すれば同じ構成になると考えてはいけません。

共有が後で使えても、マウントのタイミングによって起動が失敗することがある

ネットワーク共有はシステムの完全な起動後には書き込み可能でも、Home Assistantがデータベースや設定を最初に必要とする時点では利用できない場合があります。これにより、後から手動で書き込みテストをしても検出できない起動順序の問題が発生します。

RecorderのSQLiteをSMB上に置いたHome Assistantユーザーは、ホストから共有に書き込めたにもかかわらず、起動中に0バイトのデータベースファイルや破損したデータベースファイルが作成される問題を確認しました。この議論では、マウントのタイミングと、ネットワーク共有上でSQLiteを使用する適性が具体的に取り上げられています。

コールドブート、ホストの再起動、NASの再起動、一時的な共有停止をテストしてください。NASを手動で再マウントした後にしか動作しない構成は、家全体の制御に使うには十分な信頼性がありません。

Featured

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

ZimaCube2

ネットワーク遅延によって、制御を壊さずに履歴が遅くなることがある

リモートのデータベースや設定に対するI/Oでは、小さな読み書きにもネットワーク遅延が加わります。最初に現れる症状は、自動化の失敗ではなく、履歴グラフ、データベースのメンテナンス、起動の遅さである場合があります。

Home AssistantをKubernetesにデプロイした事例では、NFS上のSQLiteとリモートSQL経路によってデータベースの応答性が低下したため、執筆者はアクティブなデータベースのパスをHome Assistantのワークロードに近い場所へ移しました。

具体的な症状を測定してください。ローカルの制御は高速なのに履歴だけが遅い場合、データベースのパスが物理的な自動化そのものではなく、履歴機能に影響している可能性があります。共有に重要な設定も保存している場合は、停止による影響がサービス全体に及ぶ可能性があります。

小規模サーバーではローカル状態とネットワークバックアップを優先する

ほとんどのホームサーバーでは、/configとデフォルトのSQLiteデータベースを、信頼性の高いローカルSSDなどの永続デバイスに保存してください。バックアップはNASに送信し、メディアはNASに保存し、中央の容量を活用できる大容量データにはネットワーク共有を使用します。

この分離により診断が容易になります。ローカルデータベースの遅延はHome Assistantホストの問題であり、見つからないバックアップやメディアファイルはNASのパスに関する問題です。ネットワークの利便性を活かしながら、すべての状態書き込みを同期的に依存させずに済みます。

アクティブな状態をリモートストレージに移すのは、共有、マウント順序、ロックのセマンティクス、遅延、障害時の挙動、復元手順をすべて、コールドスタートと一時的なネットワーク切断の状況でテストしてからにしてください。

よくある質問

NASはHome Assistantのバックアップ先として適していますか？

はい。NASは、バックアップアーカイブを保存する独立した保存先として適していることが多く、特にHome Assistantのシステムディスクが故障してもコピーが残る点で有用です。ただし、NASとHome Assistantホストが同じ物理的な障害範囲にある場合は、別の場所にもコピーを保存してください。

デフォルトのHome Assistant SQLiteデータベースをSMBまたはNFS上に直接置くべきですか？

通常は避けてください。特別な理由があり、十分にテスト済みの場合を除き、SQLiteは信頼性の高いローカルストレージに保存してください。データベースをリモートに置く必要がある場合は、SQLiteファイルを通常のネットワーク文書のように扱うより、サポートされているクライアント・サーバー型データベースを使用するほうが、より明確な構成になります。