System Center : Service Manager Leistung

Wichtig

Diese Version von Service Manager das Ende des Support erreicht hat. Es wird empfohlen, dass Sie ein Upgrade auf Service Manager 2019 durchführen.

Leistung für System Center: Service Manager Serverrollen und -features werden durch verschiedene Faktoren beeinflusst. Im Allgemeinen gibt es drei Bereiche, in denen die positive und negative Leistung in der Regel am deutlichsten Service Manager:

  • Service Manager der Konsolenschnelligkeit. Hierbei handelt es sich um die Zeitdauer von dem Moment an, in dem irgendeine Aktion in der Konsole gestartet wird, bis zu deren Abschluss.

  • Dateneinfügedauer für Connectors. So lange dauert es, bis Service Manager daten importiert werden, wenn ein Connector synchronisiert wird.

  • Workflowabschlussdauer. Hierbei handelt es sich um die Zeitdauer, die von Workflows benötigt wird, um irgendeine Aktion automatisch anzuwenden.

Connectorleistung

Die Erstsynchronisierung des Connectors kann sehr lange dauern, z. B. 8 bis 12 Stunden für eine große Erstsynchronisierung mit Konfigurations-Manager. Bei der ersten Synchronisierung eines Connectors können Sie davon ausgehen, dass die Leistung für alle Service Manager Serverrollen und Prozesse während dieser Zeit zu beeinträchtigen ist. Dies liegt daran, wie Daten sequenziell in die Service Manager-Datenbank eingefügt werden, bei der es sich um eine Microsoft SQL Server handelt. Obwohl Sie den Anfänglichen Synchronisierungsprozess des Connectors nicht beschleunigen können, können Sie die Erstsynchronisierung planen und sicherstellen, dass der Synchronisierungsprozess gut abgeschlossen ist, bevor Service Manager in die Produktionsumgebung eingedrungen wird.

Wenn die Erstsynchronisierung abgeschlossen ist, Service Manager weiterhin die Unterschiede synchronisieren, die keine messbaren Auswirkungen auf die Leistung haben.

Workflowleistung

Workflows sind automatisch erfolgende Prozesse. Sie umfassen u. a. den Versand von E-Mail-Benachrichtigungen, Change Request-Aktivitäten sowie die automatische Anwendung von Vorlagen.

Im Zusammenhang mit der Workflowleistung gilt Folgendes:

  • Workflows werden normalerweise innerhalb von einer Minute gestartet und beendet. Wenn Service Manager Serverrollen eine hohe Arbeitsauslastung haben, werden Workflows nicht so schnell wie gewohnt abgeschlossen.

  • Zudem vergrößert sich mit jedem Workflow, den Sie erstellen (beispielsweis in Form eines neuen Benachrichtigungsabonnements), die Systemlast. Je mehr neue Workflows Sie erstellen, desto länger dauert die Ausführung der einzelnen Workflows.

Wenn das System starklastig ist, z. B. wenn eine große Anzahl neuer Incidents erstellt wird und jeder Incident viele Workflows generiert, kann sich dies negativ auf die Leistung auswirken.

Auswirkungen von Gruppen-, Warteschlangen- und Benutzerrolle auf die Leistung

Sie sollten Gruppen und Benutzerrollen früh planen. Erstellen Sie Gruppen bedarfsorientiert (d. h. so wenige Gruppen wie möglich), und beschränken Sie den Gruppenbereich auf die Mindestgröße. Anschließend sollten Sie ihre Datenbank zunächst mit Daten aus Active Directory Domain Services (AD DS), Konfigurations-Manager und System Center Operations Manager auffüllen, bevor Sie Ihre Gruppen erstellen.

