-
VERWANDTE ANMELDUNG
-
Dieses Patent entstammt einer Anmeldung, die den Vorteil der vorläufigen
US-Patentanmeldung mit der Seriennr. 62/841,042 , angemeldet am 30. April 2019; der vorläufigen
US-Patentanmeldung mit der Seriennr. 62/907,597 , angemeldet am 28. September 2019; und der vorläufigen
US-Patentanmeldung mit der Seriennr. 62/939,303 , angemeldet am 22. November 2019 beansprucht. Die vorläufige
US-Patentanmeldung mit der Seriennr. 62/841,042 ; die vorläufige
US-Patentanmeldung mit der Seriennr. 62/907,597 ; und die vorläufige
US-Patentanmeldung mit der Seriennr. 62/939,303 sind hierdurch unter Bezugnahme in ihrer Gesamtheit eingebunden. Es wird hierdurch Priorität gegenüber der vorläufigen
US-Patentanmeldung mit der Seriennr. 62/841,042 ; der vorläufigen
US-Patentanmeldung mit der Seriennr. 62/907,597 ; und der vorläufigen
US-Patentanmeldung mit der Seriennr. 62/939,303 beansprucht.
-
GEBIET DER OFFENBARUNG
-
Diese Offenbarung betrifft allgemein Edge-Umgebungen und genauer Verfahren und Einrichtungen zum Steuern einer Verarbeitung von Telemetriedaten auf einer Edge-Plattform.
-
STAND DER TECHNIK
-
Edge-Umgebungen (z. B. ein Edge-, Fog-, Mehrzugriffs-Edge-Computing(MEC)- oder Internet-der-Dinge(IdD)-Netzwerk) ermöglichen eine Ausführung einer Arbeitslast (z. B. eine Ausführung von einer oder mehreren Rechenaufgaben, eine Ausführung eines maschinellen Lernmodells unter Verwendung von Eingabedaten usw.) nahe Endpunktvorrichtungen, die eine Ausführung der Arbeitslast anfordern. Edge-Umgebungen können Infrastruktur wie eine Edge-Plattform enthalten, die über Netzwerke wie dem Internet mit einer Cloud-Infrastruktur, Endpunktvorrichtungen und/oder zusätzlicher Edge-Infrastruktur verbunden ist. Edge-Plattformen können näher bei Endpunktvorrichtungen als eine Cloud-Infrastruktur, wie zum Beispiel zentralisierte Server, liegen.
-
Figurenliste
-
- 1 zeigt ein beispielhaftes Edge-Rechensystem zum Bereitstellen von Edge-Diensten und Anwendungen an Entitäten mit mehreren Akteuren, wie sie unter einer oder mehreren Client-Rechenplattformen, einer oder mehreren Edge-Gatewayplattformen, einer oder mehrerer Edge-Aggregationsplattformen, einem oder mehreren Kernrechenzentren und einer globalen Netzwerkcloud verteilt sind, wie sie über Schichten des Edge-Rechensystems verteilt sind.
- 2 zeigt ein Implementierungsbeispiel einer Edge-Plattform, um von Client-Rechenknoten empfangene Arbeitslasten zu verarbeiten, nach den Lehren dieser Offenbarung.
- 3 zeigt ein Implementierungsbeispiel des Orchestrators von 2, um eine Verarbeitung von Telemetriedaten auf einer Edge-Plattform auf Grundlage von Ressourcenverfügbarkeit zu steuern.
- 4 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator von 2 und 3 zu implementieren, um eine Verarbeitung von Telemetriedaten auf einer Edge-Plattform auf Grundlage von Ressourcenverfügbarkeit zu steuern.
- 5 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator von 2 und/oder 3 zu implementieren, um ausgelagerte Telemetriedaten zu verarbeiten.
- 6 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator von 2 und/oder 3 zu implementieren, um eine Orchestrierung auf einer Edge-Plattform zu skalieren.
- 7 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator von 2 und/oder 3 zu implementieren, um Telemetriedaten auszulagern, die auf einem anderen Computer zu verarbeiten sind, um grobe Orchestrierungsergebnisse zu erhalten.
- 8 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator von 2 und/oder 3 zu implementieren, um Telemetriedaten auszulagern, die auf einem anderen Computer zu verarbeiten sind, um feine Orchestrierungsergebnisse zu erhalten.
- 9 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator von 2 und/oder 3 zu implementieren, um eine Verarbeitung von Telemetriedaten auf einer Edge-Plattform auf Grundlage einer Temperatur an der Edge-Plattform zu steuern.
- 10 ist ein Blockdiagramm einer beispielhaften Verarbeitungsplattform, die strukturiert ist, die Anweisungen von 4, 5, 6, 7, 8 und/oder 9 auszuführen, um den Orchestrator von 2 und/oder 3 zu implementieren.
-
Die Figuren sind nicht maßstabgetreu. Im Allgemeinen werden in allen Zeichnungen und in der beigefügten schriftlichen Beschreibung dieselben Bezugszeichen verwendet, um auf dieselben oder ähnliche Teile Bezug zu nehmen. Bezugnahmen auf Verbindungen (z. B. befestigt, gekoppelt, verbunden und zusammengefügt) sind breit auszulegen und können Zwischenelemente zwischen einer Sammlung von Elementen und eine relative Bewegung zwischen Elementen enthalten, falls nicht anders angegeben. Als solche lassen Bezugnahmen auf Verbindungen nicht notwendigerweise den Schluss zu, dass zwei Elemente direkt miteinander verbunden sind und in einer festen Beziehung zueinander stehen.
-
Deskriptoren „erstes“, „zweites“, „drittes“ usw. werden hierin beim Identifizieren mehrerer Elemente oder Komponenten verwenden, auf die separat Bezug genommen werden kann. Falls nicht anders angegeben oder auf Grundlage ihres Verwendungskontexts verstanden wird, sollen derartige Deskriptoren keine Bedeutung von Priorität, physischer Reihenfolge oder Anordnung in einer Liste oder zeitlicher Reihenfolge unterstellen, sondern werden lediglich als Bezeichnungen verwendet, um auf mehrere Elemente oder Komponenten separat zu verweisen, um die offengelegten Beispiele leichter verständlich zu machen. In einigen Beispielen kann der Deskriptor „erstes“ verwendet werden, um auf ein Element in der ausführlichen Beschreibung zu verweisen, während auf dasselbe Element in einem Anspruch mit einem unterschiedlichen Deskriptor, wie „zweites“ oder „drittes“, verwiesen wird. In derartigen Fällen sollte klar sein, dass derartige Deskriptoren nur zur einfacheren Bezugnahme auf mehrere Elemente oder Komponenten verwendet werden.
-
AUSFÜHRLICHE BESCHREIBUNG
-
Edge-Computing bezeichnet auf allgemeiner Ebene den Übergang von Rechen- und Speicherressourcen näher an Endpunktvorrichtungen (z. B. Endverbraucher-Rechenvorrichtungen, Endgeräte usw.), um die Gesamtbetriebskosten zu optimieren, eine Anwendungslatenz zu reduzieren, Dienstfunktionalitäten zu verbessern und eine Einhaltung von Datenschutz- oder Sicherheitsanforderungen zu verbessern. Edge-Computing kann in einigen Szenarien einen cloudähnlichen verteilten Dienst bereitstellen, der Orchestrierung und Verwaltung von Anwendungen unter vielen Arten von Speicher- und Rechenressourcen bietet. Als Ergebnis wurden einige Implementierungen von Edge-Computing als die „Edge-Cloud“ oder der „Fog“ bezeichnet, wenn leistungsstarke Rechenressourcen, die vorher nur in großen entfernten Rechenzentren verfügbar waren, näher an Endpunkte bewegt werden und Endverbrauchern am „Rand“ des Netzwerks zur Verwendung zur Verfügung gestellt werden.
-
Anwendungsfälle von Edge-Computing in mobilen Netzwerkumgebungen wurden zur Integration mit Mehrfachzugriff-Edge-Computing(MEC)-Ansätzen entwickelt, die auch als „mobiles Edge-Computing“ bekannt sind. MEC-Ansätze sind entwickelt, um Anwendungsentwicklern und Inhaltsanbietern zu ermöglichen, auf Rechenfähigkeiten und eine Informatik(IT)-Dienstumgebung in dynamischen mobilen Netzwerkumgebungen am Rand des Netzwerks zuzugreifen. Von der Industrienormungsgruppe (ISG) Europäische Institut für Telekommunikationsnormen (ETSI) wurden beschränkte Standards im Versuch entwickelt, gemeinsame Schnittstellen zum Betrieb von MEC-Systemen, Plattformen, Hosts, Diensten und Anwendungen zu definieren.
-
Edge-Computing, MEC und verwandte Technologien versuchen, eine reduzierte Latenz, erhöhte Reaktionsfähigkeit und mehr verfügbare Rechenleistung bereitzustellen, als sie in herkömmlichen Cloud-Netzwerkdiensten und Fernnetzverbindungen geboten werden. Die Integration von Mobilität und dynamisch gestarteten Diensten für einen mobilen Einsatz und Vorrichtungsverarbeitungs-Anwendungsfälle hat jedoch zu Einschränkungen und Bedenken bei Orchestrierung, funktionaler Koordinierung und Ressourcenverwaltung geführt, insbesondere in komplexen Mobilitätsumgebungen, an denen viele Teilnehmer (z. B. Vorrichtungen, Hosts, Mandanten, Dienstanbieter, Betreiber usw.) involviert sind.
-
Auf ähnliche Weise sind Netzwerke und Vorrichtungen des Internets der Dinge (IdD) konstruiert, eine verteilte Rechenanordnung von einer Vielfalt von Endpunkten zu bieten. IdD-Vorrichtungen können physische oder virtualisierte Objekte sein, die auf einem Netzwerk kommunizieren können, und können Sensoren, Stellglieder und andere Eingabe/Ausgabe-Komponenten enthalten, die verwendet werden können, um Daten zu sammeln oder Handlungen in einer realen Umgebung durchzuführen. IdD-Vorrichtungen können zum Beispiel Niedrigenergie-Endpunktvorrichtungen enthalten, die in alltägliche Dinge eingebettet oder an diesen befestigt sind, wie Gebäude, Fahrzeuge, Pakete usw., um eine zusätzliche Ebene von künstlicher Sensorerfassung dieser Dinge bereitzustellen. In den letzten Jahren wurden IdD-Vorrichtungen immer beliebter, und deshalb haben sich Anwendungen, die diese Vorrichtungen verwenden, stark vermehrt.
-
In einigen Beispielen kann eine Edge-Umgebung eine Unternehmens-Edge enthalten, in der eine Kommunikation mit und/oder eine Kommunikation innerhalb der Unternehmens-Edge über drahtlose und/oder verdrahtete Verbindungsfähigkeit ermöglicht werden kann. Der Einsatz verschiedener Edge-, Fog-, MEC- und IdD-Netzwerke, Vorrichtungen und Dienste haben eine Anzahl von erweiterten Anwendungsfällen und Szenarien hervorgebracht, die am Rand und zum Rand des Netzwerks hin auftreten. Diese erweiterten Anwendungsfälle haben jedoch auch eine Anzahl entsprechender technischer Herausforderungen in Bezug auf Sicherheit, Verarbeitung und Netzwerkressourcen, Dienstverfügbarkeit und -effizienz, unter vielen anderen Problemen eingeführt. Eine derartige Herausforderung ist, in Bezug auf Edge-, Fog-, MEC- und IdD-Netzwerke, -Vorrichtungen und -Dienste, ein Ausführen von Arbeitslasten im Auftrag von Endpunktvorrichtungen.
-
Die vorliegenden Techniken und Konfigurationen können in Verbindung mit vielen Gesichtspunkten aktueller Netzwerksysteme eingesetzt werden, werden jedoch unter Bezugnahme auf Edge-, Cloud-, IdD-, Mehrfachzugriff-Edge-Computing (MEC) und andere verteilte Computing-Aufstellungen bereitgestellt. Die folgenden Systeme und Techniken können in einer Vielfalt von verteilten, virtualisierten oder verwalteten Edge-Rechensystemen implementiert sein oder diese erweitern. Diese enthalten Umgebungen, in denen Netzwerkdienste unter Verwendung von Mehrfachzugriff-Edge-Computing (MEC), drahtloser Netzwerkkonfigurationen der vierten Generation (4G) oder der fünften Generation (5G); oder in verdrahteten Netzwerkkonfigurationen implementiert sind, die Lichtwellenleiter, Kupfer und andere Verbindungen involvieren. Ferner können Gesichtspunkte der Verarbeitung durch die jeweiligen Rechenkomponenten rechnerische Elemente involvieren, die sich in geografischer Nähe zu einem Endgerät oder anderen Endpunktstandorten befinden, wie ein Smartphone, eine Fahrzeugkommunikationskomponente, IdD-Vorrichtungen usw. Ferner können die gegenwärtig offenbarten Techniken andere Edge-/MEC-/IdD-Netzwerk-Kommunikationsstandards und -konfigurationen und andere Zwischenverarbeitungsentitäten und -architekturen betreffen.
-
Edge-Computing ist ein sich entwickelndes Konzept, bei dem Rechnen am oder näher am „Rand“ eines Netzwerks durchgeführt wird, üblicherweise durch die Verwendung einer Rechenplattform, die an Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen implementiert ist, die sich viel näher bei Endpunktvorrichtungen befinden, die die Daten erzeugen und konsumieren. Beispielsweise können Edge-Gatewayserver mit Beständen von Arbeitsspeicher- und Speicherressourcen ausgestattet sein, um eine Berechnung in Echtzeit für Anwendungsfälle mit niedriger Latenz (z. B. autonomes Fahren oder Videoüberwachung) für angebundene Clientvorrichtungen durchzuführen. Oder als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für angebundene Endgeräte direkt zu verarbeiten, ohne weiter Daten über Zubringernetzwerke zu kommunizieren. Oder als weiteres Beispiel kann zentrale Büronetzwerkverwaltungshardware durch Rechenhardware ersetzt werden, die virtualisierte Netzwerkfunktionen durchführt und Rechenressourcen für die Ausführung von Diensten und Verbraucheranwendungen für angebundene Vorrichtungen bietet.
-
Edge-Umgebungen enthalten Netzwerke und/oder Abschnitte von Netzwerken, die zwischen einer Cloud-Umgebung und einer Endpunktumgebung angeordnet sind. Edge-Umgebungen ermöglichen Berechnungen von Arbeitslasten an Rändern eines Netzwerks. Eine Endpunktvorrichtung kann zum Beispiel anfordern, dass eine Basisstation in der Nähe anstatt eines zentralen Servers in einer Cloud-Umgebung eine Arbeitslast berechnet. Edge-Umgebungen enthalten Edge-Plattformen, die Bestände von Arbeitsspeicher, Speicherressourcen und/oder Verarbeitungsressourcen enthalten. Edge-Plattformen führen Berechnungen, wie eine Ausführung einer Arbeitslast, im Auftrag von anderen Edge-Plattformen und/oder Edge-Knoten aus. Edge-Umgebungen ermöglichen Verbindungen zwischen Erzeugern (z. B. Ausführern von Arbeitslasten, Edge-Plattformen) und Verbrauchern (z. B. anderen Edge-Plattformen, Endpunktvorrichtungen).
-
Da Edge-Plattformen näher an Endpunktvorrichtungen als zentralisierte Server in Cloud-Umgebungen angeordnet sein können, ermöglichen Edge-Plattformen Berechnungen von Arbeitslasten mit einer geringeren Latenz (z. B. Antwortzeit) als Cloud-Umgebungen. Edge-Plattformen können auch eine lokalisierte Ausführung einer Arbeitslast auf Grundlage von geografischen Standorten oder Netzwerktopografien ermöglichen. Eine Endpunktvorrichtung kann zum Beispiel erfordern, dass eine Arbeitslast in einem ersten geografischen Bereich ausgeführt wird, aber ein zentralisierter Server kann sich in einem zweiten geografischen Bereich befinden. Die Endpunktvorrichtung kann eine Arbeitslastausführung durch eine Edge-Plattform anfordern, die sich im ersten geografischen Bereich befindet, um unternehmerische oder regulatorische Einschränkungen zu erfüllen.
-
Beispiele von Arbeitslasten, die in einer Edge-Umgebung auszuführen sind, enthalten Berechnungen für autonomes Fahren, Videoüberwachung, Ausführen maschineller Lernmodelle und Datenanalyse in Echtzeit. Zusätzliche Beispiele von Arbeitslasten enthalten ein Liefern und/oder Codieren von Medienströmen, Messen von Werbeeindrucksraten, Objekterkennung in Medienströmen, Sprachanalyse, Anlagen- und/oder Bestandsverwaltung und Verarbeitung erweiterter Realitäten.
-
Edge-Plattformen ermöglichen sowohl die Ausführung von Arbeitslasten als auch ein Zurückgeben eines Ergebnisses einer ausgeführten Arbeitslast an Endpunktvorrichtungen mit einer Reaktionszeit, die niedriger als die Reaktionszeit eines Servers in einer Cloud-Umgebung ist. Falls zum Beispiel eine Edge-Plattform näher bei einer Endpunktvorrichtung als ein Cloud-Server in einem Netzwerk angeordnet ist, kann der Edge-Dienst schneller als der Cloud-Server auf Arbeitslastausführungsanforderungen von der Endpunktvorrichtung reagieren. Eine Endpunktvorrichtung kann eine Ausführung einer zeitlich eingeschränkten Arbeitslast von einem Edge-Dienst anstatt von einem Cloud-Dienst anfordern.
-
Darüber hinaus ermöglichen Edge-Plattformen die Verteilung und Dezentralisierung von Arbeitslastausführungen. Eine Endpunktvorrichtung kann zum Beispiel eine Ausführung einer ersten Arbeitslast und eine Ausführung einer zweiten Arbeitslast anfordern. In einigen Beispielen kann ein Cloud-Server auf beide Anforderungen zur Arbeitslastausführung reagieren. Mit einer Edge-Umgebung kann jedoch eine erste Edge-Plattform die Ausführungsanforderung der ersten Arbeitslast ausführen, und eine zweite Edge-Plattform kann die Ausführungsanforderung der zweiten Arbeitslast ausführen.
-
Um die Anforderungen niedriger Latenz und hoher Bandbreite von Endpunktvorrichtungen zu erfüllen, wird in Edge-Clouds eine Orchestrierung auf Grundlage von zeitgerechten Informationen über den Einsatz vieler Ressourcen (z. B. Hardwareressourcen, Softwareressourcen, virtuellen Hardware- und/oder Softwareressourcen usw.) und über die Effizienz, mit der diese Ressourcen die an sie gestellten Anforderungen erfüllen können, durchgeführt. Derartige zeitgerechte Informationen werden allgemein als Telemetrie (z. B. Telemetriedaten, Telemetrieinformationen usw.) bezeichnet.
-
Telemetrie kann aus einer Vielzahl von Quellen generiert werden, einschließlich jeder Hardwarekomponente oder jedem Abschnitt davon, virtueller Maschinen (VMs), Betriebssystemen (OSes), Anwendungen und Orchestratoren. Telemetrie kann von Orchestratoren, Planern usw. verwendet werden, um eine Menge, Mengen und/oder einen Typ von Rechenaufgaben, die zur Ausführung an welcher Ressource oder (einem) Abschnitt(en) davon zu planen sind, und eine erwartete Zeit bis zum Abschluss derartiger Rechenaufgaben auf Grundlage von historischer und/oder aktueller (z. B. sofortiger oder fast sofortiger) Telemetrie zu planen sind. Ein Kern einer zentralen Mehrkern-Verarbeitungseinheit (CPU) kann zum Beispiel jeden Sekundenbruchteil unter Verwendung einer Leistungsüberwachungseinheit (PMU), die den Kern und/oder allgemeiner die Mehrkern-CPU abtastet, über ein Tausend verschiedene Varianten von Informationen generieren. Periodisches Aggregieren und Verarbeiten der gesamten derartigen Telemetrie auf einer bestimmten Edge-Plattform, einem bestimmten Edge-Knoten usw. können ein mühsamer und beschwerlicher Prozess sein. Ein Priorisieren von wesentlichen interessierenden Merkmalen und ein Extrahieren derartiger wesentlicher Merkmale aus Telemetrie, um aktuelle oder zukünftige Probleme, Stressfaktoren usw. zu identifizieren, die mit einer Ressource assoziiert sind, ist schwierig. Ferner ist ein Identifizieren einer anderen Ressource zum Auslagern von Arbeitslasten von einer belasteten Ressource ein komplexes Unterfangen.
-
Einige Edge-Umgebungen wollen Telemetriedaten erhalten, die mit Ressourcen assoziiert sind, die eine Vielfalt von Funktionen oder Diensten ausführen, wie Datenverarbeitungs- oder Videoanalysefunktionen (z. B. Maschinensehen, Bildverarbeitung für ein autonomes Fahrzeug, Gesichtserkennung, visuelle Objekterkennung usw.). Viele Arbeitslasten mit hohem Durchsatz, einschließlich einer oder mehrerer Videoanalysefunktionen, können weniger als eine Millisekunde lang (oder eine andere, relativ geringe Zeitdauer) ausgeführt werden. Derartige Edge-Umgebungen weisen keine verteilte Überwachungssoftware oder Hardwarelösungen oder eine Kombination daraus auf, die fähig sind, derartige stark granulare zustandslose Funktionen zu überwachen, die auf einer Plattform (z. B. einer Ressourcenplattform, einer Hardwareplattform, einer Softwareplattform, einer virtualisierten Plattform usw.) ausgeführt werden.
-
Viele Edge-Umgebungen enthalten eine Vielfalt von Komponenten zur Ressourcenverwaltung und Orchestrierung. Die meisten davon setzen eine statische Orchestrierung beim Entscheiden über eine Platzierung von Diensten und einer Arbeitslast auf spezifischen Edge-Plattformen ein und führen eine Überwachung eines Leistungsvertrags der Anwendungen und/oder Dienste in einem Framework mit beliebigem Kostenaufwand durch. Ein Framework mit beliebigem Kostenaufwand enthält Orchestrierungskomponenten, die Ressourcen und Dienste auf einer Edge-Plattform verwalten, aber berücksichtigt die rechnerischen Kosten nicht, die mit den Orchestrierungskomponenten assoziiert sind. Darüber hinaus enthält ein Framework mit beliebigem Kostenaufwand Orchestrierungskomponenten, die nicht auf die Verfügbarkeit von rechnerischen Ressourcen und Energie zum Durchführen von Operationen reagieren, die mit diesen Orchestrierungsressourcen assoziiert sind. Deshalb enthalten viele Edge-Umgebungen Orchestrierungsressourcen, die unelastisch sind und Ressourcen einer Edge-Plattform auf nicht proportionale Weise in Bezug auf die Ressourcen und Energie verbrauchen, die sie verwalten. Darüber hinaus enthalten viele Edge-Umgebungen keine Orchestrierungskomponenten, die auf einem Beschleuniger ausgeführt werden können. Das Framework mit beliebigem Kostenaufwand bestehender Komponenten ist eine Schwachstelle (z. B. ein Glaskinn) vieler Edge-Umgebungen. Orchestrierungskomponenten in den meisten Edge-Plattformen konzentrieren sich auf Optimieren der Ressourcennutzung von Diensten und/oder Anwendungen, die auf einer Edge-Plattform ausgeführt werden, und das Erfüllen von Leistungsverträgen (SLAs) von Anwendungen und/oder Arbeitslasten. Orchestrierungskomponenten in den meisten Edge-Umgebungen berücksichtigen jedoch nicht den Verbrauch von Ressourcen durch Orchestrierungskomponenten. Während einige Orchestrierungskomponenten bei ihren eigenen Rechen- und Telemetriedatenbewegungsanforderungen sparsam sein können, sind diese sparsamen Operationen inflexibel und unbeweglich (es gibt z. B. keinen Weg zum Orchestrieren des Orchestrators).
-
Die Inflexibilität der meisten Orchestrierungskomponenten in Edge-Umgebungen kann durch Einbinden von Universalprozessoren und/oder Beschleunigern in Edge-Plattformen zum Implementieren einer skalierbaren Edge-Cloud behoben werden. Das Einbinden von Universalprozessoren und/oder Beschleunigern in Edge-Plattformen zum Implementieren einer skalierbaren Edge-Cloud kann jedoch Herausforderungen darstellen. Edge-Plattformen enthalten beispielsweise im Gegensatz zu den Plattformen in einer herkömmlichen Cloud Einschränkungen auf den physischen Raum. Zusätzlich zielen Edge-Plattformen darauf ab, eine niedrige Latenz und eine skalierbare Planung von Lösungen beim Verarbeiten von Mandantenanforderungen und/oder Funktionen bereitzustellen. Andere Herausforderungen sind mit einem Erzielen eines hohen Verhältnisses der Ressourcennutzung für Mandantenanforderungen und/oder Funktionen in Bezug auf für einen Systemsoftwarestapel verwendete Ressourcen verbunden. Darüber hinaus stellt ein Verwalten des Energieverbrauchs und/oder von Verrechnungsrichtlinien an Edge-Plattformen Herausforderungen dar.
-
Angesichts von Energie- und/oder thermalen Einschränkungen an Edge-Plattformen (z. B. Basisstationen) im Gegensatz zu denen in herkömmlicheren zentralisierten Cloud-Umgebungen (z. B. zentralen Büros) können dynamische, intelligente Energieverwaltungsrichtlinien pro Mandant auf Edge-Plattformen einen Kapitalaufwand und/oder einen Betriebsaufwand, der bzw. die mit einer Edge-Architektur verbunden ist bzw. sind, reduzieren und/oder rückgewinnen. Durch Monetisieren aller Funktionen, die in eine Edge-Architektur eines Edge-Dienstanbieters investiert wurden, kann der Edge-Anbieter zum Beispiel den Kapitalaufwand und/oder Betriebsaufwand rückgewinnen, die mit den Funktionen der Edge-Architektur assoziiert sind. Einige Edge-Architekturen können durch Sonnen- und Windenergie angetrieben werden. Wenn rechnerische Ressourcen und/oder thermale Bedingungen auf einer Edge-Plattform durch variable erneuerbare Energien (z. B. Sonne, Wind, Hydro usw.) und/oder durch eine Notstrombatterie mit eingeschränkter Kapazität angetrieben werden, kann ein Versagen, eine genaue Energieverwaltung für Dienste bereitzustellen, die Zuverlässigkeit von Edge-Plattformen mindern. Darüber hinaus können einige Edge-Architekturen eine stabile (z. B. mit dem Netz verbundene) Energie aufweisen, ein Ausgleichen von thermalen Zuständen kann jedoch in derartigen Edge-Architekturen schwierig sein.
-
Während Originalhersteller (OEMs) und Siliziumanbieter die Energieanforderungen und/oder Stromversorgungen von verteilten Rechenumgebungen berücksichtigen, setzen viele rechenzentrumsähnliche, kontinuierlich und stabil mit Strom versorgte Umgebungen mit unterbrechungsfreien Stromversorgungen und Generatoren voraus, die zur Unterstützung während Stromausfällen verfügbar sind. Bei vielen OEM- und Siliziumanbieterdesigns für Edge-Plattformen fehlt eine Unterstützung zum optimalen und flexiblen Betrieb bei dynamischen Energie- und/oder thermalen Einhüllenden. Darüber hinaus können Edge-Plattformen unterschiedliche Energie-Leistungs-Auswirkungen beim Betrieb in einer herkömmlichen Rechenumgebung im Gegensatz zu einem Betrieb in einer Edge-Umgebung aufweisen.
-
Eine weitere Herausforderung in Edge-Umgebungen ist eine eingeschränkte Versorgung, nicht nur in Bezug auf Energie, sondern auch in Bezug auf eine Elastizität von Edge-Plattformen. Beim Erweitern von herkömmlichen rechenzentrumsähnlichen Cloud-Praktiken zum Hosten von Anwendungen an unterschiedlichen Edge-Standorten enthalten einige der zu berücksichtigenden Faktoren: wie viele Ressourcen jeder Arbeitslast (z. B. Dienst, Anwendung usw.) auf Edge-Plattformen zugewiesen sind; wie und/oder wo Beschleuniger einzusetzen sind, um eine gute Leistung pro Watt zu erhalten; auf Grundlage der Energie, welche Dienste zwischen Edge-Plattformen zu migrieren sind, um Spitzen im Energieverbrauch zu verhindern; und wie ein Energiebedarf über Leistungsverträge hinweg auszugleichen ist, die mit verschiedenen Mandantenarbeitslasten (z. B. auf Grundlage von Richtlinien) assoziiert sind.
-
Der nicht einheitliche und unvorhersehbare Bedarf, der in einer Edge-Umgebung zusammen mit der unelastischen Versorgung von Energie und/oder anderer Ressourcen in einer Edge-Umgebung auftreten kann, bewirkt nicht nur, dass die Benutzer/Mandantendienste/Anwendungen Energie und/oder andere Ressourcen verbrauchen, sondern auch der Systemsoftwarestapel und die Edge-Plattform-Verwaltungskomponenten, die ebenfalls Energie und Hardware verbrauchen. In einigen Edge-Plattformen können der Softwarestapel und die Edge-Plattform-Verwaltungskomponenten zum Beispiele 30 % eines Fußabdrucks der gesamten Edge-Plattform nutzen.
-
Hierin offenbarte Beispiele enthalten Verfahren und Vorrichtungen zum Steuern einer Verarbeitung von Telemetriedaten auf einer Edge-Plattform. Hierin offenbarte Beispiele berücksichtigen, wie Telemetriedaten vom Systemsoftwarestapel und den Edge-Plattform-Verwaltungskomponenten (z. B. Orchestrierungskomponenten) verarbeitet werden. Hierin offenbarte Beispiele ermöglichen die Verarbeitung von Telemetriedaten auf Near-Edge-Plattformen (die z. B. geografisch von einem Endpunkt und/oder einer Clientvorrichtung entfernt sind) und/oder Far-Edge-Plattformen (die z. B. geografisch nahe an einem Endpunkt und/oder einer Clientvorrichtung sind). In hierin offenbarten Beispielen beruht die Auswahl zwischen Near-Edge-Plattformen und/oder Far-Edge-Plattformen zum Verarbeiten von Telemetriedaten darauf, wie Orchestrierungskomponenten Telemetriedaten gesammelt und/oder verarbeitet haben. Deshalb ändern hierin offenbarte Beispiele eine Telemetriedatenanalyse dynamisch zwischen Near-Edge-Plattformen und Far-Edge-Plattformen. Einige Telemetriedaten können zum Beispiele auf einer Near-Edge-Plattform verarbeitet werden und auf Grundlage der Orchestrierungsaufgaben und/oder Ergebnisse, die auf der Near-Edge-Plattform ermittelt wurden, können zukünftige Telemetriedaten auf einer Far-Edge-Plattform verarbeitet werden.
-
Hierin offenbarte Beispiele berücksichtigen, wo und wie Komponenten, die für eine Orchestrierung und eine Verwaltung von Leistungsverträgen (SLA) verantwortlich sind (z. B. Orchestrierungskomponenten), ausgeführt werden. Deshalb bieten hierin offenbarte Beispiele eine dynamische Wahl zwischen einer lokalen Ausführung, auf einer Far-Edge-Plattform mit eingeschränkten Ressourcen, oder einem Delegieren an eine vergleichsweise gut ausgestattete Near-Edge-Plattform, aber auf Kosten einiger Reaktionsfähigkeit und mit einem Verlust einer feineren Steuerung der Orchestrierung an der Far-Edge-Plattform. Hierin offenbarte Beispiele enthalten eine abgestufte Architektur, die den dynamischen Kompromiss zwischen der Art, wie Telemetriedaten von Orchestrierungskomponenten verarbeitet werden, und der Art und/oder dem Standort ermöglichen, wie und/oder wo Orchestrierungskomponenten ausgeführt werden. Hierin offenbarte Beispiele beschreiben, wie Hardwarebeschleuniger eine dynamische Verwaltung der Orchestrierungskomponenten implementieren können. Hierin offenbarte Beispiele enthalten eine Meta-Orchestrierung von Orchestrierungskomponenten als Reaktion auf fluktuierende Energieversorgung und thermale Bedingungen.
-
1 zeigt ein beispielhaftes Edge-Rechensystem 100 zum Bereitstellen von Edge-Diensten und Anwendungen an Entitäten mit mehreren Akteuren, wie sie unter einer oder mehreren Client-Rechenplattformen 102, einer oder mehreren Edge-Gatewayplattformen 112, einer oder mehrerer Edge-Aggregationsplattformen 122, einem oder mehreren Kernrechenzentren 132 und einer globalen Netzwerkcloud 142 verteilt sind, wie sie über Schichten des Edge-Rechensystems 100 verteilt sind. Die Implementierung des Edge-Rechensystems 100 kann an einem Telekommunikationsdienstanbieter („Telko“ oder „TSP“), einem Internet-der-Dinge-Dienstanbieter, Cloud-Dienstanbieter (CSP), einer Unternehmensentität oder einer beliebigen anderen Anzahl von Entitäten oder im Auftrag eines bzw. einer solchen bereitgestellt werden. Verschiedene Implementierungen und Konfigurationen des Edge-Rechensystems 100 können dynamisch bereitgestellt werden, wie zum Beispiel, bei Orchestrierung, um Dienstziele zu erfüllen.
-
Individuelle Plattformen oder Vorrichtungen des Edge-Rechensystems 100 befinden sich in einer bestimmten Schicht, die den Schichten 120, 130, 140, 150 und 160 entspricht. Die Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f befinden sich zum Beispiel in einer Endpunkt-Schicht 120, während sich die Edge-Gatewayplattformen 112a, 112b, 112c in einer Edge-Vorrichtungsschicht 130 (lokale Ebene) des Edge-Rechensystems 100 befinden. Darüber hinaus befinden sich die Edge-Aggregationsplattformen 122a, 122b (und/oder Fog-Plattform(en) 124, falls sie mit einer Fog-Netzwerkkonfiguration 126 angeordnet oder betrieben oder unter einer solchen angeordnet oder betrieben werden) in einer Netzwerkzugriffsschicht 140 (einer Zwischenebene). Fog-Computing (oder „Fogging“) bezeichnet allgemein Erweiterungen von Cloud-Computing an den Rand eines Netzwerks eines Unternehmens oder die Fähigkeit, Transaktionen über die Cloud/Edge-Landschaft hinweg zu verwalten, üblicherweise in einem koordinierten verteilten oder Mehrknoten-Netzwerk. Einige Formen des Fog-Computing sehen den Einsatz von Rechen-, Speicher- und Netzwerkdiensten zwischen Endvorrichtungen und Cloud-Computing-Rechenzentren im Auftrag der Cloud-Computing-Standorte vor. Einige Formen des Fog-Computing sehen auch die Fähigkeit vor, die Arbeitslast/die Dienste auf Arbeitslastebene in Bezug auf die Gesamttransaktion zu verwalten, indem bestimmte Arbeitslasten auf Grundlage der Fähigkeit, den Gesamtleistungsvertrag zu erfüllen, an den Rand oder in die Cloud verlagert werden.
-
Fog-Computing sieht in vielen Szenarien eine dezentralisierte Architektur vor und dient durch Zusammenarbeiten mit einer oder mehreren Edge-Knoten-Vorrichtungen, Bereitstellen des nachfolgenden Ausmaßes an lokalisierter Steuerung, Konfiguration und Verwaltung und vieles mehr für Endvorrichtungen als eine Erweiterung zum Cloud-Computing. Ferner sieht Fog-Computing die Fähigkeit für Edge-Ressourcen vor, ähnliche Ressourcen zu identifizieren und zusammenzuarbeiten, um eine Edge-lokale Cloud zu erstellen, die alleine oder zusammen mit Cloud-Computing verwendet werden kann, um rechen-, speicher- oder verbindungsbezogene Dienste abzuschließen. Fog-Computing kann den cloudbasierten Diensten auch ermöglichen, ihre Reichweite an den Rand eines Netzwerks von Vorrichtungen zu erweitern, um lokale und raschere Erreichbarkeit von Edge-Vorrichtungen zu bieten. Deshalb sehen einige Formen von Fog-Computing Operationen vor, die mit Edge-Computing vereinbar sind, wie hierin besprochen; die hierin besprochenen Edge-Computing-Gesichtspunkte sind auch auf Fog-Netzwerke, Fogging und Fog-Konfigurationen anwendbar. Ferner können Gesichtspunkte der hierin besprochenen Edge-Rechensysteme als ein Fog konfiguriert sein oder Gesichtspunkte eines Fogs können in eine Edge-Rechenarchitektur integriert sein.
-
Das Kernrechenzentrum 132 befindet sich in einer Kernnetzwerkschicht 150 (einer regionalen oder geografisch zentralen Ebene), während sich die globale Netzwerk-Cloud 142 in einer Cloud-Rechenzentrumsschicht 160 (einer nationalen oder weltweiten Ebene) befindet. Die Verwendung von „Kern“ ist als ein Begriff für eine zentralisierte Netzwerkposition - tiefer im Netzwerk - vorgesehen, die durch mehrere Edge-Plattformen oder Komponenten zugänglich ist; ein „Kern“ bezeichnet jedoch nicht notwendigerweise das „Zentrum“ oder die tiefste Position des Netzwerks. Dementsprechend kann das Kernrechenzentrum 132 innerhalb, in oder nahe der Edge-Cloud 110 angeordnet sein. Obwohl eine veranschaulichende Anzahl von Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f; Edge-Gatewayplattformen 112a, 112b, 112c; Edge-Aggregationsplattformen 122a, 122b; Edge-Kern-Rechenzentren 132; und globale Netzwerkclouds 142 in 1 gezeigt sind, sollte klar sein, dass das Edge-Rechensystem 100 in jeder Schicht eine beliebige Anzahl von Vorrichtungen und/oder Systemen enthalten kann. Vorrichtungen in einer beliebigen Schicht können als Peer-Knoten und/oder Peer-Plattformen zueinander konfiguriert sein und dementsprechend auf zusammenwirkende Weise arbeiten, um Dienstziele zu erfüllen. In zusätzlichen oder alternativen Beispielen können die Edge-Gatewayplattformen 112a, 112b, 112c beispielsweise als ein Rand von Rändern konfiguriert werden, sodass die Edge-Gatewayplattformen 112a, 112b, 112c über Peer-zu-Peer-Verbindungen kommunizieren. In einigen Beispielen können die Edge-Aggregationsplattformen 122a, 122b und/oder die Fog-Plattform(en) 124 als ein Rand von Rändern konfiguriert sein, sodass die Edge-Aggregationsplattformen 122a, 122b und/oder die Fog-Plattform(en) über Peer-zu-Peer-Verbindungen kommunizieren. Zusätzlich, wie in 1 gezeigt, erhöht sich die Anzahl der Komponenten der jeweiligen Schichten 120, 130, 140, 150 und 160 im Allgemeinen in jeder niedrigeren Ebene (z. B., wenn man sich näher an die Endpunkte (z. B. die Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f) bewegt). Als solche kann eine der Edge-Gatewayplattformen 112a, 112b, 112c mehrere der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f betreuen und eine Edge-Aggregationsplattform (z. B. eine der Edge-Aggregationsplattformen 122a, 122b) kann mehrere der Edge-Gatewayplattformen 112a, 112b, 112c betreuen.
-
In Übereinstimmung mit den hierin bereitgestellten Beispielen kann eine Client-Rechenplattform (z. B. eine der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f) als ein beliebiger Typ von Endpunktkomponente, Vorrichtung, Gerät oder ein anderes Ding implementiert sein, das fähig ist, als ein Erzeuger oder Verbraucher von Daten zu kommunizieren. Eine Client-Rechenplattform kann zum Beispiel ein Mobiltelefon, einen Laptop-Computer, einen Desktop-Computer, eine Prozessorplattform in einem autonomen Fahrzeug usw. enthalten. In zusätzlichen oder alternativen Beispielen kann eine Client-Rechenplattform eine Kamera, einen Sensor usw. enthalten. Ferner bedeutet die Bezeichnung „Plattform“, „Knoten“ und/oder „Vorrichtung“, wie sie im Edge-Rechensystem 100 verwendet wird, nicht notwendigerweise, dass eine derartige Plattform, ein derartiger Knoten und/oder eine derartige Vorrichtung in einer Client- oder Slave-Rolle arbeitet; vielmehr bezeichnen beliebige der Plattformen, Knoten und/oder Vorrichtungen im Edge-Rechensystem 100 individuelle Entitäten, Plattformen, Knoten, Vorrichtungen und/oder Teilsysteme, die diskrete und/oder verbundene Hardware- und/oder Softwarekonfigurationen enthalten, um die Edge-Cloud 110 zu ermöglichen und/oder zu verwenden.
-
Als solche ist die Edge-Cloud 110 aus Netzwerkkomponenten und funktionalen Merkmalen gebildet, die von den Edge-Gatewayplattformen 112a, 112b, 112c bzw. den Edge-Aggregationsplattformen 122a, 122b der Schichten 130, 140 betrieben und innerhalb dieser betrieben werden. Die Edge-Cloud 110 kann als ein beliebiger Typ von Netzwerk implementiert werden, der Edge-Computing- und/oder Speicherressourcen bereitstellt, die in der Nähe von Funkzugangsnetzwerk(RAN)-fähigen Endpunktvorrichtungen (z. B. mobilen Rechenvorrichtungen, IdD-Vorrichtungen, intelligenten Vorrichtungen usw.) angeordnet sind, die in 1 als die Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f gezeigt sind. Anders ausgedrückt kann man sich die Edge-Cloud 110 als ein „Rand“ vorstellen, der die Endpunktvorrichtungen und herkömmliche Netzwerkzugangspunkte verbindet, der als ein Zugriffspunkt zu Kernnetzen von Dienstanbietern dient, einschließlich Netzwerken von mobilen Trägern (z. B. Netzwerke des Global System for Mobile Communications (GSM), Long-Term-Evolution(LTE)-Netzwerke, 5G/6G-Netzwerke usw.), während er auch Speicher- oder Rechenfunktionen bereitstellt. Andere Arten und Formen des Netzwerkzugriffs (z. B. WiFi, drahtlose, verdrahtete Langstreckennetze einschließlich optischer Netzwerke) können auch anstatt oder in Kombination mit derartigen 3GPP-Trägernetzen eingesetzt werden.
-
In einigen Beispielen kann die Edge-Cloud 110 einen Abschnitt einer Fog-Netzwerkkonfiguration 126 (z. B. eines Netzwerks der Fog-Plattform(en) 124, nicht im Detail gezeigt) bilden oder anderweitig einen Zugangspunkt in diese oder über diese hinweg bereitstellen, der als eine horizontale und verteilte Architektur auf Systemebene implementiert sein kann, die Ressourcen und Dienste verteilt, um eine bestimmte Funktion durchzuführen. Ein koordiniertes und verteiltes Netzwerk der Fog-Plattform(en) 124 kann beispielsweise Rechnen, Speicherung, Steuerung oder Netzwerkgesichtspunkte im Kontext einer IdD-Systemanordnung durchführen. Andere vernetzte, aggregierte und verteilte Funktionen können in der Edge-Cloud 110 zwischen dem Kernrechenzentrum 132 und den Client-Endpunkten existieren (z. B. den Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f). Einige dieser werden in den folgenden Abschnitten im Kontext von Netzwerkfunktionen oder Dienstvirtualisierung besprochen, einschließlich der Verwendung von virtuellen Rändern und virtuellen Diensten, die für mehrere Mandanten orchestriert werden.
-
Wie unten ausführlicher besprochen wird, arbeiten die Edge-Gatewayplattformen 112a, 112b, 112c und die Edge-Aggregationsplattformen 122a, 122b zusammen, um den Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f verschiedene Edge-Dienste und Sicherheit bereitzustellen. Darüber hinaus, da eine Client-Rechenplattform (z. B. eine der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f) stationär oder mobil sein kann, kann eine jeweilige Edge-Gatewayplattform 112a, 112b, 112c mit anderen Edge-Gatewayplattformen zusammenarbeiten, um aktuell bereitgestellte Edge-Dienste, relevante Dienstdaten und Sicherheit weiterzuleiten, wenn sich die entsprechenden Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f in einem Bereich bewegen. Hierzu können die Edge-Gatewayplattformen 112a, 112b, 112c und/oder die Edge-Aggregationsplattformen 122a, 122b Konfigurationen mit mehreren Mandaten und mehreren Mandanten unterstützen, in denen Dienste von mehreren Dienstanbietern, Eigentümern und mehreren Verbrauchern (oder für diese gehostete Dienste) über eine einzige oder mehrere Rechenvorrichtungen unterstützt und koordiniert werden können.
-
In hierin offenbarten Beispielen enthalten Edge-Plattformen im Edge-Rechensystem 100 Meta-Orchestrierungsfunktionalität. Beispielsweise können Edge-Plattformen am Far Edge (z. B. Edge-Plattformen näher bei Edge-Benutzern, der Edge-Vorrichtungsschicht 130 usw.) die Leistung oder den Energieverbrauch von mit Far-Edge-Plattformen assoziierten Orchestrierungsaufgaben reduzieren, sodass die Ausführung von Orchestrierungskomponenten auf Far-Edge-Plattformen einen kleinen Bruchteil der Energie und Leistung verbraucht, die an Far-Edge-Plattformen verfügbar sind.
-
Die Orchestratoren auf verschiedenen Far-Edge-Plattformen nehmen an einer durchgehenden Orchestrierungsarchitektur teil. Hierin offenbarte Beispiele erwarten, dass das umfassende Betriebssoftwareframework (wie zum Beispiel die Open Network Automation Platform (ONAP) oder eine ähnliche Plattform) erweitert wird oder innerhalb dieser erstellte Optionen erweitert werden, sodass hierin offenbarte Beispiele mit diesen Frameworks kompatibel sein können. Orchestratoren auf Edge-Plattformen, die hierin offenbarte Beispiele implementieren, können zum Beispiel an ONAP-Orchestrierungsabläufe anbinden und eine Edge-Plattform-Orchestrierung und Telemetrieaktivitäten ermöglichen. Orchestratoren, die hierin offenbarte Beispiele implementieren, arbeiten, um die Orchestrierungs- und Telemetrieaktivitäten, die auf Edge-Plattformen durchgeführt werden, zu regeln, einschließlich eines Erhöhens oder Verringerns der Energie und/oder Ressourcen, die von den lokalen Orchestrierung- und Telemetriekomponenten aufgewandt werden, eines Delegierens von Orchestrierungs- und Telemetrieprozessen an einen entfernten Computer und/oder ein Abrufen von Orchestrierungs- und Telemetrieprozessen vom entfernten Computer, wenn Energie und/oder Ressourcen verfügbar sind.
-
Die oben beschriebenen entfernten Vorrichtungen sind an alternativen Standorten in Bezug auf diejenigen Edge-Plattformen angeordnet, die Telemetrie- und Orchestrierungsprozesse auslagern. Die oben beschriebenen entfernten Vorrichtungen können zum Beispiel im Gegensatz dazu an Near-Edge-Plattformen angeordnet sein (z. B. der Netzwerkzugangsschicht 140, der Kernnetzwerkschicht 150, einem zentralen Büro, einem Mini-Rechenzentrum usw.). Durch Auslagern von Telemetrie- und/oder Orchestrierungsprozessen an eine Near-Edge-Plattform wird einem Orchestrator an einer Near-Edge-Plattform eine (vergleichsweise) stabile Energieversorgung und hinreichende rechnerische Ressourcen sichergestellt, um eine Ausführung von Telemetrie- und/oder Orchestrierungsprozessen zu ermöglichen. Ein Orchestrator (der z. B. in Übereinstimmung mit einer globalen Schleife arbeitet) auf einer Near-Edge-Plattform kann delegierte Telemetrie- und/oder Orchestrierungsprozesse von einem Orchestrator (der z. B. in Übereinstimmung mit einer lokalen Schleife arbeitet) auf einer Far-Edge-Plattform nehmen. Falls ein Orchestrator auf einer Near-Edge-Plattform zum Beispiel delegierte Telemetrie- und/oder Orchestrierungsprozesse annimmt, dann kann der Orchestrator auf der Near-Edge-Plattform die delegierten Telemetrie- und/oder Orchestrierungsprozesse zu einem späteren Zeitpunkt an einen Orchestrator auf einer Far-Edge-Plattform zurückgeben, wenn sich die Zustände auf der Far-Edge-Plattform ändern (z. B. wenn Energie- und Rechenressourcen auf einer Far-Edge-Plattform einen Schwellenpegel erfüllen, wenn höhere Energiepegel und/oder höhere Rechenressourcenpegel auf einer Far-Edge-Plattform verfügbar werden usw.).
-
Eine Vielfalt von Sicherheitsansätzen kann innerhalb der Architektur der Edge-Cloud 110 eingesetzt werden. In einer Umgebung mit mehreren Akteuren kann es mehrere ladbare Sicherheitsmodule (LSMs) geben, die verwendet werden, um Richtlinien bereitzustellen, die die Interessen der Akteure, einschließlich der der Mandanten, durchsetzen. In einigen Beispielen können andere Betreiber, Dienstanbieter usw. Sicherheitsinteressen aufweisen, die mit den Interessen des Mandanten konkurrieren. Mandanten können zum Beispiel vorziehen, vollständige Dienste (die z. B. von einer Edge-Plattform bereitgestellt werden) kostenlos zu empfangen, während Dienstanbieter gerne eine vollständige Zahlung für ein Durchführen von wenig Arbeit oder Aufwenden geringer Kosten erhalten würden. Durchsetzungspunktumgebungen könnten mehrere LSMs unterstützen, die die Kombination von geladenen LSM-Richtlinien anwenden (wobei z. B. die am meisten eingeschränkte effektive Richtlinie angewandt wird, wie zum Beispiel, falls irgendeiner der Akteure A, B oder C einen Zugriff einschränkt, dann ist der Zugriff eingeschränkt). Innerhalb der Edge-Cloud Fehler! Verweisquelle konnte nicht gefunden werden. 10, kann jede Edge-Entität LSMs bereitstellen, die die Interessen der Edge-Entität durchsetzen. Die Cloud-Entität kann LSMs bereitstellen, die die Interessen der Cloud-Entität durchsetzen. Gleichermaßen können die verschiedenen Fog- und IdD-Netzwerkentitäten LSMs bereitstellen, die die Interessen der Fog-Entität durchsetzen.
-
In diesen Beispielen können Dienste aus der Perspektive einer Transaktion, die gegen eine Gruppe von Verträgen durchgeführt werden, oder als Bestandteile angesehen werden, egal auf Niveau eines Bestandteils oder einem von Menschen wahrnehmbaren Niveau. Deshalb erwartet ein Benutzer, der eine Dienstvertrag mit einem Dienstanbieter aufweist, dass der Dienst zu den Bedingungen des SLA geliefert wird. Obwohl nicht im Detail besprochen, kann die Verwendung von hierin besprochenen Edge-Rechentechniken während der Verhandlung der Vereinbarung und der Messung der Erfüllung der Vereinbarung eine Rolle spielen (um z. B. zu identifizieren, welche Elemente vom System erforderlich sind, um einen Dienst durchzuführen, wie das System auf Dienstbedingungen und Änderungen reagiert und dergleichen).
-
Darüber hinaus, in hierin offenbarten Beispielen können Edge-Plattformen und/oder Orchestrierungskomponenten davon mehrere Faktoren beim Orchestrieren von Diensten und/oder Anwendungen in einer Edge-Umgebung berücksichtigen. Diese Faktoren können eine Virtualisierung und Dienstverwaltung von intelligenten Zentralbüro-Netzwerkfunktionen der nächsten Generation, ein Verbessern einer Leistung pro Watt auf einer Edge-Plattform und/oder von Orchestrierungskomponenten, um die Einschränkung der Energie auf Edge-Plattformen zu überwinden, ein Reduzieren des Energieverbrauchs von Orchestrierungskomponenten und/oder einer Edge-Plattform, ein Verbessern des Hardwareeinsatzes, um eine Verwaltungs- und Orchestrierungseffizienz zu erhöhen, ein Bereitstellen von physischer und/oder durchgehender Sicherheit, ein Bereitstellen von individueller Erfüllung von Mandanten-Dienstqualitäts- und/oder Leistungsverträgen, ein Verbessern des Netzwerkausrüstung-Gebäudesystem-Complianceniveaus für jeden Anwendungsfall und jedes Mandanten-Geschäftsmodell, Zusammenlegen von Beschleunigungskomponenten und Verrechnungs- und Messrichtlinien, um eine Edge-Umgebung zu verbessern, enthalten.
-
Ein „Dienst“ ist ein breiter Begriff, der oft auf verschiedene Kontexte angewandt wird, aber allgemein bezeichnet er eine Beziehung zwischen zwei Entitäten, wobei eine Entität Arbeit zum Vorteil einer anderen anbietet und durchführt. Die von einer Entität zu einer anderen gelieferten Dienste müssen jedoch unter bestimmten Richtlinien durchgeführt werden, die Vertrauen zwischen den Entitäten sicherstellen und die Transaktion in Übereinstimmung mit den Vertragsbedingungen verwalten, die zu Beginn, während und am Ende des Diensts dargelegt werden.
-
Eine beispielhafte Beziehung zwischen Diensten zur Verwendung in einem Edge-Rechensystem wird unten beschrieben. In Szenarien des Edge-Computing gib es mehrere Dienste und Transaktionsschichten im Betrieb, die voneinander abhängig sind - diese Dienste erzeugen eine „Dienstkette“. Auf der untersten Ebene bilden Bestandteile Systeme. Diese Systeme und/oder Ressource kommunizieren und arbeiten miteinander zusammen, um einander sowie anderen permanenten oder transienten Entitäten um sie herum eine Vielzahl von Diensten bereitzustellen. Diese Entitäten können wiederum von Menschen konsumierbare Dienste bereitstellen. Mit dieser Hierarchie müssen Dienste, die auf jeder Stufe angeboten werden, transaktionsbezogen verbunden sein, um sicherzustellen, dass sich die individuelle Komponente (oder Teilentität), die einen Dienst bereitstellt, an die vertraglich vereinbarten Ziele und Spezifikationen hält. Abweichungen in jeder Schicht könnten zu einer Gesamteinwirkung auf die gesamte Dienstkette führen.
-
Eine Art von Dienst, der in einer Edge-Umgebungshierarchie angeboten werden kann, ist Dienste auf Siliziumebene. Hardware vom softwaredefinierten Silizium-Typ (SDSi-Typ) stellt zum Beispiel die Fähigkeit bereit, eine Befolgung von Transaktionen auf niedriger Ebene sicherzustellen, durch die Fähigkeit der Intraskalierung, Verwaltung und Sicherstellung der Durchführung von betrieblichen Leistungsverträgen. Die Verwendung von SDSi und ähnlicher Hardware-Lenkung stellt die Fähigkeit bereit, Merkmale und Ressourcen innerhalb eines Systems mit einem bestimmten Mandanten zu assoziieren und den individuellen Titel (die individuellen Rechte) auf diese Ressourcen zu verwalten. Die Verwendung derartiger Merkmale ist darunter ein Weg, um die Rechenressourcen dynamisch zur Arbeitslast „zu bringen“.
-
Eine Vereinbarung auf Betriebsebene und/oder ein Leistungsvertrag könnte zum Beispiel einen „transaktionsbezogenen Durchsatz“ oder „Pünktlichkeit“ definieren - im Fall von SDSi kann bzw. können sich das System und/oder die Ressource anmelden, um bestimmte Spezifikationen auf Dienstebene (SLS) und Ziele auf Dienstebene (SLO) eines Leistungsvertrags zu garantieren. SLOs können zum Beispiel bestimmten Leistungskennzahlen (KPIs) (z. B. Frames pro Sekunde, Gleitkommaoperationen pro Sekunde, Latenzziele usw.) einer Anwendung (z. B. einem Dienst, einer Arbeitslast usw.) entsprechen und ein SLA kann einer Vereinbarung auf Plattformebene entsprechen, um ein bestimmtes SLO zu erfüllen (z. B. ein Gigabyte Arbeitsspeicher für 10 Frames pro Sekunde). SDSi-Hardware stellt dem Infrastruktur- und Ressourceneigentümer auch die Fähigkeit bereit, der Siliziumkomponente (z. B. die Komponenten eines zusammengesetzten Systems, die metrische Telemetrie erzeugen) zu ermöglichen, auf Produktmerkmale zuzugreifen und diese zu verwalten (hinzuzufügen/zu entfernen) und Hardwarefunktionen und Nutzung frei auf- und abwärts zu skalieren. Ferner stellt sie auch die Fähigkeit bereit, deterministische Merkmalszuordnungen pro Mandant bereitzustellen. Sie stellt auch die Fähigkeit bereit, eine deterministische Orchestrierung und Dienstverwaltung mit der dynamischen (oder abonnementbasierten) Aktivierung von Merkmalen zu verknüpfen, ohne dass laufende Dienste, Clientoperationen unterbrochen werden müssen oder das System rückgesetzt oder neu geladen werden muss.
-
In der untersten Schicht kann SDSi Systemen Dienste und Garantien bereitstellen, um eine aktive Einhaltung von vertraglich vereinbarten Spezifikationen auf Dienstebene sicherzustellen, die eine einzelne Ressource innerhalb des Systems bereitstellen muss. Darüber hinaus stellt SDSi die Fähigkeit bereit, die vertraglichen Rechte (Titel), Nutzung und zugehörigen Finanzdaten eines oder mehrerer Mandanten auf Grundlage pro Komponente oder gar eines Merkmals auf Siliziumebene (z. B. von SKU-Merkmalen) zu verwalten. Merkmale auf Siliziumebene können mit Rechen-, Speicher- oder Netzwerkfähigkeiten, Leistung, Determinismus oder gar Merkmalen für Sicherheit, Verschlüsselung, Beschleunigung usw. assoziiert sein. Diese Fähigkeiten stellen nicht nur sicher, dass der Mandant einen spezifischen Leistungsvertrag erreichen kann, sondern helfen auch bei Verwaltung und Datensammlung und stellen die Transaktion und die vertragliche Vereinbarung auf der Ebene der niedrigsten verwaltbaren Komponente sicher.
-
In einer höheren Schicht in der Diensthierarchie enthalten Dienste auf Ressourcenebene Systeme und/oder Ressourcen, die (vollständig oder durch Zusammensetzung) die Fähigkeit bereitstellt, Anforderungen von Arbeitslasten entweder durch Erwerben und Aktivieren von Merkmalen auf Systemebene via SDSi oder durch die Zusammensetzung von individuell adressierbaren Ressourcen (Rechnen, Speicherung und Netzwerk) zu erfüllen. In noch einer höheren Schicht der Diensthierarchie sind Dienste auf Arbeitsablaufebene horizontal, da Dienstketten Anforderungen auf Arbeitsablaufebene aufweisen können. Arbeitsabläufe beschreiben Abhängigkeiten zwischen Arbeitslasten, um bestimmte Ziele und Anforderungen auf Dienstebene an den durchgängigen Dienst zu liefern. Diese Dienste können Merkmale und Funktionen wie hohe Verfügbarkeit, Redundanz, Wiederherstellung, Fehlertoleranz oder Lastenausgleich enthalten (wir können hier viel mehr aufnehmen). Arbeitsablaufdienste definieren Abhängigkeiten und Beziehungen zwischen Ressourcen und Systemen, beschreiben Anforderungen an zugehörige Netzwerke und Speicher sowie beschreiben Anforderungen auf Transaktionsebene und zugehörige Verträge, um den durchgängigen Dienst sicherzustellen. Dienste auf Arbeitsablaufebene werden üblicherweise in Zielen auf Dienstebene gemessen und weisen verpflichtende und erwartete Dienstanforderungen auf.
-
In noch einer höheren Schicht der Diensthierarchie sind funktionale Geschäftsdienste (BFS) betreibbar, und diese Dienste sind die unterschiedlichen Elemente des Diensts, die Beziehungen zueinander aufweisen und bestimmte Funktionen für den Kunden bereitstellen. Im Fall von Edge-Computing und innerhalb des Beispiels des autonomen Fahrens können Geschäftsfunktionen zum Beispiel den Dienst einer „zeitgerechten Ankunft bei einem Ereignis“ bilden - dieser Dienst würde erfordern, dass mehrere Geschäftsfunktionen zusammen und gemeinsam arbeiten, um das Ziel der Benutzerentität zu erreichen: GPS-Lenkung, Bewusstsein der RSU (der straßenseitigen Einheit) über lokale Verkehrsbedingungen, Bezahlungsverlauf der Benutzerentität, Autorisierung der Benutzerentität der Ressource(n) usw. Ferner, da diese BFS(s) mehreren Entitäten Dienste bereitstellen, verwaltet jeder BFS seinen eigenen SLA und ist sich seiner Fähigkeit bewusst, die Anforderungen an seine eigenen Ressourcen (Arbeitslast und Arbeitsablauf) zu handhaben. Wenn die Anforderungen und der Bedarf steigen, kommuniziert er die Anforderungen der Dienständerung an Arbeitsablaufentitäten und Dienstentitäten auf Ressourcenebene, damit diese wiederum Einsichten in ihre Fähigkeiten zur Erfüllung bereitstellen. Dieser Schritt unterstützt die Gesamttransaktions- und Dienstlieferung an die nächste Schicht.
-
In der höchsten Schicht von Diensten in der Diensthierarchie sind Dienste auf Geschäftsebene (BLS) mit der Fähigkeit verknüpft, die geliefert wird. Auf dieser Ebene ist es dem Kunden oder der Entität möglicherweise egal, wie der Dienst zusammengesetzt ist oder welche Bestandteile verwendet, verwaltet und/oder nachverfolgt werden, um den Dienst bzw. die Dienste bereitzustellen. Das primäre Ziel von Diensten auf Geschäftsebene ist, die Ziele, die vom Kunden festgelegt wurden, in Übereinstimmung mit den Gesamtvertragsbedingungen zu erreichen, die zwischen dem Kunden und dem Anbieter in der vereinbarten finanziellen Vereinbarung festgelegt wurden. BLS(s) bestehen aus mehreren funktionalen Geschäftsdiensten (BFS) und einem Gesamt-SLA.
-
Diese Anordnung und andere hierin beschriebene Dienstverwaltungsmerkmale sind ausgelegt, die verschiedenen Anforderungen von Edge-Computing mit seinen einzigartigen und komplexen Ressourcen- und Dienstinteraktionen zu erfüllen. Diese Dienstverwaltungsanordnung soll mehrere der grundlegenden Ressourcendienste innerhalb seines Frameworks behandeln, anstatt durch einen Agenten oder Middlewarefunktionen. Dienste, wie zum Beispiel: Auffinden, Suchen, Adressieren, Nachverfolgen, Verfolgen, Identifizieren und/oder Registrieren, können unmittelbar in Kraft gesetzt werden, wenn Ressourcen im Framework erscheinen, und der Verwalter oder Eigentümer der Ressourcendomäne kann Verwaltungsregeln und Richtlinien verwenden, um eine ordnungsgemäße Entdeckung, Registrierung und Zertifizierung von Ressourcen sicherzustellen.
-
Darüber hinaus kann eine beliebige Anzahl von hierin beschriebenen Edge-Computingarchitekturen mit Dienstverwaltungsmerkmalen angepasst werden. Diese Merkmale können einem System ermöglichen, sich fortlaufend der Bewegung, des Vektors und/oder der Richtung von Ressourcen bewusst zu sein und Informationen darüber aufzuzeichnen sowie diese Merkmale sowohl als Telemetrie als auch Metadaten, die mit diesen Vorrichtungen assoziiert sind, vollständig zu beschreiben. Diese Dienstverwaltungsmerkmale können zur Ressourcenverwaltung, Abrechnung und/oder Messung sowie als ein Element der Sicherheit verwendet werden. Die gleiche Funktionalität gilt auch für verwandte Ressourcen, wo eine weniger intelligente Vorrichtung, wie ein Sensor, an einer verwaltbareren Ressource, wie einem Edge-Gateway, angehängt sein könnte. Das Dienstverwaltungsframework wird über eine Änderung der Aufsicht oder Kapselung für Ressourcen benachrichtigt. Da Knoten und Komponenten direkt über eine übergeordnete oder alternative verantwortliche Vorrichtung für eine kurze Dauer oder für ihren gesamten Lebenszyklus zugänglich oder indirekt über diese verwaltet werden können, wird diese Art von Struktur über seine Schnittstelle an das Dienstframework weitergeleitet und externen Abfragemechanismen zur Verfügung gestellt.
-
Darüber hinaus ist dieses Dienstverwaltungsframework immer dienstbewusst und gleicht die Dienstbereitstellungsanforderungen mit der Fähigkeit und Verfügbarkeit der Ressourcen und den Zugriff für das Datenhochladen der Datenanalysesysteme natürlich aus. Falls die Netzwerktransporte degradieren, ausfallen oder zu einer Funktion mit höheren Kosten oder niedrigerer Bandbreite wechseln, stellen Dienstrichtlinienüberwachungsfunktionen alternative Analyse- und Dienstbereitstellungsmechanismen innerhalb der Datenschutz- oder Kostengrenzen des Benutzers bereit. Mit diesen Merkmalen können die Richtlinien den Aufruf von Analyse- und Dashboard-Diensten am Edge auslösen, wodurch eine fortlaufende Dienstverfügbarkeit mit reduzierter Genauigkeit oder Granularität sichergestellt wird. Sobald Netzwerktransporte wiederhergestellt sind, können normale Datensammlung, Hochladen und Analysedienste fortsetzen.
-
Der Einsatz eines Edge-Rechensystems mit mehreren Akteuren kann angeordnet und orchestriert werden, um den Einsatz mehrerer Dienste und virtueller Edge-Instanzen unter mehreren Edge-Plattformen und Teilsystemen zur Verwendung durch mehrere Mandanten und Dienstanbieter zu ermöglichen. In einem Systembeispiel, das auf einen Cloud-Dienstanbieter (CSP) anwendbar ist, kann der Einsatz eines Edge-Rechensystems über einen Ansatz „über die Spitze hinweg“ bereitgestellt werden, um Edge-Rechenplattformen als ein ergänzendes Werkzeug für Cloud-Computing einzuführen. In einem Vergleichsbeispiel, das auf einen Telekommunikations-Dienstanbieter (TSP) anwendbar ist, kann die Bereitstellung eines Edge-Rechensystems über einen „Netzwerk-Aggregations“-Ansatz bereitgestellt werden, um Edge-Rechenplattformen an Standorten einzuführen, an denen Netzwerkzugriffe (von verschiedenen Typen von Datenzugriffsnetzen) aggregiert sind. Dieser Ansatz über die Spitze hinweg und der Netzwerk-Aggregations-Ansatz können jedoch zusammen in einem Hybrid- oder zusammengefassten Ansatz oder einer solchen Konfiguration implementiert werden.
-
2 zeigt ein Implementierungsbeispiel einer Edge-Plattform 200, um von Client-Rechenknoten empfangene Arbeitslasten zu verarbeiten, nach den Lehren dieser Offenbarung. Beispielsweise können beliebige der Egde-Gatewayplattformen 112a, 112b, 112c; der Edge-Aggregationsplattformen 122a, 122b; der Fog-Plattform(en) 124; und/oder des Kern-Rechenzentrums 132 von der Edge-Plattform 300 implementiert sein. Die beispielhafte Edge-Plattform 200 von 2 enthält einen beispielhaften Orchestrator 202, eine beispielhafte Fähigkeitssteuerung 204, eine beispielhafte Telemetriesteuerung 206, eine beispielhafte Edge-Plattform(EP)-Datenbank 208 und (eine) beispielhafte Ressource(n) 210. Im Beispiel von 2 können beliebige des Orchestrators 202, der Fähigkeitssteuerung 204, der Telemetriesteuerung 206, der EP-Datenbank 208 und/oder der Ressource(n) 210 über einen beispielhaften Kommunikationsbus 212 kommunizieren. In hierin offenbarten Beispielen kann der Kommunikationsbus 212 unter Verwendung einer beliebigen geeigneten verdrahteten und/oder drahtlosen Kommunikation implementiert sein. In zusätzlichen oder alternativen Beispielen enthält der Kommunikationsbus 212 Software, maschinenlesbare Anweisungen und/oder Kommunikationsprotokolle, durch die Informationen unter dem Orchestrator 202, der Fähigkeitssteuerung 204, der Telemetriesteuerung 206, der EP-Datenbank 208 und/oder der bzw. den Ressource(n) 210 kommuniziert werden.
-
Im in 2 veranschaulichten Beispiel sind der Orchestrator 202, die Fähigkeitssteuerung 204, die Telemetriesteuerung 206, die EP-Datenbank 208 und die Ressource(n) 210 in der Edge-Plattform 200 enthalten, entsprechen dieser und/oder sind anderweitig für diese repräsentativ. In einigen Beispielen kann bzw. können jedoch eines oder mehrere des Orchestrators 202, der Fähigkeitssteuerung 204, der Telemetriesteuerung 206, der EP-Datenbank 208 und der Ressource(n) 210 in einer Edge-Umgebung enthalten sein, die die Edge-Plattform 200 (z. B. die Edge-Cloud 110) enthält, anstatt in der Edge-Plattform 200 enthalten zu sein. Der Orchestrator 202 kann zum Beispiel mit einer Endpunktschicht (z. B. der Endpunktschicht 120), einer Edgevorrichtungsschicht (z. B. der Edgevorrichtungsschicht 130), einer Netzwerkzugriffsschicht (z. B. der Netzwerkzugriffsschicht 140), einer Kernnetzschicht (z. B. der Kernnetzschicht 150) und/oder einer Cloud-Rechenzentrumsschicht (z. B. der Cloud-Rechenzentrumsschicht 160) verbunden sein, während er sich außerhalb der Edge-Plattform 200 befindet.
-
In anderen Beispielen ist/sind eines oder mehrere vom Orchestrator 202, der Fähigkeitssteuerung 204, der Telemetriesteuerung 206, der EP-Datenbank 208 und der Ressource(n) 210 separate Vorrichtungen, die in einer Edge-Umgebung enthalten sind. Ferner können eines oder mehrere vom Orchestrator 202, der Fähigkeitssteuerung 204, der Telemetriesteuerung 206, der EP-Datenbank 208 und der Ressource(n) 210 in einer Edgevorrichtungsschicht (z. B. der Edgevorrichtungsschicht 130), einer Netzwerkzugriffsschicht (z. B. der Netzwerkzugriffsschicht 140), einer Kernnetzschicht (z. B. der Kernnetzschicht 150) und/oder einer Cloud-Rechenzentrumsschicht (z. B. der Cloud-Rechenzentrumsschicht 160) enthalten sein. Der Orchestrator 202 kann zum Beispiel in einer Edgevorrichtungsschicht (z. B. der Edgevorrichtungsschicht 130) enthalten sein, oder die Ressource(n) 210 können in einer einer Netzwerkzugriffsschicht (z. B. der Netzwerkzugriffsschicht 140), einer Kernnetzschicht (z. B. der Kernnetzschicht 150) und/oder einer Cloud-Rechenzentrumsschicht (z. B. der Cloud-Rechenzentrumsschicht 160) enthalten sein.
-
In einigen Beispielen, als Reaktion auf eine Anforderung, eine Arbeitslast von einer Client-Rechenplattform (z. B. einer der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f) auszuführen, kommuniziert der Orchestrator 202 mit mindestens einer der Ressource(n) 210 und der Client-Rechenplattform (z. B. einer der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f), um einen Vertrag (z. B. einen Arbeitslastvertrag) zu erstellen, der mit einer Beschreibung der auszuführenden Arbeitslast assoziiert ist. Die Client-Rechenplattform (z. B. eine der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f) stellt dem Orchestrator 202 eine Aufgabe bereit, die mit dem Vertrag und der Beschreibung der Arbeitslast assoziiert ist, und der Orchestrator 202 plant die auf der Edge-Plattform auszuführende Aufgabe. Die Aufgabe kann den Vertrag und die Beschreibung der auszuführenden Arbeitslast enthalten. In einigen Beispielen enthält die Aufgabe Anforderungen, Ressourcen, die zum Ausführen der Arbeitslast verwendet werden, zu beschaffen und/oder anderweitig zuzuweisen.
-
In einigen Beispielen pflegt der Orchestrator 202 Datensätze und/oder Protokolle von Handlungen, die in einer Endpunktschicht (z. B. der Endpunktschicht 120), einer Edgevorrichtungsschicht (z. B. der Edgevorrichtungsschicht 130), einer Netzwerkzugriffsschicht (z. B. der Netzwerkzugriffsschicht 140), einer Kernnetzschicht (z. B. der Kernnetzschicht 150) und/oder einer Cloud-Rechenzentrumsschicht (z. B. der Cloud-Rechenzentrumsschicht 160) einer Edge-Umgebung auftreten. Die Ressource(n) 210 kann bzw. können zum Beispiel dem Orchestrator 202 einen Empfang einer Arbeitslastbeschreibung melden. Der Orchestrator 202 und/oder die Ressource(n) 210 stellt bzw. stellen dem Orchestrator 202 Aufzeichnungen von Handlungen und/oder Ressourcenzuweisungen bereit. Der Orchestrator 202 pflegt und/oder speichert beispielsweise eine Aufzeichnung eines Empfangs einer Anforderung zum Ausführen einer Arbeitslast (z. B. eine von einer der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f bereitgestellte Vertragsanforderung).
-
In einigen Beispielen greift der Orchestrator 202 auf eine Aufgabe zu und stellt die Aufgabe einer oder mehreren der Ressource(n) 210 zur Ausführung oder zum Abschluss bereit und/oder ordnet diese zu. Die Ressource(n) 210 führt bzw. führen eine Arbeitslast auf Grundlage einer Beschreibung der Arbeitslast aus, die in der Aufgabe enthalten ist.
-
Im Beispiel von 2 setzt der Orchestrator 202 eine abgestufte Meta-Orchestrierungsarchitektur auf Grundlage einer globalen Orchestrierung und einer lokalen adaptiven Orchestrierung ein, um energiethermal-bewusste dynamisch adaptive Funktionalität zu implementieren. Der Orchestrator 202 ist ausgelegt, den Energieverbrauch und die Nutzung des Orchestrators 202 (z. B. jeweiligen der Ressource(n) 210, die dem Orchestrator 202 zugewiesen sind) zu kalibrieren und eine Orchestrierung auf Grundlage von verfügbarer oder vorhergesagter Energie, thermalen und/oder Ressourceneinstellungen (z. B. Budgets) anzupassen. Der Orchestrator 202 kann zum Beispiel Konfigurationseinstellungen für jeweilige der Ressource(n) 210, die dem Orchestrator 202 zugewiesen sind, von einer Client-Rechenplattform mit einer Arbeitslast empfangen. Der Orchestrator 202 ist ausgelegt, eine Überwachungsfrequenz und/oder ein Planen von Überwachungsdatensammlungen anzupassen, um den Ressourcenverbrauch 210 durch den Orchestrator 202 (z. B. von Orchestrierungskomponenten) zu verwalten, sodass sie SLA-Ziele einhalten, während Aufgaben effizient orchestriert werden. Der Orchestrator 202 kann zum Beispiel die Frequenz der Überwachung von Telemetriedaten auf Grundlage einer Priorität (z. B. einer Prioritätsstufe) anpassen, die mit Ressourcen (z. B. der bzw. den Ressource(n) 210) auf einer Edge-Plattform (z. B. der Edge-Plattform 200) assoziiert ist. In einigen Beispielen kann der Orchestrator 202 Ressourcen auf einer Edge-Plattform in Gruppen kategorisieren. Eine erste Gruppe von Ressourcen kann zum Beispiel oberste Priorität haben, wobei der Orchestrator 202 eine Telemetrieüberwachungsfrequenz, die mit jeweiligen der Ressourcen der ersten Gruppe assoziiert ist, geringfügig anpassen (z. B. reduzieren) kann, eine zweite Gruppe kann zum Beispiel mittlere Priorität haben, wobei der Orchestrator 202 eine Telemetrieüberwachungsfrequenz, die mit jeweiligen der Ressourcen der zweiten Gruppe assoziiert ist, anpassen (z. B. reduzieren) kann, und eine dritte Gruppe kann zum Beispiel niedrige Priorität haben, wobei der Orchestrator 202 eine Telemetrieüberwachungsfrequenz, die mit jeweiligen der Ressourcen der dritten Gruppe assoziiert ist, anhalten kann.
-
Im in 2 veranschaulichten Beispiel ist der Orchestrator 202 ausgelegt, den rechnerischen Aufwand anzupassen, der vom Orchestrator 202 (z. B. Orchestrierungskomponenten) beim Verarbeiten von Telemetriedaten eingesetzt wird (z. B. die rechnerische Last, die damit assoziiert ist). Wenn zum Beispiel hinreichende der Ressource(n) 210 verfügbar sind, kann der Orchestrator 202 eine feinere Analyse ausführen, einschließlich einer Simulation, um eine Ausrichtung an Dienstqualitätsziele zu verbessern. Wenn andererseits Energie und/oder die Ressource(n) 210 knapp sind, kann der Orchestrator 202 die rechnerische Last, die mit Orchestrierungsaufgaben assoziiert ist, durch Einsetzen einer Anschnitts- und/oder oberflächlichen Analyse (z. B. durch Einsetzen eines Roofline-Modells) reduzieren.
-
Im Beispiel von 2, wenn die Energie und/oder andere der Ressource(n) 210 einen ersten Schwellenpegel von Ressourcen, die der Orchestrierung zuzuweisen sind, erreichen und/oder überschreiten, kann der Orchestrator 202 Orchestrierungsaufgaben an einen anderen Computer auslagern, um grobe Orchestrierungsergebnisse zu erhalten. In diesem Fall kann der Orchestrator 202 vom anderen Computer Planungshandlungen empfangen, die beschreiben, was Betriebszustandsdienste und/oder Arbeitslasten, die der Edge-Plattform 200 zugeordnet sind, in der Zukunft und/oder der nahen Zukunft erfordern würden. Die groben Orchestrierungsergebnisse stellen dem Orchestrator 202 Anweisungen bereit, die die rechnerische Belastung reduzieren, die mit dem Verarbeiten von Orchestrierungsaufgaben am Orchestrator 202 assoziiert ist, während dem Orchestrator 202 ermöglicht wird, feinere Orchestrierungsentscheidungen auf der Edge-Plattform 200 zu treffen.
-
Zusätzlich oder alternativ, wenn die Energie und/oder andere der Ressource(n) 210 einen zweiten Schwellenpegel von Ressourcen, die der Orchestrierung zuzuweisen sind, erreichen und/oder überschreiten, kann der Orchestrator 202 Orchestrierungsaufgaben an einen anderen Computer auslagern, um feine Orchestrierungsergebnisse zu erhalten. In diesem Beispiel setzt der Orchestrator 202 Hardwarebeschleuniger ein, falls in der bzw. den Ressource(n) 210 verfügbar, um die Menge an Telemetriedaten zu reduzieren, die an einen entfernten Computer zu senden sind (z. B. unter Einsatz statistischer Verfahren, wie Markov-Ketten), und sendet Planungsaufgaben an die entfernte Vorrichtung. Die entfernte Vorrichtung könnte zum Beispiel eine Edge-Plattform in derselben Schicht einer Edge-Umgebung wie die Edge-Plattform 200 sein, die sich auf einem höheren Energiepegel wie die Edge-Plattform 200 befindet. In einigen anderen Beispielen könnte die entfernte Vorrichtung eine Edge-Plattform in einer Schicht einer Edge-Umgebung sein, die geografisch weiter als die Edge-Plattform 200 von einer Client-Rechenplattform entfernt ist.
-
Im Beispiel von 2, falls der Orchestrator 202 Telemetriedaten und/oder Planungsaufgaben von einer entfernten Vorrichtung empfängt, orchestriert und/oder plant der Orchestrator 202 Arbeitslasten an der entfernten Vorrichtung auf einem gröberen Niveau als die entfernte Vorrichtung (z. B. eine Orchestrierung „höherer Ordnung“). Falls der Orchestrator 202 zum Beispiel Telemetriedaten und/oder Planungsaufgaben von einer entfernten Vorrichtung empfängt, kann der Orchestrator 202 allgemein sehr leicht in Bezug auf Energieverbrauch sein und beim Verarbeiten von Telemetriedaten und/oder Planen von Aufgaben einfachere Formen der Telemetrieextrahierung oder Orchestrierungsanleitung erzeugen. Darüber hinaus kann sich der Orchestrator 202 in stabileren Energieumgebungen im Vergleich zur entfernten Vorrichtung befinden, die Telemetriedaten und/oder Planungsaufgaben an die entfernte Vorrichtung gesendet hat. Die entfernte Vorrichtung könnte zum Beispiel eine Edge-Plattform in derselben Schicht einer Edge-Umgebung wie die Edge-Plattform 200 sein, die sich auf einem niedrigeren Energiepegel wie die Edge-Plattform 200 befindet. In zusätzlichen oder alternativen Beispielen könnte die entfernte Vorrichtung eine Edge-Plattform in einer Schicht einer Edge-Umgebung sein, die geografisch näher als die Edge-Plattform 200 an einer Client-Rechenplattform liegt. Die entfernte Vorrichtung (z. B. eine globale Vorrichtung) kann zum Beispiel eine delegierte Orchestrierung und/oder Telemetrieverarbeitung von der Edge-Plattform 200 (z. B. einer lokalen Vorrichtung) erhalten, wenn sich die Edge-Plattform 200 in einem Energie-, thermalen und/oder Ressourcenzustand befindet, der sich für einen reduzierten Verbrauch von Energie, thermalen und/oder Ressourcen durch Orchestrierungskomponenten anbietet.
-
In einigen Beispielen implementiert der beispielhafte Orchestrator 202 beispielhafte Mittel zum Orchestrieren. Das Orchestrierungsmittel ist durch ausführbare Anweisungen implementiert, wie zum Beispiel die durch zumindest Blöcke 402, 404, 406, 408, 410, 412, 414, 416, 418, 420, 422, 424 und 426 von 4 veranschaulichten und/oder die zumindest Blöcke 502, 504, 506, 508, 510 und 512 von 5 veranschaulichten und/oder die zumindest Blöcke 602, 604, 606, 608, 610, 612, 614, 616 und 618 von 6 veranschaulichten und/oder die zumindest Blöcke 702, 704, 706, 708, 710, 712, 714, 714, 716 und 718 von 7 veranschaulichten und/oder die zumindest Blöcke 802, 804, 806, 808, 810, 812, 814, 816, 818, 820 und 822 von 8 veranschaulichten und/oder die zumindest Blöcke 902, 904, 906, 908, 910, 912, 914, 916, 918, 920, 922 und 924 von 9 veranschaulichten, die auf mindestens einem Prozessor, wie dem beispielhaften Prozessor 1012, der im Beispiel von 10 gezeigt ist, ausgeführt werden können. In anderen Beispielen ist das Orchestrierungsmittel durch Hardwarelogik, hardwareimplementierte Zustandsmaschinen, Logikverschaltung und/oder eine beliebige andere Kombination von Hardware, Software und/oder Firmware implementiert.
-
Vorteilhafterweise reduziert eine Ausführung einer Arbeitslast auf der Edge-Plattform 200 Kosten (z. B. Rechen- oder Rechnerkosten, Netzwerkkosten, Speicherkosten usw. und/oder eine Kombination daraus) und/oder eine Verarbeitungszeit, die verwendet wird, um die Arbeitslast auszuführen. Eine der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f kann zum Beispiel anfordern, dass die Edge-Plattform 200 eine Arbeitslast mit einem ersten Aufwand ausführt, der niedriger als ein zweiter Aufwand ist, der mit einem Ausführen der Arbeitslast in der Cloud-Rechenzentrumsschicht 160 assoziiert ist. In anderen Beispielen kann eine Endpunktvorrichtung, wie eine der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f näher (z. B. räumlich oder geografisch näher) und/oder anderweitig nahe an einer Edge-Plattform sein, wie der Edge-Plattform 200, als ein zentralisierter Server (z. B. die globale Netzwerkcloud 142) in der Cloud-Rechenzentrumsschicht 160. Die Edge-Plattform 200 ist zum Beispiel räumlich näher an einer der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f als die globale Netzwerkcloud 142. Als Ergebnis können beliebige der Client-Rechenplattformen 102a, 102b, 102c, 102d, 102e, 102f anfordern, dass die Edge-Plattform 200 eine Arbeitslast ausführt, und die Antwortzeit der Edge-Plattform 200, um das ausgeführte Arbeitslastergebnis zu liefern, ist niedriger als die, die von der globalen Netzwerkcloud 142 in der Cloud-Rechenzentrumsschicht 160 bereitgestellt werden kann.
-
Im veranschaulichten Beispiel von 2 ermittelt die Fähigkeitssteuerung 204 die Fähigkeiten der Edge-Plattform 200 während einer Registrierung und Eingliederung der Edge-Plattform 200. Die Fähigkeitssteuerung 204 generiert zum Beispiel Fähigkeitsdaten (z. B. Hardwareressourcen, Speicherressourcen, Netzwerkressourcen, Softwareressourcen usw. auf der Edge-Plattform 200). Die Fähigkeitssteuerung 204 kann zum Beispiel die Ressource(n) 210 ermitteln, die der Edge-Plattform 200 zugewiesen sind, wie zum Beispiel Hardwareressourcen (z. B. Rechen-, Netzwerk-, Sicherheits-, Speicher- usw. Hardwareressourcen), Softwareressourcen (z. B. eine Firewall, eine Lastenausgleichseinheit, eine virtuelle Maschine (VM), ein Gastbetriebssystem (OS), eine Anwendung, einen Hypervisor usw.) usw. und/oder eine Kombination daraus, auf Grundlage der Fähigkeitsdaten, auf denen Edge-Rechenarbeitslasten (z. B. registrierte Arbeitslasten) ausgeführt werden können. In einigen Beispielen kann die Fähigkeitssteuerung 204 Container ermitteln, die auf der Edge-Plattform 200 bereitgestellt sind und/oder ausgeführt werden. Die Fähigkeitssteuerung 204 kann zum Beispiel Mikrodienste identifizieren, die mit Containern assoziiert sind, die auf der Edge-Plattform 200 bereitgestellt sind, und/oder Ressourcen, die Containern auf der Edge-Plattform 200 zugewiesen sind.
-
In einigen Beispielen ruft die Fähigkeitssteuerung 204 die Fähigkeitsdaten aus der EP-Datenbank 208 ab. Wenn der Orchestrator 202 zum Beispiel eine Anforderung zum Ausführen einer Arbeitslast empfängt, identifiziert der Orchestrator 202 durch Zugreifen auf die Fähigkeitssteuerung 204 und/oder die EP-Datenbank 208, ob die Fähigkeiten der Edge-Plattform 200 (eine) angemessene Ressource(n) enthält, um die Arbeitslastaufgabe zu erfüllen. Falls der Orchestrator 202 zum Beispiel eine Anforderung empfängt, eine Arbeitslast auszuführen, die einen Prozessor mit zwei Kernen erfordert, kann der Orchestrator 202 auf die Fähigkeitssteuerung 204 und/oder die EP-Datenbank 208 zugreifen, um zu ermitteln, ob die Edge-Plattform 200 die Fähigkeit zum Verarbeiten der angeforderten Arbeitslast enthält.
-
Im Beispiel von 2 ermittelt die Fähigkeitssteuerung 204 zusätzlich die Fähigkeiten von neuen und/oder zusätzlichen Ressourcen, die der Edge-Plattform 200 zugewiesen sind. Falls die Edge-Plattform 200 zum Beispiel durch einen Edge-Dienstanbieter hochgerüstet wird, um zusätzliche Rechenressourcen, Speicherressourcen und/oder Netzwerkressourcen aufzunehmen, kann die Fähigkeitssteuerung 204 die zusätzlichen Ressourcen registrieren und Fähigkeitsdaten generieren, die mit den zusätzlichen Ressourcen assoziiert sind. In einigen Beispielen kann die Fähigkeitssteuerung 204 Protokolle generieren und/oder senden, um an Ressourcen (z. B. die bzw. den Ressource(n) 210) auf der Edge-Plattform 200 an eines oder mehrere vom Orchestrator 202, der Telemetriesteuerung 206 und/oder der EP-Datenbank 208 über Schnittstellen anzubinden.
-
Im veranschaulichten Beispiel von 2 verbessert die Telemetriesteuerung 206 die Verteilung und Ausführung von Edge-Computing-Arbeitslasten (z. B. unter Edge-Plattformen) auf Grundlage von Telemetriedaten, die mit Edge-Plattformen in einer Edge-Computing-Umgebung assoziiert sind. Die Telemetriesteuerung 206 kann zum Beispiel ermitteln, dass eine erste Edge-Plattform und/oder eine zweite Edge-Plattform eine bzw. einige der Ressource(n) 210 verfügbar aufweist, wie zum Beispiel Hardwareressourcen (z. B. Rechen-, Netzwerk-, Sicherheits-, Speicher- usw. (z. B. nichtflüchtigen Arbeitsspeicher-Express) Hardwareressourcen), Softwareressourcen (z. B. eine Firewall, eine Lastenausgleichseinheit, eine virtuelle Maschine (VM), ein Gastbetriebssystem (OS), eine Anwendung, einen Hypervisor usw.) usw. und/oder eine Kombination daraus, auf Grundlage der Telemetriedaten, auf denen Edge-Computing-Arbeitslasten ausgeführt werden können. In derartigen Beispielen können die Telemetriedaten eine Nutzung (z. B. einen Prozentsatz einer Ressource, der genutzt oder nicht genutzt wird), eine Verzögerung (z. B. eine durchschnittliche Verzögerung) beim Empfangen eines Diensts (z. B. Latenz), eine Rate (z. B. eine durchschnittliche Rate), mit der eine Ressource verfügbar ist (z. B. Bandbreite, Durchsatz usw.), Energieverbrauch, Temperaturen usw. enthalten, die mit einer der bzw. einigen der Ressource(n) 210 mindestens einer der Edge-Plattformen assoziiert sind (z. B. der Edge-Plattform 200 und/oder einer alternativen Edge-Plattform).
-
Im veranschaulichten Beispiel von 2 enthält die Edge-Plattform 200 die EP-Datenbank 208 zum Aufzeichnen von Daten (z. B. Telemetriedaten, Arbeitslasten, Fähigkeitsdaten usw.). Die EP-Datenbank 208 kann durch einen flüchtigen Arbeitsspeicher (z. B. einen synchronen dynamischen Arbeitsspeicher mit wahlfreiem Zugriff (SDRAM), einen dynamischen Arbeitsspeicher mit wahlfreiem Zugriff (DRAM), einen dynamischen RAMBUS-Arbeitsspeicher mit wahlfreiem Zugriff (RDRAM) usw.) und/oder einen nichtflüchtigen Arbeitsspeicher (z. B. Flashspeicher) implementiert sein. Die EP-Datenbank 208 kann zusätzlich oder alternativ durch einen oder mehrere Arbeitsspeicher mit doppelter Datenrate, wie DDR, DDR2, DDR3, DDR4, mobilen DDR (mDDR) usw. implementiert sein. Die EP-Datenbank 208 kann zusätzlich oder alternativ durch eine oder mehrere Massenspeichervorrichtungen, wie (ein) Festplattenlaufwerk(e), Compact-Disc-Laufwerk(e), Digital-Versatile-Disk-Laufwerk(e), Festkörperlaufwerk(e) usw. implementiert sein. Während die EP-Datenbank 208 im veranschaulichten Beispiel als eine einzelne Datenbank veranschaulicht ist, kann die EP-Datenbank 208 durch eine beliebige Anzahl und/oder einen beliebigen Typ von Datenbanken implementiert sein. Ferner können die in der EP-Datenbank 208 gespeicherten Daten in einem beliebigen Datenformat, wie zum Beispiel binären Daten, durch Kommata getrennte Daten, durch Tabulatoren getrennte Daten, Structured-Query-Language(SQL)-Strukturen usw. sein.
-
Im illustrierten Beispiel von 2 wird bzw. werden die Ressource(n) 210 aufgerufen, um eine Arbeitslast (z. B. eine Edge-Rechenarbeitslast) auszuführen, die von einer Client-Rechenplattform erhalten wurde. Beispielsweise kann bzw. können die Ressource(n) 210 einer Edge-Plattform oder (einem) Abschnitt(en) davon entsprechen und/oder anderweitig dafür repräsentativ sein. Der Orchestrator 202, die Fähigkeitssteuerung 204, die Telemetriesteuerung 206, die EP-Datenbank 208 und/oder allgemeiner die Edge-Plattform 200 kann bzw. können eine jeweilige der Ressource(n) 210 aufrufen, um eine oder mehrere Edge-Rechenarbeitslasten auszuführen.
-
In einigen Beispielen ist bzw. sind die Ressource(n) 210 für Hardwareressourcen, Virtualisierungen der Hardwareressourcen, Softwareressourcen, Virtualisierungen der Softwareressourcen usw. und/oder einer Kombination davon repräsentativ. Die Ressource(n) 210 können zum Beispiel eine oder mehrere CPUs (z. B. Mehrkern-CPUs), eine oder mehrere FPGAs, eine oder mehrere GPUs, eine oder mehrere Netzwerkschnittstellenkarten (NICs), eine oder mehrere Bildverarbeitungseinheiten (VPUs) usw. und/oder einen beliebigen anderen Typ von Hardware oder Hardwarebeschleuniger enthalten, einem derartigen entsprechen und/oder anderweitig für eine bzw. einen solchen repräsentativ sein. In derartigen Beispielen kann bzw. können die Ressource(n) 210 einer Virtualisierung bzw. Virtualisierungen der einen oder mehreren CPUs, des einen oder mehreren FPGAs, der einen oder mehreren GPUs, der einen oder mehreren NICs usw. enthalten, entsprechen und/oder anderweitig für diese repräsentativ sein. In anderen Beispielen kann bzw. können der Orchestrator 202, die Fähigkeitssteuerung 204, die Telemetriesteuerung 206, die EP-Datenbank 208, die Ressource(n) 210 und/oder allgemeiner die Edge-Plattform 200 eine oder mehrere Softwareressourcen, Virtualisierungen der Softwareressourcen usw., wie Hypervisors, Lastenausgleichseinheiten, OSes, VMs usw. und/oder eine Kombination daraus enthalten, dieser bzw. diesen entsprechen und/oder anderweitig dafür repräsentativ sein.
-
3 zeigt ein Implementierungsbeispiel des Orchestrators 202 von 2, um eine Verarbeitung von Telemetriedaten auf einer Edge-Plattform auf Grundlage von Ressourcenverfügbarkeit zu steuern. Der beispielhafte Orchestrator 202 enthält eine beispielhafte Orchestratorschnittstelle 302, eine beispielhafte Ressourcenverwaltungssteuerung 304, einen beispielhaften Arbeitslastenplaner 306, eine beispielhafte thermale Steuerung 308 und eine beispielhafte Orchestrierungsdatenbank 310. Im Beispiel von 3 können beliebige der Orchestratorschnittstelle 302, der Ressourcenverwaltungssteuerung 304, des Arbeitslastenplaners 306, der thermalen Steuerung 308 und/oder der Orchestrierungsdatenbank 310 über einen beispielhaften Kommunikationsbus 312 kommunizieren. In hierin offenbarten Beispielen kann der Kommunikationsbus 312 unter Verwendung einer beliebigen geeigneten verdrahteten und/oder drahtlosen Kommunikation implementiert sein. In zusätzlichen oder alternativen Beispielen enthält der Kommunikationsbus 312 Software, maschinenlesbare Anweisungen und/oder Kommunikationsprotokolle, durch die Informationen unter der Orchestratorschnittstelle 302, der Ressourcenverwaltungssteuerung 304, dem Arbeitslastenplaner 306, der thermalen Steuerung 308 und/oder der Orchestrierungsdatenbank 310 kommuniziert werden.
-
Im Beispiel von 3 ermöglicht der Orchestrator 202 eine N-stufige Meta-Orchestrierungsarchitektur (z. B. eine Orchestrierung einer Orchestrierung), wobei N größer als oder gleich zwei ist. Der Orchestrator 202 kann beispielsweise in einer lokalen Konfiguration arbeiten, in der der Orchestrator 202 Operationen lokal auf der Edge-Plattform 200 orchestriert und/oder plant. In zusätzlichen oder alternativen Beispielen kann der Orchestrator 202 in einer globalen Konfiguration arbeiten, in der der Orchestrator 202 Telemetriedaten von einer entfernten Edge-Plattform verarbeitet, um Operationen zu orchestrieren und/oder planen, die auf der entfernten Edge-Plattform auszuführen sind.
-
Im illustrierten Beispiel von 3 enthält der Orchestrator 202 die Orchestratorschnittstelle 302. Allgemein steuert die Orchestratorschnittstelle 302 eine Kommunikation (z. B. mit Orchestrierung verbundene Kommunikationen) mit der Edge-Plattform 200 und/oder entfernten Edge-Plattformen (z. B. Near-Edge-Plattformen in Bezug auf die Edge-Plattform 200, eine einer nächsten Stufe usw.). Eine Kommunikation zwischen Stufen in der Meta-Orchestrierungsarchitektur kann bei Bedarf über sichere Kanäle ermöglicht werden und kann lose an den Orchestrator 202 gekoppelt sein (z. B. Band-externe Verfahren und Schnittstellen). Der Kommunikationskanal zwischen Meta-Orchestrierungsstufen kann zum Beispiel durch durchgehende Verschlüsselung verschlüsselt sein. In einigen Beispielen kann der sichere Kommunikationskanal hierarchisch sein (z. B. unter Verwendung von signierten Daten), sodass Änderungen an auf dem sicheren Kanal gesendeten Daten leicht erkannt werden können. In zusätzlichen oder alternativen Beispielen kann der sichere Kanal unter Verwendung hardwarebasierter Sicherheit gesichert werden. In einigen Beispielen kann der sichere Kanal JavaScript-Object-Notation-Dateiformate, Webtoken und/oder andere Dateistrukturen einsetzen, die eine Verschlüsselung ermöglichen.
-
Die Orchestratorschnittstelle 302 ist ausgelegt, zu ermitteln, ob die Edge-Plattform 200 Telemetriedaten von einer entfernten Edge-Plattform empfangen hat. Die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 kann Telemetriedaten von einer Edge-Plattform empfangen, die geografisch näher an einer Client-Rechenplattform als die Edge-Plattform 200 liegt. Als Reaktion auf ein Ermitteln, dass die Edge-Plattform 200 Telemetriedaten von einer entfernten Edge-Plattform empfangen hat, sendet die Orchestratorschnittstelle 302 die Telemetriedaten und/oder etwaige zusätzliche Daten (z. B. einen Hinweis auf die Granularität, Konfigurationseinstellungen für einen entfernten Edge-Plattform-Orchestrator usw.) an die Ressourcenverwaltungssteuerung 304.
-
Im Beispiel von 3, nachdem die Ressourcenverwaltungssteuerung 304 Ressourcen der entfernten Edge-Plattform abschätzt, die jeder Arbeitslast zuzuweisen sind, um die entsprechenden SLAs der Arbeitslasten zu erfüllen, ermittelt die Orchestratorschnittstelle 302, ob die Telemetriedaten anzeigen, dass grobe Orchestrierungsergebnisse zu generieren sind, oder ob die Telemetriedaten anzeigen, dass feine Orchestrierungsergebnisse zu generieren sind. Falls die Orchestratorschnittstelle 302 ermittelt, dass feine Orchestrierungsergebnisse vom Orchestrator der entfernten Edge-Plattform angefordert sind, kann die Orchestratorschnittstelle 302 der Ressourcenverwaltungssteuerung 304 und/oder dem Arbeitslastenplaner 306 anzeigen, dass feine Orchestrierungsergebnisse zu ermitteln sind und/oder Arbeitslasten zur Ausführung auf der entfernten Edge-Plattform zu planen sind. Die Orchestratorschnittstelle 302 ist zusätzlich ausgelegt, grobe Orchestrierungsergebnisse, feine Orchestrierungsergebnisse, einen Plan von Arbeitslasten und/oder Telemetriedaten an/von einer entfernten Edge-Plattform und/oder einem anderen Computer zu senden und/oder zu empfangen. In einigen Beispielen kann die Orchestratorschnittstelle 302 über eine Schnittstelle an die Fähigkeitssteuerung 204 ankoppeln, um die Fähigkeiten der Edge-Plattform 200 zu ermitteln.
-
Im Beispiel von 3, kann ein Orchestrator auf einer Edge-Plattform durch Auslagern (z. B. Übergeben) von Telemetriedaten, die auf einer entfernten Edge-Plattform und/oder einem anderen Computer zu verarbeiten sind, effizientere Orchestrierungsergebnisse bei reduzierter Energie und/oder Ressourcenkapazität erzielen. Eine entfernte Edge-Plattform (z. B. eine Near-Edge-Plattform) und/oder ein anderer Computer kann bzw. können zum Beispiel einen größeren Verlauf von Betriebszuständen auf der Edge-Plattform, die die Telemetriedaten ausgelagert hat, sowie die Betriebszustände auf anderen Edge-Plattformen enthalten. Als solche kann bzw. können die entfernte Edge-Plattform (z. B. eine Near-Edge-Plattform) und/oder ein anderer Computer zwischen Planen einer Arbeitslast auf der Edge-Plattform, die die Telemetriedaten ausgelagert hat, und auf anderen Edge-Plattformen vergleichen.
-
In einigen Beispielen implementiert die beispielhafte Orchestratorschnittstelle 302 beispielhafte Mittel zum Anbinden über Schnittstellen. Das Schnittstellenmittel ist durch ausführbare Anweisungen implementiert, wie zum Beispiel die durch zumindest Blöcke 402 und 406 von 4 veranschaulichten und/oder die zumindest Blöcke 504, 506 und 512 von 5 veranschaulichten und/oder die zumindest Blöcke 704, 706 und 708 von 7 veranschaulichten und/oder die zumindest Blöcke 802, 806, 808, 810, 816, 818 und 820 von 8 veranschaulichten und/oder die zumindest Block 904 von 9 veranschaulichten, die auf mindestens einem Prozessor, wie dem beispielhaften Prozessor 1012, der im Beispiel von 10 gezeigt ist, ausgeführt werden können. In anderen Beispielen ist das Orchestrierungsmittel durch Hardwarelogik, hardwareimplementierte Zustandsmaschinen, Logikverschaltung und/oder eine beliebige andere Kombination von Hardware, Software und/oder Firmware implementiert.
-
Im illustrierten Beispiel von 3 enthält der Orchestrator 202 die Ressourcenverwaltungssteuerung 304. Die Ressourcenverwaltungssteuerung 304 ist ausgelegt, einen Ressourcenverbrauch von Ressource(n) 210 durch Orchestrierungskomponenten (z. B. die Orchestrierungsschnittstelle 302, die Ressourcenverwaltungssteuerung 304, den Arbeitslastenplaner 306 und/oder die Orchestrierungsdatenbank 310) und/oder andere Komponenten der Edge-Plattform 200 (z. B. der Fähigkeitssteuerung 204, der Telemetriesteuerung 206, der EP-Datenbank 208 und/oder der Ressource(n) 210) zu verwalten. Im Allgemeinen überwacht die Ressourcenverwaltungssteuerung 304 die Verwendung von Energie und/oder verschiedener anderer Ressourcen durch Orchestrierungskomponenten und/oder andere Komponenten einer Edge-Plattform. Abhängig von der Ressourcenmenge, die auf der Edge-Plattform verfügbar ist, und der jeweils geschätzten oder versprochenen Menge für die Arbeitslasten, die auf der Edge-Plattform ausgeführt werden, kann die Ressourcenverwaltungssteuerung 304 die Arbeit für Telemetrie und Orchestrierung erhöhen, senken oder an eine nächste Near-Edge-Stufe übertragen.
-
In einigen Beispielen führt die Ressourcenverwaltungssteuerung 304 Software und/oder Firmware und/oder einen oder mehrere Bitstromkernels aus, um eine Verwaltung von Ressourcenverbrauch auf der Edge-Plattform 200 zu ermöglichen. In einigen Beispielen führt die Ressourcenverwaltungssteuerung 304 Software und/oder Firmware ohne Ausführen von Bitstromkernels und/oder anderen Rechenkernels aus. In einigen Beispielen führt die Ressourcenverwaltungssteuerung 304 Rechenkernels ohne Ausführen von Software und/oder Firmware aus (z. B. einigem oder keinem Fußabdruck von Software, die auf einem Universalprozessor oder Spezialprozessor (z. B. einer CPU, einem Xeon-Prozessor von Intel usw.) läuft).
-
In einigen Beispielen führt die Ressourcenverwaltungssteuerung 304 Software und/oder Firmware auf anderen rechenfähigen Plattformen aus, wie Smart-NICs, Platinenverwaltungssteuerungen (BMCs) usw. Im Allgemeinen regelt die Ressourcenverwaltungssteuerung 304 lokale Orchestrierungsmechanismen auf der Edge-Plattform 200 und kann eine Beschleunigung einsetzen, wenn diese verfügbar ist (z. B. wenn eine Edge-Plattform Beschleuniger enthält), um Orchestrierungsaufgaben zu verarbeiten.
-
Um die Ressourcen auf einer Edge-Plattform zu verwalten (z. B. der Edge-Plattform 200), fordert die Ressourcenverwaltungssteuerung 304 von einem Orchestrator auf einer entfernten Edge-Plattform und/oder einem anderen Computer grobe Orchestrierungsergebnisse oder feine Orchestrierungsergebnisse an. Zusätzlich oder alternativ kann die Ressourcenverwaltungssteuerung 304 Ressourcen auf einer Edge-Plattform auf Grundlage von KPIs verwalten, die mit einer Anwendung (z. B. einer Arbeitslast, einem Dienst usw.) assoziiert sind. Beispielsweise können von der Telemetriesteuerung 206 abgerufene Telemetriedaten Hinweise auf KPIs enthalten, die mit einem Dienst und/oder einer Arbeitslast assoziiert sind, die auf einer bestimmten Ressource (z. B. irgendwelchen der Ressource(n) 210) ausgeführt wird bzw. werden. In derartigen Beispielen kann bzw. können die Ressourcenverwaltungssteuerung 304 und/oder der Orchestrator 202 eine Ressourcenzuweisung auf der Edge-Plattform 200 anpassen, um bestimmte SLOs eines SLA für jeden Dienst und/oder jede Arbeitslast zu erfüllen, die auf der Edge-Plattform 200 ausgeführt wird bzw. werden. Zusätzlich oder alternativ schätzt die Ressourcenverwaltungssteuerung 304 auf Grundlage der von der Orchestratorschnittstelle 302 gesammelten Telemetriedaten die Ressourcenmenge ab, die von verschiedenen Diensten, Anwendungen und/oder Arbeitslasten zu nutzen sind, die der Edge-Plattform zugeordnet sind, um die jeweiligen SLAs zu erfüllen, die mit jedem bzw. jeder der Dienste, Anwendungen und/oder Arbeitslasten assoziiert sind. Auf Grundlage des Dienstausmaßes, der geschätzt wird, dass er genutzt wird, ermittelt die Ressourcenverwaltungssteuerung 304, welche Ressourcenmenge von den Orchestrierungskomponenten auf der Edge-Plattform freigegeben werden können oder diesen verfügbar gemacht werden können, mit einer oberen Schranke auf Grundlage der Konfigurationseinstellungen.
-
Im in
2 veranschaulichten Beispiel ist die Ressourcenverwaltungssteuerung
304 ausgelegt, auf Grundlage der von der Orchestratorschnittstelle
302 gesammelten Telemetriedaten und/oder auf Grundlage von KPIs und/oder SLOs von Anwendungen, die auf der Edge-Plattform
200 ausgeführt werden, die derzeit Orchestrierungskomponenten zugewiesenen Ressourcen oder diejenigen, die diesen zugewiesen werden, mit Konfigurationseinstellungen für den Orchestrator
202 zu vergleichen. In einigen Beispielen können die Telemetriedaten die auf einer Edge-Plattform verfügbare Ressourcenmenge und die vor Kurzem geschätzte oder vor Kurzem zugesagte Ressourcenmenge anzeigen, die zu verwenden sind, um eine oder mehrere Arbeitslasten in naher Zukunft auszuführen. In einigen Beispielen kann die Ressourcenverwaltungssteuerung
304 ausgelegt sein, bedingt auf Grundlage des Ressourcenverbrauchs von individuellen Orchestrierungskomponenten zu arbeiten (z. B. von irgendwelchen der Orchestratorschnittstelle
302, der Ressourcenverwaltungssteuerung
304, dem Arbeitslastenplaner
306, der thermalen Steuerung
308 und/oder der Orchestrierungsdatenbank
310). Falls die Ressourcenverwaltungssteuerung
304 zum Beispiel 10 % von Ressourcen eines Prozessors auf einem ersten Energiepegel zuweist, kann die Ressourcenverwaltungssteuerung
304 vorab ausgelegt sein, 5 % der Ressourcen eines Prozessors auf einem zweiten Energiepegel zuzuweisen (wobei der zweite z. B. kleiner als der erste ist). Die Konfigurationseinstellungen können einen Vektor mit Werten enthalten, die angeben, welche Ressourcenmenge (z. B. irgendwelche der Ressource(n)
210) für Orchestrierungskomponenten auf einer Edge-Plattform (z. B. der Edge-Plattform
200) aufgewandt werden dürfen (z. B. von diesen verwendet werden dürfen). Konfigurationseinstellungen für jede Komponente werden zum Beispiel mit der Ressourcenverwaltungssteuerung
304 vorab konfiguriert. In einigen Beispielen können die Konfigurationseinstellungen angeben, welche Ressourcenmenge (z. B. irgendwelche der Ressource(n)
210) für Orchestrierungskomponenten in jeder Stufe in der hierin beschriebenen Meta-Orchestrierungsarchitektur aufgewandt werden dürfen (z. B. von diesen verwendet werden dürfen). Die unten gezeigten Vektoren veranschaulichen Konfigurationseinstellungen für m ≥ 1 Ressourcen auf n ≥ 1 Energiepegeln (PLs).
-
Konfigurationseinstellungen
-
Im veranschaulichten Beispiel von 2 ist die Ressourcenverwaltungssteuerung 304 ausgelegt, zu ermitteln, ob die Ressourcenmenge, die Orchestrierungskomponenten derzeit zugewiesen ist oder diesen zugewiesen werden wird, einen vorläufigen Schwellenwert erreicht. Der vorläufige Schwellenwert kann zum Beispiel einem ersten Energiepegel entsprechen, der anzeigt, dass sich die Edge-Plattform in einem Zustand mit reduzierter Energie befindet. Falls die Ressourcenmenge, die derzeit Orchestrierungskomponenten zugewiesen ist oder diesen zugewiesen werden wird, den vorläufigen Schwellenwert erreicht, lädt der Orchestrator 202 diese Telemetriedaten aus, sodass sie an einem anderen Computer verarbeitet werden, um grobe Orchestrierungsergebnisse zu erhalten.
-
Zusätzlich oder alternativ ist die Ressourcenverwaltungssteuerung 304 ausgelegt, zu ermitteln, ob die Ressourcenmenge, die Orchestrierungskomponenten derzeit zugewiesen ist oder diesen zugewiesen werden wird, einen sekundären Schwellenwert erreicht. Der sekundäre Schwellenwert kann zum Beispiel einem zweiten Energiepegel entsprechen, der anzeigt, dass sich die Edge-Plattform in einem Zustand mit kritischer Energie befindet. Der sekundäre Schwellenwert kann zum Beispiel einem zweiten Energiepegel entsprechen, der niedriger als ein erster Energiepegel ist, der dem vorläufigen Schwellenwert entspricht. Falls die Ressourcenmenge, die derzeit Orchestrierungskomponenten zugewiesen ist oder diesen zugewiesen werden wird, den sekundären Schwellenwert erreicht, kann der Orchestrator 202 diese Telemetriedaten auslagern, sodass sie an einem anderen Computer verarbeitet werden, um feine Orchestrierungsergebnisse zu erhalten. In einigen Beispielen kann die Ressourcenmenge, die Orchestrierungskomponenten derzeit zugewiesen ist oder zugewiesen werden wird, thermalen Zuständen sowie physischen Ressourcen und/oder Softwareressourcen entsprechen. Die Konfigurationseinstellungen können zum Beispiel auf thermalen Zuständen auf einer Edge-Plattform zusätzlich zu oder als eine Alternative zu den Konfigurationseinstellungen auf Grundlage eines Energiepegels beruhen. In derartigen Beispielen kann bzw. können der vorläufige Schwellenwert und/oder der sekundäre Schwellenwert (a) einer Menge (z. B. einem Prozentsatz) von Energie entsprechen, die von Orchestrierungskomponenten verbraucht wird und/oder werden wird und/oder (b) thermalen Zuständen auf einer Edge-Plattform und/oder von Orchestrierungskomponenten entsprechen. Eine Ressourcenzuweisung und/oder Auslagerung von Telemetriedaten und/oder Orchestrierungsaufgaben kann auf der Ressourcenmenge beruhen, die derzeit Orchestrierungsressourcen auf der Edge-Plattform zugewiesen sind und/oder diesen zugewiesen werden, um KPIs und/oder SLOs einer Anwendung (z. B. eines Diensts, einer Arbeitslast usw.) zu erreichen und/oder zu erzielen.
-
Im veranschaulichten Beispiel von 2, falls die Ressourcenmenge, die Orchestrierungskomponenten derzeit zugewiesen ist oder die diesen zugewiesen wird, den vorläufigen Schwellenwert oder den sekundären Schwellenwert nicht erreicht, ist die Ressourcenverwaltungssteuerung 304 ausgelegt, Ressourcen abzuschätzen (z. B. einige der Ressource(n) 210), die einer Edge-Plattform (z. B. der Edge-Plattform 200) zugeordneten Arbeitslasten zuzuweisen sind, um jeweilige mit den Arbeitslasten assoziierte SLAs zu erreichen und/oder anderweitig zu erfüllen. Darüber hinaus ist die Ressourcenverwaltungssteuerung 304 ausgelegt, Ressourcen abzuschätzen (z. B. einige der Ressource(n) 210), die Orchestrierungskomponenten (z. B. der Orchestratorschnittstelle 302, der Ressourcenverwaltungssteuerung 304, dem Arbeitslastenplaner 306, der thermalen Steuerung 308 und/oder der Orchestrierungsdatenbank 310) einer Edge-Plattform (z. B. der Edge-Plattform 200) zuzuweisen sind. Die Ressourcenverwaltungssteuerung 304 ermittelt zum Beispiel Ressourcenzuweisungswerte auf Grundlage einer oder mehrerer Arbeitslasten, die zum Ausführen auf einer Edge-Plattform (z. B. der Edge-Plattform) (z. B. bald, in naher Zukunft usw.) geplant sind.
-
Im Beispiel von 3, auf Grundlage der abgeschätzten Ressourcen, die den Arbeitslasten auf einer Edge-Plattform zuzuweisen sind und/oder der abgeschätzten Ressourcen, die den Orchestrierungskomponenten auf der Edge-Plattform zuzuweisen sind, skaliert die Ressourcenverwaltungssteuerung 304 (z. B. ist ausgelegt, zu skalieren) eine Orchestrierung auf der Edge-Plattform, um die geschätzten Ressourcenzuweisungswerte zu erfüllen. Die Ressourcenverwaltungssteuerung 304 reduziert, erhöht und/oder passt ein Planen von Arbeitslasten auf der Edge-Plattform anderweitig an und/oder reduziert, erhöht und/oder passt Überwachungsraten für SLAs an der Edge-Plattform anderweitig an. Zusätzlich oder alternativ kann eine derartige Anpassung ein Setzen jeder der Orchestrierungskomponenten auf der Edge-Plattform auf eine langsamere Operation (z. B. eine langsamere Taktfrequenz) und/oder ein Konfigurieren von Orchestrierungskomponenten enthalten, in einem niedrigen Energiebetriebsmodus grobe Orchestrierungsergebnisse zu generieren.
-
Im Beispiel von 3 passt die Ressourcenverwaltungssteuerung 304 Ressourcenverbrauch oder Orchestrierungskomponenten auf eine Vielfalt von Arten an und/oder drosselt diese anderweitig. Die Ressourcenverwaltungssteuerung 304 kann zum Beispiel Ziele für den Orchestrator 202 definieren. Derartige Ziele können durch einen Edge-Dienstanbieter, einen Leistungsvertrag und/oder eine beliebige andere geeignete Entität definiert werden. Die Ziele können ein Betreiben unter 5 % Ressourcenverbrauch für eine bestimmte Ressource enthalten. In einigen Beispielen, in denen die Sendung von Daten zwischen Edge-Plattformen für einen Dienst relevant ist, kann das mit diesem Dienst assoziierte Ziel sein, die Orchestrierungskomponenten auf einem Verbrauch der Bandbreite einer Edge-Plattform von unter 5 % zu betreiben. In anderen Beispielen kann das Ziel sein, die Orchestrierungskomponenten auf unter 5 % des Gesamtenergieverbrauchs der Edge-Plattform zu betreiben.
-
In zusätzlichen oder alternativen Beispielen kann das Ziel ein Betreiben von Orchestrierungskomponenten mit reduzierter Latenz enthalten. In einigen Beispielen, wenn Ressourcen und/oder Energie auf einer Edge-Plattform besonders eingeschränkt sind (z. B. unter dem zweiten Schwellenwert), kann das Ziel ein Betreiben der Orchestrierungskomponenten enthalten, um grobe Orchestrierungsergebnisse zu erhalten. Die Ressourcenverwaltungssteuerung 304 passt zum Beispiel Ressourcen, die den Orchestrierungskomponenten zugewiesen sind, auf Grundlage einer Nachschlagetabelle (LUT) an, die eine proportionale Verteilung von Ressourcen zu Orchestrierungskomponenten enthält.
-
Im Beispiel von 3 kann das Anpassen und/oder anderweitige Drosseln eines Ressourcenverbrauchs oder von Orchestrierungskomponenten (z. B. über die Ressourcenverwaltungssteuerung 304) ein Anpassen (z. B. Reduzieren, Erhöhen usw.) der jeder der Orchestrierungskomponenten zugewiesenen Ressourcenmenge, ein Anpassen (z. B. Reduzieren, Erhöhen usw.) der von der Orchestrierungskomponente für jede der Arbeitslasten zu verarbeitende Menge von Telemetriedaten (z. B. von den Orchestrierungskomponenten verbraucht) und/oder eine beliebige andere Technik zum Anpassen des Ressourcenverbrauchs durch Orchestrierungskomponenten enthalten.
-
Im illustrierten Beispiel von 3, beim Anpassen der Menge von Telemetriedaten, die von der Orchestrierungskomponente zu verarbeiten ist, können die resultierenden Telemetriedaten von der Ressourcenverwaltungssteuerung 304 genutzt werden, um Arbeitslast-SLAs und/oder angeforderte Leistungsmetriken zu erfüllen. Die Ressourcenverwaltungssteuerung 304 konfiguriert zum Beispiel Telemetriekomponenten (z. B. die Telemetriesteuerung 206) in einem Niedrigenergiemodus. Zusätzlich oder alternativ reduziert (z. B. verlangsamt) und/oder passt die Ressourcenverwaltungssteuerung 304 anderweitig an, wie oft die Ressourcenverwaltungssteuerung 304 Telemetriedaten verarbeitet, oder den Typ der Verarbeitung (z. B. die Granularität der Verarbeitung), die an Telemetriedaten durch die Ressourcenverwaltungssteuerung 304 ausgeführt wird. Eine Orchestrierungskomponente, Telemetriekomponente und/oder eine andere Komponente kann zum Beispiel ausgelegt sein, zusammenfassende Informationen über den Betrieb zu erzeugen, anstatt Telemetriedaten pro Subkomponente zu generieren.
-
In einigen Beispielen passt die Ressourcenverwaltungssteuerung 304 Ressourcenverbrauch oder Orchestrierungskomponenten durch Reduzieren, Erhöhen und/oder anderweitiges Anpassen der Ressourcenmenge an, die einer Telemetriekomponente (z. B. der Telemetriesteuerung 206) zugeordnet ist und/oder drosselt diesen bzw. diese anderweitig. In einigen Beispielen passt die Ressourcenverwaltungssteuerung 304 einen Ressourcenverbrauch von Orchestrierungskomponenten durch Reduzieren, Erhöhen und/oder Anpassen der Menge der Telemetriedaten an, die für die Ressourcenverwaltungssteuerung 304 und/oder andere Orchestrierungskomponenten verfügbar ist.
-
Im Beispiel von 3, wenn der Orchestrator 202 Telemetriedaten, die auf einer entfernten Edge-Plattform und/oder einem anderen Computer zu verarbeiten sind, um grobe Orchestrierungsergebnisse zu erhalten, beendet (z. B. deaktiviert, terminiert usw.) die Ressourcenverwaltungssteuerung 304 eine Verarbeitung von Telemetriedaten auf der Edge-Plattform und zeigt der Orchestratorschnittstelle 302 an, dass die Orchestratorschnittstelle 302 Telemetriedaten an eine entfernte Edge-Plattform und/oder einen anderen Computer zur Verarbeitung (z. B. Data Mining) zu senden hat. In einigen Beispielen, wenn eine erste Ressource für eine bestimmte Arbeitslast stark gefragt ist und eine zweite Ressource vergleichsweise wenig gefragt ist, lagert der Orchestrator 202 Orchestrierung und/oder Planung in Bezug auf die erste Ressource aus, während die Orchestrierung und/oder Planung der zweiten Ressource auf der Edge-Plattform behalten werden. Die Orchestratorschnittstelle 302 kann dann die entfernte Edge-Plattform und/oder einen anderen Computer auf die verarbeiteten (z. B. gewonnenen) Orchestrierungsergebnisse überwachen. Wenn der Orchestrator 202 grobe Orchestrierungsergebnisse empfängt, ermittelt die Ressourcenverwaltungssteuerung 304, ob die den Orchestrierungskomponenten zugewiesenen Ressourcen und/oder die Ressourcen, die Orchestrierungskomponenten in naher Zukunft zugewiesen werden, den sekundären Schwellenwert erreichen.
-
Im veranschaulichten Beispiel von 3, falls die Ressourcenverwaltungssteuerung 304 ermittelt, das die derzeit Orchestrierungskomponenten zugewiesenen Ressourcen und/oder die Ressourcen, die Orchestrierungskomponenten in naher Zukunft zugeordnet werden, den sekundären Schwellenwert erreichen, lagert der Orchestrator 202 Telemetriedaten aus, die an einem anderen Computer und/oder einer entfernten Edge-Plattform zu verarbeiten sind, um feine Orchestrierungsergebnisse zu erhalten. In einigen Beispielen, vor dem Auslagern der Telemetriedaten, kann die Orchestratorschnittstelle 302 Telemetriedaten vorab auf Grundlage des Ausmaßes der Bandbreite, die einer Edge-Plattform verfügbar ist und/oder die dem Orchestrator 202 zugewiesen ist, und/oder der Energie, die eingesetzt wird, um die Telemetriedaten an eine entfernte Edge-Plattform zu senden, vorab verarbeiten. Um Telemetriedaten zum Beispiel vorab zu verarbeiten, kann die Orchestratorschnittstelle 302 die Telemetriedaten vor dem Senden der Telemetriedaten an eine entfernte Edge-Plattform komprimieren und/oder filtern. In einigen Beispielen kann die Orchestratorschnittstelle 302 die Telemetriedaten auf Daten in Bezug auf KPIs und/oder SLOs von Anwendungen (z. B. Diensten, Arbeitslasten usw.) filtern, die auf der Edge-Plattform 200 ausgeführt werden. Falls die Ressourcenverwaltungssteuerung 304 ermittelt, dass die derzeit Orchestrierungskomponenten zugewiesenen Ressourcen und/oder die Ressourcen, die Orchestrierungskomponenten in naher Zukunft zugewiesen werden, den sekundären Schwellenwert nicht erreichen, schätzt die Ressourcenverwaltungssteuerung 304 die Ressourcen ab, die Orchestrierungskomponenten auf Grundlage der groben Orchestrierungsergebnisse zuzuweisen sind. In einigen Beispielen ermittelt die Ressourcenverwaltungssteuerung 304 feine Orchestrierungsergebnisse auf Grundlage der groben Orchestrierungsergebnisse.
-
Im in 3 veranschaulichten Beispiel, wenn der Orchestrator 202 Telemetriedaten auslagert, die auf einem anderen Computer und/oder einer entfernten Edge-Plattform zu verarbeiten sind, hält die Ressourcenverwaltungssteuerung 304 ein Verarbeiten von Telemetriedaten und Orchestrierungsaufgaben auf einer Edge-Plattform an (z. B. deaktiviert, beendet diese usw.) und sendet Telemetriedaten an eine entfernte Edge-Plattform und/oder einen anderen Computer, um feine Orchestrierungsergebnisse zu erhalten. Optional, wenn die Edge-Plattform Hardwarebeschleuniger enthält, kann die Ressourcenverwaltungssteuerung 304 sich selbst und/oder den Arbeitslastenplaner 306 neu konfigurieren, um unter Verwendung von gröberen, beschleunigerbasierten (z. B. statistikbasierten und/oder probenbasierten) Techniken, die die Anzahl von Orchestrierungsentscheidungen auf Grundlage eines erschöpfenden Volumens von Telemetriedaten reduzieren, Telemetriedaten zu verarbeiten und/oder Arbeitslastenpläne zu generieren.
-
Im Beispiel von 3, wenn eine Edge-Plattform keine Hardwarebeschleuniger enthält, kann die Ressourcenverwaltungssteuerung 304 ein Verarbeiten von Telemetriedaten und Orchestrierungsaufgaben auf der Edge-Plattform abschalten (z. B. deaktivieren, beenden usw.), um eine erschöpfende Analyse von detaillierten Telemetriedaten zu verhindern. Wenn eine Edge-Plattform keine Hardwarebeschleuniger enthält, kann die Ressourcenverwaltungssteuerung 304 sich selbst und/oder den Arbeitslastenplaner 306 auf Techniken auf Grundlage rechnerisch leichterer, abgetasteter oder reduzierter Telemetriedaten (z. B. zusammengefasster) neu konfigurieren, um Orchestrierungsergebnisse (z. B. Orchestrierungsinferenzen) zu erhalten.
-
In hierin beschriebenen Beispielen kann ein Auslagern von orchestrierungsbezogener Verarbeitung umgekehrt werden, wenn eine Verfügbarkeit von Energie und/oder anderen Ressourcen normal wird. Beispielsweise können Hysteresemechanismen eingesetzt werden, um den Transfer der Verarbeitung von orchestrierungsbezogenen Aufgaben und/oder Telemetriedaten zu steuern, sodass ein verlängerter Modus normaler Energieverfügbarkeit beobachtet wird, bevor der Orchestrator 202 auf einer Edge-Plattform, der ein Verarbeiten von Orchestrierungsaufgaben und/oder Telemetriedaten ausgelagert hat, ein Verarbeiten derartiger Aufgaben und/oder Daten umkehrt.
-
In einigen Beispielen implementiert die beispielhafte Ressourcenverwaltungssteuerung 304 beispielhafte Mittel zum Verwalten von Ressourcen. Das Ressourcenverwaltungsmittel ist durch ausführbare Anweisungen implementiert, wie zum Beispiel die durch zumindest Blöcke 408, 410, 412, 418, 420 und 422 von 4 veranschaulichten und/oder die zumindest Blöcke 502 und 508 von 5 veranschaulichten und/oder die zumindest Blöcke 602, 604, 606, 608, 610, 612, 614, 616 und 618 von 6 veranschaulichten und/oder die zumindest Blöcke 702, 710, 714 und 716 von 7 veranschaulichten und/oder die zumindest Blöcke 804 und 814 von 8 veranschaulichten, die auf mindestens einem Prozessor, wie dem beispielhaften Prozessor 1012, der im Beispiel von 10 gezeigt ist, ausgeführt werden können. In anderen Beispielen ist das Ressourcenverwaltungsmittel durch Hardwarelogik, hardwareimplementierte Zustandsmaschinen, Logikverschaltung und/oder eine beliebige andere Kombination von Hardware, Software und/oder Firmware implementiert.
-
Im Beispiel von 3 enthält der Orchestrator 202 den Arbeitslastenplaner 306. Der Arbeitslastenplaner 306 plant allgemein eine bzw. einen oder mehrere Arbeitslasten, Dienste und/oder Anwendungen, die auf einer Edge-Plattform auszuführen sind. In einigen Beispielen enthält das Planen ein Zugreifen auf eine von der Ressourcenverwaltungssteuerung 304 empfangene und/oder anderweitig erhaltene Aufgabe und ein Bereitstellen der Aufgabe an eine oder mehrere der Ressourcen auf einer Edge-Plattform (z. B. irgendwelchen der Ressource(n) 210) zur Ausführung oder zum Abschließen. In einigen Beispielen enthält das Planen ein Auswählen derjenigen Arbeitslasten, die einer Edge-Plattform zugeordnet sind, um sie an eine entfernte Edge-Plattform zur Ausführung auszulagern.
-
Im Beispiel von 3 führt bzw. führen die Ressource(n) 210 eine Arbeitslast auf Grundlage einer Beschreibung der Arbeitslast aus, die in der Aufgabe enthalten ist. Der Arbeitslastenplaner 306 greift auf ein Ergebnis der Ausführung der Arbeitslast von einer oder mehreren der Ressourcen auf der Edge-Plattform (z. B. von der bzw. den Ressource(n) 210) zu, die die Arbeitslast ausgeführt haben. Der Arbeitslastenplaner 306 stellt das Ergebnis der Vorrichtung bereit, die angefordert hatte, dass die Arbeitslast ausgeführt wird, wie eine Client-Rechenplattform und/oder eine andere Edge-Plattform. In einigen Beispielen ist der Arbeitslastenplaner 306 ausgelegt, zu ermitteln, ob ein Kandidatenplan eine oder mehrere SLAs erfüllt, die mit einer oder mehreren Arbeitslasten assoziiert sind.
-
In einigen Beispielen implementiert der beispielhafte Arbeitslastenplaner 306 beispielhafte Mittel zum Planen. Das Planungsmittel ist durch ausführbare Anweisungen implementiert, wie zum Beispiel die durch zumindest Blöcke 424 und 426 von 4 veranschaulichten und/oder die zumindest Block 510 von 5 veranschaulichten und/oder die zumindest Block 718 von 7 veranschaulichten und/oder die zumindest Blöcke 812 und 822 von 8 veranschaulichten und/oder die zumindest Blöcke 918, 920 und 924 von 9 veranschaulichten, die auf mindestens einem Prozessor, wie dem beispielhaften Prozessor 1012, der im Beispiel von 10 gezeigt ist, ausgeführt werden können. In anderen Beispielen ist das Planungsmittel durch Hardwarelogik, hardwareimplementierte Zustandsmaschinen, Logikverschaltung und/oder eine beliebige andere Kombination von Hardware, Software und/oder Firmware implementiert.
-
Im in 3 veranschaulichten Beispiel enthält der Orchestrator 202 die thermale Steuerung 308. Die thermale Steuerung 308 ist ausgelegt, eine agile und adaptive Verwaltung von thermalen Zuständen auf einer Edge-Plattform zu ermöglichen. Insbesondere kann in Far-Edge-Umgebungen eine passive Kühlung die Norm sein, angesichts sowohl der Energienutzung als auch den Herausforderungen bei der Wartung von Ausrüstung bei der Nutzung einer aktiven Kühlung. Auch wenn eine aktive Kühlung eingesetzt wird, kann eine derartige Kühlung als ein sekundärer Ausweg (um z. B. eine Energienutzung zu reduzieren und/oder zu steuern) ausgeführt werden.
-
Im Beispiel von 3 ist die thermale Steuerung 308 ausgelegt, Temperaturwerte von Ressourcen (z. B. CPUs, Chipsätze und/oder Peripheriegeräte) einer Edge-Plattform zu überwachen. Die thermale Steuerung 308 kann ausgelegt sein, in mindestens zwei Betriebsmodi zu arbeiten. In einem ersten Betriebsmodus verwaltet die thermale Steuerung 308 zum Beispiel thermale Zustände an der Edge-Plattform, ohne arbeitslastspezifische Merkmale zu berücksichtigen. In einem zweiten Betriebsmodus verwaltet die thermale Steuerung 308 thermale Zustände an der Edge-Plattform unter Berücksichtigung arbeitslastspezifischer Merkmale. Im ersten Betriebsmodus, wenn die thermale Steuerung 308 übermäßige Wärme (z. B. eine Temperatur über einem Schwellenpegel) erkennt, erhöht die thermale Steuerung 308 eine Kühlung (z. B. durch Erhöhen einer Lüfterdrehzahl) und/oder drosselt eine Berechnung (z. B. niedrigere Taktfrequenz). Im ersten Betriebsmodus wendet die thermale Steuerung 308 Energieverwaltungsstrategien einheitlich über alle Mandanten hinweg an, die eine Edge-Plattform gemeinsam nutzen.
-
Im Beispiel von
3 können Mandantenarbeitslasten eine erwartete Abschlusszeit angeben, die ein Ausführungsfenster definiert, in dem die thermale Steuerung
308 die Energie optimieren kann. Jede Komponente einer Edge-Plattform kann auf verschiedenen Energie-Leistungspegeln arbeiten, die unterschiedliche Energieeffizienzen für unterschiedliche Pegel enthalten. Der „optimale Energie-Leistungspunkt“ ist der Pegel, wo (1) die meiste Berechnung ohne Drosseln auf Grundlage der Temperatur erzielt werden kann und (2) Leerlaufenergie (als ein Prozentsatz der gesamt verwendeten Energie zum Abschließen einer Arbeitslast) vernachlässigbar ist. Die Summe der Komponenten, die verwendet werden, um eine Mandanten-Arbeitslast auf einer Edge-Plattform durchzuführen, kann als Anzahl von Anweisungen bei einer Leistung pro Watt bei einer bestimmten Temperatur ausgedrückt werden.
-
In der obigen Arbeitslast-Kostenfunktion repräsentieren Anweisungen die Anzahl von Operationen, die eingesetzt werden, um eine Arbeitslast und/oder Funktion durchzuführen. Die Anweisungen können architekturspezifisch sein oder können auf einer allgemeinen Anweisungssatzarchitektur beruhen, die vielen proprietären Architekturen gemeinsam ist. Zusätzlich oder alternativ können die Anweisungen als ein Bitstromkernel (der z. B. üblicherweise von FPGAs verwendet wird) und/oder einer beliebigen anderen geeigneten Rechenkernel repräsentiert sein. Leistung repräsentiert die mit der Zeit abgeführte Energie. In einer derartigen Darstellung, desto mehr Zeit zum Durchführen einer Arbeitslast verfügbar ist, desto geringer ist die Momentanverlustleistung, die einzusetzen ist, um die Arbeitslast auszuführen. Durch Berechnen des Arbeitslastaufwands pro Mandant auf einer Edge-Plattform ermittelt die thermale Steuerung 308 eine Abschätzung der Abweichung vom „optimalen Leistungspunkt“. In der Arbeitslast-Kostenfunktion kann eine Temperatur, bei der der Arbeitslastenaufwand ermittelt wird, durch einen Gewichtungsfaktor angepasst werden. Der Gewichtungsfaktor kann auf einen „optimalen Punkt“ für eine Ressource eingestellt werden.
-
Im Beispiel von 3 berechnet die thermale Steuerung 308 ein Modell (z. B. eine Markov-Kette), das mehrere mögliche Arbeitslastenaufwandsoptionen involviert. Das Modell kann zum Beispiel auf verschiedenen maschinellen Lerntechniken beruhen, um einen Ausgleich unter konkurrierenden Zielen zu erreichen. Modelle können Markov-Ketten, Behälterproblem-Modelle, Support-Vector-Machine-Modelle usw. enthalten. Auf Grundlage des Modells wählt der Arbeitslastenplaner 306 einen optimalen Mehrmandantenplan für eine Edge-Plattform aus (z. B. auf Grundlage der aktuellen Ressourcenkonfiguration). Der Arbeitslastenplaner 306 setzt einen modellbasierten Plan (z. B. einen Markov-basierten Plan) ein, um zu ermitteln, wie Mandantenarbeitslasten am besten zu planen sind. Der Arbeitslastenplaner 306 kann zum Beispiel ermitteln, auf Grundlage des von der thermalen Steuerung 308 generierten Modells, dass mehrere Mandantenarbeitslasten mit einer niedrigeren Taktfrequenz über eine längere Zeitspanne ausgeführt werden können. Die thermale Steuerung 308 kann die Ressourcen der Edge-Plattform zum Ausführen mit der Ziel-Taktfrequenz (z. B. Taktrate) konfigurieren und der Arbeitslastenplaner 306 kann diese Mandantenarbeitslasten zum gemeinsamen Nutzen dieser Edge-Plattformen planen.
-
Im Beispiel von 3 kann die thermale Steuerung 308 ermitteln, dass durch Steuern von physischen Anlagenkühlern (z. B. Kühlern auf Luftbasis, Kühlern auf Flüssigkeitsbasis, Kühlern auf Kältetechnikbasis). In einem derartigen Beispiel bringt die thermale Steuerung 308 die Temperatur an der Edge-Plattform herunter, um ein Drosseln aufgrund der Temperatur zu vermeiden. In einem derartigen Beispiel gibt es einen Kompromiss, den die thermale Steuerung 308 zusätzlich berücksichtigt. Beim Reduzieren der Temperatur zum Vermeiden einer Drosselung fällt ein zusätzlicher Energieaufwand zum Betreiben der Kühler an. Auf Grundlage von mit Arbeitslasten assoziierten SLAs beurteilt die thermale Steuerung 308, ob der SLA die zusätzlichen Kosten erlaubt, und falls der SLA die zusätzlichen Kosten erlaubt, kann die thermale Steuerung 308 die aktive Kühlung der Edge-Plattform konfigurieren und der Arbeitslastenplaner 306 kann die Arbeitslast zum Ausführen auf der Edge-Plattform planen.
-
In einigen Beispielen implementiert die beispielhafte thermale Steuerung 308 beispielhafte Mittel zum Steuern thermaler Zustände. Das Mittel zum Steuern thermaler Zustände wird durch ausführbare Anweisungen implementiert, wie die, die durch zumindest die Blöcke 902, 906, 908, 910, 912, 914, 916 und 922 von 9 veranschaulicht sind, die auf mindestens einem Prozessor ausgeführt werden können, wie dem beispielhaften Prozessor 1012, der im Beispiel von 10 gezeigt ist. In anderen Beispielen ist das Steuermittel für thermale Zustände durch Hardwarelogik, hardwareimplementierte Zustandsmaschinen, Logikverschaltung und/oder eine beliebige andere Kombination von Hardware, Software und/oder Firmware implementiert.
-
Im illustrierten Beispiel von 3 enthält der Orchestrator 202 die Orchestrierungsdatenbank 310 zum Speichern von Daten, die mit einer Orchestrierung assoziiert sind. Die Orchestrierungsdatenbank 310 kann zum Beispiel Telemetriedaten, Arbeitslasten, Modelle, Pläne, SLAs, SLOs, KPIs, eine oder mehrere LUTs, einschließlich einer proportionalen Verteilung von Ressourcen auf Orchestrierungskomponenten und/oder Rechenkernels speichern. In einigen Beispielen ermöglichen die Rechenkernels einen Einsatz von Hardwarebeschleunigern, um beliebige der Orchestratorschnittstelle 302, der Ressourcenverwaltungssteuerung 304, des Arbeitslastenplaners 306 und/oder der thermalen Steuerung 308 zu implementieren. Die Orchestrierungsdatenbank 310 kann zum Beispiel eine Bibliothek von Bitstromkernels (z. B. FPGA-Bilder) enthalten, die verschiedene Orchestrierungsaufgaben durchführen, um zusammengefasste Telemetriedaten zu erzeugen und/oder um grobe Orchestrierungsergebnisse zu ermitteln (z. B. Robotersteuerungsentscheidungen zur Orchestrierung), wenn rechnerische Ressourcen und/oder Energie in reduziertem Angebot sind. Die Rechenkernels können unabhängig von einem Edge-Dienstanbieter konfiguriert und bereitgestellt werden und über die Fähigkeitssteuerung 204 in die Edge-Plattform registriert werden und/oder beim Orchestrator 202 registriert werden. In einigen Beispielen kann die Orchestrierungsdatenbank 310 eingesetzt werden, um beim Auslagern von Telemetriedaten an eine entfernte Edge-Plattform Telemetriedaten zu reduzieren und/oder zu filtern.
-
Im Beispiel von 3 kann die Orchestrierungsdatenbank 310 durch einen flüchtigen Arbeitsspeicher (z. B. einen SDRAM, DRAM, RDRAM usw.) und/oder einen nichtflüchtigen Arbeitsspeicher (z. B. einen Flashspeicher) implementiert sein. Die Orchestrierungsdatenbank 310 kann zusätzlich oder alternativ durch einen oder mehrere DDR-Arbeitsspeicher, wie DDR, DDR2, DDR3, DDR4, mDDR usw. implementiert sein. Die Orchestrierungsdatenbank 310 kann zusätzlich oder alternativ durch eine oder mehrere Massenspeichervorrichtungen, wie (ein) Festplattenlaufwerk(e), Compact-Disc-Laufwerk(e), Digital-Versatile-Disk-Laufwerk(e), Festkörperlaufwerk(e) usw. implementiert sein. Während die Orchestrierungsdatenbank 310 im veranschaulichten Beispiel als eine einzelne Datenbank veranschaulicht ist, kann die Orchestrierungsdatenbank 310 durch eine beliebige Anzahl und/oder einen beliebigen Typ von Datenbanken implementiert sein. Ferner können die in der Orchestrierungsdatenbank 310 gespeicherten Daten in einem beliebigen Datenformat, wie zum Beispiel binären Daten, durch Kommata getrennte Daten, durch Tabulatoren getrennte Daten, SQL-Strukturen usw. sein.
-
Im in 3 veranschaulichten Beispiel sind die Orchestratorschnittstelle 302, die Ressourcenverwaltungssteuerung 304, der Arbeitslastenplaner 306, die thermale Steuerung 308 und die Orchestrierungsdatenbank 310 im Orchestrator 202 enthalten, entsprechen diesem und/oder sind anderweitig für diesen repräsentativ. In einigen Beispielen können eines oder mehrere der Orchestratorschnittstelle 302, der Ressourcenverwaltungssteuerung 304, des Arbeitslastenplaners 306, der thermalen Steuerung 308 und der Orchestrierungsdatenbank 310 in einer anderen Komponente der Edge-Plattform 200 anstatt als eine einzelne Komponente enthalten sein. In einigen Beispielen ist/sind eines oder mehrere von der Orchestratorschnittstelle 302, der Ressourcenverwaltungssteuerung 304, des Arbeitslastenplaners 306, der thermalen Steuerung 308 und der Orchestrierungsdatenbank 310 separate Vorrichtungen, die in einer Edge-Umgebung enthalten sind. Ferner können eines oder mehrere der Orchestratorschnittstelle 302, der Ressourcenverwaltungssteuerung 304, des Arbeitslastenplaners 306, der thermalen Steuerung 308 und der Orchestrierungsdatenbank 310 auf beliebigen der Ressource(n) 210 implementiert sein. Beispielsweise können eines oder mehrere der Orchestratorschnittstelle 302, der Ressourcenverwaltungssteuerung 304, des Arbeitslastenplaners 306, der thermalen Steuerung 308 und der Orchestrierungsdatenbank 310 separate Vorrichtungen, wie eine oder mehrere CPUs (z. B. Mehrkern-CPUs), ein oder mehrere FPGAs, eine oder mehrere GPUs, eine oder mehrere NICs, eine oder mehrere VPUs usw., und/oder eine beliebige andere Art von Hardware oder Hardwarebeschleuniger sein. In derartigen Beispielen kann bzw. können die Ressource(n) 210 einer Virtualisierung bzw. Virtualisierungen der einen oder mehreren CPUs, des einen oder mehreren FPGAs, der einen oder mehreren GPUs, der einen oder mehreren NICs usw. enthalten, entsprechen und/oder anderweitig für diese repräsentativ sein. In anderen Beispielen kann bzw. können die Orchestratorschnittstelle 302, die Ressourcenverwaltungssteuerung 304, der Arbeitslastenplaner 306, die thermale Steuerung 308 und die Orchestrierungsdatenbank 310 und/oder allgemeiner der Orchestrator 202 eine oder mehrere Softwareressourcen, Virtualisierungen der Softwareressourcen usw., wie Hypervisors, Lastenausgleichseinheiten, OSes, VMs usw. und/oder eine Kombination daraus enthalten, dieser bzw. diesen entsprechen und/oder anderweitig dafür repräsentativ sein.
-
Während in 3 eine beispielhafte Art und Weise zum Implementieren des Orchestrators 202 von 2 veranschaulicht ist, können eines oder mehrere der in 3 veranschaulichten Elemente, Prozesse und/oder Vorrichtungen durch globale und/oder lokale Schleifenprotokolle implementiert sein. In einigen Beispielen kann bzw. können eines oder mehrere der Elemente, Prozesse und/oder Vorrichtungen, die in 3 veranschaulicht sind, durch Energie- und Telemetrieüberwachungs- und Verwaltungslogik, lokale Orchestrierungskomponenten und/oder dienstbeschleunigte Telemetrieverarbeitungslogik implementiert sein. Während die hierin offenbarten Beispiele im Kontext von Energiemetriken (eine wichtige Metrik in Edge-Plattformen auf Grundlage grüner Energie) beschrieben wurden, können andere Metriken eingesetzt werden. Die hierin offenbarten Beispiele können beispielsweise zusätzliche oder alternative Metriken einsetzen, einschließlich thermaler Metriken, zusätzlicher Leistungskennzahlen. Auf Grundlage der eingesetzten Metriken können hierin offenbarte Beispiele entscheiden, welche Orchestrierungshandlungen auf einer Edge-Plattform vorzunehmen sind.
-
Allgemeiner können zwei oder mehr Stufen in der hierin beschriebenen Meta-Orchestrierungsarchitektur definiert sein, sodass eine N-te Stufe eine Delegierung von einer N-1-ten Stufe zum Verarbeiten von Telemetriedaten und/oder zur Ausführung von Orchestrierungsaufgaben und/oder anderer Prozesse nehmen kann. Zusätzlich oder alternativ können zwei oder mehr Stufen in der hierin beschriebenen Meta-Orchestrierungsarchitektur definiert sein, sodass eine N-te Stufe eine Delegierung von einer N-1-ten Stufe zum Verarbeiten von Regelungsabläufen von Energie- und/oder Ressourcennutzung annehmen kann. Allgemein können ausgelagerte Operationen gröberer verarbeitet werden, da die N-te Stufe von den tatsächlichen zu überwachenden und orchestrierenden Ressourcen, einschließlich von Energie, weiter entfernt sein kann.
-
Während in 2 eine beispielhafte Art und Weise zum Implementieren der Edge-Plattform 200 von 2 veranschaulicht ist und eine beispielhafte Art und Weise zum Implementieren des Orchestrators 202 von 2 in 3 veranschaulicht ist, können eines oder mehrere der in 2 und 3 veranschaulichten Elemente, Prozesse und/oder Vorrichtungen auf beliebige andere Weise kombiniert, aufgeteilt, umgeordnet, weggelassen, eliminiert und/oder implementiert werden. Ferner können der beispielhafte Orchestrator 202, die beispielhafte Fähigkeitssteuerung 204, die beispielhafte Telemetriesteuerung 206, die beispielhafte EP-Datenbank 208, die beispielhafte(n) Ressource(n) 210 und/oder allgemeiner die beispielhafte Edge-Plattform 200 und/oder die beispielhafte Orchestratorschnittstelle 302, die beispielhafte Ressourcenverwaltungssteuerung 304, der beispielhafte Arbeitslastenplaner 306, die beispielhafte thermale Steuerung 308, die beispielhafte Orchestrierungsdatenbank 310 und/oder allgemeiner der beispielhafte Orchestrator 202 von 2 und 3 durch Hardware, Software, Firmware und/oder eine beliebige Kombination von Hardware, Software und/oder Firmware implementiert sein. Deshalb könnten zum Beispiel beliebige des beispielhaften Orchestrators 202, der beispielhaften Fähigkeitssteuerung 204, der beispielhaften Telemetriesteuerung 206, der beispielhaften EP-Datenbank 208, der beispielhaften Ressource(n) 210 und/oder allgemeiner der beispielhaften Edge-Plattform 200 und/oder der beispielhaften Orchestratorschnittstelle 302, der beispielhaften Ressourcenverwaltungssteuerung 304, des beispielhaften Arbeitslastenplaners 306, der beispielhaften thermalen Steuerung 308, der beispielhaften Orchestrierungsdatenbank 310 und/oder allgemeiner des beispielhaften Orchestrators 202 von 2 und 3 durch einen oder mehrere Analog- oder Digitalschaltkreis(e), Logikschaltkreise, programmierbare(n) Prozessor(en), programmierbare Steuerung(en), Grafikverarbeitungseinheit(en) (GPU(s)), digitale Signalprozessor(en) (DSP(s)), anwendungsspezifische(n) integrierte(n) Schaltkreis(e) (ASIC(s)), programmierbare(n) Logikvorrichtung(en) (PLD(s)) und/oder feldprogrammierbare(n) Logikvorrichtung(en) (FPLD(s)) implementiert sein. Wenn beliebige der Vorrichtungs- oder Systemansprüche dieses Patents so gelesen werden, dass diese eine reine Software- und/oder Firmwareimplementierung abdecken, ist bzw. sind mindestens eine bzw. einer beispielhaften Orchestrators 202, der beispielhaften Fähigkeitssteuerung 204, der beispielhaften Telemetriesteuerung 206, der beispielhaften EP-Datenbank 208, der beispielhaften Ressource(n) 210 und/oder allgemeiner der beispielhaften Edge-Plattform 200 und/oder der beispielhaften Orchestratorschnittstelle 302, der beispielhaften Ressourcenverwaltungssteuerung 304, des beispielhaften Arbeitslastenplaners 306, der beispielhaften thermalen Steuerung 308, der beispielhaften Orchestrierungsdatenbank 310 und/oder allgemeiner des beispielhaften Orchestrators 202 von 2 und 3 ausdrücklich als eine nicht transitorische computerlesbare Speichervorrichtung oder Speicherplatte, wie einen Arbeitsspeicher, eine Digital Versatile Disk (DVD), eine Compact Disk (CD), eine Blu-ray Disk usw. einschließlich der Software und/oder Firmware, enthaltend definiert. Darüber hinaus kann die beispielhafte Edge-Plattform 200 von 2 und/oder der beispielhafte Orchestrator 202 von 2 und/oder 3 ein oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu oder statt der in 2 und/oder 3 veranschaulichten enthalten und/oder kann mehr als eines von beliebigen oder allen der veranschaulichten Elemente, Prozesse und Vorrichtungen enthalten. Wie hierin verwendet, umfasst die Phrase „in Kommunikation“, einschließlich von Varianten davon, eine direkte Kommunikation und/oder eine indirekte Kommunikation durch eine oder mehrere Zwischenkomponenten und erfordert keine direkte physische (z. B. verdrahtete) Kommunikation und/oder konstante Kommunikation, sondern vielmehr enthält zusätzlich eine selektive Kommunikation in periodischen Intervallen, geplanten Intervallen, nicht periodischen Intervallen und/oder einmalige Ereignisse.
-
Ablaufdiagramme, die beispielhafte Hardwarelogik, maschinenlesbare Anweisungen, hardwareimplementierte Zustandsmaschinen und/oder eine beliebige Kombination davon zum Implementieren des Orchestrators 202 von 2 und/oder 3 darstellen, sind in 4, 5, 6, 7, 8 und/oder 9 gezeigt. Die maschinenlesbaren Anweisungen können ein oder mehrere ausführbare Programme oder ein Teil bzw. Teile eines ausführbaren Programms zur Ausführung durch einen Computerprozessor wie dem Prozessor 1012 sein, der in der beispielhaften Prozessorplattform 1000 gezeigt ist, die unten in Verbindung mit 10 besprochen wird. Das Programm kann in auf einem nichtflüchtigen computerlesbaren Speichermedium wie einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-ray Disk oder einem mit dem Prozessor 1012 verbundenen Arbeitsspeicher gespeicherter Software ausgebildet sein, aber das gesamte Programm und/oder Teile davon könnten alternativ von einer anderen Vorrichtung als dem Prozessor 1012 ausgeführt werden und/oder in Firmware oder dedizierter Hardware ausgebildet sein. Ferner, obwohl das beispielhafte Programm in Bezug auf die in 4, 5, 6, 7, 8 und/oder 9 veranschaulichten Ablaufdiagramme beschrieben ist, können alternativ viele andere Verfahren zum Implementieren des beispielhaften Orchestrators 202 verwendet werden. Die Reihenfolge der Ausführung der Blöcke kann zum Beispiel geändert werden und/oder einige der beschriebenen Blöcke können geändert, eliminiert oder kombiniert werden. Zusätzlich oder alternativ können beliebige oder alle der Blöcke durch einen oder mehrere Hardwareschaltkreise (z. B. diskrete und/oder integrierte analoge und/oder digitale Verschaltung, ein FPGA, einen ASIC, einen Komparator, einen Operationsverstärker (Op-Amp), einen Logikschaltkreis usw.) implementiert sein, die strukturiert sind, die entsprechende Operation ohne Ausführen von Software oder Firmware durchzuführen.
-
Die hierin beschriebenen maschinenlesbaren Anweisungen können in einem oder mehreren eines komprimierten Formats, eines verschlüsselten Formats, eines fragmentierten Formats, eines compilierten Formats, eines ausführbaren Formats, eines paketierten Formats usw. gespeichert sein. Maschinenlesbare Anweisungen, wie sie hierin beschrieben sind, können als Daten (z. B. Abschnitte von Anweisungen, Code, Darstellungen von Code usw.) gespeichert sein, die eingesetzt werden können, um maschinenlesbare Anweisungen zu erstellen, herzustellen und/oder zu erzeugen. Die maschinenlesbaren Anweisungen können beispielsweise fragmentiert und auf einer oder mehreren Speichervorrichtungen und/oder Rechenvorrichtungen (z. B. Servern) gespeichert werden. Die maschinenlesbaren Anweisungen können eines oder mehrere von Installation, Modifikation, Adaptierung, Aktualisierung, Kombinierung, Ergänzung, Konfigurierung, Entschlüsselung, Dekomprimierung, Entpackung, Verteilung, Neuzuordnung, Compilierung usw. erfordern, um sie direkt durch eine Rechenvorrichtung und/oder eine anderen Maschine lesbar, interpretierbar und/oder ausführbar zu machen. Die maschinenlesbaren Anweisungen können beispielsweise in mehreren Teilen gespeichert sein, die individuell komprimiert, verschlüsselt und auf separaten Rechenvorrichtungen gespeichert sind, wobei die Teile, wenn sie entschlüsselt, entkomprimiert und kombiniert werden, einen Satz von ausführbaren Anweisungen bilden, die ein Programm wie das hierin beschriebene implementieren.
-
In einem anderen Beispiel können die maschinenlesbaren Anweisungen in einem Zustand gespeichert sein, in dem sie von einem Computer gelesen werden können, aber eine Hinzufügung einer Bibliothek (z. B. einer Dynamic Link Library (DLL)), eines Software-Entwicklungskit (SDK), einer Anwendungsprogrammierschnittstelle (API) usw. erfordern, um die Anweisungen auf einer bestimmten Rechenvorrichtung oder anderen Vorrichtung auszuführen. In einem anderen Beispiel müssen die maschinenlesbaren Anweisungen konfiguriert werden (z. B. Einstellungen gespeichert, Daten eingegeben, Netzwerkadressen aufgezeichnet usw.), bevor die maschinenlesbaren Anweisungen und/oder das bzw. die entsprechende(n) Programm(e) gänzlich oder teilweise ausgeführt werden können. Deshalb sollen die offenbarten maschinenlesbaren Anweisungen und/oder das bzw. die entsprechende(n) Programm(e) derartige maschinenlesbare Anweisungen und/oder Programme umfassen, unabhängig vom bestimmten Format oder Zustand der maschinenlesbaren Anweisungen und/oder des/der maschinenlesbaren Programms/Programme, wenn sie gespeichert sind oder sich anderweitig in Ruhe oder in Übertragung befinden.
-
Die hierin beschriebenen maschinenlesbaren Anweisungen können durch eine beliebige vergangene, aktuelle oder zukünftige Anweisungssprache, Skriptsprache, Programmiersprache usw. repräsentiert sein. Beispielsweise können die maschinenlesbaren Anweisungen unter Verwendung beliebiger der folgenden Sprachen repräsentiert sein: C, C++, Java, C#, Perl, Python, JavaScript, HyperText Markup Language (HTML), Structured Query Language (SQL), Swift usw.
-
Wie oben erwähnt, können die beispielhaften Prozesse von 4, 5, 6, 7, 8 und/oder 9 unter Verwendung von ausführbaren Anweisungen (z. B. computer- und/oder maschinenlesbaren Anweisungen) implementiert werden, die auf einem nichtflüchtigen computer- und/oder maschinenlesbaren Medium wie einem Festplattenlaufwerk, einem Flashspeicher, einem Nur-Lese-Speicher, einer Compact-Disk, einer Digital Versatile Disk, einem Zwischenspeicher, einem Speicher mit wahlfreiem Zugriff und/oder einer beliebigen anderen Speichervorrichtung oder Speicherplatte gespeichert sind, auf der Informationen für eine beliebige Dauer gespeichert sind (z. B. für längere Zeiträume, dauerhaft, für kurze Augenblicke, zum temporären Puffern und/oder zum Zwischenspeichern der Informationen). Wie hierin verwendet, ist der Begriff nichtflüchtiges computerlesbares Medium ausdrücklich definiert, alle Typen von computerlesbarer Speichervorrichtung und/oder Speicherplatte zu enthalten und sich ausbreitende Signale auszuschließen und Sendemedien auszuschließen.
-
„Enthaltend“ und „umfassend“ (und alle Formen und Zeitformen davon) werden hier als offene Begriffe verwendet. Immer wenn ein Anspruch irgendeine Form von „enthalten“ oder „umfassen“ (z. B. umfasst, enthält, umfassend, einschließlich, aufweisend usw.) als eine Präambel oder innerhalb eines Anspruchs irgendeiner Art, versteht sich, dass zusätzliche Elemente, Ausdrücke usw. vorhanden sein können, ohne in den Schutzbereich des entsprechenden Anspruchs oder der entsprechenden Aufzählung zu fallen. Wenn hier der Begriff „mindestens“ als Übergangsbegriff zum Beispiel in einem Oberbegriff eines Anspruchs verwendet wird, ist er in der gleichen Weise offen, wie die Begriffe „umfassend“ und „enthaltend“ offen sind. Der Ausdruck „und/oder“, wenn er beispielsweise in einer Form wie A, B und/oder C verwendet wird, bezeichnet eine beliebige Kombination oder Teilmenge von A, B, C, wie beispielsweise (1) nur A, (2) nur B, (3) nur C, (4) A mit B, (5) A mit C, (6) B mit C und (7) A mit B und mit C. Wie hierin im Kontext zum Beschreiben von Strukturen, Komponenten, Elementen, Objekten und/oder Dingen verwendet, soll die Phrase „mindestens eines von A und B“ auf Implementierungen verweisen, die beliebige von (1) mindestens ein A, (2) mindestens ein B und (3) mindestens ein A und mindestens ein B enthalten. Gleichermaßen, wie hierin im Kontext zum Beschreiben von Strukturen, Komponenten, Elementen, Objekten und/oder Dingen verwendet, soll die Phrase „mindestens eines von A oder B“ auf Implementierungen verweisen, die beliebige von (1) mindestens ein A, (2) mindestens ein B und (3) mindestens ein A und mindestens ein B enthalten. Wie hierin im Kontext zum Beschreiben der Durchführung oder Ausführung von Prozessen, Anweisungen, Handlungen, Aktivitäten und/oder Schritten verwendet, soll die Phrase „mindestens eines von A und B“ auf Implementierungen verweisen, die beliebige von (1) mindestens ein A, (2) mindestens ein B und (3) mindestens ein A und mindestens ein B enthalten. Gleichermaßen, wie hierin im Kontext zum Beschreiben der Durchführung oder Ausführung von Prozessen, Anweisungen, Handlungen, Aktivitäten und/oder Schritten verwendet, soll die Phrase „mindestens eines von A oder B“ auf Implementierungen verweisen, die beliebige von (1) mindestens ein A, (2) mindestens ein B und (3) mindestens ein A und mindestens ein B enthalten.
-
Wie hierin verwendet schließen Bezugnahmen in der Einzahl (z. B. „ein“, „eine“, „eines“, „erstes“, „zweites“ usw.) eine Vielzahl nicht aus. Der Ausdruck „ein“ oder „eine“ Entität, wie er hierin verwendet wird, bezeichnet eine oder mehrere dieser Entität. Die Ausdrücke „ein/eine“ (oder „eines“), „ein oder mehrere“ und „mindestens ein“ können hierin austauschbar verwendet werden. Obwohl sie individuell aufgeführt sind, kann ferner eine Vielzahl von Mitteln, Elementen oder Verfahrenshandlungen z. B. von einer einzigen Einheit oder einem einzigen Prozessor implementiert sein. Darüber hinaus, obwohl individuelle Merkmale in unterschiedlichen Beispielen oder Ansprüchen enthalten sein können, können diese möglicherweise kombiniert werden und die Aufnahme in verschiedene Beispiele oder Ansprüche bedeutet nicht, dass eine Kombination von Merkmalen nicht möglich und/oder vorteilhaft ist.
-
4 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen 400 darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator 202 von 2 und 3 und/oder allgemeiner die Edge-Plattform 200 von 2 zu implementieren, um eine Verarbeitung von Telemetriedaten auf einer Edge-Plattform auf Grundlage von Ressourcenverfügbarkeit zu steuern. Die maschinenlesbaren Anweisungen 400 beginnen bei Block 402, wo die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 ermittelt, ob der Orchestrator 202 und/oder die Edge-Plattform 200 ausgelagerte Telemetriedaten von einer entfernten Edge-Plattform empfangen hat. Als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass der Orchestrator 202 und/oder die Edge-Plattform 200 ausgelagerte Telemetriedaten von einer entfernten Edge-Plattform (Block 402: JA) empfangen hat, fahren die maschinenlesbaren Anweisungen 400 mit Block 404 fort, wo der Orchestrator 202 die ausgelagerten Telemetriedaten verarbeitet. Nach Block 404 fahren die maschinenlesbaren Anweisungen 400 mit Block 426 fort. Detaillierte beispielhafte maschinenlesbare Anweisungen zum Verarbeiten von ausgelagerten Telemetriedaten werden in Verbindung mit 5 veranschaulicht und beschrieben.
-
Im Beispiel von 4, als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass der Orchestrator 202 und/oder die Edge-Plattform 200 keine ausgelagerten Telemetriedaten von einer entfernten Edge-Plattform (Block 402: NEIN) empfangen hat, fahren die maschinenlesbaren Anweisungen 400 mit Block 406 fort, wo die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 Telemetriedaten sammelt. Die Orchestratorschnittstelle 302 kann zum Beispiel Telemetriedaten von der Telemetriesteuerung 206 und/oder direkt von einer oder mehreren Orchestrierungskomponenten sammeln (z. B. der Orchestratorschnittstelle 302, der Ressourcenverwaltungssteuerung 304, der Arbeitslastplanungseinheit 306, der thermalen Steuerung 308 und/oder der Orchestrierungsdatenbank 310). Auf Grundlage der Telemetriedaten vergleicht die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 bei Block 408 die derzeit den Orchestrierungskomponenten zugewiesenen Ressourcen und/oder Ressourcen, die Orchestrierungskomponenten in naher Zukunft zugewiesen werden, mit Konfigurationseinstellungen, die mit dem Orchestrator 202 assoziiert sind.
-
Im in 4 veranschaulichten Beispiel ermittelt die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 bei Block 410, ob die den Orchestrierungskomponenten zugewiesenen Ressourcen und/oder Ressourcen, die Orchestrierungskomponenten in naher Zukunft zugewiesen werden, einen vorläufigen Schwellenwert erreichen. Der vorläufige Schwellenwert entspricht zum Beispiel einem ersten Nutzungspegel (z. B. einem ersten Energiepegel), der anzeigt, dass sich die Edge-Plattform in einem Zustand niedriger Verfügbarkeit (z. B. in einem Zustand mit reduzierter Energie) befindet. Als Reaktion darauf, dass die Ressourcenverwaltungssteuerung 304 ermittelt, dass die Orchestrierungskomponenten zugewiesenen Ressourcen und/oder Ressourcen, die Orchestrierungskomponenten in naher Zukunft zugewiesen werden, den vorläufigen Schwellenwert erreichen (Block 410: JA), fahren die maschinenlesbaren Anweisungen 400 mit Block 412 fort.
-
Im Beispiel von 4 ermittelt die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 bei Block 412, ob die den Orchestrierungskomponenten zugewiesenen Ressourcen und/oder die Ressourcen, die Orchestrierungskomponenten in naher Zukunft zugewiesen werden, einen sekundären Schwellenwert erreichen. Der sekundäre Schwellenwert entspricht beispielsweise einem zweiten Nutzungspegel (z. B. einem zweiten Energiepegel), der eine größere Nutzung einer Ressource als der vorläufige Schwellenwert widerspiegelt (z. B. einen niedrigeren Energiepegel als der erste Energiepegel). Als Reaktion darauf, dass die Ressourcenverwaltungssteuerung 304 ermittelt, dass die Orchestrierungskomponenten zugewiesenen Ressourcen und/oder die Ressourcen, die Orchestrierungskomponenten in naher Zukunft zugewiesen werden, einen sekundären Schwellenwert nicht erreichen (Block 412: NEIN), fahren die maschinenlesbaren Anweisungen 400 mit Block 414 fort.
-
Im veranschaulichten Beispiel von 4 bei Block 414 lagert der Orchestrator 202 Telemetriedaten aus, die an einem anderen Computer zu verarbeiten sind, um grobe Orchestrierungsergebnisse zu erhalten. Nach Block 414 fahren die maschinenlesbaren Anweisungen 400 mit Block 426 fort. Detaillierte beispielhafte maschinenlesbare Anweisungen, um Telemetriedaten auszulagern, die an einem anderen Computer zu verarbeiten sind, um grobe Orchestrierungsergebnisse zu erhalten, sind in Verbindung mit 7 veranschaulicht und beschrieben. Als Reaktion darauf, dass die Ressourcenverwaltungssteuerung 304 ermittelt, dass die Orchestrierungskomponenten zugewiesenen Ressourcen und/oder die Ressourcen, die Orchestrierungskomponenten in naher Zukunft zugewiesen werden, einen sekundären Schwellenwert erreichen (Block 412: JA), fahren die maschinenlesbaren Anweisungen 400 mit Block 416 fort, wo der Orchestrator 202 Telemetriedaten auslagert, die an einem anderen Computer zu verarbeiten sind, um grobe Orchestrierungsergebnisse zu erhalten. Detaillierte beispielhafte maschinenlesbare Anweisungen, um Telemetriedaten auszulagern, die an einem anderen Computer zu verarbeiten sind, um grobe Orchestrierungsergebnisse zu erhalten, sind in Verbindung mit 8 veranschaulicht und beschrieben. Nach Block 416 fahren die maschinenlesbaren Anweisungen 400 mit Block 426 fort.
-
Zu Block 410 zurückkehrend, als Reaktion darauf, dass die Ressourcenverwaltungssteuerung 304 ermittelt, dass die Orchestrierungskomponenten zugewiesenen Ressourcen und/oder Ressourcen, die Orchestrierungskomponenten in naher Zukunft zugewiesen werden, den vorläufigen Schwellenwert nicht erreichen (Block 410: NEIN), fahren die maschinenlesbaren Anweisungen 400 mit Block 418 fort. Bei Block 418 schätzt die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 die Ressourcen ab, die Arbeitslasten zuzuweisen sind, die der Edge-Plattform 200 zugeordnet sind, um eine jeweilige SLA jeder Arbeitslast zu erfüllen.
-
Im Beispiel von 4, bei Block 420 schätzt die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 Ressourcen ab, die Orchestrierungskomponenten (z. B. der Orchestratorschnittstelle 302, der Ressourcenverwaltungssteuerung 304, dem Arbeitslastenplaner 306, der thermalen Steuerung 308 und/oder der Orchestrierungsdatenbank 310) zuzuweisen sind. Bei Block 422 skaliert die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 eine Orchestrierung auf der Edge-Plattform 200, um die bei Block 418 und/oder Block 420 ermittelten Schätzwerte zu erreichen. In einigen Beispielen kann die Ressourcenverwaltungssteuerung 304 die Orchestrierungskomponenten individuell anpassen. Beispielsweise kann die Ressourcenverwaltungssteuerung 304 die einer ersten Orchestrierungskomponente (z. B. dem Arbeitslastenplaner 306) zugewiesenen Ressourcen auf 50 % reduzieren und die einer zweiten Orchestrierungskomponente (z. B. der Orchestratorschnittstelle 302) zugewiesenen Ressourcen auf 10 % reduzieren. Detaillierte beispielhafte maschinenlesbare Anweisungen zur Skalierungsorchestrierung auf einer Edge-Plattform werden in Verbindung mit 6 veranschaulicht und beschrieben.
-
Im in 4 veranschaulichten Beispiel, bei Block 424, plant der Arbeitslastenplaner 306 und/oder allgemeiner der Orchestrator 202 eine oder mehrere Arbeitslasten, die der Edge-Plattform 200 auf Grundlage der Orchestrierungsergebnisse zugeordnet sind. Nach Block 424 fahren die maschinenlesbaren Anweisungen 400 mit Block 426 fort. Bei Block 426 ermittelt der Arbeitslastenplaner 306 und/oder allgemeiner der Orchestrator 202, ob es zusätzliche Arbeitslasten gibt, die zu orchestrieren sind. Als Reaktion darauf, dass der Arbeitslastenplaner 306 ermittelt, dass es zusätzliche Arbeitslasten gibt, die zu orchestrieren sind (Block 426: JA), fahren die maschinenlesbaren Anweisungen 400 mit Block 402 fort. Als Reaktion darauf, dass der Arbeitslastenplaner 306 ermittelt, dass es keine zusätzlichen Arbeitslasten gibt, die zu orchestrieren sind (Block 426: JNEIN), werden die maschinenlesbaren Anweisungen 400 beendet.
-
5 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen 404 darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator 202 von 2 und 3 und/oder allgemeiner die Edge-Plattform 200 von 2 zu implementieren, um ausgelagerte Telemetriedaten zu verarbeiten. Die maschinenlesbaren Anweisungen 404 beginnen bei Block 502, wo die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 die Ressourcen abschätzt, die Arbeitslasten zuzuweisen sind, die der entfernten Edge-Plattform zugeordnet sind, um eine jeweilige SLA jeder Arbeitslast zu erfüllen. Bei Block 504 ermittelt die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202, ob die Telemetriedaten anzeigen, grobe Orchestrierungsergebnisse zu generieren.
-
Im Beispiel von 5, als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass die Telemetriedaten anzeigen, dass grobe Orchestrierungsergebnisse zu generieren sind (Block 504: JA), fahren die maschinenlesbaren Anweisungen 404 mit Block 506 fort. Bei Block 506 sendet die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 die geschätzten Ressourcen, die den entfernten Edge-Plattform-Arbeitslasten zuzuweisen sind, an die entfernte Edge-Plattform. Nach Block 506 kehren die maschinenlesbaren Anweisungen 404 zu den maschinenlesbaren Anweisungen 400 von Block 426 zurück. Als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass die Telemetriedaten anzeigen, dass grobe Orchestrierungsergebnisse zu generieren sind (Block 504: NEIN), fahren die maschinenlesbaren Anweisungen 404 mit Block 508 fort. Bei Block 508 ermittelt die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 feine Orchestrierungsergebnisse auf Grundlage der groben Orchestrierungsergebni sse.
-
Im in 5 veranschaulichten Beispiel, bei Block 510, generiert der Arbeitslastenplaner 306 und/oder allgemeiner der Orchestrator 202 einen Plan für die eine oder die mehreren Arbeitslasten, die der entfernten Edge-Plattform auf Grundlage der Orchestrierungsergebnisse zugeordnet sind. Bei Block 512 sendet die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 die Orchestrierungsergebnisse und/oder den Plan an die entfernte Edge-Plattform, die die Telemetriedaten ausgelagert hat. Nach Block 512 kehren die maschinenlesbaren Anweisungen 404 zu den maschinenlesbaren Anweisungen 400 bei Block 426 zurück.
-
6 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen 422 darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator 202 von 2 und 3 und/oder allgemeiner die Edge-Plattform 200 von 2 zu implementieren, um eine Orchestrierung auf einer Edge-Plattform zu skalieren. Die maschinenlesbaren Anweisungen 422 beginnen bei Block 602, wo die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 ermittelt, ob die geschätzten Ressourcen, die den Orchestrierungskomponenten zuzuweisen sind, größer als die derzeit den Orchestrierungsressourcen zugewiesenen Ressourcen sind. Als Reaktion darauf, dass die Ressourcenverwaltungssteuerung 304 ermittelt, dass die Orchestrierungskomponenten zuzuweisenden geschätzten Ressourcen nicht größer als die derzeit den Orchestrierungsressourcen zugewiesen sind (Block 602: NEIN), fahren die maschinenlesbaren Anweisungen 422 mit Block 610 fort.
-
Im Beispiel von 6, als Reaktion darauf, dass die Ressourcenverwaltungssteuerung 304 ermittelt, das die Orchestrierungskomponenten zuzuweisenden geschätzten Ressourcen größer als die derzeit den Orchestrierungsressourcen zugewiesen sind (Block 602: JA), fahren die maschinenlesbaren Anweisungen 422 mit Block 604 fort. Bei Block 604 erhöht die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 die Überwachungsrate von Telemetriedaten an der Edge-Plattform, um die Schätzwerte zu erreichen.
-
Im in 6 veranschaulichten Beispiel, bei Block 606, erhöht die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 die Überwachungsrate von SLAs, die mit Arbeitslasten assoziiert sind, die der Edge-Plattform zugeordnet sind, um die Schätzwerte zu erreichen. Bei Block 608 erhöht die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 die Verarbeitungsressourcen, die beim Verarbeiten von Telemetriedaten aufgewandt werden, um die Schätzwerte zu erreichen. Nach Block 608 kehren die maschinenlesbaren Anweisungen 422 zu den maschinenlesbaren Anweisungen 400 bei Block 424 zurück. Bei Block 610 ermittelt die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202, ob die geschätzten Ressourcen, die den Orchestrierungskomponenten zuzuweisen sind, kleiner als die derzeit den Orchestrierungsressourcen zugewiesenen Ressourcen sind. Als Reaktion darauf, dass die Ressourcenverwaltungssteuerung 304 ermittelt, dass die Orchestrierungskomponenten zuzuweisenden geschätzten Ressourcen nicht kleiner als die derzeit den Orchestrierungsressourcen zugewiesen sind (Block 610: NEIN), fahren die maschinenlesbaren Anweisungen 422 mit Block 612 fort.
-
Im in 6 veranschaulichten Beispiel, bei Block 612, behält die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 die derzeitige Ressourcenzuweisung zu Orchestrierungskomponenten auf der Edge-Plattform bei. Nach Block 612 kehren die maschinenlesbaren Anweisungen 422 zu den maschinenlesbaren Anweisungen 400 bei Block 424 zurück. Zu Block 610 zurückkehrend, als Reaktion darauf, dass die Ressourcenverwaltungssteuerung 304 ermittelt, dass die Orchestrierungskomponenten zuzuweisenden geschätzten Ressourcen kleiner als die derzeit den Orchestrierungsressourcen zugewiesen sind (Block 610: JA), fahren die maschinenlesbaren Anweisungen 422 mit Block 614 fort.
-
Im illustrierten Beispiel von 6, bei Block 614, verringert die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 die Überwachungsrate von Telemetriedaten an der Edge-Plattform, um die Schätzwerte zu erreichen. Die Ressourcenverwaltungssteuerung 304 kann zum Beispiel die Frequenz der Überwachung von Telemetriedaten auf Grundlage einer Priorität (z. B. einer Prioritätsstufe), die mit Ressourcen (z. B. der bzw. den Ressource(n) 210) auf einer Edge-Plattform (z. B. der Edge-Plattform 200) assoziiert ist. In einigen Beispielen kann die Ressourcenverwaltungssteuerung 304 Ressourcen auf einer Edge-Plattform in Gruppen kategorisieren. Eine erste Gruppe kann zum Beispiel oberste Priorität haben, wobei die Ressourcenverwaltungssteuerung 304 eine Telemetrieüberwachungsfrequenz, die mit jeweiligen der Ressourcen der ersten Gruppe assoziiert ist, geringfügig anpassen (z. B. reduzieren) kann, eine zweite Gruppe kann zum Beispiel mittlere Priorität haben, wobei die Ressourcenverwaltungssteuerung 304 eine Telemetrieüberwachungsfrequenz, die mit jeweiligen der Ressourcen der zweiten Gruppe assoziiert ist, anpassen (z. B. reduzieren) kann, und eine dritte Gruppe kann zum Beispiel niedrige Priorität haben, wobei die Ressourcenverwaltungssteuerung 304 eine Telemetrieüberwachungsfrequenz, die mit jeweiligen der Ressourcen der dritten Gruppe assoziiert ist, anhalten kann. Bei Block 616 verringert die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 die Überwachungsrate von SLAs, die mit Arbeitslasten assoziiert sind, die der Edge-Plattform zugeordnet sind, um die Schätzwerte zu erreichen. Bei Block 618 verringert die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 die Verarbeitungsressourcen, die beim Verarbeiten von Telemetriedaten aufgewandt werden, um die Schätzwerte zu erreichen. Zusätzliche oder alternative beispielhafte Techniken zum Skalieren der Orchestrierung auf Edge-Plattformen werden in Verbindung mit 3 im Detail beschrieben.
-
7 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen 414 darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator 202 von 2 und 3 und/oder allgemeiner die Edge-Plattform 200 von 2 zu implementieren, um Telemetriedaten auszulagern, die auf einem anderen Computer zu verarbeiten sind, um grobe Orchestrierungsergebnisse zu erhalten. Die maschinenlesbaren Anweisungen 414 beginnen bei Block 702, wobei die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 ein Verarbeiten von Telemetriedaten auf der Edge-Plattform abschaltet (z. B. deaktiviert, beendet usw.).
-
Im Beispiel von 7, bei Block 704, sendet die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 Telemetriedaten von der Edge-Plattform an einen anderen Computer (z. B. einen Beschleuniger und/oder eine entfernte Edge-Plattform), um grobe Orchestrierungsergebnisse zu erhalten. Block 704 kann zum Beispiel enthalten, dass die Orchestratorschnittstelle 302 Telemetriedaten von der Edge-Plattform an einen anderen Computer sendet, um grobe Orchestrierungsergebnisse zu erhalten. Bei Block 706 überwacht die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 den zusätzlichen Computer (z. B. den Beschleuniger und/oder die entfernte Edge-Plattform) auf die groben Orchestrierungsergebnisse. Bei Block 708 ermittelt die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202, ob die groben Orchestrierungsergebnisse vom zusätzlichen Computer empfangen worden sind.
-
Im in 7 veranschaulichten Beispiel, als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass die groben Orchestrierungsergebnisse nicht vom zusätzlichen Computer empfangen wurden (Block 708: NEIN), fahren die maschinenlesbaren Anweisungen 414 mit Block 706 fort. Als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass die groben Orchestrierungsergebnisse vom zusätzlichen Computer empfangen wurden (Block 708: JA), fahren die maschinenlesbaren Anweisungen 414 mit Block 710 fort. Bei Block 710 ermittelt die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202, ob die den Orchestrierungskomponenten zugewiesenen Ressourcen den sekundären Schwellenwert erreichen.
-
Im in 7 veranschaulichten Beispiel, als Reaktion darauf, dass die Ressourcenverwaltungssteuerung 304 ermittelt, dass die den Orchestrierungskomponenten zugewiesenen Ressourcen den sekundären Schwellenwert erreichen (Block 710: JA), fahren die maschinenlesbaren Anweisungen 414 mit Block 712 fort. Bei Block 712 lagert der Orchestrator 202 Telemetriedaten aus, die an einem anderen Computer zu verarbeiten sind, um feine Orchestrierungsergebnisse zu erhalten. Nach Block 712 kehren die maschinenlesbaren Anweisungen 414 zu den maschinenlesbaren Anweisungen 400 bei Block 426 zurück.
-
Zu Block 710 zurückkehrend, als Reaktion darauf, dass die Ressourcenverwaltungssteuerung 304 ermittelt, dass die den Orchestrierungskomponenten zugewiesenen Ressourcen den sekundären Schwellenwert nicht erreichen (Block 710: NEIN), fahren die maschinenlesbaren Anweisungen 414 mit Block 714 fort. Bei Block 714 schätzt die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 die Ressourcen ab, die den Orchestrierungskomponenten auf der Edge-Plattform zuzuweisen sind. Bei Block 716 ermittelt die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 feine Orchestrierungsergebnisse auf Grundlage der groben Orchestrierungsergebnisse. Bei Block 718 plant der Arbeitslastenplaner 306 und/oder allgemeiner der Orchestrator 202 Arbeitslasten, die auf der Edge-Plattform auf Grundlage der Orchestrierungsergebnisse auszuführen sind. Nach Block 718 kehren die maschinenlesbaren Anweisungen 414 zu den maschinenlesbaren Anweisungen 400 bei Block 426 zurück.
-
8 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen 416, 712 darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator 202 von 2 und 3 und/oder allgemeiner die Edge-Plattform 200 von 2 zu implementieren, um Telemetriedaten auszulagern, die auf einem anderen Computer zu verarbeiten sind, um feine Orchestrierungsergebnisse zu erhalten. Die maschinenlesbaren Anweisungen 416, 712 beginnen bei Block 802, wo die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 ermittelt, ob die Edge-Plattform Beschleuniger enthält. Als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass die Edge-Plattform keine Beschleuniger enthält (Block 802: NEIN), fahren die maschinenlesbaren Anweisungen 416, 712 mit Block 804 fort.
-
Im Beispiel von 8, bei Block 804, schaltet (z. B. deaktiviert, beendet usw.) die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 ein Verarbeiten von Telemetriedaten und Orchestrierungsaufgaben auf der Edge-Plattform ab. Bei Block 806 sendet die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 Telemetriedaten ein anderer Computer, um feine Orchestrierungsergebnisse zu erhalten. Block 806 kann zum Beispiel enthalten, dass die Orchestratorschnittstelle 302 Telemetriedaten von der Edge-Plattform an einen anderen Computer sendet, um feine Orchestrierungsergebnisse zu erhalten. Bei Block 808 überwacht die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 den zusätzlichen Computer auf feine Orchestrierungsergebnisse. Bei Block 810 ermittelt die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202, ob feine Orchestrierungsergebnisse vom zusätzlichen Computer empfangen worden sind.
-
Im veranschaulichten Beispiel von 8, als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass keine feinen Orchestrierungsergebnisse vom zusätzlichen Computer empfangen wurden (Block 810: NEIN), fahren die maschinenlesbaren Anweisungen 416, 712 mit Block 808 fort. Als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass feine Orchestrierungsergebnisse vom zusätzlichen Computer empfangen wurden (Block 810: JA), fahren die maschinenlesbaren Anweisungen 416, 712 mit Block 812 fort. Bei Block 812 plant der Arbeitslastenplaner 306 und/oder allgemeiner der Orchestrator 202 Arbeitslasten, die auf der Edge-Plattform auf Grundlage der feinen Orchestrierungsergebnisse auszuführen sind. Nach Block 812 kehren die maschinenlesbaren Anweisungen 416, 712 zu den maschinenlesbaren Anweisungen 400 bei Block 426 zurück und/oder die maschinenlesbaren Anweisungen 414 kehren zu den maschinenlesbaren Anweisungen 400 bei Block 426 zurück.
-
Zu Block 802 zurückkehrend, als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass die Edge-Plattform Beschleuniger enthält (Block 802: JA), fahren die maschinenlesbaren Anweisungen 416, 712 mit Block 814 fort. Bei Block 814 wird die Ressourcenverwaltungssteuerung 304 und/oder allgemeiner der Orchestrator 202 auf eine beschleunigerbasierte (z. B. statistikbasierte) Technik der Orchestrierung neu konfiguriert. Beispielsweise kann die Ressourcenverwaltungssteuerung 304 eine Orchestrierung unter Einsatz von Rechenkernels ausführen. Bei Block 816 sendet die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 Telemetriedaten an einen anderen Computer, um grobe Orchestrierungsergebnisse zu erhalten. Block 816 kann zum Beispiel enthalten, dass die Orchestratorschnittstelle 302 Telemetriedaten von der Edge-Plattform an einen anderen Computer sendet, um grobe Orchestrierungsergebnisse zu erhalten. Bei Block 818 überwacht die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 den zusätzlichen Computer auf grobe Orchestrierungsergebnisse. Bei Block 818 ermittelt die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202, ob grobe Orchestrierungsergebnisse vom zusätzlichen Computer empfangen worden sind.
-
Im veranschaulichten Beispiel von 8, als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass keine groben Orchestrierungsergebnisse vom zusätzlichen Computer empfangen wurden (Block 820: NEIN), fahren die maschinenlesbaren Anweisungen 416, 712 mit Block 818 fort. Als Reaktion darauf, dass die Orchestratorschnittstelle 302 ermittelt, dass grobe Orchestrierungsergebnisse vom zusätzlichen Computer empfangen wurden (Block 820: JA), fahren die maschinenlesbaren Anweisungen 416, 712 mit Block 822 fort. Bei Block 822 plant der Arbeitslastenplaner 306 und/oder allgemeiner der Orchestrator 202 Arbeitslasten, die auf der Edge-Plattform auf Grundlage der groben Orchestrierungsergebnisse auszuführen sind. Nach Block 822 kehren die maschinenlesbaren Anweisungen 416, 712 zu den maschinenlesbaren Anweisungen 400 bei Block 426 zurück und/oder die maschinenlesbaren Anweisungen 414 kehren zu den maschinenlesbaren Anweisungen 400 bei Block 426 zurück.
-
9 ist ein Ablaufdiagramm, das beispielhafte maschinenlesbare Anweisungen 900 darstellt, die ausgeführt werden können, um den beispielhaften Orchestrator 202 von 2 und 3 und/oder allgemeiner die Edge-Plattform 200 von 2 zu implementieren, um eine Verarbeitung von Telemetriedaten auf einer Edge-Plattform auf Grundlage einer Temperatur an der Edge-Plattform zu steuern. Die maschinenlesbaren Anweisungen 900 beginnen bei Block 902, wo die thermale Steuerung 308 und/oder allgemeiner der Orchestrator 202 ermittelt, ob der Orchestrator 202 für arbeitslastspezifisches thermales Ausgleichen und/oder Planen ausgelegt ist.
-
Im Beispiel von 9, als Reaktion darauf, dass die thermale Steuerung 308 ermittelt, dass der Orchestrator 202 nicht für arbeitslastspezifisches thermales Ausgleichen ausgelegt ist (Block 902: NEIN), fahren die maschinenlesbaren Anweisungen 900 mit Block 904 fort. Bei Block 904 überwacht die Orchestratorschnittstelle 302 und/oder allgemeiner der Orchestrator 202 die Temperatur der Edge-Plattform und/oder der Orchestrierungskomponenten. Bei Block 906 ermittelt die thermale Steuerung 308 und/oder allgemeiner der Orchestrator 202, ob die Temperatur der Edge-Plattform und/oder der Orchestrierungskomponenten einen Temperaturschwellenwert überschreitet. Der Temperaturschwellenwert kann zum Beispiel eine Temperatur sein, die vom Edge-Dienstanbieter, einem OEM, einem Siliziumanbieter usw. als „extrem“ eingestuft wurde.
-
Im Beispiel von 9, als Reaktion darauf, dass die thermale Steuerung 308 ermittelt, dass die Temperatur der Edge-Plattform und/oder der Orchestrierungskomponenten einen Temperaturschwellenwert nicht überschreitet (Block 906: NEIN), fahren die maschinenlesbaren Anweisungen 900 mit Block 904 fort. Als Reaktion darauf, dass die thermale Steuerung 308 ermittelt, dass die Temperatur der Edge-Plattform und/oder der Orchestrierungskomponenten einen Temperaturschwellenwert überschreitet (Block 906: JA), fahren die maschinenlesbaren Anweisungen 900 mit Block 908 fort. Bei Block 908 erhöht die thermale Steuerung 308 und/oder allgemeiner der Orchestrator 202 die aktive Kühlung an der Edge-Plattform. Bei Block 910 reduziert die thermale Steuerung 308 und/oder allgemeiner der Orchestrator 202 die Rechenzustände an der Edge-Plattform. Die thermale Steuerung 308 kann zum Beispiel den Orchestrator 202 und/oder allgemeiner die Edge-Plattform 200 auslegen, mit einer niedrigeren Taktfrequenz (z. B. Rate) zu arbeiten.
-
Im Beispiel von 9, bei Block 912, ermittelt die thermale Steuerung 308 und/oder allgemeiner der Orchestrator 202, ob mit dem Betrieb fortzufahren ist. Bedingungen, die zum Beispiel bewirken könnten, dass die thermale Steuerung 308 den Betrieb einstellt, können einen Energieverlust, eine Neukonfiguration ohne Bereitstellung aktiver und/oder adaptiver Kühlung enthalten. Als Reaktion darauf, dass die thermale Steuerung 308 ermittelt, mit dem Betrieb fortzufahren (Block 912: JA), fahren die maschinenlesbaren Anweisungen 900 mit Block 902 fort. Als Reaktion darauf, dass die thermale Steuerung 308 ermittelt, nicht mit dem Betrieb fortzufahren (Block 912: NEIN), werden die maschinenlesbaren Anweisungen 900 beendet.
-
Zu Block 902 zurückkehrend, als Reaktion darauf, dass die thermale Steuerung 308 ermittelt, dass der Orchestrator 202 für arbeitslastspezifisches thermales Ausgleichen ausgelegt ist (Block 902: JA), fahren die maschinenlesbaren Anweisungen 900 mit Block 914 fort. Bei Block 914 ermittelt die thermale Steuerung 308 und/oder allgemeiner der Orchestrator 202 erwünschte Leistungsmetriken (z. B. Leistungskennzahlen usw.) für Arbeitslasten, die einer Edge-Plattform auf Grundlage von SLAs zugeordnet sind. Bei Block 916 generiert die thermale Steuerung 308 und/oder allgemeiner der Orchestrator 202 ein Modell auf Grundlage eines Arbeitslastaufwands der der Edge-Plattform zugeordneten Arbeitslasten.
-
Im Beispiel von 9, bei Block 918, ermittelt der Arbeitslastenplaner 306 und/oder allgemeiner der Orchestrator 202 einen Kandidatenplan für die der Edge-Plattform zugeordneten Arbeitslasten. Bei Block 920 ermittelt der Arbeitslastenplaner 306 und/oder allgemeiner der Orchestrator 202, ob der Kandidatenplan SLAs der der Edge-Plattform zugeordneten Arbeitslasten erfüllt. Als Reaktion darauf, dass der Arbeitslastenplaner 306 ermittelt, dass der Kandidatenplan nicht mindestens eine SLA der der Edge zugeordneten Arbeitslasten erfüllt (Block 920: NEIN), fahren die maschinenlesbaren Anweisungen 900 mit Block 918 fort. Als Reaktion darauf, dass der Arbeitslastenplaner 306 ermittelt, dass der Kandidatenplan die SLAs der der Edge zugeordneten Arbeitslasten erfüllt (Block 920: JA), fahren die maschinenlesbaren Anweisungen 900 mit Block 922 fort.
-
Im illustrierten Beispiel von 9, bei Block 922, passt die thermale Steuerung 308 und/oder allgemeiner der Orchestrator 202 eine aktive Kühlung und/oder Rechenbedingungen an der Edge-Plattform und/oder der Orchestrierungsressourcen auf Grundlage des Kandidatenplans. Bei Block 924 plant der Arbeitslastenplaner 306 und/oder allgemeiner der Orchestrator 202 die Arbeitslasten, die der Edge-Plattform auf Grundlage des Plankandidaten zugeordnet sind. Nach Block 924 fahren die maschinenlesbaren Anweisungen 900 mit Block 912 fort.
-
10 ist ein Blockdiagramm einer beispielhaften Verarbeitungsplattform, die strukturiert ist, die Anweisungen von 4, 5, 6, 7, 8 und 9 auszuführen, um den Orchestrator 202 von 2 und 3 zu implementieren. Die Prozessorplattform 1000 kann beispielsweise ein Server, ein Personalcomputer, ein Arbeitsplatzrechner, eine selbstlernende Maschine (z. B. ein neuronales Netzwerk), eine mobile Vorrichtung (z. B. ein Mobiltelefon, ein Smartphone, ein Tablet wie ein iPadTM), ein Organizer (PDA), ein Internetgerät, ein DVD-Player, ein CD-Player, ein digitaler Videorekorder, ein Blu-ray-Player, eine Spielekonsole, ein persönlicher Videorekorder, eine Set-Top-Box, ein Kopfhörer oder eine andere tragbare Vorrichtung oder ein beliebiger anderer Typ von Rechenvorrichtung sein.
-
Die Prozessorplattform 1000 des illustrierten Beispiels enthält einen Prozessor 1012. Der Prozessor 1012 des illustrierten Beispiels ist Hardware. Der Prozessor 1012 kann zum Beispiel durch einen oder mehrere integrierte Schaltkreise, Logikschaltkreise, Mikroprozessoren, GPUs, DSPs oder Steuerungen einer beliebigen gewünschten Familie oder von einem beliebigen gewünschten Hersteller implementiert sein. Der Hardwareprozessor 1012 kann eine halbleiterbasierte (z. B. siliziumbasierte) Vorrichtung sein. In diesem Beispiel implementiert der Prozessor 1012 den beispielhaften Orchestrator 202, die beispielhafte Fähigkeitssteuerung 204, die beispielhafte Telemetriesteuerung 206, die beispielhafte EP-Datenbank 208, die beispielhafte(n) Ressource(n) 210 und/oder allgemeiner die beispielhafte Edge-Plattform 200 und/oder die beispielhafte Orchestratorschnittstelle 302, die beispielhafte Ressourcenverwaltungssteuerung 304, den beispielhaften Arbeitslastenplaner 306, die beispielhafte thermale Steuerung 308, die beispielhafte Orchestrierungsdatenbank 310 und/oder allgemeiner den beispielhaften Orchestrator 202 von 2 und 3.
-
Der Prozessor 1012 des veranschaulichten Beispiels enthält einen lokalen Arbeitsspeicher 1013 (z. B. einen Zwischenspeicher). Der Prozessor 1012 des veranschaulichten Beispiels steht über einen Bus 1018 in Kommunikation mit einem Hauptarbeitsspeicher, der einen flüchtigen Arbeitsspeicher 1014 und einen nichtflüchtigen Arbeitsspeicher 1016 enthält. Der flüchtige Arbeitsspeicher 1014 kann durch synchronen dynamischen Arbeitsspeicher mit wahlfreiem Zugriff (SDRAM), dynamischen Arbeitsspeicher mit wahlfreiem Zugriff (DRAM), dynamischen RAMBUS®-Arbeitsspeicher mit wahlfreiem Zugriff (RDRAM®) und/oder einen beliebigen anderen Typ von Arbeitsspeichervorrichtung mit wahlfreiem Zugriff implementiert sein. Der nichtflüchtige Arbeitsspeicher 1016 kann durch Flashspeicher und/oder einen beliebigen anderen Typ von Arbeitsspeichervorrichtung implementiert sein. Zugriff auf den Hauptarbeitsspeicher 1014, 1016 wird durch eine Arbeitsspeichersteuerung gesteuert.
-
Die Prozessorplattform 1000 des illustrierten Beispiels enthält auch einen Schnittstellenschaltkreis 1020. Der Schnittstellenschaltkreis 1020 kann durch einen beliebigen Typ von Schnittstellenstandard, wie einer Ethernet-Schnittstelle, einem Universal Serial Bus (USB), einer Bluetooth®-Schnittstelle, einer Nahfeldkommunikations(NFC)-Schnittstelle und/oder einer PCI-Express-Schnittstelle implementiert sein.
-
Im veranschaulichten Beispiel sind eine oder mehrere Eingabevorrichtungen 1022 mit dem Schnittstellenschaltkreis 1020 verbunden. Die Eingabevorrichtung(en) 1022 ermöglicht bzw. ermöglichen einem Benutzer, Daten und/oder Befehle in den Prozessor 1012 einzugeben. Die Eingabevorrichtung(en) kann bzw. können beispielsweise durch einen Audiosensor, ein Mikrofon, eine Kammer (Standbild oder Video), eine Tastatur, eine Taste, eine Maus, einen Berührungsbildschirm, ein Tastfeld, einen Trackball, Isopoint und/oder ein Spracherkennungssystem implementiert sein.
-
Eine oder mehrere Ausgabevorrichtungen 1024 sind ebenfalls mit dem Schnittstellenschaltkreis 1020 des veranschaulichten Beispiels verbunden. Die Ausgabevorrichtungen 1024 können zum Beispiel durch Anzeigevorrichtungen (z. B. eine lichtemittierende Diode (LED), eine organische lichtemittierende Diode (OLED), eine Flüssigkristallanzeige (LCD), eine Kathodenstrahlröhrenanzeige (CRT), eine ortsfeste Schaltanzeige (IPS-Anzeige), einen Berührungsbildschirm usw.), eine taktile Ausgabevorrichtung, einen Drucker und/oder einen Lautsprecher implementiert sein. Der Schnittstellenschaltkreis 1020 des veranschaulichten Beispiels enthält deshalb üblicherweise eine Grafiktreiberkarte, einen Grafiktreiberchip und/oder einen Grafiktreiberprozessor.
-
Der Schnittstellenschaltkreis 1020 des veranschaulichten Beispiels enthält auch eine Kommunikationsvorrichtung wie einen Sender, einen Empfänger, ein Modem, ein lokales Gateway, einen drahtlosen Zugangspunkt und/oder eine Netzwerkschnittstelle, um einen Austausch von Daten mit externen Maschinen (z. B. Rechenvorrichtungen einer beliebigen Art) über ein Netzwerk 1026 zu ermöglichen. Die Kommunikation kann beispielsweise über eine Ethernet-Verbindung, eine digitale Teilnehmeranschlussverbindung (DSL-Verbindung), eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein drahtloses Sichtverbindungssystem, ein Mobilfunktelefonsystem usw. erfolgen.
-
Die Prozessorplattform 1000 des veranschaulichten Beispiels enthält auch eine oder mehrere Massenspeichervorrichtungen 1028 zum Speichern von Software und/oder Daten. Beispiele derartiger Massenspeichervorrichtungen 1028 enthalten Diskettenlaufwerke, Festplattenlaufwerke, Compact-Disk-Laufwerke, Blu-ray-Plattenlaufwerke, redundante Anordnungssysteme unabhängiger Platten (RAID-Systeme) und Digital-Versatile-Disk(DVD)-Laufwerke.
-
Die maschinenausführbaren Anweisungen 1032 der 4, 5, 6, 7, 8 und 9 können in der Massenspeichervorrichtung 1028, im flüchtigen Arbeitsspeicher 1014, im nichtflüchtigen Arbeitsspeicher 1016 und/oder auf einem entfernbaren nicht transitorischen computerlesbaren Speichermedium wie einer CD oder DVD gespeichert sein.
-
Aus dem Vorstehenden wird klar sein, dass beispielhafte Verfahren, Vorrichtungen und Fabrikate offenbart wurden, die eine Verarbeitung von Telemetriedaten auf einer Edge-Plattform steuern. Hierin offenbarte Beispiele enthalten eine dezentralisierte Orchestrierungssteuerebene, die die umfangreiche Wertebene einbindet, die bei Edge- und/oder Cloud-Computing implizit ist. Hierin offenbarte Beispiele werden angepasst, um die Orchestrierung und Telemetrie einsatzsynchron, bedarfssynchron und praxissynchron zu halten. Hierin offenbarte Beispiele vereinfachen eine Integration von heterogenen Rechenfunktionen (z. B. CPUs, GPUs, FPGAs, VPUs usw.) durch Entkoppeln der Orchestrierungssteuerungsebene von den Ressourcen, auch in unterbrochen mit Strom versorgten Infrastrukturen oder Infrastrukturen mit spärlichen Ressourcen. Hierin offenbarte Beispiele enthalten ein Framework, das ermöglicht, dass Telemetrie und Orchestrierung als Dienste (z. B. Telemetrie-as-a-Service (TaaS) und/oder Orchestrierung-as-a-Service (OaaS)) implementiert werden, die bei Bedarf bereitgestellt und geformt werden und, wo möglich, beschleunigt werden.
-
Die offenbarten Verfahren, Einrichtungen und Fabrikate verbessern die Effizienz einer Verwendung einer Rechenvorrichtung durch Anpassen der Rechenressourcen, die zum Orchestrieren von Arbeitslasten an einer Edge-Plattform aufgewandt werden, auf Grundlage der verfügbaren Energie und/oder thermalen Pegel der Edge-Plattform. Hierin offenbarte Beispiele reduzieren die rechnerische Last, die mit dem Verarbeiten von Arbeitslasten auf einer Edge-Plattform assoziiert ist, durch Auslagern von rechenintensiveren Abschnitten von Orchestrierungsaufgaben an entfernte Computer und Erhalten von Orchestrierungsergebnissen von diesen entfernten Computern. Die offenbarten Verfahren, Einrichtungen und Fabrikate verbessern die Effizienz der Verwendung einer Rechenvorrichtung durch Reduzieren des Hardware-Mehraufwands, der mit dem Orchestrieren von Arbeitslasten auf einer Edge-Plattform verbunden ist, durch Reduzieren der rechnerischen Belastung, die mit dem Orchestrieren von Arbeitslasten auf einer Edge-Plattform verbunden ist, und durch Reduzieren des Energieverbrauchs, der mit dem Orchestrieren von Arbeitslasten auf einer Edge-Plattform verbunden ist. Die offenbarten Verfahren, Einrichtungen und Fabrikate sind dementsprechend auf eine oder mehrere Verbesserungen des Funktionierens eines Computers gerichtet.
-
Es werden hierin beispielhafte Verfahren, Einrichtungen, Systeme und Fabrikate zum Steuern einer Verarbeitung von Telemetriedaten auf einer Edge-Plattform offenbart. Weitere Beispiele und Kombinationen daraus enthalten Folgendes:
-
Beispiel 1 enthält eine Einrichtung zum Steuern einer Verarbeitung von Telemetriedaten auf einer Edge-Plattform, wobei die Einrichtung eine Orchestratorschnittstelle, um als Reaktion auf eine Ressourcenmenge, die einem Orchestrator zugewiesen ist, eine Arbeitslast auf der Edge-Plattform zu orchestrieren, die einen ersten Schwellenwert erreicht, mit dem Orchestrator assoziierte Telemetriedaten an einen Computer zu senden, um ein erstes Orchestrierungsergebnis mit einer ersten Granularität zu erhalten, eine Ressourcenverwaltungssteuerung, um ein zweites Orchestrierungsergebnis mit einer zweiten Granularität zu ermitteln, um die Arbeitslast auf der Edge-Plattform zu orchestrieren, wobei die zweite Granularität feiner als die erste Granularität ist, und eine Planungseinheit umfasst, um eine der Edge-Plattform zugeordnete Arbeitslast auf Grundlage des zweiten Orchestrierungsergebnisses zu planen.
-
Beispiel 2 enthält die Einrichtung von Beispiel 1, wobei die Ressourcenverwaltungssteuerung ausgelegt ist, die dem Orchestrator zugewiesene Ressourcenmenge mit mit dem Orchestrator assoziierten Konfigurationseinstellungen zu vergleichen, zu ermitteln, ob die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, und als Reaktion darauf, dass die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, zu ermitteln, ob die dem Orchestrator zugewiesene Ressourcenmenge einen zweiten Schwellenwert erreicht.
-
Beispiel 3 enthält die Einrichtung von Beispiel 2, wobei die Konfigurationseinstellungen eine Ressourcenmenge identifizieren, die dem Orchestrator auf einem Energiepegel zugewiesen werden können.
-
Beispiel 4 enthält die Einrichtung von Beispiel 2, wobei die Konfigurationseinstellungen eine Ressourcenmenge identifizieren, die dem Orchestrator bei einem thermalen Zustand zugewiesen werden können.
-
Beispiel 5 enthält die Vorrichtung von Beispiel 1, wobei die Orchestratorschnittstelle ausgelegt ist, die Telemetriedaten zu sammeln und als Reaktion darauf, dass die Ressourcenmenge, die dem Orchestrator zugewiesen ist, einen zweiten Schwellenwert erreicht, die mit dem Orchestrator assoziierten Telemetriedaten an einen Computer zu senden, um ein drittes Orchestrierungsergebnis mit der zweiten Granularität zu erhalten.
-
Beispiel 6 enthält die Einrichtung von Beispiel 5, wobei der zweite Schwellenwert unter dem ersten Schwellenwert liegt.
-
Beispiel 7 enthält die Einrichtung von Beispiel 1, wobei die Ressourcenmenge eine erste Ressourcenmenge ist und die Ressourcenverwaltungssteuerung ausgelegt ist, als Reaktion darauf, dass die erste dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert nicht erreicht, eine zweite Ressourcenmenge abzuschätzen, die dem Orchestrator zuzuweisen ist, und die erste dem Orchestrator zugewiesene Ressourcenmenge zu skalieren, sodass sie die zweite Ressourcenmenge erfüllt, wobei die zweite Ressourcenmenge einer Ressourcenmenge entspricht, um Leistungsindikatoren zu erfüllen, die mit der Arbeitslast assoziiert sind.
-
Beispiel 8 enthält die Einrichtung von Beispiel 1, wobei die Ressourcenverwaltungssteuerung ausgelegt ist, die dem Orchestrator zugewiesene Ressourcenmenge auf Grundlage einer mit jeweiligen der Ressourcen assoziierten Prioritätsstufe zu skalieren.
-
Beispiel 9 enthält die Einrichtung von Beispiel 1, wobei die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, wenn die Ressourcenmenge kleiner oder gleich dem ersten Schwellenwert ist.
-
Beispiel 10 enthält die Einrichtung von Beispiel 1, wobei die Orchestratorschnittstelle ausgelegt ist, eine Temperatur der Edge-Plattform zu überwachen.
-
Beispiel 11 enthält die Einrichtung von Beispiel 10, die ferner eine thermische Steuerung enthält, um als Reaktion darauf, dass die Temperatur der Edge-Plattform eine Schwellentemperatur überschreitet, eine Kühlung an der Edge-Plattform zu erhöhen und Rechenzustände von Ressourcen an der Edge-Plattform zu reduzieren.
-
Beispiel 12 enthält ein nicht transitorisches computerlesbares Speichermedium, das Daten umfasst, die in ausführbare Anweisungen konfiguriert werden können und die, wenn sie konfiguriert und ausgeführt werden, mindestens einen Prozessor veranlassen, als Reaktion auf eine Ressourcenmenge, die einem Orchestrator zugewiesen ist, umfasst, eine Arbeitslast auf einer Edge-Plattform zu orchestrieren, die einen ersten Schwellenwert erreicht, mit dem Orchestrator assoziierte Telemetriedaten an einen Computer zu senden, um ein erstes Orchestrierungsergebnis mit einer ersten Granularität zu erhalten, ein zweites Orchestrierungsergebnis mit einer zweiten Granularität zu ermitteln, um die Arbeitslast auf der Edge-Plattform zu orchestrieren, wobei die zweite Granularität feiner als die erste Granularität ist, und eine der Edge-Plattform zugeordnete Arbeitslast auf Grundlage des zweiten Orchestrierungsergebnisses zu planen.
-
Beispiel 13 enthält das nicht transitorische computerlesbare Speichermedium von Beispiel 12, wobei die Anweisungen, wenn sie konfiguriert und ausgeführt werden, den mindestens einen Prozessor veranlassen, die dem Orchestrator zugewiesene Ressourcenmenge mit mit dem Orchestrator assoziierten Konfigurationseinstellungen zu vergleichen, zu ermitteln, ob die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, und als Reaktion darauf, dass die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, zu ermitteln, ob die dem Orchestrator zugewiesene Ressourcenmenge einen zweiten Schwellenwert erreicht.
-
Beispiel 14 enthält das nicht transitorische computerlesbare Speichermedium von Beispiel 13, wobei die Konfigurationseinstellungen eine Ressourcenmenge identifizieren, die dem Orchestrator auf einem Energiepegel zugewiesen werden können.
-
Beispiel 15 enthält das nicht transitorische computerlesbare Speichermedium von Beispiel 13, wobei die Konfigurationseinstellungen eine Ressourcenmenge identifizieren, die dem Orchestrator bei einem thermalen Zustand zugewiesen werden können.
-
Beispiel 16 enthält das nicht transitorische computerlesbare Speichermedium von Beispiel 12, wobei die Anweisungen, wenn sie konfiguriert und ausgeführt werden, den mindestens einen Prozessor veranlassen, die Telemetriedaten zu sammeln und als Reaktion darauf, dass die Ressourcenmenge, die dem Orchestrator zugewiesen ist, einen zweiten Schwellenwert erreicht, die mit dem Orchestrator assoziierten Telemetriedaten an einen Computer zu senden, um ein drittes Orchestrierungsergebnis mit der zweiten Granularität zu erhalten.
-
Beispiel 17 enthält das nicht transitorische computerlesbare Speichermedium von Beispiel 16, wobei der zweite Schwellenwert unter dem ersten Schwellenwert liegt.
-
Beispiel 18 enthält das nicht transitorische computerlesbare Speichermedium von Beispiel 12, wobei die Ressourcenmenge eine erste Ressourcenmenge ist und wobei die Anweisungen, wenn sie konfiguriert und ausgeführt werden, den mindestens einen Prozessor veranlassen, als Reaktion darauf, dass die erste dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert nicht erreicht, eine zweite Ressourcenmenge abzuschätzen, die dem Orchestrator zuzuweisen ist, und die erste dem Orchestrator zugewiesene Ressourcenmenge zu skalieren, sodass sie die zweite Ressourcenmenge erfüllt, wobei die zweite Ressourcenmenge einer Ressourcenmenge entspricht, um Leistungsindikatoren zu erfüllen, die mit der Arbeitslast assoziiert sind.
-
Beispiel 19 enthält das nicht transitorische computerlesbare Speichermedium von Beispiel 12, wobei die Anweisungen, wenn sie konfiguriert und ausgeführt werden, den mindestens einen Prozessor veranlassen, die dem Orchestrator zugewiesene Ressourcenmenge auf Grundlage einer mit jeweiligen der Ressourcen assoziierten Prioritätsstufe zu skalieren.
-
Beispiel 20 enthält das nicht transitorische computerlesbare Speichermedium von Beispiel 12, wobei die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, wenn die Ressourcenmenge kleiner oder gleich dem ersten Schwellenwert ist.
-
Beispiel 21 enthält das nicht transitorische computerlesbare Speichermedium von Beispiel 12, wobei die Anweisungen, wenn sie ausgeführt werden, den mindestens einen Prozessor veranlassen, eine Temperatur der Edge-Plattform zu überwachen.
-
Beispiel 22 enthält das nicht transitorische computerlesbare Speichermedium von Beispiel 21, wobei die Anweisungen, wenn sie konfiguriert und ausgeführt werden, den mindestens einen Prozessor veranlassen, als Reaktion darauf, dass die Temperatur der Edge-Plattform eine Schwellentemperatur überschreitet, eine Kühlung an der Edge-Plattform zu erhöhen und Rechenzustände von Ressourcen an der Edge-Plattform zu reduzieren.
-
Beispiel 23 enthält eine Einrichtung zum Steuern einer Verarbeitung von Telemetriedaten auf einer Edge-Plattform, wobei die Einrichtung Mittel zum Anbinden über eine Schnittstelle, um als Reaktion auf eine Ressourcenmenge, die einem Orchestrator zugewiesen ist, eine Arbeitslast auf der Edge-Plattform zu orchestrieren, die einen ersten Schwellenwert erreicht, mit dem Orchestrator assoziierte Telemetriedaten an einen Computer zu senden, um ein erstes Orchestrierungsergebnis mit einer ersten Granularität zu erhalten, Mittel zum Verwalten von Ressourcen, um ein zweites Orchestrierungsergebnis mit einer zweiten Granularität zu ermitteln, um die Arbeitslast auf der Edge-Plattform zu orchestrieren, wobei die zweite Granularität feiner als die erste Granularität ist, und Mittel zum Planen umfasst, um eine der Edge-Plattform zugeordnete Arbeitslast auf Grundlage des zweiten Orchestrierungsergebnisses zu planen.
-
Beispiel 24 enthält die Einrichtung von Beispiel 23, wobei das Mittel zum Verwalten von Ressourcen ausgelegt ist, die dem Orchestrator zugewiesene Ressourcenmenge mit mit dem Orchestrator assoziierten Konfigurationseinstellungen zu vergleichen, zu ermitteln, ob die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, und als Reaktion darauf, dass die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, zu ermitteln, ob die dem Orchestrator zugewiesene Ressourcenmenge einen zweiten Schwellenwert erreicht.
-
Beispiel 25 enthält die Einrichtung von Beispiel 24, wobei die Konfigurationseinstellungen eine Ressourcenmenge identifizieren, die dem Orchestrator auf einem Energiepegel zugewiesen werden können.
-
Beispiel 26 enthält die Einrichtung von Beispiel 24, wobei die Konfigurationseinstellungen eine Ressourcenmenge identifizieren, die dem Orchestrator bei einem thermalen Zustand zugewiesen werden können.
-
Beispiel 27 enthält die Vorrichtung von Beispiel 23, wobei das Mittel zum Anbinden über eine Schnittstelle ausgelegt ist, die Telemetriedaten zu sammeln und als Reaktion darauf, dass die Ressourcenmenge, die dem Orchestrator zugewiesen ist, einen zweiten Schwellenwert erreicht, die mit dem Orchestrator assoziierten Telemetriedaten an einen Computer zu senden, um ein drittes Orchestrierungsergebnis mit der zweiten Granularität zu erhalten.
-
Beispiel 28 enthält die Einrichtung von Beispiel 27, wobei der zweite Schwellenwert unter dem ersten Schwellenwert liegt.
-
Beispiel 29 enthält die Einrichtung von Beispiel 23, wobei die Ressourcenmenge eine erste Ressourcenmenge ist und das Mittel zum Verwalten von Ressourcen ausgelegt ist, als Reaktion darauf, dass die erste dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert nicht erreicht, eine zweite Ressourcenmenge abzuschätzen, die dem Orchestrator zuzuweisen ist, und die erste dem Orchestrator zugewiesene Ressourcenmenge zu skalieren, sodass sie die zweite Ressourcenmenge erfüllt, wobei die zweite Ressourcenmenge einer Ressourcenmenge entspricht, um Leistungsindikatoren zu erfüllen, die mit der Arbeitslast assoziiert sind.
-
Beispiel 30 enthält die Einrichtung von Beispiel 23, wobei das Mittel zum Verwalten von Ressourcen ausgelegt ist, die dem Orchestrator zugewiesene Ressourcenmenge auf Grundlage einer mit jeweiligen der Ressourcen assoziierten Prioritätsstufe zu skalieren.
-
Beispiel 31 enthält die Einrichtung von Beispiel 23, wobei die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, wenn die Ressourcenmenge kleiner oder gleich dem ersten Schwellenwert ist.
-
Beispiel 32 enthält die Einrichtung von Beispiel 23, wobei das Mittel zum Anbinden über eine Schnittstelle ausgelegt ist, eine Temperatur der Edge-Plattform zu überwachen.
-
Beispiel 33 enthält die Einrichtung von Beispiel 32, die ferner ein Mittel zum Regeln von Temperaturbedingungen enthält, um als Reaktion darauf, dass die Temperatur der Edge-Plattform eine Schwellentemperatur überschreitet, eine Kühlung an der Edge-Plattform zu erhöhen und Rechenzustände von Ressourcen an der Edge-Plattform zu reduzieren.
-
Beispiel 34 enthält ein Verfahren zum Steuern einer Verarbeitung von Telemetriedaten auf einer Edge-Plattform, wobei das Verfahren als Reaktion auf eine Ressourcenmenge, die einem Orchestrator zugewiesen ist, umfasst, eine Arbeitslast auf der Edge-Plattform zu orchestrieren, die einen ersten Schwellenwert erreicht, Senden von mit dem Orchestrator assoziierter Telemetriedaten an einen Computer, um ein erstes Orchestrierungsergebnis mit einer ersten Granularität zu erhalten, Ermitteln eines zweiten Orchestrierungsergebnisses mit einer zweiten Granularität, um die Arbeitslast auf der Edge-Plattform zu orchestrieren, wobei die zweite Granularität feiner als die erste Granularität ist, und Planen einer der Edge-Plattform zugeordneten Arbeitslast auf Grundlage des zweiten Orchestrierungsergebnisses.
-
Beispiel 35 enthält das Verfahren von Beispiel 34, ferner enthaltend ein Vergleichen der dem Orchestrator zugewiesenen Ressourcenmenge mit mit dem Orchestrator assoziierten Konfigurationseinstellungen, Ermitteln, ob die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, und als Reaktion darauf, dass die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, Ermitteln, ob die dem Orchestrator zugewiesene Ressourcenmenge einen zweiten Schwellenwert erreicht.
-
Beispiel 36 enthält das Verfahren von Beispiel 35, wobei die Konfigurationseinstellungen eine Ressourcenmenge identifizieren, die dem Orchestrator auf einem Energiepegel zugewiesen werden können.
-
Beispiel 37 enthält das Verfahren von Beispiel 35, wobei die Konfigurationseinstellungen eine Ressourcenmenge identifizieren, die dem Orchestrator bei einem thermalen Zustand zugewiesen werden können.
-
Beispiel 38 enthält das Verfahren von Beispiel 34, das ferner Sammeln der Telemetriedaten und als Reaktion darauf, dass die Ressourcenmenge, die dem Orchestrator zugewiesen ist, einen zweiten Schwellenwert erreicht, Senden der mit dem Orchestrator assoziierten Telemetriedaten an einen Computer enthält, um ein drittes Orchestrierungsergebnis mit der zweiten Granularität zu erhalten.
-
Beispiel 39 enthält das Verfahren von Beispiel 38, wobei der zweite Schwellenwert unter dem ersten Schwellenwert liegt.
-
Beispiel 40 enthält das Verfahren von Beispiel 34, wobei die Ressourcenmenge eine erste Ressourcenmenge ist und das Verfahren ferner, als Reaktion darauf, dass die erste dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert nicht erreicht, Abschätzen einer zweiten Ressourcenmenge, die dem Orchestrator zuzuweisen ist, und Skalieren der ersten dem Orchestrator zugewiesenen Ressourcenmenge enthält, sodass sie die zweite Ressourcenmenge erfüllt, wobei die zweite Ressourcenmenge einer Ressourcenmenge entspricht, um Leistungsindikatoren zu erfüllen, die mit der Arbeitslast assoziiert sind.
-
Beispiel 41 enthält das Verfahren von Beispiel 34, das ferner Skalieren der dem Orchestrator zugewiesenen Ressourcenmenge auf Grundlage einer mit jeweiligen der Ressourcen assoziierten Prioritätsstufe enthält.
-
Beispiel 42 enthält das Verfahren von Beispiel 34, wobei die dem Orchestrator zugewiesene Ressourcenmenge den ersten Schwellenwert erreicht, wenn die Ressourcenmenge kleiner oder gleich dem ersten Schwellenwert ist.
-
Beispiel 43 enthält das Verfahren von Beispiel 34, das ferner Überwachen einer Temperatur der Edge-Plattform enthält.
-
Beispiel 44 enthält das Verfahren von Beispiel 43, das ferner als Reaktion darauf, dass die Temperatur der Edge-Plattform eine Schwellentemperatur überschreitet, Erhöhen einer aktiven Kühlung an der Edge-Plattform und Reduzieren der Rechenzustände von Ressourcen an der Edge-Plattform enthält.
-
Obwohl hierin bestimmte beispielhafte Verfahren, Einrichtungen und Fabrikate offenbart wurden, ist der Geltungsbereich dieses Patents nicht auf diese beschränkt. Im Gegenteil deckt dieses Patent alle Verfahren, Einrichtungen und Herstellungsgegenstände ab, die in den Geltungsbereich der Ansprüche dieses Patents fallen.
-
Die folgenden Ansprüche sind durch diese Bezugnahme in diese ausführliche Beschreibung aufgenommen, wobei jeder Anspruch eigenständig als eine separate Ausführungsform der vorliegenden Offenbarung steht.
-
ZITATE ENTHALTEN IN DER BESCHREIBUNG
-
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
-
Zitierte Patentliteratur
-
- US 62/841042 [0001]
- US 62/907597 [0001]
- US 62/939303 [0001]