Condividi tramite

System Center - Prestazioni di Service Manager

  • Articolo

Le prestazioni per i ruoli e le funzionalità del server di System Center - Service Manager sono influenzate da fattori diversi. In genere, esistono tre aree in cui le prestazioni positive e negative sono più evidenti in Service Manager:

  • Velocità di risposta della console di Service Manager. È il tempo che intercorre tra l'esecuzione e il completamento di un'azione nella console.

  • Tempo di inserimento dati per i connettori. Questo è il tempo necessario per l'importazione dei dati da parte di Service Manager quando un connettore viene sincronizzato.

  • Tempo di completamento dei flussi di lavoro. È il tempo impiegato per l'esecuzione automatica di alcuni tipi di azioni dei flussi di lavoro.

Prestazioni del connettore

La sincronizzazione iniziale del connettore può richiedere molto tempo; ad esempio da 8 a 12 ore per una sincronizzazione iniziale di grandi dimensioni con Configuration Manager. Quando un connettore viene sincronizzato inizialmente, è possibile prevedere prestazioni insufficienti per tutti i ruoli e i processi del server di Service Manager durante questo periodo. Ciò si verifica a causa del modo in cui i dati vengono inseriti in sequenza nel database di Service Manager, ovvero un database di Microsoft SQL Server. Anche se non è possibile accelerare il processo di sincronizzazione iniziale del connettore, è possibile pianificare la sincronizzazione iniziale e assicurarsi che il processo di sincronizzazione venga completato correttamente prima che Service Manager venga inserito nell'ambiente di produzione.

Al termine della sincronizzazione iniziale, Service Manager continua a sincronizzare le differenze, che non hanno un impatto misurabile sulle prestazioni.

Prestazioni del flusso di lavoro

I flussi di lavoro sono processi che si verificano automaticamente. Essi includono l'invio di notifiche tramite posta elettronica, il passaggio successivo di un'attivazione di richiesta di modifica e l'applicazione automatica di un modello.

Considerazioni sulle prestazioni dei flussi di lavoro comprendono quanto segue:

  • Di norma i flussi di lavoro si completano nell'arco di un minuto. Quando i ruoli del server di Service Manager si trovano in un carico di lavoro elevato, i flussi di lavoro non vengono completati il più rapidamente possibile.

  • Inoltre quando si creano nuovi flussi di lavoro, come una nuova sottoscrizione delle notifiche, il sistema subisce un carico ulteriore. All'aumentare del numero dei flussi di lavoro creati, aumenta anche il tempo richiesto per l'esecuzione di ciascun flusso di lavoro.

Quando il sistema è sottoposto a forte carico, ad esempio se viene creato un gran numero di nuovi eventi imprevisti e ogni evento genera molti flussi di lavoro, le prestazioni possono ridursi.

Impatto sulle prestazioni di gruppo, coda e ruolo utente

È opportuno pianificare gruppi e ruoli utente con anticipo. I gruppi dovrebbero essere generati con cautela e per l'ambito più piccolo possibile. È quindi necessario popolare inizialmente il database con i dati di Dominio di Active Directory Services (AD DS), Configuration Manager e System Center Operations Manager prima di creare i gruppi.

Spesso gli amministratori creano gruppi per garantire che gli utenti abbiano accesso solo ai gruppi specificati. Ad esempio, è possibile creare il sottoinsieme degli eventi imprevisti relativi ai computer utilizzati dal personale del reparto delle risorse umane. In questo scenario è possibile che si desideri limitare la visualizzazione o la modifica del gruppo Server riservati a personale specifico. A tale scopo, sarà necessario creare un gruppo per tutti gli utenti e un gruppo per i computer riservati e assicurarsi che un ruolo di protezione disponga dell'accesso a entrambi i gruppi Tutti gli utenti e Server riservati. Inevitabilmente, la creazione di un gruppo contenente tutti gli utenti comporta un impatto sulle prestazioni perché Service Manager controlla spesso se sono presenti modifiche al gruppo. Per impostazione predefinita, tale controllo avviene ogni 30 secondi. Per un gruppo di grandi dimensioni, il controllo delle modifiche crea un carico elevato nel sistema e può rallentare notevolmente il tempo di risposta.

