System Center

Migration de MOM vers Operations Manager 2007

Andy Dominey

Vue d'ensemble:

• Planification d'un déploiement d'Operations Manager
• Évaluation des besoins matériels
• Conservation des données historiques
• Planification des tests

La surveillance et l'administration des serveurs représentent un aspect crucial de toute infrastructure informatique moderne. Il est essentiel que vous vous assuriez que votre infrastructure informatique fonctionne non seulement correctement mais qu'elle est suffisante pour supporter la charge exercée par les utilisateurs. Toutefois, la collecte de ces informations n'est pas

une sinécure. Quant à savoir ce que vous devez faire de ces informations après les avoir collectées, c'est encore une autre histoire. Heureusement, l'aide n'est pas loin. Microsoft® Operations Manager (MOM) permet la collecte de ces informations depuis sept ans. Et sa dernière incarnation, System Center Operations Manager 2007, développe ce principe.

Pourquoi migrer ?

System Center Operations Manager 2007 offre de multiples améliorations significatives depuis sa dernière version, MOM 2005. L'architecture de base a été remaniée et considérablement améliorée pour permettre au produit d'être informé au mieux des applications réparties sur plusieurs périphériques et d'être également informé non seulement des serveurs mais également de tous les composants qui constituent un serveur.

De plus, Operations Manager contient un moteur de classement puissant capable d'agréger les données d'alertes, tout en réduisant considérablement le nombre de fausses alertes, ainsi qu'un explorateur d'intégrité qui permet de rationaliser le processus de localisation et de résolution des problèmes.

Il contient également des seuils à réglage automatique et un moteur de configuration de base qui vous permettent de suivre facilement l'utilisation des ressources sur l'ensemble de votre environnement. Le moteur de rapports, quant à lui, a été considérablement amélioré, offrant de superbes graphiques et des rapports permettant de plonger dans la hiérarchie. Examinez la Figure 1 pour un aperçu de la présentation visuelle des données de rapport.

Figure 1** Rapport de disponibilité dans Operations Manager 2007 **(Cliquer sur l'image pour l'agrandir)

Operations Manager peut même être utilisé pour contrôler les ordinateurs de bureau, ainsi que les serveurs. Voici quelques fonctionnalités supplémentaires offertes par Operations Manager 2007 :

• Excellente surveillance de la plate-forme Windows Server System™
• Fonctionnalités de surveillance des applications puissantes
• Automatisation des tâches courantes
• Le moteur de base de données nouvelle génération facilite l'évolutivité et le contrôle à l'échelle de l'entreprise
• Améliorations de sécurité et intégration avec Active Directory®

Pour encore plus d'informations sur les nouvelles fonctionnalités disponibles dans System Center Operations Manager 2007, consultez l'article « Surveillez vos serveurs grâce à Operations Manager 2007 » de Pete Zerger dans ce numéro de TechNet Magazine.

Migration vers Operations Manager

Avant de planifier votre migration vers Operations Manager 2007, vous devez savoir qu'il n'existe pas de chemin de mise à niveau direct pour le produit. Avec des modifications architecturales aussi importantes que celles apportées à Operations Manager, le produit ne pourrait pas rester suffisamment compatible avec les versions précédentes pour permettre une mise à niveau directe. Par conséquent, si vous exécutez actuellement MOM 2000 ou MOM 2005, vous devrez envisager l'une des stratégies de migration décrites ultérieurement dans cet article.

Si vous n'exécutez pas de version précédente de MOM, il vous suffit d'installer la nouvelle version du produit. Gardez à l'esprit que vous devrez décider très tôt dans le projet si vous disposez de compétences internes suffisantes pour exécuter l'installation ou la migration, ou si vous devez obtenir l'assistance d'un tiers. Ceci aura évidemment un impact sur le coût général du projet. Vous devez donc examiner la question au début de ce processus.

Scénarios de migration

