Journée communautaire System Center

La communauté System Center se réunit le onze décembre prochain, dans les locaux de Microsoft, au 148 rue de l’Université à Paris 7°.


Au menu :

 

·         Présentation du nouveau site


·         Un petit rappel de la gamme System Center par Microsoft


·         Des démonstrations de déploiement Vista avec SCCM 2007


·         Des démonstrations de supervision des services et des applications avec SCOM 2007


 


Venez discuter des premiers retours d’expérience sur SCCM et SCOM avec nous …


 


pour vous inscrire, un mail à l’adresse systemcenter@hotmail.fr fera l’affaire, en indiquant :


·         Nom


·         Prénom


·         Société et fonction si vous le souhaitez


 

OpsMgr 2007 : Dessinez…. et supervisez

L’éditeur Savision, vient de sortir son produit Live Maps for Operations Manager 2007. Ce produit permet de lier les objets supervisés par Operations Manager à leur représentation dans un diagramme Visio.


Il est possible d’avoir plusieurs niveau de cartes, de la mappemonde à l’emplacement du serveur dans son rack en salle machine. Les tâches, le Health Explorer et le mode maintenance sont disponible depuis les diagrammes qui s’intègrent dans la console.


Voir la démo : http://www.savision.com/demo


 

Le catalogue nouveau est arrivé !

Suite aux remarques faites à Microsoft, les pages du catalogue des packs d’administration pour Operations Manager et System Center Essentials ont été modifiées.


La recherche est améliorée et la visualisation de la version est plus claire.


All Packs for All Products https://www.microsoft.com/technet/prodtechnol/scp/catalog.aspx


Operations Manager 2007 https://www.microsoft.com/technet/prodtechnol/scp/opsmgr07.aspx


Operations Manager 2005 https://www.microsoft.com/technet/prodtechnol/scp/opsmgr05.aspx


Operations Manager 2000 https://www.microsoft.com/technet/prodtechnol/scp/opsmgr00.aspx


Configuration Manager 2007 https://www.microsoft.com/technet/prodtechnol/scp/configmgr07.aspx

OpsMgr 2007 : Le Service Pack 1 arrive

Le service Pack1 de System Center Operations Manager 2007 est disponible sur Connect pour les membres du programme. Il s’agit d’une version RC0 qui est pleinement supportée et pourra âtre mise à jour vers la version RTM. Un déploiement en production est donc tout à fait envisageable (après avoir pris les précautions d’usage).


Parmi les améliorations :


  • La très attendue fonction Recalculate/Reset Health
  • la console est plus performante
  • Beaucoup d’améliorations d’interface dans la recherche, le résumé des overrides, la gestion des alertes.
  • L’export des diagrammes vers Visio
  • Le Copier/Coller dans les alertes
  • La copie de vues entre deux packs d’administration
  • La publication d’un rapport vers Sharepoint
  • Le support SNMP v1 etv2

Pour l’avoir mis en test depuis une semaine, je peux dire que les premiers résultats sont très concluants.

OpsMgr 2007 : ‘Best practices’ et quelques réflexions.

Microsoft a récemment publié un article : Best practices to use when you configure overrides in System Center Operations Manager 2007 qui donne des indications quant à la façon de gérer les overrides.


Comme d’habitude, ces ‘best practices’ doivent faire l’objet d’une évaluation et être adaptées aux besoins.


Dans le cas de cet article, c’est surtout le premier point concernant le stockage des overrides qui prête à discussion.


Mais regardons de plus près de quoi il s’agit :

Packs d’administration scellés et non scellés :

Avec la version Operations Manager 2007, les packs d’administration venant des éditeurs sont généralement scellés. C’est-à-dire qu’ils sont signés numériquement, afin de garantir leur intégrité, et qu’ils ne peuvent être modifiés.


Il n’est plus possible, comme c’était le cas avec MOM 2005, de modifier directement le pack d’administration d’un éditeur.


C’est plutôt un point positif car cela facilite la gestion des changements ainsi que support.


