DE102022212115A1

DE102022212115A1 - Systeme und verfahren zur reaktiven, absichtsgesteuerten end-to-end-orchestrierung

Info

Publication number: DE102022212115A1
Application number: DE102022212115.5A
Authority: DE
Inventors: Kshitij Arun Doshi; John J. Browne; Marcos E. Carranza; Francesc Guim Bernat; Mats Gustav Agerstam; Adrian Hoban; Thijs Metsch
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2021-11-16
Filing date: 2022-11-15
Publication date: 2023-05-17
Also published as: US20220114251A1; WO2023091036A1; KR20230073372A; US20220124009A1; KR20230073371A; CN117501246A; US20220113790A1; DE102022212157A1; US20220124005A1; US20220121455A1; US20220116455A1

Abstract

Hier werden verschiedene Systeme und Verfahren für die reaktive, absichtsgesteuerte End-to-End-Orchestrierung (E2E) beschrieben. Ein Orchestratorsystem enthält einen Prozessor und einen Speicher zum Speichern von Befehlen, die, wenn sie vom Prozessor ausgeführt werden, das System zu Folgendem veranlassen: Empfangen, im Orchestratorsystem, einer absichtsbasierten Dienstleistungsgütevereinbarung (SLA) für die Ausführung einer Reihe von Aufgaben auf einer Vielzahl von Rechenknoten; Berechnen, auf der Grundlage der absichtsbasierten SLA, von Zwischenlatenzschwellenwerten, die jeder Aufgabe der Reihe von Aufgaben entsprechen; Berechnen von Schlupfschätzungen auf der Grundlage der Latenzschwellenwerte und der Echtzeit-Telemetrie der mehreren Rechenknoten oder der Echtzeit-Telemetrie von Verbindungen zwischen den mehreren Rechenknoten; Überwachen der Ausführung der Reihe von Aufgaben auf den mehreren Rechenknoten; und Durchführen einer Korrekturmaßnahme als Reaktion auf die Feststellung, dass die Ausführung der Reihe von Aufgaben voraussichtlich einen der Zwischenlatenzschwellenwerte überschreiten wird.

Description

PRIORITÄTSANSPRUCH
Diese Anmeldung beansprucht die Priorität der vorläufigen US-Patentanmeldung Nr. 63/280,001 , eingereicht am 16. November 2021, die hier durch Bezugnahme in vollem Umfang enthalten ist.
TECHNISCHES GEBIET
Die hier beschriebenen Ausführungsformen beziehen sich im Allgemeinen auf die Netzwerküberwachung und -abstimmung und insbesondere auf ein System und ein Verfahren zur reaktiven, absichtsgesteuerten End-to-End-(E2E)-Orchestrierung.
HINTERGRUND
Edge-Computing bezieht sich im Allgemeinen auf die Verlagerung von Rechen- und Speicherressourcen in die Nähe von Endgeräten (z. B. Computergeräte von Verbrauchern, Benutzergeräte usw.), um die Gesamtbetriebskosten zu optimieren, die Latenzzeit von Anwendungen zu verringern, die Servicefunktionen zu verbessern und die Einhaltung von Sicherheits- und Datenschutzanforderungen zu verbessern. Edge-Computing kann in einigen Szenarien einen Cloud-ähnlichen verteilten Dienst bereitstellen, der die Orchestrierung und Verwaltung von Anwendungen zwischen vielen Arten von Speicher- und Rechenressourcen ermöglicht. Infolgedessen werden einige Implementierungen des Edge-Computing als „Edge-Cloud“ oder „Fog“ bezeichnet, da leistungsstarke Rechenressourcen, die zuvor nur in großen, weit entfernten Rechenzentren verfügbar waren, näher an die Endpunkte verlagert und den Verbrauchern am „Rand“ des Netzwerks zur Verfügung gestellt werden.
Anwendungsfälle für Edge-Computing in Mobilfunknetzen wurden für die Integration mit MEC-Konzepten (Multi-Access Edge Computing) entwickelt, die auch als „Mobiles Edge-Computing“ bezeichnet werden. MEC-Konzepte sollen es Anwendungsentwicklern und Inhaltsanbietern ermöglichen, in dynamischen mobilen Netzwerkumgebungen am Rande des Netzwerks auf Computerkapazitäten und eine IT-Dienstumgebung zuzugreifen. Das Europäische Institut für Telekommunikationsnormen (ETSI) hat begrenzte Normen entwickelt, um gemeinsame Schnittstellen für den Betrieb von MEC-Systemen, Plattformen, Hosts, Diensten und Anwendungen zu definieren.
Edge-Computing, MEC und verwandte Technologien versuchen, geringere Latenzzeiten, eine höhere Reaktionsfähigkeit und mehr verfügbare Rechenleistung als bei herkömmlichen Cloud-Netzwerkdiensten und Wide Area Network-Verbindungen zu bieten. Die Integration von Mobilität und dynamisch gestarteten Diensten in einige Anwendungsfälle der mobilen Nutzung und Geräteverarbeitung hat jedoch zu Einschränkungen und Problemen bei der Orchestrierung, der funktionalen Koordinierung und dem Ressourcenmanagement geführt, insbesondere in komplexen Mobilitätsumgebungen, an denen viele Teilnehmer (Geräte, Hosts, Mieter, Dienstanbieter, Betreiber) beteiligt sind.
In ähnlicher Weise sind die Netzwerke und Geräte des Internets der Dinge (IoT) darauf ausgelegt, eine verteilte Datenverarbeitung von verschiedenen Endpunkten aus zu ermöglichen. IoT-Geräte sind physische oder virtualisierte Objekte, die über ein Netzwerk kommunizieren und Sensoren, Aktoren und andere Eingabe-/Ausgabekomponenten enthalten können, die zur Erfassung von Daten oder zur Durchführung von Aktionen in einer realen Umgebung verwendet werden können. Zu den IoT-Geräten können beispielsweise Endpunktgeräte mit geringer Leistung gehören, die in alltägliche Dinge wie Gebäude, Fahrzeuge, Verpackungen usw. eingebettet oder an ihnen angebracht sind, um eine zusätzliche Ebene der künstlichen sensorischen Wahrnehmung dieser Dinge zu schaffen. In letzter Zeit sind IoT-Geräte immer beliebter geworden, und daher haben sich auch die Anwendungen, die diese Geräte nutzen, vermehrt.
Der Einsatz verschiedener Edge-, Fog-, MEC- und IoT-Netzwerke, -Geräte und - Dienste hat mehrere fortschrittliche Anwendungsfälle und Szenarien hervorgebracht, die am Rand des Netzwerks und in dessen Nähe auftreten. Diese fortgeschrittenen Anwendungsfälle haben jedoch auch verschiedene technische Herausforderungen in Bezug auf Orchestrierung, Sicherheit, Verarbeitungs- und Netzwerkressourcen, Dienstverfügbarkeit und -effizienz, Gewährleistung der Dienstgüte und viele andere Fragen mit sich gebracht, insbesondere da immer mehr Arten von Computersystemen und Konfigurationen eingesetzt werden.
Figurenliste
In den Zeichnungen, die nicht unbedingt maßstabsgetreu sind, können gleiche Ziffern ähnliche Komponenten in verschiedenen Ansichten bezeichnen. Gleiche Ziffern mit unterschiedlichen Buchstabensuffixen können verschiedene Instanzen ähnlicher Komponenten darstellen. Einige Ausführungsformen sind beispielhaft und ohne Einschränkung in den Abbildungen der beigefügten Zeichnungen dargestellt, in denen Folgendes veranschaulicht wird:

1 zeigt einen Überblick über eine Edge-Cloud-Konfiguration für Edge-Computing gemäß einer Ausführungsform.
2 veranschaulicht die Betriebsebenen zwischen Endpunkten, einer Edge-Cloud und Cloud-Computing-Umgebungen, gemäß einer Ausführungsform.
3 veranschaulicht einen beispielhaften Ansatz für Netzwerke und Dienste in einem Edge-Computing-System gemäß einer Ausführungsform.
4 veranschaulicht den Einsatz einer virtuellen Edge-Konfiguration in einem Edge-Computing-System, das zwischen mehreren Edge-Knoten und mehreren Tenants betrieben wird, gemäß einer Ausführungsform.
5 zeigt verschiedene Berechnungsanordnungen, die Container in einem Edge-Computing-System einsetzen, gemäß einer Ausführungsform.
6A bietet einen Überblick über Beispielkomponenten für die Datenverarbeitung, die an einem Rechenknoten in einem Edge-Computing-System gemäß einer Ausführungsform bereitgestellt werden.
6B bietet eine weitere Übersicht von Beispielkomponenten innerhalb eines Computergerätes in einem Edge-Computing-System gemäß einer Ausführungsform.
7 zeigt eine beispielhafte Software-Verteilungsplattform zur Verteilung von Software, wie z. B. die beispielhaften computerlesbaren Anweisungen von 6B, an ein oder mehrere Geräte gemäß einer Ausführungsform.
8 ist ein Blockdiagramm, das ein serverloses Rechenzentrum gemäß einer Ausführungsform zeigt.
9 ist ein Blockdiagramm, das eine Betriebsumgebung mit mehreren Hardwaresystemen und gemäß einer Ausführungsform zeigt.
10 ist ein Blockdiagramm, das eine Orchestrierungs-Steuerungsebene gemäß einer Ausführungsform darstellt.
11 ist ein Blockdiagramm, das den Daten- und Steuerfluss in einem Orchestrierungssystem gemäß einer Ausführungsform veranschaulicht.
12 ist ein Flussdiagramm, das ein Verfahren zur Implementierung einer absichtsbasierten Orchestrierung gemäß einer Ausführungsform darstellt.
13 ist ein Diagramm, das die Aufgaben gemäß einer Ausführungsformdarstellt.
14 ist ein weiteres Diagramm, das die dominanten Pfade entsprechend den Kommunikations- und Rechenkosten gemäß einer Ausführungsform zeigt.
15 ist ein Flussdiagramm, das ein Verfahren zur Bestimmung dominanter Pfade in einem Berechnungs- und Kommunikationsgraphen gemäß einer Ausführungsform veranschaulicht.
16 ist ein weiteres Diagramm, das die dominanten Pfade entsprechend den Kommunikations- und Rechenkosten gemäß einer Ausführungsform zeigt.
17 ist ein Flussdiagramm, das ein Verfahren zur dynamischen Orchestrierung gemäß einer Ausführungsform illustriert; und
18 ist ein Flussdiagramm, das ein Verfahren zur absichtsgesteuerten Orchestrierung gemäß einer Ausführungsform darstellt.

