DE112019005604T5

DE112019005604T5 - Function-as-a-service-system-verbesserungen (faas-system-verbesserungen)

Info

Publication number: DE112019005604T5
Application number: DE112019005604.2T
Authority: DE
Inventors: Mohammed R. Haghighat; Kshitij Doshi; Andrew J. Herdrich; Anup MOHAN; Ravishankar R. Iyer; Mingqiu Sun; Krishna Bhuyan; Teck Joo Goh; Mohan J. Kumar; Michael Prinke; Michael LeMay; Leeor Peled; Jr-Shian Tsai; David M. Durham; Jeffrey D. Chamberlain; Vadim A. Sukhomlinov; Eric J. Dahlen; Sara Baghsorkhi; Harshad Sane; Areg Melik-Adamyan
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2018-11-08
Filing date: 2019-04-16
Publication date: 2021-09-09
Also published as: US11922220B2; JP2022511177A; WO2020096639A1; CN112955869A; US20210263779A1; KR20210076882A; EP3877854A4; JP7327744B2; EP3877854A1

Abstract

Ausführungsformen von Systemen, Geräten und Verfahren stellen Benutzern, zum Beispiel Computerentwicklern und Cloud-Service-Anbietern (CSPs), verbesserte Function-as-a-Service (FaaS) bereit. Ein Rechensystem, das dazu konfiguriert ist, solche verbesserte Function-as-a-Service bereitzustellen, beinhaltet ein oder mehrere Steuerarchitektursubsysteme, Software und Orchestrierungssubsysteme, Netzwerk- und Lagerungssubsysteme und Sicherheitssubsysteme. Das Rechensystem führt Funktionen als Reaktion auf Ereignisse aus, die von den Benutzern in einer Ausführungsumgebung ausgelöst werden, die von den Architektursubsystemen bereitgestellt wird, die eine Abstraktion des Ausführungsmanagements darstellen und die Benutzer von der Bürde des Managements der Ausführung abschirmen. Die Software- und Orchestrierungssubsysteme ordnen Rechenressourcen für die Funktionsausführung zu, indem sie intelligent Container für einen Funktionscode mit verringerter Instanziierungslatenz und gesteigerter Ausführungsskalierbarkeit hochlaufen und herunterlaufen lassen, während sie gesicherte Ausführung beibehalten. Außerdem ermöglicht es das Rechensystem Kunden, mit einer feinen Abrechnung bis hinunter zu Millisekunden Inkrementen, nur zu bezahlen, wenn ihr Code ausgeführt wird.

Description

QUERVERWEIS ZU VERWANDTEN ANMELDUNGEN
Die vorliegende Anmeldung beansprucht die Priorität vor der vorläufigen PCT-Patentanmeldung Nr. PCT/CN2018/114602, eingereicht am 08. November 2018.
ALLGEMEINER STAND DER TECHNIK
Function-as-a-Service (FaaS) ist ein ereignisorientiertes hoch skalierbares Computer-Code-Ausführungsmodell, das typischerweise einen Single-Purpose-Application-Programming-Interface-Endpunkt (API-Endpunkt) auf einer Cloud-Computing-Infrastruktur beistellt, um die Code-Ausführungsanforderungen während einer kleinen Zeitmenge zu empfangen und auszuführen. Solche Code-Ausführungsanforderungen und/oder Ausführungen angeforderten Codes werden verschiedentlich und gewöhnlich als Lambdas, Funktionen, Aktionen und/oder Run-To-Completion-Vorgehensweisen bezeichnet. Bei dieser Anmeldung kann der Begriff „Funktion“ und/oder „Function“ auf eine dieser Code-Ausführungsanforderungen und die Ausführung dieser Anforderungen verweisen, ob eine solche Ausführung nun als Software verkörpert ist oder als Aktionen, die in Hardware oder irgendeiner Kombination davon verkörpert sind. Die Begriffe „Function“ und „Funktion“, wie sie hierin verwendet sind, können im Allgemeinen, außer wenn ausdrücklich anderes angegeben und/oder durch Kontext angedeutet ist, auf eine FaaS-Funktion verweisen. FaaS kann folglich als ein Schritt in der Entwicklung des Cloud-Computing betrachtet werden. FaaS, die gelegentlich auch als „serverloses Computing“ bezeichnet wird, kann es Software-Entwicklern ermöglichen, hochskalierbaren Code zu schreiben, aber ohne Kosten, Zeit und Auslagen, die erforderlich sind, um die Hardware- oder Anwendungs-Softwareressourcen, die an der Ausführung des Codes beteiligt sein werden, beizustellen oder ansonsten vorab zu definieren. FaaS kann es auch Cloud-Dienst-Anbietern (Cloud Service Providers - CSPs) ermöglichen, die Ressourcennutzung aufgrund besserer Zuordnung (zum Beispiel Bin-Packing) zu steigern.
Große Recheneinheiten haben sich im Laufe der Zeit mit einer steigenden Konzentration auf Business-Logik und abnehmenden Bedenken/Kontrolle über Stapel geändert. FaaS abstrahiert eine Laufzeitumgebung, wie die Common-Language-Laufzeit (CLR) und Ausführungskontext-Lebenszyklus. Benutzer, zum Beispiel Anwendungsentwickler und CSPs, können durch FaaS beträchtlichen Wert für sich gewinnen. Entwickler bilden zum Beispiel Anwendungen, wie Funktionscode, unter Verwenden von Hochsprache und laden den Funktionscode zu einer FaaS-Plattform zur Ausführung hoch. Die Entwickler verwenden einfach die FaaS-Plattform, ohne sie selbst zu hosten, und die Infrastruktur der FaaS-Plattform ist für die Benutzer undurchsichtig.
In dem Fall von CSPs verbleibt beträchtlicher Spielraum zur Verbesserung, während ein CSP sein Portfolio an Funktionen als Dienste als ein wichtiges Unterscheidungsmerkmal verwenden kann. Es verbleibt zum Beispiel noch Besorgnis um „proprietäres Lock-in“, während Funktionscode, der in der Cloud geschrieben und eingesetzt wird, untrennbar mit den vom CSP in diesem Zeitpunkt bereitgestellten Funktionen gebunden wird. Dieses proprietäre Lock-in bedeutet, dass Anwendungen für eine spezifische Cloud-Umgebung optimiert werden. Bewegliche Funktionen zwischen CSPs könnten folglich Performance und Reaktionsfähigkeit einer Anwendung opfern, was zusätzlich in Situationen resultiert, in welchen einige der von dem CSP bereitgestellten Funktionen von anderen CSPs nicht unterstützt werden.
2A veranschaulicht eine verallgemeinerte existierende serverlose Service-Plattform 203 zum Bereitstellen von Function-as-a-Service, die serverlosen Funktionscode 201 empfängt, der von einem Computer-Anwendungsentwickler hochgeladen wird, und den Funktionscode 201 bei Auslösen durch ein entsprechendes Ereignis ausführt. Der Anwendungsentwickler des serverlosen Funktionscodes 201 kann einen Betrag bezahlen, der für nur wenn der serverlose Funktionscode 201 abgerufen wird und/oder in der serverlosen Service-Plattform 203 läuft, gilt. Wie in 2A gezeigt, weist die serverlose Service-Plattform 203 einen serverlosen Service-Manager 203a auf, um den serverlosen Funktionscode 201 zu empfangen und den serverlosen Funktionscode 201 zu einem Speicher zu speichern, und die Ausführung des serverlosen Funktionscodes 201 unter Verwenden erforderlicher Computer-Ressourcen, wie Container, zu planen. Die serverlose Service-Plattform 203 kann auch ein Networking- und Messaging-Modul 203b beinhalten, um ein oder mehrere Ereignisse, die mit dem Ausführen des serverlosen Funktionscodes 201 verbunden sind, aus Endpunkten eines CSP-Netzwerks auszulösen und zu routen. Die serverlose Service-Plattform 203 kann auch einen Sicherheits- und Zugriffsmanager 203c und einen oder mehrere Lagerungsdienste 203d beinhalten. Der Sicherheits- und Zugriffsmanager 203c ist zum Bereitstellen von Sicherheit beim Ausführen des serverlosen Funktionscodes 201 zuständig. Der Sicherheits- und Zugriffsmanager 203c kann zum Beispiel den Zugriff auf diverse Computerressourcen und/oder Privilegien, die mit dem Ausführen des serverlosen Funktionscodes 201 verbunden sind, prüfen. Die Lagerungsdienste 203d können einen Objektspeicher (zum Beispiel S3 von Amazon AWS-Lambda), eine Schlüsselwert-Datenbank (zum Beispiel DynamoDB von Amazons AWS-Services) und/oder eine mobile Backend-Datenbank (zum Beispiel Cloud Firestore von Googles Cloud Functions) beinhalten, um spezialisierte Backend-Dienste bereitzustellen. Die Speicherdienste 203d können auch Big-Data-Dienste ermöglichen, einschließlich Big-Data-Abfrage (zum Beispiel AWS Athena und Google BigQuery) und Big-Data-Umwandlung (zum Beispiel AWS Glue und Google Cloud Dataflow). Die serverlose Service-Plattform 203 aktiviert die serverlosen Dienste durch eine serverlose Service-Architektur 203e (zum Beispiel die Architektur von AWS Lambda, die Architektur von Google CloudPlatform und/oder die Architektur von Azure Functions), und ein oder mehrere mit Hardware verbundene Elemente, wie hardwaregestützte virtuelle Maschinen, CPUs, GPUs und Beschleuniger.
Es bestehen Herausforderungen für existierende FaaS-Lösungen, wie die eine, die in 2A gezeigt ist. Existierende FaaS-Lösungen stellen zum Beispiel typischerweise ein unausgereiftes Entwickler-Tools-Ökosystem bereit. Ferner erfordern existierende FaaS-Lösungen häufig unvorhersagbare und kostspielige Kaltstarts, die Vorbereiten der erforderlichen Ausführungsumgebung zusätzlich zum Ausführen des Codes umfassen, was hoher, variabler und unvorhersagbarer Latenz unterliegt. Nimmt man als ein Beispiel eine Spontan-Video-Codierungsanwendung als ein Beispiel, sind existierende Lösungen, die einen Objektspeicher verwenden können, zu langsam, um feine Kommunikation zu unterstützen, und/oder sie leiden an einer langwierigen Latenz, bevor serverloser Funktionscode zur Ausführung kommt.
Außerdem leiden existierende FaaS-Lösungen derzeit an begrenzter Kontrolle und Schwierigkeit beim Verwalten von Code-Ausführungszuständen. Bei Maschinenlerntraining im großen Umfang als ein Beispiel, sehen sich existierende FaaS-Lösungen, wie die eine in 2A gezeigte, mit Herausforderungen beim Erzielen wünschenswerter hoher Skalierfähigkeit aufgrund eines Mangels an schnellem und/oder gemeinsam verwendetem Speicher sowie Mangel an ausreichender Unterstützung für Networking-Anbindung konfrontiert.
Zusätzlich führt FaaS eine Extra-Abstraktionsschicht ein, die es schwieriger gestaltet, unterscheidende und/oder neue Infrastrukturmerkmale in Prozessoren, Plattformen oder Systemen, wie Computerarchitekturen zum Unterstützen von Hardware-Heterogenität, bei existierenden FaaS-Lösungen aufzuzeigen und umzusetzen. Mit anderen Worten, während existierende FaaS-Lösungen eventuell Softwareentwicklung abstrahieren, kann eine solche Abstraktion zu Schwierigkeiten beim effizienten Einsetzen der Hardwarearchitekturen zum Ausführen des Softwarecodes führen.
Figurenliste
Die diversen Vorteile der Ausführungsformen ergeben sich für einen Fachmann bei der Lektüre der folgenden Spezifikation und der anliegenden Ansprüche sowie durch Referenzierung der folgenden Zeichnungen, in welchen:

1 eine Veranschaulichung eines Beispiels einer FaaS-Rechenumgebung gemäß einer Ausführungsform ist;
2A ein Beispiel eines verallgemeinerten existierenden serverlosen Diensts veranschaulicht;
2B ein Blockschaltbild eines Beispiels eines Satzes von FaaS-Systembauelementen gemäß einer Ausführungsform ist;
3 ein Blockschaltbild eines Beispiels einer FaaS-Serverkonfiguration gemäß einer Ausführungsform ist;
4 ein Blockschaltbild eines Beispiels eines verbesserten FaaS-Systems gemäß einer Ausführungsform ist;
5 ein Blockschaltbild eines Beispiels der Untersysteme eines verbesserten FaaS-Systems gemäß einer Ausführungsform ist;
6A ein Blockschaltbild eines Beispiels einer verbesserten FaaS-Architektur zur Ressourcenzuweisung und Kontrolle gemäß einer Ausführungsform ist;
6B ein Ablaufdiagramm des Verwaltens von Benutzerebenenfähigkeiten unter Verwenden einer verbesserten FaaS-Architektur gemäß einer Ausführungsform ist;
6C ein Ablaufdiagramm des Verwaltens von Benutzerebenenfähigkeiten unter Verwenden einer verbesserten FaaS-Architektur gemäß einer Ausführungsform ist;
7A ein Blockschaltbild eines beispielhaften FaaS-Rechenknotens zum Überwachen diverser virtueller Leistungs-Performance-ÜberwachungseinheitsEreignisse (vPMU-Ereignisse) in einem Container gemäß einer Ausführungsform ist;
7B ein Blockschaltbild eines Beispiels eines vPMU-Pufferspeichers gemäß einer Ausführungsform ist; und
7C ein Ablaufdiagramm eines Beispiels eines Verfahrens zum Überwachen der Performance einer Funktion gemäß einer Ausführungsform ist;
8A ein Blockschaltbild eines Beispiels eines elektronischen Verarbeitungssystems gemäß einer Ausführungsform ist;
8B ein Blockschaltbild eines Beispiels eines Halbleiter-PackageGeräts gemäß einer Ausführungsform ist;
8C ein Ablaufdiagramm eines Beispiels des gemeinsamen Verwendens von Speicher unter mehreren FaaS-Funktionen gemäß einer Ausführungsform ist;
8D ein Ablaufdiagramm eines Beispiels des gemeinsamen Verwendens von Speicher unter mehreren FaaS-Funktionen gemäß einer Ausführungsform ist;
8E ein Blockschaltbild eines anderen Beispiels eines FaaS-Systems ist, das gemeinsames Verwenden von Speicher unter mehreren FaaS-Funktionen gemäß einer Ausführungsform bereitstellt;
8F ein Blockschaltbild eines anderen Beispiels eines Funktions-Adressumsetzpuffers zum Erleichtern von Kommunikationen zwischen zwei FaaS-Funktionen gemäß einer Ausführungsform ist;
8G ein Blockschaltbild eines anderen Beispiels eines FaaS-Systems zum Orchestrieren verteilter FaaS-Funktionen gemäß einer Ausführungsform ist;
9A ein Ablaufdiagramm eines Beispiels eines Verfahrens zum Bereitstellen spekulativer Container-Run-Ahead-Ausführung einer Function-as-a-Service gemäß einer Ausführungsform ist;
9B ein Blockschaltbild eines anderen Beispiels eines FaaS-Systems ist, das spekulative Container-Run-Ahead-Ausführung gemäß einer Ausführungsform unterstützt;
9C ein Blockschaltbild eines anderen Beispiels eines FaaS-Systems ist, das spekulative Container-Run-Ahead-Ausführung von Bildrotationsfunktionen gemäß einer Ausführungsform unterstützt;
10A ein Ablaufdiagramm eines anderen Beispiels eines Verfahrens zum Bereitstellen einer Function-as-a-Service mit Feedback-Unterstützung gemäß einer Ausführungsform ist;
10B ein Blockschaltbild eines anderen Beispiels eines FaaS-Systems mit Feedback-Unterstützung gemäß einer Ausführungsform ist;
10C ein Blockschaltbild eines anderen Beispiels eines FaaS-Systems mit Feedback-Unterstützung gemäß einer Ausführungsform ist;
11A ein veranschaulichendes Diagramm eines Beispiels einer Funktion, die mehrere Optionen zur Instanziierung aufweist, gemäß einer Ausführungsform ist;
11B ein Blockschaltbild eines anderen Beispiels eines FaaS-Systems, das Funktionen unterstützt, die mehrere Optionen zur Instanziierung aufweisen, gemäß einer Ausführungsform ist;
11C ein Ablaufdiagramm eines anderen Beispiels eines Verfahrens zum Bereitstellen einer Function-as-a-Service für Funktionen, die mehrere Optionen zur Instanziierung aufweisen, gemäß einer Ausführungsform ist;
12 ein Blockschaltbild eines anderen Beispiels eines FaaS-Systems mit einem Scheduler gemäß einer Ausführungsform ist;
13A ein Blockschaltbild eines Beispiels einer FaaS-Serverarchitektur gemäß einer Ausführungsform ist;
13B ein Beispiel eines verbesserten FaaS-Planungsprozesses gemäß einer Ausführungsform ist;
13C ein Ablaufdiagramm von Funktionen gemäß einer Ausführungsform ist;
die 14A und 14B Beispiele einer verbesserten Funktionsausführungssequenz gemäß einer Ausführungsform sind;
14C ein Ablaufdiagramm zum Planen einer Funktion, die mehrere Vorgänge aufweist, gemäß einer Ausführungsform ist;
15A ein Blockschaltbild eines Beispiels einer Computing-Architektur mit Verbesserung durch Speicherlagerung für FaaS-Serverarchitektur gemäß einer Ausführungsform ist;
15B ein Ablaufdiagramm einer Speicherzuordnung für Container und Funktionen einer FaaS-Plattform gemäß einer Ausführungsform ist;
16A ein Beispiel gebatchter Funktionsanforderungen zur Funktionsausführung gemäß einer Ausführungsform ist;
16B eine Veranschaulichung eines Beispiels eines Halbleiter-Package-Geräts gemäß einer Ausführungsform ist;
16C ein Ablaufdiagramm von Batching-Funktionsanforderungen gemäß einer Ausführungsform ist;
16D ein Ablaufdiagramm von Batching zweier oder mehrerer Funktionsanforderungen gemäß einer Ausführungsform ist;
16E ein Ablaufdiagramm zum Planen von Funktionsanforderungen gemäß einer Ausführungsform ist;
17A ein Beispiel einer redundanten Funktionsumsetzung gemäß einer Ausführungsform ist;
17B ein Ablaufdiagramm einer redundanten Funktionsumsetzung gemäß einer Ausführungsform ist;
18A eine Funktionserzeugungsgrafik veranschaulicht, die einen Scheduler für FaaS gemäß einer Ausführungsform darstellt;
18B ein verstärktes FaaS-System mit einem Scheduler gemäß einer Ausführungsform veranschaulicht;
18C ein Ablaufdiagramm einer FaaS-Funktionsumsetzung gemäß einer Ausführungsform ist;
19A ein Beispiel einer verbesserten FaaS-Architektur mit einer gemeinsamen Datenlagerung gemäß einer Ausführungsform ist;
19B ein Ablaufdiagramm einer beispielhaften FaaS-Datenlagerung gemäß einer Ausführungsform ist;
19C ein Ablaufdiagramm eines beispielhaften Verfahrens zum Umsetzen und Durchsetzen von FaaS-Sicherheitsprotokollen gemäß einer Ausführungsform ist;
20A ein Blockschaltbild eines Beispiels einer verbesserten FaaS-Serverarchitektur, die dedizierte FaaS-Caches aufweist, gemäß einer Ausführungsform ist;
20B ein Blockschaltbild eines Beispiels einer verbesserten FaaS-Serverarchitektur, die Allzweck-Caches aufweist, gemäß einer Ausführungsform ist;
20C ein Beispiel einer Grafik, die Datenvolumen von Datenobjekten veranschaulicht, gemäß einer Ausführungsform ist;
20D ein Ablaufdiagramm eines beispielhaften verbesserten Funktionsressourcenmanagements gemäß einer Ausführungsform ist;
21A ein Beispiel eines Verfahrens zum Priorisieren eine Software-Thread gemäß einer Ausführungsform ist;
die 21B und 21C Wechselwirkung zwischen Aufgaben und Serviceklassen (Class of Services - CLOSs) in einer Seitentabelle zum Bereitstellen von Seitenebenen-QoS in einer verbesserten FaaS-Architektur gemäß einer beispielhaften Ausführungsform veranschaulichen;
21D eine andere Architektur in Zusammenhang mit Seitenebenen-QoS gemäß einer beispielhaften Ausführungsform veranschaulicht;
22 eine beispielhafte Architektur zum Bereitstellen von Determinismus und Präzision in Zusammenhang mit einem FaaS-Service gemäß einer Ausführungsform veranschaulicht;
23 ein Beispiel eines Verfahrens zum Berechnen von Ressourcennutzung zu Abrechnungszwecken gemäß einer Ausführungsform ist;
24A ein Blockschaltbild eines Beispiels einer verteilten Rechenumgebung gemäß einer Ausführungsform ist;
24B ein Ablaufdiagramm eines anderen Beispiels zum Bereitstellen einer Function-as-a-Service gemäß einer Ausführungsform ist;
25A ein Blockschaltbild eines Beispiels eines FaaS-Systems ist, das Speicher-Wiederverwendung unter mehreren Funktionen gemäß einer Ausführungsform bereitstellt;
25B ein Ablaufdiagramm eines anderen Beispiels eines Verfahrens zum Bereitstellen einer Function-as-a-Service gemäß einer Ausführungsform ist;
26A ein Ablaufdiagramm eines anderen Beispiels zum Bereitstellen einer Function-as-a-Service gemäß einer Ausführungsform ist;
26B ein veranschaulichendes Diagramm einer Funktionsaufrufgrafik gemäß einer Ausführungsform ist;
26C ein veranschaulichendes Diagramm zum Spalten einer Funktion gemäß einer Ausführungsform ist;
26D ein anderes veranschaulichendes Diagramm einer Funktionsaufrufgrafik gemäß einer Ausführungsform ist;
26E ein veranschaulichendes Diagramm zum Zusammenführen von Funktionen gemäß einer Ausführungsform ist;
27A ein Blockschaltbild eines anderen Beispiels eines verbesserten FaaS-Systems mit einem Speicher, der von mehreren Funktionen gemeinsam verwendet wird, gemäß einer Ausführungsform ist;
27B ein Blockschaltbild eines anderen Beispiels eines verbesserten FaaS-Systems mit einem Speicher, der von mehreren Funktionen gemeinsam verwendet wird, gemäß einer Ausführungsform ist;
28A ein Ablaufdiagramm zum Bereitstellen eines Diensts gemäß einer Ausführungsform ist;
28B ein Blockschaltbild eines anderen Beispiels einer FaaS-Systems gemäß einer Ausführungsform ist;
29A ein Ablaufdiagramm zum Bereitstellen eines Diensts, der Container-Umkehrmerkmale unterstützt, gemäß einer Ausführungsform ist;
29B ein Blockschaltbild eines Beispiels eines FaaS-Systems, das Container-Umkehrmerkmale unterstützt, gemäß einer Ausführungsform ist;
30A ein Ablaufdiagramm zum Bereitstellen einer Function-as-a-Service, die eine Fortsetzungsanwendung zur verbesserten Funktions-Ausführungs-Performance gemäß einer Ausführungsform ist;
30B ein Blockschaltbild eines Beispiels eines FaaS-Systems ist, das eine Fortsetzungsanwendung für verbesserte Funktions-Ausführungs-Performance gemäß einer Ausführungsform aufweist;
die 31A und 31B Beispiele verbesserter Container-Konstruktionen und verbesserten Cache-Managements für FaaS gemäß einer Ausführungsform sind;
31C ein Ablaufdiagramm einer beispielhaften Cache-Räumung gemäß einer Ausführungsform ist;
31D ein Ablaufdiagramm einer anderen beispielhaften Cache-Räumung gemäß einer Ausführungsform ist;
31E ein Ablaufdiagramm zum Bestimmen einer Time-To-Live für zwischengespeicherte Datenobjekte gemäß einer Ausführungsform ist;
die 32A und 32B Beispiele einer verbesserten Funktionsverteilung gemäß einer Ausführungsform sind;
die 32C und 32D Beispiele einer verbesserten Funktionsverteilung gemäß einer Ausführungsform sind;
32E ein Funktionsverteilungs-Ablaufdiagramm gemäß einer Ausführungsform ist;
33A ein Beispiel eines verbesserten Funktionskonstrukts einer Funktion einer FaaS gemäß einer Ausführungsform ist;
33B ein Ablaufdiagramm einer Moniker-Identifikation aus einem verbesserten Funktionskonstrukt gemäß einer Ausführungsform ist;
34A eine Veranschaulichung eines Beispiels von Prefetching-Funktionen unter Verwenden einer Aufrufgrafik basierend auf der Frequenz von Funktionsaufrufen gemäß einer Ausführungsform ist;
34B ein Beispiel eines Verfahrens zum Verbessern der Ausführung einer FaaS-Funktion gemäß einer Ausführungsform ist;
35A ein Blockschaltbild ist, das vorhergehende Funktionen einer aktuellen Funktion gemäß einer Ausführungsform veranschaulicht;
35B ein Beispiel eines Verfahrens zum Ausführen einer FaaS-Funktion basierend auf Vorläuferfunktionen gemäß einer Ausführungsform ist;
36A ein Beispiel zum Aufrechterhalten der Wärme eines Containers basierend auf einer Wahrscheinlichkeit, dass eine Funktion ausgeführt wird, gemäß einer Ausführungsform veranschaulicht;
36B ein Beispiel eines Verfahrens zum Ausführen einer FaaS-Funktion aus einem warmen Container gemäß einer Ausführungsform ist;
37A ein Blockschaltbild ist, das adaptives Speicher-Tiering basierend auf Größe gemäß einer Ausführungsform veranschaulicht;
37B ein Blockschaltbild ist, das adaptives Speicher-Tiering basierend auf Nutzung gemäß einer Ausführungsform veranschaulicht;
37C ein Beispiel eines Verfahrens zum adaptiven Speicher-Tiering einer Funktion gemäß einer Ausführungsform ist;
38A eine Umgebung für schnelles Klassenladen für FaaS gemäß einer Ausführungsform veranschaulicht;
38B ein Beispiel eines Verfahrens zum Ausführen einer Funktion in einer verbesserten FaaS-Rechenumgebung gemäß einer Ausführungsform ist;
38C ein Beispiel eines Verfahrens zum Ausführen einer Funktion in einer verbesserten FaaS-Rechenumgebung gemäß einer Ausführungsform ist;
39A eine FaaS-Umgebung veranschaulicht, die kontinuierliches Anwenden sowohl chronologischen als auch Cloud-fähigen (horizontalen) Feedbacks gemäß einer Ausführungsform erleichtert;
39B unterschiedliche Vektoren jedes Funktionstyps gemäß einer Ausführungsform veranschaulicht;
39C ein Beispiel eines Verfahrens zum Vorabreservieren entsprechender Ressourcen gemäß einer Ausführungsform ist;
40A unterschiedliche Merkmale in Zusammenhang mit Code-Optimierung gemäß einer Ausführungsform veranschaulicht;
40B ein Beispiel eines Verfahrens zum Ausführen einer Funktion bei einem verbesserten FaaS-Computing gemäß einer Ausführungsform ist;
41A eine Grafik ist, die die Beziehung zwischen Nachfragefingerabdrücken und Funktionsausführungen gemäß einer Anführungsform zeigt;
41B einen Vorgang eines Ressourcenmanagers gemäß einer Ausführungsform veranschaulicht;
41C ein Beispiel eines Verfahrens zum effizienten FaaS-Ressourcenmanagement unter Verwenden von Nachfragefingerabdrücken gemäß einer Ausführungsform ist;
41D ein Beispiel eines Nachfragefingerabdrucks gemäß einer Ausführungsform ist;
42A ein Beispiel für Kommunikation zwischen einem Funktions-Client und einer Funktionsausführungsmaschine gemäß einer Ausführungsform ist;
42B ein Beispiel eines Verfahrens zum Ausführen einer FaaS-Funktion unter Verwenden undurchsichtiger Marker gemäß einer Ausführungsform ist;
43A eine Veranschaulichung eines Beispiels einer Standortauswahl basierend auf einem Token, das einen Kontext einer Funktion eindeutig identifiziert, gemäß einer Ausführungsform ist;
43B ein Ablaufdiagramm von Managementfunktionsaufrufen gemäß einer Ausführungsform ist;
43C ein Ablaufdiagramm eines ausführlichen Verfahrens von Managementfunktionsaufrufen gemäß einer Ausführungsform ist;
43D ein Blockschaltbild eines Beispiels eines FaaS-Systems ist, bei dem die Lage von Funktionsaufrufen basierend auf Anforderungsquelle ausgewählt wird;
43E ein Blockschaltbild eines Beispiels eines FaaS-Systems ist, bei dem die Lage von Funktionsaufrufen basierend auf dem Funktionsaufrufbaum ausgewählt wird;
44A ein Blockschaltbild eines Beispiels eines domänenübergreifenden Steuertransfers gemäß einer Ausführungsform ist;
44B ein Ablaufdiagramm zum Betreiben einer Fernvorgehensweisen-Aufgerufenen gemäß einer Ausführungsform ist;
44C ein Ablaufdiagramm des Betreibens einer Fernvorgehensweisen-Anrufers gemäß einer Ausführungsform ist;
45A ein Blockschaltbild eines Beispiels einer FaaS-Architektur, bei der die Anwendungsschichtfunktionen an der gleichen Stelle mit Datenebenenfunktionen liegen, gemäß einer Ausführungsform ist;
45B ein Ablaufdiagramm des Betreibens eines Laufzeit-Framework gemäß einer Ausführungsform ist;
46A eine Veranschaulichung eines Beispiels einer maßgeschneiderten Antwortobjektlösung gemäß einer Ausführungsform ist;
46B ein Ablaufdiagramm maßgeschneiderter Antwortobjekte auf Aufrufinstanzen gemäß einer Ausführungsform ist;
47A eine Veranschaulichung eines Beispiels einer Parameter-Rangierlösung gemäß einer Ausführungsform ist;
47B ein Diagramm eines Beispiels einer höheren Architektur, die Funktionen gleichmäßig über Plattformen aufruft, gemäß einer Ausführungsform ist
47C ein Ablaufdiagramm von Sortierfunktionsparametern gemäß einer Ausführungsform ist;
48A ein Blockschaltbild eines Beispiels eines Transfers von Fähigkeitsinformationen zwischen Funktionen gemäß einer Ausführungsform ist;
48B ein Blockschaltbild eines Beispiels codierter Inline-Fähigkeitsinformationen (Encoded Inline Capability - EIC-Informationen) gemäß einer Ausführungsform ist;
48C ein Blockschaltbild eines Beispiels eines Hardware-Warteschlangenmanagers gemäß einer Ausführungsform ist;
48D ein Ablaufdiagramm des Betreibens eines Hardware-Warteschlangenmanagers gemäß einer Ausführungsform ist;
48E ein Ablaufdiagramm zum Einreihen einer Fähigkeit gemäß einer Ausführungsform ist;
48F ein Ablaufdiagramm des Ausreihens einer Fähigkeit gemäß einer Ausführungsform ist;
49A eine Veranschaulichung eines Beispiels einer Abbildung zwischen Schlüsselindikatoren und Schlüsseln gemäß einer Ausführungsform ist;
49B ein Blockschaltbild eines Beispiels eines Einzeladressraums gemäß einer Ausführungsform ist;
49C ein Blockschaltbild eines Beispiels eines Kontextwechsels gemäß einer Ausführungsform ist;
49D ein Blockschaltbild eines Beispiels einer Schlüsselindikator-Kartenaktualisierung gemäß einer Ausführungsform ist;
49E ein Ablaufdiagramm zum Aktualisieren von Schlüsselindikator-Abbildungen gemäß einer Ausführungsform ist;
49F ein Blockschaltbild eines Beispiels eines Adressumsetz-Pufferspeichers/Page-Miss-Handlers, der zwischen virtuellen Adressen und physischen Adressen abbildet ist;
50A ein Blockschaltbild eines Beispiels einer Schutzschlüsselindikator-Aktualisierungsanweisung gemäß einer Ausführungsform ist;
50B ein Ablaufdiagramm zum Aktualisieren eines Schutzschlüsselindikators gemäß einer Ausführungsform ist;
51A ein Blockschaltbild eines Beispiels eines unprivilegierten Bauelements, dem es erlaubt ist, Subseitenbefugnisse zu ändern, gemäß einer Ausführungsform ist;
51B ein Ablaufdiagramm zum Steuern von Subseitenbefugnissen gemäß einer Ausführungsform ist;
52A eine Veranschaulichung eines Beispiels eines entprivilegierten Modus-Pfads, der Fähigkeitsinformationsauflagen beinhaltet, gemäß einer Ausführungsform ist; und
52B ein Ablaufdiagramm zum Steuern von Speicherzugriffen gemäß einer Ausführungsform ist.

BESCHREIBUNG VON AUSFÜHRUNGSFORMEN
1 zeigt eine FaaS-Computing-Umgebung gemäß einer Ausführungsform. Ein Code-Entwickler schreibt Funktionscode 100 (hierin auch als „Computercode“ bezeichnet), der eine oder mehrere Computerfunktionen darstellt, unter Funktionscode 100 wird zu einer FaaS-Plattform 102, zum Beispiel in einem CSP-Datencenter 104, hochgeladen. Ein Auslöser 106, wie zum Beispiel ein Anwendungsfall oder ein Internet-der-Dinge-Ereignis (IoT-Ereignis), initiiert die Ausführung des Funktionscodes 100 an der FaaS-Plattform 102. Die Umgebung, in der der Code einer Funktion ausgeführt wird, wird ein Container genannt. Der Container kann eine beliebige Entität zur isolierten Ausführung sein, wie ein Prozess, ein Docker- oder Kubernetes-Container, eine virtuelle Maschine usw. sein. Ein Container, der in seiner eigenen virtuellen Maschine läuft, wird ein virtueller Container genannt. Innerhalb eines CSP-Datencenters 104, die die FaaS-Plattform 102, ihr Datencenter, Edge-Umgebung, und die IoT-Vorrichtungen (einschließlich mobiler Vorrichtungen), über die die CSPs Kontrolle haben, beinhaltet, wird Infrastruktur „hochgefahren“ (zum Beispiel aktiviert und/oder zugeordnet), und auf Anfrage skaliert. Der Funktionscode 100 wird auf der physischen Infrastruktur/Edge/Iot-Vorrichtung und darunterliegenden virtualisierten Containern des CSP ausgeführt. Abschließend wird die Infrastruktur als Reaktion auf das Beenden der Ausführung „heruntergefahren“ (zum Beispiel deaktiviert und/oder freigegeben).
Wie unten ausführlicher besprochen wird, reduziert Technologie, die hierin beschrieben ist, Besorgnisse in Zusammenhang mit proprietärem Lock-in, kostspieligen Kaltstarten, Latenz und des Managements/der Steuerung von Code-Ausführungszuständen durch Bereitstellen verbesserter FaaS-Merkmale, wie Ausführen von Funktionscodes auf Anfrage als Reaktion auf Ereignisse und automatisches Skalieren mit einer Anzahl von Ereignissen basierend auf atomaren Maßstabeinheiten, die Funktionscode mit seiner entsprechenden Funktion als ein Recheneinheitsmaßstab. Technologie, die hierin beschrieben ist, reduziert die oben erwähnten Besorgnisse weiter durch Ermöglichen einer Breite von Verbesserungen, Erlauben von Plattformendiversität und/oder Ermöglichen von Sicherheit direkt in Hardware und durch Standardbibliotheken oder Laufzeiten. Zusätzlich erleichtert Technologie, die hierin beschrieben ist, das Aufzeigen und Umsetzen neuer Halbleiter-Features. Indem es Entwicklern ermöglicht wird, Anwendungen unter Verwenden von Hochsprachen, die von CSP-FaaS-Plattformen unterstützt werden, und durch Vereinfachen von Vorgängen, Optimierung, Anpassungsfähigkeit und Skalierung aufzubauen, kann die hierin beschriebene Technologie Nicht-Fachmann-Entwickler ermächtigen, robuste, hochleistende und sichere FaaS-Lösungen zu erzielen, die transparent von den Beschleunigungsfähigkeiten, die in der Hardware bereitgestellt werden, profitieren. Die hierin beschriebene Technologie kann ferner das Codieren vereinfachen und die Nachfrage nach Computing bei den CSP-FaaS-Plattformen ankurbeln.
2B zeigt Beispiele von Bauelementen 200 (200a-200b) eines verbesserten FaaS-Systems 202, wie hierin beschrieben. Im Vergleich mit Herausforderungen in Zusammenhang mit den existierenden FaaS-Services, wie in 2A gezeigt, stellt das verbesserte FaaS-System 202 zahlreiche Verbesserungen bereit, wie effiziente Funktionscodeausführung in einer ereignisorientierten Ausführungsumgebung, die minimale Verwaltung benötigt, während sie hohe Skalierbarkeit und feines Abrechnen bietet. Bei dem veranschaulichten Beispiel stellt ein Ereignisorientierungsbauelement 200a sicher, dass der Funktionscode auf Anfrage als Reaktion auf Ereignisse ausgeführt wird, ein Mindestverwaltungsbauelement 200b abstrahiert Infrastrukturmanagement zum Ausführen von Funktionscode von den Benutzern (zum Beispiel den Code-Entwicklern) entfernt durch einen FaaS-Service-Anbieter, ein Hochskalierfähigkeitsbauelement 200c skaliert Funktionscodeausführung automatisch mit der Anzahl von Ereignissen (zum Beispiel Benutzerereignisse oder IoT-bezogene Ereignisse), ein Atomar-Skaliereinheitsbauelement 200d verteilt Computercode mit seiner entsprechenden Funktion als eine Recheneinheitsskala, und ein Feinkorn-Abrechnungsbauelement 200e ermöglicht es Kunden (zum Beispiel Computer-Codeentwicklern), nur zu zahlen, wenn ihr Code ausgeführt wird, und Kunden werden zum Beispiel in Inkrementen zu je 100 Millisekunden fakturiert. Das verbesserte FaaS-System 202 kann auch andere vorteilhafte Bauelemente beinhalten, wie unten ausführlicher besprochen ist.
Benutzer und CSPs werden folglich erheblichen Wert durch das verbesserte FaaS-System 202 für sich gewinnen. Die Werte, die das verbesserte FaaS-System 202 Benutzern bietet, beinhalten zum Beispiel gesteigerte Konzentration auf die Entwicklung von Vorgängen von Interesse, verringerte Markteinführungszeit (Time To Market - (TTM-Zeit), reduziertes Infrastrukturmanagement und reduzierte Gesamtbetriebskosten (Total Cost of Ownership - TCO). Für einen CSP kann der Wert, der von dem verbesserten FaaS-System 202 geboten wird, zum Beispiel das Ankurbeln der Annahme von Services mit hoher Marge, höheren Verdienst pro Recheneinheit, Ermöglichen neuer Cloud-Workloads, verbesserte Kostentilgung, Elastizität bei der Planung von Rechenressourcen und Bereitstellen der Fähigkeit mit anderen CSPs zu konkurrieren, beinhalten.
Bei einer Ausführungsform gibt es fünf Bauelemente des verbesserten FaaS-Systems 202. Das erste ist ein Funktionsformatbauelement zum Schaffen von Funktionen und Ausführen von Computercode der Funktionen. Ein Beispiel eines Funktionsformatbauelements sind die FaaS-Exekutoren 310, 324, 319, 315, wie in 3 veranschaulicht (unten besprochen). Das zweite ist ein Ereignisverarbeitungs-API-Proxy-Bauelement zum Routen von Ereignisaufrufen zu Funktionen. Ein Beispiel eines Ereignisverarbeitungs-API-Proxy ist ein Benutzerschnittstellen-Handler 402 der 4 (unten besprochen). Das dritte Bauelement ist ein Funktionscodespeicher, der Funktionscodepakete empfängt, speichert und sichert. Ein Beispiel des Funktionscodespeichers ist ein Netzwerk-, Lagerungs- und Speichermanager 408 der 4 (unten besprochen). Das vierte Bauelement ist ein FaaS-Container, der eine Funktionsausführungsumgebung bereitstellt, in der Funktionscode heruntergeladen und in einem Container oder in anderen Alternativen für isolierte Ausführung instanziiert wird. Ein Beispiel des FaaS-Containers ist eine FaaS-Architektur 406 der 4 (unten besprochen). Nach der Ausführung wird der Container für neue Funktionen gelöscht (oder zurückgestellt, reinitialisiert usw.). Container laufen zur Sicherheit und Isolierung oft innerhalb virtueller Maschinen (VMs). Das letzte Kernbauelement ist ein Funktions-/Container-Orchestrierungsbauelement zum Optimieren von Containerplatzierung innerhalb verfügbarer Rechenressourcen durch Hochfahren des Containers für Funktionscode (zum Beispiel „Kaltstarten“). Ein Beispiel des Funktion-Container-Orchestrierungsbauelements ist ein Orchestrator 404 der 4 (unten besprochen). Falls eine Funktion vor kurzem gelaufen ist, kann eine neue Funktion in einen bereits „warmen“ Container platziert werden, was Instanziierungslatenz verringert. Ein warmer Container kann ein Container sein, der kürzlich verwendet wurde, um eine Funktion auszuführen, oder ein Container, der häufig zur Funktionsausführung verwendet wird. Statt den Container nach dem Fertigstellen der Funktionen abzubauen, kann der Container für zukünftige Funktionsausführungen behalten werden. Der Container kann daher dahingehend als „warm“ betrachtet werden, dass der Container nicht aufgebaut zu werden braucht und zur sofortigen Ausführung einer Funktion bereit ist.
3 zeigt eine FaaS-Serverkonfiguration 300 zum Bereitstellen verbesserter FaaS-Performance für Benutzer/CSPs. In der veranschaulichten Illustration beinhaltet die FaaS-Serverkonfiguration 300 eine Smart-Network-Interface-Card (NIC) 302, die FaaS-Managementlogik 304 auf einem verbesserten FaaS-Substrat 306 beinhaltet. Bei einigen Ausführungsformen funktioniert die Smart-Network-Interface-Card 302 als eine Leitstelle der FaaS-Serverkonfiguration 300. Die FaaS-Serverkonfiguration 300 beinhaltet eine oder mehrere Computercode-Ausführungseinheiten, die dazu konfiguriert sind, mehrere Sätze von Funktionen auf eine orchestrierte Art auszuführen. Bei anderen Ausführungsformen können die FaaS-Managementlogik 304 und das verbesserte FaaS-Substrat 306 verschiedentlich in einem Host-Prozessor Baseboard-Management-Controller (BMC), in einem Prozessor, in einem Softwaremodul, das auf einem Prozessor ausführt, einer speziellen Funktionslogik und/oder als einer Kombination davon umgesetzt werden. Bei dem veranschaulichten Beispiel verwenden eine oder mehrere Zentraleinheiten (CPUs) 308a bis - 308n (zum Beispiel Host-Prozessor) einen FaaS-Exekutor 310, um einen ersten Satz von Funktionen 312 auszuführen, einen oder mehrere Beschleuniger 314a bis 314n (zum Beispiel Hardwarelogik mit fester Funktionalität - Fixed-Functionality Hardware Logic), der einen zweiten Satz von Funktionen 316 ausführt, ein oder mehrere feldprogrammierbare Gate-Arrays (Field Programmable Gate Arrays - FPGAs) 318a bis 318n, die einen dritten Satz von Funktionen 320 ausführen, und eine oder mehrere Grafikverarbeitungseinheiten (Graphics Processing Units - GPUs) 318a bis 318n, die einen vierten Satz von Funktionen 326 ausführen. Die veranschaulichte FaaS-Serverkonfiguration 300 wird folglich von spezialisiertem Halbleiter mit Leistung versorgt, einschließlich der GPUs 322a bis 322n, FPGAs 318a bis 318n und spezialisierten Beschleuniger 314a bis 314n. Die FaaS-Serverkonfiguration 300 kann mehrere CPUs 308a bis 308n, GPUs 322a bis 322n, FPGAs 318a bis 318n und andere spezialisierte Beschleuniger 314a bis 314n enthalten.
Hier sei angemerkt, dass die spezialisierten Beschleuniger 314a bis 314n voneinander unterschiedliche Typen sein können. Jeder der spezifizierten Beschleuniger 314a bis 314n kann zum Beispiel spezifisch zum Beschleunigen bestimmter Funktionen oder Primitiven konzipiert sein (zum Beispiel Beschleuniger, die spezifisch für Matrix-Multiplikationen während des Trainings eines Maschinenlern-Modells (ML-Modell) konzipiert sind, Beschleuniger für effizienteren Leistungs- und Energieverbrauch und/oder Beschleuniger für bessere Sicherheit und besseren Datenschutz bestimmter Berechnungen und Daten).
Auf ähnliche Weise können die CPUs 308a bis 308n der FaaS-Serverkonfiguration 300 unterschiedliche Architekturen aufweisen (zum Beispiel von unterschiedlichen Verkäufern hergestellt und mit unterschiedlichen Schaltplänen sowie Architekturen). Bei einigen Ausführungsformen könnten die CPUs 308a bis 308n zum Beispiel eine Kombination aus diversen Intel-Architekturen, höheren Reduced-Instruction-Set-Computer-Machine-Prozessoren, Microprocessor-Without Interlocked-Pipelined-Stages-Prozessoren und Reduced-Instruction-Set-Computer-V-Prozessoren (RISC-V-Prozessoren) sein. Bei einigen Ausführungsformen können die CPUs 308a bis 308n alle ein und dieselbe Architektur (zum Beispiel Intel-Architektur) aufweisen. Auf ähnliche Art können die GPUs 322a bis 322n gleiche oder unterschiedliche Architekturen aufweisen (zum Beispiel von unterschiedlichen Verkäufern hergestellt und mit unterschiedlichen Schaltplänen). Auf ähnliche Art können die FPGAs 318a bis 318n gleiche oder unterschiedliche Architekturen aufweisen (zum Beispiel von unterschiedlichen Verkäufern hergestellt und mit unterschiedlichen Schaltplänen). Auf ähnliche Art können die spezialisierten Beschleuniger 314a bis 314n außerdem gleiche oder unterschiedliche Architekturen aufweisen (zum Beispiel von unterschiedlichen Verkäufern hergestellt und mit unterschiedlichen Schaltplänen). Darüber hinaus können die Ausführungseinheiten, CPUs 308a bis 308n, GPUs 322a bis 322n, FPGAs 318a bis 318n und spezialisierten Beschleuniger 314a bis 314n analoge Auslegungen zusätzlich zu der digitalen Auslegung aufweisen.
FaaS-Workloads weisen wahrscheinlich unterschiedliche Merkmale von herkömmlichen Workloads auf, zum Beispiel mit feinerer (das heißt gesteigerter) Körnigkeit der Workload. Die gesteigerte Körnigkeit von Workloads kann es erleichtern, spezialisierte Halbleiter zu nutzen, wie die Beschleuniger 314a bis 314n und die FPGAs 318a bis 318n. Durch Disaggregieren mehrere Sätze von Funktionen ermöglicht es die FaaS-Serverkonfiguration 300 dem CSP, jeder Workload (zum Beispiel Umschlüsseln, Schlussfolgerung, spezialisierte Vorgänge usw.) mit einem optimalen Halbleiterteil, wie dem Beschleuniger 314a bis 314n, dem FPGAs 318a bis 318n, der CPU 308a bis 308n, den GPUs 322a bis 322n usw.) gerecht zu werden. FaaS-spezifische Hardware, wie die FaaS-Serverkonfiguration 300, die in 3 beschrieben ist, ist fähig, die FaaS-Performance und Annahme bei mehr Benutzern und CSPs zu verbessern Die verbesserte FaaS-Lösung bietet hohe Grade an Anpassungsfähigkeit und Heterogenität für verbesserte Ausführungsmerkmale im Vergleich zu existierenden Lösungen.
Die FaaS-Serverkonfiguration 300 kann mehr oder weniger der veranschaulichten Bauelemente beinhalten. Bei einem Beispiel kann die FaaS-Serverkonfiguration 300 zum Beispiel eine CPU, wie eine erste CPU 308a beinhalten. Bei einem anderen Beispiel kann die FaaS-Serverkonfiguration 300 einen FPGA, wie einen ersten FPGA 318a, und eine CPU, wie die CPU 308a, beinhalten. Bei noch einem anderen Beispiel beinhaltet die FaaS-Serverkonfiguration 300 den ersten Beschleuniger 314a und keine der CPUs 308a bis 308n. Bei noch einem anderen Beispiel beinhaltet die FaaS-Serverkonfiguration 300 mehrere CPUs 308a bis 308n, mehrere GPUs 322a bis 322n, einen FPGA, wie den FPGA 318a, und mehrere spezialisierte Beschleuniger 314a bis 314n unterschiedlicher Typen.
Unter Bezugnahme auf 4 ist eine Ausführungsform eines verbesserten FaaS-Systems 400 gezeigt. Das veranschaulichte System 400 beinhaltet einen Benutzerschnittstellen-Handler 402, einen Orchestrator 404, eine FaaS-Architektur 406, ein Netzwerk, Lagerung, Speichermanager 408 und einen Sicherheitsmanager 410. Bei einer Ausführungsform empfängt das System 400 FaaS-Funktionscode 412, der unter Verwenden der FaaS-Architektur 406, die eine Container-/Funktionsausführungsumgebung bereitstellt, auszuführen ist. Das veranschaulichte System 400 erfasst auch ein oder mehrere FaaS-Ereignisse 414, die von dem System 400 empfangen werden, wie Benutzeranforderung zum Ausführen seines Computercodes, zum Beispiel des FaaS-Funktionscodes 412. Als Reaktion auf ein FaaS-Ereignis wird der entsprechende Funktionscode 412 heruntergeladen und in einem Container oder einer anderen Alternative mit isolierter Ausführung des Systems 400 instanziiert. Der Benutzerschnittstellen-Handler 402 ist ein Ereignisverarbeitungs-API-Proxy, der Ereignisaufrufe zu entsprechenden Funktionen des Computercode 412 routet. Der Orchestrator 404 optimiert die Ausführung der Funktionen (zum Beispiel mit einem Container, einer virtuellen Maschine, einem Prozess usw.) innerhalb verfügbarer Rechenressourcen durch Hochlaufen von Containern und anderer Ausführungsmaschinen für den Funktionscode 412. Falls eine Funktion kürzlich in einem Container gelaufen ist, ist der Container als ein „warmer“ Container gekennzeichnet. Der Orchestrator 404 kann eine neue Funktion in einen bereits „warmen“ Container (und allgemeiner in eine bereite Ausführungsmaschine) platzieren, was die Instanziierungslatenz verringert. Der Begriff „Container“, wie er hierin verwendet wird, kann als irgendeine Form einer Ausführungsmaschine für Code, wie der Funktionscode 412, betrachtet werden. Der Container kann ein Prozess, eine Prozessgruppe, eine virtuelle Maschine, eine Sandbox-Umgebung innerhalb eines Prozessadressraums, ein Prozess innerhalb einer virtuellen Maschine usw. sein. Das Netzwerk, die Lagerung und der Speichermanager 408 empfangen und speichern den Funktionscode 412, der durch den Sicherheitsmanager 410 gesichert wird. Bei einem Beispiel stellt der Sicherheitsmanager 410 sicher, dass die Container zur Sicherheit und Isolation innerhalb von VMs laufen.
Der Orchestrator 404 kann auch die folgenden Unterbauelemente beinhalten: Telemetriemanager 416, Profilmanager 418, Advisor für Maschinenlernen-/Künstliche Intelligenz (ML/AI) 420, und Service-Level-Vertrag-/Service-Qualitätsmanager (SLA/QoS-Manager) 422. Der Orchestrator 404 kann Daten profilieren, wie zum Beispiel Ressourcenerfordernisse und/oder Nachfrageprofile von Funktionen, die in Zusammenhang mit den Ausführungsformen der 13A bis 13C beschrieben sind, statische und dynamische Profilinformationen einer Funktion, wie unter Bezugnahme auf die Ausführungsformen der 24A bis 24B beschrieben, und dynamische Profile, wie unten unter Bezugnahme auf die 40A bis 40B beschrieben.
Der Telemetriemanager 416 kann ferner Ressourcenerfordernisse für Funktionen überwachen und aufzeichnen, zum Beispiel als Metrik-Daten (zum Beispiel Cache-Nutzung über der Zeit) und/oder Nachfrageprofile, wie in den Ausführungsformen der 13A bis 13C beschrieben, Hintergrund-Performance-Überwachung und spezifische Performance-Telemetrie, die sich während der Ausführung einer Funktion ergibt, wie unter Bezugnahme auf die Ausführungsformen der 7A bis 7C beschrieben, Out-Of-Band-Telemetrie (OOB-Telemetrie), wie unter Bezugnahme auf die Ausführungsformen der 22 beschrieben, Telemetrie- und Profilinformationen, wie unter Bezugnahme auf die 24A bis 24B beschrieben, und Telemetrieinformationen, wie unter Bezugnahme auf die Ausführungsformen der 36A-36B beschrieben. Darüber hinaus kann der SLA/QoS-Manager 422 eingesetzt werden, um eine adressbasierte QoS, Serviceklasse, Seitenebenen-QoS und/oder Thread-Level-QoS, wie unter Bezugnahme auf die Ausführungsformen der 21A bis 21D beschrieben, sowie als QoS-gemäße Ausführung, QoS-Manifestvektor, QoS-Mix, Sicherheitsvektor und/oder QoS-Spezifikation, wie unter Bezugnahme auf die 39A bis 39C beschrieben.
Es versteht sich, dass der Orchestrator 404, der Telemetriemanager 416, der Profilmanager 418, der ML/AI-Advisor 420 und der SLA/QoS-Manager 422 kombiniert und auf diverse Weisen eingesetzt werden können, um die Ausführungsformen, die hierin beschrieben sind, auszuführen. Darüber hinaus können unterschiedliche Einrichtungen des Orchestrators 404 verwendet werden, bei welchen nur ein Teilsatz des Telemetriemanagers 416, des Profilmanagers 418, des ML/AI-Advisors 420 und des SLA/QoS-Managers 422 Teil des Orchestrators 404 sind.
Bei einigen Ausführungsformen sammelt das verbesserte FaaS-System 400 mit dem Telemetriemanager 416 Telemetrieinformationen in Zusammenhang mit einer Funktion, die ausgeführt wird. Die Telemetrieinformationen können als Teil der Profilinformationen über diese Funktion verwendet werden und werden von dem Profilmanager 418 gespeichert. Der SLA/QoS-Manager 422 kann die Profilinformationen des Profilmanagers 418 zusätzlich zum Holen von Beratung und/oder Anweisungen von dem ML/AI-Advisor 420 zum Abbilden der Funktionsausführungen zu unterschiedlichen Ausführungseinheiten aufrufen, um die Effizienz zu verbessern, während die Anforderungen (zum Beispiel Zeit- und/oder Kosteneinschränkungen) zukünftiger Aufrufe der Funktion erfüllt werden. Bei einer Ausführungsform kann der ML/AI-Advisor 420 Anomalieerfassung basierend auf zuvor beobachteten Szenarien ausführen und entsprechende Aktionen setzen, und/oder den SLA/QoS-Manager 422 unterrichten.
Der Orchestrator 404 kann eine FaaS-Funktion effizient zur Ausführung platzieren. Zusätzlich zu algorithmischen und regelbasierten Mechanismen, die in dem Orchestrator 404 eingebettet sind, kann der ML/AI-Advisor 420 den Orchestrator 404 bei Planungsfunktionen führen. Aufgrund des kontinuierlichen Betriebs des FaaS-Systems 400 können enorme Mengen an „Telemetrie“-Daten von dem Telemetriemanager 416 gesammelt werden. Solche Telemetriedaten können die Ausführungsmerkmale von Funktionen auf unterschiedlichen Bereichen von Systemen und zu unterschiedlichen Zeiten/Orten aufnehmen. Die Telemetrieinformationen können Attribute wie CPU-Nutzung, Speicherverbrauch, Cache-Hierarchie-Verhalten, E/A- und Networking-Verhalten, Zeit/Ort der Ausführung, Leistungs-/Energieverbrauch, Sicherheit/Datenschutzaspekte der Funktionen und ihrer Daten (zum Beispiel Sicherheitsanforderungen und Erfassung heimtückischer Attacken), Benutzer und Anwendungen, die die Funktionen aufrufen, Parameter und Daten, die von den Funktionen verwendet werden usw. beinhalten.
Der Profilmanager 418 kann die gesammelten Telemetrieinformationen (in Echtzeit sowie offline) sammeln und eine Zusammenfassung der Informationen erzeugen und die Korrelation und Antikorrelation des Ausführungsverhaltens von Funktionen ausfindig machen. Der Orchestrator 404 kann den Profilmanager 418 sowie den ML/AI-Advisor 420 abrufen, bevor er Funktionsplatzierungsaspekte, wie Zeit, Knoten, Beschleunigernutzung usw. bestimmt.
Der Orchestrator 404 kann zum Beispiel das Planen zweier oder mehrerer CPU-intensiver Funktionen auf demselben Prozessor zur selben Zeit verhindern. Stattdessen kann der Orchestrator 404 eine CPU-intensive Funktion mit einer speicherhungrigen Funktion (zum Beispiel einer Funktion, die eine große Menge an Speicher erfordert oder eine hohe Anzahl von Prozessor-Cache-Misses oder beide aufweist) auf demselben Prozessor planen. Ferner kann der Orchestrator 404 das Planen mehrerer E/A-intensiver Funktionen auf demselben System zur gleichen Zeit verhindern und so fort. Der Orchestrator 404 stellt daher sicher, dass der Ressourcenverbrauch der FaaS-Server ausgewogen bleibt.
Außerdem und zusätzlich zu solchen Regeln, die in dem Orchestrator 404 eingebettet sind, kann der ML/AI-Advisor 420 automatisch aus einer enormen Menge vergangener Informationen, die von dem Telemetriemanager 416 gesammelt und von dem Profilmanager 418 verarbeitet werden, lernen. ML-Modelle, die von dem Profilmanager 418 gesammelt und aufgebaut werden, können zum Beispiel den ML/AI-Advisor 420 beim automatischen Bestimmen der Platzierung der Funktionen zu ihrer Ausführung unterstützen. Als ein Beispiel können die Informationen mögliche ML-Modelle, die von dem Profilmanager 418 gesammelt und verarbeitet werden, beinhalten. Die ML-Modelle können zum Beispiel aufzeigen, dass bestimmte Sammlungen von Funktionen, die gleichzeitig auf demselben System ausgeführt werden, in ungewöhnlich schlechten Ausführungsmerkmalen (zum Beispiel Anomalien, Ausführungen mit hoher Latenz usw.) resultieren werden.
Der Orchestrator 404 kann die Funktionen, die auf allen Servern unter seiner Kontrolle laufen, und ihre Zustände bestimmen und aufzeichnen. Der Orchestrator 404 kann auch eine Sammlung verteilter Orchestratoren sein, die jeweils für einen Teilsatz von FaaS-Servern zuständig sind. Wenn eine neue Funktion zur Ausführung platziert werden soll, kann der Orchestrator 404 den ML/AI-Advisor abfragen und Führung bei der Platzierung der Funktion anfragen.
Der Orchestrator 404 kann daher während „adaptiv“ sein. Da Telemetriedaten laufend von dem Telemetriemanager 416 gesammelt werden, kann das verbesserte FaaS-System 400 ständig über Funktionsausführungsverhalten lernen.
Dieser Aspekt kann es dem verbesserten FaaS-System 400 ermöglichen, automatisch über neue Funktionen zu lernen, die zuvor von dem FaaS-System 400 nicht analysiert wurden, sowie über Phasenverschiebungen (zum Beispiel unter anderem plötzliche und/oder erhebliche Änderungen des Funktionsausführungsverhaltens, wie Änderungen der CPU-Nutzung, des Speicherverbrauchs, der E/A-Vorgänge und Netzwerkinteraktionen) und saisonale Effekte lernen. Saisonale Effekte können externe Ereignisse beinhalten, deren Auftreten und zeitliche Häufigkeit die Funktionsausführungen und Ausführungsmerkmale beeinträchtigen. Funktionen, die von saisonalen Effekten beeinflusst werden können, können zum Beispiel internetfähiges GPS beinhalten, werden von Straßenverkehr getrieben, die häufiger wären Stoßzeiten oder Staatsfeiertagen ausgeführt werden können. Ein anderes Beispiel kann das Ausführen von Streaming-Anwendungen von Videoinhalt nach normalen Arbeitszeiten beinhalten. Das verbesserte FaaS-System 400 kann zum Beispiel automatisch erfassen, dass plötzlich eine bedeutende Steigerung der Aufrufe für Ausführung einer besonderen Gruppe von Funktionen oder Zugriff auf einen besonderen Datensatz auftritt. Solche Informationen können dann im Einrichten von mehr FaaS-Servern zur Ausführung oder zum Bewegen der Daten näher an die Funktionsausführungsorte, einschließlich von Datencentern zu dem Rand des Netzwerks und/oder zum Zuordnen von mehr Speicher zu Plattformen mit disaggregierten Speicherarchitekturen resultieren.
5 zeigt eine Ausführungsform eines verbesserten FaaS-Systems 500, das Untersysteme beinhaltet. Bei dem veranschaulichten Beispiel beinhaltet das FaaS-System 500 eine Benutzererlebnissubsystem 502, ein Sicherheitssubsystem 504, ein Softwaresubsystem 506 (506a bis 506c) und ein Hardwaresubsystem 508 (508a bis 508d) Das ein Softwaresubsystem 506 kann Bibliotheken 506a, Frameworks 506b Plattformen und Orchestrationsmodule 506c und so fort beinhalten. Zusätzlich beinhaltet das veranschaulichte Hardwaresubsystem 508 CPUs 508a, GPUs 508b, Speicher und Lagerung 508c, Networking-Bauelemente 508d, Beschleuniger 508e (zum Beispiel FPGAs) usw. Das verbesserte FaaS-System 500 empfängt FaaS-Funktionscode 510, der auszuführen ist, und führt den Funktionscode 510 als Reaktion auf ein oder mehrere assoziierte FaaS-Ereignisse 512 aus.
Das verbesserte FaaS-System 500 ist folglich für einen diversifizierten Markt durch Schaffen von Gelegenheit zur Feature-Monetarisierung geeignet. Für kleinere Service-Anbieter, wie Kommunikationsservice-Anbieter (Communications Service Providers - CoSPs) und regionale CSPs, die Randlagen besitzen, stellt FaaS eine Chance zur größeren Beteiligung bei der nächsten Welle von Ende-zu Ende-Anwendungen und Diensten dar. Viele Anwendungen und Dienste der nächsten Generation werden eventuell erfordern, dass ein Abschnitt einer Anwendung oder eines Dienstes in der Nähe des Verbrauchers oder Unternehmens ausgeführt oder bereitgestellt werden. Das Hosten eines kleinen Portfolios an Funktionen an diesen Randorten ist für kleinere Player ein viel leichteres Unterfangen als das Anbieten reicher Plattformen als ein Dienst (Platforms as a Service - PaaS) mit allen Tools für Entwicklung und Vorgänge (Development and Operations - DevOps), APIs und Serverdiensten, wie denen, die von Hyperscale CSPs erhältlich sind.
Das verbesserte FaaS-System 500 verbessert existierende FaaS-Architekturen und erweitert die FaaS-Parameter durch Steigern von Mietdauer, Ausmaß und Nutzung von Rechenressourcen. FaaS wird wahrscheinlich ein Standardmodus für die Entwicklung Cloud-basierter Technologien werden, die Entwickler aller Backend-Infrastrukturwartung entledigen und Programmierung für viele und nicht nur einige wenige zugänglich machen. Auf diese Weise weist das verbesserte FaaS-System 500 das Potenzial auf, ein völlig neues Arbeiten für Entwickler bereitzustellen. Das veranschaulichtes System 500 unterstützt zum Beispiel Software, die FaaS-Anbieterangebote erweitert und ergänzt und/oder diese direkt bereitstellt. FaaS-Anbieter profitieren von einer niedrigeren Barriere gegenüber FaaS-Annahme mit besseren Tools, während Benutzer sich gesteigerter Verwendungseinfachheit, die von dem System 500 bereitgestellt wird, erfreuen.
Obwohl bestimmte Beispiele hier in Zusammenhang mit FaaS-Funktionen besprochen sind, sind die Konzepte umfassender an andere Typen von Softwarebereichen, wie zum Beispiel Nicht-FaaS-Container, Desktop-Anwendungen und so fort anwendbar.
Verbesserte FaaS-Architektur
Das verbesserte FaaS-System (zum Beispiel das FaaS-System, das in 4 und 5 veranschaulicht ist) kann auch Benutzerebenenfähigkeiten zum Verwenden von Softwarefunktionen und/oder beschleunigter Funktionen (zum Beispiel FPGA oder andere konfigurierbare Logik) zur direkten Steuerung von Hardware-Features bereitstellen. Ein solcher Ansatz kann für privilegierte Wartungsfunktionen, die eine Solid-State-Laufwerk-Blockvorrichtung (Solid-State Drive- SSD-Blockvorrichtung), Managementfunktionen für Beschleuniger und so fort sichern, vorteilhaft sein. Weil die Funktionen Run-To-Completion-Aufgaben, die nicht langlebig sind, sind, stellt hardwarebasierte Kontrolle über ihre Verwendung mehr Effizienz und Transparenz bereit als das Benötigen anderer Plattformsoftwareschichten (zum Beispiel für die Funktionen von irgendwelchen anderen Funktionen von Benutzerebenensoftware nicht unterscheidbar sind, um solchen Zugang zu vermitteln.
6A zeigt eine verbesserte FaaS-Architektur 600 für die Ressourcenzuordnung und Steuerung. Bei der veranschaulichten Architektur 600 beinhaltet eine erste Funktion 602 („F₁‟) Code 604, der innerhalb eines CPU-Containers 608 auszuführen ist, und ein Sicherheitsbescheinigungs-Token 606. Die veranschaulichte erste Funktion 602 ist auch mit Metadaten 610, die einen Satz von Benutzerebenenfähigkeiten, zum Beispiel Benutzerebenenfähigkeiten 614, 618, 622, 626 definieren, verbunden. Bei einem Beispiel entspricht der Satz von Benutzerebenenfähigkeiten einem oder mehreren Features außerhalb des Containers 608. Die Features 614 in einem OS 612 könnten zum Beispiel Speichermanagement, Systemaufrufe usw. oder eine beliebige Kombination davon beinhalten. Zusätzlich können Features 618 in einem VMM 616 (Virtual Machine Monitor - Monitor virtueller Maschine, zum Beispiel Hypervisor) Speichermanagement, Vorrichtungsmanagement, Netzwerkumkonfiguration, Zugang zu Netzwerkpfaden, virtuelle Softwareumkonfiguration usw. oder eine beliebige Kombination davon beinhalten. Bei einer Ausführungsform beinhalten die Features 622 in der CPU 620 Resource Director Technology-Monitorzähler (RDT-Monitorzähler), RDT-Cache- und Speichersteuerungen, Plattformservicegüte-Monitorzähler, Plattformservicegüte-Cache- und Speichersteuerungen, Hardware-Performance-Überwachungszähler, direktere Steuerung von DRAM, 3D XPoint, Speichervorrichtungen usw. oder eine beliebige Kombination davon. Darüber hinaus beinhalten Features 626 in dem Beschleuniger 624 (zum Beispiel FPGA) Hardwareumkonfiguration, Bitstreams (zum Beispiel FPGA-Umsetzungsbilder), Geräteresets usw. oder eine beliebige Kombination davon.
Das Sicherheitsbescheinigungs-Token 606, das mit der Funktion 602 assoziiert ist, kann schwierig, wenn nicht sogar unmöglich zu fälschen sein und an ein aufzählbares, auffindbares oder prüfbares Attribut einer Aktivierung der ersten Funktion 602 gebunden sein. Falls daher ein Prüfmodul 628 in dem OS 612 und/oder ein Prüfmodul 630 in dem VMM 616 bestimmt, dass das Sicherheitsbescheinigungs-Token 606 gültig ist, wird es der ersten Funktion 602 erlaubt, die Features 614, 618 622 und 626 (die zum Beispiel Benutzerebenenfähigkeiten entsprechen), zu verwenden. Die veranschaulichten gebogenen Pfeile von der ersten Funktion 602 stellen die diversen Aufrufe dar, die die erste Funktion 602 innerhalb des Containers 608 und außerhalb des Containers 608 eventuell vornimmt. Bei einem Beispiel können die genehmigten Features nicht reserviert oder anderswie von der Exposition mit der ersten Funktion 602 durch das VMM 616, das OS 612 oder andere Software-„Executive“ (zum Beispiel Hypervisor-Host, Gast-OS) verhindert werden. Die Architektur 600 kann nämlich den Satz von Benutzerebenenfähigkeiten erweitern/ergänzen, solange die Erweiterung keinen Richtigkeitsfehler (zum Beispiel Protokoll- und/oder Syntaxfehler) oder einen Sicherheitsverstoß schafft. Die Erweiterung kann zum Beispiel eine gefilterte Großansicht von OS/VMM-Zählern, eine maßgesteuerte Kontrolle über OS/VMM-Vorgänge, wie „Affinitization“ (zum Beispiel Durchsetzen von Affinitätsregeln, die Beziehungen zwischen VMs und Hosts einrichten) oder Policy-Hinting für Speicher-Tiering usw. beinhalten. Falls jedoch bestimmt wird, dass das Sicherheitsbescheinigungs-Token 606 gültig ist, verhindert die Architektur 600 die Verwendung der Benutzerebenenfähigkeiten durch die erste Funktion 602 und setzt die Ausführung mit Standard-Features fort. Die erste Funktion 602 kann daher direkt die Features außerhalb des Containers 608 aufrufen (zum Beispiel kommandieren), um den Container 608 zu umgehen.
Der veranschaulichte Beschleuniger 624 in 6A beinhaltet auch eine oder mehrere virtuelle Schnittstellen 632 (632a bis 632c), die separate Funktionen ermöglichen, um den Beschleuniger 624 umzukonfigurieren. Bei einem Beispiel konfiguriert die erste Funktion 602 den zweiten Beschleuniger 624 über eine erste virtuelle Schnittstelle 632a um, eine zweite Funktion 634 („F₂“) konfiguriert den Beschleuniger 624 über eine zweite virtuelle Schnittstelle 632b um, und eine dritte Funktion 636 („F₃“) konfiguriert den Beschleuniger 624 über eine dritte virtuelle Schnittstelle 632c um. Die virtuellen Schnittstellen 632 ermöglichen folglich die Verwendung von Single-Root-EA-Virtualisierung (SR-IOV-Virtualisierung) und/oder Serial-Rapid-EA (sRIO) in einer FaaS-Architektur wie der in 6A veranschaulichten Architektur.
Unter Bezugnahme auf 6B veranschaulicht 6B ein Verfahren 640 zum Managen von Benutzerebenenfähigkeiten unter Verwenden einer verbesserten FaaS-Architektur, wie der in 6A gezeigten. Das Verfahren 640 kann im Allgemeinen in einem verbesserten FaaS-System, wie zum Beispiel dem System 202 (2), dem System 300 (3), dem System 400 (4) und/oder dem System 500 (5), die bereits besprochen wurden, umgesetzt werden. Insbesondere kann das Verfahren 640 in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 642 stellt das Erfassen eines Sicherheitsbescheinigungs-Tokens mit einer Funktion, die innerhalb eines Containers ausgeführt wird, bereit. Ein Orchestrator stellt zum Beispiel die erforderlichen Sicherheitsbescheinigungs-Token bereit, wenn der Orchestrator die Funktion zu einem Funktionsaufrufer sendet. Ferner kann ein Aufrufer eine Registrierung solcher Sicherheitsbescheinigungs-Token führen und ist frameworkunabhängig. Sicherheitsbescheinigungs-Token können entweder von dem Aufrufer oder von dem Orchestrator vorab erzeugt werden, wenn zum Beispiel eine Funktion bei dem Orchestrator von einem Entwickler oder einem Verbraucher der Funktion registriert wird.
Bei Block 644 kann durch prüfen einer Signatur oder durch ein anderes anwendbares Verfahren eine Bestimmung erfolgen, ob das Sicherheitsbescheinigungs-Token gültig ist. Ist das der Fall, genehmigt der Block 646 eine Verwendung (zum Beispiel direkten Zugriff) durch die Funktion eines Satzes von Benutzerebenenfähigkeiten, wobei der Satz von Benutzerebenenfähigkeiten einem oder mehreren Features außerhalb des Containers entspricht. Der Satz von Benutzerebenenfähigkeiten kann zum Beispiel Selbstüberwachung, Kontrolle über einen Abschnitt eines virtuellen Raums, Kontrolle über Leseschutz für einen Bereich von Seiten, Kontrolle über Schreibschutz für einen Bereich von Seiten, Einrichten eines Namensraums für Objekte, die in persistentem Speicher gespeichert sind, Speichermanagement, Systemaufrufmanagement, Gerätemanagement, Netzwerkkonfiguration, Zugang zu Netzwerkpfaden, virtuelle Softwareumkonfiguration und so fort beinhalten. Darüber hinaus können die Features Hostprozessor-Features (zum Beispiel CPU-Features), OS-Features, Features einer virtuellen Maschine (zum Beispiel VMM), Beschleuniger-Features und so fort sein. Die Features können feine Reservierung oder Priorisierung gegenüber diversen Bauelementen der FaaS-Architektur beinhalten (wie zum Beispiel gemeinsame Nutzung des Prozessors, gemeinsame Nutzung des Cache, gemeinsame Nutzung des E/A-Durchsatzes, gemeinsame Nutzung des Beschleunigers und so fort), indem eine spezifische Technologie, wie die Intel® Resource Director Technology (RDT) oder ähnliche Technologien, die in GPUs, ASIC, PCIe Hub, FPGA usw. umgesetzt werden, verwendet wird.
Zusätzlich kann bei Block 648 eine Bestimmung darüber erfolgen, ob eine Erweiterung des Satzes von Benutzerebenenfähigkeiten Richtigkeitsfehler (zum Beispiel Protokoll- und/oder Syntaxfehler) oder einen Sicherheitsverstoß schafft. Ist das nicht der Fall, führt der veranschaulichte Block 650 die Erweiterung als Reaktion auf das Bestimmen, dass die Erweiterung keinen Richtigkeitsfehler oder Sicherheitsverstoß schafft, aus. Falls bei Block 648 bestimmt wird, dass die Erweiterung einen Richtigkeitsfehler oder Sicherheitsverstoß schaffen würde, endet das Verfahren 640. Falls bei Block 644 bestimmt wird, dass das Sicherheitsbescheinigungs-Token ungültig ist, verhindert Block 652 die Verwendung des Satzes von Benutzerebenenfähigkeiten durch die Funktion.
Unter Bezugnahme auf 6C veranschaulicht 6C ein Verfahren 660 zum Managen von Benutzerebenenfähigkeiten unter Verwenden einer verbesserten FaaS-Architektur, wie der in 6A gezeigten. Das Verfahren 660 kann im Allgemeinen in einem verbesserten FaaS-, System wie zum Beispiel dem System 202 (2), dem System 300 (3), dem System 400 (4) und/oder dem System 500 (5), die bereits besprochen wurden, umgesetzt werden. Insbesondere kann das Verfahren 660 in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 662 stellt durch Prüfen einer Signatur oder durch andere anwendbare Verfahren das Bestimmen, dass ein Sicherheitsbescheinigungs-Token, das mit einer Funktion assoziiert ist, gültig ist, bereit. Die Funktion kann innerhalb eines Containers ausgeführt werden. Block 664 bestimmt, ob die Funktion Zugriff auf eine oder mehrere nicht verfügbare Ressourcen und/oder Features verwendet und/oder erfordert. Block 664 kann zum Beispiel bestimmen, dass eine Ressource oder eine Fähigkeit nicht verfügbar ist, wenn die Ressource oder Fähigkeit auf Benutzerebene nicht verfügbar ist, und/oder für einen Container nicht verfügbar ist. Die Fähigkeitsquelle kann zum Beispiel Selbstüberwachung, Kontrolle über einen Abschnitt eines virtuellen Raums, Kontrolle über Leseschutz für einen Bereich von Seiten, Kontrolle über Schreibschutz für einen Bereich von Seiten, Einrichten eines Namensraums für Objekte, die in persistentem Speicher gespeichert sind, Speichermanagement, Systemaufrufmanagement, Gerätemanagement, Netzwerkkonfiguration, Zugang zu Netzwerkpfaden, virtuelle Softwareumkonfiguration und so fort beinhalten. Die Ressourcen können Hostprozessor-Features (zum Beispiel CPU-Features), OS-Features, Features einer virtuellen Maschine (zum Beispiel VMM), Beschleuniger-Features und so fort sein. Darüber hinaus können die Fähigkeiten und/oder Ressourcen feine Reservierung oder Priorisierung gegenüber diversen Bauelementen der FaaS-Architektur beinhalten (wie zum Beispiel gemeinsame Nutzung des Prozessors, gemeinsame Nutzung des Cache, gemeinsame Nutzung des E/A-Durchsatzes, gemeinsame Nutzung des Beschleunigers und so fort), indem eine spezifische Technologie wie die Intel® Resource Director Technology (RDT) oder ähnliche Technologien, die in GPUs, ASIC, PCIe Hub, FPGA usw. umgesetzt werden, verwendet wird.
Ist das der Fall, zählt Block 666 die erforderlichen Ressourcen und/oder Fähigkeiten, für die Benutzerebenenzugriff erforderlich ist, auf. Bei einigen Ausführungsformen kann Block 666 ferner eine Prüfung dahingehend beinhalten, ob eine Erweiterung des Satzes von Benutzerebenenressourcen und/oder Fähigkeiten einen Richtigkeitsfehler (zum Beispiel Protokoll- und/oder Syntaxfehler) oder einen Sicherheitsverstoß schafft, und zählt keine Ressourcen und/oder Fähigkeiten, die das tun, auf. Block 668 fügt die aufgezählten Ressourcen und/oder Fähigkeiten hinzu. Block 668 fügt zum Beispiel vorübergehend die aufgezählten Ressourcen und/oder Fähigkeiten zu dem Container der Funktion hinzu. Das vorübergehende Hinzufügen verbleibt während der Dauer der Funktion. Block 670 ermöglicht Benutzerebenenzugriff auf die aufgezählten Ressourcen und/oder Fähigkeiten.
Nachdem Block 670 ausgeführt wurde oder falls die Funktion keine nicht verfügbaren Ressourcen und/oder Fähigkeiten verwendet, bestimmt der veranschaulichte Block 672, ob irgendwelche optionalen zusätzlichen Ressourcen und/oder Fähigkeiten zu aktivieren sind. Block 672 sieht eine Tabelle ein, die optionale, zusätzliche Ressourcen und/oder Fähigkeiten beschreibt, die für die Performance günstig sind oder die Einfachheit verstärken (zum Beispiel die Fähigkeit, Seiten festzulegen, Threads nach Affinität zuzuweisen). Ist das der Fall, kann Block 674 die optionalen, zusätzlichen Ressourcen und/oder Fähigkeiten aufzählen. Wie oben bereits beschrieben, kann Block 674 ferner eine Prüfung dahingehend ausführen, ob ein Richtigkeitsfehler (zum Beispiel Protokoll- und/oder Syntaxfehler) oder ein Sicherheitsverstoß auftreten wird, falls eine besondere, zusätzliche Ressource und/oder Fähigkeit aufgezählt und für Benutzerebenenzugriff erlaubt wird. Falls ein Sicherheitsverstoß oder Richtigkeitsfehler für eine besondere optionale, zusätzliche Ressource und/oder Fähigkeit auftreten würde, wird die besondere optionale, zusätzliche Ressource und/oder Fähigkeit nicht aufgezählt. Block 674 zählt daher nur sichere und beständige optionale zusätzliche Ressourcen und/oder Fähigkeiten auf. Das heißt, dass nur optionale, zusätzliche Ressourcen und/oder Fähigkeiten, die keine Sicherheitsprobleme verursachen und die auch kein Risiko für beständiges Funktionieren des Systems (wie Deadlocks, Livelocks, Starvation usw.) darstellen, aufgezählt werden. Block 676 erlaubt Benutzerebenenzugriff auf sichere und beständige zusätzliche Ressourcen und/oder Fähigkeiten während der Dauer der Funktionsausführungen.
Nach dem Fertigstellen von Block 676, endet das Verfahren. Falls Block 672 bestimmt, dass keine weiteren Fähigkeiten und Ressourcen zu ermöglichen sind, endet das Verfahren.
Anzumerken ist, dass die Verfahren 640 und 660 geändert und miteinander kombiniert werden können. Die Boxen 664, 666, 668, 670, 672, 674, 676 können für eine oder mehrere Boxen 646, 648, 650 ersetzt werden.
Zusätzliche Anmerkungen und Beispiele
Beispiel 601 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz vom computerausführbare Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, ein Sicherheitsbescheinigungs-Token, das mit einer Funktion, die innerhalb eines Containers ausgeführt wird, erfasst, eine Verwendung eines Satzes von Benutzerebenenfähigkeiten durch die Funktion genehmigt, falls das Sicherheitsbescheinigungs-Token gültig ist, und die Verwendung des Satzes von Benutzerebenenfähigkeiten durch die Funktion verhindert, falls das Sicherheitsbescheinigungs-Token ungültig ist, wobei der Satz von Benutzerebenenfähigkeiten einer oder mehreren Fähigkeiten außerhalb des Containers entspricht.
Beispiel 602 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 601, wobei die Programmanweisungen, wenn sie von dem Rechengerät ausgeführt werden, das Rechengerät veranlassen, mindestens eine Erweiterung des Satzes von Benutzerebenenfähigkeiten auszuführen, falls das Sicherheitsbescheinigungs-Token gültig ist, wobei das Sicherheitsbescheinigungs-Token gültig ist, falls es keinen Richtigkeitsfehler oder keinen Sicherheitsverstoß schafft.
Beispiel 603 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 601, wobei der Satz von Benutzerebenenfähigkeiten aus einer Gruppe ausgewählt wird, die Selbstüberwachung, Kontrolle über einen Abschnitt eines virtuellen Raums, Kontrolle über Leseschutz für einen Bereich von Seiten, Kontrolle über Schreibschutz für einen Bereich von Seiten, Einrichten eines Namensraums für Objekte, die in persistentem Speicher gespeichert sind, Speichermanagement, Systemaufrufmanagement, Gerätemanagement, Netzwerkkonfiguration, Zugang zu Netzwerkpfaden und virtuelle Softwareumkonfiguration umfasst.
Beispiel 604 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 601, wobei das eine oder die mehreren Features aus der Gruppe ausgewählt werden, die Hostprozessor-Features, Betriebssystem-Features, Features einer virtuellen Maschine und Beschleuniger-Features umfasst.
7A zeigt einen FaaS-Rechenknoten, in dem diverse virtuelle Leistungs-Performance-Überwachungseinheitsereignisse (vPMU-Ereignisse) 700 auf der Funktions- oder Containerebene während der Ausführung einer Funktion 714 innerhalb eines Containers 702 überwacht werden. Die Ereignisse 700 können zum Überwachen über eine Architekturschnittstelle 704 (zum Beispiel Hardware und/oder Software), die geschachteltes Überwachen ermöglicht, konfiguriert sein. Was das Schachteln betrifft, kann das Überwachen innerhalb eines Containers oder sogar innerhalb einer Funktion auf dieselbe Weise erfolgen wie in einem Gast einer virtuellen Maschine, in einem Bare-Metal-Betriebssystem oder in einem Bare-Metal-Container. Mit anderen Worten hängt die Fähigkeit, ein Architekturereignis (zum Beispiel die Anzahl ausgeführter Anweisungen, die Anzahl von angetroffener Cache-Misses usw.) oder die Fähigkeit zum Abtasten von Softwareereigniszählern (wie eine Anzahl von Seitenfehlern, eingelagerte oder ausgelagerte Seiten, Anzahl empfangener oder übertragener Pakete usw.) nicht davon ab, wo Zähler gelesen werden. Darüber hinaus sind Messungen an jeder Ebene möglich, um eine Ablesung zu erhalten, die den Beitrag dieser besonderen Ebene (zum Beispiel eine Funktion, ein Container, ein Gast-OS, ein Host-OS usw.) zu dieser Ablesung widerspiegelt.
Bei dem veranschaulichten Beispiel beinhalten die Ereignisse 700 die Ausführungszeit, Anweisungen pro Zyklus (Instructions Per Cycle - IPC), Speicherbandbreite, Cache-Nutzung, E/A-Vorgänge pro Sekunde (I/O Operations Per second - IoPs) und Netzwerkbandbreite, obwohl andere Ereignisse ebenfalls überwacht/gesammelt werden können. Die Programmierung der Ereignisse 700, die zu überwachen sind, kann durch Systemsoftwarefähigkeiten vereinheitlicht werden. Bei einem Beispiel führen vPMU-Treiber, die zum Beispiel von dem Container 702 und/oder der Host-Maschine beigestellt werden, die Vereinheitlichung der Ereignisse 700 aus. Wie ausführlicher besprochen wird, können die Ereignisse 700 über diverse virtuelle PMU-Zähler (zum Beispiel „Schatten“-Zähler, die andere Zähler widerspiegeln) verfolgt werden.
In dem Zeitpunkt to wird zum Beispiel ein erster Schnappschuss 706 eines Zählerwerts, der mit der Ausführung der Funktion 714 in dem Container 702 verbunden ist, erzeugt. Auf ähnliche Art kann ein zweiter Schnappschuss 708 des Zählerwerts im Zeitpunkt t_n erzeugt werden, ein dritter Schnappschuss 710 des Zählerwerts kann im Zeitpunkt t_n+1 erzeugt werden und so fort. Der Zählerwert kann im Allgemeinen eines oder mehrere der Ereignisse 700 qualifizieren, wobei die Schnappschüsse 706, 708, 710 als Reaktion auf eine neue Anweisung, einen neuen Schnittstellenaufruf usw. erzeugt werden können. Das Umsetzen der Schnappschüsse 706, 708, 710 in Hardware kann den Softwareaufwand minimieren. Einer oder mehrere der Schnappschüsse 706, 708, 710 kann/können Schattenschnappschüsse sein, die andere Teile anderer vorab existierender Schnappschüsse an tieferen Ebenen der Softwareschachtelung widerspiegeln. Die Schnappschüsse 706, 708, 710 und/oder Unterschiede (zum Beispiel Deltas) zwischen den Schnappschüssen 706, 708, 710 werden in einem vPMU-Pufferspeicher 712 gespeichert, der als eine Notizblockspeicherfläche für die Funktion 714 funktionieren kann. Bei dem veranschaulichten Beispiel wird der vPMU-Pufferspeicher 712 mit einer oder mehreren der Funktionen 714, einem Orchestrator 716 oder einem Knotenmanager 718 über einen API-Endpunkt 720 (zum Beispiel Hypertext-Transfer- Protocol-Endpunkt/HTTP-Endpunkt) aufgezeigt.
Die veranschaulichte Lösung kann folglich verwendet werden, um Starvation hinsichtlich der Kapazität oder Bandbreite in einer FaaS-Infrastruktur, die beschränkte Speicherressourcen für jeden Funktionsaufruf bereitstellt, zu verhindern. Insbesondere und als ein Beispiel kann ein Entwickler der Funktion 714 überwachen, ob und wie viel Speicherseitenauslagerung oder Cache-Thrashing die Funktion 714 durch Programmieren einer vPMU antrifft, um OS-Metriken, Speicher-Cache- und Speicherzugriffsstatistiken zum Beispiel über die Schnappschüsse 706, 708, 710 zu erhalten. Zusätzlich können mehrere Knotenebenen-vPMUs in eine verteilte vPMU zusammengesetzt werden.
Unter Bezugnahme auf 7B ist ein vPMU-Pufferspeicher 722 gezeigt, in dem erste Metrikdaten 724 (zum Beispiel Telemetrieschnappschüsse und/oder unter Unterschiede zwischen Schnappschüssen), die mit der Ausführung einer Funktion 726 verbunden sind, zu der Funktion 726 und einer Containersoftware 728 bereitgestellt sind. Bei dem veranschaulichten Beispiel führt die Containersoftware 728 eine Aggregation der ersten Metrikdaten 724 (zum Beispiel Cache-Nutzung im Laufe der Zeit) aus und erzeugt zweite Metrikdaten 730 basierend auf der Aggregation. Zusätzlich kann die Funktion 726 die ersten Metrikdaten 724 sammeln und verarbeiten, um dritte Metrikdaten 732 zu erzeugen.
Unter Bezugnahme auf 7C wird ein Verfahren 734 zum Überwachen der Performance einer Funktion gezeigt. Das Verfahren 734 kann im Allgemeinen in einem verbesserten FaaS-System, wie zum Beispiel dem System 202 (2), dem System 300 (3), dem System 400 (4) und/oder dem System 500 (5), die bereits besprochen wurden, umgesetzt werden. Insbesondere kann das Verfahren 734 in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Bearbeitungsblock 736 stellt das Erzeugen eines ersten Schnappschuss eines Zählerwerts, der mit der Ausführung einer Funktion in einem Container verbunden ist, an einem ersten Zeitpunkt der Ausführung bereit, wobei ein zweiter Schnappschuss des Zählerwerts an Block 738 in einem zweiten Zeitpunkt der Ausführung erzeugt wird. Bei einem Beispiel speichert Block 740 einen oder mehrere erste Schnappschüsse, den zweiten Schnappschuss oder einen Unterschied zwischen dem ersten Schnappschuss und dem zweiten Schnappschuss hin zu einem vPMU-Pufferspeicher. Zusätzlich kann der vPMU-Pufferspeicher mit einer oder mehreren der Funktion, einem Orchestrator oder einem Knotenmanager über einen API-Endpunkt bei Block 742 aufgezeigt werden.
Technologie, die hierin beschrieben ist, ermöglicht es folglich einem Funktionsentwickler, in Verbindung mit Containern oder irgendeiner anderen Ausführungsmaschine zu arbeiten, um über Hintergrund-Performance überwachungspezifische Performance-Telemetrie, die sich während der Ausführung der Funktion ergibt, zu demarkieren. Ereignisausrichtung, minimale Administration, hohe Skalierbarkeit, atomare Maßstabeinheit und feine Abrechnung können alle erzielt werden. Ferner erlaubt sie eine für Privileg passende Ansicht der gesammelten Schnappschussdaten. Ein Containersoftwaremodul, das den Funktionscode hostet, kann zum Beispiel einige Ereignisse, die von einem vom Entwickler bereitgestellten Modul verborgen sind, beobachten und/oder identifizieren. Zum Beispiel und aufgrund unterschiedlicher Architekturen, kann der Funktionscode eventuell bestimmte Tendenzen nicht darlegen, wenn der Funktionscode in dem vom Entwickler bereitgestellten Modul gehostet wird, kann diese bestimmten Tendenzen jedoch zeigen, wenn er innerhalb des Containersoftwaremoduls gehostet wird. Die Technologie hierin erlaubt daher feine Performance-Verfolgung auf einer Plattform, die für den Entwickler nicht direkt zugänglich ist (der Entwickler hat zum Beispiel den Funktionscode nicht auf der Plattform entwickelt und/oder ausgetestet). Bei einigen Ausführungsformen kann ein FaaS-System (zum Beispiel ein Orchestrator oder Scheduler) gesammelte Schnappschussdaten für effizientere Planung und Zuordnungen verwenden.
Zusätzliche Anmerkungen und Beispiele
Beispiel 701 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen ersten Schnappschuss eines Zählerwerts, der mit der Ausführung einer Funktion in einem Container verbunden ist, zu erzeugen, einen zweiten Schnappschuss des Zählerwerts, der mit der Ausführung der Funktionen dem Container verbunden ist, zu erzeugen, und einen oder mehrere des ersten Schnappschuss, des zweiten Schnappschuss oder eines Unterschieds zwischen dem ersten Schnappschuss und dem zweiten Schnappschuss zu einem virtuellen Performance-Überwachungseinheit-Pufferspeicher (PMU-Pufferspeicher) zu speichern.
Beispiel 702 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 701, wobei die Programmanweisungen, wenn sie von dem Rechengerät ausgeführt werden, das Rechengerät veranlassen, den virtuellen PMU-Pufferspeicher mit einer oder mehreren der Funktion, eines Orchestrators oder eines Knotenmanagers über einen Anwendungsprogrammschnittstellenendpunkt (API-Endpunkt) zu exponieren.
Beispiele für gemeinsam verwendeten Speicher
Einige Ausführungsformen können vorteilhafterweise eine Pufferspeichererweiterung für In-Core-Meldungen, In-System-Meldungen, In-Plattform-Meldungen und/oder Maschinenmeldungskommunikation bereitstellen. Herkömmliche Kommunikation zwischen Funktionen über HTTP kann mehr Aufwand involvieren als erforderlich, falls zusammenarbeitende Funktionen auf demselben Kern, demselben System, derselben Plattform und/oder einer beliebigen von Ausführungseinheiten mit gemeinsam verwendetem Speicher liegen. Einige Ausführungsformen können gemeinsam verwendeten Speicher bereitstellen, um es zwei zusammenarbeitenden Funktionen zu erlauben, ein Speichersegment zum Kopieren des Inhalts von Daten, die zwischen den zwei Funktionen ausgetauscht werden, gemeinsam zu verwenden. Vorteilhafterweise können einige Ausführungsformen Aufwand aufgrund von Kommunikation zwischen Funktionen verhindern, indem sie den OS-Kernel und andere HTTP-Schichten umgehen.
Unter Bezugnahme auf 8A kann eine Ausführungsform eines elektronischen Verarbeitungssystems 810 einen Prozessor 811, Speicher 812, der kommunikationsfähig mit dem Prozessor 811 gekoppelt ist, und Logik 813, die kommunikationsfähig mit dem Prozessor 811 und dem Speicher 812 gekoppelt ist, beinhalten, um einen Speicherbereich des Speichers 812 zwischen einer ersten transienten Funktion und einer zweiten transienten Funktion, die mit der ersten transienten Funktion zusammenarbeitet, gemeinsam zu verwenden. Bei einigen Ausführungsformen kann die Logik 813 ferner dazu konfiguriert sein, eine Pufferspeichererweiterung für In-Core-, In-System, In-Platform und/oder Maschinenmeldungskommunikation zwischen zusammenwirkenden transienten Funktionen einer FaaS-Plattform, wie der ersten und der zweiten transienten Funktion, bereitzustellen. Bei einigen Ausführungsformen kann die Logik 813 dazu konfiguriert sein, Daten zwischen der ersten transienten Funktion und der zweiten transienten Funktion mit dem gemeinsam verwendeten Speicherbereich auszutauschen. Die Logik 813 kann zum Beispiel dazu konfiguriert sein, die ausgetauschten Daten mit mindestens einer Aufrufanweisung oder einer Rücksendeanweisung zu synchronisieren. Bei einigen Ausführungsformen kann sich die Logik 813 in oder gemeinsam mit diversen Bauelementen, einschließlich des Prozessors 811, des Speichers 812 usw. (zum Beispiel auf demselben Die) liegend befinden.
Ausführungsformen jedes des oben erwähnten Prozessors 811, Speichers 812, der Logik 813 und anderer Bauelemente des Systems 810 können in Hardware, Software oder einer beliebigen zweckdienlichen Kombination davon umgesetzt werden. Hardware-Umsetzungen können zum Beispiel konfigurierbare Logik beinhalten, wie zum Beispiel programmierbare Logik-Arrays (Programmable Logic Arrays - PLAs), feldprogrammierbare Gate-Arrays (Field Programmable Gate Arrays - FPGAs), komplexe programmierbare Logikgeräte (Complex Programmable Logic Devices - (CPLDs), oder Hardware-Logik mit feststehender Funktionalität, die Schaltungstechnologie verwendet, wie zum Beispiel anwendungsspezifische integrierte Schaltung (Application Specific Integrated Circuit- ASIC), komplementäre Metalloxid-Halbleiter (Complementary Metal Oxide Semiconductor- CMOS) oder Transistor-Transistor-Logik-Technologie (TTL-Technologie) oder eine beliebige Kombination davon.
Alternativ oder zusätzlich können sämtliche oder Abschnitte dieser Bauelemente in einem oder mehreren Modulen als ein Satz von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination eines oder mehrerer Betriebssysteme (OS) anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden. Der Speicher 812, persistente Speichermedien oder anderer Speicher können zum Beispiel einen Satz von Anweisungen speichern, die, wenn sie von dem Prozessor 811 ausgeführt werden, das System 810 veranlassen, ein oder mehrere Bauelemente, Merkmale oder Aspekte des Systems 810 (zum Beispiel die Logik 813, gemeinsames Verwenden des Speicherbereichs, Bereitstellen Pufferspeichererweiterung, Datenaustausch usw.) umzusetzen. Ausführungsformen eines zweckdienlichen Prozessors können einen Allzweckprozessor, einen Spezialzweckprozessor, eine CPU, eine GPU, eine Steuervorrichtung, einen Mikrocontroller, einen Kernel, eine Ausführungseinheit usw. beinhalten.
Unter Bezugnahme auf 8B kann eine Ausführungsform eines Halbleiter-Packagegeräts 820 ein oder mehrere Substrate 821 und Logik 822, die mit dem einen oder den mehreren Substraten 821 gekoppelt ist, beinhalten, wobei die Logik 822 mindestens teilweise in einer oder mehreren von konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist. Die Logik 822, die mit dem einen oder den mehreren Substraten 821 gekoppelt ist, kann konfiguriert werden, um einen Speicherbereich zwischen einer ersten transienten Funktion und einer zweiten transienten Funktion, die mit der ersten transienten Funktion zusammenarbeitet, gemeinsam zu verwenden. Bei einigen Ausführungsformen kann die Logik 822 ferner dazu konfiguriert sein, eine Pufferspeichererweiterung für In-Core-, In-System und/oder In-Platform-Maschinenmeldungskommunikation zwischen zusammenwirkenden transienten Funktionen einer FaaS-Plattform bereitzustellen. Bei einigen Ausführungsformen kann die Logik 822 dazu konfiguriert sein, Daten zwischen der ersten transienten Funktion und der zweiten transienten Funktion mit dem gemeinsam verwendeten Speicherbereich auszutauschen. Die Logik 822 kann zum Beispiel dazu konfiguriert sein, die ausgetauschten Daten mit mindestens einer Aufrufanweisung oder einer Rücksendeanweisung zu synchronisieren. Bei einigen Ausführungsformen kann die Logik 822, die mit dem einen oder den mehreren Substraten 821 gekoppelt ist, Transistorkanalbereiche beinhalten, die innerhalb des einen oder der mehreren Substrate 821 positioniert sind.
Ausführungsformen der Logik 822 und anderer Bauelemente des Geräts 820 können in Hardware, Software oder einer beliebigen Kombination davon, einschließlich mindestens einer teilweisen Umsetzung in Hardware, umgesetzt werden. Die Hardware-Umsetzungen können zum Beispiel konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Zusätzlich können Abschnitte dieser Bauelemente in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C‟-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Gerät 820 kann einen oder mehrere Aspekte des Verfahrens 830 ( 8C) oder eine beliebige der Ausführungsformen, die hierin besprochen sind, umsetzen. Bei einigen Ausführungsformen kann das veranschaulichte Gerät 820 das eine oder die mehreren Substrate 821 (zum Beispiel Silizium, Saphir, Galliumarsenid) und die Logik 822 (zum Beispiel Transistor-Array und andere Bauelemente integrierter Schaltungen/IC) gekoppelt mit dem/den Substrat(en) 821 beinhalten. Die Logik 822 kann mindestens teilweise in konfigurierbare Logik oder Hardware-Logik mit feststehender Funktionalität umgesetzt werden. Bei einem Beispiel kann die Logik 822 Transistorkanalbereiche beinhalten, die innerhalb des/der Substrate 821 positioniert (zum Beispiel eingebettet) sind. Die Schnittstelle zwischen der Logik 822 und dem/den Substraten 821 ist daher eventuell kein abrupter Übergang. Die Logik 822 kann als auch eine epitaktische Schicht, die auf einem anfänglichen Wafer des Substrats/der Substrate 821 aufgewachsen wird, beinhaltend und betrachtet werden
Unter Bezugnahme auf 8C kann eine Ausführungsform eines Verfahrens 830 zum gemeinsamen Verwenden von Speicher unter mehreren FaaS-Funktionen das Zuordnen eines Speicherbereichs für eine erste transienter Funktion bei Block 831 und das gemeinsame Verwenden des Speicherbereichs zwischen der ersten transienten Funktion und einer zweiten transienten Funktion, die mit der ersten transienten Funktion an Block 832 zusammenarbeitet, beinhalten. Einige Ausführungsformen des Verfahrens 830 können ferner das Bereitstellen einer Pufferspeichererweiterung für In-Core-Maschinenmeldungskommunikation zwischen zusammenwirkenden transienten Funktionen einer FaaS-Plattform bei Block 833 beinhalten. Einige Ausführungsformen des Verfahrens 830 können eine Pufferspeichererweiterung für In-Platform-Maschinenmeldungskommunikation zwischen den transienten Funktionen einer FaaS-Plattform bei Block 833 beinhalten. Das Verfahren 830 kann auch das Austauschen von Daten zwischen der ersten transienten Funktion und der zweiten transienten Funktion mit dem gemeinsam verwendeten Speicherbereich bei Block 834 beinhalten. Das Verfahren 830 kann zum Beispiel das Synchronisieren der ausgetauschten Daten mit mindestens einer einer Aufrufanweisung und einer Rücksendeanweisung bei Block 835 beinhalten.
Ausführungsformen des Verfahrens 830 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 830 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 830 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Verfahren 830 kann zum Beispiel auf einem computerlesbaren Medium, wie in Verbindung mit den Beispielen 814 bis 817 unten beschrieben, umgesetzt werden. Ausführungsformen oder Abschnitte des Verfahrens 830 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Unter Bezugnahme auf 8D kann eine Ausführungsform eines Verfahrens 870 zum gemeinsamen Verwenden von Speicher unter mehreren FaaS-Funktionen das Zuordnen eines Speicherbereichs für eine erste transienter Funktion bei Block 872 und das gemeinsame Verwenden des Speicherbereichs zwischen der ersten transienten Funktion und einer zweiten transienten Funktion, die mit der ersten transienten Funktion an Block 874 zusammenarbeitet, beinhalten. Einige Ausführungsformen des Verfahrens 870 können ferner das Bereitstellen einer Pufferspeichererweiterung für In-System- und/oder In-Platform-Maschinenmeldungskommunikation zwischen zusammenwirkenden transienten Funktionen einer FaaS-Plattform bei Block 876 beinhalten. Das Verfahren 830 kann auch das Austauschen von Daten zwischen der ersten transienten Funktion und der zweiten transienten Funktion mit dem gemeinsam verwendeten Speicherbereich bei Block 878 beinhalten. Das Verfahren 870 kann zum Beispiel das Synchronisieren der ausgetauschten Daten mit mindestens einer einer Aufrufanweisung und einer Rücksendeanweisung bei Block 880 beinhalten.
Ausführungsformen des Verfahrens 870 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 870 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 870 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C‟-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Verfahren 870 kann zum Beispiel auf einem computerlesbaren Medium, wie in Verbindung mit den Beispielen 814 bis 817 unten beschrieben, umgesetzt werden. Ausführungsformen oder Abschnitte des Verfahrens 870 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Bei einigen Ausführungsformen erfordert das Weitergeben von Daten zwischen zwei zusammenarbeitenden Funktionen, die auf derselben Maschine sind und speicherbasierten Transfer, wie in Verfahren 870 beschrieben, verwenden, nicht, dass die Prozesse und Threads, die die Kommunikation ausführen, in einen Kernel gehen müssen, und daher den Datenaustausch von der Anwendung des Nutzers aus verwirklichen können. Ferner können neue Anweisungen den erforderlichen Datenaustausch sicher an der Benutzerebene ausführen. Da die Anweisungen dazu ausgelegt sein können, mit Hardwareprivilegien (die noch größer sind als Kernel-Privilegien) zu arbeiten, besitzt daher die Ausführung der Funktion das Recht zum Kopieren von Daten aus dem Container einer Funktion zu dem Container einer anderen Funktion. Alternativ kann das tatsächliche Kopieren in Firmware oder in einem Helfer-Thread in dem OS ausgeführt werden, kann aber durch eine neue Anweisungen in Gang gesetzt werden, die keine Sende- und Empfangsfunktionen in Kernel-Modus erfordert, um die Firmware oder die Helfer-Threads zu aktivieren.
Unter Bezugnahme auf 8E kann eine Ausführungsform eines verbesserten FaaS-Systems 840 zwei zusammenarbeitende FaaS-Funktionen 841 und 842 (zum Beispiel Funktion A und B) beinhalten, sowie gemeinsam verwendeten Speicher 843, der dazu konfiguriert sein kann, die Zusammenarbeit zwischen den zwei FaaS-Funktionen 841 und 842 zu erleichtern. Einige Ausführungsformen können vorteilhafterweise eine Pufferspeicher-/ISA-Erweiterung für Maschinenmeldungs-/JSON-Kommunikation zwischen FaaS-Funktionen 841 und 842 bereitstellen. Einige FaaS-Architektur kann Standard-Daten-Austauschformate wie JSON für Kommunikation zwischen Funktionen über HTTP verwenden. Wenn der Scheduler zusammenarbeitende FaaS-Funktionen auf derselben Maschine (zum Beispiel Kern oder Host) lokalisiert, braucht die Kommunikation zwischen Funktionen nicht durch den OS-Kernel und andere HTTP-Schichten durchzugehen. Bei einigen Ausführungsformen kann gemeinsam verwendeter Speicher 843 eine Art von Kommunikation bereitstellen, indem er die zwei Funktionen 841, 842 dasselbe Speichersegment zum Kopieren des Inhalts von Daten, die zwischen den zwei Funktionen 841, 842 ausgeführt werden, gemeinsam verwenden lässt. Kurz bevor die aufgerufene Funktion aufgerufen wird, können zum Beispiel Parameter, die von der aufrufenden Funktion durchgegeben werden, von dem Aufrufer in den gemeinsam verwendeten Speicher kopiert werden. Sobald der Aufgerufene zurückgesandt wird, kann ein Antwort-/JSON-Objektinhalt aus dem gemeinsam verwendeten Speicher zu dem Aufrufer kopiert werden. Die Synchronisation kann natürlich über den Aufruf und Rücksendeanweisungen erfolgen.
Unter Bezugnahme auf 8F kann eine Ausführungsform eines Funktion-Look-Aside-Buffer (FLB) 850 Eingaben für zwei zusammenarbeitende FaaS-Funktionen f und g beinhalten. Ob Kommunikation über gemeinsam verwendeten Speicher (zum Beispiel oder interne Pufferspeicher) oder durch die herkömmliche HTTP-/Kernel-Route erfolgen sollte, kann durch Prüfen, ob der Aufrufer lokal/nahe (zum Beispiel In-Core, In-System, In-Platform ist und/oder Ausführungseinheiten mit gemeinsam verwendetem Speicher) zu dem Aufgerufenen ist, und dann basierend auf dem Wert dieser Prüfung verzweigen, um den zweckdienlichen Code zum Packing/Kopieren von Daten auszuführen. Um diese Prüfung zu beschleunigen, kann der FLB 850 eine Hardwarestruktur ähnlich einem Translation-Look-Aside-Buffer (TLB) beinhalten, die zum Zwischenspeichern der Prozess-/Lambda-ID der ortsgleichen Funktionen, verwendet werden. Die Lokalitätsinformationen können aktualisiert werden, während sich Funktionen ähnlich Seitentabelleneinträgen herum bewegen, und ein residenter Eintrag in dem Cache wird ungültig gemacht, wenn Funktionen von dem Host entfernt werden.
Unter Bezugnahme auf 8G kann eine Ausführungsform eines verbesserten FaaS-Systems 860 einen Orchestrator 862 in Kommunikationen mit zwei oder mehreren Servern 863, 864 und 865 beinhalten. Die Funktionscodes F1 bis F9 können auf die Server 863, 864 und 865 mit Zusammenarbeit zwischen F1, F4, F5, F6 und F8 verteilt werden. Weil F4, F5 und F6 an demselben Ort auf demselben Server 864 liegen, können einige Ausführungsformen vorteilhafterweise gemeinsam verwendeten Speicher auf dem Server 864 einsetzen, um die Zusammenarbeit zwischen F4, F5 und F6 zu erleichtern. Einige Ausführungsformen können eine Grafik basierend darauf, welche Funktionen auf welchen Servern laufen, für besseres Bin-Packing und/oder Lokalitätsoptimierung eingesetzt werden. Einige Ausführungsformen setzen auch eine auf Grafik basierte Darstellung von funktionsübergreifenden Kommunikationsmustern ein. Aufrufketten über Knoten können zum Beispiel gemeinsam als eine auf Grafik basierende Darstellung verwendet werden.
Bei einigen Ausführungsformen kann das OS eine Funktionsaufrufs-API mit den Funktionen aufzeigen. Das API-Framework kann zum Beispiel eine OS-API für Funktionsaufrufe an Stelle von Netzwerkkommunikation, falls verfügbar, verwenden. Vorteilhafterweise kann das API-Framework für entfernte Aufrufe einen effizienteren Transport im Vergleich zu dem Netzwerk bereitstellen. Einige Ausführungsformen können das Netzwerk durch Einsetzen von 128-Bit-Adressen verhindern, um alle Funktionen global und für direkten Fernspeicherzugriff (Remote Direct Memory Acces - RDMA) zugänglich zu machen.
Ausführungsformen oder Aspekte/Features des Systems 810 (8A), des Geräts 820 (8B), des Verfahrens 830 (8C), des FaaS-Systems 840 ( 8D), des FLB 850 (8E) und/oder des FaaS-Systems 860 (8F) können ersetzt werden für oder eingebaut werden in alle oder Abschnitte der FaaS-Plattform 102 (1), des verbesserten FaaS-Systems 202 (2), der FaaS-Server Architektur 300 (3), des verbesserten FaaS-Systems (4), und/oder des verbesserten FaaS-Systems (5). Softwarebauelemente diverser Ausführungsformen (zum Beispiel der Funktionscode, Aspekte der Logik usw.) können zum Beispiel in das FaaS-Software-Subsystem 506 (5) eingebaut werden, und Hardware-Bauelemente der diversen Ausführungsformen (zum Beispiel der gemeinsam verwendete Speicher, der FLB, Aspekte der Logik usw.) können in das FaaS-Hardware-Subsystem 508 (5) eingebaut werden.
Zusätzliche Anmerkungen und Beispiele
Beispiel 800 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen Speicherbereich des Speichers zwischen einer ersten transienten Funktion und einer zweiten transienten Funktion, die mit der ersten transienten Funktion zusammenarbeitet beinhalten, 128-Bit-Adressen einsetzen, eine Funktionsaufrufschnittstelle für die erste und die zweite transiente Funktionen aufzeigen und eine auf Grafik basierende Darstellung schaffen, die die erste und die zweite transiente Funktion beinhaltet.
Beispiel 801 beinhaltet ein elektronisches Verarbeitungssystem, das einen Prozessor, Speicher, der kommunikationsfähig mit dem Prozessor gekoppelt ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher gekoppelt ist, um einen Speicherbereich des Speichers zwischen einer ersten transienten Funktion und einer zweiten transienten Funktion, die mit der ersten transienten Funktion zusammenarbeitet, gemeinsam verwenden.
Beispiel 802 beinhaltet das System des Beispiels 801, wobei die Logik ferner eine Puffererweiterung für Maschinenmeldungskommunikation unter zusammenarbeitenden transienten Funktionen einer Function-as-a-Service-Plattform bereitstellen soll.
Beispiel 803 beinhaltet das System eines der Beispiele 801 bis 802, wobei die Logik ferner Daten zwischen der ersten transienten Funktion und der zweiten transienten Funktion mit dem gemeinsam verwendeten Speicherbereich austauschen soll.
Beispiel 804 beinhaltet das System des Beispiels 803, wobei die Logik ferner die ausgetauschten Daten mit mindestens einer einer Aufrufanweisung und einer Rücksendeanweisung synchronisieren soll.
Beispiel 805 beinhaltet ein Halbleiter-Package-Gerät, das ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, aufweist, wobei die Logik mindestens teilweise in einer oder mehreren aus konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist, die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um einen Speicherbereich des Speichers zwischen einer ersten transienten Funktion und einer zweiten transienten Funktion, die mit der ersten transienten Funktion zusammenwirkt, gemeinsam zu verwenden.
Beispiel 806 beinhaltet das Gerät des Beispiels 805, wobei die Logik ferner eine Puffererweiterung für Maschinenmeldungskommunikation unter zusammenarbeitenden transienten Funktionen einer Function-as-a-Service-Plattform bereitstellen soll.
Beispiel 807 beinhaltet das Gerät eines der Beispiele 805 bis 806, wobei die Logik ferner Daten zwischen der ersten transienten Funktion und der zweiten transienten Funktion mit dem gemeinsam verwendeten Speicherbereich austauschen soll.
Beispiel 808 beinhaltet das Gerät des Beispiels 807, wobei die Logik ferner die ausgetauschten Daten mit mindestens einer einer Aufrufanweisung und einer Rücksendeanweisung synchronisieren soll.
Beispiel 809 beinhaltet das Gerät eines der Beispiele 805 bis 808, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche, die innerhalb des einen oder der mehreren Substrate positioniert sind, beinhaltet.
Beispiel 810 beinhaltet ein Verfahren zum gemeinsamen Verwenden von Speicher, das das Zuordnen eines Speicherbereichs für eine erste transiente Funktion und das gemeinsame Verwenden des Speicherbereichs des Speichers zwischen der ersten transienten Funktion und einer zweiten transienten Funktion, die mit der ersten transienten Funktion zusammenarbeitet, umfasst.
Beispiel 811 beinhaltet das Verfahren des Beispiels 810, das weiter das Bereitstellen einer Puffererweiterung für Maschinenmeldungskommunikation unter zusammenarbeitenden transienten Funktionen einer Function-as-a-Service-Plattform umfasst.
Beispiel 812 beinhaltet das Verfahren eines der Beispiele 810 bis 811, das weiter das Austauschen von Daten zwischen der ersten transienten Funktion und der zweiten transienten Funktion mit dem gemeinsam verwendeten Speicherbereich umfasst.
Beispiel 813 beinhaltet das Verfahren des Beispiels 812, das ferner das Synchronisieren der ausgetauschten Daten mit mindestens einer einer Aufrufanweisung und einer Rücksendeanweisung umfasst.
Beispiele für spekulative Container-Ausführung
Einige Ausführungsformen können vorteilhafterweise spekulative Container-Run-Ahead-Ausführung bereitstellen. Einige Funktionen involvieren lange Latenz/langes Hochlaufen, was die Ausführung verlangsamen kann. Einige Ausführungsformen können einen Run-Ahead-Ausführungsmechanismus zum Holen von Daten-/Anweisungsströmen an der Prozessor-/Core-Ebene bereitstellen und auch Ressourcen zu reservieren und/oder neu zuzuordnen. Vorteilhafterweise können einige Ausführungsformen Latenz/Hochfahren für Funktionen, die von der Run-Ahead-Fähigkeit profitieren können, verringern.
Erläuternd und nicht einschränkend kann Run-Ahead eine Technik betreffen, die es einem Prozessor erlaubt, Anweisungen (zum Beispiel spekulativ) während Cache-Miss-Zyklen weiter auszuführen statt zum Stillstand zu kommen. Die spekulative Ausführung kann verwendet werden, um Anweisung- und Datenstrom-Vorabrufe durch Erfassen von Anweisung-/Cache-Misses zu erzeugen, bevor sie ansonsten auftreten würden, indem die Ruhezustand-Ausführungsressourcen verwendet werden. Die überschaubaren Kosten können das Bereitstellen von Unterstützung spekulativer Ausführungen beinhalten, um den Registerdateistatus zu wahren und spekulative Lagerungen daran zu hindern, Speicher zu ändern.
Einige FaaS-Funktionen können vom Ausführen von Blockieren von Vorgängen mit Latenz mit variabler Länge (zum Beispiel einige lange), wie Abfragen aus Datenbanken, Aufrufen anderer FaaS-Dienste usw., profitieren. Einige Ausführungsformen können Run-Ahead-Ausführungstechnologie bereitstellen, um Daten-/Anweisungsströme an der Prozessor-/Core-Ebene zu holen, und auch, um Ressourcen zu reservieren/neu zuzuordnen (wie zum Beispiel Reservieren von Bandbreite für das Zugreifen auf Datenbanken, Aufwärmen von Containern/FaaS-Funktionen, die potenziell aufgerufen werden, Umstellen von Containern/FaaS-Funktionen näher zu der aktuellen Funktion usw.).
Um eine solche Fähigkeit in einer FaaS-Umgebung zu ermöglichen, können Ausführungsformen Copy-on-Write-Technologie bereitstellen, um spekulative Ausführung an Prozessorebene bereitzustellen, und auch eine Laufzeit-Routine zum Ersetzen der extern sichtbaren Vorgänge (wie zum Beispiel externe Funktionsaufrufe, Datenbankaktualisierungen usw.) in zweckdienliche passende Vorgänge zum Reservieren/Neuzuordnen von Ressourcen zu unterstützen. Einige Ausführungsformen können Multi-Key-Total-Memory-Encryption (MKTME) zum Kennzeichnen von Schlüsseln zu Funktionen einsetzen. Eine Ausführungsform kann zum Beispiel MKTME verwenden, um einen freien Spekulationsseitenkanal mit RDMA bereitzustellen. Bei einigen Ausführungsformen kann ein Programmierer durch eine Datenstruktur einen Hinweis dazu angeben, ob spekulative Run-Ahead-Ausführung auszuführen ist oder nicht.
Bei einer Ausführungsform ist ein elektronisches Verarbeitungssystem, wie das in Zusammenhang mit 8A beschriebene, dazu konfiguriert, Run-Ahead auszuführen, um FaaS-bezogene Informationen zu holen, und einen oder mehrere Vorgänge mit variabler Latenz basierend auf den geholten FaaS-bezogenen Informationen zu blockieren. Bei einigen Ausführungsformen kann das elektronische Verarbeitungssystem ferner dazu konfiguriert sein, Ressourcen basierend auf den geholten FaaS-bezogenen Informationen zu reservieren und/oder neu zuzuordnen. Zusätzlich oder alternativ kann das elektronische Verarbeitungssystem ferner dazu konfiguriert werden, einen oder mehrere extern sichtbare Vorgänge mit entsprechenden passenden Vorgängen zu einem oder mehreren von Reservieren und Neuzuordnen von Ressourcen zu ersetzen. Bei einigen Ausführungsformen können diverse Bauelemente, wie eine Logik, ein Prozessor, ein Speicher usw. ineinander oder ortsgleich miteinander liegen (zum Beispiel auf demselben Die).
Bei einer anderen Ausführungsform kann ein Halbleiter-Package-Gerät, das gleich oder ähnlich ist wie das Halbleiter-Package-Gerät, das in 8B veranschaulicht ist, ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, beinhalten, wobei die Logik mindestens teilweise in einer oder mehreren von konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt wird. Die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, kann für Run-Ahead konfiguriert werden, um FaaS-bezogene Informationen zu holen und einen oder mehrere Vorgänge mit Latenz mit variabler Länge zu blockieren, basierend auf den geholten FaaS-bezogenen Informationen. Bei einigen Ausführungsformen kann die Logik ferner dazu konfiguriert sein, Ressourcen basierend auf den geholten FaaS-bezogenen Informationen zu reservieren und/oder neu zuzuordnen. Zusätzlich oder alternativ kann die Logik ferner dazu konfiguriert werden, einen oder mehrere extern sichtbare Vorgänge mit entsprechenden passenden Vorgängen zu einem oder mehreren von Reservieren und Neuzuordnen von Ressourcen zu ersetzen. Bei einigen Ausführungsformen kann die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche beinhalten, die innerhalb des einen oder der mehreren Substrate positioniert sind.
Unter Bezugnahme auf 9A kann eine Ausführungsform eines Verfahrens 930 zum Bereitstellen einer Function-as-a-Service das Vorgreifen zum Holen FaaS-bezogener Informationen an Block 931 und das Blockieren eines oder mehrerer Vorgänge mit Latenz mit variabler Länge basierend auf den geholten FaaS-bezogenen Informationen bei Block 932 beinhalten. Einige Ausführungsformen des Verfahrens 930 können ferner das Reservieren und/oder Neuzuordnen von Ressourcen basierend auf den geholten FaaS-bezogenen Informationen bei Block 933 beinhalten. Zusätzlich oder alternativ kann das Verfahren 930 auch das Ersetzen eines oder mehrerer extern sichtbarer Vorgänge für entsprechende passende Vorgänge zu einer oder mehreren von Reservieren und/oder Neuzuordnen von Ressourcen bei Block 934 beinhalten.
Ausführungsformen des Verfahrens 930 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 930 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 930 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C‟-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Verfahren 930 kann zum Beispiel auf einem computerlesbaren Medium, wie in Verbindung mit den Beispielen 931 bis 933 unten beschrieben, umgesetzt werden. Ausführungsformen oder Abschnitte des Verfahrens 930 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Unter Bezugnahme auf 9B kann eine Ausführungsform eines verbesserten FaaS-Systems 940 ein Stream-Fetch-Modul 942, das kommunikationsfähig mit einem Ressourcenmanager 944 gekoppelt ist, beinhalten. Das Stream-Fetch-Modul 942 kann Technologie zum Vorgreifen zum Holen FaaS-bezogener Informationen einer Funktion, die auszuführen ist, beinhalten. Der Ressourcenmanager 944 kann Technologie zum Blockieren eines oder mehrerer Vorgänge mit Latenz mit variabler Länge basierend auf den geholten FaaS-bezogenen Informationen beinhalten. Bei einigen Ausführungsformen kann der Ressourcenmanager 944 ferner dazu konfiguriert sein, Ressourcen basierend auf den geholten FaaS-bezogenen Informationen zu reservieren und/oder neu zuzuordnen. Zusätzlich oder alternativ kann der Ressourcenmanager 944 ferner dazu konfiguriert werden, einen oder mehrere extern sichtbare Vorgänge mit entsprechenden passenden Vorgängen zu einem oder mehreren von Reservieren und Neuzuordnen von Ressourcen zu ersetzen. Einige Ausführungsformen des Systems 940 können vorteilhafterweise spekulative Container-Run-Ahead-Ausführung (zum Beispiel in einer FaaS-Umgebung) bereitstellen.
Unter Bezugnahme auf 9C kann eine Ausführungsform eines verbesserten FaaS-Systems 950 spekulative Ausführungen einiger FaaS-Funktionen beinhalten. Ein Benutzer 951 kann einen Browser 952 verwenden, um eine Webseite 954 anzuzeigen, die mehrere Bilder, zum Beispiel img1.jpg bis imgN.jpg, beinhaltet. Der Benutzer 951 kann ein oder mehrere Bilder der Webseite 954 über eine Bildrotationsfunktion 953 durch das FaaS-System 950 drehen. Das FaaS-System 950 kann eine wahrscheinliche Benutzerabsicht zum Drehen eines oder mehrerer Bilder (zum Beispiel imgl.jpg bis imgN.jpg) bestimmen und spekulativ die Bilder zu einer oder mehreren alternativen Ausrichtungen drehen. Das FaaS-System 950 kann zum Beispiel ein Nutzungsmuster/eine Nutzungssequenz der Bildausrichtungen erfassen und diverse Rotationsfunktionen im Voraus für eine bessere Benutzererfahrung und/oder Performance-Metriken starten. Die spekulative Ausführung kann die Latenz zum Drehen der Bilder aus der Perspektive des Benutzers erheblich verringern.
Ausführungsformen oder Aspekte/Features des Systems, des Geräts, des Verfahrens 930 (9A), des FaaS-Systems 940 (9B) und/oder des FaaS-Systems 950 (9C) können ersetzt werden für oder eingebaut in alle oder Abschnitte der FaaS-Plattform 102 (1), des verbesserten FaaS-Systems 202 (2), der FaaS-Server-Architektur 300 (3), des verbesserten FaaS-Systems (4) und/oder des verbesserten FaaS-Systems (5). Softwarebauelemente diverser Ausführungsformen (zum Beispiel der Stream-Fetcher, der Ressourcenmanager, der Funktionscode, Aspekte der Logik usw.) können zum Beispiel in das FaaS-Software-Subsystem 506 (5) eingebaut werden, und Hardware-Bauelemente der diversen Ausführungsformen (zum Beispiel diverse Warteschlangen/Puffer, Aspekte der Logik usw.) können in das FaaS-HardwareSubsystem 508 (5) eingebaut werden.
Zusätzliche Anmerkungen und Beispiele
Beispiel 900 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, das Holen FaaS-bezogener Informationen mindestens einer Funktion vorzugreifen, einen oder mehrere Vorgänge mit Latenz mit variabler Länge basierend auf den geholten FaaS-bezogenen Informationen blockieren, Schlüssel zu Funktionen mit Multi-Key-Total-Memory-Encryption kennzeichnen, bildbezogene Informationen erfassen und einen Bildvorgang im Voraus basierend auf den erfassten bildbezogenen Informationen starten.
Beispiel 901 beinhaltet ein elektronisches Verarbeitungssystem, das einen Prozessor, Speicher, der kommunikationsfähig mit dem Prozessor gekoppelt ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher gekoppelt ist, um das Holen FaaS-bezogener Informationen mindestens einer Funktion vorzugreifen und einen oder mehrere Vorgänge mit Latenz mit variabler Länge basierend auf den geholten FaaS-bezogenen Informationen blockieren.
Beispiel 902 beinhaltet das System des Beispiels 901, wobei die Logik ferner eines oder mehrere von Reservieren und Neuzuordnen basierend auf den geholten FaaS-bezogenen Informationen Ressourcen reservieren oder neu zuordnen soll.
Beispiel 903 beinhaltet das System eines der Beispiele 901 bis 902, wobei die Logik ferner einen oder mehrere extern sichtbare Vorgänge mit entsprechenden passenden Vorgängen zu einem oder mehreren von Reservieren und Neuzuordnen von Ressourcen ersetzen soll.
Beispiel 904 beinhaltet ein Halbleiter-Package-Gerät, das ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, umfasst, wobei die Logik mindestens teilweise in einer oder mehreren aus konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist, die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um das Holen FaaS-bezogener Informationen mindestens einer Funktion und das Blockieren eines oder mehrerer Vorgänge mit Latenz mit variabler Länge basierend auf den geholten FaaS-bezogenen Informationen zu blockieren, vorzugreifen.
Beispiel 905 beinhaltet das Gerät des Beispiels 904, wobei die Logik ferner basierend auf den geholten FaaS-bezogenen Informationen Ressourcen reservieren oder neu zuordnen soll.
Beispiel 906 beinhaltet das Gerät eines der Beispiele 904 bis 905, wobei die Logik ferner einen oder mehrere extern sichtbare Vorgänge mit entsprechenden passenden Vorgängen zu einem oder mehreren von Reservieren und Neuzuordnen von Ressourcen ersetzen soll.
Beispiel 907 beinhaltet das Gerät eines der Beispiele 904 bis 906, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche, die innerhalb des einen oder der mehreren Substrate positioniert sind, beinhaltet.
Beispiel 908 beinhaltet ein Verfahren zum Bereitstellen einer Function-asa-Service, die das Vorgreifen zum Holen FaaS-bezogener Informationen mindestens einer Funktion und das Blockieren eines oder mehrerer Vorgänge mit Latenz mit variabler Länge basierend auf den geholten FaaS-bezogenen Informationen umfasst.
Beispiel 909 beinhaltet das Verfahren des Beispiels 908, das weiter eines oder mehrere von Reservieren und Neuzuordnen von Ressourcen basierend auf den geholten FaaS-bezogenen Informationen umfasst.
Beispiel 910 beinhaltet das Verfahren eines der Beispiele 908 bis 909, das ferner das Ersetzen eines oder mehrerer extern sichtbarer Vorgänge mit entsprechenden passenden Vorgängen zu einem oder mehreren von Reservieren und Neuzuordnen von Ressourcen umfasst.
Beispiele für Plattform-Feedback, Multi-Version-Funktion und asynchrone Funktion
Ein herkömmlicher FaaS-Aufruf kann eine Anzahl von Auslösern, einschließlich eines finalen Auslösers, der eine Funktion aufruft, involvieren. Nachdem die Funktion aufgerufen wurde, wird die Arbeit zu einer Plattform mit einigen Containern (zum Beispiel neu gestarteten, aufgewärmten usw.) verteilt. Es können aber um genügend Ressourcen, die zum Unterstützen des neuen Aufrufs verwendet werden, vorhanden sein. Angesammelte Latenzen können die Ausführung der Funktion verzögern. Der herkömmliche Auslösermechanismus fließt in eine Richtung, von dem vorhergehenden zu dem Funktionsaufruf, was es erschweren kann, zwischen den eigenen Fähigkeiten des FaaS-Systems und externen Ressourcen zu optimieren. Bei einigen FaaS-Systemen steigern Startup-Zeiten für beschleunigte Funktionen die Ausführungslatenz einer Funktion. Ein anderes Problem besteht darin, dass FaaS-Daten/Aktionen über disaggregierte Systeme schwer zu synchronisieren sind. Vollsynchrone Aktionen erfordern, dass die Aufruffunktion auf das Abschließen von Aufgaben wartet, bevor die darauffolgende Funktion aufgerufen wird. Ressourcen für die Aufruffunktion sind durch Warten gebunden.
Einige Ausführungsformen eines verbesserten FaaS-Systems können Feedbacks von der Plattform, die die Funktionen ausführt, zu dem Auslösemechanismus bereitstellen, die angeben, dass die Plattform für den nächsten Funktionsaufruf reif ist. Einige Ausführungsformen können auch Vorabverständigung über benötigte Ressourcen/Bedingungen bereitstellen, wobei einige Verständigung von der Plattform zurückkommt, wenn solche Ressourcen verfügbar sind oder erwartet wird, dass sie verfügbar sind, und wenn solche Bedingungen erfüllt werden (zum Beispiel ein Pull vs. Push). Einige Ausführungsformen können auch die Startup-Zeit für eine beschleunigte Funktion verbergen, indem sie alternative Formen der beschleunigten Funktion bereitstellen, die verwendet werden können, während die beschleunigte Funktion hochläuft. Bei einigen Ausführungsformen können einige Funktionen als asynchron zum Unterstützen von Service-Verkettung identifiziert werden. Vorteilhafterweise können einige Ausführungsformen Ressourcen-Starvation verhindern, bessere Ressourcennutzung bereitstellen und/oder weniger Latenz bei der Funktionsausführung erfahren (zum Beispiel oder offensichtliche Latenz). Einige Ausführungsformen können zum Beispiel eine Aufruffunktion freigeben, nachdem eine verkettete Funktion abgewickelt wurde (indem zum Beispiel Funktionen atomarer oder modularer gemacht werden).
Bei einer Ausführungsform kann ein elektronisches Verarbeitungssystem, das gleich oder ähnlich ist wie das in Verbindung mit 8A beschriebene, einen Prozessor, einen Speicher, der kommunikationsfähig mit dem Prozessor gekoppelt ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher gekoppelt ist, beinhalten, um eine Anfrage von einem Auslöseragenten für einen darauffolgenden Funktionsaufruf zu empfangen und zu dem Auslöseragenten Feedback bereitzustellen, um die Bereitschaft für den darauffolgenden Funktionsaufruf anzugeben. Alternativ oder zusätzlich kann die Logik dazu konfiguriert werden, eine oder mehrere alternative Formen einer beschleunigten Funktion bereitzustellen, die verwendet werden kann, während die beschleunigte Funktion hochläuft. Alternativ oder zusätzlich kann die Logik dazu konfiguriert werden, eine oder mehrere Funktionen als asynchron zu identifizieren, um eine Service-Kette zu unterstützen. Bei einigen Ausführungsformen kann sich die Logik in oder gemeinsam mit diversen Bauelementen, einschließlich des Prozessors, des Speichers usw. (zum Beispiel auf demselben Die) liegend befinden.
Bei einer anderen Ausführungsform kann ein Halbleiter-Package-Gerät, das gleich oder ähnlich ist wie das in Verbindung mit 8B beschriebene, ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, beinhalten, wobei die Logik mindestens teilweise in einer oder mehreren von konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt wird. Die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, kann dazu konfiguriert werden, eine Anfrage von einem Auslöseragenten für einen darauffolgenden Funktionsaufruf zu empfangen und Feedback zu dem Auslöseragenten bereitzustellen, um Bereitschaft für den darauffolgenden Funktionsaufruf anzugeben. Alternativ oder zusätzlich kann die Logik dazu konfiguriert werden, eine oder mehrere alternative Formen einer beschleunigten Funktion bereitzustellen, die verwendet werden kann, während die beschleunigte Funktion hochläuft. Alternativ oder zusätzlich kann die Logik dazu konfiguriert werden, eine oder mehrere Funktionen als asynchron zu identifizieren, um eine Service-Kette zu unterstützen. Bei einigen Ausführungsformen kann die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche beinhalten, die innerhalb des einen oder der mehreren Substrate 1021 positioniert sind.
Unter Bezugnahme auf 10A kann eine Ausführungsform eines Verfahrens 1030 zum Bereitstellen einer Function-as-a-Service das Empfangen einer Anfrage von einem Auslöseragenten um einen darauffolgenden Funktionsaufruf bei Block 1031 anfordern und Feedback zu dem Auslöseragenten bereitstellen, um Bereitschaft für den darauffolgenden Funktionsaufruf bei Block 1032 anzugeben. Alternativ oder zusätzlich kann das Verfahren 1030 das Bereitstellen einer oder mehrerer alternativer Formen einer beschleunigten Funktion beinhalten, die verwendet werden kann, während die beschleunigte Funktion bei Block 1033 hochläuft. Alternativ oder zusätzlich kann das Verfahren 1030 das Identifizieren einer oder mehrerer Funktionen als asynchron beinhalten, um eine Service-Kette bei Block 1034 zu unterstützen.
Ausführungsformen des Verfahrens 1030 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 1030 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 1030 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Verfahren 1030 kann zum Beispiel auf einem computerlesbaren Medium, wie in Verbindung mit den Beispielen 1011 bis 1013 unten beschrieben, umgesetzt werden. Ausführungsformen oder Abschnitte des Verfahrens 1030 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Beispiele für Plattform-Feedback
Unter Bezugnahme auf 10B kann eine Ausführungsform eines verbesserten FaaS-Systems 1040 eine FaaS-Plattform 1042, die kommunikationsfähig (verdrahtet oder drahtlos) mit einem Client 1044 gekoppelt ist, beinhalten. Einige Ausführungsformen können vorteilhafterweise Architekturunterstützung für Vorhersagen FaaS- und/oder Hardware-beschleunigter FaaS-Aktionen (AFaaS-Aktionen) auf Plattformereignissen und Rückrufen bereitstellen. Eine Hardwarebeschleunigte FaaS- oder AFaaS-Aktion ist eine, die in einem FaaS-Server 300, der in 3 gezeigt ist, auf einem FPGA 318, einem Beschleuniger 314, einer GPU, einer SmartNIC 302 und so fort ausgeführt werden kann. Die FaaS-Plattform 1042 kann zum Beispiel einen Plattformmanager 1046 beinhalten, der Technologie zum Empfangen einer Anfrage von dem Client 1044 um einen darauffolgenden Funktionsaufruf beinhaltet, und Feedback zu dem Client 1044 bereitstellen, um Bereitschaft für den darauffolgenden Funktionsaufruf anzugeben. Wenn eine Funktion ausgelöst (zum Beispiel aufgerufen) wird, kann zum Beispiel ein DAEMON eine Verzögerung durch unausgereifte Bedingungen für Erledigung verursachen (zum Beispiel länger auf bessere Bedingungen warten, QoS-Betrachtungen usw.). Die unausgereifte Bedingung kann auch mit einer Situation mit beschränkten Ressourcen zusammenhängen (zum Beispiel Speicher, Beschleuniger usw.), für die die Nachfrage hoch ist, so dass eine Warteschlange für den Zugriff auf die Ressourcen besteht. Aufgrund von Auflagen kann die Funktion nie ausgeführt werden, weil sie zu lange brauchen kann, wenn sie startet (zum Beispiel ein Timeout nach 5 Minuten). Einige Ausführungsformen können Plattform-Überwachung (zum Beispiel von dem Plattform-Aufrufer ausgeführt) bereitstellen und/oder eine Funktion in Segmente/Teile teilen. Der Plattformmanager 1046 kann dann die Teile der Funktion, die keinen Zugriff auf die begrenzten Ressourcen, Vor-Warteschlangen-Daten erfordern, eine virtuelle Funktion zum Überwachen von Ressourcen starten und die restlichen Teile ausführen, sobald sie bereit sind. Mit der in Segmente geteilten Funktion kann der Client 1044 (zum Beispiel Verbraucher) einen Rückruf in einem passenden Zeitpunkt ausführen und/oder die Funktion vorübergehend unterbrechen, bis die Ressourcen verfügbar werden.
Einige Ausführungsformen können zwei potenziell unabhängige aber komplementäre Fähigkeiten bereitstellen, einschließlich 1) einer Plattform- und Fähigkeit-verständigen Unterbreitung und Ausführung von FaaS-Aktionen und 2) Bedingungen, oder auf Ereignisfeedback basierende Just-in-Time-Ausführung von FaaS-Aktionen. Solche Ausführungsformen können für den Benutzer (zum Beispiel den Client 1044) Flexibilität bereitstellen, um den Plattform-Anbieter zu führen, und für den Plattform-Anbieter, um eine kollaborative Reihe und fundierte Ausführung von Aktionen basierend auf diversen Plattform-, Netzwerk- und Leistungsbedingungen zu erzielen.
Unter Bezugnahme auf 10C kann eine Ausführungsform eines verbesserten FaaS-Systems 1050 einen Funktionssegmentierer 1051, einen Plattformmonitor 1052, ein Funktionsrückrufmodul 1053 und ein Funktionspausemodul 1054 beinhalten. Diverse Plattformbedingungen können zum Beispiel von dem Plattformmonitor 1052 überwacht werden, und wenn Ressourcen zum Ausführen von Aktionen verfügbar sind und die Plattform diverse andere subtile Bedingungen, wie nachfolgend beschrieben, erfüllt, kann das eigentliche Auslösen der Aktion ausgeführt werden. Ein Beispiel einer subtilen Plattformbedingung ist Distanz zu Daten. Falls Datensätze zum Beispiel in einem Maschinen- oder Speicherplatz vorhanden sind und die Funktion, die die Datensätze benötigt, auf einer unterschiedlichen Maschine läuft und von der die Zugriffe der Funktion auf die Datensätze durch ein oder mehrere Netzwerke oder Speicherverknüpfungen durchgehen müssen, die die Zugriffe langsamer machen als wenn die Datensätze in derselben Maschine wie die Funktion wären (zum Beispiel beträchtliche Anzahlen von Platten- oder Netzwerk-E/A-Vorgänge erfordern), wird eine solche subtile Plattformbedingung nicht erfüllt. Ein Meta-Scheduler kann einen Datenmigrationsvorgang initiieren, um eine solche „Distanz zu Daten“-Bedingung zu erfüllen, und sobald ausreichend Daten migriert sind, kann die Aktion stattfinden. Alternativ, falls die Funktion näher dahin gepusht werden muss, wo sich die Daten befinden (zum Beispiel auf einem entfernten Knoten), ändert sich die subtile Bedingung auf nahe den Daten „ausreichend rechnerische Ressourcen aufweisen). Ein anderes Beispiel einer subtilen Bedingung sind Kosten. Es kann zum Beispiel wünschenswert sein, dass eine Funktion nur ausgelöst wird (zum Beispiel unter der Annahme, dass alle anderen Bedingungen für das Auslösen erfüllt werden), falls sie zu geringen Kosten ausgeführt werden kann. Das kann wahr sein, falls zum Beispiel eine Plattform ausreichend überschüssige Leistungskapazität, CPU-Zyklen, Speicherbandbreite usw. aufweist, dass der Funktion Best-Effort-Behandlung zuteil wird, und dass erwartet werden kann, dass sie innerhalb einer toleranten aber begrenzten Latenz abgeschlossen wird. Mit anderen Antworten zieht dieser Ansatz das Auslösen und/oder das tatsächliche Erledigen einer Funktion in Betracht, die auf Erfüllung diverser direkter und indirekter Maße an Effektivität, Effizienz und sogar Sicherheit basiert (zum Beispiel kann ein Beispiel für ein Sicherheitskriterium sein, dass keine sensiblen Dienste auf der Plattform laufen, um das Laufen einer Aktion, die hinsichtlich der Sicherheit auf der grauen Liste steht, zu erlauben).
Für AFaaS kann die Ressourcen Verfügung auch eine solche Plattformbedingung sein, insbesondere falls AFaaS verwendet wird, um Hintergrundtraining mit niedriger Intensität eines Modells künstlicher Intelligenz (AI) zu führen. Auf diese Weise kann das Ziel darin bestehen, eine deterministischere Ausführung von Funktionen zu erzielen, insbesondere während die Bedingungen, unter welchen die Funktionen ausgeführt werden, selbst ein zweiter Auslöser sind (wobei zum Beispiel der erste Auslöser nur besagt, dass „alle auf logischem Zustand basierenden oder zeitausgelösten Vorläufer erfüllt wurden“). Effektiv kann diese Technik explizit und systematisch die Ausführung einer Funktion mit der Verfügbarkeit der richtigen Ressourcen und projizierten Anforderungen an die Funktion verknüpfen.
Das Funktionsrückrufmodul 1053 kann es einem Verbraucher (zum Beispiel, oder einem Softwareagenten, der als der Proxy eines Verbrauchers handelt) erlauben, die tatsächliche Unterbreitung von FaaS-Aktivitäten mit dem Empfangen und Verarbeiten der Informationen, die er anfordert, durch Feedback von der Plattform-Infrastruktur zu verknüpfen. Das Funktionsrückrufmodul 1053 kann zum Beispiel bestimmte Meta-Funktionen, die als immer bereit (zum Beispiel „vorausgelöst“) behandelt werden, einsetzen, so dass der Rückruf natürlich einen Verbraucher-Proxy an einer Steuervorrichtung oder an einem Aufrufer aktiviert. Dieser Proxy stellt das benötigte Auslösen der Funktion bereit, die der Verbraucher gerade rechtzeitig und unter genau den richtigen Plattformbedingungen zu erledigen beabsichtigt.
Vorteilhafterweise können einige Ausführungsformen von Überwachungs- und/oder Rückruftechnologie in einem FaaS-System einen Ansatz „bring deine eigenen Fähigkeiten“ (Bring Your Own Capabilities - BYOC) unterstützen, um eine reichere Zusammenarbeit zu erzielen, bei der ein Verbraucher vorab einige Ressourcen reservieren kann (zum Beispiel explizit einige Ressourcen erhalten kann, indem er sie separat im Voraus anfordert) mit der Zustimmung eines CSP, während er auf andere Ressourcen, die bei dem CSP knapper sind, wartet, um verständige Erledigung zu erzielen. Einige Übersetzungsdienste können zum Beispiel auf ihren eigenen Ressourcen alles vorbereiten, bevor sie FaaS zum Ausführen der Übersetzung aufrufen. Ein tiefes neuronales Netzwerk (Deep Neural Network - DNN) kann zum Beispiel für die FaaS-Plattform zu sein, so dass der Verbraucher den DNN-Teil auf seinen eigenen vorbezahlten Ressourcen bei einem CSP ausführen und dann die FaaS-Plattform des CSP zum Ausführen des Rests der beabsichtigten Funktion verwenden kann.
Ausführungsformen oder Aspekte/Features des Systems, des Geräts des Verfahrens 1030 (10A), des FaaS-Systems 1040 (10B) und/oder des FaaS-Systems 1050 (10C) können ersetzt werden für oder eingebaut werden Ihnen alle oder Abschnitte der FaaS-Plattform 102 (1), des verbesserten FaaS-Systems 202 (2), der FaaS-Server-Architektur 300 (3), des verbesserten FaaS-Systems (4) und/oder des verbesserten FaaS-Systems (5). Softwarebauelemente diverser Ausführungsformen (zum Beispiel der Plattformmanager, der Funktionsegmentierer, der Plattform-Monitor, das Rückruf-Feature, das Pause-Feature, der Funktionscode, Aspekte der Logik usw. können zum Beispiel in das FaaS-Software-Subsystem 506 (5) eingebaut werden, und Hardware-Bauelemente der diversen Ausführungsformen (zum Beispiel diverse Warteschlangen/Puffer, Aspekte der Logik usw.) können in das FaaS-Hardware-Subsystem 508 (5) eingebaut werden.
Beispiele für Multi-Version-Funktion
Unter Bezugnahme auf FIG. IIA kann eine Ausführungsform 1110 mehrere Optionen für Instanziierung (zum Beispiel Option 1 bis N) beinhalten. Einige Ausführungsformen können vorteilhafterweise mehrere Versionen derselben Funktion 1110 bereitstellen und ferner mehrere beschleunigte Versionen derselben Funktion 1110 bereitstellen. Die mehreren Versionen derselben Funktion 1110, einschließlich der mehreren beschleunigten Versionen derselben Funktion 1110, können sich voneinander hinsichtlich der Zeit oder Ressourcen, die für ihre Instanziierungen erforderlich sind, und der Zeit, die zum Ausführen oder Laufen der Instanziierungen erforderlich ist, wenn die Funktion 1110 ausgeführt werden muss, unterscheiden. Einige Ausführungsformen stellen diese mehreren Versionen als mehrere Mieter dar, die auf eine gestaffelte Art initiiert werden. Einige Container (zum Beispiel Container, die Beschleuniger verwenden oder Cores einsetzen, wobei die Cores gemäß der Maschine variieren) können zum Starten ein Weilchen brauchen. Softwarefunktionen können einen Start mit niedriger Latenz bereitstellen aber mit Ausführungen mit längerer Latenz. Hardwarefunktionen können einen Start mit langer Latenz bereitstellen aber mit Ausführungen mit kurzer Latenz. Bei einigen Ausführungsformen kann die Funktion 1110 mehrere Optionen (zum Beispiel Instanziierungen) beinhalten, von welchen eine zur Ausführung in Abhängigkeit von diversen Faktoren (zum Beispiel Aufrufererfordernisse, Bedingungen der FaaS-Plattform usw.) ausgewählt werden kann.
Unter Bezugnahme auf 11B kann eine Ausführungsform eines verbesserten FaaS-Systems 1120 einen Codeblock A mit mehreren Versionen einer Funktion B unterstützen. Ein Aufrufer des Codeblocks A kann unterschiedliche Versionen der Funktion B, einschließlich einer minimalistischen Beschleunigerversion Bm, einer hohen Beschleunigerversion Bh und keiner Beschleunigerversion Bs identifizieren. Falls ein Container für einen Beschleuniger (zum Beispiel den minimalistischen Beschleuniger Bm) gestartet wird, können einige Ausführungsformen jede Version der B-Funktion zu dem Container pendeln. Einige Ausführungsformen können basierend darauf, dass eine Anzahl neuer Ankünfte der Funktion B abnimmt, Beschleunigungs-Container verschlechtern (zum Beispiel die hohen Beschleuniger Bh freigeben und die minimalistische Version Bm aufwärmen oder zu einer Software-/unbeschleunigten Version Bs verlagern). Einige Ausführungsformen können die mehreren Funktionsversionen mit Prefetching von Daten kombinieren, um nahe einer physischen Lage der Funktion B zu sein.
Einige Ausführungsformen können vorteilhafterweise beschleunigte Funktionen in einer Multimietersituation auf eine Weise ausführen, die die erwarteten nicht-trivialen Startup-Latenzen an dem Startpunkt einer neuen beschleunigten Funktion verbirgt. Für einen Aufrufer, der auf einer Allzweck-CPU läuft, kann ein Ziel des Aufrufs einer Funktion entsprechen, deren auf Initialisierungs- oder Host-CPU basierender Code Codeblock A ist, und die beschleunigte Funktion kann Funktion B entsprechen. An dem Punkt, an dem A Steuerung empfängt, kann B entweder auf dem Beschleuniger bereits initialisiert sein, oder B kann ein Abbilden auf den Beschleuniger benötigen.
Im Allgemeinen kann die Initialisierung von Bh von einigen Millisekunden bis zu mehreren Zehnern von Millisekunden dauern. Die FPGA-Ressourcen können zum Beispiel unter einer Anzahl aktiver Funktionen in Verwendung, im Ruhezustand und angefordert (zum Beispiel anstehender) Funktionen arbitriert werden. Falls Bh nicht aktiv ist, kann es etwas Zeit brauchen, um die Ressourcen für Bh zuzuordnen, den Bitstrom für Bh vom nahen oder weit entfernten Speicher zu holen und dann den Bitstrom zu aktivieren (zum Beispiel zu starten). Sobald er gestartet ist, kann der Bitstrom für Bh während einiger Zeit aktiv gehalten werden, um die Kosten des Startups von Bh über viele Arbeitszyklen, während welchen Bh behalten wird, zu tilgen, bevor die Ressourcen für Bh reduziert und Bh zurückgefordert wird. Um diese Latenz zu verbergen, können einige Ausführungsformen mehrere Versionen von Bh unterstützen, einschließlich zum Beispiel zwei zusätzliche, alternative Formen, Bm und Bs, wobei Bm einer minimal beschleunigten Version von Bh entsprechen kann, die sehr wenig Zeit benötigt, um zu starten, die aber länger benötigen kann, um ausgeführt zu werden (zum Beispiel weil sie Zeitschleifen ausführt, statt sie im Raum auszuführen), und wobei Bs einer Software-Version entsprechen kann (zum Beispiel CPU) von B (zum Beispiel einer nicht beschleunigten Version von B, die viel weniger Leistungs- und Performanceeffizient sein kann als Bh, aber so gut wie sofort starten kann, falls Bs warm ist) entsprechen kann.
Unter Bezugnahme auf 11C kann eine Ausführungsform eines Verfahrens 1130 zum Bereitstellen einer Function-as-Service das Bestimmen beinhalten, ob eine voll beschleunigte Version einer Funktion (zum Beispiel eine Funktion, die in einem Container ausgeführt wird, der auf hochbeschleunigender Hardware arbeitet) bei Block 1131 aktiv ist, und, falls das der Fall ist, die beschleunigte Version bei Block 1132 verwenden. Ansonsten kann das Verfahren 1130 bestimmen, ob eine teilweise beschleunigte Version der Funktion (zum Beispiel eine Funktion, die in einem Container ausgeführt wird, der auf minimalistischer Beschleunigerhardware arbeitet) bei Block 1133 aktiv ist, und, falls das der Fall ist, die teilweise beschleunigte Version bei Block 1134 verwenden. Ansonsten kann das Verfahren 1130 eine unbeschleunigte Version der Funktion bei Block 1135 verwenden. In Abhängigkeit von den Erfordernissen des Kunden/den Bedingungen der Plattform, kann das Verfahren 1130 ferner spekulatives Starten der vollen Version oder teilweise beschleunigten Version der Funktion bei Block 1136 beinhalten (und zum Beispiel Umwechseln zu dieser Version, wenn sie aktiv wird).
Mit anderen Worten kann der Codeblock A Bh verwenden, wobei Bh bereits aktiv ist (zum Beispiel die schnellste und effizienteste Ausführung von B), und ohne Setup-Zeit für Bh; anderenfalls kann A Bm verwenden, falls Bm bereits aktiv ist (zum Beispiel ohne Setup-Zeit aber Ausführung mit längerer Dauer); oder A kann Bs verwenden, falls weder Bh noch Bm aktiv ist, wonach A Bm starten oder Bh starten und dann die gestartete Bm oder Bs gemäß gewünschter Latenz-Performance-Flächen-Leistungs-Kompromisse verwenden kann.
Einige Ausführungsformen können zuerst Bm-Versionen für diese beschleunigten Funktionen, die bekanntlich (zum Beispiel durch historisches Profiling) häufig sind, vorab starten. Für nicht häufige beschleunigte Funktionen können einige Ausführungsformen dieser minimalen Versionen auf Anfrage starten, anfänglich aber die Software-Versionen Bs verwenden, falls Bm und Bs nicht bereits gestartet sind. Falls eine Nachfrage nach Bs oder Bm einen bestimmten Schwellenwert in einem kürzlichen Zeitfenster überschreitet, können einige Ausführungsformen die beschleunigte Funktion Bh starten und, bis Bh vollständig aktiviert ist, weiterhin Bs oder Bm für Anforderungen für B verwenden.
Einige Ausführungsformen können auch einen Satz gleitender Fenster und Kostenmetriken für jede gestartete B sammeln. Falls die gesammelten Informationen unter einen Schwellenwert fallen oder falls die Nachfrage nach anderen Funktionen zunimmt, können einige Ausführungsformen eine Rückforderung von Bh initiieren, falls Bm qualifiziert, dann Ressourcen für Bh zurückfordern, aber Bm stattdessen als Reaktion auf eine neue Anfrage zum Ausführen von B starten. Umgekehrt, falls die Nachfrage nach B einen Schwellenwert von unten her überschreitet, können einige Ausführungsformen ein Starten von Bh initiieren und dann Bm zurückfordern, falls Bm aktiv ist, nachdem Bh aktiviert wurde.
Beim Auswählen der Schwellenwerte für das Starten von Bm oder Bh (zum Beispiel während jeweils der Einsatz von Bs oder Bm steigt) und beim Auswählen der Schwellenwerte für das Zurückfordern von Bh oder Bm (während zum Beispiel der Einsatz von Bh und Bm jeweils zurückgeht), können einige Ausführungsformen Dienstleistungsvereinbarungseingaben (Service Level Agreement - SLA-Eingaben) berücksichtigen, die dynamisch von einem AFaaS-Kontrolldienst bereitgestellt werden. Falls keine SLA-Eingabe bereitgestellt wird, können diese Schwellenwerte heuristisch und dynamisch basierend auf den Ankunftsraten für Anfragen für B (zum Beispiel oder ein Mittelwert gleitender Fenster der Ankunftsdaten) eingestellt werden.
Einige Ausführungsformen können eine kontinuierliche Überwachung der Taktzyklen (des Einsatzes) normalisiert nach Kosten von Bh in Hardware zum Erzielen von zwei Zielen, nämlich 1) Entscheiden, wie lange Bh aktiv gehalten werden soll und 2) Sammeln historischer Informationen, so dass zukünftige Aktivierungen von Bh schnell abgefertigt werden können, indem die historischen Häufigkeiten und die Dauer aktiven Einsatzes als Führungen verwendet werden können, einsetzen. Gierige Bin-Packing-Heuristiken können zum Bestimmen der Schwellenwerte für das Umwechseln von der Version Bs zu der Version Bm zu der Version Bh einer Funktion eingesetzt werden. Diese Statistiken können durch Verwenden eines Epilogs für Bh aktualisiert werden, und können verwendet werden, um Statistiken im Speicher zu aktualisieren, die zukünftige Aktivierungen des Codeblocks A verwenden, um zwischen Bs, Bm und Bh auszuwählen.
Ausführungsformen oder Aspekte/Features der Funktion 1110 (11A), des FaaS-Systems 1120 (11B) und/oder des Verfahrens 1130 (11C) können eingesetzt werden für oder eingebaut werden in alle oder Abschnitte der FaaS-Plattform 102 (1), des verbesserten FaaS-Systems 202 (2), der FaaS-Server-Architektur 300 (3), des verbesserten FaaS-Systems (4) und/oder des verbesserten FaaS-Systems (5). Softwarebauelemente diverser Ausführungsformen (zum Beispiel der Multi-Version-Funktionscode, Aspekte der Logik usw.) können zum Beispiel in das FaaS-Software-Subsystem 506 (5) eingebaut werden, und Hardware-Bauelemente der diversen Ausführungsformen (zum Beispiel Überwachen, Aspekte der Logik usw.) können in das FaaS-Hardware-Subsystem 508 (5) eingebaut werden.
Beispiele asynchroner Funktion
Unter Bezugnahme auf 12 kann eine Ausführungsform eines verbesserten FaaS-Systems 1210 einen Scheduler 1212 mit Warteschlangen 1214, die eine Ereigniswarteschlange 1218, Funktionswarteschlange 1216, Auslöserwarteschlange 1220 usw. beinhalten, beinhalten. Einige Ausführungsformen können vorteilhafterweise effiziente Synchronisation unter verteilten Aktionen bereitstellen. Verkettete Funktionen, die durch Zwischenaktionen verknüpft sind (zum Beispiel Funktion X, die eine Aktion zum Speichern von Daten, die von der Funktion Y verwendet werden sollen, aufrufen muss) können in mehreren Aufrufen resultieren. Nehmen wir eine Action X, die einen Netzwerk- oder Speichervorgang P ausführen muss, bevor sie sich als abgeschlossen betrachten kann, und eine andere Action Y auslösen muss, die die kommunizierten oder in einem Speicherbereich eingefüllten Daten aufgrund des genannten Vorgangs P verarbeiten soll. Bei herkömmlichen FaaS-Systemen muss zum Beispiel die Action X darauf warten, dass der Netzwerk- oder Speichervorgang P das Füllen beendet, und dann die Action Y aufrufen oder auslösen. Der Scheduler 1212 muss eventuell warten, während Ressourcen von Action X während der Wartezeit verwendet werden. Einige Ausführungsformen der verbesserten FaaS-Lösung können vorteilhafterweise die Action X Netzwerk- oder Speichervorgang P auslösen lassen und das Netzwerk oder den Speichervorgang P derart ändern lassen, dass das Beenden des Netzwerk- oder Speichervorgangs P die Action Y auslöst, so dass die Action X verworfen werden kann, bevor der Netzwerk- oder Speichervorgang P das Freigeben von Ressourcen, die von Action X verbraucht werden, abschließt. Einige Ausführungsformen können auch Parallelität von größerem Interesse (zum Beispiel modulare Designs) erlauben, weil die Wurzel (zum Beispiel Parent-Funktion) nicht zu warten braucht, so dass andere Funktionen, die durch Abschließen ausgelöst werden, das Ausführen beginnen können. Einige Ausführungsformen können durch einen Hardware-Warteschlangenmanager (Hardware Queue Manager - HQM) umgesetzt werden.
Zahlreiche verteilte Aktionen müssen synchronisiert werden, sei es auch nur, um die Anforderung, dass ein Zustand, der der Dauerhaftigkeit verschrieben ist oder zur Sichtbarkeit kommuniziert wird, erfüllt ist, durch serialisierbare Abfolgen von Vorgängen aktualisiert wird. Zeit sollte daher nicht erscheinen als hätte sie sich rückwärts auf die Art bewegt, die aus diesen Vorgängen resultiert, falls sie auf einem dauerhaften Medium aufgezeichnet oder von einer Drittpartei beobachtet werden. In einigen Fällen kann jedoch der Ansatz, der in verteilten Systemen von Prozessen herangezogen wird, zu konservativ sein. Alle Agenten können zum Beispiel durch Barrieren vorgehen, wie bei Zweiphasenverriegeln, sogar wenn die Prozesse, die eingesetzt werden, bereits Daten-parallel sind (zum Beispiel auf disjunkten Partitionen von Daten arbeiten). Für FaaS-Aktionen mit niedriger Latenz, die über einen Satz koordinierender Knoten ausgeführt werden sollen, kann solcher Aufwand prohibitiv kostspielig sein und unnötige Verzögerungen einführen.
Da etwas oder die meiste derzeitige Koordination eventuell auftreten muss, wenn ein Zustand für Persistenz oder Kommunikation aktualisiert wird, können einige Ausführungsformen der verbesserten FaaS-Lösung Fabric- und/oder Speicherschnittstellen erweitern, um asynchrone Unterbreitungen diverser Nutzlasten für Kommunikation und Lagerung (zum Beispiel als Lagerungsfunktionen oder als Netzwerkfunktionen) derart zu unterstützen, dass die Aktualisierungen an einem beliebigen gegebenen Datenbereich in einer global konsistenten zeitlichen Reihenfolge ausgeführt werden. Falls folglich zwei Vorgänge X und Y durch Abhängigkeit derart verkettet sind, dass X eine asynchrone Aktualisierung eines Datenblocks auf einem gemeinsam verwendeten Laufwerk ausführt und das Abschließen von X Y auslöst (wobei zum Beispiel Y die Aktualisierung verbrauchen kann, die X ausgeführt hat (eine Read-After-Write oder RAW-Abhängigkeit) oder sie überschreibt (eine Write-After-Write oder WAW-Abhängigkeit)), können einige Ausführungsformen des Verkettens von „Speicher- FaaS-Aktionen“ das Verstoßen gegen die erforderlichen Reihenfolgenabhängigkeiten verhindern. Einige Ausführungsformen können die Speicheraktion selbst als eine verkettete FaaS-Aktion abstrahieren.
Erläuternd und nicht einschränkend können sich verteilte Funktionen von verteilten Prozessen dadurch unterscheiden, dass die Funktionen den Close-to-Open- oder Acquire-to-Release-Konsistenzsmodellen über gemeinsam verwendete Daten folgen (weil zum Beispiel Funktionen eventuell keine Kenntnis von einem Sessionzustand haben, der über ihre finite Dauer oder Run-to-Completion-Modell hinausgeht). Statt dass Action X einen Netzwerk- oder Speichervorgang P synchron innerhalb der Action X ausführen muss, bevor das Abschließen der Action X gemeldet wird und die Action Y ausgelöst wird (zum Beispiel als [X, P] => Y dargestellt), kann bei einigen Ausführungsformen eine Funktion X abschließen, dann eine verkettete Aktion P (zum Beispiel Speicher, Netzwerk usw.) ausführen (zum Beispiel auslösen), und wenn P geplant und ausgeführt wird, spezifizieren, dass das Abschließen von P die Funktion Y (zum Beispiel als X => [P => Y] dargestellt) auslösen kann.
Die Funktionswarteschlange 1216 kann zum Beispiel eine Warteschlange der Funktionen, die auszuführen sind, enthalten. Die Funktion Y (oder eine Angabe von Funktion Y) kann in der Funktionswarteschlange 1216 zum Beispiel als eine erste Funktion gespeichert werden. Die Ereigniswarteschlange 1218 kann unterschiedliche Ereignisse beinhalten, die einen Auslöser ausführen, wie „wenn das erste Ereignis auftritt (zum Beispiel Abschließen des Netzwerk- oder Speichervorgangs P) den ersten Auslöser der Auslöserwarteschlange 1220 ausführen“. Die Auslöserwarteschlange 1220 kann diverse Auslöser für eine oder mehrere Funktionen der Funktionswarteschlange 1216 zum Ausführen speichern. Der erste Auslöser der Auslöserwarteschlange 1220 kann das Auslösen der ersten Funktion (zum Beispiel Funktion Y) aus der Funktionswarteschlange 1216 beinhalten. Wenn daher der Netzwerk- oder der Speichervorgang P endet, kann das System aus der Ereigniswarteschlange 1218 bestimmen, dass das erste Ereignis aufgetreten ist (zum Beispiel Enden des Netzwerk- oder Speichervorgangs P), um die Ausführung des ersten Auslösers aus der Auslöserwarteschlange 1220 zu veranlassen. Der erste Auslöser kann dann eine oder mehrere Funktionen (zum Beispiel die Funktion Y) aus der Funktionswarteschlange 1216 zum Ausführen veranlassen
Die herkömmliche Abfolge [X, P] => Y erfordert, dass die Funktion X den Aktualisierungsvorgang P synchron (zum Beispiel Warten auf P) vor dem Zurruhesetzen ausführt, wodurch die Latenz und potenziell Skalierungsengpässe steigen (falls X zum Beispiel um diverse Verriegelungen und Ressourcen zum Ausführen von P kämpfen muss). Y kann selbst mit X verwandt sein. Y kann zum Beispiel eine Fortsetzung von X sein und einige Berechtigungsnachweise benötigen, die ihm als Resultat für das Ausführen von P verfügbar gemacht werden. Als ein Beispiel kann X eine Bildverarbeitungsaufgabe sein, die einige Kameraaufnahmen verarbeitet, P kann eine Aufgabe sein, die eine Bilddatenbank aktualisiert, und Y kann eine Aufgabe sein, die die jüngste Aktualisierung verarbeiten muss, um zu sehen, ob sie ein bestimmtes Zielobjekt oder Muster enthält. Bei einigen Ausführungsformen kann die Aufgabe P als eine „Fire and Forget“-Aufgabe in Zusammenhang mit X betrachtet werden, so dass Ressourcen, die X zugeordnet werden, freigegeben werden können, nachdem P gestartet wurde.
Bei einigen Ausführungsformen können das Erwerben und Freigeben von Verriegelungen und das Ausführen zweiphasige Transaktionen für solche Synchronisation und Koordination in verteilten Systemen mit asynchroner Befehlswarteschlangentechnologie (Command Queuing) für eine Hochleistungs-Fabric und Speichervorgänge sein (zum Beispiel Smart-NICs, Smart-Disks usw.). Das kann besonders für „Rack-Scale-Design“- oder RSD-Architekturen von Nutzen sein, bei welchen zusammengelegte Lagerung und zusammengelegter Speicher von unterschiedlichen Ausführungsmaschinen in einem gemeinsam verwendeten, niveaufreien Paradigma verwendet werden können, so dass ein auf Hardware basierender Einreihungsmechanismus die Notwendigkeit von Locks, Bedingungen usw. verhindern und gleichzeitig das Erfordernis von Softwareprotokollen höheren Niveaus verhindern kann (zum Beispiel Reader-Writer-Lockmanagement, Deadlock-Erfassung und Lösung usw.). Einige Ausführungsformen können zum Beispiel HQM-ähnliche Technologie einsetzen. Aufgaben können zum Beispiel zu einem HQM delegiert werden, um die Ausführung der Aufgaben zu managen.
Ausführungsformen oder Aspekte/Features des Systems 1210 (12) können ersetzt werden für oder eingebaut werden in alle oder Abschnitte der FaaS-Plattform 102 (1), des verbesserten FaaS-Systems 202 (2), der FaaS-Server-Architektur 300 (3), des verbesserten FaaS-Systems (4) und/oder des verbesserten FaaS-Systems (5). Softwarebauelemente diverser Ausführungsformen (zum Beispiel der Scheduler, der Funktionscode, Aspekte der Logik usw.) können zum Beispiel in das FaaS-Software-Subsystem 506 (5) eingebaut werden, und Hardware-Bauelemente der diversen Ausführungsformen (zum Beispiel der HQM, Aspekte der Logik usw.) können in das FaaS-Hardware-Subsystem 508 (5) eingebaut werden.
Zusätzliche Anmerkungen und Beispiele
Beispiel 1200 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Anfrage von einem Auslöseragenten um einen darauffolgenden Funktionsaufruf zu empfangen, Feedback zu dem Auslöseragenten bereitzustellen, um die Bereitschaft für den darauffolgenden Funktionsaufruf anzugeben, gestaffelte Multi-Version-Initiierung beschleunigter Multi-Mieter-Funktionen bereitzustellen, Synchronisation unter verteilten Aktionen bereitzustellen und den darauffolgenden Funktionsaufruf auszulösen, wenn ein Kriterium erfüllt wird.
Beispiel 1201 beinhaltet ein elektronisches Verarbeitungssystem, das einen Prozessor, einen Speicher, der kommunikationsfähig mit dem Prozessor gekoppelt ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher gekoppelt ist, umfasst, um eine Anfrage von einem Auslöseragenten für einen darauffolgenden Funktionsaufruf zu empfangen und zu dem Auslöseragenten Feedback bereitzustellen, um die Bereitschaft für den darauffolgenden Funktionsaufruf anzugeben.
Beispiel 1202 beinhaltet das System des Beispiels 1201, wobei die Logik ferner eine oder mehrere alternative Formen einer beschleunigten Funktion bereitstellen soll, die verwendet werden kann, während die beschleunigte Funktion hochläuft.
Beispiel 1203 beinhaltet das System eines der Beispiele 1201 bis 1202, wobei die Logik ferner eine oder mehreren Funktionen als asynchron zum Unterstützen einer Service-Kette identifizieren soll.
Beispiel 1204 beinhaltet ein Halbleiter-Package-Gerät, das ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, aufweist, wobei die Logik mindestens teilweise in einer oder mehreren aus konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist, die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um eine Anfrage von einem Auslöseragenten um einen darauffolgenden Funktionsaufruf zu empfangen und Feedback zu dem Auslöseragenten bereitzustellen, um Bereitschaft für den darauffolgenden Funktionsaufruf anzugeben.
Beispiel 1205 beinhaltet das Gerät des Beispiels 1204, wobei die Logik ferner eine oder mehrere alternative Formen einer beschleunigten Funktion bereitstellen soll, die verwendet werden kann, während die beschleunigte Funktion hochläuft.
Beispiel 1206 beinhaltet das System eines der Beispiele 1204 bis 1205, wobei die Logik ferner eine oder mehreren Funktionen als asynchron zum Unterstützen einer Service-Kette identifizieren soll.
Beispiel 1207 beinhaltet das Gerät eines der Beispiele 1204 bis 1206, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche, die innerhalb des einen oder der mehreren Substrate positioniert sind, beinhaltet.
Beispiel 1208 beinhaltet ein Verfahren zum Bereitstellen einer Function-as-a-Service, die das Empfangen einer Anfrage von einem Auslöseragenten um einen darauffolgenden Funktionsaufruf und das Bereitstellen von Feedback zu dem Auslöseragenten umfasst, um Bereitschaft für den darauffolgenden Funktionsaufruf anzugeben.
Beispiel 1209 beinhaltet das Verfahren des Beispiels 1208, das ferner das Bereitstellen einer oder mehrerer alternativer Formen einer beschleunigten Funktion umfasst, die verwendet werden kann, während die beschleunigte Funktion hochläuft.
Beispiel 1210 beinhaltet das Verfahren eines der Beispiele 1208 bis 1209, das ferner das Identifizieren einer oder mehrerer Funktionen als asynchron zum Unterstützen einer Service-Kette umfasst.
Computing-Architektur mit verbesserter Performance für FaaS
Serverloses Rechnen kann erlauben, dass FaaS- und Nicht-FaaS-Funktionen auf demselben Rechenknoten ausführen. Es kann zum Beispiel möglich sein, große Anzahlen unabhängiger FaaS-Funktionen in den Zwischenräumen (Ruheperioden) zwischen normalen Cloud-Anwendungen (zum Beispiel Nicht-FaaS-Funktionen) ähnlich zu Hyperthreading zu konsolidieren. Ein Zwischenraum kann ein Spalt sein, der in keinem Fall mit den normalen Cloud-Anwendungen gefüllt werden kann. Hyperthreading kann Mikroarchitekturressourcen im Ruhezustand einsetzen, die nicht vollständig ausgeübt werden, mit nur einem Thread pro Core, mit einem zusätzlichen Thread.
Folglich können FaaS- und Nicht-FaaS-Funktionen in einem Multi-Mietverhältnis konsolidiert werden, um zum Beispiel gleichzeitig auf demselben Rechenknoten (zum Beispiel Server- oder Prozessor-Core) zu arbeiten. Bei solchen Multi-Mietverhältnissen kann ein Problem mit einem lauten Nachbarn existieren, bei dem ein Cloud-Service-Anbieter (CSP) als Mitmieter Ressourcen monopolisiert (zum Beispielbandbreite, Disk-E/A, CPU), was sich negativ auf die Performance der Mitmieter auswirken kann. Die Nicht-FaaS-Funktionen können zum Beispiel die Ressourcen Bandbreiten, die nicht vollständig abonniert sind, jederzeit durch die FaaS-Funktionen absorbieren und umgekehrt. Das verursacht ungleichmäßige Cloud-Netzwerk-Performance über die Mitmieter und steigerte Latenz für FaaS-Funktionen zum Ausführen oder verringert die Performance von Nicht-FaaS-Mitmietern. Das neue Problem mit dem lauten Nachbarn kann qualitativ einzig sein, da es die effiziente, adaptive, feine und faire gemeinsame Verwendung von Ressourcen innerhalb jedes Rechenknotens betrifft, zum Beispiel an dem Prozessorkernniveau, anders als andere Konzepte, die Ressourcen wie Cache-Kapazität, Speicherbandbreite oder Prozessorplanungsprioritäten an einem Niveau der virtuellen Maschine oder des Containers bei derzeit existierenden Lösungen zuweisen oder reservieren.
Ausführungsformen, die unten beschrieben sind, können jede FaaS-Funktion und Nicht-FaaS-Funktion planen, um die Probleme mit dem geräuschvoller Nachbarn unter den viel höheren Niveaus der Multimieterschaft, die diese Konsolidierungen darstellen, zu verhindern. Das kann Latenz aufgrund von Warten reduzieren oder stabilisieren und das Scheitern von Funktionen aufgrund von Timeout-Fehlern reduzieren und die Variabilität der Ausführung-Performance kontrollieren. Außerdem können einige Ausführungsformen die Ressourcenverteilung verbessern. Funktionen können zum Beispiel zu Knoten bereitgestellt werden, die spezialisierte Hardware-Beschleuniger besitzen, um die Ausführung der Funktionen zu verbessern.
Einige Ausführungsformen können abgegrenzte Zuordnung von Kernausführungsressourcen unter mehreren Hardware-Threads durch eine priorisierte Planung bereitstellen. Die priorisierte Planung kann Funktionen mit konfliktfreien Nachfrageprofilen für simultane Multithreading-Ausführung (SMT-Ausführung) (zum Beispiel SMT4, SMT8 usw.) auf gemeinsam verwendeten Kernen planen, so dass jede Funktion eine faire Verwendung mindestens derjenigen Ressourcen, auf die die Funktion am empfindlichsten reagiert, empfängt. Dadurch können Ressourcenkonflikte zwischen Funktionen oder ein Problem mit einem geräuschvollen Nachbar verhindert werden. Daher können einige Ausführungsformen Verfahren und Tools sowie Feedbackmechanismen, die für effiziente und wendige, kurzfristige und fein abgegrenzte Zuordnung von Kernausführungsressourcen während SMT (zum Beispiel SMT2, SMT4) erforderlich sind, beinhalten.
Unter Bezugnahme auf 13A ist eine hinsichtlich der Performance verbesserte Computing-Architektur 1300 für FaaS, die die Ressourcenauseinandersetzung reduziert, veranschaulicht. Wie unten beschrieben, kann der Server 1302 Ressourcenauseinandersetzung indem er erste bis dritte Funktionen 1312, 1314, 1316 verteilt, um es ersten bis dritten Funktionen 1312, 1314, 1316 zu erlauben, erste bis dritte Ressourcen 1326, 1328, 1330 zuzuordnen aufzuweisen, die zur Ausführung ausreichen. Ferner können bei einigen Ausführungsformen vierte bis sechste Funktionen 1318, 1320, 1322, die auf dem ersten bis dritten Rechenknoten 1304a bis 1304c ausführen, Zuordnungsmengen der ersten bis dritten Ressourcen aufweisen, die den Zugriff auf die ersten bis dritten Ressourcen durch die erste bis dritte Funktion 1312, 1314, 1316 nicht beeinträchtigen.
Anfänglich kann ein Server 1302 mit verbesserter Effizienz Anfragen um erste bis dritte Funktionen 1312, 1314, 1316 (zum Beispiel FaaS-Funktionen) von auf Ereignis basierenden Auslösevorrichtungen oder einfach nur Auslösevorrichtungen 1306, 1308, 1310 (zum Beispiel diverse Rechengeräte) empfangen. Die Anfragen um die ersten bis dritten Funktionen 1312, 1314, 1316 können von Anwendungen aufgerufen werden, die auf den Auslösevorrichtungen 1306, 1308, 1310 arbeiten. Der Server 1302 kann die sensiblen Ressourcen der ersten bis dritten Funktion 1312, 1314, 1316 bestimmen. Die erste Funktion 1312 kann zum Beispiel Zugriff auf eine erste Ressource zum Ausführen benötigen, die zweite Funktion 1314 kann Zugriff auf eine zweite Ressource zum Ausführen erfordern, und die dritte Funktion 1316 kann Zugriff auf eine dritte Ressource zum Ausführen erfordern. Die erste bis dritte Ressource können ein beliebiger Typ von Rechenressourcen (zum Beispiel eine Hardwareressourcen, Hardwarebeschleuniger, Bandbreite, arithmetische Logikeinheiten, Leistung, Frequenz usw.) sein, die die erste bis dritte Funktion 1312, 1314, 1316 während der Ausführung benötigen und die voneinander unterschiedlich sein können.
Der Server 1302 kann Hardwareressourcenzuordnungen derart lenken, dass jede der ersten bis dritten Funktion 1312, 1314, 1316 eine faire Nutzung mindestens der ersten bis dritten Ressourcen, die ausführungssensitiv sind, empfängt. Im Einzelnen kann der Server 1302 die erste bis dritte Funktion 1312, 1314, 1316 zum Ausführen auf diversen Rechenknoten 1304a bis 1304c zu diversen Zeitpunkten derart ausführen, dass die erste bis dritte Funktion 1312, 1314, 1316 Zugriff auf die ersten bis dritten Ressourcen ohne Ressourcenauseinandersetzung haben. Um Ressourcenauseinandersetzung zu verhindern, kann der Server 1302 zum Beispiel die erste Funktion 1312 zu dem ersten Rechenknoten 1304a derart verteilen, dass die erste Funktion 1312 eine erste Ressourcenzuordnung 1326, die zur Ausführung reicht, aufweist. Der Server 1302 kann die zweite Funktion 1314 zu dem dritten Rechenknoten 1304c derart verteilen, dass die zweite Funktion 1314 eine zweite Rechenressourcenzuordnung 1328, die zur Ausführung reicht, aufweist. Der Server 1302 kann die dritte Funktion 1316 zu dem zweiten Rechenknoten 1304b derart verteilen, dass die dritte Funktion 1316 eine dritte Rechenressourcenzuordnung 1330, die zur Ausführung reicht, aufweist.
Vor der Ausführung kann der Server 1302 spekulativ die erste bis dritte Ressource zu bestimmen, die für die erste bis dritte Funktion 1312, 1314, 1316 benötigt werden. Der Server 1302 kann zum Beispiel die sensiblen Ressourcen der ersten bis dritten Funktion 1312, 1314, 1316 durch Analysieren einer dazugehörenden Umsetzung (zum Beispiel Quellcode, Transcode, historische Erfordernisse bei ähnlichen Funktionen usw.) bestimmen. Der Server 1302 kann daher eine erforderliche Ressourcenzuordnung, die eine Funktion benötigt, und/oder einen Typ der Ressourcen, die eine Funktion benötigt, identifizieren und eine solche Ressource als eine sensible Ressource kennzeichnen. Die Ressourcen können eine oder mehrere von Leistungsverbrauch, Firmware-Erfordernissen, Hardware-Erfordernissen (zum Beispiel Bandbreitennachfragen, Beschleuniger, Anzahlen oder Bruchteile verfügbarer Ressourcen in dem Anweisungs-Fetch einer CPU, TLB, Branch-Target-Buffer (BTB), Reservierungsstationen, Vorgangsports, wie arithmetische Logikeinheiten (Arithmetic Logic Units - ALUs) usw.) oder Taktfrequenzerfordernisse beinhalten. Die Ressourcen können auch gegen übermäßige Zuordnung reserviert werden, indem es zum Beispiel einem CPU-Kern nicht erlaubt wird, in Turbo-Ausführung einzutreten, um die Variabilität der Performance unter unterschiedlichen Multimieterbedingungen zu kontrollieren.
Bei einigen Ausführungsformen kann der Server 1302 bestimmen, ob eine oder mehrere Ressourcenzuordnungen, die jede der ersten bis dritten Funktion 1312, 1314, 1316 benötigt, über einem Schwellenwert liegt. Ist das der Fall, kann der Server 1302 die eine oder die mehreren Ressourcen als sensible Ressourcen kennzeichnen. Der Schwellenwert kann einer mittleren historischen Ressourcenverfügbarkeit an dem ersten bis dritten Rechenknoten 1304a bis 1304c entsprechen. Der Schwellenwert kann auch auf eine aktuelle Ressourcenverfügbarkeit an jedem des einen oder der mehreren Rechenknoten 1304a bis 1304c eingestellt werden.
Der Server 1302 kann ferner die erste bis dritte Funktion 1312, 1314, 1316 basierend auf den spekulativ bestimmten ersten bis dritten Ressourcen planen, um auf unterschiedlichen der Rechenknoten 1304a bis 1304c und/oder zu unterschiedlichen Zeitpunkten auszuführen, um Ressourcenkonflikte zu verhindern. Der Server 1302 kann folglich Latenz reduzieren und Fertigstellungsraten der ersten bis dritten Funktion 1312, 1314, 1316 verbessern.
Die erste Funktion 1312 kann zum Beispiel eine intensive Speicherbandbreitenfunktion ausführen und folglich ist die erste Ressourcen (zum Beispiel die sensible Ressource) eine Source mit hoher Bandbreite. Die zweite Funktion 1314 kann eine intensive ALU-Rechenfunktion ausführen, und folglich kann die zweite Ressource (zum Beispiel die sensible Ressource) eine ALU-Ressource sein. Die dritte Funktion 1316 kann einen leistungsintensiven Vorgang beinhalten, und folglich kann die dritte Ressource (zum Beispiel die sensible Ressource) höhere Leistung sein.
Wie oben angemerkt, kann der Server 1302 Anfragen um Ausführung der ersten bis dritten Funktion 1312, 1314, 1316 von Auslösevorrichtungen 1306, 1308, 1310 empfangen und die erste bis dritte Funktion 1312, 1314, 1316 zu diversen der Rechenknoten 1304a bis 1304c verteilen, um Ressourcenauseinandersetzung zu verhindern. Bei einigen Ausführungsformen kann der Server 1302 bereits vierte bis sechste Funktionen 1318, 1320, 1322 (zum Beispiel Nicht-FaaS-Funktionen), die sich an Rechenknoten 1304a bis 1304c in Ausführung befinden, geplant haben. Der Server 1302 kann identifizieren, dass die erste bis dritte Ressource extensiv von der dritten bis sechsten Funktion 1318, 1320, 1322 an diversen der ersten bis dritten Rechenknoten 1304a bis 1304c genutzt werden, indem er sich auf die erste bis dritte Ressourcenzuordnung 1332, 1334, 1336 der vierten bis sechsten Funktion 1318, 1320, 1322 bezieht.
Der Server 1302 kann die erste Funktion 1312 zu dem ersten Rechenknoten 1304a verteilen, um Ressourcenauseinandersetzung zu verhindern. Im Einzelnen ist die erste Ressource, die für die erste Funktion 1312 erforderlich ist, von der dritten Ressource, die für die sechste Funktion 1322 erforderlich ist, unterschiedlich, und folglich wird Ressourcenauseinandersetzung zwischen der ersten und der sechsten Funktion 1312, 1322 verhindert. Im Gegensatz, falls die erste Funktion 1312 zu dem dritten Rechenknoten 1304c bereitgestellt wurde, kann Ressourcenauseinandersetzung bestehen, da sowohl die erste als auch die vierte Funktion 1312, 1318 die erste Ressource als eine sensible Ressource benötigen.
Wie oben erklärt, benötigen die erste und die vierte Funktion 1312, 1318 hohe Zuordnungen der ersten Ressourcen, und die hohen Zuordnungen können die Verfügbarkeit der ersten Ressource auf dem dritten Rechenknoten 1304c überschreiten. Obwohl zum Beispiel die erste Funktion 1312 fähig sein kann, auf die erste Ressource in einer begrenzten Quantität an dem dritten Knoten 1304c zuzugreifen, hat die erste Funktion 1312 eventuell nicht ausreichenden Zugriff auf die erste Ressource, um die Ausführung abzuschließen, da die erste Ressource bereits signifikant der vierten Funktion 1318 durch die erste Ressourcenzuordnung 1332 zugeordnet ist. Auf dieselbe Weise wird die dritte Funktion 1316 dem zweiten Rechenknoten 1304b bereitgestellt, und die zweite Funktion 1314 kann dem dritten Rechenknoten 1304c bereitgestellt werden.
Bei einigen Ausführungsformen kann der Server 1302 bestimmen, dass die sechste Funktion 1322 die erste Ressource an dem ersten Rechenknoten 1304a einsetzt. Bei einem solchen Szenario kann der Server 1302 bestimmen, ob die erste Funktion 1312 ausreichend Zugriff auf die erste Ressource zum Beenden der Ausführung haben wird. Falls zum Beispiel der sechsten Funktion 1322 nur eine kleine Menge und/oder Zugriff auf die erste Ressource zugeordnet wird, empfängt die erste Funktion 1312 immer noch eine Zuordnung der ersten Ressource, die die Ausführung erleichtern wird.
Der Server 1302 kann daher bestimmen, ob eine Funktion basierend auf eine Verfügbarkeit der Ressource Zugriff auf eine sensible Ressource haben kann. Der Server 1302 kann zum Beispiel der Gleichung 1300 unten folgen, um die gesamte verfügbare Zuordnung an einem Rechenknoten zu bestimmen: $\begin{array}{l} Insgesamt verf \ddot{u} gbare Zuordnung = \\ Insgesamt potenzielle Zuordnung - Existierende Zuordnung (en) \end{array}$
In der oben stehenden Gleichung 1300 ist die gesamte potenzielle Zuordnung die gesamte potenzielle Zuordnung einer sensiblen Ressource an einem Rechenknoten, und die existierende Zuordnung ist die aktuelle Zuordnung der sensiblen Ressource an dem Rechenknoten zum Beispiel zu anderen Funktionen. Der Server 1302 kann Gleichung 1301 unten folgen, um zu bestimmen, ob eine ausreichende Zuordnung der sensiblen Ressource existiert: $Erfoerdernis sensible Ressource \leq Insgesamt verf \ddot{u} gbare Zuordnung$
Das Erfordernis an sensitiver Ressource ist das Erfordernis an sensitiver Ressource der Funktion. Falls oben Stehendes wahr ist, existiert eine ausreichende Zuordnung. Das heißt, falls das Erfordernis an sensitiver Ressource kleiner oder gleich ist wie die gesamte verfügbare Zuordnung der sensiblen Ressource an dem Rechenknoten, existiert eine ausreichende Zuordnung, um die Ausführung der Funktion an dem Rechenknoten abzuschließen.
Bei einigen Ausführungsformen kann der Server 1302 die erste bis dritte Ressourcenzuordnung 1332, 1334, 1336 zu der vierten bis sechsten Funktion 1318, 1320, 1322 reduzieren, und kann diese erste bis dritte Ressource der ersten bis dritten Funktion 1312, 1314, 1316 derart zu ordnen, dass die sensiblen Ressourcen gleichmäßig verteilt werden. Bei einigen Ausführungsformen kann der Server 1302 zum Beispiel die erste Funktion 1312 zu dem dritten Rechenknoten 1304c statt zu dem ersten Rechenknoten 1304a verteilen. Sowohl die erste als auch die vierte Funktion 1312 und 1318 benötigen die erste Ressource als eine sensible Ressource, und es kann daher Ressourcenauseinandersetzung auftreten. Um die Ressourcenauseinandersetzung zu reduzieren, kann der Server 1302 die erste Ressourcenzuordnung 1332 zu der vierten Funktion 1318 reduzieren und die erste Ressourcenzuordnung 1326 zu der ersten Funktion 1312 erhöhen. Das kann gleiche Zuordnungen der ersten Ressourcen zwischen der vierten Funktion 1318 und der ersten Funktion 1312 einrichten.
Bei einigen Ausführungsformen kann der Server 1302 einen Zeitpunkt der ersten bis dritten Funktion 1312, 1314, 1316 planen, um Ressourcenauseinandersetzung zu verhindern. Bei einigen Ausführungsformen kann der Server 1302 zum Beispiel die erste Funktion 1312 dem dritten Rechenknoten 1304c bereitstellen. Wie erwähnt, benötigen sowohl die erste als auch die vierte Funktion 1312 und 1318 die erste Ressource als eine sensible Ressource, und es kann daher Ressourcenauseinandersetzung auftreten. Um die Ressourcenauseinandersetzung zu verhindern, kann der Server 1302 die erste Funktion 1312 planen, um auf dem dritten Rechenknoten 1304c auszuführen, nachdem die vierte Funktion 1318 die Ausführung abgeschlossen hat. Das kann Ressourcenauseinandersetzung der ersten Ressource zwischen der ersten und der vierten Funktion 1312, 1318 verhindern.
Bei einigen Ausführungsformen kann der Server 1302 bestimmen, dass eine Hardwarebeschleuniger und/oder ein FPGA die Ausführung einer der Funktionen 1312, 1314, 1316 verbessern kann. Der Server 1302 kann eine der Funktionen 1312, 1314, 1316 entsprechend planen, um Zugriff auf den Hardwarebeschleuniger zu haben.
Bei einigen Ausführungsformen können die Rechenknoten 1304a bis 1304c Prozessorkerne, Rechengeräte oder Server sein. Bei einigen Ausführungsformen können die Auslösevorrichtungen 1306, 1308, 1310 eine Anwendung aufrufen, die auf einem entfernten Server (nicht veranschaulicht) läuft, der seinerseits Anfragen für die Funktionen 1312, 1314, 1316 zu dem Server 1302 bereitstellt. Bei einigen Ausführungsformen kann der Server 1302 die Funktionen 1312, 1314, 1316 aufrufen. Die Auslösevorrichtungen 1306, 1308, 1310 können zum Beispiel Laptops, mobile Geräte, Server, Desktops usw. beinhalten. Bei einigen Ausführungsformen kann der Server 1302 den ersten bis dritten Rechenknoten 1304a bis 1304c beinhalten. Außerdem kann bei einigen Ausführungsformen der Server 1302 das verbesserte FaaS-System 400, wie den Orchestrator 404 der 4, der die Aspekte, die oben beschrieben sind, umsetzt, beinhalten.
13B veranschaulicht einen verbesserten Planungsprozess 1338 für faireres Bin-Packing, der von dem Server 1302 der 13A umgesetzt werden kann. Bei dem vorliegenden Beispiel können dem Band 1 und dem Band 2 für jede der Funktion 0 und Funktion 1 Hardwareressourcen zugeordnet werden. Band 1 kann zum Beispiel Hardwarebeschleunigerressourcen darstellen, und Band 2 kann zugeordnete Prozessorkernressourcen darstellen. Der Server 1302 kann zum Beispiel spekulativ die Funktionen 0 und 1 analysieren, um vorhergesagte Instruction-Per-Cycle-Ressourcen (IPC - Anweisungen-pro-Zyklus-Ressourcen) 1340, 1342, die den Funktionen 0 und 1 zugeordnet werden, zu identifizieren, falls die Funktionen 0 und 1 gleichzeitig auf demselben Rechenknoten arbeiten. Funktion 1 kann zum Beispiel eine Nicht-FaaS-Funktionen sein, und Funktion 0 kann eine FaaS-Funktion sein. Wie erwähnt, kann der Funktion 1 eine unfair hohe Ressourcenmenge 1340, 1342 (zum Beispiel zugeordnete Hardwareressourcen) im Vergleich zu Funktionen 0 zugeordnet bekommen. Falls die Funktion 1 den Betrieb vor Funktion 0 beginnt, kann Funktion 1 eine unfaire Ressourcenzuordnung aufweisen.
Die Planung der Funktionen 0 und 1 kann folglich, wie von dem Pfeil 1344, für faireres Bin-Packing geändert und/oder zu unterschiedlichen Zeiten und/oder an unterschiedlichen Knoten geplant werden, und/oder Hardwareressourcen können neu verteilt werden, um Fairness (zum Beispiel gleiche Mengen) zwischen Hardwareressourcen, die für höhere IPC benötigt werden, zu erstellen. Der Funktion 0 kann daher eine Ressourcenmenge 1346 (zum Beispiel zugeordnete Hardwareressourcen) zugeordnet werden, um einen IPC gleich dem zu erzielen, der von einer Ressourcenmenge 1348 (zum Beispiel zugeordnete Hardwareressourcen), die der Funktion 1 zugeordnet werden, erzielt wird. Obwohl das nicht veranschaulicht ist, können Leistungs- und Frequenzzuordnungen auch gleichmäßiger zwischen Funktionen 0 und Funktion 1 durch Änderung zugeordnet werden.
13C zeigt ein Verfahren 1350 zum Planen von Funktionen in einer CSP Umgebung und kann von dem Server 1302 der 13A und/oder dem verbesserten FaaS-System 400, wie dem Orchestrator 404, der 4 ausgeführt werden. Das Verfahren 1350 kann in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Computerprogrammcode zum Ausführen von Vorgängen, die in dem Verfahren 1350 gezeigt sind, können in einer beliebigen Kombination eine oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie die „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Der veranschaulichte Verarbeitungsblock 1352 kann das Bestimmen für jede jeweilige Funktion einer Vielzahl von Funktionen einer oder mehrerer sensitiver Ressourcen, die zum Ausführen der jeweiligen Funktion erforderlich sind, bestimmen. Der veranschaulichte Verarbeitungsblock 1354 kann das Bestimmen eines Ressourcenkonflikts zwischen der einen oder den mehreren sensiblen Ressourcen einer ersten der Funktionen und der einen oder mehreren sensiblen Ressourcen einer zweiten der Funktionen beinhalten. Der veranschaulichte Verarbeitungsblock 1356 kann das Planen einer oder mehrerer der ersten oder zweiten Funktion, um den Ressourcenkonflikt zu verhindern, beinhalten. Der veranschaulichte Verarbeitungsblock 1356 kann zum Beispiel das Planen einer oder mehrerer der ersten oder zweiten Funktion zum Ausführen zu vollständig nicht überlagerten Zeiten auf demselben Knoten beinhalten, um auf unterschiedlichen Knoten auszuführen und/oder eine Zuordnung von Ressourcen von einer Funktion zu einer anderen Funktion neu zu verteilen, um Fairness und Wahrung der Dienstgüte zu erstellen. Der veranschaulichte Verarbeitungsblock 1358 kann das Planen einer oder mehrerer der sensiblen Ressourcen der ersten und zweiten Funktion beinhalten, um Zielperformanceerträge für jeweils die erste und die zweite Funktion zu erzielen. Der veranschaulichte Verarbeitungsblock 1358 kann zum Beispiel das Zuordnen der sensiblen Ressourcen zu der ersten und der zweiten Funktion beinhalten. Obwohl dies nicht veranschaulicht ist, kann das Verfahren 1350 das Bestimmen eines Ressourcenmangelkonflikts zwischen der einen oder den mehreren sensiblen Ressourcen der ersten Funktion und der einen oder den mehreren sensiblen Ressourcen einer der dritten der Funktionen beinhalten. Das Verfahren 1350 kann das Planen der ersten und dritten Funktion zum Ausführen auf demselben Knoten zu einer überlagerten Zeit basierend auf dem Ressourcenmangelkonflikt beinhalten.
Das Verfahren 1350 kann die Effizienz und den Betrieb der CSP-Umgebung verbessern. Das Verfahren 1350 kann zum Beispiel Latenz reduzieren und Fertigstellungsraten der Funktionen verbessern.
Zusätzliche Anmerkungen und Beispiele
Beispiel 1300 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, für jede jeweilige Funktion einer Vielzahl von Funktionen, eine oder mehrere sensible Ressourcen zu bestimmen, die erforderlich sind, um die jeweilige Funktion auszuführen, einen Ressourcenkonflikt zwischen der einen oder den mehreren sensiblen Ressourcen einer ersten Funktion in der Vielzahl von Funktionen und der einen oder den mehreren sensiblen Ressourcen einer zweiten Funktion in der Vielzahl von Funktionen zu bestimmen, eine oder mehrere der ersten Funktion oder der zweiten Funktion zu planen, um den Ressourcenkonflikt zu verhindern, die erste und die zweite Funktion zum Ausführen auf unterschiedlichen Rechenknoten zu planen, einen Ressourcenmangelkonflikt zwischen der einen oder den mehreren sensiblen Ressourcen der ersten Funktion und der einen oder den mehreren sensiblen Ressourcen einer dritten Funktion in der Vielzahl von Funktionen zu bestimmen, die erste und die dritte Funktion zum Ausführen auf demselben Knoten zu einer überlagerten Zeit zu planen und eine oder mehrere der sensiblen Ressourcen der ersten und der zweiten Funktion zu planen, um einen gezielten Performanceertrag für jeweils die erste und die zweite Funktion zu erzielen.
Beispiel 1301 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, für jede jeweilige Funktion einer Vielzahl von Funktionen eine oder mehrere sensible Ressourcen zu bestimmen, die erforderlich sind, um die jeweilige Funktion auszuführen, einen Ressourcenkonflikt zwischen der einen oder den mehreren sensiblen Ressourcen einer ersten Funktion in der Vielzahl von Funktionen und der einen oder den mehreren sensiblen Ressourcen einer zweiten Funktion in der Vielzahl von Funktionen zu bestimmen, und eine oder mehrere der ersten Funktion oder der zweiten Funktion zu planen, um den Ressourcenkonflikt zu verhindern.
Beispiel 1302 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1301, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die erste und die zweite Funktion zum Ausführen zu unterschiedlichen Zeiten zu planen.
Beispiel 1303 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1301, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die erste und die zweite Funktion zum Ausführen auf unterschiedlichen Rechenknoten zu planen.
Beispiel 1304 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1301, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, das Fehlen eines Ressourcenkonflikts zwischen der einen oder den mehreren sensiblen Ressourcen der ersten Funktion und der einen oder den mehreren sensiblen Ressourcen einer dritten Funktion in der Vielzahl von Funktionen zu bestimmen, und die erste und die dritte Funktion zum Ausführen auf demselben Knoten zu einer überlagerten Zeit zu planen.
Beispiel 1305 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, für jede jeweilige Funktion einer Vielzahl von Funktionen eine oder mehrere sensible Ressourcen zu bestimmen, die erforderlich sind, um die jeweilige Funktion auszuführen, einen Ressourcenkonflikt zwischen der einen oder den mehreren sensiblen Ressourcen einer ersten Funktion in der Vielzahl von Funktionen und der einen oder den mehreren sensiblen Ressourcen einer zweiten Funktion in der Vielzahl von Funktionen zu bestimmen, und eine oder mehrere sensible Ressourcen zu der ersten und zweiten Funktion zu planen, um einen gezielten Performanceertrag für jeweils die erste und die zweite Funktion zu erzielen.
Verbesserte Funktionsausführungen für FaaS
Die 14A und 14B veranschaulichen eine verbesserte Funktionsausführungssequenz 1400 gemäß einigen Ausführungsformen. Ein solches Beispiel kann zum Beispiel von dem Server 1302 der 13A, einem oder mehreren des ersten bis dritten Rechenknotens 1304a bis 1304c und/oder des verbesserten FaaS-Systems 400, wie dem Orchestrator 404 der 4, umgesetzt werden. Insbesondere kann ein Funktionsaufruf 1402 das Ausführen der Funktion 1404 zum Ausführen anfordern. Der Funktionsaufruf 1402 kann in einem FaaS-Kontext auch als ein „Auslöser“ bezeichnet werden. Die Funktion 1404 kann eine serverlose Funktion (zum Beispiel eine einzelne FaaS-Funktionen) sein. Die Funktion 1404 kann als eine Sammlung interner Vorgänge, die in einer Reihenfolge ausführbar sind, gesehen werden. Ein Vorgang kann eine Ausführung eines Moduls innerhalb der Funktion 1404, das einen Abschnitt der gesamten Funktion vollbringt, sein. Man nehme zum Beispiel an, dass die Funktion 1404 eine Anzahl von Tupeln aus einer Datenbanktabelle gemäß einem Satz von Bedingungen auswählen soll und dann die Resultate sortieren muss, um die Ausgabe in einer gewünschten Reihenfolge zu erzeugen oder weiter aus der sortierten Ausgabe auszuwählen. Bei diesem Beispiel sind das Auswählen und das Sortieren zwei interne Vorgänge der Funktion 1404. Die internen Vorgänge können als „Funclets“ bezeichnet werden.
Die Aufgliederungsvorgehensweise 1406 kann die Funktion 1404 in eine Reihe von Funclets 1408a bis 1408e zum Beispiel durch einen Transcode oder eine statische Analyse, von der Module aus dem Codekörper der Funktion 1404 aufgerufen werden, aufgliedern, statt die Funktion 1404 als eine atomare Einheit zu behandeln und die Funktion 1404 wie präsentiert auszuführen. Die Aufgliederungsvorgehensweise 1406 kann von einem Programmierer, von einem Cloud-Service-Anbieter spezifiziert werden und/oder kann durch eine Optimierungstoolkette, die von Drittparteien geschrieben wird, umgesetzt werden. Die Aufgliederungsvorgehensweise 1406 und der Vorgang der Aufgliederungsvorgehensweise 1406 können ferner durch Optionen, Hinweise, Richtlinien und so fort, die von einem Programmierer oder einem Cloud-Service-Anbieter bereitgestellt werden, gesteuert werden. Eines oder mehrere der Funclets 1408a bis 1408c können optional von einem Benutzer umgesetzt und zu der Vorgehensweise 1406 spezifiziert werden. Anders als die Funktionen können die Funclets 1408a bis 1408e variierende Zustandsniveaus untereinander für effizientes Rechnen und Koordination gemeinsam verwenden. Die individuellen Funclets 1408a bis 1408e können einem individuellen Planungs- und Ausführungsprozess 1410 unterzogen werden, um Latenz zu verringern und Ressourcen effizienter zu verwalten. Im Einzelnen können einige der Funclets 1408a bis 1408e gleichzeitig zum Verringern der Latenz ausführen. Falls ferner ein bestimmtes Funclet der Funclets 1408a bis 1408e eine Ressource, wie eine spezialisierte Hardware (zum Beispiel einen Beschleuniger oder FPGA) oder Firmware zum Ausführen erfordert, kann es möglich sein, die Ausführung dieses bestimmten Funclet der Funclets 1408a bis 1408e aufzuschieben, bis die spezialisierte Hardware verfügbar wird, um die Ressourcennutzung und Planung zu verbessern.
Wie veranschaulicht, kann die Funktion 1404 in eine Abhängigkeitsgrafik 1414 aufgegliedert werden, die aus den Funclets 1408a bis 1408e besteht, wobei die Abhängigkeitsgrafik 1414 eine Ausführungsreihenfolge der Funclets 1408a bis 1408e angibt. In der Abhängigkeitsgrafik 1414 kann das Funclet 1408a zuerst ausführen. Die Funclets 1408b, 1408c können basierend auf Informationen von dem Funclet 1408a ausführen und gleichzeitig ausführen. Das Funclet 1408d kann nach den Funclets 1408b, 1408c und basierend auf Informationen von beiden Funclets 1408b, 1408c arbeiten. Das Funclet 1408e kann nach dem Funclet 1408d basierend auf Informationen von dem Funclet 1408d ausführen und die Ausführung der Funktion 1404 abschließen.
Eine Planungs- und Ausführungsvorgehensweise 1410 kann basierend auf der Abhängigkeitsgrafik 1414 arbeiten, um jedes der Funclets 1408a bis 1408e individuell zu planen. Basierend auf der Abhängigkeitsgrafik 1414 können zum Beispiel die Verbindungen zwischen den Funclets 1408a bis 1408e klar sein. Die Planungs- und Ausführungsvorgehensweise 1410 kann daher bestimmen, ob gleichzeitig (das heißt parallel) oder seriell (nacheinander) die Funclets 1408a bis 1408e basierend auf den Abhängigkeitsverbindungen der Abhängigkeitsgrafik 1414 geplant werden sollen.
Wie in einer Planungsgrafik 1416 der 14B veranschaulicht, können die Funclets 1408a bis 1408e von der Planungs- und Ausführungsvorgehensweise 1410 geplant werden, um während diverser Zeitschlitze zwischen den Zeitpunkten T₀ bis T₄ und an diversen Rechenknoten 1412a bis 1412c zu arbeiten. Das Funclet 1408a kann zum Ausführen auf dem Rechenknoten 1412a zwischen den Zeiten T₀ bis T₁ geplant werden. Da andere Funclets 1408b bis 1408e Daten aus dem Funclet 1408a benötigen, kann keines der anderen Funclets 1408 während der Zeit T₀ bis T₁ ausführen.
Nachdem das Funclet 1408a die Ausführung abgeschlossen hat, können beide Funclets 1408b, 1408c an den Computerknoten 1412a, 1412b zwischen den Zeiten T₁-T₂ ausführen. Wie in der Abhängigkeitsgrafik 1414 veranschaulicht, können die Funclets 1408b, 1408c gleichzeitig mit den Funclets 1408b, 1408c ausführen, denn beide benötigen nur Informationen von dem Funclet 1408a und nicht von den Funclets 1408d, 1408e. In der Planungsgrafik 1416 führen daher die Funclets 1408b und 1408c gemeinsam an unterschiedlichen Rechenknoten 1412a, 1412b aus. Bei einigen Ausführungsformen, falls einer der Rechenknoten 1412a bis 1412c ausreichend Ressourcen aufweist, um beide Funclets 1408b, 1408c zu unterstützen, können beide Funclets 1408b, 1408c geplant werden, um auf dem einen der Rechenknoten 1412a bis 1412c auszuführen.
Nachdem die Funclets 1408b, 1408c die Ausführung abgeschlossen haben, kann das Funclet 1408d auf dem Rechenknoten 1412c während der Zeiten T₂-T₃ ausführen. Die Ausführung des Funclet 1408d kann durch einen Hardwarebeschleuniger und/oder einen FPGA, der sich auf dem Rechenknoten 1412c befindet, verbessert werden. Die Planungs- und Ausführungsvorgehensweise 1410 kann daher weiter berücksichtigen, ob eine Ressource, wie eine Hardwareressource, die Ausführung eines der Funclets 1408a bis 1408e verbessern kann, und eines der Funclets 1408a bis 1408e entsprechend planen. Ferner, wie in der Abhängigkeitsgrafik 1414 veranschaulicht, kann das Funclet 1408d Daten von den Funclets 1408b, 1408c benötigen, aber nicht von dem Funclet 1408e, um auszuführen, und wird folglich geplant, nachdem die Funclets 1408b, 1408c die Ausführung abgeschlossen haben.
Nachdem das Funclet 1408d die Ausführung abgeschlossen hat, kann das Funclet 1408e auf dem Rechenknoten 1412c während der Zeiten T₃-T₄ ausführen. Die Effizienz von Ressourcen kann verbessert werden, indem man das Funclet 1408e auf dem Rechenknoten 1412c ausführen lässt. Da das Funclet 1408e Daten von dem Funclet 1408d benötigen kann, kann das Funclet 1408e nämlich geplant werden, um auf demselben Knoten auszuführen wie das Funclet 1408d, um Datentransfers zwischen den Rechenknoten 1412a bis 1412c zu minimieren und Speicher- und Cache-Nutzung zu verbessern. Die Planungs- und Ausführungsvorgehensweise 1410 kann daher die Ressourcennutzung durch Minimieren von Datentransfers und Verbessern der Cache-Wiederverwendung durch verbesserte Planung der Funclets 1408a bis 1408e weiter verbessern.
Bei einigen Ausführungsformen können eines oder mehrere der Funclets 1408a bis 1408e zu einem späteren Zeitpunkt aus einem neu geschaffenen Zustand ausgeführt werden, wenn Ressourcen, die für die Funclets 1408a bis 1408e benötigt werden, verfügbar werden. Man nehme zum Beispiel an, dass das Funclet 1408d den Hardwarebeschleuniger zur Ausführung benötigt. Das Funclet 1408d kann geplant werden, um als Reaktion auf eine Identifikation, dass der Hardwarebeschleuniger verfügbar ist, auszuführen. Die Ausführung des Funclets 1408d kann eine Periode nachdem die Funclets 1408b, 1408c die Ausführung abgeschlossen haben, auftreten. Das Funclet 1408d wird nämlich eventuell nicht automatisch ausgelöst, um die Ausführung zu beginnen, sobald die Funclets 1408b, 1408c die Ausführung abgeschlossen haben. Das Funclet 1408d kann stattdessen geplant werden, um auszuführen, wenn der Hardwarebeschleuniger zusätzlich dazu, dass die Funclets 1408b, 1408c die Ausführung abschließen, verfügbar wird.
Das Einteilen der Funktion 1404 in Funclets 1408a bis 1408e kann das Versagenspotenzial der Funktion 1404 reduzieren. Bei einigen Ausführungsformen können zum Beispiel einige Vorgänge der Funktion 1404 spezifische Hardware, wie das Funclet 1408d, das oben erwähnt ist, erfordern. Falls die Funktion 1404 auf die Hardware warten muss, kann ein Timeout-Versagen auftreten, bei dem die Funktion 1404 beim Abschließen vor einem vorbestimmten Zeitlimit versagt und folglich aufgegeben wird.
Durch Einteilen der Funktion 1404 in eine Reihe individueller Funclets 1408a bis 1408e, können solche Timeout-Versagen besser verhindert werden, da die Funclets 1408a bis 1408e getrennt geplant werden, um nur zu arbeiten, wenn Ressourcen verfügbar sind. Schlicht gesagt kann die Funktion 1404 zwischen den Funclets 1408a bis 1408e durch Warten auf das Initiieren eines Funclets 1408a bis 1408, bis Ressourcen verfügbar sind, auf „Pause gestellt“ werden. Wie erwähnt, kann das Funclet 1408d dazu geplant werden auszuführen, wenn der Hardwarebeschleuniger verfügbar wird, statt mit der Ausführung zu beginnen und dann darauf zu warten, dass der Hardwarebeschleuniger verfügbar wird.
Außerdem können die Aufgliederungsvorgehensweise 1406 und die Planungs- und Ausführungsvorgehensweise 1410 Gelegenheiten zum Verbessern der Gesamtausführung durch Erwerben und Freigeben von Ressourcen an Niveaukörnigkeit der Funclets 1408a bis 1408e bereitstellen, was eine feinere Körnigkeit ist als die der ersten Funktion 1404. Ferner kann es möglich sein, ein Funclet, wie das Funclet 1408d, das auf Sonderzweck-Hardwarebeschleuniger beschleunigt werden kann, mit denjenigen zu mischen, die besser für herkömmliche oder auf CPU-basierende Softwareausführung für die beispielhaften Funclets 1408a bis 1408c und 1408e geeignet sind.
Ferner erlauben Ausführungsformen eine einfache Flussausführung der Funktion 1404, bei der die Funktion 1404 in kleinere Funclets 1408a bis 1408e gemeinsam mit dem Ordnen, wie in der Abhängigkeitsgrafik 1414 veranschaulicht, zerlegt werden. Ein Planungssystem, das in der Abhängigkeitsgrafik 1414 umgesetzt wird, kann verfügbare Ressourcen/Ausführungen oder Prioritäten anderer konkurrierender Erfordernisse für diejenigen Ressourcen für opportunistische Planung unter Beibehaltung der Funclet-Reihenfolge überwachen. Darüber hinaus kann ein Entwickler eventuell die verbesserte Funktionsausführungssequenz 1400 nicht kennen. Das kann die Aufgabe des Entwicklers vereinfachen, da der Entwickler Subfunktionen nicht zu identifizieren braucht, da der Prozess auf der CSP-Seite opak ausgeführt wird.
Wie oben beschrieben, können die Funclets 1408a bis 1408e zu einer Ausführungsplattform gemäß den Einordnungsabhängigkeiten, die von der Abhängigkeitsgrafik 1414 beschrieben werden, bereitgestellt werden. Architekturunterstützung kann zum Sicherstellen der richtigen Einordnungsabhängigkeiten in der Abhängigkeitsgrafik 1414 bereitgestellt werden, einschließlich der Unterstützung für effiziente logische Barrieren und Ereigniskoordination unter Verwenden von Techniken, die Benutzerebenen-Interrupts (ULI), Hardware-Warteschlangenmanager, Remote Atomics (RAO) usw. für die Funclets 1408a bis 1408e erweitern, die als gleichzeitige Aktivitäten innerhalb oder über Adressraumgrenzen geplant werden können. Die Funclets 1408a bis 1408e können auch in kleinere Einheiten, „Mini-Funclets“ genannt, die ähnlich wie oben beschrieben ausgeführt werden, aufgegliedert werden.
Die verbesserte Funktionsausführungssequenz 1400 kann von einem oder mehreren Hardware-Warteschlangenmanagern koordiniert werden. Mehrere Hardware-Warteschlangenmanager können die Funclets 1408a bis 1408e planen und einreihen. Die Hardware-Warteschlangenmanager können sich auf unterschiedlichen Knoten befinden, können aber die Warteschlange der Funclets 1408a bis 1408e in der Ausführungsreihenfolge der Abhängigkeitsgrafik 1414 aufrechterhalten und entsprechend planen.
Die verbesserte Funktionsausführungssequenz 1400 kann ferner durch den Server 1302 der 13A, wie oben angemerkt, umgesetzt werden, kann aber auch oder in Verbindung mit dem Server 1302 in dem verbesserten FaaS-System 400, wie einem Orchestrator 404 der 4 und/oder einem oder mehreren Modulen als ein Satz von Logikanweisungen umgesetzt werden, der in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., in konfigurierbarer Logik, wie zum Beispiel PLAs, FPGAs, CPLDs, gespeichert sind; in Hardwarelogik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer Kombination davon umgesetzt werden.
Computerprogrammcode zum Ausführen von Vorgängen, die in der verbesserten Funktionsausführungssequenz 1400 gezeigt sind, können in einer beliebigen Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie die „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Man nehme als ein Beispiel an, dass eine Funktion das Analysieren einer kurzen Sprachdatei beinhaltet. Das Analysieren der kurzen Sprachdatei kann in Funclets (zum Beispiel Bestandteilvorgänge) aufgegliedert werden, einschließlich Übersetzen (Transkribieren) der Sprachdatei in Text, Erkennen und Trennen der Wörter und/oder Sätze, die von unterschiedlichen Teilnehmern gesprochen werden, und Zuweisen der Transkriptionen durch die Identitäten der Sprecher. Durch Aufgliedern der Funktion, wie oben in Zusammenhang mit der verbesserten Funktionsausführungssequenz 1400 beschrieben, wird teilweise Ausführung der Funktion erhalten, so dass einige der Funclets in einer verfügbaren Zeitmenge mit einer besonderen Menge an Ressourcen abschließen. Das Aufgliedern der Funktion in Funclets kann daher die Ausführung verbessern, die Ressourcennutzung reduzieren und die Latenz reduzieren.
14C zeigt ein Verfahren 1450 zum Planen einer Funktion, die mehrere Vorgänge, in einer CSP-Umgebung aufweist, und die von dem Server 1302 der 13A ausgeführt werden kann, aber auch oder in Verbindung mit dem Server 1302 in dem verbesserten FaaS-System 400, wie dem Orchestrator 404 der 4 und/oder einem oder mehreren Modulen als ein Satz logischer Anweisungen umgesetzt werden kann, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., konfigurierbarer Logik, wie zum Beispiel PLAs, FPGAs, CPLDs, gespeichert sind; in Hardwarelogik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer Kombination davon gespeichert sind.
Computerprogrammcode zum Ausführen von Vorgängen, die in dem Verfahren 1450 gezeigt sind, können in einer beliebigen Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie die „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Der veranschaulichte Verarbeitungsblock 1452 kann Vorgänge (zum Beispiel Funclets) einer Funktion bestimmen. Der veranschaulichte Verarbeitungsblock 1453 teilt die Funktion in Funclets basierend auf den identifizierten Vorgängen ein. Jedes Funclet kann zum Beispiel einen einzigen Vorgang beinhalten. Bei anderen Ausführungsformen kann jedes Funclet mehrere Vorgänge beinhalten, falls die Vorgänge miteinander verwandt sind (zum Beispiel ähnliche Daten einsetzen oder Daten voneinander benötigen). Der veranschaulichte Verarbeitungsblock 1454 kann eine statische Grafik gegenseitiger Abhängigkeit erzeugen, um die Reihenfolge der Funclets zu bestimmen. Wie oben angemerkt, kann die Reihenfolge zum Beispiel das Bestimmen beinhalten, ob die Funclets (zum Beispiel die Vorgänge) gleichzeitig oder seriell ausführen können. Der veranschaulichte Verarbeitungsblock 1456 kann individuell die Funclets basierend auf der bestimmten Reihenfolge planen. Ein erstes Funclet (zum Beispiel Vorgang) kann zum Beispiel vor anderen Funclets (zum Beispiel Vorgängen) geplant werden, falls die anderen Funclets von Daten aus dem ersten Funclet abhängen. Der veranschaulichte Verarbeitungsblock 1456 kann ferner ein erstes der Funclets zum Ausführen an einem ersten Rechenknoten, und ein zweites der Funclets zum Ausführen an einem zweiten Rechenknoten, der von dem ersten Rechenknoten unterschiedlich ist, planen. Gleichzeitige Planung kann daher erleichtert werden, oder die Verwendung unterschiedlicher Hardware (zum Beispiel spezialisierte und/oder nicht spezialisierte) zum Reduzieren der Latenz der ersten und der zweiten Funktion.
Der veranschaulichte Verarbeitungsblock 1456 kann auch ein erstes der Funclets in einem ersten Zeitpunkt planen, und ein zweites der Funclets in einem zweiten Zeitpunkt, der von dem ersten Zeitpunkt unterschiedlich ist, planen. Eine serielle Ausführung des ersten und des zweiten Funclets kann daher umgesetzt werden. Der veranschaulichte Verarbeitungsblock 1456 kann ferner planen, dass das zweite Funclet die Ausführung als Reaktion sowohl auf eine Identifikation, dass eine Ressourcenzuordnung (zum Beispiel der spezialisierte Hardwarebeschleuniger und/oder FPGA) verfügbar ist, als auch eine Identifikation, dass das erste Funclet abgeschlossen ist, beginnt. Bei einer solchen Ausführungsform kann das Verfahren 1450 weiter das absichtliche Verzögern der Ausführung des zweiten Funclets, bis die Ressourcenzuordnung verfügbar ist, beinhalten. Außerdem kann das zweite Funclet eine Ausgabe aus dem ersten Funclet erfordern.
Das Verfahren 1450 kann die Effizienz und den Betrieb der CSP-Umgebung verbessern. Das Verfahren 1450 kann zum Beispiel Latenz reduzieren, Ressourcennutzung verbessern und Fertigstellungsraten der Funktionen verbessern.
Zusätzliche Anmerkungen und Beispiele
Beispiel 1400 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, Vorgänge einer Funktion zu bestimmen, eine Reihenfolge der Vorgänge zu bestimmen, die Vorgänge individuell basierend auf der bestimmten Reihenfolge zu planen, einen ersten der Vorgänge zum Ausführen an einem ersten Rechenknoten planen, und einen zweiten der Vorgänge zum Ausführen an einem zweiten Rechenknoten planen, den ersten Vorgang in einem ersten Zeitpunkt planen, den zweiten Vorgang in einem zweiten Zeitpunkt, der von dem ersten Zeitpunkt unterschiedlich ist, planen, den zweiten Vorgang planen, so dass die Ausführung als Reaktion sowohl auf eine Identifikation, dass die Ressourcenzuordnung verfügbar ist, als auch auf eine Identifikation, dass der erste Vorgang abgeschlossen ist, planen, und die Ausführung des zweiten Vorgangs zu verzögern, bis die Ressourcenzuordnung verfügbar ist, wobei der zweite Vorgang eine Ausgabe aus dem ersten Vorgang empfangen soll.
Beispiel 1401 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, Vorgänge einer Funktion zu bestimmen, eine Reihenfolge der Vorgänge zu bestimmen, die Vorgänge individuell basierend auf der bestimmten Reihenfolge zu planen.
Beispiel 1402 beinhaltet mindestens ein computerlesbares Medium des Beispiels 1401, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen ersten der Vorgänge zu planen, um an einem ersten Rechenknoten auszuführen, und einen zweiten der Vorgänge, um an einem zweiten Rechenknoten auszuführen.
Beispiel 1403 beinhaltet mindestens ein computerlesbares Medium des Beispiels 1401, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen ersten Vorgang der Vorgänge in einem ersten Zeitpunkt zu planen und einen zweiten Vorgang der Vorgänge in einem zweiten Zeitpunkt, der von dem ersten Zeitpunkt unterschiedlich ist, zu planen.
Beispiel 1404 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1403, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, den zweiten Vorgang zu planen, damit die Ausführung als Reaktion sowohl auf eine Identifikation, dass die Ressourcenzuordnung verfügbar ist, als auch eine Identifikation, dass der erste Vorgang abgeschlossen ist, beginnt.
Beispiel 1405 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1404, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Ausführung des zweiten Vorgangs zu verzögern, bis die Ressourcenzuordnung verfügbar ist.
Beispiel 1406 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1403, wobei der zweite Vorgang eine Ausgabe aus dem ersten Vorgang empfangen soll.
Beispiel 1407 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1400, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Vorgänge basierend auf einer Benutzereingabe zu bestimmen.
Verbesserte Speicherzuordnung für FaaS
15A veranschaulicht eine Computing-Architektur 1500 mit verbesserter Leistung und Lagerung gemäß einigen Ausführungsformen. Ein solches Beispiel kann zum Beispiel von dem Server 1302 der 13A, einem oder mehreren des ersten bis dritten Rechenknotens 1304a bis 1304c und/oder des verbesserten FaaS-Systems 400, wie den Orchestrator 404 der 4, umgesetzt werden.
Die Computing-Architektur mit verbesserter Leistung und Lagerung beinhaltet einen Container 1502 und eine Funktion 1504. Die Funktion 1504 kann zusammen mit dem Container 1502 arbeiten. Die Funktion 1504 kann zum Beispiel in den Container 1502 geladen werden. Bei einigen Ausführungsformen kann die Funktion 1504 in den Container 1504 heruntergeladen und instanziiert werden. Das Plattformbetriebssystem 1506 kann den Container 1502 und die Funktion 1504 Hosten und zusammen mit dem Speicher 1510 arbeiten, um Daten für den Container 1502 und die Funktion 1504 zu speichern.
Wie veranschaulicht, kann das Plattformbetriebssystem 1506 eine dedizierte Speichercontainerauflistung 1524 und eine dedizierte Funktionsspeicherauflistung 1526 beinhalten. Die dedizierte Speichercontainerauflistung 1524 und die dedizierte Funktionsspeicherauflistung 1526 können Datenstrukturen, Arrays oder Nachschlagtabellen sein, die Adressbereiche des Speichers 1510, die der Funktion 1504 und/oder dem Container 1502 dediziert sind, identifizieren. Die dedizierte Speichercontainerauflistung 1524 identifiziert Basiscontainerspeicherräume 1520a bis 1520c. Die dedizierte Funktionsspeicherauflistung 1526 identifiziert Funktionsspeicherräume 1522a, 1522b. Wie veranschaulicht, kann der Speicher 1510 auch nicht zugeordneten Speicherplatz 1530 beinhalten.
Wenn eine Speicherzuordnungsanfrage von dem Plattformbetriebssystem 1506 empfangen wird, kann das Plattformbetriebssystem 1506 bestimmen, ob die Funktion 1504 oder der Container 1502 der Ursprung der Speicherzuordnungsanfrage ist. Falls der Container 1502 der Ursprung der Speicherzuordnungsanfrage ist, kann eine Speicherzuordnung basierend auf der dedizierten Speichercontainerauflistung 1524 bereitgestellt werden. Die Speicherzuordnung kann zum Beispiel eine Zuordnung eines Speicherbereichs sein, der von der dedizierten Speichercontainerauflistung 1524 identifiziert wird. Der Container 1502 kann folglich zu den Basiscontainerspeicherräume 1520a bis 1520c auf der Speicherzuordnung, die von dem Plattformbetriebssystem 1506 empfangen wird, Daten speichern und schreiben. Der Container 1502 kann daher mit vertrauenswürdigen Standard-Speicherabschnitten durch die Basiscontainerspeicherräume 1520a bis 1520c versehen werden.
Im Gegensatz, falls die Funktion 1504 der Ursprung der Speicherzuordnungsanfrage ist, kann eine Speicherzuordnung basierend auf der dedizierten Funktionsspeicherauflistung 1526 bereitgestellt werden. Die Speicherzuordnung kann zum Beispiel eine Zuordnung eines Speicherbereichs sein, der von der dedizierten Funktionsspeicherauflistung 1526 identifiziert wird. Die Funktion 1504 kann folglich Daten zu den Funktionsspeicherräumen 1522a, 1522b speichern und schreiben.
Containerspezifische Daten des Containers 1502 und funktionsspezifische Daten, die nur von der Funktion 1504 verwendet werden, können daher in unterschiedlichen Basiscontainer- und Funktionsspeicherräumen 1520a bis 1520c, 1522a, 1522b gespeichert werden. Die containerspezifischen Daten können durch viele unterschiedliche Funktionen wiederverwendbar sein und können von der Funktion 1504 während der Ausführung der Funktion 1504 nicht abgeändert werden.
Sobald die Funktion 1504 endet, zum Beispiel durch Abschließende Ausführung oder durch Versagen, können die funktionsspezifischen Daten, die in den Funktionsspeicherräumen 1522a, 1522b gespeichert sind, gelöscht werden. Die containerspezifischen Daten, die in den Basiscontainerspeicherräume 1520a bis 1520c gespeichert sind, können nicht gelöscht werden, wenn die Funktion 1504 die Ausführung abschließt. Der Container 1502 bleibt als solcher, sogar wenn die Funktion 1504 endet und nicht mehr ausführt, in einem halbwarmen Zustand, zum Empfangen einer anderen Funktion zur Ausführung bereit. Das Abbauen des gesamten Containers 1502 kann daher durch eine Einschränkung der Daten, die gelöscht werden, wenn die Funktion 1504 endet, vermieden werden. Indem man die Funktion 1504 Daten nur zu den Funktionsspeicherräumen 1522a, 1522b speichern lässt, können nur Änderungen, die von der Funktion 1504 aus dem Zustand des Containers 1502 ausgeführt werden, entfernt werden, wodurch der Container 1502 in dem halbwarmen Zustand mit dem vertrauenswürdigen Code in den Basiscontainerspeicherräume 1520a bis 1520c gespeichert bleibt. Durch Einteilen der Daten in funktionsspezifische Daten und containerspezifische Daten und entsprechendes Speichern kann Löschen von Daten assoziiert mit der Funktion 1504 erleichtert werden, um die Sicherheit zu verbessern und die hohe Latenz von Container-Kaltstarts zu reduzieren.
Im Einzelnen können Aufwände für diverse Containertypen zum Beenden und Neustarten des Containers 1502 prohibitiv sein und die Latenz erhöhen. Falls zum Beispiel der Container 1502 für ein neuronales Netzwerk (zum Beispiel ein neuronales Faltungsnetzwerk oder tiefes neuronales Netzwerke) bestimmt ist, kann der Container 1502 kostspielig zu beenden und dann wieder hochzufahren sein. Das kann darauf zurückzuführen sein, dass ein neuronales Netzwerk eine signifikante Datenlast (zum Beispiel neuronale Gewichte und/oder konstante Werte) zum Betreiben beinhaltet. Eine solche Datenlast kann Teil des Containers 1502 sein, da die Datenlast von unterschiedlichen Funktionen wiederverwendet werden kann und durch die Funktionen nicht abgeändert werden kann. Falls daher die Funktion 1504 versagt, kann der Container 1502 zum Beenden gezwungen werden und wieder hochgefahren werden, was die Latenz steigert und die Effizienz reduziert.
Die Computing-Architektur 1500 kann den Beendigungsprozess der Funktion 1504 verbessern. Falls zum Beispiel die Funktion 1504 versagt, kann das Plattformbetriebssystem 1506 den Umfang der Daten, die beendet werden, einschränken. Das heißt, dass nur Daten, die in den Funktionsspeicherräumen 1522a, 1522b gespeichert sind, gelöscht oder freigegeben werden können. Folglich werden nur Änderungen, die von der Funktion 1504 ausgeführt werden, von dem Zustand des Containers 1502 entfernt, und das Abbauen des gesamten Containers 1502 wird vermieden. Wie veranschaulicht, stellt das Plattformbetriebssystem 1506 den Container 1502 mit der Fähigkeit, zwei unterschiedliche Sätze von Ressourcen zu führen, die Funktionsspeicherräume 1522a, 1522b beinhalten, die zugeordnet und für die Funktion 1504 zum Laufen in dem Container 1502 verwendet werden, und Basiscontainerspeicherräume 1520a bis 1520c bereit, die zugeordnet und für den Container 1502 selbst verwendet werden.
Ferner wird die Sicherheit verbessert, da sensible Daten der Funktion 1504 nachdem die Funktion 1504 endet, gelöscht werden. Die große sensiblen Daten, die für die Funktion 1504 besonders sind, können zum Beispiel aus den Funktionsspeicherräumen 1522a, 1522b gelöscht werden.
Das Plattformbetriebssystem 1506 kann in Verbindung mit einem Virtual Machine Monitors (nicht veranschaulicht) sowie einer Bibliothek arbeiten, die von einem oder mehreren der Container 1502 oder der Funktion 1504 verwendet werden. Eines mehrere des Plattformbetriebssystems 1506, des Virtual Machine Monitor und der Bibliothek können einen Mechanismus zum Bestimmen, ob ein Speicherzuordnungsaufruf (zum Beispiel malloc, calloc usw.) seinen Ursprung in einem Codebereich der als Teil des Containers 1502 auf der Weißliste steht, oder ein bekannter und validierter Ausführungskörper des Containers 1502 ist. Falls der Speicherzuordnungsaufruf seinen Ursprung in dem Codebereich der weißen Liste oder dem bekannten und validierten Körper des Containers 1502 nimmt, wird der Speicherzuordnungsaufruf mit einem Speicherbereich von den Basiscontainerspeicherräumen 1520a bis 1520c versehen. Anderenfalls wird standardmäßig angenommen, dass der Speicherzuordnungsaufruf von dem Code der Funktion 1504 ausgeht und erhält einen Speicherbereich von den Funktionsspeicherräumen 1522a, 1522b. Dedizierte Funktionsspeicherbereiche können als „pro-tem“-Bereiche betrachtet werden.
Falls es erforderlich ist, eine Reinigungs- oder Abbauschleife zum Beispiel als ein Resultat eines Segmentierungsverstoßes auszuführen, werden an Stelle des Abbauens der Basiscontainerspeicherräume 1520a bis 1520c nur die Funktionsspeicherräume 1522a, 1522b der Funktion 1502 abgebaut. Die dedizierte Containerspeicherauflistung 1524 kann zum Beispiel eine Liste aller zugeordneten Speicherräume, die von dem Container 1502 eingesetzt werden, beinhalten. Auf dieselbe Weise kann die dedizierte Funktionsspeicherauflistung 1526 eine Liste aller zugeordneten Speicherräume, die von der Funktion 1504 eingesetzt werden, beinhalten. Während des Reinigens können Speicherräume, die der Funktion 1504 zugeordnet sind, abgebaut und gelöscht werden, während die Speicherräume, die dem Container 1502 zugeordnet sind, unberührt bleiben.
Außerdem kann jeder Typ von Speicherzuordnungsaufruf, zum Beispiel ein Portable-Operating-System-Interface-Compliant-Unix-Systemaufruf (POSIX-Systemaufruf) (zum Beispiel mmap()-Aufruf) oder ein dynamischer Speicherzuordnungsaufruf (zum Beispiel malloc, calloc usw.) identifiziert und entsprechend, wie oben beschrieben, gelenkt werden. Falls zum Beispiel ein mmap()-Aufruf von der Funktion 1504 empfangen wird, können virtuelle Speicherbereiche, die für das Mapping beigestellt werden, basierend auf der dedizierten Funktionsspeicherauflistung 1526 bereitgestellt werden. Die dedizierte Funktionsspeicherauflistung 1526 kann daher eine Identifikation virtueller Speicherbereiche beinhalten. Folglich brauchen eventuell nur diese virtuellen Speicherbereiche und etwaige dazugehörende physische Speicherbereiche zurückgefordert zu werden.
Ferner können Dateideskriptoren ähnlich behandelt werden. Für einen „open()“-Befehl kann das Plattformbetriebssystem 1506 zum Beispiel zwei unterschiedliche Gruppen von Dateideskriptoren in der dedizierten Containerspeicherauflistung 1524 und der dedizierten Funktionsspeicherauflistung 1526 führen. Die Dateideskriptoren in der dedizierten Container Speicherauflistung 1524 und die dazu gehörenden Basiscontainerspeicherräume 1520a bis 1520c brauchen bei einer anormalen Bedingung oder dem Beenden der Funktion 1504 nicht beendet oder geschlossen zu werden (müssen eventuell aber reinitiiert, neu angelegt oder wieder geöffnet und reinitialisiert werden). Die Dateideskriptoren in der dedizierten Funktionsspeicherauflistung 1526 und die assoziierten Funktionsspeicherräume 1522a, 1522b können bei einer anormalen Bedingung oder Beenden der Funktion 1504 immer geschlossen werden.
Wenn die Funktion 1504 zum Beispiel aufgrund einer Falle endet, die von einem unzulässigen Befehl oder einem Segmentierungsverstoß verursacht wird, kann der Container 1502 die Reinigung für die Funktion 1504 ausführen, ohne dass der Container 1502 selbst zum Verlassen gezwungen ist. Wie oben angemerkt, können eines oder mehrere des Plattformbetriebssystems 1506, der Software-Bibliothek und des Virtual Machine Monitor das Abbauen der Funktion 1504 erleichtern.
Bei einigen Ausführungsformen können das Plattformbetriebssystem 1506 und/oder der Container 1502 den Container 1502 zusätzlich zu der Funktion 1504 abbauen. Die Basiscontainerspeicherräume 1520a bis 1520c können nämlich gelöscht werden, wenn identifiziert wird, dass der Container 1502 einen Fehler verursacht. Falls zum Beispiel eine Beendigungsbedingung (wie ein Fehler „unzulässiger Befehl“) als ein Resultat von Code auftritt, der von innerhalb eines Weißlisten-Körpers des Containers 1502 ausführt, sollte der Prozess oder der Container 1502 zusätzlich zu der Funktion 1504 abgebaut werden. Bei einigen Ausführungsformen kann der Container 1502 abgebaut werden, falls der Container 1502 von einer Funktion während einer vorbestimmten Zeitmenge nicht verwendet wird.
Bei einigen Ausführungsformen, wenn die Funktion 1504 vor Abschließen endet (zum Beispiel durch einen Fehler), kann ein spezieller Eingangspunkt in dem Container 1502 definiert werden. Der Eingangspunkt ist dort, wohin Ausführung gerichtet wird, nachdem die Funktion 1504 abgebaut wurde und die Funktionsspeicherräume 1522a, 1522b freigegeben wurden. Der Wiedereintrittspunkt kann ein Punkt sein, an dem der Container 1502 das Starten einer Funktion während eines Warmstarts ausführt. Der Wiedereintrittspunkt kann der Startpunkt sein, an dem der Container 1502 vollständig initialisiert hat und bereit ist, die Verarbeitung der Funktion 1504 zu beginnen. Das Richten zu diesem Wiedereintrittspunkt kann mit einem „longjmp-Aufruf“ zu diesem Startpunkt äquivalent sein.
Diverse Einstellungen können an Befehlen oder Bibliothekschnittstellen erfolgen, um die zweckdienliche Zuordnung und Freigabe zu erleichtern. Der „backtrace“-Befehl ist zum Beispiel gewöhnlich den Ursprung erforderlich, um diverser Zuordnungen zu bestimmen; kann aber vermieden werden, indem zwei unterschiedliche Eintrittspunkte für diverse Zuordnungen und „offene Aufrufe“ vorhanden sind. Ein Eintrittspunkt zum Beispiel nur mit Weißlisten-Code verknüpft, und der andere Eintrittspunkt ist ein Standard zum Codieren der Funktion 1504. Eine ähnliche Verzweigung von Befehlen kann für andere Typen von Beistellen von Aufrufen erfolgen, wie „mmap()“ (der virtuelle Bereiche bereitstellen soll), „open()“ (in der Dateideskriptoren, Socket() usw. zuordnet). Auf jedem Fall kann angenommen werden, dass der Weißlisten-Code mit Code verknüpft ist, der auf die normale Art zuordnet, während Nicht-Weißlisten-Code durch einen Pfad geht, der die Ressourcen in Funktionsspeicherräumen 1522a, 1522b über die dedizierte Funktionsspeicherauflistung 1526 absondert, oder der geöffnete Dateideskriptoren, Sockets usw. als Daten, die mit der Funktion 1504 assoziiert sind, die selbstständig bei einem Fehler freigegeben/selbstständig geschlossen werden muss, verfolgt.
Die verbesserte Computing-Architektur 1500 kann daher mehrere Verbesserungen beinhalten, einschließlich eingeschränkten Abbauens von Containern und eingeschränkter Initialisierung kalter Container, wodurch die Kosten verringert werden. Darüber hinaus kann die verbesserte Computing-Architektur 1500 die Effizienz des Einsatzes von Ressourcen verbessern, da weniger Bandbreite und Leistung eingesetzt werden, um Container abzubauen und neu anzulegen. Die verbesserte Computing-Architektur 1500 weist aufgrund schnellerer Startups der Container aus dem halbwarmen Zustand und weniger Aufwand von der Funktionsbeendigung und Fehlern weniger Latenz auf. Die Sicherheit kann auch verbessert werden, indem funktionsspezifische Daten aus den Funktionsspeicherräumen 1522a, 1522b entfernt werden.
15B zeigt ein Verfahren 1550 zur Speicherzuordnung für eine Funktion und einen Container und kann von dem Server 1302 der 13A ausgeführt werden, kann aber auch oder in Verbindung mit dem Server 1302 in dem verbesserten FaaS-System 400 der 4 und/oder einem oder mehreren Modulen als ein Satz logischer Anweisungen umgesetzt werden, der in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert ist; in konfigurierbarer Logik, wie zum Beispiel PLAs, FPGAs, CPLDs, gespeichert sind; in Hardwarelogik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer Kombination davon umgesetzt werden.
Computerprogrammcode zum Ausführen von Vorgängen, die in dem Verfahren 1550 gezeigt sind, können in einer beliebigen Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie die „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.), beinhalten.
Der veranschaulichte Verarbeitungsblock 1552 kann einen oder mehrere Containerspeicherräume einem Container widmen. Der veranschaulichte Verarbeitungsblock 1554 kann einen oder mehrere Funktionsspeicherräume einer Funktion, die mit dem Container verbunden ist, widmen. Der veranschaulichte Verarbeitungsblock 1556 kann eine Speicherzuordnungsanfrage empfangen. Der veranschaulichte Verarbeitungsblock 1558 kann bestimmen, ob die Speicherzuordnungsanfrage aus dem Container oder der Funktion hervorgeht. Der veranschaulichte Verarbeitungsblock 1560 kann eine Speicherzuordnung von dem einen oder den mehreren Containerspeicherräumen von dem einen oder den mehreren Funktionsspeicherräumen basierend darauf, ob die Speicherzuordnungsanfrage aus dem Container oder der Funktion hervorgeht, bereitstellen. Wenn die Speicherzuordnungsanfrage aus dem Container hervorgeht, kann die Speicherzuordnung aus dem einen oder den mehreren Containerspeicherräumen erfolgen. Im Gegensatz dazu, wenn die Speicherzuordnungsanfrage aus der Funktion hervorgeht, kann eine Speicherzuordnung aus dem einen oder den mehreren Funktionsspeicherräumen bereitgestellt werden.
Außerdem können nur Daten damit der Container arbeitet in dem einen oder den mehreren Containerspeicherräumen gespeichert werden. Darüber hinaus werden funktionsspezifische Daten nur in dem einen oder den mehreren Funktionsspeicherräumen gespeichert.
Der veranschaulichte Verarbeitungsblock 1562 kann als Reaktion auf eine Identifikation, dass die Funktion beendet ist, Freigeben von Speicher von dem einen oder den mehreren Funktionsspeicherräumen ohne Speicher von dem einen oder den mehreren Container-Funktionsspeicherräumen freigeben. Obwohl dies nicht veranschaulicht ist, kann das Verfahren ferner das Laden zur Ausführung einer anderen Funktion in den Container beinhalten. Die Verfahren 1550 kann daher mehrere Verbesserungen beinhalten, einschließlich eingeschränkten Abbauens von Containern und eingeschränkter Initialisierung kalter Container, wodurch die Kosten verringert werden. Darüber hinaus kann das Verfahren 1550 die Effizienz des Einsatzes von Ressourcen verbessern, da weniger Bandbreite und Leistung eingesetzt werden, um Container abzubauen und neu anzulegen. Das Verfahren 1550 kann aufgrund schnellerer Startups der Container aus dem halbwarmen Zustand und weniger Aufwand von der Funktionsbeendigung und Fehlern weniger Latenz aufweisen.
Zusätzliche Anmerkungen und Beispiele
Beispiel 1500 beinhaltet mindestens ein computerlesbares Medium, das einen Satz aus Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen oder mehrere Containerspeicherräume einem Container zu widmen und einen oder mehrere Funktionsspeicherräume einer Funktion, die mit dem Container verbunden ist, zu widmen, eine Speicherzuordnungsanfrage zu empfangen, zu bestimmen, ob die Speicherzuordnungsanfrage aus dem Container oder der Funktion hervorgeht, eine Speicherzuordnung von dem einen oder den mehreren Containerspeicherräumen in bereitzustellen, wenn die Speicherzuordnungsanfrage aus dem Container hervorgeht, eine Speicherzuordnung aus dem einen oder den mehreren Funktionsspeicherräumen bereitzustellen, wenn die Speicherzuordnungsanfrage aus der Funktion hervorgeht, und als Reaktion auf eine Identifikation, dass die Funktion beendet ist, Speicher aus dem einen oder den mehreren Funktionsspeicherräumen ohne Freigeben von Speicher aus dem einen oder mehreren Containerspeicherräumen freizugeben, wobei nur Daten für den Betrieb des Containers in dem einen oder den mehreren Containerspeicherräumen gespeichert werden, und funktionsspezifische Daten nur in dem einen oder den mehreren Funktionsspeicherräumen gespeichert werden, wobei der eine oder die mehreren Containerspeicherräume einen oder mehrere eines Dateideskriptors oder eines Socket-Deskriptors speichern sollen.
Beispiel 1501 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen oder mehrere Containerspeicherräume einem Container zu widmen, und einen oder mehrere Funktionsspeicherräume einer Funktion, die mit dem Container verbunden ist, zu widmen.
Beispiel 1502 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1501, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Speicherzuordnungsanfrage zu empfangen, zu bestimmen, ob die Speicherzuordnungsanfrage aus dem Container oder der Funktion hervorgeht, und eine Speicherzuordnung von dem einen oder den mehreren Containerspeicherräumen dem einen oder den mehreren Funktionsspeicherräumen basierend darauf, ob die Speicherzuordnungsanfragen aus dem Container oder der Funktion hervorgehen, bereitzustellen.
Beispiel 1503 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1502, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Speicherzuordnung aus dem einen oder den mehreren Containerspeicherräumen bereitzustellen, wenn die Speicherzuordnungsanfrage aus dem Container hervorgeht.
Beispiel 1504 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1502, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Speicherzuordnung aus dem einen oder den mehreren Funktionsspeicherräumen bereitzustellen, wenn die Speicherzuordnungsanfrage aus der Funktion hervorgeht.
Beispiel 1505 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1501, wobei nur Daten für den Betrieb des Containers in dem einen oder den mehreren Containerspeicherräumen gespeichert sind, und funktionsspezifische Daten nur in dem einen oder den mehreren Funktionsspeicherräumen gespeichert sind.
Beispiel 1506 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1501, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, als Reaktion auf eine Identifikation, dass die Funktion beendet ist, Speicher aus dem einen oder den mehreren Funktionsspeicherräumen ohne Freigeben von Speicher aus dem einen oder den mehreren Containerspeicherräumen freizugeben.
Beispiel 1507 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1506, wobei der eine oder die mehreren Containerspeicherräume einen oder mehrere eines Dateideskriptors oder eines Socket-Deskriptors speichern sollen.
Verteilung von Funktionen zu warmen und kalten Containern
Funktionen können eine willkürliche Verteilung auf warme und kalte Container aufweisen. Wie hierin bereits beschrieben, ist die Latenzzeit zum Initialisieren eines kalten Containers nicht unbedeutend. Funktionen, die zu kalten Containern verteilt werden, können daher eine höhere Latenz aufweisen, da der kalte Container initialisiert werden muss, indem er beliefert wird, und die Funktionen dann ausführen. Im Gegensatz dazu können Funktionen, die zu warmen Containern verteilt werden, eine niedrigere Latenz aufweisen, da die Initialisierung des kalten Containers vermieden werden kann.
Die Initialisierungslatenz eines kalten Containers kann durch viele Initialisierungsphasen und Faktoren verursacht werden. Ein Satz von Faktoren kann das Zuordnen und Konfigurieren von OS-Niveau-Ressourcen, wie Namensräumen für Ressourcen-IDs (zum Beispiel Prozess-IDs und Dateideskriptoren) und Steuergruppen zum Einschränken der Menge diverser Ressourcen (zum Beispiel CPU und Speicher), die einem Container zugeordnet werden, sein. Ein anderer Satz von Faktoren kann das Initialisieren der Inhalte des Containers, wie die Sprachenlaufzeit für verwaltete Sprachen, wie Java, sein. Das Starten der Funktion selbst auferlegt auch zusätzlichen Aufwand. Warme Container können eine Anzahl dieser Phasen im Voraus ausführen, um die Latenz des Aufrufens von Funktionen, die innerhalb warmer Container gehostet sind, zu reduzieren.
Herkömmliche Planung zieht Zeit, die für die Initialisierung kalter Container erforderlich ist, beim Verteilen von Funktionen oder wie Initialisierung kalter Container minimiert werden kann, nicht in Betracht. Darüber hinaus kann einiges Planen eine ineffiziente Verteilung von Funktionen auf warme und kalte Container aufweisen, was zu höherer Ressourcennutzung und Ausführung mit höherer Latenz führt.
Unter Bezugnahme auf 16A ist ein Beispiel 1600 gezeigt, bei dem Funktionsanforderungen 1604 durch Aufrufer und Batch-Ausgleicher 1606 eines FaaS-Systems, zum Beispiel des FaaS-Systems 400 der 4, geplant werden. Der Aufrufer und der Batch-Ausgleicher 1606 können eine batchweise Umsetzung umsetzen, um Latenz zu reduzieren und Ressourceneinsatz zu verbessern. Einige Ausführungsformen können zum Beispiel erste N batchfähige Funktionsanforderungen 1608a bis 1608n, die Ausführung einer batchfähigen Funktion anfordern, identifizieren. Die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n können miteinander gebatcht werden, so dass die batchfähigen Funktionen in demselben Container 1614a statt in unterschiedlichen Containern ausführen. Initialisierungen kalter Container können folglich durch die gebatchte Ausführung der batchfähigen Funktionen zum Reduzieren von Latenz und Einsetzen von weniger Containern reduziert werden.
Außerdem können der Aufrufer und der Batch-Ausgleicher 1606 Latenzauflagen besondere Funktionen, die mit den Funktionsanforderungen 1604 verbunden sind, identifizieren und die Funktionsanforderungen 1604 verteilen, um die Latenzauflagen zu erfüllen. Eine Latenzauflage kann einer angeforderten Zeit entsprechen, zu der die Funktion die Ausführung abschließen sollte. Funktionen mit kürzerer Latenz können gruppiert werden, wenn die Latenzauflagen es erlauben, und derart geordnet werden, dass alle der Latenzauflagen für jede Funktion in der Gruppe erfüllt werden. Die oben stehende Analyse kann insbesondere solche Situationen verbessern, bei welchen Programmcode von Funktionen hinsichtlich der Länge stark variiert. Eine solche Situation kann auftreten, wenn eine lange Funktion mit einer laxen Latenzauflage (zum Beispiel Auflage langer Latenz) und eine kurze Funktion mit einer knappen Latenzauflage (zum Beispiel Auflage kurzer Latenz) gemeinsam geplant werden. Das Planen der kurzen Funktion zuerst ermöglicht es, beide Latenzauflagen der langen und der kurzen Funktion zu erfüllen. Im Gegensatz dazu verursacht das Planen der langen Funktion zuerst, dass die Latenzanforderungen für die kurze Funktion nicht erfüllt werden.
Bei einigen Ausführungsformen wird eine Planungspolitik mit „früheste Frist zuerst“ verwendet, um eine machbare Planung zu erzeugen. Funktionen mit den kürzesten Latenzauflagen werden daher vor Funktionen mit längeren Latenzauflagen geplant. Bei einigen Ausführungsformen können ein alternatives Planungssystem wie „kürzester Job zuerst“ und Umsetzung (zum Beispiel Rundlaufverfahren) verwendet werden. Die kürzesten Funktionen werden somit vor längeren Funktionen ausgeführt und können im Rundlaufverfahren ausgeführt werden.
Bei einigen Ausführungsformen kann ein Hybridmodell aus „früheste Frist zuerst“ und „kürzester Job zuerst“ angenommen werden. Die Politik mit „kürzester Job zuerst“ kann zum Beispiel die kürzesten Funktionen zum Ausführen vor längeren Funktionen anordnen. Das System kann dann alle Funktionen analysieren (zum Beispiel Timings vorhersagen, die benötigt werden, um die Funktionen abzuschließen und die Timings mit den dazugehörenden Latenzauflagen vergleichen), um vorherzusagen, ob alle Latenzauflagen erfüllt werden. Ist das der Fall, kann das System die Funktionen gemäß der bestimmten Anordnung planen.
Falls die Latenzauflagen einiger der Funktionen nicht erfüllt werden, kann das System die Anordnung basierend auf der Politik „früheste Frist zuerst“ derart ändern, dass diejenigen Funktionen, deren Latenzauflagen nicht erfüllt werden, vor anderen Funktionen, deren Latenzauflagen erfüllt werden, ausgeführt werden. Als ein Beispiel werden zum Beispiel F₁, F₂, F₃ und F₄ gemäß der Politik „kürzester Job zuerst“ zum Ausführen in dieser Reihenfolge geplant. Falls identifiziert wird, dass F₂ und F₃ die Latenzauflagen nicht erfüllen werden, kann das System F₂, F₃ bewegen, um vor F₁, F₄ ausgeführt zu werden. Zum Bestimmen, F₂ oder F₃ zuerst ausgeführt wird, kann das System eine Politik „früheste Frist zuerst“ ausführen und bestimmen, dass F₃ die früheste Frist zwischen F₂, F₃ aufweist und vor F₂ geplant werden sollte. Die finale Reihenfolge würde wie folgt aussehen: F₃, F₂, F₁ und F₄
Bei einigen Ausführungsformen können historische Informationen wie die, die aus diversen Telemetriequellen (zum Beispiel Timer, die vorherige Funktionsausführungen zeitlich festgelegt haben), verwendet werden, um die Ausführungszeit für jede Funktion zu schätzen, was dabei helfen kann, das Planen der zukünftigen Aufrufe der Funktionen zu informieren. Weitere Einzelheiten stehen in der Besprechung der 24A und 41A. Einige Ausführungsformen können auch bestimmen, ob eine Initialisierung eines kalten Containers erforderlich sein wird, um die batchfähigen Funktionen zu verarbeiten, und, falls dies der Fall ist, eine Latenzzeit für Initialisierungen eines kalten Containers in Betracht ziehen, wenn identifiziert wird, ob die Latenzauflagen erfüllt werden.
Einige Ausführungsformen können daher Initialisierungen kalter Container einschränken, während sie eine effektivere Verteilung von Funktionen zum Reduzieren von Ressourcennutzung aufweisen. Es kann zum Beispiel ressourceneffizienter sein, wenn mehrere Funktionen innerhalb desselben Containers ausgeführt werden, statt mehrere neue kalte Container zu initialisieren, um die Funktionen auszuführen. Es kann offensichtlich sein, dass andere als die erste Funktion gebatchte Funktionen bei einem seriellen Ausführungsmodell darauf warten müssen, dass vorhergehende gebatchte Funktionen abgeschlossen werden, was die Latenz in Zusammenhang mit der Annahme eines unendlichen Parallelismusmodells, bei dem keine Funktion in einem dedizierten Container auf das Enden irgendeiner anderen Funktion zu warten braucht, steigern kann. Trotzdem können die Gesamtlatenz der gebatchten Funktionen und sogar die Latenz für Funktionen, die nicht die erste Funktion sind, in der Tat niedriger sein, sobald Limits des Parallelismus in Betracht gezogen und die Reduktion der Initialisierungszeit berücksichtigt werden. Einige Ausführungsformen können daher niedrigere Latenz aufgrund verbesserter Nutzung warmer Container aufweisen, sogar falls Funktionen gebatcht werden. Parallele Ausführung mehrerer Funktionen in einem einzigen Container kann Latenz weiter reduzieren.
Außerdem, wie oben angemerkt, kann das Ressourcenmanagement verbessert werden. Warme Container können zum Beispiel nach einer bestimmten Ruhezeitmenge abgebaut werden. Ruhezeit kann Zeit sein, während der die warmen Container keine Funktion verarbeiten. Indem warme Container öfter im Laufe einer gebatchten Umsetzung, wie hierin beschrieben, eingesetzt werden, können Ausführungsformen weniger häufige Initialisierungen kalter Container und weniger häufiges Abbauen warmer Container darlegen, da die warmen Container häufiger verwendet werden. Ferner können einige Ausführungsformen weniger Instanzen identischer Container, die Ressourcen verbrauchen, aufweisen. Statt zum Beispiel einen Container für jede Funktion zu haben, kann ein Container mehrere Funktionen bedienen. Ausführungsformen verbessern daher die Effizienz und setzen weniger Ressourcen ein, um Kosten zu reduzieren. Sogar falls die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n folglich in plötzlichen und seltenen Bursts auftreten, können Latenzpenalties vermieden werden und dem verbesserten FaaS-System mehr Kontrolle über das Aufbauen und Abbauen von Containern erlauben.
Außerdem können Lastausgleichskosten reduziert werden. Individuelles Planen jede Funktion durch einen Orchestrator kann zum Beispiel umfangreichere Rechenressourcen im Gegensatz zum Planen eines Batch von Funktionen gemeinsam erfordern. Darüber hinaus können Messaging-Aufwände reduziert werden, aber da individuelle Meldungen eventuell nicht für jede Funktionsanforderung gesendet werden, wird stattdessen eine gebatchte Funktionsanforderungsmeldung, die alle der ersten N gebatchten Funktionsanforderungen 1608a bis 1608n beinhalten, übertragen werden.
Wie in dem Beispiel 1600 veranschaulicht, werden Funktionsanforderungen 1604 von dem Aufrufer und Batch-Ausgleicher 1606 eines FaaS-Systems, zum Beispiel des FaaS-System 400 der 4, geplant. Der Aufrufer und der Batch-Ausgleicher 1606 können Teil des Orchestrators 404 sein oder in Verbindung mit dem Orchestrator 404 arbeiten.
Wie in 16A veranschaulicht, kann ein Ereignisverarbeitungs-API-Proxy 1602 Ereignisaufrufe zu Funktionen, die mit den Funktionsanforderungen 1604 verbunden sind, routen. Bei dem Beispiel 1600 kann der Ereignisverarbeitungs-API-Proxy 1602 Funktionsanforderungen 1604 zum Beispiel über eine API erzeugen. Die Funktionsanforderungen 1604 können zu dem Aufrufer und Batch-Ausgleicher 1606 bereitgestellt werden. Die Funktionsanforderungen 1606 können jeweils eine Anfrage um Ausführung einer jeweiligen Funktion sein.
Der Aufrufer und der Batch-Ausgleicher 1606 können die Funktionsanforderungen 1604 analysieren, um zu identifizieren, ob die 1604 gebatcht werden können. Im Einzelnen können der Aufrufer und der Batch-Ausgleicher 1606 bestimmen, ob die Funktionen der Funktionsanforderungen 1604 in demselben Container der Container 1614a bis 1614c ausgeführt werden können. Das Ansammeln von Anfragen kann zugelassen werden, außer wenn eine starke Latenzauflage besteht, und dann können sie als ein Batch zu einem verfügbaren warmen Container oder zu einem neuen kalten Container je nachdem gesendet werden, wie viel Workload in einem Batch enthalten ist. Solches optionales Batching, Lastausgleichen, Aufrufen und Ausführen von Aktionen wird daher in einer entkoppelten Art (zum Beispiel zweistufigen Art) ausgeführt, wenn Aktionen ausgelöst werden. Funktionen, die in demselben Container der Container 1614a bis 1614c ausgeführt werden können, können gebatcht werden. Bei einigen Ausführungsformen können der Aufrufer und der Batch-Ausgleicher 1606 bestimmen, dass identische Funktionen miteinander batchfähig sind. Ferner können der Aufrufer und der Batch-Ausgleicher 1606 bestimmen, dass nicht identische Funktionen batchfähig sind, falls diese nicht identischen Funktionen auf demselben der Container 1614a bis 1614c ausgeführt werden können.
Der Aufrufer und der Batch-Ausgleicher 1606 können nicht batchfähige Funktionsanforderungen 1610, 1612 aus den Funktionsanforderungen 1604 identifizieren. Die nicht-batchfähige Funktionsanforderung 1610, 1612 kann nicht-batchfähige Funktionen anfordern, die mit anderen Funktionen nicht gruppiert werden können, und dafür als nicht-batchfähig gelten. Die nicht-batchfähige Funktionsanforderungen 1610, 1612 können individuell zu Containern 1614b, 1614c gesendet werden. Die nicht-batchfähigen Funktionen können nämlich in separaten Containern 1614b, 1614c ausgeführt werden. Die Container 1614b, 1614c können warm oder kalt sein, wobei Priorität den nicht-batchfähigen Funktionsanforderungen der nicht-batchfähigen Funktionsanforderungen 1614b, 1614c, die eine stärkste Latenzauflage aufweisen, eingeräumt wird.
Wie veranschaulicht, können der Aufrufer und der Batch-Ausgleicher 1606 die ersten N batchfähige Funktionsanforderungen 1608a bis 1608n aus den Funktionsanforderungen 1604 identifizieren. Wie beschrieben, kann jede der ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n eine Funktion (die als eine „batchfähige Funktion“ bezeichnet werden kann), die dazu konfiguriert ist, innerhalb desselben Containers ausgeführt zu werden, aufrufen. Die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n können folglich zu dem Container 1614a gesendet werden. Die batchfähigen Funktionen können innerhalb des Containers 1614a ausgeführt werden. Die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n können eine beliebige Anzahl, die größer ist als eins, von Funktionsanforderungen beinhalten.
Bei einigen Ausführungsformen können die batchfähigen Funktionen, die mit den ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n verbunden sind, gleichzeitig in dem Container 1614a ausgeführt werden, falls der Container 1614a ausreichend Ressourcen zum Unterstützen einer solchen gleichzeitigen Ausführung aufweist. Der Aufrufer und der Batch-Ausgleicher 1606 können zum Beispiel Ressourcenanforderungen jeder der batchfähigen Funktionen bestimmen, und können bestimmen, ob der Container 1614a Zugriff auf ausreichende Ressourcen (zum Beispiel CPU und Speicher) zum Erfüllen aller Ressourcenanforderungen gleichzeitig aufweist. Ist das der Fall, kann gleichzeitige Ausführung geplant werden. Ist das nicht der Fall, kann gleichzeitige Ausführung nicht unterstützt werden, und die batchfähigen Funktionen können seriell ausgeführt werden (eine nach der anderen).
Bei einigen Ausführungsformen können der Aufrufer und der Batch-Ausgleicher 1606 Sicherheitsprotokolle der batchfähigen Funktionen bestimmen. Falls ein Sicherheitsprotokoll angibt, dass eine bestimmte batchfähige Funktion eine besondere Sicherheitsauflage (zum Beispiel hohe Sicherheit) aufweist, kann die besondere batchfähige Funktion für nicht gleichzeitige Ausführung in dem Container 1614a geplant werden und einen beschränkten Abbau des Containers 1614a ausführen, bei dem nur Daten der besonderen batchfähigen Funktion entfernt werden, während die Daten des Containers 1614a beibehalten werden, wie unter Bezugnahme auf die 15A-15B und die oben dazugehörende Beschreibung beschrieben.
Bei einigen Ausführungsformen können einige der batchfähigen Funktionen gleichzeitig ausgeführt werden, und andere der batchfähigen Funktionen können seriell ausgeführt werden. Bei einigen Ausführungsformen kann der Container 1614a eine erste Gruppe batchfähiger Funktionen ausführen, zum Beispiel eine maximale Anzahl batchfähiger Funktionen, die von den Ressourcen des Containers 1614a unterstützt wird. Nach der vollständigen Ausführung der ersten Gruppe, kann eine zweite Gruppe batchfähiger Funktionen Ausführung beginnen, zum Beispiel eine maximale Anzahl batchfähiger Funktionen, die von den Ressourcen des Containers 1614a unterstützt wird. Der Aufrufer und der Batch-Ausgleicher 1606 können daher eine hybride serielle und parallele Ausführung der batchfähigen Funktionen in dem Container 1614a basierend auf Sicherheitsprotokollen und Ressourcenverfügbarkeit des Containers 1614a in Bezug auf Ressourcenanforderungen der Funktionen planen.
Bei einigen Ausführungsformen kann der Container 1614a partitionierte Arbeitsräume beinhalten, um batchfähige Funktionen, die parallel ausgeführt werden, zu trennen. Jede Funktion kann in einer unterschiedlichen Partition ausgeführt werden. Alle Partitionen können Zugriff auf gemeinsame Daten besitzen, die von beliebigen der batchfähigen Funktionen eingesetzt werden. Die Partitionen können separate Speicherräume aufweisen, um Daten zu wahren, die für eine Funktion speziell sind. Jede Partition kann somit Daten, die von der Funktion erzeugt werden, in dem separaten Speicherraum speichern, während sie auf gemeinsame Daten, die von den Funktionen verwendet werden, zugreift. Nachdem eine Funktion die Ausführung in einer Partition abgeschlossen hat, können Daten aus dem entsprechenden getrennten Speicherraum zu einem anderen Datenspeicher gespeichert werden (falls nötig), und der getrennte Speicherraum wird gelöscht, um die Partition auf eine andere Funktion vorzubereiten. Die gemeinsamen Daten können jedoch nicht durch die Funktionen während der Ausführung geändert werden, und sind durch jede Funktion, die in dem Container 1614a ausgeführt wird, wiederverwendbar.
Bei einigen Ausführungsformen können der Aufrufer und der Batch-Ausgleicher 1606 die Funktionsanforderungen 1604 sammeln. Die Funktionsanforderungen 1604 können zum Beispiel jeweils zu einer unterschiedlichen Zeit zu dem Aufrufer und dem Batch-Ausgleicher 1606 gesendet werden. Der Aufrufer und der Batch-Ausgleicher 1606 können das Ansammeln der Funktionsanforderungen 1604 während einer Zeitspanne erlauben. Der Aufrufer und der Batch-Ausgleicher 1606 planen nämlich eventuell die Funktionsanforderungen 1604 nicht sofort, wenn sie empfangen werden. Stattdessen können der Aufrufer und der Batch-Ausgleicher 1606 warten, bevor sie die Funktionsanforderungen 1604 planen. Das kann es dem Aufrufer und der Batch-Ausgleicher 1606 erlauben, eine Anzahl potenziell batchfähiger Funktionsanforderungen 1604 zu empfangen und sie dann basierend darauf, ob die Funktionsanforderungen 1604 miteinander batchfähig sind, planen.
Bei einigen Ausführungsformen können der Aufrufer und der Batch-Ausgleicher 1606 eine Latenzauflage jeder der Funktionsanforderungen 1604 bestimmen und eine dazugehörende Funktion entsprechend planen. Die nicht-batchfähige Funktionsanforderung 1610 kann zum Beispiel eine starke Latenzauflage aufweisen. Die nicht-batchfähige Funktionsanforderung 1610 muss nämlich geplant werden, um eine entsprechende Funktion sofort aufgrund einer dazugehörigen Latenzauflage auszuführen. Die Latenzauflage kann ein Zahlenwert und/oder eine absolute Zeit sein. Die Latenzauflage kann angeben, dass die dazugehörende Funktion der nicht-batchfähigen Funktionsanforderung 1610 innerhalb eines kurzen Zeitrahmens abgeschlossen werden muss. Daher kann die nicht-batchfähige Funktionsanforderung 1610 dazu geplant werden, innerhalb des Containers 1614b, der ein warmer Container sein kann, ausgeführt zu werden.
Bei einigen Ausführungsformen, falls die Latenzauflagen einer Funktionsanforderung der Funktionsanforderungen 1604 einen nicht-batchfähigen Schwellenwert erfüllt, kann die Funktionsanforderung automatisch als nicht-batchfähig klassifiziert werden, um zeitgerechte Ausführung sicherzustellen. Falls die Latenzauflage zum Beispiel angibt, dass die Funktion in weniger als einer vorbestimmten Zeitmenge abgeschlossen werden muss, kann die entsprechende Funktionsanforderung sofort geplant werden, ohne andere batchfähige Funktionen zum Batchen mit der entsprechenden Funktionsanforderung zu identifizieren.
Bei einigen Ausführungsformen können der Aufrufer und der Batch-Ausgleicher 1606 ferner die Latenzauflagen jeder der ersten N batchfähigen Funktionsanforderung in 1608a bis 1608n bestimmen. Der Aufrufer und der Batch-Ausgleicher 1606 können warten, um die ersten N batchfähigen Funktionsanforderung 1608a bis 1608n basierend auf der stärksten Latenzauflage der ersten N batchfähigen Funktionsanforderung in 1608a bis 1608n, die bisher empfangen wurden, zu planen.
Der Aufrufer und der Batch-Ausgleicher 1606 können zum Beispiel aus den Latenzauflagen einen Zeitrahmen jeder jeweiligen Funktion der ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n zum Abschließen der Ausführung bestimmen. Der Zeitrahmen kann einem vorbestimmten Zeitfenster entsprechen, während dem die jeweilige batchfähige Funktion die Ausführung abschließen sollte. Ein kürzester Zeitrahmen aus den Zeitrahmen kann bestimmt werden. Der Aufrufer und der Batch-Ausgleicher 1606 können die ersten N batchfähigen Funktionsanforderung in 1608a bis 1608n zu dem Container 1614a senden, um den kürzesten Zeitrahmen zu erfüllen. Der Aufrufer und der Batch-Ausgleicher 1606 können zum Beispiel die ersten N batchfähigen Funktionsanforderung in 1608a bis 1608n zu dem Container 1614a zu einer ersten Zeit senden, um sicherzustellen, dass die Funktion, die den kürzesten Zeitrahmen aufweist, innerhalb des kürzesten Zeitrahmens abgeschlossen wird. Der Aufrufer und der Batch-Ausgleicher 1606 können jedoch das Empfangen und Ansammeln der Funktionsanforderungen 1604 bis zum Erreichen der ersten Zeit fortsetzen. Der Aufrufer und der Batch-Ausgleicher 1606 können daher während einer Zeitspanne vor dem Senden der ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n zu dem Container 1614a warten und die Latenzauflagen einhalten.
Bei einigen Ausführungsformen können der Aufrufer und Batch-Ausgleicher 1606 ein Timing zum Beginnen der Ausführung einer besonderen Funktion zum Einhalten der Latenzauflage bestimmen. Der Aufrufer und Batch-Ausgleicher 1606 können eine projizierte Gesamtlatenz bestimmen, die zum Abschließen der Ausführung der besonderen Funktion benötigt wird. Die projizierte Gesamtlatenz kann die Zeit, die erforderlich ist, um einen kalten Container zu initialisieren, Zeit, die der Aufrufer und Batch-Ausgleicher 1606 bereits mit Ansammeln von Funktionsanforderungen 1604 verbracht haben, Latenzen von Funktionen, deren Ausführung in einem Container vor der besonderen Funktion geplant ist, Kommunikationslatenzen und/oder eine Latenz der besonderen Funktion zum Abschließen der Ausführung in dem Container beinhalten. Die folgenden Gleichung 1600 kann verwendet werden, um basierend auf einem Vergleich der projizierten Gesamtlatenz und einer akzeptablen Latenz zu bestimmen, ob die Latenzauflagen einer besonderen Funktion erfüllt wird: $Lwait + LCCL + LF + LC \leq Laccept$
In der obigen Gleichung 1600, ist L_wait die Zeitspanne, in der der Aufrufer und Batch-Ausgleicher 1606 die besondere Funktionsanforderung der besonderen Funktion angesammelt hat. L_wait kann zum Beispiel der Unterschied zwischen der aktuellen Zeit und einer Zeit, in der die besondere Funktionsanforderung empfangen wurde, sein. L_CCL ist die Zeit, die zum Initialisieren eines kalten Containers benötigt wird. Falls ein warmer Container als verwendbar identifiziert wird, kann L_CCL auf null gestellt werden. L_F ist eine Summierung einer projizierten Ausführungslatenz jeder Funktion, die zum Ausführen vor der besonderen Funktion geplant ist, sowie eine Latenz, die für das Abschließen der Ausführung der besonderen Funktion projiziert wird. L_F kann daher eine Gesamtfunktionsausführungslatenzschätzung sein. L_C ist die Kommunikationslatenz zum Senden der ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n zu dem Container 1614a. L_accept kann aus der Latenzauflage bestimmt werden und kann eine akzeptable Gesamtlatenz der besonderen Funktion sein. L_accept kann zum Beispiel ein Schwellenwert sein, der von einem Service-Provider oder einem Client auferlegt wird, und kann die Gesamtzeit sein, innerhalb der das Abschließen der Ausführung der Funktion erwartet wird. Falls die Funktion die Ausführung mit einer Latenz gleich oder kleiner als L_accept abschließt, kann die Funktion als zeitgerecht abgeschlossen betrachtet werden. Die Latenzauflage kann als erfüllt betrachtet werden, falls Obiges wahr ist, oder falls L_accept größer oder gleich einer Summierung von L_wait, L_CCL, L_C und L_F ist. Bei einigen Ausführungsformen können der Aufrufer und Batch-Ausgleicher 1606 die Latenzauflage nur als erfüllt betrachten, falls L_accept um eine vorbestimmte Menge größer ist als die Summierung.
Basierend auf der obigen Gleichung 1600, können der Aufrufer und Batch-Ausgleicher 1606 eine Startzeit zum Beginnen der Ausführung der besonderen Funktion bestimmen. Der Aufrufer und Batch-Ausgleicher 1606 können ferner eine Übertragungszeit zum Übertragen der ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n bestimmen, um das Starttiming zu erfüllen. Der Aufrufer und Batch-Ausgleicher 1606 können zum Beispiel statistische Werte bestimmen, wie L_CCL und L_C, und die dynamischen Latenzen wie L_wait und L_F einstellen, indem sie das Timing (Übertragungszeit), in dem die ersten N batchfähigen Funktionsanforderungen 1608a-1608n zu dem Container 1614a gesendet werden, und eine Reihenfolge der batchfähigen Funktionsausführungen in dem Container 1614a steuern.
Bei einigen Ausführungsformen können der Aufrufer und der Batch-Ausgleicher 1606 die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n zu dem Container 1614a als Reaktion darauf senden, dass eine besondere Anzahl der ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n angesammelt ist. Der Container 1614a kann fähig sein, gleichzeitige Ausführung einer unterstützten Anzahl von Funktionen zu unterstützen. Wenn daher die Anzahl von Funktionen der ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n die unterstützte Anzahl erreicht, können die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n zu dem Container 1614a gesendet werden, um Ausführung zu beginnen. Bei einigen Ausführungsformen können die Funktionen gleichzeitig auf unabhängigen Software-Threads innerhalb des Containers 1614a arbeiten und folglich können die Funktionen parallel ausgeführt werden. Bei einigen Ausführungsformen kann die Funktion in Teilzeitmodus auf den verfügbaren Threads ausgeführt werden.
Bei dem obigen Beispiel können daher die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n zu unterschiedlichen Zeiten von dem Aufrufer und Batch-Ausgleicher 1606 empfangen und angesammelt werden. Der Aufrufer und der Batch-Ausgleicher 1606 können die ersten N batchfähigen Funktionsanforderung in 1608a bis 1608n als ein Batch zu dem Container 1614a, der warm oder kalt sein kann, senden. Der Aufrufer und Batch-Ausgleicher 1606 können den Batch je nachdem planen, wie viel Arbeit in den Batch sein kann, und um die dazugehörenden Latenzauflagen zu erfüllen. Daher kann unter einem solchen Batching-System, Lastausgleichen, Aufrufen und Ausführen von Funktionen in einer entkoppelten Art (zum Beispiel zweistufigen Art) ausgeführt werden, wenn Aktionen ausgelöst werden.
Bei einigen Ausführungsformen können die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n von dem Aufrufer und Batch-Ausgleicher gemäß den Latenzauflagen 1606 in zwei oder mehr Gruppen eingeteilt werden. Die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n können zum Beispiel derart eingeteilt werden, dass eine erste Gruppe die stärksten Latenzauflagen aufweist, eine zweite Gruppe die nächststärksten Latenzauflagen aufweist und so fort.
Die gleichzeitige Ausführung der zwei oder mehreren Gruppen mit zwei oder mehreren Containern kann auftreten, um Latenz zu reduzieren. Falls nicht ausreichend warme Container für die zwei oder mehr Gruppen vorhanden sind, können bei einigen Ausführungsformen die warmen Container gemäß Latenzauflagen zugewiesen werden. Gruppen, die die stärksten Latenzauflagen (kürzesten Zeitfenster zur Ausführung) aufweisen, können zum Beispiel zu den warmen Containern gesendet werden, während Gruppen, die schwächere Latenzauflagen (längere Zeitfenster zur Ausführung) aufweisen, zu kalten Containern gesendet werden können. Eine Identifikation kann zum Beispiel auf den Latenzanforderungen der ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n erfolgen. Die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n können gemäß den Latenzauflagen derart gruppiert werden, dass Funktionen, die die kürzesten Zeitfenster zum Abschließen der Ausführung aufweisen, in warmen Containern ausgeführt werden. Im Gegensatz können Funktionen, die längere Zeitfenster zum Abschließen der Ausführung aufweisen, gruppiert werden, um die Ausführung in kalten Containern abzuschließen.
Bei einigen Ausführungsformen können die Gruppen zum Ausführen einen nach dem anderen in demselben Container 1614a geplant werden. Die Gruppen, die die stärksten Latenzauflagen aufweisen, können zum Ausführen vor den Gruppen, die die schwächeren Latenzauflagen aufweisen geplant werden.
Ferner können bei einigen Ausführungsformen der Aufrufer und Batch-Ausgleicher 1606 als grobe Abfertigung aus dem Frontende der FaaS-Infrastruktur zu dem Backend zum Planen von Batches von Funktionen arbeiten. An dem Backend können die ersten N batchfähigen Funktionsanforderungen 1608a bis 1608n zum Beispiel zu dem Container 1614a, in dem die dazugehörenden Funktionen auf eine normale Art ausgeführt werden, gegeben werden. Im Gegensatz dazu kann kommerzielle, hochvolumische Verwendung von FaaS mehr Ressourcen zum Ausführen von Lastausgleich, Containerzuweisungen und Transportvorgängen (die alle reiner Aufwand sein können) auf einem individuellen Funktionsanforderungsplanungssystem basieren.
Darüber hinaus kann das gebatchte Planungssystem, das hierin beschrieben ist, das Verhältnis von kalten zu warmen Containern automatisch reduzieren. Im Einzelnen ist ein kalter Container nur für die erste Aktion (zum Beispiel eine Funktion) in dem Batch kalt, und ist für die restlichen Aktionen in dem Batch warm. Ferner werden weniger kalte Container gebaut, um die Funktionen unterzubringen, was das Verhältnis von kalten zu warmen Containern reduziert. Wie oben festgehalten, kann eine Funktion nicht für mehr als eine Schwellendauer basierend auf der Latenzauflage verzögert werden, und wird in diesem Punkt ungeachtet des Batch, in dem sich die Funktion befindet, zur Ausführung gepusht.
Unter Bezugnahme auf 16B kann eine Ausführungsform eines Halbleiter-Packagegeräts 1620 ein oder mehrere Substrate 1624 und Logik 1622, die mit dem einen oder den mehreren Substraten 1624 gekoppelt ist, beinhalten, wobei die Logik 1622 mindestens teilweise in einer oder mehreren von konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist. Die Logik 1622, die mit dem einen oder den mehreren Substraten 1624 gekoppelt ist, kann dazu konfiguriert sein, eine Vielzahl von Funktionsanforderungen zu empfangen, die jeweils die Ausführung einer jeweiligen Funktion anfordern, und batchfähige Funktionsanforderungen aus der Vielzahl von Funktionsanforderungen zu bestimmen. Bei einigen Ausführungsformen kann die Logik 1622 dazu konfiguriert sein, die batchfähige Funktionsanforderungen zu demselben Container zu senden. Die Logik 1622 kann zum Beispiel dazu konfiguriert sein zu bestimmen, dass derselbe Container warm ist, und als Reaktion auf eine Bestimmung, dass der Container warm ist, bestimmen, dass die batchfähigen Funktionsanforderungen zu demselben Container zu senden sind. Bei einigen Ausführungsformen kann die Logik 1622, die mit dem einen oder den mehreren Substraten 1624 gekoppelt ist, Transistorkanalbereiche beinhalten, die innerhalb des einen oder der mehreren Substrate 1624 positioniert sind.
Ausführungsformen der Logik 1622 und anderer Bauelemente des Geräts 1620 können in Hardware, Software oder einer beliebigen Kombination davon, einschließlich mindestens einer teilweisen Umsetzung in Hardware, umgesetzt werden. Die Hardware-Umsetzungen können zum Beispiel konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Zusätzlich können Abschnitte dieser Bauelemente in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Gerät 1620 kann einen oder mehrere Aspekte der Verfahren 1650, 1670 und 1690 (16C, 16D und 16E) oder eine beliebige der Ausführungsformen, die hierin besprochen sind, umsetzen. Bei einigen Ausführungsformen kann das veranschaulichte Gerät 1620 das eine oder die mehreren Substrate 1624 (zum Beispiel Silizium, Saphir, Galliumarsenid) und die Logik 1622 (zum Beispiel Transistor-Array und andere Bauelemente integrierter Schaltungen/IC) gekoppelt mit dem/den Substrat(en) 1624 beinhalten. Die Logik 1622 kann mindestens teilweise in konfigurierbare Logik oder Hardware-Logik mit feststehender Funktionalität umgesetzt werden. Bei einem Beispiel kann die Logik 1622 Transistorkanalbereiche beinhalten, die innerhalb des/der Substrate 1624 positioniert (zum Beispiel eingebettet) sind. Die Schnittstelle zwischen der Logik 1622 und dem/den Substraten 1624 ist daher eventuell kein abrupter Übergang. Die Logik 1622 kann als auch eine epitaktische Schicht, die auf einem anfänglichen Wafer des Substrats/der Substrate 1624 aufgewachsen wird, beinhaltend und betrachtet werden 16C zeigt ein Verfahren 1650 zum Batchen von Funktionsanforderungen und kann von dem Server 1302 der 13A ausgeführt werden, kann aber auch oder in Verbindung mit dem Server 1302 in dem verbesserten FaaS-System 400 der 4 und/oder einem oder mehreren Modulen als ein Satz logischer Anweisungen umgesetzt werden, der in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert ist, konfigurierbarer Logik, wie zum Beispiel PLAs, FPGAs, CPLDs, gespeichert sind; in Hardwarelogik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer Kombination davon umgesetzt werden.
Computerprogrammcode zum Ausführen von Vorgängen, die in dem Verfahren 1650 gezeigt sind, können in einer beliebigen Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie die „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Der veranschaulichte Verarbeitungsblock 1652 kann eine Vielzahl von Funktionsanforderungen, die jeweils die Ausführung einer jeweiligen Funktion anfordern, empfangen. Der veranschaulichte Verarbeitungsblock 1654 kann batchfähige Funktionsanforderungen aus der Vielzahl von Funktionsanforderungen bestimmen. Der veranschaulichte Verarbeitungsblock 1656 kann die batchfähigen Funktionsanforderungen zu demselben Container senden. Der veranschaulichte Verarbeitungsblock 1656 kann ferner bestimmen, dass derselbe Container warm ist, und kann bestimmen, dass die batchfähigen Funktionsanforderungen zu demselben Container basierend darauf, dass derselbe Container warm ist, gesendet werden sollen.
Der veranschaulichte Verarbeitungsblock 1658 kann eine oder mehrere nicht-batchfähige Funktionsanfragen aus der Vielzahl von Funktionsanfragen, die nicht batchfähig sind, bestimmen. Der veranschaulichte Verarbeitungsblock 1660 kann jede der einen oder der mehreren nicht-batchfähigen Funktionsanforderungen zu einem unterschiedlichen Container senden.
16D zeigt ein Verfahren 1670 zum Batchen von zwei oder mehreren Funktionsanforderungen und kann von dem Server 1302 der 13A ausgeführt werden, kann aber auch oder in Verbindung mit dem Server 1302 in dem verbesserten FaaS-System 400 der 4 und/oder einem oder mehreren Modulen als ein Satz logischer Anweisungen umgesetzt werden, der in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert ist, konfigurierbarer Logik, wie zum Beispiel PLAs, FPGAs, CPLDs, gespeichert sind; in Hardwarelogik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 1672 kann eine erste batchfähige Funktionsanforderung empfangen. Der veranschaulichte Verarbeitungsblock 1674 kann bestimmen, dass die erste batchfähige Funktionsanforderung gebatcht werden soll. Der veranschaulichte Verarbeitungsblock 1676 kann warten, bis eine zweite batchfähige Funktionsanforderung empfangen wird. Die erste batchfähige Funktionsanforderung wird eventuell nämlich nicht sofort zu einem Container zur Ausführung gesendet und/oder geplant. Stattdessen kann das Verfahren 1670 auf das Empfangen anderer Funktionsanforderungen warten, um Funktionsanforderungen effektiv miteinander zur Ausführung vor der Planung zu batchen. Der veranschaulichte Verarbeitungsblock 1678 kann bestimmen, dass die erste und die zweite batchfähige Funktionsanforderung miteinander batchfähig sind. Der veranschaulichte Verarbeitungsblock 1680 kann eine oder mehrere Latenzauflagen der ersten und zweiten batchfähigen Funktionsanforderung bestimmen. Wie hierin bereits beschrieben, kann die Latenzauflage eine angeforderte Zeit widerspiegeln, zu der Funktionen, die von der ersten und zweiten batchfähigen Funktionsanforderung aufgerufen werden, die Ausführung abschließen sollten. Der veranschaulichte Verarbeitungsblock 1682 kann auf der einen oder den mehreren Latenzauflagen eine Übertragungszeit zum Senden der ersten und der zweiten batchfähigen Funktionsanforderung zu demselben Container bestimmen. Im Einzelnen kann die Übertragungszeit sicherstellen, dass die erste und die zweite batchfähige Funktionsanforderung der einen oder den mehreren Latenzauflagen entsprechen oder die Ausführung zu der angeforderten Zeit abschließen. Der veranschaulichte Verarbeitungsblock 1684 kann die erste und die zweite batchfähige Funktionsanforderung zu demselben Container in dem Übertragungszeitpunkt senden.
Bei einigen Ausführungsformen können die veranschaulichten Verarbeitungsblöcke 1680, 1682 gleichzeitig mit oder vor einem oder mehreren der veranschaulichten Verarbeitungsblöcke 1674, 1676, 1678 auftreten. Die Latenzauflage der ersten batchfähigen Funktionsanforderung kann zum Beispiel gleichzeitig mit Block 1674 identifiziert werden. Ferner kann der veranschaulichte Verarbeitungsblock 1674 basierend auf der Latenzauflage der ersten batchfähigen Funktionsanforderung bestimmen, dass die erste batchfähige Funktionsanforderung nicht dringend ist, und kann auf andere Funktionsanforderungen warten. Darüber hinaus kann der veranschaulichte Verarbeitungsblock 1676 auf die anderen Funktionen während einer Zeitspanne warten, die mit der Latenzauflage der ersten batchfähigen Funktionsanforderung übereinstimmt.
16E zeigt ein Verfahren 1690 zum Planen einer Funktionsanforderung, um mit einer Latenzauflage wie übereinzustimmen und kann von dem Server 1302 der 13A ausgeführt werden, kann aber auch oder in Verbindung mit dem Server 1302 in dem verbesserten FaaS-System 400 der 4 und/oder einem oder mehreren Modulen als ein Satz logischer Anweisungen umgesetzt werden, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., konfigurierbarer Logik, wie zum Beispiel PLAs, FPGAs, CPLDs, gespeichert sind; in Hardwarelogik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 1692 empfängt eine Funktionsanforderung. Ein Orchestrator kann zum Beispiel die Funktionsanforderung empfangen und die Funktionsanforderung planen. Der veranschaulichte Verarbeitungsblock 1694 kann eine Latenzauflage der Funktionsanforderung bestimmen. Wie oben beschrieben, kann die Latenzauflage eine akzeptable Gesamtlatenz für eine Funktion, die von der Funktionsanforderung aufgerufen wird, widerspiegeln. Die Latenzauflage kann ein Zahlenmaß (zum Beispiel 5 ms) und/oder eine absolute Zeit (zum Beispiel 2:48 EST), die ein bevorzugtes Abschluss-Timing der Funktion widerspiegelt, sein. Bei einigen Ausführungsformen kann die Latenzauflage von einer anderen Funktionsanforderung abhängig sein. Die Funktion kann zum Beispiel auf Daten aus einer anderen Funktion arbeiten, und die Latenzauflage kann folglich widerspiegeln, dass die Funktion die Ausführung innerhalb einer vorbestimmten Zeitmenge eines Abschließens der anderen Funktion abschließt. Bei einigen Ausführungsformen kann die Latenzauflage widerspiegeln, dass die Funktion der Funktionsanforderung so bald wie möglich ohne Warten auf Batching ausgeführt wird.
Der veranschaulichte Verarbeitungsprozess 1696 kann die Funktionsanforderung zu einem Container senden, um mit der Latenzauflage übereinzustimmen. Die Funktionsanforderung kann mit anderen Funktionsanforderungen gebatcht werden. Die Funktionsanforderung und die anderen Funktionsanforderungen können daher zu dem Container gesendet werden. Bei einigen Ausführungsformen kann die Funktionsanforderung eventuell nicht gebatcht werden, falls die Funktionsanforderungen einen Container nicht gemeinsam verwenden kann oder die Latenzauflage keine Zeit für das Batching genehmigt.
Zusätzliche Anmerkungen und Beispiele
Beispiel 1600 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Vielzahl von Funktionsanforderungen zu empfangen, die jeweils die Ausführung einer jeweiligen Funktion anfordern, eine Vielzahl batchfähiger Funktionsanforderungen aus der Vielzahl von Funktionsanforderungen zu bestimmen, eine erste batchfähige Funktionsanforderung aus der Vielzahl batchfähiger Funktionsanforderungen zu empfangen, zu bestimmen, dass die erste batchfähige Funktionsanforderung zu batchen ist, zu warten, bis eine zweite batchfähige Funktionsanforderung von der Vielzahl batchfähiger Funktionsanforderungen empfangen wird, zu bestimmen, dass die erste und die zweite batchfähige Funktionsanforderung miteinander basierend auf einer oder mehreren Latenzauflagen, einer Zeit zum Senden der ersten und der zweiten batchfähigen Funktionsanfrage zu demselben Container gebatcht werden sollen, die Vielzahl batchfähiger Funktionsanforderungen zu demselben Container zu der bestimmten Zeit zu senden, bestimmen, dass derselbe Container warm ist, zu bestimmen, dass die Vielzahl batchfähiger Funktionsanforderungen zu demselben Container basierend darauf, dass derselbe Container warm ist, gesendet werden soll, zu bestimmen, dass eine oder mehrere nicht-batchfähige Funktionsanforderungen aus der Vielzahl von Funktionsanforderungsaufrufen, die nicht-batchfähig sind, und jede der einen oder der mehreren nicht batchfähigen Funktionsanforderungen zu einem unterschiedlichen Container gesandt werden sollen, wobei die Funktionen der batchfähigen Funktionsanforderung seriell parallel oder in einem hybriden seriellen und parallelen System ausgeführt werden sollen.
Beispiel 1601 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Vielzahl von Funktionsanforderungen, die jeweils die Ausführung einer jeweiligen Funktion anfordern, zu empfangen, und eine Vielzahl batchfähiger Funktionsanforderungen aus der Vielzahl von Funktionsanforderungen zu bestimmen.
Beispiel 1602 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1601, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Vielzahl batchfähiger Funktionsanforderungen zu demselben Container zu senden.
Beispiel 1603 beinhaltet mindestens ein computerlesbares Medium des Beispiels 1602, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, zu bestimmen, dass derselbe Container warm ist, und bestimmen, dass die Vielzahl batchfähiger Funktionsanforderungen zu demselben Container basierend darauf, dass derselbe Container warm ist, gesendet werden soll.
Beispiel 1604 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1601, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine erste batchfähige Funktionsanforderung von der Vielzahl batchfähiger Funktionsanforderungen zu empfangen, zu bestimmen, dass die erste batchfähige Funktionsanforderung gebatcht werden soll, zu warten, bis eine zweite batchfähige Funktionsanforderung aus der Vielzahl von Funktionsanforderungen empfangen wird, und zu bestimmen, dass die erste und die zweite batchfähige Funktionsanforderung miteinander gebatcht werden sollen.
Beispiel 1605 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1604, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine oder mehrere Latenzauflagen der ersten und der zweiten batchfähigen Funktionsanforderung zu bestimmen, basierend auf der einen oder den mehreren Latenzauflagen eine Zeit zum Senden der ersten und der zweiten batchfähigen Funktionsanforderung zu demselben Container zu bestimmen und die erste und die zweite batchfähige Funktionsanforderung zu demselben Container zu der bestimmten Zeit zu senden.
Beispiel 1606 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1601, das ferner einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine oder mehrere nicht-batchfähige Funktionsanforderung aus der Vielzahl von Funktionsanforderungsaufrufen, die nicht-batchfähiger sind, zu bestimmen und jede der einen oder mehreren nicht batchfähigen Funktionsanforderungen zu einem unterschiedlichen Container zu senden.
Beispiel 1607 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1601, wobei die Funktionen der batchfähigen Funktionsanforderungen seriell, parallel oder in einem hybriden seriellen und parallelen System ausgeführt werden sollen.
Umsetzung einer redundanten Funktion
Unter Bezugnahme auf 17A ist ein Beispiel der Umsetzung redundanter Funktionen 1700 gezeigt, bei dem eine Funktionsanforderung 1710 durch einen Orchestrator 1704 eines FaaS-Systems, zum Beispiel des FaaS-Systems 400 der 4, verarbeitet wird.
In einigen Fällen kann eine Funktion aufgrund vieler Faktoren (zum Beispiel Abstürzen des Rechenknotens) das Timeout erreichen und nie abschließen. Beim Auslösen kann zum Beispiel eine Originalfunktion 1712 durch eine Reihe von Vorgängen (zum Beispiel Authentifizierung, Zulassung, Vorstart-Ressourcenverfügbarkeit usw.) durchgehen, in der ein Orchestrator 1704 der Originalfunktion 1712 einen Rechenknoten 1706c identifizieren und zuweisen kann. Unterschiedliche Plattformen können jedoch eindeutige Merkmale (zum Beispiel Virtualisierungsschicht usw.) und Ressourcen aufweisen, die für einen Client des FaaS-Service unbekannt und undurchsichtig sind, die die Originalfunktion 1712 angefordert haben. Die Originalfunktion 1712 kann zum Beispiel zur Ausführung auf einen warmen Container eines Rechenknoten 1706a mit ausreichend nicht abonnierten Ressourcen geraten, um zeitgerechte Ausführungen zu erleichtern. In anderen Fällen kann die Originalfunktion 1712 einen kalten Container des Rechenknoten 1706a ausführen, der auch auf einer geschäftigen Plattform ohne ausreichende Ressourcen zum Erleichtern der Ausführung läuft. Darüber hinaus kann die Originalfunktion 1712 ferner andere Services, deren Performance auch variabel ist, verbrauchen. Als ein Resultat kann bestimmte Gewissheit darüber bestehen, dass die Originalfunktion 1712 tatsächlich zur Ausführung fortschreiten wird, die Ausführung abschließen wird, und dass die Originalfunktion 1712 ferner auf zeitgerechte Art abschließen wird.
Die Originalfunktion 1712 kann nicht ausgesendet werden, falls die Originalfunktion 1712 verfügbare Ressourcen überschreitet (zum Beispiel dynamische Einschränkungen auf Speicher). Ferner kann die Originalfunktion 1712 eventuell nicht auf eine zeitgerechte Art ausgesandt werden oder, sobald sie ausgesandt ist, kann es unklar sein, ob die Originalfunktion 1712 die Ausführung innerhalb des zugelassenen Zeitlimits abschließen wird.
In einigen Fällen kann die Originalfunktion 1712 abschließen, aber mehrere serielle erneute Versuche erfordern. Die Originalfunktion 1712 kann daher mehrmals nacheinander erneut hervorgebracht werden, bis die Originalfunktion 1712 schließlich abschließt. Solche seriellen erneuten Versuche an dem Client sind sowohl teuer als auch schwierig, um Abschließen sicherzustellen, da der Client keine Kontrolle über die Faktoren, die in Erfolg oder Scheitern resultieren, haben kann. Das Testen auf erfolgreichen Ausgang und erneute Versuchen gestaltet auch das Programmieren an dem Anforderer kompliziert.
Einige Funktionen können als eine hohe Erfolgsanforderung aufweisend gelten und folglich kann ein Risiko des Nicht-Abschließens oder verzögerten Abschließens inakzeptabel sein. Wie unten besprochen, kann der Orchestrator 1704 die Möglichkeit des Nicht-Abschließens oder verzögerten Abschließens durch Ausführung redundanter Funktion über mehrere Rechenknoten 1706a bis 1706c mindern. Redundante Funktionen 1708a, 1708b der Originalfunktion 1712 können hervorgebracht und auf unterschiedlichen Knoten 1706a, 1706b ausgeführt werden.
Wie in 17A veranschaulicht, kann der Ereignisverarbeitungs-API-Proxy 1702 Ereignisabrufe zu Funktionen routen. Bei dem Beispiel 1700 kann der Ereignisverarbeitungs-API-Proxy 1702 eine Funktionsanfrage 1710 zum Beispiel über eine API erzeugen. Der Funktionsanforderungsaufruf 1710 kann zu dem Orchestrator 1704 bereitgestellt werden. Die Funktionsanforderung 1710 kann eine Anforderung um Ausführen der Originalfunktion 1712 sein. Der Orchestrator 1704 kann die Funktionsanforderung 1710 analysieren. Im Einzelnen kann der Orchestrator 1704 bestimmen, ob die redundante Funktionsausführungen bereitgestellt wird. Eine solche Bestimmung kann darauf basieren, ob die Originalfunktion 1712 einen Qualitätsschwellenwert erfüllt. Der Qualitätsschwellenwert kann auf einer Benutzeranforderung (zum Beispiel einem Token, einer Klasse usw.), Dienstgüte-Metriken (QoS-Metriken) oder einem Service-Level-Vertrag basieren.
Bei dem Beispiel der 17A kann der Orchestrator 1704 bestimmen, dass die Originalfunktion 1712 den Qualitätsschwellenwert erfüllt, und dass folglich die Möglichkeit des Nicht-Abschließens oder unzeitmäßigen Abschließens der Originalfunktion 1712 durch ein System mit Ausführung redundanter Funktion gemindert werden soll. Das System mit Ausführung redundanter Funktion kann das Entstehen redundanter Funktionen 1708a, 1708b beinhalten. Bei einem Beispiel kann jede der redundanten Funktionen 1708a, 1708b eine identische Kopie der Originalfunktion 1712 sein, Umsetzungen der Originalfunktion 1712 können jedoch optional für langsamere aber garantierte Ausführung bei 1708a, 1708b spezifiziert werden usw. Das kann zum Beispiel durch Verwenden unterschiedlicher Iterationsstrategien, einschließlich vorhersagende, proaktive und reaktive Maßnahmen, basierend auf verfügbaren Niveaus dynamischen Einsatzes von Ressourcen, die für die Ausführung einer garantierten Funktion kritisch sind. Zum Beispiel kann eine 128-MB-Funktion auf einem Container laufen, dem 256 MB RAM bereitgestellt sind. Funktion könnte auf einem Container mit 256 MB RAM beigestellt laufen. Als ein anderes Beispiel könnte eine Funktion mit einem längeren Timeout laufen.
Wie veranschaulicht, können die Originalfunktion 1712 und die redundante Funktionen 1708a, 1708b zu unterschiedlichen Rechenknoten 1706a bis 1706c bereitgestellt werden. Die Möglichkeit eines Funktion-Timeout oder eines Nicht-Abschlusses kann folglich gemindert werden. Es besteht daher eine verbesserte Zuverlässigkeit durch eine gesteigerte Wahrscheinlichkeit, dass eine der redundanten Funktionen 1708a, 1708b und der Originalfunktion 1712 innerhalb einer vorbestimmten Zeitmenge erfolgreich abgeschlossen wird.
Sobald eine der Originalfunktion 1712 und der redundanten Funktionen 1708a, 1708b die Ausführung abschließt, kann der Orchestrator 1704 oder ein anderer Mechanismus die Ausführung der nicht ausgeführten der Originalfunktion 1712 und der redundanten Funktionen 1708a, 1708b stornieren. Die Ressourcen können daher effizient durch die Stornierung gemanagt werden.
Bei einigen Ausführungsformen kann die Funktionsanforderung 1710 ein Feld beinhalten, das spezifiziert, ob eine Funktion garantiert werden soll. Ein Benutzer, wie ein Client der FaaS-Architektur, kann daher in der Lage sein zu spezifizieren, wenn eine Funktion garantiert werden soll. Bei einigen Ausführungsformen kann der Orchestrator 1704 eine Weißliste der Funktionen, die garantiert werden, beinhalten und mehrere Kopien dieser Funktionen während der Ausführung erzeugen.
Bei einigen Ausführungsformen können die redundante Funktionen 1708a, 1708b nicht überlagerte Ausführungen mit der Originalfunktion 1712 aufweisen. Der Rechenknoten 1706c kann zum Beispiel einen Fortschrittsbericht der Ausführung der Originalfunktion 1712 bereitstellen. Der Fortschrittsbericht kann eine Anzahl abgeschlossener Vorgänge, eine aktuell ausgeführte Codelinie der Originalfunktion 1712 usw. angeben. Falls der Fortschrittsbericht angibt, dass die Originalfunktion 1712 verzögert wird oder ein Timeout auftreten kann, kann der Orchestrator 1704 die redundante Funktionen 1708a, 1708b eine Zeit, nachdem die Originalfunktion 1712 die Ausführung begonnen hat, anlegen.
Bei einigen Ausführungsformen kann der Orchestrator 1704 eine Ressourcenanforderungen bestimmen, die eventuell für die Ausführung der Originalfunktion 1712 benötigt werden kann. Der Orchestrator 1704 kann die Ressourcenanforderungen basierend auf verfügbaren Messungen dynamischen Einsatzes von Ressourcen bestimmen. Bei einigen Ausführungsformen können historische Informationen wie die, die aus diversen Telemetriequellen, zum Beispiel von Timern oder Debug-Logs und Performance-Monitoren gesammelt werden, verwendet werden, um die Ausführungszeit und/oder Ressourcenanforderungen für jede Funktion zu schätzen, was dann verwendet werden kann, um die Planung zukünftiger Aufrufe von Funktionen zu informieren. Weitere Einzelheiten stehen in der Besprechung der 24A und 41A. Der Orchestrator 1704 kann basierend auf der Ressourcenanforderung bestimmen, ob die redundanten Funktionen 1708a, 1708b zu erzeugen sind. Die redundanten Funktionen 1708a, 1708b können zum Beispiel als Reaktion auf eine Identifikation, dass es dem Rechenknoten 1706c eventuell an ausreichenden Ressourcen mangelt, oder dass er die Ressourcenanforderungen zum Abschließen der Ausführung der Originalfunktion 1712 nicht erfüllen kann, erzeugt werden. Wenn er ursprünglich geplant wird, kann der Rechenknoten 1706c zum Beispiel ausreichend Ressourcen aufweisen, um die Originalfunktion 1712 auszuführen.
Falls der Rechenknoten 1706c sich jedoch hinsichtlich der Ressourcen verschlechtert, kann es dem Rechenknoten 1706c an ausreichend Ressourcen zum Ausführen der Originalfunktion 1712 mangeln. Falls der Rechenknoten 1706 zum Beispiel aufgrund von Überhitzen drosseln muss oder dem Rechenknoten 1706c eine neuere Funktion mit höherer Priorität zugewiesen wird, die zu einer Neuzuordnung von Ressourcen zwingt, können die verfügbaren Ressourcen für die Ausführung für die Originalfunktion 1712 geringer werden. Bei einigen Ausführungsformen kann eine Identifikation erfolgen, dass die Originalfunktion 1712 eine spezifische Menge an Ressourcen erfordern wird, die einen Schwellenwert überschreitet, und dass sie folglich auf einem bestimmten Server, wie dem Rechenknoten 1706c, schwierig aufrechtzuerhalten sein kann. Bei einigen Ausführungsformen kann jede der Originalfunktion 1712 und der redundanten Funktionen 1708a, 1708b von dem Orchestrator 1704 geplant werden, um Ausführung zur gleichen Zeit beginnen. Die Originalfunktion 1712 und die redundanten Funktionen 1708a, 1708b können zum Beispiel geplant werden, um als Reaktion auf eine Identifikation, dass die Originalfunktion 1712 den Qualitätsschwellenwert erfüllt, ausgeführt zu werden, um die Ausführung in etwa zur selben Zeit oder so früh wie möglich für jede der Originalfunktion 1712 und der redundanten Funktionen 1708a, 1708b zu beginnen. Die redundanten Funktionen 1708a, 1708b und die Originalfunktion 1712 können überlappende Ausführungszeiten aufweisen.
Bei einigen Ausführungsformen können die redundanten Funktionen 1708a, 1708b dazu geplant, nur ausgeführt zu werden, falls die Originalfunktion 1712 die Ausführung nicht abschließen kann. Der Orchestrator 1704 kann zum Beispiel bestimmen, dass die Funktion 1712 beim Abschließen versagt hat, und den Qualitätsschwellenwert erfüllt. Der Orchestrator 1704 kann folglich bestimmen, dass die mehreren redundanten Kopien der Originalfunktion 1712 als redundante Funktionen 1708a, 1708b erzeugt werden sollten, um ein zweites Auftreten des Nicht-Abschließens zu mindern.
Außerdem kann der API-Proxy 1702 oder der Orchestrator 1704 die Bedeutung der Originalfunktion 1712 basierend auf spezifizierten Parametern identifizieren. Die spezifizierten Parameter können von einem Administrator oder einem Kunden eingestellt werden, der unterschiedliche Typen von Iterationsstrategien für unterschiedliche Funktionen spezifiziert, um einen Gewissheitgrad zu erhalten. Wie oben beschrieben, können solche Strategien vorhersagende, proaktive und reaktive Maßnahmen basierend auf verfügbaren Maßnahmen dynamischen Einsatzes von Ressourcen, die für die Ausführung der Originalfunktion 1712 benötigt werden, basieren. Sobald die Originalfunktion 1712 bis zum Abschließen läuft, kann der Orchestrator 1704 die redundante Funktion 1708a, 1708b ungeachtet der Ausführungsstufe, in der sich die redundante Funktion 1708a, 1708b befindet, stornieren, aufgeben oder killen. Der Orchestrator 1704 kann folglich die FaaS-Funktionsumsetzung durch Mindern der Möglichkeit, dass Funktionen versagen, und durch Sicherstellen, dass eine Funktion in einer zeitgerechten Art ausgeführt wird, verbessern.
17B zeigt ein Verfahren 1750 redundanter FaaS-Funktionsumsetzung und kann von dem Server 1302 der 13A ausgeführt werden, kann aber auch oder in Verbindung mit dem Server 1302 in dem verbesserten FaaS-System 400 der 4 und/oder einem dem Orchestrator 1704 der 17A und/oder einem oder mehreren Modulen als ein Satz logischer Anweisungen umgesetzt werden, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, konfigurierbarer Logik, wie zum Beispiel PLAs, FPGAs, CPLDs; in Hardwarelogik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 1752 kann einen Funktionsanforderungsaufruf zum Ausführen einer Originalfunktion empfangen. Der Funktionsanforderungsaufruf kann zum Beispiel aus einer Anwendung oder einer Benutzervorrichtung hervorgehen. Der veranschaulichte Verarbeitungsblock 1754 kann bestimmen, ob die Originalfunktion einen Qualitätsschwellenwert erfüllt. Falls nicht, kann nur die Originalfunktion ausgeführt werden. Die redundanten Funktionen können daher nicht erzeugt werden. Ist das jedoch der Fall, kann der veranschaulichte Verarbeitungsblock 1756 bestimmen, dass eine oder mehrere redundante Funktionen gemeinsam mit der Originalfunktion auszuführen sind. Jede der einen oder der mehreren redundanten Kopien kann eine identische Kopie der Originalfunktion sein. Der veranschaulichte Verarbeitungsblock 1756 kann das Ausführen der Originalfunktion und der einen oder mehreren redundanten Kopien an überlappenden Zeiten an unterschiedlichen Rechenknoten beinhalten. Ferner kann der veranschaulichte Verarbeitungsblock 1756 ferner das Beginnen der Ausführung der Originalfunktion zu einer ersten Zeit und das Beginnen der Ausführung der einen oder der mehreren redundanten Kopien zu einer zweiten Zeit nach der ersten Zeit beinhalten. Bei einigen Ausführungsformen können die Originalfunktion und die eine oder die mehreren redundanten Kopien zu nicht überlappenden Zeiten ausgeführt werden. Bei einigen Ausführungsformen können die eine oder die mehreren redundanten Kopien die Ausführung als Reaktion auf eine Identifikation, dass die Originalfunktion beim Erfüllen einer oder mehrerer eines Fortschrittsschwellenwerts oder einer Ressourcenanforderung scheitert, beginnen.
Zusätzliche Anmerkungen und Beispiele
Beispiel 1700 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen Funktionsanforderungsaufruf zum Ausführen einer Originalfunktion zu empfangen, zu bestimmen, ob die Originalfunktion einen Qualitätsschwellenwert erfüllt, als Reaktion darauf, dass die Originalfunktion Qualitätsschwellenwert erfüllt, bestimmen, dass eine oder mehrere redundante Funktionen der Originalfunktion gemeinsam mit der Originalfunktion ausgeführt werden sollen, wobei jede der einen oder mehreren redundanten Funktionen eine Kopie der Originalfunktion ist, die Originalfunktion und die eine oder die mehreren redundanten Funktionen zu überlappenden Zeiten ausführen, die Originalfunktion und die eine oder die mehreren redundanten Funktionen an unterschiedlichen Rechenknoten ausführen, die Ausführung der Originalfunktion in einem ersten Zeitpunkt beginnen und die Ausführung der einen oder der mehreren redundanten Funktionen in einem zweiten Zeitpunkt nach dem ersten Zeitpunkt beginnen, und die Ausführung der einen oder der mehreren redundanten Funktionen als Reaktion auf eine Identifikation, dass die Originalfunktion beim Erfüllen eines Fortschrittschwellenwerts oder einer Ressourcenanforderung scheitert, beginnen.
Beispiel 1701 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen Funktionsanforderungsaufruf zum Ausführen einer Originalfunktion zu empfangen, zu bestimmen, ob die Originalfunktion einen Qualitätsschwellenwert erfüllt, und als Reaktion darauf, dass die Originalfunktion den Validitätsschwellenwert erfüllt, zu bestimmen, dass eine oder mehrere redundante Funktionen gemeinsam mit der Originalfunktion ausgeführt werden sollen, wobei jede der einen oder der mehreren redundanten Funktionen eine Kopie der Originalfunktion ist.
Beispiel 1702 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1701, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die die Originalfunktion und die eine oder die mehreren redundanten Funktionen zu überlappenden Zeiten auszuführen.
Beispiel 1703 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1701, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die die Originalfunktion und die eine oder die mehreren redundanten Funktionen an unterschiedlichen Rechenknoten auszuführen.
Beispiel 1704 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1701, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Ausführung der Originalfunktion zu einer ersten Zeit zu beginnen, und die Ausführung der einen oder der mehreren redundanten Funktionen zu einer zweiten Zeit nach der ersten Zeit zu beginnen.
Beispiel 1705 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1701, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Ausführung der einen oder der mehreren redundanten Funktionen als Reaktion auf eine Identifikation, dass die Originalfunktion beim Erfüllen eines Fortschrittsschwellenwerts oder einer Ressourcenanforderung scheitert, zu beginnen.
Iterative Ausführung von FaaS- und/oder AFaaS-Funktionen
Einige Aufgaben können iterative Ausführung von FaaS und/oder AFaaS-Funktionen auslösen. Während FaaS unten referenziert ist, versteht man, dass AFaaS-Funktionen ähnlich ausgeführt werden können.
FaaS-Funktionen können unterschiedliche Problemräume oder Problembereiche erforschen. Eine Angebotsabstimmungsaufgabe kann zum Beispiel diverse Kombinationen der Angebote erforschen, um eines zu finden, das die günstigsten Bedingungen aufweist. Die diversen Kombinationen können durch iterative FaaS-Funktionen erforscht werden. Als ein Beispiel kann eine FaaS-Funktion zum Beispiel benötigen, wiederholt zu iterieren, um einen Angebotsabstimmungsprozess auszuführen. Falls der Wortlaut eines Angebots zum Beispiel eine Klausel enthält, die eine Abänderung des Angebots erfordert oder um andere Angebote zu überbieten, benötigen eine oder mehrere Funktionen eventuell iteratives Arbeiten. Als ein anderes Beispiel kann bei Edge-Services mit aktivierter künstlicher Intelligenz eine Folgerung nicht als eine Lösung identifiziert werden, bis die Folgerung mit einer Vertrauensmetrik, die in ein akzeptables Risikokriterium fällt, aufweist.
In einigen Fällen kann iterative Ausführung unterstützt werden, indem die Iterationssteuerung dynamisch skriptfähig oder variabel gemacht wird, um die diversen dynamischen Bedingungen, die oben beschrieben sind, nachzuweisen, da die Bedingungen für das Abschließen einer iterativen Aufgabe wahrscheinlich dynamisch spezifiziert werden sollen. Die FaaS-Funktionen arbeiten daher in bestimmten Kontexten iterativ mit einer dynamischen Steuerung. Iterative FaaS-Funktionen können jedoch manchmal unnötig weiterarbeiten, ohne die dynamischen Bedingungen zum Abschließen zu erreichen. Nehmen wir zum Beispiel an, dass zwei Suchräume vorliegen, die jeweils von unterschiedlichen FaaS-erforscht werden. Nach einer bestimmten Zeit kann es offensichtlich werden, dass eine der FaaS-Funktionen einen Suchunterraum erforscht, der wahrscheinlich keine durchführbare Lösung ergeben wird. Wenn man eine solche FaaS-Funktion unnötig arbeiten lässt, ist das ineffizient, weil die FaaS-Funktions-Ressourcen verbraucht, die anderen FaaS-Funktionen, die mit mehr Wahrscheinlichkeit eine durchführbare Lösung ergeben werden, zugeordnet werden können. Darüber hinaus erreicht die FaaS-Funktion eventuell keine Abschlussbedingungen (zum Beispiel eine durchführbare Lösung) und arbeitet weiter, bis die Zeit erreicht ist. Die Latenz wird folglich erhöht, und die Ressourcen werden ineffizient zugeordnet.
Ein Suchraum kann ein durchführbarer Bereich von Lösungen oder Antworten sein, über die ein Suchsystem oder eine Suchvorgehensweise nach möglichen Lösungen oder Antworten, die die Suchkriterien erfüllen, erforschen kann. Ein Suchraum kann zum Beispiel verwendet werden, um eine Gesamtsammlung von Möglichkeiten, Parametern, Algorithmen, Systemen, Wert- oder Zugriff- oder Zeitauflagen, über die die Suchvorgänge als durchführbar betrachtet werden können, zu beschreiben. Bei einem besonderen Beispiel, für einen Supercomputer, der Schach spielt, kann der Suchraum sehr groß sein, aber für ein Programm, das auf einem Laptop oder einem Tablett-Computer, die von der Cloud getrennt sind, läuft, kann der Suchraum hinsichtlich der Bewertungstiefe, Zeit zum Bewerten oder der Anzahl alternativer Züge usw. eingeschränkt werden. Während ein Suchraum oben referenziert wird, wird ein „Lösungsraum“, in dem ein Suchraum ein Beispiel eines Lösungsraums ist, unten referenziert. Ein Lösungsraum kann ein Raum sein, in dem eine Lösung identifiziert werden soll ist.
Unter Bezugnahme auf die 18A und 18B wird ein verbesserter Scheduler 1820 bereitgestellt, um eine Funktionserzeugungsgrafik 1800 für FaaS-Service zu erzeugen. Der verbesserte Scheduler 1820 kann Ressourcenzuordnungen zu Lösungsräumen der Funktionserzeugungsgrafik 1800 basierend auf Bedingungen, die erfüllt werden, stornieren oder erneut priorisieren, zum Beispiel eine Wahrscheinlichkeit, dass ein Lösungsraum (zum Beispiel ein besonderer Satz von Forschungen) wahrscheinlich keine durchführbare Lösung ergeben wird. Das kann Ressourcenzuordnungen verbessern und ein Timing zum Finden einer Lösung aus einem Raum durchführbare Lösungen, die durchführbar und nahezu optimal ist, zu finden.
18A veranschaulicht eine Funktionserzeugungsgrafik 1800. Der Scheduler 1820 (wie in 18B gezeigt) kann diverse Hardware- und Softwareumsetzungen beinhalten, die die Funktionsgrafik 1800 erzeugen und die diversen Planungs-, Stornierungs- und Neupriorisierungs-Meta-Aufgaben für das Ausführen der Funktionsgrafik 1800 zum Finden einer ausreichend wertvollen Lösung umsetzen. Der Scheduler 1820 kann zum Beispiel ein Branch-and-Bound-Vorgang sein, der unter Verwenden von Thread-Bildungsblöcken gebildet wird; oder kann ein SQL-Abfrageoptimierer usw. sein. Eine Aufgabe 1812 kann eine Funktion A 1802, eine Funktion B 1804, eine Funktion C 1806, eine Funktion D 1808 und eine Funktion E 1810 erzeugen. Die Funktion A 1802, die Funktion B 1804, die Funktion C 1806, die Funktion D 1808 und die Funktion E 1810 können gemeinsam in der folgenden Beschreibung der Kürze halber als „erzeugte Funktionen“ bezeichnet werden.
Die Funktionserzeugungsgrafik 1800 ist eine Datendarstellung einer Planung mit erzeugten Funktionen, die parallel oder seriell arbeiten. Die erzeugten Funktionen können disparate aber verwandte Funktionen sein. Die Funktion C 1806 kann von Daten der Funktion A 1802 zum Ausführen abhängen und ist folglich von Funktion A 1802 abhängig. Die Funktion A 1802 und die Funktion C 1806 können als solche als eine erste Verzweigung 1814 der Funktionserzeugungsgrafik 1800 betrachtet werden. Die Funktion D 1808 kann von Daten der Funktion B 1804 zum Ausführen abhängen und ist folglich von Funktion B abhängig. Die Funktion B 1804 und die Funktion D 1808 können als eine dritte Verzweigung 1818 der Funktionserzeugungsgrafik 1800 betrachtet werden. Die Funktion E 1810 benötigt zum Arbeiten eventuell keine Daten von einer anderen Funktion. Die Funktion E 1810 kann als eine zweite Verzweigung 1816 der Funktionserzeugungsgrafik 1800 betrachtet werden. Jede der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 kann mindestens eine iterative Funktion beinhalten und als ein separater Lösungsraum und/oder eine Erforschungsmöglichkeit für eine potenzielle Lösung oder ein potenzielles Ergebnis betrachtet werden. Um als abgeschlossen betrachtet zu werden, kann die Aufgabe 1812 nur die bestmögliche Lösung oder das bestmögliche Ergebnis aus einer des ersten, zweiten und dritten Verzweigungen 1814, 1816, 1818 annehmen.
Wie veranschaulicht, können die erste, zweite und dritte Verzweigung 1814, 1816, 1818 getrennt aber miteinander verwandt sein. Die erste, zweite und dritte Verzweigung 1814, 1816, 1818 können nämlich unterschiedliche Suchlösungsräume oder Bereiche iterativer Erforschung darstellen. Die erste, zweite und dritte Verzweigung 1814, 1816, 1818 können unabhängig arbeiten, indem sie zum Beispiel keine Informationen zum Ausführen gemeinsam verwenden und folglich als separat betrachtet werden können. Die erste, zweite und dritte Verzweigung 1814, 1816, 1818 können jedoch dadurch verwandt sein, dass eine des ersten, zweiten und dritten Verzweigungen 1814, 1816, 1818 eine Entpriorisierung oder Stornierung ihrer selbst oder eine andere der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 verursachen kann.
Falls zum Beispiel eine Verzweigung der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 eine Stornierungsbedingung erreicht (die als eine Entpriorisierungsbedingung betrachtet werden kann), kann der Scheduler 1820 die eine Verzweigung beenden. Bei einem anderen Beispiel kann eine Ressourcenzuordnung zu einer Verzweigung der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 von dem Scheduler 1820 geändert und basierend auf dem Erreichen der Entpriorisierungsbedingung geändert werden. Falls der Scheduler 1820 zum Beispiel identifiziert, dass eine Verzweigung der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 eine signifikant geringere Erfolgswahrscheinlichkeit aufweist als eine andere Verzweigung der ersten, zweiten, und dritten Verzweigung 1814, 1816, 1818 kann die Entpriorisierungsbedingung als erfüllt gelten. Ferner kann der Scheduler 1820 eine Ressourcenzuordnung zu einer Verzweigung reduzieren und eine Ressourcenzuordnung zu der anderen Verzweigung erhöhen.
Jeder Lösungsraum kann zum Beispiel unterschiedliche Lösungen darstellen. Während der Lösungsraum schmaler wird oder seine Suchgröße reduziert wird, sinkt die Anzahl potenzieller Lösungen entsprechend, was bedingt, dass eine Lösung innerhalb einer begrenzten Menge an Rechenaufwand oder Zeit erzielt werden kann. Falls eine Verzweigung der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 einen Lösungsraum (mögliche Auswahlen für eine Lösung eingrenzt) über Iterationen reduziert, kann diese eine Verzweigung zum Erfolg tendieren. Im Gegensatz, falls eine andere Verzweigung der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 einen Lösungsraum erhöht (mögliche Auswahlen für eine Lösung erhöht) oder eine selbe Lösungsraumgröße beibehält, kann die andere Verzweigung zum Scheitern tendieren und/oder kann alternative Lösungen erzeugen, die nach Erschöpfen der Möglichkeit, dass eine aktuell priorisierte Erforschung zu einer Lösung führt, erforscht werden sollen. Die andere Verzweigung kann folglich die Entpriorisierungsbedingung basierend auf der Tendenz zum Scheitern erreichen. Bei einigen Ausführungsformen kann ein Vergleich der Lösungsraumgrößen (Lösung Auswahlen) verursachen, dass eine Entpriorisierungsbedingung erreicht wird. Falls zum Beispiel ein Lösungsraum einer Verzweigung der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 eine mit einer schnelleren Rate über Iterationen reduziert hat als einen anderer Lösungsraum der anderen Verzweigung der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818, kann die andere Verzweigung als eine Entpriorisierungsbedingung erfüllen gelten.
Insbesondere kann eine der angelegten Funktionen eine Entpriorisierungsbedingung wie oben beschrieben erreichen. Die Entpriorisierungsbedingung kann angeben, dass eine der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 entpriorisiert werden kann. Entpriorisieren kann bedeuten, dass eine oder mehrere des ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 als einen Bereich oder Raum erforschend gilt, der wahrscheinlich keine durchführbare Lösung für ein Problem ergeben wird, mit dem sich die Aufgabe auseinandersetzt, oder wahrscheinlich mehr Ressourcen oder Zeit benötigen wird als eine andere erzeugte Funktion. Falls der Scheduler 1820 eine Verzweigung der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 entpriorisiert, können weniger Ressourcen zu der einen Verzweigung zugeordnet werden, oder die eine Verzweigung kann vorübergehend durch vorübergehendes Aufheben/Beenden/Abwickeln irgendeiner erzeugten Funktion, die die eine Verzweigung umfasst, aufgehoben/beendet/abgewickelt werden. Die Entpriorisierungsbedingung kann sein, wenn eine der erzeugten Funktionen eine Beendigungsbedingung identifiziert, was daher im Beenden der einen angelegten Funktion oder einer anderen erzeugten Funktion resultiert. Effiziente Ressourcenzuordnung kann daher erzielt werden, indem die Ausführung von Funktionen, die für die Aufgabe weniger wichtig oder irrelevant sind, vermieden wird.
Nehmen wir zum Beispiel an, dass die Funktion D 1808 eine Entpriorisierungsbedingung erreicht. Die dritte Verzweigung 1818 kann beendet werden, was das Einstellen der Ausführung der Funktion D 1808 und/oder der Funktion B 1804 beinhalten kann. Bei einigen Ausführungsformen wird eine Ressourcenzuordnung zu der dritten Verzweigung 1818 reduziert, statt dass die dritte Verzweigung 1818 beendet wird. Eine Ressourcenzuordnung zu der Funktion D 1808 und/oder Funktion B 1804 kann zum Beispiel reduziert werden. Bei einigen Ausführungsformen kann die Entpriorisierungsbedingung durch einen Wert, der von der Funktion D 1808 erzeugt wird, ein Vertrauensintervall einer Lösung, die von der Funktion D erzeugt wird, eine Messung einer Erfolgswahrscheinlichkeit durch die Funktion D, ob Funktion D einer potenziellen Lösung nähert und so fort, identifiziert werden.
Wie in 18B veranschaulicht, kann ein verbessertes FaaS-System 1832 den Scheduler 1820 beinhalten. Wie bereits beschrieben, kann der Scheduler 1820 die Funktionserzeugungsgrafik 1800 der 18A erzeugen, gemäß der Funktionsgrafik 1800 planen und erzeugten Funktionen entsprechend stornieren.
Im Einzelnen kann der Scheduler 1820 die Ausführung der erzeugten Funktionen gemäß der Funktionserzeugungsgrafik 1800 planen und überwachen. Die iterative Ausführung der Funktion A 1822, die iterative Ausführung der Funktion B 1826, die iterative Ausführung der Funktion C 1824, die iterative Ausführung der Funktion D 1828 und die iterative Ausführung der Funktion E 1830 entsprechen jeweils der Funktion A 1802, Funktion B 1804, Funktion C 1806, Funktion D 1808 und Funktion E 1810 der 18A.
Der Scheduler 1820 kann die Entpriorisierungsbedingung (zum Beispiel eine Beendigungsbedingung) während der Ausführung der Funktionserzeugungsgrafik 1800 identifizieren und die Ausführung basierend auf der Entpriorisierungsbedingung stoppen oder vorübergehend aufheben. Der Scheduler 1820 kann zum Beispiel eine oder mehrere der angelegten Funktionen beenden oder vorübergehend aufheben und alle weiteren Funktionsinstanziierungen der erzeugten Funktionen stoppen und/oder auf Pause stellen. Der Scheduler 1820 kann dazu einen Hardware-Warteschlangenmanager und Multi-Casting einsetzen.
Im Einzelnen beinhaltet die iterative Ausführung der Funktion A 1822 FA₁ bis FA_n, die Iterationen der Funktion A 1802 sind. Die iterative Ausführung der Funktion A 1822 kann abgeschlossen werden, und dann kann die iterative Ausführung der Funktion C 1824 beginnen. Auf gleiche Art kann die iterative Ausführung der Funktion B 1826 abgeschlossen werden und die iterative Ausführung der Funktion D 1828 kann beginnen. Bei einigen Ausführungsformen kann gleichzeitige Ausführung ausgeführt werden. Die iterative Ausführung der Funktion A 1822 kann zum Beispiel gleichzeitig mit der iterativen Ausführung der Funktion C 1824 auftreten. Ferner kann die iterative Ausführung der Funktion B 1826 gleichzeitig mit der iterativen Ausführung der Funktion D 1828 erfolgen.
Während der iterativen Ausführung der Funktion C 1824 kann der Scheduler 1820 eine Entpriorisierungsbedingung identifizieren, die die iterative Ausführung der Funktion C 1824 beendet. Eine solche Entpriorisierungsbedingung kann eine Identifikation beinhalten, dass die erste Verzweigung 1814 und insbesondere die Funktion C 1806 wahrscheinlich keine durchführbare Lösung ergeben wird. Die iterative Ausführung der Funktion C 1824 führt daher nur eine Iteration FC₁ aus. Nach der Stornierung oder vorübergehenden Aufhebung der iterativen Ausführung der Funktion C 1824 können die Ressourcen, die der iterativen Ausführung der Funktion C 1824 zugeordnet sind, anderen Ausführungen neu zugeordnet werden. Die iterative Ausführung der Funktion E 1830 kann zum Beispiel eine erhöhte Ressourcenzuordnung aufweisen, und/oder die iterative Ausführung der Funktion D 1828 kann eine erhöhte Ressourcenzuordnung aufweisen.
Bei einigen Ausführungsformen kann der Scheduler 1820 statt die iterative der Funktion C 1824 zu stornieren, die Ressourcenzuordnung der iterativen Ausführung der Funktion C 1824 reduzieren. Bei einigen Ausführungsformen kann der Scheduler 1820 Ressourcenzuordnungen von der iterativen Ausführung der Funktion C 1824 zu der iterativen Ausführung der Funktion E 1830 und/oder der iterativen Ausführung der Funktion D 1828 neu verteilen. Bei einigen Ausführungsformen können die Ressourcen einer oder mehrerer der angelegten Funktionen basierend auf einer Wahrscheinlichkeit, dass die eine oder die mehreren der angelegten Funktionen eine größte Erfolgsgelegenheit und/oder eine größere Erfolgsgelegenheit in Bezug auf andere der angelegten Funktionen, die das Ausführen noch fortsetzen, aufweisen. Das kann die Latenz der iterativen Ausführung der Funktion E 1830 und/oder der iterativen Ausführung der Funktion D 1828 verringern und darüber hinaus die Latenz des Identifizierens einer Lösung für die Aufgabe verringern. Die Latenz der iterativen Ausführung der Funktion C 1824 kann zunehmen, kann jedoch angesichts der niedrigeren Erfolgswahrscheinlichkeit, die die iterative Ausführung der Funktion C 1824 aufweist, als ein akzeptabler Kompromiss betrachtet werden.
Bei einigen Ausführungsformen kann die iterative Ausführung der Funktion C 1824 erneut priorisiert werden. Die iterative Ausführung der Funktion C 1824 kann zum Beispiel erneut priorisiert werden, falls eine Neupriorisierungsbedingung erfüllt wird, so dass die iterative Ausführung der Funktion C 1824 wieder aufgenommen wird und/oder eine gesteigerte Ressourcenzuordnung aufweist. Die Neupriorisierungsbedingung kann zum Beispiel eine Angabe sein, dass iterative Ausführung der Funktion C 1824 wahrscheinlicher ein durchführbares Ergebnis erzeugen wird als andere der angelegten Funktionen. Bei einigen Ausführungsformen kann die Neupriorisierungsbedingung eine Identifikation sein, dass eine andere angelegte Funktion, zum Beispiel iterative Ausführung der Funktion D 1828, eine verringerte Erfolgswahrscheinlichkeit aufweist.
Bei einigen Ausführungsformen tritt die iterative Ausführung der angelegten Funktionen an unterschiedlichen Knoten und/oder Containern auf. Die iterative Ausführung der Funktion A 1822 kann zum Beispiel an unterschiedlichen Knoten und/oder unterschiedlichen Containern auftreten. FA₁ kann in einem ersten Container an einem ersten Knoten ausgeführt werden, während FAN an einem zweiten Container an einem zweiten Knoten ausgeführt werden kann.
Wie bereits beschrieben, kann der Scheduler 1820 die Latenz reduzieren und ein verbessertes Ressourcenmanagement, wie oben beschrieben, durch Beenden angelegter Funktionen und/oder Reduzieren von Ressourcenzuordnungen zu weniger erfolgreichen Lösungsräumen aufweisen. Ressourcen können zum Beispiel effizient als Reaktion auf eine Identifikation einer Entpriorisierungsbedingung freigegeben werden.
Iterative Ausführungssteuerung kann dynamisch skriptfähig oder variabel sein, da die Bedingungen für das Abschließen einer iterativen Aufgabe wahrscheinlich dynamisch spezifiziert sind. Der Scheduler 1820 kann daher unterschiedliche Strategien erforschen, die von der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 und insbesondere den erzeugten Funktionen der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 dargestellt sind. Die erste, zweite und dritte Verzweigung 1814, 1816, 1818 können unterschiedliche Suchstrategien sein, die gemäß dynamischen Hinweisen, kürzlich beobachteten Mustern und Verlagerungen von Mustern, Variationen der Auflagen usw. bestimmt werden.
Der Scheduler 1820 kann zum Beispiel die beste Folgerung innerhalb einer finiten Zeitmenge und eines finiten Leistungsbudgets zu einer gegebenen Zeit identifizieren. Dazu kann der Scheduler 1820 Strategien mit niedriger Präzision verwenden, falls ein Zeitfenster ausreichend klein ist oder beim Erfüllen eines Schwellenwerts scheitert, und/oder falls das Rechenbudget ausreichend klein ist oder beim Erfüllen eines Schwellenwerts scheitert. Nach dem Erforschen der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 wie in 18B veranschaulicht, kann der Scheduler 1820 höhere Präzision für spätere Iterationen verwenden, nachdem er einen Lösungsraum, wie die erste Verzweigung 1814, die oben beschrieben ist, eliminiert hat. Der Scheduler 1820 kann daher mehrere parallele Suchvorgänge mit niedrigen Kosten durch die erste, zweite und dritte Verzweigung 1814, 1816, 1818 initiieren und dann einige der ersten, zweiten und dritten Verzweigungen 1814, 1816, 1818 als Reaktion auf eine Identifikation, dass andere der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 produktivere Ergebnisse erzeugen werden, stornieren. Wie bereits beschrieben, kann die Stornierung einer Verzweigung der ersten, zweiten und dritten Verzweigung 1814, 1816, 1818 die Stornierung der angelegten Funktion(en), die die stornierte Verzweigung umfasst, bedeuten.
Der Scheduler 1820 kann daher effizient Ressourcenzuordnungen zu entpriorisierten der iterativen Ausführung der Funktion A 1822, der iterativen Ausführung der Funktion B 1826, der iterativen Ausführung der Funktion C 1824, der iterativen Ausführung der Funktion D 1828 und der iterativen Ausführung der Funktion E 1830 stornieren oder reduzieren. Entpriorisiert kann bedeuten, dass die entpriorisierte iterative Funktion als einen Bereich oder einen Raum erforschend gilt, der wahrscheinlich keine durchführbare Lösung für ein Problem, mit dem sich die Aufgabe auseinandersetzt, ergeben wird. Einige Ausführungsformen können zum Beispiel diverse Meta-Programmierhilfen für solches dynamisches iteratives Starten und Stornieren der iterativen Ausführung der Funktion A 1822, der iterativen Ausführung der Funktion B 1826, der iterativen Ausführung der Funktion C 1824, der iterativen Ausführung der Funktion D 1828 und der iterativen Ausführung der Funktion E 1830 beinhalten. Falls ein Lösungssubraum vorübergehend entpriorisiert wird, können die Ressourcen des Lösungsraums, die für sein Erforschen verbraucht werden, automatisch freigegeben werden, indem zum Beispiel Daten aus Caching-Tiers heraus bewegt werden, bis der Lösungssubraum erneut priorisiert wird. Ferner können Stornierungen erzeugter Funktionen automatisch erzeugt werden, so dass Ressourcen schnell von weniger wichtigen Funktionen oder weniger wichtiger Arbeit freigegeben und anderer Arbeit oder erzeugten Funktionen mit höherer Priorität zugeordnet werden können.
Bei einigen Beispielen wird eine flexible Multi-Casting-Topologie umgesetzt, bei der Daten (und Ereignisse) von einer Iteration an einer angelegten Funktion automatisch zu einer anderen Iteration der angelegten Funktion (oder einer anderen angelegten Funktion), die eventuell lokal auftritt oder nicht, bewegt werden kann. Die Topologie ermöglicht daher eine effiziente Kommunikationsstrategie zum Stornieren oder erneuten Priorisieren angelegter Funktionen.
Außerdem können einige Ausführungsformen eine verbesserte Multi-Casting-Topologie aufweisen, die diverse Punkt-zu-Punkt-Fähigkeiten verallgemeinert, um Netzwerkfunktions-Virtualisierungs-Performance-Nachfragen zu erfüllen. Einige Ausführungsformen können zum Beispiel eine flexible Multi-Casting-Topologie derart umsetzen, dass, während erzeugte Funktionen und Aufgaben in einem Teil einer Infrastruktur erzeugt und in einem anderen Teil der Infrastruktur storniert werden, die Kommunikationstopologie mit niedrigem Aufwand anpasst. Bei Edge-Computing, während ein anfordernder Mobil-Client oder ein Mobil-Ziel (zum Beispiel eine Basisstation oder Verbraucherstandortausstattung) den Ort wechselt, können einige Ausführungsformen die Multi-Casting-Anordnungen unter den unterschiedlichen Knoten, Containern usw. auf eine effiziente Art ändern, um die entsprechenden iterativen angelegten Funktionen neu zu verteilen.
Bei einigen Ausführungsformen kann zum Beispiel der Scheduler 1820 einen Ort eines mobilen Client und/oder eines mobilen Ziels zu identifizieren. Während ein mobiler Client und/oder das mobile Ziel seine Orte wechselt, kann die iterative Ausführung der angelegten Funktionen zu unterschiedlichen Containern und/oder Knoten bewegt werden, um innerhalb einer vorbestimmten Entfernung von dem mobilen Client und/oder Ziel zu bleiben. Das kann Kommunikationslatenzen verringern und durch die flexible Multi-Casting-Infrastruktur, die oben beschrieben ist, erzielt werden. Ferner kann der Scheduler 1820 über die Container und/oder Knoten Bescheid wissen, so dass der Scheduler 1820 die Ausführung, Ressourcenzuordnung und Stornierungen der angelegten Funktionen steuern kann. Darüber hinaus können Fähigkeiten zum Laufen von Meta-Programmen ferner in Hardware verlagert werden, wie in (einen) Hardware-Warteschlangenmanager, und zu Plattformsoftware bereitgestellt werden, so dass die erzeugten Funktionen bei Bedarf schnellere Ausführung und effizientere Stornierung aufweisen. Eine Ausführungsform eines Hardware-Warteschlangenmanagers ist ein Plattform-Hardware-Feature, das Steuervorgänge oder Datenbewegungsanforderungen für Vorgänge von einer ersten einer Vielzahl von Entitäten (wo eine Entität zum Beispiel eine Aufgabe, ein Prozess, ein Container, eine virtuelle Maschine usw. sein kann) erhalten und die angeforderten Vorgänge in einer zweiten einer Vielzahl von Entitäten (zum Beispiel einer anderen Aufgabe, einem anderen Prozess, einem anderen Container, einer anderen virtuellen Maschine usw.) nach dem Validieren, dass der angeforderte Vorgang ohne Verstoß gegen geltende Sicherheitsstrategien, und, optional, ohne eine erste anfordernde Entität zu zwingen zu warten, bis der Vorgang in einer zweiten Entität abgeschlossen wurde, ausführen kann.
18C zeigt ein Verfahren 1870 einer FaaS-Funktionsumsetzung und kann von dem Server 1302 der 13A ausgeführt werden, kann aber auch oder in Verbindung mit dem Server 1302 in dem verbesserten FaaS-System 400 der 4 und/oder dem Scheduler 1820 der 18B oder einem oder mehreren Modulen als ein Satz logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., konfigurierbarer Logik, wie zum Beispiel PLAs, FPGAs, CPLDs, gespeichert sind; in Hardwarelogik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 1872 kann eine Vielzahl von Funktionen identifizieren, die ausgeführt werden sollen. Die Vielzahl von Funktionen kann iterativ ausgeführt werden. Der veranschaulichte Verarbeitungsblock 1874 kann eine oder mehrere der Vielzahl von Funktionen als Reaktion darauf, dass eine Entpriorisierungsbedingung identifiziert wird, entpriorisieren. Der veranschaulichte Verarbeitungsblock 1874 storniert die Ausführung der einen oder mehreren der Vielzahl von Funktionen zum Beispiel als Reaktion darauf, dass die Entpriorisierungsbedingung identifiziert wird. Der veranschaulichte Verarbeitungsblock 1874 kann auch eine Ressourcenzuordnung der einen oder mehreren der Vielzahl von Funktionen als Reaktion darauf, dass die Entpriorisierungsbedingung identifiziert wird, reduzieren. Der veranschaulichte Verarbeitungsblock 1876 kann eine Ressourcenzuordnung zu einer oder mehreren der Vielzahl von Funktionen, die nicht entpriorisiert wurden, als Reaktion darauf, dass die Entpriorisierungsbedingung identifiziert wird, erhöhen.
Das Verfahren 1870 kann Latenz reduzieren und ein verbessertes Ressourcenmanagement aufweisen, wie oben beschrieben, indem Ressourcenzuordnungen zu weniger erfolgreichen Lösungsräumen, zum Beispiel der einen oder mehreren der Vielzahl von Funktionen, beendet und/oder reduziert werden. Ressourcen werden zum Beispiel effizient als Reaktion auf eine Identifikation der Entpriorisierungsbedingung, wie in Bezug auf den veranschaulichten Verarbeitungsblock 1874 beschrieben, freigegeben.
Zusätzliche Anmerkungen und Beispiele
Beispiel 1800 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Instruktionen umfasst, der, wenn er von einem Rechengerät ausgeführt wird, das Rechengerät veranlasst, eine Vielzahl von Funktionen zu identifizieren, die ausgeführt werden sollen, eine oder mehrere der Vielzahl von Funktionen als Reaktion darauf, dass eine Entpriorisierungsbedingung identifiziert wird, zu entpriorisieren, als Reaktion darauf, dass die Entpriorisierungsbedingung identifiziert wird, eine Ressourcenzuordnung zu der einen oder der mehreren der Vielzahl von Funktionen zu reduzieren oder die Ausführung der einen oder der mehreren der Vielzahl von Funktionen zu stornieren, und eine Ressourcenzuordnung zu einer oder mehreren der Vielzahl von Funktionen, die nicht entpriorisiert sind, zu erhöhen, wenn Funktionen der Vielzahl von Funktionen iterativ ausgeführt werden sollen.
Beispiel 1801 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, der, wenn er von einem Rechengerät ausgeführt wird, das Rechengerät veranlasst, eine Vielzahl von Funktionen zu identifizieren, die ausgeführt werden sollen, und eine oder mehrere der Vielzahl von Funktionen als Reaktion darauf, dass eine Entpriorisierungsbedingung identifiziert wird, zu entpriorisieren.
Beispiel 1802 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1801, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Ausführung der einen oder der mehreren der Vielzahl von Funktionen als Reaktion darauf, dass die Entpriorisierungsbedingung identifiziert wird, zu stornieren.
Beispiel 1803 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1802, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Ressourcenzuordnung zu der einen oder der mehreren der Vielzahl von Funktionen als Reaktion darauf, dass die Entpriorisierungsbedingung identifiziert wird, zu reduzieren.
Beispiel 1804 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1801, wobei Funktionen der Vielzahl von Funktionen iterativ ausgeführt werden sollen.
Beispiel 1805 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1801, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Ressourcenzuordnung zu einer oder mehreren der Vielzahl von Funktionen, die nicht entpriorisiert sind, zu erhöhen.
Verbesserte FaaS-Struktur mit einer gemeinsamen Datenlagerung
In einer FaaS-Umgebung können Kommunikationslatenzen eine einen erheblichen Aufwand darstellen. Einige FaaS-Umgebungen können zum Beispiel Tausende von Funktionen beinhalten, wobei entsprechende Daten zwischen Knoten zur Langzeitlagerung und/oder Ausführung weitergegeben werden. Funktionen können darüber hinaus als „zustandslos“ betrachtet werden. Die Datenlagerung, die die Ausführung einer Funktion, die die Daten anlegt, überlebt, kann daher besondere Herausforderungen aufweisen. Einige Ausführungsformen verbessern das Zwischenspeichern solcher Daten für zukünftige Wiederverwendung.
Nehmen wir zum Beispiel einen Datenbankserver, der ein Knoten sein kann. Der Knoten (Datenbankserver), kann in Bezug auf einen Ausführungsknoten, der eine Funktion ausführt, entfernt sein. Der Datenbankserver kann Daten speichern, die die Funktion zur Ausführung einsetzen kann. Von dem Ausführungsknoten können Datenzugriffe auf den entfernten Datenbankserver kostspielig sein, und solche Daten können daher zu dem Ausführungsknoten bewegt werden oder dem Ausführungsknoten nahe sein. Solche Datentransfers können hohe Latenz aufweisen und ressourcenintensiv sein, insbesondere in Abhängigkeit von der Beschaffenheit und der Größe der Daten. Es entsteht nicht nur verschwenderisches Hin- und-Her-Eingeben/Ausgeben, sondern das natürliche Format der Daten kann von einem Ruhezustandscodierungsformat in ein Verwendungscodierungsformat und umgekehrt geändert werden. Rangierkosten und Kosten zum Wechseln zwischen einem Ruhezustands- und einem Verwendungscodierungsformat für die Daten werden daher erhöht.
Unter Bezugnahme auf 19A ist eine verbesserte FaaS-Architektur mit einer gemeinsamen Datenlagerung 1900 veranschaulicht. Das Beispiel 1900 kann das verbesserte FaaS-System 400 der 4 beinhalten. Einige Ausführungsformen können die Effizienz durch Einsatz einer gemeinsamen Datenlagerung 1910 (die eine kurzlebige Datenlagerung sein kann) verbessern, um Daten zur Wiederverwendung durch eine oder mehrere Funktionen zu speichern. Eine Funktion F₁ kann zum Beispiel gemeinsame Daten erzeugen, die von anderen Funktionen verwendet werden sollen. Die gemeinsamen Daten können in der Datenspeicherschicht 1910 gespeichert werden. Nachdem die Funktion F₁ die Ausführung abgeschlossen hat, können die gemeinsamen Daten in der gemeinsamen Datenlagerung 1910 gespeichert bleiben. Danach können andere Funktionen, wie die Funktion F₂, die Ausführung beginnen und auf die gemeinsamen Daten zugreifen. Falls zum Beispiel die Funktion F₂ die Ausführung beginnt, nachdem die erste Funktion F₁ die Ausführung abgeschlossen hat, kann die Funktion F₂ zu einem Knoten instanziiert werden, wie zu einem Ausführungsknoten 1904, der der gemeinsamen Datenlagerung 1910 nahe ist und/oder sie beinhaltet.
Die gemeinsamen Daten können folglich in der gemeinsamen Datenlagerung 1910 verbleiben, statt geräumt zu werden. Darüber hinaus kann das Format der gemeinsamen Daten aus Sicherheitsgründen verschlüsselt werden, ansonsten aber unverändert bleiben. Die oben stehende Umsetzung kann daher E/A-Transfers und Datencodierungsformatänderungen reduzieren, was die Latenz reduziert und die Ressourcennutzung verbessert.
Ein Steuerknoten 1902 kann die Funktion F₁ in dem Zeitpunkt T₀, wie von Prozess 1912 angegeben, aufrufen. Die Funktion F₁ kann auf dem Knoten 1904 ausgeführt werden. Der Knoten 1904 kann mit der lokalen Datenlagerung 1906 in Kommunikation stehen. Bei einigen Ausführungsformen kann die lokale Datenlagerung 1906 Teil des Ausführungsknotens 1904 sein. Bei einigen Ausführungsformen gehören die lokale Datenlagerung 1906 und der Ausführungsknoten 1904 zu demselben Rechengerät, wie zu einem Server. Wie veranschaulicht, beinhaltet die lokale Datenlagerung 1906 mindestens zwei Datenlagerungen oder Partitionen, die eine gemeinsame Datenlagerung 1910 und eine spezifische Datenlagerung 1928 beinhalten.
Die Funktion F₁ kann Daten erzeugen, wenn die Funktion F₁ in einem Container des Ausführungsknotens 1904 ausgeführt wird. Mindestens einige der Daten können als gemeinsame Daten bezeichnet werden. Die gemeinsamen Daten können durch andere Funktionen wiederverwendet werden. Der Steuerknoten 1902 kann zum Beispiel eine Funktionserzeugungsgrafik erzeugen, wie die Funktionserzeugungsgrafik 1800 der 18A. Bei einigen Ausführungsformen kann der Betrieb des Steuerknotens 1902 optional von Richtlinien, die von einem Programmierer oder einem Cloud-Service-Anbieter empfangen werden, geführt werden. Der Steuerknoten 1902 kann die Funktionserzeugungsgrafik analysieren, um die gegenseitigen Abhängigkeiten von Funktionen zu bestimmen, und ob zum Beispiel eine Funktion basierend auf Daten, die von einer anderen Funktion erzeugt werden, arbeitet. Der Steuerknoten 1902 kann steuern, ob Daten in der gemeinsamen Datenlagerung 1910 oder in der spezifischen Datenlagerung 1928 gespeichert werden. Bei einigen Ausführungsformen kann die Entscheidung, ob Daten in der gemeinsamen Datenlagerung 1910 oder in der spezifischen Datenlagerung 1928 gespeichert werden, zusätzlicher Eingabe (zum Beispiel Hinweise, Richtlinien usw.) von einem Programmierer oder einem Cloud-Service-Anbieter unterliegen, und ein Programmierer oder ein Cloud-Service-Anbieter kann diese Eingaben (zum Beispiel Hinweise oder Richtlinien) von Zeit zu Zeit ändern.
Bei einigen Ausführungsformen kann der Steuerknoten 1902 bestimmen, dass die Funktion F₂ Daten verbraucht, die von Funktion F₁ erzeugt werden. Der Steuerknoten 1902 kann daher einen Befehl oder eine Meldung, dass mindestens einige der Daten, die von Funktion F₁ erzeugt werden, gemeinsame Daten sind, zu dem Ausführungsknoten 1904 weitergeben. Wenn zum Beispiel Funktion F₁ bei T₀ aufgerufen wird, kann der Steuerknoten 1902 den Ausführungsknoten 1904 anweisen, Daten, die von der Funktion F₁ erzeugt werden, als gemeinsame Daten zu speichern. Bei einigen Ausführungsformen wird eventuell nur ein Subsatz von Daten (zum Beispiel finale Berechnungen oder Schlussfolgerungsdaten) der Funktion F₁ als gemeinsame Daten betrachtet, statt alle der Daten der Funktion F₁. Der Datensubsatz kann aus Daten bestehen, die als von der Funktion F₂ verwendbar identifiziert sind. Andere Daten, die als von der Funktion F₂ nicht verwendbar identifiziert sind, können verworfen werden.
Der Ausführungsknoten 1904 kann die Funktion F₁ instanziieren und Datenlagerung von der gemeinsamen Datenlagerung 1910 zuordnen. Die Funktion F₁ kann folglich die gemeinsamen Daten, wie von Prozess 1914 angegeben, in der gemeinsamen Datenlagerung 1910 speichern. Nachdem Funktion F₁ die Ausführung abgeschlossen hat, können die gemeinsamen Daten in der gemeinsamen Datenlagerung 1910 verbleiben, statt zu dem Steuerknoten 1902 gesendet zu werden. Statt dann sofort die gemeinsamen Daten aus der gemeinsamen Datenlagerung 1910 zu entfernen, können die gemeinsamen Daten in der gemeinsamen Datenlagerung 1910 verbleiben.
Den gemeinsamen Daten kann eine Time-To-Live-Strategie gegeben werden, die eine Time-To-Live für die gemeinsamen Daten beschreibt. Die Time-To-Live kann durch andere Funktionen, die auf die gemeinsamen Daten zugreifen, erweitert werden. Die Time-To-Live kann um eine feststehende Menge (oder um eine variable Menge, wie aus Strategien und heuristisch, die auf vergangener Historie basieren, bestimmt) jedes Mal dann erweitert werden, wenn eine neue Funktion auf die gemeinsamen Daten zugreift. Bei einigen Ausführungsformen können die gemeinsamen Daten einer maximalen Time-To-Live unterliegen, nach der die gemeinsamen Daten automatisch aus mindestens der gemeinsamen Datenlagerung 1910 geräumt, und ferner aus der lokalen Datenlagerung 1906 geräumt werden. Falls auf die gemeinsamen Daten nicht zugegriffen wird, nachdem die Funktion F₁ die Ausführung abgeschlossen hat, können die gemeinsamen Daten zu dem Steuerknoten 1902, nachdem die Time-To-Live abgelaufen ist, und ohne jede Anpassung der Time-To-Live geräumt werden. Die lokale Datenlagerung 1906 und/oder der Ausführungsknoten 1904 können die Time-To-Live-Strategie durchsetzen.
Bei einigen Ausführungsformen kann Time-To-Live-Strategie gegen Sicherheitsanforderungen ausgewogen werden. Falls zum Beispiel die lokale Datenlagerung 1906 in einer Edge-Vorrichtung geführt wird, die leicht durch physischen Einbruch kompromittiert werden kann, kann die Time-To-Live auf einen niedrigen Wert eingestellt werden. Außerdem, falls die gemeinsamen Daten eine hohe Sicherheitsanforderungen aufweisen, kann die Time-To-Live auf einen niedrigen Wert eingestellt werden.
Außerdem können die Funktion F₁ und/oder die lokale Datenlagerung 1906 die gemeinsamen Daten verschlüsseln. Dadurch kann die Sicherheit verbessert werden, so dass auf die gemeinsamen Daten nur von befugten Funktionen zugegriffen werden kann.
Die Funktion F₁, der Ausführungsknoten 1904 und/oder die lokale Datenlagerung 1906 können einen Deskriptor (eindeutige Identifikatoren usw.), der beschreibt, wo die gemeinsamen Daten gespeichert werden und ob die gemeinsamen Daten verschlüsselt sind, erzeugen. Falls die gemeinsamen Daten zu Sicherheitszwecken verschlüsselt sind, kann der Deskriptor außerdem ein Entschlüsselungsprotokoll zum Zugreifen auf die gemeinsamen Daten beinhalten. Der Deskriptor kann zum Beispiel einen Entschlüsselungscode zum Entschlüsseln der gemeinsamen Daten beinhalten. Der Deskriptor kann zu dem Steuerknoten 1902 bereitgestellt werden, der den Deskriptor zu anderen Funktionen zweckdienlich weitergeben kann.
Nachdem die Funktion F₁ die Ausführung abgeschlossen hat, kann der Steuerknoten 1902 die Funktion F₂ in dem Zeitpunkt T₂, wie von Prozess 1924 angegeben, aufrufen. Der Ausführungsknoten 1904 kann die Funktion F₂ ausführen. Die Funktion F₂ kann den Deskriptor der gemeinsamen Daten, die von der Funktion F₁ gespeichert werden, empfangen. Der Deskriptor kann einen Ort der gemeinsamen Daten sowie zweckdienliche Entschlüsselungsprotokolle präzis beschreiben. Die Funktion F₂ kann auf die gemeinsamen Daten, wie von dem Prozess 1916 angegeben, die in der gemeinsamen Datenlagerung 1910 gespeichert sind, zugreifen und basierend auf den gemeinsamen Daten ausgeführt werden. Die Time-To-Live für die gemeinsame Daten kann daher erhöht werden. Zugriff kann bedeuten, dass die Funktion F₂ gelesen werden kann, neue gemeinsame Daten zu den gemeinsamen Daten hinzufügen und/oder die gemeinsamen Daten überschreiben kann. Wie oben beschrieben, wird, da auf die gemeinsamen Daten zugegriffen wird, die Time-To-Live für die gemeinsamen Daten um einen vordefinierten Wert verlängert. Bei einigen Ausführungsformen kann an Stelle oder zusätzlich zu der Time-To-Live eine Referenzzählung verwendet werden, um frühzeitiges Räumen der gemeinsamen Daten, während die Funktion F₂ ihren Abschluss nicht erreicht hat, zu verhindern.
Die Funktion F₂ kann auch spezifische Daten, die nur die Funktion F₂ verwenden wird, erzeugen. Die spezifischen Daten können, wie von Prozess 1922 angegeben, in einer separaten Partition von der gemeinsamen Datenlagerung 1910, wie der spezifischen Datenlagerung 1928 gespeichert werden. Die spezifischen Daten können automatisch aus der spezifischen Datenlagerung 1928 geräumt werden, wenn die Funktion F₂ die Ausführung, wie von Prozess 1930 veranschaulicht, abschließt.
Die Funktion F₂ kann die Ausführung in einer Zeit nach T₁ (der Aufrufzeit von T₁ abschließen, aber bevor die Funktion F₃ bei T₂, wie von Prozess 1932 angegeben, aufgerufen wird. Die spezifischen Daten, die von Funktion F₂ erzeugt werden, können automatisch, wie von Prozess 1930 angegeben, zu dem Steuerknoten 1902 geräumt werden, wenn die der F₂ dedizierten Ressourcen zurückgefordert werden. Der Steuerknoten 1902 kann die spezifischen Daten ohne Speichern der spezifischen Daten in einen Langzeitspeicher oder Speichern der spezifischen Daten an dem Datenbankknoten 1908 aufgeben.
Die gemeinsame Datenlagerung 1910 kann daher eine vorübergehende Lagerung zum Weitergeben von Daten zwischen den Funktionen F₁ und F₂ bereitstellen. Das kann den Datenbankzugriff (Lese-/Schreibvorgänge) auf den Datenbankknoten 1908 durch Sparen an Daten, die von der Funktion F₁ erzeugt werden, in die gemeinsame Datenlagerung 1910 einschränken. Außerdem kann die verbesserte FaaS-Architektur, die in 19A veranschaulicht ist, verbesserte Ressourcen Managementprotokolle aufweisen, da weniger Daten zwischen der lokalen Datenlagerung 1906 und dem Steuerknoten 1902 weitergegeben werden, was eine Latenz der Funktion F₂ weiter reduziert. Aufgrund der reduzierten Datenbewegung und Eingangs-/Ausgangsbrandbreite kann zum Beispiel die Funktion F₂ die Ausführung mit weniger Aufwand und ohne Warten auf Datentransfer der gemeinsamen Daten beginnen.
Der gemeinsame Datenspeicher 1910 kann ein lokaler Seitencache des Ausführungsknotens 1904 sein, um Zugriff durch die Funktion F₂ zu erlauben. Im Einzelnen führt die Funktion F₂ auf dem Ausführungsknoten 1904 aus und kann folglich auf den lokalen Seitencache des Ausführungsknotens 1904 auf eine sinnvolle Art zugreifen. Bei einigen Ausführungsformen kann die Datenlagerung 1910 ein Lagerungs-Cache (Datei- oder Blockspeicher-Cache), ein Speicher für transienten Schlüsselwert oder ein Dokumentspeicher sein, der eine Kombination aus einem Seitencache und einem Blockcache usw. verwendet.
Der Steuerknoten 1902 kann die Funktion F₃ im Zeitpunkt T₂, wie von Prozess 1932 veranschaulicht, aufrufen. Die Funktion F₃ beginnt die Ausführung auf dem Ausführungsknoten 1904 und erzeugt spezifische Daten. Die spezifischen Daten können von Prozess 1926 in den spezifischen Datenspeicher 1928 gespeichert werden. Nachdem die Funktion F₃ die Ausführung abgeschlossen hat, oder wenn der Container für Funktion F₃ abgebaut oder zurückgefordert wird, können die spezifischen Daten von Prozess 1930 geräumt und entweder von dem Steuerknoten 1902 verworfen oder in dem Datenbankknoten 1908 gespeichert werden.
Die Funktion F₃ greift eventuell nicht auf die gemeinsamen Daten, die in der gemeinsamen Datenlagerung 1910 gespeichert sind, zu. Die Time-To-Live der gemeinsamen Daten kann daher nicht erweitert werden und kann ablaufen. Der Prozess 1918 kann daher die gemeinsamen Daten zu einer vorbestimmten Zeit, nachdem Funktion F₂ abgeschlossen wurde, räumen. Im Einzelnen können die gemeinsamen Daten aus der gemeinsamen Datenlagerung 1910 geräumt und zu dem Steuerknoten 1902 gesandt werden. Der Steuerknoten 1902 kann die gemeinsamen Daten von einem Verwendungscodierungsformat in ein Ruhezustandscodierungsformat ändern und die gemeinsamen Daten dann bei Prozess 1920 zu dem Datenbankknoten 1908 speichern. Der Datenbankknoten 1908 kann eine Langzeitlagerung sein. Die gemeinsamen Daten können auch von der lokalen Datenlagerung 1906 in ein Ruhezustandscodierungsformat geändert werden.
Bei einigen Ausführungsformen können Daten, die von den Funktionen F₁ F₂, F₃ erzeugt werden, in der gemeinsamen Datenlagerung 1910 ohne Verweis auf potenzielle Wiederverwendung der Daten gespeichert werden. Der Steuerknoten 1902 analysiert daher eventuell eine Funktionsgrafik nicht, um zu bestimmen, welche der Funktionen F₁ F₂, F₃ Daten erzeugen kann, die von anderen Funktionen F₁ F₂, F₃ verwendet werden können. Stattdessen kann jede Funktion F₁ F₂, F₃ erzeugte Daten in der gemeinsamen Datenlagerung 1910 speichern. Die Daten können auf ähnliche Art behandelt werden wie oben beschrieben, und können verschlüsselt und aus der gemeinsamen Datenlagerung 1910 geräumt werden, nachdem eine entsprechende Time-To-Live abgelaufen ist.
19B zeigt ein Verfahren 1950 zur Verwendung der Lagerung gemeinsamer Daten, die von einer oder mehreren FaaS-Funktionen erzeugt werden, und kann von dem verbesserten FaaS-System 400 der 4 und/oder von einem oder mehreren Modulen als ein Satz von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 1952 kann während der Ausführung einer ersten Funktion erste Daten in Zusammenhang mit der Funktion in einem Datenspeicher speichern, wobei die ersten Daten von einer oder mehreren anderen Funktionen verwendet werden. Die ersten Daten können zum Beispiel in einem Cache der Datenlagerung, wo die Datenlagerung für eine oder mehrere Funktion zugänglich ist, gespeichert werden. Der veranschaulichte Verarbeitungsblock 1954 kann, nachdem die erste Funktion beendet ist, die ersten Daten der ersten Funktion in der Datenlagerung behalten. Die ersten Daten können zum Beispiel als Reaktion auf eine Identifikation, dass die erste Funktion die Ausführung abgeschlossen hat, nicht geräumt werden. Der veranschaulichte Verarbeitungsblock 1956 kann während der Ausführung einer zweiten Funktion der zweiten Funktion das Zugreifen auf die ersten Daten, die in der Datenlagerung gespeichert sind, erlauben. Die zweite Funktion kann zum Beispiel einen Deskriptor empfangen, der den Ort der ersten Daten und irgendwelche Sicherheitsprotokolle, die zum Zugreifen auf die ersten Daten erforderlich sind, angibt. Verfahren zum Anlegen von Deskriptoren zu Referenzdaten können verwendet werden. Ein Deskriptor kann zum Beispiel eine Angabe beinhalten, dass Daten, die referenziert werden sollen, an einem besonderen Ort gespeichert sind, und erzeugt werden können (zum Beispiel von einer Speichersteuervorrichtung), wenn die Daten gespeichert sind. Der Deskriptor kann ferner einen Ort von Metadaten, die mit den ersten Daten assoziiert sind, beinhalten oder angeben, wobei die Metadaten anwendbare Entschlüsselungscodes zum Entschlüssen der ersten Daten enthalten sollen, falls die ersten Daten verschlüsselt sind, anwendbare Prüfcodes, um die ersten Daten zu prüfen, falls die ersten Daten Fingerprinting aufweisen, Dekompressionscodes zum Dekomprimieren der ersten Daten, falls die ersten Daten komprimiert sind usw. Die ersten Daten können daher in der Datenlagerung gespeichert werden, während die erste und die zweite Funktion auf die Datenlagerung zugreifen. Wie oben beschrieben, kann das die Latenz reduzieren und das Ressourcenmanagement durch Reduzieren von E/A-Vorgängen, Datentransfers und Datenänderungen verbessern.
Der veranschaulichte Verarbeitungsblock 1958 kann eine Zeitspanne, in der auf die ersten Daten in der Datenlagerung nicht zugegriffen wird, bestimmen. Der veranschaulichte Verarbeitungsblock 1960 kann bestimmen, ob die Zeitspanne einen Time-To-Live-Schwellenwert der ersten Daten erfüllt. Ist das nicht der Fall, kann der veranschaulichte Verarbeitungsblock 1958 wiederholt werden, um eine Zeitspanne zu bestimmen, in der auf die ersten Daten nicht zugegriffen wird. Wenn der Time-To-Live-Schwellenwert erfüllt wird, kann der veranschaulichte Verarbeitungsblock 1962 die ersten Daten aus der Datenlagerung räumen. Das Räumen der ersten Daten kann das Freigeben des Speichers, in dem die ersten Daten gespeichert sind, und/oder das Löschen der ersten Daten aus der Datenlagerung beinhalten. Der veranschaulichte Verarbeitungsblock 1964 kann die ersten Daten an einem zweiten Datenserver speichern. Der zweite Datenserver kann ein Langzeitdatenbankspeicher-Server sein.
19C zeigt ein Verfahren 1970 zum Umsetzen und Durchsetzen von FaaS-Sicherheitsprotokollen und kann von dem verbesserten FaaS-System 400 der 4 und/oder von einem oder mehreren Modulen als ein Satz von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 1972 kann bestimmen, dass Daten, die von der ersten Funktion erzeugt werden, in gemeinsamer Datenlagerung für Zugriff durch andere Funktionen gespeichert werden. Der veranschaulichte Verarbeitungsblock 1974 kann die ersten Daten derart verschlüsseln, dass die ersten Daten verschlüsselt werden, nachdem die erste Funktion die Ausführung abgeschlossen hat. Der veranschaulichte Verarbeitungsblock 1976 kann bestimmen, dass eine zweite Funktion auf die ersten Daten zugreifen kann. Der veranschaulichte Verarbeitungsblock 1976 kann zum Beispiel Sicherheitsbefugnisse der zweiten Funktion, einen Ursprung der Instanziierung der zweiten Funktion (zum Beispiel einen Server, Dienst oder Client, der die Ausführung der zweiten Funktion anfordert), Malware-Analyse der zweiten Funktion und/oder ob die zweite Funktion mit den ersten Daten kompatibel ist, identifizieren. Der veranschaulichte Verarbeitungsblock 1978 kann die ersten Daten entschlüsseln, um es der zweiten Funktion zu erlauben, auf die ersten Daten zuzugreifen. Die Verschlüsselung bei Block 1974 und/oder die Entschlüsselung bei Block 1978 kann durch bekannte Techniken ausgeführt werden (zum Beispiel über Verschlüsselungs- und Entschlüsselungscodes), unter Verwenden von Hardware und/oder Software in dem verbesserten FaaS-System 300, und/oder Verwenden einer Kombination von Hardware- und Software-Verfahren. Das Verfahren 1970 kann daher die Sicherheit zum Reduzieren des Potenzials für das Zugreifen von Malware oder Drittparteien auf die Daten verbessern.
Zusätzliche Anmerkungen und Beispiele
Beispiel 1900 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, während der Ausführung einer ersten Funktion erste Daten, die mit der ersten Funktion assoziiert sind, in einer Datenlagerung zu speichern, wobei die ersten Daten in einem Cache der Datenlagerung gespeichert werden sollen, nachdem die erste Funktion abgeschlossen hat, die ersten Daten der ersten Funktion in der Datenlagerung während der Ausführung einer zweiten Funktion zu behalten, es der zweiten Funktion zu erlauben, auf die ersten Daten, die in der Datenlagerung gespeichert sind, zuzugreifen, eine Zeitspanne zu bestimmen, während der auf die ersten Daten in der Datenlagerung nicht zugegriffen wird, zu bestimmen, ob die Zeitspanne einem Time-To-Live-Schwellenwert der ersten Daten entspricht, die ersten Daten aus der Datenlagerung zu räumen, wenn die Zeitspanne dem Time-To-Live-Schwellenwert entspricht, als Reaktion darauf, dass die Zeitspanne dem Time-To-Live-Schwellenwert entspricht, die ersten Daten an einem zweiten Datenserver zu speichern, einen Deskriptor zu der zweiten Funktion weiterzugeben, wobei der Deskriptor einen Ort der ersten Daten angibt, und weiter einen Ort von Metadaten angibt, die mit den ersten Daten assoziiert sind, wobei die Metadaten einen oder mehrere anwendbarer Entschlüsselungscodes für das Entschlüsseln der ersten Daten enthalten sollen, falls die ersten Daten verschlüsselt sind, anwendbare Prüfcodes zum Prüfen der ersten Daten, falls die ersten Daten ein Fingerprinting aufweisen, oder Dekompressionscodes zum Dekomprimieren der ersten Daten, falls die ersten Daten komprimiert sind, Verschlüsseln der ersten Daten derart, dass die ersten Daten verschlüsselt werden, nachdem die erste Funktion die Ausführung abgeschlossen hat, und Entschlüsseln der ersten Daten, um es der zweiten Funktion zu erlauben, auf die ersten Daten zuzugreifen,
Beispiel 1901 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen beinhaltet, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät während der Ausführung einer ersten Funktion veranlassen, erste Daten, die mit der ersten Funktion assoziiert sind, in einer Datenlagerung zu speichern, nachdem die erste Funktion abgeschlossen wurde, die ersten Daten der ersten Funktion in der Datenlagerung zu behalten, und während der Ausführung einer zweiten Funktion der zweiten Funktion zu erlauben, auf die ersten Daten, die in der Datenlagerung gespeichert sind, zuzugreifen.
Beispiel 1902 kann das mindestens eine computerlesbare Medium des Beispiels 1901 beinhalten, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Zeitspanne, während der auf die ersten Daten in der Datenlagerung nicht zugegriffen wird, zu bestimmen.
Beispiel 1903 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1902, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, zu bestimmen, ob die Zeitspanne einem Time-To-Live-Schwellenwert der ersten Daten entspricht, und die ersten Daten aus der Datenlagerung zu räumen, wenn die Zeitspanne den Time-To-Live-Schwellenwert erfüllt.
Beispiel 1904 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1903, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, als Reaktion darauf, dass die Zeitspanne den Time-To-Live-Schwellenwert erfüllt, die ersten Daten an einem zweiten Datenserver zu speichern.
Beispiel 1905 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1901, wobei die ersten Daten in einem Cache der Datenlagerung gespeichert werden sollen.
Beispiel 1906 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 1901, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen Deskriptor zu der zweiten Funktion weiterzugeben, wobei der Deskriptor einen Ort der ersten Daten angibt, und weiter einen Ort von Metadaten, die mit den ersten Daten assoziiert sind, angibt, wobei die Metadaten einen oder mehrere anwendbare Entschlüsselungscodes zum Entschlüsseln der ersten Daten enthalten sollen, falls die ersten Daten verschlüsselt sind, anwendbare Prüfcodes zum Prüfen der ersten Daten, falls die ersten Daten Fingerprinting aufweisen, oder Dekompressionscode zum Dekomprimieren der ersten Daten, falls die ersten Daten komprimiert sind.
Beispiel 1907 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 1901, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die ersten Daten derart zu verschlüsseln, dass die ersten Daten verschlüsselt werden, nachdem die erste Funktion die Ausführung abgeschlossen hat, und die ersten Daten zu entschlüsseln, um es der zweiten Funktion zu erlauben, auf die ersten Daten zuzugreifen.
Function-as-a-Service-Umgebungen können einen Kompromiss zwischen Latenz und Ressourcenaufwand aufweisen. Das Bereitstellen eines kalten Containers kann groß angelegte hoch latente Datentransfers sowie den Aufbau des Containers basierend auf den Daten beinhalten. Das Beistellen des kalten Containers kann daher ein Vorgang mit hoher Latenz sein. Im Gegensatz dazu kann das Behalten eines warmen Containers ein Vorgang mit niedriger Latenz sein, da die oben stehenden Datentransfers und der Aufbau vermieden werden können. Das Behalten des warmen Containers kann übermäßige Rechenressourcen verbrauchen, die während längerer Zeitspannen im Ruhezustand bleiben und einen signifikanten Speicherfußabdruck aufweisen. Ein warmer Container kann zum Beispiel während des Wartens auf eine Funktion zur Ausführung nicht verwendet werden und im Ruhezustand bleiben. Der warme Container kann ferner signifikante Ressourcenzuordnungen zum Ausführen einer ankommenden Funktion aufweisen, während er im Ruhezustand bleibt und auf eine solche Funktion wartet.
Verbesserte FaaS-Architektur mit unterschiedlichen Modi
20A zeigt eine verbesserte FaaS-Server-Architektur 2000, bei der der Server 2002 eine Smart Network Interface Card (NIC) 2004 beinhaltet, die FaaS-Managementlogik 2006a beinhaltet. Bei einer anderen Ausführungsform kann die Logik 2006a in der Server-Architektur 2000 als Hardware umgesetzt werden, zum Beispiel in einem Prozessor, in einer Baseboard-Management-Steuervorrichtung, in einem Beschleuniger und/oder in einem FPGA usw. Der Server 2002 kann ferner FaaS-Managementlogik 2006b beinhalten, die in Verbindung und/oder Koordination mit der FaaS-Managementlogik 2006a arbeitet. Die FaaS-Managementlogik 2006b kann ein OS-Treiber oder Smart-Middleware des Servers 2002 sein. Die FaaS-Managementlogik 2006a, 2006b kann eine Änderung der Caching-Strategien derart ausführen, dass sich die FaaS-Server-Architektur 2000 an eine wachsende FaaS-Workload anpasst, indem sie mehr Speicherressourcen für dedizierte mit FaaS assoziierte Daten/Objekte wendet. Bei einigen Ausführungsformen kann der Server 2002 nur eine der FaaS-Managementlogik 2006a, 2006b statt beide beinhalten. So kann zum Beispiel nur die FaaS-Managementlogik 2006b enthalten sein, um die Caching-Strategien zu ändern. Solche Änderungen können zum Beispiel durch Programmieren eines oder mehrerer Konfigurationsregister, die die Caching-Strategien, die in einem Allzweck- oder einem Sonderzweck-Prozessor umgesetzt werden, erfolgen. Dediziertes Caching kann auch auf Software-verwaltete Ressourcen angewandt werden, wie Seitencaches; das Betriebssystem und die Laufzeit-Software können entsprechend den physischen Seiten-Pool in mindestens zwei Sub-Pools unterteilen: einer für allgemeine Verwendung, und eine für dedizierte FaaS-Verwendung, mit unterschiedlichen Größen für die Sub-Pools in Übereinstimmung damit, ob das System in dediziertem FaaS-Modus, Allzweckmodus oder Hybridmodus arbeiten soll. Cache, wie er in Bezug auf die 20A bis 20D verwendet wird, kann daher sowohl Softwareressourcen-Caches als auch Hardware-Caches beinhalten. Man versteht, dass sowohl Software-Ressourcen-Caches als auch Hardware-Caches Zugriff auf darunterliegenden Speicher (entweder direkt oder indirekt) reflektieren sollen.
Die FaaS-Managementlogik 2006a, 2006b kann bestimmen, ob der Server 2002 in drei oder mehreren unterschiedlichen Modi betrieben werden soll, einschließlich eines dedizierten FaaS-Modus, eines Allzweckmodus oder eines Hybrid-FaaS-Modus. Bei der Ausführungsform, die in 20A veranschaulicht ist, befindet sich der Server 2002 in einem Hybrid-FaaS-Modus. In dem Hybrid-FaaS-Modus werden nur einige der Caches 2008, 2010, 2012 in dedizierten FaaS-Modus platziert, während andere in Allzweckmodus platziert werden. In einem dedizierten FaaS-Modus ist jeder der Caches 2008, 2010, 2012 dem FaaS-Modus dediziert. Die Caches 2008, 2010, 2012 können sowohl Software-Ressourcen-Caches als auch Hardware-Caches beinhalten.
Die Serverarchitektur 2000 kann Latenz- und Ressourcenbetrachtungen durch den Hybrid- und den dedizierten FaaS-Modus für eine Plattform (zum Beispiel einen Server) ausgleichen. In dem Hybrid-FaaS-Modus können ein oder mehrere Caches, wie die dedizierten FaaS-Caches 2008, 2010, verwendet werden, um nur Datenobjekte, die mit einer oder mehreren Funktionen assoziiert sind, zu speichern. Alternativ kann ein dedizierter FaaS-Cache 2008 oder 2010 „Soft-Prioritäten“ derart umsetzen, dass Datenobjekte, die mit einer oder mehreren Funktionen verbunden sind, größere Cache-Residenzen erhalten. Solche Cache-Residenzen-Einstellungen können zum Beispiel durch Einsatz unterschiedlicher Alterungsstrategien für Daten, die von einer FaaS-Funktion zwischengespeichert werden, im Vergleich zu denen, die von herkömmlichen Anwendungen zwischengespeichert werden, ausgeführt werden. Bei einigen Ausführungsformen können daher die dedizierten FaaS-Caches 2008, 2010 FaaS-Datenobjekte gegenüber Nicht-FaaS-Datenobjekten derart priorisieren, dass die FaaS-Datenobjekte wahrscheinlicher in den dedizierten FaaS-Caches 2008, 2010 gespeichert werden. Bei einigen Ausführungsformen können die dedizierten FaaS-Caches 2008, 2010 mindestens einige der Daten zum Aufbauen eines Containers speichern. Bei einigen Ausführungsformen können die dedizierten FaaS-Caches 2008, 2010 zum Speichern von Daten des Containers, die benötigt werden, um den Container zu initialisieren, dediziert werden.
Einige Ausführungsformen können Latenz für Initialisierung kalter Container reduzieren, da Datentransfers zwischen unterschiedlichen Knoten vermieden werden können, und der Containeraufbau basierend auf lokal zwischengespeicherten Daten beginnen kann. Der Container und die Funktionsinitialisierung können nämlich beschleunigt werden. Wie unten beschrieben, kann die Initialisierung einer Funktion das Aufbauen des Containers und das Starten der Ausführung der Funktion in dem Container beinhalten. Die Initialisierung und/oder der Aufbau des Containers können beide den Aufbau von Abschnitten, die von Funktionsdaten unabhängig sind, die cachefähig sind, und den Aufbau zusätzlicher Funktionsdaten spezifischer Abschnitte des Containers, die nicht cachefähig sind, beinhalten.
Einige Ausführungsformen können einen „Just-in-Time-Ansatz“ für Container einsetzen. Wie oben beschrieben, können Startup-Latenzen der Container reduziert werden. Wenn sie benötigt werden, können Container rasch „Just-in-Time“ aus den Daten in den dedizierten FaaS-Caches 2008, 2010 reinitialisiert werden, um die Latenzanforderungen der Funktionen zu erfüllen. Ein „Just-in-Time“-Ansatz zur Containerinitialisierung kann daher eingesetzt werden, um Nutzung warmer Container zu reduzieren, da eine Anzahl warmer Container (zum Beispiel Container, die keine Funktionen ausführen und auf eine Funktion warten) reduziert werden kann.
Das Reduzieren der Nutzung warmer Container kann die Ressourcenzuordnungen durch einen reduzierten Ressourcen-Fußabdruck warmer Container verbessern. Wenn weniger oder kleinere warme Container auf Standby gehalten werden können, können Ressourcen freigegeben und aktiven Containern dediziert werden (die als heiße Container bezeichnet werden können), die Funktionen ausführen. Mehr Funktionen können daher mit weniger Ressourcen unterstützt werden, Ausführung durch gesteigertes Ressourcenzuordnungen abschließen und akzeptable Latenzanforderungen wahren.
Wie in 20A veranschaulicht, kann der Server 2002 drei Caches 2008, 2010, 2012 beinhalten. In dem Hybrid-FaaS-Modus können zwei der Caches 2008, 2010 als dedizierte FaaS-Caches arbeiten. Die dedizierten FaaS-Caches 2008, 2010 können Initialisierungsdaten zum Aufbauen eines oder mehrerer Container speichern. Der eine oder die mehreren Container können lokal in dem Server 2002 aufgebaut werden. Statt alle der Daten von einem entfernten Knoten zum Versorgen eines Containers zu empfangen, kann der Server 2002 daher auf die dedizierten FaaS-Caches 2008, 2010 zugreifen. Darüber hinaus braucht der Server 2002 eventuell keine warmen Container für einige Funktionen zu wahren, wodurch Ressourcenzuordnungen von Hardware-Bauelementen, wie Beschleunigern, Speicher, FPGAs, Prozessoren und so fort zu warmen Containern reduziert werden. Der Server 2002 kann daher aktivere (heiße) Container unterstützen und Funktionsausführungen durch verbesserte Ressourcenzuordnungen und einen „Just-in-Time-Ansatz“ für Containerinitialisierung beschleunigen.
Bei einigen Ausführungsformen können die dedizierten FaaS-Caches 2008, 2010 nur einen Teil der gesamten Daten, die zum Initiieren eines Containers benötigt werden, speichern. Der Server 2002 kann zum Beispiel mehrere unterschiedliche Bauelemente des Containers in serieller Reihenfolge aufbauen. Die Initialisierungsdaten in den dedizierten FaaS-Caches 2008, 2010 können Daten zum Aufbauen der anfänglichen Bauelemente des Containers sein, wobei Daten zum Aufbauen der anderen späteren Komponenten zu dem Server 2002 von einem entfernten Knoten übertragen werden. Der Container kann daher einen anfänglichen Abschnitt des Aufbauprozesses basierend auf den Initialisierungsdaten, die in den dedizierten FaaS-Caches 2008, 2010 gespeichert sind, starten. Gleichzeitig mit dem anfänglichen Abschnitt des Aufbauprozesses kann das Server 2002 Daten für einen späteren Abschnitt des Aufbauprozesses von einem entfernten Knoten empfangen und dann den Aufbauprozess basierend auf den empfangenen Daten abschließen.
Bei einigen Ausführungsformen können die dedizierten FaaS-Caches 2008, 2010 nur Datenobjekte, die mit den Funktionen assoziiert sind, speichern, wodurch die Funktionsinitialisierung beschleunigt wird. Die dedizierten FaaS-Caches 2008, 2010 können zum Beispiel nur Initialisierungsdaten für Container speichern. Andere Caches, wie ein Allzweck-Cache 2012, können Daten speichern, die von der Funktion während der Ausführung der Funktion erzeugt werden.
Das FaaS-Management 2006a, 2006b kann bestimmen, wann der Server 2002 in dem dedizierten FaaS-Modus, dem Allzweckmodus oder dem Hybrid-FaaS-Modus betrieben werden soll. Das FaaS-Management 2006a, 2006b kann zum Beispiel historische Daten einsetzen, um zu bestimmen, ob in den dedizierten FaaS-Modus oder den Hybrid-FaaS-Modus umgewechselt werden soll. Die historischen Daten können zum Beispiel angeben, dass der Server 2002 einen Funktionstyp eine Anzahl von Malen ausgeführt hat. Im Einzelnen kann das FaaS-Management 2006a, 2006b jede Funktion in einen Funktionstyp kategorisieren. Funktionen können als derselbe Funktionstyp betrachtet werden, falls die Funktionen jeweils in demselben Container ausführbar sind. Das FaaS-Management 2006a, 2006b kann die Anzahl von Malen mit einer vorbestimmten Anzahl vergleichen und bestimmen, dass in den dedizierten FaaS-Modus oder Hybrid-FaaS-Modus eingestiegen werden sollte, falls die Anzahl von Malen größer ist als die vorbestimmte Anzahl.
Bei einigen Ausführungsformen können die historischen Daten nur Funktionstypen beinhalten, die innerhalb eines Zeitfensters, zum Beispiel den vorhergehenden 5 Millisekunden, aufgerufen wurden. Zusätzlich zu historischen Daten, die die obigen Entscheidungen über den Modus des Servers 2002, Strategien, Service-Level-Vertragsbetrachtungen und explizite Anweisungen von einem Orchestrator motivieren, können die Bestimmungen zum Erhöhen oder Reduzieren der Größe und der Menge dedizierter FaaS-Caches beeinflussen. Ferner kann die Smart-NIC 2004 eine spontane Bestimmung über das Holen zwischengespeicherter FaaS-Daten aus einer Peer-Maschine und/oder den Caches 2008, 2010, 2012 ausführen. Auf ähnliche Weise kann FaaS-Management-Logik 2006a, 2006b in einem verbesserten FaaS-System 300 und in Elementen wie CPU 308, Beschleuniger 314, FPGA 318 umgesetzt werden und spontane Bestimmung über das Holen zwischengespeicherter FaaS-Daten aus einer Peer-Maschine und/oder den Caches 2008, 2010, 2012 auszuführen. Auf diese Art kann Software nichts darüber wissen, wie FaaS-Objekte in Caches, einschließlich der Caches 2008, 2010, 2012, auf einen Satz von vernetzten Servern 2002 verteilt werden.
Wie oben bemerkt, können die dedizierten FaaS-Caches 2008, 2010 mit dem Allzweck-Cache 2012 in dem Hybrid-Modus gemeinsam existieren. Bei dem obigen Beispiel können somit zwei der Caches 2008, 2010 dem FaaS-Cache gewidmet sein, während der Cache 2012 als ein Allzweck-Cache eingesetzt wird. Wenn daher der FaaS-Abschnitt der Workload auf dem 2002 zunimmt, können die Anzahl und/oder die Aggregatsgrößen der dedizierten FaaS-Caches von den Caches 2008, 2010, 2012 entsprechend zunehmen. Später, wenn der FaaS-Abschnitt zurückgeht, existiert entweder ein sehr kleiner der FaaS-Caches von den Caches 2008, 2010, 2012 weiterhin, oder alle Caches 2008, 2010, 2012 werden Allzweck-Caches mit keiner Unterscheidung zwischen FaaS-Zwischenspeichern und Nicht-FaaS-Seiten, Dateien usw.
Bei einigen Ausführungsformen kann das FaaS-Management 2006a, 2006b eine Meldung von einem Scheduler 2014 empfangen, um zu bestimmen, ob in den dedizierten FaaS-Modus, den Allzweckmodus oder den Hybrid-FaaS-Modus eingetreten werden soll. Der Scheduler 2014 kann von dem Server 2002 entfernt sein, zum Beispiel in einem Steuerknoten. Bei einigen Ausführungsformen kann der Server 2002 den Scheduler 2014 beinhalten. Der Scheduler 2014 kann das FaaS-Management 2006a, 2006b anweisen, in den dedizierten FaaS-Modus, den Hybridmodus oder in den Allzweckmodus basierend auf historischen Daten, die diese Entscheidungen motivieren, Strategien, System-Level-Vertragsbetrachtungen sowie expliziten Anweisungen von einem Orchestrator einzutreten.
Bei einigen Ausführungsformen kann der Scheduler 2014 ferner das FaaS-Management 2006a, 2006b anweisen, dass spezifische Containerdaten in den dedizierten FaaS-Caches 2008, 2010 gespeichert werden sollten. Der Scheduler 2014 kann zum Beispiel bestimmen, dass ein bestimmter Container von mehreren Funktionen einzusetzen ist, und kann folglich das FaaS-Management 2006a, 2006b anweisen, dass Initialisierungsdaten für den Container in den dedizierten FaaS-Caches 2008, 2010 zur Wiederverwendung durch die Funktionen gespeichert werden sollen.
Darüber hinaus kann der Scheduler 2014 das FaaS-Management 2006a, 2006b anweisen, aus dem Hybrid-FaaS-Modus auszutreten und in den Allzweckmodus basierend teilweise als Reaktion darauf, dass eine Funktion eine Ausführung abschließt, einzutreten. Der Scheduler 2014 kann aus der Funktionssteuerflussgrafik, aus gesammelten Statistiken und Workload-Vorhersageregeln, die in den Scheduler 2014 eingebaut sind, bestimmen, dass die Initialisierungsdaten in den dedizierten FaaS-Caches 2008, 2010 nicht weiter von Funktionen, die die Ausführung abgeschlossen haben, eingesetzt werden, und/oder dass es weniger wahrscheinlich oder unwahrscheinlich ist, dass sie starker Nachfrage unterliegen, und folglich das FaaS-Management 2006 anweisen, aus dem dedizierten FaaS-Modus oder Hybrid-FaaS-Modus auszutreten und in einen Allzweckmodus oder Hybrid-FaaS-Modus einzutreten. Der Rest der Funktionen in der Funktionssteuergrafik kann zum Beispiel basierend auf vergangenen Historien vorweggenommen werden, kann zur Ausführung in Containern befördert werden, die von einem Container, der mit Initialisierungsdaten, die in den dedizierten FaaS-Caches 2008, 2010 gespeichert sind, unterschiedlich sind, verbunden sind, ohne erhebliches Risiko für ihre Performance oder Effizienz. Sobald der Hybrid-FaaS-Modus verlassen wurde, können die dedizierten FaaS-Caches 2008, 2010 neu zugeordnet und als Allzweck-Caches in dem Allzweckmodus eingesetzt werden.
Bei einigen Ausführungsformen kann der Scheduler 2014 und/oder das FaaS-Management 2006a, 2006b eine Auslastung der FaaS-Server-Architektur 2000 identifizieren. Falls die Auslastung über einem bestimmten Schwellenwert liegt, kann in den dedizierten FaaS-Modus oder Hybrid-FaaS-Modus eingetreten werden, um Ressourcen und Latenz effektiv auszugleichen. Falls die Auslastung unter den Schwellenwert sinkt, können der dedizierte FaaS- oder der Hybrid-FaaS-Modus verlassen werden, und es kann in den Hybrid-FaaS-Modus oder Allzweckmodus eingetreten werden. Falls die Auslastung fällt, kann zum Beispiel der dedizierte FaaS-Modus zu dem Hybrid-FaaS-Modus wechseln, und falls die Last weiter fällt, wechselt der Hybrid-FaaS-Modus zu dem Allzweckmodus. Die Auslastung kann anhand einer Anzahl aktuell in Ausführung befindlicher Funktionen, von Datenzugriffen, Kommunikationsanforderungen und/oder anderen Messungen gemessen werden. Bei einigen Ausführungsformen kann die Auslastung von dem Scheduler 2014 und/oder dem FaaS-Managementlogik 2006a, 2006b basierend auf Steuerflussgrafiken vorhergesagt werden. Der Scheduler 2014 kann zum Beispiel basierend auf den Steuerflussgrafiken und/oder auf statistischer Analyse dazu, wie oft die Aktivierung eines Typs von Funktionen zu der Aktivierung desselben oder eines anderen Funktionstyps geführt hat, vorhersagen, ob mehrere Funktionen gleichzeitig arbeiten werden.
Bei einigen Ausführungsformen kann der Server 2002 den Hybrid-FaaS-Modus verlassen und in den Allzweckmodus als Reaktion auf eine Identifikation, dass der Server 2002 keine ausreichend hohe Anzahl von Anforderungen von FaaS-Anwendungen verarbeiten wird, eintreten. Wenn der Scheduler 2014 zum Beispiel bestimmen kann, dass der Server 2002 keine große Anzahl von Anforderungen von FaaS-Anwendungen mehr zu verarbeiten braucht, und den Server 2002 veranlassen, aus dem Hybrid-FaaS-Modus auszutreten.
Bei einigen Ausführungsformen kann der Server 2002 aus dem Hybrid-FaaS-Modus austreten und in den Allzweckmodus als Reaktion auf eine Identifikation, dass eine Time-To-Live der Initialisierungsdaten in den dedizierten FaaS-Caches 2008, 2010 abgelaufen ist, eintreten. Das FaaS-Managementlogik 2006a, 2006b kann zum Beispiel einen Zähler führen, um eine Zeitmenge zu bestimmen, während der die Initialisierungsdaten nicht verwendet werden und/oder nicht zum Aufbauen eines Containers verwendet werden. Das FaaS-Management 2006a, 2006b kann bestimmen, ob die Zeitmenge einen Time-To-Live-Schwellenwert überschreitet und/oder erfüllt. Falls die Zeitmenge den Schwellenwert überschreitet und/oder erfüllt, kann das FaaS-Management 2006a, 2006b automatisch aus dem Hybrid-FaaS-Modus austreten und in den Allzweckmodus eintreten.
Mehrere der obigen Ausführungsformen beschreiben das Austreten aus dem dedizierten FaaS-Modus und/oder Hybrid-FaaS-Modus basierend auf bestimmten Bedingungen (zum Beispiel Identifikation, dass eine Time-To-Live abgelaufen ist, ein Auslastungsabfall, Analyse vergangener Steuerflussgrafiken, Aktivierung von Sequenzen usw.). Bei einigen Ausführungsformen können statt sofort aus dem Hybrid-FaaS-Modus auszutreten, die Initialisierungsdaten in den dedizierten FaaS-Caches 2008, 2010 freigegeben und dann mit neuen Initialisierungsdaten ersetzt werden. Wenn zum Beispiel eine der Bedingungen erfüllt wird, können der Scheduler 2014 und/oder der Server 2002 bestimmen, ob unterschiedliche Initialisierungsdaten in den dedizierten FaaS-Caches 2008, 2010 gespeichert werden sollen.
Der Scheduler 2014 kann zum Beispiel aus einer Steuerflussgrafik bestimmen, dass die Initialisierungsdaten, die in den dedizierten FaaS-Caches 2008, 2010 gespeichert sind, nicht mehr relevant sind. Der Scheduler 2014 kann nämlich bestimmen, dass ein erster Container, der aus den Initialisierungsdaten aufgebaut ist, nicht mehr verwendet werden wird oder selten verwendet werden wird. Statt sofort aus dem Hybrid-FaaS-Modus auszutreten, kann der Scheduler 2014 die Steuerflussgrafik und/oder historische Daten referenzieren und bestimmen, ob ein zweiter Container verwendet werden soll. Ist das der Fall, kann der Scheduler 2014 das FaaS-Management 2006a, 2006b anweisen, die Initialisierungsdaten für den ersten Container zu löschen und Initialisierungsdaten für den zweiten Container in den dedizierten FaaS-Caches 2008, 2010 zu speichern. Falls der Scheduler 2014 jedoch bestimmt, dass keine anderen Initialisierungsdaten in den dedizierten FaaS-Caches 2008, 2010 gespeichert werden sollen, kann aus dem Hybrid-FaaS-Modus ausgetreten werden.
Bei einigen Ausführungsformen kann ein Betriebssystem des Servers 2002 bestimmen, wann in den dedizierten FaaS-Modus, Hybrid-FaaS-Modus, Allzweckmodus eingestiegen wird und der dedizierte FaaS-Modus, Allzweckmodus, wie oben in Bezugnahme auf den Server 2002 und/oder Scheduler 2014 beschrieben, verlassen wird. Bei einigen Ausführungsformen können die dedizierten FaaS-Caches 2008, 2010 Hardware-Caches sein. Bei einigen Ausführungsformen können die dedizierten FaaS-Caches 2008, 2010 Software-Caches sein, einschließlich aber nicht beschränkt auf Seitencaches.
Ausführungsformen, die den Server 2002 beinhalten, können eine Anzahl von Funktionen, die auf dem Server 2002 innerhalb eines gegebenen Zeitrahmens ausgeführt werden können, erhöhen. Außerdem können eine Latenz (zum Beispiel Zeit) für das Setup der Ausführungsumgebung und das Laufen einer Funktion (Startup-Zeit) sowie der Speicher, den die Funktion verbraucht, Faktoren sein, die eine Anzahl von Funktionen, die auf dem Server 2002 ausgeführt werden kann, bestimmen. Wie oben beschrieben, kann das Behalten der Ressourcen zum Ausführen einer Funktion bereit in dem Speicher (zum Beispiel ein warmer Container) eingesetzt werden, um die Startup-Zeit zu reduzieren. Um mit dem potenziell erhöhten Speicherfußabdruck und Ressourcenzuordnungen eines warmen Containers umzugehen, können einige Ausführungsformen dedizierte FaaS-Caches 2008, 2010 absondern, um nur die Ressourcen zum Hochfahren von Funktionen und/oder Containern für die Funktionen zu speichern, um den Speicherfußabdruck und die Speicherzuordnungen zu reduzieren. Die Ressourcenauseinandersetzung wird daher reduziert, und die Startup-Zeit von Funktionen wird beschleunigt. Die dedizierten FaaS-Caches 2008, 2010 können adaptiv freigegeben werden, wenn der Server 2002 nicht verwendet wird, um FaaS-Anwendungen zu verarbeiten, oder keine signifikante Auslastung besteht.
20B zeigt eine verbesserte FaaS-Server-Architektur 2020, bei der sich ein Server 2022 in einem allgemeinen Modus, wie oben unter Bezugnahme auf 20A beschrieben, befindet. Wie veranschaulicht, werden die drei Caches 2028, 2030, 2032 in einem Allzweckmodus betrieben. Die Allzweck-Caches 2028, 2030, 2032 können Datenobjekte speichern, können aber nicht dem Speichern FaaS-bezogener Objekte dediziert werden. Es kann für die Allzweck-Caches 2028, 2030, 2032 immer noch möglich sein, FaaS-bezogene Objekte zu speichern und außerdem Allzweck-Datenobjekte zu speichern.
Bei einigen Ausführungsformen wird FaaS-Managementlogik 2026a in 20B in einer Smart-NIC 2024 umgesetzt. Bei einigen Ausführungsform kann die Logik 2026a in der Server-Architektur 2000 alternativ als Hardware umgesetzt werden, zum Beispiel in einem Prozessor, in einer Baseboard-Management-Steuervorrichtung, in einem Beschleuniger und/oder in einem FPGA usw. Der Server 2002 kann ferner FaaS-Managementlogik 2026b beinhalten, die in Verbindung und/oder Koordination mit der FaaS-Managementlogik 2026a arbeitet. Die FaaS-Managementlogik 2026b kann ein OS-Treiber oder Smart-Middleware des Servers 2022 sein. Das FaaS-Management 2026a, 2026b kann den Server 2022 zwischen dem Allzweckmodus, dem Hybrid-Modus und dem dedizierten FaaS-Modus wechseln zu lassen. Das FaaS-Management 2026a, 2026b kann zum Beispiel Anweisungen von dem Scheduler 2034 zum Wechseln zwischen dem Allzweckmodus und dem dedizierten FaaS-Modus empfangen. Wenn der Server 2022 auf den Hybridmodus wechselt, kann der Server 2022 dem Server 2002 ähneln und auf ähnliche Weise arbeiten wie oben unter Bezugnahme auf 20A beschrieben. Wenn der Server 2022 auf den dedizierten FaaS-Modus wechselt, kann jeder der Caches 2028, 2030, 2032 als ein dedizierter FaaS-Cache arbeiten.
20C zeigt eine Grafik 2040, die Datenvolumen von Datenobjekten veranschaulicht. Die Grafik 2040 veranschaulicht eine Beziehung diverser Datenobjekte (X-Achse) mit einer Datenmenge (Y-Achse). Ein heißer Container kann gerade eine Funktion ausführen. Das Datenvolumen 2042 des heißen Containers ist am größten. Ein warmer Container kann im Ruhezustand sein, um aktuell keine Funktion auszuführen. Das Datenvolumen 2044 eines warmen Containers ist geringer als das Datenvolumen 2042 des heißen Containers. Initialisierungsdaten können Daten sein, die benötigt werden, um einen Container, wie oben unter Bezugnahme auf die 20A und 20B beschrieben, zu initiieren. Das Initialisierungsdatenvolumen 2046 kann das Geringste sein. Ein Vergleich des Datenvolumens 2044 des warmen Containers mit dem Initialisierungsdatenvolumen 2046 veranschaulicht daher, dass eine Speicherfußabdruckverbesserung erzielt werden kann, indem ein warmer Container 2044, in dem Initialisierungsdaten in einem oder mehreren dedizierten Caches gespeichert sind, abgebaut und ein Container aus den Initialisierungsdaten neu initialisiert wird.
Bei einigen Ausführungsformen können die Initialisierungsdaten, die von dem Initialisierungsdatenvolumen 2046 dargestellt werden, Daten sein, die für das Initialisieren mehr als eines Containers gemeinsam sind. Mehrere Container können daher aus den Initialisierungsdaten initialisiert werden. Eine solche Gemeinsamkeit kann einen Speicherfußabdruck reduzieren, der durch Speichern der Initialisierungsdaten in einem dedizierten Cache an Stelle des Führens der Daten in warmen Containern erzielt werden kann. Container können zum Beispiel aus den Initialisierungsdaten initialisiert werden. Das Bewahren jedes dieser Container als warme Container würde Aufwand für mehrere warme Container erzeugen. Der Aufwand kann mindestens das Datenvolumen 2044 eines warmen Containers multipliziert mit der Anzahl warmer Container beinhalten. Im Gegensatz dazu braucht nur eine Kopie der Initialisierungsdaten zu existieren, um jeden dieser warmen Container zu initiieren. Indem warme Container nicht gewahrt werden und statt die Initialisierungsdaten zu führen, wird daher Speicheraufwand signifikant reduziert.
20D zeigt ein Verfahren 2050 eines verbesserten Funktionsressourcenmanagements und kann von dem verbesserten FaaS-System 2000, 2020 der 20A und 20B und/oder von einem oder mehreren Modulen als ein Satz von Logikanweisungen umgesetzt werden, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 2052 bestimmt, dass in einen Funktionsmodus für einen Server eingetreten wird, zum Beispiel durch FaaS-Managementlogik 2006a oder 2006b. Der Funktionsmodus kann ein dedizierter FaaS-Modus oder Hybrid-FaaS-Modus, wie oben beschrieben, sein. Der Server kann eine Vielzahl von Caches beinhalten. Der veranschaulichte Verarbeitungsblock 2054 setzt als Reaktion darauf, dass in den Funktionsmodus eingetreten wird, einen oder mehrere Caches der Vielzahl von Caches als einen dedizierten Function-as-a-Service-Cache zum Speichern von Initialisierungsdaten ein. Initialisierungsdaten können eingesetzt werden, um eine Ausführung einer Funktion zu initiieren. Bei einigen Ausführungsformen können die Initialisierungsdaten nur ein Teil eines Gesamtdatensatzes zum Initiieren der Funktion sein. Der veranschaulichte Verarbeitungsblock 2056 kann die Funktion basierend auf Initialisierungsdaten, die in dem einen oder den mehreren dedizierten Function-as-a-Service-Caches zwischengespeichert sind, initialisieren. Die Initialisierungsdaten können zum Beispiel eingesetzt werden, um einen Container aufzubauen, um die Funktion auszuführen. Der veranschaulichte Verarbeitungsblock 2058 kann aus dem Funktionsmodus basierend auf einer Identifikation einer oder mehrerer reduzierter Nachfragen nach warmen Containern, reduzierter Rate von Funktionsaktivierungen oder reduzierten projizierten Funktionsaktivierungen austreten. Der veranschaulichte Verarbeitungsblock 2058 kann den einen oder die mehreren Caches davon freigeben, für die Initialisierungsdaten dediziert zu sein und/oder in einen Allzweckmodus einzutreten. Der eine oder die mehreren Caches können zum Beispiel als Allzweck-Caches eingesetzt werden, statt als Function-as-a-Service-Caches eingesetzt zu werden. Das Verfahren 2050 kann Ressourcennutzung verbessern und Latenz von Funktionen, wie oben beschrieben, verringern.
Zusätzliche Anmerkungen und Beispiele
Beispiel 2000 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät dazu veranlassen, zu bestimmen, dass in einen Funktionsmodus des Rechengeräts eingetreten wird, einen oder mehrere Caches der Mehrzahl von Caches als einen dedizierten Function-as-a-Service-Cache zum Speichern von Initialisierungsdaten einzusetzen, wobei die Initialisierungsdaten dazu eingesetzt werden sollen, eine Ausführung einer Funktion zu initiieren, wobei die Initialisierungsdaten nur ein Teil eines Gesamtdatensatzes zum Initiieren eine Ausführung der Funktion sind, wobei die Initialisierungsdaten dazu eingesetzt werden sollen, einen Container aufzubauen, um die Funktion auszuführen, die Funktion basierend auf Initialisierungsdaten, die in dem einen oder den mehreren dedizierten Function-as-a-Service-Caches zwischengespeichert sind, zu initialisieren, aus dem Funktionsmodus basierend auf einer Identifikation einer oder mehrerer reduzierter Nachfrage nach warmen Containern, reduzierter Rate von Funktionsaktivitäten oder reduzierten projizierten Funktionsaktivierungen, als Reaktion auf das Austreten aus dem Funktionsmodus auszutreten, den einen oder die mehreren Caches davon freizugeben, den Initialisierungsdaten dediziert zu sein, und als Reaktion auf das Austreten aus dem Funktionsmodus den einen oder die mehreren Caches als einen Allzweck-Hardware-Cache zu verwenden.
Beispiel 2001 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, zu bestimmen, dass in einen Funktionsmodus für das Rechengerät eingetreten wird, wobei das Rechengerät eine Vielzahl von Caches beinhaltet, als Reaktion darauf, dass in den Funktionsmodus eingetreten wird, einen oder mehrere Caches der Vielzahl von Caches als dedizierte Function-as-a-Service-Caches einzusetzen, um Initialisierungsdaten zu speichern, wobei die Initialisierungsdaten dazu eingesetzt werden sollen, eine Ausführung einer Funktion zu initiieren, und die Funktion basierend auf Initialisierungsdaten, die in dem einen oder den mehreren dedizierten Function-as-a-Service-Caches zwischengespeichert sind, zu initialisieren.
Beispiel 2002 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 2001, wobei die Initialisierungsdaten nur ein Teil eines Gesamtdatensatzes zum Initiieren der Funktion sind.
Beispiel 2003 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 2002, wobei die Initialisierungsdaten dazu eingesetzt werden sollen, einen Container aufzubauen, um die Funktion auszuführen.
Beispiel 2004 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 2001, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von dem Rechengerät ausgeführt werden, das Rechengerät veranlassen, aus dem Funktionsmodus basiert auf einer Identifikation eines oder mehrerer von reduzierter Nachfrage nach warmen Containern, reduzierter Rate von Funktionsaktivierungen oder reduzierten projizierten Funktionsaktivierungen auszutreten.
Beispiel 2005 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 2004, das einen weiteren Satz von Anweisungen umfasst die, wenn sie von dem Rechengerät ausgeführt werden, das Rechengerät veranlassen, als Reaktion darauf, dass aus dem Funktionsmodus ausgetreten wird, den einen oder die mehreren Caches davon freizugeben, den Initialisierungsdaten dediziert zu sein.
Beispiel 2006 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 2005, das einen weiteren Satz von Anweisungen umfasst die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, als Reaktion darauf, dass aus dem Funktionsmodus ausgetreten wird, den einen oder die mehreren Caches als Allzweck-Hardware-Caches einzusetzen.
Adressraumbasierte QoS
In einer FaaS-Umgebung ist es wichtig fähig zu sein, Anwendungen, Threads oder virtuelle Maschinen (VMs) zu priorisieren. Existierende Ansätze, die von Software (OS/VMM) zu Hardware angeben, welche Anwendungen oder VMs hohe/mittlere/niedrige Priorität aufweisen, sind ungenau und ressourcenintensiv.
Ein Beispiel existierender Lösungen des Priorisierens von Anwendungen, Threads und/oder VMs ist eine Schnittstelle, die auf Serviceklasse-Thread (Class of Service - CLOS-Thread) basiert. Während eine Schnittstelle, die auf CLOS-Thread basiert, praktisch sein kann, derzeit eingesetzt und weitgehend akzeptiert wird, weist sie mindestens zwei Nachteile auf, nämlich (1) den Mangel an Präzision - man kann nicht spezifizieren, wie jede Cache-Zeile in der Plattform behandelt werden sollte, und (2) den Aufwand beim Wechseln des CLOS bei jedem Kontextwechsel. Einige beispielhafte Ausführungsformen einer verbesserten FaaS-Lösung können technische Lösungen bereitstellen, die präziser und in Bezug auf die Ressourcen, die nötig sind, um anzugeben, welche Anwendungen oder VMs hohe/mittlere/niedrige Priorität aufweisen, weniger kostspielig sind.
Beispielhafte Ausführungsformen der verbesserten FaaS-Lösung stellen Sicht und Kontrolle darüber bereit, wie gemeinsam verwendete Ressourcen, wie Last-Level-Cache (LLC) und Speicherbandbreite von Anwendungen, VMs und Containern (zum Beispiel RDT oder Platform Quality of Service) verwendet werden. Eine Erweiterung solcher Technologie kann gebaut werden, um adressbasierte QoS zu aktivieren, bei welchen entweder (1) spezifische Bereiche eines Adressraums mit einer Serviceklasse (CLOS) gekennzeichnet werden, oder (2) individuelle Seiten durch Hinzufügen von Per-Seite-Attributen gemanagt werden können. Adressraumbasierte QoS kann durch Spezifikation von Adressbereichen in dem Stil von Speichertyp und Bereichsregistern (Memory Type and Range Registers - MTRRs) oder schutzschlüsselähnlichen Ansätzen entwickelt werden, wobei ein Bereich durch Basis- und Limit-Steuerregister (Control Registers - CRs) oder modellspezifische Register (Model-Specific Registers - MSRs) spezifiziert wird. In einem solchen Fall können entweder existierende Bereichsregister wiederverwendet werden, oder neue können eingeführt werden, solange jedes Bereichsregister mit einer CLOS assoziiert ist, um Kennzeichnen zu ermöglichen. Bei einigen Ausführungsformen können andere Mechanismen zum Kennzeichnen und Filtern verwendet werden, zum Beispiel kann Software eine Bereichs-Tag-Tabelle populieren, die mit einem Cache durch Hardware-Mechanismen in Prozessoren, Speicherkontrollen oder Address Translation Services (ATS) durch diverse DMAfähige Vorrichtungen beschleunigt wird.
Eine CLOS kann ein Software-zugewiesenes Tag sein, in das Threads/Apps/VMs/Container gruppiert werden können. Dieses Tag kann jedes Mal in ein MSR gewechselt werden, wenn ein Software-Threads oder eine vCPU beginnt, auf einem Hardware-Logik-Thread zu laufen (zum Beispiel gleichzeitiger Multithreading-Thread (SMT-Thread) auf einem Kern). Software kann flexibel null oder mehr Threads in eine CLOS zuweisen, dann Plattform-Ressourcen, wie Cache-Kapazität an dem LLC oder Speicherbandbreite kann für jede CLOS festgelegt werden (wieder durch das OS/VMM, um Priorisierungsbedürfnisse zu erfüllen). Eine solche Zuweisung kann über eines der FaaS-Systeme 400 oder 500 jeweils in den 4 und 5 zugewiesen werden.
Bei einer beispielhaften Umsetzung kann jeder Seitentabelleneintrag mit einem CLOS-Tag erweitert werden. Während eine CPU Seitentabellen während eines Adressumsetzpuffer-Miss (Translation Lookaside Buffer - TLB-Miss) durchquert, kann das CLOS-Attribut abgerufen und verwendet und in den TLBs zwischengespeichert werden. Das bedeutet, dass für jede Zeile auf jeder Seite, auf die zugegriffen wird, eine CLOS bereitgestellt werden kann, um feineres QoS-Kennzeichnen als früher möglich war, zu ermöglichen.
Während auf Threads basierendes Kennzeichnen heute entwickelt werden kann und funktionieren kann, um FaaS-Threads untereinander zu priorisieren, kann es das Konzept des bereichs- oder adressbasierten Tagging-Daten innerhalb von FaaS-Threads ermöglichen, auch priorisiert zu werden, was besser zu der feinen Beschaffenheit von FaaS passen kann. Es kann auch technische Vorteile von adressbasiertem Tagging bei anderen Nutzungen, wie IoT, industrieller Automatisierung, Bewegungssteuerung und Echtzeit-Computing, geben, bei welchen Schlüsselspeicherbereiche priorisiert oder in dem Cache „pseudo-gepinnt“ werden können, wodurch feinere Kontrollen als früher verfügbar ermöglicht werden.
Während des Entwicklungsprozesses kann der oben beschriebene Ansatz in eine Toolchain integriert werden, und kritische Daten können in einem speziellen Abschnitt eines Linker-Script gekennzeichnet werden, was es adressraumbasierter QoS ermöglicht, Priorisierung sicherzustellen. Auf ähnliche Weise können bekannte Streaming-Daten (die einen Cache verunreinigen könnten) entpriorisiert werden. Für spezialisierte Nutzungen können adressraumbasierte QoS zusätzlichen Nutzen zu existierenden threadbasierten Tagging-Techniken bereitstellen.
Bei einer Ausführungsform kann ein elektronisches Verarbeitungssystem ähnlich oder gleich wie das in Verbindung mit 8A beschriebene einen Prozessor, Speicher, der kommunikationsfähig mit dem Prozessor gekoppelt ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher gekoppelt ist, beinhalten, um Vorgänge zum Priorisieren von Software oder Software-Threads auszuführen. Bei einigen Ausführungsformen kann sich die Logik in oder gemeinsam mit diversen Bauelementen, einschließlich des Prozessors, des Speichers usw. (zum Beispiel auf demselben Die) befinden.
Bei einer anderen Ausführungsform kann ein Halbleiter-Package-Gerät, das ähnlich oder gleich ist wie das in Verbindung mit 8B beschriebene, ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, beinhalten, wobei die Logik mindestens teilweise in einer oder mehreren von konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt wird. Die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, kann dazu konfiguriert sein, Vorgänge zum Priorisieren von Software oder Software-Threads auszuführen. Bei einigen Ausführungsformen kann die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche beinhalten, die innerhalb des einen oder der mehreren Substrate positioniert sind.
Unter Bezugnahme auf 21A veranschaulicht diese Figur ein Verfahren 2150 zum Priorisieren eine Software-Thread gemäß einer Ausführungsform. Das Verfahren 2150 beinhaltet in Block 2152 einen Vorgang zum Bestimmen, ob ein Software-Thread auf einem logischen Hardware-Thread läuft. Bei Block 2154 kann ein Tag in ein Register gewechselt werden, wenn der Software-Thread auf dem logischen Hardware-Thread (zum Beispiel einem Prozessorkern) läuft. Schließlich kann bei Block 2156 eine oder mehrere einer Cache-Kapazität und Speicherbandbreite für jedes Tag gesetzt werden. Gemäß einer beispielhaften Ausführungsform können die eine oder mehreren einer Cache-Kapazität oder Speicherbandbreite durch ein Betriebssystem und/oder einen Manager virtueller Maschine (VMM) gesetzt werden.
Außerdem können gemäß einer beispielhaften Ausführungsform Daten und Anwendung(en) dynamisch in unterschiedliche Performance-Klassen zur Laufzeit basierend auf Laufzeit-Performance-Indikatoren, problematischen Speicherbereichen oder Zonen und/oder basierend auf Zugriffsmustern bewegt werden.
Ausführungsformen des Verfahrens 2150 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 2150 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 2150 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 2150 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Seitenebenen-QoS
Die Leistung einer CPU beruht weitgehend auf niedriger Latenz, Speicherzugriffen mit hoher Bandbreite. Moderne CPU-Architekturen hängen von mehreren Cache-Niveaus zum Reduzieren der Latenz und Bandbreitenauflagen externer Speicherlösungen, wie DDR, ab. Das Zwischenspeichern kann verwendet werden, um die Gesamtperformance der CPU zu verbessern, und Features wie Cache-QoS (Cache-Zuordnungstechnologie, Cache Allocation Technology, CAT) und Speicherbandbreitenzuordnung (Memory Bandwidth Allocation - MBA) (die beide existierende Features sind), stellen ein Mittel bereit, um größere Performance für einen spezifischen Kern innerhalb eines Multikernprozessors sicherzustellen. CAT und MBA stellen Vorteile in vielen Umgebungen bereit, sind aber von Thread-Niveau-Tagging abhängig. Das bedeutet, dass, nachdem ein Tag angewandt wurde (eine Serviceklasse, CLOS für Ressourcensteuerung oder eine Ressourcenüberwachungs-ID, RMID zur Überwachung), darauffolgende Aktivitäten, die mit dem Thread zusammenhängen, gesteuert und/oder überwacht werden. Derzeit gibt es jedoch kein Verfahren zum Steuern der Datenplatzierung von Threads auf eine Art, die sensitiv ist und/oder den Datenadressen, auf die dieser Thread zugreift, entspricht. In Echtzeit oder bei wichtigen Threads, wenn die wichtigsten Cache-Misses zu spezifischen Adressen eine erhebliche Auswirkung auf Performance und Ausführungs-Jitter haben können, kann das in Threads resultieren, die schwierig abzustimmen und zu optimieren sind, um ihre kritischsten Daten in dem Cache zu behalten. In einer Echtzeitumgebung werden diese Cache-Misses bei der Betrachtung einer Worst-Case-Ausführungszeit angenommen, was sich erheblich auf die Fähigkeit eines Programmierers, eine definitive Echtzeit-Workload-Abschlusszeit zu garantieren auswirken kann.
Falls zum Beispiel ein erster Kern, Core A, eine Workload aufweist, die eine Data A (< 1 KB) regelmäßig in Abständen von 100 µs verbraucht, aber auch eine Stream-Verarbeitung ausführt, die den gesamten L3-Cache verbraucht, kann Data A zwangsweise aus L1-, L2- und L3-Cache ebenso wie dem TL-Eintrag in den TLB zweiten Niveaus (STLB) geräumt werden. Durch dieses Muster, das dann wieder auf Data A mit seiner regelmäßigen Schlagzahl von 100 µs zugreift, kann oft eine unvorhersagbare zusätzliche Latenz bestehen, die durch Holen von Speicher von dem DDR, einschließlich der Seiten-Walks, die benötigt werden, um die virtuelle Adresse für Data A zu übersetzen (wobei Übersetzungen später in den TLB-/STLB-Strukturen gespeichert werden, später aber durch den großen Arbeitssatz der Streaming-Workload-Phase heraus gezwungen werden) auferlegt wird. In Echtzeitumgebungen kann diese zusätzliche Latenz die verwendbaren Ausführungszyklen noch weiter reduzieren, was weniger als 70 % der gesamten verfügbaren Performance belässt, da Zyklus-Budgets aufgefüllt werden müssen, um Worst-Case-Cache- und TLB-Verhalten zu berücksichtigen. In einigen Fällen, bei knapperen Grenzen in der Größenordnung für eine 10 µs-Schlagzahl, kann die effektive Performance < 50 % betragen. Als ein anderes Beispiel kann das Mischen von Workloads auf Kernen durch Time-Slicing-Ausführung auch Cache- und STLB-Druck einführen.
Eine beispielhafte Ausführungsform einer verbesserten FaaS- und Echtzeitlösung kann es der Cache-Hierarchie erlauben, die Residenz von Datenblöcken in dem Cache zu verbessern, indem unnötigen Räumungen und kostspieligen Seitentabellen-Walks vorgebeugt wird.
Zusätzlich kann gemäß einer beispielhaften Ausführungsform CLOS-Auswahl an Seitenattribute gebunden und der Cache-Hierarchie ein Verfahren zum Verbessern von Cache-Zeilenresidenz für kritische Pfadausführung bereitgestellt werden. Jede Seite, die in eine Seitentabelle durch das Betriebssystem zugeordnet wird, kann die ausgewählte CLOS für die Seite definieren. Wenn ein Speicherladen/- speichern auftritt und die Daten in den Cache gebracht werden müssen, können die Seitenattribute den Cache-Block angeben, den die CLOS verwenden kann, spezifisch auf welche Arten es ihr erlaubt ist zu räumen, um Platz zu machen. Auf ähnliche Art, kann es für den STLB, wenn die Seitenübersetzung gelesen wird, einen spezifischen Ort der STLB aufweisen, der für die CLOS zugeordnet ist, die von den Seitenattributen definiert wird, wodurch die Residenz der TLB-Einträge verbessert wird. Anders ausgedrückt können CLOS-Tags verwendet werden, um wichtige Daten (Data A in dem Beispiel zwei Absätze weiter oben) in geschützte Partitionen von Caches an den Niveaus L1/L2/L3/usw. und/oder dem STLB zuzuordnen. Die Gegenwart dieser Daten in geschützten Partitionen eliminiert die Möglichkeit, dass sie geräumt werden, was bedeutet, dass die Daten bei Bedarf anwesend sind, was Ausführungs-Jitter, der durch das Erfordernis, diese Daten aus dem Speicher zu holen, induziert wird.
Seitenebenen-QoS ermöglicht die Fähigkeit, jeden Datenblock individuell zu behandeln (der Begriff kann auch auf Management an dem Byte-, Cache-Zeilen- oder Seitenebene verweisen, zur Effizienz der Umsetzung kann jedoch die Seitenebene ein gemeinsamer Ansatz sein). Anweisungen können zu Seiten mit einem spezifischen Attribut (wie einem CLOS-Tag) zugewiesen, und in dem Fall kritischer Pfadausführung, können kritische Pfadanweisungen separate Seiten mit spezifischen QoS-Anforderungen aufweisen. Auf ähnliche Weise können für Daten kritische Pfadelemente mit weniger häufigen Zugriffen spezifische QoS-Anforderungen aufweisen, die Blockierungen auf Speicherzugriffen vorbeugen können. Das Eingliedern der gewünschten QoS-Tags (zum Beispiel CLOS) in die Seitenattribute kann bessere Integration mit den Cache-Steuermerkmalen, wie CAT, an diversen Cache-Ebenen ermöglichen, und mit STLB-Partitionierung-Features deterministische Residenz und einfachere Modellierung ermöglichen, um Worst-Case-Ausführungszeit zu garantieren.
Der oben beschriebene Ansatz kann von der verwandten Lösung von Kernebenen-QoS (herkömmlich RDT) unterschiedlich sein, bei der CLOS durch ein Register definiert ist, das alle stromabwärtigen Konstrukte, die innerhalb des Kerns existieren, steuert. Aufgrund von Sicherheitsrisiken wird die CLOS typischerweise durch ein privilegiertes Register, das für Benutzerraumanwendungen nicht verfügbar ist, kontrolliert. Durch diese Thread-Tagging-Umsetzung kann nur eine CLOS von einer Aufgabe zu einer gegebenen Zeit während der Ausführung für alle Speichervorgänge verwendet werden. Kernebenen-QoS kann problematischer sein, da sie annimmt, dass alle Daten innerhalb der Aufgabe auf dieselbe Weise behandelt werden (und Kernebenen-Features sind schwieriger bei Anwesenheit mehrerer Threads auf jedem Kern als in dem Fall von SMT zu managen). Ohne komplexe Sondernutzungsflüsse wie „Pseudo-Locking“, bei welchen CLOS gewechselt werden und Daten in die Caches a priori vor Nutzung „angesaugt“ werden, kann eine Aufgabe nicht steuern, welche Elemente spezifische Residenzanforderungen in dem L2- oder STLB-Cache haben werden. Ohne solche komplexe Setup-Vorgänge und/oder Schritte kann ein Stream-Bearbeitungsvorgang folglich alle kritischen Pfadelemente im Cache räumen. Ferner können Pseudo-Locking-Lösungen, während sie manchmal effektiv sind, „fragil“ sein, weil sie mit unvorhergesehenen Mikroarchitektur-Verhaltensweisen behaftet sein können, die das Aufbauen von Garantien, die das Zwischenspeicherverhalten umgeben, recht schwierig machen. Ausführungsumgebungen mit vielen konsolidierten Aufgaben pro Kern können auch ein Problem aufwerfen. Bei diesem Szenario kann die Fähigkeit, eine beträchtliche Größe von Cache pro Aufgabe herauszuarbeiten schwierig sein.
Seitenebenen-QoS können ein Mittel zum Verbessern von Laufzeit-Dienstgüte durch Hinzufügen der CLOS-Definition zu den Einträgen in der Seitentabelle bei einer beispielhaften Ausführungsform an der Seitenebene bereitstellen. Erwartete Nutzung kann durch die unten stehenden Szenarien vorgeführt werden. Wenn zum Beispiel eine Anwendung zur Ausführung vorbereitet wird, kann das Betriebssystem Seiten zuordnen, um alle binären Sektionen der Anwendung in den Speicher zu platzieren. Jedes Binär-Segment kann mit einer CLOS durch ein für das Betriebssystem sichtbares Mittel gekennzeichnet und in zugeordnete Seiten, die von dieser CLOS bestimmt und gekennzeichnet werden, platziert werden. Das kann es unterschiedlichen Segmenten der Anwendung erlauben, höhere oder niedrigere Priorität aufzuweisen, um die Gesamt-Dienstgüte zu verbessern, wichtiger ist aber, dass die kritischen Teile von Daten in wichtigen Seiten in den Caches/TLBs mit viel höherer Wahrscheinlichkeit behalten werden können, und eine einfachere Schnittstelle wird bereitgestellt (durch die Seitenebenenschnittstelle zum Laden dieser Datenbereiche in die Caches/TLBs).
Wenn die Seiten zugeordnet werden, kann jeder Seiteneintrag zu der Seitentabelle mit zusätzlichen Bits hinzugefügt werden, um die CLOS für den Speicher, den die Seite darstellt, zu definieren. Zur Laufzeit können die Seiteneinträge von der CPU abgerufen werden, um Virtuell-zu-Physisch-Adressübersetzung bereitzustellen, und in diesem Zeitpunkt kann die CLOS für den Speicher, auf den sie zugreifen soll, identifiziert werden. Da die CLOS definieren kann, wie die Cache-Hierarchie partitioniert wird, kann der Speicher dann in die Bereiche einer gemeinsamen Ressource (wie zum Beispiel STLB einer Cache-Ebene), die von der Partition für diese CLOS definiert wird, geladen werden. In dem Fall von Räumungen können nur neue Speicheranforderungen, die Zugriff auf eine spezifische Cache-Partition besitzen, Elemente aus der Cache-Partition räumen. Das bedeutet, dass umfangreiche Daten in separaten Partitionen vor Räumung geschützt werden können. Das kann die Residenz für ein Element im Cache für eine Partition, die reserviert ist, immens verbessern, so dass ein anderes (und vielleicht robusteres) Pseudo-Locking-Mittel bereitgestellt werden kann. In dem Fall von Speicheranwendungen während Laufzeit, kann der Betriebssystemaufruf zum Zuordnen von Speicher auf den Heap zusätzlich die CLOS, die für die neuen Seitentabelleneinträge, die angelegt werden sollen, ausgewählt wird, bereitgestellt bekommen.
Unter Bezugnahme auf 21B und 21C zeigen diese zwei Figuren Interaktion zwischen Aufgaben und CLOSs in einer Seitenebene, um Seitenebenen-QoS in einer verbesserten FaaS-Architektur bereitzustellen. Seitenebenen-QoS können einen Nutzen durch Partitionierung an der Segmente eines Programms in separate CLOSs bereitstellen, was erlaubt, dass bestimmte Segmente oder bestimmte Daten innerhalb von Segmenten speziell priorisiert oder in den Caches/TLBs geschützt werden. In 21B kann eine Anwendung 2160 drei separate Aufgaben (zum Beispiel Task 0, Task 1, Task 2) jeweils mit spezifischen deterministischen Echtzeitanforderungen aufweisen. Jede dieser Aufgaben weist ihr eigenes Segment für Code und Daten (.text und .bss) auf, um spezifische Cache-Partitionierung während der Ausführung zu erlauben, während immer noch der globale Prozessniveaukontext (zum Beispiel wie in dem Fall einer Multithread-Anwendung) gemeinsam verwendet wird. Die Daten 2161 und der Code 2162 betreffen die Task 0, die Daten 2163 und der Code 2164 betreffen die Task 1, und die Daten 2165 und der Code 2166 betreffen die Task 2. Der Code und die Daten jeder Aufgabe werden in eine spezifische Cache-Partition gezielt, was mehr deterministischen muss für die Ausführungszeit bereitstellt und eine knappere Berechnung der Worst-Case-Ausführungszeit erlaubt. Gemäß der beispielhaften Ausführungsform der 21B, können die .bss- und text-Segmente zu der gleichen Serviceklasse gehören, sie können aber weiter basierend auf Speichergrößenauflagen und erforderlichem Determinismusgrad partitioniert werden.
Unter Bezugnahme auf 21C kann zur Laufzeit Task 0 Heap-Daten 2170 von dem Speicherzuordner CLOS 3 als eine Partition des CPU-Kerns 0 L2- und L3-Cache anfordern. Task 1 fordert auch Heap-Daten 2171 von CLOS 4 als eine Partition des CPU-Kerns 1 L2- und L3-Cache an. Für CPU-Kern 0 kann eine beispielhafte enge Schleife auf Sensordaten wie folgt und wie in 21C gezeigt ausgeführt werden:

1) Sensordaten werden in L3/LLC durch PCI-E DMA platziert. Zum Beispiel speichert das Intel-DDIO-Feature einige Daten, die in dem Speicher gespeichert sind, in dem dedizierten Bereich des L3-/LLC-Cache zwischen.
2) Task 0 verbraucht die eingegebenen Sensordaten, streamt sie in CLOS 3 L2-Cache-Partition, während Daten auch in bss_clos_0 ds aktualisiert werden.
3) Task 0 erzeugt Ausgang für Task 2 durch Daten innerhalb von bss_clos_2 und schleift zu Schritt 1 zurück.

Für den CPU-Kern 1 kann Task 1 als synchron zu Task 0 basierend auf einem externen Interrupt ohne Datenkorrelation zu Task 0 oder Task 2 ausführen. Aufgrund von Echtzeit-Determinismus, kann die Residenz in dem Cache von Task 1 kritisch sein.
Für CPU-Kern 1 kann Task 2 isochron ausgerichtet mit dem Ausgang von Task 0 in bss_clos_2 wie folgt ausführen:

1) Ausgabe von Task 0 durch bss_clos_2 lesen.
2) Anlegen von Schreibausgangsdaten mit CLOS 4 in dem CPU-Kern 1 L2- und L3-Cache.
3) NIC auf PCI-E liest Ausgangsdaten von L3.

Unter Bezugnahme auf 21D veranschaulicht dieses Diagramm ein ähnliches Szenario wie in 21C, abgesehen von wo die Threads-Ebenen-QoS zum Definieren der CLOS verwendet wird. Zuerst angesichts von CPU-Kern 0 2180, da nur die Task 0 auf CPU-Kern 0 2180 läuft, kann es ohne spezielle softwarebasierte Techniken und eine Cache-Hierarchie, die besonders darauf abgestimmt ist, sie zu unterstützen, kein Mittel zum Partitionieren des Cache zum Steigern von Residenz der text_clos_0 oder bss_clos_0 geben, während es in die Sensor-Daten streamt. Das kann unerwünschte Räumungen im Cache forcieren und den Gesamtdeterminismus reduzieren, wenn zusätzliche Cache-Misses auftreten. Nächstfolgend wird angesichts des CPU-Kern 1 2181 das Partitionieren immer noch zwischen Task 1 und Task 2 vorhanden sein, aber das gestreamte Schreiben zu den Heap-Ausgangsdaten kann mit CLOS 2 kombiniert werden. Das kann unerwünschte Räumungen bss_clos_2 und text_clos_2 verursachen, was den Determinismus zwischen dem Timing zwischen den Sensordaten (oder in diesem Fall Paketen), die zum Senden angewiesen werden und die, wenn NIC tatsächlich ausgesandt wird, reduzieren. Mit anderen Worten besteht aufgrund des gemeinsamen Verwendens von Caches nicht-deterministische Latenz zwischen der Zeit, in der die Anwendung den Befehl zum Senden ausgegeben hat, und dem tatsächlichen Senden der Daten über die Leitung. Diese Latenz ist auf die Tatsache zurückzuführen, dass die PCIe-Vorrichtung Daten aus dem Speicher lesen muss und sie eventuell zwischengespeichert werden oder nicht. Letztendlich resultiert diese Ungewissheit der Zwischenlagerung in Nicht-Bestimmung und Jitter in der Ausführungszeit.
Angesichts des L3-Cache 2182, dem größten deterministischen Speicherblock, ist die Körnigkeit derart reduziert, dass die Heap-Eingangs- und Ausgangsdaten weitere Räumungen kritischen Codes und kritischer Daten verursachen können. Während L2-Räumungen unerwartete Latenz zu dem L3-Cache 2182 hinzufügen, kann das Holen von Daten aus externem Speicher signifikant mehr Latenz und Jitter auf Die-Speicherblöcken hinzufügen.
Durch Implementieren von Seitenebenen-QoS, kann ein deterministischeres Modell basierend auf der Residenz von Daten/Anweisungen in dem Cache entwickelt werden, was knappere Echtzeitausführungsauflagen und höhere Kernnutzung erlaubt. Für Schlüssel-FaaS-Workloads von großer Bedeutung ist das ein signifikanter Fortschritt.
Zusätzliche Anmerkungen und Beispiele
Beispiel 2101 beinhaltet ein Verfahren, das das Bestimmen umfasst, ob ein Software-Thread auf einem logischen Hardware-Thread läuft, Wechseln eines Tag in ein Register, wenn der Software-Thread auf dem logischen Hardware-Thread läuft, und Einstellen mindestens eines einer Cache-Kapazität und einer Speicherbandbreite für jedes Tag.
Beispiel 2102 beinhaltet das Verfahren des Beispiels 2101, wobei das Tag ein Serviceklasse-Tag (CLOS-Tag) von einer Seitentabelle sein soll.
Beispiel 2103 beinhaltet das Verfahren des Beispiels 2101, wobei die mindestens eine der Cache-Kapazität und der Speicherbandbreite durch eines eines Betriebssystems und eines Managers einer virtuellen Maschine eingestellt wird.
Sicherstellen von vorhersagbarem FaaS-Durchsatz und Fairness unabhängig von der Anzahl konsolidierter gleichzeitiger Threads
Gemäß einer beispielhaften Ausführungsform kann eine Hardware- oder Software-Lösung, die Determinismus und Fairness sicherstellt, in der FaaS-Umgebung bereitgestellt werden. Das kann umgesetzt werden, um Konsistenz, Präzision und Fairness bei der Abrechnung sicherzustellen. Das Management und die Überwachung von FaaS-Ressourcen werden konzipiert, um konsistent präzise Abrechnung für Ressourcennutzung sicherzustellen.
Fairness beim Beurteilen von FaaS-Ressourcennutzung ist erforderlich, weil ein Mieter bezahlt, wenn FaaS-Ressourcen verwendet werden, und Langsamerwerden an einem der Threads des Mieters durch die Aktivität der Threads eines anderen Mieters Ungerechtigkeit oder Variation der Laufzeit (und daher Variation der Abrechnung) angesichts wiederholter Aufrufe derselben Workload verursachen kann. CPU-Planungsquanten können folglich eingestellt werden, um für Fairness zu sorgen; Abrechnungsstatistiken können verwendet werden, um gegebene CPU-Zeit und Fairness insgesamt zu messen; und Out-Of-Band-Telemetrie (OOB-Telemetrie) kann bei Überwachungsanwendungen beim Verstehen des Fairnessgrades, der gerade erzielt wird, ebenfalls eine Rolle spielen. Kontrollen sind jedoch, wie unten beschrieben, wichtig.
Gemäß einer beispielhaften Ausführungsform gibt es mindestens 2 Ansätze zum Sicherstellen von Determinismus und Fairness: 1) Partitionierung gemeinsam verwendeter Ressourcen, um sicherzustellen, dass jede der Funktionen gleichen Zugriff auf gemeinsam verwendete Ressourcen besitzt, oder 2) Implementieren eines Hardware- oder Software-Performance-Management-Controllers, der folgende Vorgänge ausführt:

a. Überwachen und Kontrolle
b. Kontrolle dynamischer Funktionsressourcen und Migration

22 veranschaulicht eine beispielhafte Architektur zum Bereitstellen von Determinismus und Präzision in einer FaaS-Umgebung. In 22 kann ein Rechengerät, zum Beispiel ein Performance-Controller 2210 die Vorgänge „a“ und „b“ in dem vorstehenden Absatz ausführen. Das Rechengerät 2210 kann auch auf Historie basierende Ressourcenplanung bereitstellen, Daten in entsprechende Kerne zum Aufrufen umlenken, gemeinsames Verwenden von Daten maximieren und Datenbewegung minimieren, Funktionen gemäß Service-Level-Verträgen bündeln. Die oben beschriebenen Vorgänge des Rechengeräts 2210 können auch über Software umgesetzt werden.
Um Determinismus und Fairness sicherzustellen, kann das Rechengerät 2210 oder Software den L2-Cache derart spalten, dass er von unterschiedlichen Kernen 2220, 2230 gehandhabt wird, insbesondere wenn L2 gefüllt wird.
Gemäß einer beispielhaften Ausführungsform kann das Rechengerät 2210 Code von Daten abspalten. Zusätzlich können Funktionen herumbewegt werden, um sicherzustellen, dass sie gut ausgewogen sind, zum Beispiel falls eine Ressource Backend-schwer ist, können die Funktionen auf unterschiedlichen Kernen basierend auf einem Scheduler gemischt und abgestimmt werden. Zusätzlich kann das Rechengerät 2210 zeitliche Ressourcen dynamisch zuordnen.
Laufzeit 2240 kann in der Architektur der 22 umgesetzt werden oder nicht. Wenn sie umgesetzt wird, kann eine Funktion die Laufzeit aufrufen, um Services und Anweisungen von der Infrastruktur zu erhalten, um betriebssystemspezifische Aufrufe zu verhindern.
Gesteigerte Abrechnungspräzision für FaaS
Ein softwarebasierter Zeitabtastansatz für die Abrechnung kann für FaaS unangemessen sein, da er mit Verzerrung und hohem Aufwand behaftet ist. Falls Abrechnung auf Millisekunden basiert, wird Körnigkeit benötigt, so dass die Rechenressourcennutzung in Mikrosekunden gemessen werden kann.
Da Workload-Timescales in einem Datencenter abnehmen, kann feine Überwachung und Abrechnung zunehmend wichtig werden. FaaS ist dazu konzipiert, Kundenaufrechnung bis hinunter zur Millisekunde zu erlauben, was erfordert, dass die Betreiber prüfbare Abrechnungspräzision an der Mikrosekundenebene aufrechterhalten müssen, um Präzision sicherzustellen. Hardware-Techniken zum Unterstützen solche Abrechnung mit minimalem Aufwand wird daher erforderlich, und mehrere Techniken sind unten beschrieben.
Gemäß einer beispielhaften Ausführungsform wird ein Hardware-Ansatz zum Aufrechnen von Management und Überwachung, der niedrigem Aufwand aufweist, und das Abrufen auf Anfrage von Abrechnungsstatistiken periodisch durch die Infrastruktur ermöglicht, bereitgestellt. Diese beispielhafte Ausführungsform kann Zeitabrechnungsaufwand aus dem Kontextwechselpfad von FaaS-Funktionen eliminieren, was Aufwand und Kosten verbessert.
Nehmen wir Aufrechnen für VMs als ein Beispiel; herkömmlich können VMs durch eine webbasierte Konsole oder mobile Anwendungen gemanagt werden und werden auf Anfrage von den Administratoren hoch- und heruntergefahren. Typischerweise wird die Abrechnung jedoch auf einer minutenweisen Basis gemanagt. Diese grobe Abrechnung ist hinsichtlich ihrer Infrastruktur kostengünstig und einfach zu managen und von den Kunden zu prüfen. Die Anforderungen an ein solches System sind niedrig (zum Beispiel grundlegende Tracking- und zeitsynchronisierte Infrastruktur und existierende Protokolle, wie NTP, sind für diesen Zweck geeignet).
Bei der feinen Abrechnung, die für FaaS erforderlich ist, können herkömmliche Techniken, wie die grobe Abrechnung, die oben im Fall von VMs beschrieben ist, ungeeignet sein. Softwarebasierte Zeitabtastung der OS-Zeit-APIs leidet an Verzerrung, und die hohe Rate von Funktionsaufrufen/-beendigungen kann zu hohem Aufwand beim Sammeln von Zeitwerten, Berechnen der Unterschiede zwischen Zeitstempel usw. führen. Das kann zu (1) erhöhten Betreiberkosten und (2) möglichen Unstimmigkeiten zwischen dem, was Kunden für Laufzeit profilieren, und dem, was Betreiber berichten, führen. Kumulative Ungenauigkeit und Unrichtigkeit verschlimmern diese Probleme noch weiter.
Ein Hardware-Ansatz kann, im Gegensatz zu einer Software-Lösung sehr niedrigen Aufwand involvieren und periodisch Abrufen auf Anfrage von Abrechnungsstatistiken durch die Infrastruktur ermöglichen. Mehrere Tagging-Techniken oder Lösungen sind für hardwaregestützte FaaS-Abrechnung möglich, um die Funktionen oder einen besonderen Thread und ihre entsprechende Aktivität in dem System, eindeutig zu identifizieren, einschließlich aber nicht beschränkt auf:

1) Resource Monitoring IDs-Technik (RMIDs-Technik) - Während das OS/VMM RMIDs wechselt, kann ein RMID-Ressourcenverfolgungs-Tag verwendet werden, um FaaS-Funktionen zu verfolgen. Jeder Funktion (oder jedem Mieter) kann eine RMID zugewiesen werden, und neue CPU-Hardware kann aufgebaut oder befähigt werden, um RMID-Zeit auf der CPU zu verfolgen (entweder in einer feinen Zeitbasis oder in CPU-Referenztaktzyklen). Neue RMID-Ereigniscodes können dann berichtet werden, oder Ressourcennutzung kann über ein neues MSR oder einen MMIO-Block, der RMID-zu-Zeitnutzung berichtet, berichtet werden.
2) Process-Address-Space-IDs-Technik (PASIDs-Technik) - Gemäß einer beispielhaften Ausführungsform sind PASIDs 20b Tags, die als ein Teil eines PCIe-gen-3-Spezifikationsaddendums eingeführt werden können. PASIDS können jedem Kern zugeordnet werden und mit anderen Features, wie Scalable I/O Virtualization (SIOV), verwendet werden. Da neue Hardware aufgebaut oder zum Verfolgen von CPU-Zeit, die pro PASID verbraucht wird, befähigt wird, kann dies eine hocheffiziente Art zum Verfolgen eindeutiger Funktionsrechenzeitnutzung sein (ähnliche Umsetzungsoptionen auf MMIO basierend oder auf MSR basierend wie oben sind bei dieser Technik verfügbar). Das Hinzufügen eines Verfolgungssystems aus Zählern zum Verfolgen der CPU-Zyklen, die von jedem PASID verbraucht werden, kann ein wichtiger Abschnitt zum Umsetzen dieses Ansatzes sein.
3) Logical-Processor-ID-Technik (LPID-Technik) oder pro Thread oder pro Kern - Logical-Processor-ID, Thread oder Kern, kann ähnlich wie PASIDs und RMIDs verwendet werden, und Zähler pro Instanz könnten auf ähnliche Weise zum Verfolgen von CPU-Nutzung hinzugefügt werden. Das würde erfordern, dass das OS/der VMM wahrscheinlich diese Zähler bei jedem Kontextwechsel liest, oder Hardware würde benötigt, um diese Resultate für die Software zu aggregieren.
4) Steuerregister-CR3-basierte Technik - Falls die Basis-Seitentabelle-Adresse die Basis für einen Prozess bildet, Verfolgen von CPU-Zeit in Hardwarezählern pro eindeutigem Steuerregister-CR3. Zeit oder Zyklen, die pro eindeutigem CR3-Wert verbraucht werden, könnten verfolgt werden (für die aktivsten CR3s zum Beispiel zum reduzieren von Kosten), um die CPU-Nutzung zu verfolgen.
5) VM-vCPU-basierte Technik - Das Zuweisen von Hardwarezählern pro virtueller VM CPUID (kann mit der VT-x-Architektur assoziiert werden) - solche Zähler könnten CPU-Nutzung für jede der vCPUs verfolgen (und in der Praxis wären andere Techniken, wie oben beschrieben, auch erforderlich, um die Nutzung für nichtvirtualisierte Fälle zu verfolgen).
6) Remote-Atomics-basierte Technik (RAO-basierte Technik) - RAO kann Logik an dem Uncore aufbauen, die verwendet werden kann, um CPU-Zeit zu verfolgen, zum Beispiel können gepostete RAO-Anweisungen verwendet werden, um ein „Inkrement durch X Zyklen“ zu der Tracking-Hardware für eine gegebene Prozess-ID / PASID / RMID / usw. bei jedem Kontextwechsel automatisch durch die Hardware (oder explizit durch Software) zu senden. Das kann mit RAO-Variablen in Software beginnend mit zukünftigen Generationen von Server-Hardware möglich sein. Ein Uncore kann Funktionen eines Mikroprozessors, die nicht in dem Kern sind, widerspiegeln, die aber eng mit dem Kern verbunden sind, um hohe Leistung zu erzielen. Der Uncore kann Fähigkeiten bereitstellen, wie zum Beispiel Zwischenspeichern, Speichercontrollerzugriff, E/A-Vorrichtungszugriff (zum Beispiel über PCIe) usw., und gewöhnlich eine Hochleistungsverbindung, um alle Funktionen miteinander zu verknüpfen.
6) Remote-Atomics-basierte Technik (RAO-basierte Technik) - RAO kann Logik an dem Uncore aufbauen, die verwendet werden kann, um CPU-Zeit zu verfolgen, zum Beispiel können gepostete RAO-Anweisungen verwendet werden, um ein „Inkrement durch X Zyklen“ zu der Tracking-Hardware für eine gegebene Prozess-ID / PASID / RMID / usw. bei jedem Kontextwechsel automatisch durch die Hardware (oder explizit durch Software zu senden. Das kann mit RAO-Variablen in Software beginnend mit Sapphire Rapids Server möglich sein). Ein Uncore kann Funktionen eines Mikroprozessors, die nicht in dem Kern sind, widerspiegeln, die aber eng mit dem Kern verbunden sind, um hohe Leistung zu erzielen.

Bei einem oder mehreren der obigen Tagging-Systeme kann auch ein Mechanismus zum Abtasten / Lesen der Zähler auf Anfrage und optional Löschen der Zähler auf Anfrage ebenfalls erforderlich sein (um zum Beispiel eine PASID oder RMID einem neuen Mieter zuzuweisen und zu recyceln). Gemäß einer beispielhaften Ausführungsform können die oben beschriebenen Tags von einem OS oder anderer Hardware zugewiesen werden.
Bei einer Ausführungsform kann ein elektronisches Verarbeitungssystem ähnlich oder gleich wie das in Verbindung mit 8A beschriebene einen Prozessor, Speicher, der kommunikationsfähig mit dem Prozessor gekoppelt ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher gekoppelt ist, beinhalten, um Vorgänge zum Berechnen von Ressourcennutzung auszuführen. Bei einigen Ausführungsformen kann sich die Logik in oder gemeinsam mit diversen Bauelementen, einschließlich des Prozessors, des Speichers usw. (zum Beispiel auf demselben Die) liegend befinden.
Bei einer anderen Ausführungsform kann ein Halbleiter-Package-Gerät, das ähnlich oder gleich ist wie das in Verbindung mit 8B beschriebene, ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, beinhalten, wobei die Logik mindestens teilweise in einer oder mehreren von konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt wird. Die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, kann dazu konfiguriert sein, Vorgänge zum Berechnen von Ressourcennutzung auszuführen. Bei einigen Ausführungsformen kann die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche beinhalten, die innerhalb des einen oder der mehreren Substrate positioniert sind.
Unter Bezugnahme auf 23 veranschaulicht diese Figur gemäß einer beispielhaften Ausführungsform ein Verfahren 2300 zum Berechnen von Ressourcennutzung für Abrechnungszwecke. Das Verfahren 2300 beinhaltet bei Block 2310 einen Vorgang des Verfolgens einer Resource-Monitoring-Identifier-Zeit (RMID-Zeit) auf der CPU. Bei Block 2320 kann die RMID-Zeit berichtet werden. Bei Block 2330 kann ein Zählerlöschmodul dazu konfiguriert sein, Zähler auf Anfrage zu speichern und/oder zu löschen und RMIDs neu zuzuweisen.
Zusätzliche Anmerkungen und Beispiele
Beispiel 2301 beinhaltet ein Gerät, dass eine Zentraleinheit, ein Ressourcenüberwachungs-Hardware-Modul, das konfiguriert ist, um in einer Leistungsmanagementeinheit unter Verwenden eines Ressourcenüberwachungsidentifikators (RMID) zu partitionieren und die Ressourcenüberwachungsidentifikatorzeit (RMID-Zeit) auf der CPU zu verfolgen, und ein Codeberichterstattungshardwaremodul, das dazu konfiguriert ist, die RMID-Zeit zu berichten.
Beispiel 2302 beinhaltet das Gerät des Beispiels 2301, wobei Hardwarezähler zum Zählen von Hardware- Ereignissen pro RMID zugewiesen werden sollen.
Beispiel 2303 beinhaltet das Gerät des Beispiels 2301, das weiter ein Zählerlöschmodul umfasst, wobei das Zählerlöschmodul dazu konfiguriert sein soll, Zähler auf Anfrage zu löschen und RMIDs neu zuzuweisen.
Intelligente telemetriegeführte Planungsbeispiele
Ein herkömmlicher Scheduler/Orchestrator verteilt Funktionen basierend auf Verfügbarkeit, ohne Feedback darüber, wie sich die Funktion verhalten hat. Einige Ausführungsformen einer verbesserten FaaS-Lösung, wie die oben in Verbindung mit 5 beschriebene, kann Informationen über Verhalten sammeln, wenn eine Funktion ausgeführt wird (dass die Funktion zum Beispiel so viel Zeit gebraucht hat, so viel Cache verwendet hat usw.) und bessere Planungs-/Orchestrierungsentscheidungen basierend auf den gesammelten Informationen zu fällen. Diverse Hardwarearchitekturen können zum Beispiel zahlreiche Zähler bereitstellen, die nützliche Informationen in Zusammenhang mit dem Funktionsverhalten bereitstellen können. Einige Ausführungsformen können Statistiken funktionsbezogene Informationen (zum Beispiel an Stelle jedes Datenpunktes) sammeln. Eine Datenbank gesammelter Informationen kann zum Beispiel geführt und von dem Scheduler/Orchestrator für zukünftige Routingentscheidungen verwendet werden. Vorteilhafterweise können einige Ausführungsformen (eine) bessere Verteilungsentscheidung(en), die bessere Ressourcennutzung bereitstellt (bereitstellen) usw. fällen.
Unter Bezugnahme auf 24A kann eine Ausführungsform einer verteilten Rechenumgebung 2440 einen Server 2441, der kommunikationsfähig mit einer oder mehreren Ausführungsumgebungen (zum Beispiel Plattformen, Server usw.) 2442 gekoppelt ist, beinhalten. Bei einigen Ausführungsformen ist der Server 2441 ein verbessertes FaaS-System. Der Server 2441 kann einen Orchestrator 2443 zum Planen und Routen von Funktionen zu den Ausführungsumgebungen 2442 beinhalten. Die Ausführungsumgebungen 2442 können kommunikationsfähig mit einem Datensammelmodul 2444 gekoppelt sein, das dazu konfiguriert sein kann, Informationen in Zusammenhang mit der Ausführung der Funktionen zu sammeln. Das Datensammelmodul 2444 kann kommunikationsfähig mit einem Datenspeicher 2445 gekoppelt sein, der die gesammelten Informationen speichern kann (zum Beispiel individuell, in Zusammenfassungsform, Statistiken in Zusammenhang mit den gesammelten Informationen, in einer strukturierten Datenbank usw.). Der Orchestrator 2443 kann kommunikationsfähig mit dem Datenspeicher 2445 gekoppelt sein, um die gespeicherten Daten zu nutzen, um Entscheidungen darüber zu fällen, wie die Funktionen geplant und geroutet werden sollen. Bei einigen Ausführungsformen kann die Orchestrierung und/oder Datensammlung nur auf Funktionen umgesetzt werden, die ein bestimmtes Nutzungsniveau erreichen (zum Beispiel werden Funktionen unter 1000 Instanziierungen nicht basierend auf gesammelten Daten orchestriert, während eine Funktion über 1000 Instanziierungen Daten gesammelt und basierend auf den gesammelten Daten orchestriert haben kann). Bei einigen Ausführungsformen kann das Sammeln angehalten werden, nachdem die Funktion gut bekannt ist (zum Beispiel nachdem die Funktion eine vorbestimmte Schwellenanzahl von Malen ausgeführt wurde).
Im Einzelnen routet und plant Orchestrator 2443 Funktionen zu den Systemen, wie dem Server 2441, auf dem sie ausgeführt werden. Der Orchestrator 2443 kann Systeme und/oder Subsysteme, die freie Zyklen aufweisen, lokalisieren und die Funktionsausführung zu ihnen routen. Einige Ausführungsformen des Orchestrators 2443 können einen intelligenten Scheduler bereitstellen, der Telemetrieinformationen aus den vorhergehenden Läufen der Funktionen für effizientere und wirtschaftlichere Ausführung verwendet. Bei einigen Ausführungsformen kann der Orchestrator 2443 AI und/oder MI, die Ineffizienzen (zum Beispiel hohen Leistungsverbrauch, längere Latenz als erwartet usw.) identifiziert und Verbesserungen zum Beheben der Ineffizienzen beinhalten. Die AI und/oder MI können die Planung und/oder Verteilung von Funktionen auf dem Server 2441 anpassen und bestimmen, ob die Anpassungen effektiv sind (zum Beispiel eine Reihe von Funktionen ausführen und bestimmen, ob die Ineffizienzen verhindert oder reduziert sind). Ist das der Fall, kann der Orchestrator 2443 das Planen und/oder Verteilen anderer Funktionen basierend auf den Anpassungen fortsetzen. Ansonsten kann der Orchestrator 2443 die AI und/oder die MI wieder einsetzen, um einen unterschiedlichen Satz von Anpassungen zu probieren, um die Ineffizienzen zu überwinden. Die Telemetrieinformationen können auf vielfältige Art gesammelt werden, einschließlich nahtloses statistisches Abtasten der Ereignisse auf den Host-Systemen, sowie statische oder dynamische Instrumentierung des Codes zum Sammeln der statischen und dynamischen Profilinformationen der Funktion. Nichteinschränkende Beispiele von Ereignisinformationen, die gesammelt werden können, beinhalten Mikroarchitektur-Ereignis Informationen, wie Daten-/Anweisung-Cache-Misses; falsche Verzweigungsvorhersagen, thermische Zähler, IPT, RDT usw. (zum Beispiel In-Band (auf der CPU) oder Out-Of-Band durch CSME). Nicht einschränkende Beispiele anderer Informationen können dann gesammelt werden, einschließlich dynamischer Aufrufgrafiken oder Funktionen, Basisblockzähler, API-Aufrufe usw. Die gesammelten Informationen können als statistische/dynamische Profilinformationen, die der Funktion entsprechen, organisiert werden.
Eine Ausführungsform eines intelligenten telemetriegeführten Schedulers des Orchestrators 2443 kann die Informationen (oder zum Beispiel eine Zusammenfassung der Informationen), die über die Funktionen gesammelt werden, verwenden, um die Funktion dynamisch zu dem System oder Pools von Systemen/Subsystemen zu routen, die gut oder am besten für die Ausführung der Funktionen geeignet sind (zum Beispiel verfügbare Ressourcen, ausreichend Rechnen, Speicher, Lagerung usw.). Mit zweckdienlicher Vorverarbeitung der gesammelten Telemetrie- und Profilinformationen über die Funktionen kann der intelligente Scheduler in der Lage sein, die Verfügbarkeit von Ressourcen der Systeme, die seiner Kontrolle unterstehen, rasch zu beurteilen. Der Scheduler kann zum Beispiel ein System oder einen Pool von Systemen identifizieren, die eine ausreichende Cache-Menge aufweisen, die nötig ist, damit eine Funktion geplant wird. Die Körnigkeit der gesammelten Informationen kann in Abhängigkeit von der Umsetzung variieren, aber Ausführungsformen des intelligenten Schedulers können das Problem des Abstimmens eines Vektors von Anforderungen durch die Funktion mit denjenigen der verfügbaren Systeme lösen. Der Scheduler kann in dem Sinn als intelligent betrachtet werden, dass die Informationen, die der Scheduler über ihr vorhergesagtes Verhalten haben kann, umso präziser sind als die Funktionen zahlreich sind.
Bei einer Instanz telemetriegeführter Planung kann eine Ausführungsform eines intelligenten Schedulers des Orchestrators 2443 Versagen vorhersagen und verhindern. Einige Ausführungsformen des intelligenten Schedulers des Orchestrators 2443 können zum Beispiel den Zustand des Servers 2441 an einem Absturzpunkt einschließlich der Funktionen, die liefen, den Ressourcennutzungsvektor (zum Beispiel einschließlich eines Leistungsprofils usw.) registrieren usw. Der intelligente Scheduler kann potenziell viele Versagensfälle sehen und tiefe neuronale Netzwerke DNNs zum raschen Abstimmen des Systemzustands (zum Beispiel Vorhersagen potenzieller Versagensfälle) schaffen.
Bei einigen Ausführungsformen kann ein Compiler profilgeführte Optimierung (Profile Guided Optimization - PGO) oder feedbackgelenkte Optimierung (Feedback-Directed Optimization - FDO) für gesteigerte Kompilationsleistung verwenden. Das kann als ein Aspekt künstlicher Intelligenz betrachtet werden. Viele Knoten können verfügbar sein, um eine Funktion auszuführen, wenn ein Ereignis auslöst. Die diversen Knoten können unterschiedliche Stärken/Fähigkeiten aufweisen, und es kann erhebliche und vollständige Flexibilität hinsichtlich des Orts, an dem eine Funktion ausgeführt wird, bestehen. Der Orchestrator 2443 empfängt eine Funktion und entscheidet, wie sie zum Ausführen geroutet werden soll. Bei einigen Ausführungsformen, wenn eine Funktion ausgeführt wird, können Informationen über das Verhalten der Funktion (zum Beispiel Cache-Misses, Timing zum Ausführen usw.) von dem Orchestrator 2443 gesammelt werden. Einige Ausführungsformen können zahlreiche Zähler zum Sammeln von Programminformationen verwenden, und/oder die Funktion kann instrumentiert werden, um Daten zu sammeln (und/oder zum Beispiel kann ein Timer zum Sammeln von Informationen verwendet werden). Instrumentierung kann auch in einer Änderung von Code zum Beschleunigen des Codes resultieren (zum Beispiel wenn Matrix-Multiplikation identifiziert wird, so dass beim nächsten Mal Instrument-Code zum Einsetzen der Hardware auf einem besonderen Server). Die gesammelten Daten können ein Profil für die Funktion bilden, das der Compiler für profilgeführte Optimierung dazu, wo die Funktion ausgeführt werden soll, einsetzen kann.
Einige Ausführungsformen des Orchestrierers 2443 können auch das Ändern der Entscheidungsfällungsfähigkeiten künstlicher Intelligenz über Ressourcen beinhalten, die eingeholt werden, wenn die Funktion in der Zukunft (zum Beispiel beschleunigte Funktionen, einschließlich Hardware-Umsetzungen, wie als eine ASIC, eine GPU, ein FPGA usw.) für Just-in-Time-Anpassungen (JIT-Anpassungen) verteilt wird. Die gesammelten Daten können in einer Datenbank oder in einem Datenspeicher, wie den Datenspeicher 2445 gespeichert und abgetastet werden, um Ausführungsfehler zu identifizieren. Basierend auf Fehlern können einige Ausführungsformen des Orchestrators 2443 ideale Ressourcenzuordnung und Server identifizieren (falls zum Beispiel das Profil angibt, dass die Funktion einen großen Cache verwendet, kann der Orchestrator 2443 die Funktion zu einem Server mit großer Cache-Zuordnung routen, um Fehler zu verhindern). Einige Ausführungsformen des Orchestrators 2443 können das erzeugte Profil einsetzen, um profilgeführte Optimierung bereitzustellen und wahrscheinliche Ergebnisse zum Optimieren der Auswahl der Ressourcen zu identifizieren. Einige Ausführungsformen des Orchestrators 2433 können zum Beispiel die Funktionen analysieren und Cache-Nutzung maximieren (zum Beispiel zwei Funktionen, die ein Video zu unterschiedlichen Nutzern streamen, können zu demselben Server geschoben werden).
Unter Bezugnahme auf 24B kann eine Ausführungsform eines Verfahrens 2430 zum Bereitstellen einer Function-as-a-Service das Sammeln verhaltensbezogener Informationen in Zusammenhang mit einer ausgeführten Funktion bei Block 2431 beinhalten, und das Fällen einer darauffolgenden Funktionsmanagemententscheidung basierend auf den gesammelten verhaltensbezogenen Informationen bei Block 2432. Einige Ausführungsformen des Verfahrens 2430 können ferner das Bestimmen von Statistiken in Zusammenhang mit den gesammelten verhaltensbezogenen Informationen bei Block 2433 beinhalten, und das Fällen einer darauffolgenden Funktionsmanagemententscheidung basierend auf den bestimmten Statistiken bei Block 2434. Die Funktionsmanagemententscheidung kann zum Beispiel eine oder mehrere einer Planungsentscheidung und einer Orchestrierungsentscheidung bei Block 2435 beinhalten.
Ausführungsformen des Verfahrens 2430 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 2430 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 2430 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Verfahren 2430 kann zum Beispiel auf einem computerlesbaren Medium, wie in Verbindung mit den Beispielen 2411 bis 2413 unten beschrieben, umgesetzt werden. Ausführungsformen oder Abschnitte des Verfahrens 2430 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, FPGA-Bit-Ströme, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 2400 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, verhaltensbezogene Informationen in Zusammenhang mit einer ausgeführten Funktion zu sammeln, wobei die verhaltensbezogenen Informationen eine oder mehrere In-band-Informationen und Out-Of-Band-Informationen beinhalten, und eine anschließende Just-in-Time-Funktionsmanagemententscheidung basierend auf den gesammelten verhaltensbezogenen Informationen fällen.
Beispiel 2401 beinhaltet ein elektronisches Verarbeitungssystem, das einen Prozessor umfasst, einen Speicher, der kommunikationsfähig mit dem Prozessor gekoppelt ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher gekoppelt ist, um verhaltensbezogene Informationen in Zusammenhang mit einer Funktion, die von dem Prozessor ausgeführt wird, zu sammeln, und eine darauffolgende Funktionsmanagemententscheidung basierend auf den gesammelten verhaltensbezogenen Informationen zu fällen.
Beispiel 2402 beinhaltet das System des Beispiels 2401, wobei die Logik ferner Statistiken, die mit den gesammelten verhaltensbezogenen Informationen zusammenhängen bestimmen soll, und die darauffolgende Funktionsmanagemententscheidung basierend auf den bestimmten Statistiken zu fällen soll.
Beispiel 2403 beinhaltet das System eines der Beispiele 2401 bis 2402, wobei die Funktionsmanagemententscheidung eine oder mehrere einer Planungsentscheidung und einer Orchestrierungsentscheidung beinhaltet.
Beispiel 2404 beinhaltet ein Halbleiter-Package-Gerät, das ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, aufweist, wobei die Logik mindestens teilweise in einer oder mehreren aus konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist, die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um verhaltensbezogene Informationen in Zusammenhang mit einer ausgeführten Funktion zu sammeln und eine darauffolgende Funktionsmanagemententscheidung basierend auf den gesammelten verhaltensbezogenen Informationen zu fällen.
Beispiel 2405 beinhaltet das Gerät des Beispiels 2404, wobei die Logik ferner Statistiken, die mit den gesammelten verhaltensbezogenen Informationen zusammenhängen bestimmen soll, und die darauffolgende Funktionsmanagemententscheidung basierend auf den bestimmten Statistiken zu fällen soll.
Beispiel 2406 beinhaltet das Gerät eines der Beispiele 2404 bis 2405, wobei die Funktionsmanagemententscheidung eine oder mehrere einer Planungsentscheidung und einer Orchestrierungsentscheidung beinhaltet.
Beispiel 2407 beinhaltet das Gerät eines der Beispiele 2404 bis 2406, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche, die innerhalb des einen oder der mehreren Substrate positioniert sind, beinhaltet.
Beispiel 2408 beinhaltet ein Verfahren zum Bereitstellen einer Function-as-a-Service, die das Sammeln verhaltensbezogene Informationen in Zusammenhang mit einer ausgeführten Funktion und das Fällen einer darauffolgenden Funktionsmanagemententscheidung basierend auf den gesammelten verhaltensbezogenen Informationen umfasst.
Beispiel 2409 beinhaltet das Verfahren des Beispiels 2408, das weiter das Bestimmen von Statistiken, die mit den gesammelten verhaltensbezogenen Informationen zusammenhängen und das Fällen der darauffolgenden Funktionsmanagemententscheidung basierend auf den bestimmten Statistiken umfasst.
Beispiel 2410 beinhaltet das Verfahren eines der Beispiele 2408 bis 2409, wobei die Funktionsmanagemententscheidung eine oder mehrere einer Planungsentscheidung und einer Orchestrierungsentscheidung beinhaltet.
Beispiel 2411 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, verhaltensbezogene Informationen in Zusammenhang mit einer ausgeführten Funktion zu sammeln und eine darauffolgende Funktionsmanagemententscheidung basierend auf den gesammelten verhaltensbezogenen Informationen zu fällen.
Beispiel 2412 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 2411, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, Statistiken zu bestimmen, die mit den gesammelten verhaltensbezogenen Informationen zusammenhängen und die darauffolgende Funktionsmanagemententscheidung basierend auf den bestimmten Statistiken zu fällen.
Beispiel 2413 beinhaltet das mindestens eine computerlesbare Speichermedium eines der Beispiele 2411 bis 2412, wobei die Funktionsmanagemententscheidung eine oder mehrere einer Planungsentscheidung und einer Orchestrierungsentscheidung beinhaltet.
Beispiele zur intelligenten Funktionsplanung zum Maximieren von Speicherwiederverwendung
Einige Ausführungsformen des verbesserten FaaS-Systems, wie die obige, die in Verbindung mit 4 beschrieben ist, können vorteilhafterweise intelligente Funktionsplanung zum Maximieren von Speicherwiederverwendung bereitstellen. Speicher ist eine beschränkte Ressource und Funktionen und Daten belegen Platz in dem Speicher. Einige Ausführungsformen können Instanzen von Funktionen desselben Sprachstapels zu demselben darunterliegenden System/derselben Maschine/demselben Speicher routen. JIT-angelegter Code kann auch dupliziert werden, und bei einigen Ausführungsformen können Instanzen des duplizierten JIT-Codes zu demselben darunterliegenden System/derselben Maschine/demselben Speicher geroutet werden. Einige Ausführungsformen können vorzugsweise Funktionen, die dieselbe Sprache einsetzen (zum Beispiel JAVA, PYTHON usw.) zu derselben Maschine und/oder demselben physischen Knoten routen. Einige Ausführungsformen können zusätzlich oder alternativ gemeinsam verwendete Daten zu demselben System/derselben Maschine/demselben Speicher (zum Beispiel Kartendaten) routen.
Ausführungsumgebungen eines verbesserten FaaS-Systems, wie das FaaS-Systems 2540 in 25A unten, können gemeinsame Codebibliotheken (zum Beispiel dynamische Verknüpfungsbibliotheken - DLLs) und/oder gemeinsame Daten (zum Beispiel Datensätze, Datenbanken, Kartendaten usw.) laden, um die Ausführung von Funktionen zu unterstützen. Gemeinsam verwendete Bibliotheken können kostspielig sein und/oder viele Daten besitzen. Einige Ausführungsformen des verbesserten FaaS-Systems 2540 können vorteilhafterweise Funktionen derselben Sprache zu derselben Maschine routen, um von gemeinsam verwendeten Bibliotheken zu profitieren. Bei einigen Ausführungsformen können gemeinsam verwendete Bibliotheken wie unterschiedliche Instanzen einer gemeinsam verwendeten Funktion behandelt werden. Bei einigen Systemen kann zum Beispiel kompilierter Code derselben Funktionen ähnlich sein. Bei einigen Ausführungsformen kann das verbesserte FaaS-System 2540 auch von gemeinsam verwendeten Daten (zum Beispiel können zwei Funktionen auf dieselben Kartendaten zugreifen, und einige Ausführungsformen können die zwei Funktionen zu derselben Maschine routen) und Ressourcen profitieren.
Einige Ausführungsformen des verbesserten FaaS-Systems 2540 können Speicherwiederverwendungstechnologie beinhalten, die größere Speicherbandbreite und kürzere Speicherzugriffslatenzen ermöglichen, indem nur eine Kopie physischen Speichers von Speicherbereichen (zum Beispiel eine Cache-Zeile), die genau dieselben Bit-Strings aufweisen, verwendet werden. Wenn zum Beispiel Tausende unterschiedlicher Cache-Zeilen alle denselben Wert aufweisen (zum Beispiel, wenn alle Bits Nullen oder Einsen sind oder irgendeine Permutation von Nullen oder Einsen sind), würde der physische Speicher nur eine Kopie des duplizierten Bereichs speichern. Die Speicherwiederverwendungstechnologie kann eine Extra-Indirektion kombiniert mit Hashen zum Wiederverwenden desselben Speicherplatzes einsetzen. Wenn jedoch einer der Bereiche geändert wird, kann ein neuer Bereich für den neuen Wert geschaffen werden, und falls die Permutation bereits existiert, würde der Indirektionsmechanismus den modifizierten Bereich zu diesem existierenden gespeicherten Wert abbilden. Ein Vorteil der Speicherwiederverwendungstechnologie besteht darin, dass gemeinsame Muster aller Bits Nullen oder Einsen sind, um Duplizieren der Daten zu verhindern. Einige Ausführungsformen des verbesserten FaaS-Systems 2540 können die Möglichkeit, von Speicherwiederverwendungstechnologie zu profitieren für den Funktionscode zusätzlich zu den Daten steigern.
Zusätzlich sind Funktionen in FaaS-Plattformen oft auf gemanagten Laufzeiten (zum Beispiel JavaScript, Python, Java, C# usw.). Jede dieser Plattformen weist eine Anzahl gemeinsam verwendeter Bibliotheken, wie DLLs, auf, die dynamisch geladen und verknüpft werden. Wenn mehrere Anwendungen dieselbe DLL verwenden, behält das OS typischerweise eine DLL in dem Hauptspeicher und sie wird für alle Anwendungen, die DLL laden, gemeinsam verwendet. Zusätzlich weisen die meisten dieser gemanagten Laufzeiten JIT-Compiler auf, die Code dynamisch für ihre Hochsprache erzeugen. Solche Ausführungsformen des verbesserten FaaS-System 2540 können vorteilhafterweise einen Scheduler/Orchestrator bereitstellen, zum Beispiel den Orchestrator 2443, der in 24B gezeigt ist, um Funktionen derselben Sprache, oder Funktionen, die mit zuvor gerouteten Funktionen ähnlich oder identisch sind, zu demselben System oder demselben Pool von Systemen zu routen. Außerdem können Funktionen, die dieselben Daten verwenden (zum Beispiel dieselbe Karte, dasselbe Video streamen) zu demselben System oder demselben Pool von Systemen geroutet werden. Vorteilhafterweise können einige Ausführungsformen des verbesserten FaaS-Systems 2540 die Wahrscheinlichkeit steigern, dass diese unterschiedlichen Funktionen viel Duplizieren von Code/Daten aufweisen (zum Beispiel hinsichtlich statistischen Codes, DLLs, JIT-erzeugten Codes, JIT-erzeugter Daten usw.). Systeme, die mit Speicherwiederverwendungstechnologie ausgestattet sind, können ferner von einigen Ausführungsformen profitieren, weil die Speicherwiederverwendungstechnologie tatsächlich nur eine Instanz jedes duplizierten Codes an sehr feinen Ebenen, einschließlich der Cache-Ebene, verwenden kann. Vorteilhafterweise können einige Ausführungsformen den Druck auf Speicher nach Bandbreite verringern, und Funktionen/Anwendungen können mehr Speicher für Daten zusätzlich zu schnellerem Zugriff auf den Code, den sieverwenden, aufweisen.
Bei einigen Ausführungsformen kann Systemsoftware des FaaS-Systems 2540 dazu konfiguriert sein, den Code und Datenstrukturen auszurichten, die hohe Aussichten auf Speicherwiederverwendung an Cache-Zeilengrenzen aufweisen. Zusätzlich kann das Auffüllen der Enden einiger Datenstrukturen mit Nullen die Aussicht, von Speicherwiederverwendungstechnologie zu profitieren, weiter steigern. Das Reduzieren oder Einschränken des „Schreib-Satzes“ von Funktionen/Workloads kann dabei helfen sicherzustellen, dass Schreiben in den Staging-Bereich der Wiederverwendungstechnologie passt und kann in Verringerung der Aufwände in Zusammenhang mit dem Vermeiden von Speicherverdoppelung resultieren, wenn der Schreib-Satz zu wachsen beginnt.
Unter Bezugnahme auf 25A kann ein verbessertes FaaS-System 2540 eine oder mehrere transiente Funktionen beinhalten, einschließlich einer Funktion f und eine Funktion g, sowie ein oder mehrere Zielsysteme 2550 für die Funktionen. Jede Funktion f oder g weist unterschiedliche Speicherbereiche, die mit ihren unterschiedlichen Daten und Codesektionen (wie in 25A als unterschiedlich schattierte Bereiche gezeigt sind), assoziiert sind, auf. Einige Ausführungsformen eines intelligenten Orchestrators/Schedulers können dynamisch und nahtlos die stark verwendeten duplizierten Speicherbereiche (sowohl Daten als auch Code) abtasten, sie mit den Funktionen, die laufen, assoziieren, und die Resultate in den zukünftigen Planungsszenarien verwenden. Einige Ausführungsformen können zum Beispiel gemeinsame Informationen 2542 in Funktionen f, g identifizieren und die Funktionen f, g zu demselben Zielsystem 2550 routen (zum Beispiel weil das Zielsystem 2550 die gemeinsam verwendeten Informationen 2542 bereits geladen haben kann).
Unter Bezugnahme auf 25B kann eine Ausführungsform eines Verfahrens 2530 des Bereitstellen einer Function-as-a-Service das Identifizieren gemeinsamer Informationen, die einer transienten Funktion entsprechen, bei Block 2531 und das Routen der transienten Funktion zu einer Ausführungsumgebung basierend auf dem identifizierten gemeinsamen Informationen bei Block 2532 beinhalten. Block 2531 kann zum Beispiel einen Scheduler und/oder einen Orchestrator beinhalten, die Funktionen identifizieren, die dieselbe Sprache aufweisen, und/oder Funktionen, die einander ähnlich sind, und die folglich denselben darunterliegenden gemeinsamen Datensatz verwenden werden. Funktionen, die dieselben Daten verwenden (zum Beispiel dieselbe Karte, oder die dasselbe Video streamen, dieselben Computersprachen-Bibliotheken usw.) können als denselben darunterliegenden gemeinsamen Datensatz einsetzend (zum Beispiel gemeinsam verwendete Informationen) identifiziert werden. Die identifizierten Funktionen können geplant werden, um in demselben System (zum Beispiel einem besonderen Knoten) oder demselben Pool von Systemen ausgeführt zu werden.
Einige Ausführungsformen des Verfahrens 2530 können ferner das Identifizieren einer neuen Instanz einer zuvor gerouteten transienten Funktion bei Block 2533 beinhalten, und die neue Instanz zu derselben Ausführungsumgebung wie die zuvor geroutete transiente Funktion bei Block 2534 routen. Bei einigen Ausführungsformen kann der Block 2531 mit dem Block 2535 erweitert werden. Die verwendeten Informationen können, wie von Block 2535 veranschaulicht, zum Beispiel einen oder mehrere von gemeinsam verwendetem Code, gemeinsam verwendeter Sprache und gemeinsam verwendeten Daten beinhalten, und können ferner das gemeinsame Verwenden transienter Informationen, die von einer Funktion erzeugt und von einer anderen Funktion verbraucht werden, beinhalten.
Ausführungsformen des Verfahrens 2530 können in einem System, wie dem FaaS-System 2540, das in 25A oben beschrieben ist, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 2530 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 2530 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Verfahren 2530 kann zum Beispiel auf einem computerlesbaren Medium, wie in Verbindung mit den Beispielen 2511 bis 2513 unten beschrieben, umgesetzt werden. Ausführungsformen oder Abschnitte des Verfahrens 2530 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 2501 beinhaltet ein elektronisches Verarbeitungssystem, das einen Prozessor umfasst, Speicher, der kommunikationsfähig mit dem Prozessor verbunden ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher verbunden ist, um gemeinsam verwendete Informationen, die einer transienten Funktion entsprechen, zu identifizieren, und die transiente Funktion zu einer Ausführungsumgebung basierend auf den identifizierten gemeinsam verwendeten Informationen zu routen, wobei die identifizierten Informationen von mindestens einer anderen Funktion gemeinsam verwendet werden.
Beispiel 2502 beinhaltet das System des Beispiels 2501, wobei die Logik ferner eine neue Instanz einer zuvor gerouteten transienten Funktion identifizieren und die neue Instanz zu derselben Ausführungsumgebung wie die zuvor geroutete transiente Funktion routen soll.
Beispiel 2503 beinhaltet das System eines der Beispiele 2501 bis 2502, wobei die gemeinsam verwendeten Informationen einen oder mehrere von gemeinsam verwendetem Code, gemeinsam verwendeter Sprache und gemeinsam verwendeter Daten beinhalten.
Beispiel 2504 beinhaltet ein Halbleiter-Package-Gerät, das ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, aufweist, wobei die Logik mindestens teilweise in einer oder mehreren aus konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist, die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um gemeinsam verwendete Informationen, die einer transienten Funktion entsprechen, zu identifizieren, und die transiente Funktion zu einer Ausführungsumgebung basierend auf den identifizierten gemeinsam verwendeten Informationen zu routen, wobei die identifizierten Informationen von mindestens einer anderen Funktion gemeinsam verwendet werden.
Beispiel 2505 beinhaltet das Gerät des Beispiels 2504, wobei die Logik ferner eine neue Instanz einer zuvor gerouteten transienten Funktion identifizieren und die neue Instanz zu derselben Ausführungsumgebung wie die zuvor geroutete transiente Funktion routen soll.
Beispiel 2506 beinhaltet das Gerät eines der Beispiele 2504 bis 2505, wobei die gemeinsam verwendeten Informationen einen oder mehrere von gemeinsam verwendetem Code, gemeinsam verwendeter Sprache und gemeinsam verwendete Daten beinhalten.
Beispiel 2507 beinhaltet das Gerät eines der Beispiele 2504 bis 2506, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche, die innerhalb des einen oder der mehreren Substrate positioniert sind, beinhaltet.
Beispiel 2508 beinhaltet ein Verfahren zum Bereitstellen einer Function-as-a-Service, die das Identifizieren gemeinsam verwendeter Informationen, die einer transienten Funktion entsprechen, und das Routen der transienten Funktion zu einer Ausführungsumgebung basierend auf den identifizierten gemeinsam verwendeten Informationen beinhaltet, wobei die identifizierten Informationen von mindestens einer anderen Funktion gemeinsam verwendet werden.
Beispiel 2509 beinhaltet das Verfahren des Beispiels 2508, das ferner das Identifizieren einer neuen Instanz einer zuvor gerouteten transienten Funktion und das Routen der neuen Instanz zu derselben Ausführungsumgebung wie die zuvor geroutete transiente Funktion umfasst.
Beispiel 2510 beinhaltet das Verfahren eines der Beispiele 2508 bis 2509, wobei die gemeinsam verwendeten Informationen einen oder mehrere von gemeinsam verwendetem Code, gemeinsam verwendeter Sprache und gemeinsam verwendeten Daten beinhalten.
Beispiel 2511 umfasst mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, gemeinsam verwendete Informationen, die einer transienten Funktion entsprechen, zu identifizieren, und die transiente Funktion zu einer Ausführungsumgebung basierend auf den identifizierten gemeinsam verwendeten Informationen zu routen, wobei die identifizierten Informationen von mindestens einer anderen Funktion gemeinsam verwendet werden.
Beispiel 2512 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 2511, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine neue Instanz einer zuvor gerouteten transienten Funktion zu identifizieren und die neue Instanz zu derselben Ausführungsumgebung wie die zuvor geroutete transiente Funktion zu routen.
Beispiel 2513 beinhaltet das mindestens eine computerlesbare Speichermedium eines der Beispiele 2511 bis 2512, wobei die gemeinsam verwendeten Informationen einen oder mehrere von gemeinsam verwendetem Code, gemeinsam verwendeter Sprache und gemeinsam verwendeten Daten beinhalten.
Beispiele für Zusammenführen/Aufgliederung und Zustandsaggregation und Disaggregation
Einige Ausführungsformen des verbesserten FaaS-Systems, wie die oben in Verbindung mit 4 beschriebene, können vorteilhafterweise Container zusammenführen und/oder Aufgliederung und/oder Zustandsaggregation und Disaggregation bereitstellen. Funktionen können gewöhnlich als unabhängige Ausführungseinheiten ohne Analysieren oder Berücksichtigen einer Beziehung zwischen Funktionen behandelt werden, was manchmal verursachen kann, dass Ressourcen nicht optimiert oder E/A-Aufwand (zum Beispiel Netzwerk und lokal) gesteigert wird. Einige Ausführungsformen des verbesserten FaaS-Systems können vorteilhafterweise eine Funktionsaufrufgrafik zum Definieren einer Beziehung zwischen Funktionen bereitstellen. Einige verwandte Funktionen können In-Line gebracht werden, um mehrere Funktionsaufrufe zu verhindern. Einige Funktionen können aufgegliedert werden, um Ressourcen-/Bandbreitenverbrauch zu reduzieren. Bei einigen Ausführungsformen können dynamische Aufrufgrafiken basierend auf Laufzeitanalyse angepasst werden. Einige Ausführungsformen des verbesserten FaaS-Systems können eine Datenontologie zur dynamischen Darstellung und Zustandsnavigation bereitstellen. Vorteilhafterweise können einige Ausführungsformen des verbesserten FaaS-Systems bessere Ressourcennutzung, niedrigeren E/A-Aufwand und/oder gesteigerte Bandbreite bereitstellen. Einige Ausführungsformen erzeugen eventuell, falls nicht erforderlich, keinen Aufwand. Bei einigen Ausführungsformen kann ein Entwickler identifizieren, wie lange die Funktion braucht um auszuführen, bevor die Funktion gestartet wird.
Unter Bezugnahme auf 26A kann eine Ausführungsform eines Verfahrens 2630 zum Bereitstellen einer Function-as-a-Service das Bereitstellen organisationsbezogener Informationen, wie einer Funktionsaufrufgrafik, beinhalten, um eine Beziehung zwischen Funktionen, für eine oder mehrere transiente Funktionen bei Block 2631 zu definieren, und die Ausführung der einen oder der mehreren transienten Funktionen basierend auf den organisationsbezogenen Informationen bei Block 2632 ändern. Einige Ausführungsformen des Verfahrens 2630 können ferner das Aufspalten einer oder mehrerer der transienten Funktionen in eine oder mehrere Subfunktionen bei Block 2633 beinhalten. Das Verfahren 2630 kann auch das Zusammenführen einer oder mehrerer der transienten Funktionen und Subfunktionen bei Block 2634 beinhalten. Zum Beispiel kann das Verfahren 2630 das gemeinsame Verwenden von Zustandsinformationen zwischen der Ausführung einer oder mehrerer der transienten Funktionen und Subfunktionen bei Block 2635 beinhalten.
Ausführungsformen des Verfahrens 2630 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 2630 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 2630 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C‟-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Verfahren 2630 kann zum Beispiel auf einem computerlesbaren Medium, wie in Verbindung mit den Beispielen 2614 bis 2617 unten beschrieben, umgesetzt werden. Ausführungsformen oder Abschnitte des Verfahrens 2630 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Beispiele für Container-Zusammenführen/Aufgliederung für effiziente Ausführung
Unter Bezugnahme auf 26B kann eine Ausführungsform einer Funktionsaufrufgrafik 2640 organisationsbezogene Informationen für transiente Funktionen f, g und h bereitstellen. Wie oben erwähnt, können Funktionen, die als abhängig identifiziert werden, Aufwnderhöhung, schlechten Ressourceneinsatz usw. aufgrund einer oder mehrerer Abhängigkeiten zwischen den Funktionen verursachen. Bei dem Beispiel, das in 26B gezeigt ist, hängen die Funktionen g und h von einer Funktion f ab, zum Beispiel benötigen die Funktionen g und h zur Ausführung mindestens eine Ausgabe, die von der Funktion f erzeugt wird. Einige Ausführungsformen können vorteilhafterweise organisationsbezogene Informationen, wie die Funktionsaufrufgrafik 2640 (zum Beispiel durch Instrumentierung zum Identifizieren, wenn eine Funktion zu einer anderen führt) für effiziente Funktionsausführungen bereitstellen.
Eine Aufrufgrafik kann einer Steuerflussgrafik, die Aufrufbeziehungen zwischen Funktionen darstellt, entsprechen. Bei einer gewichteten Aufrufgrafik kann jeder Bogen (der zum Beispiel von einer Aufruferfunktion ausgeht und an einer Aufgerufenenfunktion endet) mit der Häufigkeit und/oder Wahrscheinlichkeit dieses Aufrufaufrufs gekennzeichnet werden. Die Aufrufgrafik kann statisch gebildet und dann dynamisch verfeinert werden. Basierend auf Bereichen, die innerhalb der Aufrufgrafik gebildet werden, können bestimmte FaaS-Funktionen zusammengeführt werden, um den Aufwand von Aufruf und Datenkommunikation zu reduzieren. Einige Ausführungsformen können zum Beispiel Intra-FaaS-Funktion-Steuerflussgrafiken in eine Aufrufgrafik derart eingliedern, dass bestimmte FaaS-Funktionen in zwei oder mehrere Funktionen gespaltet werden.
Unter Bezugnahme auf die 26C bis 26E können veranschaulichte Diagramme, die zeigen, wie die Funktion f in zwei Subfunktionen f₀ und f₁ gespaltet werden kann, zeigen (siehe 26C), und anschließend kann die Funktion g zwischen die zwei Subfunktionen zusammengeführt werden (siehe 26D und 26E). Dieser Aufgliederungs- und Zusammenführungsprozess kann dabei helfen, eine kompakte und/oder effiziente Abfolge von Vorgängen zu bilden. Einige Ausführungsformen haben eine positive Auswirkung auf die Cache-Performance eines Kerns und können auch die Speicheranforderung und den Aufwand reduzieren, um mehrere FaaS-Funktionen gleichzeitig warm/aktiv zu halten. Der Steuerflusspfad und die Aufrufpfade, die weniger häufig genommen werden, können immer noch Beistellung durch Einsetzen geeigneten Codes/geeigneter Aufruf(e) zu entsprechenden FaaS-Funktionen benötigen, falls kalte Pfade ausgeführt werden.
Bei einigen Ausführungsformen kann die Codeerzeugung Compiler-Techniken (zum Beispiel Compiler-/Codegenerator von dem ursprünglichen Lambda) anwenden, um Superblöcke zum Verbessern des Parallelismus der Anweisungsebene (Instruction Level Parallelism - ILP) zu bilden. Ein Superblock kann einem Verlauf entsprechen, der keine Seiteneingänge hat. Zum Beispiel kann Steuerung nur von der Oberseite eintreten, kann aber an einem oder mehreren Ausgangspunkten austreten (zum Beispiel ein einziger Eingang an der Oberseite aber mehrere Ausgänge). Bei einigen Ausführungsformen können Profilinformationen verwendet werden, um einen Superblock aus einem gemeinsamen Pfad, der mehrere Basisblöcke beinhaltet, zu bilden.
Einige Ausführungsformen können durch Infrastruktur (vor dem Planen) und/oder zur Laufzeit von einem Scheduler ausgeführt werden. Einige Ausführungsformen können auch Ortsgleichheit der Daten einsetzen. Einige Ausführungsformen können zum Beispiel eine Funktion zu Daten liefern, statt umgekehrt, weil die Kosten zum Bewegen der Daten höher sind als die Kosten zum Bewegen der Funktion. Einige Ausführungsformen können Inlining-Technologie einsetzen. Wenn zum Beispiel eine identifizierte Funktion 2 von Funktion 1 mit angemessener Gewissheit aufgerufen werden kann, können einige Ausführungsformen Code von Funktion 2 in Funktion 1 statt eines separaten Aufrufs einbinden (siehe zum Beispiel 26E). Nach dem Einbinden braucht das FaaS-System nicht nach außen, um Funktion 2 auszuführen, Scheduler zu holen oder Download-Funktion zu gehen. Einbinden kann daher die Effizienz erhöhen und/oder den Aufwand des verbesserten FaaS-Systems reduzieren. Bei einigen Ausführungsformen kann der Scheduler den Inline-Vorgang ausführen. Bei einigen Ausführungsformen werden, sogar nach dem Einbinden von Funktion 1 mit Funktion 2 eingebunden wurde, um neuen zusammengeführten Code zu erzeugen, die Codes der ursprünglichen Funktion 1 und Funktion 2 nichtsdestotrotz gespeichert (zum Beispiel nicht entfernt oder gelöscht). Dadurch können die ursprünglichen Funktionen 1 und 2 unabhängig bleiben, um getrennt voneinander auszuführen. Falls zum Beispiel ein Fehler auftritt, wenn der neu zusammengeführte Code ausgeführt wird, besteht die Möglichkeit, dass das Einbinden falsch ausgeführt wurde. In einem solchen Fall werden die ursprünglichen Funktionen 1 und 2 noch behalten und können unabhängig voneinander auf eine Nicht-Inline-Art mit separaten Funktionsaufrufen ausgeführt werden.
Einige Ausführungsformen des verbesserten FaaS-Systems können zusätzlich oder alternativ Outlining-Technologie einsetzen. Einige Ausführungsformen können zum Beispiel Teile derselben Funktion, die weniger wahrscheinlich ausgeführt werden, entfernen (zum Beispiel die else-Anweisung von einer if-else-Anweisung entfernen, so dass sie so gut nie ausgeführt wird). Die entfernten Teile können als separates Programm/separate Funktion konfiguriert werden. Das Outlining kann vorteilhafterweise kleinere Downloads für jede Funktion bereitstellen. Das dynamische Profiling kann die „Hotness“-Informationen (zum Beispiel Wahrscheinlichkeit oder Häufigkeit) von Pfaden in einem Code identifizieren und die Hotness-Informationen in dem verbesserten FaaS-System zur Verwendung speichern. Die unterschiedlichen Pfade derselben Funktion können zum Beispiel identifiziert und dann gegen die Hotness-Information referenziert werden, um eine Wahrscheinlichkeit des Auftretens jedes der Pfade zu bestimmen. Die Pfade, die mit einer Hotness-Information (zum Beispiel Wahrscheinlichkeit oder Häufigkeit des Auftretens) über einem Schwellenwert assoziiert sind, werden behalten. Andere Pfade, die keine Hotness-Informationen, die über dem Schwellenwert liegt, aufweisen, werden entfernt und als separate Programme/Funktionen platziert.
Bei einem besonderen Beispiel kann eine Funktion eine „if-else“-Anweisung aufweisen. Die Hotness-Information gibt an, dass die „if“-Anweisung eine 100-prozentige Ausführungswahrscheinlichkeit aufweist, während die „else“-Anweisung eine 10-prozentige Ausführungswahrscheinlichkeit aufweist. Falls der Schwellenwert auf eine 30-prozentige Wahrscheinlichkeit gestellt ist, kann das System schließen, dass die „if“-Anweisung behalten werden soll, aber die „else“-Anweisung entfernt werden und als ein separater Funktionsaufruf platziert werden soll. Falls jedoch die Hotness-Information angegeben hat, dass die Wahrscheinlichkeit der „else“-Anweisung 40 % beträgt, kann das System schließen, dass die „else“-Anweisung nicht entfernt sondern behalten werden soll. Der Schwellenwert kann dynamisch basierend auf unterschiedlichen Faktoren eingestellt werden, wie auf der verfügbaren Hardware, Cache-Verfügbarkeit, Bandbreitenverfügbarkeit, Prioritätsinformationen der Funktion (falls zum Beispiel die Funktion eine höhere Priorität aufweist und für das Beenden in kurzer Zeit wesentlich ist, die Funktion nicht auseinanderbrechen) usw.
Einige Ausführungsformen des verbesserten FaaS-Systems können Funktionen identifizieren, die auf denselben Daten arbeiten (die zum Beispiel ansonsten nicht verwandt sind) und die Funktionen gemeinsam an denselben Ort wie die Daten stellen. Einige Ausführungsformen können Metriken bestimmen, um zu identifizieren, ob ein Zusammenführen/Aufgliedern ausgeführt werden soll (zum Beispiel mindestens 5 Minuten Ausführungszeit für alle Funktionen).
Beispiele für Statusaggregation und Disaggregation zum Erleichtern von Funktionswiederverwendung
Viele FaaS-Framewerks können den Begriff der Wiederverwendung von Funktionen, die „rein“ oder zustandslos sind, unterstützen. Ein Container kann daher mit einem Speicher-Layout für eine Funktion, deren interner Zustand konstant ist, für praktische Zwecke initialisiert werden, die aber mit neuen Eingängen als eingehende Parameter versehen werden kann. Diese zustandslose Funktion kann dann einen Ausgang erzeugen (der zum Beispiel wieder nicht Teil des Zustands der Funktion ist). Diese Zustandslosigkeit ist nicht immer vorteilhaft. Manchmal ist für einen größeren Vorsatz ein einziger Container am besten, der unterschiedlichen Modulen zugewiesen ist, die gerade einen gemeinsamen Zustand aktualisieren (zum Beispiel statt diesen Vorsatz immer in separate Funktionen, die explizit Daten von einer Funktion zu einer anderen Funktion bewegen müssen, aufzugliedern). Falls zusätzlich die Union der benötigten Funktionen zu groß ist, um in einen einzigen Container zu passen, oder falls das Aufbrechen des Containers zur Modularität wünschenswert ist, fügt das benötigte Fließen von Ausgang von einer Funktion zu einer anderen in einer Kette von Funktionen viel Datenbewegung und Speichermanagementaufwand hinzu.
Unter Bezugnahme auf 27A kann eine Ausführungsform des verbesserten FaaS-Systems 2700 einen Speicher 2710 beinhalten, der von zwei oder mehreren Subfunktionen 2720 (zum Beispiel SubFunktion A bis N) durch den Einsatz organisationsbezogenre Informationen, wie Deskriptoren 2730, gemeinsam verwendet werden kann. Einige Ausführungsformen des verbesserten FaaS-Systems 2700 können vorteilhafterweise Technologie zum Vermeiden von Aufwänden unnötiger Fragmentierung von Containern bereitstellen. Eine Datenontologie kann zum Beispiel dynamische Darstellung und Zustandsnavigation bereitstellen. Die Gesamtmenge an Zustand, die logisch als Ausgang von einer Funktion zu einer anderen transferiert werden soll, kann zum Beispiel in eine Hierarchie von Deskriptoren geteilt und unter Verwenden der Ontologie geschrieben werden. Die Hierarchie von Deskriptoren kann beschreiben, wie die Gesamtinformationen in einer verbrauchenden Funktion gemäß einer gemeinsam verwendeten Ontologie unter Subfunktionen zu aggregieren sind.
Als ein Resultat bleiben Zustandsinformationen, die nicht von einer vorhergehenden Funktion X zu einer nächsten Funktion Y zu wechseln brauchen, einfach an Ort und Stelle hinter einem gemeinsamen Deskriptor, der von X zu Y weitergegeben wird, und alle anderen Zustandsinformationen können in Y als ein Overlay (zum Beispiel ersetzen oder erweitern) über den gemeinsamen Deskriptor bearbeitet werden. Auf diese Art können Funktionen absichtlich organisiert werden, um auf Daten zu arbeiten, auf die mit Accessor-Techniken zugegriffen wird, und diese Accessor-Techniken können sowohl die Deskriptoren verwenden als auch nötige Overlays ausführen, so dass der Körper jeder der Subfunktionen allein zustandslos bleibt. Einige Ausführungsformen können zum Beispiel dem Konzept des „Funktionen an Daten anwenden“ folgen, ohne die Daten von einem Speicherbereich zu einem anderen zu bewegen. Einige Ausführungsformen können stattdessen auf den Daten an Ort und Stelle aber indirekt durch die Deskriptoren, die weitergegeben werden, arbeiten.
27B zeigt eine ausführliche Ansicht einer Hierarchie von Deskriptoren 2754 und einer ersten und einer zweiten Deskriptorengruppe 2756, 2758, die schlussendlich auf die Objekte 1 bis 6 im Speicher 2760 verweisen. Die Hierarchie der Deskriptoren 2754 und Deskriptorengruppen 2756 und 2758 kann explizit von einem Programmierer definiert werden, oder implizit aus Datenflussanalysen, die an Funktionen 2752 und Objekten im Speicher 2760 ausgeführt werden, und wobei solche Datenflussanalyse entweder explizit von einem Programmierer initiiert wird oder implizit von dem FaaS-System selbst. Bei einigen Ausführungsformen kann ein Programmierer explizit einige Objekte spezifizieren und Deskriptoren für sie erzeugen und verwenden, und sie in eine Hierarchie platzieren, während andere Objekte und ihre Deskriptoren eventuell in einer Hierarchie durch die Verwendung von Objektbezeichnungs- und Referenzierungsmechanismen in Dateisysteme, Symboltabelle, Datenbanken usw. organisiert werden können. Es zeigt zwei Ebenen von Deskriptortransfers, obwohl es möglich ist, andere Typen von Deskriptortransfers an unterschiedlichen Ebenen in der Hierarchie auszuführen. Die erste Ebene von Deskriptortransfers beinhaltet die Deskriptoren 2754. Die Deskriptoren 2754 stellen das Transferieren eines Deskriptors auf höchster Ebene (zum Beispiel Deskriptor 1) von SubFunction A zu SubFunction B dar, so dass SubFunction B fähig ist, auf alle Objekte, die zuvor für SubFunction A zugänglich waren, zuzugreifen. Nachdem SubFunction A die Ausführung abgeschlossen hat, kann der Deskriptor 1 zum Beispiel zu SubFunction B weitergegeben werden. Die zweite Ebene von Deskriptortransfers beinhaltet die erste und die zweite Deskriptorengruppe 2756, 2758. Die erste und die zweite Deskriptorengruppe 2756, 2758 sind eine Generation neuer Deskriptoren auf höchster Ebene, die durch die erste Ebene von Deskriptortransfers transferiert werden können. Jede der ersten und zweiten Deskriptorengruppe 2756, 2758 transferiert nur eine Hälfte der Deskriptoren 2 bis 7 der zweiten Ebene, die von Deskriptor 1 referenziert werden. Diverse Deskriptorhierarchien mit diversen Tiefen sind möglich. Bemerkenswert ist, dass die Deskriptoren 2754 der ersten Ebene auch fähig sein können, modifiziert zu werden, um zu unterschiedlichen der ersten und zweiten Deskriptorengruppe 2756, 2758 zu zeigen.
Zusätzliche Anmerkungen und Beispiele
Beispiel 2600 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, organisationsbezogene Informationen für eine oder mehrere transiente Funktionen bereitzustellen, die Ausführung der einen oder mehreren transienten Funktionen basierend auf den organisationsbezogenen Informationen zu ändern, wobei die Änderung ein oder mehrere eines Spaltens und eines Zusammenführen einer oder mehrerer der transienten Funktionen in eine oder mehrere Subfunktionen, gemeinsames Verwenden von Zustandsinformationen zwischen Ausführung einer oder mehrerer der transienten Funktionen und Subfunktionen, und Bewegen einer oder mehrerer der transienten Funktionen und Subfunktionen beinhalten kann, um ortsgleich mit Daten zu sein, die von der einen oder den mehreren der transienten Funktionen und Subfunktionen eingesetzt werden.
Beispiel 2601 beinhaltet ein elektronisches Verarbeitungssystem, das einen Prozessor, Speicher der kommunikationsfähig mit dem Prozessor gekoppelt ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher gekoppelt ist, beinhaltet, um organisationsbezogene Informationen für eine oder mehrere transiente Funktionen bereitzustellen, und Ausführung der einen oder mehreren transienten Funktionen basierend auf den organisationsbezogenen Informationen zu ändern.
Beispiel 2602 beinhaltet das System des Beispiels 2601, wobei die Logik ferner eine oder mehrere der transienten Funktionen in eine oder mehrere Subfunktionen spalten soll.
Beispiel 2603 beinhaltet das System eines der Beispiele 2601 bis 2602, wobei die Logik ferner eine oder mehrere der transienten Funktionen und Subfunktionen zusammenführen soll.
Beispiel 2604 beinhaltet das System eines der Beispiele 2601 bis 2602, wobei die Logik ferner eine oder mehrere Zustandsinformationen zwischen Ausführung einer oder mehrerer der transienten Funktionen und Subfunktionen gemeinsam verwenden soll.
Beispiel 2605 beinhaltet ein Halbleiter-Package-Gerät, das ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, aufweist, wobei die Logik mindestens teilweise in einer oder mehreren aus konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist, die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um organisationsbezogene Informationen für eine oder mehrere transiente Funktionen bereitstellen und die Ausführung der einen oder der mehreren transienten Funktionen basierend auf den organisationsbezogenen Informationen ändern soll.
Beispiel 2606 beinhaltet das System des Beispiels 2605, wobei die Logik ferner eine oder mehrere der transienten Funktionen in eine oder mehrere Subfunktionen spalten soll.
Beispiel 2607 beinhaltet das Gerät eines der Beispiele 2605 bis 2606, wobei die Logik ferner eine oder mehrere der transienten Funktionen und Subfunktionen zusammenführen soll.
Beispiel 2608 beinhaltet das Gerät eines der Beispiele 2605 bis 2606, wobei die Logik ferner eine oder mehrere Zustandsinformationen zwischen Ausführung einer oder mehrerer der transienten Funktionen und Subfunktionen gemeinsam verwenden soll.
Beispiel 2609 beinhaltet das Gerät eines der Beispiele 2605 bis 2608, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche, die innerhalb des einen oder der mehreren Substrate positioniert sind, beinhaltet.
Beispiel 2610 beinhaltet ein Verfahren zum Bereitstellen einer Function-as-a-Service, das das Bereitstellen organisationsbezogener Informationen für eine oder mehrere transiente Funktionen und das Ändern der Ausführung der einen oder mehreren transienten Funktionen basierend auf den organisationsbezogenen Informationen umfasst.
Beispiel 2611 beinhaltet das System des Beispiels 2610, das ferner das Spalten einer oder mehrerer der transienten Funktionen in eine oder mehrere Subfunktionen umfasst.
Beispiel 2612 beinhaltet das System eines der Beispiele 2610 bis 2611, das ferner das Zusammenführen einer oder mehrerer der transienten Funktionen und Subfunktionen umfasst.
Beispiel 2613 beinhaltet das System eines der Beispiele 2610 bis 2611, das ferner das gemeinsame Verwenden von Zustandsinformationen zwischen Ausführung einer oder mehrerer der transienten Funktionen und Subfunktionen umfasst.
Beispiel 2614 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, organisationsbezogenen Informationen für eine oder mehrere transiente Funktionen bereitzustellen und Ausführung der einen oder mehreren transienten Funktionen basierend auf den organisationsbezogenen Informationen zu ändern.
Beispiel 2615 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 2611, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine oder mehrere der transienten Funktionen in eine oder mehrere Subfunktionen zu spalten.
Beispiel 2616 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 2614 bis 2615, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine oder mehrere der transienten Funktionen und Subfunktionen zusammenzuführen.
Beispiel 2617 beinhaltet das mindestens eine computerlesbare Speichermedium der Beispiele 2614 bis 2615, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine oder mehrere Zustandsinformationen zwischen Ausführung einer oder mehrerer der transienten Funktionen und Subfunktionen gemeinsam zu verwenden.
Beispiele für Container-Wert-Hash-Cache
Einige Ausführungsformen des verbesserten FaaS-Systems können vorteilhafterweise einen Container-Wert-Hash-Cache bereitstellen. Ein Container-Wert kann einem beliebigen Datentyp entsprechen, der in einem Container gespeichert sein kann (zum Beispiel ein KV-Speicher, Text, Code, ein komprimiertes ausführbares Bild, Parameter, die in einem Funktionsaufruf verwendet werden, Resultate aus einer Funktionsausführung usw.). Speicher ist eine beschränkte Ressource und Containerwerte verbrauchen Speicherplatz. Einige Containerwerte können von vielen Funktionen verwendet werden, und EA-Bandbreite ist erforderlich, um solche Containerwerte zu laden/wieder zu laden. Einige Ausführungsformen können einen Hash-Index bereitstellen, um die Speichermenge, die zum Zugreifen auf einen gemeinsam verwendeten Containerwert benötigt wird, zu reduzieren. Bei einigen Ausführungsformen kann ein gemeinsam verwendeter Containerwert in Cache geladen werden. Einige Ausführungsformen können einen oder mehrere Containerwerte pinnen, um einen Aufwand des Neuladens der Containerwerte zu verhindern (den Container wird zum Beispiel kennzeichnen, damit er dauerhaft in dem Cache/Speicher behalten wird).
Unter Bezugnahme auf 28A kann eine Ausführungsform eines Verfahrens 2830 zum Bereitstellen einer Function-as-a-Service das Speichern eines gemeinsam verwendeten Containerwerts in einer Hash-Tabelle beinhalten, die sich zwei oder mehrere transiente Funktionen teilen, an Block 2831, und das Zugreifen auf den gemeinsam verwendeten Containerwert, der in der gemeinsam verwendeten Hash-Tabelle gespeichert ist, mit einem Hash-Index an Block 2832. Einige Ausführungsformen des Verfahrens 2830 können ferner das Zwischenspeichern der gemeinsam verwendeten Hash-Tabelle bei Block 2833 beinhalten. Das Verfahren 2830 kann auch das Pinnen des gemeinsam verwendeten Containerwerts in der gemeinsam verwendeten Hash-Tabelle bei Block 2834 beinhalten.
Ausführungsformen des Verfahrens 2830 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 2830 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 2830 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Verfahren 2830 kann zum Beispiel auf einem computerlesbaren Medium, wie in Verbindung mit den Beispielen 2811 bis 2813 unten beschrieben, umgesetzt werden. Ausführungsformen oder Abschnitte des Verfahrens 2830 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Einige Ausführungsformen des verbesserten FaaS-Systems, wie das eine 2840, das unten in Verbindung mit 28B beschrieben ist, kann vorteilhafterweise einen Containerwert-Hash-Cache bereitstellen. Bei einigen FaaS-Systemen werden sich wiederholende Konstanten nicht unter Funktionen gemeinsam verwendet. In einigen anderen FaaS-Systemen werden Funktionen unterschiedlich behandelt, so dass die Funktionen keine Werte gemeinsam verwenden. Einige Ausführungsformen des verbesserten FaaS-Systems 2840 können vorteilhafterweise eine Hash-Tabelle bereitstellen, um gemeinsam verwendete Konstanten, die von dem Container eingesetzt werden, zu speichern. Funktionen können vorteilhafterweise die Hash-Tabelle referenzieren, wodurch sie an EA-Bandbreite, Speicherplatz, Leistungseinsatz, Rechenressourcen usw., die ansonsten benötigt würden, um den (die) gemeinsam verwendeten Containerwert(e) zu laden, sparen.
Unter Bezugnahme auf 28B kann eine Ausführungsform eines verbesserten FaaS-Systems 2840 eine Hash-Tabelle 2842 beinhalten, die von einer oder mehreren transienten Funktionen 2844 gemeinsam verwendet werden. Die Hash-Tabelle 2842 kann mit einem Hashwert (zum Beispiel H₁ bis H_N) indexiert werden, um einen entsprechenden gemeinsam verwendeten konstanten Containerwert (zum Beispiel C₁ bis C_N) zurückzugeben.
Einige Ausführungsformen des FaaS-Systems 2840 können einen Konstantwert-Cache bereitstellen, der populiert werden kann, wenn der Prozess/Lambda/Container startet, und kann große konstante Werte (zum Beispiel Drehfaktoren zum Berechnen einer Fast-Fourier-Transformierten (FFT), neuronale Netzwerkfilterwerte usw.) in einem separaten Cache speichern. Für vierundsechzig (64) unterschiedliche Double-Float-Konstanten (zum Beispiel je 64 Bits) können einige Ausführungsformen zum Beispiel einen Sechs- (6) Bit-Index zum Zugreifen darauf verwenden (zum Beispiel 2⁶ Indexwerte zum Indexieren 64 unterschiedlicher Konstanten). Diese Werte können Zeit- oder Ladezeitkonstanten (zum Beispiel beim Injizieren von Schlussfolgerungs-Lambdas zu aufgewärmten neutralen Netz-Containern) kompilieren. Der Compiler-/JIT-/Code-Generator kann zuerst die konstanten Werte zu dem Cache für konstante Werte zu Beginn der Lambda-/Containerinitialisierung mit einer speziellen Speicheranweisung laden. Darauffolgende regelmäßige Ladevorgänge, die den konstanten Werten entsprechen, können mit einer speziellen Ladeanweisung ersetzt werden, die einen Index zu dem Cache für konstante Werte angibt. Einige Ausführungsformen des FaaS-Systems 2840 können vorteilhafterweise die Cache-Performance durch ein kompakteres Codieren von Ladungen verbessern. Einige Felder (zum Beispiel das MOD-Feld, das einen Adressierungsmodus spezifiziert, und das SIB-Feld, das die Skala, den Index und die Basis zum Berechnen von Speicheradressen spezifiziert) besonderer Architekturanweisungsformate, die für Speicherreferenzen erforderlich sind, werden eventuell nicht für Referenzen zu dem Cache für konstante Werte benötigt. Einige Ausführungsformen können auch Speicherordnungspuffereinträge (Memory Ordering Buffer - MOB-Einträge) freigeben und das Erfordernis des Prüfens auf Store-Forwarding zum Beispiel für Ladeanweisungen beseitigen, die aus dem Cache für konstante Werte lesen.
Einige Ausführungsformen des FaaS-Systems 2840 können auch sicherstellen, dass die Konstanten in den Cache für konstante Werte gepinnt und nicht herausgeworfen werden). Convolutional-Neural-Network-Filterwerte (CNN-Filterwerte) können während Schlussfolgerung zum Beispiel sehr häufig verwendet werden. Die Filterwerte können konstant sein, aber die große Anzahl von Eingangs-/Ausgangskanälen kann den Arbeitssatz eines CNN viel größer als die Kapazität des Cache machen. Als ein Resultat können Filterwerte innerhalb des Caches nicht resident sein, und bei einigen anderen Systemen können sie jedes Mal von dem Speicher über mehrere unterschiedliche Funktionsaufrufe zurückgebracht werden, was kostspielig sein kann und die Performance beeinträchtigt. Bei einigen Ausführungsformen des FaaS-Systems 2840 kann der Cache für konstanten Wert einmal geladen und von mehreren Lambda/Prozessen (einschließlich mehrere Schlussfolgerungs-Lambdas, die dieselben CNN-Filterwerte verwenden) gemeinsam verwendet werden, was vorteilhafterweise Rechen-, Speicher- und/oder EA-Ressourcen sparen kann.
Zusätzliche Anmerkungen und Beispiele
Beispiel 2801 beinhaltet ein elektronisches Verarbeitungssystem, das einen Prozessor, Speicher der kommunikationsfähig mit dem Prozessor gekoppelt ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher gekoppelt ist, beinhaltet, um einen gemeinsam verwendeten Containerwert in einer Hash-Tabelle zu speichern, die von zwei oder mehreren transienten Funktionen gemeinsam verwendet wird, und auf den gemeinsam verwendeten Containerwert, der in der gemeinsam verwendeten Hash-Tabelle gespeichert ist, mit einem Hash-Index zuzugreifen.
Beispiel 2802 beinhaltet das System des Beispiels 2801, wobei die Logik ferner die gemeinsam verwendete Hash-Tabelle zwischenspeichern soll.
Beispiel 2803 beinhaltet das System eines der Beispiele 2801 bis 2802, wobei die Logik ferner den gemeinsam verwendeten Containerwert in der gemeinsam verwendeten Hash-Tabelle pinnen soll.
Beispiel 2804 beinhaltet ein Halbleiter-Package-Gerät, das ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, aufweist, wobei die Logik mindestens teilweise in einer oder mehreren aus konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist, die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um einen gemeinsam verwendeten Containerwert in einer Hash-Tabelle zu speichern, die von zwei oder mehr transienten Funktionen gemeinsam verwendet wird, und auf den gemeinsam verwendeten Containerwert, der in der gemeinsam verwendeten Hash-Tabelle gespeichert ist, mit einem Hash-Index zuzugreifen.
Beispiel 2805 beinhaltet das Gerät des Beispiels 2804, wobei die Logik ferner die gemeinsam verwendete Hash-Tabelle zwischenspeichern soll.
Beispiel 2806 beinhaltet das Gerät eines der Beispiele 2804 bis 2805, wobei die Logik ferner den gemeinsam verwendeten Containerwert in der gemeinsam verwendeten Hash-Tabelle pinnen soll.
Beispiel 2807 beinhaltet das Gerät eines der Beispiele 2804 bis 2806, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche, die innerhalb des einen oder der mehreren Substrate positioniert sind, beinhaltet.
Beispiel 2808 beinhaltet ein Verfahren zum Bereitstellen einer Function-as-a-Service, die das Speichern eines gemeinsam verwendeten Containerwerts in einer Hash-Tabelle, die von zwei oder mehr transienten Funktionen gemeinsam verwendet wird, und das Zugreifen auf den gemeinsam verwendeten Containerwert, der in der gemeinsam verwendeten Hash-Tabelle gespeichert ist, mit einem Hash-Index umfasst.
Beispiel 2809 beinhaltet das Verfahren des Beispiels 2808, das ferner das Zwischenspeichern der gemeinsam verwendeten Hash-Tabelle umfasst.
Beispiel 2810 beinhaltet das Verfahren eines der Beispiele 2808 bis 2809, das ferner das Pinnen des gemeinsam verwendeten Containerwerts in der gemeinsam verwendeten Hash-Tabelle umfasst.
Beispiel 2811 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen gemeinsam verwendeten Containerwert in einer Hash-Tabelle, die von zwei oder mehr transienten Funktionen gemeinsam verwendet wird, zu speichern und auf den gemeinsam verwendeten Containerwert, der in der gemeinsam verwendeten Hash-Tabelle gespeichert ist, mit einem Hash-Index zuzugreifen.
Beispiel 2812 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 2811, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die gemeinsam verwendete Hash-Tabelle zwischenzuspeichern.
Beispiel 2813 beinhaltet das mindestens eine computerlesbare Speichermedium eines der Beispiele 2811 bis 2812, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, den gemeinsam verwendeten Containerwert in der gemeinsam verwendeten Hash-Tabelle zu pinnen.
Beispiele für Umkehr-/Undo-Container
Einige Ausführungsformen des verbesserten FaaS-Systems können vorteilhafterweise einen Umkehr-/Undo-Container bereitstellen. In einem FaaS-System können Stornierungsanforderungen oder Abstürze einige Ressourcen in einem unbestimmten Zustand hinterlassen. Bei einigen Ausführungsformen kann eine Umkehr-/Undo-Container registriert sein, um Ressourcen, die von einem Absturz/einer Stomierungsanfrage betroffen sind, zu bereinigen. Einige Ausführungsformen können besseren Ressourceneinsatz und/oder weniger unbestimmte Zustände bereitstellen.
Unter Bezugnahme auf 29A kann eine Ausführungsform eines Verfahrens 2930 zum Bereitstellen einer Function-as-a-Service, das das Bestimmen, ob eine transiente Funktion eine dazugehörende Bereinigungsfunktion, aufweist, bei Block 2931 und das Ausführen der dazugehörenden Bereinigungsfunktion, falls die transiente Funktion unterbrochen wird, bei Block 2932 beinhalten. Einige Ausführungsformen des Verfahrens 2930 können ferner das automatische Erzeugen der Bereinigungsfunktion bei Block 2933 beinhalten. Das Verfahren 2930 kann auch automatisches Registrieren der Bereinigungsfunktion bei Block 2934 beinhalten.
Ausführungsformen des Verfahrens 2930 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 2930 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 2930 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Verfahren 2930 kann zum Beispiel auf einem computerlesbaren Medium, wie in Verbindung mit den Beispielen 2911 bis 2913 unten beschrieben, umgesetzt werden. Ausführungsformen oder Abschnitte des Verfahrens 2930 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Einige FaaS-Systeme können als zustandslos betrachtet werden. Ein Beispiel eines „zustandslosen“ FaaS-Systems ist, dass es keinen überwachten Zustand von Funktionen, die von dem FaaS-System ausgeführt werden, gibt. Falls ein System oder eine Funktion abstürzt, kann ein Problem auftreten, weil kein Zustand aufgezeichnet ist. Falls eine Funktion zum Beispiel einige Daten ändert und dann abstürzt, ist das System eventuell nicht fähig zu bestimmen, wo es fortsetzen oder wie es vorgehen soll, um die Funktion zu beenden, zu bereinigen oder erneut zu starten (zum Beispiel weiß das FaaS-System nicht, welche Daten es rückgängig machen soll). Einige Ausführungsformen eines verbesserten FaaS-Systems wie des einen, 2940, das in 29B gezeigt ist, können vorteilhafterweise eine spezialisierte Funktion zum Rückgängigmachen von Schaden (zum Beispiel ergänzend oder in derselben Funktion enthalten) als ein Umgekehrtes zu der ursprünglichen Funktion bereitstellen.
Unter Bezugnahme auf 29B kann eine Ausführungsform eines verbesserten FaaS-Systems 2940 eine Funktion f(x), die vor Abschluss unterbrochen werden kann, aufrufen. Eine solche Unterbrechung kann zum Beispiel einer Stornierung der Funktion, einem Absturz der Funktion f(x), einem Absturz des FaaS-Systems 2940, einem Verlust einer benötigten Ressourcen usw. entsprechen. Im Anschluss an die Unterbrechung können einige Ausführungsformen des FaaS-Systems 2940 eine Bereinigungsfunktion f ^-1 (x) aufrufen, um ein oder mehrere Probleme, die von der Unterbrechung der Funktion f(x) verursacht werden, zu beheben. Die Funktion f ^-1(x) kann zum Beispiel als eine Undo-Funktion, eine umgekehrte Funktion, eine Umkehrfunktion usw. betrachtet werden.
Herkömmliche FaaS-Funktionen, zum Beispiel Amazon Web Services (AWS) Lambda™, werden als zustandslos angenommen, was einige von außen sichtbare Nebenwirkungen aufweisen kann. Eine Lambda-Funktion kann zum Beispiel einen Datenbankeintrag aktualisieren oder eine andere Lambda-Funktion, die selbst einige von außen sichtbare Nebenwirkungen aufweisen kann, aufrufen. Ein Befehl für das Liefern eines Elements kann zum Beispiel eine Reihe von FaaS-Funktionen/Lambda-Funktionen aufrufen. Falls der Befehl an irgendeinem Punkt storniert wird, muss die Stornierungsanforderung weiterverbreitet werden, und bestimmte Aktualisierungen/Aktionen müssen eventuell rückgängig gemacht werden. Einige Ausführungsformen des verbesserten FaaS-Systems 2940 können eine Undo-Funktion durch Aufrufen derselben Kette mit den ursprünglichen Parametern, wie JSON-Objekte ausführen, aber um die Nebenwirkungen rückgängig zu machen usw.
Einige Ausführungsformen des verbesserten FaaS-Systems 2940, können eine Umkehr-/Undo-Version einer FaaS-Funktion/Lambda-Funktion registrieren, die an Stelle der eigentlichen Lambda aufgerufen werden soll, um die Nebenwirkungen zu bereinigen, weisen auf, dass die Undo-Lambda-Funktion von dem Anwendungsentwickler bereitgestellt oder automatisch von einem Code-Generator erzeugt werden kann. Die Undo-Lambda-Funktion kann eine Kombination von Undo-Loggen beinhalten und kann Backward-Slice-Erzeugung auf eine umgekehrte modulare Art einsetzen (zum Beispiel ähnlich den Destruktor-Aufrufen von C++, um Mitgliedobjekte zu löschen).
Zusätzliche Anmerkungen und Beispiele
Beispiel 2901 beinhaltet ein elektronisches Verarbeitungssystem, das einen Prozessor, Speicher, der Kommunikationsfähigkeit mit dem Prozessor gekoppelt ist, und Logik, die Kommunikationsfähigkeit mit dem Prozessor und dem Speicher gekoppelt ist, um zu bestimmen, ob eine transiente Funktion eine dazugehörende Bereinigungsfunktion aufweist, und die dazugehörende Bereinigungsfunktion auszuführen, falls die transiente Funktion unterbrochen wird.
Beispiel 2902 beinhaltet das System des Beispiels 2901, wobei die Logik ferner die Bereinigungsfunktion erzeugen soll.
Beispiel 2903 beinhaltet das System eines der Beispiele 2901 bis 2902, wobei die Logik ferner die Bereinigungsfunktion erzeugen soll.
Beispiel 2904. Ein Halbleiter-Package-Gerät, das ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, aufweist, wobei die Logik mindestens teilweise in einer oder mehreren aus konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist, die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um zu bestimmen, ob eine transiente Funktion eine dazugehörende Bereinigungsfunktion aufweist, und die dazugehörende Bereinigungsfunktion auszuführen, falls die transiente Funktion unterbrochen wird.
Beispiel 2905 beinhaltet das Gerät des Beispiels 2904, wobei die Logik ferner die Bereinigungsfunktion aufzeichnen soll.
Beispiel 2906 beinhaltet das Gerät eines der Beispiele 2904 bis 2905, wobei die Logik ferner die Bereinigungsfunktion erzeugen soll.
Beispiel 2907 beinhaltet das Gerät eines der Beispiele 2904 bis 2906, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche, die innerhalb des einen oder der mehreren Substrate positioniert sind, beinhaltet.
Beispiel 2908. Ein Verfahren zum Bereitstellen einer Function-as-a-Service, das das Bestimmen, ob eine transiente Funktion einer dazugehörende Bereinigungsfunktion aufweist, und das Ausführen der dazugehörenden Bereinigungsfunktion, falls die transiente Funktion unterbrochen wird.
Beispiel 2909 beinhaltet das Verfahren des Beispiels 2908, das ferner das Aufzeichnen der Bereinigungsfunktion umfasst.
Beispiel 2910 beinhaltet das Verfahren eines der Beispiele 2908 bis 2909, das ferner das automatische Erzeugen der Bereinigungsfunktion umfasst.
Beispiel 2911. Mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, zu bestimmen, ob eine transiente Funktion eine dazugehörende Bereinigungsfunktion aufweist und die dazugehörende Bereinigungsfunktion auszuführen, falls die transiente Funktion unterbrochen wird.
Beispiel 2912 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 2911, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von dem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Bereinigungsfunktion auszuführen.
Beispiel 2913 beinhaltet das mindestens eine computerlesbare Speichermedium eines der Beispiele 2911 bis 2912, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von dem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Bereinigungsfunktion automatisch zu erzeugen.
Beispiele für Container-Fortsetzungsweitergabestil
Einige Ausführungsformen des verbesserten FaaS-Systems wie des einen, das in 4 gezeigt ist, können vorteilhafterweise Fortsetzungsweitergabestile für Container bereitstellen. FaaS-Funktionen sind unabhängige Ausführungseinheiten und zusätzlicher Aufwand kann auftreten, wenn unterschiedliche FaaS-Funktionen eine Beziehung haben (zum Beispiel Daten zwischen Funktionen weitergeben). Einige Ausführungsformen des verbesserten FaaS-Systems können Weitergabefähigkeit bereitstellen, um Informationen zwischen Funktionszellen zu übergeben. Bei einigen Ausführungsformen kann ein bedingter Funktionsaufruf Teil der Weitergabedaten sein. Vorteilhafterweise können einige Ausführungsformen besseren Ressourceneinsatz, reduzierte EA-Bandbreite und/oder schnellere Ausführung bereitstellen.
Unter Bezugnahme auf 30A kann eine Ausführungsform eines Verfahrens 3030 zum Bereitstellen einer Function-as-a-Service das Ausführen einer transienten Funktion, die eine Fortsetzungsfunktion als einen Parameter der transienten Funktion beinhaltet, bei Block 3031 beinhalten, und zum Ausführen der Fortsetzungsfunktion von der transienten Funktion bei Block 3032. Einige Ausführungsformen des Verfahrens 3030 können ferner das rekursive Weitergeben eines oder mehrerer Codes, von Kontext und Daten für die Fortsetzungsfunktion bei Block 3033 beinhalten. Das Verfahren 3030 kann zum Beispiel das Weitergeben von Wiederherstellungscode als Teil der Fortsetzungsfunktionen bei Block 3034 beinhalten.
Ausführungsformen des Verfahrens 3030 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 3030 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 3030 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flash-Speicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Das Verfahren 3030 kann zum Beispiel auf einem computerlesbaren Medium, wie in Verbindung mit den Beispielen 3011 bis 3013 unten beschrieben, umgesetzt werden. Ausführungsformen oder Abschnitte des Verfahrens 3030 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Bei einigen FaaS-Systemen sind Funktionen unabhängige Funktionseinheiten und Delegationsprobleme können zwischen unterschiedlichen Funktionen auftreten, da sich unterschiedliche Delegationstaktiken auf die Performance auswirken können. Einige Ausführungsformen des verbesserten FaaS-Systems 3040, wie in 30B gezeigt, können vorteilhafterweise eine Fortsetzungsfunktion, wie eine Lambda-Funktion oder eine andere Funktion, zu anderen aufgerufenen Funktionen weitergeben, um die Funktionsausführungsperformance zu verbessern. Das kann als ein Mechanismus zum Durchsetzen von „Idempotenz“ über mehrere Funktionen betrachtet werden und es kann leistungsfähiger sein, idempotente Funktionen auszuführen. Eine Funktion mit Nebenwirkungen kann als idempotent betrachtet werden, falls der Systemzustand und/oder darunterliegende Daten, auf die die Funktion zugreift, dieselben Werte nach allen Instanzen der vollständigen Ausführung der Funktion ungeachtet wie auf die Funktion aufgerufen wird, ohne irgendwelche verschachtelte Ausführungsformen andere Funktionen aufweist. Funktionen können ursprünglich als frei von Nebenwirkungen betrachtet werden, es gibt aber Verwendungsfälle, bei welchen Funktionen extern gemeinsam verwendete Ressourcen (zum Beispiel Datenbanken und/oder Datenstrukturen) ändern, was in Nebenwirkungen resultieren kann. Angesichts der asynchronen Beschaffenheit von Funktionsaufrufen, delegiert der hierin besprochene Ansatz die Ausführung mutierender Vorgänge (zum Beispiel Funktionen, die extern gemeinsam verwendete Ressourcen, wie Datenbanken und/oder Datenstrukturen, ändern) zu der letzten Funktion innerhalb der Aufrufkette.
Unter Bezugnahme auf 30B kann eine Ausführungsform eines verbesserten FaaS-Systems 3040 rekursive Funktionsaufrufe beinhalten, bei welchen eine Funktion f Daten und Code weitergeben kann, um eine Funktion g aufzurufen, die Funktion g Daten und Code weitergeben kann, um eine Funktion h aufzurufen und so fort. Jede Fortsetzungsfunktion wird nämlich mit dem aktuellen Funktionszustand der Parent-Funktion aktualisiert und gibt dann den aktuellen Funktionszustand der Fortsetzungsfunktion zu einer Child-Funktion weiter. Bei dem veranschaulichten Beispiel gibt die Funktion / somit aktuelle Funktionszustandsdaten (cont_f) zu Funktion g weiter. „cont_f“ ruft nämlich Funktion g auf und wird als ein aktueller Funktionszustand der Funktion f betrachtet. Die Funktion g empfängt den aktuellen Funktionszustand der Funktion f, und aktualisiert den Funktionszustand auf „cont_f.g.“, was auch die Funktion h aufruft und so fort. Die Aufrufe dienen daher auch dazu, eine klare Übereinstimmung von Funktionszuständen aufrechtzuerhalten, so dass Reverse-Engineering und/oder die Debugging möglich ist.
Einige Ausführungsformen des verbesserten FaaS-Systems 3040 können Technologie/Fähigkeiten zu Funktionsaufrufen hinzufügen, um in der Lage zu sein, Code, Daten, Kontext usw. zu den aufgerufenen Funktionen weiterzugeben. Die Aufgerufenenfunktionen können dann rekursiv Code, Datenkontext usw. nach unten weitergeben. Die Funktion g ist zum Beispiel die Aufgerufene der Funktion f, die Daten zu Funktion g weitergibt; die Funktion h ist die Aufgerufene der Funktion g, die die Daten zu Funktion h weitergegeben hat. Einige Ausführungsformen des verbesserten FaaS-Systems 3040 können vorteilhafterweise verzögerte Ausführung bestimmter Aktionen (zum Beispiel Aktionen mit extern sichtbaren Nebenwirkungen) ermöglichen, bis bestimmte Anforderungen erfüllt sind. Einige Ausführungsformen des verbesserten FaaS-Systems 3040 können auch Wiederherstellungs-/Rücksetzcode weitergeben, der ausgeführt werden soll, falls bestimmte Ausnahmen/Bedingungen während der Funktionsaufrufkette durch die obige Entsprechung der Funktionszustände auftreten. Vorteilhafterweise können einige Ausführungsformen des verbesserten FaaS-Systems 3040 dabei behilflich sein, robuste Lösungen umzusetzen und zweckdienliche/effiziente Ausnahmehandhabung zu ermöglichen.
Einige Ausführungsformen des verbesserten FaaS-Systems 3040 können Fortsetzungsweitergabestile unterstützen, wobei Kontext und Datenstrukturen als Standard-Datenaustauschformate, wie Protokollpuffer, weitergegeben werden können. Code, der ausgeführt werden soll, kann in eine Lambda-Funktion gekapselt werden, und Lambda-Adresse/ID können auch gemeinsam mit dem Kontext weitergegeben werden. Bei einigen Ausführungsformen können die Wiederherstellungs-/verzögerten Nebenwirkungen von Lambda-Code von dem Compiler/Codegenerator aus der ursprünglichen Lambda extrahiert werden.
Zusätzliche Anmerkungen und Beispiele
Beispiel 3001 beinhaltet ein elektronisches Verarbeitungssystem, das einen Prozessor, einen Speicher, der kommunikationsfähig mit dem Prozessor gekoppelt ist, und Logik, die kommunikationsfähig mit dem Prozessor und dem Speicher gekoppelt ist, umfasst, um eine transiente Funktion auszuführen, die eine Fortsetzungsfunktion als einen Parameter der transienten Funktion beinhaltet, und die Fortsetzungsfunktion von der transienten Funktion auszuführen.
Beispiel 3002 beinhaltet das System des Beispiels 3001, wobei die Logik ferner einen oder mehrere von Code, Kontext und Daten für die Fortsetzungsfunktion rekursiv weitergeben soll.
Beispiel 3003 beinhaltet das System des Beispiels 3001 bis 3002, wobei die Logik ferner Wiederherstellungscode als Teil der Fortsetzungsfunktion weitergeben soll.
Beispiel 3004 beinhaltet ein Halbleiter-Package-Gerät, das ein oder mehrere Substrate und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, umfasst, wobei die Logik mindestens teilweise in einer oder mehreren aus konfigurierbarer Logik und Hardware-Logik mit feststehender Funktionalität umgesetzt ist, die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um eine transiente Funktion auszuführen, die eine Fortsetzungsfunktion als einen Parameter der transienten Funktion beinhaltet, und die Fortsetzungsfunktion von der transienten Funktion auszuführen.
Beispiel 3005 beinhaltet das Gerät des Beispiels 3004, wobei die Logik ferner einen oder mehrere von Code, Kontext und Daten für die Fortsetzungsfunktion rekursiv weitergeben soll.
Beispiel 3006 beinhaltet das Gerät eines der Beispiele 3004 bis 3005, wobei die Logik ferner Wiederherstellungscode als Teil der Fortsetzungsfunktion weitergeben soll.
Beispiel 3007 beinhaltet das Gerät eines der Beispiele 3004 bis 3006, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, Transistorkanalbereiche, die innerhalb des einen oder der mehreren Substrate positioniert sind, beinhaltet.
Beispiel 3008. Verfahren zum Bereitstellen einer Function-as-a-Service, das das Ausführen einer transienten Funktion, die eine Fortsetzungsfunktion als einen Parameter der transienten Funktion beinhaltet, und das Ausführen der Fortsetzungsfunktion von der transienten Funktion umfasst.
Beispiel 3009 beinhaltet das Verfahren des Beispiels 3008, wobei die Logik das rekursive Weitergeben eines oder mehrerer von Code, Kontext und Daten für die Fortsetzungsfunktion umfasst.
Beispiel 3010 beinhaltet das Verfahren des Beispiels 3008 bis 3009, das ferner das Weitergeben von Wiederherstellungscode als Teil der Fortsetzungsfunktion umfasst.
Beispiel 3011. Mindestens ein computerlesbares Speichermedium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine transiente Funktion auszuführen, die eine Fortsetzungsfunktion als einen Parameter der transienten Funktion beinhaltet, und die Fortsetzungsfunktion von der transienten Funktion auszuführen.
Beispiel 3012 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 3011, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine oder mehrere der transienten Funktionen in eine oder mehrere Subfunktionen zu spalten.
Beispiel 3013 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 3011 bis 3012, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von dem Rechengerät ausgeführt werden, das Rechengerät veranlassen, Wiederherstellungscode als Teil der Fortsetzungsfunktion weiterzugeben.
Beispiele für zweckmäßigen Containeraufbau und Cache-Management
Ein FaaS-System kann ein ereignisgetriebenes Modell mit periodischen und zufälligen Ereignissen sein. Gewöhnlich ergibt sich daher eine Situation, bei der dieselben Funktionen und/oder Funktionen desselben oder ähnlichen Container einsetzen, der einen Datensatz (zum Beispiel Datenobjekte) beinhaltet, den die Funktionen während der Ausführung einsetzen werden. Die Funktionen können mehrmals innerhalb einer kurzen Zeitspanne ausgeführt werden. Bei einigen Architekturen kann ein neuer Container pro Funktionsausführung mit der Ausnahme einiger Fälle, bei welchen Container durch einen Ansatz mit warmem Container wiederverwendet werden können, verwendet werden. Das Aufrechterhalten eines warmen Containers kann unnötig Ressourcen verbrauchen. Ein warmer Container kann zum Beispiel während des Wartens auf eine Funktion zur Ausführung im Ruhezustand bleiben. Die Ruhezeit kann unproduktiv sein. Darüber hinaus kann Container-Wiederverwendung oder gemeinsame Verwendung für einen Container spezifisch und nicht an alle Situationen anwendbar sein.
Im Gegensatz dazu kann ein warmer Container abgebaut werden, und ein kalter Container kann gestartet werden, wenn eine Funktion aufgerufen wird. Das Aufbauen, Initiieren und Startup des Containers kann mehrere Stufen beinhalten, wie das Konfigurieren eines Namensraums und von Steuergruppen, das Einrichten des Netzwerks und das Einrichten einer Ausführungsumgebung. Die Ausführungsumgebung kann Benutzerdaten und andere Anforderungen beinhalten. Einige andere Anforderungen können diverse Schlüssel, CPU-/Speicher-/Platten-Kapazitätsreservierungen oder Prioritäten, Datenbanken, Datensätze, Schlüsselwertspeicher, Übersetzungswörterbücher, Ressourcennutzung-Credits usw. beinhalten. Weitere Beispiele anderer Anforderungen können auch neuronale Netzwerke, Datei- oder Netzwerkdeskriptoren, die einmal geöffnet und dann zur Wiederverwendung zwischengespeichert wurden, und/oder zwischengespeicherte aufgelöste Bilder ausführbarer Programme beinhalten.
Wie oben beschrieben, weist Container-Startup (Startup eines kalten Containers) eine beträchtliche Latenz auf und verbraucht Ressourcen. Die Container-Startup- Zeit kann die Performance der FaaS beeinträchtigen und eine Reduktion der Startup-Zeit ist wünschenswert.
Unter Bezugnahme auf die 31A ist ein FaaS-Beispiel 3100 veranschaulicht, bei dem ein Container auf zweckmäßige Art neu aufgebaut werden kann, ohne einen warmen Container einzusetzen und/oder alle Daten, die zum Aufbauen eines Containers benötigt werden, überhaupt zu speichern. Eine verbesserte FaaS-Architektur des Beispiels 3100 kann einen Cache 3102, Cache-Controller 3104, Aufbewahrungsstrategiemanager 3106 und Startup-Timer 3108 beinhalten. Der Cache 3102, der Cache-Controller 3104, der Aufbewahrungsstrategiemanager 3106 und der Startup-Timer 3108 können Teil desselben Rechenknotens sein (zum Beispiel ein Rechengerät, Server, ein Mobilgerät usw.). Wie unten ausführlicher erklärt, kann die verbesserte FaaS-Architektur einen Subsatz eines Containers identifizieren und den Subsatz an Stelle des Zurückforderns oder Abbauens des Containers als ein Ganzes speichern. Der Subsatz kann ein Arbeitssatz genannt werden. Dabei können warme Container abgebaut werden, um Ressourcenverbrauch zu reduzieren, und Container können rasch wieder aufgebaut werden, wenn sie benötigt werden, um Latenz zu verringern.
Die Ressourcen des Containers können folglich als ein Arbeitssatz bezeichnet werden. Ein „heißer“ aktiver Arbeitssatz kann daher bereits in dem Cache 3102 gespeichert werden, was erlaubt, dass weniger aktive Teile des Containers entfernt können. Gemeinsam verwendete Arbeitssätze können Sätze sein, die von Funktionen gemeinsam verwendet werden, und viele umfassen Gewichte, Konstanten, Formeln, Datenbanken gemeinsamer Daten (zum Beispiel Namen, Bilder, Karten usw.), Benutzerdaten, diverse Schlüssel, CPU-Speicher-/Plattenkapazitätreservierungen oder Prioritäten, Datensätze, Schlüsselwertspeicher, Übersetzungswörterbücher, Ressourcennutzungs-Credits, neuronale Netzwerke, Datei- oder Netzwerkdeskriptoren, die einmal geöffnet und dann zur Wiederverwendung zwischengespeichert wurden, und/oder zwischengespeicherte aufgelöste Bilder ausführbarer Programme. Solche Arbeitssätze können in dem Cache 3102 geführt und von der FaaS-Architektur gemanagt werden, um Zugang zu den Arbeitssätzen zu gewähren. Jedem Arbeitssatz kann eine Time-To-Live zugewiesen werden, die jedes Mal verlängert wird, wenn eine Funktion auf den Arbeitssatz zugreift. Die Arbeitssätze können aus dem Cache 3102 basierend auf einer Verwendungshäufigkeit der Daten (wie unten erklärt) geräumt werden, sowie auch als eine Messung von Startup-Zeit zum Initiieren eines Containers ohne den Arbeitssatz und die Time-To-Live. Falls zum Beispiel ein Arbeitssatz eine große Verwendungshäufigkeit aufweist, kann dieser Arbeitssatz aufrechterhalten werden, sogar wenn die Setup-Zeit kurz ist.
Wie veranschaulicht, beinhaltet der Cache 3102 einen Cache-Raum 3112, der zwei Arbeitssätze speichert: den Arbeitssatz C(1) (der auch als Datenobjekte bezeichnet werden kann) und den Arbeitssatz C(2) (der auch als Datenobjekte bezeichnet werden kann). C(1) ist eine Abkürzung für einen ersten Container, und C(2) ist eine Abkürzung für einen zweiten Container. Der erste und der zweite Container können Datensätze beinhalten, die von Funktionen während der Ausführung eingesetzt werden. Der Arbeitssatz C(1) ist der Arbeitssatz für den ersten Container, und der Arbeitssatz C(2) ist der Arbeitssatz für den zweiten Container. Bei dem Beispiel wurden sowohl der erste als auch der zweite Container abgebaut und sind inaktiv (zum Beispiel nicht aufgebaut). Wenn der erste und der zweite Container abgebaut werden, werden die Arbeitssätze C(1) und C(2) in dem Cacheraum 3112 aufrechterhalten, um den ersten und den zweiten Container, falls sie aufgerufen werden, rasch aufzubauen. Der Arbeitssatz C(1) kann zum Beispiel verwendet werden, um den ersten Container aufzubauen, und der Arbeitssatz C(2) kann verwendet werden, um den zweiten Container aufzubauen.
Das Behalten der Arbeitssätze C(1) und C(2) in den Cacheräumen 3112 kann die darauffolgende Ausführung von Funktionen in dem ersten oder dem zweiten Container beschleunigen. Der erste und der zweite Container können nämlich mindestens zum Teil basierend auf den Arbeitssätzen C(1) und C(2) wieder aufgebaut werden. Bei einigen Ausführungsformen können die Arbeitssätze C(1) und C(2) alle Daten beinhalten, um jeweils den ersten und den zweiten Container aufzubauen. Bei einigen Ausführungsformen können die Arbeitssätze C(1) und C(2) einen Subsatz von Daten beinhalten, um jeweils den ersten und den zweiten Container aufzubauen. Einige Daten können zum Beispiel mehreren unterschiedlichen Containern gemeinsam sein. Solche Daten können als die Arbeitssätze C(1) und C(2) gespeichert werden, und als solche können die Arbeitssätze C(1) und C(2) jeweils verwendet werden, um mehrere unterschiedliche Container aufzubauen. Bei einigen Ausführungsformen können die Arbeitssätze C(1) und C(2) Datenobjekte beinhalten, um jeweils das Aufbauen des ersten und des zweiten Containers zu beginnen, wobei der Rest der Datenobjekte zum Aufbauen des ersten und des zweiten Containers ankommt, während die erste und die zweite Funktion aufgebaut werden.
Bei einigen Ausführungsformen benötigt der erste oder der zweite Container eventuell weitere Daten zum Unterstützen der Ausführung einer Funktion. Ein vollständig aufgebauter erster oder zweiter Container ist nämlich eventuell nicht in der Lage, eine Funktion in Abhängigkeit von Anforderungen der Funktion zu unterstützen. Der erste oder der zweite Container können daher aufgebaut und geändert werden, um weitere Daten zu beinhalten, und um es dem geänderten ersten oder zweiten Container zu erlauben, die Funktion zu unterstützen. Die weiteren Daten können von einer Datenquelle (zum Beispiel einem anderen Rechenknoten, Datenbankserver usw.) empfangen werden. Die Größe der Arbeitssätze C(1) und C(2) und der Startup-Zeiten des ersten und des zweiten Containers sind bei unterschiedlichen Funktionen unterschiedlich, insbesondere, falls die ersten Container und die zweiten Container mit weiteren Daten erweitert werden sollen, um die Ausführung zu erleichtern.
Einige Räumungsstrategien können fast ausschließlich auf der Nutzungshäufigkeit und darauf, ob die Daten gespeichert werden sollen, basieren. In FaaS-Umgebungen ist eine Container-Startup-Zeit (die gleich der Funktions-Startup-Zeit sein kann) nicht unbedeutend und muss folglich eventuell während der Räumung berücksichtigt werden. Das Beispiel 3100 weist daher eine verbesserte Räumungsstrategie für die Arbeitssätze C(1) und C(2) auf, um Startup-Zeiten zu berücksichtigen und Container-Startups zu verbessern.
Wie veranschaulicht, wird ein Startup-Timer 3108 bereitgestellt. Der Startup-Timer 3108 kann die Startup-Zeiten des ersten und des zweiten Containers messen und die gemessenen Startup-Zeiten (zum Beispiel Aufbauzeiten) als T(1) und T(2) in Tabelle 3114 speichern. Die Aufbauzeit T(1) ist zum Beispiel die Zeitmessung zum Aufbauen des ersten Containers (ursprüngliche Ausführung). Der erste Container kann als vollständig aufgebaut betrachtet werden, wenn der erste Container mit der Ausführung einer Funktion beginnen kann. Auf ähnliche Art ist die Aufbauzeit T(2) (ursprüngliche Ausführung) die Zeitmessung zum Aufbauen des zweiten Containers. Der zweite Container kann als vollständig aufgebaut betrachtet werden, wenn der zweite Container mit der Ausführung einer Funktion beginnen kann. Die Tabelle 3114 kann eine Datenstruktur zum Speichern der Arbeitssätze jedes Containers, der aufgebaut wird, und seiner Aufbauzeit sein.
Der verbesserte Cache-Controller 3104 kann Räumungen aus dem Cache 3102 steuern. Der Cache-Controller 3104 kann auf die Tabelle 3114 zugreifen oder eine Meldung von dem Startup-Timer 3108 empfangen, die die Informationen, die in der Tabelle 3114 gespeichert sind, enthält. Der Cache-Controller 3104 kann die Aufbauzeiten T(1) und T(2) einsetzen, wenn er Räumungen aus dem Cache 3102 bestimmt. Der Cache-Controller 3104 kann daher die Aufbauzeiten T(1) und T(2) des ersten und des zweiten Containers einsetzen, wenn er bestimmt, ob er den Arbeitssatz C(1) oder den Arbeitssatz C(2) räumen soll.
Der Cache-Controller 3104 kann zum Beispiel einen Räumungsstrategiemanager 3110 beinhalten. Der Räumungsstrategiemanager 3110 kann unterschiedlich gewichtete Formeln basierend auf den Aufbauzeiten T(1) und T(2) erzeugen und solche Werte in Tabelle 3116 speichern. Der Räumungsstrategiemanager 3110 kann zum Beispiel eine erste gewichtete Formel für den Arbeitssatz C(1) aufbauen. Die erste gewichtete Formel kann eine gewichtete Funktion F(T(1)) beinhalten. F(T(1)) kann eine Funktion sein, die Aufbauzeit T(1) als eine Eingabe akzeptiert und einen Wert, der von der Aufbauzeit T(1) abgeleitet ist, ausgibt. Auf ähnliche Art wird für den Arbeitssatz C(2) eine zweite gewichtete Formel erzeugt. Die zweite gewichtete Formel kann eine gewichtete Funktion F(T(2)) beinhalten. F(T(2)) kann eine Funktion sein, die Aufbauzeit T(2) als eine Eingabe akzeptiert und einen Wert, der von der Aufbauzeit T(2) abgeleitet ist, ausgibt. Tabelle 3116 speichert die erste und die zweite gewichtete Formel.
Sowohl die erste als auch die zweite gewichtete Formel kann auch weitere Werte beinhalten. Zum Beispiel kann die erste gewichtete Formel eine Funktion K(1, AC(1)) beinhalten, die eine andere Funktion sein kann, die auf einer Zugriffshäufigkeit AC(1) des Arbeitssatzes C(1) basiert. Die Funktion K(1) kann zum Beispiel eine Anzahl von Zugriffen AC(1) des Arbeitssatzes C(1) als eine Eingabe akzeptieren, um eine Ausgabe zu erzeugen. Auf ähnliche Art kann die Funktion K(2) eine Anzahl von Zugriffen AC(2) des Arbeitssatzes C(2) als eine Eingabe akzeptieren, um eine Ausgabe zu erzeugen. Die erste und die zweite gewichtete Formel können auch weitere Werte beinhalten. Die erste und die zweite gewichtete Formel können Summierungen der obigen Funktionen sein.
Der Räumungsstrategiemanager 3110 kann die erste und die zweite gewichtete Formel referenzieren, um zu bestimmen, ob der Arbeitssatz C(1) oder der Arbeitssatz C(2) aus dem Cache 3102 geräumt werden soll. Der Räumungsstrategiemanager 3110 kann zum Beispiel einen ersten finalen Wert bestimmen, der eine Gesamtberechnung der ersten gewichteten Formel ist, und einen zweiten finalen Wert, der eine Gesamtberechnung der zweiten gewichteten Formel ist. Der erste und der zweite finale Wert können in Tabelle 3116 des Räumungsstrategiemanagers 3110 gespeichert werden. Der Räumungsstrategiemanager 3110 kann den ersten und den zweiten finalen Wert vergleichen, um zu bestimmen, ob der Arbeitssatz C(1) und C(2) geräumt werden sollen. Der Räumungsstrategiemanager 3110 vergleicht daher die Aufbauzeiten T(1) und T(2) miteinander und/oder eine Anzahl von Zugriffen AC(1) und AC(2) auf die Arbeitssätze C(1) und C(2).
Als ein Beispiel können der erste und der zweite finale Wert zu einer Startup-Zeit jeweils des ersten und des zweiten Containers und einer Anzahl von Datenzugriffen AC(1) und AC(2) jeweils auf die Arbeitssätze C(1) und C(2) proportional sein. Falls daher der erste finale Wert größer ist als der zweite finale Wert, kann auf den Arbeitssatz C(1) mehr zugegriffen werden als auf den Arbeitssatz C(2), und/oder der erste Container kann eine höhere Startup-Zeit im Vergleich zu dem zweiten Container aufweisen. Das Räumen des Arbeitssatzes C(1) würde daher in größeren Gesamtlatenzen im Vergleich zu dem Räumen des Arbeitssatzes C(2) resultieren. Der Räumungsstrategiemanager 3110 kann daher den Arbeitssatz C(2) basierend auf dem ersten und dem zweiten finalen Wert räumen. Der Räumungsstrategiemanager 3100 kann daher einen Arbeitssatz, der mit einem kleinsten finalen Wert verbunden ist, räumen.
Der Cache-Controller 3104 kann auch einen Aufbewahrungsstrategiemanager 3106 beinhalten. Der Aufbewahrungsstrategiemanager 3106 kann unterschiedliche gewichtete Formeln erzeugen, um eine Time-To-Live für die Arbeitssätze C(1) und C(2) zu bestimmen. Die Time-To-Live kann in Tabelle 3118 gespeichert werden. Der Aufbewahrungsstrategiemanager 3106 kann zum Beispiel eine dritte gewichtete Formel für den ersten Container aufbauen. Die dritte gewichtete Formel kann eine Funktion G(T(1)) beinhalten, die eine Aufbauzeit T(1) und eine Funktion L(1) als eine Eingabe akzeptiert, um einen Wert, der von der Aufbauzeit T(1) abgeleitet wird, auszugeben. Auf ähnliche Art wird eine vierte gewichtete Formel für den zweiten Container erzeugt. Die vierte gewichtete Formel kann eine Funktion G(T(2)) beinhalten, die eine Aufbauzeit T(2) und eine Funktion L(2) als eine Eingabe akzeptiert, um einen Wert, der von der Aufbauzeit T(2) abgeleitet wird, auszugeben. Die dritte und die vierte gewichtete Formel können auch andere Werte beinhalten, wie Konstanten und/oder eine Anzahl von Datenzugriffen jeweils auf die Arbeitssätze C(1) und C(2). Der Wert, der aus der dritten gewichteten Formel abgeleitet wird, kann eine Time-To-Live für den Arbeitssatz C(1) sein, und der Wert, der aus der vierten gewichteten Formel abgeleitet wird, kann eine Time-To-Live für den zweiten Arbeitssatz C(2) sein. Tabelle 3118 zeigt die dritte und die vierte gewichtete Formel.
Bei einigen Ausführungsformen bestimmt der Aufbewahrungsstrategiemanager 3106 nur die „Time-To-Live“ für einen Arbeitssatz. Der Aufbewahrungsstrategiemanager 3106 ermöglicht es folglich im Wesentlichen dem Räumungsstrategiemanager 3110, eine fundiertere Entscheidung über priorisierte Räumungen, die nicht allein auf der Time-To-Live basieren, zu fällen. Bei einigen Ausführungsformen können die Resultate des Aufbewahrungsstrategiemanagers 3106 von dem Räumungsstrategiemanager 3110 verwendet werden, um fundiertere Entscheidungen zu fällen, und sind ein Faktor in der ersten und der zweiten gewichteten Formel. Bei solchen Ausführungsformen räumt der Aufbewahrungsstrategiemanager 3106 eventuell keine Daten aus dem Cache 3102, sondern überlässt solche Entscheidungen dem Räumungsstrategiemanager.
Bei einigen Ausführungsformen können der Aufbewahrungsstrategiemanager 3106 und der Räumungsstrategiemanager 3110 unabhängig voneinander arbeiten, um die Arbeitssätze C(1) und C(2) nach Bedarf zu entfernen. Der Räumungsstrategiemanager 3110 kann zum Beispiel ausgelöst werden, um Daten als Reaktion auf eine Bestimmung, dass der Cache 3102 voll ist und mehr freier Platz für eine andere FaaS-Funktion erforderlich ist, zu räumen. Der Räumungsstrategiemanager 3110 kann dann bestimmen, ob der Arbeitssatz C(1) oder der Arbeitssatz C(2) wie oben beschrieben geräumt werden soll. Der Aufbewahrungsstrategiemanager 3106 kann einfach identifizieren, wenn eine Time-To-Live abgelaufen ist, und den entsprechenden Arbeitssatz C(1) oder C(2) ungeachtet der Menge an freien Raum in dem Cache 3102 räumen. Der Räumungsstrategiemanager 3110 kann nämlich ausgelöst werden, um Arbeitssätze durch eine Identifikation, dass mehr freier Raum in dem Cache 3102 benötigt wird, zu entfernen, während der Aufbewahrungsstrategiemanager 3106 durch eine solche Identifikation nicht ausgelöst werden kann.
Bei einigen Ausführungsformen kann jeder Arbeitssatz C(1) und C(2) einen separaten Timer besitzen. Die berechneten Time-To-Live-Werte können mit den Timern verglichen werden. Wenn einer der Timer für einen der Arbeitssätze C(1) und C(2) den Time-To-Live-Wert für den einen Arbeitssatz erfüllt, kann der eine Arbeitssatz geräumt werden. Als ein Beispiel kann, wenn die entsprechenden Time-To-Live das Timeout erreicht, wie von einem Zähler gezählt und von dem Aufbewahrungsstrategiemanager 3106 identifiziert, kann der Arbeitssatz C(1) oder der Arbeitssatz C(2) geräumt werden. Die Timer können jedes Mal, wenn auf den Arbeitssatz C(1) oder C(2) zugegriffen wird, zurückgestellt werden. Falls zum Beispiel auf den Arbeitssatz C(1) zugegriffen wird, würde der Timer für den Arbeitssatz C(1) zurückgestellt. Im Gegensatz kann der Timer des Arbeitssatzes C(2) nicht zurückgesetzt werden, da auf C(2) nicht zugegriffen wurde. Die Timer können auch automatisch und/oder administrativ als Reaktion auf eine Identifikation eines Erfordernisses, Ressourcen freizugeben oder ausgewählten Kategorien von Anforderungen hohe Prioritäten einzuräumen, zurückgestellt werden. Bei einigen Ausführungsformen werden die Timer eventuell nicht zurückgestellt, und die Time-To-Live stellt eine maximale Time-To-Live dar.
Der Cache 3102 kann ein Hardware-Cache (zum Beispiel LLC, TLBs) oder ein Software Objekt-Cache (zum Beispiel Java Persistent Objects Cache) sein. Der Cache 3102 kann zum Beispiel ein Seitencache sein. Außerdem kann der Cache-Controller 3104 mehrere Caches oder Ebenen von Caches steuern. Darüber hinaus kann ein Räumungsereignis durch einen Mangel an Speicherraum für eingehende Daten ausgelöst und von dem Cache-Controller 3104 überwacht werden.
Als ein Beispiel kann der erste Container eine erste Funktion zur Bilderkennung ausführen, und der zweite Container kann eine zweite Funktion zur Bilddrehung ausführen. Ein Bilderkennungs-Startup für die erste Funktion kann das Initialisieren eines neuronalen Netzwerks des ersten Containers involvieren. Die Aufbauzeit T(1) für den ersten Container kann folglich erheblich höher sein als die Aufbauzeit T(2) für den zweiten Container. Der Speicherfußabdruck der Bilderkennung kann höher sein, und das die Container Aktivhalten zur Wiederverwendung zu halten, kann kostspielig sein. Ferner kann die Ausführungshäufigkeit von Bilderkennung niedriger sein als die Bilddrehungsfunktion. Die Anzahl von Zugriffen auf die Daten des ersten Containers kann daher niedriger sein als die des zweiten Containers. Aus der Sicht der Performance, da die Aufbauzeit T(1) erheblich größer ist als die Aufbauzeit T(2), kann der Räumungsstrategiemanager 3110 bestimmen, dass es ungünstig ist, den Arbeitssatz C(1) (Bilderkennungscontainer) zu räumen, und den Arbeitssatz C(2) (Bilddrehungscontainer) räumen. Darüber hinaus kann das Aufrechterhalten des Arbeitssatzes C(1) das Startup des zweiten Containers verbessern, da Daten aus dem Arbeitssatz C(1) als sowohl dem ersten als auch dem zweiten Container gemeinsam zu sein, und während eines Aufbauens des zweiten Containers eingesetzt werden. Der Räumungsstrategiemanager 3110 kann folglich die Startup-Zeit bei Cache-Räumungsstrategien berücksichtigen.
Der Prozess 3120 kann den Arbeitssatz C(2) räumen, um einen eingehenden Arbeitssatz C(3) unterzubringen. Der Arbeitssatz C(3) kann aus Daten bestehen, um einen dritten Container aufzubauen, und kann Daten ähnlich dem, was oben unter Bezugnahme auf die Arbeitssätze C(1) und C(2) beschrieben wurde, enthalten. 31B kann eine Fortsetzung des Szenarios 3100, das von 31A veranschaulicht wird, sein. Wie in 31B veranschaulicht, werden der Datensatz C(2) und dazugehörende Daten aus dem Cacheraum 3112, der Tabelle 3114, der Tabelle 3116 und der Tabelle 3118 gelöscht. Der Cacheraum 3112, die Tabelle 3114, die Tabelle 3116 und die Tabelle 3118 speichern Daten für den dritten Container und Arbeitssatz C(3), die den entsprechenden Daten, die oben beschrieben sind, ähnlich sein können.
31C zeigt ein Verfahren 3150 verbesserter Cache-Räumung und kann in der verbesserten FaaS-Serverarchitektur der 31A und 31B und/oder einem oder mehreren Modulen als ein Satz von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Computerprogrammcode zum Ausführen von Vorgängen, die in dem Verfahren 3150 gezeigt sind, können in einer beliebigen Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie die „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Der veranschaulichte Verarbeitungsblock 3152 kann eine Startup-Zeit während der ursprünglichen Ausführung einer Funktion messen. Die ursprüngliche Ausführung kann nur das Aufbauen eines Containers zum Ausführen der Funktion beinhalten. Die Startup-Zeit kann zum Beispiel nur von einem Start des Containeraufbaus, bis der Container aufgebaut und zum Ausführen einer Funktion bereit ist, gemessen werden. Der veranschaulichte Verarbeitungsblock 3154 kann eine oder mehrere Gewichtungen basierend auf der Startup-Zeit erzeugen. Die eine oder die mehreren Gewichtungen können zu der Startup-Zeit proportional sein. Der veranschaulichte Verarbeitungsblock 3156 kann die eine oder die mehreren Gewichtungen einsetzen, um Daten zu räumen. Die eine oder die mehreren Gewichtungen können in einem gewichteten Algorithmus und/oder System zum Berechnen eines finalen Werts verwendet werden, der eine Nützlichkeit eines Arbeitssatzes des Containers in einem Cache angibt, und Daten basierend auf dem finalen Wert räumen. Falls zum Beispiel der finale Wert größer ist als ein anderer finaler Wert (der ähnlich wie hierin beschrieben berechnet wird), wird der Arbeitssatz eventuell nicht aus dem Cache geräumt, und ein unterschiedlicher Arbeitssatz, der einem anderen finalen Wert entspricht, kann geräumt werden. Das Verfahren 3150 kann daher Cache-Räumung verbessern.
31D zeigt ein Verfahren 3170 verbesserter Cache-Räumung und kann in der verbesserten FaaS-Serverarchitektur der 31A und 31B und/oder einem oder mehreren Modulen als ein Satz von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Computerprogrammcode zum Ausführen von Vorgängen, die in dem Verfahren 3170 gezeigt sind, können in einer beliebigen Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie die „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Der veranschaulichte Verarbeitungsblock 3172 kann eine erste Setup-Zeit für einen ersten Container messen. Eine erste Funktion kann in dem ersten Container ausgeführt werden, nachdem der erste Container eingerichtet (zum Beispiel aufgebaut) wurde. Die erste Setup-Zeit kann eine Zeit zum Konfigurieren eines oder mehrerer Namensräume des ersten Containers und einer oder mehrerer Steuergruppen des ersten Containers sowie das Einrichten der Ausführungsumgebung sein. Der veranschaulichte Verarbeitungsblock 3174 kann eine zweite Setup-Zeit für einen zweiten Container messen. Eine zweite Funktion kann in dem zweiten Container ausgeführt werden, nachdem der zweite Container eingerichtet (zum Beispiel aufgebaut) wurde. Die zweite Setup-Zeit kann eine Zeit zum Konfigurieren eines oder mehrerer Namensräume des zweiten Containers und einer oder mehrerer Steuergruppen des zweiten Containers sowie einer Ausführungsumgebung sein. Die zweite Funktion kann von der ersten Funktion unterschiedlich sein, und der erste und der zweite Container können voneinander unterschiedlich sein.
Der veranschaulichte Verarbeitungsblock 3176 kann eine erste Verwendungshäufigkeit (zum Beispiel Zugriffe) eines ersten Datensatzes messen. Der erste Datensatz kann aus Daten zum Aufbauen des ersten Containers bestehen. Der veranschaulichte Verarbeitungsblock 3178 kann eine zweite Verwendungshäufigkeit (zum Beispiel Zugriffe) eines zweiten Datensatzes messen. Der zweite Datensatz kann aus Daten zum Aufbauen des zweiten Containers bestehen. Ein Zugriff kann ein Lesen und/oder ein Schreiben bedeuten.
Der veranschaulichte Verarbeitungsblock 3180 kann Datenobjekte aus einem Cache basierend auf einem Vergleich der ersten Setup-Zeit mit der zweiten Setup-Zeit räumen. Außerdem kann der veranschaulichte Verarbeitungsblock 3180 die Datenobjekte aus dem Cache basierend auf einem Vergleich der ersten Verwendungshäufigkeitsmessung mit der zweiten Verwendungshäufigkeitsmessung räumen. Die Datenobjekte können mit dem ersten Container verbunden sein, wenn die zweite Setup-Zeit größer ist als die erste Setup-Zeitpunkt. Die erste Setup-Zeit kann zum Beispiel kleiner sein als die zweite Setup-Zeit, und die erste Verwendungshäufigkeit kann um eine marginale Menge größer sein als die zweite Verwendungshäufigkeit. Obwohl die erste Verwendungshäufigkeit größer ist, können die Datenobjekte (zum Beispiel der erste Datensatz) des ersten Containers geräumt werden, da die erste Setup-Zeit kleiner ist als die zweite Setup-Zeit. Die Datenobjekte können der erste Datensatz, der den ersten Container initiiert, sein oder diese beinhalten.
Bei einigen Ausführungsformen, falls die erste Verwendungshäufigkeit um ein ausreichend großes Ausmaß größer ist als die zweite Verwendungshäufigkeit, können Datenobjekte (zum Beispiel der zweite Datensatz), die mit dem zweiten Container verbunden sind, an Stelle der Datenobjekte des ersten Containers geräumt werden, obwohl die zweite Setup-Zeit größer ist als die erste Setup-Zeit. Falls die erste Verwendungshäufigkeit um eine vorbestimmte Menge größer ist als die zweite Verwendungshäufigkeit oder größer ist als ein Verhältnis, können die Datenobjekte, die mit dem zweiten Container verbunden sind, geräumt werden. Bei einigen Ausführungsformen, falls eine Verwendungshäufigkeit von Datenobjekten (zum Beispiel eines Datensatzes) unter einen bestimmten Schwellenwert fällt, können die Datenobjekte ohne Berücksichtigung von Startup-Zeiten geräumt werden. Das Verfahren 3170 kann daher Cache-Räumungen verbessern und die Latenz von Funktionsausführungen reduzieren.
31E zeigt ein Verfahren 3190 verbesserter Cache-Räumung und kann in der verbesserten FaaS-Serverarchitektur der 31A und 31B und/oder einem oder mehreren Modulen als ein Satz von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Computerprogrammcode zum Ausführen von Vorgängen, die in dem Verfahren 3190 gezeigt sind, können in einer beliebigen Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie die „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Der veranschaulichte Verarbeitungsblock 3192 kann eine erste Setup-Zeit für einen ersten Container messen. Wie besprochen, kann die erstes Setup-Zeit eine Zeit zum Aufbauen des ersten Containers sein. Der veranschaulichte Verarbeitungsblock 3194 kann eine zweite Setup-Zeit für einen zweiten Container messen. Wie besprochen, kann die zweite Setup--Zeit eine Zeit zum Aufbauen des zweiten Containers sein. Der veranschaulichte Verarbeitungsblock 3196 kann eine Time-To-Live für Datenobjekte des ersten Containers basierend auf der ersten Setup-Zeit bestimmen. Die Datenobjekte können in einem Cache gespeichert werden. Der veranschaulichte Verarbeitungsblock 3196 kann ferner eine Time-To-Live für Datenobjekte des zweiten Containers basierend auf der zweiten Setup-Zeit bestimmen. Die Datenobjekte des zweiten Containers können in einem Cache gespeichert werden. Obwohl dies nicht veranschaulicht ist, können die ersten und die zweiten Objekte geräumt werden, falls die Time-To-Live abläuft.
Zusätzliche Anmerkungen und Beispiele
Beispiel 3100 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine erste Setup-Zeit für einen ersten Container zu messen, wobei eine erste Funktion in dem ersten Container ausgeführt werden soll, wobei die erste Setup-Zeit eine Zeit zum Konfigurieren eines oder mehrerer Namensräume des ersten Containers und einer oder mehrerer Steuergruppen des ersten Containers ausführen soll, eine zweite Setup-Zeit für einen zweiten Container zu messen, wobei eine zweite Funktion in dem zweiten Container ausgeführt werden soll und die zweite Funktion von der ersten Funktion unterschiedlich ist, wobei die zweite Setup-Zeit eine Zeit zum Konfigurieren eines oder mehrerer Namensräume des zweiten Containers und einer oder mehrerer Steuergruppen des zweiten Containers ist, und Datenobjekte aus einem Cache basierend auf einem Vergleich der ersten Setup-Zeit mit der zweiten Setup-Zeit und einer Verwendungshäufigkeit eines ersten Datensatzes verglichen mit einer Verwendungshäufigkeit des zweiten Datensatzes zu räumen, wobei der erste Datensatz eingesetzt wird, um den ersten Container aufzubauen, wobei der zweite Datensatz ferner verwendet wird, um den zweiten Container aufzubauen und wobei die Datenobjekte ferner den ersten Datensatz beinhalten.
Beispiel 3101 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine erste Setup-Zeit für einen ersten Container zu messen, wobei eine erste Funktion in dem ersten Container ausgeführt werden soll, eine zweite Setup-Zeit für einen zweiten Container zu messen, wobei eine zweite Funktion in dem zweiten Container ausgeführt werden soll und die zweite Funktion von der ersten Funktion unterschiedlich ist, und Datenobjekte aus einem Cache basierend auf einem Vergleich der ersten Setup-Zeit mit der zweiten Setup-Zeit zu räumen, wobei die Datenobjekte mit dem ersten Container verbunden sind.
Beispiel 3102 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 3101, wobei die erste Setup-Zeit größer ist als die zweite Setup-Zeitpunkt
Beispiel 3103 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 3102, wobei die erste Setup-Zeit eine Zeit zum Konfigurieren eines oder mehrerer Namensräume des ersten Containers und einer oder mehrerer Steuergruppen des ersten Containers ist, und die zweite Setup-Zeit eine Zeit zum Konfigurieren eines oder mehrerer Namensräume des zweiten Containers und einer oder mehrerer Steuergruppen des zweiten Containers ist.
Beispiel 3104 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 3102, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Datenobjekte aus dem Cache basierend auf einer Verwendungshäufigkeit des ersten Containers zu räumen.
Beispiel 3105 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 3102, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, die Datenobjekte aus dem Cache basierend auf einer Verwendungshäufigkeit eines ersten Datensatzes im Vergleich zu einer Verwendungshäufigkeit eines zweiten Datensatzes zu räumen, wobei der erste Datensatz eingesetzt wird, um den ersten Container aufzubauen, wobei der zweite Datensatz verwendet wird, um zweiten Container aufzubauen, wobei die Datenobjekte den ersten Datensatz beinhalten.
Beispiel 3106 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 3102, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Time-To-Live für die Datenobjekte des ersten Containers basierend auf der ersten Setup-Zeit zu bestimmen, und eine Time-To-Live für Datenobjekte des zweiten Containers basierend auf der zweiten Setup-Zeit zu bestimmen.
Beispiel 3106 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 3100, wobei die Datenobjekte Daten zum Initiieren des ersten Containers beinhalten.
Beispiele für verbesserte FaaS-Funktionsverteilung
Wie bereits beschrieben, können einige Funktionen Datensätze während der Ausführung heranziehen. Die Datensätze können in Containern enthalten sein, und die Funktionen können somit zu einem zweckdienlichen Container bereitgestellt werden, um auf einen zweckdienlichen Datensatz zuzugreifen. Einige Daten können größer und/oder verteilt sein, wie in Hadoop-Umgebungen. Das Bewegen des Datensatzes zu der Funktion kann daher ineffizient sein und/oder die Gesamtkosten der Umgebung (Total Cost of Environment - TCE) erhöhen. Die Daten, die Funktionen berühren oder ändern können (zum Beispiel ihren Speicher oder ihre Speicherung oder Netzwerkfußabdrücke) können sich erheblich auf die Latenz, innerhalb der die Aktionen abgeschlossen werden, und auf die effiziente Verwendung von Rechenressourcen, die von dem Service-Anbieter beigestellt werden, auswirken. Einige Funktionen und Datensätze können gesteigerte TCE auch ohne spezialisiertes Rechnen (zum Beispiel Hardware-Beschleuniger) aufweisen.
Bei Beispiel 3200 der 32A kann daher ein Orchestrator 3202 eine FaaS-Infrastruktur analysieren, um einen Knoten aus dem ersten Knoten 3208 und dem zweiten Knoten 3216 mit einem niedrigsten Latenztransfer für einen Datensatz für eine F₁-Funktion zu identifizieren. Der Orchestrator 3202 kann die Funktion F₁ basierend auf Datenbewegung und Datenbewegungskosten planen. Ein Kostenanalysator 3204 kann zum Beispiel die Gesamtausführungskosten der Funktion F₁ an jedem des ersten und des zweiten Knotens 3208, 3216 bestimmen. Die Gesamtkosten können eine Summierung von Datenbewegungskosten und Ausführungskosten sein. Die Gesamtkosten können ferner Latenzmessungen, Ausführungszeitmessungen, Ressourcenmessungen, die Einrichtung sicherer Kanäle, Verschlüsselungs-/Entschlüsselungs- oder Kompressions-/Dekompressionslatenzmessungen, Netzwerk-Hop, Bandbreiten- und Pufferspeicherungsschätzungen und so fort beinhalten. Der Orchestrator 3202 kann zum Beispiel ein Datenobjekt (mehrere Datenobjekte), die mit der Ausführung der Funktion F₁ assoziiert sind und die Lokalität der Datenobjekte bestimmen. Der Orchestrator 3202 kann die Verteilung der Funktion F₁ und der Datenobjekte basierend auf bevorzugten Ressourceneinsätzen orchestrieren. Der Orchestrator 3202 kann daher Ressourcen freigegeben, Gesamtausführungskosten reduzieren, niedrigere EA-Bandbreite und Funktionsausführungen mit niedrigerer Latenz aufweisen.
Ähnlich wie bei den Ausführungsformen der 31A und 31B, beinhaltet der erste Knoten 3208 einen Cache 3212, der Datenobjekte in einem Arbeitssatz C(1) speichert. Der Kürze halber wird eine ähnliche Beschreibungen ähnlicher Bauelemente weggelassen. Der Cache-Controller 3210, der Cache 3212 und der Startup-Timer 3214 der 32A können ähnlich arbeiten wie der Cache-Controller 3104, der Cache 3102 und ein Startup-Timer 3108 der 31A. Auf ähnliche Weise kann der zweite Knoten 3216 ähnlich arbeiten wie die Ausführungsformen der 31A-31B.
Wie man versteht, ist C(1) eine Abkürzung für einen ersten Container. Der Arbeitssatz C(1) ist der Arbeitssatz für den ersten Container. Bei einem Beispiel wurde der erste Container abgebaut und ist inaktiv (nicht aufgebaut). Wenn der erste Container abgebaut wird, wird der Arbeitssatz C(1) in dem Cache 3212 aufrechterhalten, um den ersten Container rasch aufzubauen. Der Arbeitssatz C(1) kann nämlich verwendet werden, um den ersten Container aufzubauen.
Der Orchestrator 3202 kann bestimmen, ob eine Funktion F₁ in einem besonderen Container ausgeführt werden kann. Der Funktionsanalysator 3206 kann zum Beispiel Merkmale optionaler Felder (zum Beispiel Metadaten) aus einem Funktionskonstrukt der Funktion F₁ bestimmen. Die 33A und 33B und die dazu gehörende Beschreibung besprechen das Funktionskonstrukt ausführlicher. Die Metadaten beschreiben die Assoziation der Funktion F₁ mit Datenmonikern. Ein Datenmoniker kann eine ungefähre Darstellung der Identitäten eines Datensatzkonstrukts sein. Ein Moniker kann von einer Set-Funktion (zum Beispiel einem Bloom-Filter) und/oder einer Moniker-Konstruktions-API über diverse universell eindeutige Identifikatoren der Funktionen, dem Aufruf einer Funktion, spezifischen Parametern einer Funktion, Dateisystem-Pfadnamen, die mit einer Funktion assoziiert sind, Resilient-Distributed-Dataset-Lineages zum Beispiel in Spark, Tablespace-Bereiche in relationalen Datenbanken, auf die die Funktion zugreift und so fort, konstruiert werden. Der Funktionsanalysator 3206 kann daher mit einer Moniker-Konstrukt-API interagieren, um Moniker abzuleiten und/oder eine Set-Funktion zu beinhalten. Bei einigen Ausführungsformen kann der Funktionsanalysator 3206 die Moniker-Konstruktions-API beinhalten. Weitere Einzelheiten sind unten unter Bezugnahme auf die 33A und 33B beschrieben.
Die Moniker können eine kompakte Darstellung oder Beschreibung von Ressourcennamen (zum Beispiel Beschleuniger, Daten, gewichtete Formeln, Hardwareanforderungen usw.), die die Funktion F₁ während der Ausführung benötigen kann, sein. Die Moniker können angeben, dass ein besonderer Datensatz von der Funktion F₁ während der Ausführung eingesetzt werden kann. Ein solcher besonderer Datensatz kann als ein F₁-Datensatz bezeichnet werden.
Der Funktionsanalysator 3206 kann die Moniker basierend auf den Metadaten bestimmen, und die Funktion F₁ kann einen Containertyp bestimmen, der eine Soft-Affinität mit den Monikern aufweisen kann, um zu bestimmen, ob der Container mindestens einen Teil des F₁-Datensatzes sowie andere Ressourcen, die während der Ausführung benötigt werden können, beinhalten kann. Der erste und der zweite Knoten 3208, 3216 können den Orchestrator 3202 beliebige gespeicherte Arbeitssätze (zum Beispiel den Arbeitssatz C(1)) informieren. Der Orchestrator 3202 kann bestimmen, ob der Arbeitssatz C(1) einen Container, der eine Soft-Affinität mit den Monikern aufweist, aufbauen kann. Bei einigen Ausführungsformen kann der Orchestrator 3202 bestimmen, ob der Arbeitssatz C(1) mindestens einen Teil des F₁-Datensatzes beinhaltet.
Der Orchestrator 3202 definiert daher eine Assoziation zwischen der Funktion F₁ und dem Datensatz, die als ein latenter Zustand zum Führen von Speicherung, Cache und kommunikationseffizienter Planung durch Anziehen der Funktion F₁ zu einem Container (zum Beispiel der erste Container, wie unten beschrieben), der eine höchste Wahrscheinlichkeit aufweist, dass er lokale, warme Kopien der Daten die die Funktion F₁ am wahrscheinlichsten während der Ausführung benötigen wird, führen. Darüber hinaus kann die obige Verbesserung erzielt werden, ohne eine serverlose Abstraktion zu verletzen.
In mehr Einzelheiten kann bei dem vorliegenden Beispiel der Funktionsanalysator 3206 bestimmen, dass der erste Container mindestens einen Teil des F₁-Datensatzes, den die Funktion F₁ während der Ausführung einsetzen wird, beinhaltet. Der Orchestrator 3202 kann bestimmen, dass der erste Knoten 3208 den Arbeitssatz C(1), der wie oben beschrieben zum Aufbauen des ersten Containers verwendet werden kann, beinhaltet. Der Orchestrator 3202 kann daher identifizieren, dass der erste Knoten 3208 mindestens einen Teil des F₁-Datensatzes beinhalten kann und die Funktion zu dem ersten Knoten 3208 lenken. Zum Beispiel und vor dem Aufbauen kann der Orchestrator 3202 den Arbeitssatz C(1), wie er in dem Cache 3212 gespeichert ist, mit dem F₁-Datensatz vergleichen, um zu bestimmen, dass der gespeicherte Arbeitssatz C(1) mindestens einen Teil des F₁-Datensatzes beinhaltet.
Im Gegensatz beinhaltet der zweite Knoten 3216 eventuell keine relevanten Datenobjekte. Während der zweite Knoten 3216 einige Arbeitssätze (nicht veranschaulicht) beinhalten kann, werden diese Arbeitssätze weggelassen, da sie keine Daten in Zusammenhang mit der Ausführung des F₁-Datensatzes beinhalten.
Der Kostenanalysator 3204 kann die Gesamtkosten des ersten Knotens 3208 und des zweiten Knotens 3216 zum Ausführen der Funktion F₁ bestimmen. Die Gesamtkosten können projizierte Kosten, vorhergesagte Schätzungen, vorhergesagte Latenzen und/oder geschätzte Latenzen sein, wobei die projizierten oder geschätzten Kosten und Latenzen Kosten und Latenzen des Datentransports zwischen dem ersten und dem zweiten Knoten beinhalten sollen. Die Summe kann ferner Latenzmessungen, Ausführungszeitmessungen, Ressourcenmessungen, die Einrichtung sicherer Kanäle, Verschlüsselungs-/Entschlüsselungs- oder Kompressions-/Dekompressionslatenzmessungen, Netzwerk-Hop, Bandbreiten- und Pufferspeicherungsschätzungen und so fort beinhalten. Die Gesamtkosten des ersten Knotens 3248 können die Kosten zum Aufbauen eines Containers (zum Beispiel des ersten Containers oder einer modifizierten Version des ersten Containers mit hinzugefügten Daten) an dem ersten Knoten 3208 darstellen und die Funktion F₁ an dem ersten Knoten 3208 ausführen. Die Gesamtkosten des zweiten Knotens 3216 können die Kosten zum Aufbauen eines Containers zum Ausführen der Funktion F₁ an dem zweiten Knoten 3216 und das Ausführen der Funktion F₁ an dem zweiten Knoten 3216 darstellen. Die Gesamtkosten können verglichen werden, um zu bestimmen, ob die Funktion F₁ zu dem ersten Knoten 3208 oder dem zweiten Knoten 3216 gesendet werden soll.
In mehr Einzelheiten kann der Kostenanalysator 3204 die Gesamtkosten jedes des ersten Knotens 3208 und des zweiten Knotens 3216 zum Ausführen der Funktion F₁ bestimmen. Die Gesamtkosten können für jeden des ersten und des zweiten Knotens 3208, 3218 bestimmt werden und können auf Kommunikationskosten (zum Beispiel Datenvolumen, das zum Aufbauen eines Containers transferiert werden muss, Nähe zu den Daten usw.), den Aufbaukosten eines Containers, den Ausführungslatenzkosten (zum Beispiel, ob ein Beschleuniger erforderlich ist) und so fort bestimmt werden.
Ausführungslatenzkosten können zum Beispiel reduziert werden, falls ein Knoten von dem ersten und dem zweiten Knoten 3208, 3216 einen Beschleuniger beinhaltet, um die Ausführung der Funktion F₁ zu erleichtern und/oder ausreichend Ressourcen zum Unterstützen der Funktion F₁ beinhaltet. Die Ausführungskosten können erhöht werden, falls ein Mangel an Ressourcen zum Unterstützen der Funktion F₁ besteht, oder ein Beschleuniger von dem Knoten nicht unterstützt wird. Der Orchestrator 3202 kann die Funktion F₁ einem Knoten des ersten und des zweiten Knotens 3208, 3216 basierend auf einem Vergleich der Gesamtkosten oder einem des ersten und des zweiten Knotens 3208, 3216, der die niedrigsten Gesamtkosten aufweist, zuweisen.
Der zweite Knoten 3216 kann zum Beispiel eine höhere Latenz (zum Beispiel höhere Latenzkosten) zum Ausführen der Funktion F₁ im Vergleich zu dem ersten Knoten 3208 aufweisen. Im Einzelnen kann der zweite Knoten 3216 das Empfangen aller Daten benötigen, um einen Container für die Funktion F₁ aufzubauen und dann den Container aufbauen. Im Gegensatz kann der erste Knoten 3208 den ersten Container aus dem Arbeitssatz C(1), der lokal in dem Cache 3212 gespeichert ist, aufbauen und den ersten Container bei Bedarf mit weiteren Daten ändern, um dadurch mindestens einige der Kommunikationslatenzkosten, die der zweite Knoten 3216 aufweist, zu verhindern. Aufgrund des Überlappens zwischen dem F₁-Datensatz und dem Arbeitssatz C(1), kann die Kommunikationslatenz des ersten Knotens 3208 im Vergleich zu dem zweiten Knoten 3216 reduziert werden, wodurch die Gesamtkosten für den ersten Knoten 3208 reduziert werden. Als ein Resultat können die Gesamtkosten zum Ausführen der Funktion F₁ an dem ersten Knoten 3208 niedriger sein als die Gesamtkosten zum Ausführen der Funktion F₁ an dem zweiten Knoten 3216.
Bei einigen Ausführungsformen kann der Arbeitssatz C(1) nur einen Abschnitt des F₁-Datensatzes beinhalten, wobei der Rest der Daten an dem ersten Knoten 3208 vor der Konstruktion oder während der Konstruktion des ersten Containers eintrifft. Bei einer solchen Ausführungsform kann der Kostenanalysator 3204 die Kosten zum Transferieren des Rests der Daten als Teil der Gesamtkosten zum Ausführen der Funktion F₁ an dem ersten Knoten 3208 beinhalten. Nachdem der erste Knoten 3208 den Rest der Daten empfangen hat, kann der erste Container mit dem Rest der Daten zum Ausführen der Funktion F₁ erweitert werden.
Bei dem vorliegenden Beispiel kann der Orchestrator 3202 bestimmen, dass die Gesamtkosten für die Funktion F₁ zum Ausführen an dem ersten Knoten 3208 niedriger sind als die Gesamtkosten zum Ausführen der Funktion F₁ an dem zweiten Knoten 3216. Der Prozess 3224 kann die Funktion F₁ verteilen. Im Einzelnen kann der Orchestrator die Funktion F₁ zu dem ersten Knoten 3208 bereitstellen. Wie in 32B veranschaulicht, baut der erste Knoten 3208 Container C(1) 3226 (zum Beispiel den ersten Container) in dem ersten Knoten 3208 basierend auf dem Arbeitssatz C(1), der in dem Cache 3212 gespeichert ist, auf.
Bei einigen Ausführungsformen kann der Container C(1) mit weiteren Daten, die in dem Arbeitssatz C(1) nicht enthalten sind, erweitert werden, um die Ausführung der Funktion F₁ zu erleichtern. Die Funktion F₁ kann dann die Ausführung beginnen. Der erste Knoten 3208 kann zum Beispiel einige Daten empfangen, die die Funktion F₁ während der Ausführung einsetzt, und kann diese Daten zu dem Container C(1) während des Aufbauens des Containers C(1) hinzufügen.
Unter Bezugnahme auf 32C ist ein Beispiel 3240 veranschaulicht. Der Kürze halber ähnliche Bauelemente wie die in den 32A, 32B veranschaulichten hier nicht wiederholt. Es versteht sich, dass die entsprechenden Bauelemente jedoch ähnlich miteinander arbeiten können.
Bei dem Beispiel 3240 soll eine Funktion F₂ von dem Orchestrator 3242 zugewiesen werden. Ähnlich wie bei den obigen Ausführungsformen beinhaltet der Knoten 3248 einen Arbeitssatz C(1) zum Aufbauen eines ersten Containers zum Ausführen der Funktion F₂, während der zweite Knoten 3258 keinen solchen Arbeitssatz enthält.
Der Funktionsanalysator 3246 kann die Funktion F₂ analysieren, um einen F₂-Datensatz zu bestimmen. Der Orchestrator 3242 kann bestimmen, dass der Arbeitssatz C(1) nur einen ersten Teil des F₂-Datensatzes beinhaltet. Ein zweiter Teil des F₂-Datensatzes muss daher zu dem ersten Knoten 3248 übertragen werden, um die Funktion F₂ an dem ersten Knoten 3248 auszuführen. Der zweite Knoten 3258 beinhaltet eventuell keine relevanten Datensätze, und daher muss ein neuer Container an dem zweiten Knoten 3258 zum Ausführen der Funktion F₂ aufgebaut werden.
Der Kostenanalysator 3244 kann die Gesamtkosten des ersten Knotens 3248 und des zweiten Knotens 3258 bestimmen. Die Gesamtkosten für den ersten Knoten 3248 können die Kosten zum Übertragen des zweiten Teils des F₂-Datensatzes zu dem ersten Knoten 3248 beinhalten. Der erste Knoten 3248 kann zu einer Datenquelle, die den zweiten Teil des F₂-Datensatzes zu dem ersten Knoten 3248 übertragen soll, distal sein. Die Datenquelle kann ein anderer Knoten sein und kann der dem ersten Knoten 3248 nächste Knoten sein, der den zweiten Teil des F₂-Datensatzes aufweist. Der Kostenanalysator 3244 kann folglich bestimmen, dass die Kommunikationskosten zum Übertragen des zweiten Teils des F₂-Datensatzes hoch sind, und dass die Gesamtkosten für den ersten Knoten 3248 entsprechend hoch sind.
Die Gesamtkosten für den zweiten Knoten 3258 können die Kosten zum Empfangen aller Aufbaudaten zum Aufbauen des ersten Containers sein. Bei diesem vorliegenden Beispiel kann der zweite Knoten 3258 jedoch nahe der Datenquelle positioniert sein. Die Datenquelle kann alle Aufbaudaten beinhalten und kann fähig sein, die Aufbaudaten zu dem zweiten Knoten 3258 zu übertragen. Die Kommunikationskosten des zweiten Knotens 3258 können daher erheblich niedriger sein als die Kommunikationskosten des ersten Knotens 3248. Aufgrund des erheblichen Unterschieds zwischen den Kommunikationskosten, kann der zweite Knoten 3258 niedrigere Gesamtkosten aufweisen, obwohl kein Arbeitssatz vorhanden ist. Der Orchestrator 3242 kann bestimmen, dass es effizienter (niedrigere Latenz) ist, die Funktion F₂ an dem zweiten Knoten 3258 aufgrund der verringerten Datentransferkosten des zweiten Knotens 3258 auszuführen, obwohl der zweite Knoten 3258 keinen Arbeitssatz aufweist. Der Orchestrator 3242 kann daher Container an Knoten, die näher an Datenquellen liegen, aufbauen, um Latenzkosten zu reduzieren, statt Container an Knoten (sogar mit relevanten Arbeitssätzen), die weiter von den Datenquellen entfernt sind, aufzubauen.
Bei dem Prozess 3266 kann der Orchestrator 3242 die Funktion F₂ verteilen. Wie in 32D, die die Fortsetzung des Beispiels 3240 der 32C ist, veranschaulicht, wird die Funktion F₂ zu dem zweiten Knoten 3258 bereitgestellt. Ein Container 3268 kann aufgebaut werden, um die Funktion F₂ und basierend auf Daten, die von der Datenquelle empfangen werden, auszuführen.
Die obigen Ausführungsformen der 32A bis 32D können die Berechnung zu Daten pushen, aber auf eine verbesserte Art, um Aktionen, die ansonsten die Hardware, auf der sie laufen oder die physischen Orte der Daten, auf die sie während ihrer Ausführung verweisen, nicht kennen, auszuführen. Die Ausführungsformen können Latenzen zum Ausführen von Funktionen reduzieren und darüber hinaus den Ressourceneinsatz reduzieren.
32E zeigt ein Verfahren 3280 verbesserter Funktionsverteilung und kann in der verbesserten FaaS-Serverarchitektur der 32A bis 32D und/oder einem oder mehreren Modulen als ein Satz von Logikanweisungen, der in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flashspeicher usw., gespeichert ist, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Computerprogrammcode zum Ausführen von Vorgängen, die in dem Verfahren 3280 gezeigt sind, können in einer beliebigen Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie die „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Der veranschaulichte Verarbeitungsblock 3282 kann eine Funktion identifizieren, die ausgeführt werden soll. Der veranschaulichte Verarbeitungsblock 3284 kann einen Datensatz bestimmen, den diese Funktion während der Ausführung einsetzen wird. Der veranschaulichte Verarbeitungsblock 3286 kann bestimmen, ob ein erster Arbeitssatz mindestens einen Teil des Datensatzes beinhaltet. Der erste Arbeitssatz kann Ressourcen für das Startup eines ersten Containers beinhalten. Außerdem kann der erste Arbeitssatz an einem ersten Knoten gespeichert sein. Der erste Arbeitssatz kann in einem Hardware- und/oder Software-Cache des ersten Knotens gespeichert sein.
Der veranschaulichte Verarbeitungsblock 3288 kann erste Gesamtkosten zum Ausführen der ersten Funktion an dem ersten Knoten berechnen. Die erste Gesamtkostenberechnung kann darauf basieren, ob der erste Arbeitssatz einen Teil des Datensatzes beinhaltet. Als ein Beispiel kann der veranschaulichte Verarbeitungsblock 3286 bestimmen, dass der erste Arbeitssatz nur einen ersten Teil des Datensatzes beinhaltet. Bei einer solchen Ausführungsform kann der veranschaulichte Verarbeitungsblock 3288 Transferkosten (die erste Gesamttransferkosten genannt werden können) zum Transferieren eines zweiten Teils des Datensatzes zu dem ersten Knoten bestimmen und die Transferkosten in den ersten Gesamtkosten beinhalten. Der veranschaulichte Verarbeitungsblock 3288 kann zum Beispiel bestimmen, dass die ersten Gesamtkosten Kosten zum Aufbauen des ersten Containers und die Transferkosten beinhalten.
Der veranschaulichte Verarbeitungsblock 3290 kann zweite Gesamtkosten zum Ausführen der ersten Funktion an einem zweiten Knoten berechnen. Die zweiten Gesamtkosten können Datentransferkosten zum Transferieren von Daten zum Aufbauen des zweiten Containers an dem zweiten Knoten und Kosten zum Aufbauen des zweiten Containers beinhalten. Der zweite Container kann ein kalter Container sein.
Der veranschaulichte Verarbeitungsblock 3292 kann bestimmen, ob die Funktion an dem ersten Knoten oder dem zweiten Knoten basierend auf den Berechnungen der ersten und zweiten Gesamtkosten ausgeführt werden soll. Als ein Beispiel kann der veranschaulichte Verarbeitungsblock 3292 bestimmen, ob der erste Container an dem ersten Knoten gestartet werden soll, und die Funktion in dem ersten Container an dem ersten Knoten basierend darauf ausführen, ob der erste Arbeitssatz mindestens einen Teil des Datensatzes beinhaltet.
Der veranschaulichte Verarbeitungsblock 3292 kann einen ersten Container an dem ersten Knoten aufbauen und die Funktion in dem ersten Container an dem ersten Knoten ausführen, wenn die ersten Gesamtkosten niedriger sind als die zweiten Gesamtkosten. Im Gegensatz kann der zweite Container an dem zweiten Knoten aufgebaut werden, und die Funktion kann in dem zweiten Container an dem zweiten Knoten ausgeführt werden, wenn die zweiten Gesamtkosten niedriger sind als die ersten Gesamtkosten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 3200 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen beinhaltet, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Funktion zu identifizieren, die ausgeführt werden soll, einen Datensatz zu bestimmen, den die Funktion während der Ausführung einsetzen wird, zu bestimmen, dass ein erster Arbeitssatz nur mindestens einen ersten Teil des Datensatzes beinhaltet, wobei der erste Arbeitssatz Ressourcen zum Startup eines ersten Containers beinhaltet, wobei der erste Arbeitssatz an dem ersten Knoten gespeichert ist, wobei der erste Arbeitssatz in einem Cache des ersten Knoten gespeichert ist, Transferkosten zum Transferieren eines zweiten Teils des Datensatzes zu dem ersten Knoten zu bestimmen, erste Gesamtkosten zum Transferieren eines zweiten Teils des Datensatzes zu dem ersten Knoten zu bestimmen, Transferkosten zum Transferieren eines zweiten Teils des Datensatzes zu dem ersten Knoten zu bestimmen, erste Gesamtkosten zum Ausführen der Funktion an dem ersten Knoten zu bestimmen, wobei die ersten Gesamtkostenkosten zum Aufbauen des ersten Containers und die Transferkosten beinhalten, zweite Gesamtkosten zum Ausführen der Funktion in einem zweiten Container an einem zweiten Knoten zu bestimmen, wobei die zweiten Gesamtkosten Datentransferkosten zum Aufbauen des zweiten Containers an dem zweiten Knoten und Kosten zum Aufbauen des zweiten Containers beinhalten, den zweiten Container an dem zweiten Knoten aufzubauen und die Funktion in dem zweiten Container an der dem zweiten Knoten auszuführen, wenn die zweiten Gesamtkosten niedriger sind als die ersten Gesamtkosten, und den ersten Container an dem ersten Knoten aufzubauen und die Funktion in dem ersten Container an dem ersten Knoten auszuführen, wenn die ersten Gesamtkosten geringer sind als die zweiten Gesamtkosten.
Beispiel 3201 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Funktion zu identifizieren, die ausgeführt werden soll, einen Datensatz, den die Funktion während der Ausführung einsetzen wird zu bestimmen, zu bestimmen ob ein erster Arbeitssatz mindestens einen Teil des Datensatzes beinhaltet, wobei der erste Arbeitssatz Ressourcen zum Startup eines ersten Containers beinhaltet, wobei der erste Arbeitssatz an einem ersten Knoten gespeichert ist, und zu bestimmen ob der erste Container an dem ersten Knoten gestartet werden soll, um die Funktion in dem ersten Container an dem ersten Knoten basierend darauf, ob der erste Arbeitssatz mindestens den Teil des Datensatzes beinhaltet, auszuführen.
Beispiel 3202 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 3201, wobei der erste Arbeitssatz in einem Cache des ersten Knotens gespeichert ist.
Beispiel 3203 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 3201, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, zu bestimmen, dass der erste Arbeitssatz nur einen ersten Teil des Datensatzes beinhaltet, und Transferkosten zum Transferieren eines zweiten Teils des Datensatzes zu dem ersten Knoten zu bestimmen.
Beispiel 3204 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 3203, das einen weiteren Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, erste Gesamtkosten zum Ausführen der Funktion an dem ersten Knoten zu bestimmen, wobei die ersten Gesamtkosten Kosten zum Aufbauen des ersten Containers und die Transferkosten beinhalten, zweite Gesamtkosten zum Ausführen der Funktion in einem zweiten Container an dem zweiten Knoten zu bestimmen, wobei die zweiten Gesamtkosten Datentransferkosten zum Transferieren von Daten zum Aufbauen des zweiten Containers an dem zweiten Knoten und Kosten zum Aufbauen des zweiten Containers beinhalten.
Beispiel 3205 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 3204, wobei der zweite Container ein kalter Container ist.
Beispiel 3206 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 3204, das einen weiteren Satz von Anweisungen umfasst die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, den zweiten Container an dem zweiten Knoten aufzubauen und die Funktion in dem zweiten Container an dem zweiten Knoten auszuführen, wenn die zweiten Gesamtkosten niedriger sind als die ersten Gesamtkosten, und den ersten Container an dem ersten Knoten aufzubauen und die Funktion in dem ersten Container an dem ersten Knoten auszuführen, wenn die ersten Gesamtkosten niedriger sind als die zweiten Gesamtkosten.
Beispiele für verbessertes FaaS-Funktionskonstrukt
33A veranschaulicht ein Funktionskonstrukt 3300 einer Funktion. Wie unter Bezugnahme auf die Ausführungsformen der 32A bis 32D besprochen, kann das Funktionskonstrukt 3300 eingesetzt werden, um einen geeigneten Modus zum Ausführen der Funktion zu bestimmen. In 33A beinhaltet das Funktionskonstrukt 3300 optionale Felder, die Assoziationen mit Daten-Monikern beschreiben. Die Felder des Funktionskonstrukts können gelesen werden, um die Metadaten, die darin enthalten sind, zu identifizieren und Assoziationen zu Monikern basierend auf den Metadaten zu machen. Ein Datenmoniker kann eine ungefähre Darstellung der Identitäten eines Funktionskonstrukt 3300 sein. Ein Moniker kann aus dem Funktionskonstrukt 3330 durch eine Set-Funktion (zum Beispiel ein Bloom-Filter) und/oder eine Moniker-Konstruktions-API über diverse universell eindeutige Identifikatoren der Funktionen, dem Aufruf einer Funktion, spezifischen Parametern einer Funktion, Dateisystem-Pfadnamen, die mit einer Funktion assoziiert sind, Resilient-Distributed-Dataset-Lineages zum Beispiel in Spark, Tablespace-Bereiche in relationalen Datenbanken, auf die die Funktion zugreift und so fort, konstruiert werden. Eine Funktion, die durch das Funktionskonstrukt 3300 zugewiesen wird, kann zur Ausführung an Containern, die in Soft-Affinität mit diesen Monikern, die aus dem Funktionskonstrukt abgeleitet sind, bereitgestellt werden. Die Moniker können daher verwendet werden, um die Funktion effektiv zuzuweisen, um Ressourcen und Latenz zu verringern.
Das Datensatzkonstrukt beinhaltet mehrere Felder. Die Attribute der Felder können bei Funktionsanlegung erzeugt sowie dynamisch basierend auf der Funktionsausführung und einer Ebene von Cache-/Speicher-Thrashing aktualisiert werden. Basierend auf den Daten, die während der Funktionsausführung berührt werden, die aus dem Funktionskonstrukt 3300 gesammelt werden, kann eine Funktion, die mit dem Funktionskonstrukt 3300 assoziiert ist, einem Container zugewiesen werden, der wahrscheinlich eine warme Kopie der Daten besitzt, wodurch Datenbewegung reduziert wird und die Möglichkeit von Thrashing reduziert wird.
Ein Aufruferfeld 3302 kann verwendet werden, um die Quelle des Funktionsaufrufs zu identifizieren (zum Beispiel ein Client, ein Rechengerät, ein geographischer Bereich usw.). Ein Aufrufer-Moniker kann aus dem Aufruferfeld 3302 bestimmt werden, um eine Identität, einen Ort und/oder ein Gerät der Quelle zu beschreiben.
Ein Argumentefeld 3304 kann verwendet werden, um die Argumente der Funktion zu identifizieren. Die Argumente können verwendet werden, um den Funktionstyp, darunterliegende Datenanforderungen und so fort zu bestimmen. Eingangsdaten in die Argumente können zum Beispiel identifiziert werden, Zugriff auf spezifische Sprachenbibliotheken und/oder Datenanforderungen können identifiziert werden. Darüber hinaus können bestimmte Argumentetypen durch spezifischen Hardwareeinsatz verbessert werden. Ein Typ-Moniker kann daher aus dem Argumentefeld 3304 bestimmt werden, um eine Computersprache, Datenanforderungen, Hardwareanforderungen (zum Beispiel Beschleuniger, Speicherung, Prozessorgeschwindigkeit) und so fort der Funktion zu beschreiben.
Andere Felder 3306 können verwendet werden, um die anderen Attribute der Funktion zu identifizieren. Die anderen Felder 3306 können zum Beispiel verwendet werden, um eine geographische Lage für Ausführung, einen Ort eines Client und so fort zu identifizieren. Ein anderer Moniker kann aus den anderen Feldern 3306 bestimmt werden, um geographische Lage und Lage von Clients zu beschreiben usw. Der andere Moniker kann zum Lenken der Funktion zu einem Knoten nahe der geographischen Lage des Client oder wohin die Daten schlussendlich übertragen werden, zu lenken.
Der Dateisystempfad 3308 kann verwendet werden, um einen Pfad der Funktion zu bestimmen. Der Dateisystempfad 3308 kann zum Beispiel verwendet werden, um einen Ort zu identifizieren, um den Ausgang der Funktion zu speichern. Ein Pfadmoniker kann aus dem Dateisystempfad 3308 bestimmt werden, um den Ort zum Speichern des Ausgangs zu beschreiben. Der Pfadmoniker kann verwendet werden, um die Funktion zu einem Knoten nahe dem Ort zum Speichern des Ausgangs zu lenken.
Der Datenbank-Tablespace-Bereich 3310 kann verwendet werden, um die logische Identität des Satzes von „Tupeln“ in einer Datenbank zum Zwecke einer kompakten Identifikation und darauffolgender Verwendung verbunden mit dem Datensatz einer Funktion zu beschreiben. Ein Bereichsmoniker kann aus dem Datenbank-Tablespace-Bereich 3310 bestimmt werden, um die logische Spanne von Daten zu beschreiben, deren Werte in diversen Feldern oder Attribute in einen Bereichsmindest- und Bereichshöchstwert fallen. Er kann verwendet werden, um einen Datenbereich, der in einer Funktion verwendet wird, basierend auf diversen Einschränkungen, die von Feldern innerhalb der Daten erfüllt werden, kompakt zu beschreiben.
33B zeigt ein Verfahren 3350 von Monikeridentifikation aus einem verbesserten Funktionskonstrukt, wie in 33B gezeigt, und kann in den verbesserten Orchestratoren 3202, 3242 der 32A bis 32D und/oder in mehreren Modulen als ein Satz logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flashspeicher usw., gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Computerprogrammcode zum Ausführen von Vorgängen, die in dem Verfahren 3350 gezeigt sind, können in einer beliebigen Kombination einer oder mehrerer Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie JAVA, SMALLTALK, C++ oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie die „C“-Programmiersprache oder ähnlichen Programmiersprachen, geschrieben werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Der veranschaulichte Verarbeitungsblock 3352 kann Felder eines Funktionskonstrukts, die mit einer Funktion zusammenhängen, identifizieren. Der veranschaulichte Verarbeitungsblock 3354 kann Metadaten aus den Feldern bestimmen.
Der veranschaulichte Verarbeitungsblock 3356 kann einen oder mehrere Moniker aus den Feldern bestimmen, wobei die Moniker eine oder mehrere Ressourcen, die die Funktion während der Ausführung verwenden soll, angeben. Die eine oder die mehreren Ressourcen können zum Beispiel Daten beinhalten, die die Funktion während der Ausführung einsetzen soll. Die eine oder die mehreren Ressourcen können ferner eine Hardwareressourcenanforderung der Funktion beinhalten. Die eine oder die mehreren Ressourcen können ferner einen Hardwarebeschleuniger beinhalten, den die Funktion während der Ausführung einsetzen soll. Darüber hinaus können der eine oder die mehreren Moniker einen geographischen Bereich zum Ausführen der Funktion angeben. Ferner können der eine oder die mehreren Moniker einen Typ der Funktion angeben (zum Beispiel Bilderkennung oder Bilddrehung). Wie oben beschrieben, können die eine oder die mehreren Ressourcen und der Typ der Funktion eingesetzt werden, um die Funktion zu einem zweckdienlichen Knoten zuzuordnen und Latenz zu reduzieren, während die Effizienz gesteigert wird.
Zusätzliche Anmerkungen und Beispiele
Beispiel 3300 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, Felder eines Funktionskonstrukts, die mit einer Funktion assoziiert sind, zu identifizieren und Metadaten aus den Feldern zu bestimmen, einen oder mehrere Moniker aus den Metadaten zu bestimmen, wobei die Moniker eine oder mehrere Ressourcen angeben sollen, die die Funktion während der Ausführung einsetzen soll, wobei die eine oder die mehreren Ressourcen Daten beinhalten, die die Funktion während der Ausführung einsetzen soll, eine Hardwareressourcenanforderung der Funktion, einen Hardwarebeschleuniger, den die Funktion während der Ausführung einsetzen soll, wobei der eine oder die mehreren Moniker einen geographischen Bereich zum Ausführen der Funktion und einen Typ der Funktion angeben.
Beispiel 3301 beinhaltet mindestens ein computerlesbares Medium, das einen Satz von Anweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, Felder eines Funktionskonstrukts, die mit einer Funktion assoziiert sind, zu identifizieren und Metadaten aus den Feldern zu bestimmen, und einen oder mehrere Moniker aus den Metadaten zu bestimmen, wobei die Moniker eine oder mehrere Ressourcen, die die Funktion während der Ausführung einsetzen soll, angeben.
Beispiel 3302 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 3301, wobei die eine oder die mehreren Ressourcen Daten beinhalten, die die Funktion während der Ausführung einsetzen soll.
Beispiel 3303 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 3301, wobei die eine oder die mehreren Ressourcen eine Hardwareressourcenanforderung der Funktion beinhalten.
Beispiel 3304 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 3301, wobei die eine oder die mehreren Ressourcen einen Hardwarebeschleuniger beinhalten, den die Funktion während der Ausführung einsetzen soll.
Beispiel 3305 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 3301, wobei der eine oder die mehreren Moniker einen geographischen Bereich zum Ausführen der Funktion angeben.
Beispiel 3306 beinhaltet das mindestens eine computerlesbare Medium des Beispiels 3301, wobei der eine oder die mehreren Moniker einen Typ der Funktion angeben sollen.
Beispiele für dynamische Platzierung und Prefetching
Für derzeit existierende Lösungen sind FaaS-Funktionen an jeder Stufe der Funktionsausführungen nicht optimal platziert. Es können zum Beispiel hohe Ressourcenkosten für das Zurückführen von Daten zwischen einer feldprogrammierbaren Gate-Array-Version (FPGA-Version) und einer Ausführungssoftware-Version (Speicher) anfallen. Eine Infrastruktur kann oft unzureichend Speicher zu einer gegebenen Zeit besitzen, um eine gewünschte Anzahl (und einen gewünschten Typ) von Funktionscontainern für schnelle Wiederverwendung verfügbar zu halten.
Unter Bezugnahme auf 34A ist gemäß einer beispielhaften Ausführungsform ein Beispiel gezeigt, in dem eine Aufrufgrafik verwendet wird, um Funktionen basierend auf der Häufigkeit der Funktionenaufrufe vorab zu holen. Ein Benutzeroberflächenhandlanger 3440 kann eine Anforderung 3450 zum Optimieren der FaaS-Funktionsausführungen empfangen und seinerseits eine Aufrufgrafik 3460 erzeugen. Die Aufrufgrafik 3460 kann Aufrufbeziehungen 3462 zwischen Funktionen darstellen.
Bei dem veranschaulichten Beispiel kann ein Orchestrator 3470 eine Funktion 3480, die am wahrscheinlichsten als nächste aufgerufen wird, basierend auf einer angegebenen Funktionsaufrufhäufigkeit in der Aufrufgrafik 3460 vorab holen. Die vorab geholte Funktion kann in die Zwischenlagerung geladen und initialisiert werden. Bei dem veranschaulichten Beispiel kann die vorab geholte Funktion vorübergehend in dem Cache 3492 eines Servers 3490 gespeichert werden. Der Orchestrator 3470 kann einen Befehl für den Server 3490 zum Freigeben der Funktion, die am wenigsten wahrscheinlich aufgerufen wird, ausgeben.
34B veranschaulicht ein Verfahren zum Verbessern des Ausführens einer FaaS-Funktion gemäß einer Ausführungsform. Bei Block 3410 des Verfahrens 3400 kann eine Grafik, die eine Häufigkeit von Funktionsaktivierungen („Calls“) angibt, erzeugt werden. Eine Aufrufgrafik kann eine Steuerflussgrafik sein, die Aufrufbeziehungen zwischen Funktionen darstellt. Bei einer gewichteten Aufrufgrafik kann jeder Bogen, der von einem Vorläufer (vorherige Funktion) ausgeht und an einer oder mehreren Nachfolgefunktionen endet, mit der Häufigkeit (zum Beispiel Wahrscheinlichkeit, dass der Vorläufer zu dem Nachfolger führen wird) des Aufrufs des Nachfolgers gekennzeichnet werden. Eine Aufrufgrafik kann einer Steuerflussgrafik ähnlich sein, mit der Ausnahme, dass da, wo die Steuerflussgrafik Call-Return-Beziehung (und Nesting) unter Vorgehensweisen aufweist, eine Aufrufgrafik für Funktionen eine grafische Angabe diverser Funktionen ist, die ausgeführt werden und allmählich die Bedingungen auslösen, die die Ausführungen anderer Funktionen verursachen, wobei letztere Funktionen gewöhnlich Daten oder Resultate, die von den vorhergehenden erzeugt wurden, verbrauchen oder auf sie zugreifen. Gemäß einer beispielhaften Ausführungsform bedeutet die Kenntnis, dass eine anwesende Funktion F ausgeführt wird, und dass sie zu dem Ausführen der Funktion führen wird, dass G „vorab geholt“ werden kann, ihr Aufbau beginnen, ihre Daten positioniert/zugewiesen usw. werden können. Die Gewichtungen auf der Aufrufgrafik können Wahrscheinlichkeiten darstellen, die die Wahrscheinlichkeit angeben, dass F die Ausführung von G verursachen wird.
Die Aufrufgrafik kann statisch gebildet und dann dynamisch verfeinert werden. Bei Block 3420 kann die Funktion, die am wahrscheinlichsten als nächste aufgerufen wird, basierend auf der angegebenen Frequenz von Funktionsaufrufen in der Aufrufgrafik vorab geholt werden. Die vorab geholte Funktion kann daher in Zwischenlagerung geladen und initialisiert werden, so dass die Funktion zum Ausführen bereit ist, wenn die Vorläuferfunktion sie aktiviert. Bei Block 3430 können FaaS-Funktionen, die am wenigsten wahrscheinlich bei jeder Phase/jedem Bereich der Aufrufgrafik aufgerufen werden, ausgeladen werden, um Ressourcen freizugeben.
Analog zu herkömmlichen Vorgehensweisenaufrufsequenzen bei herkömmlichen Programmen, kann eine „Aufrufer“-Funktion optional eine andere „Aufgerufenen“-Funktion direkt mit einem Fernvorgehensweisenaufruf aufrufen (und dann darauf warten, eine Angabe zu erhalten, dass der Fernvorgehensweisenaufruf zu dem Aufgerufenen abgeschlossen wurde). Der oben erwähnte Bogen kann ferner mit den damit verbundenen Kosten erweitert werden, mit Ausführen der Nachfolgefunktion, für FaaS kann das die Kosten von Weitergabeparametern und Resultaten beinhalten. Der Aufwand von JavaScript-Object-Notation-Objekten (JSON-Objekten) kann zum Beispiel unter Berücksichtigung der Größe in Byte und der Kommunikationsbandbreite zwischen den zwei Punkten, die die Aufgerufenenfunktion und die Aufruferfunktion hosten, kommuniziert werden. Basierend auf der Häufigkeit von Aufrufen, können Ressourcen, die auf jedem Host verfügbar sind, Aufrufaufwand, Preisgestaltung/bereitgestelltes Prioritäts-Tier usw. eine optimale Platzierung für FaaS-Funktionen bei jeder Stufe berechnet werden. Die Stufen können dynamisch sein. Jedes Mal, wenn eine Funktion F aktiviert ist, kann die Aktivierung der Funktion F daher in einer Aktivierung einer anderen Funktion G resultieren, und im Allgemeinen kann G anderswo ausgeführt werden.
Ausführungsformen des Verfahrens 3400 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 3400 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 3400 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flashspeicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 3400 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 3401 beinhaltet ein Verfahren, das das Bilden einer Aufrufgrafik umfasst, die Aufrufbeziehungen zwischen Funktionen darstellt, wobei die Aufrufgrafik eine Häufigkeit oder Wahrscheinlichkeit von Vorläufer- und Nachfolgeaktivierungen basierend auf der Frequenz von Funktionsaufrufen angibt, die von der Aufrufgrafik angegeben werden, Vorabholen einer wahrscheinlichsten nächsten Funktion, so dass die wahrscheinlichste nächste Funktion, wenn sie aufgerufen wird, bereits auf das Laufen vorbereitet ist, und Ausladen mindestens einer unwahrscheinlichsten nächsten Funktion.
Beispiel 3402 beinhaltet das Verfahren des Beispiels 3401, das ferner umfasst, dass die Aufrufgrafik einen Bogen einsetzt, der eine Aufrufaufrufungsfrequenz darstellt.
Beispiel 3403 beinhaltet das Verfahren des Beispiels 3402, das ferner das Berechnen von Ressourcen, die auf jedem Host verfügbar sind, basierend auf der Häufigkeit/Wahrscheinlichkeit von Funktionsaufrufen umfasst.
Beispiel 3404. Verfahren des Beispiels 3401, wobei die Funktionsaufrufe mit existierenden Anwendungen rückwärts kompatibel sein sollen.
Beispiel 3405. Verfahren des Beispiels 3401, wobei ein Speicherintegritätsprotokoll verwendet werden soll, um Datenversionen im Speicher zu identifizieren.
Beispiel 3406 beinhaltet ein Verfahren, das das Bilden einer Aufrufgrafik umfasst, die Aufrufbeziehungen zwischen Funktionen darstellt, wobei die Aufrufgrafik eine Häufigkeit von Funktionsaufrufen basierend auf der Häufigkeit von Funktionsaufrufen, die von der Aufrufgrafik angegeben wird, angibt, Vorabholen mindestens einer wahrscheinlichen nächsten Funktion, so dass die wahrscheinliche nächste Funktion bereits auf das Laufen vorbereitet ist, wenn sie aufgerufen wird, Ausladen mindestens einer unwahrscheinlichsten nächsten Funktion, Einsetzen eines Bogens in der Aufrufgrafik, wobei der Bogen eine Aufrufaufrufungshäufigkeit darstellt, und Berechnen von Ressourcen, die auf jedem Host verfügbar sind, basierend auf der Häufigkeit von Funktionsaufrufen, wobei die Funktionsaufrufe rückwärts mit existierenden Anwendungen kompatibel sein sollen, und wobei ein Speicherintegritätsprotokoll verwendet werden soll, um eine Datenversion im Speicher zu identifizieren.
Beispiele für gestaffelte Multiversionsinitiierung einer Multi-Mieter-Funktion
Die beispielhafte Ausführungsform, die unmittelbar oben beschrieben ist, kann auf eine zweite Funktion „B“ in einer Kette von Funktionen C: {F(i) ... F(ii) ... F(iii) ...F(n)} auf der Basis früherer Historie, zum Beispiel nicht nur basierend auf der zweiten Funktion selbst, sondern auf einem Subsatz ihrer Vorläuferkette erweitert werden. Mit anderen Worten kann beim Auswählen, ob eine softwarebasierte, minimal beschleunigte oder beschleunigte Version einer Funktion gestartet werden soll oder nicht, eine beispielhafte Ausführungsform nicht nur die Historie von Nutzungen der Funktion B, sondern auch der Vorläuferfunktionen Bp in der Kette, die B vorausgeht, berücksichtigen. 35A ist ein Blockschaltbild, das vorausgehende Funktionen Bp 3550 einer Funktion B 3560 zeigt, bei welchen die vorhergehenden Funktionen Bp 550 eine Funktion 3560, die derzeit ausgeführt wird, verwendet werden kann, um die nächste Funktion, die vorab geholt und aufgerufen werden soll, zu bestimmen.
Beispielhafte Vorteile dieser Ausführungsform beinhalten gleichzeitiges Ausgleichen der Verwendung beschränkter Beschleunigungsressourcen (unter mehreren Kandidaten), und Minimieren der Kosten des Rückführens von Daten zwischen Hardware- (zum Beispiel FPGA) und Software-Ausführungsversionen (Speicherausführungsversionen). In der Praxis kann diese Ausführungsform das Aktivieren von Ketten mit minimalen Versionen beschleunigter Funktionen über das Aktivieren vollständiger Versionen ermöglichen, so dass das Zurückfließen von Daten minimiert wird.
Gemäß einer beispielhaften Ausführungsform kann es eine Kettentiefe 1 geben: Bp → B, wobei Bp die Funktionen darstellt, die der Funktion B, wie oben erklärt, vorausgehen.
Gemäß dieser Ausführungsform ist die Funktion Bp der unmittelbare Vorläufer der Funktion B, und x und y können jeweils der Startschwellenwert und der Rückforderschwellenwert für eine volle Version der Funktion B sein. Auf ähnliche Art können u und v jeweils die Start- und Rückforderschwellenwerte für eine voll Version von Bp sein. Die Ressourcen einer Funktion werden „zurückgefordert“, falls die Time-To-Live der Funktion abgelaufen ist, oder falls andere Betrachtungen, wie ihr gewichtetes Maß für das Weiterlaufen unter einen Schwellenwert gefallen sind. In die entgegengesetzte Richtung, in Bezug auf den Startschwellenwert, falls eine Funktion, die gewöhnlich nicht zwischengespeichert oder vorab geholt wird, Anzeichen gesteigerter Nutzung zeigt, kann es mit gesteigerter Nutzung attraktiv werden, um diese Funktion zwischengespeichert und möglicherweise vorab geholt zu halten. Gemäß einer beispielhaften Ausführungsform kann daher, falls die Vorläuferfunktionen einer Funktion aktuell mit steigender Häufigkeit laufen, die Vorläuferfunktion die die Berechtigung für die Funktion B vorab geholt zu werden, einen Startschwellenwert überschreiten. Gemäß einer beispielhaften Ausführungsform können die Rückforderungsschwellenwerte für die jeweiligen Funktionen niedriger sein als die Startschwellenwerte.
x kann auch um eine kleine Menge z (Kopplungsbeitrag) verringert werden, wenn u verringert wird, und y kann um eine kleine Menge z angehoben werden, wenn v angehoben wird, und zwar in einer Bemühung sicherzustellen, dass gewünschte Hardware- oder Softwarebedingungen erfüllt werden. Solche Änderungen unterliegen der Bedingung, dass x, y und |x - y| alle zwangsweise Werte annehmen, die nicht gegen diverse Max-/Min-Regeln verstoßen.
Falls gemäß einer anderen beispielhaften Ausführungsform u und v nicht wechseln dürfen, x und y jedoch wechseln dürfen, können virtuelle Werte u' und v' (Schattenwerte für u und v) berechnet werden, und dann kann an x und y jeweils basierend auf berechneten Werten u' und v' ein Kopplungsbeitrag z angewandt werden. Gemäß einer beispielhaften Ausführungsform ist es Werten „u“ und „v“ zum Beispiel nicht gestattet zu variieren, weil der Ressourceneinsatz von Bp gezügelt werden muss; falls jedoch ein Aufwärtstrend der Ankunftsrate in Bp besteht, kann der Aufwärtstrend x abwärts beeinflussen (da die Ankunftsrate in B steigen würde), und y könnte auf ähnliche Weise aufwärts beeinflusst werden (um die Rückforderungsrate für B zu reduzieren).
Die oben beschriebene Ausführungsform kann verwendet werden, um Kettentiefen > 1 transitiv zu verallgemeinern. Im Allgemeinen können beim Berechnen des Kopplungsbeitrags (z) mehr als einen Parameter geben, zum Beispiel kann in einer ressourcenbeschränkten Umgebung eine variable Steigerungsmenge der Time-To-Live für eine gegebene beschleunigte Funktion B angewandt werden, wenn die Nachfrage nach Funktion B und ihren Vorläufer abfällt (so dass B schneller zurückgefordert werden kann); auf ähnliche Art, wenn die Gesamtnachfrage niedrig ist, oder wenn SLA-Anforderungen streng sind, kann es eine stärkere positive Tendenz für das Starten der Funktion B und eine stärkere negative Tendenz gegen das Rückfordern von B basierend auf den Beobachtungen an ihren Vorläufern geben.
Unter Bezugnahme auf 35B kann gemäß einer beispielhaften Ausführungsform bei Block 3510 des Verfahrens 3500 eine Funktion A gestartet werden. Bei Block 3520 können Vorläuferfunktionen B, die der Funktion A vorausgehen, identifiziert werden. Bei Block 3540 kann bestimmt werden, ob eine beschleunigte Version der Funktion A basierend auf den Vorläuferfunktionen B und der Nutzungshistorie der Funktion A beschleunigt gestartet werden soll.
Ausführungsformen des Verfahrens 3500 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 3500 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 3500 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flashspeicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C‟-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 3500 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 3501 beinhaltet ein Verfahren, das das Starten einer Funktion, das Identifizieren von Vorläuferfunktionen, die der Funktion vorangegangen sind, das Bestimmen, ob eine beschleunigte Version der Funktion basierend auf Vorläuferfunktionen, die der Funktion vorangegangen sind, und Nutzungshistorie der Funktion gestartet werden soll, und Speichern der Funktion und der Vorläuferfunktionen in einem Repository umfassen.
Beispiel 3502 beinhaltet das Verfahren des Beispiels 3501, das ferner das Identifizieren von Funktionsversionen im Speicher unter Verwenden von Meldungsauthentifizierungscode (Message Authentication Code - MAC) umfasst.
Beispiel 3503 beinhaltet das Verfahren des Beispiels 3501, das ferner einen Container umfasst, der einen Fernvorgehensweisenaufruf (RPC) abfängt und ihn lokal bedient, wobei die Funktion transparent und rückwärts mit existierenden Anwendungen kompatibel sein soll.
Beispiel 3503 beinhaltet das Verfahren des Beispiels 3501, das ferner das Vorabholen von Daten in Zusammenhang mit der Funktion umfasst.
Beispiel 3504 beinhaltet ein Verfahren, das das Starten einer Funktion umfasst, die Vorläuferfunktionen identifiziert, die der Funktion vorausgegangen sind, das Bestimmen, ob eine beschleunigte Version der Funktion basierend auf Vorläuferfunktionen, die der Funktion vorausgegangen sind und Historie der Nutzung der Funktion gestartet worden sind, das Identifizieren von Funktionsversionen im Speicher unter Verwenden von Meldungsauthentifizierungcode (MAC), das Abfangen über einen Container eines Fernvorgehensweisenaufrufs (RPC) und das lokale Bedienen dieser, wobei die Funktion transparent und rückwärts mit existierenden Anwendungen, Vorabholen von Daten in Zusammenhang mit der Funktion sein soll und Speichern der Funktion und der Vorläuferfunktionen in einem Repository umfasst.
Beispiele für adaptive Rückforderungsrate
Unter Bezugnahme auf 36A gemäß einer anderen Ausführungsform, zeigt 36A ein Beispiel des Behaltens der Wärme eines Containers basierend auf einer Wahrscheinlichkeit, dass eine Funktion ausgeführt wird. Im Einzelnen besteht beim Abschließen (Ausführen) einer Funktion X 3655 in einem Container 3650 eine Wahrscheinlichkeit P 3660, dass eine andere Funktion Y 3675 in einem Container 3670 ausgeführt wird. Bei einer Videoüberwachungsanwendung kann zum Beispiel die Funktion X 3655 eine Medientranscodierungsfunktion sein, und die Funktion Y 3675 kann eine Erfassungs- und grobe Abstimmungsfunktion (zum Beispiel eine Funktion, um zu bestimmen, ob der Videostream eine Person oder einen Teil einer Person zeigt) sein kann; oder die Funktion X 3655 eine grobe Abstimmungsfunktion sein kann, während die Funktion Y 3675 eine Erkennungsfunktion sein kann (zum Beispiel eine Funktion, um zu bestimmen, ob eine Person, die in dem Video erfasst wird, auch als eine bekannte Person in einer Datenbank, zum Beispiel ein Freund oder Familienmitglied, ein Fremder usw. ist). Diese Wahrscheinlichkeit P 3660 kann konstant sein, ist gewöhnlich aber variabel, basiert auf Bearbeitungszeit oder anderen zeitlich oder räumlich korrelierten Faktoren.
Ein Wahrscheinlichkeitsschätzer 3685 eines Orchestrator 3680 kann eine Entscheidung erzeugen, um den Container 3670 für die Funktion Y 3675 warm zu halten, was von einer dynamischen Entwicklung einer solchen Wahrscheinlichkeit P 3660 abhängen kann; oder, allgemeiner, kann eine Containerrückforderungsrate für Funktionen vom Typ Y gemäß dieser Wahrscheinlichkeit P 3660 variiert werden. Durch Annehmen der Rückforderungsraten und Entscheidungen basierend sowohl auf jüngeren als auch historischen Beurteilungen der Wahrscheinlichkeit P 3660, kann eine Gesamtzielsetzung, die sowohl an jüngere Informationen adaptiv als auch in Bezug auf Langzeitinformationen hinsichtlich der Belastung ausgewogen ist, erhalten werden.
Die gleich vorstehende beispielhafte Lösung kann zu einer Grafik von Funktionsaufrufen oder einem Dienstraster verallgemeinert werden und kann ferner auf beschleunigte Funktionen derart verallgemeinert werden, dass nicht nur (i) die Zeit zur Rückforderung adaptiv variiert wird, sondern (ii) längere Bereichsbeurteilungen von Wahrscheinlichkeitsflüssen über mehrere Grafikkanten verwendet werden können, um diejenigen Funktionen, für die die Aktivierungszeit (Aufwärmzeit) nicht unbedeutend ist, vorab zu aktivieren.
Bei einer Ausführungsform können probabilistische Grafikmodelle (Probabilistic Graph Models - PGMs) als Allzweck-Framework zum Aktualisieren der Wahrscheinlichkeitsflüsse der einen oder mehreren untereinander abhängigen Funktionen verwendet werden. PGM-Faktorisierungstechniken und Bibliotheken können verwendet werden, um die dynamischen Wahrscheinlichkeiten jeder Funktion Y 3675 basierend auf ihrer Abhängigkeit von ihrer Vorläuferfunktion X 3655, und der dynamischen Wahrscheinlichkeiten der Funktion X 3655 basierend auf Vorläufern der Funktion X 3655 zu erhalten. Eine einfachere aber umsetzbare Vereinfachung kann darin bestehen, schwache Wahrscheinlichkeitsflüsse (zum Beispiel durch Behandeln wöchentlich korrelierter Funktionen als voneinander unabhängig) zu entfernen, um solche Grafiken selten zu machen, und dann einen PGM-Solver, der in einer probabilistischen Programmiersprache (zum Beispiel FIGARO) geschrieben ist, anzuwenden. Eine andere Umsetzung kann darin bestehen, ein Suchmaschinen-Page-Rank-System als eine vereinfachte Form von Herstellen einer Beziehung zwischen der Beliebtheit einer Funktion mit der ihrer Vorläufer oder Antezedenten durch eine Gewichtung zu verwenden (die selbst im Voraus geschätzt oder dynamisch gefolgert werden kann), und die iterative Page-Rank-Lösung zu verwenden, um zu schätzen, wie häufig unterschiedliche Funktionen wahrscheinlich basierend auf verfügbaren Daten ausgeführt werden.
Ein solcher Ansatz kann wendige Ressourcenzuordnung sowohl für beschleunigte als auch herkömmliche (CPU-Software-basierende) Realisierung von Funktionen erlauben, statt festcodierte Konstanten oder einfache Heuristiken zum Steuern der Anzahlen warmer Container oder Time-To-Live-Parameter (TTL-Parameter). Alternativ kann diese beispielhafte Ausführungsform mit anderen Realisierungen arbeiten und kann verwendet werden, um solche Konfigurationseinstellungen über Anzahlen von Containern oder ihre TTLs basierend auf periodischer Bewertung gesammelter Telemetrie unter Verwenden der obigen Wahrscheinlichkeitstechniken anzupassen. Ferner kann das gesamte Optimierungsproblem selbst ein Bin-Packing-Problem aufweisen, das versucht, den ressourcenbeschränkten Durchsatz des Problems durch Maximieren des Durchsatzes von Aktivierungen mit höherer Wahrscheinlichkeit normalisiert durch ihre Ressourcenanforderungen zu maximieren.
Unter Bezugnahme auf 36B wird ein Verfahren zum Ausführen einer Function-as-a-Service von einem warmen Container gemäß einer Ausführungsform veranschaulicht. Bei Block 3610 des Verfahrens bei 3600 kann eine Funktion A gestartet werden. Bei Block 3630 wird eine Bereitschaft (zum Beispiel Wärme) eines Rechencontainers zum Ausführen einer darauffolgenden Funktion der Funktion A basierend auf einer dynamischen Bewertung einer Wahrscheinlichkeit, dass die darauffolgende Funktion ausgeführt wird, aufrechterhalten.
Ausführungsformen des Verfahrens 3600 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 3600 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 3600 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flashspeicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 3600 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 3601 beinhaltet ein Verfahren, das das Ausführen einer Funktion umfasst, auf das Ausführen der Funktion folgend das Aufrechterhalten einer Bereitschaft eines Containers zum Ausführen einer darauffolgenden Funktion basierend auf einer dynamischen Bewertung einer Wahrscheinlichkeit, dass die darauffolgende Funktion ausgeführt wird.
Beispiel 3602 beinhaltet ein Verfahren, das das Ausführen einer Funktion umfasst, auf das Ausführen der Funktion folgend das Aufrechterhalten einer Bereitschaft eines Containers zum Ausführen einer darauffolgenden Funktion basierend auf einer dynamischen Bewertung einer Wahrscheinlichkeit, dass die darauffolgende Funktion ausgeführt wird, das Löschen nur von Funktionsdaten nicht aber Funktionslogik, die einen Multi-Key-Total-Memory-Encryption-Code (MKTME-Code) bestimmt, wenn separate Codes separaten Funktionen zugewiesen sind, und das Zurückfordern nur von Benutzerprogrammen nicht aber gemanagter Laufzeit.
Beispiele für adaptives Speichereinteilen
Wenn eine Funktion weniger verwendet wird, kann die Kapazitätsmenge, die sie belegt, reduziert werden. Eine Infrastruktur kann oft unzureichend Speicher zu einer gegebenen Zeit besitzen, um eine gewünschte Anzahl (und einen gewünschten Typ) von Funktionscontainern für schnelle Wiederverwendung verfügbar zu halten.
Gemäß einer beispielhaften Ausführungsform des verbesserten FaaS-Systems, wie der einen, die in 4 gezeigt ist, können sowohl die Größe als auch die Nutzungshäufigkeit einer Funktion beim Entscheiden, ob eine Funktion ihre Daten oder Code in Hochleistungsspeicherebene haben sollte, berücksichtigt werden. Bei anderen Ausführungsformen kann das auf Nutzung basieren: eine weniger verwendete Funktion in einer Ebene mit niedrigerer Leistung (wie 3DXP-Speicher) lassen statt sie ganz zurückzufordern. Gemäß einer Ausführungsform des verbesserten FaaS-Systems mit Tiering in Speicher, kann das Tiering in Speicher sowohl hinsichtlich der Größe als auch der Nutzung adaptiv gemacht werden. Falls daher eine Größe groß ist, kann die Funktion, sogar falls eine Funktion häufig verwendet wird, in eine weit entfernte Ebene wie in 3DXP, gegeben werden. Falls die Nutzung niedrig ist, kann die Funktion auch in eine weit entfernte Ebene gegeben werden. Falls sie sich ferner in einer entfernteren Ebene befindet, sollte die Funktion mit entsprechend längerer Time-To-Live versehen werden, da sie bereits weniger Ressourcen verbraucht.
Bei anderen Ausführungsformen kann die Verwendung mehrerer aktueller oder virtualisierter Speicherebenen verteilt worden sein, um insgesamt eine höhere Rate warmer Container zu erhalten, ohne die leistungskritische Speicherkapazität übermäßig zu abonnieren, wie in MCDRAM/HBM- oder DDR-Ebenen. Bei der aktuellen beispielhaften Ausführungsform, die in 37A gezeigt, kann derselbe Ansatz sowohl innerhalb einer Funktion als auch an Funktionsketten angewandt werden.
1. INNERHALB EINER FUNKTION: Zunächst muss berücksichtigt werden, dass eine Funktion im Vergleich zu der Menge an verfügbarer Kapazität in Leistungsebenen (zum Beispiel MCDRAM/HBM, DRAM) in Speicher mit mehreren Ebenen, zum Beispiel Amazon Lambda, ein Limit pro Container von ~400MB auferlegt, was für öffentliche Versionen vieler Topologien groß genug ist, aber für Math Kernel Library für Deep Neural Learning Networks (MKL-DNN) zu klein sein kann.
Gemäß der aktuellen beispielhaften Ausführungsform, deren Aspekte in den 37A und 37B veranschaulicht sind, können Funktionen sowohl gemäß der Größe als auch gemäß der Nutzung segmentiert werden, so dass:

1a. die Funktionen 3710, die zu groß sind, um DRAM-Platzierung zugewiesen zu werden, vorab in eine äußere Speicherebene 3720 (37A) zugewiesen werden können; und
1b. Funktionen, die eine hohe historische Gesamtnutzungshäufigkeit aufweisen aber welchen der aktuelle Pausenratenschwellenwert bereits ausgegangen ist, in einer äußeren Speicherebene gehalten werden, statt sofort zurückgefordert zu werden; und sie können dort während einer langen Zeit altern. Der Pausenratenschwellenwert kann effektiv die Time-To-Live für einen Container einer Funktion nach ihrer jüngsten Verwendung sein. Falls keine Anforderung in dieser Zeit eintrifft, kann die Funktion entfernt werden, so dass ihre Ressourcen, in der Hauptsache Speicher, freigegeben.

Gemäß Nutzungsstatistiken und Speicherseitenzugriffsprofilierung können mit der Zeit heißere Seitensätze in reservierte MCDRAM/HBM/DDR-Bereiche reflektiert werden, außer wenn der Fußabdruck des dynamischen Codes einer Funktion gerade zu groß ist, um davon zu profitieren, dass ein Teil davon vorübergehend einer Leistungsebene zugewiesen wird.
2. FUNKTIONEN ÜBER KETTEN: Die Ausführungsformen, die gleich darüber beschrieben sind, können zu Ketten von Funktionen wie folgt erweitert werden:

2a. Wie in 37B veranschaulicht, falls Antezedentenfunktionen 3730 oder abhängige Funktionen 3750 einer Funktion X(i) 3740 in einer Kette (oder einem Web) von Funktionen aktiv sind, sei dies in einem einer oberen oder unteren Ebene zugewiesenen Speicher, kann an Stelle des Recyclings von X(i) (zum Beispiel Abbauen eines Containers, der X(i)), X(i) hostet), die Platzierung in der äußeren Ebene basierend auf der Fortsetzung dieser Antezedent- und/oder abhängigen Funktionen gegeben werden.

Dieser Ansatz von adaptivem Speicher-Tiering kann umgesetzt werden, da Latenzen der Ausführung für Kaltstarte viel empfindlicher sind als für langsamere Performance eines nicht kalten Containers, dessen Speicher sich in einer äußeren Speicherebene befindet. Ferner schließt dieser Ansatz eine zeitweilige Beförderung solcher aktiver Container, die in einer entfernten Ebene gehalten werden, nicht aus, wenn ausreichend freie Kapazität in einer näheren Ebene besteht.
Das erfinderische Konzept der 37A kann an unterschiedliche Objekte innerhalb von Funktionen angewandt werden. Bei einer beispielhaften Ausführungsform kann Software mehr darüber wissen, welchen Teil der Daten einer Funktion die Funktion bei sich behalten wird und welchen Teil nicht. Falls für Objekte, die normalerweise zum Beispiel in einer Java-Nursery (Bereich für junge Objekte) zugeordnet werden können, bekannt ist, dass die Objekte wahrscheinlich während längerer Zeit verwendet werden, können diese Objekte anderswo zugeordnet werden, zum Beispiel in einer weniger leistungsfähigen Speicherebene. Statt einen gesamten Funktionskörper einer großen Funktion in eine äußere Ebene zu geben, kann der Nicht-Nursery-Teil einer großen Funktion in eine äußere Ebene gegeben werden, da Nursery-Speicher ohnehin bald zurückgefordert werden kann.
Gemäß einer beispielhaften Ausführungsform kann es einen Fall geben, bei dem die äußere Ebene, die in den 37A oder 37B gezeigt ist, nicht vor Angriffen auf die Privatsphäre geschützt wird, weil sie zum Beispiel nicht durch einen Hardware-Schlüsselmechanismus geschützt ist. In diesem Fall kann eine Lösung darin bestehen, den Körper einer Funktion in einer äußeren Ebene, die mit Software verschlüsselt ist, zu behalten, und sie dann, wenn die Funktion aktiviert werden muss, zu entschlüsseln und den Funktionskörper in eine Speicherebene zu platzieren, die HW-Schutz genießt. Für eine solche Verschlüsselung-Entschlüsselung kann ein Schlüssel mit einer Funktion assoziiert werden, bei der der Schlüssel innerhalb des HW-geschützten Speichers geschützt ist, und dieser Schlüssel kann in einem auf Software basierenden Verschlüsselungs-Entschlüsselungsverfahren verwendet werden. Das Entschlüsseln des Körpers einer Funktion und Zustands kann billiger sein als das komplette Neukonstruieren, insbesondere wenn er groß ist.
Unter Bezugnahme auf 37C ist ein Verfahren zum adaptiven Speicher-Tiering einer Funktion gemäß einer Ausführungsform veranschaulicht. Bei Block 3710 des Verfahrens bei 3700 kann eine Funktion A gestartet werden. Bei Block 3720 werden die Größe und die Nutzungshäufigkeit der Funktion A bestimmt. Bei Block 3730 wird bestimmt, ob die Funktion A häufig verwendet wird. Falls bei Block 3730 bestimmt wird, dass die Funktion A häufig verwendet wird, wird bei Block 3740 bestimmt, ob die Funktion A groß ist. Falls die Funktion A groß ist, wird die Funktion A bei Block 3750 in eine entfernte Speicherebene gegeben.
Ausführungsformen des Verfahrens 3700 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 3700 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 3700 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flashspeicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 3700 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 3701 beinhaltet ein Verfahren, das das Ausführen einer Funktion, das Bestimmen der Größe und der Nutzungshäufigkeit der Funktion und, falls die Funktion häufig verwendet wird und groß ist, das Platzieren der Funktion in einer entfernten Speicherebene beinhaltet.
Beispiel 3702 beinhaltet das Verfahren des Beispiels 3701, das ferner das Bewegen von Funktionen in Speicherhierarchie unter Verwenden von Kryptografie umfasst.
Beispiel 3703 beinhaltet das Verfahren des Beispiels 3701, Kommunizieren zwischen Funktionen unter Verwenden von Cache.
Beispiel 3704 beinhaltet ein Verfahren, das das Ausführen einer Funktion, das Bestimmen der Größe und der Nutzungshäufigkeit der Funktion und, falls die Funktion häufig verwendet wird und groß ist, das Platzieren der Funktion in einer entfernten Speicherebene, das Bewegen von Funktionen in Speicherhierarchie unter Verwenden von Kryptografie und das Kommunizieren zwischen Funktionen unter Verwenden von Cache beinhaltet.
Beispiele für schnelles Laden vom Klassen
Ein CSP kann gewöhnlich flexible Planungsmechanismen/Module für FaaS einsetzen. Das Laden und Abbauen der gemanagten Laufzeitcontainer für FaaS kann kostspielig sein, als solches wertvolle CPU-Zeit verbrauchen, die für andere Zwecke verwendet werden könnte (zum Beispiel Verarbeiten aktiver Funktionen, Verteilen und Planen neuer Funktionen, jeder andere Typ von Umsatz erzeugendem Zweck usw.). Das Laden und das Abbauen von Containern kann daher die Effizienz reduzieren und den Stromverbrauch erhöhen. Dieses Problem kann bei gemanagten Laufzeit-Sprachen vom statischen Typ, wie Java, besonders schwerwiegend sein, da ein System mit gemanagter Laufzeit, wie zum Beispiel eine virtuelle Java-Maschine (JVM), lang benötigen kann, um einen vollständigen Satz von Bibliotheken grundlegender Klasse zu laden, um zum Beispiel auch nur ein einfaches „Hello World“-Programm laufen zu lassen. Das kann für herkömmliche Datencenternutzung kein Problem sein, ist aber für FaaS kostspielig.
Anders als langlaufende Anwendungen oder kontinuierliche Mikrodienste, machen es die Ad-Hoc-, burstartigen und unvorhersehbaren Ankunftsraten von Anforderungen nach FaaS-Ausführungen schwierig, QoS-Erwartungen zu erfüllen, insbesondere falls die QoS-Erwartungen selbst von einer Funktion zu der anderen variieren.
Gemäß einer beispielhaften Ausführungsform, wie in dem Blockschaltbild der 38A veranschaulicht, wird ein auf Workload basierendes Klassenladungs-Optimierungsmodul bereitgestellt, bei dem nur die verwendeten Klassen durch den optimierten Klassenlader geladen werden. Dieses Modul ermöglicht schnelle, gemanagte Laufzeitladezeit.
In 38A können Klassenutzungsdaten 3860 über einen benutzerdefinierten gemanagten Laufzeitsystem-Klassenlader 3850 (zum Beispiel eine benutzerdefinierte Java Virtual Maschine) erhalten werden: Ein Analysator 3854 und des benutzerdefinierten gemanagten Laufzeitsystem-Klassenladers 3850 kann während der ersten Ausführung einer Funktion eines FaaS-Service aufgerufen werden. Bei einigen Ausführungsformen kann der Analysator 3854 während Ausführungen der Funktion, die nach der ersten Ausführung auftreten, aufgerufen werden. Nutzungsdaten, wie Klassenabhängigkeitsgrafiken, Klassen, Verfahren und variable Initialisierung, Offset-Berechnung, Entvirtualisierung und Daten in Zusammenhang mit dem Binden von JNI-Funktion an JAVA-native Verfahren, können als eine Metadatendatei für späteres Aufrufen der Cloud-Funktion gespeichert werden. Die Workload-Eingaben 3862 können Eingaben und/oder Werte für die FaaS-Funktion beinhalten.

- Der benutzerdefinierte gemanagte Laufzeitsystem-Klassenlader 3850 kann die Metadatendatei über einen Metadatendateilader 3856, der mit einer spezifischen FaaS-Funktionen verbunden ist, für jede darauffolgende Ausführung dieser Funktionen laden.
- Mehrere Metadatendateien können für eine einzige FaaS-Funktion aufgrund unterschiedlicher Datenquellen, die Daten aus den Klassenutzungsdaten 3860, den Workload-Eingaben 3862 (zum Beispiel Eingaben für die spezifische FaaS-Funktion) dem FaaS-Maschinenlern-Framework 3870 beinhalten, erstellt werden. Maschinenlernalgorithmen und/oder Systeme, die von einem FaaS-Maschinenlern-Framework 3870 erzeugt werden, können für weitere Verbesserung des benutzerdefinierten gemanagten Laufzeitsystem-Klassenladers 3850 verwendet werden, um die Ineffizienzen, die oben beschrieben sind, zu reduzieren und/oder zu eliminieren. Die Verbesserungen (zum Beispiel Beschleunigernutzung, spezifische Knotennutzung, Timing für Ausführung usw.) können zu dem benutzerdefinierten gemanagten Laufzeitsystem-Klassenlader 3850 bereitgestellt und als der Metadatendateilader 3856 gespeichert werden. Darüber hinaus kann das FaaS-Maschinenlern-Framework 3870 basierend darauf, ob die Verbesserungen an den Funktionen erfolgreich sind, geändert werden. Die Verbesserungen können zum Beispiel eine Änderung zukünftiger Ausführungen einer Funktion beinhalten. Falls die Änderungen die Effizienz auf eine irgendeine Art steigern (reduzierte Leistung, niedrigere Latenz, reduzierte Ressourcennutzung usw.), können die Änderungen als erfolgreich betrachtet werden, und das FaaS-Maschinenlern-Framework 3870 kann ähnliche solche Funktionen bei zukünftigen Aufrufen der Funktion sowie bei anderen Funktionen probieren. Falls die Änderungen nicht erfolgreich sind, kann das FaaS-Maschinenlern-Framework 3870 die Änderungen rückgängig machen und diese Änderungen nicht an andere Funktionen anwenden.

Das FaaS-Maschinenlern-Framework 3870 kann gemäß einer beispielhaften Ausführungsform kontinuierliche Anwendung sowohl chronologischen Feedbacks, das aus einer Historie einer Funktion entwickelt wird, als auch Cloud-Maßstab-Feedback, das aus großen Anzahlen von Aktivierungen der Funktion, die gleichzeitig und unabhängig auftreten, einverleibt werden. Auf diese Weise ergibt sich eine Form kontinuierlichen Lernens kombiniert mit Massenlemen. Das FaaS-Maschinenlern-Framework 3870 kann basierend auf den aktuellen Klassennutzungsdaten 3860, Workload-Eingaben 3862 und Metadaten aus dem Metadatendateilader 3856 sowie Daten aus dem Analysator 3854 trainieren.
Unter Bezugnahme auf 38B kann gemäß einer beispielhaften Ausführungsform bei Block 3810 des Verfahrens 3800 eine Analysatorfunktion während der anfänglichen Ausführung einer Funktion eines FaaS-Service aufgerufen werden. Bei Block 3820 können Nutzungsdaten als eine Metadatendatei zur darauffolgenden Ausführung der Funktion gespeichert werden. Bei Block 3840 kann die Metadatendatei für darauffolgende Aufrufe der Funktion geladen werden.
Ausführungsformen des Verfahrens 3800 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 3800 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 3800 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flashspeicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 3800 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Unter Bezugnahme auf 38C kann gemäß einer beispielhaften Ausführungsform bei Block 3852 des Verfahrens 3850 eine Analysatorfunktion während der anfänglichen Ausführung einer Funktion eines FaaS-Service aufgerufen werden. Bei Block 3854 kann ein Maschinenlern-Framework trainiert werden. Bei einigen Ausführungsformen kann das Maschinenlern-Framework basierend auf Metadaten, die von einem benutzerdefinierten gemanagten Laufzeitsystem-Klassenlader gespeichert werden, Klassennutzungsdaten und Workload-Eingaben, die mit der Funktion verbunden sind, trainiert werden.
Bei einigen Ausführungsformen kann der FaaS-Anbieter den Entwickler auffordern, ein besonderes Laufzeitsystem und/oder eine Bibliothek in dem FaaS-Einsatzpackage, das benutzerdefiniert hergestellt und/oder von einer Standardbibliothek und einem Laufzeitsystem für eine gegebene Sprache und/oder Laufzeit unterschiedlich sein kann, aufzunehmen. Bei einigen Ausführungsformen kann das vorgeschlagene Laufzeitsystem und/oder die Bibliothek von dem FaaS-Anbieter oder von Drittparteien bereitgestellt werden. Bei einigen Ausführungsformen kann ein benutzerdefiniertes Laufzeitsystem zusätzliche Informationen über die Ausführungsmerkmale der Funktionen dem Entwickler oder Benutzer bereitstellen (zum Beispiel Profilinformationen über die Codeausführungsmerkmale, wie Ausführungszeit, Zählungen ausgeführter Aussagen, Codedeckung, Strom-/Energieverbrauch, zugeordnete Speichermenge, Anzahl aufgetretener Ausnahmen oder Telemetriedaten über Mikroarchitekturereignisse, die mit der Codeausführung verbunden sind, einschließlich unter anderen der Anzahl falsch vorhergesagter Verzweigungsanweisungen, OS-Seitenfehler und Daten-Anweisung-Cache-Misses). Bei einigen Ausführungsformen kann die Verwendung benutzerdefinierter Laufzeiten in kürzerer oder längerer Ausführungszeit im Vergleich zu den Standardlaufzeiten resultieren. Insbesondere bei intelligenten benutzerdefinierten Laufzeitsystemen kann sich die Ausführung desselben Codes mit der Zeit verbessern, da die intelligente Laufzeit das typische Verhalten lernt und Vorverarbeitung und/oder vorwegnehmende Techniken, wie Raten und Prüfen auf schnellere Leistung verwenden könnte. Bei einigen Ausführungsformen können die Kosten der Ausführung desselben Codes mit der Zeit billiger werden, und diese Änderung kann für den Entwickler oder Benutzer durch die Verwendung von Kundendefinitionen der Laufzeit und/oder Bibliothek beobachtbar sein. Die intelligente Laufzeit kann daher die Ausführungsumgebung von Funktionen gemäß dem Benutzer definieren.
Ausführungsformen des Verfahrens 3850 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 3850 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 3800 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flashspeicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 3850 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 3801 beinhaltet ein Verfahren, das das Aufrufen einer Analysatorfunktion während einer ursprünglichen Ausführung einer Funktion eines FaaS-Service, das Speichern von Nutzungsdaten als eine Metadatendatei für darauffolgende Aufrufe der Funktion und das Laden der Metadatendatei für darauffolgende Aufrufe der Funktion beinhaltet, wobei mehrere Metadatendateien einer einzigen Funktion entsprechen.
Beispiel 3802 beinhaltet das Verfahren des Beispiels 3801, das ferner das Zurückfordern der Funktion basierend auf einer Ausführungsumgebung umfasst.
Beispiel 3803 beinhaltet das Verfahren des Beispiels 3802, das ferner das Umsetzen einer Sicherheitsstrategie in der Ausführungsumgebung umfasst.
Beispiel 3804 beinhaltet das Verfahren des Beispiels 3801, wobei einige Funktionssätze mit demselben MKTME-Schlüssel codiert werden sollen.
Beispiel 3805 beinhaltet ein Verfahren, das das Aufrufen einer Analysatorfunktion während einer ursprünglichen Ausführung einer Funktion eines FaaS-Service, das Speichern von Nutzungsdaten als eine Metadatendatei für darauffolgendes Ausgerufen der Funktion, das Laden der Metadatendatei für darauffolgende Aufrufe der Funktion, das Zurückfordern der Funktion basierend auf einer Ausführungsumgebung, und das Umsetzen einer Sicherheitsstrategie in der Ausführungsumgebung beinhaltet, wobei mehrere Metadatendateien der einzigen Funktion entsprechen, und wobei einige Funktionssätze mit demselben MKTME-Schlüssel codiert werden sollen.
Funktions-Resourcing-Beispiele
Eine der Schlüsselherausforderungen bei FaaS-Aktivierungen ist wendiges Ausgleichen von Ressourcen, während Effizienz maximiert wird und weit variierend QoS-konform ausgeführt wird. Anders als langlaufende Anwendungen oder kontinuierliche Mikrodienste, machen es die Ad-Hoc-, burstartigen und unvorhersehbaren Ankunftsraten von Anforderungen nach FaaS-Ausführungen schwierig, QoS-Erwartungen zu erfüllen, insbesondere falls die QoS-Erwartungen selbst von einer Funktion zu der anderen variieren.
Es kann schwierig sein, die benötigten Ressourcen unter Verwenden anderer Techniken (zum Beispiel RDT-Technologie) für einen Container vorab zu reservieren und diesem Container dann eine Funktion zuzuweisen, deren Erfordernisse nicht im Voraus bekannt sind. Ausführungsformen des verbesserten FaaS-Systems, wie in 4 gezeigt, werden folglich bereitgestellt, um den Ressourcenbedarf einer Funktion (zum Beispiel wie viel Cache-Kapazität, wie viel Speicher-BW usw.) zu identifizieren, der für einen Container, dem die Funktion zugewiesen wird, vorab reserviert werden sollte. Um diese Informationen zu erfassen, werden sowohl eine chronologische als auch ein Cloud-umfassender Historiemechanismus verwendet, durch die gelernt wird, was eine Funktion, die zuvor gelaufen ist, benötigt; und wobei diese Informationen dann verwendet werden können, um die RDT-Parameter durch das verbesserte FaaS-System einzustellen.
Gemäß einer beispielhaften Ausführungsform, die in 39A veranschaulicht, erleichtert ein FaaS-Framework 3910 das kontinuierliche Anwenden sowohl chronologischen Feedbacks 3912, das aus einer Historie einer Funktion 3920 entwickelt wird, als auch Feedback im Cloud-Maßstab (horizontal) 3914, das aus großen Anzahlen von Aktivierungen der Funktion 3930, die gleichzeitig und unabhängig auftreten, entwickelt wird. Auf diese Weise handelt es sich um eine Form kontinuierlichen Lernens, das mit Massenlernen kombiniert ist, das zur Laufzeit einer Funktion umgesetzt werden kann.
Unter Bezugnahme auf 39B, gemäß einer beispielhaften Ausführungsform, können die folgenden Bauelemente/Aspekte für jeden Funktionstyp 3950 bereitgestellt werden:

1. Ein QoS-Manifest-Vektor 3940 - beschreibt das besondere QoS-Gemisch, das als ein Vektor in einem multidimensionalen Raum von {LATENCY, THROUGHPUT, VARIABILITY, UTILIZATION, COST, etc.}, normalisiert auf eine gemeinsame Referenz wünschenswert ist, dass jeder QoS-Vektor Werte innerhalb einer Einheitssphäre Q annimmt, in der Daten derart dargestellt sind, dass Beziehungen unter Daten größen- oder maßstabinvariant sein können.
2. Ein entsprechender Ressourcen-Kostenvektor von Ressourcenkostenfunktionen {CPU CYCLES, MEM BW, IO BW, ... etc.} 3990, die ähnlich auf eine gemeinsame (maschinenneutrale) Referenz derart normalisiert sind, so dass die Kostenfunktionen (zum Beispiel Code-Routinen) Werte innerhalb einer Einheitssphäre C annehmen. Der benutzerdefinierte gemanagte Laufzeitsystem-Klassenlader 3850 der 38A kann mindestens eine Komponente des Ressourcenkostenvektors erzeugen. Der Metadatendateilader 3856 kann zum Beispiel den Vektor basierend auf der FaaS-Funktion identifizieren.
3. Ein mehrwertiger Erfüllungsfunktionsvektor G = {g1, g2, ... gN} 3960, der einen Vektor Q zu einem Satz von Vektoren in C abbildet, wo zum Beispiel mehrere unterschiedliche Vektoren g1(Q), g2(Q), ... gN(Q) von Q in C einen gegebenen Vektor Q erfüllen.
4. Sowohl C als auch Q können diskretisierte Versionen darunter liegender kontinuierlicher Domänen sein. Jeder G kann auch auf ein oberes Limit in N beschränkt sein, so dass eine beschränkte Anzahl von Variationen erfüllender Ressourcenzuweisungen, durch die gesucht werden muss, besteht.
5. Verfügbarkeitsvektor 3970, der den verfügbaren Subsatz von Ressourcen beschreibt, oder gleichwertig den verfügbaren Subsatz von Vektoren in C in einer gegebenen Zeitepoche.
6. Einen Sicherheitsvektor 3980, der auf QoS bezogen ist.

Der Erfüllungsfunktionsvektor G 3960 kann iterativ aus dem Anwenden lokaler Historien trainiert werden (oder lernen), in welchen gewünschte oder spezifische QoS durch bewertete Ressourcenausgaben erfüllt werden können. Die Ressourcenausgaben können durch Telemetrie zur Laufzeit innerhalb jedes Hosts oder Containers für eine gegebene Funktion verfügbar sein. Zusätzlich können sie auch durch Dazumischen von Erfüllungsfunktionen, die von anderen Hosts oder Containern in der Cloud trainiert werden, aktualisiert werden. Dieses Mischen kann gewichtet werden, so dass lokalen Historien größeres Gewicht gegenüber temporalen Eingaben von anderen Host gegeben wird; aber diese Gewichte können absichtlich mutiert werden, um evolutionäres Lernen zu erzielen. Mit der Zeit können diese Lösungen kontinuierliche Entwicklung der Ressourcenzuweisungen erlauben, die vorübergehenden Schwankungen, zum Beispiel auf transiente Anormalität bei Maschinen- und Softwareverhalten und intrinsische Nachfragevariationen zurückzuführen sind, standhalten. Insbesondere kann das Dazumischen von Erfüllungsfunktionen im Anwenden von Bin-Packing-Heuristiken (um am besten passende Erfüllungsvektoren auszuwählen) resultieren, während sie zu Cloud-Maßstab-Lernen verallgemeinert werden.
Noch weiter kann gemäß einer beispielhaften Ausführungsform ein Metsprachenbeschleuniger umgesetzt werden, um die Telemetrie in Zusammenhang mit den oben beschriebenen Vektoren zu aggregieren, um die Hostfunktionen auf spezifische Workloads zu bewerten. Es kann eine QoS-Spezifikation (zum Beispiel Manifest) für gewünschte QoS geben, und die Spezifikation kann Daten über den Mieter (zum Beispiel Softwareumsetzung, von welchen die Funktionen bedient werden, wie Datenbanksysteme, ein Bildverarbeitungsdienst usw.) beinhalten. Es kann eine automatische Art des Sammelns und Verarbeitens solcher Daten über Mieter geben. In einigen Fällen kann ein Dienst (zum Beispiel eine Datenbank) angeben, dass seine Metriken ignoriert werden sollten, wenn er zum Beispiel nicht standardgemäß arbeitet.
Gemäß einer beispielhaften Ausführungsform kann Latenz von Ende zu Ende über einige Funktionsanforderungen verfolgt werden, die Zeit ansammeln, während dieselbe Funktionsanforderung durch mehrere Servicephasen durchgeht. Funktionen können lokal geführt werden, falls Latenz-SLA Millisekunden-Latenz (ms-Latenz) erfordert. Eine beispielhafte Ausführungsform kann garantieren, dass man unter einer Schwellenlatenz bleibt, und kann für die Konstruktion von Verknüpfungen sorgen, die eine solche Schwellenlatenz sicherstellen können.
Unter Bezugnahme auf 39C ist ein Verfahren zum Vorabreservieren angemessener Ressourcen gemäß einer Ausführungsform veranschaulicht. Bei Block 3910 des Verfahrens 3900 kann ein Ressourcenbedarf einer Funktion identifiziert werden. Bei Block 3920 können Ressourcen in einem Container, dem eine Funktion zugewiesen ist, vorab basierend auf dem identifizierten Ressourcenbedarf reserviert werden. Bei Block 3930 können RDT-Parameter basierend auf dem identifizierten Ressourcenbedarf eingestellt werden.
Ausführungsformen des Verfahrens 3900 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 3600 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 3900 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flashspeicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 3900 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 3901 beinhaltet ein Verfahren, das das Identifizieren von Ressourcenbedarf einer Funktion, das Vorabreservieren von Ressourcen in einem Container, dem die Funktion zugewiesen wird, basierend auf dem identifizierten Ressourcenbedarf, und das Einstellen von RDT-Parametern basierend auf dem identifizierten Ressourcenbedarf umfasst.
Beispiel 3902 beinhaltet das Verfahren des Beispiels 3901, das ferner das Aufrufen eines Beschleunigers zum Bewerten einer Kostenfunktion für eine Workload der Funktion umfasst.
Beispiel 3903 beinhaltet das Verfahren des Beispiels 3901, das ferner das Konstruieren von Verknüpfungen zum Sicherstellen einer Mindestlatenz umfasst.
Beispiel 3904 beinhaltet das Verfahren nach Anspruch 3901, das ferner das Sicherstellen von QoS unter Verwenden mindestens eines Vektors umfasst.
Beispiel 3905 beinhaltet ein Verfahren, das das Identifizieren von Ressourcenbedarf einer Funktion, das Vorabreservieren von Ressourcen in einem Container, dem die Funktion zugewiesen ist, basierend auf dem identifizierten Ressourcenbedarf, das Einstellen von RDT-Parametern basierend auf dem identifizierten Ressourcenbedarf, das Aufrufen eines Beschleunigers zum Bewerten einer Kostenfunktion für spezifische Workloads, das Konstruieren von Verknüpfungen zum Sicherstellen einer Mindestlatenz und das Sicherstellen von QoS unter Verwenden mindestens eines Vektors umfasst.
Beispiele für verbesserte leichte profilgeführte Optimierung (Lightweight Profile-Guided Optimization - PGO)
Codeoptimierung kann für serverlose Ausführung kritisch sein, insbesondere, weil nicht-optimierter Code mit aufgeblähter Latenz und aufgeblähtem Fußabdruck behaftet ist, was direkt Kosten in dem FaaS-Paradigma gleichkommt. Der Großteil von Code in serverlosen Architekturen kann in dynamischer Sprache, wie node.js, python usw. gehalten sein. Während die PGO wichtige Hinweise zum Schaffen größerer nach Typ spezialisierter Compilerbereiche bereitstellen und daher das Typprüfen und Ausschütten von Werten aus Stapelregistern zum Speicher minimieren kann, kann ihre Verwendung bei serverlosem Rechnen durch CPU-Aufwänden bei ihrem Sammeln, Analysieren und Anwenden eingeschränkt werden und daher in Latenz resultieren.
Da die Kosten des Ausführens einer Funktion von der Ausführungszeit, die in Millisekunden gemessen wird, und von dem verwendeten Speicher abhängen, wird das Reduzieren der Latenz und des Code-Fußabdrucks in FaaS-Umgebungen sehr wichtig. Mit verbesserten PGO-Verfahren kann der Funktions-Source-Code zuerst kompiliert werden, und dann kann während der Ausführung ein dynamisches Profil angelegt werden. Das Profil kann verwendet werden, um diverse Optimierungen auszuführen und Code-Performance für zukünftige Funktionsausführung zu verbessern. Ein Profil kann für zukünftige Ausführung einer Funktion von Nutzen sein, da nicht bekannt ist, wie gut zukünftige Ausführung einer Funktion ausgeführt wird, oder ob zukünftige Ausführung einer besonderen Funktion tatsächlich ausgeführt wird. Dieser Prozess kann sehr zeitaufwändig sein, diese beispielhafte Ausführungsform kann die oben beschriebene Profilerzeugung unter Verwenden von Hardwareunterstützung für FaaS-Funktionen beschleunigen. Letzte Verzweigungsaufzeichnungen oder andere Hardware kann umgesetzt werden, um die oben erwähnten dynamischen Profile anzulegen. Das Anlegen der dynamischen Profile kann auch zum Teil unter Verwenden von Software oder Hardware-Software-Kombinationen angelegt werden.
Gemäß noch einer anderen Ausführungsform der verbesserten PGO-Verfahren können mit der Maschine verbundene Engpässe auf niedriger Ebene, die die Funktionsperformance verschlechtern, identifiziert werden. In FaaS-Umgebungen, da das darauffolgende Ausführen der Funktionen auf unterschiedlichen Maschinen erfolgen kann, kann das Verstehen von Maschinenabhängigkeiten auf niedriger Ebene sehr nützlich sein.
Gemäß noch einer anderen beispielhaften Ausführungsform des verbesserten PGO-Verfahrens können schließlich neue Optimierungen, die verbesserte PGO-Verfahren verwenden, hinzugefügt werden, um die Funktionslatenz zu reduzieren, wie das Vektorisieren der Array-Vorgänge (zum Beispiel bei Bildverarbeitungsfunktionen), Minimieren von Verzweigungsumlenkung und Kompaktieren, um in die schnelleren Caches zu passen.
Diverse Ausführungsformen der verbesserten PGO-Verfahren können auch die Erfassung von Anomalien unter Verwenden dynamischer Profilierungsfähigkeiten in FaaS-Laufzeit ermöglichen. Im Allgemeinen ist der Prozess des Anomalieerfassens der Prozess des Identifizierens anormaler Ereignisse. In dem Kontext von FaaS-Ausführungsumgebungen beinhalten beispielhafte Anomalieereignisse einen unzulässigen Anweisungsfehler, verbotenen Zugriff auf einen Speicherbereich, unausgereiften oder unerwarteten Funktionsausgang. Beim Erfassen von Anomalieereignissen berichten die verbesserten PGO-Verfahren der Fassung zu Performance-Analysetools des verbesserten FaaS-Systems zur weiteren Analyse. Ein Anomalieereignis kann zum Beispiel eine Funktion sein, die erwartet, dass bestimmte Dateien verfügbar sind, die in Wirklichkeit aber nicht verfügbar sind.
Unter Bezugnahme auf 40A kann es gemäß einer beispielhaften Ausführungsform mehrere Verbesserungen des verbesserten FaaS-Systems wie die geben, die in 4 gezeigt ist, die drei breite Kategorien zur Auseinandersetzung mit der oben beschriebenen Herausforderung in Zusammenhang mit Codeoptimierung 4050 beinhaltet:

1. Die erste Kategorie betrifft das Sammeln von sowohl hardwaregestützten Code als auch von Code, der automatisch mit der JIT (4060) exponiert ist.
2. Die zweite Kategorie kann es erleichtern, die Hauptprobleme zu identifizieren, die Codeausführung beeinträchtigen, zum Beispiel Herausabstrahieren von Unterschieden auf niedriger Ebene zwischen Maschinen-Performance-Daten, die von Maschine zu Maschine variieren (4070). Wenn eine Funktion auf einer besonderen Maschine ausgeführt wird und langsam läuft, können daher solche mit Maschinen-Performance-Daten verbundene Informationen angeben, dass die Trägheit darauf zurückzuführen ist, dass die Maschine nicht mit einer erwünschten Frequenz läuft, und nicht aufgrund irgendeiner Schwäche in der Funktion, die optimiert werden müsste.
3. Die dritte Kategorie umfasst mehrere Optimierungen oder Verbesserungen existierender FaaS-Lösungen:
- - Kompaktieren von Code in kleinste dynamische Cache- und TLB-Fußabdrücke (4080)
- - Minimieren von Verzweigungsumlenkung (4090)
- - Vektorisieren von Array-Vorgängen (4095)

TLBs sind performancekritische Strukturen zum Zwischenspeichern von Adressübersetzungsinformationen für Speicher eines Rechensystems. Hohe Raten von TLB-Misses sind für System und Funktionsperformance kostspielig. Ausführungsformen des verbesserten FaaS-Systems können Code auf eine Weise kompilieren, dass entweder TLB-Misses reduziert werden können oder TLB-Miss-Penalites reduziert werden können, zum Beispiel durch Kommunizieren von Informationen über beabstandete Zugriffsmuster unter CPU-Kernen und Verwenden von Prefetchern um zukünftige Referenzen vorherzusagen (so dass TLB-Misses nur Daten verlangsamen, die vorab geholt werden, die aber die Geschwindigkeit der tatsächlichen Ausführung nicht beeinträchtigen).
Auf ähnliche Weise optimieren Ausführungsformen des verbesserten FaaS-Systems Codekompilierung, so dass der kompilierte Code in einen kleineren, dynamischen Seitenfußabdruck gepasst werden kann (und daher den Raum, den er in einem Prozessor-Cache verbraucht, reduziert wird). Auf ähnliche Weise werden alle statischen Daten, die von dem Code berührt werden, auch kontaktiert, so dass statistische Daten, auf die häufig zugegriffen wird, ortsgleich sind. Die Ausführungsformen des verbesserten FaaS-Systems analysieren eine Ausführungshistorie einer Funktion unter unterschiedlichen Compiler-Optionen und gesammelten Cache-Statistiken, um diejenigen kompilierten Codeteile (zum Beispiel diejenigen Code-Module) auszuwählen, die niedrige temporale Lokalität aufweisen und sie in einen Teil des Adressraums der Funktion zu platzieren, der von den restlichen Teilen des Codes unterschiedlich ist, um LI-Anweisung-Cache-Treffer zu verbessern; und auf ähnliche Weise diverse Datenobjekte zusammenbringen, auf die häufiger zugegriffen wird, oder auf die gleichzeitig zugegriffen wird, so dass die L1-Daten-Cache-Treffer verbessert werden können. Solches Kompaktieren reduziert auch die mittlere Anzahl virtueller Adressen (für Anweisungen und Datenseiten), auf die gleichzeitig zugegriffen wird, so dass die TLB-Trefferraten in dem verbesserten FaaS-System verbessert werden.
Verzweigungsumlenkung verweist auf einen Prozess des Umlenkens eines Anweisungsholers zu dem richtigen Ziel, falls der Anweisungsaufrufer früher zu einem falschen Verzweigungsziel ging. Der Branch Target Buffer (BTB) zum Beispiel ist eine Cache-ähnliche Struktur, die von dem verbesserten FaaS-System verwendet werden kann, um zuvor gesehene Verzweigungen nachzusehen. Eine Anzahl von Bits des aktuellen Programmzählers, die von dem BTB bereitgestellt wird, enthält Informationen über potenzielle Verzweigungen. Wenn das Erraten einer potenziellen Verzweigung falsch ist, geht der Anweisungsaufrufer zu einem falschen Verzweigungsziel; wenn ein solches falsches Verzweigungsziel einmal gefunden ist, muss der Anweisungsaufrufer zu dem richtigen Ziel umgelenkt werden. Durch Verwenden des verbesserten FaaS-Systems kann solche Verzweigungsumlenkung minimiert werden. Ein Compiler kann viele unterschiedliche Techniken zum Reduzieren von Verzweigungsumlenkung verwenden: Bei einem Beispiel kann ein Compiler die Richtung einer Verzweigung ändern, so dass die häufig eingeschlagene Verzweigung für die BTB einfacher als eingeschlagen vorherzusagen ist (gewöhnlich ist eine Rückwärtsverzweigung leichter als eingeschlagen vorherzusagen als eine Vorwärtsverzweigung); bei einem anderen Beispiel kann ein Compiler Vorhersagehinweise als Präfixe in der Verzweigungsanweisung basierend auf den bewerteten Profilinformationen verwenden.
Ausführungsformen des verbesserten FaaS-Systems können Funktionsausführungen durch Vektorisieren von Array-Vorgängen weiter optimieren. Die Ausführungsformen des verbesserten FaaS-Systems können zum Beispiel einen Vektorisierungscompiler einsetzen, um Schleifenvorgänge in eine Abfolge von Vektorvorgängen umzuwandeln. Solche Vektorisierung/Umwandlung erlaubt es dem verbesserten FaaS-System, einen Vorgang auf mehreren Paaren von Operanden gleichzeitig zu verarbeiten, so dass die Performance der Leistungsausführung verbessert wird.
Ausführungsmerkmale, die von der ersten Kategorie extrahiert und von der zweiten Kategorie von Verbesserungen übersetzt werden, können auch zum Treiben orthogonaler Werte, wie Aktivieren von Just-in-Time-QoS, Sicherheit und Dauerhaftigkeit mit Informationsarchitektureindeutigkeit (IA-Eindeutigkeit) wie RDT, SGX und 3DXP verwendet werden.
Unter Bezugnahme auf 40B kann gemäß einer beispielhaften Ausführungsform bei Block 4010 des Verfahrens 4000 Funktionsquellcode kompiliert werden. Bei Block 4020, während der Ausführung des kompilierten Quellcodes, kann ein dynamisches Profil in Zusammenhang mit der Funktion angelegt werden. Bei Block 4040 können neue Optimierungen basierend auf dem angelegten dynamischen Profil angelegt werden, um Funktionslatenz zu reduzieren.
Ausführungsformen des Verfahrens 4000 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 4000 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 4000 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flashspeicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 4000 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 4001 beinhaltet ein Verfahren, das das Kompilieren von Quellcode einer Funktion, während der Ausführung des kompilierten Quellcodes, das Anlegen eines dynamischen Profils in Zusammenhang mit der Funktion, und das Anlegen neuer Optimierungen basierend auf dem angelegten dynamischen Profil beinhaltet, um Funktionslatenz zu reduzieren.
Beispiel 4002 beinhaltet das Verfahren nach Beispiel 4001, das weiter das Erfassen von Anomalien unter Verwenden dynamischer Profilierungsfähigkeiten in FaaS-Laufzeit umfasst.
Beispiel 4003 beinhaltet das Verfahren des Beispiels 4002, das weiter das Berichten von Resultaten des Erfassens zu Performance-Analysetools umfasst.
Beispiel 4004 beinhaltet das Verfahren des Beispiels 4001, das weiter das Behalten einer Profilabbildung über einen Orchestrator umfasst.
Beispiel 4005 beinhaltet ein Verfahren, das das Identifizieren von Ressourcenbedarf einer Funktion, das Vorabreservieren von Ressourcen in einem Container, dem die Funktion zugewiesen ist, basierend auf dem identifizierten Ressourcenbedarf, das Einstellen von RDT-Parametern basierend auf dem identifizierten Ressourcenbedarf, das Aufrufen eines Beschleunigers zum Bewerten einer Kostenfunktion für spezifische Workloads, das Konstruieren von Verknüpfungen zum Sicherstellen einer Mindestlatenz, das Sicherstellen von QoS unter Verwenden mindestens eines Vektors, das Erfassen von Anomalien unter Verwenden dynamischer Profilierungsfähigkeiten in FaaS-Laufzeit, dass Neuposten von Resultaten des Erfassens zu Performance-Analysetools, das Behalten einer Profilabbildung über einen Orchestrator umfasst.
Beispiele für dokumentierte Fingerabdrücke
Funktionen können unterschiedliche Merkmale während ihrer Ausführung darlegen und Ressourcen wie CPU, Speicher, Netzwerk usw. mit unterschiedlichen Raten verwenden. Das Verstehen dieser Merkmale und ihr Assoziieren mit Funktionen (als ihre Nachfragefingerabdrücke) ist für effiziente Ressourcenzuordnung und Planung wichtig. Ein beispielhafter Nachfragefingerabdruck ist in 41D gezeigt. Nachfragefingerabdrücke können jedoch nicht ohne Weiteres ohne erhebliches vorheriges Experimentieren erhalten werden, viele Funktionen können mehrmals im Verlauf von Tagen, Wochen, Monaten ausgeführt werden.
Gemäß einer beispielhaften Ausführungsform des verbesserten FaaS-Systems, wie des einen in 4 gezeigten, wird ein Prozess zum automatischen Erzeugen eines ausführlichen Berichts über die Verwendung unterschiedlicher Ressourcen bei diversen Stufen der Funktionsausführung und Erzeugen des Nachfragefingerabdrucks auf dieser Basis über mehrere Ausführungen bereitgestellt. Einige Ausführungsformen (zum Beispiel CPU) könnten beim Starten der Funktion intensiv genutzt werden, und einige andere Ressourcen (zum Beispiel Speicher, Caches) könnten während des späteren Teils intensiv genutzt werden. Eine Funktion kann schließlich auch andere Funktionen aufrufen. Ein solcher ausführlicher Bericht kann FUNKTIONSCHRONIK genannt werden. Mit der Zeit, wie in 41A gezeigt, können mit jeder Ausführung der Funktion diverse Performance-, Leistungs- und Skalierungsmerkmale oder Sensibilitäten der Funktion erhalten und eine reichhaltige Historie in einen ausgereiften NACHFRAGEFINGERABDRUCK gebildet werden. Wie in 41B veranschaulicht, können die NACHFRAGEFINGERABDRUCK-Informationen verwendet werden, um Funktionen zu planen und Ressourcen zu den Funktionen für ein effizientes Ressourcenmanagement über einen Ressourcenmanager 4110 zuzuordnen, der in einem Orchestrator oder Server eines CSP umgesetzt werden kann, verwendet werden. Nachfragefingerabdrücke können mit Funktionsaufrufketten, mit Ursprungsaufrufer (spezifischer Client) und mit Werten spezifischer Parameter von Funktionsaufrufen verbunden sein.
Gemäß einer beispielhaften Ausführungsform, die in 41B gezeigt ist, kann ein NACHFRAGEFINGERABDRUCK in dem Zeitpunkt der Funktionsanlegung angelegt werden, und kann eventuell nur die Einzelheiten in Zusammenhang mit den Funktionsparametern, wie Speicheranforderungen und Timeouts, beinhalten. Während der Funktionsausführung kann der diverse Ressourcenverbrauch (zum Beispiel CPU, Speicher) aufgezeichnet werden. Am Ende der Funktionsausführungen können unterschiedliche Ressourcennutzungsmuster abgeleitet werden, wie, dass die Funktion CPU-/speicher-/netzwerkintensiv ist oder die besonderen Stufen, wenn die Funktion ausgeführt wird, die CPU-/speicherintensiv sind. Mit mehreren Funktionsausführungen wächst der NACHFRAGEFINGERABDRUCK und mehr (präzisere) Informationen in Zusammenhang mit dem Ressourcennutzungsmuster der Funktion können erhalten werden. Der NACHFRAGEFINGERABDRUCK kann zur Ressourcenplanung für weitere Ausführung der Funktionen verwendet werden. In dem Fall einer Funktionsverkettung, kann der Ressourcenmanager 4110 die Ressourcen auf das Ausführen der verketteten Funktionen vorab durch Zuordnen von Ressourcen (CPU, Speicher) basierend auf dem NACHFRAGEFINGERABDRUCK der verketteten Funktionen vorbereiten.
Unter Bezugnahme auf 41C können gemäß einer beispielhaften Ausführungsform bei Block 4120 des Verfahrens 4100 Ressourcenmerkmale mit ausgeführten Funktionen verbunden werden, um Nachfragefingerabdrücke der ausgeführten Funktionen an jeder Ausführungsstufe zu erzeugen. Bei Block 4130 kann zum Beispiel ein Orchestrator (nicht gezeigt) ausführliche Berichte über die Nutzung unterschiedlicher Ressourcen an mehreren Ausführungsstufen der Funktionen erzeugen. Bei Block 4140 kann die Ausführung von Funktionen geplant werden, und Ressourcen können den Funktionen basierend auf den erzeugten Berichten zugeordnet werden.
Ausführungsformen des Verfahrens 4100 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 4100 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 4100 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flashspeicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 4100 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 4101 beinhaltet ein Verfahren, das das Assoziieren von Ressourcenmerkmalen mit ausgeführten Funktionen umfasst, um Nachfragefingerabdrücke der ausgeführten Funktionen bei jeder Ausführungsstufe zu erzeugen, über einen Orchestrator ausführliche Berichte über die Nutzung unterschiedlicher Ressourcen bei unterschiedlichen Ausführungsstufen der Funktionen zu erzeugen, die Ausführung der Funktionen zu planen und den Funktionen Ressourcen basierend auf den erzeugten Berichten zuzuordnen.
Beispiel 4102 kann das Verfahren des Beispiels 4101 beinhalten, das ferner das Erzeugen der Nachfragefingerabdrücke in Verbindung mit Parametern der Funktionen und einem Mieter, der die Funktionen aufruft, umfasst.
Beispiel 4103 kann das Verfahren des Beispiels 4104 beinhalten, das ferner das Umsetzen eines Abfolgeanalysemaschinenlernmodells, um die Nachfragefingerabdrücke zu erzeugen.
Beispiel 4104 beinhaltet ein Verfahren, das das Assoziieren von Ressourcenmerkmalen mit ausgeführten Funktionen umfasst, um Nachfragefingerabdrücke der ausgeführten Funktionen bei jeder Ausführungsstufe zu erzeugen, über einen Orchestrator ausführliche Berichte über die Nutzung unterschiedlicher Ressourcen bei unterschiedlichen Ausführungsstufen der Funktionen zu erzeugen, die Ausführung der Funktionen zu planen und den Funktionen Ressourcen basierend auf den erzeugten Berichten zuzuordnen, das Erzeugen der Nachfragefingerabdrücke in Verbindung mit Parametern der Funktionen und einem Mieter, der die Funktionen aufruft, und das Umsetzen eines Abfolgeanalysemaschinenlernmodells zum Erzeugen der Nachfragefingerabdrücke.
Framework-Verfahren und Mittel zum Automatisieren von Deep-Profiling
Die gegenseitige Opazität einer Funktion und ihrer dazu gehörenden Ausführungsmaschinen (wie Container und/oder Hosting-Mittel), in welchen sie ausgeführt werden, führt erhebliche Herausforderungen in das Profiling, Debugging, Auditing und Optimieren ihrer Ausführung ein. Eine beispielhafte Ausführungsform des verbesserten FaaS-Systems, wie die eine in 4 gezeigte, stellt Verfahren bereit, von welchen einige hardwareunterstützt sein können, um das Verfolgen der Performance einer Funktion und das Integrieren der Informationen, die von der Ausführungsmaschine erhalten werden, zu vereinfachen. Bei dieser Integration können Einzelheiten der Hosting-Maschine/des Containers oder der Plattform zweckdienlich davor geschützt werden, enthüllt zu werden, um das gewünschte Niveau an Ausführungsmaschinentransparenz zu erzielen, und das architekturneutrale Verhalten einer Funktion kann profiliert, verfolgt und für Debugging, Tuning und Auditieren von Zielsetzungen zeitlich abgestimmt werden.
Unter Bezugnahme auf 42A beinhaltet ein verbessertes FaaS-Framework eine virtuelle Profiling-API 4250, über die eine Client-Funktionen 4260 einen zeit- oder ereignisbetonten Verlauf gemeinsam mit Markern 4270 (zum Beispiel Indices oder Daten-Handles) erhalten kann. Der zeit- oder ereignisbetonte Verlauf kann mit Ereignissen angemerkt werden, die während der Sammlung des Verlaufs (zum Beispiel Interrupt oder anderer Signale, Timeouts, Seitenfehler usw.) aufgetreten sind, und wann sie aufgetreten sind in feinen Zeiteinheiten, beginnend mit der Ausführung der Funktion. Die opaken Marker 4270 können einer Ausführungsmaschine 4280 präsentiert werden, um diverse normalisierte aggregierte Messdaten 4290 aus der Ausführungsumgebung 4280 je nach Grad der Durchsichtigkeit, die zwischen dem Funktions-Client 4260 und dem Ausführungs-Anbieter vereinbart wird, zu erhalten. Die opaken Marker 4270 können das Referenzieren von Informationsobjekten ermöglichen, ohne dass der Referencer auf den Inhalt oder die Struktur der referenzierten Objekte zugreift.
Die opaken Marker 4270 können für ein zweckdienlich privilegiertes Tool eine Art bereitstellen, diverse Statistiken zu empfangen, die sich auf Infrastrukturebene befinden, und die folglich für die Ausführungsfunktion (die auf einer niedrigeren Privilegebene läuft) nicht verfügbar sind. Auf diese Weise können die Plattformebenenereignisse oder Statistiken zweckdienlich gefiltert oder zu einigen Referenzeinheiten und dann in den Verlauf gemischt werden. Ein opaker Marker 4270 kann zum Beispiel später in „CPU eintrat in Turbofrequenz G im Zeitpunkt 0x12345 ein“ oder „Speicherfehler erfasst und korrigiert im Zeitpunkt 0x56789 aufgrund einer thermischen Auslösung“ übersetzt werden.
Aggregierte Messdaten können erhalten werden, um das Verhalten eines Systems und einer Funktion gemeinsam zu analysieren und charakterisieren, da es im Allgemeinen nicht nötig ist, alles in dem System im kleinsten Detail zu kennen. Es kann zum Beispiel ausreichen zu wissen, dass Seitenfehler mit einer mittleren Frequenz X aufgetreten sind, oder dass das System ein thermisches Ereignis erfahren hat oder kein thermisches Ereignis während einer Zeitspanne, während der eine Funktion ausgeführt wurde, aufgetreten ist. Das Erhalten einer vollständigen Messfolge kann gemäß einer beispielhaften Ausführungsform ausgeführt werden, obwohl das in einigen Instanzen sowohl zu enthüllend als auch zu kostspielig zu speichern und später zu analysieren ist. Die aggregierten Messdaten, die von der Funktionsausführungsmaschine 4280 erhalten werden, können ferner zur verbesserten Ausführung der Analyse der erhaltenen aggregierten Messdaten normalisiert werden. Die normalisierten aggregierten Messdaten 4290 können Software-Metriken, wie Auslagerungsnutzung und Hardware-Metriken, wie L1-Cache-Misses, beinhalten.
Das virtuelle Profiling kann zur Laufzeit auftreten und kann von dem Container, der die Funktion ausführt, vorgenommen werden. Der erzeugte Verlauf beinhaltet eine Sammlung von Hardware- und Software-Metriken im Verlauf der Ausführung der Funktion und kann auch basierend auf den unterschiedlichen Ereignissen, die während der Funktionsausführungen oder Funktionsverkettung auftreten, klassifiziert werden. Die opaken Marker 4270 können von der Containerschicht, der Schicht der virtuellen Maschine oder der Hardwareschicht erzeugt werden. Optionale Hardwareerweiterungen stellen direkten Zugriff auf eine direkte Leistungsmanagementeinheitsfähigkeit (Power Management Unit - PMU-Fähigkeit) für abstrahierte aber wendige Selbstcharakterisierung von innerhalb einer Funktion bereit.
Unter Bezugnahme auf 42B kann gemäß einer beispielhaften Ausführungsform eine Funktion bei Block 4210 des Verfahrens 4200 einen zeit- oder ereignisbetonten Verlauf gemeinsam mit opaken Marken erhalten. Bei Block 4220 können die opaken Marker einer Ausführungsmaschine der Funktion, wie einem Container, der die Funktion ausführt, präsentiert werden, um aggregierte Messungen aus der Ausführungsumgebung zu erhalten. Bei Block 4240 kann der Funktion direkter Zugriff auf eine virtuelle PMU bereitgestellt werden.
Ausführungsformen des Verfahrens 4200 können in einem System, Gerät, Computer, einer Vorrichtung usw., zum Beispiel wie den hierin beschriebenen, umgesetzt werden. Insbesondere können Hardware-Umsetzungen des Verfahrens 4200 konfigurierbare Logik beinhalten, wie zum Beispiel PLAs, FPGAs, CPLDs oder Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder eine beliebige Kombination davon. Alternativ oder zusätzlich kann das Verfahren 4200 in einem oder mehreren Modulen eines Satzes von Logikanweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie Direktzugriffsspeicher (Random Access Memory - RAM, Nurlesespeicher (Read-Only Memory - ROM), programmierbarem ROM (PROM), Firmware, Flashspeicher usw. gespeichert sind, umgesetzt werden, um von einem Prozessor oder einem Rechengerät ausgeführt zu werden. Computerprogrammcode zum Ausführen der Vorgänge der Bauelemente kann zum Beispiel in einer beliebigen Kombination einer oder mehrerer OS anwendbarer/zweckdienlicher Programmiersprachen, einschließlich einer objektorientierten Programmiersprache, wie PYTHON, PERL, JAVA, SMALLTALK, C++, C# oder dergleichen und herkömmlichen prozeduralen Programmiersprachen, wie der „C“-Programmiersprache, oder ähnlichen Programmiersprachen, geschrieben werden.
Ausführungsformen oder Abschnitte des Verfahrens 4200 können in Firmware, Anwendungen (zum Beispiel durch eine Anwendungsprogrammierschnittstelle (API)) oder Treibersoftware, die auf einem Betriebssystem (OS) läuft, umgesetzt werden. Zusätzlich könnten logische Anweisungen Assembler-Anweisungen, Instruction-Set-Architecture-Anweisungen (ISA-Anweisungen), Maschinenanweisungen, maschinenabhängige Anweisungen, Mikrocode, Zustandseinstelldaten, Konfigurationsdaten für integrierte Schaltungen, Zustandsinformationen, die elektronische Schaltungen und/oder andere Strukturbauelemente, die für Hardware nativ sind (zum Beispiel Host-Prozessor, Zentraleinheit/CPU, Mikrocontroller usw.) personalisieren, beinhalten.
Zusätzliche Anmerkungen und Beispiele
Beispiel 4201 beinhaltet ein Verfahren, das das Erhalten über eine Funktion eines zeit- oder ereignisbetonten Verlaufs der Funktion und opaker Marker, das Präsentieren der opaken Marker bei der Ausführungsmaschine verbunden mit der Funktion, um Informationen über die Funktion aus der Ausführungsmaschine zu erhalten, und das Bereitstellen der Funktion mit direktem Zugriff auf ein oder mehrere Hardware-Bauelemente beinhalten, wobei die opaken Marker Datenobjekte referenzieren sollen, ohne irgendeinen Zugriff auf den Inhalt oder die Struktur der Datenobjekte zu erhalten.
Beispiel 4202 beinhaltet das Verfahren des Beispiels 4201, das ferner das Speichern signierter Daten in eine Enklave, die zu einer vertrauenswürdigen Entität zu liefern ist, umfasst.
Beispiel 4203 beinhaltet das Verfahren des Beispiels 4201, das ferner Verschlüsselungssystemtelemetrie umfasst, die in Zusammenhang mit den opaken Markern erfasst wird, wobei die Verschlüsselung unter Verwenden anwendungsspezifischer Einstellungen ausgeführt werden soll.
Beispiel 4204 beinhaltet das Verfahren des Beispiels 4201, das ferner das Erzeugen eine API zur Anwendung zum Bestimmen von Profilierungspunkten unabhängig von der Ausführungsumgebung umfasst.
Beispiel 4205 beinhaltet das Verfahren des Beispiels 4201, das ferner das Entkoppeln von Privilegien von der Funktion und Profiling-Daten umfasst.
Beispiel 4206 beinhaltet das Verfahren des Beispiels 4201, das ferner das Managen von sicheren Punkten zum Einsetzen von Tabs/Token umfasst.
Beispiel 4207 beinhaltet ein Verfahren, das das Erhalten über eine Funktion, eines zeit- oder ereignisbetonten Verlaufs und opaker Marker, das Präsentieren der opaken Marker bei einer Ausführungsmaschine, um Informationen aus der Ausführungsmaschine zu erhalten, das Bereitstellen direkten Zugriffs auf eine virtuelle Leistungsmanagementeinheit für die Funktion, das Speichern signierter Daten in eine Enklave, die zu einer vertrauenswürdigen Entität geliefert werden soll, das Verschlüsseln einer erfassten Seite, die anwendungsspezifische Einstellung verwendet, das Erzeugen einer API zur Anwendung zum Bestimmen von Profilingpunkten unabhängig von der Ausführungsumgebung, das Entkoppeln von Privilegien von der Funktion und Profilingdaten und das Managen sicherer Punkte zum Einsetzen von Tabs/Token umfasst.
Serverauswahl zur Funktionsausführung
Unter Bezugnahme auf 43A ist ein Beispiel gezeigt, bei dem das Sessionzustandsmanagement von einem Benutzeroberflächen-Handler 4300 (zum Beispiel einem API-Proxy, wie zum Beispiel API GATEWAY) eines verbesserten FaaS-Systems gehandhabt wird. Bei dem veranschaulichten Beispiel erzeugt der Benutzeroberflächen-Handler 4300 ein Token 4302 (zum Beispiel Daten-„Moniker“), das einen Funktionskontextidentifikator (ID) 4304 beinhaltet. Die Funktionskontext-ID 4304 identifiziert einen Kontext 4316 einer Funktion, die mit einer eingehenden Anforderung 4306 zum Ausführen der Funktion verbunden ist, eindeutig. Insbesondere können der Funktion optionale Felder zugewiesen werden, die den Kontext 4316 als eine ungefähre Darstellung der Identität eines Datensatzkonstrukts beschreiben. Bei einem Beispiel ist das Token 4302 durch eine Moniker-Konstruktion-API des Benutzeroberflächen-Handler 4300 konstruiert, die zum Beispiel eine Set Function (zum Beispiel ein Bloom-Filter) verwendet, die über diverse universell eindeutige IDs (Universally Unique IDs-UUIDs), die Quelle der Anforderung 4306 (zum Beispiel Aufrufe der Funktion in einer anwendungsdefinierten Funktionsabbildungslösung), spezifische Parameter der Funktion, Dateisystem-Pfadnamen, Resilient Distributed Dataset-Lineages (RDD-Lineages) (zum Beispiel in APACHE SPARK), Tablespace-Bereiche in relationalen Datenbanken und so fort angewandt wird.
Bei dem veranschaulichten Beispiel wählt ein Orchestrator 4308 einen Serverstandort basierend auf dem Token 4302 (und potenziell anderen Faktoren, die ausführlicher zu besprechen sind) aus und transferiert das Token 4302 gemeinsam mit einem Funktionsaufruf 4310 zu dem ausgewählten Serverstandort. Bei dem veranschaulichten Beispiel werden der Funktionsaufruf 4310 und das Token 4302 zu einem ersten Server 4312 transferiert, der einen lokalen Cache 4314 beinhaltet, der den Kontext 4316 enthält, wobei der Kontext 4316 das Abrufen von Zustandsdaten (zum Beispiel Genehmigungen, Authentifizierungszustand, transaktionsbezogene Daten usw.) durch die Funktion erleichtert. Die veranschaulichte Lösung ermöglicht folglich, dass das Berechnen zu den Daten, die während der Funktionsausführungen verwendet werden, gepusht wird. In diesem Hinblick wird effizienteres Abrufen von Zustandsdaten erzielt, weil der Kontext 4316 lokal zwischengespeichert ist (wobei zum Beispiel Funktionsverarbeitungsanforderungen mit demselben Zustand auf Anfrage angelegt werden, wenn funktionsspezifische Affinität durchgesetzt wird).
Der Serverstandort kann basierend auf zusätzlichen Faktoren ausgewählt werden. Relative Standortkosten (zum Beispiel die Kosten von Datentransfer/Bandbreite zu dem Standort, das Speichern von Daten an dem Standort und/oder das Verarbeiten von Daten an dem Standort) des ersten Servers 4312, eines zweiten Servers 4318, eines dritten Servers 4320 und so fort, können den Transfer der des Funktionsaufrufs 4310 und das Token 4302 an einen anderen Ort vorschreiben. Bei noch einem anderen Beispiel wählt der Orchestrator 4308 den Serverstandort basierend auf einer Dienstgüteanforderung (QoS-Anforderung) (zum Beispiel Zuverlässigkeit, Verarbeitungsgeschwindigkeit usw.) aus. In einem solchen Fall könnten der Funktionsaufruf 4310 und das Token 4302 zu dem zweiten Server 4318 transferiert werden, falls der zweite Server 4318 fähig ist, die QoS-Anforderung zu erfüllen, und der erste Server 4312 nicht fähig ist, die QoS-Anforderung zu erfüllen.
Bei noch einem anderen Beispiel wählt der Orchestrator 4308 den Serverstandort basierend auf einem Hash-Resultat einer vorhergehenden Ausführung der Funktion aus. Insbesondere, falls $D a t a I D 2 = h a s h (f n (D a t a I D 1)$
Wenn fx(DataID2) aufgerufen wird, kann der Orchestrator 4308 entscheiden, ob DataID2 oder die Funktion fx() bewegt werden soll.
Der Serverstandort kann auch ein Knoten sein, zu dem die Daten registriert werden (zum Beispiel über Verarbeitung zweiten und dritten Ranges verbraucht werden). Bei weiteren Beispielen wird der Serverstandort basierend auf einer Historie (zum Beispiel Zeit-/temporale Historie), die mit der Funktion verbunden ist, der Anforderungsquelle und/oder einem Funktionsaufrufbaum (das heißt einer Abfolge von Aufrufen, die die Funktion, die geplant wird, beinhalten) ausgewählt.
Die veranschaulichte Lösung verbessert das FaaS-System mit Ereignisorientierung in dem Maß, dass der Funktionsaufruf 4310 auf Anfrage als Reaktion auf die Anforderung 4306 erzeugt wird. Zusätzlich verbessert die veranschaulichte Lösung das FaaS-System mit minimaler Verwaltung, weil die Auswahl des Serverstandorts von dem Benutzer weg abstrahiert wird. Darüber hinaus wird das FaaS-System mit hoher Skalierbarkeit verbessert, weil der Funktionsaufruf 4310 automatisch mit der Anzahl von Anforderungen 4306 skaliert. Zusätzlich verbessert die veranschaulichte Lösung das FaaS-System mit einer atomaren Skalierungseinheit in dem Maßstab, dass die Funktion der Recheneinheitsmaßstab ist. Die veranschaulichte Lösung ermöglicht es Kunden auch, nur zu bezahlen, wenn der Funktionsaufruf 4310 läuft, und verleiht folglich dem FaaS-System feine Auflösung. Zusätzlich reduziert die veranschaulichte Lösung einen Bedarf an Behalten des Kontexts 4316 in einer Datenbank, was ansonsten das Abrufen des Kontexts 4316 weniger effizient machen würde.
Unter Bezugnahme auf 43B ist ein Verfahren 4322 zum Managen von Funktionsaufrufen gezeigt. Das Verfahren 4322 kann im Allgemeinen in einem verbesserten FaaS-System, wie zum Beispiel dem System 202 (2), dem System 300 (3), und/oder dem System 400 (4), die bereits besprochen wurden, umgesetzt werden. Insbesondere kann das Verfahren 4322 in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 4324 stellt das Erzeugen eines Token bereit, das einen Kontext einer Funktion, die mit einer eingehenden Anforderung zum Ausführen der Funktion verbunden ist, eindeutig identifiziert. Die eingehende Anfrage kann ein Auslöser sein, wie zum Beispiel ein IoT-Ereignis und/oder ein FaaS-Ereignis, wie eine Benutzeranforderung zum Ausführen einer Funktion, die von dem Benutzer entwickelt wurde. Bei einem Beispiel wird Block 4324 von einem Benutzeroberflächen-Handler ausgeführt, wie zum Beispiel von dem Benutzeroberflächen-Handler 4300 (43A), der bereits besprochen wurde. Bei Block 4326 wird basierend auf dem Token ein Serverstandort ausgewählt, wobei der veranschaulichte Block 4328 die Funktion an dem ausgewählten Serverstandort aufruft. Bei dem veranschaulichten Beispiel erleichtert der Kontext ein Abrufen von Zustandsdaten durch die Funktion (die Funktion holt zum Beispiel die Zustandsdaten von dem Kontext). Die Blöcke 4326 und 4328 können von einem Orchestrator, wie zum Beispiel dem Orchestrator 4308 (43A), der bereits besprochen wurde, geleitet werden. Das veranschaulichte Verfahren 4322 verbessert folglich das FaaS-System hinsichtlich der Ereignisorientierung, minimaler Verwaltung, hoher Skalierbarkeit, atomarer Recheneinheit und feiner Abrechnung. Zusätzlich reduziert das veranschaulichte Verfahren 4322 einen Bedarf zum Behalten des Kontextes in einer separaten Datenbank und das Zugreifen darauf jedes Mal, was aufgrund der zusätzlichen Latenz von Fernzugriffen weniger effizient wäre.
43C zeigt ein ausführlicheres Verfahren 4330 zum Managen von Funktionsaufrufen. Das Verfahren 4330 kann im Allgemeinen in einem verbesserten FaaS-System, wie zum Beispiel dem System 202 (2), dem System 300 (3), und/oder dem System 400 (4), die bereits besprochen wurden, umgesetzt werden. Insbesondere kann das Verfahren 4330 in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 4332 stellt das Erzeugen eines Token bereit, das einen Kontext einer Funktion, der mit einer eingehenden Anforderung zum Ausführen der Funktion zusammenhängt, eindeutig identifiziert. Die eingehende Anforderung kann ein Auslöser sein, wie zum Beispiel ein IoT-Ereignis und/oder ein FaaS-Ereignis. Bei einem Beispiel wird Block 4332 von einem Benutzeroberflächen-Handler ausgeführt, wie zum Beispiel von dem Benutzeroberflächen-Handler 4300 (43A), der bereits besprochen wurde. Ein Serverstandort wird bei Block 4334 basierend auf dem Token und einer oder mehreren einer Zeithistorie, die mit der Funktion verbunden ist, einer Anforderungsquelle, einem Funktionsaufrufbaum, Standortkosten, einer QoS-Anforderung oder einem Hash-Resultat einer vorhergehenden Ausführung der Funktion ausgewählt. Bei dem veranschaulichten Beispiel wird der Serverstandort ausgewählt, um einen lokalen Cache zu beinhalten, der den Kontext oder einen Standort enthält, der die Performance, QoS-Anforderung oder die Datenaffinität zum Ausführen der Funktion maximiert. Der Serverstandort kann auch ein Knoten sein, zu dem die Daten registriert werden (zum Beispiel über Verarbeitung zweiten und dritten Ranges verbraucht werden).
Block 4336 ruft die Funktion an dem ausgewählten Serverstandort auf, wobei der Kontext ein Abrufen von Zustandsdaten durch die Funktion erleichtert. Der ausgewählte Serverstandort wird zu der Zeithistorie, die mit der Funktion verbunden ist, bei Block 4338 gespeichert. Die Zeithistorie kann daher dazu verwendet werden, zukünftige Serverstandortentscheidungen für die Funktion zu fällen. Bei einem Beispiel werden die Blöcke 4334, 4336 und 4338 von einem Orchestrator, wie zum Beispiel dem Orchestrator 4308 (43A), der bereits besprochen wurde, geleitet. Das veranschaulichte Verfahren 4330 verbessert daher das FaaS-System hinsichtlich der Ereignisorientierung, minimaler Verwaltung, hoher Skalierbarkeit atomarer Recheneinheit und feiner Abrechnung.
43D zeigt ein FaaS-System 4340, in dem der Ort von Funktionsaufrufen basierend auf der Anforderungsquelle ausgewählt wird. Insbesondere gibt ein erster Client 4342 („Client 1“) eine erste Anforderung 4344 („Anforderung A“), um eine besondere Funktion auszuführen, zu dem FaaS-System 4340 aus. Der erste Client 4342 kann auch eine zweite Anforderung 4346 („Anforderung B“), um dieselbe Funktion auszuführen, zu dem FaaS-System 4340 ausgeben. Zusätzlich gibt ein zweiter Client 4348 („Client 2“) eine dritte Anforderung 4350 („Anforderung C“) zum Ausführen der Funktion zu dem FaaS-System 4340 auszuführen in dem veranschaulichten Beispiel aus. In einem solchen Fall könnte das FaaS-System 4340 einen Aufruf der Anforderung A 4352 ausgeben, und einen Aufruf der Anforderung B 4354 zu einem gemeinsamen Server ausgeben, wie zum Beispiel einem i-ten Server 4354 („Server i“), um die Wahrscheinlichkeit des Bewegens von Kontext- und/oder Zustandsdaten zu reduzieren. Im Gegensatz sendet das veranschaulichte FaaS-System 4340 einen Aufruf der Anforderung C 4356 zu einem j-ten Server 4358 („Server j“), weil die dritte Anforderung 4350 von dem zweiten Client 4348 (zum Beispiel einer unterschiedlichen Anforderungsquelle) stammt.
43E zeigt ein FaaS-System 4360, in dem die Lage von Funktionsaufrufen basierend auf Funktionsaufrufbäumen ausgewählt wird.
Insbesondere werden ein erster Funktionsaufrufbaum 4362 („Funktionsaufrufbaum 1“) und ein zweiter Funktionsaufrufbaum 4364 („Funktionsaufrufbaum 2“) zu dem FaaS-System 4360 ausgegeben. In einem solchen Fall könnte das FaaS-System 4360 einen ersten Satz von Aufrufen 4366, die dem ersten Funktionsaufrufbaum 4362 entsprechen, zu dem i-ten Server 4354 senden, um die Wahrscheinlichkeit des Bewegens von Kontext- und/oder Zustandsdaten, die mit dem ersten Funktionsaufrufbaum 4362 verbunden sind, zu reduzieren. Auf ähnliche Art sendet das FaaS-System 4360 einen zweiten Satz von Aufrufen 4368 zu dem j-ten Server 4358, um die Wahrscheinlichkeit des Bewegens von Kontext- und/oder Zustandsdaten, die mit dem zweiten Funktionsaufrufbaum 4364 verbunden sind, zu reduzieren.
Zusätzliche Anmerkungen und Beispiele
Beispiel 4301 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen: ein Token zu erzeugen, das einen Kontext einer Funktion, die mit einer eingehenden Anforderung zum Ausführen der Funktion zusammenhängt, eindeutig identifiziert; einen Serverstandort basierend auf dem Token und einer oder mehreren einer Zeithistorie, die mit der Funktion verbunden ist, einer Anforderungsquelle, einem Funktionsaufrufbaum, Standortkosten, einer Dienstgüte-Anforderung (QoS-Anforderung) oder einem Hash-Resultat einer vorhergehenden Ausführung der Funktion auszuwählen, wobei der Serverstandort ausgewählt wird, um einen lokalen Cache zu beinhalten, der den Kontext enthält; die Funktion an dem ausgewählten Serverstandort aufzurufen, wobei der Kontext ein Abrufen von Zustandsdaten durch die Funktion erleichtert; und den ausgewählten Serverstandort zu der Zeithistorie zu speichern.
Beispiel 4302 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 4301, wobei die ersten Daten in einem Cache der Datenspeicherung gespeichert werden sollen.
Beispiele für domänenübergreifenden Aufruftransfer
Domänenübergreifender Steuertransfer, der sich meistens aus einem Fernvorgehensweisenaufruf (Remote Procedure Call - RPC) ergibt, ist bei verteilten Anwendungen und Dienste häufig und seine hohen Kosten können damit verbundenen Kontextwechseln, Kopieren über Stapel (zum Beispiel unter der Kontrolle eines Supervisors/Hypervisors) und sicheren Steuertransfers zugeschrieben werden. RPCs waren ein Schlüsselmechanismus für das Aufbauen von Client-Server- oder Peer-to-Peer-Interaktionen. Effiziente RPC-Umsetzungen können in einer FaaS-Umgebung zu einer Herausforderung werden. Die Bedeutung effizienter domänenübergreifender Steuertransfers kann nämlich größer werden, während andere Probleme (zum Beispiel effiziente Isolierung durch leichtere Einschließung, Service-Level-Vertrag/SLA-Unterstützung usw.) behandelt werden.
Während RPC-Interaktionen kann sich der Aufrufer (a) von seinem Benutzerraum in den Kemelraum bewegen, wo (b) nach Validierung diverser Fähigkeiten (c) die Aufrufparameter/Daten rangiert und (d) über einen zweckdienlichen Transportmechanismus zu dem Aufrufer gemeldet werden. Messungen zeigen, dass der Steuerebenenaufwand bei optimierten gRPC-Umsetzungen (GOOGLE RPC) mehr als 90 % der Zyklen ausmacht. Bei einem Beispiel hat eine cloudnative Datenebene (zum Beispiel der Teil eines Netzwerks, der Benutzerverkehr trägt) Arbeit, wie zum Beispiel das NFF-Go-Projekt (zum Beispiel github.com/intel-go/nff-go) aufgezeigt, dass effizienter RPC für Netzwerkfunktionsvirtualisierung kritisch sein kann (zum Beispiel zu Hunderten Millionen Anforderungen/Sekunde, ~ 1 Anforderungen pro Paket fähig). Gleichzeitig haben Versuche, FaaS-Paradigma auf Datenebenenverarbeitung anzuwenden, eventuell einen Bedarf an vereinheitlichtem Mechanismus (vereinheitlichten Mechanismen) zum Zugreifen auf das OS, Plattform- und Hardwarebeschleunigung sowie Function-to-Function-Verkettung zum Verhindern von Abhängigkeiten von spezifischen Frameworks, (um zum Beispiel Funktionsaufrufe auf dieselbe Weise in unterschiedlichen Cloud-Umgebungen auszuführen, wie in AMAZON LAMBDA™, OPENWHISK™, GCP/GOOGLE CLOUD PLATFORM™ und NFF-Go™) aufgedeckt.
Die Vorgänge, die in den obigen Prozessen (a) bis (d) involviert sind, können vorformulierte Codesequenzen beinhalten, die über unterschiedliche Domänen ausgeführt werden, die Überwachungseingriff involvieren, der sie rechnerisch kostspielig macht. Ähnliche Aufwände gelten nämlich auf der Seite des Aufgerufenen und auf dem Rückweg der Resultate. Während andere Hardware-Features schneller werden (zum Beispiel bei sukzessiven Hardware-Technologie-Generationen), werden diese Aufwände proportional zu einem großen Stück des „Kuchens“.
Obwohl kürzlich entwickelte Anweisungen eine Hardwareumsetzung der obigen „Makro-“ oder gewöhnlichen Vorgänge erleichtern können, bleibt noch Raum für Verbesserung. Der Mangel an einem darunterliegenden Mechanismus, der sich darauf konzentriert, den Steuertransfer effizient zu machen, ohne in größeren Kosten in Verbindung mit häufigeren Kontextwechseln, Kopieren über Stapel, Transfersicherheit und/oder Überwachungseingriff zu resultieren. Wie ausführlicher besprochen wird, können virtuelle Hardware-Threads und Uniform-Resource-Identifier-Aufrufanweisungen (URI-Aufrufanweisungen) verwendet werden, um die Effizienz von domänenübergreifenden Steuertransfers zu steigern.
Unter Bezugnahme auf 44A ist die domänenübergreifende Umgebung 4400 gezeigt, in der ein Aufrufer 4404 (zum Beispiel Aufrufer) in einer ersten Domäne 4402 eine Funktion aufruft, die auf den Aufruf in einer zweiten Domäne 4406 „virtuell wartet“. Im Allgemeinen kann ein Kern in der zweiten Domäne 4406 Überwachungslogik 4408 (zum Beispiel logische Anweisungen, konfigurierbare Logik, Hardware-Logik mit feststehender Funktionalität usw. oder irgendeine Kombination davon) und eine Vielzahl virtueller Hardware-Threads (VHTRs) wie zum Beispiel einen virtuellen Hardware-Thread 4410 beinhalten. Der virtuelle Hardware-Thread 4410 kann im Allgemeinen eine Thread-Planungsstruktur sein, die von Planungshardware verwendet wird, um Kernressourcen und Zyklen auf mehrere Threads oder virtuelle Netzwerkfunktionen (Virtual Network Functions VNFs) zu verteilen. Aus der Sicht eines Software- und Betriebssystemstandpunkts, ist ein VHTR einem gewöhnlichen CPU-Kern ähnlich. Bei einigen Ausführungsformen wird ein VHTR zu einem Thread gepinnt und mit mehreren Funktionen verbunden, um beim Planen und bei der Ausführung zu unterstützen. Bei einigen Ausführungsformen adaptiert ein Hardware-Scheduler CPU-Slice sing unter VHTRs. Hundert oder mehr VHTRs könnten geplant werden, um die CPU-Zyklen zweier Verarbeitungskerne gemeinsam zu verwenden. Tausende VHTRs können folglich Threads zugeordnet und an sie gepinnt werden, solange ausreichend Lagerung vorhanden ist.
Bei dem veranschaulichten Beispiel wird der virtuelle Hardware-Thread 4410 in einen Pausezustand („P“-Zustand) platziert, in dem Ausführung und Polling vorübergehend unterbrochen sind. Während der virtuelle Hardware-Thread 4410 in dem P-Zustand wartet, empfängt er weder Prozessorzyklen noch ruft er ab. Wenn der Aufrufer 4404 (zum Beispiel über eine CALLURI2-Anweisung) einen oder mehrere Aufrufparameter der aufgerufenen Funktion in einen überwachten Ort, wie zum Beispiel eine Warteschlange 4412 oder einen anderen Ort, der von der aufgerufenen Partei überwacht wird, einreiht, tritt der veranschaulichte Aufrufer 4404 (zum Beispiel über einen WAIT-Befehl) in einen lokalen virtuellen Hardware-Thread 4418 in den P-Zustand ein. Zusätzlich kann die Überwachungslogik 4408 die Gegenwart des/der Aufrufparameter in der Warteschlange 4412 erfassen. Die Anwesenheit des/der Aufrufparameter in der Warteschlange 4412 kann über eine vorab existierende Mikroarchitekturfähigkeit erfasst werden, wie zum Beispiel ein Benutzerebeneninterrupt (zum Beispiel UMONITOR/UMWAIT), einen Speicherauslöser (zum Beispiel MONITOR/MWAIT), eine Angabe erzeugt von einem transaktionalen Synchronisationserweiterungsmechanismus (TSX-Mechanismus) einer Ladung oder Speicherung zu einer markierten Cache-Zeile, einen Inter-Processor-Interrupt (IPI) kombiniert mit einer Halt-Anweisung (HLT-Anweisung) und eine leichte Interrupt-Service-Routine (ISR), rückwärts kompatible Pollingschleifen und so fort.
Bei einem Beispiel ist die Monitorlogik 4408 Teil eines Hardware-Schedulers, der einen Kern auswählt, der in Wartezustand ist, und die Ausführung des ausgewählten Kerns durch Weitergeben der Funktionsadresse, eines Pointers zu dem/den Abrufparameter(n), und eines Token, das eine Anforderung identifiziert, die für zukünftige Rücksendung von Resultaten verwendet werden kann, auslöst. Falls kein wartender Kern existiert, kann der HW-Scheduler entweder eine Warteschlange von Aufgaben für jeden Kern unterstützen (zum Beispiel Hardware-Warteschlangenmanager/HQM) oder eine erweiterte Semantik von UMONITOR/UMWAIT verwenden, die Parameter transferiert und Warteschlangen unterstützt (zum Beispiel berichtet, ob ein Kern in dem P-Zustand wartet). Als Reaktion darauf, dass der/die Aufrufparameter in der Warteschlange 4412 sind, platziert die Überwachungslogik 4408 den virtuellen Hardware-Thread 4410 in einen Ausführungszustand („E“-Zustand). Bei dem veranschaulichten Beispiel reiht der virtuelle Hardware-Thread 4410 eines oder mehrerer Resultate der aufgerufenen Funktion in einen überwachten Ort ein, wie zum Beispiel eine Warteschlange 4414 oder einen anderen Ort, der von der aufrufenden Partei überwacht wird. Die Überwachungslogik 4416 (zum Beispiel logische Anweisungen, konfigurierbare Logik, Hardware-Logik mit feststehender Funktionalität usw. oder irgendeine Kombination davon) kann die Anwesenheit des/der Resultat(e) in der Warteschlange 4414 erfassen. Die Anwesenheit des/der Resultat(e) in der Warteschlange 4414 kann über eine vorab existierende Mikroarchitekturfähigkeit erfasst werden, wie zum Beispiel ein Benutzerebeneninterrupt, einen Speicherauslöser, einen TSX-Mechanismus-generierten Hinweis auf eine Last oder einen Speicher zu einer markierten Cache-Zeile, einen IPI kombiniert mit einer HLT-Anweisung und einen leichten ISR, rückwärts kompatible Pollingschleifen und so fort erfasst werden. Als Reaktion darauf, dass das/die Resultat(e) in der Warteschlange 4414 sind, platziert die veranschaulichte Überwachungslogik 4416 den virtuellen Hardware-Thread 4418 in den Ausführungszustand, so dass er das/die Resultat(e) verbrauchen und weitere Vorgänge ausführen kann.
Unter Bezugnahme auf 44B ist ein Verfahren 4420 zum Betreiben eines Fernvorgehensweisenaufgerufenen gezeigt. Das Verfahren 4420 kann im Allgemeinen in einem verbesserten FaaS-System, wie zum Beispiel dem System 202 (2), dem System 300 (3), und/oder dem System 400 (4), die bereits besprochen wurden, umgesetzt werden. Bei einer Ausführungsform wird das Verfahren 4420 in der Domäne einer aufgerufenen Partei, zum Beispiel in der zweiten Domäne 4406 (44A), die bereits besprochen wurde, umgesetzt. Insbesondere kann das Verfahren 4420 in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 4422 stellt das Platzieren eines virtuellen Hardware-Thread in einem Pausezustand, in dem Ausführung und Polling vorübergehend unterbrochen sind, bereit. Bei dem veranschaulichten Beispiel ist der virtuelle Hardware-Thread mit einer aufgerufenen Funktion verbunden, und die aufgerufene Funktion ist eine Fernvorgehensweise. Bei Block 4424 kann bestimmt werden, ob sich ein oder mehrere Aufrufparameter der aufgerufenen Funktion an einem überwachten Ort befinden. Ist das nicht der Fall, wiederholt das veranschaulichte Verfahren 4420 Block 4424. Sobald bestimmt ist, dass der/die Aufrufparameter erfasst wurden, stellt der Block 4426 das Platzieren des virtuellen Hardware-Thread in einen Ausführungszustand als Reaktion darauf, dass der/die Aufrufparameter an dem überwachten Ort sind, bereit.
44C zeigt ein Verfahren 4430 zum Betreiben eines Fernvorgehensweisenaufrufers. Das Verfahren 4430 kann im Allgemeinen in einem verbesserten FaaS-System, wie zum Beispiel dem System 202 (2), dem System 300 (3), und/oder dem System 400 (4), die bereits besprochen wurden, umgesetzt werden. Bei einer Ausführungsform wird das Verfahren 4430 in einer Domäne einer aufrufenden Partei, zum Beispiel in der ersten Domäne 4402 ( 44A), die bereits besprochen wurde, umgesetzt. Insbesondere kann das Verfahren 4430 in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 4432 stellt das Platzieren eines virtuellen Hardware-Thread in einen Pausezustand, in dem Ausführung und Polling vorübergehend unterbrochen sind, bereit. Bei dem veranschaulichten Beispiel ist der virtuelle Hardware-Thread mit einem Aufrufer einer aufgerufenen Funktion verbunden, und die aufgerufene Funktion ist eine Fernvorgehensweise. Bei Block 4434 kann bestimmt werden, ob sich ein oder mehrere Resultate der aufgerufenen Funktion an einem überwachten Ort befinden. Ist das nicht der Fall, wiederholt das veranschaulichte Verfahren 4430 Block 4434. Sobald bestimmt ist, dass das/die Resultate erfasst wurden, stellt der Block 4436 das Platzieren des virtuellen Hardware-Thread in einen Ausführungszustand als Reaktion darauf, dass der/die Aufrufparameter an dem überwachten Ort sind, bereit.
Zusätzliche Anmerkungen und Beispiele
Beispiel 4401 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen virtuellen Hardware-Thread in einen Pausezustand zu platzieren, in dem Ausführung und Polling vorübergehend unterbrochen sind, wobei der virtuelle Hardware-Thread mit einer Aufgerufenenfunktion verbunden ist, und die aufgerufene Funktion eine Fernvorgehensweise ist, einen oder mehrere Aufrufparameter der aufgerufenen Funktion an einem überwachten Ort zu erfassen, und als Reaktion darauf, dass der eine oder die mehreren Aufrufparameter an dem überwachten Ort sind, den virtuellen Hardware-Thread in einen Ausführungszustand zu platzieren.
Beispiel 4402 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen virtuellen Hardware-Thread in einen Pausezustand zu platzieren, in dem der virtuelle Hardware-Thread mit einem Aufrufer einer aufgerufenen Funktion verbunden ist, und die aufgerufene Funktion eine Fernvorgehensweise ist, ein oder mehrere Resultate der aufgerufenen Funktion an einem überwachten Ort zu erfassen, und als Reaktion darauf, dass der eine oder die mehreren Resultate an dem überwachten Ort sind, den zweiten virtuellen Hardware-Thread in einen Ausführungszustand zu platzieren.
Beispiele für die Vereinheitlichung heterogener Datenflüsse
45A zeigt eine FaaS-Architektur 4500, in der Pakete eine Netzwerkgrenze 4502 überqueren, und ein Netzwerkstapel im Allgemeinen mehrere Schichten (zum Beispiel L7 - Anwendungsschicht, L4 - Transportschicht, L3 - Netzwerkschicht, L2 - Datenverbindungsschicht usw.) beinhaltet. Eine oder mehrere Datenverbindungsfunktionen (zum Beispiel Schicht L2 des Open Systems Interconnection-/OSI-Modells) 4508 erleichtern den Transfer von Daten zwischen benachbarten Netzwerkknoten in einem Wide Area Network (WAN) oder zwischen Knoten auf demselben Local Area Network-Segment (LAN-Segment). Zusätzlich können eine oder mehrere Netzwerkfunktionen (zum Beispiel Schicht L3 des OSI-Modells) 4512 Paketweiterleitung handhaben, und eine oder mehrere Transportfunktionen (zum Beispiel Schicht L4 des OSI-Modells) 4514 stellen Hostzu-Host-Kommunikationsdienste für Anwendungen bereit.
Bei einem Beispiel fängt ein API-Gateway 4506 Fernvorgehensweisenaufrufe (RPCs) aus diversen Funktionen 4504 (4504a bis 4504d) ab, wie zum Beispiel eine erste Anwendungsschichtfunktion (zum Beispiel L7 des OSI-Modells) 4504a, eine erste Datenebenenfunktion 4504b (zum Beispiel Web-Funktion), eine zweite Datenebenenfunktion 4504c (zum Beispiel Proxy-Funktion), eine zweite Anwendungsschichtfunktion 4504d und so fort. Das veranschaulichte API-Gateway 4506, das ein Hypertext Transfer Protocol (HTTP) unterstützt, fängt auch RPCs aus einer oder mehreren Infrastrukturfunktionen 4510 ab. Ein beschleunigter RPC-Aufrufer (A-RPC-Aufrufer) 4520 kann Instanziierungen von Netzwerkfunktionen, die mit den abgefangenen RPCs verbunden sind, leiten. Das API-Gateway 4506 könnte zum Beispiel einen RPC aus der ersten Anwendungsschichtfunktion 4504a abfangen, wobei, falls der abgefangene RPC mit der zweiten Anwendungsschichtfunktion 4504d verbunden ist, der Aufrufer die zweite Anwendungsschichtfunktion 4504d instanziiert.
Insbesondere werden die RPCs vor Paketierung der RPCs abgefangen, und die Instanziierungen umgehen die Transportschicht und/oder die Netzwerkschicht des Netzwerkstapels. Die veranschaulichte Lösung stellt daher eine neue Application Binary Interface (ABI) bereit, die nicht durch den gesamten Netzwerkstapel hindurch zu gehen braucht. Die Instanziierungen können auch einen oder mehrere Verschlüsselungsvorgänge, einen oder mehrere Aufrufer-Ziel-Handshake-Meldungen usw. umgehen. Das veranschaulichte API-Gateway 4506, die Funktionen 4504 und der Aufrufer 4520 bilden folglich eine FaaS-Funktion zu Funktionsbeschleunigungslogik 4522, die effizientere Instanziierung und Routing ermöglicht.
Die veranschaulichten Funktionen 4504 und diversen Ereignisquellen 4516 (zum Beispiel Zustands- und Konfigurationsdatenbanken) von einer oder mehreren Steuerebenenfunktionen 4518 unterstützt. Zusätzlich können die Ereignisquellen 4516 Kontextdaten zu der Netzwerkgrenze 4502, Datenverbindungsfunktion(en) 4508, Internet-Protocol-Logik (IP-Logik) 4524 (zum Beispiel IPv4, IPv6), Transmission-Control-Protocol-Logik (TCP-Logik) 4526, Secure-Sockets-Layer-Logik (SSL) 4528, die TCP-Meldungen mit dem API-Gateway 4506 austauscht, User-Datagram-Protocol-Logik (UDP) 4530 und Domain-Name-Server-Logik (DNS) 4532, die bei dem veranschaulichten Beispiel alle beschleunigt werden, bereitstellen. Die veranschaulichte Architektur 4500 beinhaltet auch Address Resolution Protocol-Logik (ARP) 4534. Bei einem Beispiel sind die Netzwerkgrenze 4502, Datenverbindungfunktion(en) 4508, IP-Logik 4524, TCP-Logik 4526, SSL-Logik 4528 und das API-Gateway 4506 FaaS-API-Gateway-Beschleunigungslogik 4536.
Die erste Anwendungsschichtfunktion 4504a und die zweite Anwendungsschichtfunktion 4504d sind über Representational-State-Transfer (REST), gRPC, A-RPC und so fort aufrufbar. Ein zusätzlicher Pfad 4538 kann für Pakete, die Legacy-Protokolle enthalten, wie zum Beispiel Border Gateway Protocol (BGP), die vor dem Erreichen des API-Gateway 4506 verarbeitet werden sollen, bereitgestellt werden. Die Legacy-Protokolle könnten einige Konfigurationen anderer Funktionen beeinträchtigen. BGP kann zum Beispiel verwendet werden, um Routing-Tabellen zu aktualisieren, die wiederum von einigen IP-Funktionen verwendet werden. Der veranschaulichte zusätzliche Pfad 4538 ermöglicht es daher, die Funktionalität des API-Gateway 4506 auf nur einige wenige Protokolle, falls zutreffend, einzuschränken. Der zusätzliche Pfad 4538 kann nämlich REST- und gRPC-Aufrufe handhaben, wobei das API-Gateway 4506 nur für A-RPC-Aufrufe zuständig ist (inklusive ihrer Rezirkulation, zum Beispiel F1=>F2=>F3 usw., ohne niedrige Ebenen des Netzwerkstapels). Die veranschaulichte Architektur 4500 vereinheitlicht folglich eine Umsetzung eines kompletten L2-L7-Netzwerkstapels und L7-Anwendungsfunktionen und ermöglicht diverse Shortcuts durch Exponieren des API-Gateway 4506 als eine eigenständige Infrastrukturfunktion (Laufzeitfunktion). Die veranschaulichte Architektur 4500 eliminiert auch Performance-Probleme, die mit unterschiedlich bezeichneten Anwendungen verbunden sind, wie NGINX, was ansonsten erfordern kann, dass Aufrufe durch den Kernelnetzwerkstapel durchgehen.
45B zeigt ein Verfahren 4540 zum Betreiben eines Laufzeit-Framework für einen FaaS-Service. Das Verfahren 4540 kann im Allgemeinen in einem verbesserten FaaS-System, wie zum Beispiel dem System 202 (2), dem System 300 (3), und/oder dem System 400 (4), die bereits besprochen wurden, umgesetzt werden. Bei einer Ausführungsform wird das Verfahren 4540 in einer FaaS-Architektur, wie zum Beispiel der FaaS-Architektur 4500 (45A), die bereits besprochen wurde, umgesetzt. Insbesondere kann das Verfahren 4540 in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw., gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.
Der veranschaulichte Verarbeitungsblock 4542 stellt das Abfangen eines RPC aus einer ersten Netzwerkfunktion an einer Anwendungsschicht eines Netzwerkstapels vor der Paketierung des RPC bereit. Block 4544 kann eine Instanziierung einer zweiten Netzwerkfunktion, die mit dem RPC (zum Beispiel an der Anwendungsschicht) verbunden ist, leiten, wobei die Instanziierung eine oder mehrere einer Transportschicht des Netzwerkstapels oder einer Netzwerkschicht des Netzwerkstapels umgehen soll. Bei einem Beispiel kann die Instanziierung auch einen oder mehrere Verschlüsselungsvorgänge und/oder eine oder mehrere Aufrufer-Ziel-Handshake-Meldungen umgehen.
Zusätzliche Anmerkungen und Beispiele
Beispiel 4501 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen Fernvorgehensweisenaufruf aus einer ersten Netzwerkfunktion an einer Anwendungsschicht eines Netzwerkstapels vor Paketierung des Fernvorgehensweisenaufruf abzufangen und eine Instanziierung einer zweiten Netzwerkfunktion, die mit dem Fernvorgehensweisenaufruf verbunden ist, zu leiten, wobei die Instanziierung eine oder mehrere einer Transportschicht des Netzwerkstapels oder einer Netzwerkschicht des Netzwerkstapels umgehen soll.
Beispiel 4502 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 4501, wobei die Instanziierung einen oder mehrere Verschlüsselungsvorgänge und eine oder mehrere Aufrufer-Ziel-Handshake-Meldungen umgehen soll.
Beispiele für Antwortobjektanpassung
Bei einem Beispiel verwenden FaaS-Architekturen Standard-Datenaustauschformate zum Weitergeben von Parametern und Argumenten zwischen Funktionen, Empfangen von Aufrufanforderungsantworten, die in solche Formate serialisiert werden und so fort, beinhaltet ein gewöhnlich verwendetes Format JSON (JavaScript Object Notation), das leicht ist und ohne Weiteres gelesen/geparst werden kann. Unterschiedliche Aufrufinstanzen einer Funktion können unterschiedliche Felder des Antwortobjekts verwenden, wobei das Antwortobjekt serialisiert und in der Form eines JSON-Objekt zurückgesendet werden kann. Eine Funktion „funcGetltems“ könnte zum Beispiel eine Liste von Elementen, die jeweils eine ausführliche Liste von Feldern enthalten, zurücksenden.

          füncGetItems() {
              // Elemente zum Beispiel aus der Datenbank abrufen
              itemsRet = ...
              itemsRet zurücksenden;
          }
          Eine Muster-JSON-Antwort, die von funcGetItems zurückgesendet wird:

           {
           „items": [

            { „item_id": „CCA",
            „estimated_at": 1461612017,
            „expires_at": 1461612617,
            "start-time": 1461618000,
            „end_time": 1461621600,
            „fee": 4.34,
            „currency_code": „USD",
            „ready_by_time": 1461617260
            },
            { „item_id": „CVOWF",
            „estimated_at": 1461612017,
            „expires_at": 1461612617,
            "start-time": 1461621600,
            „end_time": 1461625200,
            „fee": 4.34,
            „currency_code": „USD",
            „ready_by_time": 1461620860
            },
            { „item_id": „Y2UyND",
            „estimated_at": 1461612017, 



            „expires_at": 1461612617,
            „start_time": 1461625200,
            „end_time": 1461628800,
            „fee": 4.34,
            „currency_code": „USD",
            „ready_by_time": 1461624460

           ]}

          }

Es kann ein Szenario angetroffen werden, bei dem Funktionen „funcA“ und „funcB“ jeweils „funcGetltems“ aufrufen.

          funcA() {
              response = lambda.invoke(funcGetItems)
              all = response[„items"]
              for item in all:

               process(item[„item_id"], item[„fee"])
          }
          funcB() {
              response = lambda.invoke(funcGetItems)
              all = response[„items"]
              for item in all:

               process(item[„item_id"], item[„start _time"])
          }

Technologie, die hierin beschrieben ist, passt das serialisierte Antwortobjekt (oder den serialisierten Antwortparameter), das angepasst werden soll, basierend auf den Anforderungen/der Signatur jedes Aufrufers an. Die zurückgesandte Antwort auf „funcB“ kann zum Beispiel in das folgende JSON-Objekt, das nur die nötigen/zweckdienlichen Datenfelder enthält, komprimiert werden.

           {
           „items": [

            { „item_id": „CCA",
            "start-time": 1461618000, 



            },
            { „item_id": „CVOWF",
            "start-time": 1461621600,
            },
            { „item_id": „Y2UyND",
            „start_time": 1461625200,

           ]}

          }

46A führt zum Beispiel vor, dass eine Funktion 4600 einen Satz von Datenfeldern 4602 (zum Beispiel „item_id“ bis „ready_by_time“) zurücksenden kann. Falls zum Beispiel ein erster Aufruf durch eine erste Aufrufinstanz 4604 der Funktion 4600 (zum Beispiel Lambda/anonymer Aufrufer von „funcA“) erfasst wird, kann ein erster Subsatz 4606 (zum Beispiel nur „item_id“ und „fee“) des Satzes von Feldern 4602 identifiziert werden, wobei der erste Subsatz 4606 für die erste Aufrufinstanz 4604 relevant ist. Darüber hinaus kann ein erstes Relayout (zum Beispiel Umkonfiguration, Umordnen) eines ersten Antwortobjekts 4612 (zum Beispiel JSON-Objekt) basierend auf dem ersten Subsatz 4606 ausgeführt werden. Wie ausführlicher besprochen wird, kann das erste Relayout das erste Antwortobjekt 4612 filtern, so dass es nur den ersten Subsatz 4606 beinhaltet, das erste Antwortobjekt 4612 umordnen, um den ersten Subsatz 4606 vor restlichen Feldern in dem Satz von Feldern 4602 aufzulisten und so fort.

Auf ähnliche Art, falls ein zweiter Aufruf durch eine erste Aufrufinstanz 4608 der Funktion 4600 (zum Beispiel Lambda/anonymer Aufrufer von „funcB“) erfasst wird, kann ein zweiter Subsatz 4610 (zum Beispiel nur „item_id“ und „start_time“) des Satzes von Feldern 4602 identifiziert werden, wobei der erste Subsatz 4610 für die zweite Aufrufinstanz 4608 relevant ist. Darüber hinaus kann ein zweites Relayout eines zweiten Antwortobjekts 4614 (zum Beispiel JSON-Objekt) basierend auf dem zweiten Subsatz 4610 ausgeführt werden. Das zweite Relayout kann wieder das zweite Antwortobjekt 4612 filtern, so dass es nur den zweiten Subsatz 4610 beinhaltet, das zweite Antwortobjekt 4614 umordnen, so dass es den zweiten Subsatz 4606 vor restlichen Feldern in dem Satz von Feldern 4602 auflistet und so fort. Die veranschaulichte Lösung, die von dem verbesserten FaaS-System bereitgestellt wird, komprimiert folglich die Antwortobjekte 4612, 4614 und ermöglicht effizienteres Networking/Bandbreitennutzung, weniger Verarbeitungsaufwand, verbesserte Performance, minimierte Verwaltung und größere Skalierbarkeit.

Bei einer Ausführungsform kann der Kompressionsmechanismus als ein Treffen relevanter Felder für jede anonyme Aufruferfunktion (zum Beispiel Function-Literal, Lambda-Abstraktion, Lambda-Ausdruck) umgesetzt werden, bevor die Antwort zurückgesandt wird. Bei einem Beispiel werden die Labels/Offsets relevanter Datenfelder für jeden Aufrufer registriert und können weiter in einer Software-/Hardwarestruktur in der Nähe der aufgerufenen Lambda zwischengespeichert werden. Eine Nachschlagtabelle könnte zum Beispiel durch die Aufrufer-ID/IP/Adresse indiziert werden, um das Filter, das an das Rohergebnis angewandt wird, abzurufen. Das Filter kann einige Felder von Interesse, den obigen Beispielen ähnlich, auswählen. Zusätzlich kann das Filter auch das Antwortobjekt/JSON-Objekt umformatieren, um die Felder von Interesse zuerst aufzulisten/zu bringen und den Rest der Felder/Daten dahinter zu platzieren. Obwohl JSON-Kompression hierin verwendet wird, um die Besprechung zu erleichtern, können andere Codierungen von Meldungsparametern, wie zum Beispiel binäre gRPC-Codierung, ebenfalls verwendet werden.

Bei einem Beispiel wird der Filtercode (zum Beispiel Method-Stub, Lambda) als Teil der Aufruferumsetzungen (zum Beispiel Signatur, Method-Stub) bereitgestellt. Der Filtercode kann auch durch ein Compiler-/Laufzeittool abgeleitet werden. Bei einer Ausführungsform wird das Filtern des Rohergebnisses vor seinem Zurücksenden über eine Jump-Tabelle (zum Beispiel einen indirekten Jump zu Code, der die Kompression/das Relayout ausführt, der für jeden Aufrufer maßgeschneidert ist), umgesetzt, bevor die Rücksendeanweisung ausgeführt wird. Weitere Anweisungssatzarchitektur (Instruction Set Architecture - ISA) und Hardwareunterstützung können entwickelt werden, um Ziele des indirekten Jump zwischenzuspeichern (zum Beispiel ähnlich einem Translation-Lookaside-Buffer-Cache/TLB-Cache) oder die Ziele des indirekten Jump (zum Beispiel ähnlich einem Branch-Target-Buffer/BTB) vorherzusagen.

Unter Bezugnahme auf 46B ist ein Verfahren 4620 zum Anpassen von Antwortobjekten an Aufrufinstanzen gezeigt. Das Verfahren 4620 kann im Allgemeinen in einem verbesserten FaaS-System, wie zum Beispiel dem System 202 (2), dem System 300 (3), und/oder dem System 400 (4), die bereits besprochen wurden, umgesetzt werden. Insbesondere kann das Verfahren 4620 in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.

Der veranschaulichte Verarbeitungsblock 4622 erfasst einen ersten Aufruf durch eine erste Aufrufinstanz einer Funktion, die einen Satz von Feldern zurücksendet. Ein erster Subsatz des Satzes von Feldern kann bei Block 4624 identifiziert werden, wobei der erste Subsatz für die erste Aufrufinstanz relevant sein soll. Zusätzlich führt Block 4626 ein erstes Relayout eines ersten Antwortobjekts basierend auf dem ersten Subsatz aus. Bei einem Beispiel beinhaltet Block 4626 das Filtern des ersten Antwortobjekts, um nur den ersten Subsatz zu beinhalten. Block 4626 kann auch das Umordnen des ersten Antwortobjekts beinhalten, um den ersten Subsatz vor restlichen Feldern in dem Satz von Feldern aufzulisten. Andere Relayout-Techniken können ebenfalls verwendet werden.

Bei einem Beispiel wird bei Block 4628 ein zweiter Aufruf durch eine zweite Aufrufinstanz der Funktion erfasst. Ein zweiter Subsatz des Satzes von Datenfeldern wird bei Block 4630 identifiziert, wobei der zweite Subsatz für die zweite Aufrufinstanz relevant sein soll. Der veranschaulichte Verarbeitungsblock 4632 führt ein zweites Relayout aus einem zweiten Antwortobjekt basierend auf dem zweiten Subsatz aus, wobei das zweite Relayout von dem ersten Relayout unterschiedlich ist. Block 4632 kann das Filtern des zweiten Antwortobjekts beinhalten, so dass nur der zweite Subsatz enthalten ist, das Umordnen des zweiten Antwortobjekts, um den zweiten Subsatz vor restlichen Feldern in dem Satz von Feldern aufzulisten und so fort. Das veranschaulichte Verfahren 4620 komprimiert folglich die Antwortobjekte und ermöglicht effizienteres Networking/Bandbreitennutzung, weniger Verarbeitungsaufwand, verbesserte Performance, minimierte Verwaltung und größere Skalierbarkeit.

Zusätzliche Anmerkungen und Beispiele

Beispiel 4601 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz von ausführbaren Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen ersten Aufruf durch eine erste Aufrufinstanz einer Funktion, die einen Satz von Feldern zurücksendet, zu erfassen, einen ersten Subsatz des Satzes von Feldern zu identifizieren, wobei der erste Subsatz für die erste Aufrufinstanz relevant sein soll, und ein erstes Relayout eines ersten Antwortobjekts basierend auf dem ersten Subsatz auszuführen.

Beispiel 4602 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 4601, wobei das erste Relayout das erste Antwortobjekt filtern soll, um nur den ersten Subsatz zu enthalten.

Beispiel 4603 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 4601, wobei das erste Relayout das erste Antwortobjekt umordnen soll, um den ersten Subsatz vor restlichen Feldern in dem Satz von Feldern aufzulisten.

Beispiel 4604 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 4601, wobei die Anweisungen, wenn sie ausgeführt werden, das Rechengerät veranlassen, einen zweiten Aufruf durch eine zweite Aufrufinstanz der Funktion du erfassen, einen zweiten Subsatz des Satzes von Filtern zu identifizieren, wobei der zweite Subsatz für die zweite Aufrufinstanz relevant sein soll, und ein zweites Relayout eines zweiten Antwortobjekts basierend auf dem zweiten Subsatz auszuführen, wobei das zweite Relayout von dem ersten Relayout unterschiedlich ist.

Beispiele für Parameterrangieren

Das Parameterrangieren involviert das Umwandeln der Speicherdarstellung eines Objekts in ein anderes Format, das für die Lagerung oder die Übertragung zu anderen Softwareanwendungen geeignet ist. Das Rangieren erleichtert folglich die Kommunikation zwischen entfernten Objekten durch Umwandeln eines Objekts in eine serialisierte Form. Das Rangieren von Parametern für RPCs in einem FaaS-Framework kann sich mit Engpassherausforderungen aufgrund des schieren Datenumfangs, der transferiert wird, konfrontiert sehen. Ob nun Textcodieren (zum Beispiel REST mit JSON) oder Binäres Codieren (zum Beispiel GRPS, FLATBUFFERS, APACHE THRIFT) verwendet wird, um die Funktionsparameter weiterzugeben, kann die Engpassherausforderung fortdauern, weil Daten „auf dem Draht“ unterschiedlich von Daten im Speicher formatiert sind und eine permanente Serialisierung/Deserialisierung auftritt.

47A zeigt ein Szenario, bei dem ein Compiler 4700 eine Nutzlast 4702 (zum Beispiel ein „ausführungsbereites“ Daten-Array) für eine Funktion bestimmt und zur Kompilierungszeit die Nutzlast 4702 auf den Call-Stack 4704 platziert. Wie ausführlicher besprochen wird, ist die Funktion einheitlich über die Nutzlast 4702 als entweder eine oder mehrere lokale Instanzen 4706 (zum Beispiel auf einer lokalen Plattform) oder eine oder mehrere Ferninstanzen 4708 (zum Beispiel auf einer entfernten Plattform) aufrufbar. Falls zur Laufzeit (zum Beispiel basierend auf diversen Bedingungen, die zur Kompilierungszeit nicht bekannt sind) bestimmt wird, dass die Funktion auf der entfernten Plattform aufgerufen werden soll, wird die veranschaulichte Nutzlast 4702 zu einem Call-Stack 4710 auf der entfernten Plattform transportiert, wo sie von einem generischen RPC-Handler verwendet wird, um die Instanz(en) 4708 aufzurufen. Bei einem Beispiel beinhaltet die Nutzlast 4702 einen oder mehrere Parameterwerte, die Größe der Nutzlast 4702 und einen Identifikator der Funktion. Die veranschaulichte Lösung eliminiert folglich Engpässe in Verbindung mit dem ineffizienten Rangieren von Funktionsparametern. Verbesserte Performance, minimale Administration und größere Skalierbarkeit können folglich erzielt werden.

Insbesondere kann ein „Ready-to-Wire“-Format als Teil der ABI (binären Anwendungsschnittstelle) für Funktionsaufrufe verwendet werden, bei welchen der Stapel 4704 für einen Stub-seitigen Abschnitt des Aufrufs alle Einzelheiten enthält, die zu ihrem Übertragen eines RPC-Transportmechanismus oder Weitergeben zu Hardware erforderlich sind. Der Stapel 4704 ist es folglich, wo die Nutzlast 4702 als ein ausführungsbereites Daten-Array platziert und für Aufruf des Ziels bereit gemacht wird. Falls das Ziel daher fern ist und über einen Transportmechanismus ohne gemeinsam verwendeten Speicher aufgerufen werden muss, wird es direkt mit der Nutzlast 4702 bereits auf dem Stapel 4704 der lokalen Plattform zusammengefügt aufgerufen.

Auf der entfernten Plattform (zum Beispiel Empfänger-/Zielseite) richtet der umgekehrte Vorgang auf ähnliche Weise den Stapel 4710 zum Aufrufen ein (zum Beispiel Zusammenlegen der Protokollverarbeitung und Datenentpackens in einen einzigen Vorgang). Falls das Ziel eine Fernvorgehensweise ist, die aufgerufen werden kann, ohne die Nutzlast verdrahtet zu transportieren, kann der Stapel 4704 in gemeinsam verwendetem Speicher aufgebaut werden und der RPC kann extrem leicht sein, sogar wie ein lokaler Funktionsaufruf, falls alle Argumente in gemeinsam verwendetem Speicher mit dem Stapel 4704, der zum Verteilen des Fernaufrufs verwendet wird, liegen.

Das Konzept wird unten mit einem absichtlich einfachen Beispiel veranschaulicht, bei dem das Rangieren einfaches Kopieren der Parameterwerte (zum Beispiel Argumente) in einen Stapelrahmen involviert. Das Kernkonzept bleibt für komplexere Argumente gleich.

Zur Laufzeit, in Abhängigkeit von der Konfiguration, könnte eine Funktion, wie zum Beispiel test(int a, short b) entweder als ein lokaler Aufruf oder als ein Femaufruf auf einem entfernten Netzwerkhost abgesandt werden. Die Entscheidung kann auf diversen Bedingungen, die zur Kompilierungszeit unbekannt sind, basieren. In einem solchen Fall kann eine herkömmliche Laufzeit einen solchen Aufruf wie folgt ausführen, mit Codeanmerkungen, die auf doppelte Schrägstriche „//“ folgen):

          if (_local_call_to_test()) {
          test(a, b); // Der Compiler erzeugt Code mit Platzieren von a und b auf
 Stapel oder Registern, wie
          // folgt -           //
 stack.a=a;
          // stack.b=b;
          // Aufruftest
          } // herkömmliche ABI verwenden, a und b wären auf Stapel und/oder
 Registern
          else { // Client-seitiger Stub für Test(a, b) ...
          // Meldung zum Senden konstruieren
          struct m_test m = malloc (sizeof (struct m_test)) ;
          m->a = a;
          m->b = b;
          m->header = ... xxx ...;
          // Aufruf über Transport ausführen
          _RPC_CALL_("test", m); 



          // der Ziel-Host kehrt die obigen Vorgänge um und ruft dann test(a, b) an
 dem Ziel auf.
          }

Im Gegensatz führt die hierin beschriebene Technologie die folgende Vereinheitlichung und Vereinfachung über den Compiler 4700 aus. Der Compiler 4700 würde für den Aufruf zu test(a, b) Folgendes erzeugen:

          stack.header = test_specific_header; // Identifikation von 'Test- Funktion'
 ,
          // wie eine 32- oder 64-Bit-ID, die ein Index in vtable für diese Funktion
 sein kann
          stack.a=a;
          stack.b=b;
          stack.epilogue=test_ specific_epilogue; // enthält Rahmengröße und kann
          // zusätzlich etwas Anderes sein.
          // Rahmengröße/Nutzlast ermöglicht generische RPC-Umsetzung
          call [test]; // indirekter Aufruf unter Verwenden von vtable (Tabelle
          virtuelles Verfahren)

Darüber hinaus, falls der Aufruf ein entfernter Inter-Prozesskommunikationsaufruf (Inter-Process Communication - IPC-Aufruf) ist, kann ein generischer RPC-Handler ausführen:

#define _SES sizeof (stack.epilogue) // einen Aufruf zu der

 Funktion ausführen
          // wie in dem Header definiert, unter Verwenden von Stapelinhalt als
          Nutzlast, und Nutzlastgröße
          send(stack.header.id,&stack- _ SES _,_SES _);

Wobei SES auf die Stapelepiloggröße verweist (zum Beispiel ein Makro-Ersatz, der zur Klarheit des Codes verwendet wird). Wie bereits erwähnt, kann die Nutzlast einen Identifikator der aufgerufenen Funktion, eine Größe der Nutzlast und Werte von Parametern enthalten (zum Beispiel unter Vermeiden irgendwelcher Pointer/Referenzen, die ansonsten domänenübergreifende Aufrufe verhindern würden).

47B zeigt eine höhere Architektur 4712, bei der ein Fernaufruf zum Senden auf seinem Stapel auf dieselbe Weise angeordnet wird wie ein lokaler Aufruf, der auf dem lokalen System ausgeführt wird.

Unter Bezugnahme auf 47C ist ein Verfahren für 4720 zum Rangieren von Funktionsaufrufen gezeigt. Das Verfahren 4720 kann im Allgemeinen in einem verbesserten FaaS-System, wie zum Beispiel dem System 202 (2), dem System 300 (3), und/oder dem System 400 (4), die bereits besprochen wurden, umgesetzt werden. Insbesondere kann das Verfahren 4620 in einem oder mehreren Modulen eines Satzes logischer Anweisungen, die in einem maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.

Der veranschaulichte Verarbeitungsblock 4722 stellt das Bestimmen einer Nutzlast für eine Funktion bereit. Bei einem Beispiel beinhaltet die Nutzlast einen oder mehrere Parameterwerte, die Größe der Nutzlast und einen Identifikator der Funktion. Block 4724 platziert zur Kompilierungszeit die Nutzlast auf einen Aufrufstapel, wobei die Funktion einheitlich über die Nutzlast entweder als eine lokale Instanz oder eine Ferninstanz aufrufbar ist. Zusätzlich kann Block 4726 bei Runtime bestimmen, ob die Funktion als die lokale Instanz aufgerufen werden soll oder die Nutzlast zu einer entfernten Plattform transportiert werden soll. Das veranschaulichte Verfahren 4720 eliminiert folglich Engpässe in Verbindung mit dem ineffizienten Rangieren von Funktionsparametern. Verbesserte Performance, minimal Administration und größere Skalierbarkeit können folglich erzielt werden.

Effizienteres Datenrangieren kann folglich ein Verstreuen/Sammeln von Datenstrukturen mit optionaler Bitfolge- (MSB/LSB) und Typtranscodierung involvieren. Unter spezifischer Berücksichtigung optionalen Bitordnens kann es bei einigen Umsetzungen (zum Beispiel wenn Aufrufe zwischen heterogenen Architekturen, angenommen INTEL <-> MIPS oder ARM erfolgen), wichtig sein, die Reihenfolge von Bytes in Multi-Byte-Typen (zum Beispiel 32-Bit-Ganzzahl oder Fließkomma). Eine 32-Bit-Ganzzahl 0x12345678 kann zum Beispiel als die folgende Abfolge von Bytes codiert werden: 0x78, 0x56, 0x34, 0x12 for LSB (niedrigstwertiges Byte/Bit zuerst) oder als 0x12, 0x34, 0x56, 0x78 für MSB (höchstwertiges Byte/Bit zuerst). Der Empfänger könnte folglich die Reihenfolge auf der Last umkehren müssen, was auf vielen Architekturen mit einer speziellen Anweisung erfolgt. Die Technologie kann auch einen Funktionshub verwenden, um zwischen CPU-basierter Parameterweitergabe und entweder entfernten Aufrufen oder aufrufen, die von einem Beschleuniger-Offload gehandhabt werden, zu übersetzen. Das Ziel, an dem die Arbeit auftritt, erscheint dem Aufrufer folglich gleich wie ein lokaler Prozessaufruf.

Zusätzliche Anmerkungen und Beispiele

Beispiel 4701 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, eine Nutzlast für eine Funktion zu bestimmen, und zur Kompilierungszeit einen Code zu platzieren, der die Nutzlast auf einen Call-Stack in einem Format baut, das Informationen enthält, die zum Ausführen eines Aufrufs ausreichen, wobei die Funktion einheitlich über die Nutzlast als eine lokale Instanz, eine Ferninstanz oder Hardware aufrufbar ist.

Beispiel 4702 beinhaltet mindestens ein computerlesbares Speichermedium des Beispiels 4701, wobei die Nutzlast einen oder mehrere Parameterwerte, eine Größe der Nutzlast und einen Identifikator der Funktion beinhaltet.

Beispiel 4703 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 4701, wobei die Anweisungen, wenn sie ausgeführt werden, das Rechengerät veranlassen, zur Laufzeit zu bestimmen, ob die Funktion als die lokale Instanz aufgerufen werden soll oder ob die Nutzlast zu einer entfernten Plattform transportiert werden soll.

Beispiele für Fähigkeitstransfer

Während des Betriebs eines FaaS-Systems werden die Fähigkeiten einer Funktion (zum Beispiel Quellfunktion) oft zu einer anderen Funktion (zum Beispiel Zielfunktion), die lokal (zum Beispiel mit gemeinsamen Verwenden von Speicherbereichen mit der Quellfunktion) oder entfernt (zum Beispiel ohne gemeinsames Verwenden von Speicherbereichen mit der Zielfunktion) sein kann. Wenn die Funktionen unprivilegiert sind (zum Beispiel Privileg Ring 3), sind Sicherheitsmaßnahmen zweckmäßig, um sicherzustellen, dass die Fähigkeiten, die zwischen Funktionen weitergegeben werden, legitim sind. Wie ausführlicher besprochen wird, wird verbesserte Technologie, die von dem verbesserten FaaS-System eingesetzt wird, wie die in 4 gezeigte, verwendet, um ein Entwicklungserfordernis oder Einsetzen einer vertrauenswürdigen Software-Laufzeit zu reduzieren, um Funktionsfähigkeiten in einer komplexen Softwarearchitektur zu erzeugen. Darüber hinaus eliminiert die Technologie Aufwand, der mit dem Transferieren von HTTP-Meldungen und Kopieren von Daten bei Einstellungen mit gemeinsam verwendetem Speicher verbunden ist.

48A zeigt ein Szenario, bei dem eine erste Funktion 4800 (Quellfunktion „f3“) Fähigkeitsinformationen 4802 zu einem vertrauenswürdigen Warteschlangenmanager 4804 in Verbindung mit einem Aufruf einer zweiten Funktion 4806 (Zielfunktion „f4“) sendet. Bei dem veranschaulichten Beispiel bestimmt die vertrauenswürdige Warteschlangenmanager 4804, ob die Fähigkeitsinformationen 4802 in Bezug auf ein erstes Authentifizierungsformat 4808 gültig (zum Beispiel authentisch) sind, wobei die Fähigkeitsinformationen 4802 und das erste Authentifizierungsformat 4808 der ersten Funktion 4800 entsprechen. Bei einer Ausführungsform wird das erste Authentifizierungsformat 4808 von der ersten Funktion 4800 erkannt und involviert, dass der vertrauenswürdige Warteschlangenmanager 4804 einen ersten Schlüssel (nicht gezeigt), der der ersten Funktion 4800 zugewiesen ist, verwendet, um zu bestimmen, ob die Fähigkeitsinformationen 4802 gültig sind. Insbesondere kann der vertrauenswürdige Warteschlangenmanager 4804 den ersten Schlüssel mit einem Meldungsauthentifizierungscode (Message Authentication Code - MAC), der in den Fähigkeitsinformationen 4802 eingebettet ist, vergleichen. Alternativ können die Fähigkeitsinformationen 4802 derart verschlüsselt werden, dass das Korrumpieren der Fähigkeitsinformationen 4802 keine vorhersagbare und verwendbare Funktionalität für einen Gegner bereitstellt.

Falls der vertrauenswürdige Warteschlangenmanager 4804 bestimmt, dass die Fähigkeitsinformationen 4802 in Bezug auf das erste Authentifizierungsformat 4808 gültig sind, speichert (einreihen) der vertrauenswürdige Warteschlangenmanager 4804 die Fähigkeitsinformationen zu einer vertrauenswürdigen Warteschlange (nicht gezeigt). Der veranschaulichte vertrauenswürdige Warteschlangenmanager 4804 erzeugt und sendet auch Fähigkeitsinformationen 4803 zu der zweiten Funktion 4806 in Übereinstimmung mit einem zweiten Authentifizierungsformat 4810, das der zweiten Funktion 4806 entspricht. Bei einer Ausführungsform wird das zweite Authentifizierungsformat 4810 von der zweiten Funktion 4806 erkannt und involviert das Authentifizieren der Fähigkeitsinformationen 4803 mit einem zweiten Schlüssel (nicht gezeigt), der der zweiten Funktion 4806 zugewiesen ist. Bei einer Ausführungsform beinhaltet das Authentifizieren das Neuberechnen eines MAC unter Verwenden des zweiten Schlüssels und das Vergleichen des Resultats mit einem MAC, der in den Fähigkeitsinformationen 4803 eingebettet ist. Das erste Authentifizierungsformat 4808 ist daher typischerweise von dem zweiten Authentifizierungsformat 4810 unterschiedlich.

Das Umsetzen des vertrauenswürdigen Warteschlangenmanagers 4804 als ein Hardware-Warteschlangenmanager (HQM) eliminiert jedes Erfordernis einer vertrauenswürdigen Software-Laufzeit, um die Fähigkeitsinformationen 4802, 4803 in einer komplexen Softwarearchitektur zu erzeugen. Darüber hinaus eliminiert der vertrauenswürdige Warteschlangenmanager 4804 Aufwand in Verbindung mit dem Transferieren von Meldungen (zum Beispiel in HTTP-Format oder einem anderen Format, das von f3 zu f4 transferiert werden kann) und Kopieren von Daten in Einstellungen mit gemeinsam verwendetem Speicher. Die Funktionen 4800, 4806 können tragbare Funktionen (zum Beispiel mit tragbaren Identitäten) in dem Maße sein, dass ein Lastausgleicher Funktionen 4800, 4806 durch das FaaS-System hindurch dynamisch bewegt.

48B zeigt codierte Inline-Fähigkeitsinformationen (Encoded Inline Capability - (EIC-Informationen) 4812 (4812a bis 4812c), die ohne Weiteres für die Fähigkeitsinformationen 4802, 4803 (48A), die bereits besprochen wurden, ersetzt werden können. Bei dem veranschaulichten Beispiel beinhalten die EIC-Informationen 4812 einen MAC 4812a, Grenzinformationen 4812b und einen Pointer 4812c. Bei einem Beispiel ist der MAC 4812a ein Tag, das von einer verschlüsselten Einweg-Hash-Funktion basierend auf den Grenzinformationen 4812b angelegt wird, wobei sich der Geheimschlüssel, der dazu verwendet wird, den MAC 4812a anzulegen, in einem geschützten Bereich (zum Beispiel auf dem Host-Prozessor) befindet. Der MAC 4812a wird folglich zum Bestätigen, dass die EIC-Informationen 4812 von dem angegebenen Sender kommen und nicht geändert wurden, verwendet.

Der veranschaulichte MAC 4812a schützt folglich sowohl die Integrität als auch die Authentizität der EIC-Informationen 4812, indem er es Prüfern, die auch den geheimen Schlüssel besitzen, ermöglicht, irgendwelche Änderungen an den EIC-Informationen 4812 zu erfassen. Bei einem Beispiel referenziert der Pointer 4812c einen Speicherbereich, der von den Grenzinformationen 4812b definiert ist. Wenn daher ein Speicherzugriff von einer Funktion versucht wird, wird der MAC 4812a geprüft, um sicherzustellen, dass der Pointer, der bei dem Zugriff verwendet wird, legitim ist und innerhalb des Speicherbereichs, der von den Grenzinformationen 4812b definiert wird, liegt.

Bei einer Ausführungsform beinhalten die EIC-Informationen 4812 hierarchische codierte Inline-Fähigkeiten. Eine zusammengesetzte EIC könnte zum Beispiel eine Subgruppe von EICs beinhalten, die wiederum virtuellen (zum Beispiel Multi-Casting) Kanälen in einer mehrstufigen Hierarchie entsprechen. Zusätzlich können die EIC-Informationen 4812 Benutzerebenen-Interrupts (ULIs) als eine Fähigkeit beinhalten, und der Prozess-Adressraumidentifikator (PASID) kann mit den EIC-Informationen 4812 eingereiht werden.

48C zeigt einen Hardware-Warteschlangenmanager 4814, der ohne Weiteres den vertrauenswürdigen Warteschlangenmanager 4804 (48A), der bereits besprochen wurde, ersetzen kann. Bei dem veranschaulichten Beispiel führt der Hardware-Warteschlangenmanager 4814 einen Satz von Warteschlangen 4816, wobei jede Warteschlange 4816 Fähigkeitsinformationen für eine spezifische Funktion oder einen Satz von Funktionen enthält. Die veranschaulichte Lösung setzt folglich virtuelle Kanäle unter Verwenden von Hardware-Management eingereihter Fähigkeiten durch. Der Hardware-Warteschlangenmanager 4814, der Systemebenenprivilegien genießt (zum Beispiel privilegierter als Ring 3) kann auch Schlüsselinformationen 4818 mit einem entfernten Hardwarewarteschlangenmanager 4820 (zum Beispiel über Kanten in einer anderen Plattform/Maschine hinweg) austauschen. Bei einer Ausführungsform übernimmt der Hardware-Warteschlangenmanager 4814 auch die Verantwortung für das Aktualisieren anderer Kontextinformationen, wie zum Beispiel des Schlüssels, der zum Authentifizieren von Fähigkeiten verwendet wird, Bereichsregister, die die Grenzen eines privaten Datenbereichs für jede Funktion angeben und so fort. Der Hardware-Warteschlangenmanager 4814 stellt folglich im Vergleich zu einer herkömmlichen Wurzelschutzdomäne (Protection Domain - PD) 4815, die in Ring 3 resident ist, dar, und wirkt als vertrauenswürdige Software-Laufzeit zum Erzeugen von Funktionsfähigkeiten. Einige herkömmliche Wurzel-PD können zum Beispiel als unprivilegierte Software (zum Beispiel in Ring 3 einer CPU oder in einem anderen unprivilegierten Modus auf Prozessoren), die Zugriff auf den gesamten Speicher innerhalb eines Prozesses besitzt, umgesetzt werden. Die Software ist für das Initialisieren der Register privater Datenbereichsgrenzen, das Initialisieren eines Fähigkeitsauthentifizierungsschlüsselregisterregisters und Erzeugen codierter Inline-Fähigkeiten in Zusammenhang mit Bereichen von Speicher in dem Bereich gemeinsam verwendeter Daten, auf die besondere Nicht-Wurzel-PDs Zugriffsberechtigung besitzen, was die Effizienz verschlechtert, zuständig. Bei einem Beispiel befindet sich der Hardware-Warteschlangenmanager 4814 der aktuellen Ausführungsform in einem Host-Prozessor (zum Beispiel CPU), der erfasst, wenn aufgrund des Aufrufs einer unterschiedlichen Funktion ein Kontextwechsel bevorsteht.

48D zeigt ein Verfahren 4822 zum Betreiben eines Hardware-Warteschlangenmanagers. Das Verfahren 4822 kann im Allgemeinen von einem Warteschlangenmanager, wie zum Beispiel dem vertrauenswürdigen Warteschlangenmanager 4804 (48A) und/oder dem Hardware-Warteschlangenmanager 4814 (48C), die bereits besprochen wurden, umgesetzt werden. Insbesondere kann das Verfahren 4822 als ein oder mehrere Module in einem Satz logischer Anweisungen, die in einem nichtflüchtigen maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.

Der veranschaulichte Verarbeitungsblock 4824 bestimmt, ob Fähigkeitsinformationen in Bezug auf ein erstes Authentifizierungsformat gültig/authentisch sind, wobei die Fähigkeitsinformationen und das erste Authentifizierungsformat einer ersten Funktion entsprechen. Bei einem Beispiel verwendet Block 4824 einen ersten Schlüssel, der mit der ersten Funktion verbunden ist, um bestimmen, ob die Fähigkeitsinformationen gültig sind. Ist das der Fall, speichert Block 4826 (reiht sie zum Beispiel ein) die Fähigkeitsinformationen in einer vertrauenswürdigen Warteschlange. Bei einem Beispiel beinhalten die Fähigkeitsinformationen hierarchische codierte Inline-Fähigkeiten.

Die Fähigkeitsinformationen werden bei Block 4828 zu einer zweiten Funktion in Übereinstimmung mit einem zweiten Authentifizierungsformat, das der zweiten Funktion entspricht, transferiert. Bei einer Ausführungsform spezifiziert das zweite Authentifizierungsformat die Verwendung eines zweiten Schlüssels, der mit der zweiten Funktion verbunden ist, um die Fähigkeitsinformationen während der Übertragung zu der zweiten Funktion zu schützen und zu authentifizieren. Bei einem Beispiel sind die erste Funktion und die zweite Funktion tragbare Funktionen. Das veranschaulichte Verfahren 4822 reduziert folglich jedes Erfordernis einer vertrauenswürdigen Software-Laufzeit, um Funktionsfähigkeiten in einer komplexen Softwarearchitektur zu erzeugen. Darüber hinaus eliminiert die Technologie Aufwand, der mit dem Transferieren von Meldungen und Kopieren von Daten bei Einstellungen mit gemeinsam verwendetem Speicher verbunden ist.

48E zeigt ein Verfahren 4830 zum Einreihen einer Fähigkeit gemäß einer Ausführungsform. Das Verfahren 4830 kann im Allgemeinen von einem Warteschlangenmanager, wie zum Beispiel dem vertrauenswürdigen Warteschlangenmanager 4804 (48A) und/oder dem Hardware-Warteschlangenmanager 4814 (48C), die bereits besprochen wurden, umgesetzt werden. Insbesondere kann das Verfahren 4830 als ein oder mehrere Module in einem Satz logischer Anweisungen, die in einem nichtflüchtigen maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.

Der veranschaulichte Verarbeitungsblock 4832 erfasst eine oder mehrere Serviceanforderungen zum Einreihen einer Fähigkeit unter Verwenden einer neuen Anweisung (zum Beispiel ENQCAP), die die Fähigkeit, gesendet zu werden, sowie ihren beabsichtigten Zielort spezifiziert. Der Zielort kann zum Beispiel als eine global oder lokal eindeutige Service-ID spezifiziert werden. Bei dem veranschaulichten Block 4834 verwendet ENQCAP den aktuellen Fähigkeitsauthentifizierungsschlüssel zum Authentifizieren der bereitgestellten Fähigkeit. Falls die Authentifizierung erfolgreich ist, extrahiert ENQCAP Block 4836 die Grenzen- und Pointer-Informationen aus der Fähigkeit. ENQCAP Block 4838 identifiziert dann die entsprechende Zielwarteschlange für die extrahierten Informationen. Diese Vorgehensweise kann zum Beispiel das Übersetzen der Service-ID zu der ID eines Prozessors, der zum Hosten des Diensts zugeordnet wurde, involvieren. Jeder Dienst kann zu einem oder mehreren Prozessoren verriegelt werden, oder es kann möglich sein, den Dienst auf einem beliebigen Prozessor in einem System aufzurufen. Es kann sogar möglich sein, einen Dienst auf einem Prozessor in einem unterschiedlichen System automatisch aufzurufen. Ein solcher Aufruf würde das Kopieren der Daten, die von der Fähigkeit referenziert sind, zu dem Zielsystem erfordern. Es kann auch das Kopieren des Codes für den Dienst zu dem Zielsystem erfordern.

Ein Netzwerkprotokoll zum Kommunizieren mit dem Zielsystem kann erforderlich sein. Das Betriebssystem kann zum Beispiel für das Einrichten der Anknüpfung zwischen Hardware-Warteschlangenmanagerinstanzen auf unterschiedlichen Systemen zuständig sein. Die Hardware-Warteschlangenmanager können dann miteinander kommunizieren. Der veranschaulichte Verarbeitungsblock 4840 reiht Pointer- und Grenzeninformationen in die Zielwarteschlange gemeinsam mit der Ziel-Service-ID ein. Die Service-Ausführung kann dann bei Block 4842 fortgesetzt werden. Falls bei Block 4834 bestimmt wird, dass die bereitgestellte Fähigkeit nicht authentisch ist, wird eine Ausnahme bei dem veranschaulichten Block 4844 erzeugt.

48F zeigt ein Verfahren 4831 zum Ausreihen einer Fähigkeit gemäß einer Ausführungsform. Das Verfahren 4831 kann im Allgemeinen von einem Warteschlangenmanager, wie zum Beispiel dem vertrauenswürdigen Warteschlangenmanager 4804 (48A) und/oder dem Hardware-Warteschlangenmanager 4814 (48C), die bereits besprochen wurden, umgesetzt werden. Insbesondere kann das Verfahren 4831 als ein oder mehrere Module in einem Satz logischer Anweisungen, die in einem nichtflüchtigen maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.

Der veranschaulichte Verarbeitungsblock 4833 erfasst eine Anforderung zum Ausreihen von Pointer- und Grenzeninformationen sowie eine Ziel-Service-ID. Bei Block 4835 kann eine Bestimmung erfolgen, ob der Ziel-Service derzeit geladen ist. Ist das nicht der Fall, lädt der Block 4837 Code und Daten für den Zielservice und ordnet einen privaten Datenbereich zu. Zusätzlich werden bei Block 4839 die Register der privaten Datenbereichsgrenzen initialisiert, um den privaten Datenbereich für den Zielservice zu decken. Bei einer Ausführungsform initialisiert Block 4841 ein Fähigkeitsauthentifizierungsschlüsselregister mit zufällig erzeugten Daten. Der Schlüssel in dem Authentifizierungsschlüsselregister wird als eine Eingabe beim Erzeugen des MAC in einer codierten (zum Beispiel verschlüsselten) Inline-Fähigkeit und/oder Meldung verwendet. Da Nicht-Wurzel-PDs nicht fähig sind, den Schlüssel zu lesen oder auf ihn zuzugreifen, hilft die Verwendung des Schlüssels dabei, Nicht-Wurzel-PDs daran zu hindern, Fälschungsfähigkeiten zu haben. Der veranschaulichte Verarbeitungsblock 4843 erzeugt eine codierte Inline-Fähigkeit, die ausgereihte Pointer- und Grenzeninformationen darstellt und den erzeugten EIC in einem Register derart speichert, dass der Zielservice darauf zugreifen kann. Block 4845 transferiert die Steuerung zu dem Zielservice. Falls bei Block 4835 bestimmt wird, dass der Zielservice aktuell geladen ist, kann das Verfahren 4831 den Block 4837 umgehen.

Zusätzliche Anmerkungen und Beispiele

Beispiel 4801 beinhaltet ein Halbleitergerät, das ein oder mehrere Substrate umfasst, und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, wobei die Logik mindestens teilweise in konfigurierbare Logik oder Hardware-Logik mit feststehender Funktionalität umgesetzt wird, die Logik mit dem einen oder den mehreren Substratdaten gekoppelt ist, um zu bestimmen, ob Fähigkeitsinformationen in Bezug auf ein erstes Authentifizierungsformat gültig sind, wobei die Fähigkeitsinformationen und das erste Authentifizierungsformat einer ersten Funktion entsprechen, die Fähigkeitsinformationen zu einer Warteschlange zu speichern, falls die Fähigkeitsinformationen in Bezug auf das erste Authentifizierungsformat gültig sind, und die Fähigkeitsinformationen zu einer zweiten Funktion in Übereinstimmung mit einem zweiten Authentifizierungsformat, das der zweiten Funktion entspricht, zu transferieren, wobei die erste Funktion und die zweite Funktion tragbare Funktionen sind, und wobei die Fähigkeitsinformationen hierarchische codierte Inline-Fähigkeiten und Benutzerebenen-Interrupts beinhalten.

Beispiel 4802 beinhaltet ein Halbleitergerät, das ein oder mehrere Substrate umfasst, und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, wobei die Logik mindestens teilweise in konfigurierbare Logik oder Hardware-Logik mit feststehender Funktionalität umgesetzt wird, die Logik mit dem einen oder den mehreren Subdaten gekoppelt ist, um einen Ausreihungspointer und Grenzeninformationen und Zielservice-ID, die mit einer Funktion verbunden ist, die ausgeführt werden soll, zu bestimmen, als Reaktion darauf, dass der Zielservice aktuell nicht geladen ist, Code und Daten, die mit der Funktion verbunden sind für den identifizierten Zielservice zu laden und einen privaten Datenbereich für das Ausführen der Funktion zuzuordnen, und die Steuerung zu dem identifizierten Zielservice zu transferieren, wobei das Zuordnen des privaten Datenbereichs zum Ausführen der Funktion das Initialisieren eines oder mehrerer privater Datenbereichsgrenzenregister zum Decken des privaten Datenbereichs für den Zielservice, das Initialisieren von Fähigkeitsauthentifizierungsschlüsselregister mit zufällig erzeugten Daten, das Erzeugen codierter Inline-Fähigkeit, die ausgereihte Pointer- und Grenzinformationen darstellt, und das Speichern der codierten Inline-Fähigkeit in dem Register zum Zugreifen durch den Zielservice umfasst.

Beispiele für Intra-Adressraum-Abschottung

Total Memory Encryption (TME) kann den gesamten Speicher einer Plattform (zum Beispiel diverse Cache-Ebenen) mit einem einzigen Schlüssel verschlüsseln. TME kann durch BIOS-Konfiguration und/oder andere Software aktiviert werden, und kann dabei helfen sicherzustellen, dass alle Daten (zum Beispiel Kundenreferenzen, Verschlüsselungsschlüssel und andere IP- oder persönliche Informationen) in dem Speicher auf dem externen Speicherbus verschlüsselt wird. Falls eine Anwendung und/oder CPU-Daten aus dem Speicher anfordert, können die Daten daher verschlüsselt und dann später, nach der Übertragung, entschlüsselt werden.

Der Verschlüsselungsschlüssel, der zur Speicherverschlüsselung verwendet wird, kann unter Verwenden eines gehärteten Zufallszahlengenerators in der CPU und/oder einem vertrauenswürdigen Plattformmanager erzeugt werden. Bei einigen Ausführungsformen wird der Schlüssel eventuell nie mit Software exponiert, wodurch das Potenzial für böswilligen Datendiebstahl und/oder Kreuzkontamination von Schlüsselnutzung reduziert wird. Bei anderen Ausführungsformen kann die Software fähig sein, auf die Schlüssel durch Schlüssel-IDs zuzugreifen.

Daten im Speicher und auf den externen Speicherbussen können verschlüsselt werden, und sie können in Klartext entschlüsselt werden, während sie innerhalb der CPU sind, und/oder von einem vertrauenswürdigen Plattform Manager (Trusted Platform Manager - TPM), ähnlich wie typische Speicherverschlüsselung. Das erlaubt es existierender Software, unverändert zu laufen, während der Speicher unter Verwenden der TME geschützt wird. Die TME kann angepasst werden, um nur einen Abschnitt (zum Beispiel einen besonderen physischen Adressbereich) des Speichers zu verschlüsseln, während ein anderer Abschnitt (zum Beispiel ein anderer physischer Adressbereich) des Speichers unverschlüsselt bleiben soll. Software, die auf einem TME-fähigen System läuft, kann ein Konfigurationsregister in der CPU lesen, um volle Sicht auf die unverschlüsselten Abschnitte des Speichers zu haben, die dazu konfiguriert sind, nicht von der TME verschlüsselt zu werden.

Multi-Key-TME (MK-TME) erweitert TME, um mehrere Verschlüsselungsschlüssel zu unterstützen, um die Fähigkeit bereitzustellen, die Verwendung eines spezifischen Schlüssels für nur einen Abschnitt (zum Beispiel Seite und/oder physischer Adressbereich) des Speichers bereitzustellen. MK-TME erlaubt lokal erzeugte Schlüssel (zum Beispiel TME-erzeugte Schlüssel und/oder CPU-erzeugte Schlüssel) und/oder Drittparteischlüsseln (zum Beispiel vom Mieter bereitgestellte Schlüssel, die außerhalb der Plattform an einem entfernten Ort erzeugt werden), was Kunden volle Anpassungsfähigkeit erlaubt. Der Speicher kann daher gemäß mehreren Verschlüsselungsschlüsseln verschlüsselt werden. Ein erster Adressbereich kann somit gemäß einem ersten Schlüssel verschlüsselt werden, und ein zweiter Adressbereich kann gemäß einem zweiten Schlüssel verschlüsselt werden.

MK-TME erlaubt es virtuellen Maschinen (VMs) und Containern, kryptografisch voneinander im Speicher ohne separate Verschlüsselungsschlüssel isoliert zu sein. In einer Multimieter-Cloud-Umgebung erweist sich eine solche Isolation als vorteilhaft, wenn sensible Daten von einem Kunden verarbeitet werden.

VMs und Container kann es unter bestimmten Umständen erlaubt werden, einen individuellen Schlüssel gemeinsam zu verwenden, was den Maßstab und die Flexibilität weiter erweitert. Falls eine erste FaaS-Funktion zum Beispiel eine zweite FaaS-Funktion aufruft, kann es sowohl der ersten als auch der zweiten Funktion erlaubt werden, auf dieselben Daten zuzugreifen. Bei einem anderen Beispiel kann derselbe Kunde zwei Funktionen aufrufen, wobei eine Funktion Daten erzeugt und die andere Funktion die erzeugten Daten verbraucht. Es kann den zwei Funktionen erlaubt werden, Schlüssel, wie oben beschrieben, gemeinsam zu verwenden.

Die MK-TME kann daher verwendet werden, um Funktionen voneinander durch Verschlüsseln des Speicherbereichs, der jeder Funktion zugewiesen ist, mit unterschiedlichen Verschlüsselungsschlüsseln zu isolieren/abschotten. Ein solcher Ansatz reduziert ein Erfordernis, die Funktionen separaten linearen Adressbereichen, die separate Seitentabellen aufweisen, zuzuweisen, was ansonsten zu dem Aufwand des Aufrufens des OS-Kernels, Wechseln von Seitentabellen und Neufüllen des Translation Lookaside Buffer (TLB, der die kürzlichen Übersetzungen des virtuellen Speichers in physischen Speicher speichert) führen würde. Obwohl die unten stehende Beschreibung unter Bezugnahme auf Funktionen, die auf Daten durch Schlüssel zugreifen, beschrieben ist, kann man verstehen, dass die Funktionen in Verbindung mit darunter liegender Hardware (zum Beispiel CPU oder TPM) arbeiten können, um Daten zu entschlüsseln. Die Funktion kann zum Beispiel auf eine solche Weise geführt werden, dass die CPU und/oder der Prozessor Daten aus dem Speicher abruft und die Daten entschlüsselt, wodurch es der Funktion erlaubt wird, auf die Daten zuzugreifen.

49A zeigt eine Abbildung zwischen einem Satz von Schlüsselidentifikatoren (IDs) 4900 (4900a bis 4900d) und einem Satz von Verschlüsselungsschlüsseln 4902 (4902a bis 4902f), die zum Verschlüsseln von Speicherbereichen in einem gemeinsam verwendeten linearen Adressbereich verwendet werden. Bei dem veranschaulichten Beispiel wird eine erste Schlüssel-ID 4900a einem ersten Schlüssel 4902a und einem zweiten Schlüssel 4902b zugeordnet, eine zweite Schlüssel-ID 4900b bildet zu einem dritten Schlüssel 4902c ab, eine dritte Schlüssel-ID 4900c bildet zu einem vierten Schlüssel 4902d und einem fünften Schlüssel 4902e ab, und eine vierte Schlüssel-ID 4900d bildet zu einem sechsten Schlüssel 4902f ab. Die veranschaulichte Abbildung ermöglicht es folglich den Schlüssel-IDs 4900, über die Schlüssel 4902 wiederverwendet zu werden. Falls zum Beispiel die Funktion, die dem ersten Schlüssel 4902a entspricht, endet oder der Speicherbereich, der mit dem ersten Schlüssel 4902a verschlüsselt ist, anderswie freigegeben wird, kann die erste Schlüssel-ID 4900a automatisch dem zweiten Schlüssel 4902b ohne Wechseln von Seitentabellen neu zugewiesen werden.

49B zeigt ein Beispiel eines eindeutigen Adressraums 4901, in dem Schlüssel-ID-Multiplexen (kID-Multiplexen) nicht auf Schlüssel und Schlüssel-IDs für private Bereiche begrenzt ist. Bei dem veranschaulichten Beispiel bildet kID1 zu k7 in beiden Funktionen f1 und f3 ab, kID2 bildet zu k9 in Funktion f2 ab und kID3 bildet zu k9 in f4 ab. Diese zwei letzteren Abbildungen veranschaulichen, dass ein einziger darunter liegender Schlüssel von mehreren Schlüssel-IDs zugewiesen werden kann, was in 49A nicht unbedingt offensichtlich ist.

49C zeigt ein Beispiel, bei dem eine erste Funktion 4904 einen ersten Speicherbereich 4906, der mit dem vierten Schlüssel 4902d verschlüsselt ist, verwendet (zum Beispiel daraus liest und/oder darin schreibt). Bei dem veranschaulichten Beispiel ist die dritte Schlüssel-ID 4900c anfänglich dem vierten Schlüssel 4902d zugewiesen. Wenn ein Kontextwechsel von der ersten Funktion 4904 zu einer zweiten Funktion 4908 auftritt, wird die dritte Schlüssel-ID 4900c automatisch dem fünften Schlüssel 4902e zugewiesen, der dazu verwendet wird, einen zweiten Speicherbereich 4910, der mit der zweiten Funktion 4908 verbunden ist, zu verschlüsseln. Besonders bemerkenswert ist, dass der erste Speicherbereich 4906 und der zweite Speicherbereich 4910 in einem gemeinsam verwendeten linearen Adressbereich 4912 liegen. Die veranschaulichte Lösung eliminiert folglich den Aufwand des Aufrufens des OS-Kernels, des Wechsels von Seitentabellen und des Wiederfüllens des TLB mit Übersetzungen von virtuellem Speicher zu physischem Speicher. Die veranschaulichten Speicherbereiche 4906, 4910 können auch gemäß den Schlüsseln (jeweils „k9“ und „k7“), die zum Verschlüsseln gemeinsam verwendeter Speicherbereiche verwendet werden, verschlüsselt werden.

Insbesondere sollten Funktionen, die über gemeinsam verwendeten Speicher kommunizieren müssen, Zugang zu Schlüsseln, die verwendet werden, um entsprechende Bereiche des gemeinsam verwendeten Speichers zu verschlüsseln, gemeinsam verwenden. Falls zum Beispiel die Funktionen f1 und f3 durch einen gemeinsam verwendeten Speicherbereich 4910 kommunizieren müssen, kann dieser Bereich unter Verwenden von k7 verschlüsselt werden, und eine Schlüssel-ID in jeder Funktion kann zu k7 abgebildet werden. Die Schlüssel-ID kann in beiden Funktionen gleich oder unterschiedlich sein. Wichtig ist, dass beide Funktionen fähig sind, k7 zu verwenden. Es kann jedoch von einigem Vorteil sein, beide Funktionen dieselbe Schlüssel-ID verwenden zu lassen, da Schlüssel-IDs über physische Adressbits ermittelt werden können. Das gemeinsame Verwenden einer Schlüssel-ID macht es einfach, nur eine einzige Linear-zu-Physisch-Adressabbildung zu haben, die den Speicherbereich, den sich f1 und f2 teilen, deckt. Ein solcher Ansatz reduziert TLB-Aufwände im Vergleich dazu, wenn man mehrere Linear-zu-Physisch-Adressabbildungen hat, die diesen Bereich decken, um unterschiedliche Schlüssel-IDs zu unterstützen.

Ein neuer Typ von Anweisung könnte zum Beispiel definiert werden, um eine Schlüssel-ID zu wechseln, um zu einem unterschiedlichen Schlüssel abzubilden. Dieser Anweisungstyp könnte darauf beschränkt werden, nur innerhalb eines bestimmten Codebereichs (zum Beispiel unter Verwenden eines Bereichsregisters definiert) verwendbar zu sein. Der Bereich könnte konfiguriert werden, um einem Wurzel-PD-Code zu entsprechen. Die Anweisung kann es erlauben, einen Schlüssel aus einem Repository von Schlüsseln auszuwählen, das durch privilegierte Software (zum Beispiel OS oder VMM) und/oder Hardware (zum Beispiel CPU oder TPM) konfiguriert wird. Alternativ kann die Anweisung einen von Software bereitgestellten Schlüssel in eine Struktur an einem Ort, der privilegierter Software bekannt und von unprivilegierter Software unzugänglich ist, aufzeichnen. Der Prozessor kann dazu konfiguriert sein, die aktuelle Schlüssel-ID zu Schlüssel-Abbildungen für jede Funktion von dieser Struktur abzurufen. Das könnte zum Beispiel jedes Mal dann auftreten, wenn eine neue Funktion aufgerufen wird, oder die Wurzel-PD kann eine Anweisung aufrufen, um den Prozessor zu veranlassen, seinen internen Zustand basierend auf den Inhalten der In-Memory-Struktur zu aktualisieren.

Alternativ könnte eine Anweisung definiert werden, um die Schlüssel-ID in dem/den Blattseitentabelleneintrag oder -einträgen, die für das Abbilden einer einzigen virtuellen Adresse oder eines Bereich virtueller Adressen zuständig sind, zu ändern.

Es ist offensichtlich, dass jede Funktion auf Speicher unter Verwenden mehrerer Schlüssel-IDs zugreifen kann. Um die zweckdienliche Schlüssel-ID für jeden Speicherzugriff auszuwählen, kann die Funktion einen Tag-Wert in jeder virtuellen Speicheradresse spezifizieren, und dieser Tag-Wert kann zu einer entsprechenden Schlüssel-ID in der physischen Speicheradresse abgebildet werden. 49F veranschaulicht zum Beispiel einen TLB-/Seiten-Miss-Handler 4394, der zwischen virtuellen Adressen 4932 und physischen Adressen 4936 abbildet. Der TLB-/Seiten-Miss-Handler 4394 kann Teil des Prozessors sein. Der Tag-Wert der virtuellen Adressen 4932 wird verwendet, um auf einen Wert in einer Slice linearer Adressbits Bezug zu nehmen, wie physische Adressen 4936, die zu einem „Schlüssel-ID“-Wert auf irgendeine Art abgebildet werden können. „Schlüssel-ID“ wird verwendet, um auf den Wert in einem Slice physischer Adressbits Bezug zu nehmen, die zu einem Schlüssel auf eine Weise abgebildet werden können, zum Beispiel durch eine Nachschlagetabelle, die gegen die Schlüssel-ID referenziert ist. Seitentabelleneinträge können physische Adressen spezifizieren. Bei der veranschaulichten Ausführungsform übersetzt der TLB-/Seiten-Miss-Handler 4934 die virtuelle Adresse 4932 zu der physischen Adresse 4936 und kann während der Übersetzung abgesehen von dem Übersetzen des Tag-Werts den Tag-Wert ignorieren. Der Tag-Wert kann dann aus der virtuellen Adresse 4932 extrahiert und in die physische Adresse 4936 eingefügt werden. Der Prozessor kann daher die Slice der virtuellen Adressbits, die das Tag spezifiziert, extrahieren und sie in die Slice der physischen Adresse geben, die die Schlüssel-ID, wie in 49F gezeigt, spezifiziert.

Unter erneuter Bezugnahme auf 49E kann der private Datenbereich für die Wurzel-PD unter Verwenden eines separaten Schlüssels verschlüsselt werden, um gegnerische Funktionen daran zu hindern, auf seinen Klartextinhalt zuzugreifen. Es würde keine Schlüssel-ID, die von innerhalb von Funktionen verwendbar ist, zu diesem Schlüssel abbilden.

Der Code für jede Funktion und die Wurzel-PD könnte unter Verwenden eines separaten Schlüssels verschlüsselt werden, und Schlüssel-ID zu Schlüsselabbildungen könnten konfiguriert werden, um zu helfen, unbefugte Steuerflusstransfers (zum Beispiel direkt zwischen Funktionen oder von einer Funktion zu einem unbefugten Eingangspunkt in die Wurzel-PD) zu verhindern, indem jeder Funktion nur Zugang zu dem Schlüssel gewährt wird, der für ihren eigenen privaten Codebereich verwendet wird. Ein Trampolin, das einen Prozess zum Erreichen einer zweiten Lage in Code über einen Jump zu einer ersten Lage in Code beinhalten könnte, könnte eingesetzt werden. Ein Trampolin-Codeabschnitt, der Schlüssel-ID zu Schlüssel-Abbildungen beim Übertragen von Steuerung zwischen der Wurzel-PD und einer Funktion aktualisiert, könnte unter Verwenden eines Schlüssels verschlüsselt werden, der von einer Schlüssel-ID, die von allen Funktionen und der Wurzel-PD zugänglich ist. Alternativ könnte dieser Trampolin-Codeabschnitt für jede Funktion derart repliziert werden, dass jede Funktion nur einen einzigen Schlüssel zu verwenden braucht, um den gesamten Code, der in dem Kontext dieser Funktion ausgeführt wird, einschließlich des Trampolin-Codes, zu verschlüsseln.

Alternativ könnte der Code für alle Funktionen und die Wurzel-PD unter Verwenden eines einzigen, gemeinsam verwendeten Schlüssels verschlüsselt werden, und eine Vielfalt von Steuerfluss-Integritätsdurchsetzungsmechanismen könnte angewandt werden, um unbefugte Steuerflusstransfers zu verhindern. 16/024,547 beschreibt zum Beispiel mögliche Mechanismen.

49D zeigt einen einzigen Adressraum 4915, der eine Wurzelschutzdomäne 4914 (PD, zum Beispiel vertrauenswürdiger Benutzerraummonitor, der sich in einem Hostprozessor/CPU befindet), eine Vielzahl privater Datenbereiche pro Dienst 4917 und einen gemeinsam verwendeten Datenbereich 4916, der mehrere Kommunikationspuffer aufweist. Bei dem veranschaulichten Beispiel wird jeder private Datenbereich pro Dienst unter Verwenden eines unterschiedlichen Schlüssels verschlüsselt (zum Beispiel k*). Bei einer Ausführungsform führt die Wurzel-PD 4914 Abbildungsaktualisierungen aus, wenn zwischen Funktionen gewechselt wird, um den Aufwand des Aufrufens des Kernels zu verhindern. Die veranschaulichte Wurzel-PD 4914 weist daher unterschiedliche Schlüssel-IDs unterschiedlichen Schlüsseln zu, um die Häufigkeit von Schlüssel-ID-Neuzuweisungen zu minimieren. Insbesondere kann die Wurzel-PD 4914 zu einer Funktion mit einer unterschiedlichen Schlüssel-ID von der aktuellen Funktion wechseln, falls die Ziel-Schlüssel-ID bereits zu dem Schlüssel für die Zielfunktion abgebildet ist. Einige Schlüssel-IDs können von mehreren Funktionen zugänglich sein, um gemeinsame Speicherkommunikationen umzusetzen.

49E zeigt ein Verfahren 4918 zum Aktualisieren von Schlüssel-ID-Abbildungen. Das Verfahren 4918 kann im Allgemeinen von einer Wurzel-PD umgesetzt werden, wie zum Beispiel der Wurzel-PD 4914 (49D), die bereits besprochen wurde. Insbesondere kann das Verfahren 4918 als ein oder mehrere Module in einem Satz logischer Anweisungen, die in einem nichtflüchtigen maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.

Der veranschaulichte Verarbeitungsblock 4920 sorgt für das Abbilden eines Schlüsselidentifikators zu einem ersten Schlüssel, wobei der erste Schlüssel mit einer ersten Funktion und einem ersten Speicherbereich, der mit dem ersten Schlüssel verschlüsselt ist, verbunden ist. Ein Kontextwechsel von der ersten Funktion zu einer zweiten Funktion wird bei Block 4922 erfasst. Zusätzlich bildet der veranschaulichte Block 4924 den Schlüsselidentifikator zu einem zweiten Schlüssel als Reaktion auf den Kontextwechsel ab, wobei der zweite Schlüssel mit der zweiten Funktion und einem zweiten Speicherbereich, der mit dem zweiten Schlüssel verschlüsselt ist, verbunden ist. Bei einer Ausführungsform verwenden der erste Speicherbereich und der zweite Speicherbereich gemeinsam einen linearen Adressbereich. Das veranschaulichte Verfahren 4918 eliminiert folglich den Aufwand des Aufrufens des OS-Kernels, des Wechsels von Seitentabellen und des Wiederfüllens des TLB mit Übersetzungen von virtuellem Speicher zu physischem Speicher.

Zusätzlich kann der erste Schlüssel ein symmetrischer Schlüssel für eine erste Zieldomäne sein, und der zweite Schlüssel kann ein symmetrischer Schlüssel für eine zweite Zieldomäne sein. Bei einem Beispiel ist die erste Zieldomäne und/oder die zweite Zieldomäne eine Subdomäne einer Trust-Domäne. In einem solchen Fall könnte ein „Optimierungs“-Wert zusätzlich zu dem Verschlüsselungsschlüssel (der als ein „Optimierungsschlüssel“ bezeichnet werden kann) mit einer optimierbaren Chiffre verwendet werden, die es ermöglicht, eine unterschiedliche kryptografische Eingabe (zum Beispiel eine Optimierung zusätzlich zu dem üblichen Schlüssel und Klartext oder Geheimtexteingaben), der für jede Subdomäne zu spezifizieren. Das Verwenden von Optimierungsschlüsseln ist oft effizienter als das Spezifizieren eines vollständig unterschiedlichen Schlüssels für jede Subdomäne. Optimierungsschlüssel können effektiv geführte, separate, Sub-Trust-Domänen innerhalb der Trust-Domäne ohne die Kosten zusätzlicher Schlüssel, die in Hardware geführt werden, erlauben. Da eine Subdomäne immer in dem Kontext der „äußeren“ Trust-Domäne ausführt und zwei Subdomänen einander gegenseitig in einem Speicheradressraum ausschließen, bietet die Optimierung zusätzliche Pseudo-Zufälligkeit, wenn er mit der Primär-Trust-Domäne zum Erzeugen von Optimierungsschlüsseln verwendet wird. Wenn die Trust-Domäne zerstört wird, wird zusätzlich der Primärschlüssel zerstört, der der Funktion des effektiven Beseitigens aller Subdomäneninhalte dient, sowie durch Entfernen des Zugriffs auf irgendeinen der Optimierungsschlüssel.

Eine Funktion kann daran gehindert werden, auf Schlüssel zuzugreifen, zu deren Verwendung sie nicht befugt ist, indem man die Wurzel-PD diese Schlüssel von irgendwelchem Schlüssel-IDs abkoppeln lässt, die von der Funktion einzeln vor dem Aufrufen der Funktion zugänglich sind. Das kann jedoch unnötigen Performance-Aufwand einführen. Eine effizientere Alternative könnte darin bestehen, Tabellen-Abbildung-Adress-Tags zu Schlüssel-IDs zu unterstützen und einen effizienten Vorgang zum Wechseln zwischen solchen Tabellen zu unterstützen. Dies ist analog zu Seitentabellen, die virtuelle Speicheradressen zu physischen Speicheradressen abbilden. Falls die Schlüssel-Abbildungstabellen in Speicher gespeichert sein, wie es für das Unterstützen einer großen Anzahl von Funktionen vorteilhaft wäre, wäre es auch vorteilhaft, Abbildungen von Tags zu Schlüssel-IDs in einem Tag zu Schlüssel-ID-Lookaside-Buffer (TKLB) zwischenzuspeichern, der analog zu den Translation-Lookaside-Buffer (TLBs), die zum Zwischenspeichern von Abbildungen von virtueller Adresse zu physischer Adresse verwendet werden, ist. Analog dazu, wie TLB-Einträge mit einem Adressraumidentifikator (Address Space Identifier - ASID) gekennzeichnet werden können, um das Erfordernis zu minimieren, sie beim Wechseln zwischen unterschiedlichen Adressräumen zu leeren, könnten TKLB-Einträge auch mit einer Compartment-ID gekennzeichnet werden. Die Compartment-ID könnte in einem Register gespeichert werden, das nur von der Wurzel-PD zugänglich ist.

Alternativ oder zusätzlich zum Kennzeichnen zu Schlüssel-ID-Abbildung Tabellen, kann ein Mechanismus/eine Vorgehensweise definiert werden, um Zugang durch eine Funktion zu spezifischen Tag-Werten oder Schlüssel-IDs zu blockieren. Eine Bitmaske könnte in einem Register oder in einer In-Memory-Bitmap gespeichert werden, die nur von der Wurzel-PD zugänglich ist. Die Wurzel-PD könnte diese Tag-Maskenstruktur vor dem Aufrufen jeder Funktion aktualisieren, um die Tags oder Schlüssel-IDs, zu deren Verwendung die Funktion befugt ist, anzugeben. Ein gesetztes Bit in der Tag-Maskenstruktur könnte zum Beispiel angeben, dass ein besonderes Tag oder eine besondere Schlüssel-ID, die dieser Bitposition entspricht, zur Verwendung durch die Funktion befugt ist. Separate Tag-Maskenstrukturen könnten definiert werden, um Code-Holen und Datenzugriffe zu regulieren (zum Beispiel nurausführbare Speichergenehmigungen durchzusetzen). Datenzugriffe können sogar weiter als Lesen, Schreiben usw. unterteilt werden, mit separaten Tag-Maskenstrukturen, die für jeden Zugriffstyp definiert werden.

Aufrufe einer Anweisung zum Wechseln von Tag-Werten in Seitentabelleneinträgen könnten auch gegen Tag-Maskenstrukturen geprüft werden, um sicherzustellen, dass die neue Funktion zur Verwendung sowohl der ursprünglichen als auch der neuen Tag-Werte befugt ist. Die Anweisung kann einen Specifier dafür, welche Tag-Maskenstrukturen geprüft werden sollten, akzeptieren, oder sie könnten alle parallel geprüft werden.

Um Performance-Aufwände weiter zu reduzieren, kann es günstig sein, es Funktionen zu ermöglichen, Zugriff zu spezifizierten Tags zu wegzulassen. Es könnte zum Beispiel eine Anwendung definiert werden, die nur das Löschen von Bits in der Tag-Maskenstruktur unterstützt. Dieser Ansatz könnte es einer Funktion ermöglichen, Zugang zu bestimmten Tags wegzulassen, bevor ein Sub-Compartment aufgerufen wird, für ein effektives Sandboxing dieses Sub-Compartment, indem es daran gehindert wird, auf Speicherbereiche zuzugreifen, die mit dem weggelassenen Tag verbunden sind. Das Sub-Compartment würde daran gehindert, den Zugriff zu diesem Tag selbst wieder zu aktivieren.

Die Wurzel-PD kann aufgerufen werden, um Zugriff auf die Tag-Werte, die derzeit von der Tag-Maskenstruktur blockiert werden, wieder hinzuzufügen. Alternativ könnten Call-Gates mit Tag-Maskenstrukturwerten erweitert werden, um angewandt zu werden, wenn sie durch jedes Gate durchgehen.

Die Funktionalität zum Weglassen von Zugriff auf einen Tag-Wert könnte zum Durchsetzen von Speichergenehmigung nur zum Ausführen in einem Just-In-Time-Compiler (JIT-Compiler) nützlich sein, da der JIT Code zum Speicher schreiben und dann das entsprechende Tag aus der Daten-Tag-Masken Struktur nehmen kann, während er es in der Code-Tag-Maskenstruktur aktiviert lässt.

Außerdem könnte Hardware optional eine Strategie durchsetzen, die Schreibvorgänge zu ausführbarem Speicher innerhalb einer Nicht-WurzelSchutzdomäne verhindert. Wenn sie entweder für alle Tag-Werte oder für spezifische Tag-Werte aktiviert ist, könnte sie sowohl Daten schreiben als auch Tag-Maskenstrukturen zum Holen von Code prüfen, wenn eine Anweisung mit einem der Tag-Werte, für die diese Strategie aktiviert ist, geholt wird. Sie könnte das Holen blockieren, falls entweder die Tag-Maskenstruktur zum Holen den Zugriff auf das entsprechende Tag verhindert, oder falls die Datenschreib-Tag-Maskenstruktur Zugriff auf das entsprechende Tag gestattet.

Es könnte bei einigen Anwendungen unerwünscht sein, virtuelle Adressbits aufzugeben, um ein Tag zu spezifizieren. Alternativ könnte das effektive Segment jedes Speicherzugriffs zum Auswählen eines Tags oder einer Schlüssel-ID verwendet werden. Code-Holvorgänge könnten zum Beispiel ein Tag verwenden, das mit dem Codesegment (CS) verbunden ist, herkömmliche Datenzugriffe könnten ein Tag verwenden, das mit einem Datensegment (DS) verbunden ist, und Stapelzugriffe würden ein Tag, das mit dem Stapelsegment verbunden ist, verwenden. Die Verbindungen könnten allein auf dem effektiven Segment (zum Beispiel CS vs. DS), dem relevanten Segmentauswählerwert oder anderen Informationen, die innerhalb des Segmentregisters enthalten sind (zum Beispiel aus einem Segment-Deskriptortabelleneintrag geladen) basieren. Die Verbindungen zwischen Segment und Tag könnten in Registern oder in einer Tabelle im Speicher gespeichert werden. Die Verbindungsdaten könnten nur von privilegierter Software oder auch von zugelassener unprivilegierter Software aktualisierbar sein. Eine Anweisung könnte zum Beispiel definiert werden, um diese Verbindungen zu aktualisieren und ihre Verwendung könnte auf den Codebereich der Wurzel-PD eingeschränkt werden.

Zusätzliche Anmerkungen und Beispiele

Beispiel 4901 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechengerät ausgeführt werden, das Rechengerät veranlassen, einen Schlüsselidentifikator zu einem ersten Schlüssel abzubilden, wobei der erste Schlüssel mit einer ersten Funktion und einem ersten Speicherbereich, der mit dem ersten Schlüssel verschlüsselt ist, verbunden ist, einen Kontextwechsel von der ersten Funktion zu einer zweiten Funktion zu erfassen und den Schlüsselidentifikator zu einem zweiten Schlüssel als Reaktion auf den Kontextwechsel abzubilden, wobei der zweite Schlüssel mit der zweiten Funktion und einem zweiten Speicherbereich, der mit dem zweiten Schlüssel verschlüsselt ist, verbunden ist, wobei der erste Speicherbereich und der zweite Speicherbereich in demselben Adressraum sind, wobei der erste Schlüssel ein Schlüssel für eine erste Zieldomäne ist, und der zweite Schlüssel ein Schlüssel für eine zweite Zieldomäne ist, und wobei eine oder mehrere der ersten Zieldomäne oder der zweiten Zieldomänen Subdomänen einer Trust-Domäne sind.

Beispiele für Aktualisierung unprivilegierter Schutzschlüssel

50A zeigt mehrere Dienstschutzdomänen 5000 (5000a bis 5000n), die Zugriffsbefugnisse aktivieren, die für mehrere Funktionen zu spezifizieren sind. Insbesondere entsprechen die veranschaulichten Domänen 5000 mehreren „Slices“ in einem Schutzschlüsselregister (Protection Key Register - PKR, nicht gezeigt), wobei jede Slice ein Bit enthält, um jeglichen Zugriff auf eine Seite (zum Beispiel Speicherbereich) zu deaktivieren, und ein Bit, um Schreibvorgänge zu der Seite zu deaktivieren. Eine Wurzelschutzdomäne (PD) 5002 (zum Beispiel ein vertrauenswürdiger Userspace-Monitor) plant im Allgemeinen Funktionen zur Ausführung und weist jede geplante Funktion einer der Domänen 5000 zu (zum Beispiel und eine der Slices in dem Schutzschlüsselregister). Die Wurzelschutzdomäne PD 5002 könnte daher eine erste Funktion einer ersten Domäne 5000a (zum Beispiel und eine erste Slice in den PKR), eine zweite Funktion einer zweiten Domäne 5000b (zum Beispiel und eine zweite Slice in dem PKR) zuweisen und so fort. Einige Funktionen können auch Zugriff auf mehrere Slices (falls zum Beispiel eine der Slices Zugriffe zu einem Speicherbereich reguliert, den mehrere Funktionen gemeinsam verwenden) zugeordnet bekommen.

Die veranschaulichte Wurzel-PD 5002 weist auch den geplanten Funktionen Schutzschlüssel-IDs zu, wobei jede Schutzschlüssel-ID zu einem Verschlüsselungsschlüssel abbildet, der zum Verschlüsseln der Seite, auf die die Funktion zugreifen wird, verwendet wird. Wenn die Wurzel-PD 5002 eine Funktion zur Ausführung plant, bestimmt die Wurzel-PD 5002, ob eine Schutzschlüssel-ID zum Zuweisen zu der Funktion verfügbar ist. In diesem Hinblick kann die Anzahl von Funktionen größer sein als die Anzahl von Schutzschlüssel-IDs (zum Beispiel „n“ in dem veranschaulichten Beispiel). Falls kein Schutzschlüssel zum Zuweisen zu der Funktion verfügbar ist, ist die Anzahl von Schutzschlüssel-IDs in Bezug auf den Satz aller Funktionen unzureichend. In einem solchen Fall gibt die veranschaulichte Wurzel-PD 5002 eine Aktualisierungsanweisung 5004 zu einem Host-Prozessor (zum Beispiel CPU, nicht gezeigt) aus. Die Aktualisierungsanweisung 5004 weist den Host-Prozessor an, einen Eintrag 5006 in einer hierarchischen Seitentabelle 5008 mit einer neuen Schutzschlüssel-ID (PKID_new) zu aktualisieren. In diesem Hinblick kann die Aktualisierungsanweisung 5004 den Wert, der für die neue Schutzschlüssel-ID verwendet werden soll, sowie die lineare Adresse der Seite angeben. Der Host-Prozessor kann daher die lineare Adresse verwenden, um (zum Beispiel über einen Seiten-Walk) den Eintrag 5006 in der hierarchischen Seitentabelle 5008 zu lokalisieren. Die Einträge in die Seitentabelle 5008 sind privilegierte Datenstrukturen, die vor direkter Änderung durch unprivilegierte Bauelemente geschützt werden. Der veranschaulichte Ansatz erlaubt folglich nur, dass Schutzschlüssel-ID-Informationen geändert werden.

Bei einer Ausführungsform weist die Aktualisierungsanweisung 5004 den Host-Prozessor auch dazu an, einen Paging-Struktur-Cache zu leeren. Ein solcher Ansatz stellt sicher, dass alte Schutzschlüssel-ID-Werte aus dem Paging-Struktur-Cache entfernt werden können. Zusätzlich kann die Aktualisierungsanweisung 5004 den Host-Prozessor auch anweisen, den TLB (nicht gezeigt) zu leeren, der, wie bereits erwähnt, die kürzlichen Übersetzungen virtueller Speicheradressen in physische Speicheradressen speichert. Die veranschaulichte Lösung eliminiert folglich jedes Erfordernis, den OS-Kernel aufzurufen, wenn die Seitentabelle 5008 mit einer neuen Schutzschlüssel-ID aktualisiert wird.

Andere Sicherheitsbelange können durch Einschränken von Zugriff auf die Aktualisierungsanweisung 5004 behandelt werden. Bei einem Beispiel sind die Funktionen auf die gemanagten Laufzeitfunktionen eingeschränkt. Im Allgemeinen kann eine gemanagte Laufzeitumgebung eine höhere Lösung sein, wie zum Beispiel HTML5 (Hypertext Markup Language 5, zum Beispiel HTML5 Editor's Draft 8. Mai 2012, W3C), Dalvik (ANDROID Open Handset Alliance/OHA), ART (ANDROID Runtime, OHA), C# (zum Beispiel C# 5.0, MICROSOFT Corp., 15. August 2012), .NET (zum Beispiel .NET Framework 4.5, MICROSOFT Corp., 17. Oktober 2013), Ruby (zum Beispiel Ruby 2.1.0, Y. Matsumoto, 25. Dezember 2013), Perl (zum Beispiel Perl 5.18.2, Perl.org, 7. Januar 2014), Python (zum Beispiel Python 3.3.3, Python Software Foundation, 19. November 2013), JAVA (zum Beispiel JAVA Standard Edition 7 Update 51, ORACLE Corp., 14. Januar 2014) usw. Die Sicherheit wird daher verbessert, weil die Funktionen Just-in-Time (JIT) von der gemanagten Laufzeitumgebung interpretiert oder aufgerufen werden.

Zusätzlich kann atomare Ausführung der Funktionen durchgesetzt werden. Ein solcher Ansatz kann folglich vor der vorübergehenden Aufhebung eines Thread mitten in einem Vorgang schützen, was bei Anwendungen auftreten kann, die ihre eigenen Threads manipulieren (zum Beispiel Datenbank, JAVA und/oder Garbage-Collection-Anwendungen).

Andere Ansätze zum Einschränken des Zugriffs auf die Aktualisierungsanweisung 5004 beinhalten das Scannen nicht vertrauenswürdigen Codes, um zu prüfen, dass er die Aktualisierungsanweisung 5004 nicht enthält, Blockieren irgendwelcher Versuche, die Aktualisierungsanweisung 5004 außerhalb eines spezifizierten Bereichs, der die Wurzel-PD 5002 enthält, auszuführen und so fort.

50B zeigt ein Verfahren 5010 zum Aktualisieren von Schutzschlüssel-IDs. Das Verfahren 5010 kann im Allgemeinen von einer Wurzel-PD umgesetzt werden, wie zum Beispiel der Wurzel-PD 5002 (50A), die bereits besprochen wurde. Insbesondere kann das Verfahren 5010 als ein oder mehrere Module in einem Satz logischer Anweisungen, die in einem nichtflüchtigen maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt werden.

Der veranschaulichte Verarbeitungsblock 5012 stellt das Erfassen einer unzureichenden Anzahl von Schutzschlüssel-IDs in Bezug auf einen Satz von Funktionen bereit. Block 5014 weist als Reaktion auf eine unzureichende Anzahl von Schutzschlüssel-IDs einen Prozessor, wie zum Beispiel einen Host-Prozessor, an, einen Seitentabelleneintrag mit einer neuen Schutzschlüssel-ID zu aktualisieren. Block 5014 kann folglich das Ausgeben eine Aktualisierungsanweisung beinhalten, die die neue Schutzschlüssel-ID sowie eine lineare Adresse angibt, wobei der Prozessor einen Seiten-Walk einer hierarchischen Seitentabelle basierend auf der linearen Adresse ausführt. Der veranschaulichte Block 5014 weist auch (zum Beispiel über die Aktualisierungsanweisung) den Prozessor zum Bereinigen eines Paging-Struktur-Caches und eines TLB an. Bei einem Beispiel wird der Satz von Funktionen auf gemanagte Laufzeitfunktionen eingeschränkt, um unbefugten Zugriff auf die Aktualisierungsanweisung einzuschränken. Bei einer Ausführungsform aktualisiert Block 5014 auch die Seitentabelleneinträge (PTEs) für alle Seiten, die einem besonderen Dienst zugeordnet sind, weil jeder Dienst wahrscheinlich mehr als eine einzige Seite hat. Block 5014 kann auch das Durchsetzen atomarer Ausführung der Funktionen, das Scannen nicht vertrauenswürdigen Codes zum Prüfen, dass er die Aktualisierungsanweisung nicht enthält, das Blockieren von Versuchen, die Aktualisierungsanweisung außerhalb eines spezifizierten Bereichs, der die Wurzel-PD enthält, auszuführen und so fort beinhalten. Das veranschaulichte Verfahren 5010 eliminiert folglich jedes Erfordernis, den OS-Kernel aufzurufen, wenn Seitentabelleneinträge aktualisiert werden.

Zusätzliche Anmerkungen und Beispiele

Beispiel 5001 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechensystem ausgeführt werden, das Rechensystem veranlassen, eine unzureichende Anzahl von Schutzschlüsselidentifikatoren in Bezug auf einen Satz von Funktionen zu erfassen, einen Host-Prozessor anzuweisen, einen Seitentabelleneintrag als Reaktion auf die unzureichende Anzahl von Schutzschlüsselidentifikatoren zu aktualisieren, wobei der Satz von Funktionen auf gemanagte Laufzeitfunktionen beschränkt ist, und eine atomare Ausführung des Satzes von Funktionen durchzusetzen.

Beispiel 5002 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 5001, wobei die ausführbaren Programmanweisungen, wenn sie ausgeführt werden, das Rechensystem ferner dazu veranlassen, den Host-Prozessor anzuweisen, einen Paging-Struktur-Cache zu leeren.

Beispiel 5003 beinhaltet das mindestens eine computerlesbare Speichermedium des Beispiels 5001, wobei die ausführbaren Programmanweisungen, wenn sie ausgeführt werden, das Rechensystem dazu veranlassen, den Host-Prozessor anzuweisen, den Translation-Lookaside-Buffer zu leeren.

Beispiele der Erlaubnisaktualisierung einer unprivilegierten Seitentabelle

51A zeigt einen Prozess 5100, der eine Sandbox 5102 (zum Beispiel einen Satz von Regeln, die als ein Code-Isolierungstool arbeiten) beinhaltet, wobei die Sandbox 5102 ein unprivilegierteres Bauelement, wie zum Beispiel einen User-Modus-Broker 5104 (zum Beispiel User-Space-Compartment-Manager) am Zugreifen auf Ressourcen in Sandbox hindert, wie zum Beispiel auf logische Blockadressen 5112 in einem logischen Adressraum 5106 und physische Seiten 5114 in einem physischen Adressraum 5110. User-Mode-Sandboxing kann gewöhnlich über softwareorientierte Zugriffssteuerungen durchgesetzt werden. Bei dem veranschaulichten Beispiel bildet eine Anweisungssatz-Architektur-Seitentabelle (Instruction Set Architecture Page Table - ISA-PT) 5108 den logischen Adressraum 5106 zu dem physischen Adressraum 5110 ab, und ein Page-Miss-Handler (PMH) 5116 einer CPU 5118 führt Adressübersetzung aus, wenn eine Seitenadressübersetzung den TLB verpasst (nicht gezeigt). Das Stärken der softwarebasierten Zugriffssteuerungen mit Hardware kann insbesondere in Zusammenhang mit „Seitenkanalangriffen“ vorteilhaft sein, die auftreten können, wenn Multi-Mieter-Workloads den logischen Adressraum 5106 gemeinsam verwenden und die CPU 5118 ein Out-Of-Order-Prozessor (OOO-Prozessor) ist, der spekulative Ausführung verwendet.

Unter besonderer Berücksichtigung der Out-Of-Order-Verarbeitung schließt die CPU bestimmte Anweisungen ab und beginnt das Ausführen anderer Anweisungen, sogar falls später festgestellt wird, dass sie nicht erlaubt wurden und folglich keine dieser Anweisungen für tatsächliches Retirement in Frage käme. Keines der Resultate der nicht erlaubten Anweisungen ändert überhaupt irgendwelche Variablen. Eine Seitenkanalangriffsgefahr kann die Form des Beobachtens der Performance-Effekte annehmen, die aus sorgfältig konstruierten Vorgängen, von welchen der Angreifer weiß, dass sie verboten sind, resultieren. Sogar falls der Angreifer auf den Ort X nicht zugreifen kann, vorübergehend aber aufgrund von OOO ausreichend fortschreiten kann, um einen Wert V aus einigen wenigen Bits an dem Ort X zu konstruieren (zum Beispiel mit *X & 0x0F), kann der Angreifer dann auf einen anderen zulässigen Bereich, wie zum Beispiel R[V] zugreifen. Das Zugreifen auf R[V] verursacht einen Performance-Unterschied später, wenn der Angreifer prüfen kann, ob der Zugriff auf R[...] mit unterschiedlichen möglichen Werten von V Cache-Treffer oder Verfehlungen durch Prüfen der Latenzen ergibt. Auf diese Art erhält der Angreifer Kenntnis von Inhalten an dem Ort X jeweils von einigen wenigen Bits, ohne je befugt zu sein, diese Inhalte direkt zu sehen.

FaaS-Workloads können eine Serverform von Multi-Mieter-Workload sein, die auch in den Genuss feiner Zugriffssteuerung, die über Hardware durchgesetzt wird, kommen kann. Insbesondere kann FaaS von Hardware profitieren, die Zugangssteuerung an einer feineren Speicherobjektebene, an der herkömmliche Hardware Speichergenehmigungen auf 4096-Byte (4KB) (zum Beispiel eine Seitenebene) begrenzen kann, bereitstellt.

Die veranschaulichte Lösung stellt ein Subseiten-Genehmigungsmodell bereit, das von Hardware durchgesetzt wird und es einem OS 5120 ermöglicht, Genehmigungsmanagement und Aktualisierungen auf einer feinen Körnigkeit zu dem Benutzer-Modus-Broker 5104 bereitzustellen. Die Multi-Mieter-Workloads können daher in demselben logischen Adressraum 5106 mit dem Benutzer-Modus-Broker 5104, der die Compartmentgenehmigungen verwaltet, laufen. Besonders ist jedoch zu bemerken, dass das OS 5120 weiterhin das Abbilden des linearen Adressraums 5106 zu dem physischen Adressraum 5110 steuert.

Im Allgemeinen ermöglichen es Schutzschlüssel dem logischen Adressraum 5106, auf eine spärliche Art über eine Vielzahl von Subdomänen (zum Beispiel sechzehn Subdomänen) innerhalb des Prozesses 5100 partitioniert zu werden. Herkömmliche Schutzschlüssel können erlauben, dass Lese-/Schreib-Genehmigungen (RW-Genehmigungen) für Seiten auf einer Basis nach Domäne ausgedrückt werden und können ein schnelles Wechseln zwischen Domänen ohne Systemaufrufe auszuführen.

Bei dem veranschaulichten Beispiel spezifiziert eine Subseiten-Genehmigungstabelle (Sub-Page Permissions Table - SPPT) 5122 Genehmigungen auf der Ebene einer Subseite 5125 (zum Beispiel mit 128-Byte-Körnigkeit für eine 4KB-Seite) und wird dem Benutzer-Modus-Broker 5104 aufgezeigt. Der veranschaulichte Benutzer-Modus-Broker 5104 hat Lese-/Schreib-/Ausführungsprivilege (RWX-Privilegien) in Bezug auf die SPPT 5122. Bei einem Beispiel ist der Benutzer-Modus-Broker 5104 dazu in der Lage, Subseiten-Genehmigungen (zum Beispiel Herabstufen von RW-Zugriff auf Nurlesezugriff) in Bezug auf Subseiten in dem physischen Adressraum 5110 zu reduzieren, besitzt jedoch nicht die Fähigkeit zu besitzen, Subseiten-Genehmigungen (zum Beispiel Hochstufen von Nurlese-Zugriff auf Lese-/Schreibzugriff) zu erhöhen.

Subseiten-Genehmigungen werden folglich für jede physische Seite 5124 (oder physische Gastadresse, Guest Physical Address /GPA in einer virtualisierten Umgebung) in dem physischen Adressraum 5110 über die SPPT 5122 durchgesetzt. Bei einer Ausführungsform bildet die SPPT 5122 die physischen Seiten 5124 zu einem Bitvektor von Genehmigungen ab, wobei jedes Bit einer Schreibgenehmigung für einen Subseiten-Bereich entspricht. Statt seitenweise durch die SPPT 5122 nur durch die CPU 5118 zu gehen, wenn ein Eintrag einer erweiterten Seitentabelle (Extended Page Table - EPT) spezifiziert, dass Subseiten-Genehmigungen für eine spezifische 4KB-Abbildung aktiviert werden, wechselt die veranschaulichte Lösung den Seiten-Walk zu 1) Abschließen des Seiten-Walk ISA-PT 5108, Übersetzen einer logischen Blockadresse 5126 zu einer Adresse einer physischen Seite 5124, und verwendet dann die Adresse der physischen Seite 5124 um seitenweise durch die SPPT 5122 zu gehen. Subseiten-Genehmigungen werden daher von der ISA-PT 5108 aktiviert/ausgelöst, aber ohne, dass ein Monitor einer virtuellen Maschine (VMM) zum Aktivieren von EPTs erforderlich wäre.

Zusätzlich wird die SPPT 5122 dem Benutzer-Modus-Broker 5104 durch zweckdienliche Abbildungen in die ISA-PT 5108, die von dem OS 5120 für den Benutzer-Modus-Broker 5104 angelegt werden, aufgezeigt. Diese Abbildungen ermöglichen es dem Benutzer-Modus-Broker 5104, Genehmigungen frei zu ändern, nicht aber die logische Blockadresse zu physischen Adressabbildungen für Seiten, die noch von dem OS 5120 gesteuert werden.

Darüber hinaus kann eine neue Anweisung von dem Benutzer-Modus-Broker 5104 verwendet werden, um die SPPT 5122 ungültig zu machen, wobei die neue Anweisung zwischengespeicherte Genehmigungen löscht. Ein solcher Ansatz ist besonders nützlich, wenn die Genehmigungen reduziert sind. Jede zwischengespeicherte Genehmigung kann auch gelöscht werden, falls/wenn der Benutzer-Modus-Broker 5104 über CPUs bei Prozesskontextwechseln migriert. Bei einem Beispiel werden die Subseiten-Genehmigungen mit einer höheren Programmiersprache auf einer Basis nach Sicherheitsdomäne aufgezeigt. Zusätzlich können Call-Stack-Bereiche verwendet werden, um aufgerufene Funktionen von Aufruferfunktionen zu isolieren (zum Beispiel, um Umkehr-Stapelangriffe von aufgerufenen Funktionen mit relativ niedrigen Privilegien zu verhindern).

51B zeigt ein Verfahren 5128 zum Steuern von Subseiten-Genehmigungen. Das Verfahren 5128 kann im Allgemeinen von einem OS, wie zum Beispiel dem OS 5120 (51A), das bereits besprochen wurde, umgesetzt werden. Bei einer Ausführungsform wird das Verfahren 5128 als ein oder mehrere Module in einem Satz logischer Anweisungen, die in einem nichtflüchtigen maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie, oder einer beliebigen Kombination davon umgesetzt.

Der veranschaulichte Verarbeitungsblock 5130 stellt das Verhindern, dass ein unprivilegiertes Bauelement (zum Beispiel User-Modus-Broker) Abbildungen zwischen einem logischen Adressraum und einem physischen Adressraum, den sich eine Vielzahl von Funktionen teilen, ändert. Dem unprivilegierten Bauelement wird bei Block 5132 gestattet, Subseiten-Genehmigungen in Bezug auf den physischen Adressraum zu verringern.

Bei einem Beispiel zeigt Block 5134 die Subseiten-Genehmigungen einer höheren Programmiersprache auf einer Basis nach Sicherheitsdomäne auf. In diesem Hinblick könnten die Subseiten-Genehmigungen mit bestimmten Sicherheitsdomänen als ein Tag oder eine Anmerkung exponiert werden.

Bei einer Ausführungsform isoliert Block 5136 eine aufgerufene Funktion in der Vielzahl von Funktionen von einer Aufruferfunktion in der Vielzahl von Funktionen über Call-Stack-Bereiche. Block 5136 schützt folglich vor Umkehrstapelangriffen, bei welchen die aufgerufene Funktion niedriger privilegiert ist als die Aufruferfunktion. Die Blöcke 5130, 5132, 5134, 5136 sind unabhängige Vorgänge, die nicht sequenziell und/oder in einer beliebigen zweckdienlichen Reihenfolge ausgeführt werden können.

Zusätzliche Anmerkungen und Beispiele

Beispiel 5101 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Rechensystem ausgeführt werden, das Rechensystem veranlassen, ein unprivilegierter des Bauelement daran zu hindern, Abbildungen zwischen einem logischen Adressraum und einem physischen Adressraum, der von einer Vielzahl von Funktionen gemeinsam verwendet wird, zu ändern, es dem unprivilegierten Bauelement zu erlauben, Subseiten-Genehmigungen in Bezug auf den physischen Adressraum zu reduzieren, die Subseiten-Genehmigungen mit einer hohen Programmsprache auf einer Basis nach Sicherheitsdomäne zu exponieren und eine aufgerufene Funktion in der Vielzahl von Funktionen von einer Aufruferfunktion in der Vielzahl von Funktionen über Call-Stack-Bereiche zu isolieren.

Beispiele für entprivilegierten Modus

Das Verbessern von Hardwareeinsatz und Businesseffizienz insgesamt wird gewöhnlich durch gemeinsames Verwenden von Hardware-Computing-Ressourcen unter Mietern erzielt, wobei Beispiele Cloud-Computing, FaaS usw. sind. Dieses gemeinsame Verwenden kann erfordern, dass ein Prozess Aktionen abgrenzt und mieterübergreifende Workload-Interaktionen verhindert, um Sicherheit und Datenschutz zu wahren. Abgegrenzte Aktionen verweist daher auf alles, was vorab abgegrenzt werden muss (zum Beispiel eingeschlossen), und gewöhnlich gilt dieses Einschließen für Code, der durch eine Art von Isolierung, wie zum Beispiel Sandboxes, virtuelle Maschinen (VMs) und so fort „eingegrenzt ist“.

Während VMs, Prozesse, Namensräume (zum Beispiel für „Container“) und gemanagte Laufzeiten der Einschließherausforderung begegnen kann, bleibt beträchtlicher Raum für Verbesserung in Zusammenhang mit Startup-Zeit, Aufruf-Performance und/oder Speicheraufwand, die Anwendbarkeit und Dichte von Bereitstellungen begrenzen.

Einige Anwendungen, wie Network Functions Virtualization (NFV), können Latenz im Nanosekunden- bis Mikrosekundenbereich erfordern, während eine herkömmliche FaaS-Umsetzungslatenzen in der Größenordnung von Zehnern von Millisekunden verursachen könnte, wenn ein Kaltstart-Container aufgerufen wird. Der Poll-Modus, der typischerweise bei solchen Anwendungen verwendet wird, weist einen anderen Satz von Problemen, Dichte und Speicheraufwand verbunden mit Isolierung, auf. VMs und Container können nämlich immer noch eine relativ große Speichermenge, von einigen MB bis GB, verwenden. Die Menge an Instanzen auf einem Server ist folglich typischerweise begrenzt. Darüber hinaus funktioniert die Poll-Modus-Ausführung eventuell nicht gut mit Überbuchung. Im Gegensatz ist ein Run-to-Completion-Ansatz typischerweise entweder nur innerhalb einer einzigen Anwendung anwendbar (zum Beispiel aufgrund gemeinsam verwendeten Speicherraums zwischen Funktionsaufrufen) oder er hat, falls er zu einem FaaS-Modell mit guter Isolierung abgebildet ist, hohe Latenz.

In Extremfällen, wenn alle Anwendungen in Funktionen aufgegliedert sind (zum Beispiel einschließlich der OS-, Plattform- und Infrastrukturdienste), die sowohl lokal als auch entfernt laufen, können Performance-Nachfragen Hunderte von Millionen von Aufrufen pro Sekunde pro Server erreichen, was herkömmlich nur über nativen Code und CALL-Anweisungen erreichbar ist.

Eine kürzlich entwickelte Technik, die als ein entprivilegierter Modus bezeichnet wird, stellt ein Framework zum Laufen von Funktionen in einer Sandbox-Umgebung bereit, während ein Adressraum aus mehreren Speicher-„segmenten“ gemeinsam verwendet wird. Das Sandbox-System verhindert, dass Funktionen Segmente wechseln und schränkt Steuertransfers auf innerhalb einer Sandbox, die von einem Codesegment definiert wird, ein. Eine lokale Deskriptortabelle (LDT) ist eine Speichertabelle, die Speichersegmentdeskriptoren enthält. Jeder Segmentdeskriptor beinhaltet einen Selektor (zum Beispiel Index) und diverse Eigenschaften, wie zum Beispiel eine Basisadresse, Größe, Zugriffsprivilegien usw. Um ein Speichersegment zu referenzieren, lädt eine Funktion den Selektor in ein Segmentregister, was bewirkt, dass die Deskriptoreigenschaften von der LDT in den Hostprozessor geladen werden. Darauffolgende Änderungen an der LDT sind im Allgemeinen nicht effektiv, außer wenn das Segmentregister wieder geladen wird. Der entprivilegierte Modus beruht auf der Verwendung modifizierter Segmentdeskriptoren, wobei die Basisadresse als eine untere Bereichsgrenze behandelt wird. Weil die Anzahl verfügbarer Segmentdeskriptoren begrenzt ist, können jedoch dynamische Aktualisierungen der LDT erforderlich sein. Zusätzlich erlaubt eine niedrige Anzahl von Segmentregistern das Verwenden nur einer begrenzten Anzahl von Speicherbereichen, was auf den Aufrufer Druck ausübt, alle Parameter zu platzieren, und in der kontinuierlichen Speicherzone resultiert.

Die hierin beschriebene Technologie erweitert entprivilegierten Modus auf Fähigkeitsinformationen, wie zum Beispiel codierte Inline-Fähigkeitsinformationen (EIC-Informationen) und ermöglicht das Verwenden mehrerer Speicherbereiche, während ein Adressraum gemeinsam verwendet wird. Insbesondere wird eine Konfiguration eines entprivilegierten Modus umgesetzt, um EIC-Semantiken für Speicherzugriffe durchzusetzen, binäre Anwendungsschnittstellen (ABIs) für EIC, die Stapelzugriffe decken, zu definieren, und die Handhabung von Systemaufrufen/externer Aufrufe von entprivilegiertem Code zu definieren.

52A zeigt einen entprivilegierten Moduspfad 5200 für eine Funktion, die versucht, auf gemeinsam verwendeten Speicher (zum Beispiel ein Speichersegment) zuzugreifen. Bei dem veranschaulichten Beispiel werden eine oder mehrere Fähigkeitsauflagen (zum Beispiel Semantiken) von EIC-Informationen 5202 (5202a bis 5202c) auf dem versuchten Speicherzugriff durchgesetzt. Die EIC-Informationen 5202 beinhalten einen MAC 5202a, Grenzinformationen 5202b und einen Pointer 5202c. Bei einem Beispiel ist der MAC 5202a ein Tag, das von einer verschlüsselten Einweg-Hash-Funktion basierend auf den Grenzinformationen 5202b angelegt wird, wobei sich der Geheimschlüssel, der dazu verwendet wird, den MAC 5202a anzulegen, in einem geschützten Bereich (zum Beispiel auf dem Host-Prozessor) befindet. Der MAC 5202a wird folglich zum Bestätigen, dass die EIC-Informationen 5202 von dem angegebenen Sender kommen und nicht geändert wurden, verwendet. Der veranschaulichte MAC 5202a schützt folglich sowohl die Integrität als auch die Authentizität der EIC-Informationen 5202, indem er es Prüfern, die auch den geheimen Schlüssel besitzen, ermöglicht, irgendwelche Änderungen an den EIC-Informationen 5202 zu erfassen. Bei einem Beispiel referenziert der Pointer 5202c einen Speicherbereich, der von den Grenzinformationen 5202b definiert ist. Wenn daher ein Speicherzugriff von einer Funktion versucht wird, wird der MAC 5202a geprüft, um sicherzustellen, dass der Pointer, der bei dem Zugriff verwendet wird, legitim ist und innerhalb des Speicherbereichs, der von den Grenzinformationen 5202b definiert wird, liegt.

Bei einem Beispiel werden die Segmentdeskriptoren auch geändert, um ABIs für EIC zu definieren, die Stapelzugriffe decken und die Handhabung von Systemaufrufen/externen Aufrufen von entprivilegiertem Code definieren. Eine ABI ist eine Aufrufvereinbarung, unter der spezifische Verhaltensverantwortungen von dem Aufrufer und dem Aufgerufenen eingehalten werden. Wie hierin verwendet, spezifiziert ABI, wie Segmentregister oder Fähigkeiten des Aufgerufenen geladen werden, und wie Segmentregister oder Fähigkeiten des Aufrufers in einem Aufruf entladen werden. Auf ähnliche Art spezifiziert ABI, wie das jeweilige Laden/Ausladen umgekehrt ausgeführt wird, wenn ein Aufgerufener abschließt und der Aufrufer von dem Punkt, an dem der Aufgerufene abgeschlossen hat, fortsetzen soll. Bei einer Ausführungsform erklärt die ABI, dass alle Referenzen auf Speicher als EICs weitergegeben und auf dem Stapel des Aufgerufenen in einem spezifischen binären Format platziert werden (zum Beispiel bestehend aus Bitfeldern - MAC/Bound/Pointer), um sie von gewöhnlichen Feldern, die Einzelbitfeld für den Pointer enthalten, zu unterscheiden. Bei dem veranschaulichten Beispiel umgeht ein privilegierter Moduspfad 5204 die Fähigkeitsauflagen der EIC-Informationen 5202.

52B zeigt ein Verfahren 5206 zum Steuern von Subseiten-Genehmigungen. Bei einer Ausführungsform wird das Verfahren 5206 als ein oder mehrere Module in einem Satz logischer Anweisungen, die in einem nichtflüchtigen maschinen- oder computerlesbaren Speichermedium, wie RAM, ROM, PROM, Firmware, Flash-Speicher usw. gespeichert sind, in konfigurierbarer Logik, wie PLAs, FPGAs, CPLDs, in Hardware-Logik mit feststehender Funktionalität unter Verwenden von Schaltungstechnologie, wie zum Beispiel ASIC-, CMOS- oder TTL-Technologie oder einer beliebigen Kombination davon umgesetzt.

Der veranschaulichte Verarbeitungsblock 5208 erfasst einen Aufruf einer Funktion, wobei eine Bestimmung bei Block 5210 erfolgt, ob die Funktion in entprivilegiertem Modus aufgerufen wird. Wie bereits erwähnt, kann der entprivilegierte Modus ein Framework zum Laufen von Funktionen in einer Sandbox-Umgebung bereitstellen, während ein Adressraum aus mehreren Speichersegmenten gemeinsam verwendet wird. Als Reaktion darauf, dass die Funktion in entprivilegiertem Modus aufgerufen wird, setzt der veranschaulichte Block 5212 eine oder mehrere Fähigkeitsauflagen bei Versuchen der Funktion, auf den gemeinsamen verwendeten Speicherraum zuzugreifen, durch. Bei einem Beispiel beinhaltet Block 5212 das Definieren einer ABI für EIC, die Stapelzugriffe decken und die Handhabung von Systemaufrufen/externen Aufrufen von entprivilegiertem Code zusätzlich zum Durchsetzen der EIEC-Semantik für Speicherzugriffe handhabt. Das veranschaulichte Verfahren setzt sich folglich mit Besorgnissen über eine beschränkte Anzahl verfügbarer Segmentdeskriptoren und einer niedrigen Anzahl von Segmentregistern in einem FaaS-System, das eine extrem große Anzahl von Aufrufen pro Sekunde pro Server enthält, auseinander.

Codesegmentdeskriptoren und das Codesegmentregister könnten darauf erweitert werden, einen Fähigkeitsauthentifizierungscode zu speichern, der beim Laden jedes Deskriptors automatisch in das EIC-Authentifizierungsschlüsselregister geladen würde. Alternativ könnte der Codesegmentselektor als eine Eingabe für das EIC-Authentifizierungssystem und/oder einen Algorithmus (der zum Beispiel mit den anderen Eingaben zu der MAC-Erzeugungsvorgehensweise oder als eine kryptografische Optimierung konkateniert ist) verwendet werden.

Alternativ könnten der Fähigkeitsauthentifizierungsschlüssel oder andere Eingaben für das EIC-Authentifizierungssystem und/oder der Algorithmus aus anderen Segmentregistern bezogen werden (zum Beispiel Datensegment/DS, Extrasegment/ES, allgemeine Segmente (FS, GS) oder Stapelsegment/SS).

Zusätzliche Anmerkungen und Beispiele

Beispiel 5201 beinhaltet mindestens ein computerlesbares Speichermedium, das einen Satz ausführbarer Programmanweisungen umfasst, die, wenn sie von einem Computing-System ausgeführt werden, das Computing-System veranlassen, einen Aufruf einer Funktion zu erfassen, zu bestimmen, dass die Funktion in einem entprivilegierten Modus aufgerufen wird, und, als Reaktion darauf, dass die Funktion in dem entprivilegierten Modus aufgerufen wird, eine oder mehrere Fähigkeitsauflagen auf Versuchen der Funktion, auf den gemeinsam verwendeten Speicherraum zuzugreifen, durchzusetzen.

Der Begriff „gekoppelt“ kann hierin verwendet werden, um auf einen beliebigen Typ von Beziehung, sei sie direkt oder indirekt, zwischen den betreffenden Bauelementen zu verweisen, und kann für elektrische, mechanische, Fluid-, optische, elektromagnetische, elektromechanische oder andere Verbindungen gelten. Zusätzlich können die Begriffe „erste, erste, erstes“, „zweiter, zweite, zweites“ usw. hierin lediglich dazu verwendet werden, die Besprechung zu vereinfachen, und enthalten keine zeitliche oder chronologische Bedeutung, außer wenn Anderes angegeben ist.

Wie in dieser Anmeldung und in den Ansprüchen verwendet, kann eine Liste von Elementen, die mit dem Ausdruck „einer/eine/eines von mehreren“ verbunden sind, jede Kombination der aufgelisteten Begriffe bedeuten. Die Phrasen „einer oder mehrere von A, B oder C“ können A, B; C; A und B; A und C; B und C; oder A, B und C bedeuten.

Der Fachmann wird aus der oben stehenden Beschreibung entnehmen, dass umfassende Techniken der Ausführungsformen in einer Vielfalt von Formen umgesetzt werden können. Obwohl die Ausführungsformen in Verbindung mit besonderen Beispielen davon beschrieben sind, sollte der tatsächliche Schutzbereich der Ausführungsformen nicht auf diese Art beschränkt werden, da dem Fachmann bei einer Prüfung der Zeichnungen, Spezifikationen und folgenden Ansprüche andere Änderungen deutlich werden.

Wie man versteht, kann ein Computer und/oder eine Computing-Vorrichtung, wie hierin verwendet, diverse Schaltungen beinhalten, einschließlich aber nicht begrenzt auf CPU, GPU, FPGA, ASIC usw.

Claims

Mindestens ein nicht-flüchtiges computerlesbares Speichermedium, das einen Satz von ausführbaren Computerprogrammieranweisungen zum Bereitstellen einer verbesserten Function-as-a-Service (FaaS) für eine Vielzahl von Benutzern umfasst, die, wenn sie von einem Rechensystem ausgeführt werden, das Rechensystem veranlassen: eine Vielzahl von Funktionen auf einem oder mehreren Architektursubsystemen in dem Rechensystem als Reaktion darauf auszuführen, dass ein oder mehrere Ereignisse von einer Vielzahl von Benutzern empfangen werden, wobei das eine oder die mehreren Architektursubsysteme eine Abstraktion einer Ausführungsumgebung für die Vielzahl von Funktionen und eine Vielzahl von Containern, die mit der Vielzahl von Funktionen verbunden ist, darstellen; eine Vielzahl von Rechenressourcen des Rechensystems zuzuordnen, um die Ausführung der Vielzahl von Funktionen durch ein oder mehrere Software- und Orchestrierungssubsysteme in dem Rechensystem zu erleichtern; eine Vielzahl von Parametern, die mit der Vielzahl von Funktionen verbunden sind, und eine Vielzahl von Parametern, die mit der Vielzahl von Rechenressourcen verbunden sind, zu analysieren; die Vielzahl von Funktionen und Analyse der Vielzahl von Parametern, die mit der Vielzahl von Funktionen verbunden sind, und die Vielzahl von Rechenressourcen in einem oder mehreren Networking- und Lagerungssubsystemen in dem Rechensystem zu speichern, wobei Orte für das Speichern der Vielzahl von Funktionen und der Analyse der Vielzahl von Parametern zum Verbessern der Lokalität zwischen der Vielzahl von Funktionen und der entsprechenden Vielzahl von Rechenressourcen und zum Reduzieren von Funktionsausführungslatenz ausgewählt ist; und die Ausführung der Vielzahl von Funktionen durch ein oder mehrere Sicherheitssubsysteme in dem Rechensystem zu sichern.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: die Ausführung einer oder mehrerer Funktionen der Vielzahl von Funktionen zu überwachen; eine oder mehrere Rechenressourcen des Rechensystems in eine oder mehrere gemeinsam verwendete Ressourcen zu partitionieren, wobei jede Funktion der Vielzahl von Funktionen Zugriff auf die eine oder die mehreren gemeinsam verwendeten Ressourcen besitzt; eine Planung des Zuordnens einer oder mehrerer Rechenressourcen zum Ausführen der Vielzahl von Funktionen bereitzustellen, wobei die Planung basierend mindestens auf Historie basierter Ressourcenplanung von Funktionen, die von dem Rechensystem ausgeführt werden, erzeugt wird; Daten von einer oder mehreren Funktionen zu ausgewählten Rechengeräten zur Ausführung umzulenken; eine oder mehrere Funktionen der Vielzahl von Funktionen gemäß Service-Level-Parametern, die mit der einen oder mehreren Funktionen verbunden sind, auszuwählen; die ausgewählte eine oder mehreren Funktionen in eine kombinierte Funktion zur Ausführung zu kombinieren.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: einen Auslöseagenten zum Aufrufen einer zweiten Funktion der Vielzahl von Funktionen zu empfangen, wobei die zweite Funktion an eine Funktion der Vielzahl von Funktionen, die aktuell ausgeführt wird, anschließend ausgeführt wird; Feedback zu dem Auslöseagenten zum Angeben von Bereitschaft für den zweiten Funktionsaufruf bereitzustellen; als Reaktion darauf, dass eine Funktion der Vielzahl von Funktionen eine beschleunigte Multi-Mieter-Funktion ist, eine oder mehrere Versionen der Funktion zu initiieren; Synchronisation unter Ausführungsaktionen bereitzustellen, die mit der Ausführung der Vielzahl von Funktionen verbunden sind, wobei die Ausführungsaktionen auf eine Vielzahl von Rechengeräten und/oder Container, die mit der Vielzahl von Funktionen verbunden sind, verteilt ist; und den zweiten Funktionsaufruf als Reaktion darauf, dass ein Kriterium erfüllt wird, auszulösen.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: gemeinsam verwendete Informationen unter zwei oder mehreren Funktionen der Vielzahl von Funktionen zu identifizieren, zu analysieren, ob eine Funktion, die zum Ausführen aufgerufen ist, die gemeinsam verwendeten Informationen zur Ausführung erfordert; und die Funktion zu einer Ausführungsumgebung basierend auf der Analyse zu routen.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: eine Funktion während einer anfänglichen Ausführung der Funktion zu analysieren; Nutzungsdaten, die aus der Analyse der Funktion erzeugt werden, als eine Metadatendatei für darauffolgenden Aufruf der Funktion zu speichern, wobei jeder Aufruf der Funktion mindestens eine Metadatendatei für die Funktion erzeugt; die Funktion basierend auf einem oder mehreren Faktoren zurückzufordern, wobei der eine oder die mehreren Faktoren Ausführungszustände der Funktion angeben, wobei die Ausführungszustände angeben, ob die Funktion zurückgefordert werden soll; und eine Sicherheitspolitik der Funktion anzuwenden, wobei die Sicherheitspolitik mit der Ausführungsumgebung der Funktion verbunden ist, wobei ein oder mehrere Funktionssätze der Funktion mit demselben Sicherheitsschlüssel codiert sind.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: ein oder mehrere Rechenressourcenerfordernisse einer Funktion der Vielzahl von Funktionen zu identifizieren; eine oder mehrere identifizierte Rechenressourcen in einem Container, dem die Funktion zugewiesen ist, vorab zu reservieren, wobei jede identifizierte Rechenressource eine Ressourcenverzeichnisidentifikation aufweist; einen Beschleuniger anzuwenden, um eine Kostenfunktion für spezifische Workloads der Funktion zu bewerten; Datentransfer- und Kommunikationsverknüpfungen zwischen den vorab reservierten Rechenressourcen und Aufruf der Funktion aufzubauen, um Datentransfer- oder Kommunikationslatenz zu reduzieren; und eine oder mehrere Dienstgütemessungen (QoS-Messungen), die mit der Ausführung der Funktion verbunden sind, zu überwachen, wobei mindestens eine QoS-Messung durch einen Vektor definiert ist.
Mindestens ein computerlesbares Speichermedium nach Anspruch 6, das weiter ausführbare Computerprogrammierungsanweisungen umfasst, die, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: eine oder mehrere Anomalien zur Ausführungslaufzeit der Funktion zu erfassen, wobei die Anomalien unter Verwenden dynamischer Profiling-Fähigkeiten in der Ausführungslaufzeit der Funktion erfasst werden; Resultate des Erfassens der einen oder mehreren Anomalien zu mindestens einem Performance-Analysetool zu berichten; und eine Funktionsprofilabbildung basierend auf den dynamischen Profiling-Fähigkeiten der Funktion zu führen.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: Ressourcenmerkmale mit ausgeführten Funktionen zu verbinden, um Nachfragefingerabdrücke der ausgeführten Funktionen bei jeder Ausführungsstufe der Funktionen zu erzeugen, wobei die Nachfragefingerabdrücke mit Parametern der Funktionen und mindestens einem Mieter, der die Funktionen aufruft, verbunden sind, und wobei die Nachfragefingerabdrücke basierend auf Anwendung eines trainierten Sequenzanalytik-Maschinenlernmodells erzeugt werden; Berichte über Nutzung unterschiedlicher Ressourcen bei mehreren Ausführungsstufen der Funktionen zu erzeugen; und Funktionen Ressourcen zum Ausführen der Funktionen basierend auf den erzeugten Berichten zuzuordnen.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: einen ersten Aufruf von einer ersten Aufrufinstanz einer Funktion, die einen Satz von Feldern zurücksendet, zu erfassen; einen ersten Subsatz des Satzes von Feldern zu identifizieren, wobei der erste Subsatz mit der ersten Aufrufinstanz verbunden ist; und ein erstes Relayout eines ersten Antwortobjekts basierend auf dem ersten Subsatz zu leiten, wobei das Relayout des ersten Antwortobjekts das erste Antwortobjekt neu ordnet oder neu konfiguriert.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: eine Nutzlast für eine Funktion der Vielzahl von Funktionen zu bestimmen; und zur Kompilierungszeit einen Code zu platzieren, der die Nutzlast auf einen Rufstapel in einem Format bildet, das Informationen enthält, die ausreichen, um einen Aufruf auszuführen, wobei die Funktion gleichmäßig über die Nutzlast als eine lokale Instanz, eine entfernte Instanz oder Hardware aufrufbar ist.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: zu bestimmen, ob die Fähigkeitsinformationen, die mit einer ersten Funktion der Vielzahl von Funktionen verbunden sind, in Bezug auf ein erstes Authentifizierungsformat gültig sind, wobei die Fähigkeitsinformationen und das erste Authentifizierungsformat der ersten Funktion entsprechen; die Fähigkeitsinformationen zu einer Warteschlange zu speichern, falls die Fähigkeitsinformationen in Bezug auf das erste Authentifizierungsformat gültig sind; und die Fähigkeitsinformationen zu einer zweiten Funktion der Vielzahl von Funktionen in Übereinstimmung mit einem zweiten Authentifizierungsformat, das der zweiten Funktion entspricht, zu transferieren, wobei die erste Funktion und die zweite Funktion tragbare Funktionen sind, wobei eine tragbare Funktion eine tragbare Identität aufweist und dynamisch durch das Rechensystem durch einen Lastausgleicher bewegbar ist, und wobei die Fähigkeitsinformationen hierarchische codierte Inline-Fähigkeiten und Benutzerebenen-Interrupts beinhalten.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: einen Schlüsselidentifikator zu einem ersten Schlüssel abzubilden, wobei der erste Schlüssel mit einer ersten Funktion und einem ersten Speicherbereich, der mit dem ersten Schlüssel verschlüsselt ist, verbunden ist; einen Kontextwechsel von der ersten Funktion zu einer zweiten Funktion zu erfassen; und den Schlüsselidentifikator zu einem zweiten Schlüssel als Reaktion auf den Kontextwechsel abzubilden, wobei der zweite Schlüssel mit der zweiten Funktion und einem zweiten Speicherbereich, der mit dem zweiten Schlüssel verschlüsselt ist, verbunden ist, wobei der erste Speicherbereich und der zweite Speicherbereich einen linearen Adressbereich gemeinsam verwenden, wobei der erste Schlüssel ein Schlüssel für eine erste Zieldomäne ist, und der zweite Schlüssel ein Schlüssel für eine zweite Zieldomäne ist, und wobei eine oder mehrere der ersten Zieldomäne oder der zweiten Zieldomäne Subdomänen einer Trust-Domäne sind.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: eine unzureichende Anzahl von Schutzschlüsselidentifikatoren in Bezug auf einen Satz von Funktionen der Vielzahl von Funktionen zu erfassen; ein Host-Rechengerät anzuweisen, einen Seitentabelleneintrag als Reaktion auf die unzureichende Anzahl von Schutzschlüsselidentifikatoren zu aktualisieren, wobei der Satz von Funktionen auf gemanagte Laufzeitfunktionen beschränkt ist, und eine atomare Ausführung des Satzes von Funktionen durchzusetzen.
Mindestens ein computerlesbares Speichermedium nach Anspruch 1, wobei die ausführbaren Computerprogrammierungsanweisungen, wenn sie von dem Rechensystem ausgeführt werden, das Rechensystem veranlassen: zu bestimmen, ob ein Software-Thread auf einem Hardware-Logikthread läuft; ein Tag in ein Register zu wechseln, wenn der Software-Thread auf dem Hardware-Logik-Thread läuft; und mindestens eine einer Cache-Kapazität und einer Speicherbandbreite für jedes Tag einzustellen.
Halbleitergerät, das umfasst: ein oder mehr Substrate; und Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist, wobei die Logik mindestens teilweise in einer oder mehreren von konfigurierbarer Logik oder Hardware-Logik mit feststehender Funktionalität umgesetzt ist, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: eine Vielzahl von Funktionen auf einem oder mehreren Architektursubsystemen in dem Rechensystem als Reaktion darauf auszuführen, dass ein oder mehrere Ereignisse von einer Vielzahl von Benutzern empfangen werden, wobei das eine oder die mehreren Architektursubsysteme eine Abstraktion einer Ausführungsumgebung für die Vielzahl von Funktionen und eine Vielzahl von Containern, die mit der Vielzahl von Funktionen verbunden ist, darstellen; eine Vielzahl von Rechenressourcen des Rechensystems zuzuordnen, um die Ausführung der Vielzahl von Funktionen durch ein oder mehrere Software- und Orchestrierungssubsysteme in dem Rechensystem zu erleichtern; eine Vielzahl von Parametern, die mit der Vielzahl von Funktionen verbunden sind, und eine Vielzahl von Parametern, die mit der Vielzahl von Rechenressourcen verbunden sind, zu analysieren; die Vielzahl von Funktionen und Analyse der Vielzahl von Parametern, die mit der Vielzahl von Funktionen verbunden sind und Rechenressourcen in einem oder mehreren Networking- und Lagerungssubsystemen in dem Rechensystem zu speichern, wobei Orte für das Speichern der Vielzahl von Funktionen und der Analyse der Vielzahl von Parametern zum Verbessern der Lokalität zwischen der Vielzahl von Funktionen und der entsprechenden Vielzahl von Rechenressourcen und zum Reduzieren von Funktionsausführungslatenz ausgewählt ist; und die Ausführung der Vielzahl von Funktionen durch ein oder mehrere Sicherheitssubsysteme in dem Rechensystem zu sichern.
Halbleitergerät nach Anspruch 15, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist: die Ausführung einer oder mehrerer Funktionen der Vielzahl von Funktionen überwachen soll; eine oder mehrere Rechenressourcen des Rechensystems in eine oder mehrere gemeinsam verwendete Ressourcen partitionieren soll, wobei jede Funktion der Vielzahl von Funktionen Zugriff auf die eine oder die mehreren gemeinsam verwendeten Ressourcen besitzt; eine Planung des Zuweisens einer oder mehrerer Rechenressourcen zum Ausführen der Vielzahl von Funktionen bereitstellen soll, wobei die Planung basierend mindestens auf Historie basierter Ressourcenplanung von Funktionen, die von dem Rechensystem ausgeführt werden, erzeugt wird; Daten von einer oder mehreren Funktionen zu ausgewählten Rechengeräten zur Ausführung umlenken soll; eine oder mehrere Funktionen der Vielzahl von Funktionen gemäß Service-Level-Parametern, die mit der einen oder mehreren Funktionen verbunden sind, auswählen soll; die ausgewählte eine oder mehreren Funktionen in eine kombinierte Funktion zur Ausführung kombinieren soll.
Halbleitergerät nach Anspruch 15, wobei die Logik, die mit dem einen oder den mehreren Substraten gekoppelt ist: einen Auslöseagenten zum Aufrufen einer zweiten Funktion der Vielzahl von Funktionen empfangen soll, wobei die zweite Funktion an eine Funktion der Vielzahl von Funktionen, die aktuell ausgeführt wird, anschließend ausgeführt wird; Feedback zu dem Auslöseagenten zum Angeben von Bereitschaft für den zweiten Funktionsaufruf bereitstellen soll; als Reaktion darauf, dass eine Funktion der Vielzahl von Funktionen eine beschleunigte Multi-Mieter-Funktion ist, eine oder mehrere Versionen der Funktion initiieren soll; Synchronisation unter Ausführungsaktionen bereitstellen soll, die mit der Ausführung der Vielzahl von Funktionen verbunden sind, wobei die Ausführungsaktionen auf eine Vielzahl von Rechengeräten und/oder Container, die mit der Vielzahl von Funktionen verbunden sind, verteilt ist; und den zweiten Funktionsaufruf als Reaktion darauf, dass ein Kriterium erfüllt wird, auslösen soll.
Halbleitergerät nach Anspruch 15, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: gemeinsam verwendete Informationen unter zwei oder mehreren Funktionen der Vielzahl von Funktionen zu identifizieren, zu analysieren, ob eine Funktion, die zum Ausführen aufgerufen ist, die gemeinsam verwendeten Informationen zur Ausführung erfordert; und die Funktion zu einer Ausführungsumgebung basierend auf der Analyse zu routen.
Halbleitergerät nach Anspruch 15, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: eine Funktion während einer anfänglichen Ausführung der Funktion zu analysieren; Nutzungsdaten, die aus der Analyse der Funktion erzeugt werden, als eine Metadatendatei für darauffolgenden Aufruf der Funktion zu speichern, wobei jeder Aufruf der Funktion mindestens eine Metadatendatei für die Funktion erzeugt; die Funktion basierend auf einem oder mehreren Faktoren zurückzufordern, wobei der eine oder die mehreren Faktoren Ausführungszustände der Funktion angeben, wobei die Ausführungszustände angeben, ob die Funktion zurückgefordert werden soll; und eine Sicherheitspolitik der Funktion anzuwenden, wobei die Sicherheitspolitik mit der Ausführungsumgebung der Funktion verbunden ist, wobei ein oder mehrere Funktionssätze der Funktion mit einem selben Sicherheitsschlüssel codiert sind.
Halbleitergerät nach Anspruch 15, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: ein oder mehrere Rechenressourcenerfordernisse einer Funktion der Vielzahl von Funktionen zu identifizieren; eine oder mehrere identifizierte Rechenressourcen in einem Container, dem die Funktion zugewiesen ist, vorab zu reservieren, wobei jede identifizierte Rechenressource eine Ressourcenverzeichnisidentifikation aufweist; einen Beschleuniger anzuwenden, um eine Kostenfunktion für spezifische Workloads der Funktion zu bewerten; Datentransfer- und Kommunikationsverknüpfungen zwischen den vorab reservierten Rechenressourcen und Aufruf der Funktion aufzubauen, um Datentransfer- oder Kommunikationslatenz zu reduzieren; und eine oder mehrere Dienstgütemessungen (QoS-Messungen), die mit der Ausführung der Funktion verbunden sind, zu überwachen, wobei mindestens eine QoS-Messung durch einen Vektor definiert ist.
Halbleitergerät nach Anspruch 20, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: eine oder mehrere Anomalien zur Ausführungslaufzeit der Funktion zu erfassen, wobei die Anomalien unter Verwenden dynamischer Profiling-Fähigkeiten in der Ausführungslaufzeit der Funktion erfasst werden; Resultate des Erfassens der einen oder mehreren Anomalien zu mindestens einem Performance-Analysetool zu berichten; und eine Funktionsprofilabbildung basierend auf den dynamischen Profiling-Fähigkeiten der Funktion zu führen.
Halbleitergerät nach Anspruch 15, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: Ressourcenmerkmale mit ausgeführten Funktionen zu verbinden, um Nachfragefingerabdrücke der ausgeführten Funktionen bei jeder Ausführungsstufe der Funktionen zu erzeugen, wobei die Nachfragefingerabdrücke mit Parametern der Funktionen und mindestens einem Mieter, der die Funktionen aufruft, verbunden sind, und wobei die Nachfragefingerabdrücke basierend auf Anwendung eines trainierten Sequenzanalytik-Maschinenlernmodells erzeugt werden; Berichte über Nutzung unterschiedlicher Ressourcen bei mehreren Ausführungsstufen der Funktionen zu erzeugen; und Funktionen Ressourcen zum Ausführen der Funktionen basierend auf den erzeugten Berichten zuzuordnen.
Halbleitergerät nach Anspruch 15, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: einen ersten Aufruf von einer ersten Aufrufinstanz einer Funktion, die einen Satz von Feldern zurücksendet, zu erfassen; einen ersten Subsatz des Satzes von Feldern zu identifizieren, wobei der erste Subsatz mit der ersten Aufrufinstanz verbunden ist; und ein erstes Relayout eines ersten Antwortobjekts basierend auf dem ersten Subsatz zu leiten, wobei das Relayout des ersten Antwortobjekts das erste Antwortobjekt neu ordnet oder neu konfiguriert.
Halbleitergerät nach Anspruch 15, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: eine Nutzlast für eine Funktion der Vielzahl von Funktionen zu bestimmen; und zur Kompilierungszeit einen Code zu platzieren, der die Nutzlast auf einen Rufstapel in einem Format bildet, das Informationen enthält, die ausreichen, um einen Aufruf auszuführen, wobei die Funktion gleichmäßig über die Nutzlast als eine lokale Instanz, eine entfernte Instanz oder Hardware aufrufbar ist.
Halbleitergerät nach Anspruch 15, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: zu bestimmen, ob die Fähigkeitsinformationen, die mit einer ersten Funktion der Vielzahl von Funktionen verbunden sind, in Bezug auf ein erstes Authentifizierungsformat gültig sind, wobei die Fähigkeitsinformationen und das erste Authentifizierungsformat der ersten Funktion entsprechen; die Fähigkeitsinformationen zu einer Warteschlange zu speichern, falls die Fähigkeitsinformationen in Bezug auf das erste Authentifizierungsformat gültig sind; und die Fähigkeitsinformationen zu einer zweiten Funktion der Vielzahl von Funktionen in Übereinstimmung mit einem zweiten Authentifizierungsformat, das der zweiten Funktion entspricht, zu transferieren, wobei die erste Funktion und die zweite Funktion tragbare Funktionen sind, wobei eine tragbare Funktion eine tragbare Identität aufweist und dynamisch durch das Rechensystem durch einen Lastausgleicher bewegbar ist, und wobei die Fähigkeitsinformationen hierarchische codierte Inline-Fähigkeiten und Benutzerebenen-Interrupts beinhalten.
Halbleitergerät nach Anspruch 15, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: einen Schlüsselidentifikator zu einem ersten Schlüssel abzubilden, wobei der erste Schlüssel mit einer ersten Funktion und einem ersten Speicherbereich, der mit dem ersten Schlüssel verschlüsselt ist, verbunden ist; einen Kontextwechsel von der ersten Funktion zu einer zweiten Funktion zu erfassen; und den Schlüsselidentifikator zu einem zweiten Schlüssel als Reaktion auf den Kontextwechsel abzubilden, wobei der zweite Schlüssel mit der zweiten Funktion und einem zweiten Speicherbereich, der mit dem zweiten Schlüssel verschlüsselt ist, verbunden ist, wobei der erste Speicherbereich und der zweite Speicherbereich einen linearen Adressbereich gemeinsam verwenden, wobei der erste Schlüssel ein Schlüssel für eine erste Zieldomäne ist, und der zweite Schlüssel ein Schlüssel für eine zweite Zieldomäne ist, und wobei eine oder mehrere der ersten Zieldomäne oder der zweiten Zieldomäne Subdomänen einer Trust-Domäne sind.
Halbleitergerät nach Anspruch 15, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: eine unzureichende Anzahl von Schutzschlüsselidentifikatoren in Bezug auf einen Satz von Funktionen der Vielzahl von Funktionen zu erfassen; ein Host-Rechengerät anzuweisen, einen Seitentabelleneintrag als Reaktion auf die unzureichende Anzahl von Schutzschlüsselidentifikatoren zu aktualisieren, wobei der Satz von Funktionen auf gemanagte Laufzeitfunktionen beschränkt ist, und eine atomare Ausführung des Satzes von Funktionen durchzusetzen.
Halbleitergerät nach Anspruch 15, wobei die Logik mit dem einen oder den mehreren Substraten gekoppelt ist, um: zu bestimmen, ob ein Software-Thread auf einem Hardware-Logikthread läuft; ein Tag in ein Register zu wechseln, wenn der Software-Thread auf dem Hardware-Logik-Thread läuft; und mindestens eine einer Cache-Kapazität und einer Speicherbandbreite für jedes Tag einzustellen.
System, das umfasst: einen Speicher; und einen Prozessor, der mit dem Speicher gekoppelt ist, wobei der Prozessor Logik umfasst, um eine Vielzahl von Funktionen auf einem oder mehreren Architektursubsystemen in dem Rechensystem als Reaktion darauf auszuführen, dass ein oder mehrere Ereignisse von einer Vielzahl von Benutzern empfangen werden, wobei das eine oder die mehreren Architektursubsysteme eine Abstraktion einer Ausführungsumgebung für die Vielzahl von Funktionen und eine Vielzahl von Containern, die mit der Vielzahl von Funktionen verbunden ist, darstellen; eine Vielzahl von Rechenressourcen des Rechensystems zuzuordnen, um die Ausführung der Vielzahl von Funktionen durch ein oder mehrere Software- und Orchestrierungssubsysteme in dem Rechensystem zu erleichtern; eine Vielzahl von Parametern, die mit der Vielzahl von Funktionen verbunden sind, und eine Vielzahl von Parametern, die mit der Vielzahl von Rechenressourcen verbunden sind, zu analysieren; die Vielzahl von Funktionen und Analyse der Vielzahl von Parametern, die mit der Vielzahl von Funktionen verbunden sind, und die Vielzahl von Rechenressourcen in einem oder mehreren Networking- und Lagerungssubsystemen in dem Rechensystem zu speichern, wobei Orte für das Speichern der Vielzahl von Funktionen und der Analyse der Vielzahl von Parametern zum Verbessern der Lokalität zwischen der Vielzahl von Funktionen und der entsprechenden Vielzahl von Rechenressourcen und zum Reduzieren von Funktionsausführungslatenz ausgewählt ist; und die Ausführung der Vielzahl von Funktionen durch ein oder mehrere Sicherheitssubsysteme in dem Rechensystem zu sichern.
Verfahren, das umfasst: Ausführen einer Vielzahl von Funktionen auf einem oder mehreren Architektursubsystemen in dem Rechensystem als Reaktion darauf, dass ein oder mehrere Ereignisse von einer Vielzahl von Benutzern empfangen werden, wobei das eine oder die mehreren Architektursubsysteme eine Abstraktion einer Ausführungsumgebung für die Vielzahl von Funktionen und eine Vielzahl von Containern, die mit der Vielzahl von Funktionen verbunden ist, darstellen; Zuordnen einer Vielzahl von Rechenressourcen des Rechensystems, um die Ausführung der Vielzahl von Funktionen durch ein oder mehrere Software- und Orchestrierungssubsysteme in dem Rechensystem zu erleichtern; Analysieren einer Vielzahl von Parametern, die mit der Vielzahl von Funktionen verbunden sind, und eine Vielzahl von Parametern, die mit der Vielzahl von Rechenressourcen verbunden sind; Speichern der Vielzahl von Funktionen und Analyse der Vielzahl von Parametern, die mit der Vielzahl von Funktionen verbunden sind und Rechenressourcen in einem oder mehreren Networking- und Lagerungssubsystemen in dem Rechensystem zu speichern, wobei Orte für das Speichern der Vielzahl von Funktionen und der Analyse der Vielzahl von Parametern zum Verbessern der Lokalität zwischen der Vielzahl von Funktionen und der entsprechenden Vielzahl von Rechenressourcen und zum Reduzieren von Funktionsausführungslatenz ausgewählt sind; und Sichern der Ausführung der Vielzahl von Funktionen durch ein oder mehrere Sicherheitssubsysteme in dem Rechensystem.