Les modifications de comportement des packs d’administration se font au travers d’objets appelés ‘Overrides’.


Les packs d’administration non scellés, sont comme ceux de MOM 2005 et peuvent être modifiés directement.


Deux points importants à noter concernant les packs d’administration :


-          Les packs d’administration sont des containers qui permettent de stocker à peu près tous les objets créés dans Operations Manager.


-          Lors de l’installation, un pack d’administration non scellés par défaut est crée : Default management Pack. L’interface d’Operations Manager dirige automatiquement vers ce pack. Attention donc aux mauvaises manipulations, d’autant que l’interface d’Operations Manager ne permet pas de déplacer un objet d’un pack d’administration vers un autre.

Les overrides :

Les overrides sont des objets permettant de modifier le comportement de la supervision. Ils permettent de modifier les objets discoveries, rules, monitors.


Le mécanisme de modification par override est très souple. En effet, on peut modifier plusieurs paramètres d’un objet et spécifier la portée de cette modification : Un groupe, une instance particulière, une classe, …


Par exemple, il est possible de créer un override pour désactiver une règle concernant les sites web IIS (ne pas utiliser l’option disable de l’interface comme il est précisé dans l’article de Microsoft) ou de créer un groupe contenant certains sites web afin de désactiver la règle uniquement pour les membres de ce groupe.


C’est l’auteur du pack d’administration qui détermine quels sont les paramètres qui peuvent être modifiés par un override.


Un override étant un objet de supervision, il sera lui aussi stocké dans un pack d’administration.


L’article de Microsoft conseille de créer un pack d’administration non scellé pour stoker les overrides d’un pack d’administration scellé. Par exemple, je peux créer un pack d’administration ‘SQL Server MP Overrides’ pour stocker tous les overrides du pack d’administration SQL Server de Microsoft.


Au premier abord, cela semble être plutôt un bon conseil. Cela évite d’avoir un pack d’administration ‘fourre tout’ et permet facilement d’exporter les overrides depuis un environnement de pré-production vers un environnement de production.


Nous allons voir que cela n’est pas aussi simple que cela.

Un exemple d’implémentation Operations Manager 2007 :

Afin de comprendre les problèmes posés par la gestion des packs d’administration, je vous propose de travailler à partir d’un exemple :


Il s’agit d’une entreprise internationale qui décide de profiter des possibilités de délégation offertes par Operations Manager pour centraliser sa supervision dans l’objectif de réduire les coûts d’exploitation.


Tout le système d’information sera supervisé par Operations Manager dans un seul groupe d’administration.


La gestion des opérations est répartie sur plusieurs équipes :


INFRA : équipe en charge de l’exploitation Active Directory + services associés au niveau mondial


EMEA : équipe en charge des serveurs applicatifs pour la région EMEA


ASIE : équipe en charge des serveurs applicatifs pour la région Asie/Pacifique


Chaque équipe aura la possibilité, via les rôles et étendues, d’agir sur la supervision des serveurs de son périmètre.


Cela signifie par exemple, que l’équipe EMEA pourra créer un override pour modifier le comportement d’une règle pour les serveurs IIS de Paris.


C’est à ce point que l’on commence à entrevoir les limites du premier conseil de l’article de Microsoft :


Supposons la création d’un pack d’administration pour stocker les modifications du pack d’administration IIS : IIS MP Overrides


Les équipes INFRA, EMEA et ASIE peuvent utiliser le pack IIS MP Overrides pour y stocker les overrides du pack d’administration IIS pour les serveurs de leur périmètre.


Cela pose à l’évidence des problèmes de gestion du changement. Qui est le propriétaire du pack IIS MP Overrides ? Et comment gérer le passage de la pré-production à la production alors que plusieurs équipes font chacune de leur coté des modifications stockées dans un seul et même container ?


Il va donc falloir aménager les ‘best practices’ et multiplier les packs d’administration.


Deux possibilités :


