Avantages et inconvénients des redémarrages réguliers du serveur [fermé]

Question

Dans les oreilles de plusieurs équipes, j'ai rencontré plusieurs gestionnaires d'infrastructure qui ont mis en place une stratégie de redémarrage hebdomadaire du serveur. En tant que développeur, j'ai toujours été contre la politique. Il semble que ce soit un hack de contourner les bugs logiciels et les instabilités matérielles au lieu de les corriger.

Quelles sont les opinions des personnes, les points positifs et négatifs concernant la politique?

Answer 1

Si vous redémarrez vos serveurs de temps en temps, vous pouvez être sûr qu'ils vont revenir. Bien que cela puisse sembler excessif chaque semaine, j’ai vu ce problème sur des machines Linux avec de longues périodes de disponibilité.

Quelqu'un n'a pas pris la peine de configurer un service essentiel pour qu'il démarre automatiquement au démarrage. Ou l'ordre des services à venir est faux. Ou quelqu'un a mis à jour des bibliothèques, ajouté / supprimé des logiciels, etc. et l'exécutable ne fonctionne plus (il a été démarré avec les anciennes bibliothèques et a continué de les utiliser; maintenant, une erreur de l'éditeur de liens dynamique s'est produite). Ou alors, le service A dépend du service B et le service B dépend du service A (oops).

À un moment donné, lorsque vous le moins , vous redémarrerez. La colo va laisser tomber le pouvoir sur vous; les alimentations du serveur échoueront; quelqu'un tirera le cordon / appuiera sur le bouton de réinitialisation du mauvais serveur; etc. Maintenant, quand vous pouvez vous permettre moins de temps d'arrêt, votre serveur sanglant ne reviendra pas.

Tout comme les logiciels, les configurations système doivent être testées. La fréquence à laquelle vous devez effectuer ce test dépend de la manière dont vos boîtes sont administrées.

Answer 2

C’est une politique stupide.

Voici pourquoi:

• Si vous devez redémarrer un serveur chaque semaine (et que cela ajoute à la stabilité de votre infrastructure), vous couvrez le véritable problème d'un serveur ou de son logiciel. Une fuite de mémoire? Un mauvais conducteur? La solution à ces problèmes consiste à les corriger et non à les couvrir avec une stratégie paresseuse.

• Les serveurs sont souvent redémarrés pour les mises à jour, du moins dans le monde Windows. Le redémarrage pour les mises à jour critiques du noyau se produit quand même.

• Les serveurs de base de données mettent en cache beaucoup d'informations dans la RAM. Lorsque vous redémarrez votre serveur, ce cache devient vide et très froid. En supposant que vous utilisiez un modèle d'utilisation typique, un cache froid et vide ralentira les performances des utilisateurs qui tenteront de répondre à leurs requêtes après un redémarrage. Cela pourrait également augmenter le temps nécessaire pour effectuer certains types de maintenance, telles que les sauvegardes, car il faudra peut-être plus accéder au disque.

• Vos serveurs tombent en panne! Vos fenêtres de maintenance pour les sauvegardes et autres choses sont raccourcies car votre serveur est éteint pendant une période non nulle. Il se peut également que vous deviez informer vos utilisateurs que vous aurez des temps d'arrêt, en fonction de l'architecture de vos systèmes.

• En supposant que vous disposiez d'une sorte de système de notification pour alerter, vous devrez le configurer pour ignorer votre fenêtre d'indisponibilité. Cela peut masquer les problèmes qui surviennent au moment du redémarrage de votre serveur et ajoute à la quantité de configuration que vous devrez effectuer sur vos serveurs.

Cela étant dit, les redémarrages sont parfois bénéfiques en dernier recours sur des ressources sur lesquelles vous n'avez pas nécessairement le contrôle total (ancien logiciel écrit par le fournisseur, dispositifs "boîte noire" lorsque explicitement prescrits par le fournisseur, etc.). .) Mais cela devrait être traité au cas par cas, et non avec une politique générale naïve.