Gruppen werden vom Administrator häufig erstellt, um die Berechtigungen bestimmter Benutzer auf den jeweiligen Bereich bzw. Umfang einzuschränken. Beispiel: Sie möchten eine Teilmenge von Incidents erstellen, die Computer betreffen, welche von den Mitarbeitern der Personalabteilung benutzt werden. Dabei sollen vielleicht nur bestimmte Mitarbeiter zur Anzeige und Bearbeitung der Gruppe „Störungsanfällige Server“ berechtigt sein. In diesem Fall müssten Sie eine Gruppe für alle Benutzer und eine weitere Gruppe für störungsanfällige Computer erstellen und anschließend dafür sorgen, dass es eine Sicherheitsrolle gibt, die Zugang zu beiden Gruppen („Alle Benutzer“ sowie „Störungsanfällige Server“) erhält. Das Erstellen einer Gruppe, die alle Benutzer enthält, führt zwangsläufig zu Leistungsauswirkungen, da Service Manager häufig überprüft, ob Änderungen an der Gruppe vorgenommen wurden. Standardmäßig erfolgt diese Prüfung alle 30 Sekunden. Bei sehr großen Gruppen erzeugt die Änderungsprüfung eine hohe Systemlast, wodurch sich die Antwortzeit deutlich verschlechtern kann.

Lösung 1: Sie können manuell angeben, wie Service Manager gruppenänderungen überprüft, indem Sie einen Registrierungsschlüssel ändern. Wenn Sie beispielsweise die Gruppenprüfungshäufigkeit von 30 Sekunden in 10 Minuten ändern, wird sich hierdurch die Systemleistung deutlich verbessern. Warteschlangen und SLO-Ziele sind jedoch besondere Arten von Gruppen, die dasselbe Abrufintervall für die Gruppenberechnung verwenden. Durch Erhöhen des Werts des Abrufintervalls ergeben sich deshalb längere Zeiträume für Warteschlangen- und SLO-Zielberechnungen.

Achtung

Durch eine fehlerhafte Bearbeitung der Registrierung können schwerwiegende Schäden am System verursacht werden. Bevor Sie Änderungen an der Registrierung vornehmen, sollten Sie alle wichtigen Computerdaten sichern.

So legen Sie das Prüfintervall für Gruppenänderungen manuell fest

  1. Führen Sie „regedit“ aus, und navigieren Sie zu HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\System Center\2010\Common\.

  2. Erstellen Sie einen neuen DWORD-Wert mit dem Namen GroupCalcPollingIntervalMilliseconds.

  3. Geben Sie als Wert das gewünschte Intervall in Millisekunden an. Das Ergebnis wird mit 6 multipliziert. Beispiel: Um das Intervall auf 10 Minuten zu setzen, geben Sie 600000ein.

  4. Starten Sie den System Center Management-Dienst neu.

Lösung 2: Sie können ein Windows PowerShell-Skript verwenden, um einer Benutzerrolle Objekte eines Typs hinzuzufügen, z. B. "Benutzer". Im Wesentlichen kann ein Analyst, der in dieser Rolle angemeldet ist, auf alle Objekte zugreifen, deren Typ "User" entspricht. Wenn Sie diese Methode verwenden, entfällt die Notwendigkeit einer sehr großen Gruppe ("Alle Benutzer") und die teure Überprüfung, die Service Manager zum Bestimmen dieser Gruppenmitgliedschaft durchführt. Auf dem Service Manager-Verwaltungsserver können Sie das folgende Windows PowerShell ausführen, um der Rolle "RoleName" den Typ "benutzer" hinzuzufügen. Passen Sie dieses Beispielskript Ihrer Umgebung entsprechend an.

So führen Sie ein Windows PowerShell-Skript aus, um Objekte zu einer Benutzerrolle hinzuzufügen

  • Ändern Sie das folgende Skript nach Bedarf, und führen Sie das Skript anschließend aus:
#  
# 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."  
}  

Anzeigen der Leistung