-          Créer un pack d’administration par équipe pour que celle-ci y stocke ses overrides tous packs d’administration confondus


-          Créer pour chaque pack d’administration scellé autant de packs d’administration d’override qu’il y a d’équipes concernés : EMEA_IIS MP Overrides et ASIE_IIS MP Overrides.


Je préfère de loin la seconde solution sachant que, comme nous le verrons après, nous aurons de toute façon besoin d’un pack d’administration non scellé par équipe.


Cette organisation montre aussi une limite d’Operations Manager. La gestion de la sécurité par rôle porte sur des groupes, des classes, des vues, … mais pas sur des packs d’administration.


Ce qui signifie que l’équipe ASIE ne pourra pas créer d’override portant sur les serveurs de la zone EMEA mais en revanche, rien n’empêche l’équipe ASIE de stoker l’un de ses overrides dans le pack d’administration EMEA_IIS MP Overrides.


Trois conseils donc :


-          Mettre en œuvre un bon processus de gestion du changement


-          Imposer une convention de dénomination pour tous les objets (j’y reviendrai dans un prochain billet)


-          Utiliser un outil comme MP Studio de Silect Software pour faciliter la gestion du changement et auditer les modifications faites sur les packs d’administration.

Faut-il ou non sceller un pack d’administration ?

Un pack d’administration peut être scellé au moyen de l’outil MPSEAL. Il faut préalablement générer une clé avec SN.EXE du SDK de Windows. À chaque modification, il faut repartir de la version non scellée.


Ce processus est un peu compliqué et ne doit être utilisé que si nécessaire.


D’un point de vue technique, un pack d’administration est simplement un container permettant de regrouper et de stocker plusieurs objets.


D’un point de vue fonctionnel, il est possible de distinguer plusieurs types de packs d’administration :


-          Pack d’administration de supervision : Ce type de pack d’administration regroupe des objets (règles, moniteurs, vues, …) nécessaires à la supervision d’un service ou d’une application.


-          Packs d’administration d’overrides : Ce type de pack d’administration contient des overrides et souvent des groupes utilisés pour modifier le comportement d’un pack d’administration de supervision.


-          Packs d’administration organisationnels : J’appelle ainsi les packs d’administration qui contiennent des objets (vues et groupes) utilisés pour structurer les informations dans la console.


Les packs d’administration de supervision doivent, à mon sens, être scellés (ceux des éditeurs le sont déjà). Lorsqu’ils sont mis en production, au terme des phases de développement et de test, ils ne sont pas modifiés souvent et doivent être protégés des modifications par les opérateurs qui peuvent utiliser des overrides pour en changer le comportement.


En revanche, sceller un pack d’administration destiné à stocker des overrides ne me paraît pas pertinent. Les exploitants vont souvent créer ou modifier des overrides pour ajuster la supervision et diminuer la pollution.


De même, les packs d’administration organisationnels sont souvent modifiés. Les exploitants vont créer de nouvelles vues pour faciliter leur travail ou l’analyse d’un problème. Il n’est pas rare de créer des vues temporaires.

Problème liés à l’utilisation de packs d’administration non scellés

Il existe une règle simple : Un pack d’administration ne peut pas référencer un objet stocké dans un autre pack d’administration si ce dernier n’est pas scellé. La raison est que cette référence ne serait pas fiable puisqu’il est possible de modifier un pack d’administration non scellé.


Reprenons l’exemple de notre entreprise internationale.


Chaque équipe souhaite créer ses propres vues dans la console afin de filtrer et organiser les informations. Ces vues, seront stockées dans un pack d’administration.


Il est souhaitable de créer un pack d’administration ‘Organisationnel’ pour chaque équipe. Le fait de créer un pack d’administration crée automatiquement un dossier dans la partie ‘monitoring’ de la console (il est possible de masquer ou de supprimer ce dossier).


Nous pouvons créer un pack d’administration SPEC_EMEA avec son dossier associé.



 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


 


