Présentation du guide de conception Operations

Guide de conception Operations
Manager 2007 R2
Microsoft Corporation
Date de publication : Mai 2009
Auteur
Christopher Fox
Les informations contenues dans ce document représentent l'opinion de Microsoft Corporation
sur les points cités à la date de la publication. Microsoft devant s'adapter aux conditions
changeantes du marché, ce document ne doit pas être interprété comme un engagement de la
part de Microsoft, et Microsoft ne peut pas garantir l'exactitude des informations présentées
après la date de publication.
Ce document est fourni à titre indicatif uniquement. MICROSOFT N'ÉMET AUCUNE GARANTIE,
EXPRESSE, IMPLICITE OU LÉGALE RELATIVE AUX INFORMATIONS CONTENUES DANS
CE DOCUMENT.
L'utilisateur est tenu d'observer la réglementation relative aux droits d'auteur applicable dans son
pays. Aucune partie de ce document ne peut être reproduite, stockée ou introduite dans un
système de restitution, ou transmise à quelque fin ou par quelque moyen que ce soit
(électronique, mécanique, photocopie, enregistrement ou autre) sans la permission expresse et
écrite de Microsoft Corporation.
Microsoft Corporation peut détenir des brevets, avoir déposé des demandes d'enregistrement de
brevets ou être titulaire de marques, droits d'auteur ou autres droits de propriété intellectuelle
portant sur tout ou partie des éléments qui font l'objet du présent document. Sauf stipulation
expresse contraire d'un contrat de licence écrit de Microsoft, la fourniture de ce document ne
vous confère aucun droit de licence sur ces brevets, marques, droits d'auteur ou autres droits de
propriété intellectuelle.
Sauf mention contraire, les sociétés, les organisations, les produits, les noms de domaine, les
adresses électroniques, les logos, les personnes, les lieux et les événements mentionnés dans
les exemples sont fictifs. Toute ressemblance avec des sociétés, organisations, produits, noms
de domaine, adresses électroniques, logos, personnes, lieux ou événements réels est purement
fortuite et involontaire.
© 2009 Microsoft Corporation. Tous droits réservés.
Microsoft, Active Directory, ActiveSync, Internet Explorer, JScript, SharePoint, SQL Server, Visio,
Visual Basic, Visual Studio, Win32, Windows, Windows PowerShell, Windows Server et
Windows Vista sont des marques du groupe Microsoft.
Toutes les autres marques sont la propriété de leurs propriétaires respectifs.
Historique des révisions
Date de sortie
Modifications
Mai 2009
La version de ce guide pour Operations
Manager 2007 R2 contient les mises à jour et
les ajouts suivants :

La feuille de route du document a été
supprimée.
Date de sortie
Modifications

Des informations sur la sécurité de
l'analyse UNIX ou Linux ont été ajoutées,
ainsi que sur les mesures de performances
et d'échelle.

Mesures d'échelle actualisées
Contenu
Présentation du guide de conception Operations Manager 2007 R2 ............................................. 7
Présentation d’Operations Manager 2007 ................................................................................... 8
Identification de la configuration requise pour Operations Manager 2007 ................................ 19
Mappage de la configuration requise à une conception pour Operations Manager 2007 ......... 24
Développement d'un plan d'implémentation pour Operations Manager 2007 ........................... 46
Présentation du guide de conception
Operations Manager 2007 R2
Chaque environnement informatique est unique, de fait l'infrastructure utilisée pour l'analyser doit
tenir compte de cet aspect afin d'être efficace. Il n'existe pas de solution d'analyse universelle
délivrant des résultats satisfaisants. Toutefois, les entreprises ne peuvent pas se permettre de
développer des solutions d'analyse sur mesure de A à Z. Les moyens et les efforts impliqués
seraient trop importants.
Microsoft System Center Operations Manager 2007 est une solution intermédiaire qui fournit les
blocs de construction nécessaires à une solution qui prend en compte vos besoins
professionnels. Vous organisez les blocs et établissez les relations entre eux à votre guise, ce
processus est appelé planification de la topologie. Votre topologie dépend des besoins
professionnels, technologiques, sécuritaires et réglementaires de votre entreprise. C'est pendant
le processus de conception que l'unicité de votre environnement est intégrée à votre topologie
Operations Manager.
Avant de vous lancer dans la phase de conception, vous devez bien comprendre la notion de
sécurité dans Operations Manager 2007, notamment les groupes et comptes requis et les
autorisations associées. Il est essentiel pour votre processus de conception que vous acquériez
les notions de rôles et de sécurité basée sur les rôles dans Operations Manager 2007, ainsi que
les implications de l'authentification mutuelle obligatoire. Pour une présentation complète de la
notion de sécurité dans Operations Manager 2007, consultez le Guide de sécurité d'Operations
Manager 2007 à l'adresse http://go.microsoft.com/fwlink/?LinkId=64017.
Operations Manager 2007 utilise une approche basée sur un modèle pour l'analyse. Dans la
gestion basée sur des modèles, tous les éléments qui participent à la fourniture d'une fonction ou
d'un service dans votre organisation sont représentés sous forme de modèles. Pour plus
d'informations sur la gestion basée sur des modèles, consultez le guide consacré aux concepts
clés d'Operations Manager 2007 à l'adresse suivante
http://go.microsoft.com/fwlink/?LinkId=124799.
À propos de ce guide
Ce guide est constitué de sections qui vous accompagnent dans le processus de création et de
test de votre mise en œuvre Operations Manager 2007. Ce guide vous aide à assimiler la notion
de composants de niveau de bloc de construction dans Operations Manager 2007 à travers les
récapitulatifs des rôles. Il vous permettra de vous poser les bonnes questions afin que votre
conception réponde aux besoins de votre entreprise. Il vous permettra aussi de vérifier que vous
avez satisfait aux questions fondamentales en termes de conception afin que cette dernière soit
flexible et évolutive. Il vous permettra également de planifier et de dimensionner votre topologie
Operations Manager 2007 à l'aide de données provenant du guide relatif au dimensionnement et
aux performances. Il fournit des conseils pour la validation de votre conception en laboratoire.
7
Une fois les étapes de ce guide terminées, vous disposerez d'une configuration planifiée et d'un
diagramme d'infrastructure détaillé des composants Operations Manager 2007. Ces plans auront
été validés dans un environnement de laboratoire et vous serez prêt à démarrer la production de
votre déploiement pilote. Une fois cette étape atteinte, vous devez passer au Guide de
déploiement Operations Manager 2007 pour poursuivre.
Notez que ce guide est seulement destiné à vous accompagner, comme son nom l'indique. Les
décisions prises et la conception finale doivent être déterminées en fonction de vos besoins. Ce
guide vous permet de disposer de toutes les informations dont vous avez besoin pour prendre
des décisions avisées en fonction de votre situation spécifique.
Présentation du processus de conception
Operations Manager 2007
La conception d'une mise en œuvre Operations Manager passe par la réussite des points
suivants :

Compréhension des fonctions et fonctionnalités fournies par Operations Manager 2007.

Compréhension des impératifs techniques et professionnels de l'entreprise, de l'infrastructure
et de vos procédures d'analyses actuelles.

Mappage de ces impératifs avec une infrastructure Operations Manager 2007 qui répond à
ces besoins.

