À quelle fréquence dois-je redémarrer les serveurs Linux?

J'ai de nombreux serveurs Linux (SUSE 9 et 10) utilisés pour exécuter des services Web qui fournissent des données à de grandes grilles de calcul. Récemment, nous avons eu des pannes difficiles à expliquer (c'est-à-dire que les journaux du matériel et des logiciels ne montrent aucune erreur évidente) et nous commençons à nous demander si le temps de fonctionnement long (généralement 200 à 300 jours) est le problème. Étant donné que ces serveurs sont fortement utilisés, dois-je envisager un cycle de redémarrage régulier?

Vous devez redémarrer après une mise à jour du noyau (sauf si vous utilisez KSplice), tout le reste est facultatif. Personnellement, je redémarre sur un cycle mensuel pendant une fenêtre de maintenance pour m'assurer que le serveur et tous les services reviennent comme prévu. De cette façon, je peux être raisonnablement certain si je dois faire un redémarrage hors calendrier (c'est-à-dire une mise à jour critique du noyau) que le système reviendra correctement. La surveillance automatisée des serveurs et des services (c'est-à-dire Nagios) contribue également grandement à ce processus (redémarrez, regardez les voyants devenir rouges, puis, espérons-le, tous redeviennent verts).

PS: si vous redémarrez régulièrement, vous voudrez vous assurer que vous ajustez vos contrôles fsck (c'est-à-dire le nombre maximal de montages entre les contrôles de manière appropriée, sinon un redémarrage rapide de 2 minutes pourrait prendre 30 minutes si le serveur commence à fsck'er quelques téraoctets de données. Je règle généralement mon nombre de montages sur 0 (tune2fs -c 0) et l'intervalle entre les vérifications sur 6 mois environ, puis force manuellement un fsck de temps en temps et réinitialise le nombre.

En fait, je redémarre mes serveurs assez régulièrement, chaque fois que des changements majeurs de configuration sont effectués. Il est important de savoir qu'en cas d'urgence, le logiciel serveur apparaîtra sans tracas. La dernière chose que vous voulez, c'est d'être dans une position où vous essayez de récupérer après une panne, mais vous devez jouer avec la configuration de votre serveur parce que vous ne l'avez pas testée à fond lorsque vous l'avez configurée.

Les serveurs Linux n'ont jamais besoin d'être redémarrés sauf si vous avez absolument devez changer la version du noyau en cours d'exécution. La plupart des problèmes peuvent être résolus en modifiant un fichier de configuration et en redémarrant un service avec un script init.

Vous devez faire attention aux redémarrages ... si vous avez modifié quoi que ce soit "à la volée" sans refléter vos modifications dans le fichier de configuration d'un service, ces modifications ne seront pas appliquées après un redémarrage.

Cependant, je redémarre généralement après les mises à jour programmées du système. Ce n'est généralement pas nécessaire, mais je les fais quand personne n'est au bureau, alors pourquoi pas? Quoi qu'il en soit, il y a souvent des mises à niveau du noyau lorsque j'arrive à faire la mise à jour.

Pas vraiment nécessaire, la gestion de la mémoire Linux est excellente. Mais si vous avez des temps de disponibilité de cette durée, vous exécutez probablement des noyaux qui ont des vulnérabilités connues - vous voudrez peut-être regarder cela.

Je pense que vous devriez redémarrer s'il y a eu une mise à jour récente du noyau OU une mise à jour libc. Beaucoup de choses sont liées à libc et il n'est pas vraiment possible de décharger complètement cette lib de la mémoire et de la remplacer par la nouvelle version à moins que vous ne redémarriez.

Par exemple, même des choses de base comme / bin / ls et d'autres choses dans / bin utilisent libc. Si vous exécutez simplement une console et utilisez bash, vous utilisez libc.

$ ldd /bin/bash
        linux-gate.so.1 =>  (0xffffe000)
        libtermcap.so.2 => /lib/libtermcap.so.2 (0xb8029000)
        libdl.so.2 => /lib/libdl.so.2 (0xb8025000)
        libc.so.6 => /lib/libc.so.6 (0xb7ed9000)
        /lib/ld-linux.so.2 (0xb804b000)

$ ldd /bin/ls
        linux-gate.so.1 =>  (0xffffe000)
        librt.so.1 => /lib/librt.so.1 (0xb7f3a000)
        libacl.so.1 => /lib/libacl.so.1 (0xb7f33000)
        libc.so.6 => /lib/libc.so.6 (0xb7de7000)
        libpthread.so.0 => /lib/libpthread.so.0 (0xb7dd0000)
        /lib/ld-linux.so.2 (0xb7f61000)
        libattr.so.1 => /lib/libattr.so.1 (0xb7dcc000)

Et oui, si vous changez des fichiers dans /etc/init.d qui affectent le démarrage d'une manière ou d'une autre, je recommanderais un redémarrage. Vous ne voulez pas savoir que vous avez fait une petite erreur dans un fichier de démarrage lorsque vous avez besoin que les choses soient réactivées rapidement.

Si un serveur est resté plusieurs jours sans redémarrage, cela signifie en fait qu'il n'y a aucun moyen de s'assurer qu'il reviendra correctement. Encore une fois, cela est dû au fait que de nombreux fichiers de configuration peuvent y avoir été modifiés, et personne ne l'a redémarré depuis longtemps pour s'assurer qu'il s'affiche. De plus, si le serveur a beaucoup de mises à jour dues et que vous n'avez pas redémarré depuis longtemps, redémarrez avant d'appliquer les mises à jour, sinon s'il y a un problème, vous ne pouvez pas être sûr qu'il a été causé par une erreur de configuration a il y a longtemps ou les nouvelles mises à jour que vous avez appliquées.

Enfin, si vous redémarrez un serveur critique après une très longue période, le fsck peut signifier que vous devez attendre très longtemps maintenant pour qu'il revienne. Vous pouvez utiliser tune2fs pour éviter cela, mais c'est une bonne idée de le vérifier régulièrement, je suppose. C'est pourquoi vous ne devriez pas être dans une position où vous dépendez d'un seul serveur et si cela se produit, votre site Web entier a disparu. Vous devriez en avoir un autre en attente.

Une autre chose à rechercher tout en ayant ce temps d'arrêt inattendu, est de regarder comment exactement la mémoire et le processeur sont utilisés et par quels programmes. topdevrait être en mesure de déterminer quels processus sont à l'origine de la perte de ressources, puis être en mesure de les gérer directement. Une autre idée serait d'initialiser un cronjob pour arrêter et redémarrer vos processus selon un calendrier spécifique.

Ce n'est pas une mauvaise idée de redémarrer si cela fait si longtemps que vous pouvez exécuter une vérification du disque (fsck) sur la partition racine. Votre argument peut être que cela contribue à garantir l'intégrité des données.

Un serveur Linux correctement exécuté ne doit être redémarré que pour les mises à jour du noyau. La même chose ne peut pas toujours être dite pour certains logiciels - par exemple, je dois parfois redémarrer apache2 ou mailman.

Mon infrastructure dispose de deux sites de données, l'alpha (où les opérations ont lieu quotidiennement) et la bêta (le site de sauvegarde, au cas où les choses tournent mal à alpha). Bien que ce ne soit pas le cas actuellement, je fais pression pour avoir des arrêts planifiés sur le site alpha tous les 6 mois, afin que nous puissions exécuter tous les services à partir de la version bêta.

Cela accomplira deux choses. Tout d'abord, cela prouvera que notre site de reprise après sinistre est complètement viable. Deuxièmement, cela me donnera une semaine de temps pour éliminer la cruauté accumulée à l'alpha.

En l'état, je ne redémarre pas mes serveurs aussi souvent que je le devrais. Je suis d'accord avec les autres affiches qui ont dit qu'il est important de savoir que vos serveurs reviendront quand vous en aurez besoin. Vous ne voulez pas "penser" qu'ils le feront, seulement pour découvrir que vous avez changé quelque chose et que vous ne l'avez pas fait correctement ou que vous ne l'avez pas documenté.

Vous pouvez également écrire des scripts qui vérifieront (autant que possible) si l'état actuel de votre machine sera l'état de la machine après le redémarrage.

Ce que je veux dire par là, c'est ...

• /etc/init.d/*
  • Vérifiez que tous les services en cours d'exécution sont marqués pour démarrer au démarrage
  • Vérifiez que tous les services non exécutés sont marqués pour ne pas démarrer au démarrage
• /etc/fstab
  • Vérifiez que tous les systèmes de fichiers montés (c'est-à-dire /etc/mtab) ont une entrée correspondante dans/etc/fstab
  • Vérifiez que tous les systèmes de fichiers spécifiés pour être montés au démarrage /etc/fstabsont également actuellement montés.

Ce n'est bien sûr pas une vérification complète, mais cela réduit le risque de problèmes après le redémarrage.

En plus de cela, vous devez (imo) définir une politique pour les mises à jour des packages serveur, dans un ordre raisonnable, disons 1 groupe par semaine ...

• Serveurs Crash & Burn
• Serveurs de développement, serveurs de formation
• Serveurs de test
• Serveurs de pré-production
• Serveurs de production

Ayez également un plan global, tel que "Tous les serveurs subiront une mise à niveau complète du système d'exploitation une fois tous les 6 mois".

Dépend des tâches exécutées sur le serveur. Pour certains serveurs virtuels, nous utilisons souvent le redémarrage au lieu de redémarrage apachectl et cela prend seulement 5-10 secondes de plus. Mais certaines machines lourdes sont redémarrées plusieurs fois par an avec toute une équipe d'administration surveillant le processus.