Passer au contenu principal

Arrêts imprévus

Un arrêt inopiné se produit lorsque Unraid détecte que le array n'a pas été correctement arrêté avant que le système ne s'éteigne. Cette situation peut déclencher un parity check automatique lors du prochain démarrage pour garantir l'intégrité des données.

Recommendations pour prévenir les arrêts non propres

Prendre des mesures proactives peut vous aider à éviter ou à identifier les arrêts imprévus :

  • Utilisez un onduleur : Gardez votre serveur connecté à un appareil d'alimentation sans interruption (UPS) et configurez-le pour initier un arrêt contrôlé lorsque l'alimentation de la batterie est faible.
  • Tentez un arrêt en douceur : Si votre serveur ne répond pas, appuyez brièvement sur le bouton d'alimentation pour initier un arrêt sécurisé. Ne maintenez pas le bouton enfoncé, car cela provoquerait une coupure d'alimentation brutale et entraînerait un arrêt inopiné.
  • Activer la journalisation persistante: Allez dans Paramètres → Serveur Syslog pour activer la journalisation qui persiste après un redémarrage. Voir Logs persistants (serveur Syslog) pour plus de détails.
  • Joindre des diagnostics pour le support : Si un arrêt non sécurisé se produit, Unraid tentera de sauvegarder les diagnostics dans /log/diagnostics.zip sur votre périphérique flash. Joignez ce fichier à vos publications dans le forum lorsque vous demandez de l'aide.
UPS meilleures pratiques de configuration

Un onduleur bien configuré est votre meilleure défense contre les arrêts imprévus dus à une perte d'alimentation.

  • Connectez l'onduleur via USB à votre serveur Unraid.
  • Activez le support de l'onduleur dans Paramètres → Paramètres de l'onduleur.
  • Configurer les délais d'arrêt : Configurez l'onduleur pour déclencher un arrêt contrôlé avant que la batterie ne soit faible. Ajustez les seuils de "Durée de la batterie restante" ou de "Niveau de charge de la batterie" pour assurer suffisamment de temps à Unraid pour arrêter le array et s'éteindre en toute sécurité.
  • Testez votre configuration : Simulez une perte de puissance pour garantir que l'onduleur et Unraid réagissent correctement.

Consultez le plugin NUT pour une compatibilité étendue avec des modèles UPS avancés ou du matériel non pris en charge.

Événements qui causent des arrêts incorrects​

Comprendre les principaux déclencheurs des arrêts incorrects vous aide à les prévenir. Les sections suivantes couvrent les scénarios les plus courants et leurs solutions.

Perte de puissance inattendue​

Les interruptions de courant sont l'une des principales raisons des arrêts non propres. Protégez votre système avec un onduleur configuré correctement qui peut arrêter automatiquement Unraid avant que la batterie ne se décharge.

note

Unraid prend en charge la plupart des unités UPS utilisant le protocole apcupsd (APC et CyberPower sont généralement compatibles). Si votre UPS n'est pas pris en charge, envisagez d'utiliser le plugin Network UPS Tools (NUT) de Community Applications.

Défaillance du lecteur flash​

Le statut de array est stocké sur votre dispositif USB. Si la clé USB devient indisponible ou passe en mode lecture seule, Unraid ne peut pas mettre à jour le statut d'arrêt, même si l'array s'arrête correctement. Cela entraîne la détection d'un arrêt incorrect au prochain démarrage.

Ouvrir des sessions terminal​

Unraid attend que toutes les sessions terminales ou SSH ouvertes se ferment lors de l'arrêt. Si ces sessions restent actives et que le minuteur d'arrêt expire, un arrêt forcé se produit.

astuce

Le plugin Dynamix Stop Shell peut automatiquement fermer les sessions bash ou SSH persistantes, aidant ainsi à garantir une fermeture en douceur. Cependant, soyez prudent si des opérations d'écriture sont en cours sur le array.