Validations de la conception d'infrastructure Operations Manager 2007 dans un
environnement de laboratoire.
Au cours de ce processus, vous devrez effectuer le dimensionnement et la planification de la
capacité pour vos groupes d'administration. Les données correspondantes sont fournies dans ce
guide.
Présentation d’Operations Manager 2007
Une infrastructure d'Operations Manager 2007 est composée de certains composants principaux
qui doivent être implémentés et d'un ensemble de composants et fonctionnalités facultatifs que
vous pouvez choisir d'implémenter si nécessaire. Cette section présente ces composants et
fonctionnalités en fonction de leur catégorie, nécessaire ou facultatif. En général, un composant
est un élément que vous installez depuis votre support source, et une fonctionnalité est un
élément que vous configurez et utilisez une fois que tous les composants nécessaires à celle-ci
installés.
Rôles et composants de serveur nécessaires
L'unité de base de fonctionnalité de toutes les implémentations d'Operations Manager 2007 est le
groupe d'administration. Il est composé d'une installation de Microsoft SQL Server 2005 SP1 ou
version ultérieure ou de Microsoft SQL Server 2008, qui héberge la base de données Operations
Manager. Le serveur d'administration racine, la console Opérateur, et les agents (un ou
8
plusieurs) déployés sur les ordinateurs ou périphériques analysés sont les composants de base
d'un groupe d'administration.
Base de données Operations Manager
La base de données Operations Manager est le premier composant à installer dans tous les
groupes d'administration. Elle doit être installée sur Microsoft SQL Server 2005 SP1 ou version
ultérieure, ou sur Microsoft SQL Server 2008 SP1. Cette base de données conserve toutes les
données de configuration du groupe d'administration et stocke toutes les données d'analyse
collectées et traitées par les agents.
Pour optimiser les performances d'Operations Manager, vous devez garder sous contrôle la taille
de la base de données Operations Manager. Les tests ont montré qu'il vaut mieux rester en
dessous de 50 Go. Pour éviter de dépasser cette limite, Operations Manager 2007 nettoiera
automatiquement les données anciennes et superflues, selon des paramètres que vous
définissez.
Comme un groupe d'administration ne peut contenir qu'une seule base de données Operations
Manager, cette dernière doit être fonctionnelle pour que le groupe d'administration fonctionne.
Pour atténuer le fait qu'une seule instance de la base de données Operations Manager soit un
point faible unique, vous pouvez placer la base de données Operations Manager dans un cluster
de basculement de service Cluster (anciennement appelé MSCS). De plus, l'envoi de journaux
peut être configuré de sorte que les données d'opérations et informations de configuration
actuelles puissent être envoyées à un autre serveur Microsoft SQL de la même version qui
héberge une copie de la base de données Operations Manager principale. En cas de défaillance
de la base de données principale, la copie peut être mise à jour et basculée en principale.
Serveur d'administration racine
Le serveur d'administration racine est un type de serveur d'administration spécialisé dans un
groupe d'administration, et est le premier serveur d'administration installé dans un groupe
d'administration. Seul un serveur d'administration racine à la fois peut être actif par groupe
d'administration. En bref, le serveur d'administration racine est le point focal d'administration de la
configuration du groupe d'administration, de l'administration et de la communication avec les
agents, et de communication avec la base de données Operations Manager et d'autres bases de
données du groupe d'administration.
Le serveur d'administration racine sert aussi de cible pour la console Opérateur et de cible
préférée pour les consoles Web.
Les hôtes du serveur d'administration racine du service d'accès aux données System Center et
du service de configuration d'administration System Center. Ces services ne s'exécutent que sur
le serveur d'administration racine. Le service d'accès aux données System Center fournit un
accès sécurisé à la base de données Operations Manager pour tous les clients, notamment la
console Opérateur, l'interface Opérateur et la console Web. Le service de configuration
d'administration System Center est responsable du calcul et de la distribution de la configuration
9
de tous les serveurs d'administration et agents, notamment des packs d'administration qu'ils
doivent recevoir.
À l'instar de la base de données Operations Manager, le rôle du serveur d'administration racine
peut être installé dans un cluster de basculement MSCS pour le rendre hautement disponible. De
plus, tous les serveurs d'administration du groupe d'administration (le cas échéant) peuvent être
promus manuellement au rôle du serveur d'administration racine.
Agent
Un agent Operations Manager 2007 est un service déployé sur un ordinateur que vous souhaitez
analyser. Sur le périphérique analysé, un agent est répertorié en tant que service d'administration
System Center. Chaque agent dépend d'un serveur d'administration du groupe d'administration.
Ce serveur d'administration est appelé serveur d'administration principal de l'agent. Les agents
observent les sources de données sur le périphérique analysé et collectent des informations en
fonction de la configuration qui leur est envoyée par leur serveur d'administration. L'agent calcule
aussi l'état d'intégrité de l'objet analysé et le signale au serveur d'administration. Lorsque l'état
d'intégrité d'un objet analysé change ou que d'autres critères sont remplis, l'agent peut générer
une alerte. Cela permet à l'opérateur de savoir que quelque chose va de travers et requiert son
attention.
Les agents peuvent aussi entreprendre divers types d'action pour aider à diagnostiquer les
problèmes et à les corriger. En alimentant le serveur d'administration en données d'intégrité
relatives au périphérique analysé, l'agent fournit une image à jour du périphérique et de toutes
les applications qu'il héberge.
Il est possible d'analyser des périphériques sans recourir aux agents. Dans ce cas, un serveur
d'administration effectue l'analyse à distance.
Console Opérateur
La console Opérateur fournit une interface utilisateur unique et unifiée permettant d'interagir avec
Operations Manager 2007. Elle permet d'accéder aux données d'analyse, aux outils de création
de pack d'administration de base, aux rapports d'Operations Manager 2007, à tous les contrôles
et outils nécessaires à l'administration d'Operations Manager 2007 et à un espace de travail
personnalisable.
Pour qu'un utilisateur puisse accéder à la console Opérateur, le compte Active Directory
d'utilisateur doit être affecté à un rôle d'utilisateur d'Operations Manager 2007. Un rôle
d'utilisateur est une combinaison d'étendues de périphériques auquel l'accès est autorisé et d'un
profil qui définit ce que le rôle peut faire dans la portée qui lui est attribuée. La sécurité basée sur
les rôles est appliquée dans la console Opérateur, pour que les administrateurs d'Operations
Manager puissent définir ce qu'un utilisateur donné peut voir dans la console et les actions qu'il
peut entreprendre sur ces éléments. Pour plus d'informations, voir la section « Sécurité basée sur
les rôles » de ce document.
10
Packs d'administration
Les packs d'administration contiennent la définition d'intégrité d'une application, telle que l'ont
définie ses développeurs. Lorsqu'ils sont importés dans Operations Manager, ils permettent à
l'agent d'analyser l'intégrité d'une application, de générer des alertes quand un élément important
s'y passe mal, d'entreprendre des actions dans l'application et dans son infrastructure de prise en
charge pour diagnostiquer plus précisément l'application et restaurer son état intègre. Sans
application, système d'exploitation ni pack d'administration de périphérique donné, Operations
Manager 2007 n'a pas connaissance de ces entités et ne peut pas les analyser.
Rôles et composants de serveur facultatifs
Ces rôles de serveurs supplémentaires étendent la fonctionnalité d'un groupe d'administration. La
plupart de ces composants sont installés séparément des composants principaux nécessaires,
mais certains peuvent être installés en même temps que les composants principaux. Pour des
détails complets sur l'installation des composants d'Operations Manager 2007, voir le Guide de
déploiement d'Operations Manager 2007.
Serveur d'administration
Un serveur d'administration sert principalement à recevoir des configurations et des packs
d'administration en provenance du serveur d'administration racine et à les distribuer aux agents
qui envoient leurs rapports au serveur d'administration. Il n'effectue pas les fonctions spéciales
du serveur d'administration racine. Un serveur d'administration peut être promu au rôle du
serveur d'administration racine en cas d'échec de celui-ci, du moment qu'il était présent dans le
groupe d'administration avant la défaillance du serveur d'administration racine. Plusieurs
serveurs d'administration sont installés dans un groupe d'administration, ce qui apporte des
capacités supplémentaires pour l'administration des agents. En plus d'apporter de l'évolutivité,
l'introduction de serveurs d'administration supplémentaires dans un groupe d'administration
permet aux agents de basculer et de commencer à signaler leurs données à un autre serveur
d'administration en cas de perte de la communication avec leur serveur d'administration principal.
Le serveur d'administration peut aussi être utilisé à des fins d'analyse à distance (telle l'analyse
URL et l'analyse interplateforme). Un rôle supplémentaire est, pour un serveur d'administration,
l'hébergement du rôle de collecteur des services ACS. Le collecteur des services ACS ne peut
être installé que sur un serveur d'administration ou sur un serveur de passerelle. Voir la section
« Services ACS » ultérieurement dans ce document pour obtenir des informations
supplémentaires sur les services ACS. D'autres rôles comprennent notamment le rôle de partage
de fichiers AEM, expliqué plus tard dans ce document.
Serveur de passerelle
Operations Manager 2007 nécessite que tous les agents et serveurs d'administration
s'authentifient les uns et les autres et établissent un canal de communication crypté avant
d'échanger des informations. Kerberos est le protocole d'authentification par défaut. Lorsque
l'agent et le serveur d'administration se trouvent dans la même forêt Active Directory ou dans des
11
forêts avec approbation de forêts, l'authentification mutuelle est automatique. Cela est dû au fait
que Kerberos est le protocole d'authentification par défaut dans Active Directory.
Lorsque des agents et des serveurs d'administration ne sont pas dans les mêmes limites
d'approbation Kerberos (c'est-à-dire, qu'ils ne sont pas dans la même forêt Active Directory ni
dans des forêts avec approbation de forêts), des mécanismes d'authentification sur certificat
doivent être utilisés. Dans cette situation, un certificat doit être émis et conservé pour ces agents
et pour les serveurs d'administration auxquels ceux-ci envoient leurs rapports. De plus, en
présence d'un pare-feu entre agents et serveur d'administration, soit les règles du pare-feu
doivent permettre à chaque ordinateur hébergeant un agent de communiquer directement par
son biais via un canal crypté, soit le port de communication Operations Manager doit autoriser les
communications entrantes.
Un serveur de passerelle d'Operations Manager 2007 peut être utilisé pour réduire radicalement
la surcharge d'administration nécessaire à la maintenance de la communication entre agents et
serveurs d'administration séparés par une limite d'approbation. Le serveur de passerelle fait
office de proxy pour les communications des agents. Le serveur de passerelle est placé dans la
limite d'approbation des agents (il peut s'agir d'un domaine), et tous les agents communiquent
avec lui. Ensuite, le serveur de passerelle, grâce à l'utilisation de son certificat d'ordinateur,
effectue une authentification mutuelle avec le serveur d'administration et transfère les
communications agent-vers-serveur d'administration et serveur d'administration-vers-agent. Cela
nécessite ensuite un seul certificat pour le serveur d'administration et un pour le serveur de
passerelle. Dans le scénario avec pare-feu, seul le serveur de passerelle et le serveur
d'administration ont besoin d'être autorisés à communiquer entre eux.
Il est possible d'installer plusieurs serveurs de passerelle dans un groupe d'administration dans
un objectif d'évolutivité et de basculement. Si un agent perd la communication avec son serveur
de passerelle, il peut basculer vers un autre serveur de passerelle se trouvant dans le même
groupe d'administration et dans les limites d'approbation de l'agent.
De même, les serveurs de passerelle peuvent être configurés pour basculer entre serveurs
d'administration d'un même groupe d'administration. Cette configuration fournit ensuite des
canaux de communication intégralement redondants aux agents se trouvant hors de la limite
d'approbation d'un serveur d'administration.
Serveur de console Web
Le serveur de console Web fournit au groupe d'administration une interface accessible via un
navigateur Web. Cette interface n'a pas la fonctionnalité complète de la console Opérateur, mais
fournit un accès uniquement aux affichages Analyse, Reporting et Mon espace de travail. La
console Web permet d'accéder à toutes les données et tâches d'analyses qui sont des actions
qu'il est possible d'exécuter sur des ordinateurs analysés à partir de la console Opérateur. Dans
la console Web, l'accès aux données est soumis aux mêmes restrictions que l'accès au contenu
de la console Opérateur.
12
Console de Création des packs d'administration
La console de création d'Operations Manager 2007 est une application autonome qui fournit une
fonctionnalité de création de pack d'administration plus riche que celle fournie par l'espace de
création de la console Opérateur. Avec la console de création, vous pouvez créer des nouveaux
packs d'administration, consulter et modifier les packs d'administration existants, en vérifier
l'intégrité, et en importer et exporter depuis et vers des groupes d'administration. La console de
création d'Operations Manager 2007 peut être téléchargée depuis :
http://go.microsoft.com/fwlink/?LinkId=136356.
Entrepôt de données de rapports
L'entrepôt de données de rapports stocke les données d'analyse et d'alerte pour l'historique. Les
serveurs d'administration écrivent leurs données à l'Entrepôt de données en même temps
qu'elles sont inscrites dans la base de données Operations Manager, de sorte que les rapports
générés contiennent toujours les données les plus à jour. L'entrepôt de données effectue
automatiquement une agrégation des données de performances toutes les heures ou tous les
jours. Cela permet une exécution plus rapide des rapports de tendance à long terme, et
beaucoup moins de données doivent être conservées pour la prise en charge ces rapports.
L'entrepôt de données de rapports peut recevoir les données en provenance de groupes
d'administration, permettant donc un affichage agrégé des données de vos rapports.
Serveur de rapports
Le serveur Operations Manager Reporting est installé dans une instance de Microsoft SQL 2005
Reporting Services SP1 ou suivante ou dans Microsoft SQL Server 2008 SP1 Reporting
Services. Il est responsable de l'élaboration et de la présentation des rapports contenant les
données demandées par l'entrepôt des données de rapports. Tous les rapports sont accessibles
depuis la console Opérateur, leur accès est donc contrôlé par une sécurité basée sur les rôles.
Services ACS
Les services ACS sont une solution sécurisée aux performances élevées qui collecte et stocke
les événements du journal des événements de sécurité des ordinateurs analysés. Les
événements sont stockés dans une base de données distincte, la base de données des services
ACS (que nous aborderons plus tard dans ce document), dans Microsoft SQL Server 2005 SP1
ou suivante et Microsoft SQL Server 2008 SP1. ACS collecte tous les événements inscrits dans
le journal des événements de sécurité sur les ordinateurs pour lesquels le redirecteur ACS est
activé. Les événements sont transférés des ordinateurs analysés au collecteur des services ACS,
exécuté sur un serveur d'administration, qui les traite et inscrit ensuite dans la base de données
des services ACS. Les événements sont transférés de façon cryptée et presque en temps réel,
entre les redirecteurs et le collecteur. Un composant distinct, la fonctionnalité de rapports des
services ACS, est ensuite utilisé pour générer des rapports à partir des données ACS stockées.
Le secret d'une utilisation efficace des services ACS est le développement d'une stratégie de
groupe d'audit Windows saine implémentée en tant que stratégie de groupe de domaine. Pour
13
des détails sur la stratégie de groupe d'audit Windows et l'implémentation des services ACS, voir
http://go.microsoft.com/fwlink/?LinkId=144734.
Redirecteur ACS
Le redirecteur ACS est intégré à l'agent d'Operations Manager 2007 ; aucun déploiement ni
configuration distincts ne sont donc nécessaires. Le redirecteur ACS s'affiche en tant que service
de redirecteur d'audit et est désactivé par défaut. Le redirecteur ACS d'un ordinateur individuel ou
de groupes d'ordinateurs est activé via une tâche de la console Opérateur.
Serveur du collecteur des services ACS
L'objectif principal du serveur du collecteur des services ACS est de collecter, filtrer et de
prétraiter tous les événements des journaux de sécurité Windows pour les insérer dans la base
de données. Comme les services ACS collectent tous les événements de sécurité presque en
temps réel, de grandes quantités de données entrent dans le système, en provenance des
redirecteurs. Ces informations ne sont pas toutes intéressantes pour votre entreprise, comme
défini dans la stratégie de groupe d'audit Windows. Le mécanisme de filtrage du collecteur vous
permet de spécifier les événements que vous souhaitez inscrire à la base de données des
services ACS pour les stocker à long terme.
Le serveur du collecteur des services ACS est équipé d'un programme d'installation distinct pour
les serveurs, les agents ou les composants de création de rapports d'Operations Manager. Il ne
peut être installé que sur un serveur d'administration existant ou sur le serveur d'administration
racine si vous n'avez pas installé de serveur d'administration supplémentaire. Un serveur de
collecteur des services ACS peut prendre en charge des centaines de milliers de serveurs, en
fonction du rôle du serveur et de la stratégie de groupe d'audit Windows ainsi que des dizaines
de milliers de stations de travail. Cependant, en présence d'une relation un-à-un entre le serveur
du collecteur ACS et la base de données des services ACS (dont nous parlerons dans la section
suivante). Si, pour des raisons d'évolutivité ou de contrôle, votre entreprise a besoin de
collecteurs des services ACS supplémentaires, vous aurez besoin d'une base de données des
services ACS par collecteur des services ACS.
Base de données des services ACS
Une fois les données prétraitées par le serveur de collecteur des services ACS, elles sont
inscrites dans la base de données des services ACS, qui est une base de données créée sur une
instance de Microsoft SQL Server 2005 SP1 ou SP2. Comme il s'agit d'une base de données
SQL standard, il est possible de la mettre en cluster à des fins de haute disponibilité. Pour
supporter la relation un-à-un entre collecteurs et bases de données, vous pouvez créer, via des
instances nommées, plusieurs bases de données de services ACS sur un seul serveur SQL
Server 2005, tant que ce dernier peut prendre en charge la charge supplémentaire. Pour plus
d'informations sur le dimensionnement et la planification des capacités pour les services ACS,
voir la section correspondante plus tard dans ce guide.
14
Fonctionnalité de rapports des services ACS
Le serveur de rapports des services ACS est aussi un composant installé séparément. Plusieurs
sortes de rapports préconfigurés sont disponibles. L'installation de ce composant nécessite une
instance existante de SQL Server 2005 SP1 Reporting Services ou suivante ou de Microsoft SQL
Server 2008 Reporting Services. Il peut s'agir d'une instance autonome, ou vous pouvez installer
la fonctionnalité de rapports des services ACS avec Operations Manager 2007 Reporting, comme
compromis.
Si vous installez la fonctionnalité de rapports des services ACS sur la même instance de
Reporting Services que Operations Manager 2007 Reporting, la fonctionnalité s'intègre
entièrement à Operations Manager Reporting. Cela se traduit par une réduction de la surcharge
d'administration, parce que toutes les personnes auxquelles un rôle d'Operations Manager
Reporting a été affecté pourront accéder aux rapports ACS. Certaines entreprises peuvent
considérer cette configuration comme non souhaitable, et peuvent choisir d'installer la
fonctionnalité de rapports des services ACS dans une instance distincte de SQL
Server Reporting. Dans ce cas, vous devez définir vos propres groupes et rôles de sécurité, ce
qui produit une surcharge d'administration mais un contrôle très rapproché de l'accès aux
données ACS.
Agent proxy
Operations Manager 2007 peut analyser des périphériques réseau, via SNMP v2, les ordinateurs
n'exécutant pas de système d'exploitation Windows et les ordinateurs sans agents. Dans ces
cas, un autre ordinateur sur lequel un agent est installé effectue en fait l'analyse à distance. Cet
ordinateur est appelé agent proxy. L'agent qui joue le rôle de proxy pour l'analyse d'autres
périphériques est un agent Operations Manager standard. Il est simplement configuré
différemment au moyen de la sélection de l'option Autoriser cet agent à agir en tant que proxy
et découvrir des objets gérés sur d'autres ordinateurs dans les propriétés de l'agent. Vous
configurez ensuite le périphérique géré sans agent pour désigner l'agent proxy qu'il va utiliser.
Pour plus d'informations sur le déploiement des agents et l'administration de périphériques, voir
Operations Manager 2007 Operations Guide (Guide des opérations d'Operations Manager 2007).
Interface de commande d'Operations Manager 2007
En 2006, Microsoft a lancé l'interface de lignes de commande Windows PowerShell qui peut être
utilisée avec les systèmes d'exploitation Windows Server 2003, Windows Server 2008,
Windows XP et Vista. Cette interface a été développée pour les administrateurs systèmes
désireux d'automatiser des tâches. L'interface comprend une invite interactive et un
environnement de script qui peuvent être utilisés indépendamment ou ensemble. Les objets avec
lesquels vous interagissez dans PowerShell sont appelés « command-lets » (cmdlet) et sont des
commandes natives binaires dans Windows PowerShell. Les commandes Windows PowerShell
sont conçues pour gérer les informations structurées en objets, qui sont plus qu'une simple
chaîne de caractères affichée à l'écran. Le résultat de la commande contient toujours des
informations supplémentaires que vous pouvez utiliser si vous en avez besoin.
15
L'interface de commande d'Operations Manager 2007 est le regroupement de 203 command-lets
individuels, développés spécifiquement pour l'automatisation des tâches d'administration
d'Operations Manager 2007. L'interface de commande peut être installée sur n'importe quel
ordinateur sur lequel la console Opérateur est installée.
Fonctionnalités
Les fonctionnalités sont présentes par défaut et, pour les utiliser, une simple configuration suffit.
La capacité de configurer et d'utiliser des fonctionnalités comme il vous plaît dans Operations
Manager 2007 est la marque de sa flexibilité.
Analyse interplateforme (ordinateurs UNIX ou Linux)
Les serveurs d'administration et les serveurs de passerelle d'Operations Manager 2007 R2
peuvent analyser des ordinateurs UNIX et Linux. Pour obtenir une liste complète des systèmes
d'exploitation UNIX et Linux que vous pouvez analyser, voir le guide des configurations prises en
charge à l'adresse http://go.microsoft.com/fwlink/?LinkId=144400.
Dans l'analyse interplateforme, le service d'administration System Center du serveur
d'administration ou du serveur de passerelle exécute toute l'intelligence d'analyse. Le service
d'administration System Center d'analyse communique avec l'ordinateur analysé via une couche
WSMAN se trouvant à la fois sur le serveur d'administration et sur l'ordinateur analysé.
L'installation de la couche WSMAN sur l'ordinateur analysé fait partie de la configuration requise.
La communication entre couches WSMAN se produit via le port TCP n° 1270 et provient toujours
du serveur d'administration ou du serveur de passerelle. Dans certains cas, comme lorsque la
couche WSMAN n'est pas présente sur l'ordinateur analysé ou en cas d'échec, la communication
peut se produire vers SSH TCP 22. SSH peut être utilisé pour l'installation de la couche WSMAN
ou pour réaliser des diagnostics.
16
Analyse des exceptions sans agent
Dans les systèmes d'exploitation Windows, lorsqu'une erreur d'application se produit, le service
Watson peut saisir l'erreur et transférer les informations correspondantes à Microsoft pour
déterminer la cause du problème. En général, chaque ordinateur le fait individuellement. Comme
l'analyse des erreurs et les rapports d'erreurs se produisent individuellement, les administrateurs
informatiques ne voient pas ces exceptions à travers leur organisation.
Même si la fonction d'analyse des exceptions sans agent est activée, toutes les exceptions
peuvent être transférées à un serveur d'administration de votre groupe d'administration et
agrégées. Comme elles sont ensuite concentrées au même endroit, votre entreprise peut utiliser
ces données pour l'analyse et le diagnostic des problèmes d'applications de bureau et de serveur
lorsqu'ils se produisent au sein de votre entreprise. Si vous le décidez, vous pouvez aussi
configurer le serveur d'administration pour qu'il transfère les informations d'analyse des
exceptions au service d'analyse des pannes en ligne de Microsoft. Pour plus d'informations sur
cette rubrique, voir http://go.microsoft.com/fwlink/?LinkID=11699.
17
Structure de connecteurs
La structure de connecteurs est une interface de programmation d'application (API) exposant les
fonctionnalités d'Operations Manager pour s'intégrer aux autres produits d'administration et
technologie, tels les systèmes de dossier d'incident. Elle permet le développement des
connecteurs en mesure d'échanger des informations de façon bidirectionnelle avec Operations
Manager. La structure de connecteurs interagit principalement avec le service d'accès aux
données System Center du serveur d'administration racine. Pour plus d'informations sur le
développement d'applications qui utilisent la structure de connecteur d'Operations Manager 2007,
voir Operations Manager 2007 SDK.
Concepts
Lors de la planification de votre topologie, vous devez comprendre le concept de sécurité basée
sur les rôles telle qu'implémentée dans Operations Manager.
Sécurité basée sur les rôles
La sécurité basée sur les rôles est utilisée pour contrôler les objets que vous pouvez voir et les
actions que vous pouvez entreprendre sur eux. Un rôle est composé de deux parties. La
première est une étendue qui contient les objets auxquels vous pouvez accéder ou que vous
pouvez voir. Par exemple, une étendue peut être définie comme ne contenant rien que des
contrôleurs de domaine ou des serveurs SQL. La deuxième partie est un profil. Chaque profil
définit des actions que vous pouvez appliquer sur les objets visibles. Operations Manager 2007
est fourni avec les cinq profils suivants :

profil Administrateur : ce profil a des privilèges étendus d'accès à Operations Manager ;

profil Opérateur avancé : ce profil a un accès en écriture limité à la configuration des
analyses en configurant des remplacements de règles et d'analyses ;

profil Auteur : ce profil peut créer des éléments de configuration d'analyses, tels règles,
tâches, analyses et affichages ;

profil Opérateur : ce profil peut accéder aux alertes, aux affichages et aux tâches ;

profil Opérateur en lecture seule : ce profil permet d'accéder en lecture seule aux alertes et
affichages ;

profil Opérateur de rapports : ce profil permet d'accéder aux rapports d'Operations
Manager.
Operations Manager contient aussi cinq rôles prédéfinis dont l'étendue est définie globalement.
Par exemple, le rôle Administrateur d'Operations Manager utilise le profil Administrateur et son
étendue est définie globalement, ce qui signifie qu'il peut consulter et manipuler tous les objets
d'Operations Manager. À chacun des profils répertoriés ci-dessus correspond un rôle prédéfini.
En plus des rôles prédéfinis, vous pouvez en créer des nouveaux basés sur les profils Opérateur
avancé, Auteur, Opérateur et Opérateur en lecture seule. Lors de la création d'un nouveau
rôle, une fois que vous avez sélectionné le profil que vous souhaitez utiliser, vous créez ensuite
l'étendue d'objets auquel le rôle aura accès. De cette façon, vous pouvez créer un rôle qui utilise
18
le profil Opérateur est dont l'étendue est limitée à Microsoft Exchange Servers pour les
administrateurs Exchange. Lorsque vous assignez les administrateurs Exchange au rôle (soit par
appartenance à un groupe Active Directory, soit par compte individuel), ils peuvent ouvrir la
console Opérateur, mais ne peuvent voir que les serveurs Exchange et ne peuvent entreprendre
des actions que pour les alertes, affichages et tâches liés à Exchange.
La sécurité basée sur les rôles s'appliquent quel que soit l'accès aux fonctionnalités d'Operations
Manager, par la console Web ou l'interface de commande. Pour plus d'informations sur les rôles
et sur la sécurité basée sur ces derniers, voir le Guide de sécurité d'Operations Manager 2007.
Identification de la configuration requise pour
Operations Manager 2007
La prochaine étape de conception d'Operations Manager porte sur l'identification des conditions
requises de votre société. Ces conditions requises peuvent être divisées en trois catégories : les
conditions requises pour les opérations, les conditions requises en informatique, les conditions
requises ou objectifs d'optimisation. L'étape de collecte des conditions requises est l'étape la plus
importante dans le développement de la conception d'Operations Manager 2007. Lorsque vous
avez une maîtrise approfondie des conditions requises, vous pouvez concevoir une solution qui
cadre avec les attentes. Si les réalisations attendues du projet ne cadrent pas avec les attentes,
le projet peut échouer.
Pour vous assurer que vous maîtrisez les conditions requises de manière approfondie, vous
devez en discuter avec différents groupes de personnes. Pour commencer, vous devez
appréhender les attentes des principaux actionnaires et sponsors. S'ils s'attendent à ce que
Operations Manager accomplisse une tâche qu'il lui est impossible d'effectuer, il vous revient de
les éduquer et de définir correctement les attentes. Vous devez également travailler avec les
groupes qui exploiteront ou utiliseront les données d'Operations Manager. Il ne s'agit pas
uniquement du centre d'assistance et des équipes d'administration d'applications, mais
également de leur direction, tous utiliseront probablement les rapports d'Operations Manager et
souhaiteront connaître l'état de leur application au premier coup d'œil.
À l'issue de la collecte des conditions requises, compilez les données, puis diffusez-les
publiquement à l'attention de toutes les parties prenantes. Il s'agit ici d'une autre occasion de
clarifier les capacités. Pour veiller davantage à l'acceptation des conditions requises, vous
pouvez amener les sponsors et les principaux actionnaires à apposer leur signature en guise
d'approbation.
Conditions opérationnelles requises
Les responsables d'entreprise avec lesquels vous devez travailler ne sont pas simplement les
cadres supérieurs qui financent votre projet Operations Manager ; il s'agit aussi des gestionnaires
et des directeurs responsables des procédures de gestion qui pourvoient les fonds de votre
société. Ils peuvent ne pas particulièrement s'intéresser à Operations Manager en tant que
produit, mais s'intéresser sur le niveau de service que cette technologie apporte dans la prise en
charge des applications essentielles à leurs objectifs.
19
Lorsque vous discutez avec des personnes de cette catégorie, leur intérêt sera probablement
focalisé sur quatre secteurs :

Service informatique continu

Informations sur la performance de leurs applications

Conformité avec les règlements

Retour sur les dépenses en informatique
Service informatique continu
Les responsables d'entreprise s'attendent principalement à ce que l'informatique assure la mise à
jour et l'exécution de leurs applications. Si tel n'est pas le cas, ils doivent en être informés dans
l'immédiat. Ils voudront connaître l'impact d'une panne sur leur procédure de gestion et la durée
prévue. La compréhension de leur procédure de gestion est essentielle à la réalisation de leurs
attentes. Lorsque vous discutez avec eux, prenez soin d'appréhender les points suivants :

Quelles applications utilisent-ils pour effectuer les opérations affectant leur activité de base ?
Cela permet d'identifier les applications auxquelles vous devez consacrer un service
d'analyse de bout en bout.

Quels sont les composants de ces applications ? Cela permet de concevoir un modèle
d'application distribuée que vous allez analyser.

L'application a-t-elle un composant critique qui s'exécute sur des stations de travail ou
d'autres clients ? Cela permet de planifier la stratégie d'analyse de votre client.

Amenez-les à décrire une transaction complète dans leur application. Operations
Manager 2007 peut utiliser des transactions synthétiques pour tester une application de
manière régulière, et fournir les données d'analyse de l'expérience de l'utilisateur final avec
l'application.
Informations sur la performance
Lorsque vous discutez avec les responsables d'entreprise au sujet de la performance des
applications, il est important de distinguer la performance de la procédure de gestion de la
performance de l'application. Les performances de la procédure de gestion (ou métriques) sont
fournies par les applications de l'intelligence d'entreprise, généralement sous la forme de
rapports et de feuilles de marque équilibrées, et elles ne nous concernent pas actuellement. Les
attentes formulées ici sont celles liées à la performance des applications. Assurez-vous
d'appréhender les points suivants et d'en discuter :

Quelles informations sur la performance des applications reçoivent-ils aujourd'hui ?
Qu'aimeraient-ils recevoir ? Cela permet de planifier les rôles (profils et portées).

Comment reçoivent-ils les informations sur la performance des applications aujourd'hui ?
Comment aimeraient-ils les recevoir ? Cela permet de décider de la manière d'accéder aux
informations sur la performance. Par exemple, ont-ils besoin d'une console Opérateur avec
l'accès Opérateur en lecture seule et Rapports étendue à leur application, ou alors la console
Web suffit-elle ?
20
Conformité avec les règlements
La conformité aux règlements est une question critique pour les responsables des procédures de
gestion à l'heure actuelle et pour l'avenir. Les responsables des procédures de gestion
s'attendent à ce que l'informatique contribue aux mesures de mise en conformité de la société
avec les règlements et de mise à jour aux normes applicables. Assurez-vous d'aborder les points
suivants :

La procédure de gestion est-elle conforme aux règlements ? Si oui, que prévoient les
règlements ? Cela permet de planifier vos services ACS et votre rôle.

Quels types de données le responsable des procédures de gestion espère t-il recevoir de
l'informatique, et dans quels délais ? Cela permet de planifier les rapports ainsi que la
rétention des données.
Retour sur les dépenses en informatique
Que ce soit par retour direct d'impayés ou par dépenses indirectes, les responsables d'entreprise
paient pour des services informatiques et, à l'instar de tout bon responsable, ils souhaitent
connaître les retombées de ces dépenses. Vous pouvez utiliser Operations Manager Reporting
comme un moyen de fournir ces réponses, mais vous devez savoir ce qui intéresse le
responsable d'entreprise. Veillez à aborder les points suivants :

Quels sont selon eux les services les plus utiles que leur propose l'informatique ? Cela
permet de planifier les rapports.

Sont-ils conscients de ce qu'ils obtiennent actuellement à partir des frais généraux de
l'informatique ? Cela permet de regrouper les différents rapports qui indiquent les services
fournis au responsable d'entreprise en dehors de leur application.
Conditions requises en informatique
Les conditions requises en informatique permettront de définir la topologie d'Operations Manager
et de son infrastructure de prise en charge. Les deux principaux facteurs qui détermineront les
conditions requises en informatique sont les objectifs d'optimisation et l'environnement
informatique dans lequel Operations Manager sera placé. Vous collecterez ces conditions
requises chez les promoteurs informatiques, les principaux actionnaires et les utilisateurs des
données d'Operations Manager. Ces conversations doivent être faites de questions ouvertes
venant de vous. Commencez par interroger comment utiliser Operations Manager dans
l'environnement, et la finalité de l'optimisation d'une implémentation. Prenez soin d'aborder les
points suivants.
Objectifs d'optimisation
Les objectifs d'optimisation sont les aspects de l'implémentation d'Operations Manager que la
conception doit satisfaire. Ils sont illustrés par des déclarations telles que les suivantes :
21

Disponibilité/Récupérabilité--Operations Manager doit être disponible avec le moins de
pannes possible. Cela permet une haute disponibilité et de prévoir la
sauvegarde/récupération.

Coûts--Operations Manager doit être implémenté de la manière la plus économique possible.
Le fait de le connaître et d'opérer avec des contraintes budgétaires est essentiel à la réussite
du projet.

Performance--Par exemple, Operations Manager doit envoyer les données de
l'environnement en 1 minute maximum, et l'accès à la console doit se produire en
10 secondes maximum une fois la console lancée. Cela permet de prévoir le matériel.

Etendue--Operations Manager doit fournir une seule vue de l'environnement complet. Cela
permet de prévoir le nombre de groupes d'administration nécessaires et le rapport entre ces
groupes.

Administration--L'administration d'Operations Manager doit être restreinte (ou disponible)
pour certains groupes. Cela permet de prévoir les groupes de sécurité, les rôles, les accès,
et éventuellement le nombre de groupes d'administration à implémenter.

Emplacement des points d'accès--Operations Manager doit être accessible uniquement via
l'intranet de la société, ou être disponible en interne et en externe. Cela permet de prévoir
l'emplacement des consoles Opérateur et des consoles Web.

Intégration--Operations Manager doit s'intégrer au système de dossier d'incident ou à d'autre
produit d'analyse de la société. Cela permet de prévoir l'emplacement d'Operations Manager
et ses fonctions dans votre environnement, ainsi que le rôle qu'il devra jouer. Cela permet
également de décider si des connecteurs tiers ou des connecteurs développés par la société
seront nécessaires.
Inventaire de l'environnement actuel
La possession d'un inventaire exact de votre environnement actuel est utile à deux égards.
D'abord, il indique l'élément que Operations Manager analysera, ensuite, il indique les restrictions
ou les limites dans lesquelles il devra fonctionner. Prenez soin d'inclure les points suivants :

Echelle--Le nombre approximatif de périphériques à analyser..

Packs d'administration nécessaires--Les applications à analyser.

Type de périphériques prenant en charge les applications--Cette liste comprend les
ordinateurs Windows, les périphériques réseau, et les ordinateurs UNIX ou Linux.

Topologie--L'emplacement physique et réseau des périphériques à analyser.

Distribution de la topologie et des consoles--L'emplacement physique et réseau des
personnes qui utiliseront les données d'Operations Manager.

Certificat et besoins du serveur de passerelle--Les limites d'approbation Active Directory de
votre environnement.

Administration de routine et produits du centre d'assistance--Tout autre produit permettant
d'effectuer l'analyse, l'alerte et de générer les rapports.
22

Planification de la topologie et de la passerelle--Les lien de pare-feu et des réseaux longue
portée (WAN) qui définissent les limites réseau.

Planification de la topologie et du rôle--Les limites administratives informatiques des
périphériques et des applications analysées.

Topologie et localisation--Les limites linguistiques et géopolitiques dans lesquelles votre
environnement s'étend.
Procédures actuelles de l'inventaire
D'une manière ou d'une autre, tous les environnements sont analysés et gérés. Les techniques et
les technologies utilisées pour ces actions varient selon les niveaux de sophistication et de
maturité. Suivant le Modèle d'optimisation des infrastructures, tous les environnements peuvent
être décrits à l'aide de quatre catégories : Basique, standardisé, Rationalisé et Dynamique. Voir
http://go.microsoft.com/fwlink/?LinkId=92863 et l'Évaluation de l'optimisation des infrastructures
pour plus d'informations sur ces quatre catégories, et sur un outil d'auto-évaluation permettant
d'évaluer l'emplacement dans lequel demeurent votre processus et votre environnement.
Pour prévoir le mode d'utilisation des capacités d'Operations Manager 2007, vous devez
comprendre les procédures utilisées actuellement pour l'analyse et la gestion de votre
environnement. Cela permet de planifier la manière de répondre aux informations d'alerte et la
personne à affecter à cette tâche. Cela permettra de prévoir comment les notifications sont
envoyées et qui les reçoit. Vous pourrez en outre planifier le contrôle administratif des groupes
d'administration et de la sécurité des données.
Voici les principales questions que vous devez poser à ce stade :

Comment mon organisation effectue-t-elle l'analyse à l'heure actuelle ?

Comment mon organisation réagit-elle en ce qui concerne les informations fournies par le
processus/le système d'analyse ?
Prenez également soin d'aborder les points suivants :

Qui est ce qui répond généralement aux questions ou alertes émises par les systèmes
automatisés ou les centres d'assistance ? Cela permet de déterminer ceux qui nécessitent un
accès direct à la console Opérateur, et les données que la console doit contenir.

Le centre d'assistance résout-il habituellement les problèmes de serveur, ou sont-ils
transférés aux équipes de prise en charge du serveur ?

La société dispose-t-elle d'un Centre d'exploitation réseau piloté ou d'autres systèmes
d'analyse pilotés ? Si oui, combien de personnes et combien de consoles sont utilisées en
permanence ? Cela permet de déterminer l'emplacement auquel les groupes d'administration
peuvent être placés afin d'y recevoir la prise en charge adéquate.

Combien d'emplacements autres que les centres de traitement connaîtront un déploiement
d'agents, et où se trouvent-ils dans le réseau ?

Quelles sont les statistiques de la bande passante disponible entre les sites sur lesquels se
trouvent les périphériques gérés et ceux dans lesquels se trouvent les serveurs
d'administration ?
23

Comment se déroule actuellement la journalisation de sécurité ?

Comment sont actuellement analysées les applications de bureau ou les applications
clients ?

Comment se déroule l'analyse pour les ordinateurs et périphériques réseau fonctionnant
sous UNIX ou Linux ?
Mappage de la configuration requise à une
conception pour Operations Manager 2007
Mappage de la configuration requise à une conception
Dans la section précédente, vous avez effectué les trois tâches suivantes :

Vous avez collecté les conditions requises pour les opérations, afin de planifier les
fonctionnalités Operations Manager à implémenter.

Vous avez collecté les conditions requises pour les technologies de l'information, afin de
planifier la topologie des groupes d'administration.

Vous avez répertorié les méthodes actuelles d'analyse, afin de planifier la configuration
d'Operations Manager.
Cette section vous guide à travers les décisions de conception requises pour le mappage de
toutes les informations et les connaissances collectées aux fins d'une conception réelle. Pour ce
faire, utilisez les bonnes pratiques d'évaluation et de planification de capacité pour les rôles et les
composants serveur.
Conception du groupe d'administration
Toutes les implémentations d'Operations Manager 2007 comprennent au moins un groupe
d'administration et, compte tenu de l'évolutivité d'Operations Manager 2007, certaines
implémentations peuvent nécessiter un seul groupe d'administration. Selon les conditions
requises de la société, des groupes d'administration supplémentaires peuvent être
immédiatement requis ou ajoutés au fil du temps. Le processus de distribution des services
Operations Manager vers plusieurs groupes d'administration est appelé partition.
Cette section porte sur les critères généraux pouvant nécessiter plusieurs groupes
d'administration. La planification de la composition des groupes d'administration individuels, telle
que la détermination de l'évaluation des serveurs et la distribution des rôles d'Operations
Manager entre les serveurs d'un groupe d'administration, est abordée dans la section
« Composition d'un groupe d'administration ».
Un groupe d'administration
Envisagez de planifier le groupe d'administration d'Operations Manager de la même façon que
vous avez planifié le domaine Active Directory : commencez avec un groupe d'administration, et
24
procédez à des ajouts selon les besoins. Un seul groupe d'administration Operations Manager
2007 R2 peut s'étendre jusqu'aux limites conseillées ci-après :

3 000 agents affectés à un serveur d'administration.

La plupart des conditions requises en terme d'évolutivité, de redondance et de récupération
d'urgence peuvent être remplies à l'aide de trois à cinq serveurs d'administration d'un groupe
d'administration.

50 consoles Opérateur s'affichent simultanément.

1 500 agents affectés à un serveur de passerelle.

25 000 machines d'analyse des erreurs d'application (AEM) affectées à un serveur
d'administration dédié.

100 000 machines AEM affectées à un groupe d'administration dédié.

2 500 agents d'analyse collective affectés à un serveur d'administration.

10 000 agents d'analyse collective affectés à un groupe d'administration.

6 000 agents et ordinateurs UNIX ou Linux par groupe d'administration avec 50 consoles
ouvertes

10 000 agents et ordinateurs UNIX ou Linux par groupe d'administration avec 25 consoles
ouvertes

500 ordinateurs UNIX ou Linux analysés par serveur d'administration dédié.

100 ordinateurs UNIX ou Linux analysés par passerelle dédiée

3 000 URL peuvent être analysées par serveur d'administration dédié

12 000 URL peuvent être analysées par groupe d'administration dédié
Cliquez sur ce lien pour consulter les limites recommandées pour Operations Manager 2007
SP1.
Lorsque vous évaluez ces limites conjointement avec les portées de sécurité offertes par
l'utilisation des rôles d'Operations Manager pour contrôler l'accès aux données de la console
Opérateur, un groupe d'administration unique est adaptable et conviendra dans plusieurs
situations.
Groupes d'administration multiples et partition
Quelle que soit l'évolutivité d'un groupe d'administration, si les conditions requises incluent l'un
des scénarios suivants, vous aurez besoin de plus d'un groupe d'administration :

Fonctionnalité Production et pré-production — Dans Operations Manager, il est plus pratique
d'avoir une implémentation de production, afin d'analyser les applications de production, et
une implémentation pré-production, ayant une interaction minimale avec l'environnement de
production. Le groupe d'administration pré-production permet de tester et de régler la
fonctionnalité des packs d'administration avant qu'elle ne passe dans l'environnement de
production. En outre, certaines sociétés emploient un environnement de mise en scène de
serveurs dans lequel les serveurs nouvellement conçus sont placés pendant une période de
rodage avant d'être affectés à la production. Le groupe d'administration pré-production
25
permet d'analyser l'environnement de mise en scène afin de veiller à l'intégrité des serveurs
avant le déploiement de la production.

Fonctionnalité ACS dédiée — Si les conditions requises incluent la nécessité de collecter les
événements du journal de sécurité d'audit Windows, vous devez implémenter les services
ACS. Il peut être avantageux d'implémenter un groupe d'administration prenant spécialement
en charge la fonction ACS, si les conditions requises de votre société nécessitent que la
fonction ACS soit contrôlée et administrée par un groupe d'administration autre que celui qui
gère le reste de l'environnement de production.

Fonctionnalité de récupération d'urgence — Dans Operations Manager 2007, toutes les
interactions avec la base de données Operations Manager sont enregistrées dans les
journaux des transactions avant d'être confiées à la base de données. Ces journaux des
transactions peuvent être envoyés à un autre serveur Microsoft SQL Server 2005 SP1 ou
version ultérieure, ou Microsoft SQL Server 2008 SP1, et confiées à une copie de la base de
données Operations Manager. Cette technique est appelée envoi de journaux. Le groupe
d'administration de destination ou de basculement ne doit pas nécessairement être actif et
entièrement rempli. Il peut contenir uniquement un serveur d'administration racine (RMS, root
management server) et un serveur SQL Server 2005 SP1 ou ultérieur, ou SQL Server 2008
SP1. S'il est nécessaire d'effectuer un basculement, les serveurs d'administration restants
dans le groupe d'administration source nécessitent une modification de registre et un
redémarrage pour agir comme membres du groupe d'administration de basculement.

