Service Manager-Leistung

Veröffentlicht: Juli 2016

Gilt für: System Center 2012 SP1 - Service Manager, System Center 2012 R2 Service Manager, System Center 2012 - Service Manager

Die Leistung der System Center 2012 – Service Manager-Serverrollen und -Funktionen wird durch verschiedene Faktoren beeinflusst. Generell gibt es drei Bereiche, in denen sich eine positive und negative Leistung in Service Manager am deutlichsten bemerkbar macht:

• Reaktionsfähigkeit der Service Manager-Konsole. 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. Hierbei handelt es sich um die Zeitdauer, die Service Manager bei Synchronisierung eines Connectors benötigt, um Daten zu importieren.

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

Die Erstsynchronisierung eines Connectors kann sehr zeitaufwändig sein – 8-12 Stunden bei einer umfangreichen Erstsynchronisierung mit System Center Configuration Manager. Da ein Connector anfangs synchronisiert wird, können Sie davon ausgehen, dass es während dieser Zeit für alle Service Manager-Serverrollen und Prozesse zu Leistungseinbußen kommt. Ursächlich hierfür ist die Art und Weise, wie die Daten sequentiell in die Service Manager-Datenbank eingefügt werden, bei der es sich um eine Microsoft SQL Server-Datenbank handelt. Sie können den Erstsynchronisierungsprozess des Connectors zwar nicht beschleunigen, die Erstsynchronisierung aber so planen, dass der Vorgang abgeschlossen ist, bevor Service Manager in den Produktionsbetrieb versetzt wird.

Nach der Erstsynchronisierung erfolgt eine laufende Synchronisierung der Unterschiede durch Service Manager, was jedoch keine nennenswerten Auswirkungen auf die Systemleistung hat.

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 stark ausgelastet sind, werden Workflows nicht so schnell abgeschlossen wie üblich.

• 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 stark ausgelastet ist, beispielsweise wenn eine große Anzahl neuer Incidents erstellt wird, von denen jeder mehrere Workflows generiert, kann dies die Systemleistung negativ beeinflussen.

Die Workflowleistung in System Center 2012 – Service Manager hat sich gegenüber System Center Service Manager 2010 dank des neuen ManagmentHostKeepAlive-Management Packs verbessert; die Mehrheit der Workflows wird binnen einer Minute verarbeitet.

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. Vor der Erstellung von Gruppen sollten Sie Ihre Datenbank zudem bereits mit Daten aus AD DS (Active Directory-Domänendienste), System Center Configuration Manager und System Center Operations Manager gefüllt haben.

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 beinhaltet, führt unweigerlich zu Leistungseinbußen, da Service Manager häufig prüft, ob es Änderungen für die Gruppe gibt. 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 oft Service Manager nach Gruppenänderungen suchen soll; hierfür muss ein Registrierungsschlüssel geändert werden. 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
Eine fehlerhafte Bearbeitung der Registrierung kann Ihr System schwer beschädigen. Bevor Sie Änderungen an der Registrierung vornehmen, sollten Sie auf Ihrem Computer vorhandene wichtige Daten 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\2012\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 600000 ein.

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

   Hinweis
   Für System Center 2012 R2 Service Manager wurde der System Center-Verwaltungsdienst in Microsoft Monitoring Agent umbenannt.

Lösung 2: Sie können ein Windows PowerShell-Skript verwenden, um Objekte eines bestimmten Typs (z. B. „Benutzer“) zu einer Benutzerrolle hinzuzufügen. Im Prinzip kann ein Analytiker, der in dieser Rolle angemeldet ist, auf alle Objekte des Typs „Benutzer“ zugreifen. Wenn Sie dieses Verfahren anwenden, entfällt der Bedarf für eine sehr große Gruppe („Alle Benutzer“) und auch die aufwändige Prüfung, die von Service Manager ausgeführt wird, um die Zugehörigkeit zu dieser Gruppe festzustellen. Auf dem Service Manager-Verwaltungsserver können Sie das folgende Windows PowerShell-Skript ausführen, um den Typ „user“ (Benutzer) der Rolle „RoleName“ (Rollenname) 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."  
}  
  

