Planification d’une conception de groupe d’administration

Important

Cette version d’Operations Manager a atteint la fin du support. Nous vous recommandons de mettre à niveau vers Operations Manager 2022.

Vue d’ensemble

Un groupe d’administration est constitué d’une seule base de données opérationnelle, d’un ou de plusieurs serveurs d’administration, et d’un ou de plusieurs agents et appareils surveillés. La connexion de groupes d’administration permet d’afficher et de modifier toutes les alertes et autres données de surveillance à partir d’une console unique. Des tâches peuvent également être lancées à partir d’un groupe d’administration local pour s’exécuter sur les objets gérés d’un groupe d’administration connecté.

L’implémentation la plus simple d’Operations Manager est un groupe d’administration unique. Chaque groupe supplémentaire nécessite d’avoir au moins une base de données opérationnelle et un serveur d’administration dédiés. Chaque groupe doit également être géré séparément avec ses propres paramètres de configuration et packs d’administration, et être intégré aux autres solutions de surveillance et ITSM.

L’implémentation du groupe d’administration distribué constitue la base de 99 % des déploiements d’Operations Manager. Elle permet de distribuer des fonctionnalités et des services sur plusieurs serveurs pour profiter de la scalabilité et de la redondance de certaines fonctionnalités. Il peut inclure tous les rôles serveur Operations Manager et prend en charge la surveillance des appareils au-delà des limites d’approbation à l’aide du serveur de passerelle.

Le diagramme suivant présente une configuration convenant à la topologie de groupe d'administration distribué.

Notes

Il n’existe aucune communication directe entre la console Operations et les bases de données. Toutes les communications sont dirigées vers un serveur d’administration spécifique sur le port TCP 5724, puis vers les serveurs de base de données en utilisant OLE DB sur le port TCP 1433 ou un port défini par l’utilisateur qui a été spécifié par l’administrateur SQL pendant l’installation de l’instance du moteur de base de données SQL Server. Toutefois, il existe une communication directe entre une console Diagnostics d’application (colocalisée avec la console web) et le SQL Server hébergeant les bases de données opérationnelles et de l’entrepôt de données.

Un groupe d’administration que vous avez déployé dans votre environnement peut s’intégrer à Microsoft Operations Management Suite (OMS) et, en utilisant Log Analytics, vous pouvez mettre en corrélation, visualiser et agir sur les performances, les événements et les alertes. Cela vous offre une visibilité accrue en étant en mesure d’effectuer des recherches personnalisées sur l’ensemble du jeu de données afin de mettre en corrélation les données entre les systèmes et les applications, hébergés localement ou dans le cloud.

L’intégration à Operations Manager est étendue à d’autres produits, tels que BMC Remedy, IBM Netcool ou d’autres solutions de gestion d’entreprise utilisées par votre organisation. Pour plus d’informations sur la planification de l’interopérabilité avec ces solutions, consultez Intégration à d’autres solutions de gestion.

Composants de groupe d'administration

Serveur d’administration

Dans Operations Manager 2007, le serveur d’administration racine (le RMS) était un type particulier de serveur d’administration dans un groupe d’administration et il était le premier serveur d’administration à être installé dans un groupe d’administration. Le serveur RMS était le point central à partir duquel vous pouviez administrer la configuration d’un groupe d’administration, administrer les agents et communiquer avec eux, et communiquer avec la base de données opérationnelle et les autres bases de données dans le groupe d’administration. Il servait également de cible pour la console Opérateur et de cible privilégiée pour les consoles web. Dans System Center 2012 R2 – Operations Manager, le rôle serveur d’administration racine a été supprimé, rendant tous les serveurs d’administration homologues. Cette configuration est toujours la même dans System Center 2016 et supérieur - Operations Manager.

Le serveur RMS n’est plus un point de défaillance unique, car tous les serveurs d’administration hébergent les services qui étaient auparavant hébergés uniquement par lui. Les rôles sont distribués à tous les serveurs d'administration. Si un serveur d'administration devient indisponible, ses responsabilités sont automatiquement redistribuées. Un rôle d'émulateur RMS fournit une compatibilité ascendante pour les packs d'administration ciblant le RMS. Si vous n’avez pas de packs d’administration qui ciblaient précédemment RMS, vous n’avez pas besoin d’utiliser l’émulateur RMS.

