Études volumétriques et de capacité

Pandora FMS est une application distribuée complexe qui comporte différents éléments clés, susceptibles de représenter un goulot d'étranglement s'ils ne sont pas dimensionnés et configurés correctement. L'objectif de ce chapitre est de vous aider à réaliser votre propre étude de capacité, pour analyser la scalabilité de Pandora FMS en fonction d'une série spécifique de paramètres. Cette étude vous aidera à connaître les exigences que l'installation devrait avoir pour pouvoir supporter une certaine capacité.

Les tests de charge servent également à observer la capacité maximale par serveur. Dans le modèle d'architecture actuel (version 3.0 ou ultérieure), avec « N » serveurs indépendants et un Command Center (Metaconsole) installé, cette extensibilitétend à être d'ordre linéaire, alors que la extensibilité basée sur des modèles centralisés est exponentielle.

Le fait que Pandora FMS compacte les données en temps réel est très pertinent pour calculer la taille qu'elles vont occuper. Une première étude a été réalisée pour comparer le mode de stockage des données d'un système classique avec le mode de stockage « asynchrone » des données de Pandora FMS. Ceci est illustré par le diagramme inclus dans ce chapitre.

Dans un système conventionnel

Pour un contrôle, avec une moyenne de 20 itérations par jour, l'espace occupé est de 5 MB par an. Pour 50 contrôles par agent, cela représente 250 MB par an.

Dans un système non conventionnel, asynchrone ou avec compactage, tel que Pandora FMS.

Pour un contrôle, avec une moyenne de 0,1 variation par jour, vous avez un total de 12,3 Kb par an dans l'espace occupé. Pour 50 contrôles par agent, cela représente 615 Kb par an.

Un glossaire de termes spécifiques à cette étude est décrit ci-dessous :

• Fragmentation de l'information : Les informations gérées par Pandora FMS peuvent avoir différents comportements, soit en constante évolution (par exemple un compteur de pourcentage de CPU), soit statiques (par exemple l'état d'un service). Étant donné que le Pandora FMS en tire parti pour compacter les informations dans la base de données, il s'agit d'un facteur critique pour l'étude des performances et de la capacité, car plus la fragmentation est importante, plus la taille de la base de données est élevée et plus il faudra utiliser de capacité de traitement pour traiter les mêmes informations.
• Module : Il s'agit de l'élément d'information de base collecté pour la surveillance. Dans certains environnements, il est appelé « événement », dans d'autres « moniteur » et dans d'autres encore « métrique ».
• Interval : Le temps qui s'écoule entre les collectes de données d'un module. Il est généralement exprimé en minutes ou en secondes. La valeur « moyenne » est généralement de 5 minutes.
• Alert : Il s'agit de la notification que Pandora FMS exécute lorsqu'une donnée sort des marges établies ou change d'état pour devenir CRITICAL (critique) ou WARNING (avertissement).

L'étude a été réalisée en vue d'une mise en œuvre divisée en trois phases principales :

• Phase 1 : Déploiement de 500 agents.
• Phase 2 : Déploiement de 3 000 agents.
• Phase 3 : Déploiement de 6 000 agents.

Afin de déterminer les exigences exactes de Pandora FMS dans les implémentations de ce volume de données, il est nécessaire de savoir très bien quel type de surveillance va être effectué, avec la plus grande précision possible. Pour l'étude suivante, les caractéristiques de l'environnement d'un client fictif appelé « QUASAR TECHNOLOGIES » ont été spécifiquement prises en compte, ce qui peut être résumé dans les points suivants :

• Supervision basée à 90 % sur des agents logiciels.
• Systèmes homogènes présentant un certain nombre de caractéristiques regroupées en technologies/politiques.
• Intervalles très variables entre les différents modules et événements à surveiller.
• Grande quantité d'informations asynchrones (événements, éléments dans logs).
• Beaucoup d'informations sur l'état des processus avec une très faible probabilité de changement.
• Peu d'informations sur les performances par rapport au total.