Planen Sie beim Erstellen von Ansichten möglichst den Einsatz von „typischen“ Klassen für Ihr System ein. Die meisten Objektklassen, beispielsweise die Objektklasse „Incident Management“, umfassen zwei Typen: „typical“ und „advanced“. 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 auf Basis eines erweiterten Objekttyps erstellen und diese Ansicht öffnen, wird die Datenbank von Service Manager abgefragt und eine große Datenmenge ausgelesen. Es werden jedoch nur sehr wenige der abgerufenen Daten tatsächlich 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. Weitere Informationen hierzu finden Sie im Blogbeitrag mit dem Titel Creating Views That Use Related Property Criteria (Type Projections) : Software Views Example (Erstellen von Ansichten mit verwandten Eigenschaftskriterien (Typprojektionen): Softwareansichten-Beispiel) im SCSM Engineering Team-Blog.

Die Leistung der Service Manager-Datenbank hängt direkt von verschiedenen Faktoren ab, unter anderem davon, wie viele Service Manager-Konsolen gleichzeitig Daten lesen oder schreiben; weitere Faktoren sind das Prüfintervall für Gruppenänderungen sowie die von Connectors eingefügten Daten. Weitere Informationen hierzu finden Sie weiter hinten in diesem Dokument. Hier einige wichtige Punkte:

• Für den Verwaltungsserver, der zum Hosten der Service Manager-Datenbank verwendet wird, sollten mindestens 8 GB RAM verfügbar sein, damit in typischen Szenarien eine akzeptable Antwortzeit erzielt werden kann.

• Der Computer, der die Service Manager-Datenbank hostet, sollte über mindestens 8 CPU-Kerne verfügen.

• Sie können eine bessere Datenbankleistung erzielen, indem Sie Protokolldateien und Datendateien, sofern möglich, auf getrennten physischen Datenträgern speichern. Weitere Leistungsvorteile lassen sich erzielen, indem Sie für Ihre tempdb ein anderes physisches RAID-Laufwerk verwenden als das Laufwerk, auf dem sich die Service Manager-Datenbank befindet. Hosten Sie Ihre Service Manager-Datenbank nach Möglichkeit auf einem RAID 1+0-Plattensystem.

• Es kann sich ungünstig auf die Leistung auswirken, wenn zunächst eine kleinere Service Manager-Datenbank erstellt und diese für die automatische Vergrößerung konfiguriert wird – insbesondere, wenn kleine Zuwachsschritte vereinbart werden.

Das Service Manager Sizing Helper-Tool im Dokumentationssatz zu den Service Manager-Auftragshilfen („SM_job_aids.zip“) hilft Ihnen, die Größe der Datenbank besser abzuschätzen und so zu wählen, dass sie der endgültigen Datenbankgröße näher kommt. Dies wirkt sich positiv auf die Leistung aus, da die Datenbankgröße so seltener angepasst werden muss.

In gleicher Weise sind auch alle übrigen bewährten Methoden für leistungsstarke Datenbanken anwendbar. Beispiel: Wenn Ihnen ein übergeordnetes Plattensubsystem zur Verfügung steht, können Sie die Tabellengruppen nach Dateigruppen aufteilen und auf unterschiedliche physische Laufwerke verschieben.

Die Leistung des Service Manager-Verwaltungsservers hängt in erster Linie von der Anzahl der aktiven gleichzeitigen Service Manager-Konsolen ab. Da alle Service Manager-Rollen mit dem Verwaltungsserver kommunizieren, sollten Sie in Erwägung ziehen, weitere Verwaltungsserver hinzuzufügen, falls Sie planen, eine große Anzahl von gleichzeitigen Konsolen zu nutzen. 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).