Soluzione 1: è possibile specificare manualmente la frequenza con cui Service Manager verifica la presenza di modifiche ai gruppi modificando una chiave del Registro di sistema. Se, ad esempio, si modifica la frequenza del controllo del gruppo da 30 secondi a 10 minuti, le prestazioni miglioreranno sensibilmente. Tuttavia, le code e gli obiettivi del livello di servizio sono tipi speciali di gruppi che usano lo stesso intervallo di polling di calcolo di gruppo. Pertanto, aumentando il valore dell'intervallo di polling si ottengono tempi più lunghi per i calcoli dell'obiettivo della coda e del livello di servizio.

Attenzione

La modifica non corretta del Registro di sistema potrebbe danneggiare gravemente il sistema. Prima di apportare modifiche al Registro di sistema, si consiglia di effettuare il backup di tutti i dati importanti presenti sul computer.

Specificare manualmente l'intervallo di controllo delle modifiche del gruppo

  1. Eseguire Regedit e passare a HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Creare un nuovo valore DWORD denominato GroupCalcPollingIntervalMilliseconds.

  3. Immettere in tale valore un intervallo in millisecondi. Il risultato viene moltiplicato per 6. Ad esempio, per impostare l'intervallo su 10 minuti, immettere 600000.

  4. Riavviare il servizio System Center Management.

Soluzione 2: è possibile usare uno script di Windows PowerShell per aggiungere oggetti di un tipo, ad esempio "Utenti", a un ruolo utente. Essenzialmente, un analista che ha eseguito l'accesso a questo ruolo può accedere a tutti gli oggetti con un tipo uguale a "Utente". Se si usa questo metodo, eliminare la necessità di un gruppo di grandi dimensioni ("Tutti gli utenti") e il controllo costoso eseguito da Service Manager per determinare l'appartenenza a questo gruppo. Nel server di gestione di Service Manager è possibile eseguire lo script di Windows PowerShell seguente per aggiungere il tipo "utente" a un ruolo "RoleName". È necessario modificare questo script di esempio per l'ambiente in uso.

Eseguire uno script di Windows PowerShell per aggiungere oggetti a un ruolo utente

  • Modificare se necessario lo script seguente e quindi eseguirlo:
#  
# 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."  
}

Visualizzare le prestazioni

Quando si creano visualizzazioni, pianificare l'uso di classi "tipiche" nel sistema, quando possibile. La maggior parte delle classi oggetto, ad esempio Gestione eventi imprevisti, ha due tipi: "tipico" e "avanzato". Il tipo di oggetto tipico contiene riferimenti semplici a un piccolo sottoinsieme di dati relativi a un elemento. Il tipo avanzato contiene molti riferimenti complessi ai dati relativi a un elemento. I tipi tipici sono semplici proiezioni, mentre i tipi avanzati sono proiezioni complesse. La maggior parte dei tipi di oggetto avanzati viene usata per popolare campi diversi nei moduli che normalmente non si desidera visualizzare in una visualizzazione. Ogni volta che si crea una vista basata su un tipo di oggetto avanzato e quando si apre la vista, Service Manager esegue una query sul database e viene letta una grande quantità di dati. Tuttavia, pochissimi dati recuperati vengono visualizzati o usati.

Se si verificano problemi di prestazioni con le visualizzazioni definite quando si usano tipi di oggetto avanzati nelle visualizzazioni, passare all'uso di tipi tipici. In alternativa, è possibile creare tipi di proiezione personalizzati che contengono solo i dati su cui basare una vista.

Prestazioni del database di Service Manager

