Performances matérielles

Mis à jour: décembre 2010

S'applique à: System Center Service Manager 2010

Une partie importante des performances Service Manager dépend de la configuration matérielle et de la topologie de déploiement prévue pour répondre aux besoins de votre organisation. Les sections suivantes apportent des instructions générales à considérer lors de la planification pour des performances matérielles adéquates.

Performances matérielles

Sont listés ci-après les goulots d'étranglement les plus notables dans Service Manager avec une charge ou une quantité de données significative dans la base de données Service Manager :

1. Le goulot d'étranglement le plus répandu est la mémoire et les entrées-sorties sur le serveur SQL. Si vous disposez des ressources, investir dans plus de mémoire et un sous-système d'entrée-sortie plus rapide pour améliorer les entrées-sorties de SQL Server permettra de meilleures performances.

2. Si vous prévoyez d'avoir beaucoup de consoles connectées au serveur d'administration, vous pouvez améliorer les performances de gestion du chargement de pointe en investissant dans des processeurs et de la mémoire supplémentaires pour le serveur d'administration, ou en prévoyant d'installer un serveur d'administration secondaire Service Manager.

3. Souvenez-vous des spécifications matérielles minimum recommandées pour chaque rôle, ainsi que décrites dans ce document.

Le rôle des machines virtuelles

Beaucoup d'organisations utilisent des machines virtuelles pour héberger des applications Windows Server et des rôles de serveur Service Manager tels que serveur d'administration, entrepôt de données, et les Portail libre-service ne font pas exception. Une telle utilisation peut aller depuis la virtualisation de tous les rôles de serveur ou d'autres combinaisons d'ordinateurs virtuels et physiques. Nous ne recommandons pas de ratio particulier d'ordinateur virtuel sur physique parce que les besoins de votre organisation sont intrinsèquement uniques Quoiqu''il en soit, les spécifications matérielles minimum pour chaque rôle logiciel s'appliquent aux ordinateurs physiques - si vous décidez de virtualiser un rôle logiciel vous devez prévoir de vous assurer que vous disposez des ressources matérielles supplémentaires pour chaque ordinateur virtuel.

Les serveurs de base de données sont vulnérables aux mauvaises performances sur les machines virtuelles si les conseils de planification suivants ne sont pas suivis.

• Reportez-vous au document Exécuter SQL Server 2008 dans un environnement Hyper-V (https://go.microsoft.com/fwlink/?LinkId=144622) du centre de téléchargement..

• N'utilisez jamais de disques dynamiques sur des machines prévues pour héberger SQL Server - utilisez des lecteurs de disque virtuel à taille fixe ou un relais.

• Hyper-V ne permet que 4 processeurs virtuels par invité, ce qui peut freiner le serveur Service Manager si vous disposez de nombreuses consoles.

Résultats de test de la ligne de base Service Manager

La ligne de base Service Manager a été testée en termes de performances et d'évolutivité en utilisant différents scénarios basés sur le matériel minimum recommandé avec des ordinateurs physiques. En particulier, les scénarios furent testés avec des basés de données pré-renseignées et des console de Service Manager créant et actualisant des incidents et des demandes de changement en boucle. La base de données était pré-renseignée avec des informations pour deux tests.

Le test 1 consistait en 20 000 ordinateurs, 20 000 utilisateurs et tous les éléments de configuration nécessaires, ce qui représentait environ 250 000 éléments de configuration totalisant près de 2,5 millions de rangées dans la base de données, et le test comprenait 40 console de Service Manager actifs.

Le test 2 consistait en 50 000 ordinateurs, 50 000 utilisateurs et tous les éléments de configuration nécessaires, ce qui représentait environ 700 000 éléments de configuration totalisant près de 6 millions rangées dans la base de données, et le test comprenait 80 console de Service Manager actifs.

Afin d'atteindre les objectifs de temps de réponse pour 50 000 configurations, la mémoire SQL Server a dû être portée de 8 à 32 Go.

• Durant le test, 200 incidents et 50 demandes de changement pour 20 000 configurations, ainsi que 500 incidents et 125 demandes de changement pour 50 000 configurations, furent générées chaque heure avec 3 à 4 abonnements à des notifications et modèles traités pour chaque incident et demande de changement.

• Généralement dans la ligne de base, les flux de travail tels que de le traitement d'abonnement aux notifications et l'application de modèle s'exécutaient dans la minute suivant la génération de chaque élément de travail. Toutefois, un petit nombre de flux de travail pouvaient prendre jusqu'à 5 minutes et plus pour se terminer.

Si votre organisation prévoit de prendre en charge moins de 20 000 ordinateurs et consoles et moins de flux de travail, alors votre performance Service Manager devrait être normalement acceptable, même si certains des rôles Service Manager sont hébergés sur des ordinateurs virtuels.

Toutefois, si vous prévoyez de prendre en charge des ordinateurs supplémentaires dans la base de données Service Manager alors vous devriez prévoir d'augmenter la quantité de RAM pour le serveur de base de données Service Manager au delà des spécifications minimum listées dans ce document. Par exemple, dans le test de ligne de base 8 Go de RAM étaient installés sur le serveur de base de données Service Manager qui contenait les enregistrements pour 20 000 ordinateurs. Après coup, vous devriez ajouter 8 Go de RAM pour chaque incrément de 10 000 ordinateurs que vous prévoyez de prendre en charge. Par exemple, pour 50 000 ordinateurs prévoyez 32 Go de RAM. Lors du test de la configuration de 50 000 ordinateurs avec 32 Go de RAM installée sur le serveurs SQL, les performances furent améliorées au point qu'il n'existait plus d'effet amoindrissant, par rapport à avant d'ajouter des ordinateurs supplémentaires

Le temps d'attente réseau fut aussi testé dans la ligne de base. Une latence réseau fut introduite entre le console de Service Manager et le serveur d'administration Service Manager.

• Lorsque la latence du réseau est inférieure à 100 millisecondes, les temps de réponse console de Service Manager globaux ont été jugés bons.

• Lorsque la latence réseau était de 100 à 200 millisecondes, la performance a été notée comme utilisable avec jusqu'à 40 % de dégradation du temps de réponse dans certains scénarios. Avec une latence entre 150 et 200 millisecondes, vous devriez prévoir d'évaluer les scénarios clés pour votre organisation et de déterminer si une connexion de bureau à distance est une meilleure option.

  Notes

  L'extension des cartes de service dans le console de Service Manager était lente quel que soit le niveau de latence.

• Lorsque la latence réseau dépassait 200 millisecondes, les temps de réponse console de Service Manager globaux étaient constatés comme mauvais. Si votre latence dépasse 200 millisecondes, vous devriez prévoir d'utiliser une connexion de bureau à distance ou un autre accès à distance similaire pour des tâches d'exploitation. Toutefois, les tâches administratives occasionnelles étant moins répandues vous ne devriez pas avoir besoin d'accès à distance pour ces dernières.

Avez-vous trouvé cette information utile ? Envoyez-nous vos suggestions et commentaires au sujet de la documentation du System Center Service Manager à : scsmdocs@microsoft.com.