====== Command Center ====== {{indexmenu_n>4}} ===== 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 (//[[:fr:documentation:pandorafms:introduction:03_glossary#merging_code|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. [[:wiki:01_system_not_centralised.png?media=wiki:01_system_not_centralised.png|{{ :wiki:01_system_not_centralised.png?nolink& }}]] [[:wiki:02_command_center_menu.png?media=wiki:02_command_center_menu.png|{{ :wiki:02_command_center_menu.png?nolink& }}]] [[:wiki:03_command_center.png?media=wiki:03_command_center.png|{{ :wiki:03_command_center.png?nolink& }}]] 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 : [[:wiki:04_nodes_priority_order.png?media=wiki:04_nodes_priority_order.png|{{ :wiki:04_nodes_priority_order.png?nolink& }}]] \\ Seulement les nœuds configurés dans la Métaconsole qui ne sont pas désactivés sont tenus sur compte pour le processus de mélange.\\ 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). \\ Uniquement pour les propres paramètres de la politique (groupe, description,…). Les modules, alertes et autres éléments de la politique sont considérés comme des éléments distincts indépendants de la politique et sont donc également fusionnés.\\ \\ 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 : [[:wiki:05_tree_view_not_merged_env.png?media=wiki:05_tree_view_not_merged_env.png|{{ :wiki:05_tree_view_not_merged_env.png?nolink& }}]] Le résultat de l'unifiction du Merging tool serait : [[:wiki:06_tree_view_merged_env.png?media=wiki:06_tree_view_merged_env.png|{{ :wiki:06_tree_view_merged_env.png?nolink& }}]] 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. ==== Éléments centralisés par le Merging tool ==== 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). Vérifiez que vous ajustez le paramètre ''autocreate_group'' des fichiers de configuration des serveurs ''pandora_server.conf'' par un ID de groupe valide après avoir unifié depuis le Merging tool. * **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. {{ :wiki:07_policies_centralised.png }} === Tables de base de données utilisées pour le Merging tool === Les tableaux suivants sont synchronisés entre la Metaconsole et les nœuds du Merging tool (voir également « [[:fr:documentation:pandorafms:complex_environments_and_optimization:09_pandorafms_engineering#tables_principales_de_la_base_de_donnees|Tables principales de la base de données]] ») : \\ * tgroup * 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 * tprofile * tuser * tuser_profile * tpolicies * tpolicy_modules * tpolicy_modules_inventory * tpolicy_plugins * tpolicy_collections * tpolicy_alerts * tpolicy_alerts_actions * tautoconfig * tautoconfig_rules * tautoconfig_actions * tpolicy_agents \\ ==== Prérequis pour lancer la fusion de la base de données Merging tool ==== * 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. {{ :wiki:08_consoles_setup.png }} * 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. {{ :wiki:09_node_enterprise_setup.png }} * 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 {{ :wiki:10_metaconsole_public_url.png }} * 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 {{ :wiki:11_node_public_url.png }} * Chaque **nœud** doit pouvoir se **connecter **à son propre **base de données d'historique.** {{ :wiki:12_node_historical_database.png }} * 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**. {{ :wiki:13_version_mr.png }} * Tous les **nœuds et la Métaconsole** doivent avoir la **même taille de collection maximale** configurée dans le **Setup**. {{ :wiki:14_collection_size.png }} * 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.** {{ :wiki:15_attachment_dir_path.png }} * 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). \\ Si toutes ces exigences ne sont pas remplies, la fusion de nœuds ne sera pas effectué et une erreur sera générée. Si vous consultez les erreurs du résultat, cela vous donnera un message des exigences encore en suspens. \\ Il est important une fois l'unification de la base de données effectuée que la valeur correspondante du ''memory_limit'' de fichier de configuration ''php.ini'' soit remise (rappelez-vous que pour que la modification prenne effet, le service apache httpd doit être redémarré) ==== Recommandations avant le lancement du Merging tool ==== 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. \\ Lorsque le processus de fusion démarre, les nœuds et la Métaconsole passent en mode maintenance. Le but de ceci est le même que la recommandation d'arrêter les serveurs et le''pandora_db'', pour empêcher un utilisateur de modifier des éléments au cours du processus, ce qui peut provoquer des erreurs ou des incohérences. \\ {{ :wiki:pfms-metaconsole-command_center_05.png?nolink& }} ==== Exécution du processus d'unification ==== 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. === Phase 1 éléments === 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. {{ :wiki:18_merge_success.png }} 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). \\ Si la raison de l'échec empêche la récupération des sauvegardes, la récupération doit être effectuée manuellement. \\ {{ :wiki:17_initialize_error.png }} * Synchronisation annulée : {{ :wiki:19_merge_error.png }} \\ PArfois vous pouvez trouver des erreurs, par exemple la perte de connexion momentané entre la Métaconsole et la base de données d'un nœud ou l'imposibilité de créer une sauvegarde car vous n'avez pas d'espace dans le disque, donc il est possible que le message d'erreur montrè soit générique. Si c'est le cas, veuillez contacter l'équipe de support Pandora FMS pour recevoir de l'assistance. \\ === Phase 2 événements === 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. {{ :wiki:20_events_success.png }} ==== Environnement déjà centralisé par le biais du Merging tool ==== 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. {{ :wiki:21_metaconsoles_setup_sync_queue.png }} {{ :wiki:22_sync_queue.png }} === Inclusion de nouveaux nœuds === 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é. {{ :wiki:pfms-command_center-new_node.png }} * 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 : {{ :wiki:node_data_will_be_wiped_out.png }} 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 : {{ :wiki:node_data_will_be_merged.png }} [[:fr:documentation:start|Retour à l'index de documentation de Pandora FMS]]