Partager via

Planifier les performances matérielles Service Manager

  • Article

Important

Cette version de Service Manager a atteint la fin du support. Nous vous recommandons de mettre à niveau vers Service Manager 2022.

Une partie importante de System Center : Service Manager performances dépendent de la configuration matérielle et de la topologie de déploiement prévues pour répondre aux besoins de votre organization. Les sections suivantes fournissent des instructions générales à prendre en compte lorsque vous planifiez des performances matérielles adéquates.

Performances du matériel

Voici les goulots d’étranglement matériels les plus visibles dans Service Manager, avec une charge et une quantité significatives de données dans la base de données Service Manager :

  1. Le goulot d'étranglement le plus courant est constitué par la mémoire et les E/S de l'ordinateur sur lequel s'exécute Microsoft SQL Server. Si vous avez les ressources, investir dans plus de mémoire et un sous-système d’E/S plus rapide pour améliorer SQL Server’E/S permet d’obtenir de meilleures performances.
  2. Si vous prévoyez que de nombreuses consoles se connectent à un serveur d’administration, vous pouvez améliorer les performances pour gérer la charge maximale en investissant dans des processeurs et de la mémoire supplémentaires pour le serveur d’administration ou en installant un serveur d’administration Service Manager secondaire.

Il convient de tenir compte de la configuration matérielle minimale requise pour chaque rôle décrite dans ce document.

Rôle des machines virtuelles

De nombreuses organisations utilisent des machines virtuelles pour héberger des applications Windows Server. Service Manager rôles serveur, tels que le serveur d’administration et le serveur d’entrepôt de données, ne sont pas des exceptions. En matière d'utilisation de machines virtuelles, les scénarios vont de la virtualisation de tous les rôles de serveur à différentes combinaisons d'ordinateurs virtuels et physiques.

Nous vous déconseillons de rapport entre ordinateurs virtuels et ordinateurs physiques, car les besoins de votre organization sont intrinsèquement uniques. Toutefois, la configuration matérielle minimale requise pour chaque rôle logiciel s'applique aux ordinateurs physiques. Si vous décidez de virtualiser un rôle logiciel, vous devez prévoir de vous assurer que vous disposez de ressources matérielles supplémentaires pour chaque ordinateur virtuel.

Les serveurs de base de données sont vulnérables aux performances médiocres sur les machines virtuelles si les instructions de planification suivantes ne sont pas suivies :

  • Exécution de SQL Server dans un environnement Hyper-V.
  • N'utilisez jamais de disques dynamiques sur des machines virtuelles destinées à héberger SQL Server. Utilisez des disques durs virtuels de taille fixe ou des disques pass-through.
  • Hyper-V n’autorise que quatre processeurs virtuels par invité, ce qui peut limiter la Service Manager serveur si vous avez de nombreuses consoles.

Service Manager résultats des tests de base de référence

Service Manager a été testé de base pour les performances et la scalabilité à l’aide de différents scénarios de déploiement avec le matériel minimum recommandé sous la forme d’ordinateurs physiques. Plus précisément, les scénarios ont été testés avec des bases de données préremplies et Service Manager consoles créant et mettant à jour des incidents et des demandes de modification dans une boucle.

La base de données était pré-renseignée avec des informations pour deux tests :

  • Le test 1 a porté sur 20 000 ordinateurs, 20 000 utilisateurs et tous les éléments de configuration nécessaires, soit 250 000 éléments de configuration totalisant 2,5 millions de lignes environ dans la base de données. Le test 1 comprenait également 40 consoles Service Manager actives.
  • L'essai 2 a porté sur 50 000 ordinateurs, 50 000 utilisateurs et les éléments de configuration associés, soit 700 000 éléments de configuration environ totalisant 6 millions de lignes dans la base de données. Le test 2 incluait également 80 consoles Service Manager actives.

Les tests ont fourni les résultats suivants :

  • Pour atteindre les objectifs de temps de réponse pour la configuration avec 50 000 ordinateurs, la mémoire de l'ordinateur SQL Server doit être augmentée pour passer de 8 Go à 32 Go.
  • Pendant le test, 200 incidents et 50 demandes de modification pour la configuration à 20 000 ordinateurs, ainsi que 500 incidents et 125 demandes de modification pour la configuration à 50 000 ordinateurs ont été générés chaque heure, 3 à 4 modèles et abonnements à des notifications ayant été traités pour chaque incident et chaque demande de modification.
  • Généralement, dans le test de ligne de base, les flux de travail tels que le traitement d'abonnement aux notifications et l'application de modèles ont été exécutés moins d'une minute après la génération de chaque élément de travail.

Si votre organization prévoit d’avoir moins de 20 000 ordinateurs et consoles pris en charge et moins de flux de travail, vos performances Service Manager doivent être acceptables, même si certains des rôles Service Manager sont hébergés sur des ordinateurs virtuels.

Toutefois, si vous envisagez d’ajouter des ordinateurs pris en charge supplémentaires dans la base de données Service Manager, vous devez prévoir d’augmenter la quantité de RAM pour le serveur de base de données Service Manager au-delà de la configuration minimale indiquée dans ce document. Par exemple, dans le test de base de référence, 8 Go de RAM ont été installés dans le serveur de base de données Service Manager qui contenait des 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 comprenant 50 000 ordinateurs avec 32 Go de RAM installée sur l'ordinateur hébergeant SQL Server, les performances ont été améliorées à un point tel qu'aucune dégradation n'a pu être constatée par rapport à la situation antérieure à l'ajout d'ordinateurs.

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

Notes

Le serveur de base de données Service Manager et les serveurs d’administration Service Manager doivent se trouver sur un réseau local à faible latence ; la latence réseau entre le serveur de base de données Service Manager et le serveur d’administration Service Manager peut entraîner une dégradation significative de Service Manager Performance.

Les tests ont également fourni les résultats suivants :

  • Lorsque la latence du réseau était inférieure à 100 millisecondes (msec), les temps de réponse globaux Service Manager console ont été jugés corrects.

  • Lorsque la latence du réseau était de 150 msec à 200 msec, les performances ont été notées comme utilisables, avec une dégradation jusqu’à 40 % du temps de réponse dans certains scénarios. Avec une latence comprise entre 150 msec et 200 msec, vous devez planifier l’évaluation des scénarios clés pour votre organization et déterminer si la connexion Bureau à distance (RDC) est une meilleure option.

    Notes

    Le développement des mappages de service dans la console Service Manager a été lent avec une latence quelconque.

  • Lorsque la latence du réseau a dépassé 200 msec, les temps de réponse globaux Service Manager console ont été observés comme médiocres. Si votre latence dépasse 200 ms, vous devriez prévoir d'utiliser une connexion Bureau à distance (RDC) ou un autre accès à distance semblable pour les 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.

Étapes suivantes