Partager via

System Center - Performances de Service Manager

  • Article

Les performances pour System Center - Rôles et fonctionnalités serveur Service Manager sont affectées par différents facteurs. En règle générale, il existe trois domaines où les performances positives et négatives sont les plus visibles dans Service Manager :

  • Réactivité de la console Service Manager. 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 pour que Service Manager importe des données lorsqu’un connecteur se synchronise.

  • 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.

Performances du connecteur

La synchronisation initiale du connecteur peut prendre beaucoup de temps ; par exemple, 8 à 12 heures pour une synchronisation initiale importante avec Configuration Manager. En tant que connecteur se synchronise initialement, vous pouvez vous attendre à ce que les performances souffrent pour tous les rôles et processus serveur Service Manager pendant ce temps. Cela se produit en raison de la façon dont les données sont insérées séquentiellement dans la base de données Service Manager, qui est une base de données Microsoft SQL Server. Bien que vous ne puissiez pas hachage du processus de synchronisation initial du connecteur, vous pouvez planifier la synchronisation initiale et vous assurer que le processus de synchronisation se termine correctement avant que Service Manager ne soit mis en production.

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

Performances du flux de travail

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 serveur Service Manager sont sous une charge de travail importante, les flux de travail ne se terminent pas aussi rapidement que normalement.

  • 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.

Impact des rôles de groupe, de file d’attente et d’utilisateur sur les performances

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. Vous devez ensuite remplir initialement votre base de données avec des données de services de domaine Active Directory (AD DS), Configuration Manager et System Center Operations Manager avant de créer vos groupes.

Souvent, les administrateurs créent des groupes pour s’assurer que les utilisateurs ont accès aux groupes spécifiés uniquement. 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, la création d’un groupe contenant tous les utilisateurs entraîne un impact sur les performances, car Service Manager vérifie fréquemment s’il existe des modifications apportées au groupe. Cette vérification intervient une fois toutes les 30 secondes, par défaut. Pour un grand groupe, la vérification des modifications crée une charge importante sur le système et peut ralentir considérablement le temps de réponse.

Solution 1 : Vous pouvez spécifier manuellement la fréquence à laquelle Service Manager recherche les modifications 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 entraîne des temps plus longs pour les calculs d’objectif de niveau de service et de file d’attente.

Attention

Une modification incorrecte du Registre peut endommager gravement votre système. Avant toute modification du registre, il est conseillé de sauvegarder toutes les données importantes de votre ordinateur.

Spécifier manuellement l’intervalle de vérification des modifications de groupe

  1. Exécutez Regedit et accédez à HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\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 sur 10 minutes, entrez 6 00000.

  4. Redémarrez le service System Center Management.

Solution 2 : Vous pouvez utiliser un script Windows PowerShell pour ajouter des objets d’un type, tels que « Utilisateurs », à un rôle d’utilisateur. Essentiellement, un analyste connecté dans ce rôle peut accéder à tous les objets dont le type est égal à « Utilisateur ». Si vous utilisez cette méthode, vous éliminez le besoin d’un grand groupe (« Tous les utilisateurs ») et la vérification coûteuse effectuée par Service Manager 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 devez modifier cet exemple de script pour votre environnement.

Exécuter un script Windows PowerShell pour ajouter des 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."  
}

Afficher les performances

Lorsque vous créez des vues, planifiez l’utilisation de classes « classiques » dans le système dans la mesure du possible. La plupart des classes d’objets, par exemple, Gestion des incidents ont deux types : « standard » et « avancé ». 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’objets avancés sont utilisés pour remplir différents champs dans des formulaires que vous ne souhaitez pas normalement afficher dans une vue. Chaque fois que vous créez une vue basée sur un type d’objet avancé et que vous ouvrez la vue, Service Manager interroge la base de données et une grande quantité de données est lue. Toutefois, très peu de données récupérées sont affichées ou utilisées.

Si vous rencontrez des problèmes de performances avec les vues que vous avez définies lorsque vous utilisez des types d’objets avancés dans des vues, passez à l’utilisation de types classiques. Vous pouvez également créer vos propres types de projection qui contiennent uniquement les données sur lesquelles vous devez baser une vue.

Performances de la base de données Service Manager

