Comment dimensionner un serveur domestique pour Home Assistant et les pannes d’Internet

Dimensionnez le chemin de contrôle local protégé — et pas seulement le processus Home Assistant — en fonction des coupures d’Internet et de courant exactes auxquelles votre foyer doit survivre.

Dans un logement où l’éclairage, la climatisation, la détection des fuites ou les automatismes d’accès sont importants pendant une interruption, le serveur n’est qu’un des éléments du système. Les commutateurs locaux, les coordinateurs Wi-Fi ou radio, le stockage persistant, l’alimentation sur batterie et une configuration récupérable doivent rester synchronisés. La conception cesse d’être prête pour les pannes dès qu’une API cloud nécessaire, un routeur non protégé ou un comportement au redémarrage inconnu interrompt le processus avant même que la capacité de calcul ne soit un problème.

Définissez l’objectif de tolérance aux pannes

Faites la distinction entre une panne du FAI et une panne de courant. En cas de perte de l’accès Internet, le réseau local peut rester opérationnel et les appareils locaux peuvent continuer à communiquer. Lors d’une coupure de courant, l’hôte, le routeur, les commutateurs, les points d’accès, les coordinateurs, le NAS et les actionneurs peuvent tomber en panne simultanément. Attribuez à chaque événement sa propre durée et son propre niveau de dégradation acceptable.

Une discussion de la communauté sur la planification en cas de coupure de courant distingue le contrôle des appareils locaux de la question plus large de ce qui reste alimenté. Cette incertitude constitue le bon point de départ : inventorie-les actions critiques, leurs dépendances réseau et cloud, ainsi que la solution de secours manuelle. Une exigence générique consistant à « maintenir Home Assistant en ligne » est trop restrictive pour dimensionner la topologie.

Classez chaque processus comme devant continuer, pouvant être dégradé ou pouvant s’arrêter sans risque. Une vanne anti-fuite et une protection du chauffage peuvent être prioritaires par rapport aux graphiques historiques, aux notifications à distance et aux requêtes vocales. La configuration protégée doit avoir une capacité suffisante pour l’ensemble des fonctions qui doivent continuer, plus une marge de récupération ; les tâches facultatives peuvent être suspendues ou déplacées hors de l’hôte critique.

Dimensionnez le calcul à partir de la charge critique

Mesurez la charge d’automatisation essentielle avec le WAN déconnecté et la séquence d’événements locaux la plus exigeante en cours d’exécution. Relevez l’utilisation soutenue et de pointe du processeur, la pression mémoire, l’attente liée au stockage et la latence de réponse. Incluez la base de données et uniquement les modules complémentaires nécessaires aux actions protégées. Vous obtenez ainsi une référence serveur liée au service, et non au nombre d’appareils.

Maintenez les modèles vocaux locaux, l’inférence vidéo, le traitement multimédia et la compression des sauvegardes hors du chemin protégé, sauf si les exigences de panne les incluent explicitement. S’ils partagent l’hôte, utilisez des limites de ressources ou une planification et reproduisez leur chevauchement maximal. Ne séparez un service que lorsque son pic empêche une action critique de respecter l’objectif de tolérance.

Ajoutez une marge pour les mises à jour, la maintenance de l’enregistreur et la croissance, mais ne transformez pas cette marge en un niveau de processeur arbitraire. Un hôte est suffisamment puissant lorsque la séquence critique mesurée reste réactive et que le comportement au redémarrage est prévisible. Il est surdimensionné pour son rôle actuel lorsque sa capacité inutilisée augmente la consommation au repos et la charge de l’onduleur sans réduire une défaillance identifiée.

Construisez un seul chemin protégé pour l’alimentation et le réseau

Tracez un chemin unique allant du capteur ou du tableau de bord jusqu’au Wi-Fi ou à la radio, au commutateur local, à Home Assistant, puis à l’actionneur. Placez chaque composant réseau nécessaire et l’hôte sur un circuit protégé par un onduleur dont la charge a été mesurée. Une batterie sur le seul serveur ne peut pas maintenir le contrôle si le routeur, le commutateur, le point d’accès ou le coordinateur perd son alimentation.