Délai des machines virtuelles​

La configuration correcte des délais d'arrêt est essentielle pour garantir que votre serveur Unraid peut arrêter tous les services efficacement. Cela prévient les arrêts inappropriés, notamment lors des coupures de courant ou de la maintenance. L'étape la plus importante est de configurer vos VMs pour hiberner au lieu de s'éteindre. Cette approche aide à éliminer de nombreux problèmes liés aux délais.

Configuration de l'hibernation VM​

Use Hibernation VM

Pour les arrêts les plus fiables et rapides, configurez vos VMs pour hiberner au lieu de s'éteindre. Ceci est particulièrement important pour les VMs Windows mais bénéfique pour tous les types de VM.

Nous recommandons l'hibernation car elle :

  • Sauvegarde l'état de la VM instantanément - Pas d'attente pour que l'OS invité s'arrête.
  • Préserve la perte de données - Pas de risque d'interrompre les mises à jour ou le travail non sauvegardé.
  • Évite les problèmes de délai - L'hibernation est presque instantanée.
  • Récupération plus rapide - Les VMs reprennent exactement là où elles se sont arrêtées.

L'arrêt peut poser problème car :

  • Windows peut afficher des boîtes de dialogue (« Sauvegarder ce document ? ») qui arrêtent l'arrêt indéfiniment.
  • Les mises à jour de Windows peuvent durer plus de 10 minutes pendant l'arrêt.
  • Si le délai expire, Unraid tue de force la VM, ce qui peut corrompre les mises à jour de Windows en cours, les documents non sauvegardés, les données des applications et les systèmes de fichiers dans l'OS invité.

Critical requirement: Ensure the QEMU Guest Agent is installed in the VM for hibernation to function correctly.

Pour activer l'hibernation VM :

  1. Download QEMU Guest Agent:

  2. Installez dans Windows VM :

    • Montez le virtio-win.iso sur votre VM.
    • Exécutez le programme d'installation depuis l'ISO monté.
    • Install both VirtIO drivers AND QEMU Guest Agent.
    • Redémarrez la VM.

  3. Configurez dans Unraid :

    • Accédez aux paramètres de votre VM dans l'onglet VMs.
    • Choisissez Action à l'arrêt sur Hiberner.
    • Cliquez sur Appliquer.

Maintenant pour vérifier que votre hibernation fonctionne, démarrez votre VM et ouvrez quelques applications. Puis arrêtez-la depuis Unraid. Lorsque vous la redémarrez, elle devrait reprendre avec toutes les applications encore ouvertes.

Guest L'agent est critique

Without the QEMU Guest Agent installed, hibernation may not work properly. In that case, the VM will revert to shutdown mode, consuming the full timeout period.

Configuration de délai​

Dans cette section, nous couvrirons comment configurer les délais pour divers systèmes et processus. Ces informations sont importantes pour s'assurer que vos VMs et conteneurs Docker s'arrêtent gracieusement sans perte de données.

ParamètrePar défautQuand augmenterOù configurer
Délai d'arrêt de VM60s300s si vous n'utilisez pas l'hibernation et que les VMs plantent.Paramètres → Gestionnaire de VM → Arrêt VM (Avancé)
Délai d'arrêt des conteneurs Docker10s30s si des conteneurs plantent lors de l'arrêt.Paramètres → Docker (Avancé)
Délai d'arrêt général90s180s si vous avez des arrêts non propres, 300s+ avec VMs.Paramètres → Paramètres disque → Délai d'arrêt
When augmenter les délais

Si vous rencontrez des arrêts intempestifs ou des conteneurs qui plantent lors de l'arrêt, envisagez d'augmenter le délai d'arrêt général à 180 secondes (ou 300+ secondes si vous avez plusieurs VMs). Cela donne plus de temps aux services pour s'arrêter correctement.

Séquence d'arrêt​