DETAILLIERTE BESCHREIBUNG
Die hier beschriebenen Systeme und Verfahren bieten eine reaktive, absichtsgesteuerte End-to-End-(E2E)-Orchestrierung. Aktuelle Orchestrierungslösungen verwenden eine sehr zwingende Art und Weise, um Quality of Service (QoS)-Management zu erreichen. Beim QoS-Management geht es vor allem darum, die richtige Menge an Ressourcen (z. B. die Anzahl der virtuellen Zentraleinheiten (vCPUs)) oder Hardwarefunktionen zur Unterstützung der Arbeitslasten in der Cloud und am Edge anzufordern. Diese Art der Orchestrierung bringt mehrere Probleme mit sich. Dies führt zu einer unerwünschten Anbieterbindung, da bestimmte, von einem Anbieter spezifizierte Funktionen in den Geräten eines anderen Anbieters möglicherweise nicht verfügbar sind. Außerdem zeigt die Erfahrung, dass falsche Informationen in der QoS-Anfrage angegeben werden und somit zu einer suboptimalen Leistung führen. Schließlich haben diese Erklärungen einen Kontext, der nicht in das QoS-Verwaltungssystem einbezogen ist. So kann sich beispielsweise die Art der Plattform, auf der die Anwendung läuft (z. B. Xeon-Kern-Prozessoren im Vergleich zu Atom-Kern-Prozessoren), auf die Bereitstellungsentscheidungen zur Erfüllung einer bestimmten QoS-Anforderung auswirken.
Außerdem wird es für die Kunden immer schwieriger, die richtigen Ressourcenzuweisungen für die Arbeitslasten selbst auszuwählen, da sich die Arbeitslasten von einem monolithischen Stil zu einem Mikrodienst-Stil bewegen. Dies kann dazu führen, dass die Kunden die Ressourcen überbeanspruchen, was wiederum zu höheren Kosten führt.
Da die Hardwareplattformen immer heterogener werden (z. B. Verwendung mehrerer XPUs anstelle einer einzigen CPU), muss der Benutzer nicht mehr eine Vielzahl kontextbezogener Details in einer Orchestrierungsanforderung definieren, sondern kann sich stattdessen darauf konzentrieren, was er erreichen möchte, um eine bestimmte Reihe von Zielen für die betreffenden Dienste zu erreichen. Ein absichtsgesteuertes Modell bietet diese Abstraktion für den Benutzer und führt zu einer guten Leistung für den Diensteigentümer sowie zu einer guten Investitionsrendite für den Ressourceneigentümer. Es muss also eine Möglichkeit gefunden werden, die Absichten (definiert als Service Level Objectives (Dienstleistungsgüteziele)) in einer Reihe von Systemen und deren Ressourcen abzubilden, um das erforderliche Niveau der Dienstgüte zu erreichen.
Eine Dienstleistungsgütevereinbarung (Service Level Agreement = SLA) ist eine Vereinbarung zwischen einem Dienstanbieter und einem Kunden. SLAs sind Verträge zwischen Dritten, in denen Dienstleistungsziele oder andere Unternehmensziele festgelegt sind. SLAs können Sanktionen für Parteien vorsehen, die ein Ziel nicht erreichen. So kann beispielsweise eine teilweise Rückerstattung der Gebühren durchgesetzt werden, wenn ein Dienst innerhalb eines Zeitraums von 90 Tagen für mehr als einen bestimmten Prozentsatz nicht verfügbar ist.
Dienstleistungsgüteziele (Service Level Objectives = SLOs) liefern präzise numerische Ziele für verschiedene Systemfähigkeiten. Typische SLOs beziehen sich auf die Verfügbarkeit oder Betriebszeit von Diensten, die Latenzzeit von Diensten, die Bereitstellung von Dienstbandbreite usw. SLOs werden oft als Prozentsätze ausgedrückt, z. B. „99,9 % Betriebszeit über einen Zeitraum von 30 Tagen“ oder „Antwortzeiten von weniger als 100 ms bei mindestens 95 % der eingegangenen Anfragen“.
Leistungsindikatoren (Key Performance Indicators = KPIs) sind quantifizierbare Messgrößen für die Leistung im Zeitverlauf für ein bestimmtes Ziel. Zur Messung der SLO-Richtlinien werden KPI-Metriken erhoben. Beispiele für KPIs sind u. a. die Anzahl der Dienstfehler, Ausfallzeiten, Cache-Fehlversuche, Bilder pro Sekunde (FPS), Latenz, Anweisungen pro Zyklus (IPC), Sicherheitsfehler, fehlgeschlagene Anmeldungen usw. Bei den KPIs kann es sich um abgeleitete Werte handeln (z. B. die durchschnittliche Latenzzeit über ein gleitendes 30-Sekunden-Fenster). KPIs können auch auf Vergleichen basieren (z. B. prozentuale Abweichung vom historischen Durchschnitt).
Dienstgüteziele können als statistische und deterministische Spezifikationen erfasst werden, die eine geschichtete Top-Down-Struktur bilden, aber nicht zwangsläufig einem Baum- oder DAG-Muster entsprechen müssen. Beispielsweise kann eine Metasprache verwendet werden, um wichtige Leistungsindikatoren (Key Performance Indicators = KPIs) auszudrücken und zu beschreiben, wie sie kombiniert werden, um eine gesamte Dienstgüte (QoS) oder ein Dienstleistungsgüteziel (Service Level Objective = SLO) zu bewerten. Verschiedene Bereiche, Vergleiche, Schwellenwerte, Beschränkungen oder dergleichen für die KPIs können mit einer Metasprache ausgedrückt werden. Die meisten realen Softwarelösungen müssen viele komplizierte Anforderungen an Leistung, Skalierbarkeit, Genauigkeit und Verfügbarkeit erfüllen, und diese Anforderungen sind nicht unbedingt für alle Zeiten oder Situationen festgelegt. Genauso wie Programme in einer Sprache wie C oder Python dem Programmierer ein hohes Maß an Flexibilität bei der Formulierung der zu berechnenden Daten bieten, kann eine Metasprache verwendet werden, die die dynamischen Anforderungen ausdrückt, die von den Planern der Ressourcen erfüllt werden müssen. Ein in einer solchen Metasprache geschriebenes Meta-Programm kann Variablen einführen, die beispielsweise verschiedene Kalibrierungen widerspiegeln, die am Verhalten von Programmen, Laufzeiten, Betriebssystemen, Infrastrukturdiensten, Netzwerkausrüstung usw. vorgenommen werden. Diese Variablen werden dann in die Variablen und Ergebnisse der Meta-Programme auf höherer Ebene eingeflochten, die wiederum korrigierende, reaktive, alarmierende und andere Aktionen der Meta-Programme steuern. Die Strukturierung erfolgt schichtweise, so dass Metaprogramme zur Abstraktion und Reduktion von Details und zur Annäherung an die vorgegebenen Ziele auf höheren Ebenen konzipiert werden.
Es wird eine offene Architektur bereitgestellt, so dass die Schichtung von Strategien, Heuristiken usw. nicht allein durch logische Regeln begrenzt ist, sondern die Möglichkeit bietet, datenprogrammierte Intelligenz wie neuronale Netze, Support Vector Machines (SVMs), Entscheidungsbäume usw. einzubinden. Das übergeordnete Ziel besteht darin, einen Teil der Berechnungen auf solche Meta-Programme umzuleiten und eine strikte Trennung zwischen den Berechnungen, die Teil der Struktur einer Anwendung sind, und den Berechnungen, die dazu dienen, ein Dienstqualitätsziel während der Ausführung der Anwendung zu erreichen, zu vermeiden. So wird die übliche Unterscheidung zwischen einer Steuerungs-/Verwaltungsebene wie Kubernetes und einer containerisierten Anwendung, unter der sie läuft, verwischt, und Informationen über die Absicht und die Leistung zu dieser Absicht können auf verschiedenen Tiefenschichten bidirektional fließen. Dementsprechend können auto-korrigierende und auto-indikative Fähigkeiten zwischen den Strömen in den Dienstzielen und Dienstgütezielen mitentwickelt werden. Ein Vorteil ist, dass die Software beginnt, sich selbst oder gemeinsam mit der Umgebung, in der sie aktiviert wird, anzupassen.
Es gibt statistische Zulassungssteuerungsstrategien, die versuchen, die Erfüllung von Dienstleistungsgütevereinbarungen (SLA) zu maximieren, und die sich auf Jitter-empfindliche Netzwerksysteme beziehen. Mit zunehmender Abstraktion und der Implementierung von Scheduling in serverlosen Systemen oder hochgradig virtualisierten Systemen sowie der Justin-Time-Zuweisung von Ressourcen durch Container, die bei Bedarf erstellt werden, nimmt die Komplexität des Scheduling von Ressourcen jedoch weiter zu. Sehr große Rechenzentren können beträchtliche Kapazitäten für den reaktiven Lastausgleich bereitstellen und die Ablehnung der Zulassung bis auf die extremsten Nachfragespitzen aufschieben, aber kleinere und weniger elastische Infrastrukturanbieter müssen selbst bei statistischen Richtlinien harte Entscheidungen treffen, insbesondere dann, wenn ein Cutoff für eine Outlier-Latenzzeit vorgenommen wird. Es ist äußerst schwierig, große Nachfrageschübe zu bewältigen, die eine Kaskade von Latenzüberschreitungen verursachen können. Alternativ dazu implementieren die hier beschriebenen Systeme und Verfahren SLAs, die sowohl verschachtelt als auch abgestuft und damit Burst-akkommodierend sind.
Stellen Sie sich ein Token-Bucket-Modell mit einer einzigen Warteschlange an einem ratenbegrenzten Server vor: Eine statistische Projektion für die neueste Ankunft hat eine mittlere Antwortzeit, die proportional zur Länge der Warteschlange ist, die die neue Ankunft sieht. Eine naive Strategie würde darin bestehen, die neue Ankunft abzulehnen, wenn diese voraussichtliche Antwortzeit eine Latenzzeitbeschränkung verletzt; eine etwas weniger naive Strategie würde darin bestehen, die neue Ankunft je nach Länge der Warteschlange und der Anzahl der bereits aufgetretenen Verstöße mit einer gewissen Wahrscheinlichkeit abzulehnen. Stellen Sie sich nun eine Verallgemeinerung vor, bei der der grundlegende Single-Queue-, Single-Rate-Server in eine zweistufige Strategie aufgeteilt wird, bei der die neueste Ankunft in der zweiten Warteschlange platziert wird, wo ihr eine niedrigere Dienstrate garantiert wird, aber eine entspanntere Tail-Latenzzeit erlaubt ist. Wenn beispielsweise die erste Warteschlange eine P99-Latenzzeit von 10 ms hat, kann die zweite Warteschlange eine kombinierte SLO mit einer P95-Latenzzeit von 10 ms und einer P99-Latenzzeit von 20 ms haben. Da extreme Bursts selten sind, muss der Kapazitätsanteil der zweiten Warteschlange nicht hoch sein, da ihre durchschnittliche Warteschlangenlänge gering ist. In einem Rechenzentrum wird durch die Verschiebung in eine zweite Warteschlange die marginale Anforderung (diejenige, die wahrscheinlich gegen eine strenge Latenzgrenze verstößt) einem weniger ausgelasteten, aber mit weniger Ressourcen ausgestatteten Überlauf-Cluster mit entsprechend entspannterem SLO zugewiesen. Dieses Schema kann so verallgemeinert werden, dass, wenn die zweite Warteschlange sich ihrer Sättigung in Bezug auf die Antwortzeit nähert, eine dritte Warteschlange mit noch großzügigerer SLO den Überlauf aufnimmt. Auf diese Weise kann eine zusammengesetzte, verschachtelte SLO innerhalb einer SLA erstellt werden, die sich an Bursts anpassen lässt. Der Anbieter kann ein ähnlich gestaffeltes Kostenmodell aushandeln, bei dem die Einsparungen, die dadurch entstehen, dass er keine großen Spitzenkapazitäten bereitstellen muss, um ein unelastisches SLA zu erfüllen, an Kunden weitergegeben werden, die ein verschachteltes SLA akzeptieren.
Im Gegensatz zu hierarchischen Dienstleistungsgütevereinbarungen führen die hier beschriebenen Systeme und Verfahren SLAs ein, die sowohl verschachtelt als auch abgestuft sind. Anstatt sich auf die klassische Schwellenwertberechnung zu verlassen und „einzelne“ Klauselregeln zu überprüfen, kann eine verschachtelte Unterklausel der SLA in Kombination mit anderen Unterklauseln bewertet werden, um die SLA insgesamt zu bewerten. Dies ermöglicht komplexere Regeln. Außerdem ermöglicht das „Parsing“ der Unterklauseln, dass die Ergebnisse der einzelnen Klauseln zu einer gemeinsamen Nutzung der ungenutzten Ressourcen führen. Dieser Ansatz ermöglicht mehr Flexibilität bei den SLA-Regeln und eine bessere Nutzung der Cluster-Ressourcen. Die Flexibilität kann als „Absicht“ und nicht als Ressourcenspezifikation eingeführt werden, die dann auf verschachtelte/abgestufte SLA-Regeln abgebildet wird, die dann überwacht und durchgesetzt werden.
Bei der Bereitstellung in der Produktion ist es üblich, neue Instanzen einer Anwendung auf einem Teil der Umgebung bereitzustellen und mit einer kleinen Untergruppe der Benutzerbasis zu testen, bevor sie auf die gesamte Bevölkerung ausgeweitet werden (d. h. Canary-Rollout). Da die Zuordnung von SLAs zu immer niedrigeren Ebenen von Dienstleistungsgütezielen einen iterativen Ansatz erfordert (sowohl für Optimierungs- als auch für Abhilfezwecke), beinhaltet der neue Workflow für diese SLA-Zerlegung auch die Möglichkeit einer teilweisen Bereitstellung entweder in einer begrenzten End-to-End-Form oder als Teilkomponenten der E2E-Lösung, um die Auswirkungen auf die SLA-Einhaltung zu ermitteln.
Zusammenfassend lässt sich sagen, dass die hier beschriebenen Systeme und Verfahren einen neuen Weg zur Orchestrierung bieten, indem sie vom derzeitigen Modell zu einem zielgesteuerten Ansatz übergehen, bei dem der Kunde nur die Absicht (z. B. Latenz-, Durchsatz- und Zuverlässigkeitseigenschaften) äußert und der Orchestrierungsstapel selbst die Plattform zur Erreichung dieser Absicht einrichtet. Mit der zunehmenden Verbreitung von serverlosen Infrastrukturen werden Cloud-native (Mikrodienst)-Arbeitslasten schließlich einen Weg der absichtsgesteuerten Orchestrierung erfordern. Diese und andere Funktionen werden im Folgenden näher beschrieben.
1 ist ein Blockdiagramm 100, das einen Überblick über eine Konfiguration für Edge-Computing zeigt, die eine Verarbeitungsschicht umfasst, die in vielen der folgenden Beispiele als „Edge-Cloud“ bezeichnet wird. Wie dargestellt, befindet sich die Edge-Cloud 110 an einem Edge-Standort, z. B. einem Zugangspunkt oder einer Basisstation 140, einem lokalen Verarbeitungszentrum 150 oder einer Zentrale 120, und kann daher mehrere Einheiten, Geräte und Ausstattungsinstanzen umfassen. Die Edge-Cloud 110 befindet sich viel näher an den Endpunkt-Datenquellen 160 (z. B. autonome Fahrzeuge 161, Benutzergeräte 162, Geschäfts- und Industriegeräte 163, Videoaufnahmegeräte 164, Drohnen 165, intelligente Städte und Gebäudegeräte 166, Sensoren und IoT-Geräte 167 usw.) als das Cloud-Datenzentrum 130. Rechen-, Speicher- und Speicherressourcen, die an den Rändern der Edge-Cloud 110 angeboten werden, sind entscheidend für die Bereitstellung von Reaktionszeiten mit extrem niedriger Latenz für Dienste und Funktionen, die von den Endpunkt-Datenquellen 160 genutzt werden, und für die Reduzierung des Netzwerk-Backhaul-Verkehrs von der Edge-Cloud 110 zum Cloud-Rechenzentrum 130, wodurch sich neben anderen Vorteilen auch der Energieverbrauch und die Gesamtnetzauslastung verbessern.
Rechenleistung, Arbeitsspeicher und Speicherplatz sind knappe Ressourcen, die im Allgemeinen je nach Edge-Standort abnehmen (z. B. stehen an Endgeräten von Verbrauchern weniger Verarbeitungsressourcen zur Verfügung als an einer Basisstation oder in einer Zentrale). Je näher sich der Edge-Standort jedoch am Endpunkt (z. B. dem Benutzergerät) befindet, desto stärker sind Platz- und Energiebeschränkungen zu beachten. Mit Edge Computing wird also versucht, die Menge der für Netzdienste benötigten Ressourcen zu verringern, indem mehr Ressourcen verteilt werden, die sowohl geografisch als auch hinsichtlich der Netzzugangszeit näher beieinander liegen. Auf diese Weise versucht Edge Computing, die Rechenressourcen zu den Arbeitsdaten zu bringen, wo es angebracht ist, oder die Arbeitsdaten zu den Rechenressourcen zu bringen.
Im Folgenden werden Aspekte einer Edge-Cloud-Architektur beschrieben, die mehrere potenzielle Einsatzmöglichkeiten abdeckt und Einschränkungen berücksichtigt, die einige Netzwerkbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen haben könnten. Dazu gehören Konfigurationsvariationen auf der Grundlage des Edge-Standorts (da die Leistung und die Fähigkeiten von Edges auf Basisstationsebene in einem Multi-Tenant-Szenario stärker eingeschränkt sein können), Konfigurationen auf der Grundlage der Art der Rechen-, Speicher-, Fabric-, Beschleunigungs- oder ähnlicher Ressourcen, die Edge-Standorten, Standortschichten oder Standortgruppen zur Verfügung stehen, die Service-, Sicherheits-, Verwaltungs- und Orchestrierungsfunktionen sowie die damit verbundenen Ziele zur Erreichung der Benutzerfreundlichkeit und Leistung von Enddiensten. Diese Bereitstellungen können die Verarbeitung in Netzwerkschichten durchführen, die je nach Latenz, Entfernung und Zeitmerkmalen als „near Edge“, „close Edge“, „local Edge“, „middle Edge“ oder „far Edge“ bezeichnet werden können.
Edge Computing ist ein sich entwickelndes Paradigma, bei dem die Datenverarbeitung am oder näher am „Rand“ eines Netzes durchgeführt wird, in der Regel durch den Einsatz einer Rechenplattform (z. B. x86- oder ARM-Hardware-Architektur), die in Basisstationen, Gateways, Netzroutern oder anderen Geräten implementiert wird, die viel näher an den Endgeräten liegen, die die Daten erzeugen und verbrauchen. Edge-Gateway-Server können beispielsweise mit Speicherpools und Speicherressourcen ausgestattet sein, um Berechnungen in Echtzeit für Anwendungsfälle mit geringer Latenz (z. B. autonomes Fahren oder Videoüberwachung) für angeschlossene Client-Geräte durchzuführen. So können beispielsweise Basisstationen mit Rechen- und Beschleunigungsressourcen ausgestattet werden, um Dienstlasten für angeschlossene Benutzergeräte direkt zu verarbeiten, ohne dass die Daten über Backhaul-Netzwerke übertragen werden müssen. Ein weiteres Beispiel: Die Hardware für das Netzwerkmanagement in der Zentrale kann durch standardisierte Rechenhardware ersetzt werden, die virtualisierte Netzwerkfunktionen ausführt und Rechenressourcen für die Ausführung von Diensten und Verbraucherfunktionen für angeschlossene Geräte bereitstellt. Innerhalb von Edge-Computing-Netzen kann es Szenarien geben, in denen die Rechenressource zu den Daten „verschoben“ wird, sowie Szenarien, in denen die Daten zur Rechenressource „verschoben“ werden. So können z. B. die Rechen-, Beschleunigungs- und Netzwerkressourcen einer Basisstation Dienste bereitstellen, die sich je nach Bedarf an die Arbeitslast anpassen, indem sie ruhende Kapazitäten aktivieren (Abonnement, Kapazität auf Abruf), um Eckfälle oder Notfälle zu bewältigen oder um die Langlebigkeit der eingesetzten Ressourcen über einen wesentlich längeren Lebenszyklus zu gewährleisten.
2 zeigt die Betriebsebenen zwischen Endpunkten, einer Edge-Cloud und Cloud-Computing-Umgebungen. 2 zeigt insbesondere Beispiele für Rechenanwendungsfälle 205, bei denen die Edge-Cloud 110 auf mehreren veranschaulichenden Ebenen der Netzwerkberechnung eingesetzt wird. Die Schichten beginnen mit einer Endpunktschicht (Geräte und Dinge) 200, die auf die Edge-Cloud 110 zugreift, um Aktivitäten zur Datenerstellung, -analyse und -nutzung durchzuführen. Die Edge-Cloud 110 kann sich über mehrere Netzwerkschichten erstrecken, z. B. eine Edge-Geräte-Schicht 210 mit Gateways, Servern vor Ort oder Netzwerkvorrichtungen (Knoten 215), die sich in physisch nahe gelegenen Edge-Systemen befinden; eine Netzwerkzugangsschicht 220, die Basisstationen, Funkverarbeitungseinheiten, Netzwerk-Hubs, regionale Datenzentren (DC) oder lokale Netzwerkvorrichtungen (Geräte 225) umfasst; und alle Geräte, Vorrichtungen oder Knoten, die sich dazwischen befinden (in Schicht 212 nicht im Detail dargestellt). Die Netzwerkkommunikation innerhalb der Edge-Cloud 110 und zwischen den verschiedenen Schichten kann über eine beliebige Anzahl von drahtgebundenen oder drahtlosen Medien erfolgen, einschließlich über nicht dargestellte Verbindungsarchitekturen und -technologien.
Beispiele für Latenzzeiten, die sich aus der Entfernung zur Netzwerkkommunikation und den Einschränkungen bei der Verarbeitungszeit ergeben, reichen von weniger als einer Millisekunde (ms) bei der Kommunikation zwischen den Endpunkten (200) über weniger als 5 ms bei den Edge-Geräten (210) bis hin zu 10 bis 40 ms bei der Kommunikation mit Knoten auf der Netzwerkzugangsebene (220). Hinter der Edge-Cloud 110 befinden sich die Schichten des Kernnetzwerks 230 und des Cloud-Rechenzentrums 240, die jeweils eine zunehmende Latenz aufweisen (z. B. zwischen 50-60 ms auf der Kernnetzwerkschicht 230 und 100 oder mehr ms auf der Schicht des Cloud-Rechenzentrums). Infolgedessen ist der Betrieb in einem Kernnetzwerk-Rechenzentrum 235 oder einem Cloud-Rechenzentrum 245 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage, viele zeitkritische Funktionen der Anwendungsfälle 205 zu erfüllen. Jeder dieser Latenzwerte wird zur Veranschaulichung und zum Vergleich angegeben; es versteht sich von selbst, dass die Verwendung anderer Zugangsnetzwerkmedien und -technologien die Latenzzeiten weiter verringern kann. In einigen Beispielen können die jeweiligen Teile des Netzes als „close Edge“, „local Edge“, „near Edge“, „middle Edge“ oder „far Edge“-Schichten relativ zu einer Netzquelle und einem Ziel kategorisiert werden. Aus der Perspektive des Kernnetz-Rechenzentrums 235 oder eines Cloud-Rechenzentrums 245 kann beispielsweise ein zentrales Büro oder ein Inhaltsdatennetz als in einer „Near Edge“-Schicht befindlich betrachtet werden („near“ zur Cloud, mit hohen Latenzwerten bei der Kommunikation mit den Geräten und Endpunkten der Anwendungsfälle 205), während ein Zugangspunkt, eine Basisstation, ein Server vor Ort oder ein Netzwerk-Gateway als in einer „Far Edge“-Schicht befindlich betrachtet werden kann („far“ von der Cloud, mit niedrigen Latenzwerten bei der Kommunikation mit den Geräten und Endpunkten der Anwendungsfälle 205). Es versteht sich, dass andere Kategorisierungen einer bestimmten Netzwerkschicht als „nahe“, „lokal“, „nah“, „mittel“ oder „fern“ Edge auf Latenz, Entfernung, Anzahl der Netzwerksprünge oder anderen messbaren Eigenschaften basieren können, die von einer Quelle in einer der Netzwerkschichten 200-240 gemessen werden.
Die verschiedenen Anwendungsfälle 205 können auf Ressourcen zugreifen, die durch eingehende Streams unter Nutzungsdruck stehen, da mehrere Dienste die Edge-Cloud nutzen. Um Ergebnisse mit niedrigen Latenzzeiten zu erzielen, müssen die in der Edge-Cloud 110 ausgeführten Dienste unterschiedliche Anforderungen erfüllen: (a) Priorität (Durchsatz oder Latenz) und Dienstgüte (QoS) (z. B. kann der Datenverkehr für ein autonomes Fahrzeug eine höhere Priorität haben als ein Temperatursensor in Bezug auf die erforderliche Reaktionszeit; oder es kann je nach Anwendung eine Leistungsempfindlichkeit/ein Engpass bei einer Rechen-/Beschleunigungs-, Speicher-, Ablage- oder Netzwerkressource bestehen); b) Zuverlässigkeit und Ausfallsicherheit (z. B., einige Eingabeströme müssen verarbeitet und der Datenverkehr zuverlässig weitergeleitet werden, während andere Eingabeströme je nach Anwendung gelegentliche Ausfälle tolerieren können) und c) physische Einschränkungen (z. B. Energie, Kühlung und Formfaktor).
Die End-to-End-Service-Sicht für diese Anwendungsfälle beinhaltet das Konzept eines Service-Flusses und ist mit einer Transaktion verbunden. In der Transaktion werden die allgemeinen Serviceanforderungen für die Entität, die den Service in Anspruch nimmt, sowie die zugehörigen Services für die Ressourcen, Workloads, Workflows und die funktionalen und geschäftlichen Anforderungen auf Unternehmensebene aufgeführt. Die mit den beschriebenen „Bedingungen“ ausgeführten Dienste können auf jeder Ebene so verwaltet werden, dass die Einhaltung der vertraglichen Bestimmungen für die Transaktion während des Lebenszyklus des Dienstes in Echtzeit und zur Laufzeit gewährleistet ist. Wenn eine Komponente in der Transaktion ihre vereinbarte SLA nicht einhält, kann das System als Ganzes (Komponenten in der Transaktion) die Möglichkeit bieten, (1) die Auswirkungen der SLA-Verletzung zu verstehen und (2) andere Komponenten im System zu ergänzen, um die Gesamt-SLA der Transaktion wiederherzustellen, und (3) Schritte zur Abhilfe zu implementieren.
Mit diesen Variationen und Dienstmerkmalen im Hinterkopf kann das Edge-Computing innerhalb der Edge-Cloud 110 die Fähigkeit bieten, mehrere Anwendungen der Anwendungsfälle 205 (z. B. Objektverfolgung, Videoüberwachung, vernetzte Autos usw.) in Echtzeit oder nahezu in Echtzeit zu bedienen und auf sie zu reagieren und die Anforderungen an eine extrem niedrige Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganz neue Klasse von Anwendungen (Virtual Network Functions (VNFs), Function as a Service (FaaS), Edge as a Service (EaaS), Standardprozesse usw.), die das Cloud-Computing aufgrund von Latenzzeiten oder anderen Einschränkungen nicht nutzen können.
Mit den Vorteilen des Edge-Computing sind jedoch auch die folgenden Vorbehalte verbunden. Die Geräte am Edge sind oft ressourcenbeschränkt, weshalb die Nutzung der Edge-Ressourcen unter Druck steht. In der Regel wird dies durch die gemeinsame Nutzung von Arbeitsspeicher und Speicherressourcen durch mehrere Nutzer (Tenants) und Geräte erreicht. Der Edge kann unter Strom- und Kühlungsbeschränkungen leiden, weshalb der Stromverbrauch von den Anwendungen bestimmt werden muss, die den meisten Strom verbrauchen. Bei diesen gepoolten Speicherressourcen kann es zu einem Kompromiss zwischen Leistung und Stromverbrauch kommen, da viele von ihnen wahrscheinlich neue Speichertechnologien verwenden, bei denen mehr Leistung eine größere Speicherbandbreite erfordert. Ebenso ist eine verbesserte Sicherheit der Hardware und der vertrauenswürdigen Root-of-Trust-Funktionen erforderlich, da Edge-Standorte unter Umständen unbemannt sind und sogar eine Zugangsgenehmigung benötigen (z. B. wenn sie an einem Drittstandort untergebracht sind). Solche Probleme werden in der Edge-Cloud 110 in einer Umgebung mit mehreren Mietern, mehreren Eigentümern oder mehreren Zugängen, in der Dienste und Anwendungen von vielen Nutzern angefordert werden, noch verschärft, insbesondere wenn die Netznutzung dynamisch schwankt und sich die Zusammensetzung der verschiedenen Beteiligten, Anwendungsfälle und Dienste ändert.
Auf einer allgemeineren Ebene kann ein Edge-Informatiksystem so beschrieben werden, dass es eine beliebige Anzahl von Bereitstellungen auf den zuvor erörterten Schichten umfasst, die in der Edge-Cloud 110 (Netzwerkschichten 200-240) betrieben werden und die Koordinierung von Client- und verteilten Computergeräten ermöglichen. Ein oder mehrere Edge-Gateway-Knoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kerndatenzentren können über die verschiedenen Schichten des Netzes verteilt sein, um eine Implementierung des Edge-Computing-Systems durch oder im Namen eines Telekommunikationsdienstleisters („Telco“ oder „TSP“), eines Internet-of-Things-Dienstleisters, eines Cloud-Dienstanbieters (CSP), eines Unternehmens oder einer beliebigen anderen Anzahl von Unternehmen bereitzustellen. Verschiedene Implementierungen und Konfigurationen des Edge-Informatiksystems können dynamisch bereitgestellt werden, z. B. wenn sie zur Erfüllung von Dienstzielen orchestriert werden.
In Übereinstimmung mit den hier dargestellten Beispielen kann ein Client-Rechenknoten als jede Art von Endpunktkomponente, Vorrichtung, Gerät oder andere Sache verkörpert werden, die in der Lage ist, als Produzent oder Konsument von Daten zu kommunizieren. Darüber hinaus bedeutet die Bezeichnung „Knoten“ oder „Gerät“, wie sie im Edge-Computing-System verwendet wird, nicht notwendigerweise, dass ein solcher Knoten oder ein solches Gerät in einer Client- oder Agenten-/Mitläuferrolle arbeitet; vielmehr beziehen sich alle Knoten oder Geräte im Edge-Computing-System auf einzelne Einheiten, Knoten oder Teilsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen umfassen, um die Edge-Cloud 110 zu ermöglichen oder zu nutzen.
So besteht die Edge-Cloud 110 aus Netzwerkkomponenten und Funktionsmerkmalen, die von und in Edge-Gateway-Knoten, Edge-Aggregationsknoten oder anderen Edge-Computing-Knoten auf den Netzwerkschichten 210-230 betrieben werden. Die Edge-Cloud 110 kann daher als jede Art von Netzwerk ausgeführt werden, das Edge-Rechen- und/oder Speicherressourcen bereitstellt, die sich in unmittelbarer Nähe von RAN-fähigen Endgeräten (z. B. mobile Computergeräte, IoT-Geräte, intelligente Geräte usw.) befinden, die hier erörtert werden. Mit anderen Worten, die Edge-Cloud 110 kann als „Edge“ betrachtet werden, die Endgeräte und herkömmliche Netzzugangspunkte verbindet, die als Eingangspunkt in die Kernnetze von Dienstanbietern dienen, einschließlich der Netze von Mobilfunkanbietern (z. B. Global System for Mobile Communications (GSM)-Netze, Long-Term Evolution (LTE)-Netze, 5G/6G-Netze usw.), und gleichzeitig Speicher- und/oder Rechenfunktionen bereitstellt. Andere Arten und Formen des Netzzugangs (z. B. Wi-Fi, drahtlose Weitverkehrsnetze, drahtgebundene Netze einschließlich optischer Netze) können auch anstelle von oder in Kombination mit solchen 3GPP-Trägernetzen verwendet werden.
Bei den Netzwerkkomponenten der Edge-Cloud 110 kann es sich um Server, Tenant-fähige Server, Appliance-Computing-Geräte und/oder jede andere Art von Computing-Geräten handeln. Die Edge-Cloud 110 kann beispielsweise ein Appliance-Computing-Gerät umfassen, das ein in sich geschlossenes elektronisches Gerät mit einem Gehäuse, einem Chassis, einem Koffer oder einer Schale ist. Unter bestimmten Umständen kann das Gehäuse so dimensioniert sein, dass es von einer Person getragen und/oder transportiert werden kann. Beispielhafte Gehäuse können Materialien enthalten, die eine oder mehrere Außenflächen bilden, die den Inhalt des Gerätes teilweise oder vollständig schützen, wobei der Schutz einen Schutz vor Witterungseinflüssen, gefährlichen Umgebungsbedingungen (z. B. EMI, Vibrationen, extremen Temperaturen) und/oder die Möglichkeit des Eintauchens umfassen kann. Beispielhafte Gehäuse können Stromversorgungsschaltungen zur Bereitstellung von Strom für stationäre und/oder tragbare Geräte enthalten, wie z. B. Wechselstromeingänge, Gleichstromeingänge, AC/DC- oder DC/AC-Wandler, Leistungsregler, Transformatoren, Ladeschaltungen, Batterien, verdrahtete Eingänge und/oder drahtlose Stromeingänge. Beispielhafte Gehäuse und/oder deren Oberflächen können Befestigungselemente enthalten oder mit diesen verbunden sein, um die Befestigung an Strukturen wie Gebäuden, Telekommunikationsstrukturen (z. B. Masten, Antennenstrukturen usw.) und/oder Racks (z. B. Server-Racks, Blade-Halterungen usw.) zu ermöglichen. Beispielhafte Gehäuse und/oder deren Oberflächen können einen oder mehrere Sensoren tragen (z. B. Temperatursensoren, Vibrationssensoren, Lichtsensoren, akustische Sensoren, kapazitive Sensoren, Näherungssensoren usw.). Ein oder mehrere solcher Sensoren können in der Oberfläche enthalten sein, von ihr getragen werden oder auf andere Weise in die Oberfläche eingebettet und/oder an der Oberfläche des Gerätes angebracht sein. Beispielhafte Gehäuse und/oder deren Oberflächen können mechanische Verbindungen tragen, wie z. B. Antriebskomponenten (z. B. Räder, Propeller usw.) und/oder Gelenkkomponenten (z. B. Roboterarme, schwenkbare Anhänge usw.). In manchen Fällen können die Sensoren jede Art von Eingabegeräten umfassen, wie z. B. Benutzerschnittstellen-Hardware (z. B. Tasten, Schalter, Drehknöpfe, Schieberegler usw.). In manchen Fällen umfassen die Gehäuse Ausgabegeräte, die in ihnen enthalten sind, von ihnen getragen werden, in sie eingebettet und/oder an ihnen befestigt sind. Zu den Ausgabegeräten können Anzeigen, Touchscreens, Leuchten, LEDs, Lautsprecher, E/A-Anschlüsse (z. B. USB) usw. gehören. Unter Umständen handelt es sich bei Edge-Geräten um Geräte, die für einen bestimmten Zweck (z. B. eine Ampel) in das Netz eingebunden sind, aber über Verarbeitungs- und/oder andere Kapazitäten verfügen, die für andere Zwecke genutzt werden können. Solche Edge-Geräte können unabhängig von anderen vernetzten Geräten sein und mit einem Gehäuse ausgestattet sein, dessen Formfaktor für ihren Hauptzweck geeignet ist; sie können jedoch für andere Rechenaufgaben zur Verfügung stehen, die ihre Hauptaufgabe nicht beeinträchtigen. Zu den Edge-Geräten gehören Geräte aus dem Internet der Dinge. Das Appliance-Computing-Gerät kann Hardware- und Softwarekomponenten zur Verwaltung lokaler Probleme wie Gerätetemperatur, Vibration, Ressourcennutzung, Updates, Stromversorgungsprobleme, physische und Netzwerksicherheit usw. enthalten. Ein Beispiel für die Hardware zur Implementierung einer Geräte-Rechenvorrichtung wird in Verbindung mit 6B beschrieben. Die Edge-Cloud 110 kann auch einen oder mehrere Server und/oder einen oder mehrere Multi-Tenant-Server umfassen. Ein solcher Server kann ein Betriebssystem enthalten und eine virtuelle Datenverarbeitungsumgebung implementieren. Eine virtuelle Computerumgebung kann einen Hypervisor umfassen, der eine oder mehrere virtuelle Maschinen, einen oder mehrere Container usw. verwaltet (z. B. Auslösen, Bereitstellen, Zerstören usw.). Solche virtuellen Computerumgebungen bieten eine Ausführungsumgebung, 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.
In 3 tauschen verschiedene Client-Endpunkte 310 (in Form von mobilen Geräten, Computern, autonomen Fahrzeugen, Geschäftscomputern und industriellen Verarbeitungsgeräten) Anfragen und Antworten aus, die für die Art der Endpunkt-Netzwerkaggregation spezifisch sind. So können Client-Endpunkte 310 beispielsweise über ein kabelgebundenes Breitbandnetz Zugang zum Netz erhalten, indem sie Anfragen und Antworten 322 über ein lokales Netzsystem 332 austauschen. Einige Client-Endpunkte 310, wie z. B. mobile Rechenvorrichtungen, können über ein drahtloses Breitbandnetz Zugang zum Netz erhalten, indem sie Anfragen und Antworten 324 über einen Zugangspunkt (z. B. einen Mobilfunkmast) 334 austauschen. Einige Client-Endpunkte 310, wie z. B. autonome Fahrzeuge, können den Netzzugang für Anfragen und Antworten 326 über ein drahtloses Fahrzeugnetz durch ein straßengebundenes Netzsystem 336 erhalten. Unabhängig von der Art des Netzzugangs kann der TSP jedoch Aggregationspunkte 342, 344 innerhalb der Edge-Cloud 110 einrichten, um Datenverkehr und Anfragen zu aggregieren. So kann der TSP innerhalb der Edge-Cloud 110 verschiedene Rechen- und Speicherressourcen einsetzen, z. B. an Edge-Aggregationsknoten 340, um angeforderte Inhalte bereitzustellen. Die Edge-Aggregationsknoten 340 und andere Systeme der Edge-Cloud 110 sind mit einer Cloud oder einem Rechenzentrum 360 verbunden, das ein Backhaul-Netzwerk 350 verwendet, um Anfragen mit höherer Latenz von einer Cloud/einem Rechenzentrum 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 solcher, die auf einem einzigen Server-Framework bereitgestellt werden, können auch innerhalb der Edge-Cloud 110 oder in anderen Bereichen der TSP-Infrastruktur vorhanden sein.
4 veranschaulicht die Bereitstellung und Orchestrierung von virtualisierten und containerbasierten Edge-Konfigurationen in einem Edge-Computing-System, das von mehreren Edge-Knoten und mehreren Tenants (z. B. Nutzern, Anbietern) betrieben wird, die solche Edge-Knoten verwenden. Insbesondere zeigt 4 die Koordination eines ersten Edge-Knotens 422 und eines zweiten Edge-Knotens 424 in einem Edge-Computing-System 400, um Anfragen und Antworten für verschiedene Client-Endpunkte 410 (z. B. intelligente Städte/Gebäudesysteme, Mobilvorrichtungen, Computergeräte, Geschäfts-/Logistiksysteme, Industriesysteme usw.) zu erfüllen, die auf verschiedene virtuelle Edge-Instanzen zugreifen. Hier bieten die virtuellen Edge-Instanzen 432, 434 Edge-Rechenkapazitäten und -Verarbeitung in einer Edge-Cloud, mit Zugang zu einer Cloud/einem Rechenzentrum 440 für Anfragen mit höherer Latenz für Websites, Anwendungen, Datenbankserver usw. Die Edge-Cloud ermöglicht jedoch die Koordinierung der Verarbeitung zwischen mehreren Edge-Knoten für mehrere Tenants oder Unternehmen.
Im Beispiel von 4 umfassen diese virtuellen Edge-Instanzen: eine erste virtuelle Edge 432, die einem ersten Tenant (Tenant 1) angeboten wird und eine erste Kombination aus Edge-Speicher, Datenverarbeitung und Diensten bietet; und eine zweite virtuelle Edge 434, die eine zweite Kombination aus Edge-Speicher, Datenverarbeitung und Diensten bietet. Die virtuellen Edge-Instanzen 432, 434 sind auf die Edge-Knoten 422, 424 verteilt und können Szenarien umfassen, in denen eine Anfrage und eine Antwort von demselben oder von verschiedenen Edge-Knoten erfüllt werden. Die Konfiguration der Edge-Knoten 422, 424 für einen verteilten, aber koordinierten Betrieb erfolgt auf der Grundlage der Edge-Bereitstellungsfunktionen 450. Die Funktionalität der Edge-Knoten 422, 424 zur Bereitstellung eines koordinierten Betriebs für Anwendungen und Dienste zwischen mehreren Tenants basiert auf den Orchestrierungsfunktionen 460.
Es sollte klar sein, dass einige der Geräte in 410 Multi-Tenant-Geräte sind, bei denen Tenant 1 innerhalb einer Tenantl-„Scheibe“ funktionieren kann, während Tenant 2 innerhalb einer Tenant2-Scheibe funktionieren kann (und in weiteren Beispielen können zusätzliche oder Unter-Tenants existieren; und jeder Tenant kann sogar spezifisch berechtigt und transaktionsmäßig an einen spezifischen Satz von Merkmalen bis hin zu spezifischen Hardwaremerkmalen gebunden sein). Ein vertrauenswürdiges mandantenfähiges Gerät kann außerdem einen mandantenspezifischen kryptografischen Schlüssel enthalten, so dass die Kombination aus Schlüssel und Slice als „Root of Trust“ (RoT) oder mandantenspezifischer RoT betrachtet werden kann. Eine RoT kann außerdem dynamisch mit Hilfe einer DICE-Architektur (Device Identity Composition Engine) zusammengesetzt werden, so dass ein einziger DICE-Hardware-Baustein verwendet werden kann, um geschichtete vertrauenswürdige Computing-Basiskontexte für die Schichtung von Gerätefähigkeiten (z. B. ein Field Programmable Gate Array (FPGA)) zu konstruieren. Der RoT kann außerdem für einen vertrauenswürdigen Computerkontext verwendet werden, um ein „Fan-out“ zu ermöglichen, das für die Unterstützung der Multi-Tenant-Fähigkeit nützlich ist. In einer Multi-Tenant-Umgebung können die jeweiligen Edge-Knoten 422, 424 als Durchsetzungsstellen für Sicherheitsmerkmale für lokale Ressourcen fungieren, die mehreren Tenants pro Knoten zugewiesen sind. Darüber hinaus kann die Laufzeit des Tenants und die Ausführung der Anwendung (z. B. in den Instanzen 432, 434) als Durchsetzungspunkt für ein Sicherheitsmerkmal dienen, das eine virtuelle Edge-Abstraktion von Ressourcen schafft, die potenziell mehrere physische Hosting-Plattformen umfasst. Schließlich können die Orchestrierungsfunktionen 460 einer Orchestrierungseinheit als Durchsetzungsstelle für Sicherheitseigenschaften dienen, um Ressourcen entlang von Tenant-Grenzen zu verlagern.
Edge-Computing-Knoten können Ressourcen partitionieren (Speicher, zentrale Verarbeitungseinheit (CPU), Grafikverarbeitungseinheit (GPU), Interrupt-Controller, Input/Output-Controller (I/O), Speicher-Controller, Bus-Controller usw.), wobei die jeweiligen Partitionierungen eine RoT-Fähigkeit enthalten können und wobei Fan-out und Layering gemäß einem DICE-Modell auf Edge-Knoten angewendet werden können. Cloud-Computing-Knoten verwenden häufig Container, FaaS-Engines, Servlets, Server oder andere Berechnungsabstraktionen, die gemäß einer DICE-Schicht- und Fan-Out-Struktur partitioniert werden können, um einen RoT-Kontext für jeden zu unterstützen. Dementsprechend können die jeweiligen RoTs übergreifenden Geräte 410, 422 und 440 die Einrichtung einer verteilten vertrauenswürdigen Datenverarbeitungsbasis (DTCB) koordinieren, so dass ein Tenantspezifischer virtueller vertrauenswürdiger sicherer Kanal eingerichtet werden kann, der alle Elemente von Ende zu Ende miteinander verbindet.
Es versteht sich von selbst, dass ein Container über daten- oder arbeitslastspezifische Schlüssel verfügen kann, die seinen Inhalt vor einem früheren Edge-Knoten schützen. Im Rahmen der Migration eines Containers kann ein Pod-Controller an einem Edge-Quellknoten einen Migrationsschlüssel von einem Pod-Controller an einem Edge-Zielknoten erhalten, wobei der Migrationsschlüssel zur Umhüllung der containerspezifischen Schlüssel verwendet wird. Bei der Migration des Containers/Pods zum Edge-Zielknoten wird der Entschlüsselungsschlüssel an den Pod-Controller weitergegeben, der dann die verschlüsselten Schlüssel entschlüsselt. Die Schlüssel können nun verwendet werden, um Operationen mit containerspezifischen Daten durchzuführen. Die Migrationsfunktionen können von ordnungsgemäß zertifizierten Edge-Knoten und Pod-Managern (wie oben beschrieben) gesteuert werden.
In weiteren Beispielen wird ein Edge-Computing-System so erweitert, dass es die Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (eine enthaltene, einsatzfähige Softwareeinheit, die Code und erforderliche Abhängigkeiten bereitstellt) in einer Umgebung mit mehreren Eigentümern und mehreren Tenants ermöglicht. Ein Multi-Tenant-Orchestrator kann für die Schlüsselverwaltung, die Verwaltung von Vertrauensankern und andere Sicherheitsfunktionen im Zusammenhang mit der Bereitstellung und dem Lebenszyklus des vertrauenswürdigen „Slice“-Konzepts in 4 verwendet werden. Ein Edge-Computing-System kann beispielsweise so ausgebildet sein, dass es Anfragen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einer Cloud oder einem entfernten Rechenzentrum) aus erfüllt. Die Nutzung dieser virtuellen Edge-Instanzen kann mehrere Tenants und mehrere Anwendungen (z. B. Augmented Reality (AR)/Virtual Reality (VR), Unternehmensanwendungen, Bereitstellung von Inhalten, Spiele, Rechenleistung) gleichzeitig unterstützen. Außerdem kann es mehrere Arten von Anwendungen innerhalb der virtuellen Edge-Instanzen geben (z. B. normale Anwendungen, latenzempfindliche Anwendungen, latenzkritische Anwendungen, Anwendungen auf der Benutzerebene, Netzwerkanwendungen usw.). Die virtuellen Edge-Instanzen können sich auch über Systeme mehrerer Eigentümer an verschiedenen geografischen Standorten erstrecken (oder über entsprechende Rechnersysteme und Ressourcen, die sich im Miteigentum mehrerer Eigentümer befinden oder von diesen gemeinsam verwaltet werden).
Beispielsweise kann jeder Edge-Knoten 422, 424 die Verwendung von Containern implementieren, z. B. durch die Verwendung eines Container-„Pods“ 426, 428, der eine Gruppe von einem oder mehreren Containern bereitstellt. In einer Umgebung, die einen oder mehrere Container-Pods verwendet, ist ein Pod-Controller oder Orchestrator für die lokale Steuerung und Orchestrierung der Container im Pod verantwortlich. Verschiedene Edge-Knoten-Ressourcen (z. B. Speicher, Rechenleistung, Dienste, dargestellt durch Sechsecke), die für die jeweiligen Edge-Slices 432, 434 bereitgestellt werden, werden entsprechend den Anforderungen jedes Containers aufgeteilt.
Bei der Verwendung von Container-Pods überwacht ein Pod-Controller die Partitionierung und Zuweisung von Containern und Ressourcen. Der Pod-Controller erhält Anweisungen von einem Orchestrator (z. B. Orchestrator 460), der den Controller anweist, wie er die physischen Ressourcen am besten aufteilt und für welche Dauer, z. B. durch Erhalt von KPI-Zielen (Key Performance Indicator) auf der Grundlage von SLA-Verträgen. Der Pod-Controller bestimmt, welcher Container welche Ressourcen wie lange benötigt, um die Arbeitslast zu bewältigen und die SLA zu erfüllen. Der Pod-Controller verwaltet auch die Operationen des Container-Lebenszyklus, wie z. B. die Erstellung des Containers, die Bereitstellung von Ressourcen und Anwendungen, die Koordinierung von Zwischenergebnissen zwischen mehreren Containern, die gemeinsam an einer verteilten Anwendung arbeiten, die Demontage von Containern, wenn die Arbeitslast abgeschlossen ist, und dergleichen. Darüber hinaus kann ein Pod-Controller eine Sicherheitsfunktion erfüllen, die die Zuweisung von Ressourcen verhindert, bis sich der richtige Tenant authentifiziert hat, oder die Bereitstellung von Daten oder einer Arbeitslast für einen Container verhindert, bis ein Bestätigungsergebnis vorliegt.
Auch bei der Verwendung von Container-Pods können Tenant-Grenzen weiterhin bestehen, allerdings im Kontext der einzelnen Container-Pods. Wenn jeder Tenant-spezifische Pod über einen Tenant-spezifischen Pod-Controller verfügt, gibt es einen gemeinsam genutzten Pod-Controller, der die Ressourcenzuweisungsanforderungen konsolidiert, um typische Situationen der Ressourcenverknappung zu vermeiden. Weitere Kontrollen können vorgesehen werden, um die Bescheinigung und Vertrauenswürdigkeit des Pods und des Pod-Controllers sicherzustellen. So kann der Orchestrator 460 beispielsweise lokalen Pod-Controllern, die eine Attestierungsprüfung durchführen, eine Attestierungsprüfungsrichtlinie zur Verfügung stellen. Wenn eine Bescheinigung eine Richtlinie für einen ersten Tenant-Pod-Controller, aber nicht für einen zweiten Tenant-Pod-Controller erfüllt, kann der zweite Pod auf einen anderen Edge-Knoten migriert werden, der die Richtlinie erfüllt. Alternativ kann die Ausführung des ersten Pods gestattet werden, und ein anderer gemeinsam genutzter Pod-Controller wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
5 zeigt zusätzliche Berechnungsanordnungen, die Container in einem Edge-Computing-System einsetzen. Als vereinfachtes Beispiel zeigen die Systemanordnungen 510, 520 Einstellungen, in denen ein Pod-Controller (z. B. Container-Manager 511, 521 und Container-Orchestrator 531) angepasst ist, um containerisierte Pods, Funktionen und Functions-as-a-Service-Instanzen durch Ausführung über Rechenknoten (515 in Anordnung 510) zu starten oder um containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten (523 in Anordnung 520) separat auszuführen. Diese Anordnung ist für die Verwendung mehrerer Tenants in der Systemanordnung 530 (unter Verwendung von Rechenknoten 537) geeignet, 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) in virtuellen Maschinen (z. B. VMs 534, 535 für die Tenants 532, 533) gestartet werden, die für die jeweiligen Tenants spezifisch sind (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen). Diese Anordnung ist ferner für die Verwendung in der Systemanordnung 540 geeignet, die Container 542, 543 oder die Ausführung der verschiedenen Funktionen, Anwendungen und Funktionen auf Rechenknoten 544 bereitstellt, die von einem containerbasierten Orchestrierungssystem 541 koordiniert werden.
Die in 5 dargestellte Systemanordnung bietet eine Architektur, die VMs, Container und Funktionen in Bezug auf die Anwendungszusammensetzung gleich behandelt (und die resultierenden Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann eine oder mehrere Beschleunigerkomponenten (FPGA, ASIC) als lokales Backend verwenden. Auf diese Weise können Anwendungen auf mehrere Edge-Eigentümer aufgeteilt werden, die von einem Orchestrator koordiniert werden.
Im Zusammenhang mit 5 können der Pod-Controller/Container-Manager, der Container-Orchestrator und einzelne Knoten einen Punkt zur Durchsetzung der Sicherheit darstellen. Eine Tenant-Isolierung kann jedoch auch dann erfolgen, wenn die einem Tenant zugewiesenen Ressourcen sich von den einem zweiten Tenant zugewiesenen Ressourcen unterscheiden, die Eigentümer der Edge aber zusammenarbeiten, um sicherzustellen, dass die Ressourcenzuweisungen nicht über die Tenant-Grenzen hinweg gemeinsam genutzt werden. Oder die Ressourcenzuweisungen könnten über Mandantengrenzen hinweg isoliert werden, da die Mandanten die „Nutzung“ über ein Abonnement oder eine Transaktion/Vertragsbasis erlauben könnten. In diesem Zusammenhang können Edge-Eigentümer Virtualisierung, Containerisierung, Enklaven und Hardware-Partitionierungsschemata einsetzen, um die Besitzverhältnisse durchzusetzen. Andere Isolationsumgebungen können sein: Bare Metal (dedizierte) Ausrüstung, virtuelle Maschinen, Container, virtuelle Maschinen auf Containern oder Kombinationen davon.
In weiteren Beispielen können Aspekte der softwaredefinierten oder kontrollierten Silizium-Hardware und anderer konfigurierbarer Hardware in die Anwendungen, Funktionen und Dienste eines Edge-Computing-Systems integriert werden. Software Defined Silicon (SDSi) kann verwendet werden, um sicherzustellen, dass eine Ressource oder ein Hardwarebestandteil einen Vertrag oder eine Dienstleistungsgütevereinbarung erfüllen kann, und zwar auf der Grundlage der Fähigkeit des Bestandteils, einen Teil von sich selbst oder der Arbeitslast zu korrigieren (z. B. durch ein Upgrade, eine Neukonfiguration oder die Bereitstellung neuer Funktionen innerhalb der Hardwarekonfiguration selbst).
In weiteren Beispielen kann jeder der Rechenknoten oder -geräte, die unter Bezugnahme auf die vorliegenden Edge-Computing-Systeme und -Umgebungen erörtert werden, auf der Grundlage der in 6A und 6B dargestellten Komponenten erfüllt werden. Entsprechende Edge-Rechenknoten können als eine Art Vorrichtung, Gerät, Computer oder sonstiges „Ding“ verkörpert werden, das mit anderen Edge-, Netzwerk- oder Endpunktkomponenten kommunizieren kann. Eine Edge-Rechenvorrichtung kann beispielsweise als ein Personal Computer, ein Server, ein Smartphone, eine mobile Rechenvorrichtung, ein intelligentes Gerät, ein bordeigenes Rechensystem (z. B. ein Navigationssystem), ein in sich geschlossenes Gerät mit einem Gehäuse, einer Hülle usw. oder ein anderes Gerät oder System ausgebildet sein, das die beschriebenen Funktionen ausführen kann.
In dem in 6A dargestellten vereinfachten Beispiel umfasst ein Edge-Rechenknoten 600 eine Compute-Engine (hier auch als „Rechenschaltung“ bezeichnet) 602, ein Eingabe/Ausgabe (E/A)-Subsystem (hier auch als „E/A-Schaltung“ bezeichnet) 608, einen Datenspeicher (hier auch als „Datenspeicherschaltung“ bezeichnet) 610, ein Kommunikationsschaltungs-Subsystem 612 und optional ein oder mehrere Peripheriegeräte (hier auch als „Peripheriegeräteschaltung“ bezeichnet) 614. In anderen Beispielen können die jeweiligen Rechenvorrichtungen andere oder zusätzliche Komponenten enthalten, wie sie typischerweise in einem Computer zu finden sind (z. B. ein Display, Peripheriegeräte usw.). Darüber hinaus können in einigen Beispielen eine oder mehrere der dargestellten Komponenten in eine andere Komponente integriert werden oder auf andere Weise einen Teil dieser Komponente bilden.
Der Rechenknoten 600 kann als jede Art von Maschine, Gerät oder Sammlung von Geräten ausgeführt werden, die verschiedene Rechenfunktionen ausführen können. In einigen Beispielen kann der Rechenknoten 600 als ein einzelnes Gerät wie ein integrierter Schaltkreis, ein eingebettetes System, ein feldprogrammierbares Gate-Array (FPGA), ein System-on-a-Chip (SOC) oder ein anderes integriertes System oder Gerät verkörpert sein. Im illustrativen Beispiel umfasst der Rechenknoten 600 einen Prozessor (hier auch als „Prozessorschaltung“ bezeichnet) 604 und einen Speicher (hier auch als „Speicherschaltung“ bezeichnet) 606 oder ist als solcher ausgeführt. Der Prozessor 604 kann als jede Art von Prozessor(en) ausgeführt werden, der in der Lage ist, die hier beschriebenen Funktionen auszuführen (z. B. eine Anwendung auszuführen). Der Prozessor 604 kann beispielsweise als Multi-Core-Prozessor(en), Mikrocontroller, Verarbeitungseinheit, spezialisierte oder zweckbestimmte Verarbeitungseinheit oder als anderer Prozessor oder Verarbeitungs-/Steuerungsschaltung ausgeführt sein.
In einigen Beispielen kann der Prozessor 604 als FPGA, als anwendungsspezifische integrierte Schaltung (ASIC), als rekonfigurierbare Hardware oder Hardware-Schaltung oder als andere spezialisierte Hardware ausgeführt werden, um die Ausführung der hierin beschriebenen Funktionen zu erleichtern, oder er kann mit diesen gekoppelt sein. In einigen Beispielen kann der Prozessor 604 auch als spezialisierte x-Processing Unit (x-PU), auch bekannt als Data Processing Unit (DPU), Infrastructure Processing Unit (IPU) oder Network Processing Unit (NPU), ausgeführt sein. Eine solche x-PU kann als eigenständige Schaltung oder Schaltungspaket ausgeführt, in einen SOC integriert oder mit Netzwerkschaltungen (z. B. in einem SmartNIC oder einem erweiterten SmartNIC), Beschleunigungsschaltungen, Speichergeräten, Speicherplatten oder AI-Hardware (z. B. GPUs oder programmierten FPGAs) integriert sein. Eine solche x-PU kann so konzipiert sein, dass sie einen oder mehrere Datenströme empfängt, abruft und/oder anderweitig programmiert, um diese zu verarbeiten und spezifische Aufgaben und Aktionen für die Datenströme auszuführen (z. B. das Hosten von Mikrodiensten, das Durchführen von Dienstmanagement oder Orchestrierung, das Organisieren oder Verwalten von Server- oder Rechenzentrums-Hardware, das Verwalten von Dienstnetzen oder das Sammeln und Verteilen von Telemetrie), und zwar außerhalb der CPU oder der allgemeinen Verarbeitungs-Hardware. Es versteht sich jedoch von selbst, dass x-PU, SOC, eine CPU andere Varianten des Prozessors 604 in Koordination miteinander arbeiten können, um viele Arten von Operationen und Befehlen innerhalb und im Namen des Rechenknotens 600 auszuführen.
Der Speicher 606 kann als jede Art von flüchtigem (z. B. dynamischer Direktzugriffsspeicher (DRAM) usw.) oder nichtflüchtigem Speicher oder Datenspeicher ausgeführt werden, der die hier beschriebenen Funktionen ausführen kann. Flüchtiger Speicher kann ein Speichermedium sein, das Leistung benötigt, um den Zustand von durch das Medium gespeicherten Daten aufrechtzuerhalten. Nicht einschränkende Beispiele für flüchtige Speicher sind verschiedene Arten von Direktzugriffsspeichern (RAM), wie DRAM oder statische Direktzugriffsspeicher (SRAM). Ein besonderer Typ von DRAM, der in einem Speichermodul verwendet werden kann, ist der synchrone dynamische Direktzugriffsspeicher (SDRAM).
In einem Beispiel handelt es sich bei der Speichervorrichtung (z. B. Speicherschaltung) um eine beliebige Anzahl von blockadressierbaren Speichervorrichtungen, z. B. solche, die auf NAND- oder NOR-Technologien basieren (z. B. Single-Level Cell („SLC“), Multi-Level Cell („MLC“), Quad-Level Cell („QLC“), Tri-Level Cell („TLC“) oder andere NAND). In einigen Beispielen umfasst (umfassen) die Speichervorrichtung(en) eine byteadressierbare dreidimensionale Kreuzpunktspeichervorrichtung oder andere byteadressierbare nichtflüchtige Speichervorrichtungen (NVM), wie ein- oder mehrstufige Phasenänderungsspeicher (PCM) oder Phasenänderungsspeicher mit einem Schalter (PCMS), NVM-Vorrichtungen, die Chalkogenid-Phasenänderungsmaterial verwenden (z. B. Chalkogenid-Glas), Widerstandsspeicher einschließlich Metalloxidbasis, Sauerstoffvakanzbasis und Conductive Bridge Random Access Memory (CB-RAM), Nanodrahtspeicher, ferroelektrischer Transistor-Random-Access-Memory (FeTRAM), magnetoresistiver Random-Access-Memory (MRAM), der Memristortechnologie enthält, Spin-Transfer-Torque (STT)-MRAM, ein auf Spintronic Magnetic Junction Memory basierendes Bauelement, ein auf Magnetic Tunneling Junction (MTJ) basierendes Bauelement, ein auf DW (Domain Wall) und SOT (Spin Orbit Transfer) basierendes Bauelement, ein auf Thyristor basierendes Speicherbauelement, eine Kombination der oben genannten Bauelemente oder andere geeignete Speicher. Eine Speichervorrichtung kann auch einen dreidimensionalen Kreuzpunktspeicher (z. B. Intel® 3D XPoint™-Speicher) oder andere byteadressierbare, nichtflüchtige Speichervorrichtungen umfassen. Die Speichervorrichtung kann sich auf den Die selbst und/oder auf ein gehäustes Speicherprodukt beziehen. In einigen Beispielen können 3D-Kreuzpunktspeicher (z. B. Intel® 3D XPoint™-Speicher) eine transistorlose, stapelbare Kreuzpunktarchitektur umfassen, bei der die Speicherzellen an der Kreuzung von Wort- und Bitleitungen sitzen und einzeln adressierbar sind und bei der die Bitspeicherung auf einer Änderung des Volumenwiderstands basiert. In einigen Beispielen kann der gesamte Speicher oder ein Teil des Speichers 606 in den Prozessor 604 integriert sein. Der Speicher 606 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie z. B. eine oder mehrere Anwendungen, Daten, die von der/den Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
In einigen Beispielen umfassen widerstandsbasierte und/oder transistorlose Speicherarchitekturen Phasenwechsel-Speicher (PCM) im Nanometerbereich, bei denen sich ein Volumen eines Phasenwechselmaterials zwischen mindestens zwei Elektroden befindet. Teile des beispielhaften Phasenwechselmaterials weisen unterschiedliche Grade an kristallinen Phasen und amorphen Phasen auf, in denen unterschiedliche Grade an Widerstand zwischen den mindestens zwei Elektroden gemessen werden können. In einigen Beispielen ist das Phasenwechselmaterial ein Glas auf Chalkogenidbasis. Solche resistiven Speichergeräte werden manchmal als memristive Geräte bezeichnet, die sich an die Geschichte des Stroms erinnern, der zuvor durch sie geflossen ist. Gespeicherte Daten werden von beispielhaften PCM-Geräten durch Messung des elektrischen Widerstands abgerufen, wobei die kristallinen Phasen einen relativ geringeren Widerstandswert (z. B. die logische „0“) aufweisen als die amorphen Phasen mit einem relativ höheren Widerstandswert (z. B. die logische „1“).
PCM-Geräte speichern beispielsweise Daten über lange Zeiträume (z. B. etwa 10 Jahre bei Raumtemperatur). Schreibvorgänge auf PCM-Bauteile (z. B. Setzen auf logisch „0“, Setzen auf logisch „1“, Setzen auf einen mittleren Widerstandswert) erfolgen durch Anlegen eines oder mehrerer Stromimpulse an die mindestens zwei Elektroden, wobei die Impulse eine bestimmte Stromstärke und Dauer haben. So bewirkt beispielsweise ein langer Schwachstromimpuls (SET), der an die mindestens zwei Elektroden angelegt wird, dass sich das PCM-Bauelement in einem kristallinen Zustand mit geringem Widerstand befindet, während ein vergleichsweise kurzer Hochstromimpuls (RESET), der an die mindestens zwei Elektroden angelegt wird, bewirkt, dass sich das PCM-Bauelement in einem amorphen Zustand mit hohem Widerstand befindet.
In einigen Beispielen erleichtert die Implementierung von PCM-Geräten Nicht-Von-Neumann-Rechenarchitekturen, die In-Memory-Computing-Funktionen ermöglichen. Herkömmliche Rechenarchitekturen umfassen im Allgemeinen eine zentrale Verarbeitungseinheit (CPU), die über einen Bus mit einem oder mehreren Speichergeräten verbunden ist. Daher wird eine endliche Menge an Energie und Zeit für die Übertragung von Daten zwischen der CPU und dem Speicher verbraucht, was ein bekannter Engpass bei von-Neumann-Rechenarchitekturen ist. PCM-Geräte minimieren jedoch den Datentransfer zwischen CPU und Speicher und machen ihn in einigen Fällen sogar überflüssig, indem sie einige Rechenoperationen im Speicher durchführen. Anders ausgedrückt: PCM-Geräte speichern nicht nur Informationen, sondern sie führen auch Rechenaufgaben aus. Solche Nichtvon-Neumann-Rechenarchitekturen können Vektoren mit einer relativ hohen Dimensionalität implementieren, um das hyperdimensionale Rechnen zu erleichtern, z. B. Vektoren mit 10.000 Bits. Relativ große Bitbreitenvektoren ermöglichen Computerparadigmen nach dem Vorbild des menschlichen Gehirns, das ebenfalls Informationen analog zu breiten Bitvektoren verarbeitet.
Die Rechenschaltung 602 ist mit anderen Komponenten des Rechenknotens 600 über das E/A-Subsystem 608 kommunikativ verbunden, das als Schaltung und/oder Komponenten ausgeführt sein kann, um Eingabe-/Ausgabeoperationen mit der Rechenschaltung 602 (z. B. mit dem Prozessor 604 und/oder dem Hauptspeicher 606) und anderen Komponenten der Rechenschaltung 602 zu erleichtern. Das E/A-Subsystem 608 kann beispielsweise als Speicher-Controller-Hubs, Eingabe-/Ausgabesteuerungs-Hubs, integrierte Sensor-Hubs, Firmware-Geräte, Kommunikationsverbindungen (z. B. Punkt-zu-Punkt-Verbindungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Leiterbahnen usw.) und/oder andere Komponenten und Subsysteme zur Erleichterung der Eingabe-/Ausgabevorgänge ausgeführt werden oder diese enthalten. In einigen Beispielen kann das E/A-Subsystem 608 einen Teil eines System-on-a-Chip (SoC) bilden und zusammen mit dem Prozessor 604, dem Speicher 606 und anderen Komponenten der Rechenschaltung 602 in die Rechenschaltung 602 integriert werden.
Das eine oder die mehreren illustrativen Datenspeichergeräte/-platten 610 können als ein oder mehrere beliebige(s) physische(s) Gerät(e) ausgeführt sein, das/die für die kurz- oder langfristige Speicherung von Daten ausgebildet ist/sind, wie z. B. Speichergeräte, Speicher, Schaltungen, Speicherkarten, Flash-Speicher, Festplattenlaufwerke, Solid-State-Laufwerke (SSDs) und/oder andere Datenspeichergeräte/-platten. Einzelne Datenspeichergeräte/Festplatten 610 können eine Systempartition enthalten, die Daten und Firmware-Code für das Datenspeichergerät/die Festplatte 610 speichert. Einzelne Datenspeichergeräte/Festplatten 610 können auch eine oder mehrere Betriebssystempartitionen enthalten, auf denen Datendateien und ausführbare Dateien für Betriebssysteme gespeichert sind, die beispielsweise vom Typ des Rechenknotens 600 abhängen.
Die Kommunikationsschaltung 612 kann als jede Kommunikationsschaltung, jedes Gerät oder jede Sammlung davon ausgeführt werden, die in der Lage sind, die Kommunikation über ein Netzwerk zwischen der Rechenschaltung 602 und einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway eines implementierten Edge-Informatiksystems) zu ermöglichen. Die Kommunikationsschaltung 612 kann so konfiguriert sein, dass sie eine oder mehrere Kommunikationstechnologien (z. B. drahtgebundene oder drahtlose Kommunikation) und zugehörige Protokolle verwendet (z. B. ein zellulares Netzwerkprotokoll, wie z. B. ein 3GPP 4G- oder 5G-Standard, ein drahtloses lokales Netzwerkprotokoll, wie z. B. IEEE 802.11/Wi-Fi®, ein drahtloses Weitverkehrsnetzprotokoll, Ethernet, Bluetooth®, Bluetooth Low Energy, ein IoT-Protokoll, wie z. B. IEEE 802.15.4 oder ZigBee®, Low-Power-Wide-Area-Network-(LPWAN) oder Low-Power-Wide-Area- (LPWA) Protokolle usw.), um eine solche Kommunikation zu bewirken.
Die illustrative Kommunikationsschaltung 612 umfasst einen Netzwerkschnittstellen-Controller (NIC) 620, der auch als Host Fabric Interface (HFI) bezeichnet werden kann. Die NIC 620 kann als ein oder mehrere Add-in-Boards, Tochterkarten, Netzwerk-Schnittstellenkarten, Controller-Chips, Chipsätze oder andere Geräte ausgeführt sein, die vom Rechenknoten 600 zur Verbindung mit einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway-Knoten) verwendet werden können. In einigen Beispielen kann die NIC 620 als Teil eines System-on-a-Chip (SoC), das einen oder mehrere Prozessoren enthält, oder auf einem Multichip-Paket, das ebenfalls einen oder mehrere Prozessoren enthält, enthalten sein. In einigen Beispielen kann die NIC 620 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) enthalten, die beide lokal zu der NIC 620 sind. In solchen Beispielen kann der lokale Prozessor der NIC 620 in der Lage sein, eine oder mehrere der hier beschriebenen Funktionen der Rechenschaltung 602 auszuführen. Zusätzlich oder alternativ kann in solchen Beispielen der lokale Speicher der NIC 620 in eine oder mehrere Komponenten des Client-Rechenknotens auf der Platinen-, Sockel-, Chip-Ebene und/oder anderen Ebenen integriert werden.
Zusätzlich kann in einigen Beispielen ein entsprechender Rechenknoten 600 ein oder mehrere Peripheriegeräte 614 enthalten. Solche Peripheriegeräte 614 können alle Arten von Peripheriegeräten umfassen, die in einer Rechenvorrichtung oder einem Server zu finden sind, wie z. B. Audio-Eingabegeräte, ein Display, andere Eingabe-/Ausgabegeräte, Schnittstellengeräte und/oder andere Peripheriegeräte, je nach dem speziellen Typ des Rechenknotens 600. In weiteren Beispielen kann der Rechenknoten 600 durch einen entsprechenden Edge-Computing-Knoten (sei es ein Client, ein Gateway oder ein Aggregationsknoten) in einem Edge-Informatiksystem oder ähnliche Formen von Geräten, Computern, Subsystemen, Schaltungen oder anderen Komponenten verkörpert werden.
In einem detaillierteren Beispiel zeigt 6B ein Blockdiagramm eines Beispiels von Komponenten, die in einem Edge-Computing-Knoten 650 vorhanden sein können, um die hierin beschriebenen Techniken (z. B. Vorgänge, Prozesse, Verfahren und Methodologien) zu implementieren. Dieser Edge-Computing-Knoten 650 bietet eine nähere Betrachtung der jeweiligen Komponenten des Knotens 600, wenn er als Teil einer Rechenvorrichtung (z. B. als mobiles Gerät, Basisstation, Server, Gateway usw.) implementiert ist. Der Edge-Computing-Knoten 650 kann eine beliebige Kombination der hier genannten Hardware- oder logischen Komponenten enthalten und kann ein beliebiges Gerät enthalten, das mit einem Edge-Kommunikationsnetz oder einer Kombination solcher Netze verwendet werden kann, oder mit diesem gekoppelt sein. Die Komponenten können als integrierte Schaltungen (ICs), Teile davon, diskrete elektronische Geräte oder andere Module, Befehlssätze, programmierbare Logik oder Algorithmen, Hardware, Hardware-Beschleuniger, Software, Firmware oder eine Kombination davon im Edge-Computing-Knoten 650 implementiert werden, oder als Komponenten, die anderweitig in ein Gehäuse eines größeren Systems eingebaut sind.
Die Edge-Rechenvorrichtung 650 kann Verarbeitungsschaltungen in Form eines Prozessors 652 enthalten, bei dem es sich um einen Mikroprozessor, einen Multi-Core-Prozessor, einen Multithreading-Prozessor, einen Ultra-Niederspannungsprozessor, einen eingebetteten Prozessor, x-PU/DPU/IPU/NPU, eine spezielle Verarbeitungseinheit, eine spezialisierte Verarbeitungseinheit oder andere bekannte Verarbeitungselemente handeln kann. Der Prozessor 652 kann Teil eines System-on-Chip (SoC) sein, bei dem der Prozessor 652 und andere Komponenten in einer einzigen integrierten Schaltung oder einem einzigen Gehäuse untergebracht sind, wie z. B. die Edison™- oder Galileo™-SoC-Boards der Intel Corporation, Santa Clara, Kalifornien. Der Prozessor 652 kann beispielsweise ein Intel® Architecture Core™-basierter CPU-Prozessor sein, wie ein Quark™, ein Atom™, ein i3, ein i5, ein i7, ein i9 oder ein Prozessor der MCU-Klasse oder ein anderer von Intel® erhältlicher Prozessor. Es kann jedoch eine beliebige Anzahl anderer Prozessoren verwendet werden, z. B. von Advanced Micro Devices, Inc. (AMD®) aus Sunnyvale, Kalifornien, ein MIPSO-basiertes Design von MIPS Technologies, Inc. aus Sunnyvale, Kalifornien, ein ARM®-basiertes Design, das von ARM Holdings, Ltd. oder einem Kunden davon lizenziert wurde, oder deren Lizenznehmer oder Adoptoren. Zu den Prozessoren können Einheiten wie ein A5-A13-Prozessor von Apple® Inc., ein Snapdragon™-Prozessor von Qualcomm® Technologies, Inc. oder ein OMAP™-Prozessor von Texas Instruments, Inc. gehören. Der Prozessor 652 und die zugehörigen Schaltungen können in einem Formfaktor mit einem Sockel, einem Formfaktor mit mehreren Sockeln oder in einer Vielzahl anderer Formate bereitgestellt werden, einschließlich begrenzter Hardware-Konfigurationen oder Konfigurationen, die weniger als alle in 6B gezeigten Elemente enthalten.
Der Prozessor 652 kann mit einem Systemspeicher 654 über eine Zwischenverbindung 656 (z. B. einen Bus) kommunizieren. Es kann eine beliebige Anzahl von Speichergeräten verwendet werden, um eine bestimmte Menge an Systemspeicher bereitzustellen. Bei dem Speicher 654 kann es sich beispielsweise um einen Direktzugriffsspeicher (RAM) handeln, der einem Entwurf des Joint Electron Devices Engineering Council (JEDEC) wie den DDR- oder mobilen DDR-Standards (z. B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4) entspricht. In besonderen Beispielen kann eine Speicherkomponente einem von der JEDEC veröffentlichten DRAM-Standard entsprechen, wie JESD79F für DDR SDRAM, JESD79-2F für DDR2 SDRAM, JESD79-3F für DDR3 SDRAM, JESD79-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 Speichervorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. In verschiedenen Ausführungen können die einzelnen Speicherbausteine aus einer beliebigen Anzahl verschiedener Gehäusetypen bestehen, wie z. B. Single Die Package (SDP), Dual Die Package (DDP) oder Quad Die Package (Q17P). In einigen Beispielen können diese Geräte direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit geringerem Profil zu bieten, während in anderen Beispielen die Geräte als ein oder mehrere Speichermodule konfiguriert sind, die wiederum über einen bestimmten Anschluss mit der Hauptplatine verbunden sind. Es kann eine beliebige Anzahl von anderen Speicherimplementierungen verwendet werden, wie z. B. andere Arten von Speichermodulen, z. B. Dual-Inline-Speichermodule (DIMMs) verschiedener Sorten, einschließlich, aber nicht beschränkt auf microDIMMs oder MiniDIMMs.
Um eine dauerhafte Speicherung von Informationen wie Daten, Anwendungen, Betriebssystemen usw. zu ermöglichen, kann ein Massenspeicher 658 auch über die Verbindung 656 mit dem Prozessor 652 gekoppelt werden. In einem Beispiel kann der Massenspeicher 658 durch ein Solid-State-Laufwerk (SSDD) realisiert werden. Andere Geräte, die für die Speicherung 658 verwendet werden können, sind Flash-Speicherkarten wie Secure Digital (SD)-Karten, microSD-Karten, extreme Digital (XD)-Fotokarten und dergleichen sowie USB-Flash-Laufwerke (Universal Serial Bus). In einem Beispiel kann die Speichervorrichtung ein Chalkogenidglas, ein NAND-Flash-Speicher mit mehreren Schwellenwerten, ein NOR-Flash-Speicher, ein Einstufen- oder Mehrstufen-Phasenänderungsspeicher (PCM), ein resistiver Speicher, ein Nanodrahtspeicher, ein ferroelektrischer Transistor-Random-Access-Memory (FeTRAM), ein antiferroelektrischer Speicher, ein magnetoresistiver Random-Access-Memory-Speicher (MRAM), der die Memristor-Technologie beinhaltet, sein oder umfassen, Widerstands-Speicher, der die Metalloxid-Basis, die Sauerstoff-Vakanz-Basis und die leitende Brücke Random Access Memory (CB-RAM) enthält, oder Spin-Transfer-Torque (STT)-MRAM, eine auf einem spintronischen magnetischen Übergang (magnetic junction) basierende Vorrichtung, eine auf einem magnetischen Tunnelübergang (MTJ) basierende Vorrichtung, eine auf DW (Domain Wall) und SOT (Spin Orbit Transfer) basierende Vorrichtung, eine auf einem Thyristor basierende Speichervorrichtung oder eine Kombination aus einem der oben genannten, oder ein anderer Speicher.
In stromsparenden Implementierungen kann der Massenspeicher 658 ein On-Die-Speicher oder ein mit dem Prozessor 652 verbundenes Register sein. In einigen Beispielen kann der Massenspeicher 658 jedoch auch mit einem Mikro-Festplattenlaufwerk (HDD) realisiert werden. Darüber hinaus kann eine beliebige Anzahl neuer Technologien für den Massenspeicher 658 zusätzlich zu den beschriebenen Technologien oder an deren Stelle verwendet werden, wie z. B. Widerstandsänderungsspeicher, Phasenänderungsspeicher, holografische Speicher oder chemische Speicher, um nur einige zu nennen.
Die Komponenten können über das Interconnect 656 kommunizieren. Die Verbindung 656 kann eine beliebige Anzahl von Technologien umfassen, einschließlich der Industriestandardarchitektur (ISA), der erweiterten ISA (EISA), der Peripheral Component Interconnect (PCI), der Peripheral Component Interconnect Extended (PCIx), PCI Express (PCIe) oder einer beliebigen Anzahl anderer Technologien. Bei der Verbindung 656 kann es sich um einen proprietären Bus handeln, der beispielsweise in einem SoC-basierten System verwendet wird. Es können auch andere Bus-Systeme verwendet werden, z. B. eine I2C-Schnittstelle (Inter-Integrated Circuit), eine SPI-Schnittstelle (Serial Peripheral Interface), Punkt-zu-Punkt-Schnittstellen und ein Energiebus.
Die Verbindung 656 kann den Prozessor 652 mit einem Transceiver 666 koppeln, um mit den angeschlossenen Edge-Geräten 662 zu kommunizieren. Der Transceiver 666 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie z. B. Übertragungen mit 2,4 Gigahertz (GHz) nach dem IEEE 802.15.4-Standard, nach dem Bluetooth® Low Energy (BLE)-Standard, wie er von der Bluetooth® Special Interest Group definiert wurde, oder nach dem ZigBee®-Standard, neben anderen. Für die Verbindungen zu den angeschlossenen Edge-Geräten 662 kann eine beliebige Anzahl von Funkgeräten verwendet werden, die für ein bestimmtes drahtloses Kommunikationsprotokoll konfiguriert sind. So kann beispielsweise eine WLAN-Einheit (Wireless Local Area Network) verwendet werden, um die Wi-Fi®-Kommunikation gemäß der Norm IEEE 802.11 (Institute of Electrical and Electronics Engineers) zu realisieren. Darüber hinaus kann die drahtlose Weitverkehrskommunikation, z. B. nach einem zellularen oder einem anderen drahtlosen Weitverkehrsprotokoll, über eine WWAN-Einheit (Wireless Wide Area Network) erfolgen.
Der drahtlose Netzwerk-Transceiver 666 (oder mehrere Transceiver) kann unter Verwendung mehrerer Standards oder Funkgeräte für die Kommunikation in einem unterschiedlichen Bereich kommunizieren. Beispielsweise kann der Edge-Computing-Knoten 650 mit Geräten in der Nähe, z. B. in einem Umkreis von etwa 10 Metern, über einen lokalen Transceiver auf der Basis von Bluetooth Low Energy (BLE) oder einem anderen stromsparenden Funkgerät kommunizieren, um Strom zu sparen. Weiter entfernte Edge-Geräte 662, z. B. innerhalb von etwa 50 Metern, können über ZigBee® oder andere Funkgeräte mit mittlerer Leistung erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät mit unterschiedlicher Leistung oder über getrennte Transceiver erfolgen, z. B. einen lokalen Transceiver mit BLE und einen separaten Mesh-Transceiver mit ZigBee®.
Ein drahtloser Netzwerk-Transceiver 666 (z. B. ein Radio-Transceiver) kann enthalten sein, um mit Geräten oder Diensten in einer Cloud (z. B. einer Edge-Cloud 695) über lokale oder Weitverkehrsnetzprotokolle zu kommunizieren. Bei dem drahtlosen Netzwerk-Transceiver 666 kann es sich um einen Low-Power-Wide-Area (LPWA)-Transceiver handeln, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g entspricht. Der Edge-Computing-Knoten 650 kann über einen weiten Bereich mittels LoRaWAN™ (Long Range Wide Area Network) kommunizieren, das von Semtech und der LoRa Alliance entwickelt wurde. Die hier beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl anderer Cloud-Transceiver verwendet werden, die eine Kommunikation mit großer Reichweite und geringer Bandbreite ermöglichen, wie z. B. Sigfox und andere Technologien. Darüber hinaus können auch andere Kommunikationstechniken, wie z. B. das in der Spezifikation IEEE 802.15.4e beschriebene zeitgesteuerte Kanal-Hopping, verwendet werden.
Zusätzlich zu den hier beschriebenen Systemen für den drahtlosen Netzwerk-Transceiver 666 kann eine beliebige Anzahl anderer Funkverbindungen und Protokolle verwendet werden. Der Transceiver 666 kann zum Beispiel einen zellularen Transceiver enthalten, der Spreizspektrum-Kommunikation (SPA/SAS) zur Implementierung von Hochgeschwindigkeitskommunikation verwendet. Darüber hinaus kann eine beliebige Anzahl anderer Protokolle verwendet werden, z. B. Wi-Fi®-Netzwerke für die Kommunikation mit mittlerer Geschwindigkeit und die Bereitstellung von Netzwerkkommunikation. Der Transceiver 666 kann Funkgeräte enthalten, die mit einer beliebigen Anzahl von 3GPP-Spezifikationen (Third Generation Partnership Project) kompatibel sind, wie z. B. Long Term Evolution (LTE) und 5G-Kommunikationssysteme (5th Generation), die am Ende der vorliegenden Offenbarung näher erläutert werden. Ein Netzwerk-Schnittstellencontroller (NIC) 668 kann enthalten sein, um eine drahtgebundene Kommunikation mit Knoten der Edge-Cloud 695 oder mit anderen Geräten, wie den angeschlossenen Edge-Geräten 662 (z. B. in einem Mesh), zu ermöglichen. Die drahtgebundene Kommunikation kann über eine Ethernet-Verbindung erfolgen oder auf anderen Netzwerktypen basieren, wie z. B. Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET und vielen anderen. Eine zusätzliche Netzwerkkarte (NIC 668) kann eingebaut werden, um die Verbindung zu einem zweiten Netzwerk zu ermöglichen, z. B. eine erste NIC 668, die die Kommunikation mit der Cloud über Ethernet ermöglicht, und eine zweite NIC 668, die die Kommunikation mit anderen Geräten über eine andere Art von Netzwerk ermöglicht.
In Anbetracht der verschiedenen Arten der Kommunikation zwischen dem Gerät und einer anderen Komponente oder einem Netzwerk kann die von dem Gerät verwendete Kommunikationsschaltung eine oder mehrere der Komponenten 664, 666, 668 oder 670 enthalten oder von diesen verkörpert werden. Dementsprechend können in verschiedenen Beispielen geeignete Mittel zur Kommunikation (z. B. Empfang, Übertragung usw.) durch solche Kommunikationsschaltungen verkörpert werden.
Der Edge-Computing-Knoten 650 kann eine Beschleunigungsschaltung 664 enthalten oder mit dieser gekoppelt sein, die durch einen oder mehrere Beschleuniger für künstliche Intelligenz (AI), einen neuronalen Compute-Stick, neuromorphe Hardware, einen FPGA, eine Anordnung von GPUs, eine Anordnung von x-PUs/DPUs/IPU/NPUs, ein oder mehrere SoCs, eine oder mehrere CPUs, einen oder mehrere digitale Signalprozessoren, dedizierte ASICs oder andere Formen spezialisierter Prozessoren oder Schaltungen, die für die Ausführung einer oder mehrerer spezieller Aufgaben ausgelegt sind, verkörpert werden kann. Diese Aufgaben können die Verarbeitung von künstlicher Intelligenz (einschließlich maschinellem Lernen, Training, Schlussfolgerungen und Klassifizierungsoperationen), die Verarbeitung visueller Daten, die Verarbeitung von Netzwerkdaten, die Objekterkennung, die Regelanalyse oder dergleichen umfassen. Diese Aufgaben können auch die spezifischen Edge-Computing-Aufgaben für das Dienstmanagement und den Dienstbetrieb umfassen, die an anderer Stelle in diesem Dokument behandelt werden.
Die Verbindung 656 kann den Prozessor 652 mit einem Sensor-Hub oder einer externen Schnittstelle 670 koppeln, die zum Anschluss weiterer Geräte oder Subsysteme dient. Die Geräte können Sensoren 672 enthalten, wie z. B. Beschleunigungsmesser, Füllstandssensoren, Durchflusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren des globalen Navigationssystems (z. B. GPS), Drucksensoren, Luftdrucksensoren und dergleichen. Der Knotenpunkt oder die Schnittstelle 670 kann außerdem dazu verwendet werden, den Edge-Computing-Knoten 650 mit Aktuatoren 674 zu verbinden, z. B. mit Leistungsschaltern, Ventilaktuatoren, einem akustischen Signalgeber, einer optischen Warnvorrichtung und dergleichen.
In einigen optionalen Beispielen können verschiedene Eingabe-/Ausgabegeräte (E/A) im Edge-Computing-Knoten 650 vorhanden oder mit ihm verbunden sein. So kann beispielsweise ein Display oder ein anderes Ausgabegerät 684 zur Anzeige von Informationen, wie z. B. Sensormesswerte oder Aktuatorposition, vorgesehen werden. Ein Eingabegerät 686, wie z. B. ein Touchscreen oder ein Tastenfeld, kann zur Annahme von Eingaben vorgesehen werden. Ein Ausgabegerät 684 kann eine beliebige Anzahl von Audio- oder visuellen Anzeigeformen umfassen, einschließlich einfacher visueller Ausgaben wie binäre Statusanzeigen (z. B. Leuchtdioden (LEDs) und visuelle Ausgaben mit mehreren Zeichen) oder komplexerer Ausgaben wie Bildschirme (z. B. Flüssigkristallbildschirme (LCD)), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb des Edge-Computing-Knotens 650 generiert oder erzeugt wird. Eine Anzeige- oder Konsolen-Hardware kann im Zusammenhang mit dem vorliegenden System verwendet werden, um Ausgaben eines Edge-Computing-Systems bereitzustellen und Eingaben zu empfangen, Komponenten oder Dienste eines Edge-Computing-Systems zu verwalten, den Zustand einer Edge-Computing-Komponente oder eines Dienstes zu ermitteln oder eine beliebige andere Anzahl von Management- oder Verwaltungsfunktionen oder Dienstnutzungsfällen durchzuführen.
Eine Batterie 676 kann den Edge-Computing-Knoten 650 mit Strom versorgen, obwohl er in Beispielen, in denen der Edge-Computing-Knoten 650 an einem festen Standort montiert ist, über eine an ein Stromnetz gekoppelte Stromversorgung verfügen kann, oder die Batterie kann als Reserve oder für vorübergehende Funktionen verwendet werden. Die Batterie 676 kann eine Lithium-Ionen-Batterie oder eine Metall-Luft-Batterie wie eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen sein.
Ein Batterie-Überwachungs-/Ladegerät 678 kann in den Edge-Computing-Knoten 650 integriert werden, um den Ladezustand (SoCh) der Batterie 676 zu überwachen, falls vorhanden. Das Batterie-Überwachungs-/Ladegerät 678 kann zur Überwachung anderer Parameter der Batterie 676 verwendet werden, um Ausfallprognosen zu erstellen, z. B. des Gesundheitszustands (SoH) und des Funktionszustands (SoF) der Batterie 676. Das Batterie-Überwachungs-/Ladegerät 678 kann eine integrierte Schaltung zur Batterieüberwachung enthalten, wie z. B. einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor aus Phoenix, Arizona, oder ein IC aus der UCD90xxx-Familie von Texas Instruments aus Dallas, TX. Das Batterie-Überwachungs-/Ladegerät 678 kann die Informationen über die Batterie 676 über die Verbindungsleitung 656 an den Prozessor 652 übermitteln. Das Batterie-Überwachungs-/Ladegerät 678 kann auch einen Analog-Digital-Wandler (ADC) enthalten, der es dem Prozessor 652 ermöglicht, die Spannung der Batterie 676 oder den Stromfluss von der Batterie 676 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Aktionen zu bestimmen, die der Edge-Computing-Knoten 650 durchführen kann, wie z. B. die Übertragungsfrequenz, den Mesh-Netzwerk-Betrieb, die Abtastfrequenz und dergleichen.
Ein Stromversorgungsblock 680 oder eine andere an ein Netz gekoppelte Stromversorgung kann mit dem Batterie-Überwachungs-/Ladegerät 678 verbunden werden, um die Batterie 676 zu laden. In einigen Beispielen kann der Leistungsblock 680 durch einen drahtlosen Leistungsempfänger ersetzt werden, um die Leistung drahtlos zu beziehen, z. B. über eine Ringantenne im Edge-Computing-Knoten 650. Eine drahtlose Batterieladeschaltung, wie z. B. ein LTC4020-Chip von Linear Technologies (Milpitas, Kalifornien), kann in das Batterie-Überwachungs-/Ladegerät 678 integriert werden. Die spezifischen Ladestromkreise können auf der Grundlage der Größe der Batterie 676 und damit des erforderlichen Stroms ausgewählt werden. Das Aufladen kann unter anderem nach dem von der Airfuel Alliance veröffentlichten Airfuel-Standard, dem vom Wireless Power Consortium veröffentlichten Qi-Standard oder dem von der Alliance for Wireless Power veröffentlichten Rezence-Ladestandard erfolgen.
Der Massenspeicher 658 kann Anweisungen 682 in Form von Software-, Firmware- oder Hardware-Befehlen zur Umsetzung der hier beschriebenen Techniken enthalten. Obwohl diese Anweisungen 682 als Codeblöcke im Speicher 654 und im Massenspeicher 658 dargestellt sind, kann jeder der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden, die beispielsweise in einer anwendungsspezifischen integrierten Schaltung (ASIC) eingebaut sind.
In einem Beispiel können die Anweisungen 682, die über den Speicher 654, den Massenspeicher 658 oder den Prozessor 652 bereitgestellt werden, als nichttransitorisches, maschinenlesbares Medium 660 verkörpert werden, das einen Code enthält, der den Prozessor 652 anweist, elektronische Operationen im Edge-Computing-Knoten 650 durchzuführen. Der Prozessor 652 kann über die Verbindungsleitung 656 auf das nicht transitorische, maschinenlesbare Medium 660 zugreifen. Das nicht-transitorische, maschinenlesbare Medium 660 kann beispielsweise durch die für den Massenspeicher 658 beschriebenen Geräte verkörpert werden oder spezifische Speichereinheiten wie Speichergeräte und/oder Speicherplatten umfassen, zu denen optische Platten (z. B., digital Versatile Disk (DVD), Compact Disk (CD), CD-ROM, Blu-ray-Disk), Flash-Laufwerke, Disketten, Festplatten (z. B. SSDs) oder eine beliebige Anzahl anderer Hardware-Vorrichtungen, in denen Informationen für eine beliebige Dauer gespeichert werden (z. B. für längere Zeiträume, dauerhaft, für kurze Zeiträume, zur vorübergehenden Zwischenspeicherung und/oder zum Caching). Das nicht transitorische, maschinenlesbare Medium 660 kann Anweisungen enthalten, die den Prozessor 652 anweisen, eine bestimmte Abfolge oder einen bestimmten Ablauf von Aktionen durchzuführen, wie sie beispielsweise in den oben dargestellten Flussdiagrammen und Blockdiagrammen von Operationen und Funktionen beschrieben sind. Die hier verwendeten Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ sind austauschbar. Der Begriff „nichtflüchtiges computerlesbares Medium“ wird hier ausdrücklich so definiert, dass er jede Art von computerlesbarem Speichermedium und/oder Speicherplatte einschließt und dass er die Übertragung von Signalen und Übertragungsmedien ausschließt.
Ebenfalls in einem spezifischen Beispiel können die Anweisungen 682 auf dem Prozessor 652 (separat oder in Kombination mit den Anweisungen 682 des maschinenlesbaren Mediums 660) die Ausführung oder den Betrieb einer vertrauenswürdigen Ausführungsumgebung (TEE) 690 konfigurieren. In einem Beispiel arbeitet die TEE 690 als geschützter Bereich, der dem Prozessor 652 für die sichere Ausführung von Befehlen und den sicheren Zugriff auf Daten zugänglich ist. Verschiedene Implementierungen der TEE 690 und ein zugehöriger sicherer Bereich im Prozessor 652 oder im Speicher 654 können z. B. durch die Verwendung von Intel® Software Guard Extensions (SGX) oder ARM® TrustZone® Hardware-Sicherheitserweiterungen, Intel® Management Engine (ME) oder Intel® Converged Security Manageability Engine (CSME) bereitgestellt werden. Andere Aspekte der Sicherheitshärtung, Hardware-Roots-of-Trust und vertrauenswürdige oder geschützte Operationen können in dem Gerät 650 durch die TEE 690 und den Prozessor 652 implementiert werden.
Während die in 6A und 6B dargestellten Beispiele beispielhafte Komponenten für einen Rechenknoten bzw. eine Rechenvorrichtung enthalten, sind die hier offenbarten Beispiele nicht darauf beschränkt. Wie hierin verwendet, kann ein „Computer“ einige oder alle der Beispielkomponenten von 6A und/oder 6B in verschiedenen Arten von Computerumgebungen enthalten. Beispiele für Computerumgebungen sind Edge-Computing-Geräte (z. B. Edge-Computer) in einer verteilten Netzwerkanordnung, bei der bestimmte teilnehmende Edge-Computing-Geräte heterogene oder homogene Geräte sind. Der hier verwendete Begriff „Computer“ kann einen Personalcomputer, einen Server, ein Benutzergerät, einen Beschleuniger usw., einschließlich beliebiger Kombinationen davon, umfassen. In einigen Beispielen umfasst die verteilte Vernetzung und/oder das verteilte Rechnen eine beliebige Anzahl solcher Edge-Computing-Geräte, wie in 6A und/oder 6B dargestellt, von denen jedes verschiedene Unterkomponenten, unterschiedliche Speicherkapazitäten, E/A-Fähigkeiten usw. umfassen kann. Da einige Implementierungen von verteilten Netzwerken und/oder verteiltem Rechnen mit bestimmten gewünschten Funktionen verbunden sind, enthalten die hier offenbarten Beispiele verschiedene Kombinationen von Komponenten, die in 6A und/oder 6B dargestellt sind, um die funktionalen Ziele von Aufgaben des verteilten Rechnens zu erfüllen. In einigen Beispielen umfasst der Begriff „Rechenknoten“ oder „Computer“ nur den Beispielprozessor 604, den Speicher 606 und das E/A-Subsystem 608 von 6A. In einigen Beispielen stützen sich eine oder mehrere Zielfunktionen einer verteilten Rechenaufgabe(n) auf ein oder mehrere alternative Geräte/Strukturen, die sich in verschiedenen Teilen einer Edge-Netzwerkumgebung befinden, wie z. B. Geräte für die Datenspeicherung (z. B. der beispielhafte Datenspeicher 610), Eingabe-/Ausgabefähigkeiten (z. B. das/die beispielhafte(n) periphere(n) Gerät(e) 614) und/oder Netzwerk-Kommunikationsfähigkeiten (z. B. die beispielhafte NIC 620).
In einigen Beispielen sind Computer, die in einer Umgebung mit verteilter Datenverarbeitung und/oder verteilten Netzwerken (z. B. einem Edge-Netzwerk) betrieben werden, so strukturiert, dass sie eine bestimmte Zielfunktionalität auf eine Art und Weise erfüllen, die Rechenzeitverschwendung reduziert. Da ein Computer beispielsweise eine Teilmenge der in 6A und 6B gezeigten Komponenten enthält, erfüllen solche Computer die Zielfunktionen des verteilten Rechnens, ohne eine Rechenstruktur zu enthalten, die anderenfalls ungenutzt und/oder unzureichend ausgelastet wäre. Der Begriff „Computer“, wie er hier verwendet wird, umfasst jede Kombination von Strukturen aus 6A und/oder 6B, die in der Lage sind, objektive Funktionen verteilter Datenverarbeitungsaufgaben zu erfüllen und/oder anderweitig auszuführen. In einigen Beispielen sind die Computer so strukturiert, dass die entsprechenden Zielfunktionen des verteilten Rechnens in Abhängigkeit von der dynamischen Nachfrage herunter- oder hochskaliert werden können. In einigen Beispielen werden verschiedene Computer im Hinblick auf ihre Fähigkeit, eine oder mehrere Aufgaben der verteilten Rechenanforderung(en) zu bearbeiten, aufgerufen und/oder anderweitig instanziiert, so dass jeder Computer, der in der Lage ist, die Aufgaben zu erfüllen, mit dieser Rechenaktivität fortfährt.
In den dargestellten Beispielen von 6A und 6B enthalten die Rechenvorrichtungen Betriebssysteme. Wie hierin verwendet, ist ein „Betriebssystem“ eine Software zur Steuerung von Beispiel-Rechengeräten, wie dem Beispiel-Edge-Rechenknoten 600 von 6A und/oder dem Beispiel-Edge-Rechenknoten 650 von 6B. Beispiele für Betriebssysteme sind unter anderem verbraucherbasierte Betriebssysteme (z. B. Microsoft® Windows® 10, Google® Android® OS, Apple® Mac® OS usw.). Zu den beispielhaften Betriebssystemen gehören auch, aber nicht ausschließlich, branchenorientierte Betriebssysteme wie Echtzeitbetriebssysteme, Hypervisoren usw. Ein beispielhaftes Betriebssystem auf einem ersten Edge-Computing-Knoten kann dasselbe oder ein anderes sein als ein beispielhaftes Betriebssystem auf einem zweiten Edge-Computing-Knoten. In einigen Beispielen ruft das Betriebssystem alternative Software auf, um eine oder mehrere Funktionen und/oder Operationen zu erleichtern, die nicht systemeigen sind, wie z. B. bestimmte Kommunikationsprotokolle und/oder Interpreter. In einigen Beispielen instanziiert das Betriebssystem verschiedene Funktionen, die dem Betriebssystem nicht eigen sind. In einigen Beispielen weisen Betriebssysteme unterschiedliche Grade an Komplexität und/oder Fähigkeiten auf. Ein erstes Betriebssystem, das einem ersten Edge-Computing-Knoten entspricht, umfasst beispielsweise ein Echtzeitbetriebssystem mit besonderen Leistungserwartungen hinsichtlich der Reaktionsfähigkeit auf dynamische Eingabebedingungen, und ein zweites Betriebssystem, das einem zweiten Edge-Computing-Knoten entspricht, umfasst grafische Benutzerschnittstellenfunktionen zur Erleichterung der E/A für den Endbenutzer.
Die Anweisungen 682 können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über den drahtlosen Netzwerk-Transceiver 466 unter Verwendung eines beliebigen Übertragungsprotokolls eines drahtlosen lokalen Netzwerks (WLAN) (z. B. Frame Relay, Internet Protocol (IP), Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP) usw.) gesendet oder empfangen werden. Beispiele für Kommunikationsnetze können ein lokales Netzwerk (LAN), ein Weitverkehrsnetz (WAN), ein Paketdatennetz (z. B. das Internet), Mobilfunknetze (z. B. zellulare Netze), POTS-Netze (Plain Old Telephone) und drahtlose Datennetze sein. Die Kommunikation über die Netzwerke kann ein oder mehrere verschiedene Protokolle umfassen, wie z. B. die Normenfamilie IEEE 802.11 (bekannt als Wi-Fi), die Normenfamilie IEEE 802.16, die Normenfamilie IEEE 802.15.4, die Normenfamilie Long Term Evolution (LTE), die Normenfamilie Universal Mobile Telecommunications System (UMTS), Peer-to-Peer-Netze (P2P), die Normen der nächsten Generation (NG)/5.
Beachten Sie, dass der hier verwendete Begriff „Schaltung“ sich auf Hardwarekomponenten wie eine elektronische Schaltung, eine Logikschaltung, einen Prozessor (gemeinsam, dediziert oder Gruppe) und/oder Speicher (gemeinsam, dediziert oder Gruppe), eine anwendungsspezifische integrierte Schaltung (ASIC), ein feldprogrammierbares Bauelement (FPD) (z. B., ein feldprogrammierbares Gate-Array (FPGA), ein programmierbares Logik-Bauelement (PLD), ein komplexes PLD (CPLD), ein PLD mit hoher Kapazität (HCPLD), ein strukturierter ASIC oder ein programmierbarer SoC), digitale Signalprozessoren (DSPs) usw., die so ausgebildet sind, dass sie die beschriebene Funktionalität bieten. In einigen Ausführungsformen können die Schaltungen ein oder mehrere Software- oder Firmware-Programme ausführen, um zumindest einige der beschriebenen Funktionen bereitzustellen. Der Begriff „Schaltung“ kann sich auch auf eine Kombination aus einem oder mehreren Hardwareelementen (oder einer Kombination von Schaltungen, die in einem elektrischen oder elektronischen System verwendet werden) mit dem Programmcode beziehen, der zur Ausführung der Funktionalität dieses Programmcodes verwendet wird. In diesen Ausführungsformen kann die Kombination aus Hardwareelementen und Programmcode als eine bestimmte Art von Schaltung bezeichnet werden.
Der Begriff „Prozessorschaltung“ oder „Prozessor“, wie er hier verwendet wird, bezieht sich somit auf eine Schaltung, die in der Lage ist, sequentiell und automatisch eine Folge von arithmetischen oder logischen Operationen auszuführen oder digitale Daten aufzuzeichnen, zu speichern und/oder zu übertragen, oder ist Teil einer solchen. Der Begriff „Prozessorschaltung“ oder „Prozessor“ kann sich auf einen oder mehrere Anwendungsprozessoren, einen oder mehrere Basisbandprozessoren, eine physische Zentraleinheit (CPU), einen Einkern- oder Mehrkernprozessor und/oder jedes andere Gerät beziehen, das in der Lage ist, computerausführbare Anweisungen wie Programmcode, Softwaremodule und/oder funktionale Prozesse auszuführen oder anderweitig zu betreiben.
Jede der hier beschriebenen Funkverbindungen kann nach einer oder mehreren der folgenden Funktechnologien und/oder -standards arbeiten, einschließlich, aber nicht beschränkt auf: eine GSM-Funktechnologie (Global System for Mobile Communications), eine GPRS-Funktechnologie (General Packet Radio Service), eine EDGE-Funktechnologie (Enhanced Data Rates for GSM Evolution) und/oder eine 3GPP-Funktechnologie (Third Generation Partnership Project), z. B. Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), 3GPP Long Term Evolution Advanced (LTE Advanced), Code division multiple access 2000 (CDMA2000), Cellular Digital Packet Data (CDPD), Mobitex, Third Generation (3G), Circuit Switched Data (CSD), High-Speed Circuit-Switched Data (HSCSD), Universal Mobile Telecommunications System (Third Generation) (UMTS (3G)), Wideband Code Division Multiple Access (Universal Mobile Telecommunications System) (W-CDMA (UMTS)), High Speed Packet Access (HSPA), High-Speed Downlink Packet Access (HSDPA), High-Speed Uplink Packet Access (HSUPA), High Speed Packet Access Plus (HSPA+), Universal Mobile Telecommunications System-Time-Division Duplex (UMTS-TDD), Time Division-Code Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-CDMA), 3rd Generation Partnership Project Release 8 (Pre-4th Generation) (3GPP Rel. 8 (Pre-4G)), 3GPP Rel. 9 (3rd Generation Partnership Project Release 9), 3GPP Rel. 10 (3rd Generation Partnership Project Release 10), 3GPP Rel. 11 (3rd Generation Partnership Project Release 11), 3GPP Rel. 12 (3rd Generation Partnership Project Release 12), 3GPP Rel. 13 (3rd Generation Partnership Project Release 13), 3GPP Rel. 14 (3rd Generation Partnership Project Release 14), 3GPP Rel. 15 (3rd Generation Partnership Project Release 15), 3GPP Rel. 16 (3rd Generation Partnership Project Release 16), 3GPP Rel. 17 (3rd Generation Partnership Project Release 17) und nachfolgende Releases (wie Rel. 18, Rel. 19, etc.), 3GPP 5G, 5G, 5G New Radio (5G NR), 3GPP 5G New Radio, 3GPP LTE Extra, LTE-Advanced Pro, LTE Licensed-Assisted Access (LAA), MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), Long Term Evolution Advanced (4. Generation) (LTE Advanced (4G)), cdmaOne (2G), Code division multiple access 2000 (Dritte Generation) (CDMA2000 (3G)), Evolution-Data Optimized oder Evolution-Data Only (EV-DO), Advanced Mobile Phone System (1st Generation) (AMPS (1G)), Total Access Communication System/Extended Total Access Communication System (TACS/ETACS), Digital AMPS (2nd Generation) (D-AMPS (2G)), Push-to-talk (PTT), Mobile Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), OLT (norwegisch für Offentlig Landmobil Telefoni, Öffentlicher Landmobilfunk), MTD (schwedische Abkürzung für Mobiltelefonisystem D), Public Automated Land Mobile (Autotel/PALM), ARP (finnisch für Autoradiopuhelin, „Autofunktelefon“), NMT (Nordic Mobile Telephony), High Capacity Version von NTT (Nippon Telegraph and Telephone) (Hicap), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Circuit Switched Data (CSD), Personal Handy-phone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (UMA), auch als 3GPP Generic Access Network oder GAN-Standard bezeichnet), Zigbee, Bluetooth(r), Wireless Gigabit Alliance (WiGig)-Standard, mmWave-Standards im Allgemeinen (drahtlose Systeme, die bei 10-300 GHz und darüber arbeiten, wie WiGig, IEEE 802.11ad, IEEE 802.11ay usw.), Technologien, die über 300 GHz und THz-Bänder arbeiten (3GPP/LTEbasiert oder IEEE 802.11p oder IEEE 802.11bd und andere), Fahrzeug-zu-Fahrzeug- (V2V) und Fahrzeug-zu-X- (V2X) sowie Fahrzeug-zu-Infrastruktur- (V2I) und Infrastruktur-zu-Fahrzeug- (I2V) Kommunikationstechnologien, 3GPP-Zellular-V2X, DSRC-Kommunikationssysteme (Dedicated Short Range Communications) wie Intelligent-TransportSysteme und andere (die typischerweise im Frequenzbereich von 5850 MHz bis 5925 MHz oder darüber arbeiten (typischerweise bis 5935 MHz nach den Änderungsvorschlägen im CEPT-Bericht 71)), das europäische ITS-G5-System (d. h. die europäische Variante von IEEE 802.11p und IEEE 802.1 1ay).d. h. die europäische Variante von IEEE 802.11p-basiertem DSRC, einschließlich ITS-G5A (d. h., Betrieb von ITS-G5 in europäischen ITS-Frequenzbändern für sicherheitsrelevante ITS-Anwendungen im Frequenzbereich 5,875 GHz bis 5,905 GHz), ITS-G5B (d. h. Betrieb in europäischen ITS-Frequenzbändern für nicht sicherheitsrelevante ITS-Anwendungen im Frequenzbereich 5,855 GHz bis 5,875 GHz), ITS-G5C (d. h., Betrieb von ITS-Anwendungen im Frequenzbereich 5,470 GHz bis 5,725 GHz)), DSRC in Japan im 700-MHz-Band (einschließlich 715 MHz bis 725 MHz), IEEE 802.11bdbasierte Systeme usw.
Die hier beschriebenen Aspekte können im Zusammenhang mit jedem Frequenzverwaltungssystem verwendet werden, einschließlich lizenzierter Frequenzen, unlizenzierter Frequenzen, lizenzfreier Frequenzen, (lizenzierter) gemeinsam genutzter Frequenzen (wie LSA = Licensed Shared Access in 2,3-2,4 GHz, 3,4-3,6 GHz, 3,6-3,8 GHz und weiteren Frequenzen und SAS = Spectrum Access System / CBRS = Citizen Broadband Radio System in 3,55-3,7 GHz und weiteren Frequenzen). Zu den anwendbaren Frequenzbändern gehören IMT-Frequenzen (International Mobile Telecommunications) sowie andere Arten von Frequenzen/Bändern, z. B. Bänder mit nationaler Zuweisung (einschließlich 450-470 MHz, 902-928 MHz (Hinweis: zugewiesen z. B. in den USA (FCC Part 15)), 863-868.6 MHz (Anmerkung: zugewiesen z. B. in der Europäischen Union (ETSI EN 300 220)), 915,9-929,7 MHz (Anmerkung: zugewiesen z. B. in Japan), 917-923,5 MHz (Anmerkung: zugewiesen z. B. in Südkorea), 755-779 MHz und 779-787 MHz (Anmerkung: zugewiesen z. B. in China), 790 - 960 MHz, 1710 - 2025 MHz, 2110 - 2200 MHz, 2300 - 2400 MHz, 2,4-2,4835 GHz (Hinweis: Es handelt sich um ein ISM-Band mit weltweiter Verfügbarkeit, das von der Wi-Fi-Technologiefamilie (11b/g/n/ax) und auch von Bluetooth genutzt wird), 2500 - 2690 MHz, 698 - 790 MHz, 610 - 790 MHz, 3400 - 3600 MHz, 3400 - 3800 MHz, 3,55 - 3,7 GHz (Hinweis: zugewiesen z. B. in den USA für Citizen Broadband Radio Service), 5,15 - 5,25 GHz und 5,25 - 5,35 GHz sowie 5,47 - 5,725 GHz und 5,725-5,85 GHz (Anmerkung: zugewiesen z.B. in den USA (FCC Teil 15), besteht aus vier U-NII-Bändern mit insgesamt 500 MHz Spektrum), 5,725-5,875 GHz (Anmerkung: zugewiesen z.B. in der EU (ETSI EN 301 893)), 5,47-5,65 GHz (Anmerkung: zugewiesen z.B. in Südkorea, 5925-7085 MHz und 5925-6425-MHz-Band (Anmerkung: wird in den USA bzw. der EU geprüft. Es wird erwartet, dass das Wi-Fi-System der nächsten Generation das 6-GHz-Spektrum als Betriebsband umfasst, aber es ist anzumerken, dass im Dezember 2017 das Wi-Fi-System in diesem Band noch nicht zugelassen ist. Die Regulierung wird voraussichtlich im Zeitrahmen 2019-2020 abgeschlossen sein), IMT-Advanced-Spektrum, IMT-2020-Spektrum (voraussichtlich 3600-3800 MHz, 3800-4200 MHz, 3,5-GHz-Bänder, 700-MHz-Bänder, Bänder im Bereich 24,25-86 GHz usw.), im Rahmen der 5G-Initiative „Spectrum Frontier“ der FCC verfügbar gemachtes Spektrum (einschließlich 27,5-28,35 GHz, 29,1-29,25 GHz, 31-31,3 GHz, 37-38,6 GHz, 38,6-40 GHz, 42-42.5 GHz, 57 - 64 GHz, 71 - 76 GHz, 81 - 86 GHz und 92 - 94 GHz, usw.), das ITS-Band (Intelligent Transport Systems) von 5,9 GHz (typischerweise 5,85 - 5,925 GHz) und 63 - 64 GHz, die derzeit für WiGig zugewiesenen Bänder wie WiGig Band 1 (57.24-59,40 GHz), WiGig-Band 2 (59,40-61,56 GHz) und WiGig-Band 3 (61,56-63,72 GHz) sowie WiGig-Band 4 (63,72-65,88 GHz), 57-64/66 GHz (Anmerkung: Dieses Band hat eine nahezu weltweite Bezeichnung für Multi-Gigabit Wireless Systems (MGWS)/WiGig. In den USA (FCC Teil 15) werden Frequenzen im Bereich von insgesamt 14 GHz zugewiesen, während die EU (ETSI EN 302 567 und ETSI EN 301 217-2 für feste P2P) Frequenzen im Bereich von insgesamt 9 GHz zuweist), das Band 70,2 GHz - 71 GHz, alle Bänder zwischen 65,88 GHz und 71 GHz, Bänder, die derzeit für Kfz-Radaranwendungen zugewiesen sind, wie z. B. 76-81 GHz, und künftige Bänder einschließlich 94-300 GHz und darüber. Darüber hinaus kann das System sekundär auf Bändern wie den TV-White-Space-Bändern (typischerweise unter 790 MHz) eingesetzt werden, wobei insbesondere die 400-MHz- und 700-MHz-Bänder vielversprechende Kandidaten sind. Neben zellularen Anwendungen können auch spezifische Anwendungen für vertikale Märkte wie PMSE (Programmerstellung und Sonderveranstaltungen), Medizin, Gesundheit, Chirurgie, Automobil, niedrige Latenzzeiten, Drohnen usw. angesprochen werden.
7 zeigt eine beispielhafte Software-Verteilungsplattform 705 zur Verteilung von Software, wie z. B. die beispielhaften computerlesbaren Anweisungen 682 von 6B, an ein oder mehrere Geräte, wie z. B. Prozessorplattform(en) 710 und/oder beispielhafte angeschlossene Edge-Geräte. Die beispielhafte Software-Verteilungsplattform 705 kann durch einen beliebigen Computerserver, eine Dateneinrichtung, einen Cloud-Dienst usw. implementiert werden, der in der Lage ist, Software zu speichern und an andere Computergeräte (z. B. Dritte, die beispielhaft angeschlossenen Edge-Geräte) zu übertragen. Bei den angeschlossenen Edge-Geräten kann es sich beispielsweise um Kunden, Clients, Verwaltungsgeräte (z. B. Server) oder Dritte (z. B. Kunden eines Unternehmens, das Eigentümer und/oder Betreiber der Software-Verteilungsplattform 705 ist) handeln. Die angeschlossenen Edge-Geräte können beispielsweise in kommerziellen und/oder Heimautomatisierungsumgebungen eingesetzt werden. In einigen Beispielen ist eine dritte Partei ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber von Software, wie z. B. die computerlesbaren Anweisungen 682 von 6B. Bei den Dritten kann es sich um Verbraucher, Nutzer, Einzelhändler, OEMs usw. handeln, die die Software zur Nutzung und/oder zum Weiterverkauf und/oder zur Vergabe von Unterlizenzen erwerben und/oder lizenzieren. In einigen Beispielen veranlasst die verteilte Software die Anzeige einer oder mehrerer Benutzeroberflächen (UIs) und/oder grafischer Benutzeroberflächen (GUIs), um ein oder mehrere Geräte (z. B. verbundene Edge-Geräte) zu identifizieren, die geografisch und/oder logisch voneinander getrennt sind (z. B. physisch getrennte IoT-Geräte, die mit der Steuerung der Wasserverteilung (z. B. Pumpen), der Stromverteilung (z. B. Relais) usw. beauftragt sind).
Im gezeigten Beispiel von 7 umfasst die Software-Verteilungsplattform 705 einen oder mehrere Server und ein oder mehrere Speichergeräte. Die Speichergeräte speichern die computerlesbaren Anweisungen 682. Der eine oder die mehreren Server der beispielhaften Software-Verteilungsplattform 705 stehen mit einem Netzwerk 715 in Verbindung, das einem oder mehreren der oben beschriebenen Internet- und/oder Beispielnetzwerke entsprechen kann. In einigen Beispielen reagieren der eine oder die mehreren Server auf Anfragen zur Übertragung der Software an eine anfragende Partei als Teil einer kommerziellen Transaktion. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenzierung der Software kann über den einen oder die mehreren Server der Software-Verteilungsplattform und/oder über eine dritte Zahlungsstelle abgewickelt werden. Die Server ermöglichen es den Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 682 von der Software-Verteilungsplattform 605 herunterzuladen. Beispielsweise kann die Software, die den beispielhaften computerlesbaren Anweisungen entsprechen kann, auf die beispielhafte(n) Prozessorplattform(en) 700 (z. B. beispielhafte angeschlossene Edge-Geräte) heruntergeladen werden, die die computerlesbaren Anweisungen 682 ausführen soll(en), um das Einfügen von Inhalten an einem Schalter zu implementieren. In einigen Beispielen sind ein oder mehrere Server der Software-Verteilungsplattform 705 kommunikativ mit einer oder mehreren Sicherheitsdomänen und/oder Sicherheitsvorrichtungen verbunden, durch die die Anfragen und Übertragungen der beispielhaften computerlesbaren Anweisungen 682 laufen müssen. In einigen Beispielen bieten, übertragen und/oder erzwingen ein oder mehrere Server der Software-Verteilungsplattform 705 regelmäßig Aktualisierungen der Software (z. B. die beispielhaften computerlesbaren Anweisungen 682 von 6B), um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Software an den Endbenutzergeräten angewendet werden.
In dem in 7 dargestellten Beispiel sind die computerlesbaren Anweisungen 682 auf den Speichergeräten der Software-Verteilungsplattform 705 in einem bestimmten Format gespeichert. Ein Format für computerlesbare Anweisungen umfasst unter anderem eine bestimmte Code-Sprache (z. B. Java, JavaScript, Python, C, C#, SQL, HTML usw.) und/oder einen bestimmten Code-Zustand (z. B. nicht kompilierter Code (z. B. ASCII), interpretierter Code, verknüpfter Code, ausführbarer Code (z. B. eine Binärdatei) usw.). In einigen Beispielen liegen die in der Software-Verteilungsplattform 705 gespeicherten computerlesbaren Anweisungen 682 in einem ersten Format vor, wenn sie an die beispielhafte(n) Prozessorplattform(en) 710 übertragen werden. In einigen Beispielen ist das erste Format eine ausführbare Binärdatei, in der bestimmte Typen der Prozessorplattform(en) 710 ausgeführt werden können. In einigen Beispielen handelt es sich bei dem ersten Format jedoch um nicht kompilierten Code, der eine oder mehrere Vorbereitungsaufgaben erfordert, um das erste Format in ein zweites Format umzuwandeln, damit es auf der/den beispielhaften Prozessorplattform(en) 710 ausgeführt werden kann. Die empfangende(n) Prozessorplattform(en) 710 müssen beispielsweise die computerlesbaren Anweisungen 682 im ersten Format kompilieren, um ausführbaren Code in einem zweiten Format zu erzeugen, der auf der/den Prozessorplattform(en) 710 ausgeführt werden kann. In wieder anderen Beispielen ist das erste Format ein interpretierter Code, der bei Erreichen der Prozessorplattform(en) 710 von einem Interpreter interpretiert wird, um die Ausführung von Anweisungen zu erleichtern.
8 ist ein Blockdiagramm, das ein serverloses Rechenzentrum 800 gemäß einer Ausführungsform zeigt. Das Rechenzentrum 800 ist in logische Blöcke von Diensten unterteilt. Zu den in 8 dargestellten Dienstblöcken gehören Allzweck-Rechendienste 802, Dienste für maschinelles Lernen (ML) und künstliche Intelligenz (AI) 804, Rechenspeicherdienste 806 und Beschleunigungsdienste 808. Die Dienstblöcke sind mit einer intelligenten Netzstruktur 810 gekoppelt.
Mit dieser Art von serverlosem Rechenzentrum 800 kann eine neue Art der Orchestrierung erreicht werden, die von den derzeitigen Praktiken zu einem zielgesteuerten Ansatz übergeht, bei dem der Kunde nur die Absicht äußert und der Orchestrierungsstapel selbst die Plattform einrichtet, um diese Absicht zu erreichen.
Einige bestehende Software-as-a-Service-(SaaS)-Modelle bieten ihren Kunden in der Regel eine Reihe von dienstleistungsspezifischen Dienstleistungsgütezielen (SLO). So kann eine Datenanalyseplattform beispielsweise eine bestimmte Anzahl von Aufträgen pro Stunde vorgeben, die berechnet werden können. Dies ist aus der Sicht des Benutzers großartig, erfordert aber immer noch, dass der SaaS-Anbieter SLOs präventiv den benötigten Ressourcen zuordnet, bevor er Anfragen an den Ressourcen-Orchestrator sendet. Die Dienstanbieter sind nicht in der Lage, automatisch Ressourcentypen auf der Grundlage von SLOs auszuwählen.
Die hier beschriebenen Systeme und Verfahren veranschaulichen, wie Absichten (Ziele) automatisch, dynamisch und direkt auf Plattformeinstellungen abgebildet werden können. Absichten werden als Ziele auf höherer Ebene empfangen und im gesamten Orchestrierungsstapel auf Einstellungen auf niedrigerer Ebene abgebildet.
Ein Beispiel: Eine Anwendung verlangt, dass ein bestimmter Prozentsatz innerhalb eines bestimmten Zeitfensters abgeschlossen wird, was hier als „P50-Latenz“ bezeichnet wird Es können auch andere Begriffe verwendet werden, die ähnlich lauten, wie z. B. „P50-Ziel“ oder „P50-Abschlüsse“, um anzugeben, dass Aufgaben, Projekte, Anfragen oder dergleichen in mindestens 50 % der Fälle rechtzeitig abgeschlossen werden müssen oder dass eine Wahrscheinlichkeit von mindestens 50 % besteht, dass die Aufgabe rechtzeitig abgeschlossen wird. Diese Absicht wird auf Einstellungen auf niedrigerer Ebene abgebildet, z. B. zur Angabe einer Priorität auf Thread-Ebene und von dort aus auf einen CPU-Cache-Weg/eine Profilzuweisung/eine Ressourcenzuweisung. Auf der Ein-/Ausgabeseite (E/A) kann die Absicht auf die Netzwerkeinstellungen abgebildet werden, um sicherzustellen, dass genügend Kommunikationsressourcen für die Übertragung und den Empfang der Anfrage und der Antwort zur Verfügung stehen.
Um sich dynamisch an veränderte Bedingungen anzupassen, verwenden die Systeme und Verfahren Regelkreise auf verschiedenen Ebenen der Architektur. Die Regelkreise können Kreditsysteme, Nutzen-/Kostenfunktionen, Planungs- und Lösungsmethoden usw. verwenden. Die Regelkreise können mit unterschiedlichen Geschwindigkeiten arbeiten, je nachdem, wie schnell sich das überwachte System anpassen muss. Solche Regelkreise sind besonders wichtig und nützlich, wenn es um die Dynamik von Rechensystemen geht. Zum Beispiel kann der Netzwerkverkehr täglich schwanken. Wenn die Kunden den Ressourcenbedarf selbst ändern müssen, entsteht für sie ein zusätzlicher Aufwand bei der Inanspruchnahme des Dienstleisters. Darüber hinaus können solche Änderungen schwierig sein, weil die Informationen, die für solche Entscheidungen benötigt werden, dem Kunden möglicherweise nicht zugänglich sind. Bei den hier beschriebenen Systemen und Verfahren muss der Kunde lediglich die Absicht angeben, und das System passt die Ressourcen automatisch an. Dies kann zu Kosteneinsparungen sowohl für den Kunden als auch für den Dienstanbieter führen.
Die Dynamik des Systems gilt auch für die Pläne, die erstellt werden. Diese Pläne haben eine zeitliche Komponente. Beispielsweise kann ein Plan vorübergehend (z. B. in der Größenordnung von Minuten) darauf abzielen, einer Arbeitslast eine Fülle von Ressourcen zuzuweisen, um eine SLA unter der Aufsicht eines schnellen Regelkreises einzuholen, und dann über einen längeren Zeitraum (z. B. monatlich) versuchen, ein akzeptables und erschwingliches Ressourcenzuweisungsmuster unter der Aufsicht eines langsameren Regelkreises zu erreichen. Der Plan kann entweder automatisch oder teilweise manuell ausgelöst werden, z. B. indem der Plan zunächst als Empfehlung an einen menschlichen Bediener gesendet wird, um eine menschliche Führung zu ermöglichen.
Darüber hinaus kann der zeitliche Aspekt eines Plans auch unter dem Gesichtspunkt der kontinuierlichen Verbesserung nützlich sein. Ein Plan, der alle SLOs im System der Systeme erfüllt, kann durch einen anderen Plan ersetzt werden, der ebenfalls alle SLOs erfüllt, aber eine andere Einrichtung, Konfiguration oder Reihe von Richtlinien auslöst. Zur Vorbereitung von Wartungsarbeiten kann ein SLO beispielsweise Ressourcen effizienter nutzen, Platz für neue Arbeitslasten/Dienste schaffen oder dergleichen.
Mit einer dezentralisierten dienstorientierten Plattform nimmt die Komplexität der Orchestrierung noch weiter zu. Die hier beschriebenen Systeme und Verfahren befassen sich mit der Orchestrierung über mehrere Standorte hinweg, die sich im Besitz verschiedener Akteure befinden können. Die einzelnen Teile können Verhandlungen und Koordinierung durchführen, um eine übergreifende Absicht zu erreichen, was von entscheidender Bedeutung ist, wenn es keine zentralisierte Orchestrierung gibt.
In einer Implementierung kann ein Dienstanbieter eine Recheneinheit (z. B. einen Pod) mit Anwendungskontext-Metadaten bereitstellen, so dass der Knoten in einem schnellen Regelkreis angemessenere Anwendungsentscheidungen treffen und sich möglicherweise dafür entscheiden kann, eine Arbeitslast mit niedriger Priorität nicht zu depriorisieren, weil sie sich auf die gesamte Lebensdauer auswirkt. Dies erfordert jedoch eine E2E-Sichtweise und beinhaltet Begriffe wie Co-Scheduling und Co-Priorisierung von Knoten, die Sicherheitsfunktionen für Daten (einschließlich Datenprovenienz, Compliance und Aufzeichnung) mit anderen Rechenknoten, die Operationen in höheren Schichten des Stacks durchführen, bereitstellen müssen. In Kubernetes ist ein Pod die kleinste einsetzbare Recheneinheit, die Sie erstellen und verwalten können. Ein Pod ist eine Gruppe von einem oder mehreren Containern mit gemeinsamen Speicher- und Netzwerkressourcen und einer Spezifikation für die Ausführung der Container. Die Inhalte eines Pods werden immer in einem gemeinsamen Kontext ausgeführt und gemeinsam eingeplant.
Mit dem Übergang zu absichtsgesteuerten Systemen konzentriert sich das System auf die Frage, ob Ressourcen potenziell verfügbar gemacht werden können und wie das System neu konfiguriert werden kann, um sie verfügbar zu machen, statt auf die Bereitstellungsfunktion. Die Ressourcen können von unterschiedlichem Typ sein, obwohl sie der gleichen Kategorie angehören: z. B. Hochleistungsprozessoren (z. B. Intel® Xeon-CPUs) gegenüber mehreren rechenschwachen Prozessoren (z. B. Xeon-Ds) oder eine einzelne große XPU gegenüber mehreren kleineren XPUs. Außerdem kann eine Ressource selbst verschiedene Arten von Unterressourcen/Komponenten enthalten, z. B. effiziente und leistungsfähige Kerne usw.
In einigen Implementierungen löst das System die Herausforderung der administrativen Verwaltung komplexer, verteilter Infrastrukturen, indem es den Administratoren von Clustern und Infrastrukturen eine an Dienstleistungsgütezielen orientierte Steuerung an die Hand gibt und sie von der Last befreit, möglicherweise fehlerhafte Konfigurationsdetails auf niedriger Ebene angeben zu müssen. Ein Admin-Richtlinien-Controller und ein Admin-Richtlinien-Übersetzungsmodul können in der Orchestrierungsarchitektur implementiert werden, und ein Arbeitsablauf zur Verwaltung mehrerer Ebenen von absichtsgesteuerten Admin-Richtlinien kann im Arbeitsablauf zur Bereitstellung von Arbeitslasten verwendet werden. Es kann ein geschlossener Regelkreis für die Verwaltungspolitik verwendet werden, einschließlich der Frage, wie sie durch mehrfache Iterationen bei zwingenden Konfigurationen erreicht werden kann. Sie kann die Platzierung und Neuverteilung der Arbeitslast bei sich ändernden Richtlinien oder bei Nichteinhaltung von Richtlinien beeinflussen.
Das System kann ein neues Modell für die Steuerung des Kubernetes-Lebenszyklusmanagements (LCM) implementieren, das die Bedürfnisse der Anwendung und nicht die Annahmen des Kubernetes-Administrators widerspiegelt. Die Anwendung wird vorübergehend bereitgestellt (zur Unterstützung des Schnellstarts) und anschließend wird eine neue Kubernetes-Instanz mit den Richtlinien auf Cluster- und Knotenebene bereitgestellt, die den Anforderungen der Anwendung besser entspricht. Die Arbeitslast wird anschließend auf den neuen Cluster verschoben.
Die derzeitigen Verfahren zur gemeinsamen Nutzung von Ressourcen wie Cache Allocation Technology (CAT) und Memory Bandwidth Allocation (MBA) sowie zur Energieversorgung beruhen darauf, dass die KPIs der Anwendung von einem bestimmten dynamischen Controller (z. B. Resource Management Daemon (RMD), Dynamic Resource Controller (DRC), Appqos usw.) überwacht werden oder dass Telemetry Aware Scheduling eingesetzt wird, um die Erschöpfung der Ressourcen zu bewältigen. Ein in die Orchestrierung integrierter „Ressourcenanforderungsmakler“ kann ein nachrichtenbasiertes System haben, das unabhängig von den Anwendungs-KPI ist (die von der Anwendung selbst überwacht werden). Der Makler kann einen lokalen Agenten auf der Plattform haben, da Zeit ein Faktor bei der Aufteilung ist, und kann lokale Entscheidungen auf der Grundlage einer Cluster-„Freigabe“-Richtlinie treffen. Einzelne Pods können sich für statische Verträge, „garantierte Ressourcenverträge“, Verträge mit gleichen Anteilen oder dynamische (Ausschreibungs-)Verträge entscheiden. Konkurrierende Anfragen werden durch den lokalen Makleragenten vermittelt, der ein Gebots-/Angebotsschema anwenden kann, z. B. „Ich bin bereit, Ressource X für Ressource Y für den Zeitraum N aufzugeben“.
Sicherheitsrisiken entstehen, wenn Komponenten über mehrere Ressourcen verteilt sind. Bei der absichtsbasierten Orchestrierung kann das System, ähnlich wie bei den QoS-Klassen, den Nutzern die Möglichkeit geben, zu definieren, wie „empfindlich“ sie gegenüber bestimmten Aspekten der Sicherheit oder des Vertrauens in der Umgebung sind bzw. wie viel Risiko sie bereit sind, in Kauf zu nehmen. Das System kann eine Reihe zusätzlicher Komponenten zur Orchestrierungs-Steuerungsebene enthalten, um Risiken zu überwachen, zu analysieren und auf sie zuzugreifen, sowie eine Komponente, die in der Lage ist, die Bewertung in eine Reihe von Richtlinien, Ressourcenzuweisungen usw. umzusetzen.
9 ist ein Blockdiagramm, das eine Betriebsumgebung 900 mit mehreren Hardwaresystemen 902A und 902B gemäß einer Ausführungsform zeigt. Die Betriebsumgebung 900 kann als ein „System von Systemen“ betrachtet werden, das sich in Nord-Süd-Richtung (z. B. der gesamte Stapel) und in Ost-West-Richtung (z. B. E2E) erstreckt. Auf jeder Ebene in einem System 902A oder 902B können verschiedene Arten von Absichten von Norden nach Süden oder von Osten nach Westen auf SLOs abgebildet werden. SLOs auf verschiedenen Ebenen im Stapel können in Bildern pro Sekunde (FPS), Latenz, Anweisungen pro Zyklus (IPC) usw. beschrieben werden. SLOs zwischen Unternehmen oder Systemen können in Bezug darauf beschrieben werden, wie die einzelnen Anwendungen, aus denen der Dienst besteht, interagieren müssen, um die Gesamtziele zu erreichen. Die E2E-SLOs können beispielsweise eine P99-Latenz < 100 ms, eine maximale Frontend-Latenz von 10 ms, eine Backend-Latenz von 5 ms, eine maximale Caching-Latenz von 10 ms usw. beinhalten. Um die Ziele von Full-Stack-SLOs und E2E-SLOs zu erreichen, setzt das System Richtlinien von höheren Schichten zu niedrigeren Schichten durch und koordiniert oder verhandelt systemübergreifend zwischen Komponenten innerhalb einer Schicht.
SLOs, entweder Full-Stack oder E2E (z. B. von System zu System), können im Laufe der Zeit variiert werden, mit einer Spanne ausgedrückt werden (z. B. ein minimaler und maximaler zulässiger Wert), eine Abweichung oder Varianz außerhalb der Spanne für eine bestimmte Zeitspanne zulassen, als bevorzugt oder unter Verwendung anderer Prioritätsschemata ausgedrückt werden, oder dergleichen. Ein Beispiel könnte sein, dass die Aufgabe 99 % der Zeit während 60 Minuten P99-konform sein muss, wobei 10 ms nicht überschritten werden dürfen und eine bevorzugte Konformitätsstufe von 5 ms gilt.
In einigen Implementierungen werden auf einem Knoten eine Reihe von Sidecars verwendet, die mit ihrer Arbeitslast verbunden sind. Die Sidecars koordinieren sich, um sicherzustellen, dass der Knotenpunkt, die Plattform, die Einrichtungen usw. korrekt eingerichtet sind, damit die Ziele ihrer Arbeitslast erreicht werden können. Die Sidecars können eine bestimmte Einrichtung überwachen und die korrekten Richtlinien durchsetzen, die korrekten Ressourcen zuweisen, die Einstellungen so anpassen, dass die Ziele der Pods erreicht werden können usw.
In einigen Installationen besteht die Herausforderung darin, die vom Orchestrierungssystem beschlossene Ressourcenzuweisung mit Gebühren-/Abrechnungsbeschränkungen zu versehen, wenn für eine Arbeitslast Eingabeparameter auf der Grundlage von Dienstleistungsgütezielen vorliegen. Zwei neue Komponenten ermöglichen Intent Driven Charging und Intent Driven Billing: 1) Charging Guardrails-Funktion und 2) SLO Planning-Funktion. Das Konzept einer Charging Guardrails-Funktion wird in den Deployment-Workflow eingeführt, der einen logisch zentralen Punkt in der Orchestrierungsarchitektur darstellt. Er ist für die Steuerung und Führung der SLO-orientierten Ressourcenplanungskomponente verantwortlich, um sicherzustellen, dass die zugewiesenen Ressourcen für den Benutzer erschwinglich sind. Die SLO-Planungsfunktion muss die Kostenbasis für zugewiesene Ressourcen berücksichtigen und nicht nur deren Eignung für die wahrscheinliche Einhaltung der Arbeitslast-SLA.
10 ist ein Blockdiagramm, das eine Orchestrierungs-Steuerungsebene 1000 gemäß einer Ausführungsform darstellt. Die Orchestrierungs-Steuerungsebene 1000 ist über eine Anwendungsprogrammierschnittstelle (API) 1002 zugänglich oder konfigurierbar. Einstellungen, Daten oder andere Informationen können in einer Datenbank 1004 gespeichert werden. Die Orchestrierungs-Steuerungsebene 1000 umfasst Ressourcenmanager 1006, Controller 1008, Scheduler 1010, einen Planer 1012, einen Monitor 1014, ein Modul zur kontinuierlichen Verbesserung (CIM) 1016 und einen Beobachtbarkeitsstapel 1018. Der Planer 1012, CIM 1016, Monitor 1014 oder andere Komponenten der Orchestrierungs-Steuerungsebene 1000 können auf Daten in einer Wissensdatenbank 1020 zugreifen oder diese speichern. Die Wissensdatenbank 1020 kann verschiedene Daten enthalten, die z. B. als Eingabe für den Planer oder die Scheduler dienen. Die Wissensdatenbank 1020 kann Informationen zur Netztopologie enthalten, die zur Bestimmung der Platzierung von Aufgaben und der Nutzung von Ressourcen verwendet werden können.
Der Planer 1012 kann mit einer fest verdrahteten Schaltung, einem programmierbaren Hardware-Baustein (z. B. einem ASIC) oder als Anweisungen, die auf einer Hardware-Plattform (z. B. einer allgemeinen CPU) ausgeführt werden, implementiert werden. Der Planer 1012 kann konfiguriert, entworfen, programmiert oder anderweitig angepasst werden, um Absichten oder Ziele auf SLOs abzubilden. Der Planer 1012 kann auch SLOs in umsetzbare Pläne aufschlüsseln. Der Planer 1012 kann verwendet werden, um SLO-Anforderungen automatisch in geeignete Pod-Spezifikationen zu übersetzen oder abzubilden, die Ressourcenanforderungen, Plattformmerkmale oder Richtlinien für die Bereiche Datenverarbeitung, Netzwerk, Speicher und Einrichtungen (z. B. Energie) umfassen können. Bei der Zuordnung von Zielen zu Richtlinien und Zielvorgaben auf unterer Ebene können heuristische Mechanismen, Mechanismen des maschinellen Lernens (ML) oder der künstlichen Intelligenz (AI), Charakterisierungen der Arbeitslast (z. B. abgeleitet aus Online-Daten oder durch Offline-Experimente oder durch Sandboxing) oder Richtlinien von Ressourceneigentümern eingesetzt werden, um die Nutzung des Systems des Eigentümers zu steuern.
Der Planer 1012 kann außerdem zur Koordinierung von System zu System (z. B. E2E) mit einem anderen Planer 1022 verwendet werden und mehrere Points-of-Presence (PoPs) abbilden, die potenziell verschiedenen Beteiligten gehören. Es können verschiedene Arten von Koordinierungs- und Verhandlungsverfahren verwendet werden. Beispielsweise kann ein Modell der Multiple-Attribute-Utility-Theorie (MAUT) verwendet werden, um die Ressourcenzuweisung auszuhandeln.
Der Planer 1012 überwacht die Umsetzung von Absichten in Handlungsrichtlinien, Systemeinstellungen, Ressourcenanforderungen und dergleichen. Dies geschieht auf der Grundlage der in der Wissensdatenbank 1020 gespeicherten Erkenntnisse. Sobald ein Plan verfügbar ist, wird er von den Schedulern 1010 umgesetzt und durchgesetzt.
Ein Plan kann mit mehreren SLOs auf verschiedenen Ebenen in der Orchestrierungs-Steuerungsebene 1000 definiert werden. So können beispielsweise SLOs auf höheren Ebenen der Orchestrierungs-Steuerungsebene 1000 zur Regulierung und Steuerung von FPS und SLOs auf niedrigeren Ebenen der Orchestrierungs-Steuerungsebene 1000 zur Regulierung und Steuerung von IPC verwendet werden. Anbieter, Nutzer und Dienstanbieter können SLOs in einem standardisierten Format definieren. SLOs können auch Leitplanken enthalten, die eine gewisse Abweichung von den Ziel- oder Grenzwerten vorsehen. So kann beispielsweise eine Leitplanke eine 10 %-ige Überschreitung der P95 für bis zu 10 Minuten zulassen. Leitplanken können auch bedingt sein. So kann eine Leitplanke beispielsweise eine 10 %-ige Überschreitung von P95 für bis zu 10 Minuten zulassen, wenn das System danach die Einhaltung von P99 garantiert.
Mit zunehmender Heterogenität von Recheneinrichtungen und XPU-Umgebungen können die Orchestrierungs- und Ressourcenmanager der unteren Ebenen so konfiguriert werden, dass sie Co-Scheduling und Co-Priorisierung von Arbeitslasten auf einer sehr granularen Ebene unterstützen.
Bei der Zuordnung von Aufgaben zu Ressourcen ist das Platzierungsproblem schwer zu lösen. Im Gegensatz zur clusterbasierten Planung ermöglicht dieses System die Neupriorisierung lokaler Ressourcen auf der Grundlage der Nähe des Vorgangs zum erforderlichen Fertigstellungstermin. Lastausgleich und automatische Skalierungsmaßnahmen, die lokal an Graphen-Engpässen eingeleitet werden, ohne dass sie von einem zentralen Scheduler gesteuert werden müssen. Diese Aktionen sind auch zeitlich begrenzt, im Vergleich zu dauerhaften Anweisungen eines zentralisierten oder hierarchischen Schedulers.
Einige Ressourcen, wie z. B. Prozessoren, können so koordiniert werden, dass der Energieverbrauch optimiert wird. Die Leistungsstufen des Prozessors (z. B. PL1, PL2, PL3 usw.) werden zur Festlegung des Schwellenwertes für die Leistungsaufnahme verwendet. Die Systemplattform passt diese PL-Werte und andere Leistungswerte (Kappung, P-Status, Uncore-Frequenz) kontinuierlich und feinkörnig an. Da es sich hierbei jedoch um eine komplexe Zuordnung handelt, da die Übertragungsfunktion, die Leistung und SLAs miteinander verbindet, stark zeit- und situationsabhängig ist, werden die Anpassungen durch vortrainierte Modelle gesteuert. Die vortrainierten Modelle verwenden als Eingaben verschiedene aus Zeitreihen abgeleitete Trendsignale über Auslastung und Leistung, und es kann sich im Allgemeinen um Modelle handeln, die auf grobkörnige Arten von Arbeitslastmischungen (z. B. „AI“, „gRPC heavy“, „media“ usw.) trainiert wurden.
Wenn der Kunde bei der Registrierung von Funktionen Speicherzugriffsabsichten äußert, liefern diese Registrierungsabsichten der Infrastrukturebene genügend Kontext, um eine effiziente Datenbewegung von der Speicherebene zur Funktion zu ermöglichen. Dies geschieht entweder durch die Planung der Funktion direkt neben den Daten, durch den Einsatz von Rechenbeschleunigern auf Servern, die die Daten enthalten, oder durch die Verwendung effizienter Datenübertragungsmechanismen innerhalb von oder zwischen Servern. Der entscheidende Punkt ist, dass dies erreicht wird, ohne dass die Funktion spezifische Kenntnisse über den Standort des Servers benötigt oder spezielle Rechenressourcen oder Übertragungsmechanismen programmieren muss. Die Terminierung/Platzierung ist eine Funktion, die am Anfang eines Prozesses steht. Da die Zugriffsmuster zum Zeitpunkt der Bereitstellung möglicherweise nicht offensichtlich sind, implementiert dieses System auch eine Laufzeitbewertung der Datenlokalisierung und der Übertragungsraten und nutzt diese Erkenntnisse, um automatische Umplanungsereignisse auszulösen, z. B. Histogramme, die zeigen, welche Funktion/welcher Mikrodienst für die Verarbeitung welcher Art von Daten geeignet ist.
Das CIM 1016 sucht nach Möglichkeiten, den laufenden Betrieb effizienter zu gestalten, analysiert Kompromisse oder Änderungen in der Politik und ist für die Vorhersage des zukünftigen Verhaltens des Systems zuständig. Diese Vorhersage ist der Schlüssel zu einer vorausschauenden Planung. Es kann entweder eine reaktive oder eine proaktive Planung mit verschiedenen Zeitskalen verwendet werden (um die verschiedenen Schnell/Langsam-Schleifen zu erfüllen).
Der Monitor 1014 erhält Eingaben vom Beobachtbarkeitsstapel 1018 und verwendet diese Informationen, um den Planer 1012 und das CIM 1016 zu speisen oder auszulösen. Darüber hinaus ist der Beobachtbarkeitsstapel 1018 dafür verantwortlich, dass die Erkenntnisse, Heuristiken usw. in der Wissensdatenbank 1020 durch Online- und Offline-Lernprozesse korrekt sind. Das Offline-Lernen kann durch eine experimentelle Charakterisierung der Arbeitslast erreicht werden. Der Beobachtbarkeitsstapel 1018 kann Trainingsdaten sammeln, damit sich die Architektur durch Analysen, die die gesammelten Daten nutzen, selbst weiterentwickelt. Die Trainingsdaten können von realen Daten abgeleitet werden, die von Monitoren aufgezeichnet wurden. Alternativ können die Trainingsdaten auch offline aufbereitet und dem Beobachtbarkeitsstapel 1018 zugeführt werden. Der Einsatz eines CIM 1016 bietet den Vorteil, dass das System kontinuierlich verbessert werden kann und sich selbst anpasst, selbst heilt und optimiert.
Um eine kontinuierliche Verbesserung zu erreichen, können mehrere Regelkreise implementiert werden. 11 ist ein Blockdiagramm, das den Daten- und Steuerfluss in einem Orchestrierungssystem gemäß einer Ausführungsform veranschaulicht. Absichtsbasierte SLOs werden von einem SLO-Übersetzer 1102 empfangen, der die übersetzten SLOs an einen Dienstmonitor 1104 weiterleitet. Der SLO-Übersetzer 1102 kann eine Instanz, eine Komponente oder ein Bestandteil des Planers 1012 sein. Der Dienstmonitor 1104 kann eine Instanz, eine Komponente oder ein Bestandteil des Monitors 1014 sein.
Der SLO-Übersetzer 1102 kann eine Datenbank mit Regeln und Wörterbüchern (z. B. die Wissensdatenbank 1020) verwenden, um das absichtsbasierte SLO auf drei Aspekte abzubilden: 1) Überwachungsparameter, 2) Konfigurationsparameter und 3) Zeitbereichsparameter.
Die Überwachungsparameter werden vom Dienstmonitor 1104 bei der Überwachung von Diensten, Aufgaben oder Jobs verwendet. Zu den Überwachungsparametern können eine Reihe flexibler Leitplanken und die erforderliche Telemetrie gehören, damit der Dienstmonitor 1104 die Vorgänge aktiv überwachen kann.
Leitplanken können eine zeitlich und räumlich begrenzte Flexibilität bieten, so dass sie kontextsensitiv und situationsadaptiv werden. Die Leitplanken, die für die Funktion eines Orchestrators gelten, können sich daher sehr langsam, aber nahtlos verschieben, um die Maximierung eines wünschenswerten End-to-End-Ziels durch eine Reihe von lokalisierten Ausweichmöglichkeiten zu ermöglichen. Die Idee ist, drei wichtige Flexibilitäten zu erreichen: a) man nimmt die härteste Einschränkung - wie die P99.9-Latenz - und erlaubt ihr, sich von einem festen Schwellenwert in einen Schwellenwertbereich zu bewegen, sagen wir +10 Prozent für eine kurze Zeitspanne, um später durch eine noch bessere P99.9 Latenz für einen längeren Zeitraum zu kompensieren, b) eine möglicherweise kostspielige Anpassung der Ressourcenzuweisung zu einem bestimmten Zeitpunkt um eine bestimmte Zeitspanne zu verschieben und in der Zwischenzeit die Leitplanken aufzuweichen, so dass zufriedenstellende Lösungen weiterhin ausgeführt werden können, und c) eine umfassendere Reaktion des Systems auf Notfälle, Anforderungen usw. zu ermöglichen, um mit vorübergehenden Ausfällen in anderen Teilen eines Rechenzentrums fertig zu werden, die eine flexiblere gemeinsame Nutzung von Ressourcen erfordern, bis die Reparatur und der anschließende Normalbetrieb wieder aufgenommen werden können.
Bei den derzeitigen Verfahren für Leitplanken werden Schwellenwerte und die Integration über einen vordefinierten Zeitraum verwendet, um einen Leitplankenübergang und die anschließende Sanierung zu bewerten. Durch die Möglichkeit, Leitplanken „zustandsbasiert“ oder „kontextbasiert“ zu machen, können harte Beschränkungen unter bestimmten Bedingungen aufgeweicht werden. Beispielsweise kann die CPU-Auslastung bei der ersten Bereitstellung der Arbeitslast einen Spitzenwert erreichen, da die Arbeitslast Daten zwischenspeichert, aber nach dieser Zeit kann eine übermäßige CPU-Auslastung im normalen Betrieb eine Leitplankenüberschreitung auslösen. Das System fügt Wissen über den Kontext hinzu, einschließlich Life Cycle Staging, In-Service-Upgrades, HA-Failover, Service-Mesh-Neustarts usw. als kontextbezogene Informationen zur Implementierung von Leitplanken.
Die Konfigurationsparameter werden von Orchestratoren und Ressourcenmanagern zur Konfiguration von Rechen-, Netzwerk-, Speicher- und anderen Ressourcen verwendet. Die Konfigurationsparameter können als eine Reihe von Orchestrierungszielen ausgedrückt werden, die dem Orchestrierungssystem auf höchster Ebene zugeführt und von jeder unteren Schicht des Orchestrierungsstapels in eine Reihe von Unterzielen umgewandelt werden. Am unteren Ende des Orchestrierungsstapels befinden sich physische Hardwarekomponenten, die mit einer feinkörnigen Steuerung abgestimmt werden können. So kann eine Reihe von Ressourcencontrollern Richtlinien auf der Rechenplattform durchsetzen. Bei der Rechenplattform kann es sich um eine CPU, GPU, FPGA, einen Beschleuniger, eine IPU oder eine andere Art von Verarbeitungsvorrichtung handeln.
Die Zeitbereichsparameter werden zur Konfiguration der Regelkreise verwendet, um die Überwachungszyklen und die Häufigkeit von Änderungen der Konfigurationsparameter festzulegen. Der SLO-Übersetzer 1102 erzeugt Zeitbereiche für die SLO-Überwachung, die von der Nicht-Echtzeit-Überwachung bis zur Echtzeit-Überwachung reichen. Die Zeitbereiche spezifizieren strenge Überwachungs- und Orchestrierungsreaktionszeiten für das entsprechende SLO. Die Zeitbereiche sind in 11 in subjektiver Terminologie als „langsamer“, „langsam“ und „schneller“ dargestellt, können aber in jedem beliebigen Zeitmaß angegeben werden, wie z. B. Mikrosekunden, Stunden, Tage oder dergleichen, je nach den Anforderungen, die der SLO-Übersetzer 1102 dem Zeitbereich zuordnet. Diese Zeitbereichsparameter können feststehen, automatisch aktualisiert werden oder separat konfigurierbar sein.
Der Dienstmonitor 1104 hat Schichten, die E2E-Telemetrie 1106, Nicht-Echtzeit-Telemetrie 1108, echtzeitnahe Telemetrie oder Echtzeit-Telemetrie 1110 überwachen. Jede Schicht hat einen entsprechenden Regelkreis, der unterschiedliche Parameter im Zeitbereich haben kann.
Der SLO-Übersetzer 1102 wandelt die Absichten in „Dienststufenüberwachung“ für E2E, langsame Ressourcenüberwachung und schnelle Ressourcenüberwachung um. Auf der Grundlage von Regeln, Richtlinien und gelernten Erkenntnissen ordnet der SLO-Übersetzer 1102 die Absicht einem oder mehreren Dienstmonitoren zu, die auf der Grundlage der Art der Absicht, der erforderlichen Reaktionsgeschwindigkeit oder anderer Anforderungen instanziiert werden können. Der SLO-Übersetzer 1102 konfiguriert die Dienstmonitore so, dass sie Benachrichtigungen an Entitäten im Orchestrierungsstapel liefern, wenn die „physischen SLAs“ oder „physischen SLOs“ außerhalb der Grenzen liegen. Dienstmonitore können klassische Service-Assurance-Lösungen zur Überwachung von E2E-SLAs mit passiven oder aktiven Sonden, softwaredefinierten Vernetzungs-(SDN)-Controllern oder SDN-Analysesystemen umfassen. Schnellere Dienstmonitore können je nach Bedarf auf den Plattformen platziert werden, um die von dem zugeordneten SLO geforderte Reaktionszeit zu erreichen.
Das System kann Verfahren zur intelligenten Beobachtung einsetzen, z. B. beim Einsatz von Komponenten, und wie die Überwachung automatisch an der richtigen Stelle eingesetzt werden kann. Nach dem Einsatz der Komponenten kann das System Teil des Regelkreises sein, der eine automatische SLW-Sanierung ermöglicht. Wenn eine Abhilfemaßnahme erforderlich ist, stellt das System sicher, dass ausreichende Kontrollen vorhanden sind, um eine wirksame Abhilfemaßnahme zu ergreifen, die sich nicht ungewollt auf andere Dienste auswirkt.
Wie in 11 dargestellt, kann die absichtsbasierte Orchestrierung mit Hilfe einer Hierarchie von Orchestratoren 1112-1114 implementiert werden. Ein Standard-Orchestrator ermöglicht es dem Benutzer, eine Anwendung als einen Satz von Komponenten und Anforderungen für die Landung dieser Komponenten auf Plattformen zu beschreiben. Hierarchische Orchestrierung kann verwendet werden, um ein Problem in Teile zu zerlegen und zu verteilen, wobei ein Sub-Orchestrator für die Planung einer Teilmenge der Anwendung auf einer Teilmenge von Knoten und ein anderer Sub-Orchestrator für die Planung einer anderen Teilmenge der Anwendung auf einer anderen Teilmenge von Knoten verantwortlich ist.
Im Gegensatz zur standardmäßigen imperativen Orchestrierung kann die absichtsbasierte Orchestrierung aktiviert werden, indem der Benutzer als Teil der Anforderungen einer Komponente eine Absicht beschreiben kann. Hierbei handelt es sich um einen deklarativen Mechanismus, bei dem der Benutzer ein gewünschtes Ergebnis angibt. Anstatt also bestimmte Regeln oder Parameter (wie bei imperativen Mechanismen) anzugeben, kann der Benutzer ein gewünschtes Ergebnis angeben. Ein Beispiel wäre die Erreichung eines bestimmten Verfügbarkeitsniveaus oder einer maximalen Verarbeitungslatenz, für die mehrere Instanzen auf Knoten mit bestimmten Eigenschaften bereitgestellt werden können, um dieses Ziel zu erreichen. Eine Absicht ist ein deklarativer Ausdruck.
Anstatt die absichtsbasierte Orchestrierung tief in den Scheduler eines Standard-Orchestrators zu integrieren, kann ein absichtsbasierter Scheduling-Algorithmus in einem Sub-Orchestrator eingesetzt werden. In diesem Fall kann der Top-Level-Standard-Orchestrator, wenn er die Anwendungsbeschreibung erhält, eine Absicht erkennen, die für eine oder mehrere Komponenten der Anwendung angegeben ist. Sie kann einen absichtsbasierten Sub-Orchestrator mit der Planung dieser Komponenten beauftragen. Jeder absichtsbasierte Orchestrator oder Sub-Orchestrator kann sich auf die Erfüllung bestimmter Arten von Absichten spezialisieren. Der absichtsbasierte Sub-Orchestrator kann das Problem weiter in andere Sub-Orchestratoren aufteilen.
Nehmen wir zum Beispiel eine Videoanalyse-Pipeline, die aus einem Aufnahme-, einem Verarbeitungs- und einem Betätigungsschritt besteht. Die Gesamtanwendung besteht aus einer Aufnahmekomponente für jede Kamera, einem Verarbeitungsschritt mit einer Latenzzeit von höchstens 100 ms und einer Betätigungskomponente für jeden Aktor. Der Top-Level-Orchestrator kann die Bereitstellung der Einnahme- und Betätigungskomponenten übernehmen. Die Verarbeitung könnte an einen absichtsbasierten Orchestrator übergeben werden, der bestimmt, wie viele Verarbeitungskomponenten benötigt werden, um die Last auszugleichen und die gewünschte Latenzzeit zu erreichen. Der absichtsbasierte Orchestrator kann die Aufgabe sogar an zusätzliche Sub-Orchestratoren weitergeben, so dass mehrere Cluster von Knoten verwendet werden, um die Absicht zu erreichen (oder um vielleicht eine zusätzliche Absicht der Hochverfügbarkeit auf Clusterebene zu ermöglichen).
Dieser Ansatz hat mehrere Vorteile. Erstens ist es nicht notwendig, die komplexe Entscheidungsfindung bestehender Scheduling-Algorithmen in bestehenden Orchestratoren mit der ebenso komplexen Entscheidungsfindung der absichtsbasierten Orchestrierung zusammenzuführen. Jeder kann für die wichtigsten Teile des Problems verwendet werden. Darüber hinaus ermöglicht die verteilte Entscheidungsfindung, die Entscheidung in die Nähe der Verarbeitung zu verlagern. Dies kann zu einer schnelleren Reaktionsfähigkeit führen, was z. B. schnelle Regelkreise in industriellen Anwendungsfällen ermöglicht.
In verschiedenen Ausführungsformen ist ein übergeordneter Orchestrator so konfiguriert, programmiert oder anderweitig angepasst, dass er Absichten von einem Kunden empfängt, erkennt, wann eine absichtsbasierte Sub-Orchestrierung erforderlich ist, und Interaktionen zwischen dem übergeordneten Orchestrator und Sub-Orchestratoren definiert. Der Top-Level-Orchestrator kann ein Standard-Orchestrator sein und die Sub-Orchestratoren können ein absichtsbasierter Orchestrator sein, wie er in 10 beschrieben ist. Durch die Verwendung einer Hierarchie von Orchestratoren wird das Problem nach unten verlagert, wobei zwischen dem übergeordneten Orchestrator und dem Sub-Orchestrator eine SLA vereinbart wird. Der Sub-Orchestrator kann dem anfordernden Orchestrator mitteilen, wenn er die SLA nicht mehr einhalten kann.
Um diese Organisation der Orchestratoren zu erreichen, sollten Absichten so ausgedrückt werden, dass sie mit Standard-Orchestratoren kompatibel sind, und diese Standard-Orchestratoren sollten in der Lage sein zu erkennen, wann eine absichtsbasierte Sub-Orchestrierung erforderlich ist. Zwischen dem anfragenden Orchestrator und den Sub-Orchestratoren, die zur Erfüllung der Anforderungen des anfragenden Orchestrators eingesetzt werden, kann ein Protokoll verwendet werden.
Wenn eine Anwendung in Komponenten aufgeteilt ist, die separat orchestriert werden, können diese außerdem Ordnungsabhängigkeiten aufweisen, die sich auf die Gesamtorchestrierung auswirken. Wo solche Ordnungsabhängigkeiten vorhanden sind, können sie abstrakt beschrieben werden. In einem Anwendungsfall eines Erzeuger-Verbraucher-Flusses kann z. B. festgelegt werden, dass die erzeugende Komponente X Dateneinheiten, Ereignisse, Frames usw. vor der verbrauchenden Komponente bereithalten soll. Dementsprechend können die Sub-Orchestratoren für jede Komponente bedingte Zuständigkeiten für die Ressourcenzuweisung haben (der Verbraucher benötigt zum Zeitpunkt T0 weniger Ressourcen als zum Zeitpunkt T0+delta, während der Produzent zum Zeitpunkt T0-delta mehr Ressourcen benötigt als zum Zeitpunkt T0). Diese „Ressourcenflüsse“ werden zwischen den Sub-Orchestratoren eng koordiniert, so dass der Produzent und der Konsument in unserem Beispiel gemeinsam einen X-Anteil der CPU, des Cache, der Speicherbandbreite usw. erhalten, wobei die Ressourcen jedoch nahtlos entsprechend der choreografierten Aufteilung zwischen ihnen fließen. Ebenso müssen Prioritätsumkehrungen verhindert werden; so kann ein Erzeuger zwar eine niedrigere Priorität haben, weil der Verbraucher sich bemüht, aufzuholen und den Abstand zum Erzeuger zu verringern, aber wenn der Verbraucher den Abstand weiterhin so schnell verringert, dass der Erzeuger nun darum kämpfen muss, vorne zu bleiben, dann ist es sinnvoll, dass die Prioritäten als Funktion des Abstands schnell zwischen den beiden fließen, anstatt dass die Planungssoftware aufwändig eingestellt werden muss.
Um die geforderten Absichten/Ziele zu erreichen, kann der Bedarf an Beschleunigungstechnologie (FPGAs, GPUs usw.) sowie an Hardwarefunktionen zur Unterstützung des Gesamtaufbaus (z. B. DRC) implementiert werden. Häufig führen Beschleuniger und XPUs Operationen aus, die der Entwickler des CPU-Codes nicht direkt über Anweisungen steuern kann. So können sensible Operationen, die mit einem bestimmten Hardware-Privileg in einem Beschleuniger oder einer XPU oder auf eine für gewöhnliche Software undurchsichtige Weise in höheren Ebenen des Stapels durchgeführt werden, die Sicherheitsgrenzen vereinfachen, die anderenfalls eine gemeinsame Planung von Sicherheitsfilterungsoperationen erfordern würden. Außerdem müssen untergeordnete Funktionen die verschiedenen Regelkreise darüber informieren, was in schnellen Regelkreisen geschieht. Diese Art der Berichterstattung erfordert Erweiterungen bzw. die Verwendung von Beobachtbarkeitsrahmen für die Verfolgung, Protokollierung und Überwachung.
12 ist ein Flussdiagramm, das ein Verfahren 1200 zur Implementierung einer absichtsbasierten Orchestrierung gemäß einer Ausführungsform darstellt. Bei 1202 wird ein absichtsbasiertes Dienstleistungsgüteziel (SLO) für die Ausführung einer Aufgabe bei einem Orchestrator empfangen.
Bei 1204 wird das SLO einer Vielzahl von Richtlinien zugeordnet. Die Zuordnung kann auf einer statischen Karte basieren. Alternativ kann die Zuordnung auch mit Hilfe von Heuristiken oder anderen intelligenten Mechanismen erfolgen.
Bei 1206 wird die Vielzahl von Richtlinien an eine Vielzahl von Sub-Orchestratoren verteilt, wobei jeder der Vielzahl von Sub-Orchestratoren die Ausführung eines Teils der Aufgabe verwaltet. Richtlinien können nach Typ, Ressource oder anderen Faktoren gruppiert oder getrennt werden. Die Sub-Orchestratoren können für eine Gruppe von Ressourcen, einen Ressourcentyp, einen bestimmten Knoten oder eine Gruppe von Knoten oder dergleichen zuständig sein.
In 1208 wird die Ausführung der Aufgabe überwacht. Die Überwachung von Aufgaben kann durch die Definition von KPIs von Interesse und die wiederkehrende Erfassung von Daten zu diesen KPIs erfolgen.
In 1210 wird auf der Grundlage der Überwachung eine Abhilfemaßnahme eingeleitet. Zu den Abhilfemaßnahmen können Vorgänge wie Migration, Ressourcenzuweisung oder -freigabe, Neustart oder Aussetzen eines Prozesses, Containers, Pods oder Mikrodienste oder dergleichen gehören.
Wie bereits erwähnt, ist das Platzierungsproblem bei der Zuweisung von Aufgaben zu Ressourcen schwierig zu lösen. Datenflussdiagramme sind eine beliebte Methode zur Darstellung der Ausführungssequenzen von Berechnungsblöcken und der Daten- und Kontrollabhängigkeiten zwischen den Berechnungsblöcken. Berechnungsblöcke treten mit unterschiedlicher Granularität auf (z. B. Schritte, Prozeduren, Ketten von Prozeduren usw.), und ohne Verlust an Allgemeinheit wird in dieser Offenlegung der Begriff „Aufgabe“ verwendet, um sich auf Berechnungsblöcke mit unterschiedlicher Granularität zu beziehen. Ebenso wird der Begriff „Graph“ ohne jede Einschränkung verwendet, wenn er sich auf einen Kontroll- und Datenfluss-Abhängigkeitsgraph bezieht. Graphen werden häufig zur abstrakten Beschreibung verschiedener algorithmischer Komponenten verwendet, die beim maschinellen Lernen, bei der Big-Data-Analyse, der Signalverarbeitung und zunehmend auch bei der Vernetzung eingesetzt werden, wobei die Knoten des Graphen den Verarbeitungsprimitiven entsprechen und die Kanten des Graphen den Steuerfluss und/oder die Datenabhängigkeiten beschreiben.
13 ist ein Diagramm 1300, das Aufgaben gemäß einer Ausführungsform darstellt. Der Graph 1300 enthält die Punkte M1-M9, die Aufgaben darstellen, und Kanten zwischen den Punkten, die Abhängigkeiten zwischen den Punkten der Aufgaben darstellen. Die Werte an den Eckpunkten stellen den Arbeitsaufwand dar, den die Aufgabe in Anspruch nehmen könnte, wenn die Verarbeitungsressourcen der Aufgabe vollständig zugewiesen würden. Der Arbeitsaufwand kann ein normalisierter Wert von Zeiteinheiten zur Erledigung der Aufgabe sein, wobei eine Referenzverarbeitungseinheit (z. B. eine CPU, XPU, IPU usw.) verwendet wird. Die Referenzverarbeitungseinheit kann zum Beispiel ein Xeon 6280 von Intel Corporation sein.
Die Kanten in dem in 13 dargestellten Beispiel stellen den Kommunikationsaufwand dar, der unter Verwendung einer Referenznetzverbindung auf Zeiteinheiten normiert wurde, um von einem Knotenpunkt zum nächsten zu gelangen. Der Kommunikationsaufwand kann verschiedene Aspekte der Übertragung umfassen, einschließlich, aber nicht beschränkt auf die zu übertragende Datenmenge, den Zeitaufwand für die Netzwerkverarbeitung, das Routing, den Auf- und Abbau der Kommunikation, die Verschlüsselung, die Entschlüsselung oder die Koordinierung.
Selbst mit der Art von Modell, die durch das in 13 dargestellte Diagramm bereitgestellt wird, ist die Einhaltung diverser SLAs über viele unterschiedliche Anforderungen verschiedener Rechenketten über ein gemeinsames Rechenzentrum und eine Edge-Infrastruktur ein sehr komplexes Problem. Bisherige Implementierungen versuchen, mit einer Mischung aus zentraler Planung und hierarchischer Planung eine effiziente Lösung zu finden. Um die strengen SLA-Anforderungen zu erfüllen, lassen Dienstanbieter wie Cloud-Service-Provider (CSPs) und Kommunikationsdienstleister (CoSPs) daher oft einen großen Spielraum zwischen den geschätzten und den budgetierten Ressourcen. Unter Schlupf versteht man dann die Differenz zwischen den Ressourcen, die einer Aufgabe gemäß den Bedingungen eines SLA/SLO zur Verfügung stehen, und den verbrauchten oder budgetierten Ressourcen, die für die Nutzung durch die Aufgabe reserviert sind. Oftmals wird ein CSP oder CoSP deutlich mehr Kapazitäten bereitstellen, um sicherzustellen, dass die SLOs erfüllt werden. Erschwerend kommt hinzu, dass die Entwickler oder Betreiber von Lösungen nicht in der Lage sind, die Infrastrukturebenen auf die beabsichtigten SLAs auszurichten, was bedeutet, dass das Erreichen eines bestimmten SLA-Ziels (SLO) eine Übung in Versuch und Irrtum ist. Einige Tenants in öffentlichen Clouds müssen daher ständig abwägen und entscheiden, ob sie bei einem bestimmten Basisinstanztyp mit bekanntem Leistungs-Kosten-Profil bleiben oder höhere Kosten zahlen und auf andere Instanztypen mit höherer Leistung und höheren Kosten umsteigen wollen, und diese Abwägung ist selten einfach, da sich Engpässe und Ressourcennutzungsprofile mit der Weiterentwicklung der Software oder mit veränderten Nachfragemustern ständig verschieben. Daher ist ein besserer Mechanismus für die Ressourcenzuweisung erforderlich.
Im Mittelpunkt des Systems steht die Philosophie, dass unabhängig von der Art der proaktiven und flexiblen Optimierung der Ressourcenzuweisung auf Makro- und globaler Ebene eine reaktive Ergänzung auf Mikro- und lokaler Ebene hocheffektiv ist. Diese lokale Anpassungsfähigkeit bietet eine sich selbst stabilisierende, Just-in-Time- und rückkopplungsgesteuerte, vorübergehende Kurskorrektur. Die reaktive Komponente ist in der Lage, auf sich entwickelnde Hinweise zu reagieren, die darauf hindeuten, dass ein Job oder eine Aufgabe oder ein Teil davon nicht rechtzeitig vorankommt. Ein solches Verhalten birgt die Gefahr, dass die Latenzzeiten (P95, P99 usw.) aufgrund von Nachzügler-Effekten viel größer werden. Das hier vorgestellte System erkennt diese Art von Situation und bietet schnelle Abhilfe in einer verteilten, aber lokalisierten Weise.
Das derzeitige System ermöglicht es, dass ein „rückständiger“ Teil einer E2E-Arbeitslast mehr Kapazität erhält, um aufzuholen. Es identifiziert die Teilmengen von Pfaden in Aufgabendiagrammen und die Positionen in diesen Pfaden, bei denen das Risiko, eine End-to-End-SLA zu verpassen, stark ansteigt. Es wendet eine Vielzahl lokaler, verteilter Korrekturmaßnahmen an, ohne die Aufmerksamkeit eines zentralen Planers zu erfordern, um den Arbeitsfortschritt entlang dieser Pfade zu beschleunigen, so dass die Lücke zwischen einer gewünschten Rate und der aktuellen Fortschrittsrate auf einer kontinuierlichen und angemessenen Basis an jedem Knoten und jeder Kante des Aufgabengraphen verringert wird. Wenn das System feststellt, dass es keine Möglichkeit gibt, die SLA oder das SLO zu erreichen, kann die E2E-Verarbeitung vorzeitig abgebrochen werden. Wenn beispielsweise keine effiziente Zuordnung möglich ist oder keine Abhilfemaßnahmen zur Verfügung stehen, können Ausführungen, die gegen die E2E-Ziele verstoßen würden, frühzeitig abgebrochen werden (sofern die Richtlinien dies zulassen), wodurch Ressourcenzuordnungen frei werden.
Ein solches System der lokalen Ressourcenzuweisung bietet mehrere Vorteile. Die Möglichkeit, kurzfristig zusätzliche Ressourcen zu beschaffen, Prioritäten zu setzen usw., um den Kurs schnell zu korrigieren, wenn eine Verzögerung auftritt, verringert beispielsweise den Druck auf die übergeordneten Planer. Außerdem bleibt die Störung, die durch lokale, chirurgische Korrekturen auf die Gesamtoptimalität eines von den übergeordneten Schedulern erstellten Plans einwirkt, unbedeutend, da die Korrekturschritte nur auf den Job, die Aufgabe oder die Teilaufgabe ausgerichtet sind, die in Verzug geraten ist, und das auch nur für einen kurzen Zeitraum.
Die Ressourcenverwaltung kann die Ressourcenzuweisung und -priorisierung umfassen, z. B. die Verwaltung der Anzahl der Kerne oder der Planungsprioritäten bei CPUs, GPUs usw., aber auch die dynamische Anpassung von Ressourcen auf niedrigerer Ebene, z. B. Cache-Kapazität, Speicher- oder E/A-Bandbreite, Energiestatus, RAPL (Runtime Average Power Limit) usw. Lokale, feingranulare Pegelanpassungen können vorgenommen werden, um z. B. einen nachlaufenden Faden zu beschleunigen. Ähnliche Anpassungen können auf die QoS für symmetrisches Multithreading (SMT) oder dergleichen angewendet werden.
14 ist ein weiteres Diagramm, das die dominanten Pfade entsprechend den Kommunikations- und Rechenkosten gemäß einer Ausführungsform zeigt. Ein rechnerisch dominanter Pfad wird von den Knoten M1-M3-M6-M9 identifiziert. Ein kommunikationsdominanter Pfad wird von den Knoten M1-M4-M7-M9 identifiziert. Beachten Sie, dass nicht alle Knoten oder Kanten auf dominanten Pfaden erscheinen. Das bedeutet, dass vor der Ausführung der im Graphen dargestellten Aufgaben und Abläufe die Einhaltung der End-to-End-Latenz (E2E) optimiert werden kann, indem die dominanten Pfade so geplant werden, dass ein gewünschter Spielraum zwischen den durch diese dominanten Pfade dargestellten Mindestlatenzen und den Ziellatenzen (z. B. P99, P100 usw.) besteht.
15 ist ein Flussdiagramm, das ein Verfahren 1500 zur Bestimmung dominanter Pfade in einem Berechnungs- und Kommunikationsgraphen gemäß einer Ausführungsform veranschaulicht. Im Allgemeinen wird ein iterativer Ansatz verwendet, um die Zuordnung von Aufgaben zu Knotenpunkten in einem Berechnungs- und Kommunikationsgraphen zu verfeinern. Die Aufgaben werden den Knoten ohne Berücksichtigung der Kommunikationskosten zugewiesen. Dann werden die Kommunikationskosten ermittelt und der Weg neu bewertet. Der Prozess wird je nach Bedarf mehrmals wiederholt, bis sich das System einpendelt. Die Iterationen können periodisch oder nicht-periodisch sein. Die Iterationen liefern Korrekturen unter Verwendung dynamischer Rückmeldungen aus der tatsächlichen Ausführung bei Vorhandensein vieler unkontrollierbarer Variablen und Unwägbarkeiten.
Bei 1502 werden die Aufgaben den verfügbaren Rechenknoten zugewiesen, um die Kommunikationskosten zu reduzieren. Bei den Aufgaben kann es sich um Mikro-Dienste, Funktionen, Teilaufgaben oder dergleichen handeln. Bei der anfänglichen Ausführung des Verfahrens 1500 kann die Standardaufgabenzuweisung z. B. mit Hilfe von Nachschlagetabellen, Modellen oder einem Top-Level-Orchestrator vorgenommen werden. In späteren Iterationen des Verfahrens 1500 erfolgt die Aufgabenzuweisung auf der Grundlage eines ermittelten dominanten Kommunikationspfads (Vorgang 1508), der die tatsächlichen Leistungskennzahlen berücksichtigt.
Um 1504 wird ein neuer dominanter Berechnungspfad ermittelt. Der vorherrschende Berechnungspfad kann auf Telemetriedaten beruhen, die die tatsächliche Auslastung bestimmter Knoten, Hardwarekonfigurationen oder andere Aspekte der tatsächlichen Ausführung anzeigen.
Bei 1506 werden die Aufgaben zum Lastausgleich neu verteilt. Die Umverteilung kann z. B. darauf abzielen, die Ausführungszeit zu minimieren oder die Einhaltung von Latenz-SLAs zu maximieren.
Bei 1508 wird ein neuer dominanter Kommunikationspfad ermittelt. Der dominante Kommunikationspfad wird auf der Grundlage von Telemetriedaten bestimmt, die die verfügbare Bandbreite, die Last, die Netzwerkleistung usw. angeben.
Bei 1510 wird festgestellt, ob eine Kostenfunktion minimiert ist. Wenn das der Fall ist, wird das Verfahren 1500 abgeschlossen. Wenn dies nicht der Fall ist, wird das Verfahren 1500 durch Wiederholung der Vorgänge 1502-1508 erneut durchlaufen. Die Kostenfunktion kann auf der Einhaltung von SLAs, Leistung, Auslastung, monetären Kosten oder anderen Faktoren basieren. Wenn das System zu viel Spiel hat (z. B. über 10 %, über 20 % usw.), ist es nicht notwendig, eine zusätzliche Optimierung zu erzwingen, und das Verfahren 1500 kann abgeschlossen werden.
Das Verfahren 1500 kann in regelmäßigen Abständen nach einem Zeitplan durchgeführt werden, um die Einhaltung der SLA zu gewährleisten. Alternativ kann das Verfahren 1500 auf der Grundlage einer Auslösebedingung ausgeführt werden, z. B. wenn sich die Netzwerk- oder Berechnungsbedingungen ändern.
Die Gewichte, mit denen die vorherrschenden Berechnungs- oder Kommunikationswege bestimmt werden, sind nicht statisch. Stattdessen können die Gewichte je nach 1) der tatsächlich verwendeten Hardware an jedem einzelnen Knoten oder 2) den tatsächlichen Kosten für die geplanten Berechnungen oder Kommunikationen variieren. Möglicherweise muss die Hardware gegenüber dem Referenzwert neu skaliert werden. Wenn z. B. Scheitelpunkt/Knoten M5 eine Gewichtung von 0,27 gegenüber einem Referenz-CPU-Typ Xeon 6280 hat, die tatsächliche Hardware auf Knoten M5 aber ein anderer CPU-Typ ist, dann muss die Berechnungsgewichtung neu skaliert werden, und der dominante Berechnungspfad wird neu zugeordnet. Ebenso kann es aufgrund einer dynamischen Belastung des Knotens und der Netznutzung zum/vom Knoten erforderlich sein, die Kommunikationsgewichte anzupassen.
16 zeigt eine überarbeitete Version des in 13 und 14 dargestellten Diagramms. In 16 ist nur der dominante Berechnungspfad von M1-M3-M6-M9 dargestellt. Die Behandlung für einen kommunikationsdominanten Pfad wäre ähnlich.
Angenommen, die Berechnung hat das Ende von M3 erreicht, und M6 und M9 liegen noch vor uns. Das Aggregat von M1 und M3 zusammengenommen macht 1,44 von 5 SLA-Latenzeinheiten aus. Dabei wird nicht berücksichtigt, dass zwischen dem Latenzziel von 5 und einer tatsächlichen P99-Latenz von z. B. 6,2 bereits ein Spielraum besteht. Am Meilenstein A in 16 beträgt die Zwischensumme der Berechnungszeit also 1,44/5. Natürlich ist die maximal verfügbare Zeit, die für diese Berechnung verbleibt, 3,56, wobei der Spielraum zwischen 5 und 6,2 nicht berücksichtigt wird. Die Mindestdauer der Berechnung beträgt 0,7 + 1 + 0,45 = 1,15. Diese Berechnungszeit kann durch die tatsächliche Last auf den Knoten M6 oder M9, den Kommunikations-Overhead oder ihren nominalen, unbelasteten Durchsatz beeinflusst werden. Die tatsächlich verbleibende Rechenzeit kann also eine andere Zahl sein, zum Beispiel 2,24. In beiden Fällen ist jedoch am Meilenstein A ein ausreichender Zeitpuffer vorhanden, so dass keine Korrekturmaßnahmen ausgelöst werden.
Bei Meilenstein B nach Beendigung der Aufgabe M6 ist die verfügbare Zeit bis zum niedrigen Ziel von 5 auf 5,0 - 3,91 oder 1,09 geschrumpft. Unter Berücksichtigung des weiteren Schlupfes von 6,2 bei einer P99-Latenzzeit beträgt die verfügbare Gesamtvorlaufzeit 2,29. Die Zeit, die für die anstehende Arbeit benötigt wird, beträgt mindestens 1 + 0,45 = 1,45. An diesem Punkt kann der Orchestrator die Kommunikations- und Berechnungspriorität erhöhen, so dass die Arbeit mit größerer Wahrscheinlichkeit innerhalb oder unterhalb der verfügbaren End-to-End-Zeit abgeschlossen werden kann, wobei ein möglichst großer Teil des ursprünglichen Puffers zur Bewältigung anderer unvorhersehbarer Anforderungen zur Verfügung steht.
In diesem Beispiel wird angenommen, dass der Orchestrator eingreift und die Kommunikations- oder Berechnungspriorität ab Meilenstein B erhöht. Dies kann zu einer Verringerung der Rechen- oder Kommunikationszeit führen, was in diesem Beispiel die Kommunikationszeit von 1,0 auf 0,4 reduziert. Damit wird die SLA eingehalten, denn bei Meilenstein C liegt die Zwischensumme bei 4,31 von einem konservativen SLA-Ziel von 5. Die verbleibende Zeit, die M9 zur Ausführung benötigt, beträgt 0,45, was zu einem erfolgreichen Ausführungspfad führt, der die SLA erfüllt. Tatsächlich können auch andere Maßnahmen zur Verfügung stehen, um das Ziel so anzupassen, dass ein größerer Teil des Spielraums genutzt werden kann (z. B. die Gesamtzeit noch näher an das Ziel von 5).
Eine umsichtige Strategie für die Durchführung von M9 könnte M9 in einer größeren VM platzieren oder M9 vorübergehend mehr Kerne zuweisen oder die Cache-Zuweisung oder Speicherbandbreite von M9 vorübergehend erhöhen, da der verbleibende zeitliche Spielraum nach der Meilenmarkierung sehr gering ist. So kann es beispielsweise eine Richtlinie geben, die eine Sicherheitsmarge (z. B. 10 %) vorsieht, und die Berechnung M9 kann die Sicherheitsmarge überschreiten. In einigen Implementierungsvarianten kann die Überschreitung der Sicherheitsmarge einen Orchestrator dazu veranlassen, eine gleichzeitige redundante Berechnung von M9 zu planen, so dass die Wahrscheinlichkeit erhöht wird, dass M9 innerhalb des Zeitbudgets abgeschlossen wird.
Es gibt viele Optionen für die reaktive und proaktive Anpassung der Art und Weise, wie und wo Aufgaben ausgeführt werden. Großvolumige Serverprozessoren können neben heterogenen CPUs auch rechnerisch spezialisierte Einheiten wie GPUs, FPGAs usw. enthalten. Insbesondere sind bei einigen Prozessoren große und kleine Kerne auf demselben Chip implementiert, so dass denselben Anwendungen nahtlos Zeit auf großen Kernen zugewiesen werden kann, wenn einige wenige Aktivitäten mit hoher Geschwindigkeit ausgeführt werden müssen, und ansonsten Zeit auf kleinen Kernen, wenn viele gleichzeitige Aktivitäten mit hoher Effizienz ausgeführt werden müssen. Diese architektonischen Arrangements profitieren transparent und nahtlos von der adaptiven Zuweisung von Ressourcen, wenn sich die verfügbare Zeit für den Abschluss einer durchgehenden Rechenaktivität einem kritischen Schwellenwert nähert.
Gleichzeitig können Aufgaben, die nicht auf dem kritischen Pfad liegen, weniger Ressourcen erhalten, auch wenn sie zur gleichen Gruppe von Funktionen, Mikrodiensten usw. gehören. Im Diagramm von 14 kann M8 beispielsweise eine niedrigere Priorität erhalten, wenn es auf einem bestimmten Host gemeinsam mit M7 und M6 eingeplant ist (beachten Sie, dass M6 auf einem rechnungsdominierten Pfad liegt, während M7 auf einem kommunikationsdominierten Pfad liegt). In Verbindung mit dem Aufkommen heterogener Rechen- und Kommunikationsressourcen, auf die die Arbeit verlagert werden kann, ohne dass es zu erheblichen Overheads bei der Migration von Aufgaben von Host zu Host kommt, ermöglicht dieser Ansatz eine kontinuierliche, leichtgewichtige Anpassung der Prioritäten und Ressourcentypen, denen Berechnungen/Kommunikation zugewiesen werden.
17 ist ein Flussdiagramm, das ein Verfahren 1700 für die dynamische Orchestrierung gemäß einer Ausführungsform veranschaulicht. In 1702 werden absichtsbasierte SLAs von Anwendungen, Konfigurationsskripten oder anderer Middleware bereitgestellt. Sie werden in verschiedene Latenzschwellen als Zwischenetappen übersetzt. Die Absichten werden auch verwendet, um Wahrscheinlichkeitsschätzungen für das Erreichen der Meilensteine bei unterschiedlichem Ressourceneinsatz zu erstellen.
Um 1704 werden angesichts der verschiedenen Wahrscheinlichkeitsschätzungen zu den verschiedenen Meilensteinen in der Zukunft Pufferschätzungen erstellt. Die Schlupfschätzungen können um die Varianz (Unsicherheit) beim Erreichen der SLA auf der Grundlage der asynchronen lokalen Telemetrie angepasst werden. Ein Modell, das Schlupfschätzungen liefert, kann in Form einer Tabelle, einer Formel usw. erstellt werden. Die Tabelle kann schnell nachgeschlagen oder die Formel schnell berechnet werden, um einen Punkt während der Ausführung zu bestimmen, an dem ein bestimmter Pfad im Aufgabendiagramm mit einem Schlupfbudget verbunden werden muss, und zwar in Anbetracht des aktuellen Fortschritts (der sich in einem aus der Ausführungstelemetrie gewonnenen Meilensteinwert widerspiegelt).
Bei 1706 wird ein Modell berechnet, das die marginalen Auswirkungen einer Erhöhung oder Verringerung von Ressourcen (wie CPU-Zyklen, Cache-Kapazität, Speicher-BW, PCIe-Guthaben usw.) auf die Fortschrittsrate in Richtung des nächsten Meilensteins oder einer Reihe von Meilensteinen schätzt. Das Modell kann mehrere Knotenpunkte berücksichtigen, da die Berechnungen diese Knotenpunkte erreichen. Der Schwerpunkt dieser Modelle liegt darauf, die Komplexität von Entscheidungen über die Ressourcenzuweisung zu verringern, indem die Aufmerksamkeit auf diejenigen Ressourcen eingegrenzt wird, deren marginale Auswirkungen auf die Erreichbarkeit eines bestimmten Meilensteins am größten sind. Techniken wie die Bestimmung von Engpässen (wie sie in Top-Down-Mikroarchitektur-Analysemethoden verwendet werden) und die Abschätzung der Dachlinie können bei diesen Schätzungen eingesetzt werden. Die Vorgänge 1704 und 1706 verwenden Ausführungstelemetrie, die von Kommunikations- und Berechnungsleistungsmonitoren erhalten werden kann.
Bei 1708 werden Anpassungen vorgenommen und alle Schätzungen für künftige Meilensteine neu kalkuliert. Verschiedene Hardware- oder Softwareanpassungen können mit den Ressourcendirektoren, RAPL, anderen Hardware-Reglern oder Software-Planungsreglern vorgenommen werden. Dies ist der Auslöse- oder Korrekturvorgang. Wenn der anhand von Meilensteinen gemessene Fortschritt von den angestrebten Zielen abweicht, werden verschiedene Korrekturmaßnahmen entsprechend den aus dem obigen Vorgang 1706 verfügbaren Schätzungen durchgeführt. Dementsprechend werden verschiedene Mechanismen wie RAPL, Ressourcendirektoren, Software-Scheduling-Prioritäten, Big-Core/Small-Core-Scheduling usw. eingesetzt, um Ressourcenzuweisungen zu überarbeiten oder automatische Skalierungsschritte einzuleiten, so dass schrumpfende Schlupfwerte automatisch entsprechend höhere Ressourcenzuweisungen für Aufgaben oder Kommunikationen entlang von Pfaden auslösen, die für End-to-End-Latenzen oder -Durchsätze innerhalb einer Latenzbeschränkung entscheidend sind. Wenn diese Anpassungen in Kraft treten, werden auch die Schätzungen für die zukünftigen Meilensteine neu berechnet. Die Anpassungen können die Planung von Prioritäten, das Hinzufügen von Threads, das Erhöhen der Leistung, das Inaktivieren einiger Threads, um anderen Threads Vorrang zu geben, das Aktivieren von Ruhezuständen usw. umfassen. Dies ist ein iterativer und kontinuierlicher Prozess.
Bei 1710 wird optional eine selektive Backpropagation durchgeführt. In manchen Umgebungen ist die Elastizität des Angebots nicht voll gegeben, was die Möglichkeit einschränkt, Aufgaben oder Kommunikation auf einem kritischen Pfad mit größeren Ressourcenmengen oder mit mehr Redundanzen zu planen. Unter solchen Umständen ist es ratsam, „Gegendruck“ auszuüben, um verschiedene Stufen der Zulassungskontrolle anzuwenden, verschiedene Kompromisse zwischen Genauigkeit und Latenz zu erzielen, eine andere Gewichtung zwischen Best-Effort- und Premium-Aktivitäten vorzunehmen, die Zuweisungen für Batch-Aufgaben im Verhältnis zu interaktiven Aufgaben zu erhöhen oder zu verringern usw. Insgesamt handelt es sich um Maßnahmen, die immer früher in der Kette der Aufgabenverläufe wirksam werden, so dass die Notwendigkeit radikalerer Anpassungen in der Nähe der letzten Meilensteine verringert wird. Insgesamt handelt es sich dabei um Maßnahmen, die immer früher in der Kette der Aufgabenverläufe wirksam werden, so dass die Notwendigkeit radikalerer Anpassungen bei den letzten Meilensteinen verringert wird.
Wenn die geforderten E2E-Gesamtziele in der Mitte des Aufgabengraphen nicht erreicht werden können, kann beschlossen werden, die Gesamtausführung abzubrechen. Auf diese Weise können Ressourcen freigesetzt werden. In Fällen, in denen der Diensteigentümer beschließt, eine Aufgabe mehrmals auszuführen, und nur die erste beste Lösung benötigt, um eine P99,999-Latenzzeit zu erfüllen, kann ein frühzeitiger Abbruch die Ressourcennutzung schonen. Da die Ausführung der anderen Aufgabe nicht benötigt wird, kann sie ganz aufgegeben werden, so dass zusätzlicher Spielraum für die verbleibenden Aufgaben verbleibt. Eine weitere Alternative besteht darin, zu berücksichtigen, dass die Flussdiagramme wahrscheinlich viele Male ausgeführt werden. Mit diesem Verständnis kann eine SLA-Verfehlung durch die Zuweisung von mehr Ressourcen an frühere Aufgaben in der Reihe und die einfache Feststellung, dass der aktuelle Ausführungsablauf die SLA verfehlen wird, bewältigt werden.
Solche fristabhängigen, verteilten Richtlinien zur Priorisierung von Ressourcen verwenden lokale Agenten oder Controller, die mit Richtlinien und Leitplanken vorkonfiguriert sind. Die lokalen Agenten werden im Voraus von einer Verwaltungsinstanz konfiguriert, die die Richtlinien und Leitplanken an jeden lokalen Agenten verteilt. Die lokalen Agenten können auf aggregierter Ebene pro Cluster laufen, oder ein lokaler Agent kann pro Plattform eingesetzt werden, oder es kann eine Kombination aus beiden Systemen verwendet werden.
In den Richtlinien und Leitplanken werden verschiedene Merkmale festgelegt, z. B. 1) die maximal zulässige Schwanzlänge vor der Anwendung lokaler Abhilfemaßnahmen; 2) eine Reihe zulässiger Abhilfemaßnahmen; 3) Ausweichmaßnahmen für den Fall, dass die Abhilfemaßnahmen nicht erfolgreich sind; 4) zu überwachende Berechnungs- und Netzwerkpfade; 5) auszuwertende Pfadtelemetrie und Pfadtelemetriequellen und -endpunkte; oder 6) Kostenfunktionen/Berechnungsformeln zur Bewertung von Berechnungspfadlängen und Schlupfschätzungen.
Die Verfahren 1500 und 1700 können innerhalb der lokalen Agenten durchgeführt werden oder von den lokalen Agenten koordiniert werden. Das System macht einen zentralen Planer überflüssig. Wenn Ressourcen dorthin verlagert werden müssen, wo sie am ehesten die Einhaltung der SLAs beschleunigen, ermittelt das System gleichzeitig, welche Berechnungen auf dem kritischen Pfad liegen und welche dieser Berechnungen depriorisiert werden können, um Ressourcen für die kritischen Pfade freizugeben, oder welche Berechnungen geringere Ressourcenzuweisungen erhalten können, so dass die Einhaltung der SLAs insgesamt zu geringeren Kosten erreicht werden kann. Die Hysterese ist in das Anheben und Absenken der Priorität integriert.
Das allgemeine Problem der Ermittlung kritischer Faktoren für den Durchsatz, die Skalierbarkeit oder die Latenz von Anfragen, bei denen mehrere verschiedene Aufgaben, Mikrodienste oder Funktionen nacheinander ausgeführt werden müssen, ist ein sehr komplexes Unterfangen. Sie kann jedoch drastisch vereinfacht werden, indem Aufgaben und Aufgabenketten mit Gruppen assoziiert werden, wobei jede Gruppe ein bestimmtes Verhältnis von Leistungsempfindlichkeiten darstellt. So können die Modelle der marginalen Auswirkungen vereinfacht werden, so dass sie auf der Ebene der Gruppen liegen. Anstelle von Hunderten oder gar Tausenden von Mikrodiensten, Funktionen usw. in einer komplexen Datenfluss-Pipeline gibt es nur ein paar Dutzend Ressourcenverhältnistypen. So hat jede Aufgabe zusätzlich zu einem Quantifizierer, der die Rechenlastigkeit der Aufgabe darstellt, eine Farbe. Die Farbe stellt die Hauptkomponenten für die Randbedingungen dieser Aufgabe dar. Nehmen wir ein Beispiel, bei dem M3 eine AI-intensive Aufgabe ist und eine vorherige Charakterisierung oder Telemetrie zeigt, dass sie eine mäßige Frequenzskalierung, eine schwache Cache-Skalierung und eine starke Skalierung der Speicherbandbreite aufweist. Um die Ausführungsgeschwindigkeit von M3 zu erhöhen, kann das Gruppierungsprofil ein Verhältnis von 4:1:7:5 vorgeben - was bedeutet, dass für eine 5 %-ige Erhöhung der Geschwindigkeit von M3 eine 4 %-ige Erhöhung der Frequenz in Kombination mit 1 % mehr Cache-Kapazität (oder Priorität) und 7 % mehr Speicherbandbreite empfohlen wird. Dadurch wird es viel einfacher, die Komplexität der Ressourcenumverteilung zu verringern und herauszufinden, welche Aufgaben mit welchen anderen Aufgaben zusammengelegt werden können, um die Ausleihe von Ressourcen zu erleichtern, bei denen die Empfindlichkeiten einer Aufgabe eine viel geringere Kosinusähnlichkeit mit den Empfindlichkeiten einer anderen Aufgabe aufweisen.
Eine weitere Erweiterung besteht darin, den Begriff der Erreichbarkeit einzubauen. Die Erreichbarkeit ist ein Maß für die Wahrscheinlichkeit der Erfüllung eines SLA-Ziels oder eines Dienstgüteziels angesichts der Art der aktuellen Anforderungen und der Messwerte der Meilensteine. Das Ziel einer Erreichbarkeitsmetrik ist es, heroische Maßnahmen zur Verbesserung der SLA-Einhaltung zu vermeiden, die letztendlich nicht viel Erfolg bringen und daher ein hohes Maß an Abwanderung und Verlust von Chancen verursachen. Die Erreichbarkeit wird auf einer verteilten Basis berechnet, indem die jüngste Rate und der Grad des Erfolgs bei der Schließung der Lücke zwischen den gewünschten Ergebnissen bei den Meilensteinen und den tatsächlichen Abschlüssen bei diesen Meilensteinen geschätzt wird.
Nehmen wir zum Beispiel an, dass im Beispiel von 16 bei Meilenstein B beschlossen wurde, die E/A-Bandbreitenzuweisung für den Pfad von M6 nach M9 zu verdoppeln, und die Erwartung war, dass dies dazu führen würde, dass Meilenstein C bei 4,5/5 liegt. Wenn das tatsächliche Ergebnis besser ist (wie in 16 mit 4,31/5) als prognostiziert, würde das System in Zukunft eine höhere Bewertung für die Verkürzung der Latenzzeit auf diesem Pfad abgeben. Stellen Sie sich andererseits vor, dass das tatsächliche Ergebnis nicht effizient war und dass die Gesamtlatenzzeit bereits bei 4,9 lag, als die Aufgabe M9 beginnen sollte. Dies würde zu einem geringeren Vertrauen in die Fähigkeit beitragen, die Latenz auf dieser Strecke zwischen M6 und M9 in Zukunft zu verringern, und die Erreichbarkeitsbewertung entsprechend senken. Wenn die Erreichbarkeitsbewertung unter einen Schwellenwert fällt, können die lokalen Orchestrierungsentscheidungen den Umfang der Ressourceninvestitionen begrenzen, die für die Verbesserung der SLA-Einhaltung reserviert werden können, und stattdessen wie oben beschrieben mehr Backpropagation bereitstellen, um die Gesamt-Erreichbarkeit zu erhöhen, indem Latenz-Pushouts früher im Daten-/Kontrollfluss reduziert werden.
Zu den Faktoren, die bei der Bestimmung der Erreichbarkeit eine Rolle spielen, gehören die Analyse oder Identifizierung derjenigen Verarbeitungselemente, die am ehesten dazu beitragen können, dass die Gesamtberechnung die gewünschte SLA erreicht, die Analyse oder Identifizierung derjenigen Datenelemente, die in ihrer Priorität erhöht werden müssen, um diesen Verarbeitungselementen zu helfen, und die Bestimmung und Anwendung von Prioritätserhöhungen, die nur kurze Zeit dauern. So könnte ein Knoten beispielsweise Frames fallen lassen, um die Einhaltung des SLO zu gewährleisten, was ein weiteres Beispiel für die Bestimmung der Erreichbarkeit und die Aufgabe einer Teilaufgabe (z. B. Frame-Rendering oder -Verarbeitung) ist.
In einer anderen Ausführungsform können die Ressourcenzuweisung und der Lastausgleich auf einer Hop-by-Hop-Basis erfolgen. So werden z. B. in Stufe N eines Daten- oder Kontrollflussdiagramms die Anforderungen für die nächste Stufe N+1 bandintern an den nächsten Hop gesendet und „huckepack“ an die Anforderung der Dienstressourcen angehängt. Die Anforderungen können Folgendes umfassen: eine Reihe spezifischer Ressourcenanforderungen, z. B. <cpu% x><mem% y><qat% z>; eine Ressourcenprofil-ID, die <niedrige>|<mittlere>|<hohe> Werte abbildet; und optional kann auch die SLA als Teil der Anforderung kodiert werden.
Darüber hinaus kann die Knotenbearbeitungsstufe N den nachgelagerten Knoten einen Hinweis darauf geben, wie der Dienst am aktuellen Knoten bearbeitet wurde. Eine solche Vorhersage kann Teil einer Planungsphase sein, in der der Knotenpunkt in der Lage ist, mögliche Ressourcenknappheiten anhand der aktuellen und der erwarteten Last zu ermitteln. Alternativ kann die Vorhersage auch während der Ausführungsphase erfolgen, in der der Knotenpunkt in der Lage ist, die einzelnen Anfragen und die aktuelle Planung zu prüfen.
Die nächste Stufe (N+1) erhält die Anfrage und die Zuweisungsanforderungen über das Netz und verfügt über Komponenten zur Bearbeitung der Anfrage. Zu den Komponenten gehören ein Ressourcenbedarf-Gateway, ein lokaler Mikrodienst-Lastausgleicher und ein lokaler Ressourcen-Telemetrieagent.
Das Ressourcenbedarf-Gateway dekodiert die Dienstressourcenanforderung aus der vorhergehenden Stufe N und identifiziert die verfügbaren lokalen Ressourcen, die der Anforderung und dem für den Dienst erforderlichen SLA entsprechen. Kann der Ressourcenbedarf nicht gedeckt werden, wird die Anfrage an eine andere Stelle im Dienstnetz weitergeleitet, wo sie bearbeitet wird, oder die Anfrage wird an eine Lastausgleichereinheit zurückgeschickt, um vom Lastausgleicher bearbeitet zu werden. Wenn der lokale Ressourcenbedarf gedeckt werden kann, wird die Anfrage lokal erledigt. Die Aktionen basieren auf Regeln, die für jeden Mikrodienst konfiguriert werden können. Das Gateway ist in der Lage, logische Entscheidungen zu treffen, und ein Sidecar ist dann in der Lage, die Richtlinien des Gateways in physische Entscheidungen umzusetzen.
Der lokale Mikrodienst-Lastausgleicher wird zum Ausgleich der Lasten verwendet. Das Ressourcenbedarf-Gateway kann hinter einem lokalen Mikrodienst-Lastausgleicher innerhalb eines Sidecars auf jeder Aufgabe sitzen.
Der Telemetrieagent für lokale Ressourcen kann eine Komponente des Ressourcenbedarf-Gateways sein oder mit dem Gateway kommunizieren und dient zur Überwachung lokaler Ressourcen unter Verwendung von Telemetrie aus verschiedenen Quellen wie Telegraf, Collectd, Vmware vstats, Zabbix oder anderen kommerziellen Telemetrie-Kollektoren, offenen Telemetrie-Kollektoren, die als Sidecars eingesetzt werden, oder offener Telemetrie, die als Gateway/Aggregator eingesetzt wird.
18 ist ein Flussdiagramm, das ein Verfahren 1800 zur absichtsgesteuerten Orchestrierung gemäß einer Ausführungsform darstellt. Bei 1802 umfasst das Verfahren 1800 den Empfang einer absichtsbasierten Dienstleistungsgütevereinbarung (SLA) für die Ausführung einer Reihe von Aufgaben auf einer Vielzahl von Rechenknoten in einem Orchestratorsystem.
Bei 1804 umfasst das Verfahren 1800 die Berechnung von Zwischenlatenzschwellenwerten, die jeder Aufgabe der Reihe von Aufgaben entsprechen, auf der Grundlage der beabsichtigten SLA.
Bei 1806 umfasst das Verfahren 1800 die Berechnung von Schlupfschätzungen auf der Grundlage der Latenzschwellen und der Echtzeit-Telemetrie der Vielzahl von Rechenknoten oder der Echtzeit-Telemetrie von Verbindungen zwischen der Vielzahl von Rechenknoten.
In einer Ausführungsform umfasst die Berechnung von Schlupfschätzungen die Erstellung eines Diagramms der Reihe von Aufgaben. In einer weiteren Ausführungsform stellt ein Knoten in dem Graphen eine Aufgabe der Reihe von Aufgaben dar, die auf einem Rechenknoten der Vielzahl von Rechenknoten ausgeführt wird, und eine Kante in dem Graphen stellt die Kommunikationskosten für die Übertragung von Daten zwischen Knoten in dem Graphen dar. In einer verwandten Ausführungsform ist jeder Scheitelpunkt des Graphen mit einem Wert für die Rechenlatenz verbunden, der die Mindestzeit darstellt, die für die Durchführung der Aufgabe am Rechenknoten erforderlich ist. In einer weiteren Ausführungsform wird der Wert der Rechenlatenz auf einen Referenzwert skaliert.
In einer Ausführungsform umfasst die Berechnung der Schlupfschätzungen die iterative Zuordnung der Reihe von Aufgaben zu der Vielzahl von Rechenknoten, um eine Kostenfunktion zu minimieren. In einer weiteren Ausführungsform umfasst das iterative Abbilden der Reihe von Aufgaben auf die Vielzahl von Rechenknoten: Zuweisen der Reihe von Aufgaben an verfügbare Rechenknoten der Vielzahl von Rechenknoten in dem Graphen; Identifizieren eines dominanten Berechnungspfads durch den Graphen; Umverteilen der Reihe von Aufgaben, um die Ausführungszeit zu minimieren; Identifizieren eines dominanten Kommunikationspfads durch den Graphen; und Iterieren der Zuweisung und der Umverteilung, um die Kostenfunktion zu minimieren.
Bei 1808 umfasst das Verfahren 1800 die Überwachung der Ausführung der Reihe von Aufgaben auf der Vielzahl von Rechenknoten.
Bei 1810 beinhaltet das Verfahren 1800 die Durchführung einer Korrekturmaßnahme als Reaktion auf die Feststellung, dass die Ausführung der Reihe von Aufgaben voraussichtlich einen der Zwischenlatenzschwellenwerte überschreiten wird. In einer Ausführungsform umfasst die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einem der Vielzahl von Rechenknoten. In einer weiteren Ausführungsform umfasst die Korrekturmaßnahme eine Neuzuweisung von Ressourcen bei einer Kommunikationsverbindung zwischen zwei der Vielzahl von Rechenknoten.
In einer Ausführungsform umfasst das Verfahren 1800 die Berechnung von Wahrscheinlichkeitsschätzungen für das Erreichen der Zwischenlatenzschwellenwerte.
In einer Ausführungsform umfasst das Verfahren 1800 den Abbruch der Ausführung der Reihe von Aufgaben als Reaktion auf die Feststellung, dass die SLA nicht erreicht werden kann. In einer weiteren Ausführungsform umfasst das Verfahren 1800 die Zuweisung zusätzlicher Ressourcen an frühere Aufgaben in der Reihe von Aufgaben bei einem späteren Ausführungsversuch nach Abbruch eines früheren Ausführungsversuchs.
In einer Ausführungsform überträgt ein Rechenknoten der Vielzahl von Rechenknoten Konfigurationsdetails für eine nachfolgende Aufgabenstufe an einen zweiten Rechenknoten der Vielzahl von Rechenknoten, wobei der zweite Rechenknoten so ausgebildet ist, dass er die nachfolgende Aufgabenstufe bearbeitet. In einer weiteren Ausführungsform enthalten die Konfigurationsdetails einen Satz von Ressourcenanforderungen für die nachfolgende Aufgabenstufe. In einer verwandten Ausführungsform umfassen die Konfigurationsdetails ein Ressourcenprofil für die nachfolgende Aufgabenstufe. In einer verwandten Ausführungsform umfassen die Konfigurationsdetails die absichtsbasierte SLA.
Die in diesem Dokument beschriebenen Orchestrator- oder Orchestrierungssysteme können in einem Gerät, einer Endpunktkomponente, einer Vorrichtung, einem Client-Gerät, einem Computergerät, einem Knoten, einem Server, einem eigenständigen Knoten, der separat verkauft und in ein anderes System integriert wird, usw. implementiert werden. Ein Systemarchitekt kann ein Orchestrierungssystem in jeder beliebigen Installation implementieren.
Die Ausführungsformen können in einer oder einer Kombination aus Hardware, Firmware und Software implementiert werden. Ausführungsformen können auch in Form von Anweisungen implementiert werden, die auf einem maschinenlesbaren Speichermedium gespeichert sind und von mindestens einem Prozessor gelesen und ausgeführt werden können, um die hier beschriebenen Vorgänge durchzuführen. Eine maschinenlesbare Speichervorrichtung kann jeden nicht-übertragbaren Mechanismus zur Speicherung von Informationen in einer von einer Maschine (z. B. einem Computer) lesbaren Form umfassen. Ein maschinenlesbares Speichermedium kann z. B. einen Festwertspeicher (ROM), einen Arbeitsspeicher (RAM), Magnetplatten, optische Speichermedien, Flash-Speicher und andere Speichervorrichtungen und -medien umfassen.
Die hier beschriebenen Beispiele können eine Logik oder eine Reihe von Komponenten wie Module, Blöcke oder Kerne mit geistigem Eigentum (IP), Engines oder Mechanismen umfassen oder damit arbeiten. Bei dieser Logik oder diesen Komponenten kann es sich um Hardware, softwarekonfigurierte Hardware oder Firmware handeln, die kommunikativ mit einem oder mehreren Prozessoren verbunden ist, um die hier beschriebenen Vorgänge auszuführen. Bei der Logik oder den Komponenten kann es sich um Hardwaremodule (z. B. IP-Block) handeln, die als solche als greifbare Einheiten betrachtet werden können, die in der Lage sind, bestimmte Operationen auszuführen, und die in einer bestimmten Weise konfiguriert oder angeordnet sein können. Beispielsweise können Schaltkreise (z. B. intern oder in Bezug auf externe Einheiten wie andere Schaltkreise) in einer bestimmten Art und Weise als IP-Block, IP-Kern, System-on-Chip (SoC) oder dergleichen angeordnet sein.
In einem Beispiel kann das gesamte oder ein Teil eines oder mehrerer Computersysteme (z. B. ein eigenständiges, Client- oder Server-Computersystem) oder ein oder mehrere Hardware-Prozessoren durch Firmware oder Software (z. B. Anweisungen, ein Anwendungsteil oder eine Anwendung) als Modul konfiguriert werden, das bestimmte Operationen durchführt. In einem Beispiel kann sich die Software auf einem maschinenlesbaren Medium befinden. In einem Beispiel veranlasst die Software, wenn sie von der zugrundeliegenden Hardware des Moduls ausgeführt wird, die Hardware zur Durchführung der angegebenen Operationen. Dementsprechend ist der Begriff „Modul“ so zu verstehen, dass er eine greifbare Einheit umfasst, die physisch konstruiert, spezifisch konfiguriert (z. B. fest verdrahtet) oder vorübergehend (z. B. transitorisch) konfiguriert (z. B. programmiert) ist, um in einer bestimmten Weise zu arbeiten oder einen Teil oder alle hier beschriebenen Operationen auszuführen.
Bei Beispielen, in denen Module vorübergehend konfiguriert werden, muss nicht jedes der Module zu einem bestimmten Zeitpunkt instanziiert werden. Bestehen die Module beispielsweise aus einem Allzweck-Hardwareprozessor, der mit Hilfe von Software konfiguriert wird, so kann der Allzweck-Hardwareprozessor zu verschiedenen Zeiten als jeweils unterschiedliche Module konfiguriert werden. Dementsprechend kann Software einen Hardware-Prozessor beispielsweise so konfigurieren, dass er zu einem bestimmten Zeitpunkt ein bestimmtes Modul und zu einem anderen Zeitpunkt ein anderes Modul darstellt. Bei den Modulen kann es sich auch um Software- oder Firmware-Module handeln, die zur Durchführung der hier beschriebenen Methoden eingesetzt werden.
Ein IP-Block (auch IP-Kern genannt) ist eine wiederverwendbare Einheit aus Logik, Zelle oder integrierter Schaltung. Ein IP-Block kann als Teil eines FPGAs (Field Programmable Gate Array), eines ASICs (Application Specific Integrated Circuit), eines PLDs (Programmable Logic Device), eines SoCs (System on a Chip) oder dergleichen verwendet werden. Er kann für einen bestimmten Zweck konfiguriert werden, z. B. für die digitale Signalverarbeitung oder die Bildverarbeitung. Beispiele für IP-Kerne sind CPU-Kerne, integrierte Grafik, Sicherheit, Ein-/Ausgabesteuerung, Systemagenten, Grafikverarbeitungseinheiten (GPU), künstliche Intelligenz, neuronale Prozessoren, Bildverarbeitungseinheiten, Kommunikationsschnittstellen, Speichercontroller, Peripheriegerätesteuerung, Plattformcontroller-Hub oder dergleichen.
Zusätzliche Hinweise und Beispiele:
Beispiel 1 ist ein Orchestratorsystem, das Folgendes umfasst: einen Prozessor; und einen Speicher zum Speichern von Anweisungen, die, wenn sie vom Prozessor ausgeführt werden, das System zu Folgendem veranlassen: Empfangen, im Orchestratorsystem, einer absichtsbasierten Dienstleistungsgütevereinbarung (SLA) für die Ausführung einer Reihe von Aufgaben auf einer Vielzahl von Rechenknoten; Berechnen, auf der Grundlage der absichtsbasierten SLA, von Zwischenlatenzschwellenwerten, die jeder Aufgabe der Reihe von Aufgaben entsprechen; Berechnen von Schlupfschätzungen auf der Grundlage der Latenzschwellenwerte und der Echtzeit-Telemetrie der mehreren Rechenknoten oder der Echtzeit-Telemetrie von Verbindungen zwischen den mehreren Rechenknoten; Überwachen der Ausführung der Reihe von Aufgaben auf den mehreren Rechenknoten; und Durchführen einer Korrekturmaßnahme als Reaktion auf die Feststellung, dass die Ausführung der Reihe von Aufgaben voraussichtlich einen der Zwischenlatenzschwellenwerte überschreiten wird.
In Beispiel 2 schließt der Gegenstand von Beispiel 1 ein, dass das Orchestratorsystem zur Berechnung von Schlupfschätzungen einen Graphen der Reihe von Aufgaben erzeugt.
In Beispiel 3 schließt der Gegenstand von Beispiel 2 ein, dass ein Knoten in dem Graphen eine Aufgabe der Reihe von Aufgaben darstellt, die auf einem Rechenknoten der Vielzahl von Rechenknoten ausgeführt wird, und eine Kante in dem Graphen die Kommunikationskosten für die Übertragung von Daten zwischen Knoten in dem Graphen darstellt.
In Beispiel 4 schließt der Gegenstand von Beispiel 3 ein, dass jeder Knoten des Graphen mit einem Rechenlatenzwert verknüpft ist, der eine Mindestzeit darstellt, die erforderlich ist, um die Aufgabe an dem Rechenknoten auszuführen.
In Beispiel 5 schließt der Gegenstand von Beispiel 4 ein, dass der Wert der Rechenlatenz auf einen Referenzwert skaliert wird.
In Beispiel 6 schließt der Gegenstand der Beispiele 2-5 ein, dass zur Berechnung der Schlupfschätzungen das Orchestratorsystem die Reihe von Aufgaben iterativ auf die Mehrzahl von Rechenknoten abbildet, um eine Kostenfunktion zu minimieren.
In Beispiel 7 schließt der Gegenstand von Beispiel 6 ein, dass das Orchestratorsystem, um die Reihe von Aufgaben iterativ auf die Vielzahl von Rechenknoten abzubilden, Folgendes bewirkt: Zuweisen der Reihe von Aufgaben an verfügbare Rechenknoten der Vielzahl von Rechenknoten in dem Graphen; Identifizieren eines dominanten Berechnungspfads durch den Graphen; Umverteilen der Reihe von Aufgaben, um die Ausführungszeit zu minimieren; Identifizieren eines dominanten Kommunikationspfads durch den Graphen; und Wiederholen der Zuweisung und der Umverteilung, um die Kostenfunktion zu minimieren.
In Beispiel 8 schließt der Gegenstand der Beispiele 1-7 ein, dass das Orchestratorsystem Wahrscheinlichkeitsschätzungen für das Erreichen der Zwischenlatenzschwellenwerte berechnet.
In Beispiel 9 schließt der Gegenstand der Beispiele 1-8 ein, dass das Orchestratorsystem Folgendes bewirkt: Abbrechen der Ausführung der Reihe von Aufgaben in Reaktion auf die Feststellung, dass die SLA nicht erreicht werden kann.
In Beispiel 10 schließt der Gegenstand von Beispiel 9 ein, dass das Orchestratorsystem bei einem späteren Ausführungsversuch nach Abbruch eines früheren Ausführungsversuchs früheren Aufgaben in der Reihe von Aufgaben zusätzliche Ressourcen zuweist.
In Beispiel 11 schließt der Gegenstand der Beispiele 1-10 ein, dass die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einem der mehreren Rechenknoten einschließt.
In Beispiel 12 schließt der Gegenstand von Beispiel 11 ein, dass die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einer Kommunikationsverbindung zwischen zwei der mehreren Rechenknoten einschließt.
In Beispiel 13 schließt der Gegenstand der Beispiele 1-12 ein, dass ein Rechenknoten der Vielzahl von Rechenknoten Konfigurationsdetails für eine nachfolgende Aufgabenstufe an einen zweiten Rechenknoten der Vielzahl von Rechenknoten überträgt, wobei der zweite Rechenknoten so ausgebildet ist, dass er die nachfolgende Aufgabenstufe bearbeitet.
In Beispiel 14 schließt der Gegenstand von Beispiel 13 ein, dass die Konfigurationsdetails einen Satz von Ressourcenanforderungen für die nachfolgende Aufgabenstufe enthalten.
In Beispiel 15 schließt der Gegenstand der Beispiele 13-14 ein, dass die Konfigurationsdetails ein Ressourcenprofil für die nachfolgende Aufgabenstufe enthalten.
In Beispiel 16 schließt der Gegenstand der Beispiele 13-15 ein, dass die Konfigurationsdetails die absichtsbasierte SLA enthalten.
Beispiel 17 ist ein Verfahren, das Folgendes umfasst: Empfangen, in einem Orchestratorsystem, einer absichtsbasierten Dienstleistungsgütevereinbarung (SLA) für die Ausführung einer Reihe von Aufgaben auf einer Vielzahl von Rechenknoten; Berechnen, auf der Grundlage der absichtsbasierten SLA, von Zwischenlatenzschwellenwerten, die jeder Aufgabe der Reihe von Aufgaben entsprechen; Berechnen von Schlupfschätzungen auf der Grundlage der Latenzschwellenwerte und der Echtzeit-Telemetrie der Vielzahl von Rechenknoten oder der Echtzeit-Telemetrie von Verbindungen zwischen der Vielzahl von Rechenknoten; Überwachen der Ausführung der Reihe von Aufgaben auf der Vielzahl von Rechenknoten; und Durchführen einer Korrekturmaßnahme als Reaktion auf die Feststellung, dass die Ausführung der Reihe von Aufgaben voraussichtlich einen der Zwischenlatenzschwellenwerte überschreiten wird.
In Beispiel 18 schließt der Gegenstand von Beispiel 17 ein, dass die Berechnung von Schlupfschätzungen das Erzeugen eines Graphen der Reihe von Aufgaben einschließt.
In Beispiel 19 schließt der Gegenstand von Beispiel 18 ein, dass ein Knoten in dem Graphen eine Aufgabe der Reihe von Aufgaben darstellt, die auf einem Rechenknoten der Vielzahl von Rechenknoten ausgeführt wird, und eine Kante in dem Graphen die Kommunikationskosten für die Übertragung von Daten zwischen Knoten in dem Graphen darstellt.
In Beispiel 20 schließt der Gegenstand von Beispiel 19 ein, dass jeder Knoten des Graphen mit einem Rechenlatenzwert verknüpft ist, der eine Mindestzeit darstellt, die erforderlich ist, um die Aufgabe an dem Rechenknoten auszuführen.
In Beispiel 21 schließt der Gegenstand von Beispiel 20 ein, dass der Wert der Rechenlatenz auf einen Referenzwert skaliert wird.
In Beispiel 22 schließt der Gegenstand der Beispiele 18-21 ein, dass die Berechnung der Schlupfschätzungen eine iterative Zuordnung der Reihe von Aufgaben zu der Vielzahl von Rechenknoten umfasst, um eine Kostenfunktion zu minimieren.
In Beispiel 23 schließt der Gegenstand von Beispiel 22 ein, dass das iterative Zuordnen der Reihe von Aufgaben zu der Vielzahl von Rechenknoten Folgendes umfasst: Zuweisen der Reihe von Aufgaben an verfügbare Rechenknoten der Vielzahl von Rechenknoten in dem Graphen; Identifizieren eines dominanten Berechnungspfades durch den Graphen; Umverteilen der Reihe von Aufgaben, um die Ausführungszeit zu minimieren; Identifizieren eines dominanten Kommunikationspfades durch den Graphen; und Iterieren der Zuweisung und der Umverteilung, um die Kostenfunktion zu minimieren.
In Beispiel 24 schließt der Gegenstand der Beispiele 17-23 die Berechnung von Wahrscheinlichkeitsschätzungen für das Erreichen der Zwischenlatenzschwellen ein.
In Beispiel 25 schließt der Gegenstand der Beispiele 17-24 den Abbruch der Ausführung der Reihe von Aufgaben als Reaktion auf die Feststellung, dass das SLA nicht erreicht werden kann, ein.
In Beispiel 26 schließt der Gegenstand von Beispiel 25 die Zuweisung zusätzlicher Ressourcen an frühere Aufgaben in der Reihe von Aufgaben bei einem späteren Ausführungsversuch nach Abbruch eines früheren Ausführungsversuchs ein.
In Beispiel 27 schließt der Gegenstand der Beispiele 17-26 ein, dass die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einem der mehreren Rechenknoten einschließt.
In Beispiel 28 schließt der Gegenstand von Beispiel 27 ein, dass die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einer Kommunikationsverbindung zwischen zwei der mehreren Rechenknoten einschließt.
In Beispiel 29 schließt der Gegenstand der Beispiele 17-28 ein, dass ein Rechenknoten der Vielzahl von Rechenknoten Konfigurationsdetails für eine nachfolgende Aufgabenstufe an einen zweiten Rechenknoten der Vielzahl von Rechenknoten überträgt, wobei der zweite Rechenknoten so ausgebildet ist, dass er die nachfolgende Aufgabenstufe bearbeitet.
In Beispiel 30 schließt der Gegenstand von Beispiel 29 ein, dass die Konfigurationsdetails einen Satz von Ressourcenanforderungen für die nachfolgende Aufgabenstufe enthalten.
In Beispiel 31 schließt der Gegenstand der Beispiele 29-30 ein, dass die Konfigurationsdetails ein Ressourcenprofil für die nachfolgende Aufgabenstufe enthalten.
In Beispiel 32 schließt der Gegenstand der Beispiele 29-31 ein, dass die Konfigurationsdetails die absichtsbasierte SLA enthalten.
Beispiel 33 ist mindestens ein maschinenlesbares Medium, das Anweisungen enthält, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, Vorgänge eines der Verfahren der Beispiele 17-32 durchzuführen.
Beispiel 34 ist eine Vorrichtung, die Mittel zur Durchführung eines der Verfahren der Beispiele 17-32 umfasst.
Beispiel 35 ist mindestens ein maschinenlesbares Medium, das Anweisungen enthält, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, Operationen durchzuführen, die Folgendes umfassen: Empfangen, in einem Orchestratorsystem, einer absichtsbasierten Dienstleistungsgütevereinbarung (SLA) für die Ausführung einer Reihe von Aufgaben auf einer Vielzahl von Rechenknoten; Berechnen, auf der Grundlage der absichtsbasierten SLA, von Zwischenlatenzschwellenwerten, die jeder Aufgabe der Reihe von Aufgaben entsprechen; Berechnen von Schlupfschätzungen auf der Grundlage der Latenzschwellenwerte und der Echtzeit-Telemetrie der Vielzahl von Rechenknoten oder der Echtzeit-Telemetrie von Verbindungen zwischen der Vielzahl von Rechenknoten; Überwachen der Ausführung der Reihe von Aufgaben auf der Vielzahl von Rechenknoten; und Durchführen einer Korrekturmaßnahme als Reaktion auf die Feststellung, dass die Ausführung der Reihe von Aufgaben voraussichtlich einen der Zwischenlatenzschwellenwerte überschreiten wird.
In Beispiel 36 schließt der Gegenstand von Beispiel 35 ein, dass die Berechnung von Schlupfschätzungen das Erzeugen eines Graphen der Reihe von Aufgaben einschließt.
In Beispiel 37 schließt der Gegenstand von Beispiel 36 ein, dass ein Knoten in dem Graphen eine Aufgabe der Reihe von Aufgaben darstellt, die auf einem Rechenknoten der Vielzahl von Rechenknoten ausgeführt wird, und eine Kante in dem Graphen die Kommunikationskosten für die Übertragung von Daten zwischen Knoten in dem Graphen darstellt.
In Beispiel 38 schließt der Gegenstand von Beispiel 37 ein, dass jeder Knoten des Graphen mit einem Rechenlatenzwert verknüpft ist, der eine Mindestzeit darstellt, die erforderlich ist, um die Aufgabe an dem Rechenknoten auszuführen.
In Beispiel 39 schließt der Gegenstand von Beispiel 38 ein, dass der Wert der Rechenlatenz auf einen Referenzwert skaliert wird.
In Beispiel 40 schließt der Gegenstand der Beispiele 36-39 ein, dass die Berechnung der Schlupfschätzungen eine iterative Zuordnung der Reihe von Aufgaben zu der Vielzahl von Rechenknoten umfasst, um eine Kostenfunktion zu minimieren.
In Beispiel 41 schließt der Gegenstand von Beispiel 40 ein, dass das iterative Zuordnen der Reihe von Aufgaben zu der Vielzahl von Rechenknoten Folgendes umfasst: Zuweisen der Reihe von Aufgaben an verfügbare Rechenknoten der Vielzahl von Rechenknoten in dem Graphen; Identifizieren eines dominanten Berechnungspfades durch den Graphen; Umverteilen der Reihe von Aufgaben, um die Ausführungszeit zu minimieren; Identifizieren eines dominanten Kommunikationspfades durch den Graphen; und Iterieren der Zuweisung und der Umverteilung, um die Kostenfunktion zu minimieren.
In Beispiel 42 schließt der Gegenstand der Beispiele 35-41 die Berechnung von Wahrscheinlichkeitsschätzungen für das Erreichen der Zwischenlatenzschwellen ein.
In Beispiel 43 schließt der Gegenstand der Beispiele 35-42 den Abbruch der Ausführung der Reihe von Aufgaben als Reaktion auf die Feststellung, dass das SLA nicht erreicht werden kann, ein.
In Beispiel 44 schließt der Gegenstand von Beispiel 43 die Zuweisung zusätzlicher Ressourcen an frühere Aufgaben in der Reihe von Aufgaben bei einem späteren Ausführungsversuch nach Abbruch eines früheren Ausführungsversuchs ein.
In Beispiel 45 schließt der Gegenstand der Beispiele 35-44 ein, dass die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einem der mehreren Rechenknoten einschließt.
In Beispiel 46 schließt der Gegenstand von Beispiel 45 ein, dass die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einer Kommunikationsverbindung zwischen zwei der mehreren Rechenknoten einschließt.
In Beispiel 47 schließt der Gegenstand der Beispiele 35-46 ein, dass ein Rechenknoten der Vielzahl von Rechenknoten Konfigurationsdetails für eine nachfolgende Aufgabenstufe an einen zweiten Rechenknoten der Vielzahl von Rechenknoten überträgt, wobei der zweite Rechenknoten so ausgebildet ist, dass er die nachfolgende Aufgabenstufe bearbeitet.
In Beispiel 48 schließt der Gegenstand von Beispiel 47 ein, dass die Konfigurationsdetails einen Satz von Ressourcenanforderungen für die nachfolgende Aufgabenstufe enthalten.
In Beispiel 49 schließt der Gegenstand der Beispiele 47-48 ein, dass die Konfigurationsdetails ein Ressourcenprofil für die nachfolgende Aufgabenstufe enthalten.
In Beispiel 50 schließt der Gegenstand der Beispiele 47-49 ein, dass die Konfigurationsdetails die absichtsbasierte SLA enthalten.
Beispiel 51 ist eine Vorrichtung, die Folgendes umfasst: Mittel zum Empfangen einer absichtsbasierten Dienstleistungsgütevereinbarung (SLA) für die Ausführung einer Reihe von Aufgaben auf einer Vielzahl von Rechenknoten in einem Orchestratorsystem; Mittel zum Berechnen, auf der Grundlage der absichtsbasierten SLA, von Zwischenlatenzschwellenwerten, die jeder Aufgabe der Reihe von Aufgaben entsprechen; Mittel zum Berechnen von Schlupfschätzungen auf der Grundlage der Latenzschwellenwerte und der Echtzeit-Telemetrie der Vielzahl von Rechenknoten oder der Echtzeit-Telemetrie von Verbindungen zwischen der Vielzahl von Rechenknoten; Mittel zum Überwachen der Ausführung der Reihe von Aufgaben auf der Vielzahl von Rechenknoten; und Mittel zum Durchführen einer Korrekturmaßnahme als Reaktion auf die Feststellung, dass die Ausführung der Reihe von Aufgaben voraussichtlich einen der Zwischenlatenzschwellenwerte überschreiten wird.
In Beispiel 52 schließt der Gegenstand von Beispiel 51 ein, dass die Berechnung von Schlupfschätzungen das Erzeugen eines Graphen der Reihe von Aufgaben einschließt.
In Beispiel 53 schließt der Gegenstand von Beispiel 52 ein, dass ein Knoten in dem Graphen eine Aufgabe der Reihe von Aufgaben darstellt, die auf einem Rechenknoten der Vielzahl von Rechenknoten ausgeführt wird, und eine Kante in dem Graphen die Kommunikationskosten für die Übertragung von Daten zwischen Knoten in dem Graphen darstellt.
In Beispiel 54 schließt der Gegenstand von Beispiel 53 ein, dass jeder Knoten des Graphen mit einem Rechenlatenzwert verknüpft ist, der eine Mindestzeit darstellt, die erforderlich ist, um die Aufgabe an dem Rechenknoten auszuführen.
In Beispiel 55 schließt der Gegenstand von Beispiel 54 ein, dass der Wert der Rechenlatenz auf einen Referenzwert skaliert wird.
In Beispiel 56 schließt der Gegenstand der Beispiele 52-55 ein, dass die Berechnung der Schlupfschätzungen eine iterative Zuordnung der Reihe von Aufgaben zu der Vielzahl von Rechenknoten umfasst, um eine Kostenfunktion zu minimieren.
In Beispiel 57 schließt der Gegenstand von Beispiel 56 ein, dass die iterative Zuordnung der Reihe von Aufgaben zu der Vielzahl von Rechenknoten Folgendes umfasst: Mittel zum Zuweisen der Reihe von Aufgaben an verfügbare Rechenknoten der Vielzahl von Rechenknoten in dem Graphen; Mittel zum Identifizieren eines dominanten Berechnungspfads durch den Graphen; Mittel zum Umverteilen der Reihe von Aufgaben, um die Ausführungszeit zu minimieren; Mittel zum Identifizieren eines dominanten Kommunikationspfads durch den Graphen; und Mittel zum Iterieren der Zuweisung und der Umverteilung, um die Kostenfunktion zu minimieren.
In Beispiel 58 schließt der Gegenstand der Beispiele 51-57 die Berechnung von Wahrscheinlichkeitsschätzungen für das Erreichen der Zwischenlatenzschwellen ein.
In Beispiel 59 schließt der Gegenstand der Beispiele 51-58 den Abbruch der Ausführung der Reihe von Aufgaben als Reaktion auf die Feststellung, dass das SLA nicht erreicht werden kann, ein.
In Beispiel 60 schließt der Gegenstand von Beispiel 59 die Zuweisung zusätzlicher Ressourcen an frühere Aufgaben in der Reihe von Aufgaben bei einem späteren Ausführungsversuch nach Abbruch eines früheren Ausführungsversuchs ein.
In Beispiel 61 schließt der Gegenstand der Beispiele 51-60 ein, dass die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einem der mehreren Rechenknoten einschließt.
In Beispiel 62 schließt der Gegenstand von Beispiel 61 ein, dass die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einer Kommunikationsverbindung zwischen zwei der mehreren Rechenknoten einschließt.
In Beispiel 63 schließt der Gegenstand der Beispiele 51-62 ein, dass ein Rechenknoten der Vielzahl von Rechenknoten Konfigurationsdetails für eine nachfolgende Aufgabenstufe an einen zweiten Rechenknoten der Vielzahl von Rechenknoten überträgt, wobei der zweite Rechenknoten so ausgebildet ist, dass er die nachfolgende Aufgabenstufe bearbeitet.
In Beispiel 64 schließt der Gegenstand von Beispiel 63 ein, dass die Konfigurationsdetails einen Satz von Ressourcenanforderungen für die nachfolgende Aufgabenstufe enthalten.
In Beispiel 65 schließt der Gegenstand der Beispiele 63-64 ein, dass die Konfigurationsdetails ein Ressourcenprofil für die nachfolgende Aufgabenstufe enthalten.
In Beispiel 66 schließt der Gegenstand der Beispiele 63-65 ein, dass die Konfigurationsdetails die absichtsbasierte SLA enthalten.
Beispiel 67 ist mindestens ein maschinenlesbares Medium, das Anweisungen enthält, die, wenn sie von einer Verarbeitungsschaltung ausgeführt werden, die Verarbeitungsschaltung veranlassen, Operationen zum Implementieren eines der Beispiele 1-66 durchzuführen.
Beispiel 68 ist eine Vorrichtung, die Mittel zum Implementieren eines der Beispiele 1-66 umfasst.
Beispiel 69 ist ein System zum Implementieren eines der Beispiele 1-66.
Beispiel 70 ist ein Verfahren zum Implementieren eines der Beispiele 1-66.
Die obige detaillierte Beschreibung enthält Verweise auf die beigefügten Zeichnungen, die einen Teil der detaillierten Beschreibung bilden. Die Zeichnungen zeigen zur Veranschaulichung bestimmte Ausführungsformen, die praktiziert werden können. Diese Ausführungsformen werden hier auch als „Beispiele“ bezeichnet Solche Beispiele können zusätzlich zu den gezeigten oder beschriebenen Elementen weitere Elemente enthalten. Es sind jedoch auch Beispiele denkbar, die die gezeigten oder beschriebenen Elemente enthalten. Darüber hinaus sind auch Beispiele denkbar, bei denen eine beliebige Kombination oder Permutation der gezeigten oder beschriebenen Elemente (oder eines oder mehrerer Aspekte davon) verwendet wird, entweder in Bezug auf ein bestimmtes Beispiel (oder einen oder mehrere Aspekte davon) oder in Bezug auf andere Beispiele (oder einen oder mehrere Aspekte davon), die hier gezeigt oder beschrieben werden.
Veröffentlichungen, Patente und Patentdokumente, auf die in diesem Dokument Bezug genommen wird, werden hier in ihrer Gesamtheit aufgenommen, als ob sie einzeln durch Bezugnahme aufgenommen würden. Im Falle widersprüchlicher Verwendungen zwischen diesem Dokument und den durch Verweis einbezogenen Dokumenten ergänzt die Verwendung in den einbezogenen Verweisen die Verwendung in diesem Dokument; bei unüberbrückbaren Widersprüchen gilt die Verwendung in diesem Dokument.
In diesem Dokument werden die Begriffe „ein“ oder „eine“, wie in Patentdokumenten üblich, verwendet, um eines oder mehr als eines einzuschließen, unabhängig von allen anderen Fällen oder Verwendungen von „mindestens einem“ oder „einem oder mehreren“. In diesem Dokument bezieht sich der Begriff „oder“ auf ein nicht ausschließendes „oder“, d. h. „A oder B“ schließt „A, aber nicht B“, „B, aber nicht A“ und „A und B“ ein, sofern nicht anders angegeben. In den beigefügten Ansprüchen werden die Ausdrücke „einschließlich“ und „in denen“ als einfache englische Entsprechungen der jeweiligen Begriffe „umfassend“ und „wobei“ verwendet In den folgenden Ansprüchen sind die Begriffe „einschließlich“ und „umfassend“ offen, d. h. ein System, eine Vorrichtung, ein Gegenstand oder ein Verfahren, das Elemente enthält, die zusätzlich zu den nach einem solchen Begriff in einem Anspruch aufgeführten Elementen enthalten sind, fällt dennoch in den Anwendungsbereich dieses Anspruchs. Darüber hinaus werden in den folgenden Ansprüchen die Begriffe „erster“, „zweiter“, „dritter“ usw. lediglich als Bezeichnungen verwendet und sollen nicht auf eine numerische Reihenfolge der Gegenstände hinweisen.
Die obige Beschreibung dient der Veranschaulichung und ist nicht restriktiv. So können die oben beschriebenen Beispiele (oder ein oder mehrere Aspekte davon) in Kombination mit anderen verwendet werden. Andere Ausführungsformen können verwendet werden, wie ein Fachmann nach Durchsicht der obigen Beschreibung feststellen wird. Die Zusammenfassung soll es dem Leser ermöglichen, sich schnell über die Art der technischen Offenbarung zu informieren. Sie wird mit der Maßgabe vorgelegt, dass sie nicht zur Auslegung oder Einschränkung des Umfangs oder der Bedeutung der Ansprüche herangezogen wird. In der obigen detaillierten Beschreibung können auch verschiedene Merkmale zusammengefasst werden, um die Offenbarung zu vereinfachen. Es kann jedoch sein, dass in den Ansprüchen nicht alle hierin offenbarten Merkmale aufgeführt sind, da die Ausführungsformen eine Teilmenge dieser Merkmale aufweisen können. Darüber hinaus können Ausführungsformen auch weniger Merkmale enthalten als in einem bestimmten Beispiel angegeben. Daher werden die folgenden Ansprüche in die ausführliche Beschreibung aufgenommen, wobei ein Anspruch für sich genommen eine eigenständige Ausführungsform darstellt. Der Umfang der hierin offengelegten Ausführungsformen ist unter Bezugnahme auf die beigefügten Ansprüche zu bestimmen, zusammen mit dem vollen Umfang der Äquivalente, zu denen diese Ansprüche berechtigt sind.
ZITATE ENTHALTEN IN DER BESCHREIBUNG
Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
Zitierte Patentliteratur