Le groupe d'administration peut contenir plusieurs serveurs d'administration pour fournir d'autres capacités et une disponibilité permanente. Quand deux serveurs d’administration ou plus sont ajoutés à un groupe d’administration, les serveurs d’administration deviennent automatiquement partie intégrante des trois pools de ressources par défaut, et le travail est réparti entre les membres de chaque pool. Pour les pools de ressources définis personnalisés, les membres sont ajoutés manuellement. En cas de défaillance d'un membre du pool de ressources, les autres membres du pool de ressources intègrent la charge de travail de ce membre. Lorsqu’un nouveau serveur d’administration est ajouté, le nouveau serveur d’administration récupère automatiquement une partie du travail des membres existants dans le pool de ressources. Consultez les considérations relatives à la conception du pool de ressources pour en savoir plus sur leur fonctionnement et les recommandations qui influencent votre plan de conception.

Si un serveur d’administration n’est pas disponible pour une raison quelconque, les agents qui en dépendent basculent automatiquement par défaut vers un autre serveur d’administration. Quand vous choisissez le nombre et l’emplacement des serveurs d’administration, envisagez cette possibilité de basculement si la haute disponibilité est indispensable.

Les agents se connectent à un serveur d’administration pour communiquer avec tous les autres composants Operations Manager. Une partie du travail effectué par un serveur d’administration consiste à collecter les données opérationnelles envoyées par les agents et à les ajouter dans la base de données opérationnelle et l’entrepôt de données.

Un serveur d’administration standard gère environ 3 000 agents. Les performances réelles du serveur varient en fonction du volume de données opérationnelles collectées. Toutefois, chaque serveur d’administration peut généralement prendre en charge 3 000 agents, même avec un volume de données opérationnelles relativement élevé.

Le nombre maximal de serveurs d’administration par groupe d’administration n’est pas limité. Toutefois, il est recommandé d’utiliser le moins possible de serveurs d’administration après avoir abordé les contraintes de scalabilité, de haute disponibilité et de récupération d’urgence.

Les serveurs d’administration doivent bénéficier d’une bonne connectivité réseau avec l’entrepôt de données et la base de données Operations Manager, car ils envoient fréquemment d’importants volumes de données dans ces magasins. En général, ces connexions SQL Server consomment plus de bande passante et sont plus sensibles à la latence du réseau. Tous les serveurs d’administration doivent donc être installés sur le même réseau local que la base de données opérationnelle et la base de données de l’entrepôt de données, et ne doivent jamais être déployés sur un réseau étendu. La latence entre un serveur d’administration et l’instance SQL Server hébergeant les bases de données Operations Manager doit être inférieure à 10 millisecondes.

Serveur de passerelle

Dans Operations Manager, les agents et les serveurs d’administration doivent s’authentifier mutuellement avant de s’échanger des informations. Pour sécuriser le processus d'authentification entre les deux, le processus est chiffré. Lorsque l'agent et le serveur d'administration résident dans le même domaine Active Directory ou dans des domaines Active Directory ayant établi des relations d'approbation, ils utilisent des mécanismes d'authentification Kerberos V5 fournis par Active Directory. Lorsque les agents et les serveurs d’administration ne se trouvent pas dans la même limite d’approbation, d’autres mécanismes doivent être utilisés pour répondre à l’exigence d’authentification mutuelle sécurisée.