Après un examen approfondi de toutes les technologies et la définition de la portée de la mise en œuvre (identification des systèmes et de leurs profils de surveillance), les conclusions suivantes ont été tirées :

• Il y a en moyenne 40 modules et événements par machine.
• L'intervalle de supervision moyen est de 1200 secondes (20 minutes).
• Disposer de modules qui transmettent des informations toutes les 5 minutes et de modules qui transmettent des informations une fois par semaine.
• À partir de l'ensemble des modules (240 000), la probabilité de changement de chaque événement pour chaque échantillon a été déterminée comme étant de 25 %.
• Le taux d'alerte par module a été fixé à 1,3 (c'est-à-dire 1,3 alerte par module/événement).
• On estime (dans ce cas, il s'agit d'une estimation basée sur notre expérience) que la probabilité de déclencher une alerte est de 1 %.

Une fois que les exigences de base pour la mise en œuvre de chaque phase (taux de module/seconde, nombre d'alertes totales, modules par jour et mégaoctets par mois) sont connues, un test de stress réel (stress) sera effectué sur un serveur relativement similaire aux systèmes de production (il n'a pas été possible de tester sur une machine similaire aux systèmes de production).

Ces tests stress indiquent la capacité de traitement de Pandora FMS dans un serveur et son niveau de dégradation dans le temps. Ceci est utile pour les objectifs suivants :

1. Par extrapolation, déterminer si le volume final du projet sera réalisable avec le matériel prévu à cet effet.
2. Sachez quelles sont les limites du stockage en ligne (online) et quels devraient être les points limites à partir desquels les informations sont transférées vers les bases de données historiques.
3. Connaître les marges de réponse en cas de pics de traitement, dérivés des problèmes qui peuvent survenir (arrêt de service, arrêts planifiés) où s'accumulent les informations en attente de traitement.
4. Comprendre l'impact sur la performance résultant de la qualité différente (pourcentage de changement) des informations de suivi.
5. Comprendre l'impact du processus d'alerte dans les grands volumes.

Les tests ont été effectués sur un serveur DELL PowerEdge T100® équipé d'un processeur Intel Core Duo® 2,4 GHz et de 2 GB de RAM. Ce serveur, qui tourne sous Ubuntu Server 8.04, a servi de base d'étude pour les tests dans les environnements à haute capacité. Les tests ont été effectués sur des configurations d'agents relativement similaires à celles du projet QUASAR TECHNOLOGIES. L'objectif des tests n'est pas de reproduire exactement le même volume d'informations que QUASAR TECHNOLOGIES, puisque le même matériel n'est pas disponible, mais de reproduire un environnement à haute capacité, similaire à celui de QUASAR TECHNOLOGIES, afin d'évaluer l'impact sur la performance dans le temps et de déterminer d'autres problèmes (principalement de performance) découlant de la gestion de grands volumes de données.

Les résultats obtenus sont très positifs puisque le système, bien que fortement surchargé, a pu traiter un volume d'informations très important (180 000 modules, 6 000 agents et 120 000 alertes). Les conclusions tirées de cette étude sont les suivantes :

1. Les informations « en temps réel » doivent être transférées dans la base de données historique dans un délai maximum de 15 jours, l'idéal étant que les données datent de plus d'une semaine. Cela permet d'accélérer les opérations.
2. La marge de manœuvre dans le cas optimal est de près de 50 % de la capacité de traitement, ce qui est plus élevé que prévu compte tenu de ce volume d'informations.
3. Le taux de fragmentation de l'information est essentiel pour déterminer les performances et la capacité requises pour l'environnement dans lequel le système doit être déployé.

Alors que le point précédent représentait une étude « rapide » basée uniquement sur des modules de type « dataserver », ce chapitre présente une manière plus complète d'effectuer une analyse de la capacité de Pandora FMS.

Pour commencer, dans tous les cas, l'approche du « pire des cas » sera toujours utilisée lorsqu'un choix peut être fait. Si aucun choix ne peut être fait, la philosophie du « cas habituel » sera utilisée. Rien ne sera jamais estimé dans le « meilleur cas » car il n'est pas valable.

