Considérations relatives à la conception de pools de ressources

Important

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

Un pool de ressources est un regroupement logique de serveurs d’administration et/ou de serveurs de passerelle qui se répartissent le travail et qui prennent en charge le travail des membres du pool qui sont en échec. En d’autres termes, ils fournissent aux flux de travail une haute disponibilité et une grande scalabilité. Quand vous concevez un groupe d’administration, vous devez prendre en considération certains éléments concernant la surveillance des appareils réseau, les systèmes Linux/UNIX et d’autres charges de travail qui sont conçues pour tirer parti d’un pool de ressources.

Vue d’ensemble

Les pools de ressources assurent la continuité de la surveillance en fournissant plusieurs membres qui sont des serveurs d’administration et/ou serveurs de passerelle pouvant prendre en charge la surveillance des flux de travail si l’un des membres du pool n’est plus disponible. Vous pouvez créer des pools de ressources à des fins spécifiques. Par exemple, vous pouvez créer un pool de ressources de serveurs d’administration dans votre centre de données principal pour surveiller les appareils réseau.

Les pools de ressources appliquent une logique similaire au clustering « jeu de nœud majoritaire », où (< nombre de nœuds membres du pool > /2) + 1. Au minimum, il doit y avoir trois membres dans le pool pour maintenir le quorum, qui doit représenter plus de 50 % des membres votants du quorum dans un pool pour assurer la disponibilité du pool. Si vous n’avez que deux membres du pool et qu’un n’est pas disponible, vous avez perdu le quorum.

Pour chaque pool de ressources créé dans la console Operations, la base de données Operations Manager, appelée observateur par défaut, reçoit toujours un vote, même si vous avez un nombre pair de membres dans le pool pour permettre d’atteindre le quorum. Cela s’applique également aux trois pools de ressources créés par défaut lorsque vous créez le groupe d’administration pour la première fois, ce qui est décrit plus loin dans cet article. Pour tous les pools de ressources créés à l’aide de l’applet de commande PowerShell NewSCOM-ResourcePool, ce paramètre est désactivé par défaut. L’ajout de la base de données Operations Manager comme observateur par défaut réduit la complexité de votre groupe d’administration en vous demandant seulement de déployer deux serveurs d’administration au minimum pour garantir une haute disponibilité de vos pools de ressources.

Un autre rôle prenant en charge un pool de ressources est le rôle Observateurs. Il s’agit d’un serveur d’administration ou d’un serveur de passerelle qui ne participe pas au chargement des flux de travail pour le pool ; toutefois, ils participent aux décisions de quorum. Il n’est jamais utilisé dans des circonstances normales et ne doit donc pas être pris en compte.

Il existe deux types d’appartenance :

• Automatique
• Manuel

Lorsque vous créez un pool de ressources, son appartenance est définie comme manuelle et ne peut pas être reconfigurée sur Automatique. Quand un groupe d’administration System Center – Operations Manager est créé, trois pools de ressources sont créés par défaut avec une appartenance automatique. Le tableau suivant décrit ces trois pools de ressources.

Nom du pool de ressources	Description
Pool de ressources Tous les serveurs d'administration	Exécute les flux de travail concernant les calculs de groupe, la disponibilité, le cumul distribué d’intégrité de l’analyse et le nettoyage des bases de données.
Pool de ressources Notifications	Les flux de travail du service d’abonnement aux alertes ciblent ce pool de ressources pour prendre en charge les notifications d’alerte.
Pool de ressources Affectation Active Directory	Les flux de travail d’intégration Active Directory ciblent ce pool de ressources pour prendre en charge l’attribution automatique d’agents aux serveurs d’administration.

Étant donné que l’appartenance au pool de ressources Tous les serveurs d’administration est automatique, tous les serveurs d’administration mis en service deviendront automatiquement membres de ce pool de ressources. Selon les architectures et les exigences de conception, comme celles d’intégrer les opérations de récupération géographiquement dispersées, l’affectation automatique au pool de ressources de tous les serveurs d’administration n’est pas toujours souhaitable. Dans ces situations, il est possible de modifier l’affectation de l’appartenance d’automatique en manuelle. Les serveurs d’administration doivent donc être ajoutés au pool de ressources de tous les serveurs d’administration par le biais de l’affectation manuelle.