Augmentation de capacité — Operations Manager 2007 ne dispose pas de limites intégrées
en ce qui concerne le nombre d'agents qu'un groupe d'administration individuel peut prendre
en charge. En fonction du logiciel utilisé et de la charge d'analyse (le déploiement de
plusieurs packs d'administration entraîne l'augmentation de la charge d'analyse) sur le
groupe d'administration, plusieurs groupes d'administration peuvent être nécessaires afin de
maintenir une performance acceptable.

Affichages consolidés — Lorsque plusieurs groupes d'administration permettent d'analyser
un environnement, un mécanisme est requis pour fournir un affichage consolidé des données
d'analyse et d'alerte provenant de ces groupes. Pour cela, déployez un groupe
d'administration supplémentaire (avec ou sans responsabilités d'analyse) capable d'accéder
à toutes les données de tous les autres groupes d'administration. Ainsi, ces groupes
d'administration sont dits connectés. Le groupe d'administration utilisé pour fournir un
affichage consolidé des données est appelé Groupe d'administration local, et les autres qui
lui fournissent des données sont appelés Groupes d'administration connectés.

Langues installées — Tous les serveurs pourvus d'un rôle de serveur Operations Manager
doivent être installés dans la même langue. Autrement dit, il est impossible d'installer le
serveur RMS avec la version anglaise d'Operations Manager 2007, et de déployer ensuite la
console Opérateur à l'aide de la version japonaise. Si l'analyse doit s'étendre à plusieurs
langues, il est nécessaire de prévoir des groupes d'administration supplémentaires pour
chaque langue des opérateurs.

