Vous pouvez paramétrer Pandora pour l'utiliser dans divers scénarii HD: Cluster de bases de données pour HD. 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. Consoles Pandora Multiples. 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. Serveurs de données Pandora Multiples Pandora pour la HA . 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). Serveurs Pandora Network multiples pour HD . 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. Pandora Network Server multiples pour la balance de charge. 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. 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. 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. 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. 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. 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. 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). 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). 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. Ce graph, par exemple représente les changements pour chaque donnée reçue toutes les 180 secondes. Ci-dessous, le même graph avec une perte de connection de 05:55 à 15:29 approximativement. 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: 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: