Internet Data Center : Conception de la solution de gestion

Sur cette page

Microsoft Internet Data Center : Conception de la solution de gestion
Résumé
Introduction
Analyse et alarmes
Ressources nécessaires
Éléments requis par la conception de la solution d'analyse et d'alarme
Éléments requis par les fonctionnalités
Conditions liées au réseau
Conditions de sécurité
Conditions d'évolutivité et de performances
Configuration requise par le modèle opérationnel
Analyse et alarmes
Identification des problèmes
Types de systèmes d'analyse
Principes généraux de l'analyse
Méthodes d'analyse
Conception de la solution d'analyse et d'alarme
Résumé des fonctionnalités des produits
Placement des agents de gestion
Organigramme du Processus
Infrastructure d'analyse et d'alarme
Analyse du matériel et de l'infrastructure
Analyse du système d'exploitation et des services d'infrastructure
Analyse du réseau Web frontal
Gestion des événements liés au réseau Web frontal
Analyse du réseau VLAN d'infrastructure
Analyse du réseau VLAN de données et de gestion
Flux d'événements
Flux d'événement Microsoft Operations Manager
Flux d'événement AppManager
Flux d'événement lié aux agents de matériel de serveur
Flux d'événement AppMetrics
Gestion à distance
Ressources nécessaires
Conditions préalables à la conception de la solution de gestion à distance
Organigramme du processus
Blocs de conception
Détails des éléments à prendre en compte pour la gestion à distance
Conception de la solution de gestion à distance
Identification des outils disponibles pour la gestion à distance
Sélection des outils de gestion à distance appropriés
Détermination des personnes qui accèderont aux serveurs
Choix de la manière d'analyser l'accès aux serveurs
Détermination de la configuration de sécurité optimale
Détermination de la manière d'accéder au réseau de gestion à distance
Planification, déploiement et test des composants de gestion à distance
Méthodes recommandées d'administration à distance
Déploiement du contenu à l'aide de Microsoft Application Center
Gestion de contenu, comme définie par MOF
Mise en œuvre de la gestion de contenu
Autres considérations liées à la gestion de contenu
Éléments requis par la gestion de contenu
Organigramme du Processus
Architecture de gestion de contenu
Conception technique de la gestion de contenu
Processus d'introduction de la gestion de contenu
Serveurs Web frontaux (IIS)
Réseau VLAN d'infrastructure
Conception de la solution de sauvegarde
Importance de la sauvegarde de l'environnement
Plan de prévention des pannes
Plan de restauration d'urgence en cas d'incident grave
Choix des éléments à sauvegarder
Choix des éléments à restaurer
Réseaux VLAN de données et de gestion
Réseau VLAN d'infrastructure
Réseau Web frontal
Organigramme du processus
Stratégies de sauvegarde
Prévention des sauvegardes inutiles
Choix du moment approprié pour la sauvegarde
Types de sauvegarde
Considérations sur le matériel
Résumé
Analyse et alarmes
Gestion à distance
Gestion du contenu
Sauvegarde
Informations complémentaires
Sites/liens Web
Kits de ressources

Microsoft Internet Data Center : Conception de la solution de gestion

Cet article est tiré du Guide de référence Internet Data Center

Résumé

Ce chapitre fournit une présentation du processus de conception requis pour la création des systèmes de gestion utilisés au sein de Microsoft® Internet Data Center. Ces systèmes couvrent tous les domaines de gestion de cette solution, y compris l'analyse des serveurs et les alertes, la gestion à distance, la gestion de contenu et la sauvegarde.

Introduction

Ce chapitre fournit une vue d'ensemble sur les processus et outils de gestion utilisés dans Microsoft® Internet Data Center pour les systèmes de gestion qui prennent en charge les objectifs clés associés à la solution : la disponibilité, l'évolutivité et la sécurité. Plusieurs éléments composent les systèmes de gestion, y compris l'analyse des serveurs et les alertes, la gestion à distance, la gestion de contenu et la sauvegarde.

La conception de la solution d'analyse et d'alarme utilise Microsoft Operations Manager 2000, NetIQ AppManager, Xtremesoft AppMetrics et des agents de gestion de matériel tiers. La conception de la gestion à distance utilise les services Terminal Server comme outil d'accès distant de gestion principal et des cartes physiques de gestion de serveur tierces pour l'accès hors bande. L'architecture de déploiement/gestion de contenu utilise Microsoft Application Center 2000 pour gérer le l'application planifiée et sécurisée des modifications du contenu et de la structure du site. Des sauvegardes complètes et testées sont un composant essentiel de l'architecture Internet Data Center. La dernière section de ce chapitre offre une vue d'ensemble du processus de conception du déploiement d'une solution de sauvegarde appropriée, permettant de protéger l'architecture Internet Data Center. La solution de gestion à distance fait partie de l'architecture Internet Data Center de base ; les autres solutions de gestion présentées dans ce chapitre sont des composants additionnels, qui peuvent être intégrés à l'architecture de base, en fonction des besoins.

Analyse et alarmes

Cette section offre une description de la solution conçue pour analyser et émettre des alertes liées à l'infrastructure de serveurs de l'architecture Internet Data Center. Cette solution a été conçue pour être mise en œuvre comme un ensemble de composants additionnels à intégrer à l'architecture de base décrite au Chapitre 2, "Conception de l'infrastructure réseau", Chapitre 3, "Conception de pare-feu" et Chapitre 4, "Infrastructure de sécurité".

La solution d'analyse et d'alarme décrite dans cette section est hautement évolutive et robuste. Cette section ne traite pas de l'analyse des éléments en dehors de l'environnement Internet Data Center, via Internet ou un intranet. Cette version de l'architecture Internet Data Center ne prend pas en charge la tolérance aux pannes de la solution de gestion et n'utilise pas explicitement Microsoft Windows® Management Instrumentation (WMI), l'Analyseur de performances Microsoft ni Microsoft Application Center Health Monitoring, bien que ce soient des composants importants de la solution de gestion globale Microsoft.

Ressources nécessaires

Des membres des équipes suivantes sont requis pour mettre en œuvre une solution d'analyse et d'alarme :

• Support technique Microsoft Windows 2000 Server

• Administration Windows 2000

• Opérations de réseau

• Service d'assistance

• Analyse Windows 2000

• Administration d'infrastructure

• Sécurité

• Administration réseau (pour fournir des informations DNS, ainsi que d'autres informations concernant le réseau)

Éléments requis par la conception de la solution d'analyse et d'alarme

Pour maintenir la disponibilité, l'évolutivité et la sécurité de l'architecture Internet Data Center, il est essentiel d'analyser ses systèmes. La fonctionnalité d'alarme permet de garantir que les événements système importants sont automatiquement portés à l'attention du personnel d'administration.

Éléments requis par les fonctionnalités

Plus un environnement est sophistiqué, élaboré et distribué, plus il nécessite une analyse. Un échec d'analyse de l'état de l'architecture entraîne la création d'un modèle d'administration entièrement réactif, dans lequel une action est entreprise pour résoudre un problème, seulement une fois que le problème est devenu suffisamment sérieux pour que les utilisateurs le signalent. La solution d'analyse de l'architecture Internet Data Center a été conçue pour fournir un modèle administratif proactif, dans lequel les problèmes sont automatiquement détectés avant de prendre une dimension susceptible d'affecter le système. Pour remplir cet objectif, le système d'analyse doit répondre aux critères fonctionnels suivants :

• Gestion complète des événements. La gestion des systèmes doit utiliser des vues consolidées couvrant plusieurs systèmes, ce qui fournit une automatisation en temps réel et une récupération à l'aide de réponses pouvant faire l'objet de scripts.

• Analyse discrète. La solution d'analyse doit être aussi discrète que possible, tout en permettant la capture des informations requises.

• Capacité à empêcher les pannes en cascade. Si une panne survient, elle peut déclencher d'autres alertes. La solution d'analyse et d'alarme doit être conçue pour empêcher de telles pannes en cascade.

• Analyse de l'historique. La solution d'analyse doit fournit un historique précis des événements et des problèmes. L'analyse de l'historique permet d'identifier plus facilement les problèmes récurrents et de fournir des statistiques de planification des capacités. Elle permet également la création de rapports de fiabilité et de disponibilité sur l'architecture Internet Data Center.

• Réponse automatisée. Des règles créées par l'administrateur doivent être utilisées pour permettre au système de réagir automatiquement aux messages entrants, soit pour répondre à un scénario de panne spécifique par une action définie au préalable, soit pour consolider les messages en un événement plus significatif. La solution de gestion peut alors réagir intelligemment à des types d'événements, en déclenchant des actions ou des alertes administratives. Les règles peuvent aussi lier une séquence d'événements à des articles de la base de connaissances, en fournissant instantanément aux opérateurs un guide sur les causes probables du problème, la réponse à un scénario spécifique et des liens vers des informations complémentaires.

• Notification. Si un événement système justifie une intervention, les parties responsables doivent être notifiées de manière à pouvoir mettre en œuvre un plan d'action et les parties affectées par l'événement doivent être notifiées séparément.

Conditions liées au réseau

Une solution d'analyse et d'alarme doit prendre en charge tous les périphériques du système et doit prendre en considération la configuration réseau requise et l'impact potentiel sur la bande passante du réseau. La solution Internet Data Center utilise les éléments suivants :

• Protocoles standard. Des protocoles standard de l'industrie, tels que le protocole SMTP (Simple Network Management Protocol), sont utilisés dans la solution d'analyse pour augmenter au maximum le nombre de périphériques susceptibles d'être pris en charge par le système d'analyse.

• Bande passante minimale. La solution d'analyse et d'alarme génère un faible trafic réseau et a été testée pour garantir qu'elle ne réduit pas la bande passante requise pour traiter les réponses aux clients ni pour communiquer entre les hôtes au sein de l'architecture Internet Data Center. Pour les sites de très grande taille, dans lesquels les données d'analyse peuvent affecter la bande passante disponible du réseau, un outil de gestion distinct doit être installé.

Remarque : Pour plus d'informations sur les conditions préalables à la mise en réseau de la solution d'analyse et d'alarme de l'architecture Internet Data Center, voir le Chapitre 2, "Conception de l'infrastructure réseau".

Conditions de sécurité

Il est important de comprendre quelles sont les conditions de sécurité liées à la solution d'analyse et d'alarme et leur impact sur l'environnement Internet Data Center. La solution Internet Data Center doit fournir les éléments suivants :

• Connexion serveur/agent. Les outils d'analyse requièrent une connexion entre le serveur géré et le serveur de gestion. Microsoft Operations Manager (MOM) requiert le port 1270 via TCP/IP. Pour que le Gestionnaire des agents MOM fournisse l'ensemble de ses fonctionnalités, RPC doit être disponible. NetIQ AppManager requiert les ports 9998 et 9999 via TCP/IP. Le port 9979 et RPC sont requis pour l'installation à distance des agents.

• Réseau de gestion sécurisé. Par souci de sécurité, toute la gestion doit être effectuée sur un réseau distinct. Comme tous les serveurs sont accessibles via le réseau de gestion, toute compromission de ce réseau peut entraîner l'accessibilité via Internet à tous les serveurs de l'environnement.

Conditions d'évolutivité et de performances

La solution d'analyse et d'alarme doit être en mesure de croître avec l'environnement. Il est important d'envisager comment la solution d'analyse et d'alarme sera mise en œuvre lors du développement de l'environnement. Ceci est particulièrement vrai pour le dimensionnement et le placement des serveurs de gestion.

Évolutivité de l'infrastructure d'analyse

Les trois considérations les plus importantes dans la conception de l'infrastructure de gestion système sont :

• Le nombre de serveurs à analyser

• Le volume des données d'audit à collecter

• La topologie/géographie des serveurs analysés

Sites de petite taille

Si le réseau de gestion doit analyser moins de 200 serveurs, un serveur unique est généralement adéquat pour toute topologie, à moins que des audits intensifs soient requis. Microsoft Operations Manager peut être utilisé pour effectuer la gestion complète des journaux d'événements, y compris la collecte et la mise en corrélation des événements de sécurité (ces événements sont les alertes les plus nombreuses générées par les serveurs).

Remarque : Un serveur pauvrement configuré est capable de générer des millions d'événements par jour, ce qui peut aisément dépasser la capacité de votre système de gestion.

Il est recommandé de distribuer les fonctions entre plusieurs serveurs avant que le niveau de 50 serveurs soit atteint. Cela permet un meilleur développement et la redondance des composants d'analyse centraux.

Le tableau suivant montre le type de matériel nécessaire à l'analyse des événements et à un audit modéré de la sécurité. Un niveau d'audit modéré permet le suivi des exceptions de sécurité. À l'opposé, configurer un environnement avec un niveau d'audit de sécurité élevé implique la vérification des autorisations de chaque objet et l'accès à cet objet. Une haute sécurité requiert une augmentation importante de la taille de stockage des données.

Nombre de serveurs analysés	Configuration centrale des serveurs Microsoft Operations Manager
Moins de 20	1 X Pentium II 400, 512 méga-octets (Mo) de RAM Lecteur système : RAID 1 de 4 giga-octets (Go) Lecteur de données : total de 18 Go sur RAID 5
20–50	2 X Pentium III 500, 640 Mo de RAM Lecteur système : RAID 1 de 4 Go Lecteur de données : RAID 5 de 18 Go Lecteur de journaux : RAID 5 de 9 Go
50–100	4 X Pentium III 650, 1 Go de RAM Lecteur système : RAID 1 de 4 Go Lecteur de données : RAID 0+1 de 36 Go Lecteur de journaux : RAID 5 de 12 Go
100–200	4 X Pentium III 850, 2 Go de RAM Lecteur système : RAID 1 de 8 Go Lecteur de données : RAID 0+1 de 48 Go Lecteur de journaux : RAID 0+1 de 16 Go

Sites de grande taille

Pour les installations contenant plus de 200 serveurs à analyser, certaines fonctions doivent toujours être distribuées sur des serveurs additionnels.

Les serveurs d'analyse doivent être dupliqués (par exemple, deux serveurs peuvent être configurés à l'identique) pour être utilisés comme serveurs d'équilibrage de la charge et/ou serveurs redondants. Il est possible d'utiliser plusieurs serveurs de gestion avec un seul serveur de base de données. Par exemple, le cas correspondant à
400–800 serveurs à analyser dans le tableau ci-dessous met en jeu jusqu'à six serveurs de gestion par base de données, ce qui entraîne un total de plusieurs milliers de serveurs, qui alimentent un seul magasin en données opérationnelles.

Les capacités de stockage totales des serveurs de base de données supposent une collecte modérée des données de tendances à long terme. S'il est nécessaire de conserver des données sur les performances pendant plus de trois mois, ou des données sur la sécurité pendant plus d'un mois, envisagez l'utilisation d'un serveur de requête. Un serveur de requête est un serveur d'informations supplémentaire, de grande capacité, qui extrait régulièrement des données de la base de données et les conserve en vue d'un stockage et de rapports à long terme. Un serveur de requête permet de réduire la taille de la base de données du serveur de gestion et de conserver moins de données.

Utilisez le tableau suivant pour déterminer le type de matériel nécessaire pour effectuer une analyse des événements et un audit de sécurité modéré sur différents serveurs de gestion et de base de données.

Nombre de serveurs analysés (par serveur de gestion)	Configuration des serveurs de gestion	Configuration des serveurs de base de données
200–400	2 X Pentium III 500 256 méga-octets (Mo) de RAM Lecteur système : RAID 5 de 4 Go Lecteur de données : RAID 5 de 8 Go	4 X Pentium III 850 2 Go de RAM Lecteur système : RAID 5 de 8 Go Lecteur de données : RAID10 de 48 Go Lecteur de journaux : RAID10 de 16 Go
400–800	4 X Pentium III 650 512 Mo de RAM Lecteur système : RAID 5 de 4 Go Lecteur de données : RAID 5 de 8 Go	8 X Pentium III 850 4 Go de RAM Lecteur système : RAID 5 de 8 Go Lecteur de données : RAID 0+1 de 80 Go Lecteur de journaux : RAID 0+1 de 36 Go

Pour une présentation complète de la conception, des composants et des groupes de configuration liés à Microsoft Operations Manager, voir le Guide de l'utilisateur de Microsoft Operations Manager.

Configuration requise par le modèle opérationnel

Lors de la conception de la solution de gestion, il est important de prendre en compte le modèle opérationnel du centre informatique. La solution d'analyse et d'alarme Internet Data Center doit répondre aux conditions suivantes :

• Souplesse. Dans la plupart des cas, si la gestion de l'entreprise est centralisée, les serveurs de gestion et la base de données doivent se trouver dans le centre informatique central. Si la gestion est locale ou si une conception de réseau en étoile à plusieurs niveaux est utilisée, des serveurs de gestion plus petits doivent être déployés au niveau des concentrateurs et configurés dans une structure à plusieurs niveaux pour une gestion, une analyse et une collecte de données d'audit centralisées.

• Acceptation des opérateurs système. Il est également important de prendre en considération la manière dont cette solution de gestion sera utilisée par les opérateurs système. Les solutions d'analyse et d'alarme sont intéressantes dans l'architecture Internet Data Center, seulement si elles sont utilisées correctement. En définitive, les facteurs les plus importants dans l'environnement Internet Data Center sont les opérateurs système et les administrateurs qui travaillent tous les jours avec les outils et l'environnement. Il est donc essentiel que ces employés soient entraînés et formés sur la manière d'utiliser ces outils.

Remarque : La structure Microsoft Operations Framework (MOF) est une excellente source d'informations sur la manière d'exécuter et d'administrer l'environnement d'un data center. La structure Microsoft Operations Framework fournit une assistance technique utile sous forme de livres blancs, guides des opérations, outils d'analyse, kits d'opérations, méthodes recommandées, études de cas, modèles, outils de support et services. Cette assistance couvre les problèmes liés aux individus, aux processus, à la technologie et à la gestion, propres aux environnements informatiques complexes, distribués et hétérogènes. Pour plus d'informations, visitez la page Better Manage Your IT Systems with the Microsoft Operations Framework 

Analyse et alarmes

Une application Web .NET dans l'environnement Internet Data Center consiste en général en plusieurs couches de fonctionnalités physiques et logiques. La première couche est composée de serveurs exécutant Windows 2000 et Microsoft Internet Information Services (IIS) pour fournir des pages Web ASP et ASP+. La deuxième couche est composée de serveurs de logique d'entreprise exécutant des objets COM+ (Component Object Model) et peut-être aussi Message Queuing. La troisième couche se compose de la base de données Microsoft SQL Server™ utilisée pour conserver les informations. Ces trois couches fonctionnent ensemble pour créer un environnement d'application Web.

