ClickCease 5 façons de réduire les temps d'arrêt des serveurs (et 1 façon de les éliminer) - TuxCare

Rejoignez notre populaire bulletin d'information

Rejoignez 4 500+ professionnels de Linux et de l'Open Source !

2 fois par mois. Pas de spam.

5 façons de réduire les temps d'arrêt des serveurs (et 1 façon de les éliminer)

7 septembre 2020 - L'équipe de relations publiques de TuxCare

5 façons de réduire les temps d'arrêt des serveurs (et 1 façon de les éliminer)

Le redémarrage des serveurs vous nuit et nuit à vos clients. Il est souvent effectué pendant les heures creuses (généralement la nuit), lorsque les serveurs traitent moins de transactions, mais même le redémarrage à ce moment-là coûte des milliers de dollars en temps d'arrêt. Le redémarrage d'un serveur peut prendre de quelques minutes à plus d'une heure selon la configuration, et la synchronisation des services peut prendre plus de temps. En fait, 25 % des organisations déclarent à l'adresse que les temps d'arrêt leur coûtent entre 300 000 et 400 000 dollars pour chaque heure d'indisponibilité des serveurs. Les temps d'arrêt peuvent être évités et les redémarrages dus aux correctifs peuvent être complètement éliminés.

Contenu :

  1. Qu'est-ce qu'un temps d'arrêt du serveur et quand cela se produit-il ?
  2. Coûts des temps d'arrêt pour les organisations
  3. Planification des temps d'arrêt : Planification et exécution de la maintenance
  4. Comment réduire au minimum les temps d'arrêt des serveurs

 

 

Qu'est-ce qu'un temps d'arrêt du serveur et quand cela se produit-il ?

 

Qu'est-ce qu'un temps d'arrêt du serveur et quand cela se produit-il ?

Les serveurs tombent en panne pour diverses raisons, mais la panne d'un serveur n'est pas toujours synonyme de temps d'arrêt. Le temps d'arrêt est beaucoup plus critique pour une organisation, car il signifie qu'un point de défaillance unique a été ignoré ou négligé, ou que les systèmes de basculement n'ont pas été en mesure de prendre le relais de manière transparente. Google a hébergé une vidéo sur les les dix principales raisons des temps d'arrêt des serveurs. Nous résumons ci-dessous cette vidéo de 50 minutes.

 

Surcharge des ressources

Lorsque les demandes du serveur dépassent les ressources disponibles, les performances en pâtissent et le serveur finit par tomber en panne. Les serveurs en nuage peuvent étendre les ressources de manière dynamique, mais les administrateurs sur site responsables de ces serveurs en nuage doivent toujours s'assurer que les serveurs peuvent prendre en charge les applications des clients et les extensions de ressources.

 

Voisin bruyant

Le problème du "mauvais voisinage" concerne principalement les hébergeurs de nuages offrant des services d'hébergement partagé. Lorsqu'un client utilise une trop grande partie des ressources d'un serveur, cela affecte les performances des autres sites clients. La plupart des hôtes déplaceront le "voisin bruyant" hors des services partagés pour contrôler le problème ou limiter les ressources disponibles pour un client problématique.

 

Pics de réessayage

Qu'il s'agisse d'un serveur surchargé ou d'une application malveillante, lorsque les utilisateurs ne parviennent pas à se connecter à un serveur, ils essaient souvent plusieurs fois avant d'abandonner. Ajoutez à cela des milliers d'utilisateurs effectuant plusieurs fois les mêmes tentatives et vous obtenez un serveur qui tombe en panne à cause des pics de tentatives. Les administrateurs peuvent configurer les serveurs pour qu'ils rejettent les tentatives de connexion agressives afin de réduire les pics de tentatives.

 

Dépendances, correctifs ou applications bogués

De mauvaises habitudes en matière de correctifs, des logiciels obsolètes, des dépendances lentes et de nombreux autres problèmes liés aux applications exécutées sur le serveur peuvent provoquer des temps d'arrêt. Les administrateurs ne peuvent pas se contenter d'installer des correctifs et de redémarrer sans discernement. Ils doivent planifier l'installation des correctifs et des mises à jour et redémarrer pendant les heures creuses. Les correctifs en direct peuvent être utiles (nous y reviendrons plus tard).

 

Mise à l'échelle par des tiers

Vos serveurs sont peut-être capables d'évoluer, mais les API tierces utilisées pour le traitement des applications ne le sont peut-être pas. Google recommande le "sharding", qui consiste à diviser les processus cohérents de grande taille en morceaux afin de réduire les frais généraux.

 

Sharding inefficace

Le sharding améliore les performances, mais lorsqu'un shard est trop grand par rapport aux autres, le sharding est inégal. Pour remédier à ce problème, Google recommande de diviser les grands shards en plusieurs shards encore plus petits.

 

Erreurs humaines

