Gestion des configurations

Dans un article sur la qualité de service TI, j’abordais rapidement la gestion de la configuration dans les processus ITIL.

Le sujet de la normalisation de parc et de l’industrialisation informatique étant vaste, voici un article spécialement consacré à la gestion des configurations informatiques !

Celui-ci abordera le sujet d’un point de vue théorique et pratique, avec quelques exemples concrets.

 

I. Introduction

La mise en place de configurations normalisées répond à un besoin de simplification du parc, et d’industrialisation des déploiements et des configurations. L’uniformisation des configurations des postes de travail et des serveurs permet une meilleure gestion quotidienne et simplifie grandement l’administration du parc. Cela peut être utile pour valider facilement les prérequis d’une application ou encore faciliter le remplacement du matériel. Une industrialisation devient également plus abordable, en automatisant la mise en place des configurations.

 

II. Configurations modèles

L’uniformisation des systèmes peut être réalisée et contrôlée en utilisation une notion de modèles.  Une configuration modèle est un ensemble de normes qui peut concerner des serveurs, des postes de travail, ou encore des systèmes d’exploitation. Une configuration définit des contraintes qui doivent être respectés pour que le composant soit considéré comme correspondant au modèle.

Un modèle définit des contraintes techniques (version des composants, configuration…) ou organisationnelles (type de sauvegarde ou de support, supervision…). Il est préférable que les processus permettant la mise en place de ces contraintes soient automatisés. De cette manière, il est possible de minimiser le risque de déviation d’un composant par rapport à son modèle d’origine.
Concrètement, cela peut passer par la mise en place de GPOs, réalisant la configuration de base des systèmes. Par exemple, un modèle « Serveur Windows » définit un ensemble d’optimisations à réaliser, dont la désactivation d’IPv6.

  • Si la désactivation d’IPv6 est réalisée « à la main », il est difficile de connaitre les serveurs sur lesquels la configuration a été effectuée, et donc de savoir si un serveur respecte la norme.
  • Si la désactivation d’IPv6 est réalisée par une GPO, mappée sur un groupe correspondant au modèle, il devient possible de garantir que l’ensemble des serveurs de ce groupe possède cette configuration.

 

II. Sous modèles

Selon les besoins, il peut être nécessaire de mettre en place des sous-modèles, afin d’adresser des besoins spécifiques à une configuration. Par exemple, une configuration « poste de travail » peut contenir les sous modèles « portable » ou « poste fixe ».

Un modèle peut également gérer des configurations d’utilisateurs (environnement, logiciels installés…). Cependant, il est préférable de gérer la configuration d’un utilisateur au travers de son poste de travail.

La gestion de la configuration des utilisateurs dans leur globalité impose que ces utilisateurs ouvrent leur session sur un parc de postes de travail entièrement gérés. Ainsi, un utilisateur ouvrant une session sur un poste géré disposera forcément d’un environnement configuré.

 

III. Mise en place

La mise en place de modèles de configuration est une opération relativement simple sur des parcs modestes, si elle est effectuée d’une manière progressive, et que les différentes étapes sont bien respectées :

  1. Définition d’une liste de modèles :
    Cette première étape consiste à choisir la liste des composants sur lesquelles la gestion des configurations va s’appliquer. Dans un premier temps, il est possible de raisonner sur l’ensemble du parc Windows, sans inclure les autres composants d’infrastructure, tels que le stockage, ou le réseau (qui ne tireraient qu’un bénéfice faible d’une industrialisation).
  2. Définition des contraintes pour chaque modèle :
    Il faut ensuite mettre en place, pour les modèles choisis, un référentiel des configurations qui vont être appliquées. Ce référentiel doit contenir l’ensemble des choix techniques, ainsi que leur méthode de configuration.
  3. Création de systèmes de référence :
    Un système de référence est un composant modèle, qui permettra de tester la mise en place des configurations, et servir de base pour les futures versions.
    La configuration de ces postes pour qu’ils respectent le modèle doit entièrement être automatisée, et traitée grâce à des groupes d’entités (ordinateurs ou utilisateurs).
  4. Migration des systèmes existants :
    Une fois le modèle défini, et les mécanismes de configuration en place, il faut inclure les postes et serveurs existants dans les modèles disponibles. Pour cela, il faudra inclure un ensemble d’ordinateurs de manière régulière dans les groupes de gestion, et de vérifier qu’aucun effet de bord n’apparait.
    L’assignation des systèmes à un modèle peut être réalisée par un groupe AD, ou selon l’OU du compte ordinateur.

 

