DE102019131291A1

DE102019131291A1 - Gleichzeitige ausführung von dienstleistungen

Info

Publication number: DE102019131291A1
Application number: DE102019131291.4A
Authority: DE
Inventors: Peter Michael Bruun; Jane Koenigsfeldt; Mads Stenhuus
Original assignee: Hewlett Packard Enterprise Development LP
Current assignee: Hewlett Packard Enterprise Development LP
Priority date: 2018-11-21
Filing date: 2019-11-20
Publication date: 2020-05-28
Anticipated expiration: 2039-11-21
Also published as: CN111208975A; US20220164222A1; US11281491B2; DE102019131291B4; US11947996B2; US20200159569A1

Abstract

Verfahren zum gleichzeitigen Ausführen einer Orchestrierung von Computerdiensten, wobei das Verfahren das Entwickeln einer Darstellung eines Satzes von Diensten umfasst, wobei sich jeder Dienst über verschiedene Arten von Beziehungen auf andere Dienste bezieht. Durch Anwenden eines Satzes von Abhängigkeitsregeln für jeden Beziehungstyp innerhalb des Satzes von Diensten, so dass die Anwendung der Abhängigkeitsregeln schrittweise Abhängigkeiten zwischen Schritten erzeugt, die Zustandsübergänge des Satzes von Diensten darstellen, und Entwickeln des Orchestrierungsplans auf der Grundlage von inter -step-Abhängigkeiten, die die gleichzeitige Ausführung von nicht abhängigen Schritten ermöglichen.

Description

HINTERGRUND
Orchestrierung definiert Richtlinien und Service-Levels durch automatisierte Workflows, Bereitstellung und Änderungsverwaltung. Orchestrierungsanwendungen können im Zusammenhang mit serviceorientierter Architektur, Virtualisierung, Bereitstellung, konvergierter Infrastruktur, Telekommunikation und Rechenzentrumsthemen erörtert werden. Insofern bietet Orchestrierung eine zentralisierte Verwaltung von Computerressourcen, die eine Verwaltung ermöglicht, einschließlich der Möglichkeit, Anwendungen für einen definierten Zweck zu erstellen, zu konfigurieren, zu entfernen oder auf andere Weise zu ändern.
Figurenliste
Hier beschriebene Beispiele können unter Bezugnahme auf die folgende Beschreibung in Verbindung mit den beigefügten Zeichnungen verstanden werden, in denen gleiche Bezugszeichen gleiche Elemente bezeichnen.

1 ist eine schematische Darstellung eines Systems zur Erfüllung Dienste in Übereinstimmung mit einer oder mehreren beispielhaften Ausführungsformen.
2 ist ein Zustandsmodell in Übereinstimmung mit einer oder mehreren beispielhaften Ausführungsformen.
3 ist eine Darstellung der Leistungsbeziehungen in Übereinstimmung mit einer oder mehreren beispielhaften Ausführungsformen.
4 ist eine Darstellung einer Systemarchitektur eine Orchestrierung Ausführungsplan in Übereinstimmung mit einer oder mehreren beispielhaften Ausführungsformen zu entwickeln.
5 ist ein Schritt-Diagramm und Scheduler in Übereinstimmung mit einer oder mehreren beispielhaften Ausführungsformen.
6 ist ein Flussdiagramm eines Verfahrens der Dienste gleichzeitig in Übereinstimmung mit einer oder mehreren beispielhaften Ausführungsformen ausgeführt werden .
7 ist eine beispielhafte Rechenvorrichtung mit einem Hardwareprozessor und zugänglichen maschinenlesbaren Anweisungen gemäß einer oder mehreren beispielhaften Ausführungsformen.
8 ist eine schematische Darstellung einer Computerverarbeitungsvorrichtung, die zum Implementieren von Funktionen und Prozessen gemäß einer oder mehreren beispielhaften Ausführungsformen verwendet werden kann.

