SCOM 2012 : Les changements d’architecture

Le RMS est mort, vive le RMS emulator !

Dans la version 2007 R2, le RMS (Root Management Server) était l’unique responsable de certaines fonctions vitales (workflow) à votre groupe d’administration :

•    Le point accès des interfaces d’administration (Console et PowerShell).
•    Le calcul de la configuration de supervision du groupe d’administration.
•    Gestionnaire des notifications et connecteurs.
•    L’agréation de l’état de santé de vos objets de supervision. (Moniteurs d’agrégation)
•    Le calcul des membres des groupes.

Techniquement, cela se traduisait par le démarrage automatique des services System Center Data Access et System Center Configuration sur le RMS alors que ces mêmes services étaient désactivés sur les autres Management Servers (MS).

SCOM 2012 : Les changements d’architecture

Vous l’aurez compris, c’est le cœur de toute infrastructure SCOM 2007. Deux solutions existaient pour traiter de la bonne disponibilité de ce rôle : l’installation en cluster ou la procédure de promotion d’un MS en RMS.

Première solution : Installation du RMS en cluster. Cette solution semble séduisante, mais, au cours de nos différents projets, nous avons constaté un rapport-bénéfices/coût défavorable. Cela est principalement dû à la difficulté de maintenir l’environnement à jour en installant les Cumulative Updates et à la gestion des connecteurs avec des produits tiers.

Seconde solution : Prévoir une procédure de promotion d’un MS en RMS. C’est simple et cela peut se jouer en 30 minutes dans la plupart des cas, mais elle introduit une action manuelle pour assurer la disponibilité du RMS.  Il faut également que le MS Cible possède les mêmes capacités de traitement que le RMS originel. La mise en œuvre de cette procédure est de toute façon obligatoire même avec un RMS en cluster afin de prévoir un scénario de reprise dans le cas de la perte d’un site où l’ensemble des nœuds du cluster disparaît en même temps.

Désormais, Microsoft propose avec Operations Manager 2012 une solution plus simple pour assurer une haute disponibilité : la suppression du rôle RMS !

Les Management Servers sont maintenant égaux. C’est-à-dire qu’ils exécutent les mêmes services et se répartissent automatiquement les différentes charges de travail d’infrastructure (workflows) !

À l’image du passage des domaines NT4 à Active Directory, le rôle RMS Emulator assure une rétrocompatibilité des packs d’administration utilisant le RMS (C’est le cas du moteur de corrélation du pack d’administration Exchange 2010). Ce rôle unique est hébergé par défaut sur le premier Management Server de votre groupe d’administration.

Vous pouvez visualiser le détenteur de ce rôle à l’aide de la vue Management Servers de l’espace Administration.

La clé de cette simplification d’architecture

Techniquement, la clé de cette simplification d’architecture est l’exécution des services SCOM (System Center Configuration, System Center Data Access et System Center Health Service) sur l’ensemble des Management Servers.

Le service System Center Configuration

Petit rappel, le rôle RMS était extrêmement gourmand en mémoire vive puisque lors du démarrage de ce service, la configuration était copiée en mémoire (fichier XML pouvant atteindre quelque Go) depuis de la base de données afin d’identifier tout changement.

Le service System Center Configuration a été totalement réécrit afin de fédérer la configuration de supervision de votre groupe d’administration dans la base de données OperationsManagerDB.  Ainsi, cette configuration est directement accessible et modifiable à partir de tout Management Server.

Ce service gagne donc en rapidité d’exécution quel que soit le nombre d’agents déployés, et la configuration matérielle de vos Management Servers est réduite.

Le service System Center Health Service

Ce service gère les workflows d’infrastructure de votre groupe d’administration (Calcul d’appartenance aux groupes, nettoyage de la base de données, notification, etc..).
Afin de répartir ces charges de travail sur l’ensemble des Management Servers, un nouveau concept baptisé pool de ressources a été introduit avec Operations Manager 2012.
Les pools de ressources permettent de regrouper logiquement plusieurs Management Servers ou Gateway Servers dans deux buts :

•    Distribuer  l’exécution des workflows de façon à répartir la charge. Si un membre est indisponible, les membres restants se répartissent les ressources du pool. De même lorsqu’un nouveau membre est ajouté au pool.
•    Assure une haute disponibilité de la supervision des ressources de type Unix/Linux et périphérique réseau SNMP.

Note : Le mécanisme de failover d’un MS à un autre pour les agents Operations Manager sous Windows ne change pas. Le pool de ressources concerne plutôt les fonctions assurées par le service de configuration du RMS.

La création d’un pool de ressource est possible à partir du nœud  Ressource Pool de l’espace Administration. Par défaut, trois pools sont créés afin d’assurer la disponibilité des composants d’infrastructure.

Le service System Center Data Access

Le service System Center Data Access en charge du contrôle d’accès n’est pas inclus dans le pool de ressources. Il démarre maintenant sur chaque Management Server afin de leur permettre à tous d’accepter les connexions effectuées par PowerShell ou par des consoles. En revanche, une connexion établie sur un Management Server n’est pas automatiquement réaffectée en cas de défaillance. Il faut pour cela configurer le service Network Load Balancing.

Quelques conseils d’architecture…

Sans aucun doute, l’introduction de pool de ressources sera l’élément clé de la haute disponibilité de votre future infrastructure.

Cependant l’utilisation de cette fonctionnalité requiert une faible latence des temps de réponse entre les Management Servers (<5ms), ainsi il est fortement recommandé de les positionner à un emplacement unique et de déployer des Gateway Servers sur vos sites distants.

Nous vous recommandation de déployer systématiquement un minimum de deux Managements Servers afin d’assurer une haute disponibilité et une récupération aisée de votre infrastructure en cas d’incident.