Performances de Service Manager

Date de publication : juillet 2016

S’applique à : System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

Les performances pour les rôles de serveur et les fonctionnalités System Center 2012 - Service Manager sont affectées par différents facteurs. Généralement, il existe 3 domaines où les performances positives ou négatives sont les plus notables Service Manager:

• Console de Service Managerréactivité. Il s'agit du délai depuis le moment où vous engagez une forme d'action dans la console jusqu'à son achèvement.

• Délai d'insertion de données pour les connecteurs. Il s'agit du temps nécessaire Service Manager pour importer des données lors de la synchronisation d'un connecteur.

• Délai d'exécution du flux de travail. Il s'agit du temps nécessaire pour que les flux de travail appliquent automatiquement une forme d'action.

La synchronisation initiale d'un connecteur peut durer longtemps, par exemple 8 à 12 heures pour une synchronisation initiale de grande ampleur avec System Center Configuration Manager. Lorsqu'un connecteur se synchronise, vous pouvez vous attendre à ce que les performances souffrent pour tous les Service Manager rôles de serveur et processus durant le délai. Ceci se produit en raison du mode d'insertion séquentiel des données dans la base de données Service Manager qui est une base de données Microsoft SQL Server. Bien que vous ne puissiez pas accélérer le processus de synchronisation initiale du connecteur, vous pouvez planifier la synchronisation initiale et vous assurer que le processus de synchronisation se termine bien avant de mettre Service Manager en production.

Lorsque la synchronisation initiale est terminée, Service Manager continue de synchroniser les différences, ce qui n'a pas d'impact mesurable sur les performances.

Les flux de travail sont des processus automatiques qui se produisent. Ils comprennent l'envoi de notifications par courrier électronique, l'étape suivante de l'activation d'une demande de modification et l'application automatique d'un modèle.

Considérations sur les performances des flux de travail :

• En temps normal, les flux de travail démarrent et se terminent en moins d'une minute. Lorsque les rôles de serveur Service Managersont sous une lourde charge de travail, les flux de travail ne s'achèvent pas aussi vite qu'habituellement.

• En outre, lorsque vous créez de nouveaux flux de travail, comme un nouvel abonnement à des notifications, le système est soumis à une charge supplémentaire. Le temps d'exécution des flux de travail que vous créez augmente avec leur nombre.

Lorsque le système est soumis à une charge élevée, par exemple si un grand nombre de nouveaux incidents est créé et que chaque incident génère de nombreux flux de travail, les performances risquent de se dégrader.

Les performances des flux de travail dans System Center 2012 - Service Manager se sont améliorées depuis Gestionnaire de service System Center 2010, car le nouveau pack d'administration ManagmentHostKeepAlive a augmenté la réactivité de traitement des flux de travail afin que la plupart d'entre eux puisse être traitée en moins d'une minute.

Vous devez planifier tôt des groupes et des rôles d'utilisateur. Vous devez créer des groupes avec modération et pour la plus petite étendue possible. Ensuite, vous devez initialement remplir votre base de données à partir des services de domaine Active Directory (AD DS), de System Center Configuration Manager et de System Center Operations Manager avant de créer vos groupes.

Souvent, les administrateurs créent des groupes afin que des utilisateurs ne puissent accéder qu'aux groupes spécifiés. Par exemple, dans un scénario, vous pourriez vouloir créer un sous-ensemble d'incidents affectant les ordinateurs utilisés par le personnel des ressources humaines. Dans ce scénario, vous pourriez souhaiter que seul du personnel spécifique soit en mesure de visualiser ou de modifier le groupe de serveurs sensibles. Ensuite, pour activer ce type pour l'accès, vous auriez besoin de créer un groupe pour tous les utilisateurs et un groupe pour les ordinateurs sensibles, puis de vous assurer qu'un rôle de sécurité a accès aux groupes Tous les utilisateurs et Serveurs sensibles. Inévitablement, créer un groupe contenant tous les utilisateurs affectera les performances parce que Service Manager vérifie fréquemment pour déterminer s'il existe des changements dans le groupe.. Cette vérification intervient une fois toutes les 30 secondes, par défaut. Pour un très grand groupe, la vérification des modifications imposera une lourde charge au système et risque de réduire considérablement les temps de réponse.

Solution 1 : Vous pouvez spécifier manuellement la fréquence de vérification Service Manager des changements de groupe en modifiant une clé de registre. Par exemple, si vous modifiez la fréquence de vérification de groupe en la faisant passer de 30 secondes à 10 minutes, vous augmenterez notablement les performances. Toutefois, les files d'attente et les objectifs de niveau de service sont des types particuliers de groupes qui utilisent le même intervalle d'interrogation de calcul de groupe. Par conséquent, l'augmentation de la valeur de l'intervalle d'interrogation allonge le temps en file d'attente et les calculs d'objectif niveau de service.