Le prestazioni del database di Service Manager sono direttamente influenzate da vari fattori, tra cui il numero di console di Service Manager simultanee che leggono o scrivono dati, l'intervallo di controllo delle modifiche del gruppo e i dati inseriti dai connettori. In questo documento sono disponibili ulteriori informazioni in merito. Di seguito vengono illustrati alcuni punti chiave:

  • È necessario avere almeno 8 gigabyte (GB) di RAM per il server di gestione che ospita il database di Service Manager in in modo da poter avere un tempo di risposta accettabile in scenari tipici.

  • Nel computer che ospita il database di Service Manager devono essere presenti almeno 8 core CPU.

  • È possibile migliorare le prestazioni memorizzando file di registro e file di dati in dischi fisici diversi, quando possibile. È possibile ottenere ulteriori vantaggi spostando tempdb in un'unità RAID fisica diversa da quella del database di Service Manager. Usare un sistema di dischi RAID 1+0 per ospitare il database di Service Manager, se possibile.

  • Le prestazioni possono essere influenzate negativamente se il database di Service Manager viene creato con dimensioni inferiori ed è impostato su aumento automatico, soprattutto per piccoli incrementi.

Per informazioni sulla valutazione delle dimensioni del database, vedere lo strumento helper di ridimensionamento di Service Manager incluso nel set di documentazione dell'helper per i processi di Service Manager (SM_job_aids.zip) e creare il database con dimensioni più vicine alle dimensioni finali. Ciò consentirà di ridurre il numero di volte in cui il database deve essere aumentato automaticamente.

Analogamente, sono applicabili anche tutte le altre procedure consigliate per un database con prestazioni elevate. Ad esempio, se è possibile sfruttare un sottosistema di disco superiore, è possibile trarre vantaggio dalla suddivisione dei gruppi di tabelle nei rispettivi filegroup e dallo spostamento in un'unità fisica diversa.

Prestazioni del server di gestione di Service Manager

Le prestazioni del server di gestione di Service Manager sono influenzate principalmente dal numero di console di Service Manager attive. Poiché tutti i ruoli di Service Manager interagiscono con il server di gestione, è consigliabile aggiungere altri server di gestione se si prevede di avere un numero elevato di console simultanee. Il server di gestione deve disporre di 8 GB di RAM. Dovrebbero essere presenti almeno 4 core CPU per ogni server di gestione, presupponendo che siano presenti da 10 a 12 console attive per ogni core CPU.

Prestazioni della console di Service Manager

Le prestazioni della console di Service Manager sono influenzate principalmente dal numero di moduli aperti dagli analisti e dalla quantità di dati recuperati dalle visualizzazioni. Nel computer in cui è installata la console di Service Manager è necessario disporre di 4 GB di RAM. Se sono disponibili visualizzazioni che recuperano una grande quantità di dati, sarà necessaria una RAM aggiuntiva. È necessario avere almeno una CPU a 4 core per il computer in cui è installata la console di Service Manager. Poiché la console di Service Manager è un'applicazione dell'utente finale, è consigliabile riavviarla se viene visualizzato un consumo eccessivo di risorse. La console di Service Manager memorizza nella cache in modo aggressivo le informazioni in memoria, che possono contribuire all'utilizzo complessivo della memoria.

Prestazioni del database del data warehouse di Service Manager

Le prestazioni del data warehouse sono direttamente influenzate da vari fattori, tra cui il numero di server di gestione di Service Manager simultanei che inviano dati, volume di dati archiviati o il periodo di conservazione dei dati, la frequenza di modifica dei dati e l'estrazione, la trasformazione e la frequenza di caricamento (ETL). La quantità di dati archiviati nel data warehouse cresce nel tempo. È importante assicurarsi di non archiviare dati non necessari. Un altro fattore che influisce sulle prestazioni del data warehouse è l'impostazione BatchSize dei processi ETL.

È inoltre possibile migliorare le prestazioni memorizzando i file di registro e i file di dati in dischi fisici diversi. Tuttavia, è consigliabile evitare di inserire più di un file di registro per ogni disco. Analogamente, è possibile migliorare la velocità effettiva posizionando il database temporaneo in un disco fisico diverso da quello utilizzato dagli altri database. È infine possibile ottenere ulteriori vantaggi posizionando i diversi database su dischi fisici diversi. Quando possibile, utilizzare un sistema di unità disco RAID 1+0 per ospitare il data warehouse. Generalmente, sono necessari almeno 8 GB di RAM per il computer in cui sono installati i database del data warehouse. Se sono presenti altre origini dati del data warehouse da Operations Manager o Configuration Manager, è necessario aumentare la quantità di RAM per i database. Sarà possibile usufruire di una quantità maggiore di memoria sul computer che esegue SQL Server che ospita il data warehouse e di una quantità ancora maggiore se i database dei data mart e del repository si trovano sullo stesso server. Tuttavia, se nella topologia di distribuzione sono presenti almeno 4.000 computer, sono sufficienti 4 GB. È opportuno disporre di almeno 8 core di CPU nel computer in cui è installato il database del data warehouse. Ulteriori core miglioreranno le prestazioni di report ed ETL.

