Datenbankgröße und -leistung
Wichtig
Diese Version von Orchestrator hat das Ende des Supports erreicht. Es wird empfohlen, ein Upgrade auf Orchestrator 2019 durchzuführen.
Die Größe der Datenbank ist der Schlüssel zum Verständnis der Leistung von System Center – Orchestrator. Runbook-Server, Management-Server und Webkomponenten sind in ihrer Funktion alle von der Orchestrator-Datenbank abhängig. Probleme mit Orchestrator-Bereitstellungen können durch ein unvollständiges Verständnis der Datentypen in der Datenbank und deren Verwaltung entstehen.
Da Runbook Designer mit der Orchestrator-Datenbank kommuniziert (über den Management-Server), wirkt sich eine schlechte Datenbankleistung negativ auf diese Kommunikation aus.
Die Orchestrator-Operatorerfahrung basiert auf zwei Komponenten: der Orchestrierungskonsole und dem Webdienst. Die Orchestration-Konsole ist eine Silverlight-basierte Anwendung, die für die Verbindung mit der Orchestrator-Datenbank auf den Webdienst angewiesen ist. Der Webdienst ist eine IISAnwendung, von dem die Verbindung mit der Datenbank hergestellt wird. Daher sind sowohl Webdienst als auch Orchestration-Konsole von der Leistung der Orchestrator-Datenbank abhängig.
Neben ihrer Abhängigkeit vom Webdienst verfügt die Orchestration-Konsole auch über Logik, die speziell auf die Funktion als Benutzeroberfläche abgestimmt ist und daher eigene Leistungsmerkmale aufweist.
Konfigurations- und Protokolldaten
Grob unterteilt enthält die Orchestrator-Datenbank zwei Arten von Daten:
Konfigurationsdaten
Die Orchestrator-Infrastruktur enthält Konfigurationsdaten. Diese Daten sind in Hinblick auf das Datenbankwachstum nicht relevant, da die Speicheranforderungen für diesen Datentyp gering sind.
Protokolldaten
Orchestrator erstellt verschiedene Arten von Protokolldaten, die alle im Runbook Designerangezeigt und verwaltet werden können. Die Speicheranforderungen für diese Daten sind variabel und können sehr groß sein.
Die folgende Tabelle enthält die Typen von Protokolldaten, die in der Orchestrator-Datenbank gespeichert werden können. Orchestrator speichert Daten auch in separaten Protokolldateien (außerhalb der Datenbank) für Überwachungspfade und Ablaufverfolgungen. Informationen zu allen Protokolldatentypen finden Sie unter Orchestrator Logs.
| Protokolldatentyp | Speicherort in Runbook Designer | Von Protokolllöschung erfasst? |
|---|---|---|
| Runbookprotokolle | RegisterkartenProtokoll und Protokoll History | Ja |
| Aktivitätsereignisse (Plattformereignisse) | RegisterkarteEreignisse | Nein |
| Überprüfen des Verlaufs | RegisterkarteÜberwachungsverlauf | Nein |
Plattformcode und Domänencode
Orchestrator-Runbookaktivitäten enthalten zwei verschiedene Codetypen:
Plattformcode
Die ist gemeinsamer, von den meisten Aktivitäten genutzter Code. Mit seiner Hilfe werden allgemeine Aufgaben der Orchestrator-Aktivitäten ausgeführt. Vom Plattformcode werden gemeinsame veröffentlichte Daten erzeugt.
Domänencode
Von diesem Code wird eine Vielzahl von Tasks ausgeführt, die für die Aktionen der jeweiligen Aktivität spezifisch sind und in der Regel nicht mit der Orchestrator-Plattform selbst verbunden sind. Prinzipiell kann es große Unterschiede zwischen dem Plattformcode und dem Domänencode geben.
Die für eine bestimmte Aktivität erzeugten Protokolldaten können ein- oder mehrwertige Datenelemente enthalten. Von jeder Aktivität wird ein einzelner Datensatz einwertiger Daten erzeugt. Mit dem Domänencode können mehrere Datensätze mehrwertiger Daten erzeugt werden. Daher muss von diesem Code ermittelt werden, wie die von vorherige Aktivitäten empfangenen gemeinsamen veröffentlichten Daten von der Aktivität verwendet werden.
Orchestrator-Runbooks sind im Prinzip dazu bestimmt, Daten zwischen diskreten Elementen des Domänencodes zu übertragen. Darüber hinaus können vom Domänencode optional aktivitätsspezifische veröffentlichte Daten erzeugt werden.
Die Funktionsweise von allen Runbooks ist vom Prinzip her ähnlich. Sie sind für die Ausführung von aus Domänencode und Plattformcode bestehenden Aktivitäten, Workflow-Schleifen und Verzweigungen zuständig. Eine Verzweigung tritt auf, wenn ein Runbook von einem anderen Runbook zur Ausführung eines bestimmten Tasks aufgerufen wird. Wenn ein Runbook erstmalig aufgerufen wird, besteht es aus einem einzelnen Thread. Trifft dieser Thread auf eine Runbookaktivität, für deren Links eine Verzweigung erforderlich ist, werden zusätzliche Threads erstellt – einer für jede Verzweigung. Von jedem Thread werden als Eingabe die gemeinsamen veröffentlichten Daten der Aktivität verwendet, von der die Verzweigung erstellt wurde. Diese Daten korrelieren wiederum mit den vorherigen Aktivitäten im Runbook, um die gemeinsamen veröffentlichten, von den Aktivitäten abonnierten Daten zu aktualisieren.
Domänencode wirkt sich möglicherweise auf die Datenbankleistung stärker aus als das von Verzweigungen generierte Multithreading. Der Grund hierfür ist, dass von Domänencode große Menge aktivitätsspezifischer veröffentlichter Daten erzeugt werden können.
Protokollierungsoptionen
Über die Registerkarte Protokollierung in den Eigenschaften eines Runbooks können Sie optional Protokollierungseinträge speichern. Bei der Standardprotokollierung ist keine der beiden Optionen für veröffentlichte Daten ausgewählt. In diesem Fall werden für jede Aktivität 524 Byte an Daten generiert. Die Protokollierungsoptionen bieten zwei Kategorien für veröffentlichte Daten:
Allgemeine veröffentlichte Daten
Der Satz von Datenelementen, den alle Aktivitäten gemeinsam haben. Eine Liste finden Sie unter Runbookprotokolloptionen.
Von dieser Protokollierungsoption werden für jede Aktivität 6082 Byte an Daten generiert.
Aktivitätsspezifische veröffentlichte Daten
Dieser für die Aktivität spezifische Datensatz wird optional von Domänencode erstellt.
Von dieser Protokollierungsoption werden zusätzlich zu den von bestimmten Aktivitäten protokollierten Daten 6082 Byte an Daten generiert.
[TIPP]
Diese Option wird in erster Linie für Debugzwecke verwendet. Lassen Sie die Option deaktiviert, um das durch die Protokollierung verursachte Wachstum zu begrenzen.
Das Festlegen der Protokollierungsoptionen kann die Leistung erheblich beeinträchtigen und das Datenbankwachstum beschleunigen. Stellen Sie sich ein Szenario vor, bei dem die gleiche Runbookaktivität zweimal ausgeführt wird, einmal mit Datenprotokollierung auf der Standardstufe (keine der Optionen für veröffentlichte Daten ausgewählt) und einmal mit aktivierter Protokollierung der gemeinsamen veröffentlichten Daten. Für die Ausführung des Domänencodes sollte dieselbe Zeit erforderlich sein. Die Ausführung des Plattformcodes wird jedoch länger dauern, da von ihm im Vergleich zur Standardprotokollierung durch die Protokollierung gemeinsamer veröffentlichter Daten die zwölffache Menge an Daten verarbeitet werden muss.
Löschen von Protokollen
Die Standardoptionen, die für die Protokollbereinigungsfunktion im Runbook Designer angegeben sind, sind so konfiguriert, dass sie die beste Benutzererfahrung für eine standardmäßige Orchestratorbereitstellung bieten. Eine Änderung dieser Werte kann sich auf die Leistungsmerkmale der Umgebung auswirken und sollte daher nur schrittweise und unter genauer Beobachtung erfolgen, sodass die Auswirkungen einer Änderung ausgewertet werden können.
Weitere Informationen zum automatischen und manuellen Löschen von Protokollen finden Sie unter Bereinigen von Runbookprotokollen.
Erstellen von Leistungstests
Sie können ein einfaches Runbook zum Testen des Protokollwachstums anlegen, indem Sie mithilfe der Standardaktivität Werte vergleichen Benchmarks einer Orchestrator-Umgebung erstellen.
Mit dem folgenden Verfahren wird ein einfaches Runbook erstellt, von dem eine Aktivität Werte vergleichen 10.000-mal ausgeführt wird. Werte vergleichen ist eine sehr einfache Aktivität mit nur minimalem Domänencode. Dieses Runbook kann unter einer Vielzahl von Umständen aufgerufen werden, um die Gesamtleitung einer bestimmten Orchestrator-Laufzeitumgebung zu bestimmen.
So erstellen Sie ein Runbook, mit dem ein Vergleichstest für Ihre Orchestrator-Umgebung ausgeführt werden kann
Erstellen Sie ein neues Runbook.
Fügen Sie aus der Palette der Standardaktivitäten eine Aktivität Compare Values hinzu. Doppelklicken Sie auf die Aktivität, um sie zu konfigurieren.
Klicken Sie auf die Registerkarte Allgemein , und konfigurieren Sie die Aktivität für den Vergleich von Zeichenfolgen (der Standardwert).
Klicken Sie auf die Registerkarte Details , geben Sie im Feld Test den Wert ZEICHENFOLGE ein, und wählen Sie ist leeraus.
Klicken Sie auf Fertig stellen , um die Änderungen an der Aktivität zu speichern.
Klicken Sie mit der rechten Maustaste auf die Aktivität, und wählen Sie Schleifeaus.
Aktivieren Sie das Kontrollkästchen Aktivieren , und geben Sie für Verzögerung zwischen Versuchen die Zahl 0(null) ein.
Klicken Sie auf die Registerkarte Beenden .
Ändern Sie die Standardendbedingung. Klicken Sie auf Werte vergleichen, aktivieren Sie das Kontrollkästchen Allgemeine veröffentlichte Daten anzeigen, und wählen Sie Schleife: Anzahl der Versucheaus. Klicken Sie auf OK , um diese Änderung zu speichern.
Wählen Sie aus der aktualisierten Endbedingung Wert aus, und geben Sie die Zahl 10000 (zehntausend) ein. Klicken Sie auf OK , um diese Änderung zu speichern.
Klicken Sie auf Fertig stellen , um die Aktualisierungen zu speichern.
Klicken Sie auf Einchecken , um die Änderungen in der Orchestrator-Datenbank zu speichern.
Mit diesem Runbook kann mit unterschiedlichen Orchestrator-Konfigurationen experimentiert werden. Beispielsweise können Sie Benchmark-Runbooks erstellen, um die Leistung von vier in unterschiedlichen Rechenzentren bereitgestellten Runbook-Servern zu ermitteln.
| Rechenzentrum | Protokollierungskonfiguration | Laufzeit des Plattformcodes (Millisekunden) | Millisekunden pro Aktivität | Skalierungsfaktor |
|---|---|---|---|---|
| Standort 1 | Standardprotokollierung | 819 | 82 | 1,0 (Referenz) |
| Standort 1 | Protokollierung der gemeinsamen veröffentlichten Daten | 2012 | 201 | 2.5 |
| Standort 2 | Standardprotokollierung | 1229 | 123 | 1.5 |
| Standort 2 | Protokollierung der gemeinsamen veröffentlichten Daten | 3686 | 369 | 4,5 |
| Standort 3 | Standardprotokollierung | 2457 | 426 | 3.0 |
| Standort 3 | Protokollierung der gemeinsamen veröffentlichten Daten | 4422 | 442 | 5.4 |
| Standort 4 | Standardprotokollierung | 1474 | 147 | 1.8 |
| Standort 4 | Protokollierung der gemeinsamen veröffentlichten Daten | 2654 | 265 | 3.2 |
Beachten Sie den signifikanten Abfall der Plattformleistung, der durch die Protokollierung der gemeinsamen veröffentlichten Daten verursacht wird. Die schlechteste Leistung scheint bei der Protokollierung der gemeinsamen veröffentlichten Daten an Standort 2 erreicht zu werden. Oberflächlich ist dies eine klare und relevante Schlussfolgerung.
Diese Zahlen ergeben sich ausschließlich aus dem Mehraufwand des Plattformcodes und werden nicht vom Domänencode verursacht. Die Laufzeiten des Domänencodes können wesentlich länger sein. Die Ausführung der Aktivität VM aus Vorlage erstellen im Virtual Machine Manager Integration Pack kann mehrere Minuten dauern. In einem auf dem vorherigen Beispiel aufbauenden erweiterten Szenario werden standortunabhängig die Plattformcodekosten für eine Runbookaktivität betrachtet, deren Ausführung eine Minute dauert (1 Minute = 60.000 Millisekunden).
| Rechenzentrum | Protokollierungskonfiguration | Laufzeit des Plattformcodes (Millisekunden) | % Domänencode | % Plattformcode |
|---|---|---|---|---|
| Standort 1 | Standardprotokollierung | 819 | 98,6 % | 1,4 % |
| Standort 1 | Protokollierung der gemeinsamen veröffentlichten Daten | 2012 | 96,7 % | 3,3 % |
| Standort 2 | Standardprotokollierung | 1229 | 98,0 % | 2,0 % |
| Standort 2 | Protokollierung der gemeinsamen veröffentlichten Daten | 3686 | 93,9 % | 6,1 % |
| Standort 3 | Standardprotokollierung | 2457 | 95,9 % | 4,1 % |
| Standort 3 | Protokollierung der gemeinsamen veröffentlichten Daten | 4422 | 92,6 % | 7,4 % |
| Standort 4 | Standardprotokollierung | 1474 | 97,5 % | 2,5 % |
| Standort 4 | Protokollierung der gemeinsamen veröffentlichten Daten | 2654 | 95,6 % | 4,4 % |
Aus diesen Daten ergibt sich ein klareres Bild. Das Szenario bei dem die Protokollierung der gemeinsamen veröffentlichten Daten an Standort 2 aktiviert ist, erbringt weiterhin die schlechteste Leistung. Jedoch sind Plattformcode und Protokollierung nur für 6 % der gesamten Laufzeit verantwortlich. Dieser Wert ist zwar bedeutsam, er entspricht jedoch im günstigsten Fall nur 1,4 % der gesamten Laufzeit. Generell übersteigt in diesem Beispiel die für den Domänencode erforderliche Zeit bei weitem die Zeit, die für die Ausführung des Plattformcodes erforderlich ist. Anders ausgedrückt, wenn es gelänge, die Plattformcodekosten auf null zu senken, würde die Runbookleistung doch nur um 1,4 bis 7,4 % steigen.
Die meisten Szenarios in der Realität sehen natürlich anders aus. Das Verhalten einer Aktivität ändert sich in Abhängigkeit von der Aufgabe des Domänencodes. Eine Aktivität VM aus Vorlage klonen könnte beispielsweise für das Klonen einer VM aus der Servervorlage A nur eine Minute brauchen, für das Klonen einer VM aus Servervorlage B aber fünf Minuten. Außerdem können sich die Runbook-Server-Computer in unterschiedlichen Netzwerken mit unterschiedlichen Leistungsmerkmalen befinden, was sich potenziell sowohl auf die Domänencodeleistung als auch auf die Orchestrator-Datenprotokollierungsleistung auswirken kann.
Bestimmen des Datenbankwachstums
Ihr Datenbankadministrator für die Orchestrator-Datenbank kann mithilfe der folgenden Richtlinien eine Strategie für das Wachstum der Datenbankdatei bestimmen:
Generell führt das Aufrufen eines Runbooks nicht zu einer Vergrößerung der Datenbankdateien. Die Dateien wachsen dann, wenn die enthaltenen Daten eine bestimmte von Ihrem Datenbankadministrator konfigurierte Obergrenze erreichen.
Sorgen Sie dafür, dass jede Ausführung einer Runbookaktivität einzeln erfasst wird, und berücksichtigen Sie dabei, dass eine Schlaufenfunktion zur mehrfachen Ausführung einer einzelnen Aktivität führen kann.
Sie können den für jeden Aufruf eines Runbooks erforderlichen Speicherplatz bestimmen, indem Sie die Anzahl der Aktivitäten im Runbook mit der Anzahl der Bytes, die der Datenbank entsprechend der ausgewählten Protokollierungsstufe hinzugefügt werden, multiplizieren. Die Werte lauten wie folgt:
524 Byte
Konfiguration mit Standardprotokollierung
6082 Byte
Protokollierungsstufe mit allgemeinen veröffentlichten Daten
6082 Byte + durch Aktivität protokollierte Daten
Protokollierungsstufe mit aktivitätsspezifischen veröffentlichten Daten
Standardmäßig erfolgt in Orchestrator täglich um 2:00 Uhr eine Löschung der Runbookprotokolle. Für jedes Runbook werden dabei nur die letzten 500 Protokolle beibehalten. Multiplizieren Sie zum Bestimmen des erforderlichen Speicherplatzes den für jeden Aufruf des Runbook erforderlichen Speicher mit 500. Wenn Sie die Einstellung für das Löschen von Protokollen ändern, multiplizieren Sie jeden Aufruf mit der geschätzten Anzahl von Aufrufen pro Tag, Woche oder Monat.
In der folgenden Tabelle werden die Wachstums- und Leistungsschätzungen für die Protokollierungskonfigurationen angegeben.
| Protokolliergrad | Wachstumsfaktor der Datenbank | Leistungsfaktor | Empfohlen für Produktion |
|---|---|---|---|
| Standard | 1 | 1 | Ja |
| Gemeinsame veröffentlichte Daten | 11,6-fach | 2,5-fach | Eingeschränkte Verwendung bei Planung |
| Aktivitätsspezifische veröffentlichte Daten | Mehr als 11,6-fach | Mehr als 2,5-fach | Nein |
Beispiele
Beispiel 1
In der folgenden Tabelle werden die Überlegungen zur Dimensionierung der Datenbank für eine Bereitstellung von Orchestrator beschrieben.
| Runbookname | Anzahl der Aktivitäten | Protokolliergrad | Aufrufe pro Tag |
|---|---|---|---|
| Runbook 1 | 50 | Standard | 100 |
| Runbook 2 | 25 | Standard | 50 |
| Runbook 3 | 12 | Gemeinsame veröffentlichte Daten | 24 |
| Runbook 4 | 8 | Gemeinsame veröffentlichte Daten | 500 |
Anhand der oben angegebenen Datenbankgrößen können Sie die Speicheranforderungen für die Runbooks schätzen.
| Runbookname | Byte pro Aufruf | Speicher in MB Standardprotokolllöschung (500 Aufrufe) |
Aufrufe pro Monat | Speicher in MB in einem Monat (keine Standardprotokolllöschung) |
% des Datenbankspeichers nach 30 Tagen |
|---|---|---|---|---|---|
| Runbook 1 | 26.200 | 12,5 | 3,000 | 74.5 | 9 % |
| Runbook 2 | 13.100 | 6.2 | 1\.500 | 18,7 | 2 % |
| Runbook 3 | 72.984 | 34,8 | 720 | 50,1 | 6 % |
| Runbook 4 | 48.656 | 23,2 | 15.000 | 696,0 | 83 % |
| Gesamt: 76,7 MB | Gesamt: 839,8 MB |
Anhand dieses Beispiels können Sie deutlich erkennen, wie wichtig fundierte Entscheidungen für die Datenprotokollierung sind. Runbook 4 enthält nur acht Aktivitäten, aber bei Konfiguration mit der Protokollierungsstufe mit allgemeinen veröffentlichten Daten wird aufgrund der hohen Aufrufhäufigkeit mehr Speicherplatz in der Datenbank belegt. Basierend auf diesen Ergebnissen ist es möglicherweise angebracht, die Protokollierungsstufe von Runbook 4 auf die Standardprotokollierung herunterzusetzen.
Beispiel 2
In der folgenden Tabelle werden die Überlegungen zur Dimensionierung der Datenbank für eine andere Bereitstellung von Orchestrator beschrieben.
| Runbookname | Anzahl der Aktivitäten | Protokolliergrad | Aufrufe pro Tag |
|---|---|---|---|
| Runbook 1 | 50 | Standard | 100 |
| Runbook 2 | 25 | Standard | 50 |
| Runbook 3 | 12 | Gemeinsame veröffentlichte Daten | 24 |
| Runbook 4 | 8 | Standard | 500 |
Eine Neuberechnung der Speicherwerte für die aktualisierte Konfiguration führt zu deutlich abweichenden Ergebnissen.
| Runbookname | Byte pro Aufruf | Speicher in MB Standardprotokolllöschung (500 Aufrufe) |
Aufrufe pro Monat | Speicher in MB in einem Monat (keine Standardprotokolllöschung) |
% des Datenbankspeichers nach 30 Tagen |
|---|---|---|---|---|---|
| Runbook 1 | 26.200 | 12,5 | 3,000 | 74.5 | 37 % |
| Runbook 2 | 13.100 | 6.2 | 1\.500 | 18,7 | 9 % |
| Runbook 3 | 72.984 | 34,8 | 720 | 50,1 | 25 % |
| Runbook 4 | 4.192 | 2.0 | 15.000 | 60,0 | 29 % |
| Gesamt: 55,5 MB | Gesamt: 203,8 MB |
Während es bei der Konfiguration für die Standardprotokollierung (500 Protokolleinträge pro Runbook) nur wenig Änderungen gibt, haben sich die Anforderungen für die 30-Tage-Speicherung deutlich geändert. Es ist offensichtlich, dass die aus der Protokollierung gemeinsamer veröffentlichter Daten für Runbook 4 entstehenden Speicherkosten bedacht werden sollten, da diese Änderung zu einer Senkung der Datenspeicheranforderungen für die 30-Tage-Speicherung um 76 % führt.
Zusammenfassung
Beachten Sie bei der Verwaltung von Datenbankgröße und -leistung die folgenden Richtlinien:
Aktivieren Sie Protokollierung von gemeinsamen veröffentlichten Daten nur im Bedarfsfall.
Bedenken Sie, dass die Häufigkeit der Ausführung von Aktivitäten Auswirkungen auf die Menge der protokollierten Daten hat. Ein kleines Runbook mit nur wenigen Aktivitäten, das mehrmals ausgeführt wird, kann zu mehr protokollierten Daten führen als ein größeres Runbook, das seltener ausgeführt wird.
Aktivieren Sie die Protokollierung aktivitätsspezifischer Daten nicht in Produktionsumgebungen sondern nur zu Debugzwecken.
Entwickeln Sie ein Verständnis dafür, wie viel Zeit von Ihren Runbooks für die Ausführung von Domänencode im Vergleich zur Ausführung von Plattformcode benötigt wird.
Schätzen Sie die Plattformcodekosten mithilfe der in diesem Dokument beschriebenen Techniken ein. Verwenden Sie das Ergebnis als Referenz bei der Frage, wo Verbesserungen bei der Runbookleistung sinnvoll sind.
Identifizieren Sie mithilfe normalisierter Vergleiche Ihrer Messwerte Verbesserungsmöglichkeiten.