Während hier beschriebenen Beispiele sind anfällig für verschiedene Modifikationen und alternative Formen, werden die Zeichnungen veranschaulichen spezifische Ausführungsformen hier im Detail anhand von Beispielen beschrieben. Es versteht sich jedoch, dass die Beschreibung hierin spezifischer Ausführungsformen nicht auf die bestimmten offenbarten Formen beschränkt sein soll, sondern im Gegenteil alle Modifikationen, Äquivalente und Alternativen abdecken soll, die in den Geist und Umfang von fallen die hier beschriebenen Beispiele und die beigefügten Ansprüche.
DETAILLIERTE BESCHREIBUNG
Ein oder mehrere Beispiele werden unter Bezugnahme auf die beigefügten Figuren ausführlich beschrieben. Der Konsistenz halber sind gleiche Elemente in den verschiedenen Figuren mit gleichen Bezugszeichen versehen. In der folgenden detaillierten Beschreibung werden spezifische Details dargelegt, um ein gründliches Verständnis des nachstehend beanspruchten Gegenstands zu ermöglichen. In anderen Fällen werden dem Fachmann bekannte Merkmale, die den Vorteil dieser Offenbarung haben, nicht beschrieben, um die Beschreibung des beanspruchten Gegenstands nicht zu verschleiern.
Orchestrierung bietet einen Prozess von Aktionen, die darauf abzielen , in einer Service-Orchestrierungsanforderung definierte Ziele zu erreichen. Die Service-Orchestrierung kann das Zusammenstellen von Architektur, Tools und Prozessen, das Zusammenfügen von Software- und Hardwarekomponenten sowie gegebenenfalls das Verbinden und Automatisieren von Workflows umfassen, um einen definierten Service bereitzustellen. Da der Bedarf an neuen Ressourcen mit der Einführung neuer Anwendungen steigt, können automatisierte Tools über die Orchestrierung Aufgaben ausführen, die zuvor von mehreren Administratoren ausgeführt wurden, die einzelne Teile eines physischen Stacks bearbeiten. Das Serialisieren von Statusmodellen gibt eine Folge von Ereignissen an, die auf der Änderung eines oder mehrerer Knoten des Modells basieren. Das Serialisieren von Abhängigkeitsgraphenmodellen kann für vereinfachte Zerlegungsmodelle und zustandslose Modelle verwendet werden. Für komplexere Graphmodelle können jedoch andere Lösungen implementiert werden, um eine größere Anzahl möglicher Modelltransformationen zu lösen.
„Dienste“, wie hierin erläutert, bezieht sich auf die Orchestrierung von Änderungen in einem komplexen System, einschließlich interaktiver Dienste, Netzwerke und Systeme zur Erstellung von Kommunikationsdiensten.
Eine Lösung verwendet Ad-hoc- Zerlegungsmethoden und Ausführungspläne auf Warteschlangenbasis. Beispielsweise kann von einem Prozessor ausführbarer Maschinencode Aktionswarteschlangen in einer Reihenfolge verschieben, die dazu bestimmt ist, die richtige Abfolge von Aktionen zu erzeugen. Diese Lösung führt zu unvorhersehbaren Instanzen und ist möglicherweise nicht in der Lage, komplexe Neuerstellungen bestimmter Anwendungsfälle zu verarbeiten. Die Verwendung von Dekompositionsmethoden und warteschlangenbasierten Ausführungen ist beispielsweise einschränkend, wenn Zustandsübergänge durchlaufen werden, die Teile einer Konfigurationstopologie effektiv abreißen und neu erstellen. Darüber hinaus sind Ad-hoc- Ansätze möglicherweise nicht in der Lage, widersprüchliche Anforderungen zu erkennen, die dazu führen können, dass Ausführungsmodule unvorhersehbare Arbitrierungsentscheidungen treffen. Unvorhersehbare Arbitrierungsentscheidungen führen zu einer instabilen End-to-End-Orchestrierungslösung, wenn die Lösung nicht mehr testbar ist.
Bei einer zweiten Lösung werden als Diagrammvorlagen deklarierte Modelle verwendet, die als Topologie- und Orchestrierungsspezifikation für Cloud-Anwendungen („TOSCA“) bezeichnet werden, um die Standardsprache für strukturierte Informationsstandards („OASIS“) zu verbessern. In der TOSCA OASIS-Lösung wird die Standardsprache verwendet, um eine Topologie cloudbasierter Webdienste, deren Komponenten, Beziehungen und die Prozesse zu beschreiben, mit denen die Webdienste verwaltet werden. Die resultierenden Modelle in dieser Lösung sind statisch und können nicht geändert werden. Änderungen an den resultierenden Modellen führen zu einem Abbau und einer Wiederherstellung des gesamten Modells und der Komponenten. Dies kann zu Ausfallzeiten führen.
Eine dritte Lösung verwendet Dienste, die durch hierarchische Zerlegung definiert sind und eine Art vereinfachtes Modell darstellen. Bei der hierarchischen Zerlegung wird ein hierarchischer Entscheidungsprozess verwendet, um eine Abfolge von Aktionen zu bewerten. Diese Lösung erfasst jedoch möglicherweise keine Dienste mit Graphenstruktur, da Änderungen an der Hierarchiestruktur eine Neugestaltung der vollständigen Struktur hervorrufen würden. In diesem Beispiel handelt es sich bei der hierarchischen Zerlegungslösung eher um einen statischen Ansatz, bei dem keine Änderungen vorgenommen werden, wenn Änderungen an Diensten vorgenommen werden. Daher können Änderungen, die sich über die Hierarchie erstrecken, möglicherweise nicht ohne eine vollständige Neugestaltung verarbeitet werden. In einem anderen Beispiel der hierarchischen Zerlegung kann ein Baummodell verwendet werden, um eine Beziehung zwischen Diensten darzustellen. In einem solchen Modell kann jeder Knoten in der Struktur einen Elternknoten und / oder einen Kindknoten enthalten. Baumstrukturen sind modelltechnisch einfacher als andere Zerlegungs- und Zustandsmodelle. Solche Modelle berücksichtigen nicht die schwierigeren und komplexeren Modelle, die verschiedene Abhängigkeiten zwischen den Knoten des Baums enthalten. In bestimmten Situationen können die Knoten keine Gemeinsamkeiten aufweisen.
Eine andere Lösung verwendet ein vereinfachtes Zustandsmodell, bei dem die verschiedenen Zustände eines Dienstes voneinander abhängig sind. In dieser Lösung wird ein Knoten in einem Diagramm im Status als vollständig konfiguriert oder nicht vorhanden dargestellt. Dieser Ansatz verringert das Problem der Modellierung der Abhängigkeiten zwischen Zuständen verwandter Knoten im Diagramm. ist jedoch nicht in der Lage, die Komplexität externer Systemkonfigurationen zu bewältigen.
Lösungen für die Planung von Ausführungsschritten auf der Grundlage komplexer abhängiger Modelle berücksichtigen nicht die Beziehung zwischen Prozessschritten. Die Schritte werden linear ausgeführt. Die lineare Ausführung der Schritte verlangsamt die Verarbeitung, da Schritte, die nicht von der Ausführung eines Schritts abhängig sind, inaktiv bleiben. Die vorliegende Offenbarung umfasst einen Planer, der bestimmt, ob Schritte voneinander abhängig sind. Dadurch können nicht abhängige Schritte gleichzeitig abgearbeitet werden. Der Planer bearbeitet komplexe Schrittdiagramme mit zustandsbasierten Beziehungen zwischen den Diagrammknoten.
Insbesondere verwendet die vorliegende Offenbarung Computersysteme, um eine Darstellung eines Satzes von Diensten zu erstellen. Basierend auf den Beziehungen wird für jeden Beziehungstyp in der Darstellung ein Satz von Abhängigkeitsregeln angewendet. In Reaktion auf die Anwendung des Satzes von Abhängigkeitsregeln werden schrittweise Abhängigkeiten zwischen Schritten erzeugt, die Zustandsübergänge für den Satz von Diensten darstellen. Aus den schrittweisen Abhängigkeiten kann ein Orchestrierungsplan entwickelt werden. Der Orchestrierungsplan wird aus einem generierten Schrittdiagramm abgeleitet, das die Beziehungen zwischen den dargestellten Schritten definiert. Der Schrittgraph kann beispielsweise ein gerichteter Graph oder eine andere Art der Darstellung der Beziehungen zwischen verschiedenen Schritten sein. Der Schrittgraph kann dadurch das gleichzeitige Planen und Ausführen von nicht abhängigen Schritten ermöglichen, was es dem System ermöglicht, Schritte kontinuierlich zu verarbeiten, während weniger Zeit auf nicht abhängige Schritte gewartet wird.
Implementierungen der vorliegenden Offenbarung können ferner Modellierer, Planer, Planer und Ausführer bereitstellen, die es ermöglichen, dass Schritte gleichzeitig ausgeführt werden. In bestimmten Implementierungen kann der Modellierer eine Darstellung jedes Schritts entwickeln, da er sich auf andere Schritte bezieht. Der Planer kann dann einen Satz von Abhängigkeitsregeln für jeden Beziehungstyp zwischen jedem Schritt anwenden. Die Entwicklung der Inter-Step-Abhängigkeiten kann dadurch die Entwicklung eines Orchestrierungsplans ermöglichen, der die gleichzeitige Ausführung von nicht abhängigen Schritten ermöglicht. Ein Scheduler kann die Abhängigkeiten zwischen den einzelnen Schritten verfolgen und so die Ausführung von Schritten ermöglichen, die nicht von einem vorherigen Schritt abhängen. Dementsprechend kann der Planer den Schrittplan aktualisieren, wenn die Schritte abgeschlossen sind, wodurch alle nicht abhängigen Schritte ausgeführt werden können. Die gleichzeitige Ausführung solcher Schritte kann dadurch schnellere Bearbeitungszeiten ermöglichen. Ein solches System kann auch einen Executor haben, der mit dem Planer verbunden ist, der die vom Scheduler angegebenen, nicht abhängigen Schritte ausführt.
In 1 ist eine schematische Darstellung eines Systems zum Erfüllen von Diensten gemäß einer oder mehreren Ausführungsformen gezeigt. In einem solchen System 100 ist ein Prozessor 105 mit einem Modellierer 110 und einem Planer 115 verbunden. In bestimmten Systemen 100 kann mehr als ein Prozessor 105 mit dem Modellierer 110 und / oder dem Planer 115 verbunden sein. Der Prozessor 105 kann ein virtuelles Gerät oder ein physikalisches Gerät wie eine elektronische Schaltung enthalten, die eine integrierte Schaltung, eine programmierbare Schaltung, eine integrierte Anwendungsschaltung, einen Controller, einen Prozessor, einen Halbleiter, eine Verarbeitungsressource, einen Chipsatz oder andere Arten von Komponenten enthält, die das System 100 verwalten können .
Der Modellierer 110 erstellt ein Modell (nicht gezeigt), das einen Satz von Diensten und Beziehungen zwischen solchen Diensten darstellt. Das Modell kann als Eingabe für den Planer 115 verwendet werden, der Abhängigkeitsregeln anwenden kann, um die verschiedenen Arten von Beziehungen zwischen den Diensten zu definieren. Beispiele für Beziehungen können zwei oder mehr Dienste umfassen, die als Geschwister verbunden sind, wobei die Dienste möglicherweise gleichzeitig ausgeführt werden und nicht aufeinander angewiesen sind. Andere Arten von Beziehungen können Eltern-Kind-Beziehungen umfassen, wobei der Kind-Dienst auf dem Eltern-Dienst beruhen kann. In einer solchen Eltern-Kind-Beziehung wird der Kind-Dienst möglicherweise erst ausgeführt, wenn der Eltern-Dienst abgeschlossen ist . Die Anwendung von Abhängigkeitsregeln erzeugt dabei schrittweise Abhängigkeiten zwischen bestimmten Schritten innerhalb einer Reihe von Diensten. Das Erstellen von Abhängigkeiten zwischen Schritten ermöglicht es dem Planer 115, einen Orchestrierungsplan zu entwickeln, der ein Schrittdiagramm enthält, das eine Ausführungsreihenfolge für bestimmte Schritte definiert.
Wie nachstehend ausführlich erörtert wird, kann der Schrittgraph die gleichzeitige Ausführung von nicht abhängigen Schritten ermöglichen. Der Modellierer 110 kann ein physikalisches Gerät wie eine elektronische Schaltung sein, die eine integrierte Schaltung, eine programmierbare Schaltung, eine integrierte Anwendungsschaltung, eine Steuerung, einen Prozessor, einen Halbleiter, eine Verarbeitungsressource, einen Chipsatz oder andere Arten von Komponenten umfasst, die das System 100 verwalten können. Alternativ kann der Modellierer 110 Anweisungen enthalten, die z . B. auf einem maschinenlesbaren Medium gespeichert sind und die, wenn sie vom Prozessor 105 ausgeführt werden, das Modell erstellen. Implementierungen des Modells können Zustandsmodelle, ein Multi-Technologie-Operations-System-Schnittstellenmodell („MTOSI“), Konzeptionsmodelle, mathematische Modelle, Computermodelle oder andere Modelltypen umfassen, die die Vernetzung des Satzes von Diensten mit jedem veranschaulichen andere durch die unterschiedlichen Arten von Beziehungen.
Der Planer 115 kann das vom Modellierer 110 bereitgestellte Modell verwenden, um Abhängigkeitsregeln anzuwenden, um schrittweise Abhängigkeiten zwischen den verschiedenen Diensten zu erzeugen. Basierend auf der Erzeugung der Inter-Step-Abhängigkeiten kann der Planer 115 fortfahren, einen Orchestrierungsplan zu entwickeln. In bestimmten Implementierungen kann der Planer 115 vor der Entwicklung des Orchestrierungsplans einen Schrittgraphen entwickeln, wie nachfolgend detailliert dargestellt wird. Der Planer 115 kann das Modell verwenden, um zu bestimmen, ob bestimmte Schritte abhängig oder nicht abhängig sind. Dann können nicht abhängige Schritte identifiziert und zur gleichzeitigen Ausführung eingeplant werden. Zu den nicht abhängigen Schritten können alle Schritte gehören, die nicht von anderen Schritten im Plan abhängen, und werden im Folgenden ausführlich erläutert.
Der Planer 115 kann ein physikalisches Gerät wie eine elektronische Schaltung sein, die eine integrierte Schaltung, eine programmierbare Schaltung, eine integrierte Anwendungsschaltung, eine Steuerung, einen Prozessor, einen Halbleiter, eine Verarbeitungsressource, einen Chipsatz oder andere Arten von Komponenten umfasst, die das System 100 verwalten können. Alternativ kann der Planer 115 Anweisungen enthalten, die z . B. auf einem maschinenlesbaren Medium gespeichert sind und bei Ausführung durch den Prozessor 105 den Orchestrierungsplan entwickeln.
Abhängigkeitsregeln können verwendet werden, um die verschiedenen Arten von Beziehungen zwischen im Modell erstellten Diensten zu definieren. Beispielsweise kann ein Satz von Abhängigkeitsregeln für übergeordnete Beziehungstypen gelten. Ein anderer Satz von Abhängigkeitsregeln kann für untergeordnete Beziehungen, Geschwisterbeziehungen oder andere darin definierte Beziehungen gelten. Beispiele für Beziehungen können zwei oder mehr Dienste umfassen, die als Geschwister in Beziehung stehen, wobei die Dienste möglicherweise gleichzeitig arbeiten und nicht aufeinander angewiesen sind. Andere Arten von Beziehungen können Parent-Child-Beziehungen umfassen, wobei der Child-Dienst auf dem Parent-Dienst beruhen kann. In einer solchen Parent-Child-Beziehung wird der Child-Service möglicherweise erst ausgeführt, wenn der Parent-Service abgeschlossen ist. Die Anwendung von Abhängigkeitsregeln durch den Planer 115 führt zu schrittweisen Abhängigkeiten zwischen verschiedenen Schritten, die Zustandsübergänge in einer Reihe von Diensten darstellen. Um die Inter-Step-Abhängigkeiten für die Zustandsübergänge zu erzeugen, können Abhängigkeitsregeln einen Satz von Prinzipien enthalten, die die Zustandsübergänge für die verschiedenen Arten von Beziehungen innerhalb des Systems 100 definieren.
Ein Orchestrierungsplan wird von dem Planer 115 bei der Erzeugung der Inter-Step-Abhängigkeiten erzeugt. Der Orchestrierungsplan definiert eine Reihenfolge, für die Schritte ausgeführt werden. Aufgrund der Erstellung der Inter-Step-Abhängigkeiten können im Orchestrierungsplan nicht abhängige Schritte identifiziert werden, so dass die Ausführung bestimmter Schritte parallel erfolgen kann, wodurch bestimmte nicht abhängige Schritte gleichzeitig ausgeführt werden können.
Das System 100 kann ferner einen Ausführer 120 enthalten, der den ausgearbeiteten Orchestrierungsplan ausführt. Der Ausführende 120 kann überarbeitete Orchestrierungspläne vom Planer 115 empfangen, wenn die Pläne basierend auf automatisch erzeugten Modifikationen oder Benutzereingaben überarbeitet werden. Der Executor 120 kann ein physikalisches Gerät wie eine elektronische Schaltung sein, die eine integrierte Schaltung, eine programmierbare Schaltung, eine integrierte Anwendungsschaltung, eine Steuerung, einen Prozessor, einen Halbleiter, eine Verarbeitungsressource, einen Chipsatz oder andere Arten von Komponenten umfasst, die das System 100 verwalten können. Alternativ kann der Ausführer 120 Anweisungen enthalten, die z . B. auf einem maschinenlesbaren Medium gespeichert sind und die, wenn sie vom Prozessor 105 ausgeführt werden, den Orchestrierungsplan ausführen.
Das System 100 kann auch einen Scheduler 125 enthalten. Der Scheduler 125 kann den Fortschritt des Orchestrierungsplans basierend auf dem Start der Ausführung eines Schritts und dem Abschluss des Schritts verfolgen. Der Scheduler kann dann angeben, welche Schritte keine Abhängigkeiten aufweisen, die ihre Ausführung verhindern, und an welchem Punkt der Executor 120 alle nicht abhängigen Schritte starten kann. Um nicht abhängige Schritte zu verfolgen, kann der Scheduler jedem Schritt einen Abhängigkeitszähler zuweisen. Wenn ein Schritt von einem anderen Schritt abhängt, kann er eine Anzahl von eins haben. Wenn es von zwei weiteren Schritten abhängt, kann es eine Anzahl von zwei und damit eine geben. Wenn ein Schritt einen Abhängigkeitszähler von Null hat, gibt es keine Schritte, die die Ausführung des Schritts verhindern. Dementsprechend kann der Ausführende 120 Anweisungen bereitstellen, um den Schritt zu beginnen. Wenn ein Dienst abgeschlossen ist, wird die Anzahl der Abhängigkeiten aller abhängigen Schritte um eins verringert. Als solches aktualisiert der Scheduler 125 den Plan im Wesentlichen kontinuierlich, wodurch alle nicht abhängigen Schritte ausgeführt werden können, wenn die Dienste keine Abhängigkeiten mehr aufweisen. Es können auch andere Verfahren zum Verfolgen der Schrittabhängigkeit angewendet werden. Beispielsweise kann ein Abhängigkeitszähler verwendet werden, der unter Verwendung von zunehmenden Werten, abnehmenden Werten oder Erreichen eines bestimmten Werts zählt.
Bestimmte Parameter können dem Orchestrierungsplan und / oder Scheduler 125 hinzugefügt werden, um zu verhindern, dass Schritte ausgeführt werden. Beispielsweise kann ein Maximallastparameter festgelegt werden, wobei ein Benutzer oder ein anderes System die maximale Anzahl von Schritten definiert, die gleichzeitig ausgeführt werden dürfen. Beispielsweise kann ein Benutzer angeben, dass bis zu zweihundertfünfzig (250) Schritte gleichzeitig ausgeführt werden können. Dieser Parameter kann hinzugefügt werden, um zu verhindern, dass zu viele Schritte gleichzeitig ausgeführt werden, was die Leistung von System 100 verringern könnte. Der Parameter max load kann auf einen konfigurierten Standardwert, ein Maximum pro Anforderung und / oder ein Maximum pro Dienst festgelegt werden, wie in der Modellierungssprache definiert. Wenn ein Schritt davon abhängig ist, dass das Maximum kleiner als die aktuelle Anzahl von gleichzeitig ausgeführten Schritten zum Zeitpunkt der Anforderung ist, wartet das System 100, bis die korrekte Anzahl von Schritten abgeschlossen ist, bevor der nachfolgende Schritt ausgeführt wird. Der maximale Lastparameter kann basierend auf Software- und Hardwareeinschränkungen eines bestimmten Systems 100 sowie gewünschten Leistungsgeschwindigkeiten variieren.
Der Scheduler 125 kann auch Informationen des Systems 100 in Bezug auf fehlgeschlagene Schritte bereitstellen. Wenn ein Schritt fehlschlägt, kann der Scheduler 125 anzeigen, dass der Schritt nicht abgeschlossen wurde, wodurch Modifikationen des Plans ermöglicht werden, um den fehlgeschlagenen Schritt zu berücksichtigen. In bestimmten Implementierungen können Abhängigkeiten für alle Schritte angepasst werden, die vom fehlgeschlagenen Schritt abhängen. Zum Beispiel können die abhängigen Schritte angewiesen werden, die Ausführung zu beginnen, den Schritt abzubrechen oder auf andere Weise solche abhängigen Schritte anzupassen.
In ähnlicher Weise kann das System 100 aufhören, Schritte zu senden, die von einem anderen Schritt abhängen, der von der Revision des Orchestrierungsplans abhängt. Der Orchestrierungsplan kann anschließend neu berechnet werden, wenn keine weiteren Schritte auszuführen sind. Als solches kann das System 100 weiter arbeiten, ohne dass ein überarbeiteter Orchestrierungsplan basierend auf einem abhängigen Schritt erforderlich ist.
In 2 ist ein Zustandsmodell gemäß einer oder mehreren Ausführungsformen gezeigt. Das Zustandsmodell 205 veranschaulicht mögliche Zustandsübergänge 210a - 210e für einen gegebenen Dienst. Das Zustandsmodell 205 ist als MTOSI dargestellt, das den Anfangszustandsübergang 210a und die möglichen Zustandsübergänge 210b - 210f enthält. Dieses Modell kann von Dienstanbietern als Mechanismus zum Verwalten komplexer Netzwerke und entsprechender Dienste verwendet werden, wie zum Beispiel des Dienstes 200 von 3. In anderen Implementierungen kann das Zustandsmodell 205 konzeptionelle Modelle oder andere visuelle Darstellungen enthalten, die verschiedene Zustände eines gegebenen Dienstes darstellen. Das Zustandsmodell 205 kann ferner eine visuelle Darstellung der Wechselbeziehung des Satzes von Diensten bereitstellen, indem mögliche Zustandsübergänge 210a - 210f wiedergegeben werden.
In dieser Implementierung erzeugt die Anwendung der Abhängigkeitsregeln dienstübergreifende Abhängigkeiten 212a - 212d. Dienstübergreifende Abhängigkeiten 212a - 212d sind Abhängigkeiten, die zwischen Zustandsübergängen zwischen den Diensten bestehen, die in diesem Beispiel der gegebene Dienst (dargestellt durch das Zustandsmodell 205) und verwandte untergeordnete Dienste 214 sind. In diesem Beispiel erzeugt der gegebene Dienstübergang von Zustand „geprüft“ 210a zu „entworfen“ 210b eine dienstübergreifende Abhängigkeit 212a, die von einem Zustandsübergang (nicht dargestellt) in untergeordneten Diensten 214 abhängt. In einem anderen Beispiel hat der gegebene Zustandsübergang von „entworfen“ 210b in „reserviert“ 210 die Abhängigkeit 212b zu einem anderen Zustandsübergang (nicht dargestellt) in den untergeordneten Diensten 214. In einem weiteren Beispiel weist der Zustandsübergang von „reserviert“ 210c zu „bereitgestellt“ 210d eine dienstübergreifende Abhängigkeit 212c zu einem anderen Zustandsübergang auf, der den untergeordneten Diensten 214 entspricht. In einem weiteren Beispiel weist der Zustandsübergang für den gegebenen Dienst von „bereitgestellt“ 210d in „aktiv“ 210e eine dienstübergreifende Abhängigkeit 212d zu einem anderen Zustandsübergang auf, der den untergeordneten Diensten 214 entspricht. Dementsprechend erzeugt die Anwendung der Abhängigkeitsregeln die dienstübergreifenden Abhängigkeiten 212a - 212d zwischen mehreren Diensten, die in Beziehung stehen. Während Eltern-Kind-Abhängigkeiten hierin diskutiert werden, können dienstübergreifende Abhängigkeiten 212a - 212d für alle Dienste in einem System erzeugt werden. Solche Zustandsmodelle 205 können somit für jede Abhängigkeitsbeziehung innerhalb eines Systems erzeugt werden. Spezifische Beispiele für die Arten von Abhängigkeitsregeln, die angewendet werden können, werden nachstehend ausführlich erläutert.
In 3 ist eine Darstellung von Dienstbeziehungen gemäß einer oder mehreren Ausführungsformen gezeigt. Die verschiedenen Arten von Beziehungen zwischen Diensten 200 können zum Beispiel Eltern, Geschwister, Überweiser, Referenzen, Voraussetzungen und dergleichen umfassen. Die Pfeile repräsentieren die Beziehung eines gegebenen Dienstes 200 zu anderen Diensten. Zum Beispiel gibt es einen übergeordneten Dienst 215 für den gegebenen Dienst 200. Es gibt auch einen Geschwisterdienst 220 zu einem Dienst 200, wobei der Geschwisterdienst 210 auch eine Beziehung als ein Kind zu einem Elterndienst 215 hat. Durch das Definieren der Beziehungen zwischen den Diensten kann die Reihenfolge, in der bestimmte Dienste ausgeführt werden können, grafisch dargestellt werden. In diesem Beispiel muss der Dienst 200 möglicherweise warten, bis der übergeordnete Dienst 215 abgeschlossen ist, bevor er beginnen kann. Der Geschwisterdienst 220 muss möglicherweise auch warten, bis der übergeordnete Dienst 215 abgeschlossen ist, bevor er beginnt. Der Geschwisterdienst 220 kann jedoch gleichzeitig mit dem Dienst 200 ausgeführt werden. Zusätzliche Dienste können Verweise 225 auf einen gegebenen Dienst 200 sowie einen Referenzdienst 230 und eine beliebige Anzahl von vorausgesetzten Diensten 235 auf einen gegebenen Dienst 200 umfassen. Das in 2 entwickelte Zustandsmodell kann auch verschiedene Arten von Beziehungen zwischen einem gegebenen Dienst 200 und anderen Diensten enthalten. Abhängig von der Art der Beziehung kann eine Reihe von Abhängigkeitsregeln auf die verschiedenen Arten von Beziehungen angewendet werden, um dienstübergreifende Abhängigkeiten zu erstellen, die in dargestellt sind.
In 4 ist eine Darstellung einer Systemarchitektur zum Entwickeln eines Orchestrierungsplans gemäß einer oder mehreren Ausführungsformen gezeigt. 4 zeigt, wie ein Dienst 205 über verschiedene Arten von Beziehungen zu anderen Dienstleistungen bezieht (z. B. Eltern, Geschwister, Kind, Referrer, Voraussetzung, Referenzen, etc.). Das Aufprallmodell 245 kann ein Modell entwickeln, das vom Planer 247 verwendet wird. Der Planer 247 wendet Abhängigkeitsregeln 250 an, die für die verschiedenen Arten von Beziehungen spezifisch sind. Durch Anwenden der Abhängigkeitsregeln 250 erzeugt der Planer 247 schrittweise Abhängigkeiten zwischen dem gegebenen Dienst 205 und anderen Diensten, wie durch 240 dargestellt.
Wenn die Inter-Step-Abhängigkeiten erstellt werden, erstellt der Planer 247 einen Step-Graphen (nicht dargestellt). Beispiele für Schrittgraphen werden in späteren Figuren diskutiert. Unter Verwendung des Schrittgraphen kann der Planer einen topologischen Sortieralgorithmus 255 anwenden, um eine Liste von Zustandsübergängen zur Ausführung durch den Ausführenden 260 zu erhalten. Die Liste der Zustandsübergänge wird durch einen Orchestrierungsplan (nicht dargestellt) erstellt. In einer beispielhaften Implementierung enthält der Orchestrierungsplan die sequenzierte Reihenfolge der Statusübergänge für die Ausführung. Implementationen von Komponenten Wirkungsmodell 245, Planer 247 und Vollstrecker 260 kann umfassen elektronischen Schaltungsanordnung (dh., Hardware) wie zum Beispiel eine integrierte Schaltung, eine programmierbare Schaltung, die Anwendung integrierten Schaltung (ASIC), Controller, Prozessor, Halbleiter, Verarbeitungsressource, Chipsatz oder andere Arten von Hardwarekomponenten, die das Modell 240 aufbauen und die Liste der auszuführenden Zustandsübergänge entwickeln können. Alternativ Wirkungsmodell 245, Planer 247 und Vollstrecker 260 kann Anweisungen umfassen (z. B. auf einem maschinenlesbaren Medium gespeichert sind) , die, wenn sie durch eine Hardwarekomponente ausgeführt (z. B., Controller und / oder der Prozessor) baut ein Modell auf und entwickelt die Reihenfolge der Zustandsübergänge entsprechend.
In 5 sind ein Schrittdiagramm und ein Scheduler gemäß einer oder mehreren Ausführungsformen gezeigt. Der Schrittgraph 265 enthält eine Anzahl von einzelnen Schritten 270, die eine oder mehrere Abhängigkeiten in Bezug auf ihre jeweiligen Positionen aufweisen. In diesem Beispiel weist Schritt 1 (270a) zwei Abhängigkeiten auf, die als Schritte 2 (270b) und 3 (270c) dargestellt sind. Schritt 2 (270b) weist zwei Abhängigkeiten auf, die als Schritte 4 (270d) und 5 (270e) dargestellt sind. Schritt 3 hat eine Abhängigkeit, Schritt 6 (270f) und in ähnlicher Weise hat Schritt 6 (270d) eine Abhängigkeit, Schritt 7 (270g). Die Schritte 4 (270d) und 5 (270e) haben eine Abhängigkeit, Schritt 7 (270g). Schritt 7 (270g) hängt von Schritt 4 (270d), Schritt 5 (270e) und Schritt 6 (270f) ab.
Während des Betriebs verfolgt ein Scheduler 275 eine Abhängigkeitszählung für jeden Schritt. Wenn die Abhängigkeitszählung für einen bestimmten Schritt 0 erreicht, kann der Schritt fortgesetzt werden. In diesem Beispiel hat Schritt 1 (270a) einen Abhängigkeitszähler von 0, da er von keinen anderen Schritten abhängt. Die Schritte 2-6 (270b-270f) haben eine Abhängigkeitszählung von 1, da jeder Schritt nur von einem Schritt 270 vorher abhängt. Schritt 7 (270g) hat einen Abhängigkeitszähler von 3, da er von drei vorherigen Schritten 270d-270f abhängt. Nachdem Schritt 1 (270a) abgeschlossen ist, verringert der Zeitplan die Abhängigkeitszählung für alle direkt abhängigen Schritte 270 um den Wert 1. Somit hat, nachdem Schritt 1 (270a) abgeschlossen ist, die Abhängigkeitszählung der Schritte 2 (270b) und 3 (270c) eine neue Abhängigkeitszählung von 0. Da die Abhängigkeitszahl der Schritte 2 (270b) und 3 (270c) jetzt 0 ist, können die Schritte gleichzeitig ausgeführt werden. Bei den Schritten 4 bis 7 (270d bis 270g) wird die Anzahl der Abhängigkeiten jedoch nicht verringert, da die vorherigen Schritte noch nicht abgeschlossen wurden.
Nach dem Abschluss von Schritt 2 (270b) kann Schritt 3 (270c) noch verarbeitet werden. In früheren Lösungen müssten alle Schritte, die von Schritt 2 (270b) abhängen, auf den Abschluss von Schritt 3 (270c) warten, bevor sie ausgeführt werden. Wenn jedoch Schritt 2 (270b) abgeschlossen ist, verringert der Scheduler die Abhängigkeitszählung von Schritt 4 (270d) und Schritt 5 (270e) um 1, wodurch ihre Abhängigkeitszählung auf 0 gebracht wird und sie gleichzeitig mit Schritt 3 ausgeführt werden können (270c). Nach Abschluss von Schritt 3 (270c) kann Schritt 6 (270f) beginnen. Wenn Schritt 4 (270d), Schritt 5 (270e) und Schritt 6 (270f) abgeschlossen sind, wird der Scheduler 275 ihren Abschluss verfolgen. Schritt 7 (270g) kann erst ausgeführt werden, wenn alle Schritte 4-5 (270d-270f) abgeschlossen sind. Zum Beispiel kann Schritt 4 (270d) zuerst abgeschlossen werden, zu welchem Zeitpunkt der Scheduler 275 die Abhängigkeitszählung von Schritt 7 (270g) um 1 reduzieren wird, wodurch seine Abhängigkeitszählung auf 2 gebracht wird. Wenn die Abhängigkeitszählung von Schritt 7 (270 g) 0 erreicht, kann die Ausführung von Schritt 7 (270 g) beginnen. Nach Abschluss von Schritt 7 (270 g) kann der Scheduler den Prozess von vorne beginnen oder auf andere Weise zusätzliche Anweisungen befolgen, die im Orchestrierungsplan enthalten sind.
Vor der Fertigstellung des Orchestrierungsplans kann der Schrittgraph 265 topologisch sortiert werden, um zu bestimmen, ob Zirkularitäten vorhanden sind, die dazu führen können, dass die Schritte 270 in eine Endlosschleife eintreten. Wenn beispielsweise Schritt 1 (270a) von Schritt 3 (270c) und Schritt 3 (270c) von Schritt 1 (270a) abhängig wäre, würde eine Endlosschleife erzeugt, wodurch verhindert würde, dass die Operation fortgesetzt wird. Der Schrittgraph 265 kann vom Planer unter Verwendung eines linearen Zeitalgorithmus sortiert werden. In einer Implementierung kann der vom Planer ausführbare Linearzeitalgorithmus den Tarjan-Algorithmus enthalten.
Die oben diskutierten Verfahren zum Verfolgen der Abhängigkeit zwischen spezifischen Schritten 270 stellen ein Verfahren zum Verfolgen der Abhängigkeit von Schritt 270 dar. In anderen Implementierungen kann das Verfolgen der Abhängigkeit das Erhöhen der Abhängigkeitszahl, das Erhöhen der Abhängigkeitszahl oder das Ausführen eines Schritts 270 umfassen, wenn ein bestimmter zugewiesener oder abgeleiteter Wert erreicht wird. Dementsprechend bezieht sich die Abhängigkeit des Verfolgungsschritts 270 auf die Fähigkeit zu bestimmen, ob ein bestimmter Schritt 270 von einem anderen bestimmten Schritt 270 abhängt, der die Ausführung des Subjektschritts 270 verhindern würde.
6 zeigt ein Flussdiagramm eines Verfahrens zum gleichzeitigen Ausführen von Schritten gemäß einer oder mehreren Ausführungsformen. In diesem Beispiel wird eine Darstellung eines Satzes von Diensten entwickelt (600), wobei sich jeder Dienst über verschiedene Arten von Beziehungen auf andere Dienste bezieht. Die spezifischen Beziehungen, wie die oben diskutierten, können Eltern, Kind, Beziehung, Überweisung, Voraussetzung und dergleichen umfassen. Abhängig von der Art der Dienste können die Diagramme der Beziehungen gerichtete azyklische Diagramme („DAGs“) mit Knoten und Bögen sowie gerichtete DAGs mit Wäldern übergreifender Bäume mit Querverweisen zwischen diesen enthalten. In anderen Implementierungen können die Graphen zyklisch gerichtete Graphen sein, die Knoten und Bögen mit einer oder mehreren Verbindungen enthalten, sowie zyklisch gerichtete Graphen, die Wälder von übergreifenden Bäumen enthalten, die Querverweise zwischen den Knoten enthalten. Verschiedene Arten von gerichteten Graphen können gemäß den hier diskutierten Implementierungen verwendet werden.
Während der Entwicklung (600) einer Darstellung wird jeder Dienst durch verschiedene Arten von Beziehungen als mit anderen Diensten verwandt modelliert. In einer Implementierung kann das Computergerät ein MTOSI-Modell als Eingabe erstellen. Durch die Erstellung eines Modells stellt das Computergerät die Art der Beziehungen dar, die zwischen den einzelnen Diensten bestehen.
Das Verfahren umfasst ferner das Anwenden (605) eines Satzes von Abhängigkeitsregeln für jeden Beziehungstyp innerhalb des Satzes von Diensten, so dass das Anwenden der Abhängigkeitsregeln schrittweise Abhängigkeiten zwischen Schritten erzeugt, die Zustandsübergänge des Satzes von Diensten darstellen. Wie oben erläutert, kann jeder Dienst so definiert werden, dass er bestimmte Abhängigkeiten zwischen den Schritten enthält, wodurch die Ausführung eines bestimmten Schritts bis zum Abschluss eines oder mehrerer anderer Schritte verhindert wird. Die Abhängigkeitsregeln können die automatische Erzeugung und Änderung von nachfolgend diskutierten Graphen ermöglichen.
Der Satz von Abhängigkeitsregeln kann von der Art der Beziehung zwischen einem bestimmten Dienst und anderen Diensten abhängen. Beispiele für den Satz von Abhängigkeitsregeln können Statusübergänge anzeigen, die vor und nach einer bestimmten Abhängigkeitsregel ausgeführt werden sollen. Dies liefert einen Hinweis auf den Satz von Abhängigkeitsregeln, die die Abhängigkeit zwischen Schritten verursacht haben können, die Zustandsübergänge der Dienste darstellen. Ein Beispiel für die Abhängigkeitsregeln ist unten aufgeführt, es können jedoch auch andere Abhängigkeitsregeln implementiert werden. Dementsprechend kann es zusätzliche Abhängigkeitsregeln oder weniger Abhängigkeitsregeln als die unten aufgeführten geben. Beispiel: Der Satz von Abhängigkeitsregeln wird nach Beziehungstyp gruppiert. Für einen untergeordneten Beziehungstyp können die Abhängigkeitsregeln Folgendes enthalten:

CHILD_SETUP - Ein untergeordneter Dienst / eine untergeordnete Komponente wartet darauf, dass der übergeordnete Teil einen bestimmten MTOSI-Status erreicht, bevor der untergeordnete Teil auf denselben MTOSI-Status eingestellt wird.
CHILD_TEARDOWN - Übergeordnete Dienste warten darauf, in einen bestimmten MTOSI-Status versetzt zu werden, bis sich die untergeordneten Komponenten / Dienste zuerst in diesem Status befinden.
RESOURCE_TEARDOWN - Das untergeordnete Ressourcenelement wartet darauf, dass das übergeordnete Element BEENDET wird, bevor es abgerissen wird.

In einem anderen Beispiel können die Abhängigkeitsregeln für die übergeordnete Beziehung Folgendes enthalten:

PARENT_COMPLETE - Das Elternteil wartet darauf, dass seine Kinder vollständig sind, bevor das Elternteil selbst als vollständig markiert wird. Beachten Sie, dass die Bedeutung von „vollständig“ vom gewünschten Status des Dienstes abhängt.
PARENT_LOCK_STEP - Wenn die Option lockstep : true im Deskriptor definiert ist, wartet der übergeordnete Setup-Fortschritt darauf, dass der untergeordnete Zustand gemäß dem MTOSI-Zustandsmodell schrittweise fortgesetzt wird, sodass der übergeordnete Zustand nicht mehr als einen Zustand vor dem ist untergeordneter Staat.
PARENT_LOCK_STEP_TEARDOWN - Wenn die Option lockstep : true im Deskriptor definiert ist, wartet die übergeordnete Teardown-Progression darauf, dass der untergeordnete Zustand gemäß dem MTOSI-Zustandsmodell synchronisiert wird, sodass der übergeordnete Zustand nicht mehr als einen Zustand höher als der ist untergeordneter Staat.
RESOURCE_SETUP - Ein übergeordneter Dienst wartet darauf, dass die Ressourcen AKTIV sind, bevor der übergeordnete Dienst DESIGNED wird