Dans ce qui suit, vous verrez comment calculer la capacité du système, par type de supervision ou en fonction de la source d'information.

Sur la base de certains objectifs, calculés conformément au point précédent, on supposera que l'objectif estimé est de voir comment il se comporte avec une charge de 100 000 modules, répartis entre un total de 3 000 agents, c'est-à-dire une moyenne de 33 modules par agent.

Elle créera une tâche « pandora_xmlstress » exécutée par cron ou script manuellement, contenant 33 modules, distribuée avec une configuration similaire à celle-ci :

• 1 modules de type chaîne.
• 17 les modules de type generic_proc.
• 15 les modules de type generic_data.

Les seuils des 17 modules de type « generic_proc » sont configurés de cette manière :

module_begin
module_name Process Status X
module_type generic_proc
module_description Status of my super-important daemon / service / process
module_exec type=RANDOM;variation=1;min=0;max=100
module_end

Les seuils doivent être fixés dans les 15 modules de type « generic_data ». La procédure à suivre est la suivante :

Les seuils des 15 modules de type « generic_data » sont configurés pour générer des données de type :

module_exec type=SCATTER;prob=20;avg=10;min=0;''m''ax=100

Les seuils de ces 15 modules doivent être configurés de manière à présenter ce schéma :

0-50 normal
50-74 warning
75- critical

De nouveaux jetons seront ajoutés au fichier de configuration pandora_xml_stress pour pouvoir définir les seuils à partir de la génération XML. Attention : Ceci parce que Pandora FMS « adopte » la définition des seuils uniquement lors de la création du module, mais pas lors de la mise à jour avec de nouvelles données.

module_min_critical 75
module_min_warning 50

Exécuter le pandora_xml_stress.

Il doit fonctionner pendant au moins 48 heures sans interruption d'aucune sorte et doit superviser (à l'aide d'un agent Pandora FMS) les paramètres suivants :

• Nombre d'emballages collés :

find /var/spool/pandora/data_in | wc -l

• pandora_server CPU :

ps aux | grep "/usr/bin/pandora_server" | grep -v grep | awk '{print $3}'

• Mémoire totale de PFMS server :

ps aux | grep "/usr/bin/pandora_server" | grep -v grep | awk '{print $4}'