Le prestazioni possono essere influenzate negativamente se tutti i database vengono creati con una dimensione più piccola e impostati in modo da espandersi automaticamente, specie se per piccoli incrementi. Vedere lo strumento helper di ridimensionamento di Service Manager incluso nel set di documentazione dell'helper del processo di Service Manager (SM_job_aids.zip) per valutare le dimensioni del database e creare il database con dimensioni più vicine alle dimensioni finali, che consentiranno di ridurre il numero di volte in cui il database deve essere ridimensionato automaticamente.

Service Manager include il supporto predefinito per i filegroup. È possibile trarre vantaggio da questo inserendo i filegroup in dischi rigidi separati. Per altre informazioni sulle procedure consigliate per il filegroup, vedere la documentazione di SQL Server.

Prestazioni del server del data warehouse di Service Manager

Le prestazioni del server del data warehouse sono influenzate dal numero di server di gestione di Service Manager registrati nel data warehouse, dalle dimensioni della distribuzione e dal numero di origini dati. Generalmente, è opportuno che il server del data warehouse disponga di almeno 8 GB di RAM. Tuttavia, le prestazioni possono trarre vantaggio dalla presenza di memoria aggiuntiva per scenari di distribuzione avanzati in cui più server di gestione di Service Manager inseriscono i dati nel data warehouse. Se è necessario cercare un compromesso, considerare prioritaria la memoria del computer che esegue SQL Server. Per evitare problemi di prestazioni, è opportuno disporre di almeno 8 core di CPU.

Prestazioni del portale self-service

Il portale self-service è progettato per facilitare l'accesso a eventi imprevisti e richieste di assistenza. Non è progettato per gestire migliaia di utenti contemporaneamente.

I test delle prestazioni per il portale self-service sono stati incentrati sugli scenari tipici "lunedì mattina", in particolare per garantire che il lunedì mattina centinaia di utenti possano accedere entro un intervallo da 5 a 10 minuti e aprire eventi imprevisti con tempi di risposta accettabili (inferiori a 4-5 secondi). L'obiettivo è stato raggiunto con i requisiti hardware minimi consigliati in questo documento.

Prestazioni degli obiettivi a livello di servizio

Non esiste un numero specifico di obiettivi a livello di servizio supportati da Service Manager. Ad esempio, se un'organizzazione presenta generalmente pochi eventi imprevisti, sono supportati più obiettivi a livello di servizio di quanti ne potrebbero essere supportati altrimenti. Tuttavia, un volume maggiore di eventi imprevisti potrebbe richiedere, a seconda del caso, minori obiettivi a livello di servizio o un ampliamento di hardware e software. È consigliabile creare non più di cinque obiettivi a livello di servizio per una configurazione tipica di Service Manager di 50.000 computer. Eventualmente, è possibile creare più obiettivi a livello di servizio. Tuttavia, poiché le condizioni variano notevolmente da organizzazione a organizzazione, Microsoft non può fornire una raccomandazione concreta per il numero di obiettivi a livello di servizio che non è consigliabile superare. Se la configurazione della distribuzione presenta prestazioni scarse a causa del numero di obiettivi a livello di servizio, è consigliabile aumentare il numero di istanze usando lo scenario di distribuzione più grande successivo, come descritto nell'articolo Configurazioni per scenari di distribuzione di questa guida.

Passaggi successivi

  • Per informazioni sulle configurazioni hardware e software per gli scenari di distribuzione di Service Manager, vedere Scenari di topologia di distribuzione consigliata.