|
Avertissement
Ce document s'adresse aux personnes possédant les
connaissances de base du fonctionnement interne des systèmes d'exploitation, et peut
s'avérer d'une lecture assez ennuyeuse pour les autres :)
Introduction
iskd est l'un des programmes que nous avons développé en interne pour automatiser
certaines tâches dans la gestion quotidienne de nos serveurs mutualisés.
Son rôle est crucial, puisque il assure la surveillance constante des performances
et de l'intégrité du système d'exploitation Linux.
Si il détecte une anomalie, sont rôle est double : résoudre le problème et donner l'alerte.
Deux niveaux de limites sont configurables pour chaque vérification : une limite soft, assez élevée, utilisée
lorsque la charge du système est faible, et une limite hard, plus stricte, qui devient prioritaire lorsque
la charge système est élevée. A chaque fois qu'une action est effectuée par le programme, elle fait l'objet d'un rapport incluant l'état du système (liste des processus en cours, charge, utilisation mémoire, utilisateurs connectés au moment des "faits", swap, etc...)
Dans le jargon des systèmes d'exploitation, le terme processus définit un programme chargé en mémoire,
en cours d'exécution ou en attente d'exécution.
iskd est un daemon, c'est à dire un programme résidant en mémoire en permanence et effectuant des actions de manière autonome.
Par défaut, le programme vérifie l'état du système toutes les 30 secondes.
Lors de chaque boucle, il enregistre un instantané de l'état du système, qui sera comparé
avec les valeurs actualisées lors de la prochaine boucle. Cela permet de détecter certaines
anomalies qui sont uniquement visibles sur de longues périodes, comme l'augmentation progressive
de l'occupation mémoire d'un groupe de scripts CGI.
Fonctionnalités
Voici un résumé des fonctionnalités principales d'iskd :
 Utilisation mémoire des processus utilisateurs (scripts, etc...), avec liste d'exclusion. Par exemple, si un script lancé en CGI ou en shell décide de bugger et de s'approprier de grandes quantités de mémoire, il est détecté en 30 secondes maximum et arrêté via un signal 9. Une précision utile : les programmes lancés par les utilisateurs ne peuvent de toute façon pas utiliser plus de 32 Mo de RAM sur le serveur, car ils sont limités par la configuration ulimit.