Les serveurs de passerelle sont utilisés lorsqu’un pare-feu sépare les agents des serveurs d’administration ou lorsque les agents se trouvent dans un domaine non approuvé distinct. Le serveur de passerelle agit comme un proxy entre les agents et le serveur d’administration. Sans le serveur de passerelle, les agents peuvent toujours effectuer l’authentification du certificat auprès d’un serveur d’administration, mais un certificat X.509 doit alors être émis et installé sur chaque agent à l’aide de l’outil MOMCertImport.exe, et chaque agent doit obtenir l’accès au serveur d’administration via le pare-feu. Si les agents sont dans le même domaine que le serveur de passerelle, ou s’ils se trouvent dans un domaine approuvé, ils peuvent utiliser l’authentification Kerberos. Dans ce cas, seuls le serveur de passerelle et les serveurs d’administration connectés exigent des certificats. Cela inclut la surveillance des machines virtuelles en cours d’exécution dans Microsoft Azure Infrastructure as a Service (IaaS), avec Operations Manager (c’est-à-dire la supervision cloud hybride) qui n’est pas joint au même domaine de confiance que les rôles prenant en charge le groupe d’administration Operations Manager, ou vous avez déployé Operations Manager dans Azure IaaS (une machine virtuelle avec SQL Server hébergeant les bases de données opérationnelles et une ou plusieurs machines virtuelles hébergeant le rôle serveur d’administration) et surveillent les charges de travail locales non approuvées.

L’illustration suivante présente un exemple de déploiement d’Operations Manager pour l’analyse de ressources Azure IaaS.

L’illustration suivante présente un exemple de déploiement d’Operations Manager hébergé dans Azure IaaS.

En règle générale, les serveurs de passerelle ne sont pas utilisés pour gérer l’utilisation de la bande passante, car le volume global de données envoyées par les agents à un serveur d’administration est similaire, qu’un serveur de passerelle soit utilisé ou non. L’objectif d’un serveur de passerelle est de réduire les efforts requis dans la gestion des certificats pour les agents dans des domaines non approuvés et de réduire le nombre de chemins de communication qui doivent être autorisés via des pare-feu.

• Le fait d’avoir plus de 2 000 agents par serveur de passerelle peut nuire à la capacité de récupération en cas de panne prolongée qui empêche le serveur de passerelle de communiquer avec le serveur d’administration. Nous vous recommandons d’utiliser plusieurs serveurs de passerelle si vous avez besoin de plus de 2 000 agents. L’alternative, si le temps de récupération du serveur de passerelle est un problème, consiste à tester le système pour s’assurer que le serveur de passerelle est en mesure de vider rapidement sa file d’attente après une panne prolongée entre le serveur de passerelle et le serveur d’administration. En outre, quand la file d’attente entrante sur le serveur de passerelle est pleine, les données dans la file d’attente sont supprimées selon leur priorité. Cela signifie qu’une interruption prolongée du serveur de passerelle peut entraîner la perte de données.
• Si vous avez beaucoup d’agents connectés via des serveurs de passerelle, envisagez d’utiliser un serveur d’administration dédié pour tous les serveurs de passerelle. Le fait que tous les serveurs de passerelle se connectent à un serveur d’administration unique sans aucun autre agent connecté à celui-ci peut accélérer le temps de récupération en cas de panne prolongée. La charge effective sur le serveur d’administration correspond au nombre total d’agents qui dépendent de ce serveur, soit directement, soit par le biais de serveurs de passerelle.
• Pour empêcher le serveur de passerelle d’initier la communication avec un serveur d’administration, notamment lorsqu’il est configuré pour basculer entre plusieurs serveurs d’administration pour la haute disponibilité, l’outil d’approbation de passerelle inclut l’argument de ligne de commande /ManagementServerInitiatesConnection. Cela permet à Operations Manager de se conformer à la stratégie de sécurité d’un client quand les systèmes sont déployés dans un réseau de périmètre (DMZ) ou un autre environnement réseau et que la communication peut uniquement être démarrée de l’intranet.

Serveur de console Web

La console web fournit une interface pour le groupe d’administration, accessible via un navigateur web. Il ne dispose pas de toutes les fonctionnalités de la console Operations et permet d’accéder uniquement aux vues Supervision et Mon espace de travail. La console web fournit l’accès à toutes les données de surveillance et aux tâches qui sont des actions pouvant être exécutées sur des ordinateurs surveillés à partir de la console Opérateur. L’accès aux données dans la console web est soumis aux mêmes restrictions que l’accès au contenu dans la console Opérateur.