Pour ceux qui n'exécutent pas actuellement MOM, le déploiement est simple : planifiez et concevez l'architecture puis déployez le logiciel. En revanche, si vous utilisez MOM, Microsoft prend en charge deux scénarios de migration : côte à côte sur un même matériel et côte à côte sur un matériel différent. Explorons les deux scénarios.

Côte à côte sur un même matériel Dans ce scénario, vous installez Operations Manager sur le même matériel physique que votre architecture MOM 2000 ou MOM 2005 existante. Cette approche est utile pour les sites où l'infrastructure MOM est peu utilisée et où le matériel serveur est suffisamment puissant pour héberger côte à côte l'ancienne et la nouvelle version. N'envisagez cette option que si l'installation d'Operations Manager ne risque pas d'avoir un impact sérieux sur les performances des serveurs MOM actuels.

Côte à côte sur un matériel différent Dans ce cas-ci, la nouvelle installation est exécutée sur le nouveau matériel ou un matériel différent. Il s'agit de l'approche préférée étant donné qu'elle garantit un impact minimum sur l'infrastructure d'administration actuelle pendant la migration. Notez qu'un matériel supplémentaire n'est pas requis. Les nouveaux serveurs Operations Manager 2007 peuvent être montés sur des ordinateurs virtuels jusqu'à ce que l'ancien matériel serveur puisse être réattribué.

Considérations

Avant de choisir une stratégie de migration particulière, quelques points importants sont à prendre en considération.

Vous devez d'abord penser aux exigences matérielles et logicielles et aux coûts associés. Même si vous décidez d'installer ou de configurer une partie ou la totalité de l'infrastructure Operations Manager sur les ordinateurs virtuels, vous devrez malgré tout autoriser le système d'exploitation et les licences d'application, ainsi que les OML (Operations Management License) pour chaque agent à être contrôlés par Operations Manager.

Ensuite, vous devez planifier les ressources qui exécuteront le travail. Dans une petite entreprise, ceci peut ne pas se révéler très complexe ou difficile, mais dans les entreprises plus importantes, cela peut s'avérer un élément clé de la stratégie de migration générale.

Vous devez également considérer l'impact potentiel que cette migration pourrait avoir sur l'infrastructure de surveillance actuelle ou sur l'ensemble des serveurs. Vous devez planifier toute éventualité, y compris la possibilité de redémarrage des serveurs, voire de défaillances de serveurs de production critiques.

Notez que si vous utilisez la base de données Microsoft Access™ dans MOM 2000 ou le magasin de données SQL Server™ dans MOM 2005 pour le stockage et les rapports de données d'archive, la migration de ces données vers Operations Manager 2007 n'est actuellement pas prise en charge.

Planification pour une migration réussie

En tant que consultant, l'un des plus gros problèmes que je rencontre est la planification inadéquate des déploiements. Après avoir décidé d'effectuer l'installation sur un nouveau matériel ou un matériel existant, l'étape suivante consiste à créer un plan de projet.

Votre plan de projet doit répertorier les étapes du projet suggérées dans cet article, bien que cette liste ne soit pas exhaustive. Veillez à prévoir suffisamment de temps pour chaque étape du projet et à prendre en compte toutes les ressources nécessaires.

Comme je l'ai indiqué, System Center Operations Manager 2007 possède une architecture passablement différente de MOM 2000 et 2005. Pour commencer, il existe un rôle de serveur supplémentaire dans Operations Manager : le serveur d'administration racine (RMS). RMS gère la configuration du groupe d'administration, traite toutes les connexions aux autres groupes d'administration et produits tiers. Il gère également la sécurité au sein du groupe d'administration. Ce rôle peut être tenu sur un serveur d'administration System Center Operations Manager existant, mais dans les environnements plus grands et complexes, il doit disposer de son propre serveur physique. De même, le concept de groupes d'administration nivelés qui existait dans MOM 2005 a été remplacé par les groupes d'administration connectés. Dans cette nouvelle architecture, aucune donnée d'alerte n'est transmise entre les groupes d'administration. Au lieu de cela, les alertes des groupes d'administration connectés sont simplement présentées dans l'interface utilisateur du groupe d'administration demandeur. De plus, si vous pensez installer les agents sur les ordinateurs dans des domaines ou groupes de travail non fiables, vous devrez utiliser des certificats pour permettre à l'agent et au serveur d'administration de s'authentifier mutuellement (fonctionnalité forcée dans Operations Manager).