In einem weiteren Beispiel für die Referenzbeziehung können die Abhängigkeitsregeln Folgendes enthalten:

REFERENCE_SETUP - Der Dienst sollte warten, bis seine Referenz den gewünschten Status (normalerweise ACTIVE) erreicht hat, bevor er in den Status RESERVED übergeht.
REFERENCE_TEARDOWN - Der referenzierte Service wird nicht automatisch abgebaut, bis seine letzten Referrer abgebaut wurden. Wenn der letzte Verweiser seinen Verweisparameter in einen anderen Dienst ändert, kann es auch eine Schattenversion geben, die den alten Verweis noch beibehält. Das Herunterfahren des referenzierten Dienstes wartet also, bis die Schattenversion entfernt wird.
SOFTREF_SETUP (p1, p2, ..., pn)- Wenn ein vorausgesetzter Parameter (mit Ausnahme von reference und auxreference) auf einen Dienst verweist, bleibt der Status des Verweisenden beim Setup hinter dem Status des referenzierten Dienstes zurück. Beachten Sie, dass sich dies von REFERENCE_SETUP unterscheidet, da der referenzierte Dienst nicht gezwungen wird, vor dem Referrer AKTIV zu werden. Der Referrer befindet sich möglicherweise in einem niedrigeren MTOSI-Status. Die Abhängigkeit listet die Namen der Parameter auf, die die Abhängigkeit erstellt haben. Daher sind diese Parameter wahrscheinlich Kandidaten für eine Voraussetzung: falsche Annotation.
SOFTREF_TEARDOWN ( p1 , p2,..., pn ) - Entspricht SOFTREF_SETUP, verhindert jedoch das Herunterfahren des referenzierten Dienstes.
REFERENCE_LOCKSTEP - Wie SOFTREF_SETUP, aber den Status des referenzierten Dienstes zurückhalten, um höchstens einen MTOSI-Status vor dem referenzierenden Dienst zu behalten. Ähnlich wie REFERENCE_TEARDOWN, aber den Status des referenzierten Dienstes zurückhalten, um höchstens einen MTOSI-Status größer als den Status des referenzierenden Dienstes zu halten.
RESREF_SETUP (p1 , p2,..., pn) - Dies funktioniert wie Softreferenzen, aber diese Regel wird anstelle von SOFTREF_SETUP generiert, wenn ein Parameter mit der Voraussetzung: resource angegeben wird. Mit dieser Regel werden die Dienste, auf die durch die aufgelisteten Parameter verwiesen wird, in ihren gewünschten Zustand versetzt, noch bevor der aktuelle Dienst ENTWURFEN wird. Es ist also wie REFERENCE_SETUP, funktioniert jedoch für alle Parameter und ist noch restriktiver. In Release 2.2.1 funktioniert die Voraussetzung: Ressourcenanmerkung für Parameter reference und auxreference nicht.
RESREF_TEARDOWN ( p1 , p2,..., pn ) - Entspricht RESREF_SETUP, verhindert jedoch das vorzeitige Herunterfahren des referenzierten Dienstes.
TRANSITION_ORDER - Die Sequenz von Zustandsübergängen, die vom MTOSI-Zustandsmodell definiert werden.