Sécurité et administration — La partition des groupes d'administration pour des raisons de
sécurité et d'administration est très semblable au fait de déléguer le pouvoir administratif, via
26
les unités organisationnelles Active Directory ou les domaines, aux différents groupes
d'administration. Votre société peut comprendre plusieurs groupes informatiques, chacun
avec sa propre zone de responsabilité. Cette zone peut être une certaine zone géographique
ou un certain secteur d'opérations. Par exemple, dans le cas d'une société de portefeuille,
elle peut s'étendre sur l'une des filiales. En cas de délégation totale d'autorité administrative à
partir des groupes informatiques centralisés, il peut être judicieux d'implémenter les
structures des groupes d'administration dans chacune des zones. Ils peuvent être définis sur
un état de groupe d'administration connecté à celui de groupe d'administration local
disponible dans le centre des données informatiques centralisées.
Les scénarios précédents donnent une vision précise sur le nombre de groupes d'administration
nécessaires dans l'infrastructure d'Operations Manager. La section suivante porte sur la
distribution des rôles de serveur dans un groupe d'administration et les conditions d'évaluation
requises pour ces systèmes.
Composition d'un groupe d'administration
Il existe peu de restrictions en matière d’organisation des composants serveur d'Operations
manager dans un groupe d'administration. Ils peuvent être tous installés sur le même serveur
(sauf le rôle de serveur de passerelle), ou distribués sur plusieurs serveurs dans différentes
combinaisons. Certains rôles peuvent être installés dans un service de Cluster (précédemment
connu en tant que MSCS) en tant que cluster de basculement pour une plus grande disponibilité,
et plusieurs serveurs d'administration peuvent être installés pour permettre le basculement entre
les agents. Vous devez choisir la manière de distribuer les composants serveur Operations
Manager ainsi que les types de serveurs que vous allez utiliser en fonction des conditions
informatiques requises et des objectifs d'optimisation.
Compatibilité des rôles de serveur
Un groupe d'administration Operations Manager 2007 peut fournir une multitude de services. Ces
services peuvent être distribués à des serveurs spécifiques, attribuant ainsi un rôle spécifique à
un serveur. Les rôles de serveur et les services ne peuvent pas tous coexister. Le tableau suivant
répertorie les compatibilités et les dépendances et vérifie si le rôle peut être installé sur un cluster
de basculement :
Rôle de serveur
Compatible avec
Conditions requises
d'autres rôles
Peut être placé dans
un cluster de
basculement en
quorum
Base de données
opérationnelle
Oui
SQL
Oui
Base de données de
services ACS
Oui
SQL
Oui
27
Rôle de serveur
Compatible avec
Conditions requises
d'autres rôles
Peut être placé dans
un cluster de
basculement en
quorum
Base de données de
l'entrepôt de données
de rapports
Oui
SQL
Oui
Base de données
Rapports
Oui
Instance dédiée du
Oui
serveur SQL Reporting
Services ; non disponible
sur un contrôleur de
domaine
serveur d'administration Oui
racine
Non compatible avec le
rôle de serveur
d'administration ou de
serveur de passerelle
Oui
serveur d'administration Oui
Non compatible avec le
serveur d'administration
racine
Non
Console Administrateur
Oui
Windows XP, Windows
Vista, Windows
Server 2003 et Windows
Server 2008
Non applicable
collecteur des services
ACS
Oui
Peut être combiné avec
le serveur de passerelle
et avec la base de
données d'audit
Non
serveur de passerelle
Oui
Peut être combiné
uniquement avec le
collecteur des services
ACS ; doit être un
membre de domaine
Non
Serveur de console
Web
Oui
agent
Oui
Non applicable
Déployé
automatiquement vers le
serveur d'administration
racine et vers le serveur
d'administration d'un
Non applicable
28
Rôle de serveur
Compatible avec
Conditions requises
d'autres rôles
Peut être placé dans
un cluster de
basculement en
quorum
groupe d'administration
Toutes les recommandations faites ici sont basées sur les trois hypothèses suivantes :

Les chiffres du sous-système disque sont basés sur les lecteurs pouvant prendre en charge
125 opérations aléatoires d'E/S par seconde et par disque. Plusieurs lecteurs peuvent
prendre en charge des taux d'E/S élevés, ce qui peut diminuer le nombre de lecteurs requis
pour votre configuration.

Dans les groupes d'administration avec des serveurs d'administration déployés en plus du
serveur d'administration racine, tous les agents doivent utiliser les serveurs d'administration
comme serveurs d'administration primaire et secondaire, mais aucun ne doit utiliser le
serveur d'administration racine comme serveur d'administration primaire ou secondaire.

L'aide relative à l'Analyse des exceptions sans agent suppose qu'il se produit une à deux
pannes par machine et par semaine, avec des fichiers CAB d'une taille moyenne de 500 Ko.

L'analyse par client collectif inclut uniquement les packs d'administration spécifiques aux
clients initiaux, y compris Windows Vista, Windows XP et les packs d'administration
Information Worker.

Toute connectivité entre les agents et les serveurs est de 100 Mbps ou valeur supérieure.
Disponibilité
La nécessité d'une disponibilité élevée des bases de données, du serveur d'administration racine,
des serveurs d'administration et des serveurs de passerelle peut être résolue en générant une
redondance dans le groupe d'administration.

Base de données — Toutes les bases de données utilisées dans Operations Manager 2007
nécessitent Microsoft SQL Server 2005 SP1 ou version supérieure ou Microsoft SQL
Server 2008 SP1 ou version supérieure, dont l'installation peut être effectuée à l'aide d'une
configuration de basculement du nœud de quorum MSCS.
Remarque
Pour plus d'informations sur les services de cluster, consultez l'aide en ligne de
Windows Server 2003 et de Windows Server 2008.

Serveur d'administration racine — Le service d'accès aux données System Center et le
service de configuration de l'administration System Center s'exécutent uniquement sur le
serveur d'administration racine, ce qui en fait un point de défaillance unique dans le groupe
d'administration. Puisque le serveur d'administration racine joue un rôle crucial, si les
conditions requises incluent une haute disponibilité, ce serveur doit également être installé
dans son propre cluster de basculement à double nœuds. Pour plus d'informations sur la
29
mise en cluster du serveur d'administration racine, voir le Guide de déploiement Operations
Manager 2007.

Serveurs d'administration — Dans Operations Manager, les agents d'un groupe
d'administration peuvent envoyer des rapports à tout serveur d'administration de ce groupe.
Par conséquent, la présence de plus d'un serveur d'administration fournit des chemins
redondants pour la communication entre l'agent et le serveur. Ainsi, le meilleur moyen est de
déployer un ou deux serveurs d'administration en plus du serveur d'administration racine, et
d'utiliser l'Assistant d'affectation et de basculement des agents pour affecter les agents aux
serveurs d'administration et exclure le serveur d'administration racine de la gestion des
agents.

Serveurs de passerelle — Les serveurs de passerelle jouent le rôle d'intermédiaire de
communications entre les serveurs d'administration et les agents situés en dehors de la limite
d'approbation Kerberos des serveurs d'administration. Les agents peuvent basculer entre les
serveurs de passerelle de même qu'entre les serveurs d'administration en cas de perte de
communication avec le serveur primaire ou l'un des serveurs. De même, les serveurs de
passerelle peuvent être configurés pour basculer entre les serveurs d'administration, en
fournissant un jeu redondant de voies d'accès allant des agents aux serveurs
d'administration. Pour les procédures concernant le déploiement de cette configuration, voir
le Guide de déploiement d'Operations Manager 2007.
Coût
Plus les rôles de serveur des groupes d'administration sont distribués, plus les ressources
nécessaires pour prendre en charge cette configuration seront nombreuses. Il s'agit du matériel,
de l'environnement, de l'octroi de licences, des opérations et des charges d'entretien. Une
conception axée sur le contrôle des coûts et les objectifs d'optimisation amène à implémenter un
seul serveur ou à distribuer un rôle minimal ; ce qui en retour diminue la redondance et
éventuellement la performance.
Performances
Si la performance est choisie comme objectif d'optimisation, vous obtiendrez de meilleurs
résultats, grâce à une configuration mieux distribuée et à un matériel haut de gamme.
Proportionnellement, les coûts augmenteront.
Distribution de la console et emplacement des points d'accès
La console Opérateur communique directement avec le serveur d'administration racine, ainsi
qu'avec le serveur de rapports, lorsque le composant Reporting est installé. La planification de
l'emplacement du serveur d'administration racine et des serveurs de base de données par
rapport à la console Opérateur est alors cruciale pour les performances. Veillez à maintenir ces
composants à proximité en réseau.
30
Recommandations relatives à la distribution des composants et à
l'évaluation de la plate-forme
Les tableaux suivants présentent les recommandations relatives à la distribution des composants
et au dimensionnement de plate-forme pour Operations Manager 2007 R2. Cliquez sur ce lien
pour consulter les recommandations relatives à la distribution des composants et au
dimensionnement de plate-forme pour Operations Manager 2007 SP1. Dans ces tableaux, DB
est un serveur de base de données SQL, DW est un serveur de base de données SQL, RS est le
serveur de rapports, RMS est le serveur d'administration racine et MS est un serveur
d'administration. La conception et la planification de base des services ACS sont présentées plus
loin dans cet article.
Serveur unique, scénario intégré
No de périphériques analysés
Rôles et configuration des serveurs
15 à 250 ordinateurs Windows, 200 ordinateurs
UNIX ou Linux
DB, DW, RS, RMS ;
RAID 0+1, 4 disques, 8 Go de RAM,
processeurs à quatre cœurs
Serveurs multiples, petit scénario
No de périphériques analysés
250 à 500 ordinateurs
Windows, 500 ordinateurs
UNIX ou Linux
Rôles et configuration des
Rôles et configuration des
serveurs
serveurs
DB, DW, RS ;
serveur d'administration
racine ;
RAID 0+1, 4 disques, 4 Go de
RAM, biprocesseurs
RAID 1, 2 disques, 4 Go de
RAM, biprocesseurs
Serveurs multiples, scénario moyen
Pour permettre la redondance, vous pouvez déployer plusieurs serveurs d’administration, chacun
d’entre eux avec la configuration minimale décrite. Pour permettre une haute disponibilité des
serveurs d'administration racine et de base de données, vous pouvez les déployer en cluster et
doter chaque nœud de la configuration minimale décrite en plus des connexions à un disque
partagé en externe pour les ressources de cluster.
No de
Rôle et
Rôle et
Rôle et
Rôle et
périphériques
configuration du
configuration du
configuration du
configuration du
analysés
serveur
serveur
serveur
serveur
500 à
750 ordinateurs
DB ;
MS ;
DW, RS ;
RAID 0+1,
RAID 1,
RAID 0+1,
serveur
d'administration
31
No de
Rôle et
Rôle et
Rôle et
Rôle et
périphériques
configuration du
configuration du
configuration du
configuration du
analysés
serveur
serveur
serveur
serveur
Windows,
500 ordinateurs
UNIX ou Linux
4 disques, 4 Go
de RAM,
biprocesseurs
2 disques, 4 Go
de RAM,
biprocesseurs
4 disques
(données),
RAID 1,
2 disques
(journaux), 4 Go
de RAM,
biprocesseurs
racine ;
RAID 1, 2 disques,
8 Go de RAM,
biprocesseurs
Serveurs multiples, scénario élargi
Pour permettre la redondance, vous pouvez déployer plusieurs serveurs d’administration, chacun
d’entre eux avec la configuration minimale décrite. Pour permettre une haute disponibilité des
serveurs d'administration racine et de base de données, vous pouvez les déployer en cluster et
doter chaque nœud de la configuration minimale décrite en plus des connexions à un disque
partagé en externe pour les ressources de cluster.
No de
Rôle et
Rôle et
Rôle et
Rôle et
Rôle et
périphériques
configuration
configuration
configuration
configuration
configuration
analysés
du serveur
du serveur
du serveur
du serveur
du serveur
750 à 1
000 ordinateurs
Windows,
UNIX ou Linux
DB ;
DW ;
RS ;
RAID 0+1,
4 disques
(données),
RAID 1,
2 disques
(journaux),
8 Go de
RAM,
biprocesseurs
RAID 0+1,
4 disques
(données),
RAID 1,
2 disques
(journaux),
8 Go de RAM,
biprocesseurs.
Remarque :
Une
configuration
RAID 5 avec
des
performances
similaires peut
être utilisée
pour répondre
aux besoins
de stockage
serveur
MS ;
d'administration RAID 1,
RAID 1,
racine ;
2 disques,
2 disques,
4 Go de
RAID 1,
4 Go de
RAM,
2 disques, 8 Go RAM,
biprocesseurs de RAM,
processeurs
biprocesseurs
à quatre
cœurs
32
No de
Rôle et
Rôle et
Rôle et
Rôle et
Rôle et
périphériques
configuration
configuration
configuration
configuration
configuration
analysés
du serveur
du serveur
du serveur
du serveur
du serveur
d'entrepôt de
données.
Serveurs multiples, société
Pour permettre la redondance, vous pouvez déployer plusieurs serveurs d’administration, chacun
d’entre eux avec la configuration minimale décrite. Pour permettre une haute disponibilité des
serveurs d'administration racine et de base de données, vous pouvez les déployer en cluster et
doter chaque nœud de la configuration minimale décrite en plus des connexions à un disque
partagé en externe pour les ressources de cluster.
No de
Rôle et
Rôle et
Rôle et
Rôle et
Rôle et
périphériques
configuration
configuration
configuration
configuration
configuration
analysés
du serveur
du serveur
du serveur
du serveur
du serveur
1 000 à
3 000 ordinateurs
Windows, 500
ordinateurs UNIX
ou Linux
DB ;
DW ;
RS ;
RAID 0+1,
8 disques
(données),
RAID 1,
2 disques
(journaux),
8 Go de
RAM,
processeurs
à quatre
cœurs
RAID 0+1,
8 disques
(données),
RAID 1,
2 disques
(journaux),
8 Go de RAM,
processeurs à
quatre cœurs
RAID 1, 2
disques,
4 Go de
RAM
serveur
MS ;
d'administration RAID 0+1,
racine ;
4 disques,
RAID 0+1,
8 Go de
4 disques,
RAM,
12 Go de RAM, processeurs
processeurs à
à quatre
quatre cœurs
cœurs
64 bits
DB ;
DW ;
RS ;
RAID 0+1,
14 disques
(données),
RAID 1,
2 disques
(journaux),
16 Go de
RAM,
processeurs
à quatre
cœurs
RAID 0+1,
14 disques
(données),
RAID 1,
2 disques
(journaux),
16 Go de
RAM,
biprocesseurs
à quatre
cœurs. Une
RAID 1,
2 disques,
4 Go de
RAM,
processeurs
à quatre
cœurs
3 000 à
6 000 ordinateurs
Windows, UNIX
ou Linux
processeurs
à quatre
cœurs
serveur
MS ;
d'administration RAID 0+1,
racine ;
2 disques,
RAID 0+1,
8 Go de
4 disques,
RAM,
16 Go de RAM, processeurs
processeurs à
à quatre
quatre cœurs
cœurs
33
No de
Rôle et
Rôle et
Rôle et
Rôle et
Rôle et
périphériques
configuration
configuration
configuration
configuration
configuration
analysés
du serveur
du serveur
du serveur
du serveur
du serveur
configuration
RAID 5 avec
des
performances
similaires
peut être
utilisée pour
répondre aux
besoins de
stockage
d'entrepôt de
données.
Recommandations et bonnes pratiques applicables aux composants
Outre les recommandations sur l'évaluation énoncées ci-dessus, il existe d'autres considérations
et pratiques recommandées à prendre en compte lors de la planification de chaque composant
serveur Operations Manager.
Recommandations et bonnes pratiques applicables au serveur d'administration racine
Sur le serveur d'administration racine, les ressources les plus essentielles sont la RAM et l'UC,
puisque la plupart des opérations qu'il exécute nécessitent beaucoup de mémoire et causent par
conséquent une pagination excessive. Les facteurs influençant la charge du serveur
d'administration racine sont les suivants :

Le nombre d'agents du groupe d'administration — Étant donné que le serveur
d'administration racine doit calculer la configuration de tous les agents d'un groupe
d'administration, l'augmentation du nombre d'agents accroît la quantité de mémoire requise
sur le serveur d'administration racine, indépendamment du volume des données
opérationnelles que les agents envoient.

Le taux des modifications d'espace d'instances — L'espace d'instances correspond aux
données que Operations Manager conserve pour décrire tous les ordinateurs, les services et
les applications analysés dans un groupe d'administration. Lorsque ces données changent
fréquemment, il est nécessaire d'ajouter d'autres ressources au serveur d'administration
racine pour lui permettre de calculer les mises à jour de configuration des agents affectés. Le
taux des modifications d'espace d'instances augmente au fur et à mesure que vous importez
d'autres packs d'administration dans votre groupe d'administration. En outre, l'ajout de
nouveaux agents au groupe d’administration augmente temporairement le taux des
modifications d'espace d'instances.
34

Le nombre de consoles Opérateur concurrentes et de clients SDK supplémentaires — Les
clients SDK supplémentaires comprennent, par exemple, la console Web et plusieurs outils
tiers connectés à Operations Manager. Puisque le service SDK se trouve sur le serveur
d'administration racine, chaque connexion supplémentaire utilise la mémoire et l'UC.
Bonnes pratiques relatives à l'évaluation du serveur d'administration racine :

Utilisation de matériel et de système d'exploitation 64 bits — L'utilisation du matériel 64 bits
permet d'augmenter facilement la mémoire au-delà de 4 Go. Même si le déploiement actuel
ne nécessite pas plus de 4 Go de RAM, l'utilisation de matériel 64 bits permet de ménager la
croissance éventuelle de vos besoins futurs.

Limitation du nombre ou élimination d'agents affectés au serveur d'administration racine —
Dans les groupes d'administration avec un petit nombre d'agents, il est généralement
conseillé de placer les agents sous la supervision directe du serveur d'administration racine.
Cela permet de réduire le coût global du matériel requis pour votre installation. Cependant,
au fur et à mesure que le nombre d'agents augmente, pensez à empêcher les agents
d'envoyer directement des rapports au serveur d'administration racine. Le déplacement de la
charge de travail des agents vers d'autres serveurs d'administration réduit les conditions
requises pour le matériel du serveur d'administration racine, et entraîne généralement
l'amélioration de la performance et de la fiabilité du groupe d'administration.

Assurez une haute connectivité de la bande passante disponible sur le réseau vers la base
de données et l'entrepôt de données Operations Manager — Le serveur d'administration
racine communique fréquemment avec la base de données opérationnelle et avec l'entrepôt
de données. En général, ces connexions SQL sont plus gourmandes en bande passante et
plus sensibles à la latence réseau que les connexions entre les agents et le serveur
d'administration racine. C’est pourquoi, vous vous assurerez généralement que serveur
d'administration racine, base de données Operations Manager et base de données de
l'entrepôt de données sont sur le même réseau local.
Recommandations et bonnes pratiques applicables à la base de données opérationnelle
Comme c'est le cas dans toutes les applications de base de données, la performance de la base
de données opérationnelle dépend surtout de celle du sous-système disque. Étant donné que
toutes les données d'Operations Manager circulent à travers la base de données Operations
Manager, plus le disque est rapide, plus la performance s'en trouve améliorée. L'UC et la
mémoire affectent également la performance. Les facteurs qui influencent la charge de la base
de données Operations manager sont les suivants :

Le taux de collecte de données — Le serveur d'administration racine communique
fréquemment avec la base de données opérationnelle et avec l'entrepôt de données. En
général, ces connexions SQL sont plus gourmandes en bande passante et plus sensibles à
la latence réseau que les connexions entre les agents et le serveur d'administration racine.
C’est pourquoi, vous vous assurerez généralement que serveur d'administration racine, base
de données Operations Manager et base de données de l'entrepôt de données sont sur le
même réseau local.
35

Le taux des modifications d'espace d'instances — L'espace d'instances correspond aux
données que Operations Manager conserve pour décrire tous les ordinateurs, les services et
les applications analysés dans un groupe d'administration. La mise à niveau de ces données
dans la base de données Operations Manager est fastidieuse pour ce qui est d'écrire de
nouvelles données opérationnelles dans la base de données. En outre, en cas de
modification des données d'espace d'instances, le serveur d'administration racine envoie une
requête à la base de données OperationsManager lui demandant de calculer les
modifications de la configuration et des groupes. Le taux des modifications d'espace
d'instances augmente au fur et à mesure que vous importez d'autres packs d'administration
dans votre groupe d'administration. En outre, l'ajout de nouveaux agents au groupe
d’administration augmente temporairement le taux des modifications d'espace d'instances.

Consoles Opérateur concurrentes et clients SDK supplémentaires — Chaque instance
d'ouverture de la console Opérateur lit des données dans la base de données Operations
Manager. L'interrogation de ces données est gourmande en quantité d'activité de disque
ainsi qu'en UC et en RAM. Les consoles affichant de grandes quantités de données
opérationnelles dans l'affichage des événements, l'affichage des états, l'affichage des alertes
et l'affichage des données de performance, ont tendance à placer les charges les plus
grandes dans la base de données. Pour obtenir une évolutivité maximale, envisagez de
dimensionner les affichages pour inclure uniquement les données nécessaires.
Bonnes pratiques pour l'évaluation du serveur de la base de données Operations Manager :

Choisissez un sous-système disque approprié — Le sous-système disque de la base de
données Operations Manager est le composant le plus utile en terme d'évolutivité et de
performance globale du groupe d'administration. Généralement, le volume disque de la base
de données doit être RAID 0+1 avec un nombre suffisant de piles. Le choix de RAID 5 est
généralement inapproprié pour ce composant, étant donné qu'il optimise l'espace de
stockage au détriment de la performance. Puisque le facteur primaire relatif au choix d'un
sous-système disque pour la base de données Operations Manager est la performance, au
lieu de l'espace de stockage global, il est plus approprié d'utiliser la méthode RAID 0+1.
Lorsque les besoins en terme d'évolutivité ne dépassent pas le débit d'un seul lecteur, la
méthode RAID 1 est généralement le choix approprié puisqu'elle fournit une tolérance aux
pannes sans pénaliser la performance.

Le placement des fichiers de données et des journaux de transaction — Pour les
déploiements de bas niveau, il est généralement coûteux de combiner le fichier de données
SQL et les journaux des transactions sur un seul volume physique, étant donné que la
quantité d'activités générées par le journal des transactions n'est pas très élevée. Toutefois,
au fur et à mesure que le nombre d'agents augmente, vous devez envisager de placer le
fichier de données SQL et le journal des transactions sur des volumes physiques distincts.
Cela permet au volume des journaux des transactions de lire et d'écrire de manière plus
efficace. Cela est dû au fait que la charge de travail consistera principalement d'écritures
séquentielles. Un volume RAID 1 à deux piles est capable de gérer des volumes importants
d'écritures séquentielles et doit suffire pour la plupart des déploiements, même ceux de très
haut niveau.
36

Utilisation de matériel et de système d'exploitation 64 bits — La base de données Operations
Manager utilise souvent une RAM de grande capacité, ce qui peut être un moyen
économique de réduire l'activité disque effectuée sur ce serveur. L’utilisation d'un matériel
64 bits permet d’augmenter facilement la mémoire à plus de 4 Go. Même si le déploiement
actuel ne requiert pas plus de 4 Mo de RAM, l’utilisation de matériel 64 bits permet de
ménager la croissance éventuelle des besoins futurs.

Utilisation d'un contrôleur de disques avec cache d'écriture à pile de secours — L'essai
révèle que la charge de travail sur la base de données Operations Manager tire parti du
cache d'écriture des contrôleurs de disques. Lors de la configuration de la cache d'écriture
par rapport au cache d'écriture des contrôleurs de disques, il est conseillé d'allouer 100
pourcent du cache au cache d'écriture. Lors de l’utilisation avec toute base de données de
contrôleurs de disques avec cache d’écriture, il est crucial de s’assurer qu’ils disposent d’un
système de sauvegarde alimenté par batterie pour éviter les pertes de données en cas de
panne.
Recommandations et bonnes pratiques applicables à l'entrepôt de données
Dans Operations Manager 2007, les données sont écrites dans l'entrepôt de données presque en
temps réel. Ainsi, la charge qu'il contient est semblable à la charge de l'ordinateur de base de
données Operations Manager. Puisqu'il s'agit d'un serveur SQL, le sous-système disque est plus
essentiel à la performance globale, suivi de la mémoire et de l'UC. Operations Manager
Reporting Services place également une charge légèrement différente sur le serveur de l'entrepôt
de données. Les facteurs qui influencent la charge de la base de données Operations manager
sont les suivants :

Le taux d'insertion des données — Pour pouvoir générer les rapports avec plus d'efficacité,
l'entrepôt de données calcule et stocke les données agrégées, en plus d'une quantité
restreinte de données brutes. L'exécution de cette tâche supplémentaire signifie que la
collecte des données opérationnelles dans l'entrepôt de données peut être un peu plus
coûteuse que dans la base de données Operations Manager. Ce coût supplémentaire est
généralement compensé par la réduction du coût de traitement des données de détection
dans l'entrepôt de données par opposition à leur traitement dans la base de données
Operations Manager.

Le nombre d'utilisateurs de rapports simultanés — Puisque les rapports récapitulent
fréquemment de grands volumes de données, chaque utilisateur de rapports peut placer une
charge considérable sur le système. Le nombre de rapports exécutés en même temps, et le
type des rapports exécutés, influencent les besoins en capacité totale. Généralement, les
rapports qui interrogent des plages de données ou des quantités importantes d'objets
nécessitent plus de ressources système.
Bonnes pratiques applicables à l'évaluation du serveur de l'entrepôt de données :

Le choix d'un sous-système disque approprié — Étant donné que l'entrepôt de données est à
présent une composante du flux global des données à travers le groupe d'administration, il
est très important de choisir un sous-système disque approprié pour l'entrepôt de données.
Comme dans la base de données Operations Manager, la méthode RAID 0+1 s'avère
37
souvent être le meilleur choix. En général, le sous-système disque de l'entrepôt de données
doit être semblable au sous-système disque de la base de données Operations Manager.