Chaque couche de cet environnement doit être analysée pour garantir le fonctionnement correct du site. Des outils d'analyse sophistiqués permettent d'anticiper les pannes, de comprendre les baisses de performances et d'utiliser les informations capturées pour affiner la configuration du système. Le coût de possession de ces systèmes et applications peut être réduit par l'automatisation des tâches longues et répétitives, fournissant des règles de gestion d'entreprise et des connaissances. Ces règles portent sur la gestion et l'analyse des environnements Windows 2000 distribués, sur la centralisation de la gestion des systèmes et des applications distribués et distants et sur l'activation de la notification et de la correction proactives des problèmes, avant qu'ils affectent l'environnement Web et l'entreprise.

Un système d'analyse est constitué de trois types d'éléments :

• Des périphériques et des services à analyser

• L'identification du problème, l'alerte et la notification

• Des processus d'escalade, qui déterminent la manière de répondre aux événements

La Figure 1 illustre les modules qui correspondent à ces éléments.

Figure 1. Composants d'un système d'analyse active

Identification des problèmes

L'élément d'identification des problèmes est composé de trois modules, qui déterminent ensemble la manière dont le problème sera géré. Ces modules sont les suivants :

• Module d'interrogation de périphériques et d'applications. Ce module représente la fonction ou le processus responsable de la vérification périodique de l'état d'un service, périphérique, hôte, application, ou autre système à analyser. Lorsqu'un périphérique ne répond pas à une interrogation spécifiée, une alerte est générée pour indiquer quel périphérique a échoué et la nature de la panne.

