Je pense que beaucoup d'administrateurs système craignent la planification de la capacité ou pensent simplement que c'est inutile. Premièrement, il n'y a aucune raison de craindre la planification des capacités (ce n'est pas sorcier); et deuxièmement, la planification des capacités est 100 % nécessaire. Dans le passé, les administrateurs système devaient faire face à la prise de décisions radicales par la direction pour ajouter de la capacité et améliorer les performances, soit en ajoutant de nouveaux systèmes au mélange, soit en ajoutant un processeur, de la RAM ou un stockage plus rapide. Habituellement, mais pas toujours, le problème persistait au-delà des mises à niveau et de la capacité supplémentaire. Mais le qualificatif « habituellement » est la partie de l'équation qui bloque les administrateurs système et les gestionnaires, au point que personne ne veut s'occuper de la planification et de l'administration réelles de la capacité et des performances.
Ce problème ne doit pas être une lutte. Dans cet article, je présente cinq choses que vous devez savoir pour vous lancer dans la planification de la capacité Linux. Vous pouvez également appliquer ces directives à n'importe quel environnement :Linux, Windows, Unix ou une version hybride de ceux-ci.
Principes de base de la planification des capacités
Lorsque vous discutez de capacité, vous discutez vraiment de performance. La capacité et la performance sont toujours mentionnées ensemble. Vous devez mesurer et surveiller les performances pour effectuer toute sorte de planification de la capacité. La capacité signifie la capacité de traiter et de stocker des données sans goulots d'étranglement ni impact sur l'utilisateur final. La plupart du temps, les administrateurs système pensent aux performances en termes de traitement de données pour les sites Web, les bases de données ou les applications. Mais ce n'est pas là que la performance s'arrête. Pensez aux performances de sauvegarde et de restauration. Les sauvegardes nécessitent une compression, une déduplication, un transfert de disque à disque ou un transfert sur le réseau. Et n'oubliez pas que le déplacement de machines virtuelles d'un hôte à un autre nécessite une capacité de calcul, de stockage ET de réseau.
Votre conclusion ici est la suivante :la capacité et les performances sont trop étroitement liées pour les séparer en différentes conversations. Examinons les étapes de ce processus.
Tout d'abord :obtenez une ligne de base
Peu importe que vos systèmes soient neufs ou vieux de trois ans, vous devez établir une base de référence avant de pouvoir commencer la planification et la projection de la capacité. L'établissement d'une ligne de base prend un peu de temps car une ligne de base n'est pas un instantané, c'est plutôt une vue à plus long terme des performances. Utilisez au moins une ligne de base d'un mois pour chaque système. Un mois de données devrait vous donner la plage de performances à partir de laquelle vous pouvez planifier et prévoir les besoins en capacité.
Il y a trois chiffres que vous devez examiner après avoir recueilli la date préliminaire :charge ou utilisation maximale, faible et moyenne. Après avoir analysé ces données, vous comprendrez pourquoi vous ne pouvez pas compter sur un instantané de charge pour vous guider tout au long du processus de planification de la capacité. Une ligne de base vous indique où vous en êtes dans ce processus.
Le prochain ensemble de données que vous devez prendre en compte est la capacité actuelle. Vous devez évaluer les informations sur la RAM, le processeur, le disque et la capacité du réseau. Ensuite, vous devez déterminer quelle est votre capacité maximale pour chaque système. La différence entre la capacité actuelle et la capacité maximale vous donne votre capacité de croissance. Par exemple, considérez un système qui a la configuration suivante :deux processeurs Quad-core, 128 Go de RAM, deux disques de 1 To en RAID 1 (en miroir) et une interface réseau Ethernet double Go. Votre capacité maximale pour ce système est donc de quatre processeurs quadricœurs, 512 Go de RAM, six disques et deux emplacements PCIe ouverts pour les cartes d'extension telles que les cartes d'interface réseau (NIC) Gb Ethernet.
| CPU | 2 - Quad core | 4 - Quad core |
| RAM | 128 Go | 512 Go |
| Disque | 2 disques - 1 To - RAID 1 | 6 disques |
| NIC | 2 GbE (double) | 6 GbE (double) - 10 GbE (quadruple) |
Maintenant, comparez les deux. Ce système a beaucoup plus de capacité disponible pour une puissance de calcul, un réseau et un stockage accrus. Ces paramètres de capacité matérielle ainsi que les données de performances de votre mois sont vos points de départ pour prévoir le besoin de capacité supplémentaire, que ce soit sous la forme de mises à niveau du système ou d'une actualisation complète de la technologie.
Deuxièmement :Configurez la surveillance des performances
Si vous ne disposez pas déjà d'un package de surveillance des performances tel que sysstat installé, vous pouvez facilement le faire à partir des référentiels par défaut. Vérifiez si vous avez sysstat :
$ rpm -qa |grep sysstat Si vous ne l'avez pas, installez-le avec :
$ sudo yum -y install sysstat
Exécutez les deux commandes suivantes pour exécuter sysstat collecteurs de données au démarrage, puis pour démarrer sysstat collecteurs de données de sur votre système :
$ sudo systemctl enable sysstat sysstat-collect.timer sysstat-summary.timer
$ sudo systemctl start sysstat sysstat-collect.timer sysstat-summary.timer
Le sysstat Le package se compose d'une poignée de commandes qui rapportent des statistiques de performances sur une variété de sous-systèmes et de services, de CIFS/Samba au disque en passant par les tâches Linux. La commande la plus utile est sar , le rapporteur d'activité du système. Le sar La commande vous fournit une liste courante des statistiques d'activité du système. Tout utilisateur peut émettre le sar commande pour afficher les statistiques :
$ sar
Linux 4.18.0-80.7.1.el8_0.x86_64 (rhel) 08/14/2019 _x86_64_ (1 CPU)
12:00:24 AM CPU %user %nice %system %iowait %steal %idle
12:10:01 AM all 0.22 0.00 0.43 0.01 0.00 99.33
12:20:32 AM all 1.18 0.05 1.24 0.12 0.00 97.41
12:30:01 AM all 0.27 0.00 0.49 0.01 0.00 99.23
12:40:32 AM all 0.20 0.00 0.38 0.00 0.00 99.41
12:50:32 AM all 0.18 0.00 0.36 0.01 0.00 99.46
Par défaut, les statistiques système sont collectées toutes les 10 minutes. Le sar La commande affiche les statistiques générales du système, mais l'option de statistiques beaucoup plus utile et complète fournit tout sar a à offrir, en utilisant le -A choix :
$ sar -A
La sortie est beaucoup trop longue pour être publiée ici, mais notez que vous verrez toutes les statistiques pour chaque sous-système et service que sar recueille. Veuillez vous référer au sar page de manuel pour plus d'informations et de détails sur des statistiques spécifiques et leurs options.
Troisièmement :analyser et tracer les données
Le sysstat collecteur rassemble les informations système et les conserve sous /var/log/sa . Les numéros de dossier sont le jour du mois à partir duquel ils ont été collectés. Vous aurez besoin d'une méthode de collecte et d'analyse de ces données. Je suggère Orca de Blair Zajac. Je vous suggère également de transférer vos données collectées vers un référentiel central pour les traiter et les afficher. En d'autres termes, ne traitez pas vos statistiques sur vos systèmes de production car cela impactera négativement vos statistiques de performances et faussera vos résultats.
Orca n'est pas trivial mais pas très difficile à mettre en place. Il y a quelques années, j'ai écrit un article qui vous aide à commencer à afficher vos statistiques de performances sur un serveur Web avec Orca. Orca n'a pas été mis à jour depuis un moment, mais fonctionne toujours comme indiqué dans la documentation et dans mon article.
Quatrième :Définir des seuils de performances
Pour chacun de vos systèmes de production ou de surveillance, vous devez répondre à la question :" Comment est occupé ?" Il n'y a pas de réponse parfaite, et vous modifierez probablement les chiffres à un moment donné pour réduire le nombre de notifications que vous recevez en cas de dépassement de ces seuils. Par exemple, supposons que vous disposiez de cinq serveurs Web dont la charge est équilibrée pour fournir des services Web à vos clients externes, et que vous deviez surveiller leurs performances pour prévoir quand ajouter d'autres systèmes à la batterie, ou quand vous pouvez en prendre un ou plus hors ligne.
En guise de test préliminaire, vous définissez le seuil d'UC à 80 % d'occupation pour les cinq serveurs. Deux fois par jour, vous recevez des alertes par e-mail indiquant que vos systèmes ont dépassé 80 %. Le problème? Vous recevez des alertes toutes les cinq minutes des cinq serveurs, pendant deux heures, deux fois par jour. Cela indique que les seuils sont trop bas, sauf si vous aimez recevoir toutes ces notifications.
Vous devez examiner les performances pendant ces périodes de pointe pour décider où définir le seuil et si vous devez ou non ajouter d'autres systèmes à la batterie de serveurs pour réduire l'utilisation globale. Après avoir examiné les chiffres, vous remarquez que l'utilisation ne dépasse jamais 87 % pour toute période de pointe sur n'importe quel serveur. Vous décidez ensuite de définir le seuil du processeur à 90 % et de continuer à faire vérifier votre moniteur toutes les cinq minutes, mais vous abaissez le seuil d'alerte à 90 % en continu pendant plus de deux heures. Cela signifie que si l'utilisation du processeur d'un système dépasse 90 % pendant plus de deux heures, vous recevrez une notification. Ce seuil pour cet environnement est raisonnable et gérable. Votre niveau de tolérance pour l'ajout d'un nouveau système à la ferme, après quelques mois d'observation, est CPU supérieur à 95 % pendant plus de deux heures.
Il s'agit du processus de détermination du niveau d'occupation et de vos niveaux de tolérance pour chaque service. Cela semble arbitraire, mais ce n'est pas le cas, car vous observez les données de manière continue et effectuez des ajustements et des décisions en fonction de vos observations. Une utilisation à 90 % pendant deux heures n'est pas excessive, mais vous ne voulez pas dépasser ce niveau, car les utilisateurs commencent alors à subir de longs temps d'attente lorsqu'ils extraient des données de votre système.
Cinquième :Alertes de performances
J'ai discuté des alertes, mais je n'ai pas encore trouvé de solution pour créer et gérer des événements (alertes). Vous pouvez créer quelque chose d'aussi simple qu'un script Bash pour vérifier sar données pour les chiffres d'utilisation, mais vous pouvez également déployer une solution commerciale ou même quelque chose entre les deux. Je ne vous recommanderai pas de solution d'alerte, mais il existe une poignée d'applications de surveillance et d'alerte open source disponibles. La plupart sont basés sur des agents, alors ajoutez l'installation et la maintenance d'un autre service à votre liste de tâches d'administration.
Comme indiqué dans la section précédente, vous devrez ajuster vos seuils et vos tolérances pour éviter de vous rendre fou avec des alertes, surtout si ces alertes se présentent sous forme de SMS sur votre ou vos téléphones. Vous ne souhaitez être averti que si quelque chose est en panne ou en difficulté et nécessite votre attention pour une résolution.
Le dilemme de la planification des capacités
Le dilemme de la planification de la capacité et de la surveillance des performances de nos jours est qu'au lieu d'acheter plusieurs racks de serveurs, vous louez probablement votre matériel de serveur ou vous utilisez une sorte de solution cloud où la capacité et les performances sont gérées de manière dynamique par des règles métier. . Les baux matériels de trois ans imposent une actualisation du matériel tous les trois ans, que vous en ayez besoin ou non. Le type de politique matérielle que vous avez dans votre entreprise modifie certainement la façon dont vous planifiez les changements de capacité.
Si vous louez, vous devrez toujours effectuer une surveillance des performances et penser à la capacité, car si vous avez du matériel sous-dimensionné ou sous-acheté, vous aurez certainement besoin de le savoir. Si vous achetez, vous devriez alors examiner la planification des performances et de la capacité sur une base continue de cinq ans. Je dis cinq ans parce que les gestionnaires et les propriétaires d'entreprise ne veulent pas remplacer le matériel tous les trois ans s'ils l'achètent. Il est probable qu'ils utilisent les achats de matériel comme un actif amorti.
L'astuce avec les actifs achetés est que vous ne voulez pas gaspiller de capacité en achetant trop trop tôt. De nombreuses histoires circulent sur des personnes qui achètent des systèmes haut de gamme uniquement pour les actualiser en cinq ans sans jamais exploiter la capacité de ces systèmes, et après cinq ans, ils sont trop vieux pour se soucier de la mise à jour et de la mise à niveau. L'essentiel pour acquérir du nouveau matériel loué ou acheté est d'acheter en gardant à l'esprit la croissance, puis de tirer parti de cette croissance en budgétisant les mises à niveau en fonction de l'utilisation. En d'autres termes, achetez ce dont vous avez besoin, mettez à niveau si nécessaire et profitez pleinement de vos ressources matérielles avant le prochain cycle d'actualisation.
Résumé
La planification de la capacité et la surveillance des performances fonctionnent ensemble pour vous donner une image complète du cycle de vie de votre matériel et de vos logiciels. Il est important de prendre le temps et de faire l'effort de mettre en place la surveillance et l'alerte, et d'analyser les données. Trop souvent, les administrateurs système occupés mettent en place des solutions élaborées pour la surveillance, puis les ignorent. Trouvez un moyen de trouver un équilibre entre être rendu fou par les alertes de performances et ne jamais voir celle qui entraîne des temps d'arrêt prolongés. La planification des capacités vous aide également à économiser de l'argent en redéployant les services des systèmes surutilisés vers les systèmes sous-utilisés.