Certaines procédures du serveur comportent trop d'implication humaine. Sans automatisation, des erreurs humaines peuvent se produire. Par exemple, le fait de compter sur le personnel informatique pour appliquer manuellement les correctifs et mettre à niveau les serveurs entraîne souvent des erreurs et des temps d'arrêt. La gestion des correctifs et l'automatisation réduisent considérablement les erreurs humaines en ne demandant l'intervention des administrateurs que lorsqu'un problème est détecté.

 

Déploiements de mauvais code

Pour les organisations disposant d'applications internes, les tests sont essentiels pour garantir que le code déployé ne présente pas de problèmes. En plus des tests lourds et des procédures d'assurance qualité (AQ), un processus de retour en arrière doit toujours être développé. 

 

Suivi insuffisant

La plupart des administrateurs savent que la surveillance est essentielle. C'est également un élément de la conformité réglementaire. Une seule configuration ou un seul serveur oublié dans une stratégie de surveillance expose l'organisation à des lacunes en matière de surveillance. L'audit du réseau pour s'assurer que chaque ressource est ajoutée aux applications de surveillance permet d'éviter ce problème.

 

Domaines et infrastructures mal configurés

La connectivité à une ressource serveur ne provient pas toujours de problèmes liés à la machine locale. Un domaine défaillant peut entraîner un temps d'arrêt du serveur car les clients ne peuvent pas se connecter aux serveurs. Le basculement et les tests avant le déploiement des changements de configuration permettront d'éviter ce problème.

 

 

Coûts des temps d'arrêt pour les organisations

 

Coûts des temps d'arrêt pour les organisations

Quelle qu'en soit la cause, la principale préoccupation des entreprises est l'argent perdu pendant (et après) les temps d'arrêt. Les transactions ne peuvent pas être traitées, et elles pourraient être perdues dans le vide sans systèmes de reprise en place. La frustration des clients est un autre problème majeur qui peut entraîner une perte de revenus en raison de la perte de clients et des dommages à la marque, car les temps d'arrêt affectent la réputation.

Dans un récent rapport de Ponemon rapportles entreprises subissent 30 % de temps d'arrêt en plus en raison d'une mauvaise gestion des correctifs et de retards dans la correction des vulnérabilités. Parmi les entreprises interrogées, 52 % ont déclaré qu'elles n'avaient aucune tolérance pour les temps d'arrêt, y compris les redémarrages dus aux correctifs et aux mises à jour du système d'exploitation. Les petites entreprises souffrent davantage que les grandes, car elles ne disposent pas des ressources et de l'automatisation nécessaires pour gérer les correctifs de vulnérabilité, ce qui entraîne une augmentation des temps d'arrêt.

Parmi toutes les causes de temps d'arrêt mentionnées ci-dessus, l'erreur humaine et les mauvais déploiements de correctifs peuvent être complètement éliminés grâce à l'automatisation des correctifs. Les redémarrages peuvent être complètement éliminés grâce à l'application de correctifs en direct. Les organisations dépensent 1,4 million de dollars par an pour la gestion des vulnérabilités, mais la gestion et l'automatisation des correctifs réduisent considérablement les frais généraux du personnel, les coûts des temps d'arrêt et même les problèmes de redémarrage.

 

Planification des temps d'arrêt - Planification et exécution de la maintenance

Planification des temps d'arrêt : Planification et exécution de la maintenance

À un certain moment de la vie d'un serveur, les administrateurs doivent prévoir des temps d'arrêt. Il peut s'agir du déploiement d'un code, d'une modification du matériel du serveur, d'un changement de configuration ou d'un passage d'un ancien serveur à un nouveau. La maintenance planifiée est généralement exécutée pendant les heures creuses, mais quelques mesures peuvent être prises pour réduire les temps d'arrêt.

  • Assurez-vous que les sauvegardes sont récentes, fonctionnelles et disponibles.. Si vous devez effectuer un retour en arrière critique qui interrompt le service et que vous avez besoin de sauvegardes, assurez-vous qu'elles sont disponibles afin qu'elles puissent être extraites et déployées plus rapidement.
  • Vérifier l'utilisation du disque. Pour les petites entreprises dont les serveurs utilisent des ressources limitées, vérifiez toujours que l'espace disque est disponible pour les mises à jour. Un disque plein donnera des résultats inattendus et entraînera une forte dégradation des performances.
  • Vérifier l'utilisation des ressources du serveur. En plus de vérifier l'espace de stockage, assurez-vous que le serveur n'a pas de pics de CPU ou de mémoire qui pourraient interférer avec une mise à jour ou un changement de configuration réussis.
  • Testez avant de déployer tout changement. Cela peut sembler être du bon sens administratif, mais de nombreux changements de configuration ou mises à jour "rapides et faciles" entraînent des temps d'arrêt et les administrateurs omettent de tester les petits changements. Les administrateurs pensent qu'un petit changement ne peut pas causer de problèmes, mais le risque est toujours présent. Testez toujours les modifications apportées à un serveur de production dans un environnement de test.

 

Comment réduire au minimum les temps d'arrêt des serveurs

5 façons de réduire les temps d'arrêt des serveurs (et 1 façon de les éliminer)

