Un serveur domestique peut-il relancer les services dans l’ordre des dépendances après la récupération de l’onduleur ?

Eva Wong

IceWhale author

Eva Wong est la rédactrice technique et bricoleuse résidente chez ZimaSpace. Geek depuis toujours, passionnée par les homelabs et les logiciels open source, elle se spécialise dans la traduction de concepts techniques complexes en guides accessibles et pratiques. Eva croit que l’auto-hébergement doit être amusant, pas intimidant. À travers ses tutoriels, elle donne à la communauté les moyens de démystifier les configurations matérielles, depuis la construction de leur premier NAS jusqu’à la maîtrise des conteneurs Docker.

Can a Home Server Resume Services in Dependency Order After UPS Recovery?

Oui, mais uniquement lorsque le graphe des dépendances est explicite. Un serveur peut se mettre automatiquement sous tension après le rétablissement de l’onduleur, tandis que les applications échouent encore parce que le stockage, le DNS, les bases de données ou les réseaux ne sont pas prêts.

L’ordre de démarrage des processus n’est pas équivalent à la disponibilité des services. Utilisez les dépendances systemd pour les ressources au niveau de l’hôte et des contrôles d’état pour les conteneurs et les applications. Cette distinction détermine la configuration sûre, la méthode de validation et le point de restauration.

Écrivez le graphe des dépendances avant de l’automatiser

Répertoriez la chaîne allant de l’alimentation et du réseau aux disques chiffrés, aux montages NAS, à l’environnement d’exécution des conteneurs, aux bases de données, aux services applicatifs et au proxy inverse. Indiquez quelles dépendances sont locales et lesquelles se trouvent sur un autre serveur.

Attribuez à chaque dépendance avec état un signal de disponibilité : chemin monté, requête à la base de données, résolution DNS ou point de terminaison de contrôle d’état de l’application. Évitez les temporisations fixes, car le temps de récupération varie après un arrêt brutal.

Définissez un état d’échec limité afin qu’un NAS indisponible n’amène pas une application à écrire dans un répertoire local vide.

Coordonnez chaque couche de contrôle

Utilisez les relations `After=` et `RequiresMountsFor=` de systemd pour les services de l’hôte et les montages distants. Faites dépendre l’unité de la pile de conteneurs de Docker et des unités de montage requises.

Dans Compose, ajoutez de véritables contrôles d’état et utilisez `depends_on` avec `condition: service_healthy` lorsque cette option est prise en charge. Les applications doivent tout de même réessayer les connexions aux bases de données, car les dépendances peuvent échouer après le démarrage.

Utilisez le tableau ci-dessous pour attribuer chaque dépendance à la couche capable de l’observer réellement.

État observé	Décision	Action suivante
Montages des disques et du NAS	Dépendances de montage systemd	Bloquer les services avec état
Base de données prête à recevoir des requêtes	Contrôle d’état du conteneur	Bloquer les applications
Application externe accessible	Nouvelle tentative de l’application et supervision	Ne pas utiliser de temporisation fixe

Concevez la récupération sur deux serveurs

Démarrez d’abord le serveur de stockage ou d’infrastructure, puis attendez que les partages exportés et les bases de données soient opérationnels avant d’autoriser les services applicatifs sur le deuxième hôte. Le logiciel de l’onduleur ne doit pas simplement mettre les deux hôtes sous tension simultanément.

L’article de ZimaSpace sur les signaux de l’onduleur et les machines virtuelles montre pourquoi la chaîne de contrôle traverse plusieurs couches.

Un guide indépendant sur systemd et Compose explique les conditions de concurrence liées à l’ordre de démarrage et d’arrêt.

Conservez une procédure manuelle de démarrage à froid pour le cas où l’automatisation s’arrête après l’échec d’un contrôle d’état. Elle doit préciser le contrôle, le délai d’expiration attendu, la nouvelle tentative sûre et le responsable de chaque service.

Featured

ZimaCube 2 NAS personnel Cloud à domicile

ZimaCube2

Testez l’état complet de récupération après une panne de l’onduleur

Planifiez un arrêt contrôlé sur batterie, rétablissez l’alimentation secteur et enregistrez les horodatages du démarrage de l’hôte, de la disponibilité des montages, de l’état de la base de données, de l’état de l’application et de la disponibilité du proxy.

Répétez le test avec un NAS retardé et avec une récupération de base de données plus longue que la normale. Les services doivent attendre ou échouer de manière visible plutôt que démarrer sans l’état requis.

Poursuivez lorsque les récupérations normale et retardée préservent l’ordre et les chemins de données. Arrêtez-vous si les politiques de redémarrage contournent la disponibilité, si les applications écrivent dans des répertoires de secours ou si une dépendance ne dispose d’aucun signal d’état mesurable.