Afin de concevoir l'architecture pour System Center Operations Manager, vous devrez considérer le nombre de serveurs et de clients que vous souhaitez surveiller, s'ils sont situés dans un domaine de confiance, quelles applications et plates-formes vous devez surveiller et si vous souhaitez surveiller votre infrastructure réseau. Vous devez également identifier toute application qui nécessite des règles ou des packs d'administration personnalisés.

Il s'agit là de l'étape où vous devez identifier vos exigences de pack d'administration. Après avoir déterminé les applications à surveiller, vous pouvez décider des packs d'administration à installer. Les packs d'administration contiennent des règles, des moniteurs, des tâches et des classes qui s'appliquent à une application ou un système d'exploitation spécifique et doivent être importés si leur application ou système d'exploitation associé est utilisé dans votre environnement. Le choix des packs d'administration à cette étape aura une influence sur la configuration matérielle et logicielle requise et le temps qui devra être alloué à l'installation et à la configuration du logiciel.

Une fois que vous aurez une idée de l'architecture de votre infrastructure Operations Manager, vous devrez recourir à l'outil System Center Capacity Planner 2007 (encore à la version bêta à la rédaction de cet article). Utilisez l'outil pour dresser le plan de votre infrastructure réseau et de serveurs et simuler son exécution par rapport au déploiement planifié d'Operations Manager pour vous assurer qu'il est suffisant pour contrôler et gérer votre infrastructure.

À ce stade, vous devez faire également très attention à la conception architecturale si vous comptez procéder à une migration. Vous devez considérer le fait que MOM 200x s'exécutera à côté d'Operations Manager, entraînant une augmentation du trafic réseau.

Déploiement

Le déploiement est l'étape suivante. Assurez-vous que le matériel adéquat configuré avant d'installer le logiciel. Si vous effectuez l'installation sur un nouvel environnement, un matériel physique est plus approprié, surtout pour le serveur de base de données. Cependant, les serveurs d'administration peuvent être virtualisés si le matériel physique ne peut pas être envisagé. Dans un scénario de migration, l'utilisation de serveurs virtualisés constitue une bonne alternative à l'achat de matériel pour l'installation de la nouvelle infrastructure. Dans cette situation, vous pouvez utiliser des ordinateurs virtuels pour installer Operations Manager pendant que les anciens serveurs MOM sont désactivés et reconstruits.

Une fois les serveurs configurés, vous pouvez commencer à installer le logiciel. Tout d'abord, assurez-vous que les serveurs qui exécuteront Operations Manager disposent de la configuration logicielle préalablement requise pour sa prise en charge. Par exemple, si vous exécutez SQL Server 2000 et que vous comptez installer Operations Manager sur le même serveur, vous devrez tout d'abord mettre à niveau vers SQL Server 2005 avec SP1. Pour effectuer cette vérification, exécutez le module de vérification des conditions requises d'Operations Manager à partir du support d'installation de System Center Operations Manager.

Une fois toutes ces conditions requises satisfaites et après avoir configuré SQL Server et Reporting Services, commencez l'installation du logiciel Operations Manager. Dans un environnement de serveur unique, c'est facile : il vous suffit d'exécuter le fichier d'installation Operations Manager sur le serveur, puis d'exécuter l'installation d'Operations Manager Reporting si vous souhaitez utiliser cette fonctionnalité. Cependant, dans un environnement distribué, les composants d'Operations Manager doivent être installés sur les serveurs individuels dans le bon ordre. Installez en premier la base de données, puis le premier serveur d'administration, auquel sera automatiquement attribué le rôle de serveur d'administration racine. Ensuite, tout serveur d'administration supplémentaire peut être installé. L'étape finale consiste à installer la console Web et les composants de rapport.

Migration