Un temps d'arrêt inattendu du serveur est beaucoup plus dommageable pour une organisation qu'une maintenance planifiée. Les administrateurs doivent disposer d'un plan de sauvegarde et de retour en arrière et être prêts à faire face à des problèmes lors d'une maintenance planifiée, mais les temps d'arrêt imprévus nécessitent une analyse des causes profondes et les ressources nécessaires pour remettre le serveur en service. Les administrateurs doivent prendre des mesures préventives pour s'assurer qu'un serveur subit le moins de temps d'arrêt possible. Voici quelques bonnes pratiques pour aider à réduire les temps d'arrêt :

 

Sécurité

La cybersécurité est d'une importance capitale pour la fiabilité et la disponibilité des serveurs. Les administrateurs qui travaillent avec des serveurs destinés au public seront confrontés à de nombreuses analyses de vulnérabilité, tentatives d'exploitation et trafic suspect qui doivent être surveillés. Toute vulnérabilité signalée publiquement sera suivie d'exploits et d'attaques sur le serveur. Les administrateurs doivent donc prendre des mesures immédiates et appliquer des correctifs au système. Les temps d'arrêt dus à une violation de données entraînent des pertes de revenus et des problèmes d'entreprise bien plus importants que le simple coût d'un redémarrage.

 

Surveillance des serveurs

Pour les organisations comptant des centaines de serveurs, il est facile d'en oublier un seul. L'audit du réseau et l'identification de chaque serveur permettent de s'assurer que les serveurs font l'objet d'une surveillance adéquate, non seulement en cas de panne, mais aussi en cas de pics de ressources et d'inefficacités (par exemple, le refroidissement) qui pourraient entraîner une panne lente. Tout problème doit être signalé aux administrateurs, y compris par des messages texte en cas d'erreurs critiques. La surveillance proactive permet d'alerter les administrateurs des pannes en cours, qu'elles soient virtuelles ou physiques, afin qu'ils puissent remédier au problème avant qu'il n'entraîne un temps d'arrêt.

 

Retirer les serveurs inefficaces

Les serveurs plus anciens sont beaucoup plus susceptibles de tomber en panne, de sorte qu'un serveur doit être mis hors service. Il n'est pas rare que les administrateurs mettent à jour le matériel, mais il n'est pas rentable de toujours le faire. Ces serveurs peuvent consommer plus d'énergie et avoir un effet en cascade sur les performances de l'environnement.

 

Optimiser le refroidissement

La chaleur et l'humidité détruisent lentement les équipements des serveurs. Avec la mise en place d'une surveillance, ces facteurs environnementaux seront détectés avant qu'ils ne détruisent l'équipement et que les serveurs ne subissent une défaillance matérielle. Un système de refroidissement adéquat doit être installé dans toutes les salles de serveurs, et un système de secours doit être mis en place en cas de défaillance du refroidissement primaire.

 

Effectuer des tests de charge

L'utilisation d'un équilibreur de charge pour répartir la charge sur plusieurs serveurs contribue à améliorer les performances, mais que se passe-t-il si plus d'un serveur tombe en panne ? Avec les tests de charge, vous savez comment les serveurs se comporteront après la défaillance de ressources partielles. Cela peut entraîner le provisionnement de serveurs supplémentaires ou l'ajout de ressources aux serveurs existants. Pour tout serveur critique, il faut toujours surestimer les limites de capacité afin de s'assurer que suffisamment de ressources sont disponibles pour évoluer et se développer.

 

Automatisation des correctifs et correctifs en direct

L'application manuelle de correctifs entraîne des erreurs humaines et la disparition d'importantes alertes de vulnérabilité. Les organisations devraient plutôt utiliser l'automatisation des correctifs. Même avec l'automatisation des correctifs, la mise à jour du noyau Linux nécessite toujours un redémarrage, jusqu'à présent. Avec KernelCare et KernelCare + pour les bibliothèques partagées, les administrateurs peuvent mettre à jour leurs systèmes sans redémarrer le serveur. Le patching en direct élimine complètement la nécessité d'une maintenance planifiée et d'un temps d'arrêt pour les mises à jour du noyau. Par exemple, HostUS utilise KernelCare et a récemment retiré un serveur qui n'avait pas été redémarré pendant 5,5 ans.

Conclusion

Les temps d'arrêt des serveurs sont extrêmement coûteux, mais ils peuvent être réduits grâce aux bonnes pratiques. La plupart des temps d'arrêt dus à des erreurs inattendues peuvent être évités, mais tout temps d'arrêt dû à l'application de correctifs peut être complètement éliminé grâce aux correctifs en direct de KernelCare. Pour voir ce que KernelCare peut faire pour vos serveurs, inscrivez-vous gratuitement et commencez à travailler. 

Vous cherchez à automatiser la correction des vulnérabilités sans redémarrage du noyau, temps d'arrêt du système ou fenêtres de maintenance programmées ?

Découvrez le Live Patching avec TuxCare

Devenez rédacteur invité de TuxCare

Commencer

Courrier

Rejoindre

4,500

Professionnels de Linux et de l'Open Source
!

S'abonner à
notre lettre d'information