Command Center

À partir de la version 756 de Pandora FMS les système de synchronisation a été conçu de zéro pour des environnements avec le mode centralisé, en le rendant plus rapide et efficace, puisque les changements seront répliqués aux nœuds automatiquement sans besoin de synchronisation manuelle, comme avant.

Ce changement laisse le système précédent en désuétude, donc dans les environnements où il était actif, il faudra passer par le système de fusion automatique précédent (merge ) pour utiliser le nouveau système de centralisation et pouvoir garantir l'intégrité des données.

Lors de la mise à jour, tous les environnements Metaconsole déjà centralisés seront obligés de passer par la nouvelle section de l'outil de fusion (Merging tool) située dans la gestion centralisée (Centralised Management) afin d'être à nouveau centralisés correctement.

Le Merging tool va mélanger les différents éléments des bases de données des nœuds et de la Métaconsole (de ceux qui doivent être gérés depuis la Métaconsole) comme suit : Un ordre de priorité sera établi entre les nœuds et la Métaconsole, plaçant les éléments les plus prioritaires en haut de la liste et en bas les moins prioritaires.

Par exemple :

Cette liste de priorité est utilisée pour les cas où le même élément existe dans les différents nœuds mais a des configurations différentes. Par exemple, que les 2 nœuds et la Métaconsole ont le groupe « Bases de données ». Avec cet ordre de priorité, la configuration de l'élément le plus prioritaire sera prise pour tous, dans l'exemple de la Métaconsole.

Dans un autre cas, si par exemple seuls les nœuds 1 et 2 avaient une politique appelée « Windows », pour tous les nœuds et la Métaconsole, la configuration de cette politique serait celle du nœud 1 (on saute la Métaconsole car elle ne l'a pas).

Dans le cas des politiques il serait l'élément le plus particulier de tous les éléments synchronisés par son mode de configuration, suique chaque plugin, module et alerte… sont traités comme des éléments independantes et pas comme une partie de la configuration de la politique. C'est à dire, dans l'example précédent de la politique et le regardant seulement avec des modules, si vous avez :

Le résultat de l'unifiction du Merging tool serait :

Cela permet au résultat d'avoir autant de configurations différentes que possible afin que vous puissiez maintenant les gérer depuis la Métaconsole.

Les éléments suivants sont ceux qui sont centralisés depuis le nouveau Merging tool:

• Utilisateurs : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même ID seront considérés comme le même utilisateur (suivant les règles de priorité décrites avant).
• Profils d'utilisateur : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme le même profil (suivant les règles de priorité décrites avant)..
• Groupes d'agents : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme le même group (suivant les règles de priorité décrites avant).

• Collections de fichiers : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom court seront considérés comme la même collection (suivant les règles de priorité décrites avant).
• Modèles d'alerte : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme le même modèle (suivant les règles de priorité décrites avant).
• Commande d'alerte : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme la même commande (suivant les règles de priorité décrites avant).
• Actions d'alerte : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme la même action (suivant les règles de priorité décrites avant).
• Plugins de serveur : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom et exécution seront considérés comme le même plugin (suivant les règles de priorité décrites avant).
• Système d'exploitation : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même no seront considérés comme le même système d'exploitation (suivant les règles de priorité décrites avant).
• Étiquettes de modules : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme la même étiquette (suivant les règles de priorité décrites avant)..
• Catégories de modules : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme la même catégorie (suivant les règles de priorité décrites avant).
• Groupes de modules : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme le même groupe (suivant les règles de priorité décrites avant).
• Groupes de composants : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme le même groupe (suivant les règles de priorité décrites avant).
• Composants réseau : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom et système d'exploitation seront considérés comme le même composant (suivant les règles de priorité décrites avant).
• Composants locales : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom et système d'exploitation seront considérés comme le même composant (suivant les règles de priorité décrites avant).
• Modèles de composants : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme le même modèle (suivant les règles de priorité décrites avant).
• Module d'inventaire : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom et système d'exploitation seront considérés comme le même module (suivant les règles de priorité décrites avant).
• Politiques de supervision : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom seront considérés comme la même politique (suivant les règles de priorité décrites avant).
• Modules de politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom dans un politique avec le même nom seront considérés comme le même module (suivant les règles de priorité décrites avant).
• Modules d'inventaire de politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom et système d'exploitation dans une politique avec le même nom seront considérés comme le même module (suivant les règles de priorité décrites avant).
• Plugins de politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on la même exécution dans un politique avec le même nom seront considérés comme le même plugin (suivant les règles de priorité décrites avant).
• Collections de politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom court dans une politique avec le même nom seront considérés comme la même collection (suivant les règles de priorité décrites avant).
• Alertes et alertes externes de polítiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même modèle sur le même nom de module dans une politique avec le même nom seront considérés comme la même alerte (suivant les règles de priorité décrites avant).
• Actions sur des alertes et alertes externes de politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui on le même nom sur le modèle sur le même nom de module dans un politique avec le même nom seront considérés comme la même action (suivant les règles de priorité décrites avant).
• Agents dans les politiques : Il sont gérés depuis la Métaconsole. La gestion dans le nœud est désactivée. Lors de l'unification depuis le Merging tool ceux qui sont dans des politiques avec le mÊme nom seront considérés comme agents dans une même politique. Les journaux d'agents dans les politiques de la Métaconsole seront écartés et seulement les journaux des nœuds teront tenus sur compte (où l'application est effective).
• Agents : Les agents peuvent être gérés dans le nœud, à exception de sa élimination qui doit se faire dans la Métaconsole.

Les sections où ces éléments sont gérés de manière centralisée seulement peuvent se gérer depuis la Métaconsole. Dans le cas d'accèder à ces éléments depuis les nœuds, vous ne pouvez que les lister, et vous ne trouverez pas les options d'édition et de création. Vous verrez un avis qui vous indiquera que l'énvironement Test sous mode centralisé, avec un lien à l'administrateur à la section de ña Métaconsole correspondante pour la configuration de ces éléments.

Les tableaux suivants sont synchronisés entre la Metaconsole et les nœuds du Merging tool (voir également « Tables principales de la base de données ») :

• La Métaconsole doit pouvoir se connecter à toutes les bases de données et à toutes les API de nœuds. Assurez-vous que la configuration « Consoles setup » est correcte et que les indicateurs sont verts.

• Les consoles des nœuds doivent pouvoir se connecter à la base de données de la Métaconsole. Normalement, ce ne sera pas un problème, à moins que vous n'ayez les consoles sur des ordinateurs autres que les serveurs Pandora FMS. Assurez-vous que les paramètres de configuration Setup → Enterprise pour la Métaconsole sur les nœuds sont corrects.

• Les serveurs de tous les nœuds doivent pouvoir se connecter à l'API de la Métaconsole. On recommande de configurer l'URL de la politique dans la Métaconsole

• Les serveurs de tous les nœuds doivent avoir leur configuration API correcte dans « pandora_server.conf » ou leur configuration de URL publique dans le Setup de la console. Si vous ne l'avez pas configuré, les serveurs doivent s'héberger dans les mêmes machines dans lesquelles votres consoles se trouvent.

console_api_url http://localhost/pandora_console/include/api.php
console_api_pass pandora

• Chaque nœud doit pouvoir se connecter à son propre base de données d'historique.

• Tous les nœuds et la Métaconsole doivent être dans la même version.
• Tous les nœuds et la Métaconsole doivent être dans le même MR.

• Tous les nœuds et la Métaconsole doivent avoir la même taille de collection maximale configurée dans le Setup.

• Pour éviter les erreurs, les nœuds et la Métaconsole doivent avoir le paramètre memory_limit de fichier de configuration php.ini mis à -1, c'est-à-dire sans limite, mais uniquement pour le processus de fusion. Après l'avoir terminé, il est recommandé de le remettre à la valeur précédente. C'est le cas, puisque beaucoup de mémoire est utilisée pour fusionner les nœuds, et dans un très grand environnement (avec de nombreux éléments différents) une grande quantité de mémoire peut être utilisée, de cette façon vous vous assurez que le système peut utiliser toute la mémoire disponible. Si les éléments à fusionner dépassent la valeur de la mémoire physique disponible sur le serveur, le Merging tool échouera en raison d'une erreur inattendue, et dans les journaux de la console/Apache, vous verrez la ligne indiquant l'excès de mémoire atteint.
• Tous les nœuds doivent avoir une valeur pour le paramètre post_max_size du fichier de configuration php.ini supérieure ou égale par rapport à la valeur configurée pour le même paramètre de la Métaconsole. La valeur doit être aussi grand que la taille de la collection de fichiers plus grande que vous avez. Il faut également tenir compte du fait que ce paramètre doit avoir une valeur supérieure ou égale, tant dans les nœuds que dans la Metaconsole, à la valeur de upload_max_filesize.
• Tous les nœuds doivent avoir une valeur pour le paramètre upload_max_filesize du fichier de configuration php.ini supérieure ou égale par rapport à la valeur configurée pour le même paramètre de la Métaconsole. La valeur doit être aussi grand que la taille de la collection de fichiers plus grande que vous avez.
• Tous les nœuds et la Métaconsole doivent avoir space suffisant dans le disque qui hebérge son répertoire “attachment” pour pouvoir faire les backups (sauvegardes) de la base de données et collections.

• Tous les nœuds et la Métaconsole doivent avoir la date et l'heure de l'ordinateur correctement configuré (on recommande l'utilisation des serveurs NTP).

Bien qu'ils ne sont pas des exigénces pour le processus d'unification des bases de données con récommande fortement de faire ces actions :

• Arrêter les serveurs de tous les nœuds et la Métaconsole pendant la durée du processus. Comme les éléments fondamentaux tels que les groupes vont être modifiés, leurs identifiants peuvent être modifiés et il n'est pas recommandé que le processus serveur inclue de nouvelles références à l'environnement tant qu'il dure. Cependant, le serveur en cours d'exécution ne devrait pas être un problème dans la plupart des cas.
• Désactivez temporairement le processus cron pandora_db pour la durée du processus, pour les mêmes raisons que le serveur.

Le processus d'unification a 2 étapes différentes, une première étape pour synchroniser les différents éléments gérables depuis la Métaconsole et une seconde étape pour mettre à jour les réferences dans les événements à ces éléments centralisés. Ce processus se fait de cette manière pour permettre que la console soit accesible encore un fois aussi tôt que possible, puique la mise à jour des éléments est la partie du processus qui peut prendre lus de temps car elle a habituellement la plus grande quantité d'information. Les deux étapes sont divisés en deux sous-étapes diférenciées en deux barres de progrès.

Dans cette étape les éléments trouvés dans les bases de données de tos les nœuds gérables depuis la Métaconsole sont synchronisés. Il s'agit du processus d'unification et est sous divisé en deux étapes, chacune avec sa barre de progrès :

• Initialize: Il vérifie toutes les exigences précédentes, génère les sauvegardes correspondantes (si les exigences sont remplies) en cas d'échec d'une partie du processus et génère en mémoire le résultat de la fusion des bases de données. Si ce processus échoue pour une raison quelconque, les bases de données n'auront pas encore été modifiées, il ne sera donc pas nécessaire de restaurer les sauvegardes. Les sauvegardes sont stockées dans chaque nœud/Métaconsole dans le répertoire: pandora_console/attachment/merge_backups
• Apply: Si la phase d'initialisation précédente a réussi, le résultat de l'unification commencera à être appliqué à tous les nœuds et à la Métaconsole. Ce processus est séquentiel par ordre de priorité, donc lorsque il termine avec un, il commencera par le suivant.

Si des erreurs surviennent au cours de ce processus (par exemple, perte de connexion avec une base de données), le processus lui-même tentera de restaurer les sauvegardes générées (une troisième barre de progression rouge apparaîtra qui marquera la progression de la restauration).

• Synchronisation annulée :

Dans cette étape les références existantes dans les événements aux différents éléments synchronisés seront mis à jour (par exemple à groupes). L'étape est sous divisé en la mise à jour des événements de la base de données principale et la mise à jour des événements de la base de données historique et seulement affectera les événements qui existent avant de lancer le processus d'unification. Les nouveaux événements générées après avoir centralisé l'environnement auront toutes les références correctement et ne será pas nécessaire de les mettre à jour.

• Base de données principale : Comme les événements sont un grand volume d'informations qui sont également affectées, ce processus de mise à jour se fait en parallèle avec le fonctionnement normal de l'environnement déjà fusionné. À ce stade, le serveur et pandora_db peuvent être redémarrés normalement et les utilisateurs standard peuvent à nouveau accéder à la console. Bien sûr, vous verrez dans la vue des événements la barre de processus de mise à jour pour tous les événements, donc pour cette partie vous pouvez encore avoir des incohérences (en ce qui concerne les filtres par exemple) uniquement pour les événements qu'il y avait avant la fusion. De nouveaux événements seraient générés normalement. Cette phase et ce processus sont lancés par chacun des nœuds, via une tâche spécifique dans le cron de la console. En raison du volume d'informations, la tâche peut être lourde et longue. Dans la mesure du possible, moins l'environnement est chargé à ce moment-là, mieux c'est (essayez de le lancer en dehors des heures les plus chargées sur Pandora FMS).
• Base de données historique : Ce serait la continuation du point précédent, mettant à jour les événements dans la base de données historique sous les mêmes caractéristiques déjà indiquées.

Une fois la phase 1 terminée, l'environnement sera considéré comme centralisé, et à partir de là vous pourrez tout gérer depuis la Métaconsole. La synchronisation des éléments a également été modifiée, désormais le processus pandora_ha de chaque nœud est en charge de synchroniser sa base de données avec celle de la Métaconsole.

Lorsque nous apportons une modification à la Métaconsole (par exemple, créer un utilisateur), cela met en file d'attente les requêtes nécessaires dans la base de données pour les nœuds (INSERTS, UPDATES, etc.) que pandora_ha lit de manière ordonnée et exécute dans chaque server_threshold. Cela garantit que si un serveur est en panne pendant un certain temps, lorsqu'il est redémarré, il peut reprendre sa vitesse correctement.

Cette liste de requêtes en attente peut être consultée à partir de la Métaconsole dans la section Consoles setup. Si pour une raison quelconque une requête échoue, le nœud ne continuera pas avec les autres, nous verrons une erreur dans Consoles setup et il sera nécessaire de la traiter manuellement par un administrateur. Dans la plupart des cas, vous devriez pouvoir le résoudre en lançant à nouveau le processus de fusion dans le Merging tool.

Pour ajouter un nouveau nœud à un environnement centralisé, allez dans Setup → Metasetup → Consoles setup dans la Metaconsole et cliquez sur le bouton New node. Tous les champs doivent être remplis pour réaliser la connexion et au moment de l'enregistrement, selon qu'il s'agit d'un nœud complètement nouveau, sans aucune donnée, il sera ajouté à l'aide du bouton Register empty node, sinon le bouton Register node with data to merge sera utilisé.

• Lorsque vous utilisez le bouton Register empty node, une fenêtre d'avertissement s'affiche, indiquant que les données du nœud seront supprimées :

Appuyez sur Ok si vous êtes sûr et le nouveau nœud sera centralisé.

• L'utilisation du bouton Register node with data to merge affiche une fenêtre de confirmation indiquant que les données du nœud existant seront centralisées :

Retour à l'index de documentation de Pandora FMS