pandorafms/pandora_doc/fr/pandora_advanced.xml

168 lines
8.4 KiB
XML

<?xml version="1.0" encoding="utf-8"?>
<chapter>
<title>Section Pandora FMS avancé</title>
<sect1><title>Fonctionnalités Haute Disponibilité (HD) de Pandora FMS</title>
<para>
Vous pouvez paramétrer Pandora pour l'utiliser dans divers scénarii HD:
<itemizedlist mark='bullet'>
<listitem>
<para>
<emphasis>Cluster de bases de données pour HD</emphasis>. Vous avez besoin de
configurer un cluster MySQL5. Il y a des informations pour mettre cela en oeuvre
dans les forums/wikis de support, vous devez seulement convertir le schéma de la DB
vers des tables compatibles avec un cluster MySQL. Ce scénario a été testé
et fonctionne bien, mais il nécessite d'avoir des connaissances avancées
sur l'administration de clusters MySQL.
</para>
</listitem>
<listitem>
<para>
<emphasis>Consoles Pandora Multiples</emphasis>. Très facilement,
paramétrez simplement une autre console. Aucun problème de verrouillage ou
d'incompatibilité n'a été détecté au cours de multiples déploiements.
</para>
</listitem>
<listitem>
<para>
<emphasis>Serveurs de données Pandora Multiples Pandora pour la HA
</emphasis>. C'est le scénario le plus complexe, car si vous n'avez
pas besoin de connaître en détail le paramétrage de Pandora Server,
vous aurez besoin d'utiliser d'autres outils pour implémenter la HD
réseau, comme VRRP or Keepalive. Pour le serveur de données Pandora
vous aurez besoin de 2 machines identiques, avec les même clefs publiques
pour tous les agents qui se connectent au serveur (et de dupliquer
la clef hôte du serveur SSH). Puis paramétrer la HD sur le réseau pour
pointer sur l'un d'entre eux. Si l'un d'entre eux vient à faillir, VRRP
ou Keepalive "promeu" l'autre serveur, ainsi les agents Pandora, s'y connecteront
pour envoyer leur prochain paquet de données. Il n'y a rien à changes dans
les serveurs de données Pandora, assurez-vous seulement que le nom des deux
seveurs de données Pandora est le même sur ces deux machines (dans le programme
pandora serveur, pas le nom d'hôte de la machine).
</para>
</listitem>
<listitem>
<para>
<emphasis>Serveurs Pandora Network multiples pour HD
</emphasis>. Cela est plus aisé. Vous aurez besoin de paramétrer
plusieurs Pandora Network Servers sur plusieurs machines du réseau
(ou toutes celles dans un même sgment), et assignez-les au
même serveur. Si ce serveur s'arrête, et qu'il y a d'autres
Network Servers actifs, marqués comme serveurs "primaires",
automatiquement, le premier Network Server disponible marqué comme
"primaire", lancera l'interrogation du module réseau. Si vous avez
plusieurs serveurs marqués comme primaire, tous peuvent lancer
des requêtes.
</para>
</listitem>
<listitem>
<para>
<emphasis>Pandora Network Server multiples pour la balance de
charge</emphasis>. Vous aurez besoin de paramétrer plusieurs
Pandora Network Servers sur plusieurs machines du réseau
(ou toutes celles dans un même sgment), et assigner les
agents/modules à differents servers, equilibrant la charge entre
tous les serveurs disponibles.
</para>
</listitem>
</itemizedlist>
</para>
</sect1>
<sect1><title>Serveurs virtuels Pandora</title>
<para>
Une cas particulier pour obtenir plus de puissance de calcul dans
les serveurs, pourrait d'être d'implémenter des serveurs "virtuels".
Utiliser des serveurs virtuels (une autre instance du même serveur
dans la même machine) est utilisé quand le serveur Pandora ne peut
traiter toutes les informations sans délais trop important.
Pandora 1.2 utilise un nombre limité de therads pour traiter l'information
(cela changera dans les versions futures), vous pouvez donc installer
d'autres instances de Pandora Network ou Pandora Data Server (avec
un autre répertoire data_in !), pour pouvoir traiter plus d'informations
avec la même machine.
</para>
</sect1>
<sect1><title>Conception de la base de données de Pandora (et modification depuis la 1.1)</title>
<para>
Les premières versions de Pandora, depuis la 0.83 jusqu'à la 1.1 étaient basées
sur une idée simple: une donnée, une insertion en base. Cela était très facile à
développer et autorisait l'implémentation facile des recherches, insertions et autres
operations.
</para>
<para>
Cela eut beaucoup d'avantages mais aussi un sérieux problème:
la capacité à monter en charge. La limite de ce système est
définie par le nombre maximal de modules qu'il peut supporter.
Passé cette limite, la gestion sera trop lente.
</para>
<para>
Les solutions basées sur un cluster MySQL sont difficiles à mettre
en oeuvre et ont posent des problème, de plus, elles n'offrent pas
de solution viable sur le long terme.
</para>
<para>
La compression de données basée sur l'interpolation et la purge de données
génère une base de données plus petite. Cela n'est aps suffisant:
Les systèmes de production ont une limite de 100 agents comprenant
chacun 10 modules. Ce qui n'est pas beaucoup pour les gros réseaux.
</para>
<para>
Ce problème était très important pour le futur de Pandora FMS, la façon
dont Pandora gérait ses données fut donc modifiée. Le nouveau système
de gestion des données stocke les donnée uniquement si la nouvelle valeur
est différente de la précédente. Ce système évite de stocker des données
redondantes. Cela permet de garder une base de données de petite taille.
Cette logique vaut pour tous les types de modules Pandora (texte, numérique,
incrémental et booléen).
</para>
<para>
Cela résout une partie de la problèmatique de la montée en charge
en réduisant considérablement l'utilisation de la base de données,
dans des propprtions de l'ordre de 40 à 70%. Une autre solution au
problème de montée en charge serait: séparer totalement les composants
Pandora et une implémentation intégrée de la Haute Disponibilité dans
les composants Pandora. Autorisant alors plusieurs serveurs Pandora
(réseau, données, SNMP), consoles Pandora, bases de données Pandora
(dans un cluster MySQL5).
</para>
<para>
Ces changements s'accompagnent d'une façon différente de lire les données.
Dans la nouvelle version, si un agent ne peut communiquer avec le serveur
Pandora, et le serveur Pandora ne reçoit pas de données de cet agent, cette
absence de données sera représentée par une ligne horizontale prolongeant
la dernière valeur reçue, matérialisant l'absence de changement depuis lors.
Pandora, représentera donc cette absence de nouvelle valeur comme une absence de
changement depuis le dernier contact.
</para>
<para>
Ce graph, par exemple représente les changements pour chaque donnée reçue toutes
les 180 secondes.
<graphic fileref="images/module_graph_full.jpg" scale="60" align="center"/>
Ci-dessous, le même graph avec une perte de connection de 05:55 à 15:29 approximativement.
<graphic fileref="images/module_graph_peak.jpg" scale="60" align="center"/>
</para>
<para>
Il a été introduit dans Pandora 1.2, un nouveau graph représentant la connectivité
des agents vers le serveur Pandora. Ce graphe vient donc compléter les autres en
indiquant quand les agents parviennent à envoyer des données au serveur Pandora.
Voici un exemple de ce graph montrant le contact régulier d'un agent à son serveur:
<graphic fileref="images/access_graph_full.jpg" scale="65" align="center"/>
Si ce graph montre des "trous", cela peut révéler des problèmes, ou être dû à une
connexion lente lorsqu'un agent Pandora contacte le serveur Pandora.
Le graphe suivant reprend le graphe ci-dessus, en montrant ce phénomène:
<graphic fileref="images/access_graph_peak.jpg" scale="65" align="center"/>
</para>
</sect1>
<sect1><title>Le guide du programmeur sur l'architechture Pandora</title>
<para>
<graphic fileref="images/Pandora_NetworkServer_Diagram.png" scale="65" align="center"/>
<graphic fileref="images/Pandora_DataServer_Diagram.png" scale="65" align="center"/>
<graphic fileref="images/Pandora_SNMP_Diagram.png" scale="55" align="center"/>
<graphic fileref="images/pandora_ER.png" scale="50" align="center"/>
</para>
</sect1>
</chapter>