Attention
Une modification incorrecte du registre peut endommager sérieusement votre système. Avant de modifier le registre, vous devez sauvegarder toutes les données importantes sur l'ordinateur.

Pour spécifier manuellement l'intervalle de vérification de changement de groupe

1. Exécutez Regedit et parcourez l'arborescence jusqu'à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2012\Common\.

2. Créez une nouvelle valeur DWORD nommée GroupCalcPollingIntervalMilliseconds.

3. Pour sa valeur, spécifiez l'intervalle en millisecondes. Le résultat est multiplié par 6. Par exemple, pour définir l'intervalle de 10 minutes, tapez 600000.

4. Redémarrez le service System Center Management.

   Notes

   
   Pour System Center 2012 R2 Service Manager, le service d'administration de System Center a été renommé Microsoft Monitoring Agent.

Solution 2 : Vous pouvez utiliser un script Windows PowerShell pour ajouter des objets d'un type, comme « Utilisateurs », à un rôle d'utilisateur. Ainsi, un analyste ayant ouvert une session avec ce rôle peut accéder à tous les objets dont le type est « Utilisateur ». En utilisant cette méthode, vous éliminez le besoin d'un très grand groupe ("Tous les utilisateurs") et la vérification coûteuse que Service Manager effectue pour déterminer l'appartenance à ce groupe. Sur le serveur d'administration Service Manager, vous pouvez exécuter le script Windows PowerShell suivant pour ajouter le type « utilisateur » à un rôle « RoleName ». Vous devrez adapter ce script d'exemple à votre environnement.

Pour exécuter un script Windows PowerShell d'ajout d'objets à un rôle d'utilisateur

• Modifiez le script suivant en fonction des besoins, puis exécutez-le :

# Insert a \"type\" scope in a role  
# Syntax:  
#   AddTypeToRoleScope -server \"put_server_name_here\" -RoleName \"put display name of the role here\" -TypeToAdd \"put display name of the type to add to scope here\"  
# Note:  This is a simple demonstration script without error checking.   
  
# set script parameter defaults  
param ([String]$Server = "localhost", [String]$RoleName="My Analyst Role", [String]$TypeToAdd="User")  
  
$a = [reflection.assembly]::LoadWithPartialName("Microsoft.EnterpriseManagement.Core")  
  
$m = new-object Microsoft.EnterpriseManagement.EnterpriseManagementGroup $Server   
  
# Get Type object  
#   Note:  If you need to get a list of all available classes related to (for example) “User”,   use this command:  
#               $m.EntityTypes.GetClasses() | ?{ $_.Name -like '*user*'} | %{ $_.Name}  
$type = $m.EntityTypes.GetClasses() | ?{ $_.DisplayName -eq $TypeToAdd}  
  
# Get role object, and insert the type GUID into scope  
$role = $m.Security.GetUserRoles()  | ?{ $_.DisplayName -eq $RoleName}  
$role.Scope.Objects.Add($type.Id)     
$role.Update()  
  
# Get the value from the database again and validate it is there  
if ( $role.scope.objects.Contains($type.Id) ) {  
    write-host *** Successfully set the scope for role `" $role.DisplayName`" and it now contains all instances of $type.DisplayName `( $type.Name `)  
} else {  
    write-host "There was an error trying to insert the scope into the role."  
}  
  

Lors de la création d'affichages, prévoyez d'utiliser des classes « typical » dans le système chaque fois que possible. La plupart des classes d'objet, par exemple Incident Management, ont deux types : « typical » et « advanced ». Le type d'objet « typical » contient des références simples à un petit sous-ensemble de données lié à un élément. Le type « advanced » contient de nombreuses références complexes à des données liées à un élément. Les types « typical » sont des projections simples, tandis que les types « advanced » sont des projections complexes. La plupart des types d'objet avancé s'utilisent pour renseigner différents champs dans des formulaires que vous ne souhaitez habituellement pas afficher dans un affichage. Chaque fois que vous créez un affichage sur un type d'objet avancé et lorsque vous ouvrez l'affichage, Service Manager interroge la base de données et une grande quantité de données est lue. Toutefois, très peu de données extraites sont réellement affichées ou utilisées.