Answer 3

Toutes mes excuses pour avoir dépoussiéré un ancien fil de discussion.

Je pense que tout le monde passe à côté de la question, en particulier le redémarrage «hard-hard»? Je préférerais vendre mon commodore! Nix administrateurs.

Le fait est qu'une fenêtre hebdomadaire devrait être PLANIFIEE. Cela ne veut pas dire qu’il doit être utilisé, mais en fait, il est préférable de ne pas l’utiliser car il est inévitablement utilisé à une heure donnée du matin.

Mais si c'est là, vous pouvez l'utiliser.

Personnellement, je pense qu’un redémarrage trimestriel est une très bonne idée. Il peut vous donner une idée des problèmes (matériels et logiciels) et, comme l’a souligné l’autre affiche la plus avant-gardiste, vous informe des changements qui empêchent toute démarrage qui ne devient apparent qu'après un redémarrage. Plutôt que d'avoir la situation qui se présente après une coupure de courant de 4 heures, prendre encore 2 heures pour amener votre boîte devient vraiment assez gênant ....

Il y a d'autres aspects positifs ..

• La direction est habituée à redémarrer et vous avez l'assurance de le redémarrer (par exemple, en le déplaçant physiquement). Si vous ne redémarrez jamais une boîte, votre responsable va être assez nerveuse quand vous dites qu'elle doit être redémarrée après 4 ans et qu'il n'y a pas de temps mort.

• Vous vous habituez vous-même à redémarrer et savez ce qui peut mal se passer quand il est hors ligne.

• Vous savez combien de temps prend le redémarrage. Ainsi, lorsqu'il revient 10 minutes plus longtemps que d'habitude, vous êtes directement dans les journaux.

• Si vous êtes renversé par un bus demain, il existe une documentation ACTUELLE (non âgée de 4 ans) sur ce qui se produit lorsqu'un redémarrage a lieu (en supposant que vous soyez un bon administrateur et que vous notiez des choses)

• Un redémarrage de 30 minutes par trimestre correspond parfaitement à 99,9% des contrats de niveau de service (SLA).

• Enfin, il efface les toiles d'araignées proverbiales.

Pour répondre à certains points CONTRE le redémarrage normal ..

• C’est hilarant de couvrir un mauvais pilote avec une fuite de mémoire, etc. Comment savez-vous que c’est une fuite de mémoire \ mauvais pilote à moins de redémarrer le serveur? Non seulement cela, mais que se passe-t-il si vous ne parvenez pas à résoudre ce problème dans le temps mort prévu? Si vous avez une fenêtre hebdomadaire, ce n'est pas un problème! Vous venez d’essayer de nouveau la semaine prochaine ....

• Système de notification - si vous avez une fenêtre planifiée, vous pouvez définir une exception planifiée. Si votre logiciel \ script ne le fait pas, je suggère alors un logiciel moderne \ meilleure écriture de script.

• En ce qui concerne la fenêtre d’exception planifiée, les problèmes de masquage qui se produisent pendant la fenêtre d’exception planifiée sont tout à fait ridicules. Les autres statistiques de votre serveur afficheront très rapidement ce problème si vous les examinez.

Bien entendu, une stratégie globale n'est pas recommandée et vous devez définir des critères d'exception (par exemple, de l'espace disque d'une certaine taille, etc.)

Cela étant dit, le résultat final est simplement parce que votre serveur ne devrait pas avoir besoin d'être redémarré, il est incroyablement naïf de penser que vous ne devriez pas le redémarrer ....

Modifier:

Je ne suis pas sûr d'avoir bien expliqué cela, mais le redémarrage ne doit PAS être utilisé pour résoudre un problème. La fenêtre doit être hebdomadaire pour que vous ayez plusieurs tentatives pour résoudre le problème, pas pour "vivre avec".