• Module de mise en corrélation des événements. Ce module est fourni par le module d'interrogation et met en corrélation les événements pour déterminer la cause initiale de la panne. Il supprime ensuite tous les événements qui ont pu se produire suite à d'autres événements (par exemple, un routeur tombant en panne risque d'affecter tous les hôtes, les systèmes ou les périphériques en aval du périphérique, les rendant temporairement indisponibles). Après suppression des événements indirects, le module construit une ou plusieurs alertes et les transfert au module de notification.

• Module de notification. Ce module reçoit les alertes en provenance du module de corrélation et génère les notifications au répondant ou à la partie responsable appropriée (programmée). Dans certains cas, ce module génère une notification destinée à un système de réponse automatisée, préprogrammé pour redémarrer un service, ou exécute toute autre action destinée à remédier à la défaillance.

Types de systèmes d'analyse

Il existe trois types d'analyseurs utilisés dans l'architecture Internet Data Center :

• Les analyseurs d'erreurs matérielles détectent les pannes de réseau et de matériel. Comme exemple d'erreur matérielle, citons une panne de serveur d'annuaire ou la perte d'un disque, entraînant une perte de fonctionnalité ou de service d'annuaire. 

• Les analyseurs d'erreurs logicielles détectent les problèmes de programmation et de données, susceptibles de générer des données erronées ou incohérentes et des défaillances générales dans les applications.

• Les analyseurs de performances fournissent des commentaires précieux sur les performances du système, en identifiant les goulets d'étranglement, les points de conflits et la dégradation des performances. L'analyse des performances peut également fournir des informations de base, qui peuvent s'avérer utiles lors de la planification des capacités ou de l'exécution d'une mise à niveau vers l'architecture Internet Data Center.

Principes généraux de l'analyse

Cette section présente plusieurs principes fondamentaux de l'analyse de l'environnement Internet Data Center.

Analyse inaperçue

Vous devez comprendre clairement les implications de la stratégie d'analyse que vous adoptez. Une solution pauvrement conçue ou mise en œuvre peut nuire aux performances ou au fonctionnement du système. En général, la solution d'analyse doit avoir l'impact le plus faible possible sur le système analysé, tout en fournissant toutes les informations appropriées.

Si, par exemple, vous utilisez une interrogation, il suffit de récupérer une seule entrée pour indiquer que le serveur fonctionne bien, plutôt que plusieurs ou de nombreuses entrées. Le système doit être interrogé uniquement lorsque cela s'avère absolument nécessaire pour assurer une réponse adéquate. Cela limite la charge supplémentaire imposée aux serveurs et aux applications. Interroger un système trop tôt et trop souvent permettra de renvoyer plus tôt des informations sur la panne, mais placera une charge gênante sur les services. L'architecture Internet Data Center a été conçue pour ne pas utiliser plus de 5 % des ressources du dispositif analysé. Ce taux varie selon le matériel utilisé et doit être évalué séparément pour chaque ordinateur.

Prévention des pannes en cascade

Si une panne survient, elle peut déclencher d'autres alertes dans la solution d'analyse. L'échec d'un ensemble de serveurs exécutant Microsoft Internet Information Services (IIS) peut par exemple placer une charge supplémentaire sur les serveurs restants, qui généreront à leur tour des alertes. Si cela se produit, vous pouvez répondre en désactivant les services ou les applications non critiques, afin de réduire la charge sur les serveurs restants. En outre, vous devez évaluer les capacités du système pour fournir de manière proactive des capacités système supplémentaires dans le cas où le problème se reproduirait.

Maintien d'un historique des problèmes

Vous devez concevoir la solution d'analyse pour qu'elle fournisse un historique précis des événements et des problèmes. Par exemple, si le système d'analyse et de gestion de réseau enregistre des événements dans un format standard, les entrées liées à IIS peuvent être régulièrement extraites, compilées et archivées dans un emplacement central pour pouvoir être passées en revue ultérieurement. Ces journaux extraits fournissent des données de tendances critiques, qui peuvent être utilisées pour les opérations suivantes :

• Identification des problèmes récurrents (informations sur les causes et
  les conséquences).

• Planification des capacités de support technique.

• Informations résumées sur la fiabilité et la disponibilité.

Maintien d'un plan écrit

Pour chaque panne, événement ou problème, il doit exister un plan écrit capable de fournir des réponses opportunes, précises, cohérentes et réutilisables. L'exécution d'un plan cohérent pour traiter les événements récurrents peut vous aider à réduire vos coûts en temps, ressources et argent.

Utilisation de techniques de notification efficaces

La capture active d'informations sur les événements en temps réel est inutile, s'il n'est pas notifié aux parties responsables de mettre en œuvre le plan d'action. La notification des événements accomplit quatre objectifs importants :

• Notifier les parties responsables de la réparation du problème. Dès qu'un problème est détecté, le système doit notifier la ou les personnes responsables de sa résolution. Ceci concerne en général une ressource de niveau supérieur, telle qu'un architecte système, un ingénieur système ou un consultant qui a conçu et déployé la solution. En fonction de la nature et de la sévérité du problème, ainsi que de la sophistication de vos capacités de réponse aux événements, cette personne peut aussi être un administrateur système ou un technicien correctement formé pour répondre aux événements d'interruption du système. Ce type de notification est en général urgent — en particulier dans une situation où l'environnement est capital pour l'entreprise et doit être constamment opérationnel — et prend le plus souvent la forme d'un appel téléphonique ou d'un message.

• Notifier les parties responsables de l'administration du système. Le système de notification doit aussi notifier le groupe responsable de l'administration de l'environnement Internet Data Center. Cette notification s'effectue à titre informatif et peut prendre la forme d'un message électronique. Celui-ci indique au groupe responsable qu'il existe un problème, et que ce dernier est en cours de résolution ou a déjà été résolu par un système de réponse automatisée. Il est important que la coordination soit étroite entre les personnes responsables de la résolution du problème et le groupe responsable du support administratif.

• Notifier les parties affectées par l'événement. Les utilisateurs et les clients doivent éventuellement être prévenus d'une interruption. Bien que les clients n'aient pas à connaître les détails du problème, ils doivent être prévenus en cas d'interruption (ou d'interruption anticipée) et doivent être informés du moment où le problème sera résolu. Selon la partie concernée, cette notification peut prendre la forme d'un message électronique, d'une page Web qui répertorie des informations sur les interruptions système, un message de messagerie vocale téléphonique ou même une notification au personnel du service d'assistance, qui sera chargé de transmette les informations lorsque les clients demanderont de l'assistance.

• Notifier chaque partie de manière appropriée pour réagir. Une fois que vous avez capturé un événement et avez notifié les personnes adéquates de la manière appropriée, vous devez effectuer les opérations suivantes :

  • diminuer au maximum l'impact du problème ;

  • corriger le problème ;

  • déterminer la nature exacte du problème ;

  • exécuter une analyse de l'origine de la cause ;

  • créer un plan formel visant à fournir une solution à long terme et un plan d'action réutilisable si l'événement devait se reproduire.

Méthodes d'analyse

L'analyse peut être mise en œuvre de plusieurs manières. L'architecture Internet Data Center utilise les méthodes d'analyse suivantes car elles répondent aux conditions de conception.

SNMP (Simple Network Management Protocol)

Vous pouvez utiliser le protocole SNMP (Simple Network Monitoring Protocol) pour analyser et gérer des applications et des processus, qui s'exécutent sur des serveurs et d'autres périphériques de support. SNMP permet à une application de gestion de surveiller l'état d'une entité sur un réseau. Une application de gestion peut également être notifiée de manière asynchrone (la notification ne requiert pas d'accusé de réception) par le biais du mécanisme de piège SNMP, lorsqu'un événement ou une erreur survient.Le protocole SNMP est utilisé sur tous les serveurs de l'environnement Internet Data Center pour fournir des informations sur l'état du système.

Interrogation LDAP

L'interrogation LDAP (Lightweight Directory Access Protocol) est utilisée pour analyser la santé et l'état du service d'annuaire Active Directory™ au sein de l'environnement Internet Data Center. Une des méthodes les plus simples et efficaces d'analyser l'annuaire consiste à s'y connecter à partir d'un client et d'exécuter des demandes ou des commandes LDAP. Par exemple, un outil d'interrogation simple peut se connecter à un annuaire et rechercher une entrée déterminée. Si la réponse survient dans le délai spécifié, l'annuaire est considéré comme opérationnel. Si ce n'est pas le cas, l'outil d'interrogation peut générer une erreur, une alerte ou une notification personnalisée.

Interrogations spécifiques au système d'exploitation

Le système d'exploitation Microsoft Windows 2000 propose des outils intégrés, qui assurent l'analyse de leurs services respectifs, y compris de leurs services d'annuaire natifs. Ce type d'informations peut vous aider à déterminer si votre annuaire rencontre un problème dû au système d'exploitation. Les interrogations Windows 2000 sont utilisées sur tous les serveurs pour fournir des informations sur l'état et la santé du système d'exploitation.

Analyse indirecte

L'analyse des applications qui sollicitent directement l'infrastructure Internet Data Center (l'utilisent ou y accèdent) procure à l'utilisateur final une vue de la réactivité et de la fiabilité du système. L'analyse indirecte est utilisée dans l'environnement Internet Data Center sur tous les serveurs qui répondent aux demandes des clients. Ce type d'analyse peut s'avérer extrêmement important et est le plus souvent négligé. L'analyse indirecte fournit une vue précise des performances et de l'efficacité des applications.

Analyse des fichiers journaux

Les fichiers journaux du système peuvent être automatiquement analysés pour détecter les événements qui indiquent une condition d'erreur ou des problèmes de performances. L'analyse des fichiers journaux est une méthode très efficace d'analyse proactive, dans laquelle les conditions d'erreur et les indications des problèmes imminents sont identifiées, avant d'affecter les clients. L'analyse des fichiers journaux est réalisée sur les serveurs Web dans l'environnement Internet Data Center. 

Conception de la solution d'analyse et d'alarme

La solution d'analyse et d'alarme pour l'architecture Internet Data Center doit être conçue pour optimiser les performances et l'évolutivité, fournir un environnement sécurisé et fournir toutes les informations nécessaires à la gestion proactive
de l'architecture.

Dans la ferme de gestion, deux serveurs traitent les données Microsoft Operations Manager et NetIQ AppManager. Un de ces serveurs est également utilisé pour la collecte et le stockage des données Xtremesoft AppMetrics. Au total, trois serveurs sont utilisés pour que la solution d'analyse présente une souplesse et des performances optimales.Le premier serveur agit en tant qu'espace de stockage et point de collecte de toutes les informations d'analyse et d'alarme. Le deuxième serveur représente le point de convergence de l'analyse et des alertes proactives dans l'environnement Internet Data Center. Ce serveur est responsable de toutes les communications avec les agents et héberge également toutes les consoles de gestion.

Un troisième serveur exécutant les services Terminal Server fournit aux outils d'analyse et d'alarme l'accès à la gestion à distance. La sécurité représente un point essentiel dans cette architecture, de sorte que tous les agents inscrits dans le réseau périphérique (également nommé zone démilitarisée, zone DMZ ou sous-réseau filtré) utilisent un cryptage dans les communications à destination du serveur contenant l'espace de stockage des données.

Résumé des fonctionnalités des produits

Chaque produit de gestion utilisé dans la solution de gestion pour l'architecture Internet Data Center apporte son lot particulier de fonctionnalités, qui s'additionnent pour former la solution complète de gestion. Vous trouverez ci-dessous une liste détaillée des fonctionnalités de chaque produit composant la solution de gestion, et des domaines dans lesquels elles sont utilisées.

Microsoft Operations Manager

Microsoft Operations Manager (MOM) est utilisé dans l'architecture Internet Data Center pour traiter spécifiquement la gestion des éléments suivants :

• Les serveurs Windows 2000

• Les serveurs Microsoft® .NET Enterprise Server

• Les applications utilisant Microsoft BackOffice®

• Les applications et les services hébergés par Windows 2000

Il répond aux conditions clés de gestion des entreprises utilisant Windows, dont :

• Des fonctions de gestion centrales, telles que la gestion des événements, l'analyse et les alertes proactives, les rapports et l'analyse des tendances.

• L'analyse de la santé et des activités des serveurs Windows 2000 et .NET Enterprise Server, tels que Microsoft Exchange 2000, SQL Server et Commerce Server.

• L'analyse des applications Microsoft BackOffice.

• La gestion d'applications et de services supplémentaires, qui sont hébergés au sein de l'environnement Windows 2000.

En raison du caractère exhaustif de ces fonctions, vous pouvez utiliser MOM en tant que point unique central d'analyse et de contrôle de votre environnement Windows 2000.

MOM a été conçu pour être utilisé comme console du data center de gestion pour l'environnement Internet Data Center et les serveurs Windows 2000 et .NET Enterprise Server. MOM permet la consolidation des événements et peut être utilisé pour créer des stratégies de gestion et un système conforme aux accords de niveau de service, qui utilise des workflow de résolution d'alerte efficaces et rapides. MOM fournit la plupart des outils nécessaires à la détection et à la résolution rapides des problèmes les plus courants dans les entreprises utilisant Windows. Tous les autres produits et solutions de gestion figurant dans l'architecture Internet Data Center sont configurés directement ou indirectement pour transmettre leurs informations et événements à la console MOM.

Un atout majeur de MOM tient à ce qu'il utilise les connaissances des ingénieurs Microsoft, qui sont des experts en technologies Microsoft. Par exemple, il peut traiter rapidement et efficacement des problèmes courants liés à Active Directory, car il intègre la somme des connaissances des employés Microsoft qui ont conçu Active Directory. MOM peut également être amélioré à l'aide de Packs de gestion, édités par Microsoft ou des partenaires de Microsoft, comme par exemple NetIQ.

AppManager

MOM a été conçu pour être utilisé principalement par les techniciens des opérations, qui ont besoin d'un outil de filtrage efficace et rapide, capable de résoudre les problèmes automatiquement et de les guider dans le traitement des problèmes qui requièrent une intervention manuelle. Pour sa part, NetIQ AppManager a été conçu pour les experts en informatique qui ont besoin de se plonger dans un système d'entreprise spécifique pour rechercher des causes primaires et, si nécessaire, créer des scripts ou d'autres fonctions pour cibler les problèmes très spécifiques que les techniciens opérationnels ne peuvent pas résoudre. Comme MOM et NetIQ AppManager s'adressent à des groupes d'utilisateurs finals relativement différents, dont les tâches professionnelles, le contexte et les besoins diffèrent, les deux produits sont utilisés au sein de l'architecture Internet Data Center pour fournir une solution complète. Cette solution utilise ces produits, connectés entre-eux, pour créer un flux de données pour certains événements et applications.

Solution mettant en jeu des agents de gestion du matériel de serveur

En utilisant des agents de gestion spécifiques au matériel de serveur pour activer l'analyse et les alertes sur tous les serveurs de l'environnement Internet Data Center, il est possible d'analyser de nombreux types d'états du matériel, qu'il peut être difficile d'identifier par une autre méthode.

Obtenir ce type d'informations sur le matériel de serveur vous permet d'identifier les composants défaillants et les goulots d'étranglement potentiels, vous permettant ainsi de réduire les temps d'indisponibilité.

Ces informations sont collectées et transmises à NetIQ AppManager via un connecteur spécifique, utilisé pour la solution mettant en jeu des agents de gestion du matériel de serveur. Les informations sont ensuite transférées de NetIQ AppManager vers la console MOM, par le biais du connecteur NetIQ AppManager – MOM. Cela permet à MOM d'être utilisé comme console principale pour l'architecture Internet Data Center.

AppMetrics

Si vous développez l'architecture Internet Data Center de base pour inclure un environnement COM+/BizTalk, vous pouvez associer l'analyse du système d'exploitation et du matériel avec une analyse au niveau des objets COM+. AppMetrics for Transactions permet l'analyse des métriques COM+ clés suivantes :

• 5 composants principaux

• 5 transactions principales

• 5 méthodes principales

• % UC de package

• Mémoire de package

• Erreurs de page de package par seconde

• Transactions actives

• Transactions (démarrées, terminées, annulées)

• Durée de la transaction

• Composants actifs

• Composants (démarrés, terminés, annulés)

• Durée du composant

Grâce à Xtremesoft AppMetrics pour BizTalk, cette architecture étendue permet également d'analyser BizTalk et d'obtenir les informations suivantes :

• Vue agrégée de la ferme BizTalk Server. L'analyse et la surveillance OLAP sont utilisées pour fournir ces informations.

• Gestion détaillée des processus de gestion. Le suivi de la planification XLANG permet aux clients de gérer l'état de leurs processus de gestion.

• Alertes via SMTP, SNMP et WMI. La prise en charge de plusieurs protocoles est prête à être intégrée à MOM.

Outre ces informations, AppMetrics pour BizTalk fournit également les fonctionnalités suivantes :

• Affichage des documents suspendus. Les documents suspendus peuvent être affichés à partir d'un lien inclus dans un message électronique.

• Mise en relief des actions qui attendent trop longtemps. Cette fonctionnalité aide à garantir le respect des accords de niveau de service.

• Génération de rapports de performances de production. Ces rapports peuvent être utilisés pour rassembler des statistiques sur les performances directement à partir de la ferme BizTalk Server.

Placement des agents de gestion

Le tableau ci-dessous montre le placement de chacun des agents requis pour l'architecture Internet Data Center, y compris le placement des cartes de gestion de matériel de serveur.

Rôles des serveurs	Gestion du matériel	Operations Manager	AppManager	AppMetrics
Serveurs Web (IIS)	X	X	X
COM+/BizTalk (facultatif)	X			X
Services d'infrastructure (Active Directory, DNS, VPN, etc.)	X	X	X
Serveurs de données (SQL)	X	X
Serveurs de gestion	X	X	X

Les agents de gestion du matériel de serveur sont installés sur tous les serveurs de l'environnement Internet Data Center pour fournir des informations et des alertes spécifiques au matériel de serveur. Les agents Microsoft Operations Manager et NetIQ AppManager analysent les performances et l'état de Windows 2000 et de Microsoft IIS. Les agents Xtremesoft AppMetrics analysent les objets BizTalk, COM+ et Message Queuing (nommé également MSMQ) et leurs performances, s'ils sont inclus dans l'architecture Internet Data Center de base. Dans le réseau VLAN (réseau local virtuel) d'infrastructure, les agents Microsoft Operations Manager et NetIQ AppManager analysent le système d'exploitation et les services d'infrastructure clés, tels que DNS et Active Directory. Dans le réseau VLAN de données, les agents Microsoft Operations Manager analysent le matériel, les systèmes d'exploitation et les bases de données SQL Server 2000. Enfin, les serveurs de gestion sont eux-mêmes analysés et exécutent ainsi également des agents. Tous ces agents transmettent alors leurs informations aux serveurs de gestion et à la console MOM.

La Figure 2 montre en détails les serveurs d'analyse et d'alarme installés dans le réseau local virtuel (VLAN) de gestion et de données. Cette figure illustre comment le réseau VLAN s'intègre à l'architecture du réseau Internet Data Center et comment d'autres composants de gestion de l'architecture, tels que les serveurs de gestion à distance, le serveur de sauvegarde et les éventuels serveurs de déploiement de contenu, peuvent être incorporés dans la conception. Ces composants sont décrits plus en détails plus loin dans ce chapitre.

Figure 2. Détails du réseau VLAN de gestion et de données et vue d'ensemble du réseau Internet Data Center

Organigramme du Processus

Les organigrammes suivants illustrent le processus de mise en œuvre de l'architecture d'analyse et d'alarme. Ils peuvent être utilisés comme ressource pour détailler les points de décision impliqués dans la conception et la création de
cette architecture.

Figure 3. Organigramme du processus d'analyse et d'alarme, partie 1

Figure 4. Organigramme du processus d'analyse et d'alarme, partie 2

Figure 5.

Infrastructure d'analyse et d'alarme

L'environnement de gestion de l'architecture Internet Data Center est composé de plusieurs serveurs, aux fonctions variées. Cette section traite du placement et des fonctionnalités des serveurs MGMT01 et MGMT02, ainsi que des outils illustrés à la Figure 2 plus haut dans ce chapitre.

Pour garantir la sécurité optimale du réseau de gestion, un réseau local virtuel (VLAN) distinct est utilisé pour le réseau de gestion. Ce réseau est accessible uniquement à partir d'Internet par le biais d'un serveur de réseau privé virtuel (VPN) placé derrière un pare-feu. Si un serveur frontal est compromis, le réseau VLAN de gestion empêche les utilisateurs non autorisés d'utiliser le serveur pour accéder aux serveurs principaux via le réseau de gestion.

Chaque serveur de gestion utilise une paire de cartes réseau pour disposer de connexions réseau redondantes, au cas où une panne surviendrait. Les caractéristiques de ces serveurs sont les suivantes :

• MGMT01 est la console centrale pour tous les outils de gestion, y compris Microsoft Operations Manager, NetIQ AppManager et Xtremesoft AppMetrics. MGMT01 est configuré avec un biprocesseur et 640 Mo de RAM.

• MGMT02 exécute SQL Server 2000 et héberge toutes les bases de données de gestion pour Microsoft Operations Manager et NetIQ AppManager. MGMT02 est un serveur de base de données, qui s'appuie beaucoup sur les insertions. C'est pourquoi RAID 0+1 (répartition de fichiers sur plusieurs disques en miroir) est recommandé pour des performances optimales. Un ordinateur équipé d'un biprocesseur et de 640 Mo de RAM est également recommandé et doit disposer de suffisamment d'espace disque pour pouvoir conserver toutes les informations nécessaires et permettre des performances optimales.

• Le serveur de gestion Outils exécute Windows 2000 et est équipé de toutes les consoles de gestion pour toutes les parties de la solution d'analyse et d'alarme. Il dispose aussi de tous les kits de ressources des produits Microsoft, de tous les outils et de tous les utilitaires requis pour l'architecture Internet Data Center, y compris Microsoft Operations Manager, NetIQ AppManager, Xtremesoft AppMetrics et tout logiciel tiers destiné à être utilisé avec les cartes et les agents de gestion du matériel de serveur. Vous pouvez utiliser ce serveur de console pour gérer l'architecture Internet Data Center entière, sans accéder directement aux serveurs de gestion. Comme les consoles sont installées sur un serveur exécutant Windows 2000 Server, vous pouvez utiliser les services Terminal Server pour l'accès à distance.

Analyse du matériel et de l'infrastructure

Cette section présente les composants qu'il convient d'analyser au sein de l'architecture Internet Data Center à l'aide des agents NetIQ AppManager. Elle couvre aussi l'emploi de Microsoft Operations Manager et des autres outils prévus pour l'analyse de la technologie d'infrastructure, comme par exemple Windows 2000, Active Directory et DNS.

En utilisant les agents de gestion du matériel, vous pouvez effectuer certaines ou l'ensemble des tâches suivantes, en fonction de la mise en œuvre réalisée par le revendeur :

• Analyser l'état du ventilateur du processeur et du système.

• Déterminer si la charge de la batterie UPS est faible.

• Vérifier l'état des systèmes SCSI.

• Déterminer si des messages critiques ont été enregistrés dans les journaux des événements Windows 2000.

• Fournir des informations sur les biens, comme par exemple le numéro de série et la vitesse du processeur.

• Analyser les cartes réseau (NIC) pour rechercher des conditions de panne.

Obtenir des informations sur le matériel de serveur vous permet d'identifier les composants défaillants et les goulots d'étranglement potentiels du système et vous permet ainsi de réduire les temps d'indisponibilité. Toutefois, cette solution pour le matériel n'est qu'un seul des outils de la solution de gestion Internet Data Center. En associant Microsoft Operations Manager avec les outils NetIQ et Xtremesoft pour analyser et examiner les événements de manière proactive, la souplesse et la puissance globale du système de gestion peuvent être grandement améliorées.

Les sections suivantes contiennent des exemples, qui illustre le type d'informations que vos agents de gestion du matériel de serveur doivent être en mesure de fournir à votre solution de gestion.

Santé et restauration des serveurs

Pour maintenir la disponibilité d'un serveur, vous devez vous assurer que les systèmes fonctionnent dans des conditions environnementales étroitement contrôlées.Dans le cas contraire, les composants des systèmes connaissent un taux plus élevé de défaillances dans des conditions normales de fonctionnement.C'est pourquoi, il est important d'analyser les éléments suivants :

• Température du système. Analyse l'état de l'environnement thermique, qui est susceptible de sortir d'une fourchette acceptable en cas de panne du ventilateur système, d'ouverture du châssis de l'ordinateur ou de températures élevées dans l'environnement externe.

• État du ventilateur système.Analyse le ventilateur du système et du processeur, qui peut affecter la température du système.

• Condition de la batterie de l'onduleur.Analyse l'état de charge de la batterie de l'onduleur.

• État du redémarrage du système.Analyse les compteurs Condition et Redémarrage du serveur.

Systèmes de stockage

Les sous-systèmes de disques du serveur contiennent toutes les informations de serveur et les propriétés de configuration du système d'exploitation.Pour permettre une disponibilité maximale, il est important d'analyser les éléments suivants des systèmes de stockage :

• État des disques et des baies de disques. Analyse l'état des lecteurs et des baies de disques du système, comme par exemple les erreurs de lecture matérielles récupérées, les erreurs de recherche et les dépassements de délais de demandes de données.

• État SCSI. Analyse l'état des systèmes SCSI (Small Computer System Interface), comme par exemple les erreurs de recherche SCSI, les dépassements de délais, les erreurs de lecture, les événements antérieurs à la panne du contrôleur de baie de disques, les erreurs de réécriture sur bande, de relecture et les erreurs de bande irrémédiables.

Interface réseau

Un serveur s'avère utile dans l'architecture Internet Data Center, seulement s'il est possible d'y accéder via le réseau.C'est pourquoi, il est important d'analyser l'élément suivant :

• État NIC. Analyse la carte réseau en recherchant des paquets reçus et transmis contenant des erreurs, ainsi que des paquets ignorés.

Informations sur les biens

La capacité d'inventorier les biens au sein de l'architecture Internet Data Center est précieuse pour une large gamme d'opérations nécessaires aux rapports de gestion. Une de ces opérations consiste à générer un rapport sur les composants essentiels du système. Ces composants peuvent être conservés en prévision d'une panne, pour aider à réduire les temps d'indisponibilité.Voici quelques exemples d'informations utiles sur les biens :

• Nom de serveur

• Numéro de série

• Version de la ROM

• Type et vitesse de processeur

• Configuration de la mémoire

• Sous-systèmes de disques

• Configuration du sous-système vidéo

La capacité d'intégrer étroitement les différents produits d'analyse et d'alarme Internet Data Center est un atout majeur de la solution décrite dans ce chapitre. Il est important que vous évaluiez le niveau d'intégration que fournit votre solution de gestion globale. Lors du choix du matériel de serveur à utiliser, il convient d'évaluer les dispositifs de gestion proposés par le vendeur de serveurs et de déterminer la qualité de leur intégration dans votre solution globale.

Par exemple, les agents de gestion de serveur doivent être en mesure de signaler les conditions d'erreur à la console de gestion centrale. En outre, la capacité d'enregistrer les événements dans le journal des événements système Windows 2000 local est fortement utile, car les agents MOM lisent par défaut les journaux des événements. NetIQ fournit également des packs XMP (eXtended Management Pack) à utiliser avec MOM. Ces packs peuvent être intégrés avec du matériel de serveur de tierces parties pour déclencher des alertes en cas d'événements système importants et pour afficher des informations sur les problèmes, directement sur la console MOM, sans aucune personnalisation.

NetIQ AppManager permet de détecter les agents, les versions, le matériel, etc. Une fois ces données recueillies, AppManager peut interroger de manière intelligente les composants et capturer toutes les alertes, qui peuvent alors être transmises à MOM via un connecteur disponible dans NetIQ.

Analyse du système d'exploitation et des services d'infrastructure

Microsoft Operations Manager et NetIQ AppManager fonctionnent de pair pour fournir des informations qui dépassent de loin les statistiques fournies par les compteurs de l'Analyseur de performances de Windows 2000. Ces applications fournissent des rapports, sous forme de lots, sur les performances et les accords de niveau de service. Ces rapports sont essentiels pour le maintien des performances et de la fiabilité au sein de l'architecture Internet Data Center. Microsoft Operations Manager et NetIQ AppManager contribuent à l'analyse du système d'exploitation en fournissant les avantages suivants :

• Stockage des informations SQL Server. Ces applications utilisent SQL Server pour fournir un accès ouvert et évolutif aux données pour l'analyse des tendances à long terme et des rapports.

• Automatisation. Les applications peuvent configurer des actions déclenchées par des événements, comme par exemple le redémarrage d'un service arrêté, le redémarrage d'un service défaillant, lorsque l'utilisation de la mémoire dépasse un seuil, la suppression des répertoires temporaires, lorsque la quantité d'espace disque devient faible et la correction des entrées DNS, si les données sont corrompues.

• Réduction des coûts de prise en charge. Ce système réduit les coûts de prise en charge en affichant la santé et l'état des systèmes Windows distribués à partir d'un emplacement central. Des scripts de connaissances sous forme de lots contiennent des méthodes recommandées par l'industrie pour l'analyse de l'infrastructure.

NetIQ AppManager fournit des fonctionnalités de test et d'analyse, tandis que Microsoft Operations Manager est optimal pour la gestion des journaux des événements, des journaux de type texte, des événements WMI, des pièges SNMP de périphériques, des journaux de sécurité et du fichier NetLogon.log, issu de Active Directory.

Microsoft Operations Manager dispose de modules intégrés, qui surveillent les événements importants liés à Active Directory, au service de réplication de fichiers, à DNS, au gestionnaire de contrôle des services, à DHCP (Dynamic Host Configuration Protocol), à Proxy/PPTP, aux services Terminal Server, à VPN/RRAS et aux autres services centraux du système d'exploitation. Plusieurs milliers de règles non script surveillent les événements importants et les seuils de performance. Microsoft Operations Manager inclut un dispositif permettant d'afficher et d'imprimer l'ensemble des règles analysées pour une application ou un service central. Vous pouvez utiliser ce dispositif à partir de la console MMC Microsoft Operations Manager.

Microsoft Operations Manager et NetIQ AppManager sont utilisés pour analyser les métriques suivantes dans l'architecture Internet Data Center.

Disponibilité des services

Pour que le système d'exploitation présente des performances et une disponibilité optimales, vous devez garantir la disponibilité des services.Il est important de disposer des informations suivantes sur les services :

• Alertes générées en cas d'échec de services Windows 2000 clés.

• Alertes générées si des services Windows 2000 clés ont gelé leur exécution ou ont été automatiquement redémarrés.

• Alertes générées en cas d'échec de processus spécifiques.

Il est également important d'analyser les fonctionnalités clés suivantes, fournies par les services Windows 2000 :

• DNSConnectivity. Vérifie si un ordinateur peut se connecter au serveur DNS.

• RASStat. Rassemble des statistiques et des métriques RAS.

• NetSession. Effectue le suivi des sessions établies sur un ordinateur.

• PortHealth. Vérifie si les ports spécifiés fonctionnent correctement.

Utilisation des ressources

Pour garantir que les serveurs mettent des ressources à la disposition des demandes entrantes des services, il est important d'analyser les ressources de serveur clés, qui incluent les éléments suivants :

• TopCPUUsers. Analyse l'utilisation globale du processeur et montre le temps processeur consommé par les processus.

• TopMemoryUsers. Détecte l'utilisation de la mémoire et identifie les principaux consommateurs de mémoire.

• LogicalDiskSpace. Génère une alerte si la quantité d'espace disque disponible devient faible.

Disponibilité des serveurs

Pour garantir la disponibilité d'un serveur, il est important d'analyser les éléments suivants :

• MachineDown. Permet la vérification de la disponibilité du système et de la connexion réseau entre un système quelconque et un groupe de systèmes.

• PingMachine. Génère une alerte si une adresse IP ne répond plus à une commande ping.

Éléments essentiels

Les éléments répertoriés dans les listes suivantes sont tous des éléments essentiels (critiques) de l'infrastructure Internet Data Center.Pour garantir leur disponibilité, vous devez analyser ces éléments.

Vous devez analyser les éléments Active Directory suivants :

• TrustRelationships. Surveille si des relations d'approbation sont rompues.

• ReplicationCheckedByUSN. Vérifie que la réplication Active Directory a lieu, en analysant la valeur USN maximale sur chaque contrôleur de domaine.

• ReplicationByObject. Vérifie que la réplication Active Directory a lieu, en suivant la progression d'un petit objet d'analyse dans Active Directory tout entier.

• Authentications. Analyse le nombre d'authentifications Active Directory par seconde.

• KDCRequests. Analyse les demandes adressées au centre de distribution de clés Active Directory.

• CacheHitRate. Analyse le taux de recours au cache de la résolution de noms.

• ClientSessions. Vérifie le nombre de sessions Active Directory à partir de clients différents.

• InboundReplStat. Analyse les statistiques de la réplication Active Directory entrante.

• OutboundReplStat. Analyse les statistiques de la réplication Active Directory sortante.

• Inter-ReplTraffic. Analyse le trafic de réplication entrant et sortant sur les autres sites Active Directory.

• SyncRequest. Analyse les demandes de synchronisation Active Directory et les échecs des demandes de réplication.

• TrustEventLog. Analyse les erreurs et les événements liés aux relations d'approbation Active Directory.

Vous devez analyser les éléments ISA Server suivants :

• AlertAll. Répond à toutes les alertes générées par le serveur ISA Server et désactive au choix les alertes détectées dans la console ISA Server.

• EventLog. Analyse les entrées du journal des événements créées par le serveur ISA Server (entrées, dont la source est ISA Server dans le journal System Log).

• ProxyCacheHitRatio. Fournit le taux de demandes auxquelles le serveur proxy Web répond à l'aide de données mises en cache.

• ProxyFailedRequests. Analyse le nombre total de demandes adressées au serveur proxy Web qui ont échouées pendant l'intervalle d'analyse.

• ProxyHTTPRequests. Analyse le nombre de demandes HTTP adressées au serveur proxy Web pendant l'intervalle d'analyse.

• ProxyInetBytes. Analyse le nombre d'octets transmis par seconde entre le serveur proxy Web et les serveurs distants sur Internet.

• ProxySitesDenied. Analyse le nombre de sites Internet auxquels le serveur proxy Web a refusé l'accès pour cet intervalle.

• ProxyTotalRequests. Analyse le nombre total de demandes Internet adressées au serveur proxy Web.

• ProxyWebUsers. Analyse le nombre d'utilisateurs actuellement connectés au serveur proxy Web.

• ResourceHigh. Analyse le temps processeur ou la mémoire utilisé(e) par le service proxy WinSock et le processus Admin.

• ServiceCheck. Vérifie si des services proxy sont en cours d'exécution.

• Sessions. Analyse le nombre de sessions utilisateur sur les composants de proxy et de pare-feu de ISA Server.

Vous devez analyser les éléments d'équilibrage de charge réseau suivants :

• ConfigurationChange. Analyse les paramètres de configuration du cluster et de l'hôte d'équilibrage de la charge réseau, pour rechercher des modifications. 

• ConvergenceState. Analyse la convergence entre un cluster d'équilibrage de la charge réseau et chaque hôte.

• DefaultHostChange. Vérifie si un hôte par défaut du cluster d'équilibrage de la charge réseau a changé.

• EventLog. Analyse le journal des événements système à la recherche d'entrées créées par l'équilibrage de la charge réseau.

• MemberChange. Analyse l'appartenance d'un cluster d'équilibrage de la charge réseau pour rechercher des modifications.

• PortRuleChange. Analyse les règles de port d'un cluster d'équilibrage de la charge réseau pour rechercher des modifications.

Vous devez analyser les éléments de réseau privé virtuel (VPN) suivants :

• RASConnections. Analyse le nombre total de connexions au serveur VPN. 

• RASErrors. Détecte les erreurs dans les connexions VPN.

• RASStat. Analyse le trafic VPN en octets/s.

Analyse du réseau Web frontal

Les agents NetIQ AppManager pour IIS fournissent de nombreux rapports sur les performances et les accords de niveau de service Internet Information Server.
Ces informations sur les niveaux de service sont automatiquement intégrées dans Microsoft Operations Manager.

Les métriques suivantes sont analysées et gérées au moyen de NetIQ AppManager, au sein du réseau Web frontal de l'environnement Internet Data Center. Si les services répertoriés ci-dessous ne sont pas disponibles, l'architecture Internet Data Center ne peut pas répondre aux demandes externes des clients :

• URLConnectivity. Analyse les connexions aux URL (telles que http://..., https://… et ftp://...). Ce script de connaissances collecte également des statistiques sur l'état disponible/indisponible pour fournir des rapports sur les niveaux de service et les temps d'accès aller-retour aux URL (il convient de spécifier des seuils pour les temps de réponse souhaités). URLConnectivity prend en charge la capacité d'analyser les URL HTTPS sécurisées et permet également de spécifier un nom de serveur proxy, si nécessaire.

• URLContent. Examine le contenu des URL et recherche les modifications. Peut également faire correspondre des chaînes de type texte au contenu d'URL.

• HealthCheck. Génère immédiatement une alerte en cas d'échec de IIS ou de services associés, tels que FTP, Gopher ou News, et redémarre automatiquement le service.

• PingMachine. Génère une alerte si une commande ping ne peut plus atteindre une adresse IP ou un domaine.

• CPUHigh. Vérifie si les services IIS utilisent trop de ressources processeur.
  Un autre script de connaissances peut vérifier l'emploi de la mémoire IIS.

• PortHealth. Vérifie si un port Internet spécifique sur un hôte fonctionne toujours correctement.

• DNSConnectivity. Vérifie si un ordinateur peut se connecter au serveur DNS.

• HTTPNotFound. Signale le nombre d'erreurs NOT FOUND sur le serveur HTTP/Web.

• HTTPConnections. Analyse les connexions HTTP.

• ASPThroughput. Analyse le débit des demandes ASP.

• ASPSessionTimeout. Identifie l'état périmé de la session.

• FTPFiles. Affiche le nombre de fichiers transférés par le serveur FTP.

• NNTPServerFailures. Analyse les échecs du serveur NNTP (Network News Transfer Protocol).

Gestion des événements liés au réseau Web frontal

Microsoft Operations Manager, chargé avec le pack de gestion de Microsoft Internet Information Services, analyse les journaux des événements Windows 2000 et les journaux de type texte IIS. Le pack de gestion envoie automatiquement des alertes à la console pour les erreurs IIS et ASP enregistrées dans les journaux IIS. Les problèmes du système IIS enregistrés dans les journaux Système ou Application de Windows 2000 sont également capturés et signalés sur la console Microsoft Operations Manager, et sont éventuellement transmis à la console NetIQ AppManager.

Lorsqu'elles sont utilisées ensemble, les fonctionnalités suivantes permettent d'afficher sur une console unique toutes les informations pertinentes sur l'état de IIS :

• Gestion des événements Microsoft Operations Manager.

• Analyse de la santé des applications IIS par NetIQ AppManager.

• Connecteur NetIQ AppManager – Microsoft Operations Manager.

NetIQ AppManager et Microsoft Operations Manager fournissent tous les deux un mécanisme d'automatisation des réponses aux conditions détectées. Par exemple, le script de connaissances HealthCheck de NetIQ AppManager pour IIS peut être facilement configuré pour redémarrer tous les services qu'il trouve arrêtés. Microsoft Operations Manager fournit également cette capacité. Pour empêcher la duplication, l'architecture Internet Data Center utilise la solution la plus efficace ou, lorsque des solutions présentent une efficacité égale, elle utilise la plus simple à déployer.

Analyse du réseau VLAN d'infrastructure

Cette section présente les éléments à analyser au sein de l'environnement Internet Data Center dans le réseau VLAN d'infrastructure (COM+) en utilisant Xtremesoft AppMetrics for Transactions, version 2.0. 

L'utilisation de Xtremesoft AppMetrics for Transactions pour analyser la couche de logique d'entreprise, y compris les objets COM+ et Message Queuing, fournit les avantages suivants :

• Affichage de l'historique ou de la valeur en cours de l'efficacité transactionnelle d'une application.

• Notification en temps réel des métriques d'application qui dépassent les valeurs de test attendues.

• Rapports détaillés sur les informations d'appel de méthodes et sur la consommation de ressources au niveau des applications COM+.

Xtremesoft AppMetrics for Transactions 2.0 fournit les informations COM+ suivantes :

• Les 5 composants principaux

• Les 5 transactions principales

• Les 5 méthodes principales

• % UC de package

• Mémoire de package

• Erreurs de page de package par seconde

• Transactions actives.

• Transactions (démarrées, terminées, annulées)

• Durée de la transaction

• Composants actifs

• Composants (démarrés, terminés, annulés)

• Durée du composant

L'analyse de ces éléments permet de vous assurer que l'application qui s'exécute au sein de l'architecture Internet Data Center fonctionne de manière optimale et sans erreur. L'analyse permet également la planification des capacités et le réglage des performances de l'environnement, ce qui permet à l'architecture Internet Data Center de répondre sans interruption aux demandes des clients. 

Analyse du réseau VLAN de données et de gestion

En analysant SQL Server à l'aide de Microsoft Operations Manager et de NetIQ AppManager, vous pouvez maintenir un niveau élevé de disponibilité en résolvant tôt les problèmes. Vous devez transférer les alertes liées à SQL Server vers une équipe d'analyse, afin qu'elle les utilise pour la détection et la résolution des problèmes d'application. L'utilisation de Microsoft Operations Manager et de NetIQ AppManager dans le réseau VLAN de données et de gestion fournit deux fonctions de gestion clés :

• Analyse des performances et rapports. Les fonctionnalités de MOM et de AppManager permettent l'analyse de l'emploi des ressources SQL Server au niveau des instructions SQL elles-mêmes. Elles fournissent également des rapports sous forme de lots sur les performances et les accords de niveau de service. Comme les données de performance sont conservées dans une base de données SQL Server, il est aisé d'effectuer une analyse des tendances à long terme.

• Gestion proactive des événements. Cette fonctionnalité permet une gestion robuste des défaillances par la détection proactive des problèmes susceptibles d'affecter la disponibilité des serveurs exécutant SQL Server. En utilisant l'automatisation, vous pouvez facilement configurer des actions déclenchées par des événements, comme par exemple l'exécution automatique d'un programme correctif, lorsqu'un événement spécifique survient. MOM inclut des règles qui surveillent des centaines d'événements SQL Server. La notification automatisée pour les conditions détectées par NetIQ AppManager est intégrée dans Microsoft Operations Manager par le biais du connecteur NetIQ AppManager - Microsoft Operations Manager et des mécanismes de notification intégrés dans Microsoft Operations Manager.

NetIQ AppManager pour SQL Server et Microsoft Operations Manager analysent les éléments et événements suivants, qui sont déterminants pour les performances de SQL Server :

• ServerDown. Si SQL Server ou des services associés, tels que SQL Executive, échouent, ServerDown génère immédiatement une alerte et redémarre automatiquement le service défaillant.

• TopIOUsers. Effectue le suivi de la consommation d'E/S par les utilisateurs SQL Server et met en corrélation les E/S et l'exécution des instructions SQL Server.

• TopLockUsers. Identifie une activité de verrouillage par les utilisateurs et identifie les instructions SQL Server à l'origine du verrouillage.

• TopMemoryUsers. Analyse l'utilisation de la mémoire par les utilisateurs SQL Server et met en corrélation l'utilisation de la mémoire et l'exécution des instructions SQL Server.

• DBSpace. Analyse et génère des alertes dans l'espace disponible pour vos bases de données SQL Server.

• LogSpace. Détecte si l'espace réservé au journal SQL Server devient faible et fournit une option pour tronquer automatiquement le fichier journal des transactions.

• NearMaxConnect. Indique si les connexions disponibles s'amenuisent.

• NearMaxLocks. Vérifie si SQL Server n'a presque plus de verrous.

• ServerThroughput. Mesure des statistiques d'E/S clés, telles que le nombre de transactions par seconde.

• UserConnections. Indique qui se connecte à SQL Server et combien de connexions chaque personne utilise.

• CacheHitRatio. Analyse le cache des tampons SQL Server et génère une alerte si cela est nécessaire pour augmenter la mémoire allouée à SQL Server.

Parallèlement, le module des connaissances actives sur SQL Server de Microsoft Operations Manager analyse de nombreux compteurs de performances SQL, dont :

• SQLServer : Méthodes d'accès – Analyses complètes/s

• SQLServer : Bases de données, Base de données d'application – Croissances de journaux

• SQLServer : Bases de données, Base de données d'application – Pourcentage utilisé du journal

• SQLServer : Bases de données, Base de données d'application – Transactions/s

• SQLServer : Statistiques générales – Connexions utilisateur

• SQLServer : Verrous – Attente de verrous/s

• SQLServer : Verrous – Nombre d'interblocages/s

• SQLServer : Gestionnaire de mémoire – Demandes de mémoire en attente

L'analyse de ces éléments vous aide à garantir que les bases de données SQL qui s'exécutent au sein de l'architecture Internet Data Center fonctionnent de manière optimale, et que tout problème soit traité rapidement. Elle permet également la planification des capacités et le réglage des performances de l'environnement, permettant ainsi à Internet Data Center de fournir des services efficaces de manière continue.

Flux d'événements

Si un des événements présentés précédemment déclenche une alerte, une procédure composée de plusieurs étapes doit prendre place, avant que la console de gestion centrale (MOM) enregistre l'occurrence de l'événement et réagisse, si nécessaire. Les Figures 6 à 9 (ci-dessous) détaillent le flux d'événement de chaque application de gestion, lorsqu'elle reçoit un événement à partir de ses composants analysés sur la console MOM.

Flux d'événement Microsoft Operations Manager

La Figure 6 montre une alerte, générée sur l'un des serveurs Web IIS. L'alerte est détectée et gérée par l'agent MOM, comme illustré dans la figure.

Figure 6. Flux d'événement MOM

Les étapes parcourues par le flux d'événement MOM sont les suivantes :

1. Un événement est généré.

2. L'agent MOM capture l'événement.

3. L'agent MOM crypte les informations sur l'événement et les retransmet à DCAM via le port TCP 1270, à travers le pare-feu interne. Ces informations sont retransmises selon les règles suivies par l'agent MOM.

4. L'événement est inscrit dans la base de données MOM.

5. Une alerte s'affiche sur la console MOM.

Flux d'événement AppManager

La Figure 7 montre le flux d'un événement, de retour vers la console MOM après avoir été généré et capturé par NetIQ AppManager.

Figure 7. Flux d'événement NetIQ AppManager

Les étapes parcourues par le flux d'événement NetIQ AppManager sont les suivantes :

1. Un événement est généré sur un serveur analysé.

2. L'agent AppManager capture l'événement.

3. L'agent retransmet les informations au serveur de gestion AppManager via les ports TCP 9979, 9998 et 9999, à travers le pare-feu interne. Ces informations sont retransmises selon les règles suivies par l'agent.

4. L'événement est capturé par le serveur AppManager et est inscrit dans la base de données AppManager.

5. Le connecteur AppManager - MOM transmet les informations à MOM.

6. L'événement est inscrit dans la base de données MOM.

7. Une alerte s'affiche sur la console MOM.

Flux d'événement lié aux agents de matériel de serveur

Les événements générés par le matériel de serveur sont détectés par les agents de gestion du matériel de serveur. Ces agents peuvent être utilisés pour transmettre ces événements au système de gestion d'événements et d'alarme. La Figure 8 décrit comment les événements et les alertes générés par le matériel de serveur sont piégés par les agents de gestion de serveur, puis transmis à la console MOM centrale :

Figure 8. Flux d'événement du matériel de serveur

Les étapes parcourues par le flux d'événement du matériel de serveur sont les suivantes :

1. Une condition liée au matériel survient sur un serveur analysé.

2. L'agent de carte de gestion de serveur détecte la condition.

3. L'agent de gestion du matériel de serveur transmet les informations à l'agent NetIQ AppManager, qui est configuré pour être à l'écoute de tels événements.

4. L'agent AppManager transmet les informations au serveur de gestion AppManager via les ports TCP 9979, 9998 et 9999.

5. Les informations sont inscrites dans la base de données AppManager.

6. Le connecteur AppManager – MOM transmet les informations à MOM.

7. L'événement est inscrit dans la base de données SQL MOM.

8. Une alerte s'affiche sur la console MOM.

Flux d'événement AppMetrics

La Figure 9 décrit un événement généré par une condition d'application COM+ ou BizTalk Server. L'événement est piégé par l'application de gestion Xtremesoft AppMetrics, puis retourne à la console MOM centrale.

Figure 9. Flux d'événement AppMetrics

Les étapes détaillées de ce processus sont les suivantes :

1. Un événement est généré par une condition COM+ ou BizTalk.

2. L'agent AppMetrics détecte l'événement.

3. AppMetrics transmet les informations à l'agent NetIQ AppManager.

4. Si l'agent AppManager est configuré pour être à l'écoute de tels événements, il transmet les informations via les ports TCP 9979, 9998 et 9999 au serveur de gestion, qui inscrit alors ces informations dans la base de données NetIQ AppManager.

5. Le connecteur NetIQ AppManager – MOM transmet les informations à MOM.

6. L'événement est inscrit dans la base de données SQL MOM.

7. Une alerte s'affiche sur la console MOM.

Gestion à distance

Dans l'environnement professionnel actuel, la gestion informatique est essentielle pour la réussite d'une entreprise. Il est impératif que les administrateurs informatiques fournissent des solutions et des services informatiques centralisés, complets, pour la gestion du réseau d'une société, quels que soient l'emplacement et l'état des serveurs. Ces solutions informatiques centrales confèrent aux administrateurs la liberté de déployer des serveurs essentiels pour l'entreprise aux emplacements les plus appropriés, comme par exemple dans le data center de l'entreprise, dans des sites distants, ou dans les deux.

Grâce aux outils de gestion à distance, les administrateurs informatiques peuvent effectuer toutes les opérations de maintenance planifiées, nécessaires, ainsi que toute intervention d'urgence sur les serveurs, à partir de leurs stations de travail locales. Cela permet d'améliorer les temps de réponse et ainsi de diminuer grandement les temps d'indisponibilité.

Ressources nécessaires

Des employés appartenant aux équipes ci-dessous sont requis pour mettre en œuvre une solution de gestion à distance :

• Support Windows 2000 Server

• Administration Windows 2000

• Opérations de réseau

• Service d'assistance

• Analyse Windows 2000

• Administration d'infrastructure

• Sécurité

• Administration réseau, pour fournir les informations DNS, ainsi que d'autres informations concernant le réseau

Conditions préalables à la conception de la solution de gestion à distance

Une condition essentielle doit être prise en compte pour faciliter la gestion de l'architecture Internet Data Center : la capacité de gérer les systèmes à partir d'un emplacement distant, d'une manière sécurisée et pratique.

Organigramme du processus

L'organigramme suivant illustre comment une solution de gestion à distance doit être conçue et mise en œuvre.

Figure 10. Organigramme de conception et de mise en œuvre d'une solution de gestion à distance, partie 1

Figure 11. Organigramme de conception et de mise en œuvre d'une solution de gestion à distance, partie 2

Figure 12. Organigramme de conception et de mise en œuvre d'une solution de gestion à distance, partie 3

Blocs de conception

La solution de gestion à distance décrite dans ce chapitre utilise les services Terminal Server comme outil principal et les cartes de gestion de serveur pour l'accès aux sauvegardes.

Services Terminal Server

Les services Terminal Server de Microsoft Windows 2000 sont utilisés en mode d'administration à distance (une nouvelle fonctionnalité de Windows 2000) pour réaliser la maintenance de routine des systèmes ou effectuer des changements de configuration sur les serveurs qui sont hébergés hors site ou dans un data center sécurisé.

Cette fonctionnalité vous permet d'utiliser jusqu'à deux sessions d'administration à distance, outre la session sur la console, sans affecter les performances du serveur, ni la compatibilité des applications. Les services Terminal Server en mode d'administration à distance requièrent seulement 2 Mo de mémoire sur le serveur et aucun espace disque supplémentaire, et ils ont un impact négligeable sur l'utilisation de l'UC. Ils permettent l'accès aux outils GUI, disponibles dans les environnements Windows, la connexion au serveur sur une bande passante basse, une connexion cryptée pour les mises à niveau, la mise à jour du système et la modification de la configuration, telle que la promotion et la rétrogradation de contrôleurs de domaine.

Grâce aux services Terminal Server, vous pouvez démarrer une tâche, qui dépend de paramètres horaires ou qui prend beaucoup de temps, et vous déconnecter de la session sans arrêter la tâche. Vous pouvez retourner ultérieurement à cette session pour vérifier l'état de la tâche.

Le client des services Terminal Server fournit de la souplesse dans l'administration des serveurs de distribution. Grâce au Gestionnaire des connexions des services Terminal Server, vous pouvez créer une connexion unique à un ou plusieurs serveurs spécifiques, pour les personnes qui doivent accéder uniquement à ces serveurs. Les administrateurs responsables de la gestion de plusieurs serveurs peuvent utiliser le client des services Terminal Server ou le composant logiciel enfichable MMC (Microsoft Management Console) des services Terminal Server (disponible à la page Microsoft Terminal Services Advanced Client ) pour sélectionner un serveur dans une liste de serveurs disponibles ou entrer le nom DNS ou l'adresse IP du serveur, afin d'établir une connexion. Les services Microsoft Terminal Server représentent la base de la solution de gestion à distance.

Fonctionnalités des cartes de gestion de serveur

Les cartes de gestion de serveur utilisées dans l'architecture Internet Data Center fournissent un autre type d'administration à distance, en donnant aux administrateurs l'accès au serveur. Les cartes fournissent généralement un bureau virtuel, quel que soit l'état actuel du serveur. Si le système d'exploitation ou les services Terminal Server cessent de répondre, ou si le serveur accuse une perte de puissance, la carte de gestion de serveur doit fournir aux administrateurs la possibilité de gérer le serveur à distance, notamment de le mettre en service ou de le démarrer à partir d'un lecteur de disquettes virtuel. L'accès à ces cartes est assuré via une puce Ethernet intégrée (10/100Mbps). L'architecture Internet Data Center utilise ces solutions matérielles parallèlement aux services Terminal Server en raison de leur capacité à fournir un accès distant aux serveurs avant le démarrage du système d'exploitation, voire même avant son installation.

Détails des éléments à prendre en compte pour la gestion à distance

Avant de concevoir et de mettre en œuvre la solution de gestion à distance, vous devez passer en revue les éléments à prendre en compte pour la gestion à distance. Ces éléments sont les suivants :

• Instructions Microsoft Operations Framework (MOF). Consultez les méthodes recommandées et les conseils fournis par MOF. Ces instructions sont un composant nécessaire à l'établissement de la fiabilité, de la disponibilité et de la facilité de gestion du système de production.

• Processus de gestion actuels pour les systèmes existants. Revoyez le processus de gestion actuel des environnements existants, ainsi que les rôles et les compétences requis pour la maintenance de ces environnements.

• Conditions de sécurité pour votre environnement. Identifiez les limites techniques et organisationnelles qui affectent la sécurité de la solution. Celles-ci incluent notamment :

  • les problèmes liés à la configuration de serveurs Web frontaux (faisant face à Internet) à l'aide d'outils de gestion à distance ;

  • les applications qui ne fonctionnent pas correctement, lorsqu'elles sont installées et/ou configurées à partir d'une session de gestion à distance ;

  • les limites pour certains types de trafic dans l'environnement, comme par exemple le port 3389 pour les services Terminal Server ;

  • les stratégies organisationnelles et opérationnelles concernant l'utilisation de l'accès à distance pour gérer les serveurs.

• Serveurs à gérer. Dans les environnements relativement grands, les serveurs qui ne stockent pas de données uniques ou ne fournissent pas de service unique sont souvent considérés comme aisément remplaçables et ne justifient pas l'utilisation de certains outils de gestion à distance ou de tous ces outils. En raison de la nature de ces derniers, il est important de prendre en compte les problèmes de sécurité, lors de la détermination des serveurs à configurer avec un accès de gestion à distance.

• Composants et applications à gérer. Après avoir identifié les serveurs qui seront analysés, choisissez les types d'activités qui seront autorisées via l'administration à distance.

• Conditions futures. Identifiez les nouvelles applications, le nouveau matériel ou les autres composants, que vous envisagez d'ajouter à votre solution de gestion à distance. Définissez l'impact de ces futurs éléments sur la solution de gestion à distance.

Conception de la solution de gestion à distance

Une fois que vous avez passé en revue les points requis par la gestion à distance, l'étape suivante consiste à mener une analyse détaillée des options des composants de gestion à distance, en tenant compte des recommandations fournies dans les guides des opérations MOF.

Identification des outils disponibles pour la gestion à distance

Différents outils fournissent les fonctionnalités de gestion à distance, y compris des outils de ligne de commande, tels que Telnet, et des outils de script, tels que Windows Scripting Host. Toutefois, beaucoup de ces outils ne sont pas faciles à manipuler et requièrent l'utilisation de commandes démodées.

Une solution de gestion à distance qui fournit à l'administrateur l'accès aux outils GUI Windows connaîtra une acceptation beaucoup plus large. Dans le passé, les organisations utilisaient des applications tierces pour fournir un contrôle distant sur un serveur qui devait être géré à distance. Le chargement et l'exécution de tels produits affectent de manière significative les ressources du serveur et introduisent un risque d'échec des applications, si des fichiers nécessaires sont écrasés lorsque de nouvelles applications sont installées sur le serveur. Pour leur part, les services Terminal Server en mode d'administration à distance fournissent aux utilisateurs l'accès à tous les outils GUI inclus dans Windows 2000, avec un léger impact sur les ressources du serveur. Comme ils sont intégrés au système d'exploitation Windows 2000, les services Terminal Server en mode d'administration à distance utilisent la sécurité Windows 2000 et ne requièrent pas de licence supplémentaire.

Encore peu de temps auparavant, aucune solution ne répondait à la nécessité de pouvoir gérer le serveur, quel que soit son état. Si un serveur était accidentellement arrêté, si une disquette se trouvait dans le lecteur au redémarrage du serveur ou si le système d'exploitation gelait son exécution, l'administrateur devait administrer directement l'ordinateur. Les cartes de gestion de serveur permettent aux administrateurs de se connecter au serveur via une connexion Ethernet. Ils peuvent alors réaliser différentes tâches et peuvent afficher la console, quel que soit l'état du système d'exploitation.

Sélection des outils de gestion à distance appropriés

L'étape suivante de conception d'une solution consiste à examiner les fonctionnalités et l'accessibilité des composants de gestion à distance identifiés dans la section précédente, et à déterminer quels outils répondent le mieux aux conditions de gestion à distance de l'organisation.

La solution de gestion à distance de l'architecture Internet Data Center utilise les services Windows 2000 Terminal Server en mode d'administration à distance, car ils fournissent un accès rapide et fiable à Windows 2000, utilisent un temps système réduit et sont parfaitement appropriés à une utilisation sur des liaisons lentes. La carte de gestion de serveur est utilisée pour l'accès auxiliaire au serveur lorsque les services Terminal Server ne sont pas disponibles.

Détermination des personnes qui accèderont aux serveurs

Dans la plupart des environnements, il existe une distinction entre ceux qui administrent les serveurs d'application et ceux qui administrent le service Microsoft Active Directory. Il est important de définir clairement les personnes responsables de la maintenance de chaque type de serveur inclus dans la solution, c'est-à-dire des personnes qui administreront les serveurs Web, les bases de données et les opérations de sauvegarde et de restauration. Souvent, ces rôles se chevauchent, avec certains utilisateurs ayant accès à plusieurs types d'applications, qui possèdent également souvent des privilèges d'administration de Microsoft Active Directory. Toutefois, la méthode recommandée consiste à définir clairement qui est responsable de la gestion d'un type de serveur et qui peut accéder à distance aux serveurs.

La solution de gestion à distance de l'architecture Internet Data Center inclut un groupe global de domaine distinct, nommé Administration à distance, destiné à la gestion à distance des serveurs, sans que ces administrateurs aient le contrôle total sur le domaine Active Directory. Ce groupe dispose d'un accès administratif à tous les serveurs de l'environnement.

En outre, un nouveau compte de domaine, nommé TaskAdmin, est créé spécifiquement pour terminer les tâches longues, une fois la session déconnectée. Le compte TaskAdmin est configuré pour ne pas réinitialiser une session interrompue ou déconnectée. Le paramètre par défaut de réinitialisation d'une session interrompue est utilisé pour tous les autres comptes, car les services Terminal Server en mode d'administration à distance sont limités à deux utilisateurs. Le compte TaskAdmin est membre du groupe Administration à distance.

Choix de la manière d'analyser l'accès aux serveurs

Dans les environnements de grande taille où plusieurs utilisateurs ont la possibilité de gérer des serveurs, vous devrez peut-être fournir un certain niveau d'analyse des accès pour retracer les actions entreprises. Il convient d'équilibrer le fait de savoir qui accède aux serveurs et quelles actions ont été effectuées avec la conservation des ressources de l'environnement. Vous devez choisir quel degré d'enregistrement dans les journaux est nécessaire à l'environnement. Les journaux sur le matériel de réseau sont-ils suffisants ou faut-il ajouter des enregistrements côté serveur ? Les capacités d'enregistrement dans les journaux peuvent aussi être activées sur les cartes de gestion à distance. Quels types d'actions faut-il analyser ?

Après avoir déterminé le niveau d'analyse requis, vous devez configurer un processus pour passer en revue les journaux. Quand les journaux seront-ils vérifiés ? Qui sera responsable de la vérification de ces journaux et de l'identification des problèmes ? Combien de temps les journaux seront-ils conservés ?

Les réponses à ces questions diffèrent pour chaque environnement et dépendent de la sécurité en cours dans l'organisation et des limites de traitement.

Détermination de la configuration de sécurité optimale

Cette section traite des fonctionnalités de sécurité des services Windows Terminal Server et des cartes de gestion de serveur, et décrit leur utilisation dans l'architecture Internet Data Center.

Services Windows Terminal Server

Les services Terminal Server sont installés sur chaque ordinateur de l'environnement au cours de l'installation et de la configuration. Avant la fabrication, les services Terminal Server sont supprimés des serveurs IIS (Internet Information Services) accessibles à partir d'Internet. Comme ces ordinateurs sont considérés comme aisément remplaçables, les services Terminal Server ne sont pas considérés nécessaires ; ces ordinateurs sont remplacés par un clone simple à créer et sont corrigés hors connexion. Si votre organisation a besoin d'activer les services Terminal Server sur les serveurs IIS Web frontaux, il est recommandé d'associer les services Terminal Server avec la carte réseau (NIC) interne uniquement.

Les paramètres par défaut pour le cryptage des services Terminal Server correspondent à l'hypothèse que l'accès aux serveurs s'effectue à partir d'une connexion au réseau local (LAN). Si l'accès doit être fourni aux serveurs via les services Terminal Server, à partir d'un emplacement situé hors de la connexion LAN sécurisée, il est recommandé de spécifier le niveau de cryptage sur "élevé", ce qui permet d'assurer un cryptage sur 128 bits. Le serveur de la console de gestion et tous les serveurs de l'environnement doivent utiliser le même niveau de cryptage des services Terminal Server, de sorte que plusieurs serveurs n'aient pas à fournir le logiciel d'installation du client des services Terminal Server.

Cartes de gestion de serveur

Dans l'architecture Internet Data Center, les cartes de gestion de serveur sont configurées sur leur propre réseau local virtuel (VLAN 14). Ce réseau ne peut pas router vers un autre VLAN, à l'exceptiondu VLAN de gestion (en utilisant des listes de contrôle d'accès sur le commutateur pour contrôler quels sous-réseaux peuvent accéder au VLAN des cartes). Cela garantit que le pare-feu n'a pas à ouvrir de ports supplémentaires pour fournir l'accès aux cartes.

Le nom d'hôte par défaut, le nom d'administrateur et le mot de passe d'administrateur sont tous changés par rapport aux valeurs par défaut. Le nom d'hôte de chaque carte est remplacé par nom_d'hôte_d'ordinateurRMan (par exemple, le nom d'hôte de la carte de gestion de serveur pour IIS01 est IIS01RMan). Les mêmes valeurs de nom et de mot de passe d'administrateur sont définies pour toutes les cartes. La solution Internet Data Center requiert un mot de passe fort, qui associe des lettres minuscules et majuscules avec des chiffres ou des caractères spéciaux. Cette condition ne tient pas à la carte elle-même, mais correspond à une méthode recommandée.

Détermination de la manière d'accéder au réseau de gestion à distance

Une fois la conception théorique de la solution de gestion à distance terminée, vous devez décider de la manière dont les utilisateurs accèderont au réseau de gestion à distance. Pour des raisons de sécurité, les serveurs d'infrastructure et de données ne sont pas connectés à Internet ; vous devez donc fournir l'accès à ces ordinateurs via une connexion sécurisée.

La solution Internet Data Center utilise un réseau privé virtuel (VPN) à cet effet (voir la Figure 2 dans la section "Conception de la solution d'analyse et d'alarme" plus haut dans ce chapitre). Un administrateur situé hors du data center établit une connexion VPN avec un serveur situé dans le dispositif d'hébergement. Une fois l'administrateur connecté au serveur VPN et authentifié par Active Directory, il a accès au serveur de la console de gestion. Ce serveur est configuré avec le client des services Terminal Server pour pouvoir accéder aux serveurs via les services Terminal Server, et avec Internet Explorer pour pouvoir accéder aux cartes de gestion de serveur.

Planification, déploiement et test des composants de gestion à distance

La solution de gestion à distance d'Internet Data Center utilise les composants suivants :

• les services Terminal Server de Microsoft Windows 2000 en mode d'administration à distance ;

• des cartes de gestion de serveur pour certaines actions, telles que la mise en/hors tension et le démarrage à distance ;

• un ensemble de serveurs VPN pour la connexion à distance via Internet ;

• un ensemble de pare-feu ;

• un ensemble de routeurs ISP.

Remarque : La Figure 2, dans la section "Conception de la solution d'analyse et d'alarme" plus haut dans ce chapitre, montre l'emplacement des composants de la solution de gestion à distance.

Ces composants permettent d'utiliser Internet pour accéder au serveur Internet Data Center à partir d'un emplacement distant. Après la connexion au serveur de la console de gestion par le biais du routeur ISP, du pare-feu et du serveur VPN (les deux dernières étapes incluent des vérifications des informations d'identification pour la sécurité), il est possible d'accéder aux serveurs Internet Data Center d'infrastructure et de base de données par le biais du client des services Terminal Server, installé sur le serveur de la console de gestion.

Lorsqu'un administrateur est connecté au serveur de la console de gestion dans le cadre d'une session PPTP cryptée (c'est-à-dire, via le réseau VPN), il peut se connecter aux serveurs et utiliser l'Observateur d'événements dans une fenêtre de la console MMC (Microsoft Management Console) pour afficher les journaux des événements système, de sécurité et d'application de chaque serveur.

Au cours de la routine d'accès du serveur de la console de gestion, il convient de consulter le logiciel d'analyse pour rechercher les avertissements et les erreurs non critiques, qui n'ont pas généré de messages d'erreur.

Pour mettre en œuvre la maintenance et les mises à niveau approuvées, à l'aide des outils de gestion Windows standard, le client des services Terminal Server installé sur le serveur de la console de gestion est utilisé. Les administrateurs doivent utiliser l'interface des services Terminal Server pour réaliser toutes les tâches, y compris l'arrêt et le redémarrage des serveurs.

Les services Terminal Server sont utilisés comme interface principale, lorsque l'accès de la console aux serveurs est nécessaire ; les problèmes de performances rendent difficile l'exécution de toute tâche complexe à l'aide de la carte de gestion de serveur. Les services Terminal Server sont généralement préférés, car une session des services Terminal Server peut être déconnectée, alors qu'une tâche continue de s'exécuter sur le serveur.

La carte de gestion de serveur peut être utilisée comme méthode de sauvegarde pour accéder à un serveur dont le système d'exploitation devient instable ou qui est mis hors tension, suite à une coupure de courant ou à un arrêt inapproprié. La carte de gestion de serveur peut aussi être utilisée par un administrateur qui a besoin de voir l'analyseur pendant le démarrage du serveur (par exemple, lors de la recherche des erreurs de démarrage ou de la restauration du démarrage de Windows 2000).

Méthodes recommandées d'administration à distance

Pour garantir le succès de la solution de gestion à distance, les concepteurs et les administrateurs doivent suivre les méthodes recommandées d'administration
à distance.

Sécurisation de l'environnement

Lors de la mise en œuvre d'une solution de gestion à distance, l'environnement peut devenir vulnérable. Pour mieux sécuriser l'environnement, l'administrateur peut effectuer les tâches suivantes :

• Définir des mots de passe forts sur la carte de gestion de serveur et les comptes locaux Administrateurs et Administrateurs de domaine.

• Modifier les noms de compte par défaut sur les cartes de gestion de serveur et les comptes locaux Administrateurs et Administrateurs de domaine.

• Configurer des verrous de compte.

• Activer l'enregistrement dans le journal pour les cartes de gestion de serveur et examiner les journaux pour s'assurer qu'il n'y a eu aucune tentative non autorisée d'accès aux cartes.

• Désactiver les comptes, services et protocoles inutiles.

• Ouvrir uniquement les ports nécessaires.

Si votre organisation a besoin des services Terminal Server pour effectuer la maintenance des serveurs dans la ferme de serveurs IIS, il est fortement recommandé d'installer une carte réseau supplémentaire sur chaque serveur. Ces cartes réseau doivent être configurées avec des informations IP statiques et doivent résider sur un réseau VLAN distinct. Pour ces serveurs Web frontaux, seule la seconde carte réseau doit être accessible par le biais des services Terminal Server.

Coordination des tâches d'administration à distance avec d'autres administrateurs

L'administration à distance à l'aide des services Terminal Server de Windows 2000 permet jusqu'à deux sessions utilisateur simultanées avec un certain degré de collaboration entre-elles, mais elle n'a pas été conçue comme système multi-utilisateur. Les administrateurs doivent coordonner leurs activités pour garantir qu'une session est disponible. Une manière d'empêcher que plusieurs utilisateurs tentent de mettre en œuvre des modifications au même moment consiste à planifier toutes les tâches de maintenance sur le serveur et à les attribuer à des personnes spécifiques.

Prévention de la corruption des données et des programmes dans le cadre de l'administration à distance

Lorsque les services Terminal Server de Windows 2000 sont installés en tant que serveur d'application, ils présentent des conditions d'installation spéciales pour les applications pour garantir leur exécution correcte dans un environnement multi-utilisateur. Lorsque les services Terminal Server de Windows 2000 sont installés pour l'administration à distance, ils ne présentent pas ces conditions d'installation spéciales et les applications installées sur le serveur ne sont pas configurées pour être simultanément utilisées par plusieurs utilisateurs. Cette situation peut conduire à la corruption de données ou de programmes. Il n'est donc pas recommandé d'utiliser les services Terminal Server Windows 2000 en mode d'administration à distance en tant que serveur d'application.

Configuration des sessions Terminal Server pour se déconnecter en cas d'interruption

Lorsqu'un serveur est géré par le biais d'une connexion non fiable, le paramètre par défaut "Déconnecter en cas d'interruption" peut empêcher la fin des processus en cours, si la session est perdue. Une fois la session déconnectée, un administrateur peut la reconnecter ultérieurement et confirmer que les processus sont finis.

Configuration de délais de déconnexion et de réinitialisation

Bien qu'il soit important de se déconnecter d'une session et de permettre à tous les processus de continuer à s'exécuter, il est également important de réinitialiser éventuellement les sessions déconnectées, en raison de la limite de deux utilisateurs, imposée par les services Terminal Server en mode d'administration à distance. Lors de la configuration des délais, il est essentiel de laisser suffisamment de temps pour terminer les tâches qui s'exécutent encore dans une session déconnectée. Pour empêcher la déconnexion prématurée d'une session, vous devez utiliser un compte d'administrateur partagé pour effectuer les tâches système, et modifier la valeur du délai dans la boîte de dialogue Propriétés du compte d'utilisateur de l'administrateur partagé.

Déploiement du contenu à l'aide de Microsoft Application Center

Cette section décrit l'architecture de gestion et de déploiement de contenu et le rôle de Microsoft Application Center dans l'architecture Internet Data Center. Cette solution est conçue pour être mise en œuvre comme un ensemble de composants additionnels à intégrer à l'architecture de base décrite au Chapitre 2, "Conception de l'infrastructure réseau", Chapitre 3, "Conception de pare-feu" et Chapitre 4, "Infrastructure de sécurité". Les rubriques couvertes incluent le placement, l'accessibilité et la sécurité des serveurs, ainsi que le processus de mise en œuvre de la gestion de contenu sur le réseau Web frontal, dans l'infrastructure et sur les réseaux VLAN de données.

Cette section vous guide dans la mise en œuvre d'un système de déploiement de contenu pour un environnement à un seul site. La présentation ne couvre pas la mise en miroir de sites entre plusieurs emplacements, ni le déploiement de contenu sur un réseau étendu (WAN).

Gestion de contenu, comme définie par MOF

La gestion de contenu, comme définie par MOF (Microsoft Operations Framework), est un ensemble de processus permettant la coordination, l'autorisation et la communication des modifications. Ces processus garantissent que les personnes appropriées sont informées d'une modification apportée à l'infrastructure ou aux services informatiques, et qu'elles l'approuvent toutes.

La gestion de contenu requiert une communication entre ceux qui effectuent la modification du contenu et ceux qui sont affectés par cette modification. Cette communication doit indiquer la manière dont cette modification affecte les services et doit établir le calendrier des modifications.

La gestion de contenu offre les avantages suivants :

• Elle offre aux chefs d'entreprises un contrôle sur les priorités des services informatiques.

• Elle protège les services existants et introduit en toute sécurité les nouveaux services.

• Elle augmente la disponibilité et l'efficacité des services en réduisant le nombre de modifications inutiles et en garantissant que les modifications des applications et de l'infrastructure ne génèreront aucun problème de service.

Mise en œuvre de la gestion de contenu

La gestion de contenu garantit que toutes les modifications sont représentées de manière précise dans l'espace de stockage de configuration et dans l'infrastructure informatique. Pour maintenir la fiabilité de l'environnement informatique d'une entreprise, il est nécessaire de suivre un processus ordonné de validation et d'acceptation des modifications. Le processus de gestion de contenu implique la série d'actions suivante :

1. Inscrire et définir les modifications nécessaires.

2. Valider la modification—coût, ressource, besoins professionnels, techniques, risques et mécanisme de restauration.

3. Planifier la modification.

4. Communiquer les informations sur la modification, les plans de progression et l'accord pour une modification.

5. Établir l'approbation de la modification.

6. Appliquer la modification.

7. Enregistrer la réalisation de la modification.

8. Examiner l'impact ou les résultats de la modification.

Autres considérations liées à la gestion de contenu

Les points suivants sont aussi des facteurs importants dans un système de gestion de contenu.

Adhésion au processus de gestion de contenu

Tous les employés (du service informatique et des autres services) doivent comprendre le processus de gestion de contenu, ainsi que leur rôle et leurs responsabilités au sein de ce processus.

Informations sur les outils et les systèmes de prise en charge de la gestion de contenu

La mise en œuvre d'un système de gestion de contenu varie d'une organisation à une autre. Il peut être donné à un rôle plus d'importance dans un environnement que dans un autre. La terminologie peut varier entre les environnements. Toutefois, les informations qui doivent être associées à chaque modification sont les mêmes pour toutes les organisations. 

Les systèmes et les applications (outils) que vous utilisez dans votre solution doivent prendre en charge les conditions de gestion de contenu suivantes :

• Communication, coordination et planification complètes

• Modifications automatisées, déclenchées par les outils de gestion de contenu

• Validation automatisée des modifications techniques

• Intégration avec l'espace de stockage de configuration

• Synchronisation automatisée des autorisations

• Dispositifs d'analyse et de signalisation des modifications

Le niveau de contrôle, les risques et les investissements varient selon les besoins et les priorités de chaque organisation. En conséquence, il convient d'évaluer pour chaque organisation les éléments requis par le système et les applications. Pour plus d'informations sur les processus de gestion de contenu MOF, visitez la page Better Manage Your IT Systems with the Microsoft Operations Framework .

Éléments requis par la gestion de contenu

Les systèmes de gestion de contenu pour les applications Web doivent être développés avec des objectifs spécifiques à l'esprit. Dans l'architecture Internet Data Center, il est important de gérer les modifications d'une application .NET et de les déployer avec le minimum d'efforts.

La solution doit présenter les caractéristiques indiquées ci-après.

• Elle doit utiliser une installation à base de scripts ou de packages.

• Elle doit pouvoir effectuer une nouvelle installation ou une mise à niveau.

• Elle doit pouvoir effectuer des installations répétées avec quelques configurations spécifiques de serveur.

• Elle doit pouvoir répliquer une image de serveur automatiquement sur de nombreux serveurs.

• Elle doit pouvoir tester le succès d'une installation.

• Elle doit effectuer le suivi de l'historique d'installation et de code base (avec des numéros de révision, entre autres moyens).

• Elle doit pouvoir restaurer un niveau de code antérieur.

• Sa disponibilité doit connaître des impacts minimaux.

• Elle doit utiliser un mécanisme d'enregistrement dans le journal pour les erreurs piégées.

Organigramme du Processus

L'organigramme suivant illustre le processus de conception et de mise en œuvre de la gestion de contenu.

Figure 13. Conception et mise en œuvre de la gestion de contenu

Architecture de gestion de contenu

La solution de gestion de contenu fait partie intégrante de l'architecture Internet Data Center. La Figure 14 offre une vue d'ensemble de l'infrastructure Internet Data Center, mettant en évidence la position des serveurs intermédiaires utilisés dans le processus de gestion de contenu.

Figure 14. Internet Data Center - Infrastructure de la gestion de contenu

L'infrastructure est un environnement d'applications à plusieurs niveaux, hautement complexe et distribué. Le schéma de l'infrastructure illustre une mise en œuvre de site unique ; le schéma serait encore plus complexe pour une mise en œuvre avec plusieurs sites en miroir dans des emplacements dispersés géographiquement.

Conception technique de la gestion de contenu

Cette section décrit la conception et la mise en œuvre de la solution de gestion de contenu au sein de l'environnement Internet Data Center.

Placement des serveurs

Dans l'environnement Internet Data Center, les serveurs intermédiaires sont placés à distance des réseaux VLAN Web frontaux. Cette configuration offre une sécurité aux serveurs intermédiaires et protège la copie principale du code utilisé pour la distribution, qui réside sur les serveurs intermédiaires. Le niveau le plus élevé de sécurité est requis pour empêcher les pirates informatiques d'accéder à un serveur intermédiaire, de changer le code et de déployer les modifications sur l'ensemble du site.

Un mécanisme de test indépendant peut être mis en place pour les nouvelles applications, avant leur diffusion dans l'environnement de production. L'ajout d'un cluster de test sur le réseau Web frontal permet de tester un site à partir d'une source externe. De cette manière, un site peut être mis en miroir et utilisé, alors que le site de production est en cours de mise à jour.

Comme illustré à la Figure 6, STG01 est le serveur intermédiaire pour le réseau Web frontal et est placé sur le réseau VLAN d'infrastructure, aux côtés de STG02 et des serveurs d'application. STG03, lui, est placé sur le réseau VLAN de données et de gestion, aux côtés des serveurs de base de données.

Comme alternative, STG01 peut être placé sur le réseau Web frontal, et non pas sur le réseau VLAN d'infrastructure. Dans ce cas, il peut être utilisé pour le mécanisme de test de la nouvelle application à la place du cluster de test, mais cette option offre une sécurité plus faible.

Sécurité des serveurs

Le placement de STG01 dans le réseau VLAN d'infrastructure affecte la sécurité. En conséquence, des ports doivent être ouverts pour permettre de transmettre le contenu à partir du serveur intermédiaire vers les serveurs de production sur le réseau Web frontal.

Les fonctionnalités intégrées de Microsoft Application Center 2000 permettent de déployer le contenu à partir du serveur intermédiaire, STG01, par le biais du pare-feu, vers les serveurs de production, via les ports TCP 4243 et 4244. Lorsque les mécanismes de synchronisation et de déploiement de Microsoft Application Center 2000 sont utilisés, ces ports doivent être ouverts uniquement à partir du serveur intermédiaire vers les clusters de production Application Center 2000 au sein du réseau Web frontal. C'est le serveur intermédiaire qui déclenche le déploiement des applications Web sur les clusters de production.

Placer STG01 sur le réseau VLAN d'infrastructure présente l'avantage supplémentaire de permettre la sauvegarde sécurisée du contenu et des archives du serveur. L'enregistrement de tous les fichiers d'installation de STG01 et STG02 sur STG02 peut également simplifier le processus de sauvegarde, qui permettra ensuite de sauvegarder un emplacement unique pour les deux serveurs intermédiaires au sein de la zone sécurisée du réseau de gestion.

Compte de serveur

Des serveurs intermédiaires distincts sont utilisés pour le réseau Web frontal (IIS01 et IIS03) et le réseau VLAN d'infrastructure. Cela peut être étendu à deux serveurs intermédiaires pour chaque réseau.

Grâce à Application Center 2000, le serveur intermédiaire Web (IIS01), par exemple, peut disposer d'un autre serveur dans son cluster (IIS02). Le second serveur obtient tous ses paramètres de configuration du premier serveur, mais peut être configuré pour ne pas être synchronisé avec le premier serveur. Il est ainsi possible d'effectuer des mises à jour sur un des serveurs intermédiaires pour le Web, sans qu'elles soient synchronisées sur l'autre serveur intermédiaire. Si, après le déploiement du contenu à partir du serveur intermédiaire mis à jour, vous remarquez que les mises à jour n'ont pas fonctionné comme prévu, vous pouvez effectuer immédiatement une restauration du code antérieur à partir du serveur intermédiaire qui n'a pas été mis à jour. La Figure 15 montre le fonctionnement de ce processus :

Figure 15. Processus de déploiement d'une application Web

Analyse des serveurs et résolution des problèmes

Il est essentiel que les sites Web inscrits dans l'architecture Internet Data Center et l'infrastructure sous-jacente soient analysés pour détecter les performances optimales et les problèmes généraux.

Microsoft Operations Manager et NetIQ AppManager sont utilisés pour analyser et résoudre les problèmes de cet environnement. Toutefois, Application Center 2000 peut également être utilisé dans cet objectif, lorsque l'option Enregistrement des événements et des performances est installée. Ce logiciel permet d'analyser l'état général des clusters, la configuration de l'équilibrage de la charge réseau, l'état des sites Web et de différents services, au niveau des clusters et des serveurs. Cela inclut tous les serveurs Web et les serveurs d'application qui sont utilisés dans l'architecture Internet Data Center.

Configuration de l'équilibrage de la charge des serveurs

La configuration de l'équilibrage de la charge est un autre facteur à prendre en compte dans la mise en œuvre d'un site à haute disponibilité. Il doit être possible d'effectuer aisément des modifications de configuration sur les clusters Web et d'ajouter ou de supprimer des serveurs à partir de l'équilibrage de la charge, selon l'importance du trafic sur un site particulier.

Application Center 2000 permet ce développement de la configuration et des sites au sein de sa propre interface. Le logiciel est intégré avec l'équilibrage de la charge réseau Microsoft et éventuellement avec Component Load Balancing (CLB) pour fournir un mécanisme permettant d'installer et de configurer aisément l'équilibrage de la charge des serveurs. L'utilisation de Microsoft Application Center 2000 parallèlement à l'analyse intégrée permet le développement des sites dynamiques de script, lorsque la charge du site augmente.

Une intégration restreinte avec des logiciels d'équilibrage de charge tiers est également fournie, pour le cas où vous n'utiliseriez pas l'équilibrage de la charge réseau Microsoft.

Processus d'introduction de la gestion de contenu

La Figure 16 illustre l'infrastructure globale de gestion de contenu.

Figure 16. Schéma des applications de gestion de contenu

Le processus de gestion de contenu est similaire pour les trois couches. Chaque couche possède une zone de développement/test, une zone intermédiaire et une zone de production. En général, des zones distinctes sont utilisées pour le déploiement des applications. La zone de développement/test est habituellement située sur le réseau d'entreprise, car le site de production est placé dans un data center.

La procédure ci-dessous résume le processus de gestion de contenu global (notez que certaines étapes décrivent le processus de mise en œuvre et n'impliquent donc pas de choix de conception spécifique) :

1. Le processus de développement/test crée une application, qui peut inclure un site Web, une application COM+ ou une base de données SQL.

2. Une fois l'application testée, elle est convertie en un ensemble de fichiers d'installation à envoyer aux serveurs intermédiaires.

3. L'état actuel du serveur intermédiaire est sauvegardé à l'aide des stratégies de sauvegarde décrites à la section "Conception de la solution de sauvegarde" plus loin dans ce chapitre

4. Le responsable de la mise en œuvre des modifications copie les fichiers d'installation dans une structure de répertoires sur le serveur. Chaque dossier de l'espace de stockage d'installation est nommé après la révision du code copié dans le dossier. Par exemple, un dossier nommé WebSiteRev1 peut contenir les fichiers d'installation de la première version du site Web. Il est recommandé de placer tous ces fichiers dans la partition D:\ et d'inclure ces fichiers dans la solution de sauvegarde.

5. Le responsable de la mise en œuvre des modifications exécute les fichiers d'installation pour créer l'application testée sur le serveur intermédiaire.

6. Si le serveur intermédiaire appartient au réseau Web frontal ou au réseau VLAN d'infrastructure, le responsable de la mise en œuvre des modifications configure Microsoft Application Center 2000 de manière à reconnaître l'application nouvellement installée ou mise à jour.

7. Si le serveur intermédiaire appartient au réseau VLAN de données, le responsable de la mise en œuvre des modifications installe et teste l'application.

8. Une fois le serveur intermédiaire configuré et testé, le responsable de la mise en œuvre des modifications déploie l'application en production, dans une période d'utilisation minimale des sites.

9. Le responsable de la mise en œuvre des modifications teste les serveurs de production.

10. Le responsable de la mise en œuvre des modifications indique à la personne désignée de sauvegarder tous les serveurs dans le cadre du plan de restauration d'urgence.

Les sections suivantes présentent tous les environnements pour tous les réseaux, en mettant l'accent sur les zones intermédiaire et de production. En particulier, les sections présentent la manière dont une application est déployée à partir de la zone de développement/test vers la zone de production.

Serveurs Web frontaux (IIS)

Cette section présente les caractéristiques de la gestion des modifications sur les serveurs Web frontaux et décrit les décisions à prendre pour chaque processus.

Configuration des serveurs Web

La zone intermédiaire est composée d'un serveur équipé de Microsoft Application Center 2000. Ce serveur est configuré comme contrôleur de cluster dans son propre cluster indépendant.

Les fermes de serveurs Web (clusters Web) sont composées de plusieurs serveurs (voir Figure 17). Tous ces serveurs sont équipés de Microsoft Application Center 2000. Le premier serveur, IIS01, est configuré comme contrôleur de cluster du premier cluster Web. IIS03 est configuré comme contrôleur de cluster du second cluster Web. En cas d'échec d'un des contrôleurs de cluster, tout membre du même cluster peut être promu manuellement contrôleur de cluster.

Figure 17. Ferme de serveurs Microsoft IIS (cluster Web)

Environnement de développement/test

Le premier élément requis pour le succès d'une modification est un code base clair et concis. Si un développeur soumet 100 fichiers de script à exécuter manuellement à partir d'une invite de commande, les probabilités d'erreur seront grandes.
Au contraire, si un fichier de commande exécutant automatiquement les scripts contrôle la même installation, les chances d'erreur seront minimes. Le succès d'une modification requiert un code capable d'être exécuté facilement plusieurs fois par différentes personnes et de retourner des résultats similaires.

Pour installer le composant Web de l'application, un produit de conditionnement comme InstallShield peut être utilisé. Si InstallShield n'est pas utilisé, un mécanisme de contrôle doit être utilisé pour créer et remplir les répertoires physiques et virtuels requis par l'application.

Environnement intermédiaire

Pour déployer les modifications, des projets de déploiement sont utilisés, qui mettent en jeu des serveurs intermédiaires et des serveurs terminaux. Un serveur intermédiaire reçoit le contenu à partir des auteurs par le biais d'autres serveurs, tels que des serveurs HTTP ou FTP d'intranet. Le serveur terminal reçoit le contenu à partir du serveur intermédiaire. Il reçoit les demandes de pages Web des clients et y répond.

Configuration des serveurs intermédiaires Web

La zone intermédiaire des serveurs Web frontaux est composée d'un serveur intermédiaire, qui contient les différents fichiers d'installation de chaque site Web déployé dans l'environnement. Ces fichiers sont stockés dans un système de fichiers hiérarchique pour conserver une trace de l'historique des modifications. Application Center 2000 est également installé sur ce serveur pour déployer les sites Web installés et les applications COM+ dans le cluster Web. Le serveur intermédiaire Web contient également les composants COM+ à utiliser côté client si Component Load Balancing (CLB) est mis en œuvre.

Le serveur intermédiaire Web est un serveur intermédiaire distinct, en raison des composants COM+ qui y sont installés. En particulier, les composants COM+, lorsqu'ils sont utilisés dans le cadre de la fonctionnalité facultative CLB, doivent être configurés avec l'équilibrage dynamique de la charge et doivent répertorier des serveurs de routage COM+.

Composants COM+ sur le serveur intermédiaire

Les applications COM+ sont installées sur le serveur intermédiaire Web car il est utilisé comme client COM+ par un serveur d'application COM+. La particularité des composants COM+ situés sur le réseau Web frontal est d'interagir avec la fonctionnalité facultative CLB, installée par Application Center 2000. Cette conception permet d'améliorer la sécurité en vous permettant de placer un pare-feu entre le réseau Web frontal et vos applications COM+.

Environnement de production

Le déploiement manuel d'un site Web sur un cluster de serveurs représente beaucoup de travail. Ce processus implique la copie manuelle de tous les fichiers et autorisations du site Web dans chaque cluster Web utilisé sur le réseau Web frontal. Il requiert également l'uniformisation de toutes les modifications des informations du site Web ou des répertoires virtuels (comme par exemple les pools ou les journaux de processus) sur l'ensemble des serveurs de la ferme Web frontale. Application Center 2000 participe à ce processus en déployant un site Web sur le contrôleur de cluster de la ferme Web à partir du serveur intermédiaire Web, puis en répliquant le site Web à partir du contrôleur de cluster de la ferme Web sur tous les serveurs membres de la ferme Web.

Encore une fois, le déploiement des applications COM+ pour le réseau Web frontal doit être séparé du déploiement du site Web. Pour une présentation détaillée de la procédure à suivre, voir la section "Réseau VLAN d'infrastructure", plus loin dans ce chapitre.

Déploiement des applications

Une fois que toutes les données ont été copiées sur le serveur intermédiaire Web, Application Center 2000 peut être utilisé pour déployer de manière contrôlée le contenu et les applications COM+ du site Web. En particulier, l'assistant de déploiement de Microsoft Application Center 2000 et l'interface de ligne de commande permettent de déployer un site Web à partir du serveur intermédiaire sur un nombre quelconque de serveurs de production. Une fois le contrôleur d'un cluster mis à jour avec le nouveau contenu issu du serveur intermédiaire, il utilise le mécanisme de réplication de contenu décrit précédemment pour répliquer le contenu sur les serveurs membres du cluster.

Dans l'architecture Internet Data Center, cette méthode est utilisée au lieu de copier manuellement les fichiers ou d'utiliser des scripts pour copier les fichiers sur chaque serveur Web. Cette méthode vous permet de conditionner et de distribuer des composants COM+ sur l'ensemble du cluster Web, sans avoir à exécuter un lot d'installation sur chaque serveur.

Réplication du contenu

Une fois que le site a été déployé sur le contrôleur du cluster de serveurs Web, l'application déployée peut être répliquée automatiquement sur tous les autres serveurs membres du cluster Web ou peut être répliquée manuellement. La décision d'utiliser la synchronisation automatique ou manuelle dépend du type d'application que le site héberge et du volume des modifications.

Remarque : Dans le cadre de ce chapitre, une application est composée d'un site Web et de composants COM+. Pour obtenir des informations sur les applications qui incluent des lots Commerce Server 2000 ou sur d'autres cas particuliers, consultez la documentation de Microsoft Application Center 2000.

Si une application contient un ensemble relativement réduit de modifications, ou si la distribution des modifications sur le cluster doit être automatisée, il est recommandé d'utiliser un mode de synchronisation automatique.

Comme exemple d'utilisation d'un mode de synchronisation automatisée, on peut citer l'utilisation de Microsoft Application Center dans un intranet d'entreprise où les développeurs publient les modifications directement sur le site à l'aide de l'outil de création et de gestion de sites Web Microsoft FrontPage®. Les modifications sont effectuées sur le contrôleur, puis automatiquement mises à jour sur l'ensemble du cluster.

Modes de synchronisation automatisée

Application Center 2000 fournit deux types de synchronisation automatique permettant de maintenir la cohérence du contenu et des paramètres de configuration sur l'ensemble du cluster :

• Synchronisation basée sur les modifications. Application Center 2000 reçoit une notification si le contenu synchronisé (à l'exception des applications COM+, des informations de stockage CryptoAPI (CAPI), des modifications des listes de contrôle d'accès, et des paramètres réseau) sur le contrôleur de cluster est modifié. Les fichiers modifiés sont automatiquement et immédiatement mis à jour sur tous les membres du cluster dans la boucle de synchronisation. La synchronisation basée sur les modifications peut être désactivée dans la boîte de dialogue Propriétés du nom_de_cluster en désactivant la case à cocher Synchroniser les membres lors de la mise à jour du contenu. Cette méthode peut être utilisée pour mettre à jour automatiquement tous les membres du cluster, chaque fois qu'une modification intervient dans une application sur le contrôleur de cluster.

• Synchronisation basée sur des intervalles. Régulièrement, Application Center 2000 synchronise toutes les applications Application Center 2000 pour garantir que le contenu est identique sur l'ensemble du cluster. L'intervalle entre des synchronisations complètes peut être défini dans la boîte de dialogue Propriétés du nom_de_cluster. Par défaut, l'intervalle de synchronisation est de 60 minutes. La synchronisation basée sur des intervalles peut être désactivée dans la boîte de dialogue Propriétés du nom_de_cluster en désactivant la case à cocher Synchroniser les membres lors de la mise à jour du contenu ou en utilisant la commande ac deploy /disablesync dans une invite de commande. Cette méthode peut être utilisée pour mettre à jour automatiquement tous les membres du cluster, afin qu'ils soient toujours synchronisés avec le contrôleur du cluster.

Si une application inclut un ensemble volumineux de modifications, ou si un contrôle plus important de la distribution des modifications sur l'ensemble du cluster est requis, il est recommandé d'utiliser un mode de synchronisation manuelle. La synchronisation manuelle permet de mettre hors connexion un serveur individuel et de le mettre à jour avec toutes les modifications, sans mettre hors connexion le site entier.

Remarque. Si l'application présente un volume important de modifications et que vous voulez réduire au maximum le trafic réseau lors des pics d'utilisation, vous pouvez synchroniser manuellement les serveurs dans deux ou trois groupes, plutôt que mettre à jour tous les serveurs au même moment.

Comme exemple d'utilisation d'un mode de synchronisation manuelle, on peut citer l'utilisation de Microsoft Application Center sur un site Web public d'entreprise.
Un cluster peut être configuré à l'aide de Microsoft Application Center. Dans ce cas, le cluster est configuré pour ne pas synchroniser automatiquement les membres, lors de la mise à jour de contenu. Le contrôleur est ensuite configuré pour traiter 0% de la charge du cluster et exécuter uniquement les tâches de gestion. Lorsque des modifications sont apportées au contrôleur, un test de validation peut être exécuté par rapport au contrôleur. Lorsque le test présente un résultat positif, les modifications peuvent être déployées sur l'ensemble du cluster, après les heures de pics d'utilisation, de manière à ne pas perturber l'activité professionnelle normale.

Modes de synchronisation manuelle

Application Center 2000 fournit trois modes de synchronisation manuelle et la synchronisation à la demande, pour vous permettre de contrôler quand et comment la synchronisation a lieu au sein d'un cluster :

• Synchronisation de cluster. Tous les membres du cluster dans la boucle de synchronisation sont synchronisés avec le contrôleur du cluster. La boucle de synchronisation est composée de tous les membres du cluster que vous avez sélectionnés pour la synchronisation en activant la case à cocher Inclure ce membre dans les synchronisations dans la boîte de dialogue Propriétés du nom_de_membre. Les membres du cluster peuvent être ajoutés ou supprimés de la boucle à tout moment, en utilisant l'utilitaire de ligne de commande ou le composant logiciel enfichable Application Center. Tous les fichiers et applications sont synchronisés à l'exception des applications COM+. Ce type de synchronisation a lieu uniquement pour les membres de la boucle de synchronisation. La synchronisation de cluster peut être utilisée, si plusieurs applications ont été modifiées et que la synchronisation automatique a été désactivée. Ce processus manuel permet d'effectuer des mises à jour sur le contrôleur de cluster et de les tester dans l'environnement de production. Cette méthode de synchronisation est utilisée après la phase de test pour mettre à jour les autres membres du cluster.

• Synchronisation de membre. Seule le membre du cluster spécifié est synchronisé avec le contrôleur de cluster. Tous les fichiers et applications
  (à l'exception des applications COM+) sont synchronisés. Ce type de synchronisation a lieu uniquement si le membre est inscrit dans la boucle de synchronisation. La synchronisation de membre peut être utilisée lorsqu'un serveur particulier est désynchronisé ou corrompu.

• Synchronisation d'application. Seule l'application spécifiée est synchronisée avec le contrôleur de cluster sur l'ensemble du cluster. Ce type de synchronisation a lieu seulement pour les membres inscrits dans la boucle de synchronisation. La synchronisation d'application peut être utilisée si une seule application a été modifiée et que la synchronisation automatique a été désactivée. Ce processus manuel permet d'effectuer des mises à jour sur le contrôleur de cluster et de les tester dans l'environnement de production. Après la phase de test, cette méthode de synchronisation est utilisée pour mettre à jour les autres membres du cluster.

Restauration

Si un échec survient au cours du déploiement de votre site Web, ou si vous voulez retirer de la production la nouvelle version du site Web après son déploiement, vous devrez revenir à une version antérieure du site. Votre solution de gestion de contenu doit inclure un mécanisme pour la restauration des modifications dans de tels cas.

Réseau VLAN d'infrastructure

Cette section présente les caractéristiques de la gestion des modifications sur les serveurs COM+ d'infrastructure et détaille les choix de conception pour chaque processus. Ces caractéristiques s'appliquent aussi à la gestion des modifications des composants COM+ sur le réseau Web frontal.

Configuration des serveurs COM+

La zone intermédiaire est composée d'un serveur équipé de Microsoft Application Center 2000. Ce serveur est configuré comme contrôleur de cluster de son propre cluster indépendant.

La ferme de serveurs COM+ (cluster COM+) est composée de plusieurs serveurs. Tous ces serveurs sont équipés de Microsoft Application Center 2000. Les serveurs IIS01 et IIS03 sont configurés en tant que contrôleurs de cluster des clusters COM+. Les autres serveurs sont des membres du cluster COM+. Le réseau VLAN d'infrastructure de la Figure 8 (voir "Processus de diffusion de la gestion de contenu" plus haut dans ce chapitre) illustre la ferme de serveurs COM+ et le rôle des ordinateurs qui exécutent la fonction de gestion de contenu.

Environnement de développement/test

Dans l'environnement de développement/test, le même type de méthodes de test et de déploiement doit être utilisé que sur le réseau Web frontal.

Environnement intermédiaire

Pour déployer des modifications dans l'environnement intermédiaire, vous pouvez utiliser des serveurs intermédiaires et des projets de déploiement comme sur le réseau Web frontal.

Configuration des serveurs intermédiaires COM+

L'environnement intermédiaire pour les applications COM+ est composé d'un serveur intermédiaire, qui contient les différents fichiers d'installation de chaque application COM+ à déployer dans l'environnement. Ces fichiers sont stockés dans un système de fichiers hiérarchique pour conserver une trace de l'historique des modifications. Application Center 2000 est installé sur ce serveur pour déployer les applications COM+ installées, sur le cluster des applications COM+.

Le serveur intermédiaire des applications COM+ est un serveur intermédiaire distinct, en raison des composants COM+, qui y sont installés. En particulier, les composants COM+, lorsqu'ils sont utilisés en association avec un cluster CLB facultatif du réseau Web frontal, doivent être configurés de manière sécurisée. Cette conception améliore la sécurité en vous permettant de placer un pare-feu entre le réseau Web frontal et vos applications COM+.

Environnement de production

Application Center 2000 peut être utilisé pour déployer les applications COM+ dans la zone de production. À la différence des serveurs Web, les serveurs des applications COM+ doivent être mis hors connexion pour que les modifications prennent effet. Application Center 2000 peut être utilisé pour déployer les applications de manière incrémentielle, de sorte que les serveurs ne soient pas tous mis hors connexion en même temps, ce qui permet de conserver un site disponible et entièrement opérationnel.

Déploiement d'applications

Une fois les données copiées sur le serveur intermédiaire des applications COM+, Application Center 2000 peut être utilisé pour déployer les applications COM+ de manière contrôlée, à partir du serveur intermédiaire, sur un nombre quelconque de clusters de production.

Dans l'architecture Internet Data Center, cette méthode est employée au lieu de copier manuellement les fichiers ou d'utiliser des scripts pour copier les fichiers sur chaque serveur. Cette méthode vous permet de conditionner et distribuer des composants COM+ sur l'ensemble du cluster Web, sans avoir à exécuter un lot d'installation sur chaque serveur.

Pour prévenir les temps d'indisponibilité, Application Center 2000 vous offre un contrôle total pour déterminer quels serveurs membres sont mis à jour à l'aide des applications COM+ au cours d'une session de synchronisation.

Le déploiement de composants COM+ Application Center 2000 se déroule généralement comme suit :

1. Le serveur membre qui effectue la réception est mis hors connexion.

2. Les connexions existantes à ce serveur sont éliminées.

3. Des services, comme par exemple IIS, sont arrêtés.

4. Les composants COM+ en cours d'utilisation sont arrêtés.

5. La nouvelle application COM+ est exportée en tant que lot par le serveur source. Ce lot inclut toutes les données de configuration du composant COM+, telles que les chaînes de connexion, etc.

6. La nouvelle application COM+ est synchronisée avec le membre cible.

7. Les services sont redémarrés.

8. Le serveur mis à jour est reconnecté.

9. Pour synchroniser un composant COM+ ou un filtre ISAPI global, il convient de créer au préalable une application spécifique à ce composant. Les composants COM+ et les filtres ISAPI globaux ne sont pas synchronisés automatiquement.

Il n'est pas idéal de mettre hors connexion tous les serveurs d'application dans un environnement de production continue. Application Center 2000 permet de résoudre cette difficulté en vous fournissant l'option de définir quels serveurs sont mis à jour au cours d'un processus de déploiement quelconque.

Restauration

Dans cet environnement de déploiement des applications, il convient d'utiliser pour la restauration une conception similaire à celle utilisée sur le réseau Web frontal.

Réseau VLAN de données et de gestion

Cette section présente les caractéristiques de la gestion des modifications de contenu sur les serveurs SQL principaux. La Figure 18 montre les ordinateurs impliqués dans le processus de gestion de contenu appliqué aux bases de données SQL Server 2000.

Figure 18. Processus de gestion de contenu pour SQL Server 2000

Environnement de développement/test

Pour le réseau VLAN de données et de gestion, l'équipe de développement fournit les ensembles de fichiers d'installation. Ces fichiers d'installation sont conformes aux conditions soulignées plus haut dans ce chapitre.

En général, le processus de gestion de contenu SQL requiert des développeurs qu'ils fournissent un ensemble de scripts d'installation et de désinstallation. Les scripts d'installation ne doivent pas requérir de modification avant d'être exécutés.
Il doit être possible d'exécuter les scripts d'installation (à partir d'une ligne de commande ou de la fenêtre de l'Analyseur de requêtes) de manière identique d'une installation à une autre. Si des valeurs spécifiques aux serveurs doivent être incluses dans un script, ce dernier doit utiliser une convention de noms, qui associe clairement ce script particulier au serveur spécifique ; par exemple, le script sur SQL01 à la Figure 13 peut être nommé Procedures-sql01.sql. Le script doit inclure des commentaires en en-tête, qui explicitent les références spécifiques aux serveurs, susceptibles d'être présentes dans le corps du script.

Les scripts de désinstallation doivent s'exécuter de manière similaire, sans modification interne. Là encore, les références spécifiques aux serveurs doivent être clairement signifiées dans le nom de fichier et dans les commentaires d'en-tête. En outre, les commentaires d'en-tête doivent indiquer le niveau de code auquel sera restauré le serveur après la suppression de l'installation.

Ces scripts permettent aux différentes parties d'effectuer des installations et des désinstallations, sans connaître en détail le fonctionnement d'une version donnée. Ceci s'avère essentiel, si des testeurs, le personnel de déploiement ou le personnel des opérations doivent traiter une version sans les développeurs centraux.

Les scripts d'installation sont testés en premier lieu dans l'environnement de test avant d'être utilisés dans l'environnement intermédiaire. Lorsqu'il est clair que l'installation est prête à passer en phase intermédiaire, les scripts sont copiés manuellement dans un partage de fichiers sur le serveur intermédiaire qui exécute SQL Server.

Environnement intermédiaire

Lorsque le serveur intermédiaire qui exécute SQL Server reçoit les scripts associés à une version donnée, il agit initialement en tant qu'espace de stockage de fichiers. Cet espace de stockage de fichiers est une ressource importante que les installations suivantes de la version utiliseront, et il doit donc être intégré dans le système de contrôle de version Microsoft Visual SourceSafe™.

Les scripts d'installation sont ensuite testés dans l'environnement intermédiaire. Le serveur intermédiaire exécutant SQL Server devra peut-être interagir avec les serveur intermédiaires Web et COM+ pour confirmer qu'une mise en œuvre fonctionne correctement.

Environnement de production

Après le succès d'une mise en œuvre dans la phase intermédiaire, le responsable de la mise en œuvre des modifications doit utiliser les mêmes scripts pour copier les données sur le serveur intermédiaire exécutant SQL Server et en production. Ensuite, il doit sauvegarder la base de données de production pour faciliter la restauration en cas de problème. Enfin, il doit exécuter les scripts d'installation sur le serveur de production SQL Server. Il n'est pas nécessaire de conserver les scripts réels sur le serveur de production.

Une fois l'installation terminée, le responsable de la mise en œuvre des modifications doit effectuer une nouvelle sauvegarde complète de la base de données de production. Cette sauvegarde doit être restaurée en priorité par rapport à toute image de la base de données de production qui existe ailleurs en production. Cela inclut tous les serveurs de signalisation et les abonnés de réplication qui sont sensibles aux modifications de schéma effectuées dans la base de données d'application.

Conception de la solution de sauvegarde

Cette section présente les choix de conception impliqués dans le développement de la solution de sauvegarde pour l'architecture Internet Data Center. Elle indique quelles parties de l'environnement doivent être sauvegardées et comment planifier une stratégie de sauvegarde pour l'environnement. La solution de sauvegarde est conçue pour être mise en œuvre comme un ensemble de composants additionnels à intégrer à l'architecture de base décrite au Chapitre 2, "Conception de l'infrastructure réseau", Chapitre 3, "Conception de pare-feu" et Chapitre 4, "Infrastructure de sécurité".

Importance de la sauvegarde de l'environnement

L'architecture Internet Data Center a été conçue pour être très résistante et ne présenter aucun point de défaillance. Il est tout de même essentiel d'effectuer des sauvegardes adéquates, afin que les données et la configuration des systèmes puissent être restaurés en cas de panne irrémédiable. Même si chaque précaution imaginable est prise, il est impossible de prévoir tous les incidents graves ou les pannes susceptibles d'affecter un data center. C'est pourquoi, il est extrêmement important de planifier une stratégie de restauration d'urgence.

Si une organisation ne dispose pas de stratégie de restauration d'urgence adéquate et qu'elle subit une perte de données totale, ses activités seront sévèrement perturbées. La capacité d'une organisation à effectuer une restauration rapide après toute panne ou incident grave, qu'il s'agisse de la panne d'un composant ou de la destruction complète d'un site, est une composante centrale de sa capacité à survivre. En conséquence, une architecture de sauvegarde et de restauration ne doit pas répondre à un seul type de panne, mais doit être conçue pour tous les types de pannes. Cette architecture doit s'appuyer sur une condition bien définie de disponibilité du système et doit prendre en compte les éléments de chaque serveur.

Une architecture correcte de sauvegarde et de restauration doit inclure des procédures, des outils et un plan de prévention des pannes, qui vous aideront à effectuer une restauration après un incident grave ou une panne, ainsi que des procédures et des normes détaillées de restauration. Dans chaque domaine traité, l'architecture doit clairement définir les personnes, le processus et les technologies requis pour un bon fonctionnement.

Plan de prévention des pannes

Un plan de prévention des pannes doit anticiper les événements susceptibles d'affecter le fonctionnement du système et indiquer les procédures à suivre en pareil cas. Les événements susceptibles de perturber les services Internet peuvent être un problème de connexion Internet, des pannes mineures au niveau de composants qui ne peuvent pas être facilement remplacés, ou des problèmes logiciels plus complexes.

Les éléments requis pour élaborer un plan de prévention des pannes efficace incluent la redondance géographique et le stockage distant des bandes de sauvegarde. L'utilisation de data centers distants géographiquement et redondants est une méthode efficace, qui garantit qu'une catastrophe au niveau régional ne supprimera pas la capacité de fournir des services. La suppression des bandes de sauvegarde dans chaque data center permet d'éviter de perdre à la fois le data center et le mécanisme de sauvegarde du data center. Selon l'importance des données, plusieurs dispositifs de stockage hors site peuvent être utilisés. De nombreuses entreprises qui fournissent des services de stockage hors site relèvent et livrent les bandes, lorsque ces dernières doivent être remplacées. Le stockage hors site n'ajoute pas nécessairement des coûts importants à l'architecture de sauvegarde et de restauration.

Un plan de prévention des pannes doit s'appuyer sur les conditions requises de performances et de disponibilité, définies pour l'application particulière hébergée. Par exemple, si l'application est utilisée dans une région spécifique, il peut ne pas être intéressant d'inclure un second data center, distant géographiquement, dans la planification.

Plan de restauration d'urgence en cas d'incident grave

Un plan de restauration d'urgence en cas d'incident grave permet la restauration des données après un incident grave ou une panne, qui n'ont pas pu être évités. Lors du développement du plan, il convient de prendre en compte les points suivants :

• Les activités professionnelles peuvent-elles se poursuivre pendant l'incident grave ou la panne ? Le plan de restauration d'urgence doit inclure des procédures qui permettent de maintenir les activités professionnelles pendant un incident ou une panne (y compris les pannes de réseau). Par exemple, les téléphones du service des ventes continueront à sonner même si le serveur est en panne ; le personnel devra peut-être prendre les commandes manuellement jusqu'à ce que le serveur soit à nouveau opérationnel. Chaque service doit mettre en place des stratégies en vue de telles situations.

• Comment le plan de restauration d'urgence doit-il être créé et entretenu ? Pour être efficace, le plan de restauration d'urgence doit être géré correctement. Un ou plusieurs membres de l'organisation doivent être responsables du contrôle des efforts de préparation de l'organisation face aux incidents graves. Quelqu'un doit installer et entretenir les périphériques de protection du matériel, s'assurer que tous les services disposent d'un plan pour faire face à une panne temporaire du serveur, vérifier que les sauvegardes sont effectuées et remplacées régulièrement hors site, et créer une documentation détaillée, relative au plan de restauration d'urgence.

Choix des éléments à sauvegarder

Virtuellement tous les composants système peuvent être sauvegardés et les supports de sauvegarde sont relativement bon marché. Il est donc tentant de sauvegarder l'ensemble des composants de l'architecture Internet Data Center. Toutefois, une solution de ce type vous demande beaucoup de temps et de bande passante pour sauvegarder et restaurer le système.

Choix des éléments à restaurer

Il est important d'examiner toutes les parties de la mise en œuvre de l'architecture Internet Data Center et de déterminer quelles données doivent être restaurées si le plan de restauration d'urgence est appliqué. Cela vous aide à mettre en place une stratégie efficace de sauvegarde et de restauration, ainsi qu'à identifier les faiblesses potentielles de la conception des applications. La stratégie de sauvegarde doit être réexaminée chaque fois qu'un changement important survient dans l'architecture des applications.

Réseaux VLAN de données et de gestion

Les serveurs de données et de gestion sont les serveurs qui ont le plus besoin d'une solution de sauvegarde efficace. Les ordinateurs SQL Server du réseau VLAN de données contiennent souvent des informations sur la clientèle et des informations financières, dont la perte perturberait grandement le fonctionnement de l'organisation. Par exemple, dans le cas d'une banque proposant des services en ligne, toutes les données des transactions et des avoirs des clients peuvent être stockées sur des ordinateurs SQL Server. Si ces données étaient perdues irrémédiablement, les clients et la banque subiraient une perte financière. En conséquence, tous les serveurs de base de données contenant des données en direct doivent être sauvegardés aussi souvent que possible.

Ces données étant d'une importance capitale pour le bon fonctionnement de l'organisation, il est également recommandé de sauvegarder les serveurs contenant des réplicas de ces données.

Les espaces de stockage de gestion doivent également être sauvegardés car ils contiennent des données de l'historique du système. Par exemple, les événements de sécurité doivent être archivés dans les espaces de stockage NetIQ ; certaines organisations, telles que les sociétés proposant des services financiers, peuvent être tenues par la loi de conserver ces données pendant un temps donné.

Réseau VLAN d'infrastructure

Le réseau VLAN d'infrastructure contient les contrôleurs de domaine pour Windows 2000 et, si l'architecture des applications l'exige, les serveurs d'équilibrage de charge des services de composants. Les contrôleurs de domaine fournissent une haute disponibilité en utilisant un réplica multimaître du service Windows 2000 Active Directory. Si l'architecture des applications s'appuie sur Active Directory pour stocker les données des comptes clients, le succès de la sauvegarde et de la restauration de Microsoft Active Directory doit être une priorité aussi importante que la restauration des données à partir des ordinateurs SQL Server sur le réseau VLAN de données.

Même si l'application ne s'appuie pas sur Active Directory pour le stockage des données ou l'authentification des utilisateurs, il est capital de sauvegarder régulièrement les contrôleurs de domaine. Les autres serveurs de l'environnement disposeront d'autorisations et de comptes de service, basés sur les instances de compte stockées dans Active Directory. S'il n'est pas possible de restaurer une instance en cours de Microsoft Active Directory, des efforts considérables seront requis pour resynchroniser les comptes d'ordinateur et appliquer une nouvelle fois les autorisations.

Si l'application utilise la baie de serveurs CLB (Component Load Balancing) facultatifs, envisagez uniquement la sauvegarde du serveur intermédiaire. L'architecture Internet Data Center fournit des installations automatisées de tous les serveurs. En conséquence, les serveurs CLB peuvent être reconstruits aussi rapidement que s'ils étaient restaurés à partir d'une sauvegarde, et cette reconstruction peut s'avérer moins problématique que la restauration à partir de sauvegardes. Le serveur intermédiaire contiendra la copie principale actuelle de l'application des services de composants et de la configuration Microsoft Application Center 2000. Il faut donc le sauvegarder pour réduire le temps nécessaire à la restauration de la baie entière.

Réseau Web frontal

Un des objectifs principaux liés à la conception du réseau Web frontal dans l'architecture Internet Data Center consiste à éviter le stockage de données persistantes sur les serveurs Web. En conséquence, les serveurs Microsoft Internet Information Services (IIS) ne devraient pas avoir à être sauvegardés pour la plupart des applications Web. Cela réduit radicalement le volume des données sauvegardées et simplifie la configuration du pare-feu. Dans l'architecture Internet Data Center, le processus de restauration recommandé pour le réseau Web frontal inclut la reconstruction des serveurs à l'aide des installations automatisées fournies et un nouveau chargement des applications Web à partir d'un CD-ROM ou d'un support similaire.

Dans le cas de certaines applications, telles que les applications destinées aux entreprises, où des données persistantes peuvent avoir à être stockées sur les serveurs Web, y compris des composants COM+ facultatifs issus de clusters CLB, il peut s'avérer nécessaire de sauvegarder les serveurs Web individuels. Cela doit être évité si possible, et requerra une solution de sauvegarde utilisable par le biais d'un pare-feu sans qu'un nombre important de ports soient ouverts.

Organigramme du processus

L'organigramme suivant décrit le processus de conception utilisé pour choisir les serveurs à sauvegarder dans l'architecture Internet Data Center.

Figure 19. Processus du choix de la solution de sauvegarde

Stratégies de sauvegarde

Cette section présente les différentes stratégies à envisager, lorsque vous planifiez votre solution de sauvegarde.

Prévention des sauvegardes inutiles

Lors de la conception d'une stratégie de sauvegarde, vous pouvez être tenté d'effectuer une sauvegarde complète de chaque serveur de l'environnement. L'objectif le plus important du processus de sauvegarde est le succès de la restauration de l'environnement après une panne ou un incident grave. En conséquence, la sauvegarde doit permettre d'atteindre les objectifs suivants lors de la restauration :

• Les données à restaurer doivent être faciles à trouver.

• La restauration doit être aussi rapide que possible.

• La restauration doit se dérouler correctement.

Si chaque serveur est sauvegardé, le volume des données à restaurer sera important. Bien que les produits de sauvegarde et de stockage sur bandes permettent une restauration rapide des données, la restauration de l'ensemble des données à partir de bandes peut augmenter la durée d'indisponibilité des serveurs. Par exemple, la procédure suivante doit être exécutée pour la plupart des produits de sauvegarde :

1. Réinstaller le système d'exploitation.

2. Réinstaller le logiciel de sauvegarde.

3. Restaurer les données à partir des bandes de sauvegarde.

Lorsque de tels produits sont utilisés, la sauvegarde des fichiers du système d'exploitation et du logiciel de sauvegarde augmente encore la durée de la restauration et la quantité de données à stocker et à déplacer sur le réseau. Il est préférable de sauvegarder les paramètres de configuration du système, tels que le Registre et toutes les données sur le serveur, puis de remplacer tous les fichiers du système d'exploitation par l'installation automatisée.

Plus la sauvegarde est volumineuse, plus elle est longue et plus la restauration est longue, ce qui est encore plus gênant. Lorsqu'un incident grave survient, le temps est un facteur capital et il est préférable d'avoir le moins de données possible à restaurer. Une sauvegarde volumineuse effectuée régulièrement affecte également les performances du réseau, à moins que vous disposiez d'un réseau dédié à
la sauvegarde.

Il est capital d'effectuer une restauration test sur le réseau de test complet, une fois que la stratégie de sauvegarde optimale a été déterminée pour votre environnement. Cet essai permet d'identifier tous les types de problèmes et représente une expérience utile pour le personnel, qui peut alors restaurer les systèmes dans l'architecture Internet Data Center sans subir la pression liée à la remise en service d'un système de production.

Choix du moment approprié pour la sauvegarde

Sauvegarder un environnement de commerce électronique n'est pas la même chose que sauvegarder l'infrastructure d'un réseau local d'entreprise. Sur un réseau local d'entreprise, l'utilisation du réseau est moins importante en dehors des heures de bureau. Dans un environnement de commerce électronique, l'utilisation du réseau augmente en général tôt dans la soirée et peut rester au même niveau jusqu'au matin, en particulier si la base des clients est répartie sur plusieurs fuseaux horaires. Pour cette raison, il peut s'avérer impossible d'identifier un moment idéal pour la sauvegarde. Pour réduire l'impact sur les clients Internet, respectez les consignes suivantes :

• Planifiez les sauvegardes de manière à éviter les périodes de pics d'utilisation du Web.

• Ne sauvegardez pas de données inutiles.

• Effectuez régulièrement des essais de restauration sur un réseau de test pour vérifier que vous effectuez des sauvegardes correctes.

Types de sauvegarde

Les trois types principaux de sauvegarde sont :

• la sauvegarde normale ;

• la sauvegarde différentielle ;

• la sauvegarde incrémentielle.

Sauvegarde normale

Une sauvegarde normale (ou complète) entraîne la copie de tous les fichiers sélectionnés et chaque fichier est marqué comme sauvegardé (en d'autres termes, l'attribut archive est effacé). Avec les sauvegardes normales, seule la copie la plus récente du fichier ou de la bande de sauvegarde est nécessaire pour restaurer tous les fichiers. Une sauvegarde normale est généralement exécutée la première fois qu'un jeu de sauvegarde est créé.

Sauvegarde différentielle

Une sauvegarde différentielle entraîne la copie des fichiers créés ou modifiés depuis la dernière sauvegarde normale ou incrémentielle. Les fichiers ne sont pas marqués comme ayant été sauvegardés (en d'autres termes, l'attribut archive n'est pas effacé). Si les sauvegardes normale et différentielle sont utilisées en association, les fichiers ou les bandes correspondant aux deux sauvegardes sont nécessaires pour restaurer les fichiers et les dossiers.

Sauvegarde incrémentielle

Une sauvegarde incrémentielle sauvegarde uniquement les fichiers créés ou modifiés depuis la dernière sauvegarde normale ou incrémentielle. Les fichiers sont marqués comme sauvegardés (en d'autres termes, l'attribut archive est effacé). Si les sauvegardes normale et incrémentielle sont associées, le dernier jeu de sauvegarde normale et tous les jeux de sauvegarde incrémentielle sont nécessaires pour restaurer l'ensemble des données.

Lorsque vous choisissez le type de sauvegarde à effectuer, vous devez prendre en compte l'impact sur la bande passante du réseau, ainsi que le temps requis pour effectuer une restauration.

Considérations sur le matériel

La Figure 2 (voir "Analyse et alarme" plus haut dans ce chapitre) illustre le placement du serveur de sauvegarde et du système de bandes. Vous trouverez des détails sur la solution matérielle utilisée pour l'architecture Internet Data Center sur les sites suivants :

Veritas  

CommVault Systems  

Il est également important de déterminer quel matériel supplémentaire sera nécessaire hors site. Il n'y a aucun intérêt à disposer d'un accès rapide aux bandes de sauvegarde hors site, si vous n'avez pas l'équipement qui permet de restaurer les sauvegardes. C'est pourquoi, dans de nombreux environnements, il est recommandé de posséder un dispositif de test, doté du même équipement que l'environnement de production, mais situé dans un emplacement différent.

Résumé

La tâche correspondant à la gestion d'un système aussi complexe et important pour le bon fonctionnement d'une entreprise que l'architecture Internet Data Center ne doit pas être sous-estimée. Ce chapitre vous a fourni une vue d'ensemble des systèmes de gestion qui prennent en charge les objectifs clés de la solution : disponibilité, évolutivité et sécurité. Cela a impliqué le respect des conditions de gestion suivantes.

Analyse et alarmes

L'architecture Internet Data Center présente de nombreuses zones que vous devez analyser avec soin pour vous assurer que votre site est opérationnel et qu'il fonctionne correctement. En gérant et analysant de manière proactive les serveurs du système, vous pouvez assurer la disponibilité et les performances de ces systèmes essentiels. L'analyse de ces serveurs et l'utilisation des outils appropriés réduisent le coût de possession de ces systèmes et applications en vous permettant d'effectuer les opérations suivantes :

• Automatiser les tâches répétitives et longues.

• Fournir des connaissances et des règles d'entreprise sous forme de lots, pour la gestion et l'analyse des environnements Windows 2000 distribués.

• Centraliser la gestion des systèmes et applications distribués et distants.

• Activer la notification et la correction proactives des problèmes, avant qu'ils affectent l'environnement Web et l'entreprise.

Gestion à distance

La solution complète et sécurisée présentée dans ce chapitre offre aux administrateurs la possibilité de conduire des tâches à distance sur un ordinateur doté d'une connexion LAN, WAN ou VPN. L'accès aux outils GUI de Windows est établi à l'aide des services Terminal Server de Windows 2000 Server en mode d'administration à distance. Lorsqu'il n'est pas possible d'accéder à un serveur via l'interface des services Terminal Server, les cartes matérielles de gestion de serveur peuvent être utilisées comme sauvegarde pour accéder au serveur.

Gestion du contenu

La gestion du contenu est un processus capital dans l'architecture globale d'un site Internet Data Center. Elle fournit des instructions permettant d'effectuer des installations d'applications fiables, pouvant être répétées et gérées facilement. Ce processus a pour objectifs les points suivants :

• Une installation claire et concise.

• Un code base stable à la sortie de l'environnement de test.

• Une mise en œuvre bien organisée, testée dans la phase intermédiaire.

• Une introduction parfaite en production.

Si tous ces objectifs sont respectés, l'entreprise devra pouvoir compter entièrement sur l'application déployée par Application Center 2000.

Sauvegarde

Lorsque vous planifiez une stratégie de sauvegarde, il est important d'étudier avec soin ce qui doit être sauvegardé et le moment de la sauvegarde. Il est recommandé que le matériel de duplication, tel que les lecteurs de bandes, soit disponible hors site et qu'un essai de restauration de l'infrastructure Internet Data Center
soit effectué.

Informations complémentaires

Les sites et ressources ci-dessous fournissent des informations complémentaires sur les sujets traités dans ce chapitre.

Sites/liens Web

Pour plus d'informations sur Microsoft Operations Manager , visitez le site Web correspondant.

Pour plus d'informations sur NetIQ AppManager  , visitez le site Web correspondant.

Vous trouverez plus d'informations sur Windows 2000 Server, les services Terminal Server et l'administration à distance, sur le site Windows 2000 Server 

Vous trouverez des liens à une série de livres blancs de commerce électronique, qui inclut des informations sur la gestion des modifications et du contenu, sur le site Microsoft Business 

Des informations officielles sur l'architecture Internet Data Center sont disponibles sur le site Microsoft .NET 

Kits de ressources

Vous trouverez des informations détaillées sur Application Center 2000 et des informations complémentaires sur CLB, dont notamment des scénarios de déploiement, dans le Kit de ressources Microsoft Application Center 2000.

Des informations complémentaires sur différents aspects de la gestion sont également disponibles dans le Kit de ressources Microsoft Windows 2000 Server et dans le Guide de planification du déploiement Windows 2000.

<< 1 2 3 4 5 6 7 8 9 >>

Dernière mise à jour le vendredi 1 mars 2002

Pour en savoir plus

• Lire la version US de cet article