US 63/280001 [0001]
JP 9179235 [0090]

Claims

Orchestratorsystem, das Folgendes umfasst: einen Prozessor; und einen Speicher, um Anweisungen zu speichern, die, wenn sie vom Prozessor ausgeführt werden, das System zu Folgendem veranlassen: Empfangen, im Orchestratorsystem, einer absichtsbasierten Dienstleistungsgütevereinbarung (SLA) für die Ausführung einer Reihe von Aufgaben auf einer Vielzahl von Rechenknoten; Berechnen, auf der Grundlage der beabsichtigten SLA, von Zwischenschwellenwerten für die Latenzzeit, die jeder Aufgabe der Aufgabenserie entsprechen; Berechnen von Schlupfschätzungen auf der Grundlage der Latenzschwellenwerte und der Echtzeit-Telemetrie der Vielzahl von Rechenknoten oder der Echtzeit-Telemetrie der Verbindungen zwischen der Vielzahl von Rechenknoten; Überwachen der Ausführung der Reihe von Aufgaben auf der Vielzahl von Rechenknoten; und Durchführen einer Korrekturmaßnahme als Reaktion auf die Feststellung, dass die Ausführung der Reihe von Aufgaben voraussichtlich einen der dazwischen liegenden Latenzschwellenwerte überschreiten wird.
Orchestratorsystem nach Anspruch 1, wobei das Orchestratorsystem zur Berechnung von Schlupfschätzungen ein Diagramm der Reihe von Aufgaben erzeugt.
Orchestratorsystem nach Anspruch 2, wobei ein Knoten in dem Graphen eine Aufgabe der Reihe von Aufgaben darstellt, die auf einem Rechenknoten der Vielzahl von Rechenknoten ausgeführt wird, und eine Kante in dem Graphen die Kommunikationskosten für die Übertragung von Daten zwischen Knoten in dem Graphen darstellt.
Orchestratorsystem nach Anspruch 3, wobei jeder Knoten des Graphen mit einem Rechenlatenzwert verknüpft ist, der eine Mindestzeit darstellt, die erforderlich ist, um die Aufgabe an dem Rechenknoten durchzuführen.
Orchestratorsystem nach Anspruch 4, wobei der Rechenlatenzwert auf einen Referenzwert skaliert wird.
Orchestratorsystem nach einem der Ansprüche 2 bis 5, wobei das Orchestratorsystem zur Berechnung der Schlupfschätzungen die Reihe von Aufgaben iterativ der Vielzahl von Rechenknoten zuordnet, um eine Kostenfunktion zu minimieren.
Orchestratorsystem nach Anspruch 6, wobei das Orchestratorsystem zum iterativen Zuordnen der Reihe von Aufgaben zu der Vielzahl von Rechenknoten Folgendes bewirkt: Zuweisen der Reihe von Aufgaben an verfügbare Rechenknoten aus der Vielzahl von Rechenknoten in dem Graphen; Identifizieren eines dominanten Berechnungspfads durch den Graphen; Umverteilen der Reihe der Aufgaben, um die Ausführungszeit zu minimieren; Identifizieren eines dominanten Kommunikationspfads durch den Graphen; und Iterieren der Zuweisung und der Umverteilung, um die Kostenfunktion zu minimieren.
Orchestratorsystem nach einem der Ansprüche 1-7, wobei das Orchestratorsystem Wahrscheinlichkeitsschätzungen für das Erreichen der Zwischenlatenzschwellenwerte berechnet.
Orchestratorsystem nach einem der Ansprüche 1-8, wobei das Orchestratorsystem Folgendes bewirkt: Abbrechen der Ausführung der Aufgabenreihe als Reaktion auf die Feststellung, dass die SLA nicht erreicht werden kann.
Orchestratorsystem nach Anspruch 9, wobei das Orchestratorsystem bei einem späteren Ausführungsversuch nach Abbruch eines früheren Ausführungsversuchs früheren Aufgaben in der Reihe von Aufgaben zusätzliche Ressourcen zuweisen soll.
Orchestratorsystem nach einem der Ansprüche 1-10, wobei die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einem der Vielzahl von Rechenknoten umfasst.
Orchestratorsystem nach Anspruch 11, wobei die Korrekturmaßnahme eine Neuzuweisung von Ressourcen an einer Kommunikationsverbindung zwischen zwei der Vielzahl von Rechenknoten umfasst.
Orchestratorsystem nach einem der Ansprüche 1-12, wobei ein Rechenknoten der Vielzahl von Rechenknoten Konfigurationsdetails für eine nachfolgende Aufgabenstufe an einen zweiten Rechenknoten der Vielzahl von Rechenknoten überträgt, wobei der zweite Rechenknoten so ausgebildet ist, dass er die nachfolgende Aufgabenstufe bearbeitet.
Orchestratorsystem nach Anspruch 13, wobei die Konfigurationsdetails einen Satz von Ressourcenanforderungen für die nachfolgende Aufgabenstufe enthalten.
Orchestratorsystem nach einem der Ansprüche 13-14, wobei die Konfigurationsdetails ein Ressourcenprofil für die nachfolgende Aufgabenstufe enthalten.
Orchestratorsystem nach einem der Ansprüche 13-15, wobei die Konfigurationsdetails die absichtsbasierte SLA enthalten.
Verfahren, das Folgendes umfasst: Empfangen, in einem Orchestratorsystem, einer absichtsbasierten Dienstleistungsgütevereinbarung (SLA) für die Ausführung einer Reihe von Aufgaben auf einer Vielzahl von Rechenknoten; Berechnen, auf der Grundlage der absichtsbasierten SLA, von Zwischenschwellenwerten für die Latenz, die jeder Aufgabe der Aufgabenreihe entsprechen; Berechnen von Schlupfschätzungen auf der Grundlage der Latenzschwellenwerte und der Echtzeit-Telemetrie der Vielzahl von Rechenknoten oder der Echtzeit-Telemetrie der Verbindungen zwischen der Vielzahl von Rechenknoten; Überwachen der Ausführung der Reihe von Aufgaben auf der Vielzahl von Rechenknoten; und Durchführen einer Korrekturmaßnahme als Reaktion auf die Feststellung, dass die Ausführung der Reihe von Aufgaben voraussichtlich einen der Zwischenschwellenwerte für die Latenzzeit überschreiten wird.
Verfahren nach Anspruch 17, wobei die Berechnung von Schlupfschätzungen die Erstellung eines Graphen der Reihe von Aufgaben umfasst.
Verfahren nach Anspruch 18, wobei ein Scheitelpunkt in dem Graphen eine Aufgabe der Reihe von Aufgaben darstellt, die auf einem Rechenknoten der Vielzahl von Rechenknoten ausgeführt wird, und eine Kante in dem Graphen Kommunikationskosten für die Übertragung von Daten zwischen Scheitelpunkten in dem Graphen darstellt.
Verfahren nach Anspruch 19, wobei jedem Knoten des Graphen ein Rechenlatenzwert zugeordnet ist, der eine Mindestzeit darstellt, die erforderlich ist, um die Aufgabe an dem Rechenknoten durchzuführen.
Verfahren nach Anspruch 20, wobei der Rechenlatenzwert auf einen Referenzwert skaliert wird.
Verfahren nach einem der Ansprüche 18-21, wobei das Berechnen der Schlupfschätzungen das iterative Zuordnen der Reihe von Aufgaben zu der Vielzahl von Rechenknoten umfasst, um eine Kostenfunktion zu minimieren.
Verfahren nach Anspruch 22, wobei das iterative Zuordnen der Reihe von Aufgaben zu der Vielzahl von Rechenknoten Folgendes umfasst: Zuweisen der Reihe von Aufgaben an verfügbare Rechenknoten aus der Vielzahl von Rechenknoten in dem Graphen; Identifizieren eines dominanten Berechnungspfads durch den Graphen; Umverteilen der Reihe von Aufgaben zur Minimierung der Ausführungszeit; Identifizieren eines dominanten Kommunikationspfads durch den Graphen; und Iterieren der Zuweisung und der Umverteilung, um die Kostenfunktion zu minimieren.
Mindestens ein maschinenlesbares Medium, das Anweisungen enthält, die, wenn sie von einer Maschine ausgeführt werden, die Maschine veranlassen, Vorgänge nach einem der Verfahren der Ansprüche 17-23 durchzuführen.
Vorrichtung, die Folgendes umfasst: Mittel zum Empfangen, in einem Orchestratorsystem, einer absichtsbasierten Dienstleistungsgütevereinbarung (SLA) für die Ausführung einer Reihe von Aufgaben auf einer Vielzahl von Rechenknoten; Mittel zum Berechnen, auf der Grundlage der absichtsbasierten SLA, von Zwischenlatenzschwellenwerten, die jeder Aufgabe der Reihe von Aufgaben entsprechen; Mittel zum Berechnen von Schlupfschätzungen auf der Grundlage der Latenzschwellen und der Echtzeit-Telemetrie der Vielzahl von Rechenknoten oder der Echtzeit-Telemetrie von Verbindungen zwischen der Vielzahl von Rechenknoten; Mittel zum Überwachen der Ausführung der Reihe von Aufgaben auf der Vielzahl von Rechenknoten; und Mittel zum Durchführen einer Korrekturmaßnahme als Reaktion auf die Feststellung, dass die Ausführung der Reihe von Aufgaben voraussichtlich einen der Zwischenlatenzschwellenwerte überschreiten wird.