• mysqld CPU (vérifier la syntaxe d'exécution qui dépend de la distribution MySQL utilisée) :

ps aux | grep "sbin/mysqld" | grep -v grep | awk '{print $3}'

• Temps de réponse moyen de la base de données Pandora FMS :

/usr/share/pandora_server/util/pandora_database_check.pl /etc/pandora/pandora_server.conf

• Nombre de moniteurs dont l'état est inconnu (unknown) :

echo "select SUM(unknown_count) FROM tagente;" | mysql -u pandora -p < password > -D pandora | tail -1

(où < password > est le mot de passe de l'utilisateur pandora)

Les premières exécutions doivent être utilisées pour affiner le serveur et la configuration de l'interface utilisateur MySQL.

Le script /usr/share/pandora_server/util/pandora_count.sh sera utilisé pour compter (lorsqu'il y a des fichiers XML en attente de traitement) le taux de traitement des paquets. L'objectif est de faire en sorte que tous les paquets générés (3000) puissent être « traités » dans un intervalle inférieur à 80 % de la limite de temps (5 minutes). Cela signifie que 3000 paquets doivent être traités en 4 minutes :

3000 / (4 x 60) = 12.5

Un taux de traitement d'au moins 12,5 paquets doit être atteint pour être raisonnablement sûr que le Pandora FMS peut traiter cette information.

Éléments à ajuster :

• Nombre de fils.
• Nombre maximal d'éléments dans la file d'attente intermédiaire (max_queue_files).
• Bien sûr, tous les paramètres MySQL pertinents (très importants).

Le système est configuré pour que la maintenance de la base de données script dans /usr/share/pandora_server/util/pandora_db.pl soit exécutée toutes les heures au lieu de tous les jours :

mv /etc/cron.daily/pandora_db /etc/cron.hourly

Le système fonctionne avec le générateur de paquets pendant au moins 48 heures. Après cette période, les points suivants sont évalués :

1. Le système est-il stable, est-il tombé en panne ? En cas de problème, consultez les logs et les graphiques des mesures obtenues (principalement la mémoire).
2. Évaluer la tendance temporelle de la métrique « nombre de moniteurs dans un état inconnu ». Il n'est pas nécessaire qu'il y ait des tendances ou des pics importants. Ils doivent être l'exception. Si elles se produisent avec une régularité d'une heure, c'est qu'il y a des problèmes de concurrence dans le processus de gestion de la base de données.
3. Evaluez la métrique « Temps de réponse moyen de la base de données du Pandora FMS ». Il ne doit pas augmenter avec le temps mais rester constant.
4. Evaluez la métrique « CPU of pandora_server » : Elle doit présenter des pics fréquents, mais avec une tendance constante, non croissante.
5. Evaluez la métrique « MySQL server CPU », elle devrait rester constante avec des pics fréquents, mais avec une tendance constante, non croissante.

Si tout s'est bien passé, il convient maintenant d'évaluer l'impact de l'exécution de l'alerte sur les performances. Appliquez une alerte à cinq modules spécifiques à l'agent (de type generic_data), pour la condition CRITICAL. Quelque chose de relativement léger, comme la création d'un événement ou l'écriture dans syslog (pour éviter l'impact que pourrait avoir quelque chose avec une latence élevée comme l'envoi d'un message électronique).

Vous pouvez éventuellement créer une alerte de corrélation d'événements pour générer une alerte pour toute condition critique pour tout agent avec l'un de ces cinq modules.

Laissez le système fonctionner pendant 12 heures selon ces critères et évaluez l'impact, en suivant les critères ci-dessus.

En supposant que la politique de stockage des données soit :

• Suppression des événements datant de plus de 72 heures.
• Déplacer les données dans l'historique de plus de 7 jours.

Vous devez laisser le système fonctionner « seul » pendant au moins 10 jours pour évaluer les performances à long terme. Il se peut que vous constatiez un « pic » important après 7 jours en raison du mouvement des données vers la base de données historique. Il est important de tenir compte de cette dégradation. Si vous ne disposez pas d'autant de temps, vous pouvez la reproduire (avec moins de « réalisme ») en modifiant l'intervalle de purge à 2 jours pour les événements et à 2 jours pour déplacer les données vers l'historique, afin d'évaluer cet impact.

Il s'agit en particulier du serveur réseau ICMP. En cas de test pour le serveur réseau de la version Open, voir le point pour le serveur réseau (générique).

Supposons que le serveur soit déjà opérationnel et configuré. Quelques paramètres clés pour son fonctionnement :

block_size X

Il définit le nombre de pings que le système effectuera par exécution. Si la plupart des pings prennent le même temps, vous pouvez augmenter considérablement ce nombre, par exemple de 50 à 70.

Si, en revanche, le pool de modules ping est hétérogène et qu'ils se trouvent sur des réseaux très différents, avec des temps de latence très différents, il n'est pas intéressant de fixer un nombre élevé, car le test durera aussi longtemps que le plus lent, et vous pouvez donc utiliser un nombre relativement faible, tel que 15 à 20.

icmp_threads X

Évidemment, plus vous avez de threads, plus vous pouvez effectuer de vérifications. Si vous additionnez tous les threads que Pandora FMS exécute, ils ne devraient pas atteindre 30 à 40. Vous ne devriez pas utiliser plus de 10 threads ici, bien que cela dépende beaucoup du type de matériel et de la version GNU/Linux que vous utilisez.

Vous devez maintenant « créer » un nombre fictif de modules de type ping à tester. On suppose que vous allez tester un total de 3000 modules de type ping /. Pour ce faire, il est préférable de prendre un système sur le réseau capable de supporter tous les pings (n'importe quel serveur GNU/Linux peut s'acquitter de cette tâche).

En utilisant l'importateur CSV de Pandora FMS, créez un fichier au format suivant :

Ce shellscript peut être utilisé pour générer un tel fichier (en changeant l'adresse IP de destination et l'ID de groupe) :

A=3000
while [ $A -gt 0 ]
do
    echo "AGENT_$A,192.168.50.1,1,300,10"
    A=`expr $A - 1`
done

L'essentiel est de faire superviser le Pandora FMS, en mesurant les paramètres du point précédent : la consommation de CPU (pandora et mysql), le nombre de modules dans un état inconnu et d'autres moniteurs intéressants.

Importez le CSV pour créer 3000 agents, ce qui prendra quelques minutes. Allez ensuite dans le premier agent (AGENT_3000) et créez-y un module PING.

Allez ensuite dans l'outil d'opérations en masse et copiez ce module sur les 2999 agents restants.

Le Pandora FMS devrait commencer à traiter ces modules. Mesurez avec les mêmes paramètres que dans le cas précédent et observez l'évolution. L'objectif est de laisser un système opérationnel pendant le nombre requis de modules de type ICMP sans qu'aucun d'entre eux n'atteigne un état inconnu.

Il s'agit spécifiquement du serveur réseau SNMP. Supposant que votre serveur fonctionne et est configuré. Quelques paramètres clé pour son fonctionnement :

block_size X

Il définit le nombre de requêtes SNMP que le système fera pour chaque exécution. Il faut tenir sur compte que le serveur les groupe par addresse IP de destination, donc le bloc est orientatif. Il convient qu'il ne soit pas trop grand (30 à 40 comme maximum). Lorsqu'un élément du bloc échour, un compteur interne fale le serveur PFMS le réessaie.

snmp_threads X

Bien évidemment, le plus de fils, les plus de vérifications à réaliser. Si vous sommez tous les fils exécutés par Pandora FMS, ils ne devront attendre le rang de 30 à 40. Il ne devrait pas d'utiliser plus de 10 fils ici, bien qu'il dépend beaucoup du type de matériel et la version GNU/Linux utilisée.

La forme la plus rapide de tester est par le biais d'un appareil SNMP, en applicant à toutes les interfaces tous les modules de supervision « de base » de série. Cela se fait par l'application du SNMP Explorer (Agent → Mode d'administration → SNMP Explorer). Idéntifiez les interfaces et appliquex toutes les métriques pa chaque interface. Dans un switch de 24 ports, cela génére environ 650 modules.

Si un autre agent avec un autre nom est généré, mais avec la même adresse IP, il aura d'autres 650 modules. Une autre option est de copier tous les modules à une série d'agents qui ont tous la même adresse IP, donc les modules copiés attaquent le même switch.

Une autre option est d'utiliser un simulateur de SNMP, tel que Jalasoft SNMP Device Simulator.

L'objectif de ce point est d'être en mesure de superviser de manière constante un pool de modules SNMP pendant au mois 48 heures, en supervisant l'infrastructure, afin de vous assurer que le ratio de supervision de modules par seconde est constant et il n'y a pas des periodes de temps où le serveur génère des modules en état inconnu. Cet situation pourrait de produire à cause de :

• Un manque de ressources (mémoire, UCT). On pourrait voir une tendance croissante continue de ces métriques, donc il s'agit d'un mauvais signal.
• Des problèmes précis : Redémarrage quotidien du serveur (pour la rotation de journaux), l'exécution de la maintenance programmée de la base de données ; ou d'autres scripts qui sont exécutés dans le serveur ou le serveur de la base de données.
• Dres problèmes réseau, produits par des processus non liés (par exemple la sauvegarde de sonnées d'un serveur dans le réseau) qui affectent la vitesse et disponibilité du réseau à un moment précis.

Le même concept s'applique ici que ci-dessus, mais sous une forme plus simplifiée. Il sera nécessaire de contrôler :

• Nombre de fils.
• Délai de traitement (timeouts) pour calculer l'incidence la plus défavorable.
• Durée moyenne de l'enregistrement.

À l'aide de ces données, dimensionnez un ensemble de test et vérifiez que la capacité du serveur est constante dans le temps.

L'hypothèse est ici plus simple : on suppose que le système ne recevra pas de déroutements en permanence, mais qu'il évaluera la réponse à un flot de déroutements, dont certains généreront des alertes.

Pour ce faire, il suffit de créer un script qui génère des déroutements de manière contrôlée et à grande vitesse :

#!/bin/bash
TARGET=192.168.1.1
while [ 1 ]
do
   snmptrap -v 1 -c public $TARGET .1.3.6.1.4.1.2789.2005 192.168.5.2 6 666 1233433 .1.3.6.1.4.1.2789.2005.1 s "$RANDOM"
done

Note : Arrêtez-le avec la touche CTRL+C après quelques secondes, car il va générer des centaines de déroutements rapidement.

Une fois l'environnement mis en place, les hypothèses suivantes doivent être validées :

1. Injection de traps à un rythme constant (il suffit d'ajouter la commande sleep 1 au script précédent à l'intérieur de la boucle while, pour générer 1 trap par seconde). Laissez le système fonctionner pendant 48 heures et évaluez l'impact sur le serveur.
2. Tempête de traps. Évaluer la situation avant, pendant et après une tempête de déroutements.
3. Les effets du système sur une très grande table de traps / (plus de 50 000). Cela inclut l'effet de la maintenance de la base de données.

Comme pour SNMP, les events du système PFMS doivent être évalués dans deux scénarios :

1. Taux de réception normal des événements. Ceci a déjà été testé sur le serveur de données, car un événement est généré à chaque changement d'état.
2. Tempête de génération d'événements. Pour ce faire, nous allons forcer la génération d'événements via le CLI. En utilisant la commande suivante (avec un groupe existant appelé « Tests ») :

pandora_manage /etc/pandora/pandora_server.conf --create_event "Event test" system Tests

Cette commande, utilisée dans une boucle comme celle utilisée pour générer des déroutements, peut être utilisée pour générer des dizaines d'événements par seconde. Vous pouvez paralléliser un script avec plusieurs instances pour provoquer un plus grand nombre d'insertions. Cela permettrait de simuler le comportement du système lors d'une tempête. Le système pourrait ainsi être testé avant, pendant et après une tempête.

Pour ce faire, un autre serveur indépendant du Pandora FMS sera utilisé, en recourant à la fonctionnalité de surveillance WEB. Au cours d'une session utilisateur, il effectuera les tâches suivantes dans un ordre spécifique et mesurera le temps nécessaire à leur traitement :

1. Connectez-vous à la console web.
2. Voir les événements.
3. Accédez à la vue du groupe.
4. Accédez à la vue détaillée de l'agent.
5. Affichez un rapport (en HTML). Ce rapport doit contenir quelques graphiques et quelques modules avec des rapports SOMME ou MOYENNE. L'intervalle pour chaque élément doit être d'une semaine ou de cinq jours.
6. Affichage d'un graphique combiné (24 heures).
7. Génération d'un rapport PDF (un rapport différent).

Ce test est effectué avec au moins trois utilisateurs différents. Vous pouvez paralléliser cette tâche pour l'exécuter toutes les minutes, de sorte que s'il y a 5 tâches (chacune avec son propre utilisateur), vous simulerez la navigation de cinq utilisateurs simultanés. Une fois l'environnement mis en place, il prendra en compte les éléments suivants :

1. La vitesse moyenne de chaque module permet d'identifier les goulets d'étranglement liés à d'autres activités parallèles, telles que l'exécution de la maintenance script, etc.
2. L'impact de l'unité centrale et de la mémoire sur le serveur sera mesuré pour chaque session simultanée.
3. L'impact de chaque session d'utilisateur simulée sera mesuré par rapport au temps moyen des autres sessions. En d'autres termes, il convient d'estimer le nombre de secondes de retard que chaque session simultanée supplémentaire ajoute.

Retour à l'index de la documentation de Pandora FMS