Un opérateur décrit la protection des équipements réseau, du stockage et du serveur Home Assistant au moyen de petits onduleurs, l’arrêt des serveurs en quelques minutes et le maintien plus long des équipements réseau. Les durées dépendent de chaque installation, mais la séparation des rôles est utile : le calcul peut s’arrêter correctement tandis que le chemin de communication local reste disponible.

Mesurez la charge totale sur la prise, sélectionnez une autonomie cible et testez-la pendant l’activité de pointe normale. Définissez si l’hôte doit continuer à fonctionner, s’arrêter proprement ou redémarrer après le retour du courant. Rejetez toute conception qui ne peut pas récupérer lorsque le courant revient alors que l’onduleur est encore chargé, car ce cas limite peut laisser une batterie en bon état protéger un service hors ligne.

-15% OFF

ZimaBoard 2 - Mini serveur domestique pour votre grande idée

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Séparez l’état actif des copies de récupération

Conservez la configuration et la base de données active de l’enregistreur sur un stockage persistant surveillé qui démarre avec l’hôte protégé. Placez les copies de récupération sur une destination distincte dont la perte n’empêche pas l’automatisation locale de démarrer. Un NAS peut être une cible de sauvegarde efficace, mais il ne doit pas devenir une dépendance accidentelle du service principal.

Une séquence de panne rapportée avec Home Assistant et Synology montre que les deux systèmes s’arrêtent lors d’un événement lié à l’onduleur, mais ne se rallument pas automatiquement lorsque le courant revient avant que l’onduleur ne soit complètement déchargé. Ce cas montre pourquoi la récupération du stockage, de l’hôte et de l’alimentation doit être testée comme une seule séquence ; des composants corrects individuellement peuvent tout de même produire un service indisponible.

Définissez la fréquence des sauvegardes en fonction de la perte de données acceptable, puis restaurez une copie récente sur un autre support ou une machine de secours. Stockez les identifiants et les procédures là où un autre administrateur du foyer peut y accéder. Le RAID, le stockage miroir ou une deuxième partition ne remplacent pas une copie hors hôte, car ils conservent le même domaine de défaillance humain et système.

Validez la topologie et définissez les seuils d’extension

Effectuez quatre tests d’acceptation : déconnectez le WAN, rendez la cible de sauvegarde indisponible, simulez l’action de l’onduleur lorsque sa batterie est faible et restaurez le système sur un autre matériel. Chronométrez les automatisations critiques, l’arrêt, le redémarrage et la restauration. Notez les défaillances par liaison dans le graphe afin qu’une mise à niveau modifie le rôle défaillant au lieu d’ajouter de la capacité partout.

Le guide de ZimaSpace consacré à la mesure des performances de Home Assistant au-delà du cache à chaud explique pourquoi des tests répétés avec un cache chaud peuvent masquer les limites au démarrage à froid ou en période de pointe. Appliquez cette méthode à la charge protégée, puis comparez le résultat avec la consommation de l’onduleur et le comportement de récupération au lieu de surdimensionner l’hôte à partir d’un test confortable en cache.

Augmentez la capacité de calcul lorsque la latence critique mesurée dépasse la limite après exclusion des autres goulots d’étranglement. Augmentez la capacité de la batterie lorsque l’autonomie du chemin complet n’atteint pas l’objectif. Séparez les services lourds lorsque l’isolation corrige la défaillance. Cessez d’acheter du matériel serveur lorsqu’un appareil dépendant uniquement du cloud, un composant réseau non protégé ou une restauration non testée reste la première limite.

Règle finale de configuration

La configuration prête à affronter les pannes est la plus petite topologie protégée qui réussit les tests de perte du WAN, d’autonomie sur batterie, de redémarrage et de restauration du foyer. Augmentez le calcul, la batterie ou l’isolation uniquement lorsqu’une limite mesurée échoue. Si les dépendances cloud ou les lacunes des commandes manuelles restent prépondérantes, corrigez-les avant d’étendre le serveur Home Assistant.