Lorsque l'arrêt est en cours, le processus se déroule dans l'ordre suivant :

  1. Arrêt des VMs : Cela implique trois étapes, chacune pouvant prendre jusqu'au délai d'attente de la VM :

    • Étape 1 : Reprendre toutes les VMs mises en pause
    • Étape 2 : Hiberner les VMs qui sont configurées pour l'hibernation
    • Étape 3 : Arrêter les VMs restantes

    Toutes les VMs à chaque étape sont traitées en même temps, ce qui signifie que le temps total d'arrêt peut être calculé comme : Temps d'attente VM × 3.

  2. Les conteneurs Docker s'arrêtent simultanément (temps total = délai d'attente Docker).

  3. Les autres services incluent des tâches telles que les conteneurs LXC et les plugins tiers, qui prennent généralement quelques secondes.

  4. Arrêt de l'array : les disques doivent être démontés et les données synchronisées ; cela prend généralement 15 à 30 secondes.

Calculate votre délai d'arrêt général

Formule : Votre délai d'arrêt général doit être supérieur à :

(VM timeout × 3) + (Docker timeout) + (Other services) + 15-30 seconds

Exemple : Selon la formule, cela ressemblerait à ceci : (300 × 3) + 30 + 10 + 30 = 970 secondes (plus de 16 minutes).

Recommandation : Au moins 180 secondes (3 minutes) au minimum et 300+ secondes (5+ minutes) si vous avez plusieurs VMs ou des conteneurs complexes.

Si tous vos VMs sont réglés pour hiberner plutôt que de s'éteindre, alors le délai d'attente de la VM est moins critique puisque l'hibernation est presque immédiate. Vous pouvez utiliser un délai d'attente plus court pour les VM (par exemple, 60-120 secondes) comme sauvegarde pour les VMs qui ne prennent pas en charge l'hibernation.

Guide de configuration détaillé​

Cette section fournit des informations détaillées sur la configuration des délais pour différents composants système. Chaque réglage de délai fonctionne ensemble pour garantir que votre serveur s'arrête en douceur sans perte de données.

Delais d'attente pour les VM​

Configurer les délais d'arrêt VM dans Paramètres → Gestionnaire de VM → Arrêt VM (activer la vue avancée).

Comment ça fonctionne:

  • Les VMs passent par trois étapes d'arrêt, chacune consommant la totalité du délai de la VM.
  • Toutes les VMs à chaque étape sont traitées simultanément.
  • Temps total d'arrêt de la VM = Temps d'attente de la VM × 3

Problèmes courants :

  • Interruptions de mise à jour Windows : Les mises à jour pendant l'arrêt peuvent être corrompues si le délai expire.
  • Travail non sauvegardé : Les boîtes de dialogue demandant de sauvegarder les documents peuvent arrêter l'arrêt indéfiniment.
  • Hibernation failures: VMs without QEMU Guest Agent may fail to hibernate and use full timeout.
VM recommandations de délai d'attente
  • Primary recommendation: Configure VMs to hibernate instead of shutting down (requires QEMU Guest Agent).
  • Si les VMs plantent lors de l'arrêt : Augmentez le délai à 300 secondes (5 minutes) pour les VMs Windows.
  • Mises à jour Windows : Configurez Windows pour installer les mises à jour au démarrage plutôt que lors de l'arrêt.
  • Testez votre configuration : Arrêtez manuellement vos VMs pour confirmer qu'elles s'arrêtent ou hibernent dans le délai imparti.
No délai d'attente sécuritaire sans hibernation

Without hibernation and QEMU Guest Agent, there isn't a truly safe timeout for Windows VMs. Dialog boxes or ongoing update installations could render any timeout inadequate, leading to forced shutdowns and data corruption risk.

Délais d'arrêt Docker​

Configurer les délais d'arrêt des conteneurs Docker dans Paramètres → Docker (activer la vue avancée).

