DE102021207160A1

DE102021207160A1 - Verfahren und einrichtung zur verwaltung der dienstgüte in bezug auf service-level-agreements in einer rechenvorrichtung

Info

Publication number: DE102021207160A1
Application number: DE102021207160.0A
Authority: DE
Inventors: Ned M. Smith; Nilesh Kumar Jain; Andrew J. Herdrich; Kshitij Arun Doshi; Brinda Ganesh; Francesc Guim Bernat; Rashmin Patel; Monica Kenguva; Alexander Vul
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-09-25
Filing date: 2021-07-07
Publication date: 2022-03-31
Also published as: US20210014303A1; CN114338680A; US12113853B2

Abstract

Es sind beispielhafte Verfahren, Einrichtungen und Systeme zum Verwalten der Dienstgüte mit Bezug auf Service-Level-Agreements in einer Rechenvorrichtung offenbart. Eine beispielhafte Einrichtung beinhaltet einen ersten Mesh-Proxy, der einer ersten plattformagnostischen Anwendung zugeordnet ist, wobei der erste Mesh-Proxy ein erstes Ressourcenanforderungssignal basierend auf einer ersten Service-Level-Agreement-Voraussetzung von der ersten plattformagnostischen Anwendung erzeugen soll; einen zweiten Mesh-Proxy, der einer zweiten plattformagnostischen Anwendung zugeordnet ist, wobei der zweite Mesh-Proxy ein zweites Ressourcenanforderungssignal basierend auf einer zweiten Service-Level-Agreement-Voraussetzung von der zweiten plattformagnostischen Anwendung erzeugen soll; und einen Lastausgleicher zum Zuweisen von Hardwareressourcen für die erste plattformagnostische Anwendung und die zweite plattformagnostische Anwendung basierend auf dem ersten Ressourcenanforderungssignal und dem zweiten Ressourcenanforderungssignal.

Description

GEBIET DER OFFENBARUNG
Die vorliegende Offenbarung betrifft allgemein Rechenvorrichtungen und insbesondere Verfahren und Einrichtungen zum Verwalten der Dienstgüte in Bezug auf Service-Level-Agreements (Dienstgütevereinbarungen) in einer Rechenvorrichtung.
KURZE BESCHREIBUNG
Wenn eine Anwendung (z. B. Drittanbietersoftware) auf einer Rechenvorrichtung installiert ist, verwaltet das Betriebssystem der Rechenvorrichtung Hardwareressourcen der Rechenvorrichtung, um Dienste für die Anwendung bereitzustellen. Manche Anwendungen beinhalten Service-Level-Agreements (SLAs - Dienstgütevereinbarungen) oder Service-Level-Objectives (SLOs - Dienstgüteziele), die Voraussetzungen für Leistungsfähigkeitsmetriken definieren, die mit der Anwendung assoziiert sind. Solche Leistungsfähigkeitsmetriken können der Speicher-/Cache-Bandbreite, der Nutzung der Zentralverarbeitungseinheit (CPU), dem Jitter, der Latenz, der Geschwindigkeit, einer Anzahl/einem Anteil von Paketverwürfen, einer Anzahl von zu verarbeitenden Frames pro Sekunde usw. entsprechen. Die SLA- und/oder SLO-Voraussetzungen informieren die Rechenvorrichtung über die Mindestvoraussetzungen, die zur Implementierung der Anwendung benötigt werden.
Figurenliste

1 veranschaulicht einen Überblick über eine Edge-Cloud-Konfiguration für Edge-Computing.
2 veranschaulicht operative Schichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Rechenumgebungen.
3 veranschaulicht ein Blockdiagramm einer beispielhaften Umgebung für Networking und Dienste in einem Edge-Rechensystem.
4 veranschaulicht den Einsatz einer virtuellen Edge-Konfiguration in einem Edge-Rechensystem, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird.
5 veranschaulicht verschiedene Rechenanordnungen, die Container in einem Edge-Rechensystem einsetzen.
6 veranschaulicht einen beispielhaften Rechen- und Kommunikationsverwendungsfall, der Mobilzugriff auf Anwendungen in einem beispielhaften Edge-Rechensystem involviert.
7 ist ein Blockdiagramm eines beispielhaften Systems, das in Verbindung mit hierin offenbarten Beispielen beschrieben ist, zum Verwalten der Dienstgüte.
8 ist ein Blockdiagramm einer Implementierung der beispielhaften Rechenvorrichtung von 7.
9 ist ein anderes Blockdiagramm einer Implementierung der beispielhaften Rechenvorrichtung von 7.
10A-C sind Blockdiagramme von Implementierungen des beispielhaften Brokers und der beispielhaften Rechenvorrichtung von 7.
11 veranschaulicht ein Flussdiagramm, das beispielhafte maschinenlesbare Anweisungen repräsentiert, die ausgeführt werden können, um den Mesh-Proxy von 8 zu implementieren.
12 veranschaulicht ein Flussdiagramm, das beispielhafte maschinenlesbare Anweisungen repräsentiert, die ausgeführt werden können, um den Soft-QoS-Mesh-Proxy von 9 zu implementieren.
13 veranschaulicht ein Flussdiagramm, das beispielhafte maschinenlesbare Anweisungen repräsentiert, die ausgeführt werden können, um den Broker und die gepoolte QoS-Steuerung von 10A zu implementieren.
14A ist ein Blockdiagramm einer beispielhaften Implementierung eines beispielhaften Rechenknotens, der in einem der in den 1-4 und/oder 6-10C veranschaulichten Edge-Rechensysteme eingesetzt werden kann.
14B ist ein Blockdiagramm einer beispielhaften Prozessorplattform, die zum Ausführen der Anweisungen der 11-13 strukturiert ist, um den Mesh-Proxy, die Soft-QoS-Steuerung und/oder die gepoolte QoS-Steuerung der 8-10C zu implementieren.
15 ist ein Blockdiagramm einer beispielhaften Prozessorplattform, die zum Ausführen der Anweisungen von 13 strukturiert ist, um den Broker von 10A zu implementieren.