Serveur de rapports

Création de rapports pour System Center : Operations Manager est installé sur SQL Server Reporting Services (prise en charge par la version d’Operations Manager que vous utilisez), et la seule configuration valide de Reporting Services prise en charge par Operations Manager Reporting est le mode natif.

Notes

L’installation de System Center – Operations Manager Reporting Services intègre la sécurité de l’instance SQL Reporting Services à la sécurité basée sur les rôles d’Operations Manager. N’installez pas d’autres applications Reporting Services dans ce même instance du SQL Server.

Les composants Operations Manager Reporting Server peuvent être installés sur le même serveur qui exécute SQL Server 2014 ou 2016 Reporting Services, ou sur un autre ordinateur. Pour des performances optimales, en particulier dans un environnement d’entreprise où les utilisateurs produisent des rapports parallèles en volume élevé pendant que les rapports interactifs ou planifiés sont traités simultanément, vous devez effectuer un scale-up pour gérer davantage d’utilisateurs simultanés et des charges d’exécution de rapports plus importantes. Il est recommandé que le service de création de rapports Operations Manager ne soit pas colocalisé sur le même SQL Server hébergeant la base de données de l’entrepôt de données et installé sur un système dédié.

Base de données opérationnelle

La base de données opérationnelle est une base de données SQL Server qui contient toutes les données opérationnelles, informations de configuration et règles de surveillance d’un groupe d’administration. La base de données Operations Manager étant à elle seule une source de défaillance pour le groupe d’administration, elle peut être rendue hautement disponible en utilisant des configurations de cluster prises en charge.

Pour conserver cette base de données à une taille cohérente, les paramètres de nettoyage dans Operations Manager spécifient la durée pendant laquelle les données peuvent être conservées dans la base de données. Par défaut, cette durée est de sept (7) jours.

Base de données de l’entrepôt de données Reporting

L’entrepôt de données Reporting est une base de données SQL Server qui collecte et stocke des données opérationnelles pour créer des rapports à long terme. Ces données sont écrites directement dans la base de données opérationnelle sur la base de règles de collecte des données de rapport et selon les processus de synchronisation des données définis. La maintenance de l’entrepôt de données, notamment l’agrégation, le nettoyage et l’optimisation, est effectuée automatiquement par Operations Manager.

Le tableau suivant répertorie les types de données par défaut et la période de conversation des données après l’installation initiale de la base de données de l’entrepôt de données.

Dataset	Type d’agrégation	Période de conservation (en jours)
Alerte	Brut	400
Analyse du client	Brut	30
Analyse du client	Quotidien	400
Événements	Brut	100
Performances	Brut	10
Performances	Toutes les heures	400
Performances	Quotidien	400
State	Brut	180
State	Toutes les heures	400
State	Quotidien	400

Un entrepôt de données peut servir à plusieurs groupes d’administration. Cela permet d’incorporer des données provenant de tous les ordinateurs dans l’organisation dans un seul et même rapport.

De la même manière que la base de données Operations Manager, la base de données de l’entrepôt de données peut être mise en cluster pour garantir une haute disponibilité. S’il n’est pas cluster, il doit être soigneusement surveillé afin que tous les problèmes puissent être rapidement résolus.

collecteur des services ACS

Le collecteur des services ACS reçoit et traite des événements depuis les redirecteurs ACS, puis envoie ces données à la base de données des services ACS. Ce traitement comprend le désassemblement des données afin qu’elles puissent être réparties sur plusieurs tables au sein de la base de données ACS, la réduction de la redondance des données et l’application de filtres afin que les événements inutiles ne soient pas ajoutés à la base de données ACS.

Base de données des services ACS

La base de données des services ACS correspond au référentiel centralisé des événements qui sont générés par une stratégie d'audit dans le cadre d'un déploiement ACS. La base de données des services ACS peut se trouver sur le même ordinateur que le collecteur des services ACS, mais pour des performances optimales, il convient que chacun soit installé sur un serveur dédié. Par défaut, les données sont conservées pendant quatorze (14) jours.