Utilisation mémoire des processus du serveur web Apache. Les processus Apache ont tendance à grossir de façon démesurée lorsqu'ils sont utilisés avec certains modules. Cette fonctionnalité d'iskd permet de les arrêter automatiquement si leur taille dépasse un certain seuil. Ils seront ensuite automatiquement redémarrés par le processus maître Apache, qui lui n'est bien sûr jamais arrêté de cette façon.
Nombre total de processus actifs. Si le nombre total de processus sur un serveur franchit une certaine limite, une alerte est envoyée aux techniciens et le système passe en mode "charge élevée" : seules les limites hard sont prises en compte.
Nombre de processus actifs par utilisateur, avec prise en compte de la charge système. Si un utilisateur a lancé trop de processus, les processus surnuméraires sont arrêtés, en commençant par les plus récents (les derniers lancés).
Cycles CPU qu'un processus peut consommer sur une période d'une minute (configurable), avec liste d'exclusion et détection des processus en priorité basse (niced). Si un processus utilise plus de temps machine que le maximum configuré, il est arrêté via un signal 9. Nous pouvons exclure certains processus vitaux (init, par exemple). Les processus lancés en priorité basse peuvent également être exclus, ce qui permet de ne pas arrêter les processus tar lors de backups, par exemple.
Utilisation de la mémoire virtuelle (swap), avec deux seuils d'action configurables. Par exemple, 33% d'utilisation déclanche une alerte, et le passage à 50% d'utilisation en moins de 5mn peut déclancher un reboot ou bien l'arrêt temporaire du serveur Apache.
Espace libre sur les partitions. Si l'espace disponible sur une partition devient insuffisant, le programme génère une alerte et peut décider de suspendre temporairement certains services pour éviter les pertes de données.
Charge système moyenne ("load average"), avec action configurable en cas de dépassement durant une période prédéfinie. L'une des fonctionnalités les plus utiles d'iskd. Si le seuil limite est dépassé, le système entre en mode "charge élevée" et des actions prédéfinies peuvent êtres déclanchées (redémarrage d'Apache, arrêt de certains scripts CGI, blocage d'une base de données, etc...).
Temps de réponse du serveur Apache (httpd), avec délai d'expiration déclanchant une action. Si le temps de réponse du serveur Apache est trop élevé, par exemple plus de 20 secondes durant 2 minutes avec 4 essais infructueux consécutifs, le programme envoi une alerte et peut prendre la décision de redémarrer le serveur Apache dans un premier temps, puis la machine elle-même si ce remède est insuffisant.
Grâce à sa conception entièrement modulable et configurable, chaque limite, fréquence et action peut être adaptée aux type de sites hébergés sur un serveur.
L'autre facette d'iskd est sa capacité à collecter des données afin de générer des statistiques. Notamment :
Le pourcentage d'utilisation des processeurs.
Le pourcentage d'utilisation de la mémoire vive et virtuelle.
Les temps de réponse vers le routeur passerelle.
Le nombre de connexions simultanées à un serveur MySQL.
Le nombre moyen de requêtes par seconde à un serveur MySQL.
Le nombre de connexions FTP.
Le nombre de connexions au serveur web Apache.
La charge moyenne ("load average").
Le nombre d'emails envoyés par période.
Le nombre de connexions TCP simultanées.
Le nombre de pointeurs de fichiers utilisés / disponibles.
Toutes ces données, une fois affichées sous forme de graphiques, nous permettent d'une part de déterminer rapidement la cause d'un disfonctionnement, mais également de disposer d'un historique allant jusqu'à un an, ce qui permet de planifier plus efficacement le taux d'occupation des serveurs ("capacity planning").
Par exemple, le graphique ci-dessous montre le pourcentage d'utilisation de la mémoire d'un serveur sur une
période d'une journée (entre les barres rouges). Les valeurs grises indiquent le
pourcentage d'utilisation de la mémoire physique, et les valeurs oranges celui de la mémoire virtuelle (swap).
Le pic entre 4:00 et 5:00 correspond au transfert des données sur un serveur de backup, et le creux vers 21:45 à un redémarrage du serveur Apache.
D'autres outils...
En complément d'iskd, nous avons mis au point un système d'alerte avancé baptisé issw, qui repose sur deux serveurs dédiés : l'un situé à l'intérieur de notre réseau, et l'autre à l'extérieur. La qualité de la connectivité de nos serveurs est testée toutes les 60 secondes depuis ces deux machines, et en cas d'incident (connexion impossible ou délai trop élevé) des alertes sont acheminées par appel téléphonique directement sur les portables des techniciens d'astreinte, ainsi que par email.
Pourquoi pas par SMS ? Tout simplement
parce que le protocole de transport des SMS ne garantit pas les délais d'acheminement, ni n'informe l'expéditeur de la délivrance des messages.
Lors de la phase de test, nous recevions parfois les messages SMS plusieurs heures après leur envoi, même en restant sur le réseau d'un même opérateur.
D'autres outils sont actuellement en cours de développement, notamment un programme de vérification de l'intégrité des bases MySQL (avec réparation ou restauration automatique), ainsi qu'un programme de vérification de l'état du matériel, via l'utilisation des standards S.M.A.R.T et SMBus.
Conclusion
Une forte expérience dans l'activité d'hébergement nous a permis de développer des solutions fiables et efficaces pour l'administration de nos serveurs.
Ces technologies sont réellement utiles et profitables à nos clients : les périodes d'indisponibilité ou durant lesquelles le service est dégradé sont
réduites au strict minimum, et le temps normalement alloué aux tâches d'administration répétitives est limité, ce qui nous permet de consacrer l'essentiel de notre temps au
support client et au développement de nouveaux services.
|
Retour aux 