Die Figuren sind nicht maßstabsgetreu. Allgemein werden die gleichen Bezugsziffern durchweg durch die Zeichnung(en) und die begleitende geschriebene Beschreibung verwendet, um sich auf dieselben oder ähnliche Teile zu beziehen.
Deskriptoren „erster“, „zweiter“, „dritter“ usw. werden hierin verwendet, wenn mehrere Elemente oder Komponenten identifiziert werden, auf die sich möglicherweise getrennt bezogen wird. Sofern nichts anderes basierend auf ihrem Verwendungskontext spezifiziert oder verstanden wird, sollen solche Deskriptoren keine Bedeutung von Priorität oder zeitlicher Reihenfolge implizieren, sondern lediglich als Bezeichnungen zum separaten Verweisen auf mehrere Elemente oder Komponenten zum einfachen Verständnis der offenbarten Beispiele dienen. In manchen Beispielen kann der Deskriptor „erster“ verwendet werden, um sich auf ein Element in der ausführlichen Beschreibung zu beziehen, während sich auf dasselbe Element in einem Anspruch mit einem anderen Deskriptor wie etwa „zweiter“ oder „dritter“ bezogen werden kann. In solchen Fällen versteht es sich, dass solche Deskriptoren lediglich zum einfachen Referenzieren mehrerer Elemente oder Komponenten verwendet werden.
AUSFÜHRLICHE BESCHREIBUNG
Flexibilität und leicht handhabbare Lösungen auf Rack-Ebene sind für Netzwerk-Edge-Verarbeitung und/oder virtuelle Maschinenverarbeitung wünschenswert, bei denen sich mehrere Edge-Domänen einen Pool von Ressourcen teilen. Falls zum Beispiel ein Prozess speicherintensiv und/oder prozessorintensiv ist, kann es vorteilhaft sein, den Prozess in Unterprozesse aufzuteilen, die durch unterschiedliche Rechenvorrichtungen ausgeführt werden können, um Effizienz, Geschwindigkeit und/oder Genauigkeit zu gewährleisten. Jede dieser Rechenvorrichtungen kann einen Satz von Ressourcen aufweisen, die mit anderen verbundenen Vorrichtungen gemeinsam genutzt werden können. Wie hierin verwendet, sind gepoolte Ressourcen Ressourcen (z. B. Speicher, CPU, GPU, Beschleuniger usw.) einer ersten Vorrichtung, einer einzelnen Edge-Knotenvorrichtung und/oder einer ersten virtuellen Maschine, die Ressourcen für einen bestimmten Mandanten/Benutzer zuweist oder kennzeichnet. Gepoolte Ressourcen können mit einer anderen Vorrichtung gemeinsam genutzt und/oder von dieser verwendet werden, um eine bestimmte Aufgabe durchzuführen. Auf diese Weise kann eine Anwendung die Ressourcen mehrerer Rechenvorrichtungen und/oder virtueller Maschinen nutzen, um eine Aufgabe auf eine schnelle und effiziente Weise durchzuführen. Bei manchen Beispielen beinhaltet die Anwendung Service-Level-Agreement(SLA)-Voraussetzungen und/oder Service-Level-Objectives(SLO)-Voraussetzungen zum Durchführen der Aufgabe. Zum Beispiel können eine oder mehrere SLA/SLO-Voraussetzungen einer Dienstanforderung von einer Anwendung Bandbreitenvoraussetzungen, Latenzvoraussetzungen, Jitter-Voraussetzungen, Anzahl/Anteil von Paketverwürfen, Anzahl von pro Sekunde verarbeiteten Bildern usw. entsprechen.
Einige Cloud-basierte Entwicklungen vereinfachen die Komplexitäten und Details einer zugrundeliegenden Plattform aus Anwendungen, die mit der Plattform eine Schnittstelle bilden. Auf diese Weise reduzieren derartige Vereinfachungen die Notwendigkeit, dass sich manche Lösungen Plattformfähigkeiten oder Orten von Infrastrukturdiensten bewusst sein müssen, wodurch die Lösungsgeschwindigkeit erhöht wird. Derartige Cloud-basierte Entwicklungen verbergen jedoch einige oder alle der Software- (z. B. Betriebssystem (OS)) und/oder VMM-Plattformfähigkeiten (VMM: Virtual Machine Manager - Virtuelle-Maschine-Manager) und/oder Hardwarecharakteristiken (z. B. CPU, GPU, Speicher usw.) einer Rechenvorrichtung vor einer Anwendung, die versucht, gepoolte Ressourcen zum Durchführen einer Aufgabe zu verwenden. Dementsprechend erschwert eine solche Cloud-basierte Entwicklung für eine Anwendung, einen Prozess auf mehrere verschiedene Rechenvorrichtungen und/oder virtuelle Maschinen aufzuteilen, da die Charakteristiken der Hardware und/oder Software verborgen sein können, wodurch es schwierig und/oder unmöglich gemacht wird, dass die Erfüllung von SLA/SLO-Voraussetzungen entsprechend der Aufgabe gewährleistet wird, da die Software- und/oder Hardwarecharakteristiken verborgen sind.
Hierin offenbarte Beispiele verwalten Dienstgüte(QoS: Quality of Service)-Funktionalität, indem sie die Konformität mit SLA/SLO-Voraussetzungen für gepoolte Ressourcen von Rechenvorrichtungen ermöglichen. Hierin offenbarte Beispiele beinhalten einen Broker zum Empfangen von Dienstanforderungen von externen Anwendungen (z. B. die in einer anderen Rechenvorrichtung, einer Cloud/einem Datenzentrum, einem Edgebasierten Server, einer zentralen Datenbank usw. betrieben werden) und zum Weiterleiten der Dienstanforderungen an eine QoS-Steuerung, die in der Rechenvorrichtung implementiert ist, die die gepoolten Ressourcen beinhaltet. Die QoS-Steuerung wird durch Resource Director Technology (RDT) vollzogen. RDT beinhaltet Cache-Überwachung, Cache-Zuweisung, Speicherbandbreitenüberwachung und Speicherbandbreitenzuweisung. Zusätzlich dazu kann RDT eine Schnittstelle mit einem Vorrichtungs-Interconnect-Fabric (z. B. PCIe: Peripheral Component Interconnect Express)-Switch in Vorrichtungs-Interconnect-Fabric-basierten Netzwerkvorrichtungen bilden, um die Bandbreite durch verschiedene mit Vorrichtungs-Interconnect-Fabric(z. B. PCIe)-verbundene Komponenten (z. B. Beschleuniger, Netzwerkschnittstellenkarten, Speicherung usw.) zu überwachen. Zum Beispiel kann der Switch insgesamt 64 Gigabit (Gb)/Sekunde (s) unterstützen, und falls der Switch mit drei PCIe-Vorrichtungen (wobei z. B. jede Vorrichtung die Fähigkeit hat, bis zu 40 Gb/s zu verwenden) verbunden ist, kann die RDT verwendet werden, um eine Grenze für die Verwendung der 64-Gb/s-Bandbreite gemäß verschiedenen minimalen Bandbreiten, die für die jeweiligen drei Vorrichtungen konfiguriert sind, zu definieren und zu vollziehen. PCIe und andere Busprotokolle können Befehle beinhalten, die sich auf die Fähigkeit eines Dienstes beziehen, Ressourcen zur Verwendung durch eine(n) bestimmte(n) Mandanten, Benutzer, Arbeitslast usw. zuzuweisen, zuzuordnen, zu kennzeichnen und/oder anderweitig zu poolen. Durch das Überwachen der Verwendung der Befehle können hierin offenbarte Beispiele einen Benutzer/eine verfügbare Ressource jederzeit überwachen (z. B. eine Map dafür bilden). Auf diese Weise kann die QoS-Steuerung basierend auf den SLA/SLO-Voraussetzungen bestimmen, ob die gepoolten Ressourcen der Rechenvorrichtung in der Lage sind, die Anforderung zu versorgen. Falls zum Beispiel eine Dienstanforderung einer bestimmten Speicherbandbreite entspricht, kann die QoS-Steuerung bestimmen, ob die Rechenvorrichtung in der Lage ist, die Speicherbandbreite zu erreichen, und dann basierend auf der Bestimmung eine Antwort an den Broker übermitteln. Nachdem der Broker Antworten von allen verbundenen Rechenvorrichtungen mit gepoolten Ressourcen erhält, kann der Broker bestimmen, wie der Prozess den Rechenvorrichtungen zuzuweisen ist, um die Anforderung gemäß den SLA/SLO-Voraussetzungen zu versorgen.
Zusätzlich nutzen hierin offenbarte Beispiele einen oder mehrere Mesh-Proxys innerhalb einer Rechenvorrichtung, um die Größe und Komplexität von Anwendungen zu reduzieren, die für Rechenvorrichtungen entwickelt und/oder zu Rechenvorrichtungen übertragen werden. Anwendungen werden entwickelt, um in einer Rechenvorrichtung implementiert zu werden, um die Rechenvorrichtung zu veranlassen, eine oder mehrere Aufgaben gemäß Anweisungen durchzuführen, die in den Anwendungen enthalten sind. Es gibt jedoch mehrere Versionen von Rechenvorrichtungen mit unterschiedlichen Hardwarekomponenten, unterschiedlichen Betriebssystemen und/oder unterschiedlichen VMMs. Dementsprechend beinhalten Anwendungen eine Service-Level-Agreement(SLA)- und/oder Service-Level-Objectives(SLO)-Bibliothek, die identifiziert, wie verschiedenen Arten von Rechenvorrichtungen betrieben sollen und/oder mit diesen kommuniziert werden soll. Zusätzlich oder alternativ dazu kann die Anwendung ein/en SLA- oder SLO-Startprogramm und/oder -Administrator zum Handhaben der Kommunikation mit den verschiedenen Rechenvorrichtungsarten beinhalten. Zum Beispiel kann die SLO/SLA-Bibliothek/das SLO/SLA-Startprogramm/der SLO/SLA-Administrator ein SLA/SLO in ressourcenbasierte Attribute umwandeln und ein RDT-Steuersignal (z. B. ein Ressourcenanforderungssignal) basierend auf den ressourcenbasierten Attributen erzeugen. Wie oben beschrieben, identifiziert ein SLA/SLO Voraussetzungen (z. B. Bandbreitenvoraussetzungen, Latenzvoraussetzungen, Jitter-Voraussetzungen, Anzahl von Paketverwürfen usw.) einer Anwendung, wenn sie durch ein Rechensystem implementiert wird. Das RDT-Steuersignal entspricht Anweisungen zum Reservieren der geeigneten Menge an Speicher- und/oder Prozessorressourcen, um die SLA/SLO-Voraussetzungen zu erfüllen. Auf diese Weise kann eine Anwendung ein SLA und/oder SLO erzwingen, während Ressourcen genutzt werden, um eine Aufgabe auf mehreren Arten von Rechenvorrichtungen auszuführen. Die SLA-Bibliotheken und/oder das/der SLA-Startprogramm/-Administrator benötigen jedoch viel Code. Dementsprechend entspricht das Übertragen der Anwendung zu einer Vorrichtung einer großen Datenmenge, selbst wenn die Anwendung nur einige Zeilen an Code aufweist.
Mesh-Proxys sind Komponenten, die in Containern (z. B. Sidecars) implementiert werden, die einen gemeinsamen Satz von Funktionalitäten implementieren, die für Verzeichnisnachschläge benötigt werden, um andere Dienste auf derselben oder einer anderen Maschine zu lokalisieren. Ein Mesh-Proxy arbeitet als eine Kommunikationsbrücke zu anderen Mesh-Proxys in anderen Containern und implementiert übliche Infrastrukturdienste, wie etwa Transport, sicheren Transport, eine Verbindung zu Host-Brücken, Lastausgleich, Protokollüberbrückung usw. Der Mesh-Proxy wird in der Rechenvorrichtung implementiert und steht in Kommunikation mit dem Betriebssystem der Rechenvorrichtung. Auf diese Weise können Anwendungen plattformagnostisch sein (z. B. ohne Code einzuschließen, der einem bestimmten Betriebssystem und/oder bestimmten Hardwareressourcen der Vorrichtung/Plattform entspricht, in der die Anwendung implementiert wird). Somit können die Anwendungen auf einer Vorrichtung laufen und agnostisch bezüglich des Betriebssystems und/oder der Hardware der zugrundeliegenden Rechenvorrichtung sowie anderer verbundener Rechenvorrichtungen bleiben, da der Mesh-Proxy als die Brücke zwischen der Anwendung und dem Betriebssystem der Vorrichtung und anderer Vorrichtungen wirkt.
Hierin offenbarte Beispiele nutzen Mesh-Proxys aus, um die Einbeziehung von SLA/SLO-Bibliotheken, -Startprogrammen und/oder -Administratoren aus Anwendungen zu eliminieren. Da der Mesh-Proxy in der Rechenvorrichtung implementiert wird, ordnet die Rechenvorrichtung, wenn eine neue Anwendung in der Rechenvorrichtung implementiert wird, der neuen Anwendung einen Mesh-Proxy zu und der Mesh-Proxy wandelt die SLA/SLO-Voraussetzungen hoher Ebene in ressourcenbasierte Attribute für RDT-Steueranweisungen um. Auf diese Weise muss die Anwendung die SLA-Bibliotheken und/oder -Startprogramme nicht beinhalten. Somit können Anwendungen auf einer beliebigen Art von Rechenvorrichtung laufen, ohne Code (z. B. SLA/SLO-Bibliotheken, -Startprogramme und/oder -Administratoren) einzuschließen, der für die verschiedenen Rechenvorrichtungsarten spezifisch ist. Dementsprechend wird die Größe von Anwendungen, die über ein Netzwerk übertragen werden, verringert, was zu einer effizienteren und schnelleren Anwendungsübertragung mit weniger komplexer Codeentwicklung führt.
1 ist ein Blockdiagramm 100, das einen Überblick über eine Konfiguration für Edge-Computing zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der folgenden Beispiele als eine „Edge-Cloud“ bezeichnet wird. Wie gezeigt, befindet sich die Edge-Cloud 110 gemeinsam an einem Edge-Ort, wie etwa einem Zugangspunkt oder einer Basisstation 140, einem lokalen Verarbeitungshub 150 oder einer Zentrale 120, und kann somit mehrere Entitäten, Vorrichtungen und Geräteinstanzen beinhalten. Die Edge-Cloud 110 befindet sich viel näher an den Endpunkt(Verbraucher und Erzeuger)-Datenquellen 160 (z. B. autonome Fahrzeuge 161, Benutzergeräte 162, Unternehmens- und Industrieausrüstung 163, Videoaufnahmevorrichtungen 164, Drohnen 165, Smart-Städte- und -Gebäude-Vorrichtungen 166, Sensoren und IoT-Vorrichtungen 167 usw.) als das Cloud-Datenzentrum 130. Rechen-, Speicher- und Speicherungsressourcen, die an den Edges in der Edge-Cloud 110 angeboten werden, sind kritisch für das Bereitstellen von Antwortzeiten mit ultraniedriger Latenz für Dienste und Funktionen, die durch die Endpunktdatenquellen 160 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 110 zu dem Cloud-Datenzentrum 130, wodurch Energieverbrauch und Gesamtnetzwerknutzungen unter anderen Vorteilen verbessert werden.
Berechnung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit von dem Edge-Ort ab (wobei z. B. weniger Verarbeitungsressourcen an Verbraucherendpunktvorrichtungen verfügbar sind als an einer Basisstation, als an einer Zentrale). Je näher sich der Edge-Ort jedoch am Endpunkt (z. B. Benutzergerät (UE)) befindet, desto mehr sind Raum und Leistung häufig eingeschränkt. Somit versucht Edge-Computing die Menge an Ressourcen, die für Netzwerkdienste benötigt werden, durch die Verteilung von mehr Ressourcen, die sich sowohl geographisch als auch in der Netzwerkzugriffszeit näher befinden, zu reduzieren. Auf diese Weise versucht Edge-Computing, die Rechenressourcen gegebenenfalls zu den Arbeitslastdaten zu bringen oder die Arbeitslastdaten zu den Rechenressourcen zu bringen.
Das Folgende beschreibt Aspekte einer Edge-Cloud-Architektur, die mehrere potentielle Einsätze abdeckt und Einschränkungen anspricht, die manche Netzwerkbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen aufweisen können. Diese beinhalten Variation von Konfigurationen basierend auf dem Edge-Ort (weil Edges auf einer Basisstationsebene zum Beispiel mehr eingeschränkte Leistungsfähigkeit und Fähigkeiten in einem Multi-Mandanten-Szenario aufweisen können); Konfigurationen basierend auf der Art von Berechnung, Speicher, Speicherung, Fabric, Beschleunigung oder ähnlichen Ressourcen, die Edge-Orten, Stufen von Orten oder Gruppen von Orten zur Verfügung stehen; die Dienst-, Sicherheits- und Verwaltungs- und Orchestrierungsfähigkeiten; und zugehörige Ziele zum Erreichen der Nutzbarkeit und Leistungsfähigkeit von Enddiensten. Diese Einsätze können eine Verarbeitung in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Entfernungs- und Timing-Charakteristiken als „Near-Edge“-, „Close-Edge“-, „Local-Edge“-, „Middle-Edge“- oder „Far-Edge“-Schichten betrachtet werden können.
Edge-Computing ist ein sich entwickelndes Paradigma, bei dem Computing an oder näher am „Edge“ (Rand) eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer Rechenplattform (z. B. x86 oder ARM-Rechenhardwarearchitektur), die bei Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen implementiert wird, die sich viel näher an Endpunktvorrichtungen befinden, die die Daten erzeugen und verbrauchen. Edge-Gateway-Server können zum Beispiel mit Pools von Speicher- und Speicherressourcen ausgestattet sein, um eine Berechnung in Echtzeit für Verwendungsfälle mit niedriger Latenz (z. B. autonomes Fahren oder Videoüberwachung) für verbundene Client-Vorrichtungen durchzuführen. Oder als ein Beispiel können Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für verbundene Benutzergeräte direkt zu verarbeiten, ohne ferner Daten über Backhaul-Netzwerke zu kommunizieren. Oder als ein anderes Beispiel kann Zentralen-Netzwerkverwaltungshardware durch standardisierte Rechenhardware ersetzt werden, die virtualisierte Netzwerkfunktionen durchführt und Rechenressourcen für die Ausführung von Diensten und Verbraucherfunktionen für verbundene Vorrichtungen anbietet. Innerhalb von Edge-Rechennetzwerken kann es Szenarien in Diensten geben, in denen die Rechenressource zu den Daten „verschoben“ wird, sowie Szenarien geben, in denen die Daten zu der Rechenressource „verschoben“ werden. Oder als ein Beispiel können Basisstationsberechnungs-, Beschleunigungs- und Netzwerkressourcen Dienste bereitstellen, um die Arbeitslastbedürfnisse nach Bedarf durch Aktivieren inaktiver Kapazität (Subskription, Kapazität nach Bedarf) zu skalieren, um Ausnahmefälle, Notfälle zu verwalten oder Langlebigkeit für eingesetzte Ressourcen über einen wesentlich längeren implementierten Lebenszyklus bereitzustellen.
2 veranschaulicht operative Schichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Rechenumgebungen. Insbesondere stellt 2 Beispiele für Rechenverwendungsfälle 205 dar, die die Edge-Cloud 110 unter mehreren veranschaulichenden Schichten des Netzwerk-Computing nutzen. Die Schichten beginnen bei einer Endpunkt(Vorrichtungen und Dinge)-Schicht 200, die auf die Edge-Cloud 110 zugreift, um Datenerzeugungs-, Analyse- und Datenverbrauchsaktivitäten durchzuführen. Die Edge-Cloud 110 kann mehrere Netzwerkschichten überspannen, wie etwa eine Edge-Vorrichtungsschicht 210 mit Gateways, Vor-Ort-Servern oder Netzwerkgeräten (Knoten 215), die sich in physisch nahen Edge-Systemen befinden, eine Netzwerkzugangsschicht 220, umfassend Basisstationen, Funkverarbeitungseinheiten, Netzwerkhubs, regionale Datenzentren (DZ) oder lokale Netzwerkgeräte (Geräte 225); und beliebige Geräte, Vorrichtungen oder Knoten, die sich dazwischen befinden (in Schicht 212, nicht ausführlich veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 110 und zwischen den verschiedenen Schichten können über eine beliebige Anzahl von drahtgebundenen oder drahtlosen Medien stattfinden, einschließlich über Konnektivitätsarchitekturen und Technologien, die nicht dargestellt sind.
Beispiele für Latenz, die aus Netzwerkkommunikationsentfernungs- und Verarbeitungszeitbeschränkungen resultieren, können von weniger als einer Millisekunde (ms), wenn inmitten der Endpunktschicht 200, unter 5 ms an der Edge-Vorrichtungsschicht 210, bis sogar zwischen 10 und 40 ms, wenn mit Knoten an der Netzwerkzugangsschicht 220 kommuniziert, reichen. Jenseits der Edge-Cloud 110 befinden sich Schichten des Kernnetzwerks 230 und des Cloud-Datenzentrums 240, jeweils mit zunehmender Latenz (z. B. zwischen 50-60 ms an der Kernnetzwerkschicht 230 bis 100 oder mehr ms an der Cloud-Datenzentrumsschicht). Infolgedessen werden Operationen an einem Kernnetzwerk-Datenzentrum 235 oder einem Cloud-Datenzentrum 245 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Verwendungsfälle 205 zu realisieren. Jeder dieser Latenzwerte wird zu Veranschaulichungs- und Kontrastzwecken bereitgestellt; es versteht sich, dass die Verwendung anderer Zugangsnetzwerkmedien und -technologien die Latenzen weiter reduzieren kann. Bei manchen Beispielen können jeweilige Teile des Netzwerks relativ zu einer Netzwerkquelle und einem Netzwerkziel als „Close-Edge“-, „Local-Edge“-, „Near-Edge“-, „Middle-Edge“- oder „Far-Edge“-Schichten kategorisiert sein. Beispielsweise kann aus der Perspektive des Kernnetzwerk-Datenzentrums 235 oder eines Cloud-Datenzentrums 245 ein Zentralen- oder Inhaltsdatennetzwerk als innerhalb einer „Near-Edge“-Schicht („near“ (nahe) an der Cloud, mit hohen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Verwendungsfälle 205 kommuniziert wird) befindlich betrachtet werden, wohingegen ein Zugangspunkt, eine Basisstation, ein Vor-Ort-Server oder ein Netzwerk-Gateway als innerhalb einer „Far-Edge“-Schicht („far“ (fern) von der Cloud entfernt, mit niedrigen Latenzwerten, wenn mit den Vorrichtungen und Endpunkten der Verwendungsfälle 205 kommuniziert wird) befindlich betrachtet werden können. Es versteht sich, dass andere Kategorisierungen einer speziellen Netzwerkschicht als ein „Close“-, „Local“-, „Near“-, „Middle“- oder „Far“-Edge bildend auf Latenz, Entfernung, Anzahl von Netzwerksprüngen oder anderen messbaren Charakteristiken basieren können, wie von einer Quelle in einer beliebigen der Netzwerkschichten 200-240 gemessen.
Die diversen Verwendungsfälle 205 können aufgrund mehrerer Dienste, die die Edge-Cloud nutzen, auf Ressourcen unter Nutzungsdruck von eingehenden Strömen zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 110 ausgeführt werden, variierende Voraussetzungen in Bezug auf Folgendes aus: (a) Priorität (Durchsatz oder Latenz) und Dienstgüte (QoS: Quality of Service) (z. B. kann Verkehr für ein autonomes Auto eine höhere Priorität als ein Temperatursensor hinsichtlich der Antwortzeitvoraussetzung aufweisen; oder eine Leistungsfähigkeitsempfindlichkeit/-engstelle kann an einer Rechen-/Beschleuniger-, Speicher-, Speicherungs- oder Netzwerkressource in Abhängigkeit von der Anwendung existieren); (b) Zuverlässigkeit und Widerstandsfähigkeit (z. B. müssen manche Eingangsströme bearbeitet und der Verkehr mit missionskritischer Zuverlässigkeit geleitet werden, wohingegen manche anderen Eingangsströme je nach Anwendung einen gelegentlichen Ausfall tolerieren können); und (c) physikalische Beschränkungen (z. B. Leistung, Kühlung und Formfaktor).
Die Ende-zu-Ende-Dienstansicht für diese Verwendungsfälle beinhaltet das Konzept eines Dienstflusses und ist mit einer Transaktion assoziiert. Die Transaktion gibt die Gesamtdienstvoraussetzung für die Entität an, die den Dienst verbraucht, sowie die assoziierten Dienste für die Ressourcen, Arbeitslasten, Arbeitsabläufe und Unternehmensfunktions- und Unternehmensebenenvoraussetzungen. Die Dienste, die mit den beschriebenen „Begriffen“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, dass Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt wird. Wenn einer Komponente in der Transaktion ihr vereinbartes SLA fehlt, kann das System als Ganzes (Komponenten in der Transaktion) die Fähigkeit bereitstellen, (1) die Auswirkung der SLA-Verletzung zu verstehen und (2) andere Komponenten in dem System zu erweitern, um das gesamte Transaktions-SLA wiederaufzunehmen, und (3) Schritte zu implementieren, um Abhilfe zu schaffen.
Dementsprechend kann unter Berücksichtigung dieser Variationen und Dienstleistungsmerkmale Edge-Computing innerhalb der Edge-Cloud 110 die Fähigkeit bereitstellen, mehrere Anwendungen der Verwendungsfälle 205 (z. B. Objektverfolgung, Videoüberwachung, verbundene Autos usw.) in Echtzeit oder nahezu Echtzeit zu versorgen und auf diese zu reagieren und Voraussetzungen für ultraniedrige Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganz neue Klasse von Anwendungen (VNFs (Virtual Network Functions), FaaS (Function as a Service), Edge as a Service (EaaS), Standardprozesse usw.), die herkömmliches Cloud-Computing aufgrund von Latenz oder anderen Einschränkungen nicht nutzen können.
Mit den Vorteilen von Edge-Computing ergeben sich jedoch die folgenden Vorbehalte. Die am Edge befindlichen Vorrichtungen sind häufig ressourcenbeschränkt, sodass Druck auf die Nutzung von Edge-Ressourcen besteht. Typischerweise wird dies durch das Pooling von Speicher- und Speicherungsressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Vorrichtungen adressiert. Der Edge kann leistungs- und kühlungseingeschränkt sein, sodass der Leistungsverbrauch durch die Anwendungen berücksichtigt werden muss, die die meiste Leistung verbrauchen. Es kann inhärente Leistung-Leistungsfähigkeits-Kompromisse in diesen gepoolten Speicherressourcen geben, da viele von ihnen wahrscheinlich neu entwickelte Speichertechnologien verwenden, bei denen höhere Leistung eine größere Speicherbandbreite benötigt. Gleichermaßen sind verbesserte Sicherheit von Hardware und vertrauenswürdigen Root-of-Trust-Funktionen auch erforderlich, da Edge-Orte unbemannt sein können und sogar zugelassenen Zugriff benötigen können (z. B. wenn sie an einem Drittparteistandort untergebracht sind). Solche Probleme werden in der Edge-Cloud 110 in einem Multi-Mandanten-, Multi-Eigentümer- oder Multi-Zugriff-Umfeld vergrößert, in dem Dienste und Anwendungen von vielen Benutzern angefordert werden, insbesondere da die Netzwerknutzung dynamisch schwankt und sich die Zusammensetzung der mehreren Stakeholder, Verwendungsfälle und Dienste ändert.
Auf einer generischeren Ebene kann ein Edge-Rechensystem so beschrieben werden, dass es eine beliebige Anzahl von Einsätzen an den zuvor besprochenen Schichten umfasst, die in der Edge-Cloud 110 arbeiten (Netzwerkschichten 200-240), die eine Koordination vom Client und verteilten Rechenvorrichtungen bereitstellen. Ein oder mehrere Edge-Gateway-Knoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kerndatenzentren können über Schichten des Netzwerks verteilt sein, um eine Implementierung des Edge-Rechensystems durch oder im Auftrag eines Telekommunikationsdienstanbieters („telco“ oder „TSP“), Internet-der-Dinge-Dienstanbieters, Cloud-Dienstanbieters (CSP), Unternehmensentität oder einer beliebigen anderen Anzahl von Entitäten bereitzustellen. Verschiedene Implementierungen und Konfigurationen des Edge-Rechensystems können dynamisch bereitgestellt werden, wie etwa, wenn orchestriert, um Dienstziele zu erfüllen.
Im Einklang mit den hierin bereitgestellten Beispielen kann ein Client-Rechenknoten als eine beliebige Art von Endpunktkomponente, -vorrichtung, -gerät oder anderer Sache umgesetzt sein, die/das dazu in der Lage ist, als ein Erzeuger oder Verbraucher von Daten zu kommunizieren. Ferner bedeutet die Bezeichnung „Knoten“ oder „Vorrichtung“, wie es in dem Edge-Rechensystem verwendet wird, nicht notwendigerweise, dass ein solcher Knoten oder eine solche Vorrichtung in einer Client- oder Agenten-/Minion-/Folgerrolle arbeitet; vielmehr beziehen sich beliebige der Knoten oder Vorrichtungen in dem Edge-Rechensystem auf einzelne Entitäten, Knoten oder Untersysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen beinhalten, um die Edge-Cloud 110 zu ermöglichen oder zu verwenden.
Von daher ist die Edge-Cloud 110 aus Netzwerkkomponenten und Funktionsmerkmalen gebildet, die durch und innerhalb von Edge-Gateway-Knoten, Edge-Aggregationsknoten oder anderen Edge-Rechenknoten unter den Netzwerkschichten 210-230 betrieben werden. Die Edge-Cloud 110 kann somit als eine beliebige Art von Netzwerk umgesetzt sein, das Edge-Computing- und/oder Speicherungsressourcen bereitstellt, die sich in der Nähe von Funkzugangsnetzwerk(RAN)-fähigen Endpunktvorrichtungen (z. B. mobilen Rechenvorrichtungen, IoT-Vorrichtungen, Smart-Vorrichtungen usw.) befinden, die hierin besprochen werden. Mit anderen Worten kann die Edge-Cloud 110 als ein „Edge“ angesehen werden, der die Endpunktvorrichtungen und traditionelle Netzwerkzugangspunkte, die als ein Eingangspunkt in Dienstanbieter-Kernnetzwerke dienen, verbindet, einschließlich Mobilträgernetzen (z. B. GSM(Global System for Mobile Communications)-Netze, LTE(Long-Term Evolution)-Netze, 5G/6G-Netze usw.), während auch Speicherungs- und/oder Rechenfähigkeiten bereitgestellt werden. Andere Arten und Formen von Netzwerkzugang (z. B. WiFi, Long-Range-Wireless, drahtgebundene Netze einschließlich optischer Netze) können auch anstelle von oder in Kombination mit solchen 3GPP-Trägernetzen genutzt werden.
Die Netzwerkkomponenten der Edge-Cloud 110 können Server, Multi-Mandanten-Server, Geräterechenvorrichtungen und/oder eine beliebige andere Art von Rechenvorrichtungen sein. Zum Beispiel kann die Edge-Cloud 110 eine Geräterechenvorrichtung beinhalten, die ein eigenständiges elektronisches System einschließlich eines Gehäuses, einer Einhausung, eines Behälters oder einer Umhüllung ist. Unter Umständen kann das Gehäuse für Portabilität dimensioniert sein, sodass es von einem Menschen getragen und/oder versandt werden kann. Beispielhafte Gehäuse können Materialien beinhalten, die eine oder mehrere Außenflächen bilden, die Inhalte des Geräts teilweise oder vollständig schützen, wobei der Schutz Wetterschutz, Schutz vor gefährlichen Umgebungen (z. B. EMI, Vibration, extreme Temperaturen) beinhalten und/oder Eintauchbarkeit ermöglichen kann. Beispielhafte Gehäuse können Leistungsschaltungsanordnungen beinhalten, um Leistung für stationäre und/oder tragbare Implementierungen bereitzustellen, wie etwa AC-Leistungseingänge, DC-Leistungseingänge, AC/DC- oder DC/AC-Wandler, Leistungsregler, Transformatoren, Ladeschaltungsanordnungen, Batterien, drahtgebundene Eingänge und/oder drahtlose Leistungseingänge. Beispielhafte Gehäuse und/oder Oberflächen davon können Montagehardware beinhalten oder mit dieser verbunden sein, um eine Befestigung an Strukturen, wie etwa Gebäuden, Telekommunikationsstrukturen (z. B. Masten, Antennenstrukturen usw.) und/oder Racks (z. B. Server-Racks, Blade-Mounts usw.), zu ermöglichen. Beispielhafte Gehäuse und/oder Oberflächen davon können einen oder mehrere Sensoren (z. B. Temperatursensoren, Vibrationssensoren, Lichtsensoren, Akustiksensoren, kapazitive Sensoren, Näherungssensoren usw.) unterstützen. Ein oder mehrere solcher Sensoren können in der Oberfläche enthalten, von dieser getragen oder anderweitig darin eingebettet und/oder an der Oberfläche des Geräts montiert sein. Beispielhafte Gehäuse und/oder Oberflächen davon können mechanische Konnektivität unterstützen, wie etwa Antriebshardware (z. B. Räder, Propeller usw.) und/oder Gelenkhardware (z. B. Roboterarme, schwenkbare Anhänge usw.). Unter manchen Umständen können die Sensoren eine beliebige Art von Eingabevorrichtungen beinhalten, wie etwa Benutzerschnittstellenhardware (z. B. Tasten, Schalter, Wählscheiben, Schieber usw.). Unter manchen Umständen beinhalten beispielhafte Gehäuse Ausgabevorrichtungen, die darin enthalten, durch diese getragen werden, darin eingebettet sind und/oder daran angebracht sind. Ausgabevorrichtungen können Anzeigen, Touchscreens, Leuchten, LEDs, Lautsprecher, E/A-Ports (z. B. USB) usw. beinhalten. Unter manchen Umständen sind Edge-Vorrichtungen Vorrichtungen, die in dem Netzwerk für einen spezifischen Zweck vorhanden sind (z. B. eine Ampel), können aber Verarbeitungs- und/oder andere Kapazitäten aufweisen, die für andere Zwecke genutzt werden können. Solche Edge-Vorrichtungen können unabhängig von anderen vernetzten Vorrichtungen sein und können mit einem Gehäuse ausgestattet sein, das einen Formfaktor aufweist, der für seinen primären Zweck geeignet ist; aber dennoch für andere Rechenaufgaben verfügbar ist, die ihre primäre Aufgabe nicht stören. Edge-Vorrichtungen beinhalten Internet-der-Dinge-Vorrichtungen. Die Geräterechenvorrichtung kann Hardware- und Softwarekomponenten beinhalten, um lokale Probleme, wie etwa Vorrichtungstemperatur, Vibration, Ressourcenausnutzung, Aktualisierungen, Leistungsprobleme, physische Sicherheit und Netzwerksicherheit usw., zu verwalten. Beispielhafte Hardware zum Implementieren einer Geräterechenvorrichtung ist in Verbindung mit 14B beschrieben. Die Edge-Cloud 110 kann auch einen oder mehrere Server und/oder einen oder mehrere Multi-Mandanten-Server beinhalten. Ein solcher Server kann ein Betriebssystem und eine virtuelle Rechenumgebung beinhalten. Eine virtuelle Rechenumgebung kann einen Hypervisor-Manager (Spawning, Einsatz, Zerstörung usw.), eine oder mehrere virtuelle Maschinen, einen oder mehrere Container usw. beinhalten. Solche virtuellen Rechenumgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen und/oder andere Software, Code oder Skripte ausgeführt werden können, während sie von einer oder mehreren anderen Anwendungen, Software, Code oder Skripten isoliert sind.
3 veranschaulicht ein Blockdiagramm einer beispielhaften Umgebung 300, in der verschiedene Client-Endpunkte 310 (in der Form von Mobilvorrichtungen, Computern, autonomen Fahrzeugen, Unternehmensrechenanlagen, industriellen Verarbeitungsanlagen) Anforderungen und Antworten mit der beispielhaften Edge-Cloud 110 austauschen. Beispielsweise können Client-Endpunkte 310 Netzwerkzugang über ein drahtgebundenes Breitbandnetzwerk erhalten, indem Anforderungen und Antworten 322 durch ein Vor-Ort-Netzwerksystem 332 ausgetauscht werden. Manche Client-Endpunkte 310, wie etwa mobile Rechenvorrichtungen, können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem Anforderungen und Antworten 324 durch einen Zugangspunkt (z. B. Mobilfunkturm) 334 ausgetauscht werden. Manche Client-Endpunkte 310, wie etwa autonome Fahrzeuge, können Netzwerkzugang für Anforderungen und Antworten 326 über ein drahtloses Fahrzeugnetzwerk durch ein Straßennetzwerksystem 336 erhalten. Unabhängig von der Art des Netzwerkzugangs kann der TSP jedoch Aggregationspunkte 342, 344 innerhalb der Edge-Cloud 110 einsetzen, um Verkehr und Anforderungen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 110 verschiedene Rechen- und Speicherungsressourcen einsetzen, wie etwa bei Edge-Aggregationsknoten 340, um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 340 und andere Systeme der Edge-Cloud 110 sind mit einer Cloud oder einem Datenzentrum 360 verbunden, die/das ein Backhaul-Netzwerk 350 verwendet, um Anforderungen mit höherer Latenz von einer Cloud/einem Datenzentrum für Websites, Anwendungen, Datenbankserver usw. zu erfüllen. Zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 340 und der Aggregationspunkte 342, 344, einschließlich jener, die auf einem einzigen Server-Framework eingesetzt werden, können auch innerhalb der Edge-Cloud 110 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein.
4 veranschaulicht Einsatz und Orchestrierung für virtuelle Edge-Konfigurationen über ein Edge-Rechensystem, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird. Insbesondere stellt 4 eine Koordination eines ersten Edge-Knotens 422 und eines zweiten Edge-Knotens 424 in einem Edge-Rechensystem 400 dar, um Anforderungen und Antworten für verschiedene Client-Endpunkte 410 (z. B. Smart-Städte / -Gebäude-Systeme, Mobilvorrichtungen, Rechenvorrichtungen, Unternehmens-/Logistiksysteme, Industriesysteme usw.) zu erfüllen, die auf verschiedene virtuelle Edge-Instanzen zugreifen. Hier stellen die virtuellen Edge-Instanzen 432, 434 Edge-Rechenfähigkeiten und Verarbeitung in einer Edge-Cloud mit Zugriff auf eine Cloud/ein Datenzentrum 440 für Anforderungen mit höherer Latenz für Websites, Anwendungen, Datenbankserver usw. bereit. Die Edge-Cloud ermöglicht jedoch eine Koordination der Verarbeitung zwischen mehreren Edge-Knoten für mehrere Mandanten oder Entitäten.
In dem Beispiel von 4 beinhalten diese virtuellen Edge-Instanzen: einen ersten virtuellen Edge 432, der einem ersten Mandanten (Mandant 1) angeboten wird und eine erste Kombination von Edge-Speicherung, -Berechnung und -Diensten anbietet; und einen zweiten virtuellen Edge 434, der eine zweite Kombination von Edge-Speicherung, -Berechnung und -Diensten anbietet. Die virtuellen Edge-Instanzen 432, 434 sind unter den Edge-Knoten 422, 424 verteilt und können Szenarien beinhalten, in denen eine Anforderung und Antwort von demselben oder unterschiedlichen Edge-Knoten erfüllt werden. Die Konfiguration der Edge-Knoten 422, 424 zum Arbeiten auf eine verteilte, aber koordinierte Weise findet basierend auf Edge-Bereitstellungsfunktionen 450 statt. Die Funktionalität der Edge-Knoten 422, 424 zum Bereitstellen eines koordinierten Betriebs für Anwendungen und Dienste unter mehreren Mandanten findet basierend auf Orchestrierungsfunktionen 460 statt.
Es versteht sich, dass manche der Vorrichtungen 410 Multi-Mandanten-Vorrichtungen sind, wobei Mandant 1 innerhalb eines Mandanten-1-„Slice“ fungieren kann, während ein Mandant 2 innerhalb eines Mandanten-2-„Slice“ fungieren kann (und in weiteren Beispielen können zusätzliche oder Unter-Mandanten existieren; und jeder Mandant kann sogar spezifisch berechtigt für und transaktionell an einen spezifischen Satz von Merkmalen bis zu spezifischen Hardwaremerkmalen gebunden sein). Eine vertrauenswürdige Multi-Mandanten-Vorrichtung kann ferner einen mandantenspezifischen kryptografischen Schlüssel enthalten, sodass die Kombination aus Schlüssel und Slice als eine „Root of Trust“ (RoT) oder mandantenspezifische RoT angesehen werden kann. Eine RoT kann ferner dynamisch unter Verwendung einer DICE-Architektur (DICE: Device Identity Composition Engine) berechnet werden, sodass ein einzelner DICE-Hardwarebaustein verwendet werden kann, um geschichtete vertrauenswürdige Rechenbasiskontexte zum Schichten von Vorrichtungsfähigkeiten (wie etwa ein feldprogrammierbares Gate-Array (FPGA)) zu konstruieren. Die RoT kann ferner für einen vertrauenswürdigen Rechenkontext verwendet werden, um einen „Fan-Out“ zu ermöglichen, der zum Unterstützen von Multi-Mandanten nützlich ist. Innerhalb einer Multi-Mandanten-Umgebung können die jeweiligen Edge-Knoten 422, 424 als Sicherheitsmerkmalvollzugspunkte für lokale Ressourcen arbeiten, die mehreren Mandanten pro Knoten zugewiesen sind. Zusätzlich dazu können Mandantenlaufzeit und Anwendungsausführung (z. B. in den Fällen 432, 434) als ein Vollzugspunkt für ein Sicherheitsmerkmal dienen, das eine virtuelle Edge-Abstraktion von Ressourcen erzeugt, die potenziell mehrere physische Hosting-Plattformen überspannen. Schließlich können die Orchestrierungsfunktionen 460 an einer Orchestrierungsentität als ein Sicherheitsmerkmalvollzugspunkt zum Marshalling von Ressourcen entlang Mandantengrenzen arbeiten.
Edge-Rechenknoten können Ressourcen (Speicher, Zentralverarbeitungseinheit (CPU), Grafikverarbeitungseinheit (GPU), Interrupt-Steuerung, Eingabe/Ausgabe(E/A)-Steuerung, Speichersteuerung, Bussteuerung usw.) partitionieren, wobei jeweilige Partitionierungen eine RoT-Fähigkeit enthalten können und wobei Fan-Out und Schichtbildung gemäß einem DICE-Modell ferner auf Edge-Knoten angewendet werden können. Cloud-Rechenknoten, die aus Containern, FaaS-Engines, Servlets, Servern oder einer anderen Berechnungsabstraktion bestehen, können gemäß einer DICE-Schichtbildungs- und Fan-Out-Struktur partitioniert werden, um jeweils einen RoT-Kontext zu unterstützen. Dementsprechend können die jeweiligen Vorrichtungen 410, 422 und 440, die RoTs überspannen, die Erstellung einer verteilten vertrauenswürdigen Rechenbasis (DTCB: Distributed Trusted Computing Base) koordinieren, sodass ein mandantenspezifischer virtueller vertrauenswürdiger sicherer Kanal, der alle Elemente Ende-zu-Ende verknüpft, erstellt werden kann.
Ferner versteht es sich, dass ein Container daten- oder arbeitslastspezifische Schlüssel aufweisen kann, die seinen Inhalt vor einem vorherigen Edge-Knoten schützen. Als Teil der Migration eines Containers kann eine Pod-Steuerung an einem Quell-Edge-Knoten einen Migrationsschlüssel von einer Ziel-Edge-Knoten-Pod-Steuerung erhalten, wobei der Migrationsschlüssel zum Wrappen der containerspezifischen Schlüssel verwendet wird. Wenn der Container/Pod zu dem Ziel-Edge-Knoten migriert wird, wird der Unwrapping-Schlüssel der Pod-Steuerung preisgegeben, die dann die gewrappten Schlüssel entschlüsselt. Die Schlüssel können nun zur Durchführung von Operationen an containerspezifischen Daten verwendet werden. Die Migrationsfunktionen können durch korrekt attestierte Edge-Knoten und Pod-Manager (wie oben beschrieben) angesteuert werden.
In weiteren Beispielen wird ein Edge-Rechensystem erweitert, um Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (einer eingebundenen, einsetzbaren Softwareeinheit, die Code und benötigte Abhängigkeiten bereitstellt) in einer Multi-Eigentümer-, Multi-Mandanten-Umgebung bereitzustellen. Ein Multi-Mandanten-Orchestrator kann verwendet werden, um Schlüsselverwaltung, Vertrauensanker-Verwaltung und andere Sicherheitsfunktionen in Bezug auf die Bereitstellung und den Lebenszyklus des vertrauenswürdigen „Slice“-Konzepts in 4 durchzuführen. Beispielsweise kann ein Edge-Rechensystem dazu konfiguriert sein, Anforderungen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einer Cloud oder einem entfernten Datenzentrum) zu erfüllen. Die Verwendung dieser virtuellen Edge-Instanzen kann mehrere Mandanten und mehrere Anwendungen (z. B. Augmented Reality (AR)/Virtual Reality (VR), Unternehmensanwendungen, Inhaltslieferung, Gaming, Rechen-Offload) gleichzeitig unterstützen. Ferner kann es mehrere Arten von Anwendungen innerhalb der virtuellen Edge-Instanzen geben (z. B. normale Anwendungen; latenzempfindliche Anwendungen; latenzkritische Anwendungen; Benutzerebenenanwendungen; Networking-Anwendungen usw.). Die virtuellen Edge-Instanzen können auch über Systeme mehrerer Eigentümer an unterschiedlichen geographischen Orten (oder jeweilige Rechensysteme und Ressourcen, den mehreren Eigentümern gemeinsam gehören oder gemeinsam von diesen verwaltet werden) gespannt sein.
Beispielsweise kann jeder der Edge-Knoten 422, 424 die Verwendung von Containern implementieren, wie etwa unter Verwendung eines Container-„Pod“ 426, 428, der eine Gruppe von einem oder mehreren Containern bereitstellt. In einer Einstellung, die eine oder mehrere Container-Pods verwendet, ist eine Pod-Steuerung oder ein Orchestrator für die lokale Steuerung und Orchestrierung der Container im Pod verantwortlich. Verschiedene Edge-Knotenressourcen (z. B. Speicherung, Berechnung, Dienste, dargestellt mit Hexagonen), die für die jeweiligen Edge-Slices 432, 434 bereitgestellt werden, werden gemäß den Bedürfnissen jedes Containers partitioniert.
Bei der Verwendung von Container-Pods übersieht eine Pod-Steuerung die Partitionierung und Zuweisung von Containern und Ressourcen. Die Pod-Steuerung empfängt Anweisungen von einem Orchestrator (z. B. dem Orchestrator 460), die die Steuerung darüber anweisen, wie physische Ressourcen am besten zu partitionieren sind und für welche Dauer, wie etwa durch Empfangen von KPI(Key Performance Indicator)-Zielen basierend auf SLA-Verträgen. Die Pod-Steuerung bestimmt, welcher Container welche Ressourcen und für wie lange benötigt, um die Arbeitslast abzuschließen und das SLA zu erfüllen. Die Pod-Steuerung verwaltet auch Container-Lebenszyklusvorgänge, wie etwa: Erzeugen des Containers, Versehen desselben mit Ressourcen und Anwendungen, Koordinieren von Zwischenergebnissen zwischen mehreren Containern, die auf einer verteilten Anwendung zusammenarbeiten, Zerlegen von Containern, wenn die Arbeitslast abgeschlossen ist, und dergleichen. Zusätzlich dazu kann eine Pod-Steuerung eine Sicherheitsrolle spielen, die eine Zuweisung von Ressourcen verhindert, bis sich der rechte Mandant authentifiziert, oder eine Bereitstellung von Daten oder einer Arbeitslast an einen Container verhindert, bis ein Attestierungsergebnis erfüllt ist.
Auch bei der Verwendung von Container-Pods können Mandantengrenzen weiterhin existieren, jedoch im Kontext jedes Pods von Containern. Falls jeder mandantenspezifische Pod eine mandantenspezifische Pod-Steuerung aufweist, wird es eine gemeinsam genutzte Pod-Steuerung geben, die Ressourcenzuweisungsanforderungen konsolidiert, um typische Ressourcenmangelsituationen zu vermeiden. Weitere Steuerungen können vorgesehen sein, um eine Attestierung und Vertrauenswürdigkeit des Pods und der Pod-Steuerung zu gewährleisten. Beispielsweise kann der Orchestrator 460 lokalen Pod-Steuerungen, die eine Attestierungsverifizierung durchführen, eine Attestierungsverifizierungsrichtlinie bereitstellen. Falls eine Attestierung eine Richtlinie für eine erste Mandanten-Pod-Steuerung, aber nicht eine zweite Mandanten-Pod-Steuerung erfüllt, dann könnte der zweite Pod zu einem anderen Edge-Knoten migriert werden, der ihn erfüllt. Alternativ dazu kann dem ersten Pod erlaubt werden, ausgeführt zu werden, und eine andere gemeinsam genutzte Pod-Steuerung wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
5 veranschaulicht zusätzliche Rechenanordnungen, die Container in einem Edge-Rechensystem einsetzen. Als ein vereinfachtes Beispiel stellen die Systemanordnungen 510, 520 Einstellungen dar, bei denen eine Pod-Steuerung (z. B. Container-Manager 511, 521 und ein Container-Orchestrator 531) dazu eingerichtet ist, containerisierte Pods, Funktionen, und Functions-as-a-Service-Instanzen durch Ausführung über Rechenknoten (515 in Anordnung 510) zu starten oder containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten (523 in Anordnung 520) separat auszuführen. Diese Anordnung ist zur Verwendung mehrerer Mandanten in einer beispielhaften Systemanordnung 530 (unter Verwendung von Rechenknoten 537) eingerichtet, wobei containerisierte Pods (z. B. Pods 512), Funktionen (z. B. Funktionen 513, VNFs 522, 536) und Functions-as-a-Service-Instanzen (z. B. FaaS-Instanz 514) innerhalb virtueller Maschinen (z. B. VMs 534, 535 für Mandanten 532, 533) gestartet werden, die spezifisch für jeweilige Mandanten sind (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen). Diese Anordnung ist ferner zur Verwendung in der Systemanordnung 540 eingerichtet, die Container 542, 543 oder die Ausführung der verschiedenen Funktionen, Anwendungen und Funktionen auf den Rechenknoten 544 bereitstellt, wie durch ein containerbasiertes Orchestrierungssystem 541 koordiniert.
Die in 5 dargestellten Systemanordnungen stellen eine Architektur bereit, die VMs, Container und Funktionen hinsichtlich der Anwendungszusammensetzung gleich behandelt (und resultierende Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann die Verwendung einer oder mehrerer Beschleuniger(FPGA, ASIC)-Komponenten als ein lokales Backend beinhalten. Auf diese Weise können Anwendungen über mehrere Edge-Eigentümer aufgeteilt werden, koordiniert durch einen Orchestrator.
Im Kontext von 5 können die Pod-Steuerung/der Container-Manager, der Container-Orchestrator und die einzelnen Knoten einen Sicherheitsvollzugspunkt bereitstellen. Die Mandantenisolation kann jedoch orchestriert werden, wobei sich die Ressourcen, die einem Mandanten zugewiesen sind, von Ressourcen unterscheiden, die einem zweiten Mandanten zugewiesen sind, aber Edge-Eigentümer kooperieren, um zu gewährleisten, dass Ressourcenzuweisungen nicht über Mandantengrenzen hinweg geteilt werden. Oder Ressourcenzuweisungen könnten über Mandantengrenzen hinweg isoliert werden, da Mandanten eine „Verwendung“ über eine Subskriptions- oder Transaktions-/Vertragsbasis ermöglichen könnten. In diesen Zusammenhängen können Virtualisierungs-, Containerisierungs-, Enklaven- und Hardwarepartitionierungsschemen von Edge-Eigentümern verwendet werden, um die Mandanten zu vollziehen. Andere Isolationsumgebungen können beinhalten: Bare-Metal(dedizierte)-Geräte, virtuelle Maschinen, Container, virtuelle Maschinen auf Containern oder Kombinationen davon.
Bei weiteren Beispielen können Aspekte von softwaredefinierter oder gesteuerter Siliziumhardware und anderer konfigurierbarer Hardware mit den Anwendungen, Funktionen und Diensten eines Edge-Rechensystems integrieren. Softwaredefiniertes Silizium kann verwendet werden, um zu gewährleisten, dass mancher Ressourcen- oder Hardwarebestandteil einen Vertrag oder ein Service-Level-Agreement erfüllen kann, basierend auf der Fähigkeit des Bestandteils, einen Teil von sich selbst oder die Arbeitslast zu beheben (z. B. durch ein Upgrade, eine Rekonfiguration oder eine Bereitstellung neuer Merkmale innerhalb der Hardwarekonfiguration selbst).
Es versteht sich, dass die hierin besprochenen Edge-Rechensysteme und -Anordnungen bei verschiedenen Lösungen, Diensten und/oder Verwendungsfällen anwendbar sein können, die Mobilität involvieren. Als ein Beispiel zeigt 6 einen beispielhaften vereinfachten Fahrzeugberechnungs- und -kommunikationsverwendungsfall, der Mobilzugriff auf Anwendungen in einem beispielhaften Edge-Rechensystem 600 involviert, das eine Edge-Cloud, wie etwa die Edge-Cloud 110 von 1, implementiert. In diesem Verwendungsfall können die jeweiligen Client-Rechenknoten 610 als fahrzeuginterne Rechensysteme (z. B. fahrzeuginterne Navigations- und/oder Infotainment-Systeme) umgesetzt sein, die sich in entsprechenden Fahrzeugen befinden, die mit den beispielhaften Edge-Gateway-Knoten 620 während des Durchfahrens einer Straße kommunizieren. Beispielsweise können sich die Edge-Gateway-Knoten 620 in einem Schaltschrank oder einer anderen Einhausung befinden, die in eine Struktur eingebaut ist, die einen anderen, separaten, mechanischen Nutzen aufweist und entlang der Straße, an Kreuzungen der Straße oder anderen Orten nahe der Straße platziert werden kann. Wenn jeweilige Fahrzeuge entlang der Straße fahren, kann die Verbindung zwischen ihrem Client-Rechenknoten 610 und einem speziellen der Edge-Gateway-Knoten 620 propagieren, um eine konsistente Verbindung und einen konsistenten Kontext für den beispielhaften Client-Rechenknoten 610 aufrechtzuerhalten. Gleichermaßen können mobile Edge-Knoten an den Diensten mit hoher Priorität oder gemäß den Durchsatz- oder Latenzauflösungsvoraussetzungen für den einen oder die mehreren zugrundeliegenden Dienste aggregieren (z. B. im Fall von Drohnen). Die jeweiligen Edge-Gateway-Vorrichtungen 620 beinhalten eine Menge an Verarbeitungs- und Speicherungsfähigkeiten und daher kann eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 610 auf einem oder mehreren der Edge-Gateway-Knoten 620 durchgeführt werden.
Die Edge-Gateway-Knoten 620 können mit einem oder mehreren Edge-Ressourcenknoten 640 kommunizieren, die veranschaulichend als Rechenserver, -geräte oder -komponenten umgesetzt sind, die sich an oder in einer Kommunikationsbasisstation 642 (z. B. einer Basisstation eines zellularen Netzes) befinden. Wie oben besprochen, beinhalten der eine oder die mehreren jeweiligen Edge-Ressourcenknoten 640 eine Menge an Verarbeitungs- und Speicherungsfähigkeiten, sodass eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenknoten 610 an dem einen oder den mehreren Edge-Ressourcenknoten 640 durchgeführt werden kann. Zum Beispiel kann die Verarbeitung von Daten, die weniger dringend oder wichtig sind, durch den einen oder die mehreren Edge-Ressourcenknoten 640 durchgeführt werden, während die Verarbeitung von Daten, die eine höhere Dringlichkeit oder Wichtigkeit aufweisen, durch die Edge-Gateway-Vorrichtungen 620 durchgeführt werden kann (in Abhängigkeit von zum Beispiel den Fähigkeiten jeder Komponente oder Informationen in der Anforderung, die Dringlichkeit oder Wichtigkeit angeben). Basierend auf Datenzugriff, Datenort oder Latenz kann die Arbeit auf Edge-Ressourcenknoten fortgesetzt werden, wenn sich die Verarbeitungsprioritäten während der Verarbeitungsaktivität ändern. Gleichermaßen können konfigurierbare Systeme oder Hardwareressourcen selbst aktiviert werden (z. B. durch einen lokalen Orchestrator), um zusätzliche Ressourcen bereitzustellen, um den neuen Bedarf zu erfüllen (z. B. Anpassen der Rechenressourcen an die Arbeitslastdaten).
Der eine oder die mehreren Edge-Ressourcenknoten 640 kommunizieren auch mit dem Kerndatenzentrum 650, das Rechenserver, -geräte und/oder andere Komponenten beinhalten kann, die sich an einem Zentralort (z. B. einer Zentrale eines zellularen Kommunikationsnetzes) befinden. Das beispielhafte Kerndatenzentrum 650 kann ein Gateway zu der globalen Netzwerk-Cloud 660 (z. B. das Internet) für die Operationen der Edge-Cloud 110 bereitstellen, die durch den einen oder die mehreren Edge-Ressourcenknoten 640 und die Edge-Gateway-Vorrichtungen 620 gebildet werden. Zusätzlich kann das Kerndatenzentrum 650 in manchen Beispielen eine Menge an Verarbeitungs- und Speicherungsfähigkeiten beinhalten und somit kann eine gewisse Verarbeitung und/oder Speicherung von Daten für die Client-Rechenvorrichtungen auf dem Kerndatenzentrum 650 durchgeführt werden (z. B. Verarbeitung mit niedriger Dringlichkeit oder Wichtigkeit oder hoher Komplexität).
Die Edge-Gateway-Knoten 620 oder der eine oder die mehreren Edge-Ressourcenknoten 640 können die Verwendung zustandsbehafteter Anwendungen 632 und einer geographisch verteilten Datenbank 634 anbieten. Obwohl die Anwendungen 632 und die Datenbank 634 als horizontal auf einer Schicht der Edge-Cloud 110 verteilt veranschaulicht sind, versteht es sich, dass Ressourcen, Dienste, oder andere Komponenten der Anwendung vertikal in der gesamten Edge-Cloud verteilt sein können (einschließlich eines Teils der Anwendung, die an dem Client-Rechenknoten 610 ausgeführt wird, anderer Teile an den Edge-Gateway-Knoten 620 oder dem einen oder den mehreren Edge-Ressourcenknoten 640 usw.). Zusätzlich dazu kann es, wie zuvor angegeben, Peer-Beziehungen auf einer beliebigen Ebene geben, um Dienstziele und Verpflichtungen zu erfüllen. Ferner können sich die Daten für einen speziellen Client oder eine spezielle Anwendung basierend auf sich ändernden Bedingungen von Edge zu Edge bewegen (z. B. basierend auf Beschleunigungsressourcenverfügbarkeit, Folgen der Autobewegung usw.). Beispielsweise kann basierend auf der „Abklingrate“ des Zugangs eine Vorhersage getroffen werden, um den nächsten fortsetzenden Eigentümer zu identifizieren, oder wann die Daten oder der rechnerische Zugang nicht mehr umsetzbar sein werden. Diese und andere Dienste können genutzt werden, um die Arbeit abzuschließen, die benötigt wird, um die Transaktion konform und verlustfrei zu halten.
In weiteren Szenarien kann ein Container 636 (oder ein Pod von Containern) flexibel von einem der Edge-Knoten 620 zu anderen Edge-Knoten (z. B. einem anderen der Edge-Knoten 620, einem des einen oder der mehreren Edge-Ressourcenknoten 640 usw.) migriert werden, sodass der Container mit einer Anwendung und Arbeitslast nicht rekonstituiert, rekompiliert, reinterpretiert werden muss, damit die Migration funktioniert. In solchen Einstellungen kann es jedoch einige angewendete Abhilfe- oder „Swizzling“-Übersetzungsoperationen geben. Zum Beispiel kann sich die physische Hardware an dem einen oder den mehreren Edge-Ressourcenknoten 640 von der Hardware an dem einen oder den mehreren Edge-Ressourcenknoten 620 unterscheiden und daher wird die Hardware-Abstraktionsschicht (HAL), die den unteren Rand des Containers bildet, erneut auf die physische Schicht des Ziel-Edge-Knotens abgebildet. Dies kann irgendeine Form einer späten Bindungstechnik beinhalten, wie etwa binäre Übersetzung der HAL von dem nativen Containerformat in das physische Hardwareformat, oder kann Abbildungsschnittstellen und -operationen beinhalten. Eine Pod-Steuerung kann verwendet werden, um die Schnittstellenabbildung als Teil des Container-Lebenszyklus anzusteuern, was Migration zu/von verschiedenen Hardwareumgebungen beinhaltet.
Die Szenarien, die von 6 eingeschlossen werden, können verschiedene Arten von mobilen Edge-Knoten nutzen, wie etwa einen Edge-Knoten, der in einem Fahrzeug (Auto/Lastkraftwagen/Straßenbahn/Zug) gehostet wird, oder eine andere mobile Einheit, da sich der Edge-Knoten zu anderen geografischen Orten entlang der Plattform, die ihn hostet, bewegen wird. Bei Fahrzeug-zu-Fahrzeug-Kommunikationen können einzelne Fahrzeuge sogar als Netzwerk-Edge-Knoten für andere Autos fungieren (z. B. um Caching, Berichterstellung, Datenaggregation usw. durchzuführen). Somit versteht es sich, dass die Anwendungskomponenten, die in verschiedenen Edge-Knoten bereitgestellt sind, in statischen oder mobilen Einstellungen verteilt sein können, einschließlich Koordination zwischen einigen Funktionen oder Operationen an einzelnen Endpunktvorrichtungen oder den Edge-Gateway-Knoten 620, einigen anderen an dem einen oder den mehreren Edge-Ressourcenknoten 640 und anderen in dem Kerndatenzentrum 650 oder der globalen Netzwerk-Cloud 660.
Bei weiteren Konfigurationen kann das Edge-Rechensystem FaaS-Rechenfähigkeiten durch die Verwendung jeweiliger ausfuhrbarer Anwendungen und Funktionen implementieren. In einem Beispiel schreibt ein Entwickler Funktionscode (hier z. B. „Computercode“), der eine oder mehrere Computerfunktionen repräsentiert, und der Funktionscode wird auf eine FaaS-Plattform hochgeladen, die zum Beispiel durch einen Edge-Knoten oder ein Datenzentrum bereitgestellt wird. Ein Auslöser, wie beispielsweise ein Dienstverwendungsfall oder ein Edge-Verarbeitungsereignis, initiiert die Ausführung des Funktionscodes mit der FaaS-Plattform.
Bei einem Beispiel für FaaS wird ein Container verwendet, um eine Umgebung bereitzustellen, in der Funktionscode (z. B. eine Anwendung, die durch eine Drittpartei bereitgestellt werden kann) ausgeführt wird. Der Container kann eine beliebige Entität mit isolierter Ausführung sein, wie etwa ein Prozess, ein Docker- oder Kubernetes-Container, eine virtuelle Maschine usw. Innerhalb des Edge-Rechensystems werden verschiedene Datenzentrum-, Edge- und Endpunktvorrichtungen (einschließlich Mobilvorrichtungen) verwendet, um Funktionen „hochzufahren“ (z. B. Funktionshandlungen zu aktivieren und/oder zuzuweisen), die nach Bedarf skaliert werden. Der Funktionscode wird auf der physischen Infrastrukturvorrichtung (z. B. Edge-Rechenknoten) und zugrundeliegenden virtualisierten Containern ausgeführt. Schließlich wird der Container auf der Infrastruktur als Reaktion darauf, dass die Ausführung abgeschlossen ist, „heruntergefahren“ (z. B. deaktiviert und/oder freigegeben).
Weitere Aspekte von FaaS können das Einsetzen von Edge-Funktionen auf eine Dienstweise ermöglichen, einschließlich einer Unterstützung jeweiliger Funktionen, die Edge-Computing als einen Dienst unterstützen (Edge-as-a-Service oder „EaaS“). Zusätzliche Merkmale von FaaS können beinhalten: eine granuläre Abrechnungskomponente, die Kunden (z. B. Computercodeentwicklern) ermöglicht, nur zu bezahlen, wenn ihr Code ausgeführt wird; gemeinsame Datenspeicherung zum Speichern von Daten zur Wiederverwendung durch eine oder mehrere Funktionen; Orchestrierung und Verwaltung zwischen einzelnen Funktionen; Funktionsausführungsverwaltung, Parallelität und Konsolidierung; Verwaltung von Container- und Funktionsspeicherräumen; Koordination von Beschleunigungsressourcen, die für Funktionen verfügbar sind; und Verteilung von Funktionen zwischen Containern (einschließlich „warmer“ Container, die bereits eingesetzt oder betrieben werden, gegenüber „kalten“, die Initialisierung, Einsatz oder Konfiguration erfordern).
Das Edge-Rechensystem 600 kann einen Edge-Bereitstellungsknoten 644 beinhalten oder mit diesem in Kommunikation stehen. Der Edge-Bereitstellungsknoten 644 kann Software, wie etwa die beispielhaften computerlesbaren Anweisungen 1482 von 14B, an verschiedene Empfangsparteien zum Implementieren eines beliebigen der hierin beschriebenen Verfahren verteilen. Der beispielhafte Edge-Bereitstellungsknoten 644 kann durch einen beliebigen Computerserver, einen Heimserver, ein Inhaltslieferungsnetzwerk, einen virtuellen Server, ein Softwareverteilungssystem, eine zentrale Anlage, eine Speicherungsvorrichtung, einen Speicherungsknoten, eine Datenanlage, einen Cloud-Dienst usw. implementiert werden, der/die/das in der Lage ist, Softwareanweisungen (z. B. Code, Skripte, ausführbare Binärcodes, Container, Pakete, komprimierte Dateien und/oder Ableitungen davon) zu speichern und/oder an andere Rechenvorrichtungen zu übertragen. Eine oder mehrere Komponenten des beispielhaften Edge-Bereitstellungsknotens 644 können sich in einer Cloud, in einem lokalen Netzwerk, in einem Edge-Netzwerk, in einem Weitbereichsnetzwerk, im Internet und/oder einem beliebigen anderen Standort befinden, der kommunikativ mit der/den Empfangspartei(en) gekoppelt ist. Die Empfangsparteien können Kunden, Clients, Teilhaber, Benutzer usw. der Entität sein, die den Edge-Bereitstellungsknoten 644 besitzt und/oder betreibt. Beispielsweise kann die Entität, die den Edge-Bereitstellungsknoten 644 besitzt und/oder betreibt, ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber (oder ein Kunde und/oder Verbraucher davon) von Softwareanweisungen, wie etwa die beispielhaften computerlesbaren Anweisungen 1482 von 14B, sein. Die Empfangsparteien können Verbraucher, Dienstanbieter, Benutzer, Einzelhändler, OEMs usw. sein, die die Softwareanweisungen zur Verwendung erwerben und/oder lizenzieren und/oder wiederverkaufen und/oder unterlizenzieren.
Bei einem Beispiel beinhaltet der Edge-Bereitstellungsknoten 644 einen oder mehrere Server und eine oder mehrere Speicherungsvorrichtungen. Die Speicherungsvorrichtungen hosten computerlesbare Anweisungen, wie etwa die beispielhaften computerlesbaren Anweisungen 1482 von 14B, wie unten beschrieben. Ähnlich den oben beschriebenen Edge-Gateway-Vorrichtungen 620 stehen der eine oder die mehreren Server des Edge-Bereitstellungsknotens 644 in Kommunikation mit einer Basisstation 642 oder einer anderen Netzwerkkommunikationsentität. Bei manchen Beispielen reagieren der eine oder die mehreren Server auf Anforderungen, die Softwareanweisungen als Teil einer kommerziellen Transaktion zu einer anfordernden Partei zu übertragen. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Softwareanweisungen kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Drittpartei-Bezahlungsentität gehandhabt werden. Die Server ermöglichen Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 1482 von dem Edge-Bereitstellungsknoten 644 herunterzuladen. Zum Beispiel können die Softwareanweisungen, die den beispielhaften computerlesbaren Anweisungen 1482 von 14B entsprechen können, zu der/den beispielhaften Prozessorplattform/en heruntergeladen werden, die die computerlesbaren Anweisungen 1482 ausführen sollen, um die hierin beschriebenen Verfahren zu implementieren.
Bei manchen Beispielen können sich die Prozessorplattform(en), die die computerlesbaren Anweisungen 1482 ausführen, physisch an verschiedenen geografischen Standorten, gesetzlichen Jurisdiktionen usw. befinden. Bei manchen Beispielen bieten, übertragen und/oder erzwingen ein oder mehrere Server des Edge-Bereitstellungsknotens 644 periodisch Aktualisierungen für die Softwareanweisungen (z. B. die beispielhaften computerlesbaren Anweisungen 1482 von 14B), um zu gewährleisten, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Softwareanweisungen angewendet werden, die an den Endbenutzervorrichtungen implementiert sind. Bei manchen Beispielen können unterschiedliche Komponenten der computerlesbaren Anweisungen 1482 von unterschiedlichen Quellen und/oder an unterschiedliche Prozessorplattformen verteilt werden; zum Beispiel können unterschiedliche Bibliotheken, Plug-Ins, Komponenten und andere Typen von Rechenmodulen, ob kompiliert oder interpretiert, von unterschiedlichen Quellen und/oder an unterschiedliche Prozessorplattformen verteilt werden. Zum Beispiel kann ein Teil der Softwareanweisungen (z. B. ein Skript, das an sich nicht ausführbar ist) von einer ersten Quelle verteilt werden, während ein Interpreter (der in der Lage ist, das Skript auszuführen) von einer zweiten Quelle verteilt werden kann.
In weiteren Beispielen können beliebige der Rechenknoten oder Vorrichtungen, die unter Bezugnahme auf die vorliegenden Edge-Rechensysteme und die vorliegende Umgebung erörtert wurden, basierend auf den Komponenten, die in den 14A und 14B dargestellt sind, erfüllt werden. Jeweilige Edge-Rechenknoten können als ein Typ von Vorrichtung, Gerät, Computer oder anderem „Ding“ umgesetzt sein, der/die/das in der Lage ist, mit anderen Edge-, Networking- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Personal Computer, Server, Smartphone, eine mobile Rechenvorrichtung, ein Smart-Gerät, ein fahrzeuginternes Rechensystem (z. B. ein Navigationssystem), eine eigenständige Vorrichtung mit einem Außengehäuse, einer Umhüllung usw. oder eine andere Vorrichtung oder ein anderes System, die/das in der Lage ist, die beschriebenen Funktionen durchzuführen, umgesetzt sein.
7 ist ein Blockdiagramm einer beispielhaften Umgebung 700 zum Ermöglichen des Verwaltens einer Dienstgüte gemäß hierin offenbarten Beispielen. Die beispielhafte Umgebung 700 beinhaltet die beispielhafte Edge-Cloud 110 der 1, 2, 3 und/oder 6 und eine beispielhafte Cloud/ein beispielhaftes Datenzentrum 701, ein beispielhaftes Netzwerk 702, eine beispielhafte Domäne 703, einen beispielhaften Broker 704 und beispielhafte Rechenvorrichtungen 706, 708. Obwohl das Beispiel von 7 einem Cloud-basierten Netzwerk entspricht, können hierin offenbarte Beispiele auf eine beliebige Art von Rechenumgebung (z. B. virtuelle Maschinen, Racks von Servern usw.) angewendet werden. In manchen Beispielen entspricht die Cloud/das Datenzentrum 701 der Cloud/dem Datenzentrum 360, 440 der 3 und/oder 4 und/oder der globalen Netzwerk-Cloud 660 von 6. Zusätzlich dazu können die beispielhaften Rechenvorrichtungen 706, 708 den beispielhaften Edge-Knoten 422, 424, 620, 644 der 4 und/oder 6 entsprechen.
Die beispielhafte Cloud/das beispielhafte Datenzentrum 701 von 7 ist eine Rechenvorrichtung, die mit dem beispielhaften Broker 704 und/oder den beispielhaften Rechenvorrichtungen 706, 708 (z. B. über das beispielhafte Netzwerk 702) eine Schnittstelle bildet, um einen Betrieb verbundener Vorrichtungen zu überwachen und/oder zu ermöglichen. In manchen Beispielen kann die Cloud/das Datenzentrum 701 Daten von Rechenvorrichtungen erhalten, um rechenintensivere Aufgaben durchzuführen. In manchen Beispielen kann die Cloud/das Datenzentrum 701 Aufgaben einsetzen, die an anderen Rechenvorrichtungen (z. B. den beispielhaften Rechenvorrichtungen 706, 708) durchgeführt werden sollen. Der beispielhafte Cloud-basierte Server 701 kann in einer privaten Cloud und/oder einer öffentlichen Cloud implementiert werden. Bei manchen Beispielen ist die Cloud/das Datenzentrum 701 ein Server, der virtuelle Maschinen oder Server in einem Rack implementiert und verwaltet.
Das beispielhafte Netzwerk 702 von 7 ist ein System von miteinander verbundenen Systemen, die Daten zwischen der Cloud/dem Datenzentrum 701 und Verarbeitungsvorrichtungen (z. B. dem Broker 704 und/oder den Rechenvorrichtungen 706, 708) austauschen. Das beispielhafte Netzwerk 702 kann unter Verwendung einer beliebigen Art von öffentlichem oder privatem Netzwerk implementiert werden, wie etwa unter anderem das Internet, ein Telefonnetzwerk, ein lokales Netzwerk (LAN), ein Kabelnetzwerk und/oder ein drahtloses Netzwerk. Um eine Kommunikation über das beispielhafte Netzwerk 702 zu ermöglichen, beinhalten die Cloud/das Datenzentrum 701, der Broker 704 und/oder die Rechenvorrichtungen 706, 708 eine Kommunikationsschnittstelle, die eine Verbindung mit einem Ethernet, einer digitalen Teilnehmerleitung (DSL), einer Telefonleitung, einem Koaxialkabel, einer beliebigen drahtlosen Verbindung usw. ermöglicht.
Die beispielhafte Domäne 703 von 7 beinhaltet den beispielhaften Broker 704 und die beispielhaften Rechenvorrichtungen 706, 708. Die beispielhafte Domäne 703 kann eine Edge-Domäne, eine Fog-Domäne und eine IoT-Domäne, eine Virtuelle-Maschine(VM)-Domäne, eine Multi-Access-Edge-Computing(MEC)-Domäne usw. sein. Obwohl die beispielhafte Domäne 703 einen Broker 704 und zwei Rechenvorrichtungen 706, 708 beinhaltet, kann die Domäne 703 eine beliebige Anzahl von Brokern und/oder Rechenvorrichtungen beinhalten. Zusätzlich dazu kann es andere Domänen geben, die über das Netzwerk 702 (z. B. in demselben Edge-Netzwerk 110 oder einem anderen Edge-Netzwerk) verbunden sind. Wie hierin verwendet, wird eine Kommunikation zwischen einer Vorrichtung in der Domäne 703 und einer Vorrichtung außerhalb der Domäne 703 als Inter-Domänen-Kommunikation bezeichnet und eine Kommunikation zwischen Vorrichtungen innerhalb der Domäne 703 wird als Intra-Domänen-Kommunikation bezeichnet.
Der beispielhafte Broker 704 von 7 verwaltet die Verwendung der gepoolten Ressourcen der beispielhaften Rechenvorrichtungen 706, 708 basierend auf QoS-Voraussetzungen, die einer Dienstanforderung entsprechen. Beispielsweise kann der Broker 704 eine Dienstanforderung (z. B. um eine oder mehrere Aufgaben durchzuführen) von einer der Rechenvorrichtungen 706, 708, einer Rechenvorrichtung von einer anderen Domäne (z. B. über einen anderen Broker) und/oder der Cloud/dem Datenzentrum 701 erhalten. Nachdem die Dienstanforderung erhalten wurde, identifiziert der Broker 704 die SLA/SLO-Voraussetzungen, die der Dienstanforderung entsprechen, und überträgt die SLA/SLO-Voraussetzungen an die Rechenvorrichtungen 706, 708 der Domäne 703. Wie unten weiter beschrieben, bestimmen die beispielhaften Rechenvorrichtungen 706, 708, ob sie die Fähigkeit aufweisen, die SLA/SLO-Voraussetzungen zu erreichen, und geben eine Antwort an den Broker 704 zurück. Nachdem der beispielhafte Broker 704 die Antworten empfängt, weist der Broker 704 die gepoolten Ressourcen der Rechenvorrichtungen 706, 708 basierend auf ihrer Antwort zum Versorgen der Anforderung, während die entsprechenden SLA/SLO-Voraussetzungen am besten erreicht werden, zu. Bei manchen Beispielen könnte der Broker 704 innerhalb der beispielhaften Rechenvorrichtungen 706, 708 implementiert werden (wobei z. B. eine der Rechenvorrichtungen als eine führende Rechenvorrichtung agiert, und/oder in beiden Vorrichtungen). Der beispielhafte Broker 704 wird weiter unten in Verbindung mit 10A beschrieben.
Die beispielhaften Rechenvorrichtungen 706, 708 von 7 können Edge-Vorrichtungen, IoT-Vorrichtungen, Fog-Vorrichtungen, virtuelle Maschinen, Server und/oder eine beliebige andere Art von Rechenvorrichtung sein. In manchen Beispielen erhalten die Rechenvorrichtungen 706, 708 SLA/SLO-Voraussetzungen basierend auf einer Dienstanforderung, die gepoolten Ressourcen entspricht. Gepoolte Ressourcen können Speicher, Speicherung, Hardwarebeschleuniger usw. sein, die miteinander und/oder von einer beliebigen anderen Vorrichtung in der Domäne 703 (z. B. Inter-Domänen) und/oder einer anderen Domäne (z. B. Intra-Domänen) gemeinsam genutzt werden können. Die beispielhaften Rechenvorrichtungen 706, 708 beinhalten gepoolte QoS-Steuerungen, um die notwendige Menge an Speicher- und/oder Prozessorressourcen zu bestimmen, die benötigt werden, um die SLA/SLO-Voraussetzung zu erfüllen. Nachdem die Ressourcenmenge bestimmt wurde, bestimmen die gepoolten QoS-Steuerungen, ob die jeweilige Rechenvorrichtung 706, 708 genügend verfügbare Speicher- und/oder Verarbeitungsressourcen aufweist, um die bestimmte Ressourcenmenge zu erfüllen. Die beispielhaften Rechenvorrichtungen 706, 708 senden eine Antwort an den Broker 704 basierend darauf, ob die Rechenvorrichtungen 706, 708 genügend verfügbare Ressourcen aufweisen oder nicht, um die Anforderung gemäß den SLA/SLO-Voraussetzungen zu versorgen. Falls der beispielhafte Broker 704 bestimmt, dass eine oder mehrere der Rechenvorrichtungen 706, 708 einen Teil oder die gesamte Dienstanforderung versorgen sollten, wird der Broker 704 Anweisungen darüber übertragen, wie der Teil oder die gesamte Dienstanforderung versorgt werden soll, und die Rechenvorrichtung 706 wird einen Teil oder die gesamte Dienstanforderung basierend auf den Anweisungen versorgen. Die gepoolte QoS-Steuerung der Rechenvorrichtung 706 ist weiter unten in Verbindung mit 10A beschrieben.
In manchen Beispielen nutzen die Rechenvorrichtungen 706, 708 von 7 einen Mesh-Proxy, um RDT-Unterstützung wirksam einzusetzen, um zu ermöglichen, dass Anwendungen implementiert werden, ohne eine SLA/SLO-Bibliothek, ein Startprogramm und/oder einen Administrator zu beinhalten, um SLAs in ressourcenbasierte Attribute in ressourcenbasierte Attribute zu übersetzen und RDT-Steuersignale basierend auf den ressourcenbasierten Attributen für verschiedene Rechenvorrichtungstypen zu erzeugen (z. B. können Anwendungen plattformagnostisch sein (z. B. nicht spezifisch für ein bestimmtes Betriebssystem und/oder eine bestimmte Hardware) und anwendungsspezifische Logik ohne plattformspezifische Logik beinhalten). Auf diese Weise werden die Größe und Komplexität von Anwendungen reduziert. In solchen Beispielen erhält der Mesh-Proxy proxidierte SLA/SLO-Verwaltungsinformationen hoher Ebene (z. B. SLA/SLO-Voraussetzungen), wandelt die Voraussetzungen in ressourcenbasierte Attribute um, erzeugt die RDT-Steuerinformationen (z. B. die Menge an Ressourcen, die benötigt wird, um die SLA/SLO-Voraussetzungen basierend auf den ressourcenbasierten Attributen zu erfüllen), und sendet die RDT-Steuerinformationen an das OS der Rechenvorrichtung 706. Das OS kann RDT-Erweiterungen nutzen, um zu gewährleisten, dass der Prozessor und/oder die Speicherressourcen, die dem RDT-Steuersignal entsprechen, genutzt werden, um das SLA/SLO zu erfüllen. Zusätzlich dazu können die Rechenvorrichtungen 706, 708 ein Software(Soft)-QoS-Mesh nutzen, um einen Lastausgleich zwischen mehreren Anwendungen mit mehreren unterschiedlichen SLA/SLO-Voraussetzungen durchzuführen, wie unten in Verbindung mit 9 weiter beschrieben wird. Der beispielhafte Mesh-Proxy wird weiter unten in Verbindung mit den 8 und 9 beschrieben und das Soft-QoS-Mesh ist unten in Verbindung mit 9 weiter beschrieben.
8 ist ein Blockdiagramm einer beispielhaften Implementierung der beispielhaften Rechenvorrichtung 706 von 1. Die beispielhafte Rechenvorrichtung 706 beinhaltet beispielhafte Anwendungen 800, 802, beispielhafte Mesh-Proxys 804, 806, ein beispielhaftes OS 808 und beispielhafte Hardwarekomponenten 810. Obwohl die beispielhafte Rechenvorrichtung 706 von 8 zwei Anwendungen und zwei Mesh-Proxys beinhaltet, kann die Rechenvorrichtung 706 eine beliebige Anzahl von Rechenvorrichtungen und/oder Mesh-Proxys beinhalten.
Die beispielhaften Anwendungen 800, 802 von 8 sind Anwendungen, die auf die beispielhafte Rechenvorrichtung 706 installiert und/oder heruntergeladen wurden. Die beispielhaften Anwendungen 800, 802 beinhalten Code, der, wenn er durch das OS 808 ausgeführt wird, eine oder mehrere Aufgaben ausführt. Wie oben beschrieben, sind die beispielhaften Anwendungen 800 plattformagnostisch (z. B. OS- und/oder Hardwareagnostisch), da der Netz-Proxy 804 eine RDT-Unterstützung beinhaltet. Die beispielhaften Anwendungen 800, 802 können SLA-Verwaltungsinformationen hoher Ebene beinhalten, die SLA/SLO-Voraussetzungen entsprechen. Der entsprechende Mesh-Proxy 804, 806, der den jeweiligen Anwendungen 800, 802 zugeordnet wurde, wandelt die SLA-Verwaltungsinformationen in ressourcenbasierte Attribute um. Auf diese Weise erzeugt der entsprechende Mesh-Proxy 804, 806 ein RDT-Steuersignal, um die Prozessor- und/oder Speicherressourcen zu reservieren, die benötigt werden, um die SLA/SLO-Voraussetzungen zu erfüllen, ohne die Notwendigkeit eines SLA-Startprogramms oder von SLA-Bibliotheken, die den Anwendungen 800, 802 entsprechen. Die beispielhaften Anwendungen 800, 802 können von dem Cloud-basierten Server 701 (1) und/oder von einer anderen Rechenvorrichtung in der Domäne 703 (1) und/oder einer anderen Domäne eingesetzt werden.
Die beispielhaften Mesh-Proxys 804, 806 von 8 sind Komponenten, die die Kommunikation zwischen den Anwendungen 800, 802 und dem OS 808 überbrücken. Auf diese Weise können die Anwendungen 800, 802 SLA/SLO-Voraussetzungen an die beispielhaften jeweiligen Mesh-Proxys 804, 806 übertragen und die Mesh-Proxys 804, 806 können die SLA/SLO-Voraussetzungen in ressourcenbasierte Attribute umwandeln, um ein RDT-Steuersignal zu erzeugen, das der Menge an Speicher- und/oder Prozessorressourcen entspricht, die benötigt werden, um die SLA/SLO-Voraussetzungen zu erfüllen. Zusätzlich dazu können die beispielhaften Mesh-Proxys 804, 806 Telemetriedaten von dem OS 808 erhalten. Telemetriedaten beinhalten Daten, die verwendet werden, um Leistungsfähigkeit und Verfügbarkeit von Hardwarekomponenten 810 (z. B. Prozessorkerne, Speicher, Speicherung, Zentralverarbeitungseinheit (CPU), GPU und/oder beliebigen anderen Hardwarekomponenten) zu überwachen. Die beispielhaften Mesh-Proxys 804, 806 können die Telemetriedaten analysieren, um zu bestimmen, ob die SLA/SLO-Voraussetzungen erfüllt sind, und/oder können die Telemetriedaten und/oder eine Konformitätsangabe an die jeweiligen Anwendungen 800, 802 übertragen. Da die Verarbeitung von Telemetriedaten durch die Mesh-Proxys 804, 806 (z. B. im Gegensatz zu den Anwendungen 800, 802) durchgeführt wird, können die Anwendungen 800, 802 zum Lastausgleich, elastischen Skalieren usw. frei migriert oder repliziert werden, ohne spezifisch für die Konfigurationen und spezialisierte Beschleunigung gemacht zu werden, die in einer Rechenvorrichtung verfügbar sind. Zusätzlich ermöglicht das Verarbeiten von Telemetriedaten an den Mesh-Proxys 804, 806 der Rechenvorrichtung 706, softwarebasierte QoS und softwarebasierte hierarchische QoS durchzuführen, wie unten in Verbindung mit 9 weiter beschrieben ist.
In manchen Beispielen können die Telemetriedaten Datenschutz-sensitiv sein. Verbraucher von Telemetriedaten könnten aus den Telemetriedaten auf Informationen schließen, die über den unmittelbaren Betrieb der sie verbrauchenden Instanz hinausgehen. Zum Beispiel kann ein Lastausgleicher die Telemetriedaten verwenden, um die Lastausgleichseffizienz zu verbessern, und kann auch die Telemetriedaten verwenden, um ein Modell mit ausgereifter künstlicher Intelligenz (z. B. maschinelles Lernen, Deep-Learning, neuronales Netzwerk usw.) aufzubauen, um Inferenzdaten zu erzeugen. In einigen Beispielen (z. B. wenn solche Daten privat oder wertvoll sind) können die Telemetriedaten zu einer vertrauenswürdigen Ausführungsumgebung (TEE) verschlüsselt werden. Somit können die beispielhaften Mesh-Proxys 804, 806 erfordern, dass eine Telemetrieinferenzanwendung autorisiert ist, eine spezifische Optimierungsfunktion mit der TEE durchzuführen. Eine beispielhafte TEE wird weiter unten in Verbindung mit 14 beschrieben.
Das beispielhafte OS 808 von 8 erhält RDT-Steueranweisungen von den beispielhaften Mesh-Proxys 804, 806 und reserviert die Hardwarekomponenten 810 basierend auf dem RDT-Steuersignal (z. B. unter Verwendung von RDT-Erweiterungen), um zu gewährleisten, dass die entsprechenden SLA/SLO-Voraussetzungen erfüllt werden. Nachdem die Hardware reserviert ist, führt das beispielhafte OS 808 die Anweisungen der Anwendung(en) 800, 802 unter Verwendung der reservierten Hardwarekomponenten 810 aus, um die SLA/SLO-Voraussetzungen zu erfüllen. Zusätzlich überwacht das beispielhafte OS 808 die Hardwarekomponenten 810, um Telemetriedaten zu entwickeln, die der Verwendung der Hardwarekomponenten 810 entsprechen (z. B. Bandbreite, Latenz, Latenzdivergenz, Jitter, Anzahl von Paketverwürfen usw.). Das beispielhafte OS 808 überträgt die Telemetriedaten periodisch, aperiodisch und/oder basierend auf einem Auslöser an den entsprechenden Mesh-Proxy 804, 806. Das beispielhafte OS 808 nutzt die Hardwarekomponenten 810, um die Anweisungen der Anwendung 800 auszuführen. Die Hardwarekomponenten 810 können Prozessorkerne, CPU, GPU, Speicher, Speicherung, Hardwarebeschleuniger usw. beinhalten.
9 ist ein Blockdiagramm einer alternativen beispielhaften Implementierung der beispielhaften Rechenvorrichtung 706 von 1. Die beispielhafte Rechenvorrichtung 706 beinhaltet beispielhafte Anwendungen 900, 902, 904, beispielhafte Mesh-Proxys 908, 910, 912, ein beispielhaftes Soft-QoS-Mesh-Netzwerk 914, eine beispielhafte Schnittstelle 916, einen beispielhaften Hierarchiegenerator 918, einen beispielhaften Lastausgleicher 920, ein beispielhaftes OS 922 und beispielhafte Hardwarekomponenten 924. Die beispielhaften Anwendungen 902, 904, 906 arbeiten wie die beispielhaften Anwendungen 800, 802 von 8, die beispielhaften Mesh-Proxys 908, 910, 912 arbeiten wie die beispielhaften Mesh-Proxys 804, 806 von 8, das beispielhafte OS 922 arbeitet wie das beispielhafte OS 808 von 8 und die beispielhaften Hardwarekomponenten 924 arbeiten wie die beispielhaften Hardwarekomponenten 810 von 8.
In dem Beispiel von 9 ist das beispielhafte Soft-QoS-Mesh-Netzwerk 914 eine softwarebasierte Komponente, die zwischen den Mesh-Proxys 908, 910, 912 und dem OS 922 verbunden ist. Das beispielhafte Soft-QoS-Mesh-Netzwerk 914 beinhaltet die beispielhafte Schnittstelle 916, den beispielhaften Hierarchiegenerator 918 und den beispielhaften Lastausgleicher 920.
Die beispielhafte Schnittstelle 916 von 9 erhält RDT-Steuersignale von dem beispielhaften Mesh-Proxy 908, 910, 912. Wie oben beschrieben, identifizieren die RDT-Steuersignale, wie viele Speicher- und/oder Prozessorressourcen benötigt werden, um die jeweiligen Anwendungen 902, 904, 906 auszuführen, während entsprechende SLA/SLO-Voraussetzungen erfüllt werden. Die beispielhafte Schnittstelle 916 empfängt auch Telemetriedaten von dem beispielhaften OS 922, die der Verwendung und/oder Kapazität der Hardwarekomponenten 924 entsprechen. Bei manchen Beispielen kann die Schnittstelle 916 Telemetriedaten, die einer Anwendung entsprechen, an den entsprechenden Mesh-Proxy 908, 910, 912 übertragen. Die beispielhafte Schnittstelle 916 überträgt Zuordnungsanweisungen an das beispielhafte OS 922, um das OS 922 zu informieren, wie Ressourcen der Hardwarekomponenten 924 für die beispielhaften Anwendungen 902, 904, 906 zuzuweisen sind, nachdem der Lastausgleicher 920 bestimmt hat, wie die Ressourcen zuzuweisen sind, wie weiter unten beschrieben ist.
Der beispielhafte Hierarchiegenerator 918 von 9 kann Anwendungen zusammengruppieren und/oder eine Ressourcenhierarchie für die Anwendungen 902, 904, 906 erzeugen. Zum Beispiel kann die Anwendung 902 als hohe Priorität gekennzeichnet oder anderweitig identifiziert werden, während die übrigen Anwendungen 904, 906 als niedrige Priorität gekennzeichnet werden können. In solchen Beispielen kann der Hierarchiegenerator 918 die SLA/SLO-Voraussetzungen und/oder Hardwarekomponenten 924 für die erste Anwendung 902 reservieren und/oder anderweitig priorisieren. In manchen Beispielen entwickelt der Hierarchiegenerator 918 eine Ressourcenzuweisung, die eine gewisse Menge oder einen gewissen Anteil der Hardwarekomponenten 924 für die Anwendung 902 reserviert und die verbleibende Menge oder den verbleibenden Anteil der Hardwarekomponenten 924 für die verbleibenden Anwendungen 904, 906 belässt. Die Reservierungsmenge und/oder die Anzahl von Gruppen und/oder Hierarchien (z. B. hoch, mittelhoch, niedrig usw.) können auf Benutzerpräferenzen, Herstellerpräferenzen, Anwendungspräferenzen und/oder Verfügbarkeit der beispielhaften Hardwarekomponenten 924 basieren.
Der beispielhafte Hierarchiegenerator 918 von 9 kann auch basierend auf einem Auslöser (z. B. einem auftretenden Ereignis) bestimmen, dass sich eine Anwendung von einer ersten Priorität zu einer zweiten Priorität geändert hat. Zum Beispiel kann die Anwendung 902 Code beinhalten, der dem entspricht, dass die Anwendung 902 eine niedrige Priorität hat, es sei denn, die Latenz erfüllt eine Schwelle nicht und/oder ein spezieller Codeabschnitt ist auszuführen. In solchen Beispielen kann sich die Anwendung 902 von einer niedrigen Priorität zu einer hohen Priorität ändern, falls die Latenz die Schwelle nicht mehr erfüllt und/oder falls der spezielle Codeabschnitt auszuführen ist. Die beispielhafte Anwendung 902 kann zu niedriger Priorität zurückkehren, nachdem die Latenz die Schwelle erfüllt und/oder der spezielle Codeabschnitt nicht mehr ausgeführt wird. In solchen Beispielen überwacht der Hierarchiegenerator 818 die Telemetriedaten und/oder andere Daten, um zu bestimmen, ob die Latenz und/oder der Code durch das OS 922 ausgeführt werden, um zu bestimmen, ob eine Hierarchiestruktur aufgrund einer Prioritätsstatusänderung initiiert oder geändert werden soll. Falls der beispielhafte Hierarchiegenerator 818 bestimmt, dass eine Prioritätsstatusänderung vorliegt, restrukturiert und/oder erzeugt der Hierarchiegenerator 818 die Hierarchiestruktur für die Anwendungen 902, 904, 906 basierend auf der Prioritätsstatusänderung.
Der beispielhafte Lastausgleicher 920 von 9 führt einen anwendungsübergreifenden Ausgleich von Ressourcen durch, bevor Ressourcenzuweisungsanweisungen an das OS 922 gesendet werden. Der beispielhafte Lastausgleicher 920 führt den anwendungsübergreifenden Ausgleich durch Bestimmen durch, wie viel Ressourcen (z. B. die Hardwarekomponenten 924) für die jeweiligen Anwendungen 902, 904, 906 zuzuweisen sind, basierend auf den jeweiligen empfangenen RDT-Steuersignalen von den entsprechenden Mesh-Proxys 908, 910, 912 und/oder der Hierarchie, die durch den beispielhaften Hierarchiegenerator 918 erzeugt wird. Sobald die Ressourcenzuweisung abgeschlossen ist, überträgt der beispielhafte Lastausgleicher 920 unter Verwendung der Schnittstelle 916 Zuweisungsanweisungen zu dem OS 922. Auf diese Weise weist der beispielhafte Lastausgleicher 920 Ressourcen zu, um die SLA/SLO-Voraussetzungen jeder Anwendung 902, 904, 906 effizient auszugleichen, während die Anwendungen 902, 904, 906 basierend auf einer erzeugten Hierarchie (falls z. B. eine erzeugt wird) priorisiert werden. Zusätzlich dazu kann der beispielhafte Lastausgleicher 920 eine Ressourcenzuweisung als Reaktion auf sich ändernde dynamische Bedingungen kontinuierlich ändern. Falls zum Beispiel identifiziert wurde, dass für eine Anwendung das Risiko besteht, dass sie ihr SLA/SLO verfehlt, kann der beispielhafte Lastausgleicher 920 die Anwendung vorübergehend auf eine höhere Priorität erhöhen und zusätzliche Ressourcen übergeben, die für eine andere Anwendung reserviert sind (z. B. die die Anwendung nicht benötigt oder nicht braucht). Der beispielhafte Lastausgleicher 920 kann die Ressourcenzuweisung dynamisch anpassen, ohne irgendwelche Änderungen an den beispielhaften Anwendungen 902, 904, 906 zu erfordern.
10A ist ein Blockdiagramm einer beispielhaften Implementierung des beispielhaften Brokers 704 und der beispielhaften Rechenvorrichtung 706 von 1. Der beispielhafte Broker 704 von 10A beinhaltet eine beispielhafte Netzwerkschnittstelle 1000, einen beispielhaften Dienstanforderungsanalysator 1002 und einen beispielhaften Ressourcenkomparator 1004. Die beispielhafte Rechenvorrichtung 706 von 10A beinhaltet eine beispielhafte Rechenplattform 1008, beispielhafte CPUs 1009, einen beispielhaften Plattformagenten 1010, eine beispielhafte gepoolte QoS-Steuerung 1012, eine beispielhafte gepoolte Beschleunigerplattform 1014 und einen beispielhaften PCIe-Switch 1016. Die beispielhafte Rechenvorrichtung 706 kann zusätzlich oder alternativ eine beliebige der in den 8 und/oder 9 veranschaulichten beispielhaften Komponenten beinhalten. In manchen Beispielen können die Rechenplattform 1008 und die beispielhafte gepoolte Beschleunigerplattform 1014 in den Hardwarekomponenten 810 und/oder den Hardwarekomponenten 924 enthalten sein.
Die beispielhafte Netzwerkschnittstelle 1000 von 10A empfängt Dienstanforderungen von Intra-Domänen- und/oder Inter-Domänen-Vorrichtungen (z. B. über das Netzwerk 702 von 1). Nachdem eine Dienstanforderung empfangen und/oder verarbeitet wurde, überträgt die beispielhafte Netzwerkschnittstelle 1000 die Dienstanforderung und/oder die SLA/SLO-Voraussetzungen zu der beispielhaften gepoolten QoS-Steuerung 1012 der Rechenvorrichtung 706. Die beispielhafte gepoolte QoS-Steuerung 1012 überträgt eine Antwort zum Identifizieren der Fähigkeit der gepoolten Beschleunigerplattform 1014, die Anforderungen basierend auf den SLA/SLO-Voraussetzungen zu versorgen. Die beispielhafte Netzwerkschnittstelle 1000 erhält die Antwort und kann Anweisungen zu dem Plattformagenten 1010 der Rechenplattform 1008 übertragen, um einen Teil oder die gesamte Dienstanforderung zu versorgen. In manchen Beispielen kann die Netzwerkschnittstelle 1000 ein Flag oder eine andere Indikation übertragen, dass die Rechenvorrichtung 706 unzureichende Ressourcen aufweist, wenn zum Beispiel die gepoolte QoS-Steuerung 1012 angibt, dass die gepoolte Beschleunigerplattform 1014 unzureichende Ressourcen aufweist, um eine Dienstanforderung zu versorgen. Zum Beispiel kann die Netzwerkschnittstelle 1000 ein Flag zu der Cloud/dem Datenzentrum 701 oder einer anderen Entität, die die Rechenvorrichtung 706 verfolgt, übertragen. Auf diese Weise kann die beispielhafte Cloud/das beispielhafte Datenzentrum 701 oder eine andere Entität mehr Ressourcen an der beispielhaften Rechenvorrichtung 706 einsetzen und/oder diese anderweitig aktualisieren/anpassen.
Der beispielhafte Dienstanforderungsanalysator 1002 analysiert empfangene Dienstanforderungen, um die Menge an Ressourcen (z. B. CPU, GPU-Speicher usw.) zu bestimmen, die benötigt werden, um die Dienstanforderung zu versorgen. Zum Beispiel kann eine empfangene Dienstanforderung ein SLA und/oder ein SLO, die Voraussetzungen zum Versorgen der Dienstanforderung angeben, beinhalten oder durch Konfiguration damit assoziiert sein. Der beispielhafte Dienstanforderungsanalysator 1002 identifiziert die SLA- und/oder SLO-Voraussetzungen. Der Dienstanforderungsanalysator 1002 kann die SLO/SLA-Voraussetzungen und/oder die Dienstanforderung zu der beispielhaften gepoolten QoS-Steuerung 1012 übertragen, um zu bestimmen, ob die gepoolte Beschleunigerplattform Kapazität zum Versorgen der Anforderung gemäß den SLA/SLO-Voraussetzungen aufweist. Zusätzlich oder alternativ dazu kann der Dienstanforderungsanalysator 1002 die SLA/SLO-Voraussetzungen in eine Ressourcenmenge umwandeln und die Ressourcenmenge zu der beispielhaften gepoolten QoS-Steuerung 1012 übertragen, um zu bestimmen, ob die gepoolte Beschleunigerplattform 1014 Kapazität zum Versorgen der Anforderung gemäß der Ressourcenmenge aufweist. Zusätzlich oder alternativ dazu kann der beispielhafte Dienstanforderungsanalysator 1002 eine Anforderung nach Ressourcenkapazitätsinformationen von der gepoolten QoS-Steuerung 1012 übertragen und dann bestimmt der Ressourcenkomparator 1004 lokal, ob die gepoolte Beschleunigerplattform 1014 eine ausreichende Kapazität aufweist, um die Anforderung gemäß den SLA/SLO-Voraussetzungen zu versorgen.
Der beispielhafte Ressourcenkomparator 1004 von 10A vergleicht die Menge verfügbarer gepoolter Ressourcen von verbundenen Vorrichtungen (z. B. der beispielhaften Rechenvorrichtung 706, der beispielhaften Rechenvorrichtung 708 von 1 usw.), um zu bestimmen, wie die Anforderung versorgt werden soll. Der beispielhafte Ressourcenkomparator 1004 kann die Dienstanforderung an einer Rechenvorrichtung oder mehreren Rechenvorrichtungen basierend auf der Verfügbarkeit gepoolter Ressourcen und den SLA/SLO-Voraussetzungen versorgt haben. In manchen Beispielen bestimmt der Ressourcenkomparator 1004, wie die Anforderung versorgt werden soll, basierend auf Kapazitätsinformationen, die von der gepoolten QoS-Steuerung 1012 gesendet werden (z. B. wenn die gepoolte QoS-Steuerung 1012 ihre Ressourcenfähigkeit sendet). In solchen Beispielen kann der Ressourcenkomparator 1004 Vorrichtungen markieren, die keine ausreichenden Ressourcen aufweisen, um die Anforderung zu versorgen.
Die beispielhafte Rechenplattform 1008 von 10A beinhaltet Prozessorressourcen (z. B. die CPUs 1009) und Ressourcensteuerungen (RCs) zum Durchführen von Aufgaben. Dementsprechend beinhaltet die beispielhafte Rechenplattform 1008 eine reine CPU-Struktur. Die beispielhaften CPUs 1009 sind CPU-Hardware (HW) oder CPU-Plattformen. Obwohl die beispielhafte Rechenplattform 1008 die beispielhaften CPUs 1009 beinhaltet, kann die Rechenplattform 1008 eine beliebige Anzahl von CPUs beinhalten. Die beispielhafte Rechenplattform 1008 beinhaltet ferner den Plattformagenten 1010 zum Steuern der Bitübertragungsschichten (PHYs), um eine Schnittstelle mit der gepoolten Beschleunigerplattform 1014 zu bilden, um die gepoolten Beschleuniger zu verwenden, um eine Aufgabe basierend auf Anweisungen von dem Broker 704 durchzuführen (z. B. nachdem der Broker 704 die Rechenvorrichtung 706 zum Versorgen einer Dienstanforderung ausgewählt hat).
Die beispielhafte gepoolte QoS-Steuerung 1012 von 10A empfängt Informationen von dem Broker 704 und bestimmt die Fähigkeit und/oder Kapazität der gepoolten Ressourcen in der gepoolten Beschleunigerplattform 1014 durch Verbinden mittels Schnittstelle mit dem PCIe-Switch 1016 (oder einem anderen Vorrichtungs-Interconnect-Fabric-Switch). Falls der beispielhafte Broker 704 die Menge an Ressourcen, die notwendig sind, um die SLA/SLO-Voraussetzung zu erfüllen, aus einer Dienstanforderung bestimmt und die Menge und/oder Charakteristiken der Ressourcen zu der gepoolten QoS-Steuerung 1012 überträgt, bestimmt die gepoolte QoS-Steuerung 1012, ob ausreichend verfügbare Ressourcen vorhanden sind, um die identifizierte Menge und/oder Charakteristiken der Ressourcen zu erfüllen. Falls der beispielhafte Broker 704 die SLA/SLO-Voraussetzungen bereitstellt, bestimmt die gepoolte QoS-Steuerung 1012 die Menge/Charakteristiken von Ressourcen, die notwendig sind, um die SLA/SLO-Voraussetzungen zu erfüllen, und bestimmt, ob die Menge/Charakteristiken von Ressourcen zur Verwendung in der gepoolten Beschleunigerplattform 1014 verfügbar ist/sind. Falls der beispielhafte Broker 704 Informationen anfordert, bestimmt die beispielhafte gepoolte QoS-Steuerung 1012 die Fähigkeit und/oder Kapazität der gepoolten Beschleunigerplattformen 1014 und gibt die Fähigkeits- und/oder Kapazitätsinformationen zurück.
Obwohl die beispielhafte Rechenvorrichtung 706 die beispielhafte gepoolte Beschleunigerplattform 1014 mit gepoolten Beschleunigerressourcen beinhaltet, kann die beispielhafte Rechenvorrichtung 706 zusätzlich oder alternativ eine andere gepoolte Ressource beinhalten. Zum Beispiel kann die Rechenvorrichtung 706 eine gepoolte Speicherplattform mit gepoolten Speicherressourcen beinhalten. Bei einem solchen Beispiel verbindet sich die gepoolte QoS-Steuerung 1012 (z. B. ermöglicht mit RDT-Funktionalität) mittels Schnittstelle mit der gepoolten Speicherplattform auf ähnliche Weise wie oben beschrieben, um eine Cacheüberwachung, Cachezuweisung, Speicherbandbreitenüberwachung und Speicherbandbreitenzuweisung durchzuführen. Auf diese Weise kann die gepoolte QoS-Steuerung 1012 gepoolte Speicherinformationen zum Versorgen einer Dienstanforderung bereitstellen.
10B ist ein Blockdiagramm einer beispielhaften Implementierung des beispielhaften Brokers 704 und der beispielhaften Rechenvorrichtung 706 von 1. Der beispielhafte Broker 704 von 10B beinhaltet eine beispielhafte Netzwerkschnittstelle 1000, einen beispielhaften Dienstanforderungsanalysator 1002 und einen beispielhaften Ressourcenkomparator 1004. Die beispielhafte Rechenvorrichtung 706 von 10B beinhaltet eine beispielhafte Rechenplattform 1008, eine beispielhafte CPU 1009, eine beispielhafte GPU 1011, einen beispielhaften Plattformagenten 1010, eine beispielhafte gepoolte QoS-Controller 1012, eine beispielhafte gepoolte Beschleunigerplattform 1014 und einen beispielhaften PCIe-Switch 1016. Die beispielhafte Rechenvorrichtung 706 kann zusätzlich oder alternativ eine beliebige der in den 8 und/oder 9 veranschaulichten beispielhaften Komponenten beinhalten. In manchen Beispielen können die Rechenplattform 1008 und die beispielhafte gepoolte Beschleunigerplattform 1014 in den Hardwarekomponenten 810 und/oder den Hardwarekomponenten 924 enthalten sein.
Die beispielhafte Rechenplattform 1008 von 10B beinhaltet die beispielhafte CPU 109 und die beispielhafte GPU 1011 als die Prozessorressourcen zum Durchführen von Aufgaben. Dementsprechend beinhaltet die beispielhafte Rechenplattform 1008 eine Hybridstruktur. Die beispielhafte GPU 1011 ist eine GPU-Hardware (HW) oder GPU-Plattform. Obwohl die beispielhafte Rechenplattform 1008 die beispielhafte CPU 109 und die beispielhafte GPU 1011 beinhaltet, kann die Rechenplattform 1008 eine beliebige Anzahl von CPUs und/oder GPUs beinhalten.
10C ist ein Blockdiagramm einer beispielhaften Implementierung des beispielhaften Brokers 704 und der beispielhaften Rechenvorrichtung 706 von 1. Der beispielhafte Broker 704 von 10C beinhaltet eine beispielhafte Netzwerkschnittstelle 1000, einen beispielhaften Dienstanforderungsanalysator 1002 und einen beispielhaften Ressourcenkomparator 1004. Die beispielhafte Rechenvorrichtung 706 von 10C beinhaltet eine beispielhafte Rechenplattform 1008, beispielhafte GPUs 1011, einen beispielhaften Plattformagenten 1010, eine beispielhafte gepoolte QoS-Steuerung 1012, eine beispielhafte gepoolte Beschleunigerplattform 1014 und einen beispielhaften PCIe-Switch 1016. Die beispielhafte Rechenvorrichtung 706 kann zusätzlich oder alternativ eine beliebige der in den 8 und/oder 9 veranschaulichten beispielhaften Komponenten beinhalten. In manchen Beispielen können die Rechenplattform 1008 und die beispielhafte gepoolte Beschleunigerplattform 1014 in den Hardwarekomponenten 810 und/oder den Hardwarekomponenten 924 enthalten sein.
Die beispielhafte Rechenplattform 1008 von 10C beinhaltet die beispielhaften GPUs 1011 als die Prozessorressourcen zum Durchführen von Aufgaben. Dementsprechend beinhaltet die beispielhafte Rechenplattform 1008 eine reine GPU-Struktur. Die beispielhaften GPUs 1011 sind GPU-Hardware (HW) oder GPU-Plattformen. Obwohl die beispielhafte Rechenplattform 1008 die beispielhaften GPUs 1011 beinhaltet, kann die Rechenplattform 1008 eine beliebige Anzahl an GPUs beinhalten.
Obwohl eine beispielhafte Weise des Implementierens des beispielhaften Brokers 704 und/oder der beispielhaften Rechenvorrichtung 708 von 7 in 1 veranschaulicht ist, können die Elemente und/oder Prozesse und/oder Vorrichtungen, die in den 8, 9 und/oder 10 veranschaulicht sind, kombiniert, geteilt, umgeordnet, weggelassen, eliminiert und/oder auf eine beliebige andere Weise implementiert werden. Ferner können die beispielhafte Netzwerkschnittstelle 1000, der beispielhafte Dienstanforderungsanalysator 1002, der beispielhafte Ressourcenkomparator 1004 und/oder allgemeiner der beispielhafte Broker 704 der 7 und/oder 10 und/oder die Mesh-Proxys 804, 806, 908, 910, 912, die beispielhaften OSs 808, 922, das beispielhafte Soft-QoS-Mesh-Netzwerk 914, die beispielhafte Schnittstelle 916, der beispielhafte Hierarchiegenerator 918, der beispielhafte Lastausgleicher 920, die beispielhafte gepoolte QoS-Steuerung 1012 und/oder allgemeiner die Rechenvorrichtung 708 der 7-10C durch Hardware, Software, Firmware und/oder eine beliebige Kombination von Hardware, Software und/oder Firmware implementiert werden. Somit könnten zum Beispiel beliebige der beispielhaften Netzwerkschnittstelle 1000, des beispielhaften Dienstanforderungsanalysators 1002, des beispielhaften Ressourcenkomparators 1004 und/oder allgemeiner des beispielhaften Brokers 704 der 7 und/oder 10 und/oder der Mesh-Proxys 804, 806, 908, 910, 912, der beispielhaften OSs 808, 922, des beispielhaften Soft-QoS-Mesh-Netzwerks 914, der beispielhaften Schnittstelle 916, des beispielhaften Hierarchiegenerators 918, des beispielhaften Lastausgleichers 920, der beispielhaften gepoolten QoS-Steuerung 1012 und/oder allgemeiner der Rechenvorrichtung 708 der 7-10C durch eine oder mehrere analoge oder digitale Schaltungen, Logikschaltungen, einen oder mehrere programmierbare Prozessoren, eine oder mehrere programmierbare Steuerungen, eine oder mehrere Grafikverarbeitungseinheiten (GPU(s)), einen oder mehrere Digitalsignalprozessoren (DSP(s)), eine oder mehrere anwendungsspezifische integrierte Schaltungen (ASIC(s)), eine oder mehrere programmierbare Logikvorrichtungen (PLD(s)) und/oder eine oder mehrere feldprogrammierbare Logikvorrichtungen (FPLD(s)) implementiert werden. Wenn gelesen wird, dass beliebige der Einrichtungs- oder Systemansprüche dieses Patents eine reine Software- und/oder Firmware-Implementierung abdecken, wird mindestens eines des Beispiels, der beispielhaften Netzwerkschnittstelle 1000, des beispielhaften Dienstanforderungsanalysators 1002, des beispielhaften Ressourcenkomparators 1004 und/oder allgemeiner des beispielhaften Brokers 704 der 7 und/oder 10 und/oder der Mesh-Proxys 804, 806, 908, 910, 912, der beispielhaften OSs 808, 922, des beispielhaften Soft-QoS-Mesh-Netzwerks 914, der beispielhaften Schnittstelle 916, des beispielhaften Hierarchiegenerators 918, des beispielhaften Lastausgleichers 920, der beispielhaften gepoolten QoS-Steuerung 1012 und/oder allgemeiner der Rechenvorrichtung 708 der 7-10C ausdrücklich so definiert, dass sie eine nichtflüchtige computerlesbare Speicherungsvorrichtung oder Speicherungsplatte, wie etwa einen Speicher, eine DVD (Digital Versatile Disk), eine CD (Compact Disk), eine Blu-Ray-Disk usw. einschließlich der Software und/oder Firmware, beinhalten. Ferner können der beispielhafte Broker 704 und/oder die Rechenvorrichtung 708 der 7, 8, 9 und/oder 10 ein/e oder mehrere Elemente, Prozesse und/oder Vorrichtungen zusätzlich zu oder anstelle der in den 7, 8, 9 und/oder 10 beinhalten und/oder können mehr als eines von beliebigen oder allen der veranschaulichten Elemente, Prozesse und Vorrichtungen beinhalten. Wie hierin verwendet, schließt der Ausdruck „in Kommunikation“, einschließlich Variationen davon, eine direkte Kommunikation und/oder indirekte Kommunikation über eine oder mehrere zwischenliegende Komponenten ein und erfordert keine direkte physische (z. B. verdrahtete) Kommunikation und/oder konstante Kommunikation, sondern beinhaltet stattdessen zusätzlich eine selektive Kommunikation mit periodischen Intervallen, geplanten Intervallen, aperiodischen Intervallen und/oder einmalige Ereignisse.
Flussdiagramme, die beispielhafte Hardwarelogik, maschinenlesbare Anweisungen, hardwareimplementierte Zustandsmaschinen und/oder eine beliebige Kombination davon zum Implementieren des beispielhaften Brokers 704 und/oder der Rechenvorrichtung 708 der 7, 8, 9 und/oder 10 repräsentieren, sind in den 11-13 gezeigt. Die maschinenlesbaren Anweisungen können ein oder mehrere ausführbare Programme oder Teil(e) eines oder mehrerer ausführbarer Programme zur Ausführung durch einen Computerprozessor sein, wie etwa den Prozessor 1452, 1552, der in der beispielhaften Prozessorplattform 1450, 1550 gezeigt ist, die unten in Verbindung mit den 14B und/oder 15 besprochen ist. Die Programme können in Software umgesetzt sein, die auf einem nichttransitorischen computerlesbaren Speicherungsmedium gespeichert ist, wie etwa einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-Ray-Disk, oder einem Speicher, der mit dem Prozessor 1452, 1552 assoziiert ist, aber alternativ könnte die Gesamtheit der Programme und/oder Teile davon durch eine andere Vorrichtung als den Prozessor 1452, 1552 ausgeführt werden und/oder in Firmware oder dedizierter Hardware umgesetzt sein. Obwohl ferner das eine oder die mehreren beispielhaften Programme unter Bezugnahme auf die in den 11-13 veranschaulichten Flussdiagramme beschrieben sind, können alternativ viele andere Verfahren zum Implementieren des beispielhaften Brokers 704 und/oder der Rechenvorrichtung 708 der 7, 8, 9 und/oder 10 verwendet werden. Beispielsweise kann die Reihenfolge der Ausführung der Blöcke geändert werden und/oder manche der beschriebenen Blöcke können geändert, entfernt oder kombiniert werden. Zusätzlich oder alternativ dazu können beliebige oder alle der Blöcke durch eine oder mehrere Hardwareschaltungen (z. B. eine diskrete und/oder integrierte analoge und/oder digitale Schaltungsanordnung, ein FPGA, eine ASIC, einen Operationsverstärker (Op-Amp), eine Logikschaltung usw.) implementiert werden, die so strukturiert sind, dass sie eine entsprechende Operation ohne die Ausführung von Software oder Firmware durchführen.
Die hierin beschriebenen maschinenlesbaren Anweisungen können in einem komprimierten Format und/oder einem verschlüsselten Format und/oder einem fragmentierten Format und/oder einem kompilierten Format und/oder einem ausführbaren Format und/oder einem paketisierten Format usw. gespeichert werden. Maschinenlesbare Anweisungen, wie hierin beschrieben, können als Daten (z. B. Teile von Anweisungen, Code, Repräsentationen von Code usw.) gespeichert werden, die zum Erstellen, Herstellen und/oder Erzeugen von maschinenausführbaren Anweisungen genutzt werden können. Beispielsweise können die maschinenlesbaren Anweisungen fragmentiert und auf einer oder mehreren Speicherungsvorrichtungen und/oder Rechenvorrichtungen (z. B. Servern) gespeichert werden. Die maschinenlesbaren Anweisungen können Installation und/oder Modifikation und/oder Anpassung und/oder Aktualisierung und/oder Kombinieren und/oder Ergänzen und/oder Konfigurieren und/oder Entschlüsselung und/oder Dekomprimierung und/oder Entpacken und/oder Verteilung und/oder Neuzuordnung und/oder Kompilierung usw. erfordern, um sie durch eine Rechenvorrichtung und/oder eine andere Maschine direkt lesbar, interpretierbar und/oder ausführbar zu machen. Beispielsweise können die maschinenlesbaren Anweisungen in mehreren Teilen gespeichert werden, die individuell komprimiert, verschlüsselt und auf separaten Rechenvorrichtungen gespeichert sind, wobei die Teile nach ihrer Entschlüsselung, Dekomprimierung und Kombination einen Satz ausführbarer Anweisungen bilden, die ein Programm, wie etwa das hierin beschriebene, implementieren.
Bei einem anderen Beispiel können die maschinenlesbaren Anweisungen in einem Zustand gespeichert werden, in dem sie durch einen Computer gelesen werden können, aber einen Zusatz einer Bibliothek (z. B. einer DLL (Dynamic Link Library)), eines SDK (Software Development Kit), einer Anwendungsprogrammierungsschnittstelle (API) usw. erfordern, um die Anweisungen auf einer speziellen Rechenvorrichtung oder anderen Vorrichtung auszuführen. In einem anderen Beispiel müssen die maschinenlesbaren Anweisungen möglicherweise konfiguriert werden (z. B. Einstellungen gespeichert, Daten eingegeben, Netzwerkadressen aufgezeichnet werden usw.), bevor die maschinenlesbaren Anweisungen und/oder das (die) entsprechende(n) Programm(e) vollständig oder teilweise ausgeführt werden können. Somit sollen die offenbarten maschinenlesbaren Anweisungen und/oder das (die) entsprechende(n) Programm(e) derartige maschinenlesbare Anweisungen und/oder Programm(e) ungeachtet des speziellen Formats oder Zustands der maschinenlesbaren Anweisungen und/oder Programm(e) einschließen, wenn sie gespeichert oder anderweitig im Ruhezustand oder im Transit sind.
Die hier beschriebenen maschinenlesbaren Anweisungen können durch eine beliebige vergangene, gegenwärtige oder zukünftige Befehlssprache, Skriptsprache, Programmiersprache usw. repräsentiert werden. Zum Beispiel können die maschinenlesbaren Anweisungen unter Verwendung einer beliebigen der folgenden Sprachen repräsentiert werden: 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 Programme der 11-13 unter Verwendung ausführbarer Anweisungen (z. B. computer- und/oder maschinenlesbarer Anweisungen) implementiert werden, die auf einem nichttransitorischen computer- und/oder maschinenlesbaren Medium gespeichert sind, wie etwa einem Festplattenlaufwerk, einem Flash-Speicher, einem Nurlesespeicher, einer Compact Disk, einer Digital Versatile Disk, einem Cache, einem Direktzugriffsspeicher und/oder einer beliebigen anderen Speicherungsvorrichtung oder Speicherungsplatte, in der Informationen für eine beliebige Dauer gespeichert sind (z. B. für längere Zeiträume, permanent, für kurze Instanzen, zum temporären Puffern und/oder zum Cachen der Informationen). Wie hierin verwendet, wird der Begriff nichttransitorisches computerlesbares Medium ausdrücklich so definiert, dass er eine beliebige Art von computerlesbarer Speicherungsvorrichtung und/oder Speicherungsplatte beinhaltet und das Propagieren von Signalen ausschließt und Übertragungsmedien ausschließt.
„Beinhaltend“ und „umfassend“ (und alle Formen und Zeitformen davon) werden hierin als offene Begriffe verwendet. Wann auch immer ein Anspruch eine beliebige Form von „beinhalten“ und „umfassen“ (z. B. umfasst, beinhaltet, umfassend, beinhaltend, aufweisend usw.) als eine Präambel oder in einer Anspruchsrezitation einer beliebigen Art einsetzt, soll somit verstanden werden, dass zusätzliche Elemente, Begriffe usw. vorhanden sein können, ohne außerhalb des Schutzumfangs des entsprechenden Anspruchs oder der entsprechenden Rezitation zu fallen. Wie hierin verwendet, wenn der Ausdruck „mindestens“ als der Übergangsausdruck in zum Beispiel einer Präambel eines Anspruchs verwendet wird, ist er auf die gleiche Art und Weise offen, wie der Begriff „umfassend“ und „beinhaltend“ offen ist. Der Begriff „und/oder“, wenn er zum Beispiel in einer Form wie etwa A, B und/oder C verwendet wird, bezieht sich auf eine beliebige Kombination oder Teilmenge von A, B, C, wie etwa (1) A alleine, (2) B alleine, (3) C alleine, (4) A mit B, (5) A mit C, (6) B mit C und (7) A mit B und mit C. Wie hierin im Zusammenhang der Beschreibung von Strukturen, Komponenten, Gegenständen, Objekten und/oder Dingen verwendet, wird beabsichtigt, dass sich die Phrase „mindestens eines von A und B“ auf Implementierungen bezieht, einschließlich ein beliebiges von (1) mindestens eines von A, (2) mindestens eines von B und (3) mindestens eines von A und mindestens eines von B. Wie hierin im Zusammenhang der Beschreibung von Strukturen, Komponenten, Gegenständen, Objekten und/oder Dingen verwendet, wird gleichermaßen beabsichtigt, dass sich die Phrase „mindestens eines von A oder B“ auf Implementierungen bezieht, einschließlich (1) mindestens eines von A, (2) mindestens eines von B und (3) mindestens eines von A und mindestens eines von B. Wie hierin im Zusammenhang der Beschreibung der Leistungsfähigkeit oder Ausführung von Prozessen, Anweisungen, Handlungen, Aktivitäten und/oder Schritten verwendet, wird beabsichtigt, dass sich die Phrase „mindestens eines von A und B“ auf Implementierungen bezieht, einschließlich ein beliebiges von (1) mindestens eines von A, (2) mindestens eines von B und (3) mindestens eines von A und mindestens eines von B. Wie hierin im Zusammenhang der Beschreibung der Leistungsfähigkeit oder Ausführung von Prozessen, Anweisungen, Handlungen, Aktivitäten und/oder Schritten verwendet, wird gleichermaßen beabsichtigt, dass sich die Phrase „mindestens eines von A oder B“ auf Implementierungen bezieht, einschließlich ein beliebiges von (1) mindestens eines von A, (2) mindestens eines von B und (3) mindestens eines von A und mindestens eines von B.
Wie hierin verwendet, schließen Bezüge im Singular (z. B. „ein“, „eine“, „erste/r/s“, „zweite/r/s“ usw.) keine Mehrzahl aus. Der Begriff „eine“ Entität, wie hierin verwendet, bezieht sich auf eine oder mehrere dieser Entität. Die Begriffe „ein“ (oder „eine“), „ein oder mehrere“ und „mindestens ein“ können hierin austauschbar verwendet werden. Obwohl einzeln aufgelistet können ferner mehrere Mittel, Elemente oder Verfahrenshandlungen durch z. B. eine einzige Einheit oder einen einzigen Prozessor implementiert werden. Zusätzlich dazu, obwohl einzelne Merkmale in unterschiedlichen Beispielen oder Ansprüchen enthalten sein können, können diese möglicherweise kombiniert werden, und der Einschluss in verschiedenen Beispielen oder Ansprüchen deutet nicht an, dass eine Kombination von Merkmalen nicht machbar und/oder vorteilhaft ist.
11 veranschaulicht ein Flussdiagramm, das beispielhafte maschinenlesbare Anweisungen 1100 repräsentiert, die ausgeführt werden können, um den beispielhaften Mesh-Proxy 804 (8) zu implementieren, um QoS basierend auf SLAs in der Rechenvorrichtung 706 (7-9) zu verwalten. Obwohl das Flussdiagramm von 11 in Verbindung mit der Rechenvorrichtung 706 der 7-9 beschrieben ist, können die beispielhaften Anweisungen verwendet werden, um eine oder mehrere andere Arten von Rechenvorrichtungen (z. B. virtuelle Maschinen, Dienste usw.) zu implementieren. Obwohl die Anweisungen 1100 von 11 in Verbindung mit dem Mesh-Proxy 804 beschrieben sind, können die Anweisungen zusätzlich durch einen oder mehrere der Mesh-Proxys 804, 806, 908, 910, 912 basierend auf SLA/SLO-Anweisungen von einer oder mehreren der Anwendungen 800, 802, 902, 904, 906 (z. B. parallel oder anderweitig) durchgeführt werden.
Bei Block 1102 bestimmt der beispielhafte Mesh-Proxy 804 (8), ob eine neue Anwendung (z. B. die beispielhafte Anwendung 800 (8)) auf der beispielhaften Rechenvorrichtung 706 installiert ist. Die beispielhafte Anwendung 800 kann von der beispielhaften Cloud/dem beispielhaften Datenzentrum 701 von 1 heruntergeladen, installiert und/oder empfangen werden. Der beispielhafte Mesh-Proxy 804 bestimmt basierend auf einem Signal von dem OS 808 (8), ob eine neue Anwendung installiert ist. Falls der beispielhafte Mesh-Proxy 804 bestimmt, dass keine neue Anwendung installiert ist (Block 1102: NEIN), kehrt die Steuerung zu Block 1102 zurück, bis eine neue Anwendung installiert ist. Falls der beispielhafte Mesh-Proxy 804 bestimmt, dass die neue Anwendung 800 installiert ist (Block 1102: JA), verbindet sich der Mesh-Proxy 804 mit der neuen Anwendung 800 (z. B. wenn das OS 808 den Mesh-Proxy 804 der Anwendung 800 zuordnet) (Block 1104).
Bei Block 1106 bestimmt der beispielhafte Mesh-Proxy 804, ob ein SLA/SLO-Befehl von der Anwendung 800 erhalten wurde. Zum Beispiel beinhaltet der SLA/SLO-Befehl eine Voraussetzung (z. B. Bandbreitenvoraussetzung, Jitter-Voraussetzung, Latenzvoraussetzung, Geschwindigkeitsvoraussetzung usw.) für das OS 808 und/oder die Hardwarekomponenten 810 (8), wenn die Anweisungen der Anwendung 800 ausgeführt werden. Falls der beispielhafte Mesh-Proxy 804 bestimmt, dass kein SLA/SLO-Befehl von der Anwendung 800 erhalten wurde (Block 1106: NEIN), kehrt die Steuerung zu Block 1106 zurück, bis ein SLO/SLA-Befehl empfangen wird. Falls der beispielhafte Mesh-Proxy 804 bestimmt, dass ein SLA/SLO-Befehl von der Anwendung 800 erhalten wurde (Block 1106: JA), wandelt der beispielhafte Mesh-Proxy 804 den SLA/SLO-Befehl in ein Ressourcenanforderungssignal (z. B. ein RDT-Steuersignal) um (Block 1108). Der beispielhafte Mesh-Proxy 804 wandelt den SLA/SLO-Befehl in ein RDT-Steuersignal um, indem der Befehl in ressourcenbasierte Attribute übersetzt wird und das RDT-Steuersignal so erzeugt wird, dass es die ressourcenbasierten Attribute beinhaltet. Dementsprechend beinhaltet das RDT-Steuersignal Informationen, die der Menge und/oder Charakteristiken des OS 808 und/oder der Hardwarekomponenten 810 entsprechen, die notwendig sind, um die SLA/SLO-Voraussetzungen zu erreichen.
Bei Block 1110 überträgt der beispielhafte Mesh-Proxy 804 das Ressourcenanforderungssignal (z. B. das RDT-Steuersignal) zu dem OS 808, um Ressourcen (z. B. Ressourcen des OS 808 und/oder der Hardwarekomponenten 810) gemäß dem SLA/SLO-Befehl (z. B. um die SLA/SLO-Voraussetzungen zu erfüllen) zuzuweisen. Bei Block 1112 bestimmt der beispielhafte Mesh-Proxy 804, ob Telemetriedaten von dem OS 808 empfangen wurden. Die Telemetriedaten entsprechen der Leistungsfähigkeit des OS 808 und/oder der Hardwarekomponenten 810. Auf diese Weise können der Mesh-Proxy und/oder die Anwendung 800 die Konformität mit dem SLA/SLO überwachen. Falls der beispielhafte Mesh-Proxy 804 bestimmt, dass keine Telemetriedaten empfangen wurden (Block 1112: NEIN), enden die Anweisungen. Falls der beispielhafte Mesh-Proxy 804 bestimmt, dass Telemetriedaten empfangen wurden (Block 1112: JA), verarbeitet der beispielhafte Mesh-Proxy 804 die Telemetriedaten (Block 1114). Der Mesh-Proxy 804 kann zum Beispiel die Telemetriedaten verarbeiten, indem er bestimmt, ob die Telemetriedaten die SLA/SLO-Voraussetzungen erfüllen, und/oder kann die Telemetriedaten zu der Anwendung 800 übertragen, wie unten weiter beschrieben wird. In manchen Beispielen überträgt der Mesh-Proxy 804 eine Indikation darüber zu der Anwendung 800, ob die Rechenvorrichtung 706 mit den SLO/SLA-Voraussetzungen konform ist.
Bei Block 1116 bestimmt der beispielhafte Mesh-Proxy 804, ob die Anwendung 800 beendet ist (z. B. in der Rechenvorrichtung 706 terminiert oder aufgehoben). Falls der beispielhafte Mesh-Proxy 804 bestimmt, dass die Anwendung 800 beendet ist (Block 1116: JA), enden die Anweisungen. Falls der beispielhafte Mesh-Proxy 804 bestimmt, dass die Anwendung 800 nicht beendet ist (Block 1116: NEIN), bestimmt der beispielhafte Mesh-Proxy 804 basierend auf den verarbeiteten Telemetriedaten, ob die SLA- und/oder SLO-Voraussetzungen erfüllt sind (Block 1118). Falls der Mesh-Proxy 804 bestimmt, dass die SLA- und/oder SLO-Voraussetzungen erfüllt sind (Block 1118: JA), kehrt die Steuerung zu Block 112 zurück. Falls der Mesh-Proxy 804 bestimmt, dass die SLA- und/oder SLO-Voraussetzungen nicht erfüllt sind (Block 1118: NEIN), überträgt der beispielhafte Mesh-Proxy 804 eine aktualisierte Ressourcenanforderungssteuerung zu dem OS 808, um Ressourcen zuzuweisen, um die SLA- und/oder SLO-Voraussetzungen zu erfüllen (Block 1120), und die Steuerung kehrt zu Block 1112 zurück.
12 veranschaulicht ein Flussdiagramm, das beispielhafte maschinenlesbare Anweisungen 1200 repräsentiert, die ausgeführt werden können, um das beispielhafte Soft-QoS-Mesh-Netzwerk 914 von 9 zu implementieren, um QoS in Bezug auf SLAs von mehreren Anwendungen in der Rechenvorrichtung 706 zu verwalten. Obwohl das Flussdiagramm von 12 in Verbindung mit der Rechenvorrichtung 706 von 9 beschrieben ist, kann die beispielhafte Anweisung von 12 verwendet werden, um eine oder mehrere andere Arten von Rechenvorrichtungen (z. B. virtuelle Maschinen, Dienste usw.) zu implementieren.
Bei Block 1202 bestimmt der beispielhafte Lastausgleicher 920 ( 9), ob eine neue Anwendung (z. B. eine der beispielhaften Anwendungen 902, 904, 906 (9)) auf der beispielhaften Rechenvorrichtung 706 installiert ist. Die Anwendung 902 kann von der beispielhaften Cloud/dem beispielhaften Datenzentrum 701 von 1 heruntergeladen, installiert und/oder empfangen werden. Der beispielhafte Lastausgleicher 920 bestimmt basierend auf einem Signal von dem OS 922 (9), ob eine neue Anwendung installiert ist. Falls der beispielhafte Lastausgleicher 920 bestimmt, dass keine neue Anwendung installiert ist (Block 1202: NEIN), kehrt die Steuerung zu Block 1202 zurück, bis eine neue Anwendung installiert ist. Falls der beispielhafte Lastausgleicher 920 bestimmt, dass eine neue Anwendung installiert ist (Block 1202: JA), ordnet der Lastausgleicher 920 der neuen Anwendung (z. B. der Anwendung 902 von 9) einen Mesh-Proxy (z. B. den Mesh-Proxy 908 von 9) zu (Block 1204).
Bei Block 1206 bestimmt der beispielhafte Hierarchiegenerator 918 (9), ob eine anwendungsbasierte Hierarchie ausgelöst wird. Eine anwendungsbasierte Hierarchie kann erzeugt werden, wenn eine oder mehrere der Anwendungen 902, 904, 906 als hohe Priorität angesehen werden. Die beispielhaften Anwendungen 902, 904, 906 können einen Prioritätsstatus als Teil einer SLA/SLO-Vereinbarung beinhalten und/oder ein Benutzer und/oder Hersteller kann den Prioritätsstatus der Anwendungen 902, 904, 906 auswählen. Falls der beispielhafte Hierarchiegenerator 918 bestimmt, dass eine Anwendungshierarchie nicht ausgelöst wurde (Block 1206: NEIN), geht die Steuerung zu Block 1210 über. Falls der beispielhafte Hierarchiegenerator 918 bestimmt, dass eine Anwendungshierarchie ausgelöst wurde (Block 1206: JA), erzeugt der beispielhafte Hierarchiegenerator 918 eine Anwendungshierarchie (Block 1208).
Der beispielhafte Hierarchiegenerator 918 kann die Hierarchie zu einer beliebigen Struktur (z. B. eine beliebige Anzahl von Stufen mit einer beliebigen Anzahl von Anwendungen pro Stufe/Gruppe) basierend auf dem Prioritätsstatus oder den Prioritätsanweisungen strukturieren. Der Hierarchiegenerator 818 kann zum Beispiel hierarchischen Ressourcenmanager-Kennungen (RMIDs) fünf Anwendungen zuweisen, sodass die Ressourcen hierarchisch durch eine Hierarchie der RMIDs gesteuert werden. Zum Beispiel können die Anwendung 1 und die Anwendung 8 eine Vorgänger-RMID Rx mit einer Ressourcenzuweisung von X teilen und die Anwendungen 9, 11 und 12 können eine Vorgänger-RMID Ry mit einer Ressourcenanwendung von Y teilen, und die Sammlung aller 11 Anwendungen 1, 8, 9, 10, 11 kann eine gemeinsame Vorgänger-RMID Rz mit einer Ressourcenzuweisung von Z teilen. In einem solchen Beispiel können innerhalb der Zuweisung Z, die Rz gegeben wird, Unterzuweisungen X' und Y' an Rx und Ry gegeben werden. Rx und Ry können sich zu einer Ressourcenvoraussetzung summieren, der Rz übersteigt, jedoch kann die Plattform Z in Zuweisungen X' für Rx und Y' für Ry zu Verhältnissen (z. B. X' = Z * X / (X + Y) und Y' = Z * Y / (X + Y)) aufteilen. Alternativ dazu können unterschiedliche Weisen des Aufteilens von Z unter den Komponenten-RMIDs X und Y durch eine andere Richtlinie formuliert und gesteuert werden. Dies ermöglicht es den Hardwarekomponenten 924 und dem OS 922, die Zuweisung von Ressourcen (z. B. Prozessorfrequenzen, Speicherbandbreiten, Cache-Kapazitäten, PCIe-Durchsätze usw.) gemäß einer solchen beispielhaften zusammengesetzten RMID-Hierarchie und assoziierten kollektiven Ressourcenzuweisungen anzupassen, während die Mesh-Proxys 908, 910, 912 periodisch die Hardwarekomponenten 924 und das OS 922 mit zusätzlichen Aktualisierungen anweisen.
Bei Block 1210 bestimmt der beispielhafte Lastausgleicher 920, ob die Schnittstelle 916 (9) ein oder mehrere Ressourcenanforderungssignale (e.g., RDT-Steuersignal(e)) von den Mesh-Proxys 908, 910, 912 empfangen hat. Falls der beispielhafte Lastausgleicher 920 bestimmt, dass die Schnittstelle 916 ein oder mehrere Ressourcenanforderungssignale nicht erhalten hat (Block 1210: NEIN), geht die Steuerung zu Block 1216 über. Falls der beispielhafte Lastausgleicher 920 bestimmt, dass die Schnittstelle 916 ein oder mehrere Ressourcenanforderungssignale erhalten hat (Block 1210: JA), bestimmt der beispielhafte Lastausgleicher 920 einen RMID-übergreifenden (z. B. anwendungsübergreifenden) Ausgleich der Ressourcen des OS 922 und/oder der Hardwarekomponenten 924 basierend auf den Ressourcenanforderungssignalen (z. B. dem einen oder den mehreren RDT-Steuersignalen von dem einen oder den mehreren Mesh-Proxys 908, 910, 912 (Block 1212). Der Lastausgleicher 920 gleicht zum Beispiel die SLA/SLO-Voraussetzungen der Anwendungen 902, 904, 906 aus, die gewissen Anwendungen Priorität als Teil der Hierarchie geben, falls überhaupt. Bei Block 1214 überträgt die beispielhafte Schnittstelle 916 Ressourcenzuweisungsanweisungen zu dem OS 922 gemäß dem RMID-übergreifenden Ausgleich.
Bei Block 1216 bestimmt der beispielhafte Lastausgleicher 920, ob Telemetriedaten von dem OS 808 über die Schnittstelle 916 empfangen wurden. Die Telemetriedaten entsprechen der Leistungsfähigkeit des OS 808 und/oder der Hardwarekomponenten 810. Auf diese Weise können der beispielhafte Lastausgleicher 920, der beispielhafte Mesh-Proxy 908 und/oder die beispielhafte Anwendung 902 die Einhaltung des SLA/SLO überwachen. Falls der beispielhafte Lastausgleicher 920 bestimmt, dass keine Telemetriedaten empfangen wurden (Block 1216: NEIN), geht die Steuerung zu Block 1220 über. Falls der beispielhafte Lastausgleicher 920 bestimmt, dass Telemetriedaten empfangen wurden (Block 1216: JA), verarbeitet der beispielhafte Lastausgleicher 920 die Telemetriedaten (Block 1218). Der beispielhafte Lastausgleicher 920 kann die Telemetriedaten verarbeiten, indem er bestimmt, ob die Telemetriedaten die SLA/SLO-Voraussetzungen erfüllen, und/oder kann die Telemetriedaten zu dem Mesh-Proxy 908 übertragen. In manchen Beispielen überträgt der Lastausgleicher 920 eine Indikation darüber zu dem Mesh-Proxy 908, ob die Rechenvorrichtung 706 mit den SLO/SLA-Voraussetzungen konform ist.
Bei Block 1220 bestimmt der beispielhafte Lastausgleicher 920 basierend auf den verarbeiteten Telemetriedaten, ob die SLA- und/oder SLO-Voraussetzungen erfüllt sind. Falls der Lastausgleicher 920 bestimmt, dass die SLA- und/oder SLO-Voraussetzungen erfüllt sind (Block 1120: JA), geht die Steuerung zu Block 1224 über. Falls der Lastausgleicher 920 bestimmt, dass die SLA- und/oder SLO-Voraussetzungen nicht erfüllt sind (Block 1120: NEIN), überträgt der beispielhafte Lastausgleicher 920 eine aktualisierte Ressourcenanforderungssteuerung zu dem OS 922, um Ressourcen zuzuweisen, um die SLA- und/oder SLO-Voraussetzungen zu erfüllen (Block 1222).
Bei Block 1224 bestimmt der beispielhafte Lastausgleicher 920, ob eine neue Anwendung installiert wurde. Falls der beispielhafte Lastausgleicher 920 bestimmt, dass eine neue Anwendung installiert wurde (Block 1224: JA), kehrt die Steuerung zu Block 1204 zurück. Falls der beispielhafte Lastausgleicher 920 bestimmt, dass keine neue Anwendung installiert wurde (Block 1224: NEIN), enden die Anweisungen.
13 veranschaulicht ein Flussdiagramm, das beispielhafte maschinenlesbare Anweisungen 1300 repräsentiert, die ausgeführt werden können, um den beispielhaften Broker 704 (7 und 10) und die beispielhafte gepoolte QoS-Steuerung 1012 (10A) zu implementieren, um QoS basierend auf SLAs für gepoolte Ressourcen in der Rechenvorrichtung 706 zu verwalten. Obwohl das Flussdiagramm von 13 in Verbindung mit der Rechenvorrichtung 706 von 10A beschrieben ist, können die beispielhaften Anweisungen verwendet werden, um eine oder mehrere andere Arten von Rechenvorrichtungen (z. B. virtuelle Maschinen, Dienste usw.) zu implementieren.
Bei Block 1302 bestimmt die beispielhafte Schnittstelle 1000 ( 10A) des Brokers 704, ob eine Dienstanforderung empfangen wurde. Eine Dienstanforderung kann einer Anweisung zum Durchführen einer oder mehrerer Aufgaben entsprechen. Die Dienstanforderung kann von einer anderen Rechenvorrichtung von derselben Domäne 703 (z. B. Inter-Domänen) oder einer anderen Domäne (z. B. von einem anderen Broker, einer Rechenvorrichtung von einer anderen Domäne und/oder der Cloud/dem Datenzentrum 701 von 1) gesendet werden. Falls die Schnittstelle 1000 bestimmt, dass keine Dienstanforderung empfangen wurde (Block 1302: NEIN), kehrt die Steuerung zu Block 1302 zurück, bis eine Dienstanforderung empfangen wird. Falls die Schnittstelle 1000 bestimmt, dass eine Dienstanforderung empfangen wurde (Block 1302: JA), überträgt der beispielhafte Dienstanforderungsanalysator 1002 die SLA/SLO-Voraussetzungen (z. B. extrahiert aus oder als Teil der Dienstanforderung) zu der beispielhaften gepoolten QoS-Steuerung 1012 (Block 1304). Wie oben beschrieben, kann der beispielhafte Dienstanforderungsanalysator 1002 (10A) die Dienstanforderung verarbeiten, um die SLA/SLO-Voraussetzungen der Dienstanforderung zu bestimmen, und die Voraussetzungen in eine Menge gepoolter Ressourcen und/oder Charakteristiken der gepoolten Ressourcen umwandeln und die Menge gepoolter Ressourcen und/oder gepoolter Ressourcencharakteristiken zu der gepoolten QoS-Steuerung 1012 übertragen. Zusätzlich oder alternativ dazu kann der beispielhafte Dienstanforderungsanalysator 1002 eine Anforderung nach gepoolten Ressourcencharakteristiken und/oder gepoolter Ressourcenverfügbarkeit senden. Auf diese Weise kann der beispielhafte Ressourcenkomparator 1004 bestimmen, ob die Rechenvorrichtung 706 ausreichend Ressourcen aufweist, um die Anforderung gemäß den SLA/SLO-Voraussetzungen lokal an dem Broker 704 zu versorgen.
Bei Block 1306 übersetzt die beispielhafte gepoolte QoS-Steuerung 1012 die Service-Level-Voraussetzungen in Ressourcen-ressourcenbasierte Attribute. Falls die Dienstanforderung zum Beispiel ein SLO beinhaltet, das einer bestimmten Latenzvoraussetzung entspricht, wandelt die gepoolte QoS-Steuerung 1012 die Latenzvoraussetzung in die Menge und/oder Art von Ressource um, die benötigt wird, um die Latenzvoraussetzung zu erfüllen. Bei Block 1308 bestimmt die beispielhafte gepoolte QoS-Steuerung 1012, ob die gepoolten Ressourcen (z. B. von der gepoolten Beschleunigerplattform 1014) in der Lage sind, die Dienstanforderung gemäß den ressourcenbasierten Attributen (z. B. basierend auf den Charakteristiken der Ressourcen an der Rechenvorrichtung 106) zu versorgen. Falls die Dienstanforderung zum Beispiel einer Latenz entspricht, bestimmt die gepoolte QoS-Steuerung 1012, ob die gepoolten Ressourcen in der Lage sind, gemäß der erforderlichen Latenz zu arbeiten.
Falls die beispielhafte gepoolte QoS-Steuerung 1012 bestimmt, dass die gepoolten Ressourcen nicht in der Lage sind, gemäß der Dienstanforderung zu arbeiten (Block 1308: NEIN), überträgt die beispielhafte gepoolte QoS-Steuerung 1012 eine negative Antwort zu dem beispielhaften Broker 704, die angibt, dass die Rechenvorrichtung 706 unzureichende Ressourcen aufweist, um die Dienstanforderung gemäß den Voraussetzungen zu erfüllen (Block 1310). Bei Block 1312 markiert der beispielhafte Ressourcenkomparator 1004 (10A) die negative Antwort. In manchen Beispielen kann die Netzwerkschnittstelle 1000 die markierte negative Antwort zu einer Überwachungsvorrichtung übertragen, die die Rechenvorrichtung 706 (z. B. die Cloud/das Datenzentrum 701 von 1) überwacht. Auf diese Weise kann die Überwachungsvorrichtung potentiell die gepoolten Ressourcen an der Rechenvorrichtung 706 aktualisieren und/oder einem Administrator das Aktualisieren der gepoolten Ressourcen an der Rechenvorrichtung 706 vorschlagen. Nach Block 1312 enden die Anweisungen.
Falls die beispielhafte gepoolte QoS-Steuerung 1012 bestimmt, dass die gepoolten Ressourcen in der Lage sind, gemäß der Dienstanforderung zu arbeiten (Block 1308: JA), bestimmt die beispielhafte gepoolte QoS-Steuerung 1012 die Kapazität der gepoolten Ressourcen (Block 1314). Zum Beispiel können die gepoolten Ressourcen der Rechenvorrichtung 706 strukturell (z. B. Ressourcenfähigkeit) in der Lage sein, eine SLA/SLO-Voraussetzung zu erfüllen, aber möglicherweise keine Kapazität (z. B. Ressourcenkapazität) aufweisen, um eine SLA/SLO-Voraussetzung zu erfüllen, weil die gepoolten Ressourcen nicht verfügbar sind (z. B. durch die Rechenvorrichtung 106 verwendet werden). Dementsprechend bestimmt die gepoolte QoS-Steuerung 1012, wie viele der gepoolten Ressourcen nicht verwendet werden und/oder anderweitig zur Verwendung verfügbar sind, um die Kapazität der gepoolten Ressourcen zu bestimmen.
Bei Block 1316 überträgt die beispielhafte gepoolte QoS-Steuerung 1012 eine Antwort zu dem Broker 704, die die Fähigkeit und die bestimmte Kapazität der gepoolten Ressourcen der Rechenvorrichtung 706 angibt. Die Antwort kann eine Indikation darüber beinhalten, ob die gepoolten Ressourcen die strukturelle Fähigkeit und ausreichende Kapazität zum Versorgen der Anforderung aufweisen. Die Antwort kann auch die bestimmte Kapazität beinhalten. Auf diese Weise kann der Broker 704, falls die gepoolten Ressourcen die strukturelle Fähigkeit aufweisen, aber nicht genügend Kapazität aufweisen, um die gesamte Anforderung zu versorgen, Anweisungen zum Durchführen eines Teils der Dienstanforderung basierend auf der bestimmten Kapazität übertragen.
Bei Block 1318 bestimmt der beispielhafte Ressourcenkomparator 1004 eine Ressourcenzuweisung für die Dienstanforderung basierend auf der einen oder den mehreren Antworten von den Rechenvorrichtungen 706, 708 und/oder beliebigen anderen Rechenvorrichtungen in der Domäne 703 (1). Zum Beispiel kann der Ressourcenkomparator 1004 basierend auf den Fähigkeiten und/oder der Kapazität der gepoolten Ressourcen der beiden Rechenvorrichtungen 706, 708 bestimmen, dass die Dienstanforderung einer der Rechenvorrichtungen 706, 708 zugewiesen oder auf die beiden Rechenvorrichtungen 706, 708 aufgeteilt werden sollte. Bei Block 1320 überträgt die beispielhafte Netzwerkschnittstelle 1000 die Zuweisungsanweisungen zu dem Plattformagenten 1010 der Rechenvorrichtungen, die der bestimmten Ressourcenzuweisung entsprechen. Die Übermittlung der Zuweisungsanweisungen teilt den Recheneinrichtungen mit, welche Teile der Dienstanforderungen auszuführen sind. Nach Block 1320 enden die Anweisungen.
14A ist ein Blockdiagramm einer beispielhaften Implementierung eines beispielhaften Edge-Rechenknotens 1400, der eine Rechen-Engine (hierin auch als „Rechenschaltungsanordnung“ bezeichnet) 1402, ein Eingabe/Ausgabe(E/A)-Untersystem 1408, eine Datenspeicherung 1410, ein Kommunikationsschaltungsanordnungsuntersystem 1412 und optional eine oder mehrere Peripherievorrichtungen 1414 beinhaltet. Bei anderen Beispielen können jeweilige Rechenvorrichtungen andere oder zusätzliche Komponenten beinhalten, wie etwa jene, die typischerweise in einem Computer gefunden werden (z. B. eine Anzeige, Peripherievorrichtungen usw.). Zusätzlich dazu können bei manchen Beispielen eine oder mehrere der veranschaulichenden Komponenten in einer anderen Komponente integriert sein oder anderweitig einen Teil davon bilden. Der beispielhafte Edge-Rechenknoten 1400 von 14 kann in einem der in den 1-4 und/oder 6-10C veranschaulichten Edge-Rechensysteme eingesetzt werden, um einen beliebigen Edge-Rechenknoten der 1-4 und/oder 6-10C zu implementieren. Der beispielhafte Edge-Rechenknoten 1400 kann zusätzlich oder alternativ beliebige der Komponenten der Rechenvorrichtung 706 der 7-10C beinhalten.
Der beispielhafte Rechenknoten 1400 kann als eine beliebige Art von Engine, Vorrichtung oder Sammlung von Vorrichtungen umgesetzt sein, die in der Lage sind, verschiedene Rechenfunktionen durchzuführen. Bei manchen Beispielen kann der Rechenknoten 1400 als eine einzige Vorrichtung ausgeführt sein, wie etwa eine integrierte Schaltung, ein eingebettetes System, ein feldprogrammierbares Gate-Array (FPGA), ein System-on-Chip (SOC) oder ein anderes integriertes System oder eine andere integrierte Vorrichtung. Bei dem veranschaulichenden Beispiel beinhaltet der Rechenknoten 1400 einen Prozessor 1404 oder einen Speicher 1406 oder ist als diese ausgeführt. Der beispielhafte Prozessor 1404 kann als eine beliebige Art von Prozessor umgesetzt sein, der in der Lage ist, die hierin beschriebenen Funktionen (z. B. Ausführen einer Anwendung) durchzuführen. Der Prozessor 1404 kann zum Beispiel als ein oder mehrere Mehrkernprozessoren, ein Mikrocontroller, eine Verarbeitungseinheit, eine spezialisierte oder SpezialVerarbeitungseinheit oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerschaltung umgesetzt sein.
Bei manchen Beispielen kann der Prozessor 1404 als ein FPGA, eine anwendungsspezifische integrierte Schaltung (ASIC), rekonfigurierbare Hardware oder Hardwareschaltungsanordnung oder andere spezialisierte Hardware umgesetzt sein, diese beinhalten oder mit diesen gekoppelt sein, um eine Leistungsfähigkeit der hierin beschriebenen Funktionen zu ermöglichen. Bei manchen Beispielen kann der Prozessor 1404 auch als eine spezialisierte x-Verarbeitungseinheit (xPU) umgesetzt sein, die auch als eine Datenverarbeitungseinheit (DPU), eine Infrastrukturverarbeitungseinheit (IPU) oder eine Netzwerkverarbeitungseinheit (NPU) bekannt ist. Eine solche xPU kann als eine eigenständige Schaltung oder ein Schaltungs-Package umgesetzt sein, innerhalb eines SOC integriert sein oder mit einer Networking-Schaltungsanordnung (z. B. in einem SmartNIC), einer Beschleunigungsschaltungsanordnung, Speicherungsvorrichtungen oder KI-Hardware (z. B. GPUs oder programmierte FPGAs) integriert sein. Eine solche xPU kann dazu ausgelegt sein, eine Programmierung zu empfangen, um einen oder mehrere Datenströme zu verarbeiten und spezifische Aufgaben und Handlungen für die Datenströme (wie etwa Hosten von Mikrodiensten, Durchführen von Dienstverwaltung oder Orchestrierung, Organisieren oder Verwalten von Server- oder Datenzentrum-Hardware, Verwalten von Dienst-Meshes oder Sammeln und Verteilen von Telemetrie) außerhalb der CPU und/oder GPU oder Allzweck-Verarbeitungshardware durchzuführen. Es versteht sich jedoch, dass eine xPU, ein SOC, eine CPU, eine GPU und andere Variationen des Prozessors 1404 koordiniert miteinander arbeiten können, um viele Arten von Operationen und Anweisungen innerhalb und für den Rechenknoten 1400 auszuführen.
Der beispielhafte Speicher 1406 kann als ein beliebiger Typ von flüchtigem (z. B. dynamischer Direktzugriffsspeicher (DRAM) usw.) oder nichtflüchtigem Speicher oder flüchtiger oder nichtflüchtiger Datenspeicherung umgesetzt sein, der/die in der Lage ist, die hierin beschriebenen Funktionen durchzuführen. Ein flüchtiger Speicher kann ein Speicherungsmedium sein, das Leistung zum Aufrechterhalten des Zustands von durch das Medium gespeicherten Daten benötigt. Nichtbeschränkende Beispiele für flüchtigen Speicher können verschiedene Typen von Direktzugriffsspeicher (RAM), wie etwa DRAM oder statischen Direktzugriffsspeicher (SRAM), einschließen. Ein bestimmter Typ von DRAM, der in einem Speichermodul verwendet werden kann, ist synchroner dynamischer Direktzugriffsspeicher (SDRAM).
Bei einem Beispiel ist die Speichervorrichtung 1406 eine blockadressierbare Speichervorrichtung, wie etwa jene, die auf NAND- oder NOR-Technologien basieren. Eine Speichervorrichtung 1406 kann auch eine dreidimensionale Crosspoint-Speichervorrichtung (z. B. Intel® 3D XPoint™ Speicher) oder andere byteadressierbare nichtflüchtige „Write-in-Place“-Speichervorrichtungen beinhalten. Die Speichervorrichtung 1406 kann sich auf den Die selbst und/oder auf ein gekapseltes Speicherprodukt beziehen. Bei manchen Beispielen kann der 3D-Crosspoint-Speicher (z. B. Intel® 3D XPoint™ Speicher) eine transistorlose stapelbare Crosspoint-Architektur umfassen, bei der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und einzeln adressierbar sind und bei der die Bitspeicherung auf einer Änderung des Volumenwiderstands basiert. Bei manchen Beispielen kann der gesamte oder ein Teil des Speichers 1406 in den Prozessor 1404 integriert sein. Der Speicher 1406 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie etwa eine oder mehrere Anwendungen, Daten, die durch die Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
Die beispielhafte Rechenschaltungsanordnung 1402 ist kommunikativ mit anderen Komponenten des Rechenknotens 1400 über das E/A-Untersystem 1408 gekoppelt, das als eine Schaltungsanordnung und/oder Komponenten umgesetzt sein kann, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 1402 (z. B. mit dem Prozessor 1404 und/oder dem Hauptspeicher 1406) und anderen Komponenten der Rechenschaltungsanordnung 1402 zu ermöglichen. Das E/A-Untersystem 1408 kann zum Beispiel als Speichersteuerungshubs, Eingabe/Ausgabe-Steuerungshubs, integrierte Sensorhubs, Firmwarevorrichtungen, Kommunikationslinks (z. B. Punkt-zu-Punkt-Links, Buslinks, Drähte, Kabel, Lichtleiter, Leiterbahnen usw.) und/oder andere Komponenten und Untersysteme umgesetzt sein oder diese anderweitig beinhalten, um die Eingabe/Ausgabe-Operationen zu erleichtern. Bei manchen Beispielen kann das E/A-Untersystem 1408 einen Teil eines System-on-Chip (SoC) bilden und zusammen mit dem Prozessor 1404 und/oder dem Speicher 1406 und/oder anderen Komponenten der Rechenschaltungsanordnung 1402 in die Rechenschaltungsanordnung 1402 integriert sein.
Die eine oder die mehreren veranschaulichenden Datenspeicherungsvorrichtungen 1410 können als eine beliebige Art von Vorrichtungen umgesetzt sein, die zur Kurzzeit- oder Langzeitspeicherung von Daten konfiguriert sind, wie etwa zum Beispiel Speichervorrichtungen und -schaltungen, Speicherkarten, Festplattenlaufwerke, Solid-State-Laufwerke oder andere Datenspeicherungsvorrichtungen. Einzelne Datenspeicherungsvorrichtungen 1410 können eine Systempartitionierung beinhalten, die Daten und Firmwarecode für die Datenspeicherungsvorrichtung 1410 speichert. Einzelne Datenspeicherungsvorrichtungen 1410 können auch eine oder mehrere Betriebssystempartitionierungen beinhalten, die Datendateien und ausführbare Dateien für Betriebssysteme in Abhängigkeit von zum Beispiel der Art des Rechenknotens 1400 speichern.
Die beispielhafte Kommunikationsschaltungsanordnung 1412 kann als eine beliebige Kommunikationsschaltung, -vorrichtung oder Sammlung davon umgesetzt sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltungsanordnung 1402 und einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway eines implementierenden Edge-Rechensystems) zu ermöglichen. Die beispielhafte Kommunikationsschaltungsanordnung 1412 kann dazu konfiguriert sein, eine oder mehrere beliebige Kommunikationstechnologien (z. B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle (z.B. ein zellulares Networking-Protokoll, wie etwa einen 3GPP-4G- oder -5G-Standard, ein drahtloses lokales Netzwerkprotokoll, wie etwa IEEE 802.11/WiFi®, ein drahtloses Weitbereichsnetzwerkprotokoll, Ethernet, Bluetooth®, Bluetooth Low Energy, ein IoT-Protokoll wie etwa IEEE 802.15.4 oder ZigBee®, Niederleistungs-Weitbereichsnetzwerk- (LPWAN - Low-Power Wide Area Network) oder Niederleistungs-Weitbereichs(LPWA - Low-Power Wide Area)-Protokolle usw.) zu verwenden, um eine solche Kommunikation zu bewirken.
Die veranschaulichende Kommunikationsschaltungsanordnung 1412 beinhaltet eine Netzwerkschnittstellensteuerung (NIC) 1420, die auch als eine Host-Fabric-Schnittstelle (HFI: Host Fabric Interface) bezeichnet werden kann. Die beispielhafte NIC 1420 kann als eine oder mehrere Add-In-Platinen, Tochterkarten, Netzwerkschnittstellenkarten, Steuerungschips, Chipsätze oder andere Vorrichtungen umgesetzt sein, die durch den Rechenknoten 1400 verwendet werden können, um sich mit einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway-Knoten) zu verbinden. Bei manchen Beispielen kann die NIC 1420 als Teil eines System-on-Chip (SoC) umgesetzt sein, das einen oder mehrere Prozessoren beinhaltet, oder kann auf einem Mehrchip-Package enthalten sein, das auch einen oder mehrere Prozessoren beinhaltet. Bei manchen Beispielen kann die NIC 1420 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) beinhalten, die beide lokal für die NIC 1420 sind. Bei solchen Beispielen kann der lokale Prozessor der NIC 1420 dazu in der Lage sein, eine oder mehrere der Funktionen der hierin beschriebenen Rechenschaltungsanordnung 1402 durchzuführen. Zusätzlich oder alternativ dazu kann in solchen Beispielen der lokale Speicher der NIC 1420 in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Socket-Ebene, Chip-Ebene und/oder anderen Ebenen integriert sein.
Zusätzlich kann in manchen Beispielen ein jeweiliger Rechenknoten 1400 eine oder mehrere Peripherievorrichtungen 1414 beinhalten. Solche Peripherievorrichtungen 1414 können eine beliebige Art von Peripherievorrichtung beinhalten, die in einer Rechenvorrichtung oder einem Server gefunden wird, wie etwa Audioeingabevorrichtungen, eine Anzeige, andere Eingabe/Ausgabe-Vorrichtungen, Schnittstellenvorrichtungen und/oder andere Peripherievorrichtungen, in Abhängigkeit von der speziellen Art des Rechenknotens 1400. In weiteren Beispielen kann der Rechenknoten 1400 durch einen jeweiligen Edge-Rechenknoten (egal ob ein Client, Gateway oder Aggregationsknoten) in einem Edge-Rechensystem oder ähnlichen Formen von Geräten, Computern, Untersystemen, Schaltungsanordnungen oder anderen Komponenten umgesetzt sein.
In einem ausführlicheren Beispiel veranschaulicht 14B ein Blockdiagramm einer beispielhaften Rechenvorrichtung 1450, die dazu strukturiert ist, die Anweisungen der 11-13 auszuführen, um die hierin beschriebenen Techniken (z. B. Operationen, Prozesse, Verfahren und Methodologien) zu implementieren, wie etwa die Rechenvorrichtung 708 der 7-10C. Diese Rechenvorrichtung 1450 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 1400 bereit, wenn sie als eine oder als Teil einer Rechenvorrichtung (z. B. als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway usw.) implementiert wird. Die Rechenvorrichtung 1450 kann beliebige Kombinationen der Hardware- oder Logikkomponenten beinhalten, die hierin referenziert sind, und sie kann eine beliebige Vorrichtung beinhalten oder mit dieser gekoppelt sein, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination solcher Netzwerke verwendbar ist. Die Komponenten können als integrierte Schaltungen (ICs: Integrated Circuits), Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Anweisungssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die in der Rechenvorrichtung 1450 angepasst sind, oder als Komponenten, die anderweitig in einem Gestell eines größeren Systems integriert sind, implementiert werden. Zum Beispiel kann die Rechenvorrichtung 1450 beispielsweise ein Server, ein Personal Computer, eine Workstation, eine selbstlernende Maschine (z. B. ein neuronales Netzwerk), eine Mobilvorrichtung (z. B. ein Mobiltelefon, ein Smartphone, ein Tablet wie etwa ein iPadTM), ein Personal Digital Assistant (PDA), ein Internet-Gerät, ein DVD-Abspielgerät, ein CD-Abspielgerät, ein digitaler Videorekorder, ein Blue-Ray-Abspielgerät, eine Spielekonsole, ein persönlicher Videorekorder, eine Set-Top-Box, ein Headset oder eine andere tragbare Vorrichtung, eine Internet-der-Dinge(IoT)-Vorrichtung oder eine beliebige andere Art von Rechenvorrichtung sein.
Die Edge-Rechenvorrichtung 1450 kann eine Verarbeitungsschaltungsanordnung in der Form eines Prozessors 1452 beinhalten, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithread-Prozessor, ein Ultraniederspannungsprozessor, ein eingebetteter Prozessor, eine xPU/DPU/IPU/NPU, eine Spezialverarbeitungseinheit, eine spezialisierte Verarbeitungseinheit oder andere bekannte Verarbeitungselemente sein kann. Der Prozessor 1452 kann ein Teil eines System-on-Chip (SoC) sein, in dem der Prozessor 1452 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Package ausgebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel Corporation, Santa Clara, Kalifornien, USA. Als ein Beispiel kann der Prozessor 1452 einen auf Intel® Architecture Core™ basierenden CPU-Prozessor, wie etwa einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i14-, einen i9- oder einen MCU-Klasse-Prozessor oder einen anderen solchen Prozessor, der von Intel® verfügbar ist, beinhalten. Eine beliebige Anzahl anderer Prozessoren kann jedoch verwendet werden, wie etwa erhältlich von der Firma Advanced Micro Devices, Inc. (AMD®) aus Sunnyvale, Kalifornien, USA, ein MIPS®-basiertes Design der Firma MIPS Technologies, Inc. aus Sunnyvale, Kalifornien, USA, ein ARM®-basiertes Design, lizenziert von ARM Holdings, Ltd. oder ein Kunde davon, oder deren Lizenznehmer oder Adopter. Die Prozessoren können Einheiten beinhalten, wie etwa einen A5-A13-Prozessor von Apple® Inc., einen Snapdragon™-Prozessor von Qualcommon® Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc. Der Prozessor 1452 und die begleitende Schaltungsanordnung können in einem einzigen Socket-Formfaktor, mehreren Socket-Formfaktoren oder einer Vielfalt anderer Formate bereitgestellt sein, einschließlich in beschränkten Hardwarekonfigurationen oder Konfigurationen, die weniger als alle in 14B gezeigten Elemente beinhalten. In diesem Beispiel implementiert der Prozessor die beispielhaften Mesh-Proxys 804, 806, 908, 910, 912, die beispielhaften OSs 808, 922, das beispielhafte Soft-QoS-Mesh-Netzwerk 914, die beispielhafte Netzwerkschnittstelle 916, den beispielhaften Hierarchiegenerator 918, den beispielhaften Lastausgleicher 920 und die beispielhafte gepoolte QoS-Steuerung 1012 der 8-10C.
Der Prozessor 1452 kann über ein Interconnect 1456 (z. B. einen Bus) mit einem Systemspeicher 1454 kommunizieren. Eine beliebige Anzahl an Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher 1454 Direktzugriffsspeicher (RAM) gemäß einem JEDEC-Design (JEDEC: Joint Electron Devices Engineering Council) sein, wie etwa den DDR- oder mobilen DDR-Standards (z. B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In bestimmten Beispielen kann eine Speicherkomponente einem von JEDEC vertriebenen DRAM-Standard entsprechen, wie etwa JESD149F für DDR-SDRAM, JESD149-2F für DDR2-SDRAM, JESD149-3F für DDR3-SDRAM, JESD149-4A für DDR4-SDRAM, JESD209 für Low-Power-DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Solche Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden und Kommunikationsschnittstellen der Speicherungsvorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. Bei diversen Implementierungen können die einzelnen Speichervorrichtungen von einer beliebigen Anzahl von verschiedenen Package-Typen sein, wie etwa Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q114P). Diese Vorrichtungen können bei manchen Beispielen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Vorrichtungen bei anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die der Reihe nach durch einen gegebenen Verbinder mit der Hauptplatine gekoppelt sind. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, z. B. Dual Inline Memory Modules (DIMMs) verschiedener Varianten, einschließlich unter anderem microDnVIMs oder MiniDnVIMs.
Um eine dauerhafte Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssystemen und so weiter, bereitzustellen, kann eine Speicherung 1458 auch über das Interconnect 1456 mit dem Prozessor 1452 gekoppelt sein. Bei einem Beispiel kann der Speicher 1458 über ein Solid-State-Laufwerk (SSDD) implementiert werden. Andere Vorrichtungen, die für die Speicherung 1458 verwendet werden können, beinhalten Flash-Speicherkarten, wie etwa Secure-Digital(SD)-Karten, microSD-Karten, eXtreme-Digital-(XD)-Bildkarten und dergleichen und Universal-Serial-Bus(USB)-Flash-Laufwerke. Bei einem Beispiel kann die Speichervorrichtung Speichervorrichtungen sein oder beinhalten, die Chalkogenidglas, NAND-Flash-Speicher mit mehreren Schwellenpegeln, NOR-Flash-Speicher, Einzel- oder Mehrfachpegel-Phasenwechselspeicher (PCM), einen resistiven Speicher, Nanodrahtspeicher, ferroelektrischen Transistor-Direktzugriffsspeicher (FeTRAM), antiferroelektrischen Speicher, magnetoresistiven Direktzugriffsspeicher (MRAM), Speicher, der Memristortechnologie beinhaltet, resistiven Speicher einschließlich der Metall-Oxid-Basis, der Sauerstoffleerstellenbasis und den Leitfähige-Brücke-Direktzugriffsspeicher (CB-RAM) oder Spin-Transfer-Torque(STT)-MRAM, einer auf spintronischen Magnetübergangsspeicher basierte Vorrichtung, eine Magnettunnelübergang(MTJ)-basierte Vorrichtung, eine DW(Domänenwand)- und SOT(Spin-Orbit-Transfer)-basierte Vorrichtung, eine thyristorbasierte Speichervorrichtung oder eine Kombination von beliebigen der obigen oder eines anderen Speichers verwenden.
In Niederleistungsimplementierungen kann die Speicherung 1458 ein On-Die-Speicher oder Register sein, die mit dem Prozessor 1452 assoziiert sind. Bei manchen Beispielen kann die Speicherung 1458 jedoch unter Verwendung eines Mikro-Festplattenlaufwerks (HDD) implementiert werden. Ferner kann eine beliebige Anzahl neuer Technologien für die Speicherung 1458 zusätzlich zu den, oder anstelle der, beschriebenen Technologien verwendet werden, wie etwa unter anderem Widerstandswechselspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher.
Die Komponenten können über das Interconnect 1456 kommunizieren. Das Interconnect 1456 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich Industry Standard Architecture (ISA), extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe) oder eine beliebige Anzahl anderer Technologien. Das Interconnect 1456 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird. Andere Bussysteme können enthalten sein, wie etwa unter anderem eine Inter-Integrated-Circuit(I2C)-Schnittstelle, eine Serial-Peripheral-Interface(SPI)-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
Das Interconnect 1456 kann den Prozessor 1452 mit einem Sendeempfänger 1466 koppeln, um mit den verbundenen Edge-Vorrichtungen 1462 zu kommunizieren. Der Sendeempfänger 1466 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie z. B. 2,4-Gigahertz (GHz)-Übertragungen nach dem IEEE-802.15.4-Standard, unter Verwendung des Bluetooth®-Low-Energy(BLE)-Standards, wie von der Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards unter anderem. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen zu den verbundenen Edge-Vorrichtungen 1462 verwendet werden. Zum Beispiel kann eine WLAN-Einheit (WLAN: Wireless Local Area Network - drahtloses Lokalnetzwerk) verwendet werden, um WiFi® -Kommunikationen gemäß dem IEEE (Institute of Electrical and Electronics Engineers) 802.11-Standard zu implementieren. Außerdem können Drahtlos-Weitbereichskommunikationen, z. B. gemäß einem zellularen oder anderen Drahtlos-Weitbereichsprotokoll über eine Drahtlos-Weitbereichsnetzwerk(WWAN)-Einheit stattfinden.
Der Drahtlosnetzsendeempfänger 1466 (oder mehrere Sendeempfänger) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen in einer anderen Reichweite kommunizieren. Zum Beispiel kann die Rechenvorrichtung 1450 mit nahen Vorrichtungen, z. B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Sendeempfängers basierend auf Bluetooth Low Energy (BLE) oder einem anderen Niedrigleistungsfunkgerät kommunizieren, um Leistung zu sparen. Entferntere verbundene Edge-Vorrichtungen 1462, z. B. innerhalb von etwa 50 Metern, können über ZigBee® oder andere Zwischenleistungsfunkgeräte erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät mit unterschiedlichen Leistungspegeln stattfinden oder können über separate Sendeempfänger stattfinden, zum Beispiel einen lokalen Sendeempfänger, der BLE verwendet, und einen separaten Mesh-Sendeempfänger, der ZigBee® verwendet.
Ein Drahtlosnetzsendeempfänger 1466 (z. B. ein Funksendeempfänger) kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 1495 über Lokal- oder Weitbereichsnetzwerkprotokolle zu kommunizieren. Der Drahtlossendeempfänger 1466 kann ein LPWA-Sendeempfänger (LPWA: Low Power Wide Area) sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Die Rechenvorrichtung 1450 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network - Langstrecken-Weitbereichsnetzwerk), das von Semtech und der LoRa Alliance entwickelt wird, kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl von anderen Cloud-Sendeempfängern verwendet werden, die Kommunikationen mit großer Reichweite und niedriger Bandbreite implementieren, wie etwa Sigfox, und andere Technologien. Ferner können andere Kommunikationstechniken, wie beispielsweise Kanalspringen mit Zeitschlitzen, das in der Spezifikation IEEE 802.15.4e beschrieben ist, verwendet werden.
Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den Systemen verwendet werden, die für den Drahtlosnetzsendeempfänger 1466 erwähnt wurden, wie hierin beschrieben. Zum Beispiel kann der Sendeempfänger 1466 einen zellularen Sendeempfänger umfassen, der Spreizspektrum(SPA/SAS)-Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa WiFi®-Netze für Kommunikationen mittlerer Geschwindigkeit und Bereitstellung von Netzkommunikationen. Der Sendeempfänger 1466 kann Funkgeräte umfassen, die mit einer beliebigen Anzahl von 3GPP(Third Generation Partnership Project)-Spezifikationen kompatibel sind, wie etwa Long Term Evolution (LTE) und Kommunikationssysteme der fünften Generation (5G), die am Ende der vorliegenden Offenbarung ausführlicher erörtert werden. Eine Netzwerkschnittstellensteuerung (NIC) 1468 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 1495 oder zu anderen Vorrichtungen, wie etwa den verbundenen Edge-Vorrichtungen 1462 (die z. B. in einem Mesh arbeiten), bereitzustellen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET unter vielen anderen. Eine zusätzliche NIC 1468 kann enthalten sein, um eine Verbindung mit einem zweiten Netzwerk zu ermöglichen, beispielsweise eine erste NIC 1468, die Kommunikationen zu der Cloud über Ethernet bereitstellt, und eine zweite NIC 1468, die Kommunikationen zu anderen Vorrichtungen über einen anderen Netzwerktyp bereitstellt.
Angesichts der Vielfalt von Arten anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk kann zutreffende Kommunikationsschaltungsanordnung, die von der Vorrichtung verwendet wird, eine oder mehrere der Komponenten 1464, 1466, 1468 oder 1470 beinhalten oder durch diese verkörpert sein. Dementsprechend können bei verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z. B. Empfangen, Senden usw.) durch eine solche Kommunikationsschaltungsanordnung verkörpert werden.
Die Rechenvorrichtung 1450 kann eine Beschleunigungsschaltungsanordnung 1464 beinhalten oder mit dieser gekoppelt sein, die durch einen oder mehrere Beschleuniger mit künstlicher Intelligenz (KI), einen neuronalen Rechen-Stick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, eine Anordnung aus xPUs/DPUs/IPU/NPUs, ein oder mehrere SoCs, eine oder mehreren CPUs, einen oder mehreren Digitalsignalprozessoren, dedizierte ASICs oder andere Formen spezialisierter Prozessoren oder Schaltungsanordnungen umgesetzt sein, die zum Erfüllen einer oder mehrerer spezialisierter Aufgaben ausgelegt sind. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzdatenverarbeitung, Objektdetektion, Regelanalyse oder dergleichen beinhalten. Zu diesen Aufgaben können auch die an anderer Stelle in diesem Dokument besprochenen spezifischen Edge-Rechenaufgaben für Dienstverwaltung und Dienstoperationen gehören.
Das Interconnect 1456 kann den Prozessor 1452 mit einem Sensorhub oder einer externen Schnittstelle 1470 koppeln, die verwendet wird, um zusätzliche Vorrichtungen oder Untersysteme zu verbinden. Die Vorrichtungen können Sensoren 1472, wie etwa Beschleunigungsmesser, Pegelsensoren, Strömungssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Navigationssystems (z. B. GPS), Drucksensoren, barometrische Drucksensoren und dergleichen beinhalten. Der Hub oder die Schnittstelle 1470 kann ferner verwendet werden, um die Rechenvorrichtung 1450 mit Aktoren 1474, wie etwa Leistungsschaltern, Ventilaktoren, einem akustischen Tongenerator, einer visuellen Warnvorrichtung und dergleichen, zu verbinden.
Bei manchen optionalen Beispielen können verschiedene Eingabe/Ausgabe(E/A)-Vorrichtungen innerhalb der Rechenvorrichtung 1450 vorhanden oder mit dieser verbunden sein. Zum Beispiel kann eine Anzeige oder eine anderen Ausgabevorrichtung 1484 enthalten sein, um Informationen anzuzeigen, wie etwa Sensormesswerte oder Aktorposition. Eine Eingabevorrichtung 1486, wie beispielsweise ein Touchscreen oder eine Tastenfeld, kann enthalten sein, um Eingaben anzunehmen. Eine Ausgabevorrichtung 1484 kann eine beliebige Anzahl von Formen einer akustischen oder visuellen Anzeige beinhalten, einschließlich einfacher visueller Ausgaben, wie etwa binärer Statusindikatoren (z. B. Leuchtdioden (LEDs)) und visueller Mehrzeichenausgaben, oder komplexere Ausgaben, wie etwa Anzeigebildschirme (z. B. Flüssigkristallanzeige(LCD)-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb der Rechenvorrichtung 1450 generiert oder erzeugt wird. Eine Anzeige- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um eine Ausgabe bereitzustellen und eine Eingabe eines Edge-Rechensystems zu empfangen; Komponenten oder Dienste eines Edge-Rechensystems zu verwalten; einen Zustand einer Edge-Rechenkomponente oder eines Edge-Rechendienstes zu identifizieren; oder eine beliebige andere Anzahl von Verwaltungs- oder Administrationsfunktionen oder Dienstverwendungsfällen durchzuführen.
Eine Batterie 1476 kann die Rechenvorrichtung 1450 mit Leistung versorgen, obwohl sie in Beispielen, in denen die Rechenvorrichtung 1450 an einem festen Ort montiert ist, eine Leistungsversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie kann als ein Backup oder für temporäre Fähigkeiten verwendet werden. Die Batterie 1476 kann eine Lithium-Ionen-Batterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
Ein Batterieüberwachungsgerät/-ladegerät 1478 kann in der Rechenvorrichtung 1450 enthalten sein, um den Ladezustand (SoCh) der Batterie 1476, falls enthalten, zu verfolgen. Das Batterieüberwachungsgerät/-ladegerät 1478 kann verwendet werden, um andere Parameter der Batterie 1476 zu überwachen, um Ausfallvorhersagen bereitzustellen, wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SoF) der Batterie 1476. Das Batterieüberwachungsgerät/-ladegerät 1478 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor aus Phoenix, Arizona, USA, oder einen IC der UCD90xxx-Familie von Texas Instruments aus Dallas, TX, USA. Das Batterieüberwachungsgerät/-ladegerät 1478 kann die Informationen über die Batterie 1476 über das Interconnect 1456 an den Prozessor 1452 kommunizieren. Das Batterieüberwachungsgerät/-ladegerät 1478 kann auch einen Analog-Digital(ADC)-Wandler beinhalten, der es dem Prozessor 1452 ermöglicht, die Spannung der Batterie 1476 oder den Stromfluss von der Batterie 1476 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Handlungen zu bestimmen, die die Rechenvorrichtung 1450 durchführen kann, wie etwa Übertragungsfrequenz, Mesh-Netzbetrieb, Erfassungsfrequenz und dergleichen.
Ein Leistungsblock 1480 oder eine andere Leistungsversorgung, die an ein Stromnetz gekoppelt ist, kann mit dem Batterieüberwachungsgerät/-ladegerät 1478 gekoppelt werden, um die Batterie 1476 zu laden. Bei manchen Beispielen kann der Leistungsblock 1480 durch einen Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel durch eine Schleifenantenne in der Rechenvorrichtung 1450, zu erhalten. Eine Drahtlosbatterieladeschaltung, wie unter anderem ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, USA, kann in dem Batterieüberwachungsgerät/-ladegerät 1478 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 1476 und somit dem erforderlichen Strom ausgewählt werden. Das Aufladen kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Airfuel-Standard, dem vom Wireless Power Consortium veröffentlichten Qi-Ladestandard oder dem von der Alliance for Wireless Power veröffentlichten Rezence-Ladestandard durchgeführt werden.
Die Speicherung 1458 kann Anweisungen 1482 in Form von Software-, Firmware- oder Hardwarebefehlen enthalten, um die hierin beschriebenen Techniken zu implementieren. Obwohl solche Anweisungen 1482 als Codeblöcke gezeigt sind, die in dem Speicher 1454 und der Speicherung 1458 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC: Application Specific Integrated Circuit) eingebaut sind.
In einem Beispiel können die Anweisungen 1482, die über den Speicher 1454, die Speicherung 1458 oder den Prozessor 1452 bereitgestellt werden, als ein nichttransitorisches maschinenlesbares Medium 1460 umgesetzt sein, das Code beinhaltet, um den Prozessor 1452 anzuweisen, elektronische Operationen in der Rechenvorrichtung 1450 durchzuführen. Der Prozessor 1452 kann über das Interconnect 1456 auf das nichttransitorische, maschinenlesbare Medium 1460 zugreifen. Zum Beispiel kann das nichttransitorische, maschinenlesbare Medium 1460 durch für die Speicherung 1458 beschriebene Vorrichtungen ausgeführt werden oder kann spezielle Speicherungseinheiten, wie optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwarevorrichtungen, beinhalten. Das nichttransitorische, maschinenlesbare Medium 1460 kann Anweisungen beinhalten, um den Prozessor 1452 anzuweisen, eine spezifische Sequenz oder einen spezifischen Ablauf von Handlungen durchzuführen, wie zum Beispiel mit Bezug auf das Flussdiagramm bzw. die Flussdiagramme und das Blockdiagramm bzw. die Blockdiagramme von Operationen und Funktionalität, die vorstehend dargestellt sind, beschrieben. Wie hierin verwendet, sind die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ austauschbar.
Auch in einem spezifischen Beispiel können die Anweisungen 1482 auf dem Prozessor 1452 (separat oder in Kombination mit den Anweisungen 1482 des maschinenlesbaren Mediums 1460) die Ausführung oder Operation einer vertrauenswürdigen Ausführungsumgebung (TEE) 1490 konfigurieren. In einem Beispiel arbeitet die TEE 1490 als ein geschützter Bereich, der für den Prozessor 1452 zur sicheren Ausführung von Anweisungen und zum sicheren Zugriff auf Daten zugänglich ist. Verschiedene Implementierungen der TEE 1490 und eines begleitenden sicheren Bereichs in dem Prozessor 1452 oder dem Speicher 1454 können beispielsweise durch Verwendung von Intel® Software Guard Extensions (SGX) oder ARM® TrustZone® Hardwaresicherheitserweiterungen, Intel® Management Engine (ME) oder Intel® Converged Security Manageability Engine (CSME) bereitgestellt werden. Andere Aspekte von Sicherheitsverhärtung, Hardware-Rootsof-Trust und vertrauenswürdigen oder geschützten Operationen können in der Vorrichtung 1450 durch die TEE 1490 und den Prozessor 1452 implementiert werden. Wie oben in Verbindung mit 8 beschrieben, kann die TEE 1490 Datenschutz-sensitive Telemetriedaten (z. B. KI-Inferenz über Telemetriedaten) verarbeiten. In solchen Beispielen kann die TEE 1490 gewährleisten, dass die verschiedenen Interessen (z. B. Bedingungen) als eine Bedingung der Annahme und/oder Offenbarung der Telemetriedaten erfüllt sind.
In weiteren Beispielen beinhaltet ein maschinenlesbares Medium auch irgendein greifbares Medium, das zum Speichern, Codieren oder Führen von Anweisungen zur Ausführung durch eine Maschine imstande ist und das bewirkt, dass die Maschine beliebige einer oder mehrerer der Methodologien der vorliegenden Offenbarung durchführt, oder das zum Speichern, Codieren oder Führen von Datenstrukturen imstande ist, die von solchen Anweisungen genutzt werden oder damit assoziiert sind. Ein „maschinenlesbares Medium“ kann somit Solid-State-Speicher und optische und magnetische Medien umfassen, ist jedoch nicht darauf beschränkt. Zu spezifischen Beispielen für maschinenlesbare Medien zählen nichtflüchtiger Speicher, wie zum Beispiel Halbleiterspeichervorrichtungen (z. B. elektrisch programmierbarer Nurlesespeicher (Electrically Programmable Read-Only Memory, EPROM), elektrisch löschbarer programmierbarer Nurlesespeicher (Electrically Erasable Programmable Read-Only Memory, EEPROM)) und Flash-Speichervorrichtungen, Magnetplatten, wie zum Beispiel interne Festplatten und austauschbare Speicherplatten, magnetooptische Speicherplatten und CD-ROM- und DVD-ROM-Speicherplatten. Die Anweisungen, die durch ein maschinenlesbares Medium umgesetzt sind, können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z. B. Hypertext Transfer Protocol (HTTP)) nutzt.
Ein maschinenlesbares Medium kann durch eine Speicherungsvorrichtung oder eine andere Einrichtung bereitgestellt werden, die dazu in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. Bei einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderweitig bereitgestellte Informationen die Anweisungen repräsentieren, wie etwa die Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können. Dieses Format, aus dem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (z. B. in komprimierter oder verschlüsselter Form), verpackte Anweisungen (z. B. in mehrere Pakete aufgeteilt) oder dergleichen beinhalten. Die die Anweisungen repräsentierenden Informationen im maschinenlesbaren Medium können durch eine Verarbeitungsschaltungsanordnung in die Anweisungen zum Implementieren beliebige der hierin besprochenen Operationen verarbeitet werden. Das Ableiten der Anweisungen aus den Informationen (z. B. Verarbeitung durch die Verarbeitungsschaltungsanordnung) kann beispielsweise beinhalten: Kompilieren (z. B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z. B. dynamisches oder statisches Verknüpfen), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitig Manipulieren der Informationen in die Anweisungen.
Bei einem Beispiel kann die Ableitung der Anweisungen Zusammenstellung, Kompilierung oder Interpretation der Informationen (z. B. durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus einem Zwischenformat oder vorverarbeiteten Format, das durch das maschinenlesbare Medium bereitgestellt wird, zu erzeugen. Wenn die Informationen in mehreren Teilen bereitgestellt werden, können sie kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Die Informationen können sich zum Beispiel in mehreren komprimierten Quellcodepaketen (oder Objektcode oder ausführbarer Binär-Code usw.) auf einem oder mehreren Fernservern befinden. Die Quellcodepakete können verschlüsselt sein, wenn sie über ein Netzwerk übertragen werden, und können an einer lokalen Maschine falls notwendig entschlüsselt, dekomprimiert, zusammengesetzt (z. B. verknüpft) und kompiliert oder interpretiert (z. B. in eine Bibliothek, selbständige ausführbare Datei usw.) werden und durch die lokale Maschine ausgeführt werden.
Die maschinenausführbaren Anweisungen 1100, 1200, 1300 (1482) der 11-13 können in dem Speicher 1554, der Speicherung 1558 und/oder auf einem entfernbaren nichttransitorischen computerlesbaren Speicherungsmedium, wie etwa einer CD oder DVD, gespeichert sein.
In einem ausführlicheren Beispiel veranschaulicht 15 ein Blockdiagramm einer beispielhaften Rechenvorrichtung 1550, die dazu strukturiert ist, die Anweisungen von 13 auszuführen, um die hierin beschriebenen Techniken (z. B. Operationen, Prozesse, Verfahren und Methoden), wie etwa den Broker 704 der 7 und/oder 10, zu implementieren. Diese Rechenvorrichtung 1550 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 1500 bereit, wenn sie als eine oder als Teil einer Rechenvorrichtung (z. B. als eine Mobilvorrichtung, eine Basisstation, ein Server, ein Gateway usw.) implementiert wird. Die Rechenvorrichtung 1550 kann beliebige Kombinationen der Hardware- oder Logikkomponenten beinhalten, die hierin referenziert sind, und sie kann eine beliebige Vorrichtung beinhalten oder mit dieser gekoppelt sein, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination solcher Netzwerke verwendbar ist. Die Komponenten können als integrierte Schaltungen (ICs: Integrated Circuits), Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Anweisungssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die in der Rechenvorrichtung 1550 angepasst sind, oder als Komponenten, die anderweitig in einem Gestell eines größeren Systems integriert sind, implementiert werden. Zum Beispiel kann die Rechenvorrichtung 1550 beispielsweise ein Server, ein Personal Computer, eine Workstation, eine selbstlernende Maschine (z. B. ein neuronales Netzwerk), eine Mobilvorrichtung (z. B. ein Mobiltelefon, ein Smartphone, ein Tablet wie etwa ein iPadTM), ein Personal Digital Assistant (PDA), ein Internet-Gerät, ein DVD-Abspielgerät, ein CD-Abspielgerät, ein digitaler Videorekorder, ein Blue-Ray-Abspielgerät, eine Spielekonsole, ein persönlicher Videorekorder, eine Set-Top-Box, ein Headset oder eine andere tragbare Vorrichtung, eine Internet-der-Dinge(IoT)-Vorrichtung oder eine beliebige andere Art von Rechenvorrichtung sein.
Die Edge-Rechenvorrichtung 1550 kann eine Verarbeitungsschaltungsanordnung in der Form eines Prozessors 1552 beinhalten, der ein Mikroprozessor, ein Mehrkernprozessor, ein Multithread-Prozessor, ein Ultraniederspannungsprozessor, ein eingebetteter Prozessor, eine xPU/DPU/IPU/NPU, eine Spezialverarbeitungseinheit, eine spezialisierte Verarbeitungseinheit oder andere bekannte Verarbeitungselemente sein kann. Der Prozessor 1552 kann ein Teil eines System-on-Chip (SoC) sein, in dem der Prozessor 1552 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Package ausgebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen von Intel Corporation, Santa Clara, Kalifornien, USA. Als ein Beispiel kann der Prozessor 1552 einen auf Intel® Architecture Core™ basierenden CPU-Prozessor, wie etwa einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i14-, einen i9- oder einen MCU-Klasse-Prozessor oder einen anderen solchen Prozessor, der von Intel® verfügbar ist, beinhalten. Eine beliebige Anzahl anderer Prozessoren kann jedoch verwendet werden, wie etwa erhältlich von der Firma Advanced Micro Devices, Inc. (AMD®) aus Sunnyvale, Kalifornien, USA, ein MIPS®-basiertes Design der Firma MIPS Technologies, Inc. aus Sunnyvale, Kalifornien, USA, ein ARM®-basiertes Design, lizenziert von ARM Holdings, Ltd. oder ein Kunde davon, oder deren Lizenznehmer oder Adopter. Die Prozessoren können Einheiten beinhalten, wie etwa einen A5-A13-Prozessor von Apple® Inc., einen Snapdragon™-Prozessor von Qualcommon® Technologies, Inc., oder einen OMAP™-Prozessor von Texas Instruments, Inc. Der Prozessor 1552 und begleitende Schaltungsanordnungen können in einem Einzel-Socket-Formfaktor, Multi-Socket-Formfaktor oder einer Vielfalt anderer Formate bereitgestellt sein, einschließlich in beschränkten Hardwarekonfigurationen oder Konfigurationen, die weniger als alle in 15 gezeigten Elemente beinhaltet. In diesem Beispiel implementiert der Prozessor die Netzwerkschnittstelle 1000, den Dienstanforderungsanalysator 1002 und den Ressourcenkomparator 1004 von 10A.
Der Prozessor 1552 kann über ein Interconnect 1556 (z. B. einen Bus) mit einem Systemspeicher 1554 kommunizieren. Eine beliebige Anzahl an Speichervorrichtungen kann verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Als Beispiele kann der Speicher 1554 Direktzugriffsspeicher (RAM) gemäß einem JEDEC-Design (JEDEC: Joint Electron Devices Engineering Council) sein, wie etwa den DDR- oder mobilen DDR-Standards (z. B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4). In bestimmten Beispielen kann eine Speicherkomponente einem von JEDEC vertriebenen DRAM-Standard entsprechen, wie etwa JESD149F für DDR-SDRAM, JESD149-2F für DDR2-SDRAM, JESD149-3F für DDR3-SDRAM, JESD149-4A für DDR4-SDRAM, JESD209 für Low-Power-DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Solche Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden und Kommunikationsschnittstellen der Speicherungsvorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. Bei diversen Implementierungen können die einzelnen Speichervorrichtungen von einer beliebigen Anzahl von verschiedenen Package-Typen sein, wie etwa Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q114P). Diese Vorrichtungen können bei manchen Beispielen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Vorrichtungen bei anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die der Reihe nach durch einen gegebenen Verbinder mit der Hauptplatine gekoppelt sind. Eine beliebige Anzahl anderer Speicherimplementierungen kann verwendet werden, wie etwa andere Typen von Speichermodulen, z. B. Dual Inline Memory Modules (DIMMs) verschiedener Varianten, einschließlich unter anderem microDnVIMs oder MiniDnVIMs.
Um eine dauerhafte Speicherung von Informationen, wie etwa Daten, Anwendungen, Betriebssystemen und so weiter, bereitzustellen, kann eine Speicherung 1558 auch über das Interconnect 1556 mit dem Prozessor 1552 gekoppelt sein. Bei einem Beispiel kann der Speicher 1558 über ein Solid-State-Laufwerk (SSDD) implementiert werden. Andere Vorrichtungen, die für die Speicherung 1558 verwendet werden können, beinhalten Flash-Speicherkarten, wie etwa Secure-Digital(SD)-Karten, microSD-Karten, eXtreme-Digital-(XD)-Bildkarten und dergleichen und Universal-Serial-Bus(USB)-Flash-Laufwerke. Bei einem Beispiel kann die Speichervorrichtung Speichervorrichtungen sein oder beinhalten, die Chalkogenidglas, NAND-Flash-Speicher mit mehreren Schwellenpegeln, NOR-Flash-Speicher, Einzel- oder Mehrfachpegel-Phasenwechselspeicher (PCM), einen resistiven Speicher, Nanodrahtspeicher, ferroelektrischen Transistor-Direktzugriffsspeicher (FeTRAM), antiferroelektrischen Speicher, magnetoresistiven Direktzugriffsspeicher (MRAM), Speicher, der Memristortechnologie beinhaltet, resistiven Speicher einschließlich der Metall-Oxid-Basis, der Sauerstoffleerstellenbasis und den Leitfähige-Brücke-Direktzugriffsspeicher (CB-RAM) oder Spin-Transfer-Torque(STT)-MRAM, einer auf spintronischen Magnetübergangsspeicher basierte Vorrichtung, eine Magnettunnelübergang(MTJ)-basierte Vorrichtung, eine DW(Domänenwand)- und SOT(Spin-Orbit-Transfer)-basierte Vorrichtung, eine thyristorbasierte Speichervorrichtung oder eine Kombination von beliebigen der obigen oder eines anderen Speichers verwenden.
In Niederleistungsimplementierungen kann die Speicherung 1558 ein On-Die-Speicher oder Register sein, die mit dem Prozessor 1552 assoziiert sind. Bei manchen Beispielen kann die Speicherung 1558 jedoch unter Verwendung eines Mikro-Festplattenlaufwerks (HDD) implementiert werden. Ferner kann eine beliebige Anzahl neuer Technologien für die Speicherung 1558 zusätzlich zu den, oder anstelle der, beschriebenen Technologien verwendet werden, wie etwa unter anderem Widerstandswechselspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher.
Die Komponenten können über das Interconnect 1556 kommunizieren. Das Interconnect 1556 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich Industry Standard Architecture (ISA), extended ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe) oder eine beliebige Anzahl anderer Technologien. Das Interconnect 1556 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird. Andere Bussysteme können enthalten sein, wie etwa unter anderem eine Inter-Integrated-Circuit(I2C)-Schnittstelle, eine Serial-Peripheral-Interface(SPI)-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
Das Interconnect 1556 kann den Prozessor 1552 mit einem Sendeempfänger 1566 koppeln, um mit den verbundenen Edge-Vorrichtungen 1562 zu kommunizieren. Der Sendeempfänger 1566 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie z. B. 2,4-Gigahertz (GHz)-Übertragungen nach dem IEEE-802.15.4-Standard, unter Verwendung des Bluetooth®-Low-Energy(BLE)-Standards, wie von der Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards unter anderem. Eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, kann für die Verbindungen zu den verbundenen Edge-Vorrichtungen 1562 verwendet werden. Zum Beispiel kann eine WLAN-Einheit (WLAN: Wireless Local Area Network - drahtloses Lokalnetzwerk) verwendet werden, um WiFi® -Kommunikationen gemäß dem IEEE (Institute of Electrical and Electronics Engineers) 802.11-Standard zu implementieren. Außerdem können Drahtlos-Weitbereichskommunikationen, z. B. gemäß einem zellularen oder anderen Drahtlos-Weitbereichsprotokoll über eine Drahtlos-Weitbereichsnetzwerk(WWAN)-Einheit stattfinden.
Der Drahtlosnetzsendeempfänger 1566 (oder mehrere Sendeempfänger) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen in einer anderen Reichweite kommunizieren. Zum Beispiel kann die Rechenvorrichtung 1550 mit nahen Vorrichtungen, z. B. innerhalb von etwa 10 Metern, unter Verwendung eines lokalen Sendeempfängers basierend auf Bluetooth Low Energy (BLE) oder einem anderen Niedrigleistungsfunkgerät kommunizieren, um Leistung zu sparen. Entferntere verbundene Edge-Vorrichtungen 1562, z. B. innerhalb von etwa 50 Metern, können über ZigBee® oder andere Zwischenleistungsfunkgeräte erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät mit unterschiedlichen Leistungspegeln stattfinden oder können über separate Sendeempfänger stattfinden, zum Beispiel einen lokalen Sendeempfänger, der BLE verwendet, und einen separaten Mesh-Sendeempfänger, der ZigBee® verwendet.
Ein Drahtlosnetzsendeempfänger 1566 (z. B. ein Funksendeempfänger) kann enthalten sein, um mit Vorrichtungen oder Diensten in der Edge-Cloud 1595 über Lokal- oder Weitbereichsnetzwerkprotokolle zu kommunizieren. Der Drahtlossendeempfänger 1566 kann ein LPWA-Sendeempfänger (LPWA: Low Power Wide Area) sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Die Rechenvorrichtung 1550 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network - Langstrecken-Weitbereichsnetzwerk), das von Semtech und der LoRa Alliance entwickelt wird, kommunizieren. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl von anderen Cloud-Sendeempfängern verwendet werden, die Kommunikationen mit großer Reichweite und niedriger Bandbreite implementieren, wie etwa Sigfox, und andere Technologien. Ferner können andere Kommunikationstechniken, wie beispielsweise Kanalspringen mit Zeitschlitzen, das in der Spezifikation IEEE 802.15.4e beschrieben ist, verwendet werden.
Eine beliebige Anzahl anderer Funkkommunikationen und Protokolle kann zusätzlich zu den Systemen verwendet werden, die für den Drahtlosnetzsendeempfänger 1566 erwähnt wurden, wie hierin beschrieben. Zum Beispiel kann der Sendeempfänger 1566 einen zellularen Sendeempfänger umfassen, der Spreizspektrum(SPA/SAS)-Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa WiFi®-Netze für Kommunikationen mittlerer Geschwindigkeit und Bereitstellung von Netzkommunikationen. Der Sendeempfänger 1566 kann Funkgeräte umfassen, die mit einer beliebigen Anzahl von 3GPP(Third Generation Partnership Project)-Spezifikationen kompatibel sind, wie etwa Long Term Evolution (LTE) und Kommunikationssysteme der fünften Generation (5G), die am Ende der vorliegenden Offenbarung ausführlicher erörtert werden. Eine Netzwerkschnittstellensteuerung (NIC) 1568 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 1595 oder zu anderen Vorrichtungen, wie etwa den verbundenen Edge-Vorrichtungen 1562 (die z. B. in einem Mesh arbeiten), bereitzustellen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET unter vielen anderen. Eine zusätzliche NIC 1568 kann enthalten sein, um eine Verbindung mit einem zweiten Netzwerk zu ermöglichen, beispielsweise eine erste NIC 1568, die Kommunikationen zu der Cloud über Ethernet bereitstellt, und eine zweite NIC 1568, die Kommunikationen zu anderen Vorrichtungen über einen anderen Netzwerktyp bereitstellt.
Angesichts der Vielfalt von Arten anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netz kann zutreffende Kommunikationsschaltungsanordnung, die von der Vorrichtung verwendet wird, eine oder mehrere der Komponenten 1564, 1566, 1568 oder 1570 beinhalten oder durch diese verkörpert sein. Dementsprechend können bei verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z. B. Empfangen, Senden usw.) durch eine solche Kommunikationsschaltungsanordnung verkörpert werden.
Die Rechenvorrichtung 1550 kann eine Beschleunigungsschaltungsanordnung 1564 beinhalten oder mit dieser gekoppelt sein, die durch einen oder mehrere Beschleuniger mit künstlicher Intelligenz (KI), einen neuronalen Rechen-Stick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, eine Anordnung aus xPUs/DPUs/IPU/NPUs, ein oder mehrere SoCs, eine oder mehreren CPUs, einen oder mehreren Digitalsignalprozessoren, dedizierte ASICs oder andere Formen spezialisierter Prozessoren oder Schaltungsanordnungen umgesetzt sein, die zum Erfüllen einer oder mehrerer spezialisierter Aufgaben ausgelegt sind. Diese Aufgaben können KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzdatenverarbeitung, Objektdetektion, Regelanalyse oder dergleichen beinhalten. Zu diesen Aufgaben können auch die an anderer Stelle in diesem Dokument besprochenen spezifischen Edge-Rechenaufgaben für Dienstverwaltung und Dienstoperationen gehören.
Das Interconnect 1556 kann den Prozessor 1552 mit einem Sensorhub oder einer externen Schnittstelle 1570 koppeln, die verwendet wird, um zusätzliche Vorrichtungen oder Untersysteme zu verbinden. Die Vorrichtungen können Sensoren 1572, wie etwa Beschleunigungsmesser, Pegelsensoren, Strömungssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Navigationssystems (z. B. GPS), Drucksensoren, barometrische Drucksensoren und dergleichen beinhalten. Der Hub oder die Schnittstelle 1570 kann ferner verwendet werden, um die Rechenvorrichtung 1550 mit Aktoren 1574, wie etwa Leistungsschaltern, Ventilaktoren, einem akustischen Tongenerator, einer visuellen Warnvorrichtung und dergleichen, zu verbinden.
Bei manchen optionalen Beispielen können verschiedene Eingabe/Ausgabe(E/A)-Vorrichtungen innerhalb der Rechenvorrichtung 1550 vorhanden oder mit dieser verbunden sein. Zum Beispiel kann eine Anzeige oder eine anderen Ausgabevorrichtung 1584 enthalten sein, um Informationen anzuzeigen, wie etwa Sensormesswerte oder Aktorposition. Eine Eingabevorrichtung 1586, wie beispielsweise ein Touchscreen oder eine Tastenfeld, kann enthalten sein, um Eingaben anzunehmen. Eine Ausgabevorrichtung 1584 kann eine beliebige Anzahl von Formen einer akustischen oder visuellen Anzeige beinhalten, einschließlich einfacher visueller Ausgaben, wie etwa binärer Statusindikatoren (z. B. Leuchtdioden (LEDs)) und visueller Mehrzeichenausgaben, oder komplexere Ausgaben, wie etwa Anzeigebildschirme (z. B. Flüssigkristallanzeige(LCD)-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb der Rechenvorrichtung 1550 generiert oder erzeugt wird. Eine Anzeige- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um eine Ausgabe bereitzustellen und eine Eingabe eines Edge-Rechensystems zu empfangen; Komponenten oder Dienste eines Edge-Rechensystems zu verwalten; einen Zustand einer Edge-Rechenkomponente oder eines Edge-Rechendienstes zu identifizieren; oder eine beliebige andere Anzahl von Verwaltungs- oder Administrationsfunktionen oder Dienstnutzungsfällen durchzuführen.
Eine Batterie 1576 kann die Rechenvorrichtung 1550 mit Leistung versorgen, obwohl sie in Beispielen, in denen die Rechenvorrichtung 1550 an einem festen Ort montiert ist, eine Leistungsversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie als ein Backup oder für temporäre Fähigkeiten verwendet werden kann. Die Batterie 1576 kann eine Lithiumionenbatterie oder eine Metall-Luft-Batterie, wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen, sein.
Ein Batterieüberwachungsgerät/-ladegerät 1578 kann in der Rechenvorrichtung 1550 enthalten sein, um den Ladezustand (SoCh) der Batterie 1576, falls enthalten, zu verfolgen. Das Batterieüberwachungsgerät/-ladegerät 1578 kann verwendet werden, um andere Parameter der Batterie 1576 zu überwachen, um Ausfallvorhersagen bereitzustellen, wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SoF) der Batterie 1576. Das Batterieüberwachungsgerät/-ladegerät 1578 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor aus Phoenix, Arizona, USA, oder einen IC der UCD90xxx-Familie von Texas Instruments aus Dallas, TX, USA. Das Batterieüberwachungsgerät/-ladegerät 1578 kann die Informationen über die Batterie 1576 über das Interconnect 1556 an den Prozessor 1552 kommunizieren. Das Batterieüberwachungsgerät/-ladegerät 1578 kann auch einen Analog-Digital(ADC)-Wandler beinhalten, der es dem Prozessor 1552 ermöglicht, die Spannung der Batterie 1576 oder den Stromfluss von der Batterie 1576 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Handlungen zu bestimmen, die die Rechenvorrichtung 1550 durchrühren kann, wie etwa Übertragungsfrequenz, Mesh-Netzbetrieb, Erfassungsfrequenz und dergleichen.
Ein Leistungsblock 1580 oder eine andere Leistungsversorgung, die an ein Stromnetz gekoppelt ist, kann mit dem Batterieüberwachungsgerät/-ladegerät 1578 gekoppelt werden, um die Batterie 1576 zu laden. Bei manchen Beispielen kann der Leistungsblock 1580 durch einen Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel durch eine Schleifenantenne in der Rechenvorrichtung 1550, zu erhalten. Eine Drahtlosbatterieladeschaltung, wie unter anderem ein LTC4020-Chip von Linear Technologies aus Milpitas, Kalifornien, USA, kann in dem Batterieüberwachungsgerät/-ladegerät 1578 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 1576 und somit dem erforderlichen Strom ausgewählt werden. Das Aufladen kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Airfuel-Standard, dem vom Wireless Power Consortium veröffentlichten Qi-Ladestandard oder dem von der Alliance for Wireless Power veröffentlichten Rezence-Ladestandard durchgeführt werden.
Die Speicherung 1558 kann Anweisungen 1582 in Form von Software-, Firmware- oder Hardwarebefehlen enthalten, um die hierin beschriebenen Techniken zu implementieren. Obwohl solche Anweisungen 1582 als Codeblöcke gezeigt sind, die in dem Speicher 1554 und der Speicherung 1558 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC: Application Specific Integrated Circuit) eingebaut sind.
In einem Beispiel können die Anweisungen 1582, die über den Speicher 1554, die Speicherung 1558 oder den Prozessor 1552 bereitgestellt werden, als ein nichttransitorisches maschinenlesbares Medium 1560 umgesetzt sein, das Code beinhaltet, um den Prozessor 1552 anzuweisen, elektronische Operationen in der Rechenvorrichtung 1550 durchzuführen. Der Prozessor 1552 kann über das Interconnect 1556 auf das nichttransitorische, maschinenlesbare Medium 1560 zugreifen. Zum Beispiel kann das nichttransitorische, maschinenlesbare Medium 1560 durch für die Speicherung 1558 beschriebene Vorrichtungen ausgeführt werden oder kann spezielle Speicherungseinheiten, wie optische Platten, Flash-Laufwerke oder eine beliebige Anzahl anderer Hardwarevorrichtungen, beinhalten. Das nichttransitorische, maschinenlesbare Medium 1560 kann Anweisungen beinhalten, um den Prozessor 1552 anzuweisen, eine spezifische Sequenz oder einen spezifischen Ablauf von Handlungen durchzuführen, wie zum Beispiel mit Bezug auf das Flussdiagramm bzw. die Flussdiagramme und das Blockdiagramm bzw. die Blockdiagramme von Operationen und Funktionalität, die vorstehend dargestellt sind, beschrieben. Wie hierin verwendet, sind die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ austauschbar.
Auch in einem spezifischen Beispiel können die Anweisungen 1582 auf dem Prozessor 1552 (separat oder in Kombination mit den Anweisungen 1582 des maschinenlesbaren Mediums 1560) die Ausführung oder Operation einer vertrauenswürdigen Ausführungsumgebung (TEE) 1590 konfigurieren. In einem Beispiel arbeitet die TEE 1590 als ein geschützter Bereich, der für den Prozessor 1552 zur sicheren Ausführung von Anweisungen und zum sicheren Zugriff auf Daten zugänglich ist. Verschiedene Implementierungen der TEE 1590 und eines begleitenden sicheren Bereichs in dem Prozessor 1552 oder dem Speicher 1554 können beispielsweise durch Verwendung von Intel® Software Guard Extensions (SGX) oder ARM® TrustZone® Hardwaresicherheitserweiterungen, Intel® Management Engine (ME) oder Intel® Converged Security Manageability Engine (CSME) bereitgestellt werden. Andere Aspekte von Sicherheitsverhärtung, Hardware-Rootsof-Trust und vertrauenswürdigen oder geschützten Operationen können in der Vorrichtung 1550 durch die TEE 1590 und den Prozessor 1552 implementiert werden.
In weiteren Beispielen beinhaltet ein maschinenlesbares Medium auch irgendein greifbares Medium, das zum Speichern, Codieren oder Führen von Anweisungen zur Ausführung durch eine Maschine imstande ist und das bewirkt, dass die Maschine beliebige einer oder mehrerer der Methodologien der vorliegenden Offenbarung durchführt, oder das zum Speichern, Codieren oder Führen von Datenstrukturen imstande ist, die von solchen Anweisungen genutzt werden oder damit assoziiert sind. Ein „maschinenlesbares Medium“ kann somit Solid-State-Speicher und optische und magnetische Medien umfassen, ist jedoch nicht darauf beschränkt. Zu spezifischen Beispielen für maschinenlesbare Medien zählen nichtflüchtiger Speicher, wie zum Beispiel Halbleiterspeichereinrichtungen (z. B. elektrisch programmierbarer Nur-Lese-Speicher (Electrically Programmable Read-Only Memory, EPROM), elektrisch löschbarer programmierbarer Nur-Lese-Speicher (Electrically Erasable Programmable Read-Only Memory, EEPROM)) und Flash-Speichereinrichtungen, Magnetplatten, wie zum Beispiel interne Festplatten und austauschbare Speicherplatten, magnetooptische Speicherplatten und CD-ROM- und DVD-ROM-Speicherplatten. Die Anweisungen, die durch ein maschinenlesbares Medium umgesetzt sind, können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über eine Netzwerkschnittstellenvorrichtung übertragen oder empfangen werden, die ein beliebiges einer Anzahl von Übertragungsprotokollen (z. B. Hypertext Transfer Protocol (HTTP)) nutzt.
Ein maschinenlesbares Medium kann durch eine Speicherungsvorrichtung oder eine andere Einrichtung bereitgestellt werden, die dazu in der Lage ist, Daten in einem nichtflüchtigen Format zu hosten. Bei einem Beispiel können auf einem maschinenlesbaren Medium gespeicherte oder anderweitig bereitgestellte Informationen die Anweisungen repräsentieren, wie etwa die Anweisungen selbst oder ein Format, aus dem die Anweisungen abgeleitet werden können. Dieses Format, aus dem die Anweisungen abgeleitet werden können, kann Quellcode, codierte Anweisungen (z. B. in komprimierter oder verschlüsselter Form), verpackte Anweisungen (z. B. in mehrere Pakete aufgeteilt) oder dergleichen beinhalten. Die die Anweisungen repräsentierenden Informationen im maschinenlesbaren Medium können durch eine Verarbeitungsschaltungsanordnung in die Anweisungen zum Implementieren beliebige der hierin besprochenen Operationen verarbeitet werden. Das Ableiten der Anweisungen aus den Informationen (z. B. Verarbeitung durch die Verarbeitungsschaltungsanordnung) kann beispielsweise beinhalten: Kompilieren (z. B. aus Quellcode, Objektcode usw.), Interpretieren, Laden, Organisieren (z. B. dynamisches oder statisches Verknüpfen), Codieren, Decodieren, Verschlüsseln, Entschlüsseln, Verpacken, Entpacken oder anderweitig Manipulieren der Informationen in die Anweisungen.
Bei einem Beispiel kann die Ableitung der Anweisungen Zusammenstellung, Kompilierung oder Interpretation der Informationen (z. B. durch die Verarbeitungsschaltungsanordnung) beinhalten, um die Anweisungen aus einem Zwischenformat oder vorverarbeiteten Format, das durch das maschinenlesbare Medium bereitgestellt wird, zu erzeugen. Wenn die Informationen in mehreren Teilen bereitgestellt werden, können sie kombiniert, entpackt und modifiziert werden, um die Anweisungen zu erzeugen. Die Informationen können sich zum Beispiel in mehreren komprimierten Quellcodepaketen (oder Objektcode oder ausführbarer Binär-Code usw.) auf einem oder mehreren Fernservern befinden. Die Quellcodepakete können verschlüsselt sein, wenn sie über ein Netzwerk übertragen werden, und können an einer lokalen Maschine falls notwendig entschlüsselt, dekomprimiert, zusammengesetzt (z. B. verknüpft) und kompiliert oder interpretiert (z. B. in eine Bibliothek, selbständige ausführbare Datei usw.) werden und durch die lokale Maschine ausgeführt werden.
Die maschinenausführbaren Anweisungen 1300 (1482) von 13 können in dem Speicher 1554, der Speicherung 1558 und/oder auf einem entfernbaren nichttransitorischen computerlesbaren Speichermedium, wie etwa einer CD oder DVD, gespeichert sein.
Aus dem Vorstehenden versteht es sich, dass beispielhafte Verfahren, Einrichtungen und Herstellungsartikel hierin offenbart wurden, um Dienstgüte in Bezug auf Service-Level-Agreements in einer Rechenvorrichtung zu verwalten. Offenbarte Verfahren, Einrichtungen und Herstellungsartikel verbessern die Effizienz eines Computers, indem Anwendungen plattformagnostisch sein können. Auf diese Weise muss eine Anwendung keinen plattformspezifischen (z. B. OS- oder Hardware-spezifischen) Code beinhalten, wodurch die Größe und Komplexität von Anwendungen reduziert wird. Dementsprechend werden weniger Ressourcen benötigt, um Anwendungen einzusetzen. Zusätzlich ermöglichen hierin offenbarte Beispiele QoS-Funktionalität, um zu gewährleisten, dass SLA/SLO-Voraussetzungen in Bezug auf gepoolte Ressourcen erfüllt werden. Dementsprechend richten sich offenbarte Verfahren, Einrichtungen und Herstellungsartikel auf eine oder mehrere Verbesserungen der Funktionsweise eines Computers.
Beispielhafte Verfahren, Einrichtungen, Systeme und Herstellungsartikel zum Verwalten von Dienstgüte in Bezug auf Service-Level-Agreements in einer Rechenvorrichtung sind hierin offenbart. Weitere Beispiele und Kombinationen davon beinhalten das Folgende: Beispiel 1 beinhaltet eine Einrichtung (z.B. eine EdgeRechenvorrichtung) zum Ermöglichen eines Service-Level-Agreement, wobei die Einrichtung Folgendes beinhaltet: einen ersten Mesh-Proxy, der einer ersten plattformagnostischen Anwendung zugeordnet ist, wobei der erste Mesh-Proxy ein erstes Ressourcenanforderungssignal basierend auf einer ersten Service-Level-Agreement-Voraussetzung von der ersten plattformagnostischen Anwendung erzeugen soll, einen zweiten Mesh-Proxy, der einer zweiten plattformagnostischen Anwendung zugeordnet ist, wobei der zweite Mesh-Proxy ein zweites Ressourcenanforderungssignal basierend auf einer zweiten Service-Level-Agreement-Voraussetzung von der zweiten plattformagnostischen Anwendung erzeugen soll, und einen Lastausgleicher zum Zuweisen von Hardwareressourcen (z. B. Prozessorressourcen, Speicher, Hardwarebeschleuniger usw.) für die erste plattformagnostische Anwendung und die zweite plattformagnostische Anwendung basierend auf dem ersten Ressourcenanforderungssignal und dem zweiten Ressourcenanforderungssignal.
Beispiel 2 beinhaltet die Einrichtung des Beispiels 1, ferner beinhaltend einen dritten Mesh-Proxy, der einer dritten plattformagnostischen Anwendung zugeordnet ist, einen Hierarchiegenerator zum Erzeugen einer Hierarchie für die erste plattformagnostische Anwendung, die zweite plattformagnostische Anwendung, und die dritte plattformagnostische Anwendung, und den Lastausgleicher, um die Hardwareressourcen für die erste plattformagnostische Anwendung, die zweite plattformagnostische Anwendung und die dritte plattformagnostische Anwendung basierend auf der Hierarchie zuzuweisen.
Beispiel 3 beinhaltet die Einrichtung der Beispiele 1-2, wobei eine erste Gruppe in der Hierarchie eine andere Anzahl von Ressourcen empfängt als eine zweite Gruppe in der Hierarchie.
Beispiel 4 beinhaltet die Einrichtung der Beispiele 1-3, ferner beinhaltend eine Schnittstelle zum Übertragen einer Hardwareressourcenzuweisung, die den zugewiesenen Hardwareressourcen entspricht, zu einem Betriebssystem.
Beispiel 5 beinhaltet die Einrichtung der Beispiele 1-4, wobei der Lastausgleicher die Konformität mit der ersten Service-Level-Agreement-Voraussetzung basierend auf Telemetriedaten bestimmen soll.
Beispiel 6 beinhaltet die Einrichtung des Beispiels 1, wobei der erste Mesh-Proxy die Konformität mit der ersten Service-Level-Agreement-Voraussetzung basierend auf Telemetriedaten bestimmen soll.
Beispiel 7 beinhaltet eine Einrichtung (z. B. eine Edge-Rechenvorrichtung) zum Ermöglichen eines Service-Level-Agreement, wobei die Einrichtung Speicher und eine Prozessorschaltungsanordnung beinhaltet, um eine Service-Level-Voraussetzung einer Dienstanforderung in ressourcenbasierte Attribute zu übersetzen, zu bestimmen, ob gepoolte Ressourcen (z. B. Speicher, Prozessorressourcen, Hardwarebeschleuniger usw.) in der Lage sind, die Dienstanforderung gemäß den ressourcenbasierten Attributen zu versorgen, eine Kapazität der gepoolten Ressourcen zu bestimmen und eine Antwort (z. B. ein Signal, ein Datensignal oder ein Datenpaket) zu übertragen, um die Fähigkeit und die Kapazität der gepoolten Ressourcen anzugeben.
Beispiel 8 beinhaltet die Einrichtung des Beispiels 7, wobei die Prozessorschaltungsanordnung die Dienstanforderung von einem Broker erhalten und die Antwort zu dem Broker übertragen soll.
Beispiel 9 beinhaltet die Einrichtung der Beispiele 7-8, wobei die Prozessorschaltungsanordnung die Service-Level-Voraussetzung der Dienstanforderung in die ressourcenbasierten Attribute übersetzen soll, um Ressourcen zum Erfüllen der Service-Level-Voraussetzung zu bestimmen.
Beispiel 10 beinhaltet die Einrichtung der Beispiele 7-9, wobei die Prozessorschaltungsanordnung eine negative Antwort übertragen soll, um anzugeben, dass die gepoolten Ressourcen nicht in der Lage sind, die Dienstanforderung zu versorgen, wenn die gepoolten Ressourcen nicht in der Lage sind, die Dienstanforderung zu versorgen.
Beispiel 11 beinhaltet die Einrichtung der Beispiele 7-10, wobei die gepoolten Ressourcen Speicher und/oder Prozessorressourcen und/oder Beschleuniger beinhalten.
Beispiel 12 beinhaltet die Einrichtung der Beispiele 7-11, wobei die Prozessorschaltungsanordnung eine Schnittstelle mit einem Vorrichtungs-Interconnect-Fabric-Switch bilden soll, um die Fähigkeit und/oder die Kapazität der gepoolten Ressourcen zu bestimmen.
Beispiel 13 beinhaltet die Einrichtung der Beispiele 7-12, wobei die Prozessorschaltungsanordnung in einer Edge-Vorrichtung und/oder einem Server und/oder einer virtuellen Maschine implementiert ist.
Beispiel 14 beinhaltet ein nichttransitorisches computerlesbares Speicherungsmedium, das Anweisungen umfasst, die, wenn sie ausgeführt werden, bewirken, dass ein oder mehrere Prozessoren zumindest ein erstes Ressourcenanforderungssignal basierend auf einer ersten Service-Level-Agreement-Voraussetzung von einer ersten plattformagnostischen Anwendung erzeugen, ein zweites Ressourcenanforderungssignal basierend auf einer zweiten Service-Level-Agreement-Voraussetzung von einer zweiten plattformagnostischen Anwendung erzeugen und Hardwareressourcen für die erste plattformagnostische Anwendung und die zweite plattformagnostische Anwendung basierend auf dem ersten Ressourcenanforderungssignal und dem zweiten Ressourcenanforderungssignal zuweisen.
Beispiel 15 beinhaltet das computerlesbare Speicherungsmedium des Beispiels 14, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren eine Hierarchie für die erste plattformagnostische Anwendung, die zweite plattformagnostische Anwendung, und eine dritte plattformagnostische Anwendung erzeugen und die Hardwareressourcen für die erste plattformagnostische Anwendung, die zweite plattformagnostische Anwendung und die dritte plattformagnostische Anwendung basierend auf der Hierarchie zuweisen.
Beispiel 16 beinhaltet das computerlesbare Speicherungsmedium der Beispiele 14-15, wobei eine erste Gruppe in der Hierarchie eine andere Anzahl von Ressourcen empfängt als eine zweite Gruppe in der Hierarchie.
Beispiel 17 beinhaltet das computerlesbare Speichermedium der Beispiele 14-16, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren eine Hardwareressourcenzuweisung, die den zugewiesenen Hardwareressourcen entspricht, zu einem Betriebssystem übertragen.
Beispiel 18 beinhaltet das computerlesbare Speicherungsmedium der Beispiele 14-17, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die Konformität mit der ersten Service-Level-Agreement-Voraussetzung basierend auf Telemetriedaten bestimmen.
Beispiel 19 beinhaltet ein nichttransitorisches computerlesbares Speicherungsmedium, das Anweisungen umfasst, die, wenn sie ausgeführt werden, bewirken, dass ein oder mehrere Prozessoren zumindest eine Service-Level-Voraussetzung einer Dienstanforderung in ressourcenbasierte Attribute übersetzen, bestimmen, ob gepoolte Ressourcen in der Lage sind, die Dienstanforderung gemäß den ressourcenbasierten Attributen zu versorgen, eine Kapazität der gepoolten Ressourcen bestimmen und eine Antwort übertragen, um die Fähigkeit und die Kapazität der gepoolten Ressourcen anzugeben.
Beispiel 20 beinhaltet das computerlesbare Speicherungsmedium des Beispiels 19, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die Dienstanforderung von einem Broker erhalten und die Antwort zu dem Broker übertragen.
Beispiel 21 beinhaltet das computerlesbare Speicherungsmedium der Beispiele 19-20, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die Service-Level-Voraussetzung der Dienstanforderung in die ressourcenbasierten Attribute übersetzen, um Ressourcen zum Erfüllen der Service-Level-Voraussetzung zu bestimmen.
Beispiel 22 beinhaltet das computerlesbare Speicherungsmedium der Beispiele 19-21, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren eine negative Antwort übertragen, um anzugeben, dass die gepoolten Ressourcen nicht in der Lage sind, die Dienstanforderung zu versorgen, wenn die gepoolten Ressourcen nicht in der Lage sind, die Dienstanforderung zu versorgen.
Beispiel 23 beinhaltet das computerlesbare Speicherungsmedium der Beispiele 19-22, wobei die gepoolten Ressourcen Speicher und/oder Prozessorressourcen und/oder Beschleuniger beinhalten.
Beispiel 24 beinhaltet das computerlesbare Speicherungsmedium der Beispiele 19-23, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren mit einem Vorrichtungs-Interconnect-Fabric-Switch eine Schnittstelle bilden, um die Fähigkeit und/oder die Kapazität der gepoolten Ressourcen zu bestimmen.
Beispiel 25 beinhaltet das computerlesbare Speicherungsmedium der Beispiele 19-24, wobei der eine oder die mehreren Prozessoren in einer Edge-Vorrichtung und/oder einem Server und/oder einer virtuellen Maschine implementiert sind.
Beispiel 26 beinhaltet ein Verfahren zum Ermöglichen eines Service-Level-Agreement, wobei das Verfahren Folgendes beinhaltet: Erzeugen, durch Ausführen einer Anweisung mit einem oder mehreren Prozessoren, eines ersten Ressourcenanforderungssignals basierend auf einer ersten Service-Level-Agreement-Voraussetzung von einer ersten plattformagnostischen Anwendung, Erzeugen, durch Ausführen einer Anweisung mit dem einen oder den mehreren Prozessoren, eines zweiten Ressourcenanforderungssignals basierend auf einer zweiten Service-Level-Agreement-Voraussetzung von einer zweiten plattformagnostischen Anwendung und Zuweisen, durch Ausführen einer Anweisung mit dem einen oder den mehreren Prozessoren, von Hardwareressourcen für die erste plattformagnostische Anwendung und die zweite plattformagnostische Anwendung basierend auf dem ersten Ressourcenanforderungssignal und dem zweiten Ressourcenanforderungssignal.
Beispiel 27 beinhaltet das Verfahren des Beispiels 26, ferner beinhaltend Erzeugen einer Hierarchie für die erste plattformagnostische Anwendung, die zweite plattformagnostische Anwendung und eine dritte plattformagnostische Anwendung, und Zuweisen der Hardwareressourcen für die erste plattformagnostische Anwendung, die zweite plattformagnostische Anwendung und die dritte plattformagnostische Anwendung basierend auf der Hierarchie.
Beispiel 28 beinhaltet das Verfahren der Beispiele 26-27, wobei eine erste Gruppe in der Hierarchie eine andere Anzahl von Ressourcen empfängt als eine zweite Gruppe in der Hierarchie.
Beispiel 29 beinhaltet das Verfahren der Beispiele 26-28, ferner beinhaltend Übertragen einer Hardwareressourcenzuweisung, die den zugewiesenen Hardwareressourcen entspricht, zu einem Betriebssystem.
Beispiel 30 beinhaltet das Verfahren der Beispiele 26-29, ferner beinhaltend Bestimmen der Konformität mit der ersten Service-Level-Agreement-Voraussetzung basierend auf Telemetriedaten.
Beispiel 31 beinhaltet ein Verfahren zum Ermöglichen eines Service-Level-Agreement, wobei das Verfahren Folgendes beinhaltet: Übersetzen, durch Ausführen einer Anweisung mit einem oder mehreren Prozessoren, einer Service-Level-Voraussetzung einer Dienstanforderung in ressourcenbasierte Attribute, Bestimmen, durch Ausführen einer Anweisung mit dem einen oder den mehreren Prozessoren, ob gepoolte Ressourcen in der Lage sind, die Dienstanforderung gemäß den ressourcenbasierten Attributen zu versorgen, Bestimmen, durch Ausführen einer Anweisung mit dem einen oder den mehreren Prozessoren, der Kapazität der gepoolten Ressourcen und Übertragen einer Antwort, um die Fähigkeit und die Kapazität der gepoolten Ressourcen anzugeben.
Beispiel 32 beinhaltet das Verfahren des Beispiels 31, ferner beinhaltend Erhalten der Dienstanforderung von einem Broker und Übertragen der Antwort zu dem Broker.
Beispiel 33 beinhaltet das Verfahren der Beispiele 31-32, ferner beinhaltend Übersetzen der Service-Level-Voraussetzung der Dienstanforderung in die ressourcenbasierten Attribute, um Ressourcen zum Erfüllen der Service-Level-Voraussetzung zu bestimmen.
Beispiel 34 beinhaltet das Verfahren der Beispiele 31-33, ferner beinhaltend Übertragen einer negativen Antwort, um anzugeben, dass die gepoolten Ressourcen nicht in der Lage sind, die Dienstanforderung zu versorgen, wenn die gepoolten Ressourcen nicht in der Lage sind, die Dienstanforderung zu versorgen.
Beispiel 35 beinhaltet das Verfahren der Beispiele 31-24, wobei die gepoolten Ressourcen Speicher und/oder Prozessorressourcen und/oder Beschleuniger beinhalten.
Beispiel 36 beinhaltet das Verfahren der Beispiele 31-35, ferner beinhaltend Bilden einer Schnittstelle mit einem Vorrichtungs-Interconnect-Fabric-Switch, um die Fähigkeit und/oder die Kapazität der gepoolten Ressourcen zu bestimmen.
Beispiel 37 beinhaltet das Verfahren der Beispiele 31-36, wobei der eine oder die mehreren Prozessoren in einer Edge-Vorrichtung und/oder einem Server und/oder einer virtuellen Maschine implementiert sind.
Beispiel 28 ist eine Edge-Rechenvorrichtung, die eine Verarbeitungsschaltungsanordnung zum Durchführen eines beliebigen der Beispiele 26-37 umfasst.
Beispiel 29 ist ein computerlesbares Medium, das Anweisungen zum Durchführen eines beliebigen der Beispiele 26-37 umfasst.
Beispiel 30 ist eine Einrichtung, die Mittel zum Durchführen eines beliebigen der Beispiele 26-37 umfasst.
Obwohl gewisse beispielhafte Verfahren, Einrichtungen und Herstellungsartikel hier offenbart wurden, ist der Schutzumfang dieses Patents nicht darauf beschränkt. Vielmehr deckt dieses Patent alle Verfahren, Einrichtungen und Herstellungsartikel ab, die angemessen in den Schutzumfang der Ansprüche dieses Patents fallen.