Wenn Sie Ansichten erstellen, planen Sie nach Möglichkeit die Verwendung "typischer" Klassen im System. Die meisten Objektklassen, z. B. Incident Management, haben zwei Typen: "typisch" und "erweitert". Die Objekttyp „typical“ (typisch) umfasst einfache Verweise auf eine kleine Teilmenge von elementbezogenen Daten. Der Typ „advanced“ (erweitert) umfasst viele komplexe Verweise auf elementbezogene Daten. Typische Typen sind einfache Projektionen, erweiterte Typen sind komplexe Projektionen. Erweiterte Objekttypen werden meist verwendet, um verschiedene Felder in Formularen aufzufüllen, die normalerweise nicht in einer Ansicht angezeigt werden sollen. Wenn Sie eine Ansicht basierend auf einem erweiterten Objekttyp erstellen und die Ansicht öffnen, fragt Service Manager die Datenbank ab, und eine große Datenmenge wird gelesen. Allerdings wird nur sehr wenig der abgerufenen Daten angezeigt oder verwendet.

Falls Leistungsprobleme mit den von Ihnen definierten Ansichten auftreten und Sie „erweiterte“ Objekttypen in Ihren Ansichten verwendet haben, sollten Sie stattdessen „typische“ Objekttypen verwenden. Alternativ können Sie auch eigene Projektionstypen erstellen, die nur die für eine Ansicht benötigten Daten enthalten.

Service Manager der Datenbankleistung

Die Leistung der Service Manager-Datenbank wird direkt durch verschiedene Faktoren beeinflusst, z. B. die Anzahl gleichzeitiger Service Manager-Konsolen, die Daten lesen oder schreiben, das Intervall für die Gruppenänderungsprüfung und daten, die von Connectors eingefügt werden. Weitere Informationen hierzu finden Sie weiter hinten in diesem Dokument. Hier einige wichtige Punkte:

  • Für den Verwaltungsserver, der die Service Manager-Datenbank hostet, sollten Sie mindestens 8 GIGABYTE (GB) RAM haben, damit Sie in typischen Szenarien eine akzeptable Antwortzeit haben können.

  • Sie sollten mindestens 8 CPU-Kerne auf dem Computer haben, auf dem die Service Manager wird.

  • Sie können eine bessere Datenbankleistung erzielen, indem Sie Protokolldateien und Datendateien, sofern möglich, auf getrennten physischen Datenträgern speichern. Sie können weitere Vorteile erzielen, indem Sie Ihre tempdb auf ein anderes physisches RAID-Laufwerk als das der Service Manager verschieben. Hosten Sie Ihre Service Manager-Datenbank möglichst auf einem RAID 1+0-Plattensystem.

  • Die Leistung kann negativ beeinflusst werden, wenn die Service Manager-Datenbank mit einer kleineren Größe erstellt und auf automatische Vergrößerung festgelegt ist, insbesondere durch kleine Inkremente.

Informationen zur Bewertung der Größe der Datenbank und zum Erstellen der Datenbank mit einer Größe, die näher an der endgültigen Größe liegt, finden Sie im Service Manager-Hilfsprogramm für die Größengröße, das im Service Manager-Auftragshilfsprogramm -Dokumentationssatz (SM_job_aids.zip) enthalten ist. Dies hilft bei der Leistung, da die Anzahl der automatischen Verwächste der Datenbank reduziert wird.

In gleicher Weise sind auch alle übrigen bewährten Methoden für leistungsstarke Datenbanken anwendbar. Wenn Sie beispielsweise ein übergeordnetes Datenträgersubsystem nutzen können, können Sie davon profitieren, dass Sie die Tabellengruppen in den jeweiligen Dateigruppen aufteilen und auf ein anderes physisches Laufwerk verschieben.

Service Manager-Verwaltungsserverleistung

