Considérations relatives à la conception de la liste de ressources partagées

Un pool de ressources est un regroupement logique de serveurs d’administration et/ou de serveurs de passerelle utilisés pour distribuer le travail entre eux et reprendre le travail d’un membre ayant échoué. En d’autres termes, elles fournissent une haute disponibilité et une scalabilité pour les flux de travail. Lors de la conception d’un groupe d’administration, certaines considérations doivent être prises en compte pour la surveillance des appareils réseau, des systèmes Linux/UNIX et d’autres charges de travail conçues pour tirer parti d’une liste de ressources partagées.

Vue d’ensemble

Les pools de ressources garantissent la continuité de la surveillance en fournissant plusieurs membres, qui sont des serveurs d’administration et/ou des serveurs de passerelle qui peuvent prendre en charge les flux de travail de surveillance si l’un des membres du pool devient indisponible. 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 seul n’est pas disponible, vous avez perdu le quorum.

Pour chaque pool de ressources créé dans la console Opérateur, 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 l’accès au quorum. Cela s’applique également aux trois pools de ressources créés par défaut lorsque vous créez d’abord le groupe d’administration, qui est abordé plus loin dans cet article. Pour tous les pools de ressources créés à l’aide de l’applet de commande PowerShell NewSCOM-ResourcePool, il est défini sur désactivé par défaut. L’inclusion de la base de données Operations Manager en tant qu’observateur par défaut réduit la complexité de votre groupe d’administration en vous demandant uniquement de déployer deux serveurs d’administration au minimum pour maintenir la haute disponibilité de vos pools de ressources.

Un autre rôle prenant en charge un pool de ressources est Observateurs. Il s’agit d’un serveur d’administration ou d’un serveur de passerelle qui ne participe pas au chargement de flux de travail pour le pool ; toutefois, ils participent aux décisions de quorum. Cela 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 sur manuelle et ne peut pas être reconfigurée en automatique. Lorsqu’un groupe d’administration System Center – Operations Manager est créé, trois pools de ressources sont créés par défaut avec l’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	Effectue des flux de travail pour le calcul de groupe, la disponibilité, le cumul d’intégrité du moniteur distribué et le nettoyage des bases de données.
Pool de ressources de notifications	Les flux de travail du service d’abonnement aux alertes sont ciblés vers ce pool de ressources pour prendre en charge les notifications d’alerte.
Pool de ressources d’affectation AD	Les flux de travail d’intégration AD sont destinés à 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, tout serveur d’administration commandé est automatiquement fait membre de ce pool de ressources. Dans certaines architectures et considérations de conception, telles que celles qui incorporent des opérations d’urgence dispersées géographiquement, l’affectation automatique au pool de ressources Tous les serveurs d’administration peut ne pas être souhaitée. Dans ces situations, il est possible de changer l’attribution d’appartenance de automatique à manuelle. Par conséquent, les serveurs d’administration doivent être ajoutés au pool de ressources Tous les serveurs d’administration par le biais d’une affectation manuelle.

Remarque

L'appartenance du pool de ressources de tous les serveurs d'administration est en lecture seule. Pour passer de l’appartenance automatique à manuelle, consultez Modification de l’appartenance au pool.

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 en fonction des 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 n’y a que deux membres et le quorum n’est pas atteint.
• Il n’existe aucune 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 de vote : deux serveurs d’administration et l’observateur par défaut.
• Si vous désactivez l’observateur par défaut, vous perdrez 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 de vote : trois serveurs d’administration et l’observateur par défaut.
• Par défaut, vous ne pouvez avoir qu’un seul serveur d’administration indisponible pour maintenir le quorum. Si deux serveurs d’administration ne sont pas disponibles, vous avez exactement 50 % des membres de vote et le pool de ressources ne fonctionne plus pour gérer les charges de travail de surveillance.
• L’observateur par défaut n’augmente pas le nombre de serveurs d’administration qui peuvent être arrêtés. Par conséquent, 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 existe cinq membres de vote : 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 % des membres de vote et le pool de ressources ne fonctionne plus pour gérer les charges de travail de surveillance.
• L’observateur par défaut dans ce scénario fournit une valeur significative, car il augmente le nombre de serveurs d’administration pouvant être arrêtés. Sans l’observateur par défaut, vous n’auriez que quatre membres de quorum, ce qui permet uniquement à un membre d’être indisponible.

Cinq serveurs d’administration

• L’observateur par défaut est activé par défaut.
• Il existe une haute disponibilité pour le pool, car il existe six membres de vote : cinq serveurs d’administration et l’observateur par défaut.
• Par défaut, vous ne pouvez avoir que deux serveurs d’administration indisponibles pour maintenir le quorum. Si trois serveurs d’administration ne sont pas disponibles, il s’agit exactement de 50 % des membres de vote, et le pool de ressources ne fonctionne plus pour gérer les charges de travail de surveillance.
• L’observateur par défaut n’augmente pas le nombre de serveurs d’administration qui peuvent être arrêtés. Par conséquent, 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 atteignez trois serveurs d’administration ou plus 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, il est possible que la base de données opérationnelle rencontre une charge significative, ce qui peut générer suffisamment de latence pour affecter les calculs du pool de ressources.

Avec la façon dont l’observateur par défaut joue un rôle, chaque serveur d’administration du pool interroge son propre service SDK local, ce qui lui permet d’interroger une table dans la base de données opérationnelle pour l’observateur par défaut. 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’existe aucune 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 que 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 du 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 de vote : 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 en panne, il s’agit de moins de 50 % des membres de vote et le pool de ressources ne fonctionne plus 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 de supervision 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 appareils réseau
• Gestion des agents UNIX/Linux
• Surveillance des URL d’application web

Remarque

Les agents Windows ne rapportent pas aux pools de ressources.

La surveillance réseau dans Operations Manager nécessite son propre pool de ressources dédié distinct. Cela est dû au fait que les flux de travail de supervision réseau s’exécutent sur des serveurs d’administration (sur le module SNMP) et non sur des agents. Cela place 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 vous 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 de tous les pools d’affectations, notifications et serveurs d’administration.

La supervision Linux/UNIX dans Operations Manager peut être affectée à un pool de ressources dédié si nécessaire pour activer la supervision de la haute disponibilité et la gestion des agents, mais n’est pas nécessaire. 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 avoir tous les certificats racines utilisés pour signer les certificats déployés sur les agents 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 ayant échoué.

Étapes suivantes

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