Si vous rencontrez des problèmes de performances avec les affichages que vous avez définis lorsque vous utilisez des types d'objet « advanced » dans les affichages, utilisez le type « typical ». Sinon, vous pouvez créer vos propres types de projection contenant seulement les données dont vous avez besoin pour baser votre affichage. Pour plus d'informations, voir le billet de blog Creating Views That Use Related Property Criteria (Type Projections) : Software Views Example (Création d'affichages utilisant des critères de propriétés liées (projections de type) : exemple d'affichages logiciels) de l'équipe SCSM Engineering Team.

La performance de la base de données Service Manager est directement affectée par différents facteurs incluant le nombre de Console de Service Manager qui lisent ou écrivent des données simultanément, l'intervalle de vérification de changement de groupe, et les données insérées par les connecteurs. D'autres informations sont disponibles dans ce document. Voici quelques points clés :

• Vous devez disposer d'un minimum de 8 Go de RAM pour le serveur d'administration qui héberge la base de données Service Manager afin d'obtenir un temps de réponse acceptable dans des scénarios standards.

• Vous devez disposer d'au moins 8 cœurs de processeur sur l'ordinateur qui héberge la base de données Service Manager.

• Vous pouvez obtenir de meilleures performances de base de données en séparant les fichiers de journaux et les fichiers de données sur des disques physiques distincts, si c'est possible. Vous pouvez obtenir d'autres avantages en déplaçant votre base de données temporaire (tempdb) sur un lecteur RAID physique différent de celui utilisé pour la base de données Service Manager. Dans la mesure du possible, utilisez un système de disque RAID 1+0 pour héberger votre base de données Service Manager.

• Les performances peuvent se dégrader si la base de données Service Manager est créée avec une taille plus petite paramétrée pour grossir automatiquement, notamment par petits incréments.

Voir l'Outil d'assistance au dimensionnement Service Manager fourni dans le jeu de documentation Aide aux travaux Service Manager (SM_job_aids.zip) pour vous aider à évaluer la taille de la base de données, et créez la base de données avec une taille proche de la taille finale. Cette disposition améliorera les performances en réduisant le nombre de fois où la base de données doit grossir automatiquement.

De même, toutes les autres pratiques recommandées pour améliorer les performances d'une base de données sont applicables. Par exemple, si vous pouvez disposer d'un sous-système de disque supérieur, vous pourrez en tirer parti en séparant les groupes de tables en groupes de fichiers respectifs et en les déplaçant sur des lecteurs physiques différents.

Les performances du serveur d'administration Service Manager sont essentiellement affectées par le nombre de Console de Service Manager actives simultanément. Étant donné que tous les rôles Service Manager interagissent avec le serveur d'administration, envisagez d'ajouter des serveurs d'administration si vous prévoyez d'avoir un grand nombre de consoles opérant simultanément. Vous devez disposer de 8 Go de RAM pour le serveur d'administration. Vous devez avoir au moins 4 cœurs d'UC par serveur d'administration, en supposant que vous avez entre 10 et 12 consoles actives par cœur d'UC.

Les performances de la Console de Service Manager sont affectées en premier par le nombre de formulaires qu'ouvrent habituellement vos analystes et par la quantité de données extraites par les affichages. Vous devez disposer d'un minimum de 4 Go de RAM sur l'ordinateur où est installée la Console de Service Manager. Si vous avez des affichages extrayant de grandes quantités de données, vous aurez besoin de RAM supplémentaire. Vous devez disposer d'au moins un processeur 4 cœurs pour l'ordinateur où la Console de Service Manager est installée. Étant donné que la Console de Service Manager est une application de l'utilisateur final, nous vous recommandons de la redémarrer si vous constatez une consommation excessive des ressources. La Console de Service Manager effectue une mise en cache en mémoire intensive des informations, ce qui peut contribuer à l'utilisation d'ensemble de la mémoire.

Les performances de l'entrepôt de données sont directement affectées par différents facteurs, notamment le nombre de serveurs d'administration Service Manager envoyant simultanément des données, le volume de données stockées ou le délai de rétention de données, le taux de modification des données et leur fréquence d'extraction, de transformation et de chargement (ETL). La quantité de données stockées dans l'entrepôt de données augmente au fil du temps. Vous assurer que vous n'archivez pas de données inutiles est important. Un autre facteur affectant les performances de l'entrepôt de données est le paramètre BatchSize des processus ETL.