IV. Évolution des modèles

Afin de prendre en compte des modifications de la société, ou une nouvelle version de composant, un modèle peut être mis à jour. On peut alors utiliser un système de versions pour gérer les différentes modifications.

Pour cela, il faut mettre en place un référentiel contenant l’ensemble des configurations effectuées par les différentes versions. Des groupes Active Directory peuvent alors gérer l’inclusion dans une version ou une autre.

 

V. Exemple

L’exemple ci-dessous est tiré d’un projet de normalisation de parc effectué chez un client. Celui-ci souhaiter uniformiser son parc de serveurs et de postes de travail, afin de simplifier sa gestion et de stabiliser l’existant.

 

La gestion des configuration a été découpée en 4 modèles. Un modèle basé sur « Serveurs / Postes de travail » a été choisi, plutôt qu’un modèle « Windows », englobant les deux systèmes. Cela offrait plus flexibilité, et permet une gestion plus souple (au niveau des politiques de mise à jour notamment).

 

Pour chaque entité, deux types de postes ont été définis : Prod et Préprod avec des groupes AD régissant les affectations aux modèles. Les postes de Préprod doivent contenir un ensemble varié d’utilisateurs, et permettent de tester les nouvelles versions de configurations (exemple : déploiement d’un nouveau logiciel).

 

L’ensemble des serveurs sont donc séparés en classe (Prod / Préprod). Une classe indique la qualité de l’hébergement fourni, selon :

  • La priorité des ressources d’hébergement (CPU, mémoire, stockage…),
  • La fréquence de sauvegarde (journalière, hebdo…) et le délai de rétention,
  • La qualité de la supervision (priorité de traitement des alertes, possibilité de gestion par l’astreinte…)
  • La fréquence de gestion (maintenance, mises à jour…).

Chaque serveur est clairement associé à une classe, notamment par son nom.

Cette notion de classe peut être retrouvée dans l’ensemble des systèmes de gestion (Active Directory, monitoring, sauvegarde, WSUS, vCenter…), où une division Prod / Préprod est présente (exemple : Des jobs de sauvegarde Prod, et des jobs Préprods, avec des configurations et des priorités différentes).

 

Une fois les serveurs classés, nous avons défini un référentiel contenant toute les configurations actuellement effectuées sur un système. Nous avons pu nous baser sur les procédures de déploiement et d’installation pour établir la liste des opérations à effectuer.

 

Ce référentiel était divisé en deux parties :

  • La configuration de l’infrastructure, qui comprenait les vérifications de base : Le serveur est bien sauvegardé (disaster recovery et granulaire), le serveur est bien supervisé (disponibilité, performance…)…
  • La configuration Windows, qui vérifiait que l’ensemble des configurations était effectuées : Les prérequis de base sont installés (agents, outils…), les bonnes pratiques de la société et des éditeurs sont respectées, le serveur est à jour (configuration Windows Update, dernier service pack présent…).

 

Voici un extrait de ce référentiel :

 

Au total, une 50aines de spécifications composaient ce référentiel.

Couplé avec une politique d’industrialisation (ou des procédures), cette politique de gestion des configurations à permis d’uniformiser les nouveaux serveurs, et de construire une plateforme stable et flexible.

 

VI. Conclusion

La gestion des configurations est un processus ITIL particulièrement intéressant lorsque l’on souhaite améliorer la gestion de son parc.  Sa mise en place est moins complexe qu’il n’y parait, et ne nécessite pas forcement d’outil tiers  (type SCCM). Cependant, une grande rigueur est nécessaire !

J’espère que cet article vous aura donné quelques idées pour mieux gérer vos systèmes.
Un article sur le même sujet : La qualité de service TI.

par .

Laisser un commentaire

*