Notes

L'appartenance du pool de ressources de tous les serveurs d'administration est en lecture seule. Pour lui attribuer une appartenance manuelle plutôt qu’automatique, consultez Modification de l’appartenance au pool de ressources.

Avec l’introduction des pools de ressources, il est recommandé que tous les membres soient connectés par un réseau à faible latence (moins de 10 ms). Les pools de ressources ne doivent pas être déployés sur plusieurs centres de données ou dans un environnement cloud hybride comme Microsoft Azure.

Exemples de disponibilité du pool de ressources

Les exemples suivants illustrent le concept de disponibilité du pool de ressources selon les configurations suivantes, uniquement avec des serveurs d’administration ou uniquement avec des serveurs de passerelle.

Serveur d’administration unique

• L’observateur par défaut est activé par défaut et n’offre aucun avantage, car il existe seulement deux membres et le quorum n’est pas atteint.
• Il n’y a pas de haute disponibilité, car le serveur d’administration est un point de défaillance unique.

Deux serveurs d’administration

• L’observateur par défaut est activé par défaut.
• Il existe une haute disponibilité pour le pool, car il existe trois membres votants : deux serveurs d’administration et l’observateur par défaut.
• Si vous désactivez l’observateur par défaut, vous perdez la haute disponibilité pour le pool.

Trois serveurs d’administration

• L’observateur par défaut est activé par défaut.
• Il existe une haute disponibilité pour le pool, car il existe quatre membres votants : trois serveurs d’administration et l’observateur par défaut.
• Par défaut, un seul serveur d’administration peut ne pas être disponible afin de maintenir le quorum. Si deux serveurs d’administration ne sont pas disponibles, vous avez exactement 50 % de membres votants et le pool de ressources ne fonctionne plus pour gérer les charges de travail de supervision.
• L’observateur par défaut n’augmentant pas le nombre de serveurs d’administration qui peuvent être arrêtés, il n’augmente pas la disponibilité du pool.
• Vous pouvez envisager de supprimer l’observateur par défaut dans ce scénario.

Quatre serveurs d’administration

• L’observateur par défaut est activé par défaut.
• Il existe une haute disponibilité pour le pool, car il y a cinq membres votants : quatre serveurs d’administration et l’observateur par défaut.
• Par défaut, deux serveurs d’administration uniquement peuvent ne pas être disponibles afin de maintenir le quorum. Si trois serveurs d’administration sont en panne, vous avez moins de 50 % de membres votants et le pool de ressources ne fonctionne plus pour gérer les charges de travail de supervision.
• L’observateur par défaut dans ce scénario est important, car il augmente le nombre de serveurs d’administration qui peuvent être arrêtés. Sans l’observateur par défaut, vous n’auriez que quatre membres du quorum, ce qui ne permettrait qu’à un seul membre de ne pas être disponible.

Cinq serveurs d’administration

• L’observateur par défaut est activé par défaut.
• Il existe une haute disponibilité pour le pool, car il y a six membres votants - cinq serveurs d’administration et l’observateur par défaut.
• Par défaut, deux serveurs d’administration uniquement peuvent ne pas être disponibles afin de maintenir le quorum. Si trois serveurs d’administration ne sont pas disponibles, cela représente exactement 50 % des membres votants et le pool de ressources n’est plus opérationnel pour gérer les charges de travail de surveillance.
• L’observateur par défaut n’augmentant pas le nombre de serveurs d’administration qui peuvent être arrêtés, il n’augmente pas la disponibilité du pool.
• Vous pouvez envisager de supprimer l’observateur par défaut dans ce scénario.