Das Verfahren umfasst auch das Entwickeln (610) eines Orchestrierungsplans auf der Grundlage der Erzeugung der Inter-Step-Abhängigkeiten, die die gleichzeitige Ausführung von nicht abhängigen Schritten ermöglichen. Wie in Bezug auf 5 erläutert, kann der Orchestrierungsplan auf einem erzeugten Schrittdiagramm basieren, das mehrere Schritte umfasst. Jeder Schritt in dem Schrittgraphen kann einen Prozess darstellen und kann als einer oder mehrere der oben diskutierten Typen gerichteter Graphen dargestellt werden oder auf diesen basieren. Während des Betriebs kann ein Scheduler eine Abhängigkeit zwischen bestimmten Schritten auf dem Schrittgraphen verfolgen. In bestimmten Implementierungen kann der Scheduler die Abhängigkeit unter Verwendung eines Abhängigkeitszählers verfolgen. Der Scheduler kann anschließend die Abhängigkeitszahl eines Schritts verringern, wenn alle Schritte, von denen er abhängt, abgeschlossen sind. Somit kann in bestimmten Implementierungen ein Schritt von mehr als einem vorherigen Schritt abhängen. Der Schritt kann auf jeden Schritt warten, von dem es abhängt, dass er ausgeführt wird. Indem Sie die Beziehung zwischen den einzelnen Schritten erstellen und grafisch darstellen, können Schritte, die nicht voneinander abhängig sind, gleichzeitig ausgeführt werden. Dementsprechend umfasst das Verfahren ferner das gleichzeitige Ausführen von mindestens zwei nicht abhängigen Schritten. Die nicht abhängigen Schritte können ausgeführt werden, wenn der spezifische Schritt eine Abhängigkeitszählung von Null aufweist. Als solches können mehrere Schritte gleichzeitig ausgeführt werden, abhängig von den spezifischen Schritten mit einer Abhängigkeitszählung von Null. Andere Verfahren zum Zählen von Schritten, wie die oben diskutierten, können ebenfalls verwendet werden, um zu bestimmen, welche Schritte gleichzeitig ausgeführt werden können.
Während hierin eine Diskussion über einen Prozess mit sieben (7) Schritten in Bezug auf 5 enthalten ist, können im Betrieb Hunderte oder sogar Tausende von Schritten in einem Prozess vorhanden sein. In ähnlicher Weise kann in der Praxis jeder Schritt von einer Vielzahl von Schritten abhängen, die drei überschreiten, obwohl eine bis drei Abhängigkeiten hierin ausdrücklich offenbart sind.
Das Verfahren kann ferner verschiedene andere Implementierungen enthalten, um die Ausführungsgeschwindigkeiten weiter zu verbessern. Beispielsweise kann in einer Implementierung ein Stufendiagramm abgelehnt werden, wenn das Stufendiagramm eine Zirkularität enthält, die eine Endlosschleife verursachen würde. Wenn zum Beispiel zwei Schritte voneinander abhängig wären, würde der Prozess nicht voranschreiten, da es niemals eine Vollendung geben würde, was zu einer Endlosschleife führen würde. Um eine solche Schleife zu verhindern, kann der Planer bei der Entwicklung des Orchestrierungsplans eine Sortierfunktion bereitstellen, die die Topologie des Schrittgraphen sortiert. In bestimmten Implementierungen kann die topologische Sortierung unter Verwendung des Tarjan-Algorithmus durchgeführt werden.
Drehen auf 7 ein Beispiel mit einem Hardware - Prozessor und zugänglich maschinenlesbaren Anweisungen die Computervorrichtung wird in Übereinstimmung mit einer oder mehreren beispielhaften Ausführungsformen gezeigt. provides 7 stellt eine beispielhafte Rechenvorrichtung 625 mit einem Hardwareprozessor 630 und zugänglichen maschinenlesbaren Anweisungen bereit, die auf einem maschinenlesbaren Medium 635 gespeichert sind, um die Ausführung eines Orchestrierungsplans mit einer Vielzahl von nicht abhängigen Schritten durchzuführen, die oben in Bezug auf erläutert wurden eine oder mehrere offenbarte beispielhafte Implementierungen. 7 zeigt eine Rechenvorrichtung 625, die so konfiguriert ist, dass sie den in den Blöcken 600, 605 und 615 beschriebenen Ablauf sowie den in den Blöcken 600, 605 und 610 beschriebenen Ablauf ausführlich in Bezug auf 6 erläutert. Die Computervorrichtung 625 kann jedoch auch konfiguriert sein, um den Fluss anderer in dieser Offenbarung beschriebener Verfahren, Techniken, Funktionen oder Prozesse durchzuführen.
In dieser Implementierung umfasst die Entwicklung des Orchestrierungsplans basierend auf der Erstellung von Abhängigkeiten zwischen den Schritten, dass ein erster Schritt ausgeführt werden kann, wenn er nicht von einem zweiten Schritt abhängt. Wenn der zweite Schritt beispielsweise vom ersten Schritt abhängt, besteht für den zweiten Schritt eine Abhängigkeit zwischen den Schritten, die dessen Ausführung verhindert, bis der erste Schritt abgeschlossen ist. Eine beispielhafte Abhängigkeit zwischen Schritten kann eine Eltern-Kind-Beziehung enthalten. In einem anderen Beispiel kann der zweite Schritt von einem Schritt zwischen dem ersten Schritt und dem zweiten Schritt abhängen. In einem solchen Beispiel kann der zweite Schritt eine Eltern-Enkel-Beziehung haben und der Kind-Schritt kann zusätzlich zum Eltern-Schritt eine Abhängigkeit erzeugen. In bestimmten Implementierungen können der erste Schritt und der zweite Schritt gleichzeitig ausgeführt werden, vorausgesetzt, keiner der Schritte hängt voneinander ab und keiner der Schritte hängt von einem dritten Schritt ab, der sich entweder auf den ersten Schritt oder den zweiten Schritt bezieht.
Ein maschinenlesbares Speichermedium, wie z. B. 635 von 7, kann sowohl flüchtige als auch nicht flüchtige, entfernbare und nicht entfernbare Medien enthalten und kann ein beliebiges elektronisches, magnetisches, optisches oder anderes physikalisches Speichermedium sein, das ausführbare Anweisungen enthält oder speichert Datenstrukturen, Programmmodule oder andere Daten, auf die ein Prozessor zugreifen kann, z. B. Firmware, löschbarer programmierbarer Nur-Lese-Speicher („EPROM“), Direktzugriffsspeicher („RAM“), nichtflüchtiger Direktzugriffsspeicher („NVRAM“) ), eine optische Disk, Festkörperlaufwerk („SSD“), Flash - Speicherchips, und dergleichen. Das maschinenlesbare Speichermedium kann ein nichtflüchtiges Speichermedium sein, wobei der Begriff „nichtflüchtig“ keine transitorischen Ausbreitungssignale umfasst.
Drehen auf 8 eine schematische Darstellung einer Computerverarbeitungseinrichtung 800 , die verwendet werden können , Funktionen und Prozesse in Übereinstimmung mit einer oder mehrerer beispielhaften Ausführungsform gezeigt ist, zu implementieren. 8 stellt eine Computerverarbeitungsvorrichtung 700 , die verwendet werden , können die Systeme, Methoden und Verfahren dieser Offenbarung zu implementieren. Beispielsweise könnte das in 8 dargestellte Computergerät 700 ein Clientgerät oder ein physisches Servergerät darstellen und je nach Abstraktionsgrad des Computergeräts entweder Hardware oder virtuelle Prozessoren umfassen. In einigen Fällen (ohne Abstraktion) beziehen sich das Computergerät 7 und seine Elemente, wie in 8 gezeigt, jeweils auf physikalische Hardware. Alternativ könnten in einigen Fällen ein, mehrere oder alle Elemente unter Verwendung von Emulatoren oder virtuellen Maschinen als Abstraktionsebenen implementiert werden. Unabhängig davon, wie viele Abstraktionsebenen von der physischen Hardware entfernt sind, kann die Computervorrichtung 700 auf ihrer niedrigsten Ebene auf physischer Hardware implementiert sein. In einer Implementierung kann die Computervorrichtung 700 einem Teilnehmer den Fernzugriff auf ein oder mehrere Datenzentren ermöglichen. In ähnlicher Weise kann das vom Teilnehmer verwendete Verwaltungswerkzeug eine Softwarelösung enthalten, die auf einem solchen Computergerät 700 ausgeführt wird
zeigt ein Computersystem 700 gemäß einem oder mehreren Ausführungsbeispielen. Das Rechensystem 700 kann umfassen eine oder mehrere zentrale Verarbeitungseinheiten (Singular „CPU“ oder im Plural „CPUs“) 705 , angeordnet auf einer oder mehreren Leiterplatten (ansonsten nicht gezeigt). Jede der einen oder mehreren CPUs 705 kann ein Einkernprozessor (nicht unabhängig dargestellt) oder ein Mehrkernprozessor (nicht unabhängig dargestellt) sein. Mehrkernprozessoren umfassen typischerweise mehrere Prozessorkerne (nicht gezeigt), die auf demselben physikalischen Chip (nicht gezeigt) angeordnet sind, oder mehrere Prozessorkerne (nicht gezeigt), die auf mehreren Chips (nicht gezeigt) angeordnet sind, die gemeinsam in demselben angeordnet sind mechanisches Gehäuse (nicht gezeigt). Das Computersystem 700 kann eine oder mehrere Kernlogikvorrichtungen enthalten, wie beispielsweise die Hostbrücke 710 und die Eingabe / Ausgabe-Brücke („IO“ -Brücke 715.
Die CPU 705 kann eine Schnittstelle 708 zur Hostbrücke 710, eine Schnittstelle 718 zum Systemspeicher 720 und eine Schnittstelle 723 zu einem oder mehreren E / A-Geräten, wie beispielsweise der Grafikverarbeitungseinheit („GFX“) 725, enthalten. GFX 725 kann einen oder mehrere Grafikprozessorkerne (nicht unabhängig gezeigt) und eine Schnittstelle 728 zur Anzeige 730 enthalten. In bestimmten Ausführungsformen kann die CPU 705 die Funktionalität von GFX 725 integrieren und eine direkte (nicht gezeigte) Schnittstelle mit der Anzeige 730 bilden. Die Host-Brücke 710 kann eine Schnittstelle 708 zur CPU 705, eine Schnittstelle 713 zur IO-Brücke 715 für Ausführungsformen enthalten, bei denen die CPU 705 keine Schnittstelle 718 zum Systemspeicher 720 enthält, eine Schnittstelle 716 zum Systemspeicher 720 und für Ausführungsformen, bei denen die CPU 705 dies tut Integriertes GFX 725 oder Schnittstelle 723 zu GFX 725, Schnittstelle 721 zu GFX 725 nicht enthalten. Ein Durchschnittsfachmann wird erkennen, dass die CPU 705 und die Hostbrücke 710 ganz oder teilweise integriert sein können, um die Anzahl der Chips, den Platzbedarf auf der Hauptplatine, die Leistung beim thermischen Design und den Stromverbrauch zu verringern. Die IO-Brücke 715 kann eine Schnittstelle 713 zur Host-Brücke 710, eine oder mehrere Schnittstellen 733 zu einem oder mehreren IO-Erweiterungsgeräten 735, eine Schnittstelle 738 zur Tastatur 740, eine Schnittstelle 743 zur Maus 745, eine Schnittstelle 748 zu einem oder mehreren lokalen Speichern enthalten Geräte 750 und eine Schnittstelle 753 zu einem oder mehreren Netzwerkschnittstellengeräten 755.
Jedes lokale Speichergerät 750 kann ein Festkörperspeichergerät, ein Festkörperspeichergerät-Array, ein Festplattenlaufwerk, ein Festplattenlaufwerk-Array oder ein beliebiges anderes nichtflüchtiges computerlesbares Medium sein. Jedes Netzwerkschnittstellengerät 755 kann eine oder mehrere Netzwerkschnittstellen bereitstellen, einschließlich beispielsweise Ethernet, Fibre Channel, WiMAX, Wi-Fi, Bluetooth oder jedes andere Netzwerkprotokoll, das zur Erleichterung der Netzwerkkommunikation geeignet ist. Das Computersystem 700 kann zusätzlich zu oder anstelle von einer oder mehreren lokalen Speichereinheiten 750 eine oder mehrere an das Netzwerk angeschlossene Speichereinheiten 760 enthalten. Die an das Netzwerk angeschlossene Speichervorrichtung 760 kann eine Festkörperspeichervorrichtung, ein Festkörperspeichervorrichtungsarray, ein Festplattenlaufwerk, ein Festplattenlaufwerksarray oder ein beliebiges anderes nichtflüchtiges computerlesbares Medium sein. Die an das Netzwerk angeschlossene Speichervorrichtung 760 kann mit dem Computersystem 00 zusammengestellt sein oder nicht und kann über eine oder mehrere Netzwerkschnittstellen, die von einer oder mehreren Netzwerkschnittstellenvorrichtungen 755 bereitgestellt werden, für das Computersystem 700 zugänglich sein.
Ein Durchschnittsfachmann wird erkennen, dass das Computersystem 700 eine oder mehrere anwendungsspezifische integrierte Schaltungen („ASICs“) enthalten kann, die konfiguriert sind, um eine bestimmte Funktion auszuführen, wie beispielsweise Hashing (nicht gezeigt) in a effizienter Weise. Der eine oder die mehreren ASICs können direkt mit einer Schnittstelle der CPU 705, der Hostbrücke 760, des Systemspeichers 720 oder der IO-Brücke 715 verbunden sein. Alternativ kann ein (nicht gezeigtes) anwendungsspezifisches Computersystem, das manchmal als Mining-Systeme bezeichnet wird, auf die Komponenten reduziert werden, die die gewünschte Funktion ausführen, z. Thermal Design Power und Stromverbrauch. Als solches wird ein Durchschnittsfachmann erkennen, dass die eine oder die mehreren CPUs 705, die Hostbrücke 710, die IO-Brücke 715 oder ASICs oder verschiedene Untersätze , Supersätze oder Kombinationen von Funktionen oder Merkmalen davon , können ganz oder teilweise integriert sein oder auf verschiedene Geräte in einer Weise verteilt sein, die auf der Grundlage einer Anwendung, eines Designs oder eines Formfaktors gemäß einer oder mehreren beispielhaften Ausführungsformen variieren kann. Als solches ist die Beschreibung des Computersystems 700 lediglich beispielhaft und soll nicht den Typ, die Art oder die Konfiguration von Komponenten einschränken, die ein Computersystem bilden, das zum Ausführen von Computeroperationen geeignet ist, einschließlich, aber nicht beschränkt auf Hashing-Funktionen. Zusätzlich wird ein Durchschnittsfachmann erkennen, dass das Computersystem 600, ein anwendungsspezifisches Computersystem (nicht gezeigt) oder eine Kombination davon in einem eigenständigen, Desktop-, Server- oder rackmontierbaren Formfaktor angeordnet sein kann.
Ein Fachmann auf dem Gebiet wird erkennen , dass 700 das Computersystem kann eine Cloud-basierte sein Server, ein Server, eine Workstation, ein Desktop, ein Laptop, ein Netbook, ein Tablet, ein Smartphone, ein Mobilgerät und / oder jede andere Art von Computersystem gemäß einer oder mehreren beispielhaften Ausführungsformen.
Es versteht sich, dass alle Kombinationen der vorstehenden Konzepte (vorausgesetzt, solche Konzepte sind nicht gegenseitig inkonsistent) als Teil des hierin offenbarten erfinderischen Gegenstands betrachtet werden. Insbesondere werden alle am Ende dieser Offenbarung erscheinenden Kombinationen von beanspruchten Gegenständen als Teil des hierin offenbarten erfinderischen Gegenstands betrachtet. Es versteht sich auch, dass die hierin ausdrücklich verwendete Terminologie, die auch in einer durch Bezugnahme aufgenommenen Offenbarung erscheinen kann, eine Bedeutung erhalten sollte, die mit den hierin offenbarten bestimmten Konzepten am konsistentesten ist.
Während die vorliegenden Lehren in Verbindung mit verschiedenen Beispielen beschrieben wurden, ist nicht beabsichtigt, dass die vorliegenden Lehren auf solche Beispiele beschränkt sind. Die oben beschriebenen Beispiele können auf eine von zahlreichen Arten implementiert werden.
Die hier beschriebene Technologie kann auch als ein Verfahren ausgeführt werden, von dem mindestens ein Beispiel bereitgestellt wurde. Die im Rahmen der Methode durchgeführten Handlungen können auf jede geeignete Weise angeordnet werden. Dementsprechend können Beispiele konstruiert werden, in denen Handlungen in einer anderen als der dargestellten Reihenfolge ausgeführt werden, was das gleichzeitige Ausführen einiger Handlungen umfassen kann, obwohl sie in veranschaulichenden Beispielen als aufeinanderfolgende Handlungen gezeigt sind.
Zu den Vorteilen einer oder mehrerer beispielhafter Ausführungsformen können eines oder mehrere der folgenden gehören:
In einem oder mehreren Beispielen können hier offenbarte Systeme und Verfahren verwendet werden, um die Verarbeitungsgeschwindigkeit zu erhöhen, indem nicht abhängige Schritte in einem Dienstsatz ausgeführt werden.
In einem oder mehreren Beispielen können hier offenbarte Systeme und Verfahren verwendet werden, um die Zeit zum Ausführen eines Plans zu verringern.
Nicht alle Ausführungsformen werden notwendigerweise alle diese Vorteile offenbaren. In dem Maße, in dem verschiedene Ausführungsformen einen oder mehrere dieser Vorteile aufweisen können, werden dies nicht alle in gleichem Maße tun.
Während der beanspruchte Gegenstand in Bezug auf die oben angegebenen Ausführungsformen beschrieben worden ist, wird der Fachmann mit dem Vorteil dieser Offenbarung erkennen, dass andere Ausführungsformen entwickelt werden können, die innerhalb des Schutzumfangs der Ansprüche liegen, wie durch die dargestellt hierin offenbarte beispielhafte Ausführungsformen.

Claims

Verfahren zum gleichzeitigen Ausführen einer Orchestrierung von Computerdiensten, wobei das Verfahren Folgendes umfasst: Entwickeln einer Darstellung eines Satzes von Diensten, wobei jeder Dienst sich über verschiedene Arten von Beziehungen auf andere Dienste bezieht; Anwenden eines Satzes von Abhängigkeitsregeln für jede Art von Beziehung innerhalb des Satzes von Diensten, so dass die Anwendung der Abhängigkeitsregeln schrittweise Abhängigkeiten zwischen Schritten erzeugt, die Zustandsübergänge des Satzes von Diensten darstellen; und Entwickeln des Orchestrierungsplans basierend auf den schrittweisen Abhängigkeiten, die die gleichzeitige Ausführung von nicht abhängigen Schritten ermöglichen.
Verfahren nach Anspruch 1, wobei der Satz von Diensten mindestens zwei nicht abhängige Dienste umfasst und das Verfahren ferner das gleichzeitige Ausführen von mindestens zwei nicht abhängigen Schritten umfasst.
Verfahren nach einem der Ansprüche 1 oder 2, wobei das Entwickeln des Orchestrierungsplans das Erzeugen eines Schrittgraphen der Dienste mit mehreren Schritten umfasst.
Verfahren nach Anspruch 3, ferner umfassend das Zurückweisen des Schrittgraphen, wenn der Schrittgraph eine Zirkularität enthält, die eine Endlosschleife verursachen würde.
Verfahren nach einem der Ansprüche 3 oder 4, ferner umfassend das Verfolgen einer Abhängigkeit zwischen den mehreren Schritten.
Verfahren nach Anspruch 5, ferner umfassend das Identifizieren der Schritte, die keine Abhängigkeiten aufweisen, und das Ausführen der Schritte, die keine Abhängigkeiten aufweisen.
Verfahren nach einem der Ansprüche 1 bis 6, wobei das Entwickeln des Orchestrierungsplans das topologische Sortieren eines Schrittgraphen unter Verwendung von Tarjans Algorithmus umfasst.
Verfahren nach einem der Ansprüche 1 bis 7, wobei das Anwenden eines Satzes von Abhängigkeitsregeln für jeden Beziehungstyp das Erzeugen von Schritten mit einer Eltern-Kind-Beziehung umfasst.
Verfahren nach einem der Ansprüche 1 bis 8, wobei das Anwenden eines Satzes von Abhängigkeitsregeln für jeden Beziehungstyp das Erzeugen von Schritten mit einer Geschwisterbeziehung umfasst.
Nichtflüchtiges computerlesbares Medium mit darauf gespeicherten computerausführbaren Anweisungen, die, wenn sie von einer oder mehreren Verarbeitungseinheiten ausgeführt werden, ein Verfahren zum gleichzeitigen Ausführen eines Orchestrierungsplans von Diensten ausführen, wobei das nichtflüchtige maschinenlesbare Speichermedium Anweisungen umfasst, um: Entwicklung einer Darstellung einer Reihe von Diensten, wobei jeder Dienst über verschiedene Arten von Beziehungen mit anderen Diensten in Beziehung steht; Anwenden eines Satzes von Abhängigkeitsregeln für jede Art von Beziehung innerhalb des Satzes von Diensten, so dass die Anwendung der Abhängigkeitsregeln schrittweise Abhängigkeiten zwischen Schritten erzeugt, die Zustandsübergänge des Satzes von Diensten darstellen; und Entwickeln Sie den Orchestrierungsplan basierend auf der Erstellung der Inter-Step-Abhängigkeiten, die die Ausführung eines Schritts ermöglichen, wenn dieser nicht von einem zweiten Schritt abhängt.
Verfahren nach Anspruch 10, ferner umfassend mindestens zwei Schritten ausgeführt wird, die gleichzeitig auf einander nicht abhängen.
Verfahren nach einem der Ansprüche 10 oder 11, wobei die Entwicklung der Orchestrierung Plan umfasst einen Schritt Graph Erzeugen einer Mehrzahl aufweist.
Verfahren nach Anspruch 12, ferner umfassend den Schritt Graph zurückgewiesen , wenn der Schritt Kurve , die eine Zirkularität enthält , die eine unendliche Schleife verursachen würde.
Verfahren nach einem der Ansprüche 12 oder 13, ferner umfassend eine Abhängigkeit zwischen der Vielzahl von Schritten zu verfolgen.
Verfahren nach Anspruch 14, ferner umfassend die Schritte zu identifizieren , die keine Abhängigkeiten aufweisen und die Schritte ausführen , die keine Abhängigkeiten aufweisen.
Ein System zur Entwicklung eines Orchestrierungs-Ausführungsplans, das Folgendes umfasst: ein Modellierer, der eine Darstellung jedes Dienstes in Bezug auf andere Dienste über verschiedene Arten von Beziehungen entwickelt; Ein Planer, der mit dem Modellierer und einem Prozessor verbunden ist, der eine Reihe von Abhängigkeitsregeln für jeden Beziehungstyp zwischen jedem Dienst und anderen Diensten anwendet und auf der Anwendung der Reihe von Abhängigkeitsregeln basiert, erstellt schrittweise Abhängigkeiten zwischen Schritten, die einen Zustandsübergang darstellen Entwickelt für jeden Dienst basierend auf den schrittweisen Abhängigkeiten den Orchestrierungsplan, der die gleichzeitige Ausführung von nicht abhängigen Schritten ermöglicht.
System nach Anspruch 16, die weiterhin einen Exekutor umfassend an den Planer verbunden , die gleichzeitig nondependent Schritte ausführt.
Das System nach einem der Ansprüche 16 oder 17, wobei der Hobel einen Schritt Graph erhält , wobei jeder Knoten in dem Graph Schritt den Schritt , die den Zustandsübergang für einen anderen Dienst darstellt und verwendet den Schritt Graph die Instrumentation Plan zu entwickeln.
Zirkularitäten um zu verhindern , wodurch eine Endlosschleife System nach Anspruch 18, wobei der Planer eine topologische Sortierung des Schritt Graph zur Verfügung stellt.
Das System nach einem der Ansprüche 18 oder 19, ferner umfassend einen Scheduler, der Spuren eine Abhängigkeit zwischen einer Vielzahl von Schritten.