Redirecteur ACS

Le service exécuté sur les redirecteurs ACS est compris dans l'agent Operations Manager. Par défaut, ce service est installé lors de l'installation de l'agent Operations Manager, mais il n'est pas activé. Vous pouvez activer ce service immédiatement pour les ordinateurs à agents multiples à l’aide de la tâche Activer la collecte d’audit ou de PowerShell. Une fois ce service activé, tous les événements de sécurité sont envoyés au collecteur des services ACS en plus du Journal de sécurité local.

Remarques relatives à la conception

Vous devez prendre en considération les facteurs suivants pour déterminer si vous devez implémenter un ou plusieurs groupes d’administration :

• Augmentation de capacité. Operations Manager n’impose pas de limite concernant le nombre d’agents maximal qu’un groupe d’administration peut prendre en charge. En fonction de votre matériel et de la charge de surveillance (plus il y a de packs d’administration déployés, plus la charge de surveillance est élevée) sur le groupe d’administration, vous aurez peut-être besoin de plusieurs groupes d’administration pour garantir des performances correctes.
• Vues centralisées. Si vous utilisez plusieurs groupes d’administration pour surveiller un environnement, vous devez mettre en place un mécanisme capable de fournir une vue centralisée de toutes les données de surveillance et d’alerte collectées. Pour ce faire, vous pouvez déployer un groupe d’administration supplémentaire (avec ou sans responsabilités de surveillance) qui a accès à toutes les données dans tous les autres groupes d’administration. Ces groupes d’administration sont dits « connectés ». Le groupe d’administration utilisé pour fournir une vue centralisée des données est appelé « groupe d’administration local », tandis que les autres groupes d’administration qui lui fournissent les données sont appelés « groupes d’administration connectés ».
• Sécurité et administration. Le partitionnement des groupes d’administration pour des raisons de sécurité et d’administration est similaire dans son concept à la délégation d’autorité administrative sur les unités ou domaines d’organisation Active Directory à différents groupes d’administration. Votre entreprise peut compter plusieurs groupes informatiques, chacun ayant son propre domaine de responsabilité. Ce domaine peut correspondre à une zone géographique ou à une division spécifique de l’entreprise. Par exemple, dans le cas d’une société de portefeuille, il peut s’agir de l’une de ses filiales. Quand ce type de délégation totale de l’autorité administrative du groupe informatique centralisé est en place, il peut être utile d’implémenter une infrastructure de groupes d’administration dans chaque domaine de responsabilité. Les groupes d’administration peuvent être configurés comme groupes d’administration connectés à un groupe d’administration local qui se trouve dans le centre de données informatique centralisé.
• Langues installées. Tous les serveurs sur lesquels est installé le rôle serveur Operations Manager doivent être installés dans la même langue. Autrement dit, vous ne pouvez pas installer le serveur d’administration à l’aide de la version anglaise d’Operations Manager 2012 R2, puis déployer la console Operations à l’aide de la version japonaise. Si la surveillance englobe plusieurs langues, vous devez prévoir un groupe d’administration supplémentaire pour chaque langue utilisée par les opérateurs.
• Fonctionnalité de production et de préproduction. Dans Operations Manager, il est recommandé d’avoir une implémentation de production utilisée pour superviser vos applications de production et une implémentation de préproduction qui a une interaction minimale avec l’environnement de production. Le groupe d’administration de préproduction est utilisé pour tester et paramétrer les fonctionnalités du pack d’administration avant sa migration vers l’environnement de production. Certaines entreprises utilisent un environnement de préproduction pour les serveurs, où les nouveaux serveurs développés sont placés pendant une période de test avant d’être mis en production. Le groupe d’administration de préproduction peut être utilisé pour surveiller l’environnement intermédiaire afin de garantir l’intégrité des serveurs avant le déploiement en production.
• Fonctionnalité ACS dédiée. Si vos besoins incluent la nécessité de collecter des événements de journal de sécurité d’audit Windows ou des événements de sécurité UNIX/Linux, vous allez implémenter le service de collecte d’audit (ACS). Il peut être utile d’implémenter un groupe d’administration qui prend en charge la fonctionnalité ACS uniquement si les exigences de sécurité de votre société imposent que la fonctionnalité ACS soit contrôlée et gérée par un groupe d’administration différent de celui qui gère le reste de l’environnement de production.
• Fonctionnalité de récupération d’urgence. Dans Operations Manager, toutes les interactions avec la base de données Operations Manager sont enregistrées dans les journaux de transactions avant leur validation dans la base de données. Ces journaux de transactions peuvent être envoyés à un autre serveur exécutant Microsoft SQL Server et validées dans une copie de la base de données Operations Manager. Cette fonctionnalité offre un moyen de fournir la redondance de la base de données opérationnelle Operations Manager entre deux serveurs SQL Server du même groupe d’administration. Quand un basculement contrôlé doit être effectué, les serveurs d’administration du groupe d’administration nécessitent une modification du Registre pour référencer le serveur SQL Server secondaire et communiquer avec lui. Un groupe d’administration de basculement peut être déployé, qui correspond à la configuration exacte du groupe d’administration principal (packs d’administration, remplacements, abonnements de notification, sécurité, etc.) et les agents sont configurés pour faire rapport aux deux groupes d’administration. Si le groupe d’administration principal dans son intégralité devient indisponible pour une raison quelconque, il n’y a pas de temps d’arrêt de l’environnement de supervision. Cette solution garantit la continuité de service du groupe d’administration et aucune perte de la surveillance opérationnelle.