En outre, vous pouvez obtenir de meilleures performances en séparant les fichiers journaux et les fichiers de données sur des disques physiques distincts. Toutefois, vous devez éviter de placer plusieurs fichiers journaux sur un même disque. De même, vous obtiendrez un meilleur débit en plaçant la base de données temporaire (tempdb) sur un disque physique différent de celui utilisé par les autres bases de données. Enfin, vous pouvez également placer les différentes bases de données sur leurs disques physiques respectifs. Utilisez un système de disque RAID 1+0 pour héberger votre entrepôt de données, si possible. Vous devez généralement avoir un minimum de 8 Go de RAM sur l'ordinateur sur lequel sont installées les bases de données de l'entrepôt de données. Si vous avez des sources de données d'entrepôt des données supplémentaires d'Operations Manager ou de Configuration Manager, vous devez augmenter la quantité de RAM en conséquence. Les performances seront améliorées par l'installation d'une plus grande quantité de mémoire sur l'ordinateur exécutant SQL Server qui héberge l'entrepôt de données, et le seront encore plus si les bases de données du mini-Data Warehouse et du référentiel se trouvent sur le même serveur. Néanmoins, si le nombre d'ordinateurs est inférieur ou égal à 4 000, 4 Go sont suffisants. Vous devez disposer d'au moins 8 cœurs de processeur dans l'ordinateur sur lequel la base de données de l'entrepôt de données est installée. Des cœurs supplémentaires aideront aux performances ETL et de rapport.

Les performances peuvent se dégrader si toutes les bases de données du système sont créées avec une plus petite taille paramétrée pour grossir automatiquement, notamment par petits incréments. Voir l'Outil d'assistance au dimensionnement Service Manager fourni dans le jeu de documentation Aide aux travaux Service Manager (SM_job_aids.zip) pour vous aider à évaluer la taille de la base de données, et créez la base de données avec une taille proche de la taille finale. Cette disposition améliorera les performances en réduisant le nombre de fois où la base de données doit grossir automatiquement.

Service Manager inclut la prise en charge intégrée des groupes de fichiers. Vous pouvez tirer parti de cela en plaçant les groupes de fichiers sur des disques durs distincts.Pour plus d'informations sur les meilleures pratiques de groupe de fichiers, consultez la documentation de SQL Server.

Les performances du serveur d'entrepôt de données sont affectées par le nombre de serveurs d'administration Service Manager inscrits auprès de l'entrepôt de données ainsi que par la taille de votre déploiement et le nombre de sources de données. Vous devez généralement disposer d'un minimum de 8 Go de RAM pour le serveur d'administration de l'entrepôt de données. Toutefois, les performances seront meilleures en installant de la mémoire supplémentaire pour les scénarios de déploiement avancés lorsque plusieurs serveurs d'administration Service Manager insèrent des données dans l'entrepôt de données. Si vous recherchez un compromis, votre priorité la plus élevée doit être la mémoire pour l'ordinateur exécutant SQL Server. Vous devez disposer d'au moins 8 cœurs de processeur pour éviter des problèmes de performance.

Le Portail libre-service est conçu pour permettre de renseigner facilement les formulaires d'incident et de demande de service. Il n'est pas conçu pour gérer des milliers d'utilisateurs simultanément.

Les tests de performances pour le Portail libre-service se sont concentrés sur des scénarios caractéristiques de type « lundi matin » afin de vérifier que le lundi matin, des centaines d'utilisateurs peuvent se connecter dans un laps de temps de 5 à 10 minutes et ouvrir des incidents avec des temps de réponse acceptables (en moins de 4 à 5 secondes). Cet objectif a été atteint avec le matériel minimum recommandé dans ce document.

Il n'existe aucun nombre précis d'objectifs de niveau de service pris en charge par Service Manager. Par exemple, si une organisation rencontre généralement un faible nombre d'incidents, elle peut prendre en charge un plus grand nombre d'objectifs de niveau de service. Toutefois, un plus grand volume d'incidents peut nécessiter un plus petit nombre d'objectifs de niveau de service ou l'ajout de ressources matérielles et logicielles supplémentaires selon le cas. Nous vous recommandons de ne pas créer plus de cinq objectifs de niveau de service pour une configuration type Service Manager comprenant 50 000 ordinateurs. Vous pouvez éventuellement créer un plus grand nombre d'objectifs de niveau de service. Toutefois, les conditions variant considérablement d'une organisation à l'autre, Microsoft ne peut fournir une recommandation précise pour le nombre d'objectifs de niveau de service que vous ne devez pas dépasser. Si les performances de votre configuration de déploiement sont faibles en raison du nombre d'objectifs de niveau de service, nous vous recommandons d'effectuer une montée en charge en utilisant le scénario de déploiement suivant (en termes de taille de déploiement), comme indiqué à la section Configurations pour les scénarios de déploiement de ce guide.