Planification d’une conception de groupe d’administration

Vue d’ensemble

Un groupe d’administration est identifié par une base de données opérationnelle unique, un ou plusieurs serveurs d’administration et un ou plusieurs agents et appareils surveillés. La connexion de groupes d’administration permet aux alertes et à d’autres données de surveillance d’être consultées et modifiées à partir d’une seule console. Les tâches peuvent également être lancées à partir d’un groupe d’administration local pour s’exécuter sur les objets managés d’un groupe d’administration connecté.

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

L’implémentation du groupe d’administration distribué constitue la base de 99 % des déploiements Operations Manager. Il permet la distribution des fonctionnalités et des services sur plusieurs serveurs afin de permettre la scalabilité et la redondance de certaines de ces fonctionnalités. Il peut inclure tous les rôles de 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é.

Remarque

Il n’existe aucune communication directe entre la console Opérateur 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 utilisant OLE DB sur TCP 1433 ou un port défini par l’utilisateur spécifié par l’administrateur SQL lors de 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 SQL Server hébergeant les bases de données opérationnelles et d’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ées localement ou dans le cloud.

L’intégration à Operations Manager s’étend à 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 du groupe d’administration

Serveur d'administration

Dans Operations Manager 2007, le serveur d’administration racine (RMS) était un type spécialisé de serveur d’administration dans un groupe d’administration et était le premier serveur d’administration installé dans un groupe d’administration. RmS était le point focal pour administrer la configuration du groupe d’administration, administrer et communiquer avec les agents, et communiquer avec la base de données opérationnelle et d’autres bases de données du groupe d’administration. RmS a également servi de cible pour la console Opérateur et la cible préférée pour les consoles Web. Dans System Center 2012 R2 – Operations Manager, le rôle serveur d’administration racine a été supprimé et tous les serveurs d’administration sont désormais homologues. Cette configuration continue d’exister dans System Center 2016 et versions ultérieures - Operations Manager.

RmS n’est plus un point de défaillance unique, car tous les serveurs d’administration hébergent les services précédemment hébergés uniquement par rmS. 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’aurez 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. Lorsque deux serveurs d’administration ou plus sont ajoutés à un groupe d’administration, les serveurs d’administration font automatiquement partie des trois pools de ressources par défaut et le travail est réparti entre les membres du 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 certaines tâches des membres existants dans le pool de ressources. Passez en revue 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, par défaut, les agents qui s’appuient dessus basculent automatiquement vers un autre serveur d’administration. Lorsque vous sélectionnez le nombre et le placement des serveurs d’administration, cette capacité de basculement doit être prise en compte si la haute disponibilité est requise.

Les agents se connectent à un serveur d’administration pour communiquer avec tous les autres composants Operations Manager. Certaines tâches effectuées par un serveur d’administration sont le processus de prise des données opérationnelles envoyées par les agents et leur insertion dans la base de données opérationnelle et l’entrepôt de données.

Un serveur d’administration classique 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, les serveurs d’administration peuvent généralement prendre en charge 3 000 agents chacun, même avec un volume relativement élevé de données opérationnelles.

Il n’existe aucune limite quant au nombre maximal de serveurs d’administration par groupe d’administration. Toutefois, il est recommandé d’utiliser autant de serveurs d’administration que possible après avoir abordé les contraintes d’extensibilité, de haute disponibilité et de récupération d’urgence.

Les serveurs d’administration doivent disposer d’une bonne connectivité réseau à la base de données Et à l’entrepôt de données Operations Manager, car ils envoient fréquemment de grandes quantités de données à ces magasins. En général, ces connexions SQL Server consomment plus de bande passante et sont plus sensibles à la latence réseau. Par conséquent, tous les serveurs d’administration doivent se trouver 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 jamais être déployés sur un réseau étendu. Il doit y avoir moins de 10 millisecondes de latence entre un serveur d’administration et une instance SQL Server hébergeant les bases de données Operations Manager.

Serveur de passerelle

Operations Manager nécessite une authentification mutuelle entre les agents et les serveurs d’administration avant l’échange d’informations entre eux. 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 satisfaire à 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 en tant que proxy entre les agents et le serveur d’administration. Sans le serveur de passerelle, les agents peuvent toujours effectuer l’authentification par certificat auprès d’un serveur d’administration, mais un certificat X.509 doit être émis et installé sur chaque agent à l’aide de l’outil de MOMCertImport.exe, et chacun nécessite l’accès au serveur d’administration via le pare-feu. Si les agents se trouvent 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, seul le serveur de passerelle et les serveurs d’administration connectés nécessitent des certificats. Cela inclut la surveillance des machines virtuelles exécutées dans l’infrastructure en tant que service (IaaS) Microsoft Azure, avec Operations Manager (c’est-à-dire la supervision du cloud hybride) qui n’est pas jointe au même domaine approuvé que les rôles prenant en charge le groupe d’administration Operations Manager, ou que 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 des machines virtuelles non approuvées charges de travail locales.