Avant de déployer System Center Operations Manager dans un environnement de production, planifiez la conception de votre groupe d’administration. Au cours de la phase de planification, comprenez les composants du service informatique (c’est-à-dire, au niveau de l’infrastructure et de l’application) et le nombre de systèmes et d’appareils qui les prennent en charge, comment ils intégreront et prendront en charge vos processus de gestion des incidents et comment vous visualiserez les données pour les différents niveaux de prise en charge de l’escalade des incidents, l’ingénierie, les consommateurs de services et la gestion.

Groupes d’administration connectés

La plupart du temps, les entreprises qui ont des serveurs dispersés géographiquement doivent mettre en place une surveillance centralisée de ces serveurs. La configuration du groupe d’administration connecté, illustrée ci-dessous, est un ensemble de processus de flux de travail qui sont conçus pour créer une infrastructure de gestion des systèmes hiérarchique.

Cette configuration permet de répondre aux besoins d’une surveillance centralisée. Il est conçu pour prendre en charge l’affichage des alertes et des données de surveillance, ainsi que pour lancer des tâches sur un objet managé d’un groupe d’administration connecté.

Grâce à la connexion des groupes d’administration Operations Manager, la fonctionnalité de surveillance centralisée peut être gérée, tout en permettant :

• La surveillance d’un nombre d’objets gérés supérieur par rapport à un groupe d’administration unique.
• L’isolation de l’activité de surveillance en fonction des domaines d’activité logiques, comme le marketing, ou des emplacements physiques, par exemple Rome.

Lorsque vous connectez des groupes d’administration, vous ne déployez aucun nouveau serveur ; Au lieu de cela, vous autorisez le groupe d’administration local à avoir accès aux alertes et aux informations de découverte qui se trouve dans un groupe d’administration connecté. De cette façon, vous pouvez afficher et interagir avec toutes les alertes et autres données d'analyse à partir de plusieurs groupes d'administration dans une console Opérateur unique. En outre, vous pouvez exécuter des tâches sur les ordinateurs analysés des groupes d'administration connectés. Pour apprendre à connecter des groupes d’administration, consultez Connexion de groupes d’administration dans Operations Manager.

Langues installées

Les groupes d’administration Operations Manager prennent en charge une seule langue installée. Si plusieurs langues sont installées sur l'environnement informatique global à analyser, il vous faudra un groupe d'administration séparé pour chaque langue.