À cette étape, vous devez vous assurer que votre nouvelle infrastructure reflète votre surveillance existante avant de tenter d'exploiter toute nouvelle fonctionnalité. Tout pack d'administration utilisé dans l'ancien environnement doit être dupliqué dans le nouveau déploiement d'Operations Manager. S'il existe un pack d'administration d'Operations Manager, vous souhaiterez peut-être l'importer, mais tout pack d'administration qui ne dispose pas de nouvelles versions devra être exporté du groupe d'administration actuel, converti à l'aide de l'outil MPConvert depuis le CD d'installation, puis importé dans Operations Manager, à moins que votre pack d'administration personnalisé soit simple ou peu volumineux, auquel cas il est préférable de simplement le recréer. Il existe également un outil très utile pour la duplication de la configuration. L'outil de migration de MOM 2005 vers Operations Manager aide à dupliquer la configuration d'un groupe d'administration MOM existant vers Operations Manager. Vous le trouverez également sur le CD d'installation d'Operations Manager. La figure 2 illustre une configuration typique lors d'une migration.

Figure 2** Configuration typique lors d'une migration **(Cliquer sur l'image pour l'agrandir)

Une fois votre configuration dupliquée, assurez-vous que vous obtenez les mêmes alertes et recueillez les mêmes données avec Operations Manager qu'avec MOM. Heureusement, l'agent Operations Manager peut coexister avec les agents hérités de MOM pour une exécution simultanée des agents des deux versions. Vous pouvez recueillir des données des agents des deux versions et les comparer côte à côte par souci d'exactitude avant de désactiver le système hérité.

Vous devez ensuite formuler un plan de tests. Les tests peuvent consister en une simple comparaison des alertes du système hérité avec celles du système Operations Manager, mais peuvent également aller jusqu'à nécessiter la génération délibérée d'alertes pour une évaluation complète de la nouvelle infrastructure. Une fois satisfait des résultats de tests, vous pouvez commencer à désinstaller les agents MOM hérités à l'aide de la console MOM ou avec l'option Ajout/Suppression de programmes sur les ordinateurs agents.

La création de rapports représente un aspect important d'un déploiement MOM et System Center Operations Manager et doit également être abordée. La base de données SystemCenterReporting existante ne peut pas être actuellement migrée vers Operations Manager 2007. Par conséquent, vous pouvez créer une nouvelle instance de Reporting Services pour Operations Manager et conserver la base de données MOM 2005 existante (SystemCenterReporting) dans une instance de SQL Reporting Services dédiée pour afficher les rapports hérités. La nouvelle console de rapports de System Center Operations Manager 2007 est intégrée au produit. Il n'est donc pas recommandé d'utiliser la console Reporting Services pour tout ce qui n'est pas Operations Manager. La migration des données de rapports sera peut-être possible à l'avenir au moyen d'un script de migration de données, mais pour le moment, vous devrez peut-être dire au revoir à vos données de rapports archivées et vous consoler en pensant que lorsque vous commencerez à générer vos tout nouveaux rapports, la direction sera si enthousiaste qu'elle ne remarquera même pas que vos anciennes données ont disparu.

Conclusion

System Center Operations Manager offre des améliorations significatives par rapport à MOM 2000 et 2005, mais ces avancées peuvent avoir un coût. Une modification majeure de l'architecture sous-jacente (et par conséquent, l'absence d'un chemin de mise à niveau direct) signifie que les coûts de déploiement sont potentiellement plus élevés. Pour réduire ces coûts, vous devez effectuer une planification détaillée et vous assurer que vous disposez des bonnes personnes pour effectuer cette migration. Faites tout cela et vous récolterez les avantages du dur labeur de Microsoft grâce à System Center Operations Manager.

Andy Dominey est dans le secteur informatique depuis huit ans et est actuellement employé chez 1E, Royaume-Uni, en tant que spécialiste de l'administration Windows. Il travaille sur MOM depuis MOM 2000. Andy a reçu la récompense Microsoft MVP ces deux dernières années pour MOM.

© 2008 Microsoft Corporation et CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable.