Command Center
À partir de la version 756 du Pandora FMS, le système de synchronisation pour les environnements en mode centralisé a été entièrement repensé, ce qui le rend plus rapide et plus efficace, puisque les changements seront répliqués vers les nœuds automatiquement sans qu'il soit nécessaire de procéder à une synchronisation manuelle comme c'était le cas jusqu'à présent.
Ce changement défonctionne le système précédent de sorte que dans les environnements où il était actif, il devra passer par le système de fusion automatique pour utiliser le nouveau système de centralisation afin de garantir l'intégrité des données.
Lors de la mise à jour, tous les environnements Command Center déjà centralisés devront passer par la nouvelle section Merging tool située dans Centralised management afin d'être à nouveau correctement centralisés.
Seuls les nœuds configurés dans le Command Center qui ne sont pas désactivés sont pris en compte dans le processus de fusion.
L'outil de fusion fusionnera les différents éléments des bases de données des nœuds et du centre de commande (pour ceux qui doivent être gérés à partir du centre de commande) de la manière suivante: Un ordre de priorité sera établi entre les nœuds enregistrés dans le centre de commande, en plaçant les éléments les plus prioritaires en haut de la liste et les éléments les moins prioritaires en bas.
Par exemple:
Cette liste de priorités concerne les cas où le même élément existe dans les différents nœuds ou dans le centre de commande et a des configurations différentes.
Dans le cas des politiques de surveillance, les modules, les alertes et les autres éléments de la politique sont considérés comme des éléments distincts et indépendants de la politique et seront donc également fusionnés.
Exemple uniquement avec des modules:
Éléments centralisés par l'outil de fusion
Les éléments suivants sont centralisés à partir du nouvel outil Merging tool:
Utilisateurs: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui ont le même utilisateur seront considérés comme ayant le même ID utilisateur (en suivant les règles de priorité décrites ci-dessus).
Profils d'utilisateurs: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui portent le même nom seront considérés comme le même profil (selon les règles de priorité décrites ci-dessus).
Groupes d'acteurs: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui ont le même groupe seront considérés comme ayant le même nom (en suivant les règles de priorité décrites ci-dessus).
Collections de fichiers: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui portent le même nom court seront considérés comme la même collection (en suivant les règles de priorité décrites ci-dessus).
Modèles d'alerte: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui portent le même nom seront considérés comme le même modèle (en suivant les règles de priorité décrites ci-dessus).
Commandes d'alerte: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui portent le même nom seront considérés comme la même commande (selon les règles de priorité décrites ci-dessus).
Actions d'avertissement: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui portent le même nom (en suivant les règles de priorité décrites ci-dessus) seront considérés comme la même action.
Plugins de serveur: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui ont le même nom et la même exécution seront considérés comme le même plugin (en suivant les règles de priorité décrites ci-dessus).
OS: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, les nœuds ayant le
même OS seront considérés comme ayant le
même nom (en suivant les règles de priorité décrites ci-dessus).
Étiquettes des modules: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, la même balise sera considérée comme le même nom (en suivant les règles de priorité décrites ci-dessus).
Catégories de modules: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, la même catégorie sera considérée comme le même nom (en suivant les règles de priorité décrites ci-dessus).
Groupes de modules: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui ont le même groupe seront considérés comme ayant le même nom (en suivant les règles de priorité décrites ci-dessus).
Groupes de composants: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui ont le même groupe seront considérés comme ayant le même nom (en suivant les règles de priorité décrites ci-dessus).
Composants du réseau: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui ont le
même nom et le même OS seront considérés comme le
même composant (en suivant les règles de priorité décrites ci-dessus).
Composants locaux: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui ont le
même nom et le même OS seront considérés comme le
même composant (en suivant les règles de priorité décrites ci-dessus).
Modèles de composants: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui portent le même nom seront considérés comme le même modèle (en suivant les règles de priorité décrites ci-dessus).
Modules d'inventaire: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, ceux qui ont le
même nom et le même OS seront considérés comme le
même module (en suivant les règles de priorité décrites ci-dessus).
Politiques de suivi: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Dans le nœud, il sera possible d'appliquer les politiques précédemment gérées par la cible. Lors de l'unification à partir de l'outil de fusion, celles qui portent le même nom (en suivant les règles de priorité décrites ci-dessus) seront considérées comme la même politique.
Modules politiques: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil Fusion, ceux qui ont le même nom au sein d'une politique portant le même nom (en suivant les règles de priorité décrites ci-dessus) seront considérés comme le même module.
Modules d'inventaire des politiques: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil Fusion, ceux qui ont le
même nom et le même OS au sein d'une politique portant le même nom seront considérés comme le
même module (en suivant les règles de priorité décrites ci-dessus).
Plugins de politiques: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, le même plugin sera considéré comme la même exécution au sein d'une politique portant le même nom (en suivant les règles de priorité décrites ci-dessus).
Collections de politiques: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, les collections portant le même nom court dans une politique portant le même nom seront considérées comme la même collection (en suivant les règles de priorité décrites ci-dessus).
Alertes et avertissements relatifs à la politique extérieure: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, les alertes ayant le même modèle sur le même nom de module dans une politique ayant le même nom seront considérées comme la même alerte (en suivant les règles de priorité décrites ci-dessus).
Actions sur les alertes et les avertissements relatifs à la politique extérieure: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil Fusion, les actions ayant le même nom sur le même modèle sur le même nom de module au sein d'une politique ayant le même nom (en suivant les règles de priorité décrites ci-dessus) seront considérées comme la même action.
Agents au sein des politiques: Il n'est géré qu'à partir du centre de commande. La gestion des nœuds est désactivée. Lors de l'unification à partir de l'outil de fusion, les agents d'une même politique seront pris en compte dans les politiques portant le même nom. Les enregistrements d'agents dans les politiques du Command Center seront écartés et seuls les enregistrements de nœuds seront pris en compte (c'est là que se fait l'application effective).
Agents: La gestion des agents des nœuds est autorisée, à l'exception de la suppression des agents, qui doit être effectuée à partir du centre de commande.
Assurez-vous de définir le paramètre autocreate_group
des fichiers de configuration du serveur pandora_server.conf
à un identifiant de groupe valide après la fusion à partir de l'outil de fusion.
Résumé de ce qui précède:
Les éléments suivants sont centralisés dans le Command Center, conformément aux règles de priorité décrites ci-dessus, au moyen de le Merging Tool:
Élément | ID | Profil | Nom | Groupe | Exe.1) | OS |
Utilisateurs | ✅ | ❌ | ❌ | ❌ | ❌ | ❌ |
Profils d'utilisateurs | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Groupes d'acteurs | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Collections de fichiers | ❌ | ❌ | ✅ 2) | ❌ | ❌ | ❌ |
Modèles d'alerte | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Commandes d'alerte | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Actions d'avertissement | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Plugins de serveur | ❌ | ❌ | ✅ | ❌ | ✅ | ❌ |
OS | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Étiquettes des modules | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Catégories de modules | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Groupes de modules | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Groupes de composants | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Composants du réseau | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
Composants locaux | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
Modèles de composants | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Modules d'inventaire | ❌ | ❌ | ✅ | ❌ | ❌ | ✅ |
Politiques de suivi | ❌ | ❌ | ✅ | ❌ | ❌ | ❌ |
Modules politiques | ❌ | ❌ | ✅ 3) | ❌ | ❌ | ❌ |
Modules d'inventaire | ❌ | ❌ | ✅ 4) | ❌ | ❌ | ✅ |
Plugins de politique | ❌ | ❌ | ✅ 5) | ❌ | ✅ 6) | ❌ |
Collections de politiques | ❌ | ❌ | ✅ 7) | ❌ | ❌ | ❌ |
Alertes de politique
extérieure et alertes | ❌ | ❌ | ✅ 8) | ❌ | ❌ | ❌ |
Actions sur les alertes
et des alertes externes
de politiques | ❌ | ❌ | ✅ 9) | ❌ | ❌ | ❌ |
Acteurs au sein
des politiques | ❌ | ❌ | ✅ 10) | ❌ | ❌ | ❌ |
Agents 11) | ❌ | ❌ | ❌ | ❌ | ❌ | ❌ |
Les sections où ces éléments sont gérés de manière centralisée ne peuvent être gérées qu'à partir du Command Center. Si l'on accède à ces éléments à partir des nœuds, ils ne peuvent être que listés, les options d'édition et de création disparaissant. Un avertissement sera également affiché pour indiquer que l'environnement est en mode centralisé, avec un lien qui conduira l'administrateur à la section correspondante du Command Center pour la configuration de ces éléments.
Les tables suivantes sont synchronisées entre Command Center et les nœuds de le Merging Tool:
tgrupo
tcollection
tplugin
tconfig_os
ttag
tcategory
tmodule_group
tnetwork_component_group
tnetwork_component
tlocal_component
tnetwork_profile
tmodule_inventory
talert_commands
talert_actions
talert_templates
talert_calendar
talert_special_days
Le
Command Center doit pouvoir se
connecter à toutes les
bases de données et
API des nœuds. Assurez-vous que la
configuration des consoles du centre de commande est correcte et que les indicateurs sont verts.
Les consoles de nœud doivent pouvoir se connecter à la base de données du Command Center. Normalement, cela ne pose pas de problème, sauf si les consoles se trouvent sur des ordinateurs autres que les serveurs Pandora.
Il convient de s'assurer que les paramètres de la configuration du Management → Setup → Enterprise pour le Command Center sur les nœuds sont correctes.
Les
serveurs de tous les nœuds doivent pouvoir se
connecter à l'
API du Command Center. Il est recommandé de configurer l'
URL publique dans le Command Center.
Les
serveurs de tous les nœuds doivent avoir leur
configuration API correctement configurée dans
pandora_server.conf
ou leur
configuration URL publique dans le
Setup de la console. S'ils ne sont pas configurés, les serveurs doivent être hébergés sur les mêmes machines que celles où se trouvent vos consoles.
console_api_url http://localhost/pandora_console/include/api.php
console_api_pass pandora
Chaque nœud doit pouvoir se connecter à sa propre base de données historique.
Tous les nœuds et le centre de commande doivent être dans la même version.
Tous les nœuds et le centre de commande doivent être situés dans le même MR.
Tous les nœuds et le centre de commande doivent avoir la même taille maximale de collection configurée dans le Setup .
Pour éviter les erreurs, tous les nœuds et le Command Center doivent avoir le paramètre memory_limit
de php.ini
fixé à -1
, c'est-à-dire aucune limite, mais seulement pour le processus de fusion de la base de données. Une fois la fusion terminée, il est recommandé de la ramener à la valeur précédente. En effet, la fusion des nœuds utilise beaucoup de mémoire et, dans les environnements très vastes (avec de nombreux éléments différents), elle peut utiliser beaucoup de mémoire ; de cette manière, nous nous assurons que le système peut utiliser toute la mémoire disponible. Si cela n'est pas fait et que la limite de mémoire spécifiée est atteinte, l'outil de fusion échouera avec une erreur inattendue et dans les logs de la console et/ou d'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
dans php.ini
qui est plus grande ou égale à la valeur définie pour le même paramètre dans le Command Center. Cette valeur doit être au moins aussi grande que la taille de la plus grande collection de fichiers que vous possédez. Notez également que ce paramètre doit avoir une valeur supérieure ou égale à la valeur de upload_max_filesize
à la fois dans les nœuds et dans le Command Center.
Tous les nœuds doivent avoir une valeur pour le paramètre upload_max_filesize
de php.ini
qui soit plus grande ou égale à la valeur définie pour le même paramètre dans le Command Center. Cette valeur doit être au moins aussi grande que la taille de la plus grande collection de fichiers que vous possédez.
Tous les nœuds et le Command Center doivent disposer de suffisamment d'espace sur le disque hébergeant leur répertoire d'attachement pour pouvoir effectuer des backups de la base de données et des collections.
La date et l'heure de tous les nœuds et du centre de commande doivent être configurées correctement (l'utilisation de serveurs NTP est recommandée).
Si toutes ces conditions ne sont pas remplies, la fusion de nœuds ne sera pas effectuée et une erreur sera générée. Si les erreurs de résultat sont interrogées, un message indiquant les exigences encore en suspens sera affiché.
Il est important, une fois l'unification des bases de données effectuée, que le paramètre memory_limit
du fichier de configuration php.ini
soit réinitialisé à la valeur correspondante. N'oubliez pas que pour que le changement prenne effet, le service apache httpd
doit être redémarré.
Bien qu'il ne s'agisse pas d'une exigence du processus d'unification de la base de données, il est fortement recommandé d'effectuer les actions suivantes:
Arrêtez les serveurs de tous les nœuds et le Command Center pendant la durée du processus. Étant donné que des éléments fondamentaux tels que les groupes seront modifiés, leurs identifiants peuvent être changés, et il n'est pas recommandé de faire en sorte que le processus de serveur inclue de nouvelles références à l'environnement pendant la durée du serveur. Toutefois, l'exécution du serveur ne devrait pas poser de problème dans la plupart des cas.
Arrêtez le processus pandora_db
du cron temporairement pour la durée du processus, pour les mêmes raisons que le serveur.
Lorsque le processus de fusion démarre, les nœuds et le Command Center passent en mode maintenance pour les utilisateurs standards (pas pour les administrateurs). L'objectif est le même que celui de la recommandation d'arrêter les serveurs et le pandora_db
, afin d'éviter qu'un utilisateur ne modifie des éléments pendant le processus et ne provoque des erreurs ou des incohérences.
Exécution du processus de fusion
Le processus de fusion comporte 2 phases distinctes, une première phase pour synchroniser les différents éléments qui peuvent être gérés depuis le Command Center et une seconde phase pour mettre à jour les références des événements à ces éléments centralisés. Ce processus est réalisé de manière à permettre à la console d'être à nouveau accessible le plus rapidement possible, étant donné que la mise à jour des événements est la partie du processus qui peut prendre le plus de temps car elle implique généralement le plus grand volume d'informations. Ces deux phases sont à leur tour divisées en deux autres sous-phases différenciées par deux barres de progression.
Phase 1 : Synchronisation de l'environnement
Au cours de cette phase, les éléments présents dans les bases de données de tous les nœuds pouvant être gérés à partir du Command Center sont synchronisés. Il s'agit du processus de fusion en tant que tel, qui se subdivise en deux autres phases, chacune ayant sa propre barre de progression:
Initialize: Il vérifie toutes les exigences susmentionnées, génère les backups correspondantes (si les exigences sont remplies) en cas d'échec d'une partie du processus et génère le résultat de la fusion des bases de données en mémoire. Si ce processus échoue pour une raison quelconque, les bases de données restent inchangées et il n'est donc pas nécessaire de restaurer les backups. Les sauvegardes sont stockées sur chaque nœud/centre de commande dans son répertoire attachment
sous attachment/merge_backups
.
Apply: Si la phase de démarrage précédente a été couronnée de succès, elle commence à appliquer la fusion à tous les nœuds et au centre de commandement. Ce processus est séquentiel par ordre de priorité, de sorte que lorsqu'il a terminé l'un des nœuds, il commence le suivant.
Si des erreurs surviennent au cours de ce processus (par exemple, perte de connexion à une base de données), le processus lui-même tentera de restaurer les backups générées (vous verrez une troisième barre de progression rouge indiquant la progression de la restauration).
Si la raison de la défaillance empêche la récupération des backups, celle-ci doit être effectuée manuellement.
Des erreurs inattendues peuvent parfois se produire, par exemple la perte momentanée de connexion entre le centre de commande et la base de données d'un nœud ou l'impossibilité de créer une backup/ en raison d'un manque d'espace sur le disque, de sorte qu'il est possible que le message d'erreur affiché soit générique. Si c'est le cas et que vous en avez besoin, veuillez contacter l'équipe d'assistance de Pandora FMS pour obtenir de l'aide.
Phase 2 : Mise à jour des événements
Au cours de cette phase, les références existantes dans les événements aux différents éléments qui ont été synchronisés (par exemple, aux groupes) sont mises à jour. Cette phase se subdivise en une mise à jour des événements de la base de données principale et une mise à jour des événements de la base de données historique, et n'affecte que les événements qui existaient avant le lancement du processus de fusion. Les nouveaux événements générés après la centralisation de l'environnement auront toutes les références correctement et ne devront pas être mis à jour.
Base de données principale: Comme les événements représentent un volume important d'informations qui sont également affectées, ce processus de mise à jour est effectué 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. Cependant, ils verront dans la vue des événements la barre de progression de la mise à jour de tous les événements, donc pour cette partie ils peuvent encore avoir des incohérences (concernant les filtres par exemple) seulement pour les événements qui existaient avant la fusion. Les nouveaux événements seront générés normalement. Cette phase et ce processus sont lancés par chacun des nœuds, au moyen d'une tâche spécifique du cron de la console. En raison du volume d'informations, il peut s'agir d'une tâche lourde et fastidieuse, de sorte que, dans la mesure du possible, moins l'environnement est sollicité à ce moment-là, mieux c'est.
Base de données historique: Il s'agirait de la suite du point précédent, en mettant à jour les événements de la base de données historique selon 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 ce moment-là, nous pourrons tout gérer depuis le Centre de commandement. La synchronisation des éléments a également été modifiée, le pandora_ha
de chaque nœud étant désormais chargé de synchroniser sa base de données avec celle du Centre de commandement.
Cela fonctionne de la manière suivante : lorsque nous effectuons un changement dans le Command Center (par exemple, la création d'un utilisateur), cela met en file d'attente pour les nœuds les requêtes nécessaires à la base de données (INSERTS
, UPDATES
, etc.) que le pandora_ha
lit de manière ordonnée à partir de la base de données du Command Center et exécute à chaque server_threshold. Cela garantit que si un serveur est arrêté pendant un certain temps, lorsqu'il est redémarré, il peut être mis à jour correctement.
Cette liste de requêtes en attente peut être consultée à partir du Command Center dans la section Consoles setup. Si, pour une raison quelconque, une requête échoue, le nœud ne continuera pas avec les autres, vous verrez une erreur dans Consoles setup et vous devrez la traiter manuellement par un administrateur. Dans la plupart des cas, vous devriez pouvoir résoudre ce problème en relançant le processus de fusion dans le Merging Tool.
Inclusion de nouveaux nœuds dans le centre de commandement
Pour ajouter un nouveau nœud à un environnement centralisé, accédez au Command Center à l'adresse suivante Setup → Metasetup → Consoles setup → New node. Tous les champs doivent être remplis pour établir la connexion et lors de l'enregistrement, selon qu'il s'agit d'un nœud entièrement nouveau sans aucune donnée, il sera ajouté à l'aide du bouton Register empty node, dans le cas contraire, le Register node with data to merge.
Appuyez sur OK si vous êtes sûr et le nouveau nœud sera centralisé.
Retour à l'index de la documentation du Pandora FMS