Die Leistung des Service Manager-Verwaltungsservers wird hauptsächlich durch die Anzahl der aktiven gleichzeitigen Service Manager beeinflusst. Da alle Service Manager-Rollen mit dem Verwaltungsserver interagieren, sollten Sie zusätzliche Verwaltungsserver hinzufügen, wenn Sie eine große Anzahl gleichzeitiger Konsolen planen. Der Verwaltungsserver sollte über 8 GB RAM verfügen. Jeder Verwaltungsserver sollte über mindestens 4 CPU-Kerne verfügen (bei10 bis 12 aktiven Konsolen pro CPU-Kern).

Service Manager der Konsolenleistung

Die Leistung der Service Manager-Konsole hängt hauptsächlich von der Anzahl der Formulare ab, die Ihre Analysten in der Regel geöffnet haben, und der Datenmenge, die von Ansichten abgerufen wird. Sie sollten über 4 GB RAM auf dem Computer verfügen, auf dem die Service Manager installiert ist. Wenn Sie über Ansichten verfügen, die große Datenmengen abrufen, benötigen Sie weitere RAM-Kapazitäten. Sie sollten mindestens über eine CPU mit 4 Kernen für den Computer verfügen, auf dem die Service Manager installiert ist. Da die Service Manager-Konsole eine Endbenutzeranwendung ist, wird empfohlen, sie neu zu starten, wenn ein übermäßiger Ressourcenverbrauch angezeigt wird. Die Service Manager speichert Informationen aggressiv im Arbeitsspeicher zwischen, was zur Gesamtspeicherauslastung beitragen kann.

Service Manager Data Warehouse-Datenbankleistung

Die Leistung des Data Warehouse wird direkt durch verschiedene Faktoren beeinflusst, z. B. die Anzahl gleichzeitiger Service Manager-Verwaltungsserver, die Daten senden, die Menge der gespeicherten Daten oder die Datenaufbewahrungsdauer, die Rate der Datenänderung und die ETL-Häufigkeit (Extrahieren, Transformieren und Laden). Die im Data Warehouse gespeicherte Datenmenge nimmt im Laufe der Zeit immer weiter zu. Archivieren Sie daher auf jeden Fall alle nicht benötigen Daten. Ein weiterer Faktor, der die Data Warehouse-Leistung beeinflusst, ist die BatchSize-Eigenschaft von ETL-Prozessen.

Sie können eine bessere Leistung erzielen, indem Sie Protokolldateien und Datendateien auf getrennten physischen Datenträgern speichern. Allerdings sollten Sie es vermeiden, mehr als eine Protokolldatei auf einem Datenträger zu speichern. Ebenso können Sie einen besseren Durchsatz erzielen, indem Sie tempdb nicht auf demselben physischen Datenträger ablegen wie die anderen Datenbanken. Weitere Vorteile erzielen Sie, wenn Sie die verschiedenen Datenbanken ebenfalls auf eigenen physischen Datenträgern ablegen. Hosten Sie Ihr Data Warehouse möglichst auf einem RAID 1+0-Plattensystem. Auf dem Computer, auf dem die Data Warehouse-Datenbanken installiert werden, sollten grundsätzlich mindestens 8 GB RAM verfügbar sein. Wenn Sie über zusätzliche Data Warehouse-Datenquellen aus Operations Manager oder Konfigurations-Manager verfügen, sollten Sie die Ram-Menge für die Datenbanken erhöhen. Eine Speichererweiterung empfiehlt sich für den Computer, auf dem SQL Server ausgeführt und der zum Hosten des Data Warehouse verwendet wird, insbesondere dann, wenn sich die Datamart- und die Repositorydatenbank auf demselben Server befinden. Wenn Ihre Bereitstellungstopologie jedoch maximal 4.000 Computer umfasst, sind 4 GB ausreichend. Der Computer, auf dem die Data Warehouse-Datenbank installiert ist, sollte über mindestens 8 CPU-Kerne verfügen. Zusätzliche Kerne tragen zu einer besseren ETL- und Berichtsleistung bei.