Voici un exemple de déploiement Operations Manager qui surveille les ressources Azure IaaS.

Voici un exemple de déploiement 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 des agents à un serveur d’administration est similaire si un serveur de passerelle est utilisé ou non. L’objectif prévu d’un serveur de passerelle est de réduire l’effort nécessaire pour gérer les 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 par le biais de pare-feu.

• Le fait d’avoir plus de 2 000 agents par serveur de passerelle peut affecter la possibilité de récupérer en cas de panne prolongée qui empêche le serveur de passerelle de communiquer avec le serveur d’administration. Plusieurs serveurs de passerelle sont recommandés si plus de 2 000 agents sont requis. 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. De plus, une fois la file d’attente entrante sur le serveur de passerelle remplie, les données de la file d’attente sont supprimées en fonction de sa priorité, ce qui signifie qu’une panne de serveur de passerelle soutenue dans ce scénario peut entraîner des pertes de données.
• Lorsqu’un grand nombre d’agents sont 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 seul serveur d’administration 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 est le nombre total d’agents qui lui sont signalés directement ou par le biais de serveurs de passerelle.
• Pour empêcher le serveur de passerelle de lancer 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 lorsque les systèmes sont déployés dans une zone DMZ ou un autre environnement réseau et que la communication ne peut être lancée qu’à partir de l’intranet.

Serveur de console Web

La console Web fournit une interface au groupe d’administration accessible via un navigateur Web. Elle ne dispose pas de la fonctionnalité complète de la console Opérateur et fournit l’accès uniquement aux vues Surveillance et Mon espace de travail. La console web permet d’accéder à toutes les données et tâches de surveillance qui sont des actions qui peuvent ê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 a les mêmes restrictions que l’accès au contenu dans la console Opérateur.

Serveur de reporting