Les performances de la base de données Service Manager sont directement affectées par différents facteurs, notamment le nombre de consoles Service Manager simultanées qui lisent ou écrivent des données, l’intervalle de vérification des modifications 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 gigaoctets (Go) de RAM pour le serveur d’administration qui héberge la base de données Service Manager afin de pouvoir disposer d’un temps de réponse acceptable dans les scénarios classiques.

  • Vous devez avoir au moins 8 cœurs de processeur sur l’ordinateur hébergeant 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 tempdb vers un lecteur RAID physique différent de celui de la base de données Service Manager. Utilisez un système de disque RAID 1+0 pour héberger votre base de données Service Manager, si possible.

  • Les performances peuvent être affectées négativement si la base de données Service Manager est créée avec une taille plus petite et qu’elle est définie sur la croissance automatique, en particulier par petits incréments.

Pour obtenir de l’aide sur l’évaluation de la taille de la base de données, consultez l’outil Service Manager Helper inclus dans l’ensemble de documentation sur les aides de Service Manager (SM_job_aids.zip) pour obtenir de l’aide sur l’évaluation de la taille de la base de données et créer la base de données avec une taille plus proche de la taille finale. Cela permet de réduire les performances en réduisant le nombre de fois où la base de données doit s’effectuer automatiquement.

De même, toutes les autres meilleures pratiques pour une base de données hautement performante s’appliquent également. Par exemple, si vous pouvez tirer parti d’un sous-système de disque supérieur, vous pouvez tirer parti du fractionnement des groupes de tables sur les groupes de fichiers respectifs et de les déplacer vers un autre lecteur physique.

Performances du serveur d’administration Service Manager

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

Performances de la console Service Manager

Les performances de la console Service Manager sont principalement affectées par le nombre de formulaires que vos analystes ont généralement ouverts et la quantité de données récupérées par les vues. Vous devez disposer de 4 Go de RAM sur l’ordinateur sur lequel la console Service Manager est installée. Si vous avez des vues qui récupèrent une grande quantité de données, vous aurez besoin de ram supplémentaire. Vous devez disposer d’au moins un processeur à 4 cœurs pour l’ordinateur sur lequel la console Service Manager est installée. Étant donné que la console Service Manager est une application utilisateur final, nous vous recommandons de le redémarrer si vous voyez une consommation excessive de ressources. La console Service Manager met en cache de manière agressive les informations en mémoire, ce qui peut contribuer à l’utilisation globale de la mémoire.

Performances de la base de données de l’entrepôt de données Service Manager

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 simultanés qui envoient des données, le volume de données stockées ou la période de rétention des données, le taux de modification des données et la 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 de données supplémentaires à partir d’Operations Manager ou de Configuration Manager, vous devez augmenter la quantité de RAM pour les bases de données. 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. Toutefois, si vous avez 4 000 ordinateurs ou moins dans votre topologie de déploiement, 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. Consultez l’outil Service Manager Sizing Helper inclus dans le jeu de documentation sur les aides aux travaux Service Manager (SM_job_aids.zip) pour évaluer la taille de la base de données et créer la base de données avec une taille plus proche de la taille finale, ce qui permettra de réduire le nombre de fois où la base de données doit s’effectuer 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 relatives au groupe de fichiers, consultez la documentation de SQL Server.

Performances du serveur d’entrepôt de données Service Manager

Les performances du serveur d’entrepôt de données sont affectées par le nombre de serveurs d’administration Service Manager inscrits dans l’entrepôt de données, 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 bénéficieront d’une mémoire supplémentaire pour les scénarios de déploiement avancés où plusieurs serveurs d’administration Service Manager insère 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.

Performances du portail libre-service

Le portail libre-service est conçu pour faciliter l’accès aux incidents et au dépôt des demandes 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 « lundi matin » typiques, notamment pour s’assurer que les centaines d’utilisateurs du lundi matin peuvent se connecter dans un intervalle de 5 à 10 minutes et ouvrir des incidents avec des temps de réponse acceptables (inférieurs à 4 à 5 secondes). Cet objectif a été atteint avec le matériel minimum recommandé dans ce document.

Performances de l’objectif au niveau du service

Il n’existe aucun nombre spécifique 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 créer plus de cinq objectifs de niveau de service pour une configuration Service Manager standard de 50 000 ordinateurs. Vous pouvez éventuellement créer un plus grand nombre d'objectifs de niveau de service. Toutefois, étant donné que les conditions varient considérablement de l’organisation à l’organisation, Microsoft ne peut pas fournir de recommandation concrète pour le nombre d’objectifs de niveau de service que vous ne devez pas dépasser. Si votre configuration de déploiement souffre de performances médiocres en raison du nombre d’objectifs de niveau de service, nous vous recommandons de procéder à un scale-out à l’aide du scénario de déploiement plus grand suivant, comme décrit dans l’article Configurations pour les scénarios de déploiement de ce guide.

Étapes suivantes