Die Leistung der Service Manager-Konsole hängt in erster Linie davon ab, wie viele Formulare Ihre Analytiker typischerweise geöffnet haben, sowie von der durch Ansichten abgerufenen Datenmenge. Auf dem Computer, auf dem die Service Manager-Konsole installiert ist, sollten 4 GB RAM verfügbar sein. Wenn Sie über Ansichten verfügen, die große Datenmengen abrufen, benötigen Sie weitere RAM-Kapazitäten. Der Computer, auf dem die Service Manager-Konsole installiert ist, sollte mindestens über eine 4-Core-CPU verfügen. Da es sich bei der Service Manager-Konsole um eine Endbenutzeranwendung handelt, wird bei übermäßigem Ressourcenverbrauch ein Konsolenneustart empfohlen. Informationen werden von der Service Manager-Konsole in erheblichem Umfang im Arbeitsspeicher zwischengespeichert, wodurch sich die Gesamtspeicherauslastung vergrößern kann.

Die Leistung des Data Warehouse hängt direkt von verschiedenen Faktoren ab, unter anderem davon, wie viele gleichzeitige Service Manager-Verwaltungsserver Daten senden. Weitere Faktoren sind das gespeicherte Datenvolumen und die Datenbeibehaltungsdauer, die Datenänderungsrate sowie die ETL-Frequenz (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. Im Fall weiterer Data Warehouse-Datenquellen (Operations Manager/Configuration Manager) sollten Sie die RAM-Kapazität für die Datenbanken entsprechend 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. Das Service Manager Sizing Helper-Tool im Dokumentationssatz zu den Service Manager-Auftragshilfen („SM_job_aids.zip“) hilft Ihnen, die Größe der Datenbank besser abzuschätzen und so zu wählen, dass sie der endgültigen Datenbankgröße näher kommt. Dies wirkt sich positiv auf die Leistung aus, da die Datenbankgröße so seltener angepasst werden muss.

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

Die Leistung des Data Warehouse-Servers hängt von der Größe Ihrer Bereitstellung und der Anzahl der Datenquellen sowie davon ab, wie viele Service Manager-Verwaltungsserver beim Data Warehouse registriert sind. Allgemein gilt, dass für den Data Warehouse-Server mindestens 8 GB RAM verfügbar sein sollten. Im Fall erweiterter Bereitstellungsszenarien, bei denen von mehr als einem Service Manager-Verwaltungsserver Daten zum Data Warehouse hinzugefügt werden, kann die Leistung durch eine Erhöhung der Speicherkapazität jedoch optimiert werden. 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.

Das Self-Service-Portal erleichtert die Archivierung von Incidents und Service Requests. Es ist nicht für Tausende von gleichzeitigen Benutzern ausgelegt.

Die Leistungstests zum Self-Service-Portal konzentrierten sich auf Situationen mit Spitzenbelastung, um sicherzustellen, dass sich montagmorgens Hunderte von Benutzern innerhalb von 5-10 Minuten anmelden und Incidents mit akzeptablen Antwortzeiten (weniger als 4-5 Sekunden) aufrufen können. Dieses Ziel wurde mit der in diesem Dokument empfohlenen Mindesthardwarekonfiguration erreicht.

Die Anzahl der von Service Manager unterstützten Servicelevel-Zielpunkte (SLO) ist nicht genau definiert. 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, dass Sie für eine typische Service Manager-Konfiguration mit 50.000 Computern maximal fünf Servicelevel-Zielpunkte 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 die Leistung Ihrer Bereitstellungskonfiguration aufgrund der Menge an Servicelevel-Zielpunkten beeinträchtigt ist, wird die Skalierung auf das nächstgrößere Bereitstellungsszenario empfohlen. Mehr hierzu finden Sie im Abschnitt Konfigurationen für Bereitstellungsszenarien dieses Handbuchs.