Le placement des fichiers de données et des journaux des transactions — Comme dans la
base de données Operations Manager, la séparation des données SQL et des journaux des
transactions est généralement un choix approprié aussi longtemps que vous augmentez le
nombre d'agents. Si la base de données Operations Manager et l'entrepôt de données se
trouvent sur le même ordinateur physique et que vous souhaitez séparer les données et les
journaux des transactions, vous devez placer les journaux des transactions de la base de
données Operations Manager sur un volume physique distinct de l'entrepôt de données pour
constater l'avantage obtenu. Les fichiers de données de la base de données Operations
Manager et l'entrepôt de données peuvent partager le même volume physique tant qu'il est
bien évalué.

Utilisation de matériel et de système d'exploitation 64 bits — L'entrepôt de données utilise
souvent une RAM de grande capacité, ce qui peut être un moyen économique de réduire
l'activité disque effectuée sur ce serveur. L’utilisation d'un matériel 64 bits permet
d’augmenter facilement la mémoire à plus de 4 Go. Même si le déploiement actuel ne
requiert pas plus de 4 Mo de RAM, l’utilisation de matériel 64 bits permet de ménager la
croissance éventuelle des besoins futurs.

Utilisation de matériel de serveur dédié de l'entrepôt de données — Bien que les
déploiements de bas niveau puissent souvent consolider la base de données Operations
Manager et l'entrepôt de données du même ordinateur physique, il est avantageux de les
séparer au fur et à mesure que le nombre d'agents augmente. En conséquence, le volume
des données opérationnelles entrantes augmente de même. Si vous séparez l'entrepôt de
données et les serveurs de rapports, la performance de la génération des rapports s'en
trouvera améliorée.

Utilisation d'un contrôleur de disques avec cache d'écriture à pile de secours — L'essai
révèle que la charge de travail sur l'entrepôt de données tire parti du cache d'écriture des
contrôleurs de disques. Lors de la configuration du cache d'écriture par rapport au cache
d'écriture des contrôleurs de disques, il est conseillé d'allouer 100 pourcent du cache au
cache d'écriture. Lors de l’utilisation avec toute base de données de contrôleurs de disques
avec cache d’écriture, il est crucial de s’assurer qu’ils disposent d’un système de sauvegarde
alimenté par batterie pour éviter les pertes de données en cas de panne.
Recommandations et bonnes pratiques applicables au serveur d'administration
La plus grande partie de la charge d'un serveur d'administration provient de la collecte des
données opérationnelles et de leur insertion dans les bases de données Operations Manager et
de l'entrepôt de données. Il est important de noter que les serveurs d'administration effectuent
directement ces opérations, indépendamment du serveur d'administration racine. Les serveurs
d'administration exécutent la plupart des files d'attente de données dans la mémoire, plutôt que
de se soumettre à un disque lent, ce qui augmente la performance. La ressource la plus
importante des serveurs d'administration est l'UC, mais les essais révèlent qu'ils ne nécessitent
généralement pas de matériel haut de gamme. Les facteurs qui influencent la charge d'un
serveur d'administration sont les suivants :
38

Le taux de collecte des données opérationnelles — Étant donné que la collecte des données
opérationnelles est l'activité principale d'un serveur d'administration, ce taux influence plus
l'utilisation globale d'un serveur. Cependant, les essais révèlent que les serveurs
d'administration peuvent généralement combiner des taux élevés de traitement de données
opérationnelles avec des taux réduits afin de modérer leur utilisation. Le facteur primaire
affectant le taux de collecte de données opérationnelles est lié au type de packs
d'administration déployés dans le groupe d'administration.
Bonnes pratiques applicables à l'évaluation d'un serveur d'administration :

Ne pas surdimensionner le matériel du serveur d'administration — Pour la plupart des
scénarios, l'utilisation d'un serveur d'utilitaire classique convient suffisamment pour les tâches
que le serveur d'administration effectue. Les recommandations matérielles suivantes de ce
document doivent suffire pour la plupart des charges de travail.

Ne pas dépasser le taux agents/serveur d'administration d'environ 3 000 pour 1 — La
performance réelle du serveur varie en fonction du volume des données opérationnelles
collectées, mais les essais révèlent que les serveurs d'administration n'ont généralement pas
de difficultés à prendre en charge 2 000 agents avec un volume de données opérationnelles
entrantes relativement élevé. La disponibilité de 2 000 agents par serveur d'administration est
une recommandation basée sur des tests, non sur une limite stricte. Vous pourriez vous
rendre compte qu'un serveur d'administration de votre environnement peut prendre en
charge un nombre élevé ou réduit d'agents

Pour maximiser le taux ordinateurs UNIX ou Linux/serveur d'administration (500:1), utilisez
les serveurs d'administration dédiés pour effectuer l'analyse interplateforme.

Utiliser le nombre minimal de serveurs d'administration par groupe d'administration pour
remplir les conditions requises en terme de redondance — Le déploiement de plusieurs
serveurs d'administration découle principalement de la nécessité de garantir la redondance et
la récupération d'urgence, au lieu de l'évolutivité. Les essais révèlent que la plupart des
déploiements n'ont pas besoin de plus de trois à cinq serveurs d'administration pour
satisfaire ces besoins.
Recommandations et bonnes pratiques applicables au serveur de passerelle
Les serveurs de passerelles relaient les communications entre les serveurs d'administration et
les agents situés l'un et l'autre à l'opposé des limites d'approbation de Kerberos. Le serveur de
passerelle utilise l'authentification basée sur un certificat pour s'authentifier mutuellement avec le
serveur d'administration, et il y procède à l'aide d'une seule connexion, au lieu de plusieurs
connexions, tel que recommandé entre les agents et le serveur d'administration. Ainsi, la gestion
de l'authentification basée sur le certificat dans des domaines non approuvés devient plus facile
et plus gérable. Les facteurs qui influencent la charge d'un serveur de passerelle sont les
suivants :

Le taux de collecte des données opérationnelles — Le facteur primaire affectant la charge
d'une passerelle est le taux de collecte des données opérationnelles. Ce taux dépend du
nombre d'agents affectés à la passerelle et des packs d'administration déployés dans le
groupe d'administration.
39
Bonnes pratiques applicables à l'évaluation d'un serveur de passerelle :

Les serveurs de passerelle peuvent être utiles à la gestion de l'utilisation de la bande
passante — Du point de vue de la performance, les passerelles sont recommandées pour
optimiser la bande passante dans les environnements à bande passante limitée, étant donné
qu'elles appliquent un niveau de compression à toutes les communications avec le serveur
d'administration.

Ne pas dépasser le ratio agents/serveur de passerelle d'environ 1 500 pour 1 — Les essais
révèlent que la disponibilité de plus de 1 000 agents par passerelle peut compromettre la
capacité de récupération, en cas de panne prolongée (plusieurs heures) empêchant une
passerelle de communiquer avec le serveur d'administration. Pour affecter plus d'agents à
une passerelle, envisagez d'utiliser plusieurs serveurs de passerelle. Pour dépasser plus de
1 500 agents par passerelle, il est vivement conseillé de tester votre système pour vous
assurer que la passerelle peut rapidement vider sa file d'attente en cas de panne prolongée
entre elle et le serveur d'administration, au cas où le temps de récupération de la passerelle
pose un problème dans votre environnement.

Dans le cas d'un nombre élevé de passerelles et d'agents connectés à la passerelle, utiliser
un serveur d'administration dédié — Si vous connectez toutes les passerelles à un seul
serveur d'administration sans que d'autres agents n'y soient connectés, vous pouvez
accroître la vitesse de récupération en cas de panne prolongée.
Recommandations et bonnes pratiques applicables à l'analyse des erreurs d'application
Le serveur d'administration utilisé pour l'analyse des erreurs d'application reçoit les données du
client de rapports d'erreurs et les enregistre dans un partage de fichiers. Si ce partage de fichier
est local, cela affecte le serveur d'administration.
Bonnes pratiques applicables à la planification de l'analyse des erreurs d'application :

Le stockage sur disque du partage de fichiers peut s'effectuer localement, sur un stockage
réseau connexe (NAS) ou sur un périphérique réseau de stockage SAN.

Le disque utilisé pour l'analyse des erreurs d'application doit être distinct du disque utilisé
pour les bases de données de l'entrepôt de données ou Operations Manager.

Si le stockage est configuré sur un Système de fichiers distribués (DFS), veuillez désactiver
la réplication DFS.

Un serveur de passerelle ne doit pas être utilisé comme un collecteur d'analyse des erreurs
d'application.
No de périphériques analysés
serveur d'administration pour le partage de
fichiers d'analyse des erreurs d'application
0 à 10 000
200 Go de disque en RAID 1, 2 disques, 4 Go
de RAM, biprocesseurs
10 000 à 25 000
500 Go de disque en RAID 1, 2 disques, 8 Go
de RAM, processeurs à quatre cœurs
40
Recommandations et bonnes pratiques applicables à l'Analyse par client collectif
L'Analyse de l'intégrité collective s'effectue par la collecte des données d'événement et de
performance de plusieurs ordinateurs, et par le regroupement des données en fonction des
groupes de systèmes de rapports et d'analyse. Par exemple, les données de performance
individuelle de la mémoire sont collectées sur différents types de matériels à l'aide des clients
Windows XP et Windows Vista. L'Analyse de l'intégrité collective regroupe ces données et fournit
des rapports en fonction de la performance de la mémoire des groupes de systèmes spécifiques,
par exemple par système d'exploitation ou par fournisseur de matériel. Cela rend l'analyse de la
performance globale plus facile qu'avec l'option d'étudier de longues listes de rapports de
performance individuelles du système. Le mode d'analyse collective permet également l'alerte et
l'analyse à un niveau collectif plutôt qu'individuel.
Les packs d'administration de l'analyse par client collectif comprennent les éléments suivants :
Information Worker, Windows Client, Windows XP, Windows Vista, Network Address Protocol et
d'autres packs d'administration axés sur le client.
Chaque client analysé par un agent génère généralement des événements récapitulatifs de
manière périodique, lesquels permettent de calculer l'intégrité collective des clients. Si l'alerte de
l'agent individuel est désactivée, les agents exécutés sur les clients ne pourront plus générer des
données d'alerte.
En fonction du nombre de packs d'administration déployés et du trafic des agents, chaque
serveur d'administration peut gérer jusqu'à 3 000 à 4 000 clients gérés par agent.
Lors de la planification du déploiement des clients d'analyse collectif, les agents doivent être
approuvés par lots de 1 000 à la fois afin qu'ils se synchronisent avec la configuration la plus
récente.
Dans le tableau suivant, DW signifie entrepôt de données, ODB signifie base de données
Operations Manager, RMS renvoie au serveur d'administration racine, et MSFS2 renvoie à un
ordinateur de partage de fichiers basé sur un deuxième serveur d'administration.
Recommandations pour une configuration réduite :
No de périphériques analysés
Rôle et configuration du serveur
0 à 2 500
DW, ODB, MSFS2, RMS ;
30 Go de disque en RAID 1 2 disques, 4 Go de
RAM
Recommandations pour une configuration moyenne :
No de périphériques analysés
2 500 à 5 000
Rôle et configuration du
Rôle et configuration du
serveur
serveur
DW, ODB ;
MSFS2, RMS ;
50 Go de disque en RAID 1
2 disques, 4 Go de RAM
RAID 1 2 disques, 4 Go de
RAM
41
Recommandations pour une configuration élargie :
No de périphériques
Rôle et configuration
Rôle et configuration
Rôle et configuration du
analysés
du serveur
du serveur
serveur
5 000 à 7 500
DW, ODB ;
MSFS2 ;
100 Go de disque en
RAID 1 2 disques,
4 Go de RAM
RAID 1 2 disques,
serveur d'administration
racine ;
4 Go de RAM
RAID 1 2 disques,
4 Go de RAM
Recommandations pour une configuration d'entreprise :
No de
Rôle et
Rôle et
Rôle et
Rôle et
périphériques
configuration du
configuration du
configuration du
configuration du
analysés
serveur
serveur
serveur
serveur
7 500 à 10 000
DW ;
ODB ;
MSFS2 ;
300 Go de
disque en
RAID 1
2 disques, 4 Go
de RAM
300 Go de
disque en
RAID 1
2 disques, 4 Go
de RAM
RAID 1
2 disques,
serveur
d'administration
racine ;
4 Go de RAM
RAID 1 2 disques,
4 Go de RAM
Conception des services ACS
Cette section fournit les recommandations de haut niveau permettant de commencer la
planification de l'implémentation des services ACS.
Les services ACS ne sont pas une solution autonome. Ils peuvent être hébergés uniquement
dans un groupe d'administration existant, étant donné que leur agent est intégré et installé avec
l'agent Operations Manager, et le collecteur ACS peut être installé uniquement sur un serveur
d'administration ou sur un serveur de passerelle. Les composants restants, la base de données
des services ACS et la fonctionnalité de rapports des services ACS, peuvent être installés sur un
même serveur ou sur une même instance de SQL Server 2005, tout comme le reste des
composants de la base de données OperationsManager, de même que les composants de
rapports. Cependant, pour des motifs de performance, de capacité et de sécurité, vous choisirez
probablement de les installer sur un matériel dédié.
Décisions de conception
Il existe quatre décisions de conception majeures à prendre lorsque vous planifiez
l'implémentation des services ACS. En prenant ces décisions, gardez à l'esprit qu'il existe un
rapport bi-univoque entre le serveur du collecteur des services ACS et la base de données des
services ACS. Une base de données des services ACS ne peut contenir, à la fois, que les
42
données d'alimentation des services ACS, et chaque collecteur des services ACS doit posséder
sa propre base de données des services ACS. Il est possible de disposer de plusieurs paires de
collecteurs de services ACS/bases de données dans un groupe d'administration ; cependant,
aucune procédure supplémentaire n'est disponible pour intégrer les données de plusieurs bases
de données des services ACS dans une seule base de données.
La première décision à prendre est celle de déployer ou de ne pas déployer un groupe
d'administration utilisé exclusivement pour la prise en charge des services ACS, ou de déployer
les services ACS dans un groupe d'administration qui fournit également l'analyse de l'intégrité et
les services d'alerte. Les caractéristiques suivants correspondent aux deux scénarios de
déploiement des services ACS.