Reporting pour System Center – Operations Manager est installé sur SQL Server Reporting Services (qui est pris 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 en mode natif.

Remarque

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 Operations Manager. N’installez aucune autre application Reporting Services dans cette même instance de SQL Server.

Les composants Operations Manager Report 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 avec une génération de rapports parallèles en volume élevé par les utilisateurs tandis que les rapports interactifs ou planifiés sont traités simultanément, vous devez effectuer un scale-up pour gérer des utilisateurs plus simultanés et des charges d’exécution de rapports plus volumineuses. Il est recommandé que le service Operations Manager Reporting ne soit pas colocalisé sur le même serveur 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, les informations de configuration et les règles de surveillance d’un groupe d’administration. La base de données Operations Manager est une source unique d’échec pour le groupe d’administration. Elle peut donc être rendue hautement disponible à l’aide de configurations de clustering 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 ces données peuvent être conservées. Par défaut, cette durée est de sept (7) jours.

Base de données Reporting Data Warehouse

L’entrepôt de données reporting est une base de données SQL Server qui collecte et stocke les données opérationnelles pour la création de rapports à long terme. Ces données sont écrites directement à partir de règles qui collectent des données à signaler et à partir de processus de synchronisation des données dans la base de données opérationnelle. La maintenance de l’entrepôt de données, y compris l’agrégation, le nettoyage et l’optimisation, est effectuée automatiquement par Operations Manager.

Le tableau suivant met en évidence les types de données et la période de rétention par défaut après la configuration initiale de la base de données de l’entrepôt de données.

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

Un entrepôt de données peut servir plusieurs groupes d’administration. Cela permet à un rapport unique d’incorporer des données de tous les ordinateurs de l’organisation.

Comme la base de données Operations Manager, la base de données de l’entrepôt de données peut être en cluster pour 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 inclut le désassemblage des données afin qu’elles puissent être réparties entre plusieurs tables au sein de la base de données ACS, ce qui réduit la redondance des données et applique des 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 pour plusieurs ordinateurs d’agent à la fois à 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.

Considérations sur la conception

Les facteurs suivants doivent être pris en compte lors de la décision d’implémenter un ou plusieurs groupes d’administration :

• Capacité accrue. Operations Manager n’a pas de limites intégrées concernant le nombre d’agents qu’un seul groupe d’administration peut prendre en charge. En fonction du matériel que vous utilisez et de la charge de surveillance (davantage de packs d’administration déployés signifie une charge de surveillance plus élevée) sur le groupe d’administration, vous devrez peut-être plusieurs groupes d’administration afin de maintenir les performances acceptables.
• Vues consolidées. Lorsque plusieurs groupes d’administration sont utilisés pour surveiller un environnement, un mécanisme est nécessaire pour fournir une vue consolidée des données de surveillance et d’alerte à partir de celles-ci. Pour ce faire, vous pouvez déployer un groupe d’administration supplémentaire (qui peut ou non avoir des responsabilités de surveillance) qui a accès à toutes les données de tous les autres groupes d’administration. Ces groupes d’administration sont alors dits connectés. Le groupe d’administration utilisé pour fournir une vue consolidée des données est appelé groupe d’administration local, et les autres qui fournissent des données sont appelées 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 au concept de délégation d’autorité administrative sur des unités organisationnelles ou des domaines Active Directory à différents groupes d’administration. Votre entreprise peut inclure plusieurs groupes informatiques, chacun ayant sa propre zone de responsabilité. Il peut s’agir d’une zone géographique spécifique ou d’une division commerciale. Par exemple, dans le cas d’une société de portefeuille, il peut s’agir de l’une des filiales. Lorsque ce type de délégation complète de l’autorité administrative du groupe informatique centralisé existe, il peut être utile d’implémenter une structure de groupe d’administration dans chacun des domaines. Ils peuvent ensuite être configurés en tant que groupes d’administration connectés à un groupe d’administration local qui réside dans le centre de données informatique centralisé.
• Langues installées. Tous les serveurs dotés d’un rôle serveur Operations Manager installés sur eux 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 Opérateur à l’aide de la version japonaise. Si la surveillance doit s’étendre sur plusieurs langues, un groupe d’administration supplémentaire sera nécessaire pour chaque langue des 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 surveiller 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 dans l’environnement de production. En outre, certaines entreprises utilisent un environnement intermédiaire pour les serveurs où les serveurs nouvellement construits sont placés pendant une période de brûlure avant d’être placés en production. Le groupe d’administration de préproduction peut être utilisé pour surveiller l’environnement intermédiaire pour garantir l’intégrité des serveurs avant le déploiement de production.
• Fonctionnalités ACS dédiées. 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 fonction ACS exclusivement si les exigences de sécurité de votre entreprise imposent que la fonction ACS soit contrôlée et administrée par un groupe administratif autre que 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 des transactions avant d’être validées dans la base de données. Ces journaux de transactions peuvent être envoyés à un autre serveur exécutant Microsoft SQL Server et validés dans une copie de la base de données Operations Manager. Cette fonctionnalité est une option permettant de fournir une redondance de la base de données opérationnelle Operations Manager entre deux serveurs SQL Server dans le même groupe d’administration. Lorsqu’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 et communiquer avec le serveur SQL Server secondaire. 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 signaler les deux groupes d’administration. Si le groupe d’administration principal dans son intégralité devient indisponible pour une raison quelconque, il n’y a aucun temps d’arrêt de l’environnement de surveillance. Cette solution garantit la continuité du service du groupe d’administration et aucune perte de surveillance opérationnelle.

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

Groupes d'administration connectés

De nombreuses entreprises disposant de serveurs dans plusieurs emplacements géographiques nécessitent une surveillance centralisée de ces serveurs. La configuration du groupe d’administration connecté, illustrée dans l’image ci-dessous, est un ensemble de processus de flux de travail conçus pour créer une infrastructure de gestion de systèmes hiérarchiques.

Cette configuration peut être utilisée pour effectuer une surveillance centralisée. Il est conçu pour prendre en charge l’affichage des alertes et des données de surveillance, et lancer des tâches sur un objet managé d’un groupe d’administration connecté.

En connectant des groupes d’administration Operations Manager, les fonctionnalités de supervision centralisée peuvent être conservées tout en activant :

• Surveillance d’un plus grand nombre d’objets de gestion que possible avec un seul groupe d’administration.
• Isolation de l’activité de surveillance en fonction des unités commerciales logiques, telles que le « marketing » ou les emplacements physiques, tels que Rome.

Lorsque vous connectez des groupes de gestion, vous ne déployez pas de nouveaux serveurs, mais vous permettez au groupe de gestion local d'avoir accès aux alertes et aux informations de découverte qui se trouvent dans un groupe de gestion 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 savoir comment connecter des groupes d’administration, consultez Connexion de groupes d’administration dans Operations Manager.

Langues installées

Les groupes d’administration Operations Manager ne prennent en charge qu’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.