Comment ça fonctionne:

  • Les conteneurs sont arrêtés en parallèle, donc le temps total équivaut au délai d'arrêt Docker.
  • La plupart des conteneurs s'arrêtent en moins de 10 secondes, mais certains peuvent nécessiter plus de temps.
  • Les conteneurs complexes avec de grandes bases de données ou des opérations en cours pourraient nécessiter un temps supplémentaire.
  • Si le temps imparti expire, les conteneurs sont arrêtés de force.
Docker recommandations de délai d'attente
  • Le délai par défaut de 10 secondes fonctionne bien pour la plupart des conteneurs.
  • Si les conteneurs se plantent à l'arrêt : Augmentez le délai à 30 secondes.
  • Surveillez vos conteneurs pendant l'arrêt pour identifier ceux qui ont systématiquement besoin de plus de temps.

Délais généraux​

Configurer le délai d'arrêt général dans Paramètres → Paramètres du disque → Délai d'arrêt.

Considérations UPS (facteur le plus critique) :

  • Votre onduleur doit offrir suffisamment de temps pour compléter la séquence d'arrêt complète avant que la batterie ne s'épuise.
  • Pour un arrêt manuel, vous pouvez définir des délais plus longs puisque vous contrôlez le début de l'arrêt.
  • Avec un arrêt en cas de coupure de courant, votre délai est limité par l'autonomie de la batterie de l'onduleur.
  • Testez votre onduleur en simulant une coupure de courant pour assurer un arrêt propre de votre serveur avec du temps à revendre.
General recommandations de délai d'attente
  • Si vous avez des arrêts non propres : Augmenter à 180 secondes (3 minutes) pour les systèmes sans VMs.
  • Pour les systèmes avec VMs : Utilisez 300+ secondes (5+ minutes) si vous n'utilisez pas l'hibernation.
  • Si l'hibernation est utilisée : 180-300 secondes sont généralement suffisantes.
  • Assurez-vous que les délais ne dépassent pas ce que votre onduleur peut supporter lors d'une coupure de courant.

Services tiers​

Conteneurs LXC : Le plugin LXC a son propre paramètre de délai d'arrêt pour arrêter les conteneurs. Comme les conteneurs Docker, les conteneurs LXC s'arrêtent généralement en quelques secondes, mais certains peuvent nécessiter plus de temps. Consultez les paramètres du plugin LXC pour le délai d'arrêt du conteneur et incluez ce délai dans le calcul de votre délai d'arrêt général.

Autres services : Certains plugins ou services personnalisés peuvent avoir leurs propres procédures d'arrêt. Consultez la documentation du plugin pour des délais d'arrêt spécifiques et intégrez-les dans vos calculs.

Formule mise à jour avec des services tiers :

(VM timeout × 3) + (Docker timeout) + (LXC/other timeouts) + 15-30 seconds

Plugin Dynamix Stop Shell : Si vous utilisez souvent SSH ou des sessions terminal, des sessions ouvertes peuvent empêcher des arrêts propres car Unraid attend qu'elles se ferment avant de procéder.

Le plugin Dynamix Stop Shell aide en fermant automatiquement les sessions bash ou SSH persistantes lorsque le tableau est arrêté, assurant un arrêt en temps opportun.

Vous pouvez l'installer depuis Applications Communautaires (rechercher "Dynamix Stop Shell").

When pour utiliser le plugin
  • Si vous avez régulièrement des sessions terminal ouvertes.
  • Pour éviter que des sessions SSH oubliées ne retardent l'arrêt.
  • Pour un nettoyage automatisé lors de l'arrêt.
précaution
  • Soyez prudent si vous avez des scripts ou des processus en cours dans des sessions terminal.
  • Assurez-vous qu'aucune opération d'écriture critique n'est en cours avant l'arrêt.
  • Le plugin fermera de force les sessions, ce qui pourrait interrompre le travail.