Services ACS hébergés dans un scénario de groupe d'administration production :

Utilisation graduée des services ACS Étant donné que les services ACS collectent
chaque événement de sécurité des systèmes sur lesquels les redirecteurs ACS sont
activés, leur utilisation peut générer une grande quantité de données. À moins d'utiliser
un matériel dédié pour le collecteur de services ACS et les Rôles de base de données, le
traitement de ces données peut compromettre la performance du groupe d'administration
hôte, en particulier dans la couche de la base de données.

Une administration et une sécurité distinctes ne sont pas nécessaires — Étant donné que
les services ACS sont hébergés dans un groupe d'administration, les personnes
autorisées à l'administration du groupe d'administration disposeront des droits
d'administration sur les services ACS. Si les conditions requises dans le cadre des
opérations, du contrôle/audit et de l'informatique nécessitent que les services ACS soient
placés sous contrôle informatique non-production, évitez de les déployer dans un
scénario de groupe d'administration production comme alternative.
Services ACS hébergés dans un scénario de groupe d'administration dédié :

Une administration et une sécurité distinctes sont requises — S'il existe un groupe
d'administration distinct responsable des contrôles d'audit et de sécurité de votre société,
il est conseillé d'héberger les services ACS dans un groupe d'administration dédié et
géré par le groupe d'audit/de sécurité.
La deuxième décision à prendre est celle de déployer ou non la fonctionnalité de rapports des
services ACS dans une instance SQL Server 2005 Reporting Services identique au composant
Reporting d'Operations Manager 2007. Les caractéristiques suivantes se rapportent à ces deux
scénarios.

Fonctionnalité de rapports des services ACS intégrée à Operations Manager Reporting :

Console unique pour tous les rapports — Lorsque la fonctionnalité de rapports des
services ACS est installée avec Operations Manager Reporting, les rapports ACS sont
accessibles à l'aide de la console Opérateur Operations Manager.

Modèle de sécurité commun — Lorsque Operations Manager 2007 Reporting est installé
sur SQL Server 2005 Reporting Services, il remplace le modèle de sécurité par défaut
par le modèle de sécurité par rôle d'Operations Manager. La fonctionnalité de rapports
des services ACS est compatible avec ce modèle. Tous les utilisateurs pourvus du rôle
43
d'Opérateur de rapports pourront accéder aux rapports des services ACS tant qu'ils
disposeront des permissions requises dans la base de données ACS.
Remarque
Si Operations Manager Reporting est désinstallé plus tard, le modèle de sécurité
SRS d'origine doit être restauré manuellement à l'aide de l'utilitaire
ResetSRS.exe, disponible sur le support d'installation du répertoire
SupportTools.

Fonctionnalité de rapports des services ACS installée sur une instance dédiée de SQL
Server Reporting Services :

Console distincte pour les rapports ACS et Operations Manager — Lorsqu'ils sont
installés sur une instance SRS dédiée, les rapports ACS sont accessibles à travers le
site Web SRS créé pour l'occasion pendant l'installation. Cela fournit une plus grande
flexibilité dans la configuration de la structure des dossiers et dans l'utilisation du
concepteur de rapports SRS.

Modèle de sécurité distinct — Comme conséquence de l'utilisation de l'instance SRS
dédiée, vous pouvez créer des rôles de sécurité au besoin, pour remplir les conditions
requises dans le cadre des opérations et de l'informatique permettant de contrôler l'accès
aux rapports ACS. Notez que les permissions requises doivent toujours être obtenues
dans la base de données des services ACS.
La troisième décision de conception à prendre porte sur le nombre de paires de collecteurs de
services/base de données ACS à déployer pour la prise en charge de votre environnement. La
vitesse à laquelle une seule paire de collecteurs de services ACS/base de données de prendre
en charge la collecte et l'insertion d'événements continus n'est pas un nombre absolu. Elle
dépend de la performance du sous-système de stockage auquel le serveur de base de données
est relié. Par exemple, une solution SAN de niveau inférieur peut généralement prendre en
charge jusqu'à 2 500 à 3 000 événements de sécurité par seconde. Hormis ce facteur, l'on a pu
observer que le collecteur de services ACS prend en charge une rafale de 20 000 événements
de sécurité par seconde. Facteurs affectant le nombre d'événements de sécurité générés par
seconde :

Configuration de la politique d'audit — Plus la politique d'audit est agressive, plus le nombre
d'événements de sécurité générés à l'aide des ordinateurs audités est élevé.

Le rôle de l'ordinateur sur lequel le redirecteur ACS est activé, grâce à la politique d'audit par
défaut et au contrôleur de domaine, génère les événements de sécurité les plus performants.
Les serveurs membres génèrent la quantité suivante la plus élevée, et les stations de travail
génèrent la plus petite quantité.
Rôle de l'ordinateur
Nombre approximatif d'événements de sécurité
non filtrés par seconde, générés pendant une
charge élevée
Contrôleur de domaine Windows Server 2003
40 événements par seconde
44
Rôle de l'ordinateur
Nombre approximatif d'événements de sécurité
non filtrés par seconde, générés pendant une
charge élevée
Serveur membre Windows Server 2003
2 événements par seconde
Station de travail
0,2 événement par seconde

À l'aide des chiffres du tableau précédent, une seule paire de collecteurs de services
ACS/base de données haut de gamme peut prendre en charge jusqu'à 150 contrôleurs de
domaines, 3 000 serveurs membres ou 20 000 stations de travail (avec l'application du filtre
approprié du collecteur des services ACS).

L'activité des utilisateurs sur le réseau — Si votre réseau est exploité par des utilisateurs haut
de gamme exécutant un grand nombre de transactions, le cas de Microsoft, plus
d'événements seront générés. Si les utilisateurs réseau effectuent des transactions
relativement réduites, le cas d'un scénario de kiosque ou d'entrepôt, attendez-vous à recevoir
peu de notifications de sécurité.

Configuration du filtre du collecteur des services ACS — Les services ACS collectent tous les
événements de sécurité à partir d'un journal des événements de sécurité d'un ordinateur
analysé. De tous les événements collectés, seul un sous-ensemble réduit pourrait vous
intéresser. Les services ACS fournissent la capacité de filtrer les événements non
approuvés, permettant ainsi que seuls les événements approuvés soient traités par le
collecteur, puis insérés dans la base de données des services ACS. Au fur et à mesure que
le volume de filtrage augmente, peu d'événements sont traités et insérés dans la base de
données des services ACS.
La dernière décision de conception à prendre porte sur la version de SQL Server 2005 ou de
SQL Server 2008 à utiliser pour la base de données des services ACS. Les services ACS
prennent en charge l'utilisation des éditions SQL Server 2005 Standard et SQL Server 2005
Enterprise ou des éditions SQL Server 2008 Standard ou Enterprise. Le type de version utilisé
influence le comportement du système lorsque la fenêtre de maintenance quotidienne de la base
de données s'affiche. Lorsque la fenêtre de maintenance s'affiche, les partitions de la base de
données dont l'horodatage se situe en dehors de la planification de rétention des données
(14 jours correspondant à une configuration typique de la rétention de données), sont supprimées
de la base de données. Si vous utilisez l'édition SQL Server Standard, l'insertion des événements
de sécurité s'arrête et les événements forment une file d'attente sur le collecteur des services
ACS jusqu'a la fin de la maintenance. Si vous utilisez l'édition SQL Server Enterprise, l'insertion
des événements de sécurité traités se poursuit, mais uniquement de 30 à 40 pourcent du taux
normal. C'est la raison pour laquelle vous devez choisir prudemment la plage de temps de la
maintenance quotidienne de la base de données, en choisissant une période pendant laquelle
très peu d'utilisateurs et d'applications se trouvent sur le réseau.
45
Recommandations et bonnes pratiques relatives aux services ACS
La performance globale du système ACS est largement influencée par la performance de la base
de données des services ACS et du sous-système disque correspondant. Étant donné que
plusieurs milliers d'événements sont insérés par seconde de manière continue, il est donc
possible qu'ils culminent jusqu'à des dizaines de milliers par secondes. Cette action se vérifie
également dans un grand nombre de périphériques analysés, y compris les contrôleurs de
domaine, afin d'accumuler plus d'un téraoctet de données pendant une période de 14 jours dans
la base de données des services ACS. Bonnes pratiques applicables aux services ACS :

Utilisez un matériel et un système d'exploitation 64 bits pour le collecteur des services ACS,
en même temps qu'une solution SAN à haute performance.

Séparez les fichiers de données des journaux des transactions.

S'il le faut, hébergez les services ACS avec un matériel dédié.

Utilisez des filtres étanches pour diminuer le nombre d'événements de sécurité anti-bruit
insérés dans la base de données.

Planifiez soigneusement votre stratégie d'audit Windows afin de consigner uniquement les
événements importants sur les systèmes analysés.

Activez le redirecteur de services ACS uniquement sur les systèmes requis.

Configurez les journaux des événements de sécurité avec assez d'espace, de sorte qu'en
cas de perte de communication avec le collecteur des services ACS, le fichier des journaux
des événements de sécurité ne revienne pas sur lui-même et n'efface pas les événements
précédents, entraînant ainsi la perte des données d'événements.
Développement d'un plan d'implémentation pour
Operations Manager 2007
Développement d'un plan de mise en œuvre
À ce stade du processus de conception, vous devez disposer de plusieurs documents :

une liste des objectifs inhérents à votre projet de mise en œuvre Operations Manager 2007 ;

un récapitulatif des impératifs informatiques, réglementaires et professionnels ;

un inventaire fiable de votre environnement de production actuel ;

une description fidèle des processus actuellement utilisés pour effectuer les analyses ;

une liste des services Operations Manager 2007 qui seront mis en œuvre et des composants
nécessaires à la prise en charge de ces services ;

un diagramme détaillé des groupes d'administration planifiés et de leur future place dans
votre environnement ;

un plan détaillé de la méthode d'intégration d'Operations Manager dans vos processus
d'analyse actuels ;
46

les spécifications matérielles requises pour les serveurs des groupes d'administration
planifiés.
Le plan de mise en œuvre correspond au dernier élément que ce guide vous aidera à
développer.
Test en laboratoire
Un plan de mise en œuvre consiste simplement en une liste moyennement détaillée des étapes
nécessaires au déplacement de l'environnement d'analyse depuis son emplacement actuel,
appelé « état de départ », vers l'emplacement où vous souhaitez l'installer, appelé « état de fin
souhaité ». Il n'existe qu'une seule manière de développer correctement un plan de mise en
œuvre et c'est par le biais d'un test en laboratoire. Le but du test en laboratoire dans le cadre du
développement d'un plan de mise en œuvre est de valider la configuration et les procédures. Il ne
s'agit pas d'établir les possibilités d'évolutivité de l'environnement car il est généralement très
coûteux de modéliser l'intégralité de l'environnement de production en tenant compte de sa
complexité et de sa charge dans un environnement de laboratoire.
Démarrez votre conception en laboratoire en identifiant les composants essentiels de votre
environnement de production qui prennent en charge l'environnement d'analyse, par exemple
Active Directory et DNS. Identifiez également les composants avec lesquels Operations Manager
va interagir, par exemple, des applications, des serveurs et des stations de travail.
Sécurisez le matériel qui hébergera l'environnement de laboratoire de l'état de départ. Puisque
vous ne procédez pas à des tests à l'échelle, vous pouvez utiliser Microsoft Virtual Server pour
héberger ces composants en tant qu'ordinateurs virtuels. Virtual Server offre l'avantage d'une
capacité de réinitialisation rapide de l'environnement de test vers un état de départ sain après
l'exécution d'un test. Générez l'infrastructure de composants essentiels et les autres composants
de l'état de départ dans cet environnement. Soyez attentif à ce que l'environnement de
laboratoire ressemble le plus possible à l'environnement de production. Plus l'environnement
sera semblable en termes de configuration, de services et de données, plus le test qui en
découle sera pertinent.
Munissez-vous ensuite du matériel qui sera utilisé pour prendre en charge la mise en œuvre de
la production de vos groupes d'administration et exécutez-le dans l'environnement de laboratoire.
Vous aurez la possibilité de confirmer que tout le matériel nécessaire est présent et fonctionne
correctement. Établissez ensuite une brève liste des étapes que vous allez suivre pour
l'exécution du déploiement Operations Manager. Les étapes de préparation sont maintenant
terminées.
Vous devez maintenant procéder à la mise en œuvre en laboratoire, étape par étape, en mettant
à jour les procédures au fur et à mesure de votre progression. Vous serez très certainement
confronté à des difficultés pendant ce processus. Le but est d'identifier le maximum de problèmes
bloquant la mise en œuvre et de développer des solutions ou procédures pour les résoudre.
Préparez-vous à répéter ce processus de nombreuses fois, à constater des avancements à
chaque fois et à réinitialiser le laboratoire sur l'état de départ autant de fois que nécessaire.
Dès que vous parvenez à procéder à la mise en œuvre de l'état de départ à l'état de fin souhaité,
vous avez l'assurance de disposer d'un plan de mise en œuvre fiable et réellement utile.
47
48