Toutes les vues créées dans ce dossier seront automatiquement stockées dans le pack d’administration SPEC_EMEA.


Supposons que l’équipe EMEA veuille créer une vue permettant d’afficher l’état des serveurs SQL du site de Paris.

Il faut tout d’abord créer un groupe contenant les serveurs SQL de Paris (SPEC_EMEA_OG_Paris SQL Servers), puis créer une vue ciblée sur la classe ‘Windows Computer’ filtrée sur le groupe SPEC_EMEA_OG_Paris SQL Servers.

Comme le groupe est référencé dans la définition de la vue, il doit être stocké dans le même pack d’administration. La vue et le groupe seront donc stockés dans le pack d’administration SPEC_EMEA.

C’est à ce stade que les choses se compliquent.

Par exemple, il existe un monitor qui vérifie la conformité des serveurs SQL avec un niveau minimum de service Pack. Ce monitor est réglé par défaut sur la version RTM.

L’équipe EMEA souhaite vérifier que tous les serveurs SQL 2005 du site de Paris sont au minimum en SP1. Il va donc falloir créer un override pour modifier le comportement du monitor.

Pour respecter les ‘best practices’, cet override sera stocké dans le pack d’administration EMEA_SQL MP Overrides qui est dédié aux overrides du pack d’administration SQL pour l’équipe EMEA.

Cet override va devoir être ciblé sur un groupe contenant tous les serveurs SQL du site de Paris. Comme l’équipe EMEA a déjà créé ce groupe lors de la création de la vue d’état des serveurs SQL de Paris, elle souhaitera naturellement réutiliser ce groupe.

Comme le groupe trouve dans le pack d’administration non scellé SPEC_EMEA, il ne peut être utilisé comme cible par un override stocké dans le pack d’administration EMEA_SQL MP Overrides

Cette limite nous conduit à 2 possibilités :

-          Stocker tous les objets (vues, groupes, overrides, …) d’une équipe dans sont pack d’administration

-          Continuer à utiliser pour chaque équipe un pack d’administration ‘organisationnel’ et autant de packs d’administration d’overrides que nécessaire. Ce choix suppose de souvent dupliquer des groupes car il y aura souvent les mêmes regroupements dans les vues et dans les overrides.

Personnellement, je préfère de loin la seconde solution. La première conduit encore à un pack d’administration fourre tout.

Bien sur, créer 2 fois un groupe avec la même définition est une contrainte supplémentaire mais je préfère séparer dans 2 packs d’administrations distincts la partie organisationnelle liée à la gestion des vues (ou au filtrage de la console avec la sécurité basée sur les rôles) et la partie technique liée aux overrides.

En effet, la création d’une vue et d’un groupe associé n’a pas d’impact en dehors de la console Operations Manager alors que la création d’override impacte le trafic réseau (augmentation ou diminution du nombre d’évènements, d’alertes ou de mesures de performance) et peut aussi impacter la charge CPU des agents (augmentation du timeout ou de la fréquence d’exécution d’un script).

Il est donc raisonnable de penser que la modification des vues sera généralement faite directement dans l’environnement de production alors que la création d’overrides passera souvent par une étape de validation dans un environnement de pré-production.

Pour appliquer ces 2 processus de gestion du changement, il est préférable de spécialiser les packs d’administration afin de permettre les opérations d’import/export entre la pré-production et la production.

Comme on le voit, le premier conseil de l’article de Microsoft, anodin en apparence, nécessite d’être approfondi avant d’être mis directement en application.

Heureusement, les autres conseils de cet article ne prêtent pas à discussion et peuvent être appliqués à la lettre J

Mais au fait, à quoi sert donc le pack d’administration par défaut ?

Une des premières fonctions du pack d’administration par défaut semble être de capter les étourderies des utilisateurs d’Operations Manager qui oublient de spécifier le pack d’administration qu’ils souhaitent utiliser lors de la création d’un objet J.

À part cela, le pack d’administration par défaut contient les vues crées au premier niveau  dans la console.