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

  1. Erstellen Sie ein neues Runbook.

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

  3. Klicken Sie auf die Registerkarte Allgemein , und konfigurieren Sie die Aktivität für den Vergleich von Zeichenfolgen (der Standardwert).

  4. Klicken Sie auf die Registerkarte Details , geben Sie im Feld Test den Wert ZEICHENFOLGE ein, und wählen Sie ist leeraus.

  5. Klicken Sie auf Fertig stellen , um die Änderungen an der Aktivität zu speichern.

  6. Klicken Sie mit der rechten Maustaste auf die Aktivität, und wählen Sie Schleifeaus.

  7. Aktivieren Sie das Kontrollkästchen Aktivieren , und geben Sie für Verzögerung zwischen Versuchen die Zahl 0(null) ein.

  8. Klicken Sie auf die Registerkarte Beenden .

  9. Ä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.

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

  11. Klicken Sie auf Fertig stellen , um die Aktualisierungen zu speichern.

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

Weitere Informationen

Orchestratorprotokolle– Orchestratorarchitektur