Le redémarrage en tant que méthode permettant de traiter un problème sur un serveur est un administrateur système médiocre. Rien n’est appris, cela fait perdre un temps précieux aux gens et diminue (à juste titre) l’opinion de la direction sur vous.

Mon point est

• Il est difficile de vous assurer de résoudre un problème sans une fenêtre de maintenance acceptée, planifiée et hebdomadaire en place.
• Avec une fenêtre hebdomadaire, vous avez la possibilité en permanence de régler correctement les problèmes et d'éviter la situation dans laquelle vous avez une demi-douzaine de solutions de contournement truquées sur autant de serveurs différents.

Answer 4

Répondant à ma propre question: l'un des avantages de la stratégie est son application à un cluster de serveurs et le basculement des processus d'un nœud à un autre. De cette manière, tous les nœuds sont constamment testés pour la bonne installation du logiciel.

Answer 5

Nos serveurs sont tous des serveurs Linux au travail. Nous ne redémarrons jamais et n'avons jamais eu de problèmes. Je conviens que c’est au mieux un bidouillage, et je pense aussi que cela a probablement un rapport avec la première réponse que les gens donnaient toujours lorsqu’ils supportaient des problèmes Windows: "Avez-vous redémarré votre ordinateur?"

Maintenant, pourquoi cela pourrait être bénéfique, vous pouvez avoir des applications qui entrent dans un état étrange ou qui ont des fuites de mémoire qu'un redémarrage résoudrait.

Un gros inconvénient pour moi est que vous devez planifier des temps d'arrêt hebdomadaires des serveurs. Pour certains, ce n'est pas un problème et pour d'autres, c'est un problème énorme.

Answer 6

Évidemment, si la source d’un problème ne peut pas être résolue rapidement, il faut contourner le problème. Planifier un redémarrage pour y remédier est un moyen simple de sauver l'entreprise si cela fonctionne.

Bien sûr, cela fait mal mentalement et ne devrait pas être nécessaire et il serait préférable de travailler contre une telle solution, en particulier si vous maîtrisez le logiciel problématique ou si vous êtes en mesure de critiquer les producteurs pour une solution ou tout simplement le remplacer. Mais sinon ..?

Je me souviens de l'avoir fait pour les serveurs d'une batterie Citrix. À la fin, ils étaient redémarrés toutes les nuits avec un script compliqué attendant que les utilisateurs se déconnectent, verrouillant les connexions sur des serveurs spécifiques, puis redémarrant ceux qui étaient libres. La raison en était une ancienne application cliente 16 bits 4GL dont nous ne pouvions tout simplement pas nous débarrasser et qui tendait à couper la réactivité globale de l'utilisateur après quelques jours de disponibilité.

Je conviens cependant que cela semble être principalement basé sur le fait de ne pas être assez intelligent pour comprendre la cause et le réparer - tout le monde n’est pas aussi expérimenté en maintenance ou motivé que nous le souhaiterions.

Answer 7

C’est vraiment un hack, mais c’est peut-être le hack le plus efficace. C'est un problème de type 80:20 où vous pouvez résoudre 80% du problème avec 20% de l'effort. Si vous pouvez survivre au temps d'immobilisation ou que le temps d'immobilisation vous coûte moins cher que de réparer réellement la cause fondamentale, c'est une bonne solution. Personnellement, je n'aime pas ça, mais c'est seulement parce que ce n'est pas une solution propre.

Answer 8

Une autre possibilité à considérer est que, dans certains environnements, tels que les magasins de vente au détail ouverts 24h / 24, un "magasin fermé". événement afin que les serveurs puissent être mis à jour, sauvegardés, etc.

Même si les serveurs doivent exécuter "24x7", ils sont vraiment hors ligne pendant au moins quelques minutes chaque jour.

Cela permet effectivement à un serveur de redémarrer tous les jours, même si le magasin fonctionne toujours quand cela se produit.