Claims

Einrichtung zum Ermöglichen eines Service-Level-Agreement, wobei die Einrichtung Folgendes beinhaltet: einen ersten Mesh-Proxy, der einer ersten plattformagnostischen Anwendung zugeordnet ist, wobei der erste Mesh-Proxy ein erstes Ressourcenanforderungssignal basierend auf einer ersten Service-Level-Agreement-Voraussetzung von der ersten plattformagnostischen Anwendung erzeugen soll; einen zweiten Mesh-Proxy, der einer zweiten plattformagnostischen Anwendung zugeordnet ist, wobei der zweite Mesh-Proxy ein zweites Ressourcenanforderungssignal basierend auf einer zweiten Service-Level-Agreement-Voraussetzung von der zweiten plattformagnostischen Anwendung erzeugen soll; und einen Lastausgleicher zum Zuweisen von Hardwareressourcen für die erste plattformagnostische Anwendung und die zweite plattformagnostische Anwendung basierend auf dem ersten Ressourcenanforderungssignal und dem zweiten Ressourcenanforderungssignal.
Einrichtung nach Anspruch 1, die ferner Folgendes beinhaltet: einen dritten Mesh-Proxy, der einer dritten plattformagnostischen Anwendung zugeordnet ist; einen Hierarchiegenerator zum Erzeugen einer Hierarchie für die erste plattformagnostische Anwendung, die zweite plattformagnostische Anwendung und die dritte plattformagnostische Anwendung; und wobei der Lastausgleicher die Hardwareressourcen für die erste plattformagnostische Anwendung, die zweite plattformagnostische Anwendung und die dritte plattformagnostische Anwendung basierend auf der Hierarchie zuweist.
Einrichtung nach Anspruch 2, wobei eine erste Gruppe in der Hierarchie eine andere Anzahl von Ressourcen empfängt als eine zweite Gruppe in der Hierarchie.
Einrichtung nach einem der Ansprüche 1-3, ferner beinhaltend eine Schnittstelle zum Übertragen einer Hardwareressourcenzuweisung, die den zugewiesenen Hardwareressourcen entspricht, zu einem Betriebssystem.
Einrichtung nach einem der Ansprüche 1-3, wobei der Lastausgleicher die Konformität mit der ersten Service-Level-Agreement-Voraussetzung basierend auf Telemetriedaten bestimmen soll.
Einrichtung nach einem der Ansprüche 1-3, wobei der erste Mesh-Proxy die Konformität mit der ersten Service-Level-Agreement-Voraussetzung basierend auf Telemetriedaten bestimmen soll.
Einrichtung zum Ermöglichen eines Service-Level-Agreement, wobei die Einrichtung Folgendes beinhaltet: Speicher; Anweisungen; und eine Prozessorschaltungsanordnung zum Ausführen der Anweisungen zum: Übersetzen einer Service-Level-Voraussetzung einer Dienstanforderung in ressourcenbasierte Attribute; Bestimmen, ob gepoolte Ressourcen in der Lage sind, die Dienstanforderung gemäß den ressourcenbasierten Attributen zu versorgen; Bestimmen der Kapazität der gepoolten Ressourcen; und Übertragen einer Antwort, um die Fähigkeit und die Kapazität der gepoolten Ressourcen anzugeben.
Einrichtung nach Anspruch 7, wobei die Prozessorschaltungsanordnung die Dienstanforderung von einem Broker erhalten und die Antwort zu dem Broker übertragen soll.
Einrichtung nach Anspruch 7, wobei die Prozessorschaltungsanordnung die Service-Level-Voraussetzung der Dienstanforderung in die ressourcenbasierten Attribute übersetzen soll, um Ressourcen zum Erfüllen der Service-Level-Voraussetzung zu bestimmen.
Einrichtung nach Anspruch 7, wobei die Prozessorschaltungsanordnung eine negative Antwort übertragen soll, um anzugeben, dass die gepoolten Ressourcen nicht in der Lage sind, die Dienstanforderung zu versorgen, wenn die gepoolten Ressourcen nicht in der Lage sind, die Dienstanforderung zu versorgen.
Einrichtung nach einem der Ansprüche 7-10, wobei die gepoolten Ressourcen Speicher und/oder Prozessorressourcen und/oder Beschleuniger beinhalten.
Einrichtung nach einem der Ansprüche 7-10, wobei die Prozessorschaltungsanordnung eine Schnittstelle mit einem Vorrichtungs-Interconnect-Fabric-Switch bilden soll, um die Fähigkeit und/oder die Kapazität der gepoolten Ressourcen zu bestimmen.
Einrichtung nach einem der Ansprüche 7-10, wobei die Prozessorschaltungsanordnung in einer Edge-Vorrichtung und/oder einem Server und/oder einer virtuellen Maschine implementiert ist.
Nichttransitorisches computerlesbares Speicherungsmedium, das Anweisungen umfasst, die, wenn sie ausgeführt werden, bewirken, dass ein oder mehrere Prozessoren zumindest Folgendes ausführen: Erzeugen eines ersten Ressourcenanforderungssignals basierend auf einer ersten Service-Level-Agreement-Voraussetzung von einer ersten plattformagnostischen Anwendung; Erzeugen eines zweiten Ressourcenanforderungssignals basierend auf einer zweiten Service-Level-Agreement-Voraussetzung von einer zweiten plattformagnostischen Anwendung; und Zuweisen von Hardwareressourcen für die erste plattformagnostische Anwendung und die zweite plattformagnostische Anwendung basierend auf dem ersten Ressourcenanforderungssignal und dem zweiten Ressourcenanforderungssignal.
Computerlesbares Speicherungsmedium nach Anspruch 14, wobei die Anweisungen den einen oder die mehreren Prozessoren zu Folgendem veranlassen: Erzeugen einer Hierarchie für die erste plattformagnostische Anwendung, die zweite plattformagnostische Anwendung und eine dritte plattformagnostische Anwendung; und Zuweisen der Hardwareressourcen für die erste plattformagnostische Anwendung, die zweite plattformagnostische Anwendung und die dritte plattformagnostische Anwendung basierend auf der Hierarchie.
Computerlesbares Speicherungsmedium nach Anspruch 15, wobei eine erste Gruppe in der Hierarchie eine andere Anzahl von Ressourcen als eine zweite Gruppe in der Hierarchie empfängt.
Computerlesbares Speicherungsmedium nach einem der Ansprüche 14-16, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren eine Hardwareressourcenzuweisung, die den zugewiesenen Hardwareressourcen entspricht, zu einem Betriebssystem übertragen.
Computerlesbares Speicherungsmedium nach einem der Ansprüche 14-16, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die Konformität mit der ersten Service-Level-Agreement-Voraussetzung basierend auf Telemetriedaten bestimmen.
Nichttransitorisches computerlesbares Speicherungsmedium, das Anweisungen umfasst, die, wenn sie ausgeführt werden, bewirken, dass ein oder mehrere Prozessoren zumindest Folgendes ausführen: Übersetzen einer Service-Level-Voraussetzung einer Dienstanforderung in ressourcenbasierte Attribute; Bestimmen, ob gepoolte Ressourcen in der Lage sind, die Dienstanforderung gemäß den ressourcenbasierten Attributen zu versorgen; Bestimmen der Kapazität der gepoolten Ressourcen; und Übertragen einer Antwort, um die Fähigkeit und die Kapazität der gepoolten Ressourcen anzugeben.
Computerlesbares Speicherungsmedium nach Anspruch 19, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die Dienstanforderung von einem Broker erhalten und die Antwort zu dem Broker übertragen.
Computerlesbares Speicherungsmedium nach Anspruch 19, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren die Service-Level-Voraussetzung der Dienstanforderung in die ressourcenbasierten Attribute übersetzen, um Ressourcen zum Erfüllen der Service-Level-Voraussetzung zu bestimmen.
Computerlesbares Speicherungsmedium nach Anspruch 19, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren eine negative Antwort übertragen, um anzugeben, dass die gepoolten Ressourcen nicht in der Lage sind, die Dienstanforderung zu versorgen, wenn die gepoolten Ressourcen nicht in der Lage sind, die Dienstanforderung zu versorgen.
Computerlesbares Speicherungsmedium nach einem der Ansprüche 19-22, wobei die gepoolten Ressourcen Speicher und/oder Prozessorressourcen und/oder Beschleuniger beinhalten.
Computerlesbares Speicherungsmedium nach einem der Ansprüche 19-22, wobei die Anweisungen bewirken, dass der eine oder die mehreren Prozessoren mit einem Vorrichtungs-Interconnect-Fabric-Switch eine Schnittstelle bilden, um die Fähigkeit und/oder die Kapazität der gepoolten Ressourcen zu bestimmen.
Computerlesbares Speicherungsmedium nach einem der Ansprüche 19-22, wobei der eine oder die mehreren Prozessoren in einer Edge-Vorrichtung und/oder einem Server und/oder einer virtuellen Maschine implementiert sind.