Une fois que vous avez atteint au moins trois serveurs d’administration dans un pool de ressources, où vous avez un nombre impair de membres dans le pool, vous pouvez envisager de supprimer l’observateur par défaut en tant que membre. Si vous atteignez cinq serveurs d’administration, la base de données opérationnelle risque de subir une charge importante, ce qui peut générer une latence suffisante pour affecter les calculs du pool de ressources.

De la façon dont l’observateur par défaut joue un rôle, chaque serveur d’administration dans le pool interroge son propre service SDK local, ce qui lui permet de rechercher l’observateur par défaut dans une table de la base de données opérationnelle. Si la base de données ou le service SDK est chargé, il se produit une latence qui n’existerait pas autrement.

Serveur de passerelle unique

• L’observateur par défaut est activé par défaut.
• Il n’y a pas de haute disponibilité, car le serveur de passerelle est un point de défaillance unique.
• L’observateur par défaut ne doit pas être utilisé ici, car les serveurs de passerelle n’ont pas de service SDK local et ne peuvent donc pas interroger la base de données opérationnelle.

Deux serveurs de passerelle

• L’observateur par défaut est activé par défaut.
• Il n’y a pas de haute disponibilité, car il n’y a que deux membres du pool et l’observateur par défaut n’est pas un participant, car les serveurs de passerelle ne communiquent pas directement avec la base de données opérationnelle. Trois serveurs de passerelle sont nécessaires pour maintenir le quorum de pool.

Trois serveurs de passerelle

• L’observateur par défaut est activé par défaut.
• Il existe une haute disponibilité pour le pool, car il existe trois membres votants : trois serveurs de passerelle.
• Par défaut, vous ne pouvez avoir qu’un seul serveur de passerelle indisponible pour maintenir le quorum. Si deux serveurs de passerelle sont arrêtés, cela représente moins de 50 % des membres votants et le pool de ressources n’est plus opérationnel pour gérer les charges de travail de surveillance.
• L’observateur par défaut ne doit pas être utilisé ici, car les serveurs de passerelle n’ont pas de service SDK local et ne peuvent donc pas interroger la base de données opérationnelle.

Scénarios d’analyse prenant en charge les pools de ressources

Les flux de travail suivants sont hébergés par des pools de ressources dans Operations Manager :

• Gestion des périphériques réseau
• Gestion des agents UNIX/Linux
• Surveillance des URL d'application web

Notes

Les agents Windows ne rendent pas de comptes aux pools de ressources.

La surveillance du réseau dans Operations Manager nécessite son propre pool de ressources dédié, car les flux de travail de surveillance de réseau sont exécutés sur des serveurs d'administration (sur le module SNMP), et non sur des agents. Cela entraîne une charge importante sur les serveurs d’administration une fois que vous incluez la surveillance des ports réseau, en particulier si vous sélectionnez la plupart des ports actifs disponibles sur l’appareil. Par conséquent, pour de meilleures performances, nous recommandons d'utiliser des serveurs d'administration dédiés dans des pools de ressources dédiés pour la surveillance du réseau. En outre, les serveurs d’administration qui sont membres de ce pool doivent être supprimés des pools Tous les serveurs d'administration, Notifications et Affectation Active Directory.

L’analyse Linux/UNIX dans Operations Manager peut être affectée à un pool de ressources dédié si nécessaire, afin de permettre la surveillance de la haute disponibilité et la gestion des agents. Toutefois, cela n’est pas obligatoire. Operations Manager utilise des certificats pour authentifier l’accès aux ordinateurs qu’il gère. Lorsque l'Assistant Détection déploie un agent, il récupère le certificat auprès de l'agent, signe le certificat, déploie le certificat à l'agent, puis redémarre l'agent. Pour prendre en charge la haute disponibilité, chaque serveur d'administration du pool de ressources doit contenir tous les certificats racine utilisés pour signer les certificats déployés sur les agents se trouvant sur les ordinateurs UNIX et Linux. Sinon, si un serveur d’administration devient indisponible, les autres serveurs d’administration ne peuvent pas approuver les certificats signés par le serveur qui a échoué.

Étapes suivantes

Pour savoir comment créer et gérer des pools de ressources, consultez Gestion des pools de ressources.