Es kann sich ungünstig auf die Leistung auswirken, wenn alle Datenbanken des Systems zunächst als kleinere Datenbanken erstellt und für eine automatische Vergrößerung konfiguriert werden – insbesondere, wenn kleine Zuwachsschritte vereinbart werden. Informationen Service Manager zum Bewerten der Größe der Datenbank und erstellen Sie die Datenbank mit einer Größe, Service Manager die näher an der endgültigen Größe liegt. Dies hilf SM_job_aids.zip t der Leistung, indem die Anzahl der automatischen Vergrößerungen der Datenbank reduziert wird.

Service Manager enthält integrierte Unterstützung für Dateigruppen. Sie können hiervon profitieren, indem Sie die Dateigruppen auf verschiedenen Festplattenlaufwerken platzieren. Weitere Informationen zu bewährten Methoden für Dateigruppen finden Sie in der SQL Server-Dokumentation.

Service Manager Data Warehouse-Serverleistung

Die Leistung des Data Warehouse-Servers hängt von der Anzahl der Service Manager-Verwaltungsservern, die beim Data Warehouse registriert sind, der Größe Ihrer Bereitstellung und der Anzahl der Datenquellen ab. Allgemein gilt, dass für den Data Warehouse-Server mindestens 8 GB RAM verfügbar sein sollten. Die Leistung wird jedoch durch zusätzlichen Arbeitsspeicher für erweiterte Bereitstellungsszenarien profitieren, in denen mehr als ein Service Manager-Verwaltungsserver Daten in das Data Warehouse einfügt. Wenn Sie bei der Leistung Kompromisse machen müssen, sollte der Speicher für den Computer, auf dem SQL Server ausgeführt wird, oberste Priorität haben. Um Leistungsprobleme zu vermeiden, sollten Sie über mindestens 8 CPU-Kerne verfügen.

Leistung des Self-Service-Portals

Das Self-Service-Portal ist für den einfachen Zugriff auf incident- und service request-Anmeldungen konzipiert. Es ist nicht für Tausende von gleichzeitigen Benutzern ausgelegt.

Leistungstests für das Self-Service-Portal konzentrierten sich insbesondere auf typische "Montag morgen"-Szenarien, um sicherzustellen, dass sich Hunderte von Benutzern am Montagvormittag innerhalb einer Zeitspanne von 5 bis 10 Minuten anmelden und Incidents mit akzeptablen Antwortzeiten (weniger als 4 bis 5 Sekunden) öffnen können. Dieses Ziel wurde mit der in diesem Dokument empfohlenen Mindesthardwarekonfiguration erreicht.

Leistung des Servicelevelziels

Es gibt keine bestimmte Anzahl von Servicelevelzielen, die Service Manager unterstützt. So wird im Fall eines Unternehmens mit normalerweise wenigen Incidents eine größere Anzahl von Servicelevel-Zielpunkten unterstützt. Bei einer umfangreicheren Incidentmenge muss dagegen u. U. die Anzahl der Servicelevel-Zielpunkte reduziert werden, sofern keine entsprechende Hard- und Softwareskalierung stattfindet. Es wird empfohlen, nicht mehr als fünf Servicelevelziele für eine typische Konfiguration mit 50.000 Computern Service Manager zu erstellen. Möglicherweise können Sie weitere Servicelevel-Zielpunkte erstellen. Da sich die Bedingungen von Unternehmen zu Unternehmen jedoch z. T. stark unterscheiden, kann von Microsoft keine verbindliche Obergrenze für Servicelevel-Zielpunkte festgelegt werden. Wenn ihre Bereitstellungskonfiguration aufgrund der Anzahl von Servicelevelzielen unter einer schlechten Leistung zu sehen ist, wird empfohlen, die Skalierung mithilfe des nächsthöheren Bereitstellungsszenarios durchzuführen, wie im Artikel Konfigurationen für Bereitstellungsszenarien dieses Handbuchs beschrieben.

Nächste Schritte