DE112018007409T5 - Verfahren und vorrichtung zum planen von dienstanforderungen in einem netzwerk-rechensystem mit hilfe von hardware-warteschlangenverwaltungen - Google Patents

Verfahren und vorrichtung zum planen von dienstanforderungen in einem netzwerk-rechensystem mit hilfe von hardware-warteschlangenverwaltungen Download PDF

Info

Publication number
DE112018007409T5
DE112018007409T5 DE112018007409.9T DE112018007409T DE112018007409T5 DE 112018007409 T5 DE112018007409 T5 DE 112018007409T5 DE 112018007409 T DE112018007409 T DE 112018007409T DE 112018007409 T5 DE112018007409 T5 DE 112018007409T5
Authority
DE
Germany
Prior art keywords
service
service requests
rack
requests
gateway
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
DE112018007409.9T
Other languages
English (en)
Inventor
Francesc Guim Bernat
Karthik Kumar
Suraj Prabhakaran
Ignacio Astilleros Diez
Timothy Verrall
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Intel Corp
Original Assignee
Intel Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Intel Corp filed Critical Intel Corp
Publication of DE112018007409T5 publication Critical patent/DE112018007409T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/46—Multiprogramming arrangements
    • G06F9/50—Allocation of resources, e.g. of the central processing unit [CPU]
    • G06F9/5005—Allocation of resources, e.g. of the central processing unit [CPU] to service a request
    • G06F9/5027—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals
    • G06F9/5055—Allocation of resources, e.g. of the central processing unit [CPU] to service a request the resource being a machine, e.g. CPUs, Servers, Terminals considering software capabilities, i.e. software resources associated or available to the machine
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/50—Queue scheduling
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/2866—Architectures; Arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Ein beispielhaftes System zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe von Hardware-Warteschlangenverwaltungen beinhaltet: eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung in einem Edge-Gateway zum Planen der Dienstanforderungen, die von Client-Geräten empfangen werden, in einer Warteschlange; eine Rack-Ebenen-Hardware-Warteschlangenverwaltung in einem physischen Rack in Verbindung mit dem Edge-Gateway, wobei die Rack-Ebenen-Hardware-Warteschlangenverwaltung für das Senden einer Pull-Anforderung für eine erste der Dienstanforderungen an die Gateway-Ebenen-Hardware-Warteschlangenverwaltung vorgesehen ist; und eine Einschub-Ebenen-Hardware-Warteschlangenverwaltung in einem Einschub des physischen Racks, wobei die Einschub-Ebenen-Hardware-Warteschlangenverwaltung für das Senden einer zweiten Pull-Anforderung für die erste der Dienstanforderungen an die Rack-Ebenen-Hardware-Warteschlangenverwaltung vorgesehen ist, wobei der Einschub eine Ressource zum Bereitstellen einer Funktion als Dienst beinhaltet, die in der ersten der Dienstanforderungen spezifiziert ist.

Description

  • GEBIET DER OFFENBARUNG
  • Die vorliegende Offenbarung betrifft allgemein Netzwerk-Rechensysteme und ist insbesondere auf Verfahren und eine Vorrichtung zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe von Hardware-Warteschlangenverwaltungen gerichtet.
  • STAND DER TECHNIK
  • In Edge-Cloud-Architekturen können Telekomdienstanbieter (TSPs) und Kommunikationsdienstanbieter (CSPs) cloudbasierte Rechendienste anbieten, wie beispielsweise FaaS (Function as a Service - Funktion als Dienst) und AFaaS (Accelerated Function as a Service - Beschleunigte Funktion als Dienst). Mit derartigen Angeboten fordern Kunden, dass bestimmte Funktionen in der Cloud ausgeführt werden, die auf einem Client-Gerät entweder nicht oder nur kostenintensiver ausgeführt werden können. Einige Beispiele sind Bildsuche/-verarbeitung (z. B. zur Verwendung in erweiterter Realität (AR)), autonome selbstfahrende Autos, in denen Rechenfunktionen autonome Fahrmanöver übernehmen, usw. Um FaaS- und AFaaS-Dienste zu verwenden, sendet ein Client-Gerät eine Anforderung, die sachbezogene Daten beinhaltet, an eine Netzwerkadresse, die der FaaS oder AFaas entspricht. Dann werden Cloud-Ressourcen an der Netzwerkadresse zugewiesen, um die angeforderte FaaS oder AFaaS durchzuführen und ein Ergebnis der ausgeführten Operation zurückzugeben. Die Anforderungsübertragung, Berechnung und Ergebnisübertragung zurück zum Client-Gerät erfordern Zeit, die als Latenz bezeichnet wird. Wenn ein Client-Gerät eine derartige FaaS oder AFaas verwendet, fällt beim cloudbasierten Dienst eine entsprechende Latenz an, die das Client-Gerät beim Erreichen einer gewünschten oder geforderten Leistung für seine lokalen Funktionen berücksichtigen muss.
  • Figurenliste
    • 1 veranschaulicht ein beispielhaftes Edge-Gateway, das eine Gateway-Hardware-Warteschlangenverwaltung zum Planen von Dienstanforderungen beinhaltet, die an dem Edge-Gateway zu planen und von Ressourcen in Verbindung mit dem Edge-Gateway zu bedienen sind.
    • 2A und 2B veranschaulichen beispielhafte Hardware-Warteschlangenverwaltungen des beispielhaften Edge-Gateway von 1, ein beispielhaftes physisches Rack und beispielhafte Einschübe (Drawer) zum Bearbeiten von Dienstanforderungen, die von Client-Geräten empfangen werden, basierend auf einer Planung der Dienstanforderungen durch die Hardware-Warteschlangenverwaltung.
    • 3 veranschaulicht beispielhafte Peer-Edge-Gateways in Verbindung mit dem Edge-Gateway von 1 und 2A zum Ausführen von Lastausgleich von Dienstanforderungen auf der Gateway-Ebene.
    • 4 stellt ein Ablaufdiagramm dar, das repräsentativ für beispielhafte computerlesbare Anweisungen ist, die ausgeführt werden können, um die beispielhaften Hardware-Warteschlangenverwaltungen der Gateway-Ebene von 1 und 2A umzusetzen, um Dienstanforderungen gemäß den Lehren der vorliegenden Offenbarung zu planen.
    • 5A und 5B stellen Ablaufdiagramme dar, die repräsentativ für beispielhafte computerlesbare Anweisungen sind, die ausgeführt werden können, um die beispielhaften Hardware-Warteschlangenverwaltungen von 1, 2A und 2B umzusetzen, um Dienstanforderungen gemäß den Lehren der vorliegenden Offenbarung zu planen.
    • 6 ist ein Blockdiagramm einer beispielhaften Verarbeitungsplattform, die dafür strukturiert ist, die Anweisungen von 4, 5A und/oder 5B auszuführen, um die beispielhaften Hardware-Warteschlangenverwaltungen von 1, 2A und/oder 2B umzusetzen, um Dienstanforderungen gemäß den Lehren der vorliegenden Offenbarung zu planen.
  • Wann immer es möglich ist, werden in den Zeichnungen und der begleitenden schriftlichen Beschreibung durchweg die gleichen Bezugszeichen verwendet, um gleiche oder ähnliche Teil zu bezeichnen. Verbindungslinien oder Verbinder, die in den verschiedenen präsentierten Figuren gezeigt sind, sollen beispielhafte funktionelle Verhältnisse und/oder physische oder logische Kopplungen zwischen den verschiedenen Elementen darstellen.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Im Vorliegenden offenbarte Beispiele planen Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe von Hardware-Warteschlangenverwaltungen. Im Vorliegenden offenbarte Beispiele können in Cloud-Rechensystemen verwendet werden, die mit Hilfe von Edge-Gateways in Schaltung mit physischen Racks umgesetzt sind, die Einschübe physischer Ressourcen beinhalten. Beispielhafte Dienstanforderungen, die mit Hilfe von im vorliegenden offenbarten Techniken geplant werden können, entsprechen cloudbasierten Rechendiensten, wie beispielsweise FaaS (Function as a Service) und AFaaS (Accelerated Function as a Service), die von Cloud-Dienstanbietern angeboten werden. Eine FaaS stellt eine softwarebasierte Funktion bereit, die an Ressourcen von Einschüben in physischen Racks in Verbindung mit Edge-Gateways ausgeführt wird. Ein FaaS-Dienst stellt eine hardwarebasierte Funktion bereit, die mit Hilfe eines oder mehrerer Hardware-Beschleuniger (z. B. FPGAs (Field Programmable Gate Arrays), ASICs (anwendungsspezifischen integrierten Schaltungen) usw.) in Einschüben von physischen Racks in Verbindung mit Edge-Gateways umgesetzt ist. Cloudbasierte Rechendienste können FaaS/AFaaS -Dienste beinhalten, um schnellere und/oder leistungsstärkere Rechenpotenziale zu ermöglichen, die mit Hilfe lokaler Rechenressourcen von Client-Geräten erzielt werden können. Einige Client-Geräte, wie beispielsweise Internet-der-Dinge(IoT-)Client-Geräte, können zum Beispiel mit Energiespar-Hardware-Ressourcen gestaltet sein, die in ihrer Rechenleistung beschränkt sind. Somit können IoT-Client-Geräte auf ihrer lokalen Hardware geringe Rechenlasten abarbeiten, während sie hohe Rechenlasten an FaaS/AFaaS-Dienste eines Cloud-Rechensystems auslagern. Beispielhafte Technologien, die FaaS/AFaaS-Dienste verwenden können, beinhalten IoT-Geräte, mobiles Rechnen, Wearables, autonome, selbstfahrende Autos, unbemannte Luftfahrzeuge (UAVs), Verteilter-Prozess-Steuersysteme, Feldsensoren, Sicherheitsüberwachungssysteme usw.
  • Unterschiedliche Arbeitslasten von Client-Geräten weisen unterschiedliche Latenzerfordernisse auf (z. B. Umschlagzeiterfordernisse). Einige Arbeitslasten weisen flexible Latenzerfordernisse auf, während andere Arbeitslasten schnelle, strikte Latenzerfordernisse aufweisen (z. B. typischerweise weniger als 20 ms). Bei leistungsmäßig anspruchsvolleren Arbeitslasten (z. B. IoT-Client-Geräte, autonome, selbstfahrende Autos, UAVs usw.) können Latenzerfordernisse geringer als 2 Millisekunden (ms) sein. Frühere Techniken platzieren FaaS/AFaaS-Dienste am Rand (Edge) eines Netzwerks, um zugehörige Latenzen zu senken. Ein Netzwerkrand ist der Punkt, an dem ein Kernnetzwerk (z. B. eine Zentrale, ein Datenzentrum, ein Cloud-Netzwerk usw.) auf ein Weitbereichsnetz (WAN) (z. B. das Internet, ein Telekommunikationsnetz usw.) trifft. Bei einigen Beispielen werden Edge-Gateways am Rand eines Netzwerks verwendet, um das Kernnetzwerk mit dem WAN zu verbinden. Eine FaaS/AFaaS - Latenz kann als eine Einweglatenz oder eine Zweiwegelatenz gemessen werden. Eine Einweglatenz ist die Menge an Zeit, die zwischen dem Senden einer Dienstanforderung von einem Client-Gerät bis zum Empfangen der Dienstanforderung an einem Ziel (z. B. an einem Edge-Gateway oder an einer Ressource, die eine Funktion als Dienst bereitstellen wird) verstreicht. Eine Zweiwegelatenz (z. B. eine Umschlagzeit, eine Umlauflatenz usw.) ist die Menge an Zeit, die zwischen dem Senden einer Dienstanforderung von einem Client-Gerät bis zum Empfangen eines Ergebnisses an dem Client-Gerät von einer netzwerkbasierten Rechenressource, die das Ergebnis basierend auf dem Bedienen der Dienstanforderung erzeugt, verstreicht.
  • Zusätzlich zu Laufzeiten von Dienstanforderungen und -antworten beinhaltet eine Zweiwegelatenz außerdem (i) die Menge an Zeit, die zum Planen und zur Ressourcenverwaltung (z. B. Funktionsplanung der angeforderten Funktion und Zuweisen von Ressourcen zum Ausführen der angeforderten Funktion) der in der Dienstanforderung angeforderten Funktion erforderlich ist, und (ii) die Menge an Rechenzeit, die für den Dienstanbieter erforderlich ist, um die angeforderte Funktion auszuführen. In Datenzentren werden frühere Techniken zur Ressourcenverwaltung, Funktionsplanung und Orchestrierung durch Software erzielt. Derartige softwarebasierte Planungslösungen akzeptieren typischerweise Benutzeranforderungen von FaaS/AFaaS-Diensten als Funktion-als-Dienst-Vorlagen und planen dann die Funktionen in dem Satz von Ressourcen, die in einem Cluster von Servern in einem Datenzentrum zur Verfügung stehen. Das Planen einer Funktion durch softwarebasiertes Planen dauert gewöhnlich etwa 2 bis 5 ms. Deshalb erfüllt das Verwenden derartiger früherer Techniken in Edge-Cloud-Architekturen kein Hochleistungs-Umschlagzeiterfordernis von weniger als 2 ms. Da Rechenzeiten von Arbeitslasten für verschiedene Verwendungsfälle variieren, ist das Verbessern von Rechenzeiten auf eine Weise, die deterministische Verbesserungen an Latenzen bereitstellt, schwierig, da unterschiedliche Arten von FaaS/AFaaS-Diensten unterschiedliche Rechenzeiten erfordern und leistungsmäßig anspruchsvollere FaaS/AFaaS-Dienste höhere Rechenzeiten erfordern. Somit sind im Vorliegenden offenbarte Beispiele auf die Verbesserung der Zeitplanung und der Ressourcenverwaltungszeiten für FaaS/AFaaS-Dienste gerichtet, um deterministischere und wesentlichere Auswirkungen auf das Reduzieren von Latenzen derartiger FaaS/AFaaS-Dienste zu erreichen. Auf diese Weise können im Vorliegenden offenbarte Beispiele verwendet werden, um höhere Leistungserfordernisse bezüglich der Dienstgüte (QoS) und SLA (Service Level Agreement - Dienstgütevereinbarung) (z. B. Prioritätsebenen von Funktionen, Vorwegnahme genutzter Ressourcen usw.) von FaaS/AFaaS-Diensten zu erfüllen.
  • Im Vorliegenden offenbarte Beispiele verwenden Hardware-Warteschlangenverwaltungen (Hardware Queue Managers, HQMs), um das Bedienen von FaaS/AFaaS-Dienstanforderungen zu planen, um die Planungs- und Ressourcenverwaltungszeiten im Verhältnis zu früheren Techniken zu verringern und somit zu allgemein kürzeren Zweiwegelatenzen beizutragen, die mit FaaS/AFaaS-Dienstanforderungen von Client-Geräten an ein Netzwerk-Rechensystem, wie beispielsweise ein Cloud-Rechensystem, verbunden sind. Zum Beispiel sind im Vorliegenden offenbarte Hardware-Warteschlangenverwaltungen als Gateway-Ebenen-HQMs verwendbar, die am Rand eines Cloud-Rechensystems oder am Rand eines Datenzentrums umgesetzt sind, als Rack-Ebenen-HQMs, die an Schaltern von physischen Racks umgesetzt sind, und/oder als Einschubebenen-HQMs, die in Einschüben von physischen Racks umgesetzt sind. Im Vorliegenden offenbarte Beispiele können in Verbindung mit verschiedenen Arten von Netzwerkrändern verwendet werden, einschließlich Basisstation-Edge-Gateways, Zentralen-Edge-Gateways, regionaler POP(Point of Presence)-Edge-Gateways usw.
  • 1 veranschaulicht ein beispielhaftes Edge-Gateway 102, das Dienstanforderungen 104 für Funktionen als Dienst (z. B. FaaS- und/oder AFaaS-Dienste) plant, die von Ressourcen in Einschüben (z. B. den Einschüben 208a, b von 2A) von einem oder mehreren physischen Racks (z. B. den physischen Racks 204 von 2A) in Verbindung mit dem Edge-Gateway 102 und/oder von einem oder mehreren physischen Racks, die zu anderen Edge-Gateways gehören (z. B. den Peer-Edge-Gateways 302, 304 von 3), die in Verbindung mit dem Edge-Gateway 102 stehen, bereitgestellt werden. Bei dem veranschaulichten Beispiel empfängt das Edge-Gateway 102 die Dienstanforderungen 104 von einem Client-Gerät 105. Um derartige Dienstanforderungen 104 zu planen, stellen im Vorliegenden offenbarte Beispiele Hardware-Warteschlangenverwaltungen (HQMs) auf drei verschiedenen Ebenen bereit, die Folgendes beinhalten: (i) eine Edge-Gateway-Ebene, (ii) eine Rack-Ebene und (iii) eine Einschubebene. Das Edge-Gateway 102 beinhaltet zum Beispiel eine beispielhafte Gateway-Ebenen-HQM 106 und beinhaltet eine erste Warteschlange 108a und eine zweite Warteschlange 108b, in denen die Gateway-Ebenen-HQM 106 die Dienstanforderungen 104 plant. Obwohl nur zwei Warteschlangen 108a, b gezeigt sind, kann jede beliebige Anzahl an Warteschlangen bereitgestellt sein. Die beispielhaften Client-Geräte 105 können IoT-Geräte, Digitalkameras, mobile Rechengeräte, Smartphones, Smartwatches, Wearables, Medienabspielgeräte, autonome, selbstfahrende Autos, UAVs, Komponenten von Verteilter-Prozess-Steuersystemen, Feldsensoren, Sicherheitsüberwachungssysteme usw. sein.
  • Die beispielhafte Gateway-Ebenen-HQM 106 ist die oberste HQM 106 und plant die Dienstanforderungen 104 in den Warteschlangen 108a, b zum Senden an HQMs auf niedrigerer Ebene (z. B. Rack-Ebenen-HQMs und Einschubebenen-HQMs) und/oder HQMs von anderen Edge-Gateways. Die Client-Geräte 105 stellen zum Beispiel Dienstparameter in der Dienstanforderung 104 bereit, die eine Angabe von Fristen und/oder Umlauflatenzen sind, innerhalb derer Ergebnisse von entsprechenden der Dienstanforderungen 104 an entsprechenden der Client-Geräte 105 zu empfangen sind. Client-Geräte 105 können Fristen als zukünftige Zeitstempelwerte spezifizieren, die in Feldern von Dienstanforderungen 104 gespeichert sind. Um Umlauflatenzen zu spezifizieren, können Client-Geräte 105 Werte der Dauer der Umlauflatenz in Feldern von Dienstanforderungen 104 speichern und die Client-Geräte 105 können außerdem Startzeitstempel in den Dienstanforderungen 104 speichern, die Zeiten angeben, zu denen die Client-Geräte 105 die Dienstanforderungen 104 sendeten. Auf diese Weise kann die Gateway-Ebenen-HQM 106 die Menge der Zeit bestimmen, die seit der Zeit vergangen ist, zu der das Client-Gerät 105 die Dienstanforderung 104 sendete, um zu identifizieren, wie viel Zeit verbleibt, um ein Ergebnis für das Client-Gerät 105 bereitzustellen. Beispielhafte Dienstparameter können außerdem Diensttypkennungen und/oder Dienstkennungen beinhalten, die angeben, welche Funktionen als Dienst in der entsprechenden Dienstanforderung 104 angefordert werden. Eine Diensttypkennung gibt eine Art einer Funktion als Dienst an, die in einer Dienstanforderung 104 angefordert wird (z. B. Diensttyp = „Bildverarbeitung“). Eine Dienstkennung gibt eine spezielle Instanz einer Funktion als Dienst an, die in einer Dienstanforderung 104 angefordert wird (z. B. Diensttyp = „Gesichtserkennungs-Bildverarbeitung“). Die Diensttypkennungen und die Dienstkennungen können von den Client-Geräten 105 in Feldern der Dienstanforderung 104 gespeichert werden.
  • Die beispielhaften Client-Geräte 105 können die Dienstanforderungen 104 basierend auf einer URL (Uniform Resource Locator) oder einer IP(Internetprotokoll)-Adresse des Edge-Gateway 102 senden. Ein beispielhaftes Format, das die Client-Geräte 105 verwenden können, um die Dienstanforderungen 104 zu erzeugen, kann in Form von „ExecFaaS(FuncID, Payload or Inputs, Service Provider ID, Tenant ID, Max Cost, Result Time, Priority ID, SLA ID, Resource Type)“ vorliegen, das eine Anzahl an Dienstparametern wie folgt beinhaltet. Bei diesem Beispielformat spezifiziert der Dienstparameter „FuncID“ eine Diensttypkennung oder eine Dienstkennung einer Funktion als Dienst, auf die eine Dienstanforderung 104 gerichtet ist. Der beispielhafte Dienstparameter „Payload or Inputs“ beinhaltet Daten, die von der angeforderten Funktion als Dienst zu verarbeiten sind. Der beispielhafte Dienstparameter „Service Provider ID“ spezifiziert einen FaaS/AFaaS-Dienstanbieter, der die angeforderte Funktion als Dienst bereitstellen soll. Ein derartiger Dienstanbieter kann der Anbieter sein, den Benutzer abonnieren, um auf Funktionen als Dienst zuzugreifen. Der beispielhafte Dienstparameter „Tenant ID“ identifiziert den Teilnehmer/Kunden von FaaS/AFaaS-Diensten. Der beispielhafte Dienstparameter „Max Cost“ spezifiziert maximale Kosten, die durch die angeforderte Funktion als Dienst zum Bedienen der Dienstanforderung 104 anfallen. Bei diesem Beispiel sind die maximalen Kosten ein monetärer Betrag, der durch eine oder mehrere Ressourcen beim Verarbeiten einer Funktion als Dienst in einer Menge an Berechnungszeit anfällt. Zum Beispiel kann der Dienstparameter „Max Cost“ spezifizieren, dass bei einer Dienstanforderung 104 bis zu 100 monetäre Einheiten (z. B. US-Dollar) anfallen können, was die Verarbeitung der Dienstanforderung 104 durch einen Xeon-Prozessor in einer Rechenzeit von 40 Nanosekunden (ns) ermöglichte. Bei einem weiteren Beispiel kann der Dienstparameter „Max Cost“ spezifizieren, dass bei einer Dienstanforderung 104 bis zu 400 monetäre Einheiten (z. B. US-Dollar) anfallen können, was die Verarbeitung der Dienstanforderung 104 durch ein FPGA in einer kürzeren Rechenzeit von 15 ns ermöglichte. Bei anderen Beispielen kann eine andere geeignete Maßeinheit der Kosten für den Dienstparameter „Max Cost“ verwendet werden.
  • Der beispielhafte Dienstparameter „Result Time“ spezifiziert eine Frist oder eine Umlauflatenz, die eine Zeitbeschränkung definiert, innerhalb welcher der Empfang eines Ergebnisses einer Funktion als Dienst an einem anfordernden Client-Gerät 105 erwartet wird. Somit entspricht der Dienstparameter „Result Time“ einem Frist-Dienstparameter oder einem Umlauflatenz-Dienstparameter der Dienstanforderung 104. Bei weiteren Beispielen kann der Dienstparameter „Result Time“ aus der Dienstanforderung 104 ausgespart sein und stattdessen kann ein Frist-Dienstparameter oder ein Umlauflatenz-Dienstparameter über den Dienstparameter „SLA ID“ bereitgestellt werden, wie im Weiteren beschrieben. Der beispielhafte Dienstparameter „Priority ID“ ist dafür vorgesehen, eine Prioritätsebene oder Prioritätsrichtlinie zu identifizieren, die eine Priorität spezifiziert, die der entsprechenden Dienstanforderung 104 zugewiesen sein sollte. Bei einigen Beispielen wird der Dienstparameter „Priority ID“ als eine „hohe Priorität“, eine „normale Priorität“, eine „geringe Priorität“ und/oder eine Priorität auf numerischer Basis ausgedrückt (z. B. ist „1“ die höchste Priorität und „10“ die niedrigste Priorität). Bei weiteren Beispielen ist der Dienstparameter „Priority ID“ eine Prioritätsrichtlinienkennung einer Prioritätsrichtlinie, die in einer oder mehreren der HQMs 106, 202, 206a, b von 1, 2A und 2B gespeichert ist. Bei derartigen Beispielen spezifiziert die gespeicherte Prioritätsrichtlinie die Priorität, die der Dienstanforderung 104 zuzuweisen ist. Die Priorität in der Prioritätsrichtlinie kann zum Beispiel dem Dienstparameter „FuncID“, dem Dienstparameter „Service Provider ID“, dem Dienstparameter „Tenant ID“ oder dem Dienstparameter „Resource Type“ der Dienstanforderung 104 entsprechen. Der Dienstparameter „SLA ID“ ist dafür vorgesehen, eine Dienstgütevereinbarung (SLA) zu identifizieren, die eine Dienstgüte (QoS) spezifiziert, die für die entsprechende Dienstanforderung 104 bereitgestellt werden soll. Der Dienstparameter „SLA ID“ ist zum Beispiel eine SLA-Kennung einer SLA, die in einer oder mehreren der HQMs 106, 202, 206a, b von 1, 2A und 2B gespeichert ist. Bei diesen Beispielen spezifiziert die gespeicherte SLA die QoS-Ebene für die Dienstanforderung 104, basierend zum Beispiel auf dem Dienstparameter „FuncID“, dem Dienstparameter „Service Provider ID“, dem Dienstparameter „Tenant ID“ oder dem Dienstparameter „Resource Type“ der Dienstanforderung 104. Bei einigen Beispielen spezifiziert die SLA eine QoS-Ebene als eine Frist oder Umlauflatenz, die eine Zeitbeschränkung definiert, innerhalb welcher der Empfang eines Ergebnisses einer Funktion als Dienst an einem anfordernden Client-Gerät 105 erwartet wird. Bei diesen Beispielen entspricht der Dienstparameter „SLA ID“ einem Frist-Dienstparameter oder einem Umlauflatenz-Dienstparameter der Dienstanforderung 104 und der Dienstparameter „Result Time“ kann aus der Dienstanforderung 104 ausgespart sein. Der beispielhafte Dienstparameter „Resource Type“ ist dafür vorgesehen, eine Art von Ressource zu identifizieren, die dafür vorgesehen ist, die Funktion als Dienst, der von der Dienstanforderung 104 angefordert wird, auszuführen. Arten von Ressourcen beinhalten beispielsweise Plattformressourcen und Hardware-Beschleunigungsressourcen. Beispiele für Plattformressourcen beinhalten Software, die von Prozessoren ausgeführt wird (z. B. von Xeon-Prozessoren). Beispiele für Hardware-Beschleunigungsressourcen beinhalten Logikschaltungen (z. B. FPGAs, ASICs usw.), die dafür konfiguriert sind, Funktionen als Dienst auszuführen.
  • Um die Dienstanforderungen 104 in den Warteschlangen 108a, b zu planen, tut die Gateway-Ebenen-HQM 106 Folgendes: (1) Parsen der Dienstanforderungen basierend auf den Dienstparametern in den Dienstanforderungen 104 und (2) Organisieren der Dienstanforderungen 104 in den Warteschlangen 108a, b, basierend auf den Dienstparametern. Die Gateway-Ebenen-HQM 106 kann zum Beispiel einige der Dienstanforderungen 104 mit kürzeren Umlauflatenzen und/oder mit Fristen, die in kürzerer Zeit verstreichen, an oder nahe dem Kopf einer Warteschlange 108a, b speichern. Bei einigen Beispielen organisiert die Gateway-Ebenen-HQM 106 Dienstanforderungen 104 über verschiedene Warteschlangen 108a, b, basierend auf Diensttypkennungen und/oder Dienstkennungen. Zum Beispiel kann eine der Warteschlangen 108a, b von der Gateway-Ebenen-HQM 106 verwendet werden, um einige der Dienstanforderungen 104 zu speichern, die Diensttypkennungen und/oder Dienstkennungen aufweisen, die Funktionen als ein Dienst angeben, die von einer Ressource bereitgestellt werden; eine andere der Warteschlangen 108a, b kann von der Gateway-Ebenen-HQM 106 verwendet werden, um einige der Dienstanforderungen 104 zu speichern, die Diensttypkennungen und/oder Dienstkennungen aufweisen, die Funktionen als Dienst angeben, die von einer anderen Ressource bereitgestellt werden, und noch weitere Warteschlangen können von der Gateway-Ebenen-HQM 106 verwendet werden, um einige der Dienstanforderungen 104 basierend auf entsprechenden Diensttypkennungen und/oder Dienstkennungen zu speichern, die Funktionen als Dienst angeben, die von noch weiteren Ressourcen bereitgestellt werden.
  • Bei dem veranschaulichten Beispiel von 1 sind mehrere Ressourcen 116a, 116b und 118 in Verbindung mit dem Edge-Gateway 102 gezeigt. Einige der Ressourcen 116a, b und 118 können Ressourcen von physischen Racks in Verbindung mit dem Edge-Gateway 102 sein (z. B. Anwendung(en), Betriebssystem(e) (OS), Server, zentrale Recheneinheiten (CPU(s)), Netzwerk-Schnittstellenkarten (NIC(s)), Hardware-Beschleunigungsvorrichtung(en), Grafikverarbeitungseinheiten (GPU(s)), Kurzzeit-Speichervorrichtung(en), Langzeit-Speichervorrichtung(en) usw.) und weitere der Ressourcen 116a, b und 118 können Ressourcen physischer Racks sein, die anderen Peer-Edge-Gateways entsprechen, die in Verbindung mit dem Edge-Gateway 102 stehen.
  • Bei einigen Beispielen können eine oder mehrere der Ressourcen 116a, b und 118 in dem Edge-Gateway 102 und/oder in weiteren Rechenressourcen umgesetzt sein, die sich näher bei den Client-Geräten befinden können, bei denen der Datenursprung liegt. Auf diese Weise können, obwohl zu einigen im Vorliegenden offenbarten Beispielen Funktionen als Dienst gehören, die von Ressourcen in physischen Racks eines Datenzentrums bereitgestellt werden, im Vorliegenden offenbarte Beispiele zusätzlich oder alternativ verwendet werden, um Edge-Berechnungs- und/oder Fog-Berechnungslösungen umzusetzen, bei denen Rechenressourcen, die sich am Rand eines Netzwerks befinden, Funktionen als Dienst ausreichend nahe bei Client-Geräten bereitstellen, um zugehörige Latenzen zu reduzieren und um die Datenmenge zu reduzieren, die zu Cloud-Datenzentren rückübertragen wird. Zum Beispiel können Funktionen als Dienst durch Rechenressourcen in Fog-Knoten (z. B. einem Fog-Server) oder an dem Edge-Gateway 102 an einem Netzwerkrand umgesetzt sein, so dass Daten von Client-Geräten lediglich an die Fog-Server oder das Edge-Gateway 102 übertragen werden müssen, um die Funktionen als Dienst bereitzustellen, ohne diese Daten durch Netzwerkressourcen an die Cloud übertragen zu müssen, und so dass den Client-Geräten entsprechende Ergebnisse schneller geliefert werden können. Somit können im Vorliegenden offenbarte Beispiele in vernetzten Umgebungen umgesetzt sein, wie beispielsweise als Mehrfachzugriffs-Edge-Berechnung, Fog-Knoten-Berechnung und/oder eine andere Art von netzwerkbasiertem Rechnen, bei dem Funktionen als Dienst in Zwischenknoten umgesetzt sind (z. B. an einem Edge-Gateway oder zwischen dem Edge-Gateway 102 und einem Cloud-Datenzentrum), anstelle oder zusätzlich zu dem Übertragen von Daten des Client-Geräts an die Cloud.
  • Beispielhafte Edge-Berechnungslösungen oder Fog-Berechnungslösungen, die mit Hilfe von im Vorliegenden offenbarten Beispielen umgesetzt sein können, beinhalten das Bereitstellen und Planen von Funktionen als Dienst an verteilten Rechenressourcen in Edge-Knoten über ein Netzwerk, um intelligente Städte umzusetzen, die autonomes Fahren, IoT-Gerät-Berechnung usw. unterstützen. Bei derartigen Beispielen werden Funktionen als Dienst an lokalen Knoten oder Edge-Servern bereitgestellt (z. B. an Straßenecken, an Durchgängen entlang Versorgungsleitungen usw.). Weitere beispielhafte Edge-Berechnungslösungen oder Fog-Berechnungslösungen, die mit Hilfe von im Vorliegenden offenbarten Beispielen umgesetzt werden können, beinhalten das Bereitstellen und Planen von Funktionen als Dienst an lokalen Edge-Cloud-Servern und/oder Mikrodatenzentren. Mikrodatenzentren können zum Beispiel als öffentliche und/oder private On-Premise-Clouds nahe dem Datenursprung umgesetzt sein. Funktionen als Dienst können an derartigen Mikrodatenzentren geplant werden, wie es im Vorliegenden für lokale Datenverarbeitung offenbart ist, um Latenzen zu vermindern, die zu diesen Funktionen als Dienst gehören. Auf diese Weise können, wenn Anwendungen und/oder Geräte große Datenmengen erzeugen, die durch Funktionen als Dienst verarbeitet werden sollen, diese Funktionen als Dienst wie im Vorliegenden offenbart an Mikrodatenzentren und/oder lokalen Edge-Cloud-Servern geplant werden, um Ergebnisse geringer Latenz bereitzustellen. Somit können im Vorliegenden offenbarte Beispiele verwendet werden, um Funktionen als Dienst in einem Datenzentrum auf der Cloud-Ebene umzusetzen und/oder Funktionen als Dienst bereitzustellen, die zu Rechenressourcen am Rand eines Netzwerks bewegt oder portiert wurden. Bei einigen Beispielen weisen derartige Funktionen als Dienst, die an Edge-Berechnungs- oder Fog-Berechnungsressourcen ausgeführt werden, eine verminderte Funktionalität auf, um diese lokale Körperlichkeit zu ermöglichen, aber behalten ausreichend Funktionalität bei, um gewünschte Ergebnisse bereitzustellen, während die Latenzen, die zum Bereitstellen derartiger Ergebnisse für Client-Geräte gehören, vermindert werden. Verminderte Latenzen sind insbesondere für Verwendungen nützlich, die kurze Antwortzeiten erfordern, wie beispielsweise Anwendungen autonomen Fahrens, Anwendungen erweiterter Realität usw.
  • Bei dem Beispiel von 1 stellen die Ressourcen 116a der Plattform 1 bis Ressourcen 116b der Plattform N Ressourcen dar, auf die über eine Anzahl N von Plattformen zugegriffen werden kann, auf die durch eine oder mehrere Hypervisorplattformen, Gast-OS-Plattformen und/oder Containerplattformen zugegriffen werden kann. Ein Hypervisor ist eine Software, die auf einem Host-OS oder auf dem „Bare-Metal“ eines Servers oder eines Einschubs von Hardware-Ressourcen ausgeführt wird (z. B. ohne ein zwischengeschaltetes Host-OS zwischen dem Server/der Hardware und dem Hypervisor), um eine virtuelle Umgebung für eine oder mehrere virtuelle Maschinen zu erzeugen, in denen Gast-OS-Plattformen laufen. Der Hypervisor virtualisiert Hardware-Ressourcen des Servers oder des Einschubs für den Zugriff durch Funktionen als Dienst, die auf dem Hypervisor laufen und/oder die auf den Gast-OS-Plattformen laufen. Eine Container-Plattform ermöglicht eine Instanziierung mehrerer containerisierter Anwendungen auf eine Containerlaufzeit, die in einem Host-OS ausgeführt wird. Die Container sind voneinander und von der Container-Laufzeitumgebung, in der sie laufen, logisch getrennt. Jeder Container führt eine separate Anwendung aus. Da die Container voneinander logisch getrennt sind, können die Anwendungen nicht auf Anwendungen oder entsprechende Daten in anderen Containern zugreifen. Container können jedoch ihre Anwendungen als Ressourcen für Funktionen als Dienst bereitstellen und sie haben Zugriff auf darunterliegende Hardware-Ressourcen, um Funktionen als Dienst auszuführen.
  • Die beispielhaften Ressourcen 118 des Beschleunigers N stellen eine Anzahl N von Hardware-Beschleunigungsressourcen dar, die in Einschüben von physischen Racks zur Verfügung stehen. Beispielhafte Hardware-Beschleunigungsressourcen, die verwendet werden können, um die Ressourcen 118 des Beschleunigers N umzusetzen, beinhalten FPGAs, ASICs und/oder eine beliebige andere Art von Logikschaltung, die dafür konfiguriert sein kann, eine Funktion als Dienst bereitzustellen. Bei einigen Beispielen sind einige der Ressourcen 118 des Beschleunigers N in den gleichen Racks und/oder in den gleichen Einschüben umgesetzt wie einige der Ressourcen 116a der Plattform 1 bis Ressourcen 116b der Plattform N. Bei weiteren Beispielen sind die Ressourcen 118 des Beschleunigers N in Racks und/oder in Einschüben umgesetzt, die von Racks und/oder Einschüben getrennt sind, in denen die Ressourcen 116a der Plattform 1 bis Ressourcen 116b der Plattform N umgesetzt sind.
  • Bei dem veranschaulichten Beispiel von 1 beinhaltet jede der Ressourcen 116a, b und 118 mehrere Funktionen als Dienst, die mittels entsprechender Diensttypkennungen und/oder Dienstkennungen identifiziert sind. Zum Beispiel beinhalten die Ressourcen 116a der Plattform 1 eine FaaS-Funktion Typ D als Dienst 122 und eine erste FaaS-Funktion Typ A als Dienst 124a und die Ressourcen 116b der Plattform N beinhalten eine FaaS-Funktion Typ C als Dienst 126 und eine zweite FaaS-Funktion Typ A als Dienst 124b. Die beispielhafte FaaS-Funktion Typ D als Dienst 122 ist durch die Dienstkennung 0x26 identifiziert, die beispielhafte FaaS-Funktion Typ C als Dienst 126 ist durch die Dienstkennung 0x21 identifiziert und die beispielhafte erste und die beispielhafte zweite FaaS-Funktion Typ A als Dienst 124a, b sind durch die Dienstkennung 0x24 identifiziert. Bei dem veranschaulichten Beispiel sind die FaaS-Funktionen Typ A als Dienst 124a, b auf getrennten Plattforminstanziierungen umgesetzt, so dass die mehreren der FaaS-Funktionen Typ A als Dienst 124a, b einige der Dienstanforderungen 104 in den Warteschlangen 108a, b, die Dienstkennungen 0x24 aufweisen, handhaben können. Durch Umsetzen mehrerer Instanzen der FaaS-Funktionen Typ A als Dienst 124a, b können diese mehreren Instanzen dafür verwendet werden, größere Volumen entsprechender einiger der Dienstanforderungen 104 zu verarbeiten. Des Weiteren kann eine derartige Strategie der Umsetzung mehrerer Instanzen der gleichen Funktion als Dienst über mehrere Ressourcen verwendet werden, um die Rechtzeitigkeit des Verarbeitens großer Mengen an Dienstanforderungen 104 zu verbessern, die auf die gleiche Funktion als Dienst gerichtet sind.
  • Bei dem veranschaulichten Beispiel von 1 sind in den Ressourcen 118 des Beschleunigers N eine erste AFaaS-Funktion Typ V als Dienst 132 und eine zweite AFaaS-Funktion Typ V als Dienst 134 bereitgestellt. Die erste AFaaS-Funktion Typ V als Dienst 132 ist durch die Dienstkennung 0x54 identifiziert und die zweite AFaaS-Funktion Typ V als Dienst 134 ist durch die Dienstkennung 0x56 identifiziert. Bei dem veranschaulichten Beispiel sind die erste und die zweite AFaaS-Funktion Typ V als Dienst 132, 134 mit Hilfe unterschiedlicher Dienstkennungen identifiziert, obwohl sie von der gleichen Art AFaaS-Funktion als Dienst sind. Auf diese Weise kann eine Dienstanforderung 104 eine Dienstartkennung und/oder eine Dienstkennung beinhalten. Bei einigen Beispielen kann ein Client-Gerät 105 in einer Dienstanforderung 104 eine Diensttypkennung beinhalten, um zu spezifizieren, dass die Dienstanforderung 104 von einer beliebigen Instanz der Art AFaaS-Funktion als Dienst verarbeitet werden kann. Bei einigen Beispielen kann ein Client-Gerät 105 in einer Dienstanforderung 104 eine Dienstkennung beinhalten (z. B. die Dienstkennung 0x54 der ersten AFaaS-Funktion Typ V als Dienst 132 oder die Dienstkennung 0x56 der zweiten AFaaS-Funktion Typ V als Dienst 134), um eine bestimmte Instanz der Art von AFaaS-Funktion als Dienst zu spezifizieren, um die Dienstanforderung 104 zu verarbeiten. Obwohl in jeder der Ressourcen 116a, b, 118 nur zwei Funktionen als Dienst gezeigt sind, können mehr oder weniger Funktionen als Dienst bereitgestellt sein.
  • Anders als frühere Techniken, die geplante Anforderungen für Funktionen als Dienst (z. B. Dienstanforderungen) zu Ressourcen schieben (Push), ermöglichen es im Vorliegenden offenbarte Beispiele anderen HQMs, die geplanten Dienstanforderungen 104 aus den Warteschlangen 108a, b zu ziehen (Pull). Um die Dienstanforderungen 104 an andere HQMs zu übermitteln, beinhaltet das Edge-Gateway 102 des veranschaulichten Beispiels eine beispielhafte HQM-Kommunikationsschnittstelle 136, um diejenigen der Dienstanforderungen 104 von einer oder mehreren der Warteschlangen 108a, b des Edge-Gateway 102 an ein oder mehrere andere Edge-Gateways, ein oder mehrere physische Racks und/oder einen oder mehrere Einschübe zu senden (z. B. als Antwort auf Pull-Anforderungen von dem einen oder den mehreren anderen Edge-Gateways, einen oder mehreren physischen Racks und/oder einen oder mehreren Einschüben). Auf diese Weise können einige der Dienstanforderungen 104, die auf Funktionen als Dienst gerichtet sind, die über andere Edge-Gateways zur Verfügung stehen, durch entsprechende Gateway-Ebenen-HQMs an dem einen oder den mehreren anderen Edge-Gateway geplant werden und einige der Dienstanforderungen 104, die auf Funktionen als Dienst gerichtet sind, der von Ressourcen in einem oder mehreren physischen Racks in Verbindung mit dem Edge-Gateway 102 gerichtet sind, können an dem einen oder den mehreren physischen Racks durch entsprechende Rack-Ebenen-HQMs (z. B. die Rack-Ebenen-HQM 202 von 2A) und entsprechende Einschub-Ebenen-HQMs (z. B. die Einschub-Ebenen-HQMs 206a, b von 2B) geplant werden. Bei dem veranschaulichten Beispiel ist die HQM-Kommunikationsschnittstelle 136 außerhalb der Gateway-Ebenen-HQM 106 umgesetzt. Bei weiteren Beispielen, beispielsweise wie in 2A gezeigt, ist die HQM-Kommunikationsschnittstelle 136 in der Gateway-Ebenen-HQM 106 umgesetzt.
  • Bei im Vorliegenden offenbarten Beispielen sind Gateway-Ebenen-HQMs, Rack-Ebenen-HQMs und Einschub-Ebenen-HQMs dafür konfiguriert, die Funktionen als Dienst, die von Ressourcen in ihren entsprechenden physischen Racks geboten werden, zu kennen oder zu identifizieren (z. B. basierend auf den Diensttypkennungen und/oder Dienstkennungen). Basierend auf diesen Dienstangebotskonfigurationen ziehen (pull) Peer-Gateway-Ebenen-HQMs, die Rack-Ebenen-HQMs und die Einschub-Ebenen-HQMs entsprechende der Dienstanforderungen 104 von Gateway-Ebenen-HQMs. Zum Beispiel ziehen Rack-Ebenen-HQMs und Einschub-Ebenen-HQMs entsprechend der Gateway-Ebenen-HQM 106 über die HQM-Kommunikationsschnittstelle 136 Dienstanforderungen 104 aus den Warteschlangen 108a, b. Des Weiteren können Peer-Gateway-Ebenen-HQMs von anderen Edge-Gateways, die in Verbindung mit dem Edge-Gateway 102 stehen, Dienstanforderungen 104 aus den Warteschlangen 108a, b ziehen. Bei dem veranschaulichten Beispiel von 1 sendet eine HQM, die den Ressourcen 116a der Plattform 1 entspricht, basierend auf einer Diensttypkennung (z. B. PullRequest(FaaSType=D)) eine beispielhafte Pull-Anforderung 142 an die Gateway-Ebenen-HQM 106 über die HQM-Kommunikationsschnittstelle 136, um eine oder mehrere der Dienstanforderungen 104 zu ziehen, die Diensttypkennungen aufweisen, die mit der Diensttypkennung „D“ in der Pull-Anforderung 142 übereinstimmen. Eine HQM, die den Ressourcen 116b der Plattform N entspricht, sendet basierend auf einer Dienstkennung (z. B. PullRequest(Service=0x21)) eine beispielhafte Pull-Anforderung 144 über die HQM-Kommunikationsschnittstelle 136 an die Gateway-Ebenen-HQM 106, um eine oder mehrere der Dienstanforderungen 104 zu ziehen, die Dienstkennungen aufweisen, die mit der Dienstkennung „0×21“ in der Pull-Anforderung 144 übereinstimmen. Eine HQM, die den Ressourcen 118 des Beschleunigers N entspricht, sendet basierend auf einer Diensttypkennung (z. B. PullRequest(AFaaSType=V)) eine beispielhafte Pull-Anforderung 146 über die HQM-Kommunikationsschnittstelle 136 an die Gateway-Ebenen-HQM 106, um eine oder mehrere der Dienstanforderungen 104 zu ziehen, die Diensttypkennungen aufweisen, die mit der Diensttypkennung „V“ in der Pull-Anforderung 146 übereinstimmen.
  • Bei im Vorliegenden offenbarten Beispielen werden Ergebnisse von Berechnungen oder Prozessen, die den angeforderten Funktionen als Dienst entsprechen, von HQMs der untersten Ebene an HQMs der obersten Ebene übertragen. Einschub-Ebenen-HQMs übertragen zum Beispiel Ergebnisse hinauf zu Rack-Ebenen-HQMs und die Rack-Ebenen-HQMs übertragen die Ergebnisse hinauf zu der Gateway-Ebenen-HQM 106. Die Gateway-Ebenen-HQM 106 sendet die Ergebnisse an Client-Geräte 105, von denen entsprechende der Dienstanforderungen 104 empfangen wurden.
  • 2A und 2B veranschaulichen die beispielhafte Gateway-Ebenen-HQM 106 des Edge-Gateway 102 von 1, eine beispielhafte Rack-Ebenen-HQM 202 eines physischen Racks 204 und beispielhafte Einschub-Ebenen-HQMs 206a, b von Einschüben 208a, b des physischen Racks 204, um Dienstanforderungen 104 (1) zu verarbeiten, die von den Client-Geräten 105 empfangen werden, basierend auf der Planung der Dienstanforderungen 104 in den HQMs 106, 202, 206a, b. Die beispielhafte Gateway-Ebenen-HQM 106 beinhaltet eine beispielhafte Client-Kommunikationsschnittstelle 212, eine beispielhafte Authentifizierungseinrichtung 214, eine beispielhafte Systemverwaltung 216, eine beispielhafte Anforderung-Client-Abbildung 218, einen beispielhaften Parser 220, eine beispielhafte Priorisierungseinrichtung 222 und einen beispielhaften Anforderungsplaner 224. Außerdem beinhaltet bei dem veranschaulichten Beispiel von 2A und 2B die Gateway-Ebenen-HQM 106 die HQM-Kommunikationsschnittstelle 136. Die beispielhafte Rack-Ebenen-HQM 202 beinhaltet eine beispielhafte Gateway-Kommunikationsschnittstelle 226, eine beispielhafte Anforderungsabrufeinrichtung 228, eine beispielhafte Rack-Verwaltung 230, eine beispielhafte Dienstetabelle 234 und eine beispielhafte Einschub-Kommunikationsschnittstelle 236. Bei dem veranschaulichten Beispiel der 2A und 2B ist die Rack-Ebenen-HQM 202 mit beispielhaften Warteschlangen 238a, b verschaltet. Obwohl nur zwei Warteschlangen 238a, b gezeigt sind, kann jede beliebige Anzahl an Warteschlagen mit der Rack-Ebenen-HQM 202 verschaltet bereitgestellt sein. Des Weiteren kann, obwohl nur ein physisches Rack 204 und zwei Einschübe 208a, b gezeigt sind, jede beliebige Anzahl physischer Racks und entsprechender Rack-Ebenen-HQMs und jede beliebige Anzahl von Einschüben und entsprechenden Einschub-Ebenen-HQMs in Verbindung mit dem Edge-Gateway 102 bereitgestellt sein. Diese physischen Racks und entsprechenden Rack-Ebenen-HQMs und diese Einschübe und entsprechenden Einschub-Ebenen-HQMs können auf im Wesentlichen die gleiche Weise konfiguriert sein, wie im Vorliegenden in Verbindung mit der Rack-Ebenen-HQM 202 und den Einschub-Ebenen-HQMs 206a, b offenbart.
  • Die Gateway-Ebenen-HQM 106 ist mit der beispielhaften Client-Kommunikationsschnittstelle 212 bereitgestellt, um die Dienstanforderungen 104 zu sammeln, die von verschiedenen Client-Geräten 105 empfangen werden. Die beispielhafte Client-Kommunikationsschnittstelle 212 beinhaltet einen oder mehrere Eingangs-/Ausgangsspeicherpuffer, um die Dienstanforderungen 104 von den Client-Geräten 105 zu sammeln und/oder um entsprechende Ergebnisse zum Senden an die Client-Geräte 105 zu speichern. Bei dem veranschaulichten Beispiel kann die Client-Kommunikationsschnittstelle 212 außerdem einen Sender und einen Empfänger (z. B. eine Ethernet-Netzwerk-Schnittstellenkarten(NIC)-Schnittstelle) zum Empfangen von Dienstanforderungen 104 von den Client-Geräten 105 und zum Senden der Ergebnisse an die Client-Geräte 105 beinhalten.
  • Die Gateway-Ebenen-HQM 106 ist mit der beispielhaften Authentifizierungseinrichtung 214 ausgestattet, um Authentifizierung und Richtlinien-Gegenprüfung von Dienstanforderungen 104 auszuführen, um zu bestimmen, welche Dienstanforderungen 104 zu akzeptieren sind. Die Authentifizierungseinrichtung 214 kann Dienstanforderungen 104 zum Beispiel mit Hilfe digitaler Zertifikate und oder anderer Authentifizierungsinformationen (z. B. Gerätekennungen, Benutzerberechtigungsnachweise usw.) authentifizieren, um zu bestimmen, ob Dienstanforderungen 104 gültig sind. Die beispielhafte Authentifizierungseinrichtung 214 kann eine Richtlinien-Gegenprüfung der Dienstanforderungen 104 durchführen, indem sie bestätigt, dass Dienstanforderungen 104 Systemrichtlinien erfüllen. Zum Beispiel können Richtlinien erzeugt werden, um zu definierten, welche Funktionen als Dienst zur Verfügung stehen, welche Client-Geräte auf Funktionen als Dienst zugreifen dürfen, wann auf Funktionen als Dienst zugegriffen werden darf, wann Client-Geräte maximale Grenzen für Dienstanforderungen 104 für Funktionen als Dienst ausgeschöpft haben usw. Die beispielhafte Authentifizierungseinrichtung 214 sendet authentifizierte der Dienstanforderungen 104 an die Warteschlangen 108a, b. Die Warteschlangen 108a, b speichern die Dienstanforderungen 104, so dass sie von HQMs unterer Ebenen gezogen werden können, wie beispielsweise der Rack-Ebenen-HQM 202 und den Einschub-Ebenen-HQMs 206a, b und/oder anderen Gateway-Ebenen-HQMs von Edge-Gateways, die in Verbindung mit dem Edge-Gateway 102 stehen.
  • Die Gateway-Ebenen-HQM 106 ist mit der beispielhaften Systemverwaltung 216 ausgestattet, um Prioritätsrichtlinien für die Dienstanforderungen 104 zu konfigurieren, Verfügbarkeiten von Funktionen als Dienst zu konfigurieren, die von physischen Racks (z. B. dem physischen Rack 204) in Verbindung mit dem Edge-Gateway 102 angeboten werden, und den Lastausgleich von Dienstanforderungen 104 über HQMs zu steuern, die Dienstanforderungen 104 von der Gateway-Ebenen-HQM 106 ziehen. Die beispielhafte Systemverwaltung 216 kann diese Merkmale in der Gateway-Ebenen-HQM 106 und in anderen HQMs (z.B. die Rack-Ebenen-HQM 202 und die Einschub-Ebenen-HQMs 206a, b), die in Verbindung mit der Gateway-Ebenen-HQM 106 stehen, konfigurieren. Zum Beispiel kann die Systemverwaltung 216 in der Gateway-Ebenen-HQM 106 Prioritätsrichtlinien für die Priorisierungseinrichtung 222 zur Verwendung durch die Priorisierungseinrichtung beim Zuordnen von Prioritäten zu einigen der Dienstanforderungen 104 bereitstellen. Beispielhafte Prioritätsrichtlinien können auf Fristen, Umlauflatenzen, Diensttypkennungen und/oder Dienstkennungen basieren, die von Client-Geräten 105 in den Dienstanforderungen 104 spezifiziert werden. Einige Prioritätsrichtlinien können zum Beispiel die Prioritäten für Dienstanforderungen 104 mit kürzeren Umlauflatenzen und/oder mit Fristen, die in kürzerer Zeit verstreichen als andere Dienstanforderungen 104, erhöhen. Einige beispielhafte Prioritätsrichtlinien können höhere Prioritäten für einige Funktionen als Dienst basierend auf Diensttypkennung und/oder Dienstkennung spezifizieren. Zum Beispiel können Funktionen als Dienst, die zu autonomen, selbstfahrenden Autos gehören, höhere Prioritäten zugeordnet werden als Funktionen als Dienst für Bildspeicherungs- oder Bildverarbeitungsanwendungen, weil autonome, selbstfahrende Autos schneller die Sicherheit menschlichen Lebens beeinflussende Ergebnisse benötigen. Bei noch einem weiteren Beispiel können Prioritätsrichtlinien Dienstanforderungen 104 von bestimmten Quellen oder Orten höhere Prioritäten zuordnen (z. B. basierend auf IP(Internetprotokoll)-Adresse, MAC(Medienzugriffssteuerung)-Adressen, IMEI(International Mobile Equipment Identity), Koordinaten physischer Orte usw.). Zum Beispiel können Dienstanforderungen 104 von Regierungsgeräten, Militärgeräten, Polizeigeräten, Feuerwehrgeräten, Gesundheitswesengeräten und/oder von Orten, an denen Notfallbedingungen vorliegen, höhere Prioritäten zugeordnet werden als anderen Dienstanforderungen.
  • Um Verfügbarkeiten von Funktionen als Dienst zu konfigurieren, die von physischen Racks (z. B. dem physischen Rack 204) in Verbindung mit dem Edge-Gateway 102 angeboten werden, führt die beispielhafte Systemverwaltung 216 ein Diensteverzeichnis von Diensttypkennungen und/oder Dienstkennungen, die Funktionen als Dienst angeben, die von Ressourcen in einem oder mehreren physischen Racks in Verbindung mit dem Edge-Gateway 102 bereitgestellt werden. Des Weiteren programmiert die Systemverwaltung 216 Diensttypkennungen und/oder Dienstkennungen in Dienstetabellen von physischen Racks und/oder Einschüben (z. B. die Dienstetabelle 234 des physischen Racks 204 und/oder die Dienstetabelle 254 des Einschubs‚0‘ 208a von 2B), um zu spezifizieren, welche Funktionen als Dienst von Ressourcen in diesen physischen Racks bereitgestellt werden. Wenn die beispielhafte Systemverwaltung 216 Aktualisierungen zu ihrem Diensteverzeichnis empfängt, aktualisiert sie die Dienstetabellen in physischen Racks basierend auf Änderungen ihres Dienstverzeichnisses, so dass die physischen Racks in Echtzeit Kenntnis darüber erlangen, welche Funktionen als Dienst sie bereitstellen. Aktualisierungen des Diensteverzeichnisses der Systemverwaltung 216 können manuell von Systemadministratoren und/oder automatisch durch softwarebasierte Agenten vorgenommen werden, da Funktionen als Dienst aus einer Anzahl von Gründen aktiviert oder deaktiviert werden (z. B. neue Funktionen als Dienst instanziiert werden, Funktionen als Dienst zum Aktualisieren oder Reparieren offline genommen werden, einige Funktionen als Dienst nicht mehr angeboten werden usw.).
  • Um den Lastausgleich von Dienstanforderungen 104 über mehrere HQMs physischer Racks zu steuern, welche die Dienstanforderungen 104 von der Gateway-Ebenen-HQM 106 ziehen, programmiert die Systemverwaltung 216 Lastausgleichsregeln, die mengenbasierte und/oder zeitbasierte Grenzen spezifizieren, in andere HQMs. Diese Lastausgleichsregeln können verwendet werden, um die Anzahl und/oder Geschwindigkeit von Dienstanforderungen 104 zu steuern, die von den anderen HQMs gezogen werden. Zum Beispiel kann die Systemverwaltung 216 diese Lastausgleichsregeln in Rack-Ebenen-HQMs von physischen Racks programmieren, die mit dem Edge-Gateway 102 verbunden sind, wie beispielsweise die Rack-Ebenen-HQM 202 des physischen Racks 204. Auf diese Weise können die Lasten von Dienstanforderungen 104, welche die gleiche Funktion als Dienst spezifizieren, über mehrere physische Racks, welche die spezifizierten Funktionen als Dienst bereitstellen, ausgeglichen werden.
  • Bei einigen Beispielen kann der Lastausgleich der Dienstanforderungen 104 über mehrere HQMs physischer Racks auch durch die Systemverwaltung 216 basierend auf dem Zuordnen verschiedener Funktionen als Dienst zu verschiedenen der physischen Racks umgesetzt sein. Zum Beispiel kann die Systemverwaltung 216 HQMs von einigen physischen Racks dafür programmieren, Dienstanforderungen 104 entsprechend Funktionen als Dienst zu verarbeiten, die typischerweise kürzere Fristen und/oder kürzere Umlauflatenzen aufweisen, und sie kann HQMs von anderen physischen Racks dafür programmieren, Dienstanforderungen 104 entsprechend Funktionen als Dienst zu verarbeiten, die typischerweise längere Fristen und/oder längere Umlauflatenzen aufweisen. Bei einigen Beispielen kann die Systemverwaltung 216 einige der Dienstanforderungen 104, die dringender sind und/oder eine höhere Priorität aufweisen, HQMs physischer Racks zuweisen, die Hardware-Beschleunigungsressourcen aufweisen, die Funktionen als Dienst schneller als software-basierte Funktionen als Dienst ausführen können.
  • Um in anderen HQMs Veränderungen an Prioritätsrichtlinien, Dienstetabellen, Lastausgleichsregeln vorzunehmen, ist die beispielhafte Systemverwaltung 216 mit einem Protokoll ausgestattet, um mit HQMs zu kommunizieren. Das Protokoll spezifiziert Adressen von anderen HQMs für wahlweises Kommunizieren mit einzelnen der HQMs und beinhaltet einen Broadcast-Modus zum Kommunizieren mit mehreren HQMs gleichzeitig. Auf diese Weise kann die Systemverwaltung 216 Veränderungen an einzelnen der HQMs vornehmen und/oder Veränderungen an mehreren der HQMs gleichzeitig vornehmen.
  • Die Gateway-Ebenen-HQM 106 ist mit der beispielhaften Anforderung-Client-Abbildung 218 ausgestattet, um anhängige der Dienstanforderungen 104 mit Kennungen (z. B. Quell-IP-Adressen, MAC-Adressen, IMEI-Nummern usw.) entsprechender Client-Geräte 105 abzubilden. Bei dem veranschaulichten Beispiel sind anhängige der Dienstanforderungen 104 Dienstanforderungen 104, die auf die Verarbeitung durch Funktionen als Dienst warten oder durch Funktionen als Dienst verarbeitet werden und für die entsprechende Ergebnisse noch nicht an der Gateway-Ebenen-HQM 106 empfangen wurden. Die beispielhafte Gateway-Ebenen-HQM 106 verwendet die Anforderung-Client-Abbildung 218, um Ergebnisse, die den Dienstanforderungen 104 entsprechen, an entsprechende Client-Geräte 105 zu senden. Zum Beispiel kann die Client-Kommunikationsschnittstelle 212 Ergebnisse an IP-Adressen von Client-Geräten 105 senden, die in der Anforderung-Client-Abbildung 218 als den Dienstanforderungen 104 entsprechend, die zu den Ergebnissen gehören, identifiziert sind.
  • Die Gateway-Ebenen-HQM 106 ist mit dem beispielhaften Parser 220 ausgestattet, um die Dienstanforderungen 104 basierend auf Dienstparametern zu parsen, die in den Dienstanforderungen 104 von den Client-Geräten 105 enthalten sind. Die Gateway-Ebenen-HQM 106 ist mit der beispielhaften Priorisierungseinrichtung 222 ausgestattet, um die Dienstanforderungen 104 basierend auf dem Parsen, das von dem Parser 220 ausgeführt wird, zu priorisieren. Wenn der Parser 220 zum Beispiel die Dienstanforderungen basierend auf Fristen und/oder Umlauflatenzen parst, priorisiert die Priorisierungseinrichtung 222 einige der Dienstanforderungen 104 mit kürzeren Umlauflatenzen und/oder mit Fristen, die in kürzerer Zeit verstreichen, als höhere Priorität als einige der Dienstanforderungen 104 mit weniger zwingenden Fristen und/oder Umlauflatenzen. Bei Beispielen, bei denen der Parser 220 die Dienstanforderungen 104 basierend auf Diensttypkennungen und/oder Dienstkennungen parst, kann die Priorisierungseinrichtung 222 einigen der Dienstanforderungen 104, die auf Funktionen als Dienst gerichtet sind, welche die Systemverwaltung 216 als höhere Priorität als andere der Funktionen als Dienst identifiziert hat, eine höhere Priorität zuordnen. Die beispielhafte Priorisierungseinrichtung 222 kann zusätzlich oder alternativ die Dienstanforderungen 104 basierend auf einem anderen Typ von Dienstgütemetrik und/oder Maximalkostenmetrik priorisieren. Die Priorisierungseinrichtung 222 kann zum Beispiel Dienstanforderungen 104, die Maximalkosten spezifizieren, die einen Dienstgüte-Grenzwert oder Kostengrenzwert erfüllen, eine höhere Priorität zuordnen. Bei einigen Beispielen kann die Priorisierungseinrichtung 222 zusätzlich oder alternativ die Dienstanforderungen 104 basierend auf einer Mandanten(Tenant)-ID und/oder Dienstanbieter-ID priorisieren. Zum Beispiel kann die Priorisierungseinrichtung 222 Mandanten-IDs verwenden, um Abonnenten von Funktionen als Dienst auf verschiedenen Dienstgüteebenen zu priorisieren (z. B. hochstufige bevorzugte Dienstabonnements, mittelstufige leistungsausgeglichene Dienstabonnements und niedrigstufige Spar-Dienstabonnements usw.) und die Dienstanforderungen 104 basierend auf diesen Ebenen priorisieren. In ähnlicher Weise kann die Priorisierungseinrichtung 222 Dienstanbieter-IDs verwenden, um unterschiedliche Dienstgüteebenen zu identifizieren, die von verschiedenen Dienstanbietern garantiert werden, und Dienstanforderungen 104 entsprechend diesen Dienstanbietern basierend auf diesen Ebenen priorisieren. In jedem Fall kann die Priorisierungseinrichtung 222 dafür konfiguriert sein, die Dienstanforderungen 104 in beliebiger gewünschter Weise durch Bereitstellen verschiedener Richtlinienregeln für die Priorisierungseinrichtung 222 zu priorisieren.
  • Die Gateway-Ebenen-HQM 106 ist mit dem beispielhaften Anforderungsplaner 224 ausgestattet, um die Dienstanforderungen 104 in den Warteschlangen 108a, b basierend auf Prioritäten, die von der Priorisierungseinrichtung 222 zugeordnet werden, zu planen. Auf diese Weise zieht die HQM-Kommunikationsschnittstelle 136, wenn Pull-Anforderungen (z. B. die Pull-Anforderungen 142, 144, 146 von 1) von anderen HQMs an der HQM-Kommunikationsschnittstelle 136 empfangen werden, Dienstanforderungen 104 höherer Priorität, die höhere der zugeordneten Prioritäten aufweisen, aus den Warteschlangen 108a, b zum Senden an die anfordernden HQMs, bevor sie Dienstanforderungen 104 niedrigerer Priorität sendet.
  • Die Rack-Ebenen-HQM 202 ist mit der beispielhaften Gateway-Kommunikationsschnittstelle 226 ausgestattet, um mit der Gateway-Ebenen-HQM 106 zu kommunizieren. Die Gateway-Kommunikationsschnittstelle 226 sendet zum Beispiel Pull-Anforderungen an die HQM-Kommunikationsschnittstelle 136 der Gateway-Ebenen-HQM 106, um Dienstanforderungen 104 aus den Warteschlangen 108a, b zu ziehen oder abzurufen. Des Weiteren stellt die beispielhafte Gateway-Kommunikationsschnittstelle 226 Ergebnisse für die Gateway-Ebenen-HQM 106 bereit. Wenn zum Beispiel eine Funktion als Dienst des physischen Racks 204 ein Ergebnis für eine entsprechende der Dienstanforderungen 104 erzeugt, sendet die Gateway-Kommunikationsschnittstelle 226 das Ergebnis an die Gateway-Ebenen-HQM 106, so dass die Gateway-Ebenen-HQM 106 das Ergebnis an ein entsprechendes Client-Gerät 105 senden kann.
  • Des Weiteren empfängt die Gateway-Kommunikationsschnittstelle 226 Konfigurationsinformationen, die von der Systemverwaltung 216 der Gateway-Ebenen-HQM 106 bereitgestellt werden. Zum Beispiel kann die Gateway-Kommunikationsschnittstelle 226 Diensttypkennungen und/oder Dienstkennungen empfangen, die Funktionen als Dienst angeben, die von Ressourcen des physischen Racks 204 bereitgestellt werden. Die Gateway-Kommunikationsschnittstelle 226 sendet diese Diensttypkennungen und/oder Dienstkennungen an die Dienstetabelle 234 zum Speichern in der Dienstetabelle 234, so dass die Rack-Ebenen-HQM 202 von den Funktionen als Dienst Kenntnis erlangt, die von ihren Ressourcen bereitgestellt werden.
  • Die Rack-Ebenen-HQM 202 ist mit der beispielhaften Anforderungsabrufeinrichtung 228 ausgestattet, um Pull-Anforderungen zur Verwendung beim Ziehen oder Abrufen von Dienstanforderungen 104 von der Gateway-Ebenen-HQM 106 zu erzeugen. Wenn zum Beispiel Einschubebenenressourcen des physischen Racks 204 zur Verfügung stehen, um Funktionen als Dienst bereitzustellen, und/oder wenn in den Warteschlangen 238a, b Platz für zusätzliche Dienstanforderungen 104 zur Verfügung steht, kann die Anforderungsabrufeinrichtung 228 eine oder mehrere Pull-Anforderungen erzeugen, um eine oder mehrere Dienstanforderungen 104 von der Gateway-Ebenen-HQM 106 abzurufen. Bei dem veranschaulichten Beispiel erzeugt die Anforderungsabrufeinrichtung 228 Pull-Anforderungen basierend auf Diensttypkennungen und/oder Dienstkennungen, die in der Dienstetabelle 234 gespeichert sind, indem die Diensttypkennungen und/oder Dienstkennungen in Pull-Anforderungen eingeschlossen werden, um zu spezifizieren, welche Dienstanforderungen 104 von der Gateway-Ebenen-HQM 106 zu ziehen sind. Bei dem veranschaulichten Beispiel von 2A erzeugt die Anforderungsabrufeinrichtung 228 eine Pull-Anforderung, die als „PullRequest(AFaaS/FaaS ID-LIST)“ gezeigt ist, die von der Gateway-Kommunikationsschnittstelle 226 der Rack-Ebenen-HQM 202 an die HQM-Kommunikationsschnittstelle 136 der Gateway-Ebenen-HQM 106 gesendet wird. Die Pull-Anforderung „PullRequest(AFaaS/FaaS ID-LIST)“ des veranschaulichten Beispiels ist so strukturiert, dass sie eine Liste (z. B. ID-LIST) von Diensttypkennungen und/oder Dienstkennungen enthält, die Typen von Funktionen als Dienst oder spezifische Funktionen als Dienst spezifizieren, für die Dienstanforderungen 104 aus den Warteschlangen 108a, b der Gateway-Ebenen-HQM 106 gezogen werden sollten.
  • Nach dem Empfangen von Dienstanforderungen 104 von der Gateway-Ebenen-HQM 106 kann die beispielhafte Anforderungsabrufeinrichtung 228 die Dienstanforderungen 104 in einigen der Warteschlangen 238a, b speichern. Auf diese Weise können die beispielhaften Einschub-Ebenen-HQMs 206a, b die Dienstanforderungen 104 aus den Warteschlangen 238a, b ziehen, um die Funktionen als Dienst auszuführen, die in den Dienstanforderungen 104 spezifiziert sind.
  • Die Rack-Ebenen-HQM 202 ist mit der beispielhaften Rack-Verwaltung 230 ausgestattet, um verschiedene Aspekte der Rack-Ebenen-HQM 202 zu verwalten. Zum Beispiel können mehrere physische Racks zusätzlich zu dem in 2A gezeigten physischen Rack 204 in Verbindung mit dem Edge-Gateway 102 stehen. Bei einigen Beispielen können mehrere der physischen Racks die gleichen Funktionen als Dienst anbieten. Diese redundanten Funktionen als Dienst über mehrere physische Racks können dafür verwendet werden, um die Last einiger der Dienstanforderungen 104, welche die gleiche Funktion als Dienst spezifizieren, durch Verteilen dieser Dienstanforderungen 104 über verschiedene der physischen Racks auszugleichen. Um einen derartigen Lastausgleich zu erreichen, kann die beispielhafte Rack-Verwaltung 230 durch die Systemverwaltung 216 der Gateway-Ebenen-HQM 106 mit Lastausgleichsregeln konfiguriert sein, welche die Anzahl an Dienstanforderungen begrenzen, die die Rack-Ebenen-HQM 202 von der Gateway-Ebenen-HQM 106 ziehen kann, wie vorstehend beschrieben. Desgleichen können Rack-Verwaltungen von Rack-Ebenen-HQMs in anderen physischen Racks, die mit dem Edge-Gateway 102 verbunden sind, ebenfalls mit ähnlichen Lastausgleichsregeln konfiguriert sein. Zum Beispiel kann die Rack-Verwaltung 230 eine Dienstanforderungsgrenze durchsetzen, die spezifiziert, dass die Anforderungsabrufeinrichtung 228 in einer einzelnen Pull-Anforderung oder in aufeinanderfolgenden Pull-Anforderungen Dienstanforderungen 104 bis zu einer maximalen Menge ziehen kann. Zusätzlich oder alternativ kann die Rack-Verwaltung 230 eine Dienstanforderungsgrenze durchsetzen, die spezifiziert, dass die Anforderungsabrufeinrichtung 228 eine einzelne Dienstanforderung 104 oder eine maximale Menge an Dienstanforderungen 104 innerhalb einer spezifizierten Zeitspanne ziehen kann.
  • Bei einigen Beispielen können verschiedene der physischen Racks, die mit dem Edge-Gateway 102 verbunden sind, dafür zugeordnet sein, verschiedene Funktionen als Dienst auszuführen, basierend auf zum Beispiel verschiedenen Ressourcen der physischen Racks und/oder auf dem Erfordernis, einige Funktionen als Dienst auf einigen physischen Racks schneller als andere Funktionen als Dienst auf anderen physischen Racks auszuführen. Bei diesen Beispielen kann die Rack-Verwaltung 230 dafür programmiert sein, basierend auf Funktionen als Dienst, die in der Dienstetabelle 234 als von dem physischen Rack 204 bereitgestellt spezifiziert sind, zu steuern, welche Dienstanforderungen 104 von der Anforderungsabrufeinrichtung 228 von der Gateway-Ebenen-HQM 106 gezogen werden können.
  • Die Rack-Ebenen-HQM 202 ist mit der beispielhaften Einschub-Kommunikationsschnittstelle 236 ausgestattet, um Pull-Anforderungen von den Einschub-Ebenen-HQMs 206a, b zu empfangen und in Antwort auf die Pull-Anforderungen Dienstanforderungen 104 von den Warteschlangen 238a, b an die Einschub-Ebenen-HQMs 206a, b zu senden. Des Weiteren empfängt die Einschub-Kommunikationsschnittstelle 236 die Ergebnisse von den Einschub-Ebenen-HQMs 206a, b, wenn Einschubebenenressourcen die Funktionen als Dienst ausführen, die in den Dienstanforderungen 104 spezifiziert sind, und entsprechende Ergebnisse erzeugen. Die beispielhafte Einschub-Kommunikationsschnittstelle 236 sendet die Ergebnisse an die Gateway-Kommunikationsschnittstelle 226, so dass die Ergebnisse hinauf zur Gateway-Ebenen-HQM 106 und hinaus an die entsprechenden Client-Geräte 105 übermittelt werden können.
  • Bei dem veranschaulichten Beispiel von 2A und 2B empfängt die Einschub-Kommunikationsschnittstelle 236 die Pull-Anforderungen, die in 2B als „Pull(AFaaS ID-LIST)“ gezeigt sind, von der Einschub-Ebenen-HQM 206a und eine „Pull(FaaS ID-LIST)“ von der Einschub-Ebenen-HQM 206b. Die „Pull(AFaaS ID-LIST)“ und die „Pull(FaaS ID-LIST)“ des veranschaulichten Beispiels sind so strukturiert, dass sie Listen (z. B. ID-LIST) von Diensttypkennungen und/oder Dienstkennungen enthalten, um mehrere Dienstanforderungen 104 zu spezifizieren, die aus den Warteschlangen 238a, b der Rack-Ebenen-HQM 202 gezogen werden sollen.
  • Wie bei dem Beispiel von 2B gezeigt, ist der Einschub ,0' 208a mit beispielhaften Ressourcen 242a, b in Schaltung mit der Einschub-Ebenen-HQM 206a ausgestattet, und der Einschub ,1' 208b ist mit beispielhaften Ressourcen 244a, b in Schaltung mit der Einschub-Ebenen-HQM 206b ausgestattet. Die beispielhaften Ressourcen 242a, b des Einschubs ,0' 208a sind Ressourcen vom Typ eines Beschleunigers (z. B. ähnlich oder im Wesentlichen identisch mit den Ressourcen 118 des Beschleunigers N von 1), die Dienstanforderungen 104 entsprechend Funktionen als Dienst verarbeiten, die durch Hardware-Beschleunigungsressourcen umgesetzt sind. Die beispielhaften Ressourcen 244a, b des Einschubs ,1' 208b sind Ressourcen vom Typ Plattform (z. B. Xeon-Plattformen) (z. B. ähnlich oder im Wesentlichen identisch mit den Plattformressourcen 116a, b von 1), die Funktionen als Dienst entsprechen, die durch software-basierte Ressourcen umgesetzt sind. Bei dem veranschaulichten Beispiel stellt die Einschub-Ebenen-HQM 206a Dienstanforderungen 104 bereit, die von der/den Warteschlange(n) 238a, b der Rack-Ebenen-HQM 202 in die Ressourcen 242a, b vom Typ Beschleuniger abgerufen werden. Bei dem veranschaulichten Beispiel stellt außerdem die Einschub-Ebenen-HQM 206b Dienstanforderungen 104 bereit, die von den Warteschlangen 238a, b der Rack-Ebenen-HQM 202 in die Ressourcen 244a, b vom Typ Plattform abgerufen werden. Auf diese Weise können die Ressourcen 242a, b vom Typ Beschleuniger des Einschubs ,0' 208a Dienstanforderungen 104 von der Einschub-Ebenen-HQM 206a ziehen, wenn verfügbar, um Funktionen als Dienst auszuführen, die in diesen Dienstanforderungen 104 spezifiziert sind. In ähnlicher Weise können die Ressourcen 244a, b vom Typ Plattform des Einschubs ,1' 208b Dienstanforderungen 104 von der Einschub-Ebenen-HQM 206b ziehen, wenn verfügbar, um Funktionen als Dienst auszuführen, die in diesen Dienstanforderungen 104 spezifiziert sind. Bei dem veranschaulichten Beispiel beinhalten die Ressourcen 242a, b vom Typ Beschleuniger und die Ressourcen 244a, b vom Typ Plattform entsprechende Warteschlangen zum Speichern von Dienstanforderungen 104, für die die Ressourcen 242a, b vom Typ Beschleuniger und die Ressourcen 244a, b vom Typ Plattform Funktionen als Dienst ausführen werden. Wenn deren Dienstanforderungen 104 in ihren entsprechenden Warteschlangen unter einen Grenzwert fallen, senden die Ressourcen 242a, b vom Typ Beschleuniger und die Ressourcen 244a, b vom Typ Plattform Pull-Anforderungen an die entsprechenden Einschub-Ebenen-HQMs 206a, b, um mehr Dienstanforderungen von der Rack-Ebenen-HQM 202 abzurufen.
  • Bei dem veranschaulichten Beispiel von 2B ist die Einschub-Ebenen-HQM 206a mit einer Anzahl an Komponenten gezeigt, die eine beispielhafte Rack-Kommunikationsschnittstelle 252, eine beispielhafte Dienstetabelle 254, eine beispielhafte Dienstregeltabelle 256 und eine beispielhafte Ressourcen-Kommunikationsschnittstelle 258 beinhalten. Obwohl nicht gezeigt, beinhaltet die beispielhafte Einschub-Ebenen-HQM 206b des Einschubs ,1' 208b außerdem ähnliche Komponenten wie die in der Einschub-Ebenen-HQM 206a des Einschubs ,0' 208a gezeigten.
  • Die Einschub-Ebenen-HQM 206a ist für die Kommunikation mit der Rack-Ebenen-HQM 202 mit der beispielhaften Rack-Kommunikationsschnittstelle 252 ausgestattet. Zum Beispiel sendet die Rack-Kommunikationsschnittstelle 252 Pull-Anforderungen (z. B. Pull(AFaaS ID-LIST)) an die Einschub-Kommunikationsschnittstelle 236 der Rack-Ebenen-HQM 202 und empfängt entsprechende Dienstanforderungen 104 von der Einschub-Kommunikationsschnittstelle 236. Des Weiteren sendet die Rack-Kommunikationsschnittstelle 252 Ergebnisse für entsprechende Dienstanforderungen 104, die durch die Ressourcen 242a, b vom Typ Beschleuniger erzeugt werden, an die Rack-Ebenen-HQM 202.
  • Die Einschub-Ebenen-HQM 206a ist mit der beispielhaften Dienstregeltabelle 254 ausgestattet, um Funktionen als Dienst zu identifizieren, die von den Ressourcen 242a, b vom Typ Beschleuniger des Einschubs ,0' 208a bereitgestellt werden. Die beispielhafte Dienstetabelle 254 kann durch die Systemverwaltung 216 der Gateway-Ebenen-HQM 106 mit Diensttypkennungen und/oder Dienstkennungen programmiert sein.
  • Die Einschub-Ebenen-HQM 206a ist mit der beispielhaften Dienstregeltabelle 256 ausgestattet, um Richtlinienregeln zu speichern, die Arten von Dienstanforderungen 104 angeben, die von der Rack-Ebenen-HQM 202 zu ziehen sind, und die Priorisierungen für das Verarbeiten dieser Dienstanforderungen 104 durch die Ressourcen 242a, b vom Typ Beschleuniger angeben. Richtlinienregeln können zum Beispiel spezifizieren, dass die Einschub-Ebenen-HQM 206a nur diejenigen der Dienstanforderungen 104 von der Rack-Ebenen-HQM 202 ziehen soll, die bestimmte Fristen und/oder bestimmte Umlauflatenzen aufweisen. Des Weiteren können beispielhafte Richtlinienregeln spezifizieren, dass denjenigen der Dienstanforderungen 104, die bestimmte Fristen und/oder Umlauflatenzen aufweisen, eine höhere Priorität zuzuweisen ist als anderen der Dienstanforderungen 104. Somit kann die Einschub-Ebenen-HQM 206a, wenn die Rack-Kommunikationsschnittstelle 252 mehrere Dienstanforderungen 104 von der Rack-Ebenen-HQM 202 empfängt, basierend auf den Richtlinienregeln in der Dienstregeltabelle 256 ein prioritätsbasiertes Planen der Dienstanforderungen 104 ausführen. Bei einigen Beispielen speichert die Dienstregeltabelle 256 außerdem Lastausgleichsregeln, um Lasten von Dienstanforderungen 104 über mehrere Ressourcen des Einschubs ,0' 208a, die die gleichen Funktionen als Dienst bereitstellen, auszugleichen.
  • Die Einschub-Ebenen-HQM 206a ist mit einer beispielhaften Ressourcen-Kommunikationsschnittstelle 258 ausgestattet, um Pull-Anforderungen von den Ressourcen 242a, b vom Typ Beschleuniger zu empfangen und in Antwort auf die Pull-Anforderungen entsprechende Dienstanforderungen 104 an die Ressourcen 242a, b vom Typ Beschleuniger zu senden. Bei dem veranschaulichten Beispiel von 2B senden die Ressourcen 242a, b vom Typ Beschleuniger Pull-Anforderungen (z. B. Pull(AFaaS ID)) an die Einschub-Ebenen-HQM 206a, wenn die Ressourcen 242a, b vom Typ Beschleuniger bereit sind, zusätzliche Dienstanforderungen 104 zu bedienen. (In ähnlicher Weise senden die beispielhaften Ressourcen 244a, b vom Typ Plattform Pull-Anforderungen (z. B. Pull(FaaS ID)) an die Einschub-Ebenen-HQM 206b, wenn die Ressourcen 244a, b vom Typ Plattform bereit sind, zusätzliche Dienstanforderungen 104 zu bedienen.) Die beispielhafte Ressourcen-Kommunikationsschnittstelle 258 empfängt außerdem Ergebnisse von den Ressourcen 242a, b vom Typ Beschleuniger, die denjenigen der Dienstanforderungen 104 entsprechen, die von den Ressourcen 242a, b vom Typ Beschleuniger bedient werden. Zum Beispiel können die Ressourcen 242a, b vom Typ Beschleuniger erzeugte Ergebnisse zu der Ressourcen-Kommunikationsschnittstelle 258 schieben (push), so dass die Rack-Kommunikationsschnittstelle 252 diese hinauf zur Rack-Ebenen-HQM 202 senden kann.
  • 3 veranschaulicht Peer-Edge-Gateways 302, 304 in Verbindung mit dem Edge-Gateway 102 von 1 und 2A, um einen Lastausgleich von Dienstanforderungen 104 (1) auf der Gateway-Ebene auszuführen. Bei dem veranschaulichten Beispiel ist das Edge-Gateway 102 in Verbindung mit mehreren physischen Racks gezeigt, die entsprechende Einschübe von Ressourcen aufweisen, welche das physische Rack 204 von 2A und die Einschübe 208a,b von 2B beinhalten. Die beispielhaften Peer-Edge-Gateways 302, 304 stehen ebenfalls in Verbindung mit entsprechenden physischen Racks, welche entsprechende Einschübe von Ressourcen beinhalten, die Funktionen als Dienst bereitstellen. Die beispielhaften Peer-Edge-Gateways 302, 304 und ihre entsprechenden physischen Racks und Einschübe beinhalten HQMs, die im Wesentlichen ähnlich oder identisch mit der Gateway-Ebenen-HQM 106, der Rack-Ebenen-HQM 202 und den Einschub-Ebenen-HQMs 206a, b von 1, 2A und 2B konfiguriert sind. Somit planen und verarbeiten die Peer-Edge-Gateways 302, 304 und ihre entsprechenden physischen Racks und Einschübe Dienstanforderungen 104 in einer Weise, die der vorstehend im Zusammenhang mit 1, 2A und 2B beschriebenen ähnlich ist. Die Edge-Gateways 102, 302, 304 können über Ethernet-Verbindungen, über das Internet und/oder über eine beliebige andere vernetzende Schnittstelle miteinander kommunizieren.
  • Bei dem veranschaulichten Beispiel von 3 führen die Edge-Gateways 102, 302, 304 einen Lastausgleich der Dienstanforderungen 104 aus, um Funktionen als Dienst schneller und effizienter auszuführen. Um diesen Lastausgleich auszuführen, kommunizieren die Edge-Gateways 102, 302, 304 miteinander, um einander darüber in Kenntnis zu setzen, wie viele Dienstanforderungen 104 in ihren entsprechenden Warteschlangen (z. B. den Warteschlangen 108a, b von 1 und 2A) auf eine Verarbeitung warten. Auf diese Weise kann eines der Edge-Gateways 102, 302, 304 Dienstanforderungen 104 von einem oder mehreren anderen der Edge-Gateways 102, 302, 304 ziehen, wenn dieses eine der Edge-Gateways 102, 302, 304 eine Kapazität oder Verfügbarkeit zum Verarbeiten von Dienstanforderungen 104 aufweist.
  • Bei dem veranschaulichten Beispiel von 3 sendet das Edge-Gateway 102 periodisch (z. B. alle N Zeiteinheiten) oder aperiodisch (z. B. ereignisgesteuert, basierend auf der Menge anhängiger Dienstanforderungen 104, basierend auf der Verfügbarkeit von Ressourcen usw.) eine Nachricht 308 zu anhängigen Dienstanforderungen, die eine Menge anhängiger Dienstanforderungen‘ beinhalten, welche die Menge der Dienstanforderungen 104 angibt, die in den Warteschlangen 108a, b des Edge-Gateway 102 geplant sind. Zum Beispiel kann die Gateway-Ebenen-HQM 106 (1 und 2A) ihre HQM-Kommunikationsschnittstelle 136 (1 und 2A) verwenden, um die Nachricht 308 zu anhängigen Dienstanforderungen mit Hilfe eines Broadcast-, eines Multicast- und/oder eines Unicast-Übertragungsmodus an Gateway-Ebenen-HQMs der Peer-Edge-Gateways 302, 304 zu senden. Bei einigen Beispielen erzeugt die Systemverwaltung 216 der Gateway-Ebenen-HQM 106 die Nachricht 308 zu anhängigen Dienstanforderungen derart, dass sie Dienstparameter beinhaltet, die den anhängigen Dienstanforderungen 104 entsprechen. Bei dem veranschaulichten Beispiel senden die Peer-Edge-Gateways 302, 304 Pull-Anforderungen 312, 314 (z.B. PullRequest(FaaS/AFaaS ID-LIST)) an die Gateway-Ebenen-HQM 106 des Edge-Gateway 102, um diejenigen der Dienstanforderungen 104 zu ziehen oder abzurufen, die von Funktionen als Dienst verarbeitet werden können, die von Ressourcen in den physischen Racks der Edge-Gateways 302, 304 bereitgestellt werden. Zum Beispiel beinhalten die Pull-Anforderungen 312, 314 Listen (z. B. ID-LIST) von Diensttypkennungen und/oder Dienstkennungen, die Typen von Funktionen als Dienst oder spezifische Funktionen als Dienst spezifizieren, für die Dienstanforderungen 104 von den Warteschlangen 108a, b der Gateway-Ebenen-HQM 106 gezogen werden sollten. Bei einigen Beispielen sind die Peer-Edge-Gateways 302, 304 dafür konfiguriert, die Pull-Anforderungen 312, 314 basierend darauf an das Edge-Gateway 102 zu senden, wenn die Anzahl an Dienstanforderungen in ihren Warteschlangen so abnimmt, dass ein Minimalwarteschlangen-Grenzwert erfüllt ist. Das heißt, wenn die Anzahl an Dienstanforderungen bei oder unter dem Minimalwarteschlangen-Grenzwert liegt, werden die Gateway-Ebenen-HQMs der Peer-Edge-Gateways 302, 304 angesteuert, die Pull-Anforderungen 312, 314 an das Edge-Gateway 102 zu senden. Als Antwort sendet die Gateway-Ebenen-HQM 106 Dienstanforderungen 104, die den Diensttypkennungen und/oder Dienstkennungen der Pull-Anforderungen 312, 314 entsprechen, an die Edge-Gateways 302, 304.
  • Die beispielhaften Peer-Edge-Gateways 302, 304 können außerdem Nachrichten 308 zu anhängigen Dienstanforderungen an einander und an das Edge-Gateway 102 senden, so dass zwischen beliebigen der Edge-Gateways 102, 302, 304 ähnliche Übertragungen von Dienstanforderungen 104 vorgenommen werden können. Auf diese Weise kann ein Lastausgleich der Dienstanforderungen 104 über die Edge-Gateways 102, 302, 304 verwendet werden, um eine höhere Dienstgüte für Client-Geräte 105 bereitzustellen, die Funktionen als Dienst betreffen, und Ressourcen, die zu den Peer-Edge-Gateways 102, 302, 304 gehören, können effizienter genutzt werden.
  • Während in 2A und 2B eine beispielhafte Art und Weise des Umsetzens der Gateway-Ebenen-HQM 106, der Rack-Ebenen-HQM 202 und der Einschub-Ebenen-HQMs 206a, b veranschaulicht ist, können eines oder mehrere der Elemente, Prozesse und/oder Geräte, die in 2A und 2B veranschaulicht sind, kombiniert, geteilt, neu angeordnet, ausgelassen, entfernt und/oder auf eine andere Weise umgesetzt sein. Des Weiteren können die beispielhafte Client-Kommunikationsschnittstelle 212, die beispielhafte Authentifizierungseinrichtung 214, die beispielhafte Systemverwaltung 216, die beispielhafte Anforderung-Client-Abbildung 218, der beispielhafte Parser 220, die beispielhafte Priorisierungseinrichtung 222, der beispielhafte Anforderungsplaner 224, die beispielhafte HQM-Kommunikationsschnittstelle 136, die beispielhafte Gateway-Kommunikationsschnittstelle 226, die beispielhafte Anforderungsabrufeinrichtung 228, die beispielhafte Rack-Verwaltung 230, die beispielhafte Dienstetabelle 234, die beispielhafte Einschub-Kommunikationsschnittstelle 236, die beispielhafte Rack-Kommunikationsschnittstelle 252, die beispielhafte Dienstetabelle 254, die beispielhafte Dienstregeltabelle 256, die beispielhafte Ressourcen-Kommunikationsschnittstelle 258 und/oder allgemeiner die beispielhafte Gateway-Ebenen-HQM 106, die beispielhafte Rack-Ebenen-HQM 202 und die beispielhaften Einschub-Ebenen-HQMs 206a, b der 1, 2A und 2B durch Hardware, Software, Firmware und/oder eine Kombination aus Hardware, Software und/oder Firmware umgesetzt sein. Somit könnten zum Beispiel beliebige der beispielhaften Client-Benutzerschnittstelle 212, der beispielhaften Authentifizierungseinrichtung 214, der beispielhaften Systemverwaltung 216, der beispielhaften Anforderung-Client-Abbildung 218, des beispielhaften Parsers 220, der beispielhaften Priorisierungseinrichtung 222, des beispielhaften Anforderungsplaners 224, der beispielhaften HQM-Kommunikationsschnittstelle 136, der beispielhaften Gateway-Kommunikationsschnittstelle 226, der beispielhaften Anforderungsabrufeinrichtung 228, der beispielhaften Rack-Verwaltung 230, der beispielhaften Dienstetabelle 234, der beispielhaften Einschub-Kommunikationsschnittstelle 236, der beispielhaften Rack-Kommunikationsschnittstelle 252, der beispielhaften Dienstetabelle 254, der beispielhaften Dienstregeltabelle 256, der beispielhaften Ressourcen-Kommunikationsschnittstelle 258 und/oder allgemeiner der beispielhaften Gateway-Ebenen-HQM 106, der beispielhaften Rack-Ebenen-HQM 202 und der beispielhaften Einschub-Ebenen-HQMs 206a, b durch eine oder mehrere analoge oder digitale Schaltungen, Logikschaltungen, programmierbare Prozessoren, programmierbare Steuerungen, Grafikverarbeitungseinheiten (GPUs), Digitalsignalprozessoren (DSPs), anwendungsspezifische integrierte Schaltungen (ASICs), FPGAs (Field Programmable Gate Arrays), programmierbare Logikgeräte (PLDs) und/oder feldprogrammierbare Logikgeräte (FPLDs) umgesetzt sein. Werden beliebige der Vorrichtungs- oder Systemansprüche dieser Patentschrift dahingehend gelesen, dass sie eine reine Software- und/oder Firmware-Umsetzung umfassen, ist mindestens eines von der beispielhaften Client-Kommunikationsschnittstelle 212, der beispielhaften Authentifizierungseinrichtung 214, der beispielhaften Systemverwaltung 216, der beispielhaften Anforderung-Client-Abbildung 218, des beispielhaften Parsers 220, der beispielhaften Priorisierungseinrichtung 222, des beispielhaften Anforderungsplaners 224, der beispielhaften HQM-Kommunikationsschnittstelle 136, der beispielhaften Gateway-Kommunikationsschnittstelle 226, der beispielhaften Anforderungsabrufeinrichtung 228, der beispielhaften Rack-Verwaltung 230, der beispielhaften Dienstetabelle 234, der eine beispielhaften Einschub-Kommunikationsschnittstelle 236, der beispielhaften Rack-Kommunikationsschnittstelle 252, der beispielhaften Dienstetabelle 254, der beispielhaften Dienstregeltabelle 256, der beispielhaften Ressourcen-Kommunikationsschnittstelle 258 und/oder allgemeiner der beispielhaften Gateway-Ebenen-HQM 106, der beispielhaften Rack-Ebenen-HQM 202 und der beispielhaften Einschub-Ebenen-HQMs 206a, b hiermit ausdrücklich als ein nichtflüchtiges computerlesbares Speichergerät oder einen nichtflüchtigen computerlesbaren Plattenspeicher, wie einen Kurzzeitspeicher, eine DVD (Digital Versatile Disk), eine CD (Compact Disk), eine Blu-Ray-Disk beinhaltend definiert, der/die die Software und/oder Firmware beinhalten. Ferner können die beispielhafte Gateway-Ebenen-HQM 106, die beispielhafte Rack-Ebenen-HQM 202 und die beispielhaften Einschub-Ebenen-HQMs 206a, b ein oder mehrere Elemente, Prozesse und/oder Geräte zusätzlich zu den oder anstelle der in 1, 2A und 2b veranschaulichten beinhalten und/oder können mehr als eines von einigen oder allen der veranschaulichten Elemente, Prozesse und Geräte beinhalten. Wenn im Vorliegenden verwendet, schließt die Formulierung „in Verbindung“, einschließlich ihrer Varianten, direkte Verbindung und/oder indirekte Verbindung durch eine oder mehrere Zwischenkomponenten ein und erfordert keine direkte physische (z. B. verdrahtete) Verbindung und/oder konstante Verbindung, sondern beinhaltet stattdessen zusätzlich selektive Verbindungen in periodischen Intervallen, geplanten Intervallen aperiodischen Intervallen und/oder in einmaligen Ereignissen.
  • Bei im Vorliegenden offenbarten Beispielen können Mittel zum Planen der Dienstanforderungen 104 durch den Anforderungsplaner 224 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Senden von Pull-Anforderungen an die Gateway-Ebenen-HQM 106 durch die Gateway-Kommunikationsschnittstelle 226 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Senden von Pull-Anforderungen an die Rack-Ebenen-HQM 202 durch die Rack-Kommunikationsschnittstelle 252 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Senden der Nachricht 308 zu anhängigen Dienstanforderungen an ein Peer-Edge-Gateway 302, 304 durch die HQM-Kommunikationsschnittstelle 136 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Senden der Dienstanforderungen 104 an ein Peer-Edge-Gateway 302, 304 durch die HQM-Kommunikationsschnittstelle 136 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Zuordnen von Prioritäten zu den Dienstanforderungen 104 durch die Priorisierungseinrichtung 222 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Abbilden der Dienstanforderungen 104 auf entsprechende der Client-Geräte 105 durch die Anforderung-Client-Abbildung 218 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Senden von Ergebnissen, die durch Funktionen als Dienst erzeugt werden, an die Client-Geräte 105 durch die Client-Kommunikationsschnittstelle 212 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Speichern einer Diensttypkennung und/oder einer Dienstkennung in die Dienstetabelle 234 der Rack-Ebenen-HQM 202 und/oder in die Dienstetabelle 254 der Einschub-Ebenen-HQM 206a durch die Systemverwaltung 216 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Empfangen von Pull-Anforderungen an der Einschub-Ebenen-HQM 206a, b von entsprechenden Ressourcen 242a, b, 244a, b des Einschubs 208a, b zum Abrufen der Dienstanforderungen 104 durch die Ressourcen-Kommunikationsschnittstelle 258 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Senden der Dienstanforderungen 104 von der Einschub-Ebenen-HQM 206a, b an entsprechende Ressourcen 242a, b, 244a, b der Einschübe 208a, b durch die Ressourcen-Kommunikationsschnittstelle 258 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Speichern von Richtlinienregeln, die Typen von Dienstanforderungen angeben, die durch die Einschub-Ebenen-HQM 206a, b von der Rack-Ebenen-HQM 202 zu ziehen sind, durch die Dienstregeltabelle 256 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Speichern von Richtlinienregeln, die Prioritäten zum Verarbeiten der Dienstanforderungen 104 angeben, durch die Dienstregeltabelle 256 umgesetzt sein.
  • Bei im Vorliegenden offenbarten Beispielen können Mittel zum Parsen von Dienstanforderungen 104 durch den Parser 220 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Senden von Dienstanforderungen 104 an die Rack-Ebenen-HQM 202 durch die HQM-Kommunikationsschnittstelle 136 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Empfangen von Pull-Anforderungen von der Rack-Ebenen-HQM 202 durch die HQM-Kommunikationsschnittstelle 136 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Programmieren von Diensttypkennungen und/oder Dienstkennungen und/oder Richtlinienregeln in die Rack-Ebenen-HQM 202 und/oder die Einschub-Ebenen-HQM 206a durch die Systemverwaltung 216 umgesetzt sein.
  • Bei im Vorliegenden offenbarten Beispielen können Mittel zum Authentifizieren von Dienstanforderungen 104 durch die Authentifizierungseinrichtung 214 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Erzeugen und/oder Bereitstellen von Pull-Anforderungen zum Ziehen oder Abrufen von Dienstanforderungen von der Gateway-Ebenen-HQM 106 durch die Anforderungsabrufeinrichtung 228 umgesetzt sein. Bei im Vorliegenden offenbarten Beispielen kann die Einschub-Kommunikationsschnittstelle 236 der Rack-Ebenen-HQM 202 Mittel zum Empfangen von Pull-Anforderungen von der Einschub-Ebenen-HQM 206a, b und/oder Mittel zum Senden von Dienstanforderungen 104 an die Einschub-Ebenen-HQM 206a, b umsetzen. Bei im Vorliegenden offenbarten Beispielen kann die Rack-Verwaltung 230 Mittel zum Speichern von Lastausgleichsregeln, Mittel zum Durchsetzen von Dienstanforderungsgrenzen und Mittel zum Steuern, welche Dienstanforderungen 104 von der Gateway-Ebenen-HQM 106 gezogen werden können, umsetzen. Bei im Vorliegenden offenbarten Beispielen können die Warteschlangen 108a, b, 238a, b Mittel zum Speichern von Dienstanforderungen 104 umsetzen. Bei im Vorliegenden offenbarten Beispielen können Mittel zum Ausführen oder Umsetzen von Funktionen als Dienst durch die Ressourcen 242a, b, 244a, b der Einschübe 208a, b umgesetzt sein.
  • Ablaufdiagramme, die beispielhafte Hardware-Logik oder maschinenlesbare Anweisungen zum Umsetzen der beispielhaften Gateway-Ebenen-HQM 106, der beispielhaften Rack-Ebenen-HQM 202 und/oder der beispielhaften Einschub-Ebenen-HQM 206a, b darstellen, sind in 4, 5A und 5B gezeigt. Die maschinenlesbaren Anweisungen können ein oder mehrere Programme oder Abschnitte von einem oder mehreren Programmen zum Ausführen durch einen Prozessor sein, wie beispielsweise den Prozessor 612, der in der beispielhaften Prozessorplattform 600 gezeigt ist, die im Weiteren in Verbindung mit 6 erläutert wird. Das/die Programm(e) kann/können in Software verkörpert sein, die auf einem nichtflüchtigen computerlesbaren Speichermedium gespeichert ist, wie beispielsweise einer CD-ROM, einer Diskette, einer Festplatte, einer DVD, einer Blu-ray-Disk oder einem zum Prozessor 612 gehörenden Speicher, die Gesamtheit des Programms/der Programme und/oder Teile davon könnte jedoch alternativ durch ein anderes Gerät als den Prozessor 612 ausgeführt werden und/oder in Firmware oder dedizierter Hardware verkörpert sein. Ferner können, obschon das/die beispielhafte(n) Programm(e) mit Bezug auf die in 4, 5A und 5B veranschaulichten Ablaufdiagrammen beschrieben ist/sind, alternativ viele andere Verfahren des Umsetzens der beispielhaften Gateway-Ebenen-HQM 106, der beispielhaften Rack-Ebenen-HQM 202 und der beispielhaften Einschub-Ebenen-HQMs 206a, b angewandt werden. Zum Beispiel kann die Reihenfolge der Ausführung der Blöcke geändert werden und/oder einige der beschriebenen Blöcke können verändert, entfernt oder kombiniert werden. Zusätzlich oder alternativ können einige oder alle Blöcke durch eine oder mehrere Hardware-Schaltungen (z. B. separate und/oder integrierte analoge und/oder digitale Schaltungen, ein FPGA, eine ASIC, eine Vergleichsschaltung, ein Operationsverstärker (op-amp), eine Logikschaltung usw.) umgesetzt und dafür strukturiert sein, die entsprechende Operation ohne Ausführen von Software oder Firmware durchzuführen.
  • Wie vorstehend erwähnt, können die beispielhaften Prozesse der 4, 5A und 5B mit Hilfe ausführbarer Anweisungen (z. B. computer- und/oder maschinenlesbarer Anweisungen) umgesetzt werden, die in einem nichtflüchtigen computer- und/oder maschinenlesbaren Medium gespeichert sind, wie beispielsweise einem Festplattenlaufwerk, einem Flash-Speicher, einem Nur-LeseSpeicher, einer CD, einer DVD, einem Cache-Speicher, einem Speicher mit wahlfreiem Zugriff und/oder einem anderen Speichergerät oder einer anderen Speicherplatte, auf denen Informationen für eine beliebige Dauer gespeichert sind (z. B. für längere Zeitspannen, dauerhaft, für kurze Zeiten, zum temporären Zwischenspeichern und/oder zum Cachen der Informationen). Wenn im Vorliegenden verwendet, ist der Ausdruck nichtflüchtiges computerlesbares Medium ausdrücklich als einen beliebigen Typ computerlesbaren Speichergeräts und/oder computerlesbarer Speicherplatte beinhaltend und das Verbreiten von Signalen ausschließend und Übertragungsmedien ausschließend definiert.
  • „Beinhaltend“ und „umfassend“ (sowie alle Formen und Zeitformen davon) werden im Vorliegenden als offene Ausdrücke verwendet. Somit versteht es sich, dass, wann immer ein Anspruch eine Form von „beinhalten“ oder „umfassen“ (z. B. umfasst, beinhaltet, umfassend, beinhaltend, aufweisend usw.) als einen Oberbegriff oder in einer Anspruchsrezitation jeglicher Art verwendet, zusätzliche Elemente, Ausdrücke usw. vorhanden sein können, ohne aus dem Geltungsbereich des entsprechenden Anspruchs oder der entsprechenden Rezitation zu fallen. Wenn im Vorliegenden verwendet, ist, wenn die Formulierung „mindestens“ als Übergangsausdruck in zum Beispiel einem Oberbegriff eines Anspruchs verwendet wird, diese in der gleichen Weise offen, wie die Ausdrücke „umfassend“ und „beinhaltend“ offen sind. Der Ausdruck „und/oder“ bezeichnet, wenn er zum Beispiel in einer Form verwendet wird wie A, B und/oder C, eine beliebige Kombination oder Teilmenge von A, B, C, wie beispielsweise (1) A allein, (2) B allein, (3) C allein, (4) A mit B, (5) A mit C und (6) B mit C.
  • 4 bildet ein Ablaufdiagramm ab, das beispielhafte computerlesbare Anweisungen darstellt, die ausgeführt werden können, um die beispielhafte Gateway-Ebenen-HQM 106 der 1, 2A und 2B umzusetzen, um Dienstanforderungen 104 (1) gemäß Lehren der vorliegenden Offenbarung umzusetzen. Der beispielhafte Prozess von 4 beginnt bei Block 402, bei dem die Gateway-Ebenen-HQM 106 die Dienstanforderungen 104 basierend auf Dienstparametern in den Dienstanforderungen 104 parst. Die beispielhafte Gateway-Ebenen-HQM 106 plant die Dienstanforderungen 104 in einer Warteschlange 108a, b (1 und 2A) basierend auf den Dienstparametern (Block 404). Die beispielhafte HQM-Kommunikationsschnittstelle 136 (1 und 2A) sendet einige der Dienstanforderungen 104 von der Warteschlange 108a, b an die Rack-Ebenen-HQM 202 (2A) des physischen Racks 204 (2A) in Schaltung mit dem Edge-Gateway 102 (1 und 2A) (Block 406). Zum Beispiel sendet die HQM-Kommunikationsschnittstelle 136 diejenigen der Dienstanforderungen 104, die Funktionen als Dienst entsprechen, welche von Ressourcen in dem physischen Rack 204 bereitgestellt werden. Dann endet der beispielhafte Prozess von 4.
  • 5A und 5B bilden Ablaufdiagramme ab, die beispielhafte computerlesbare Anweisungen darstellen, die ausgeführt werden können, um die beispielhafte Gateway-Ebenen-HQM 106 (1 und 2A), die beispielhafte Rack-Ebenen-HQM 202 (1 und 2A) und die beispielhaften Einschub-Ebenen-HQM 206a, b (2B) umzusetzen, um Dienstanforderungen 104 für Funktionen als Dienst zu planen. Die beispielhaften Ablaufdiagramme von 5A und 5B beinhalten einen beispielhaften Gateway-Ebenen-HQM-Prozess 502 (5A), einen beispielhaften Rack-Ebenen-HQM-Prozess 504 (5A und 5B) und einen beispielhaften Einschub-Ebenen-HQM-Prozess 506 (5B). Der Gateway-Ebenen-HQM-Prozess 502 wird durch die beispielhafte Gateway-Ebenen-HQM 106 durchgeführt. Der beispielhafte Rack-Ebenen-HQM-Prozess 504 wird durch die Rack-Ebenen-HQM 202 durchgeführt. Der beispielhafte Einschub-Ebenen-HQM-Prozess 506 wird durch die Einschub-Ebenen-HQM 206a durchgeführt. Jedoch kann auch die Einschub-Ebenen-HQM 206b den Einschub-Ebenen-HQM-Prozess 506 durchführen.
  • Der beispielhafte Gateway-Ebenen-HQM-Prozess 502 beginnt bei Block 512, bei dem die Systemverwaltung 216 (2A) Prioritätsregeln konfiguriert. Die Systemverwaltung 216 kann zum Beispiel Prioritätsregeln in die Priorisierungseinrichtung 222 (2A) der Gateway-Ebenen-HQM 106 und/oder in die Rack-Verwaltung 230 (2A) der Rack-Ebenen-HQM 202 programmieren. Die beispielhafte Systemverwaltung 216 konfiguriert Verfügbarkeiten von Funktionen als Dienst (Block 514). Zum Beispiel speichert die Systemverwaltung 216 Diensttypkennungen und/oder Dienstkennungen in die Dienstetabelle 234 der Rack-Ebenen-HQM 202 und/oder in die Dienstetabelle 254 der Einschub-Ebenen-HQM 206a. Die beispielhafte Client-Kommunikationsschnittstelle 212 (2A) empfängt Dienstanforderungen 104 (Block 516). Zum Beispiel empfängt die Client-Kommunikationsschnittstelle 212 die Dienstanforderungen 104 von den Client-Geräten 105 (1 und 2A). Die beispielhafte Authentifizierungseinrichtung 214 (2A) authentifiziert die Dienstanforderungen 104 (Block 518). Der beispielhafte Parser 220 (2A) parst die Dienstanforderungen 104 (Block 520). Zum Beispiel parst der Parser 220 die Dienstanforderungen 104 basierend auf Dienstparametern in den Dienstanforderungen 104. Die beispielhafte Priorisierungseinrichtung 222 (2A) priorisiert die Dienstanforderungen 104 (Block 522). Zum Beispiel priorisiert die Priorisierungseinrichtung 222 die Dienstanforderungen 104 basierend auf den Dienstparametern. Die Gateway-Ebenen-HQM 106 plant die Dienstanforderungen 104 (Block 524). Zum Beispiel plant der Anforderungsplaner 224 (2A) der Gateway-Ebenen-HQM 106 die Dienstanforderungen 104 in einer oder mehreren der Warteschlangen 108a, b basierend auf den Prioritätsebenen, die den Dienstanforderungen 104 durch die Priorisierungseinrichtung 222 zugeordnet werden. Bei einigen Beispielen bildet der Anforderungsplaner 224 außerdem anhängige der Dienstanforderungen 104 mit Kennungen entsprechender der Client-Geräte 105 in der Anforderung-Client-Abbildung 218 ab, so dass nachfolgend erzeugte Ergebnisse an die entsprechenden der Client-Geräte 105 gesendet werden können.
  • Bei dem veranschaulichten Beispiel rückt die Steuerung zu Block 526 vor, bei dem die Gateway-Ebenen-HQM 106 bestimmt, ob ein Lastausgleich durchzuführen ist. Zum Beispiel kann die Systemverwaltung 216 der Gateway-Ebenen-HQM 106 bestimmen, dass die Menge der Dienstanforderungen 104 in den Warteschlangen 108a, b eine Grenzwertmenge erfüllt, die angibt, wenn einige der Dienstanforderungen 104 an andere Peer-Edge-Gateways zu entladen oder zu übertragen sind, zum Beispiel die Peer-Edge-Gateways 302, 304 von 3. Wenn die Gateway-Ebenen-HQM 106 an Block 526 bestimmt, dass ein Lastausgleich durchgeführt werden soll, sendet die HQM-Kommunikationsschnittstelle 136 (1 und 2A) die beispielhafte Nachricht 308 zu anhängigen Dienstanforderungen (3) von dem Edge-Gateway 102 zu einem oder mehreren Peer-Edge-Gateways 302, 304 (Block 528). Die HQM-Kommunikationsschnittstelle 136 sendet eine oder mehrere der Dienstanforderungen 104 an das eine oder die mehreren Peer-Edge-Gateways 302, 304 in Antwort auf eine oder mehrere Pull-Anforderungen 312, 314 von den Peer-Edge-Gateways 302, 304 (Block 530). Die beispielhafte(n) Pull-Anforderung(en) 312, 314 von den Peer-Edge-Gateways 302, 304 ist/sind die Antwort auf die Nachricht 308 zu anhängigen Dienstanforderungen, die von der HQM-Kommunikationsschnittstelle 136 gesendet wird. Bei dem veranschaulichten Beispiel kehrt die Steuerung nach Block 530 zu Block 516 zurück, um zusätzliche Dienstanforderungen 104 von den Client-Geräten 105 zu empfangen. Die Steuerung kann jedoch auch zu einer beliebigen anderen geeigneten Operation vorrücken. Außerdem rückt die Steuerung bei dem veranschaulichten Beispiel zu Block 532 vor, wenn die Gateway-Ebenen-HQM 106 bei Block 526 bestimmt, keinen Lastausgleich durchzuführen. Die Steuerung kann jedoch auch zu einer beliebigen anderen geeigneten Operation vorrücken.
  • Bei Block 532 bestimmt die HQM-Kommunikationsschnittstelle 136, ob von der Rack-Ebenen-HQM 202 eine Pull-Anforderung empfangen wurde. Zum Beispiel kann der Rack-Ebenen-HQM-Prozess 504 parallel ausgeführt werden, um Dienstanforderungen 104 in der Rack-Ebenen-HQM 202 zu verarbeiten. Nun bezugnehmend auf den beispielhaften Rack-Ebenen-HQM-Prozess 504 bestimmt die Rack-Verwaltung 230 (2A) bei Block 534, ob eine oder mehrere Dienstanforderungen 104 von der Gateway-Ebenen-HQM 106 zu ziehen sind. Zum Beispiel kann die Rack-Verwaltung 230 bei Block 534 bestimmen, (eine) Dienstanforderung(en) 104 von der Gateway-Ebenen-HQM 106 zu ziehen, wenn die Menge der Dienstanforderungen 104 in den Warteschlangen 238a, b des physischen Racks 204 unter einem Grenzwert liegt. Wenn die Rack-Verwaltung 230 bei Block 534 bestimmt, eine oder mehrere Dienstanforderungen 104 von der Gateway-Ebenen-HQM 106 zu ziehen, sendet die Rack-Ebenen-HQM 202 eine Pull-Anforderung für eine oder mehrere Dienstanforderungen 104 an die Gateway-Ebenen-HQM 106 (Block 538). Zum Beispiel erzeugt die beispielhafte Anforderungsabrufeinrichtung 228 (2A) die Pull-Anforderung und die Gateway-Kommunikationsschnittstelle 226 (2A) der Rack-Ebenen-HQM 202 sendet die Pull-Anforderung an die HQM-Schnittstelle 136 der Gateway-Ebenen-HQM 106. Bei einigen Beispielen erzeugt die Anforderungsabrufeinrichtung 228 die Pull-Anforderung basierend auf Richtlinien oder Regeln, die durch die Rack-Verwaltung 230 (2A) durchgesetzt werden.
  • Zurückkehrend zum beispielhaften Gateway-Ebenen-HQM-Prozess 502, rückt die Steuerung zu Block 540 vor, wenn die HQM-Kommunikationsschnittstelle 136 bei Block 532 bestimmt, dass sie die Pull-Anforderung von der Rack-Ebenen-HQM 202 empfangen hat. Bei Block 540 sendet die Gateway-Ebenen-HQM 106 eine oder mehrere Dienstanforderungen 104 an die Rack-Ebenen-HQM 202. Zum Beispiel sendet die HQM-Kommunikationsschnittstelle 136 der Gateway-Ebenen-HQM 106 in Antwort auf die Pull-Anforderung, die bei Block 532 empfangen wird, eine oder mehrere Dienstanforderungen 104 aus den Warteschlangen 108a, b an die Gateway-Kommunikationsschnittstelle 226 der Rack-Ebenen-HQM 202.
  • Zurückkehrend zum beispielhaften Rack-Ebenen-HQM-Prozess 504, empfängt die Rack-Ebenen-HQM 202 die Dienstanforderung(en) 104 von der Gateway-Ebenen-HQM 106 (Block 542). Die beispielhafte Anforderungsabrufeinrichtung 228 speichert die Dienstanforderungen 104 oder reiht sie in die Warteschlangen 238a, b des physischen Racks 204 ein (Block 544). Die Steuerung rückt dann zu Block 546 des in 5B gezeigten Rack-Ebenen-HQM-Prozesses 504 vor. Bei Block 546 bestimmt die Einschub-Kommunikationsschnittstelle 236 (2A) der Rack-Ebenen-HQM 202, ob von der Einschub-Ebenen-HQM 206a (2B) eine Pull-Anforderung empfangen wurde. Zum Beispiel kann der Einschub-Ebenen-HQM-Prozess 506 parallel ausgeführt werden, um die Dienstanforderungen 104 an der Einschub-Ebenen-HQM 206a zu verarbeiten. Nun bezugnehmend auf den beispielhaften Einschub-Ebenen-HQM-Prozess 506, bestimmt die Einschub-Ebenen-HQM 206a bei Block 548, ob eine oder mehrere Dienstanforderungen 104 von der Rack-Ebenen-HQM 202 zu ziehen sind. Zum Beispiel kann die Einschub-Ebenen-HQM 206a bei Block 548 bestimmen, Dienstanforderungen 104 von der Rack-Ebenen-HQM 202 zu ziehen, wenn sie eine oder mehrere Pull-Anforderungen von einer oder mehreren Ressourcen des Einschubs ,0' 208a (2B) (z. B. die Ressourcen 242a, b vom Typ Beschleuniger von 2B) empfängt. Wenn die Einschub-Ebenen-HQM 206a bei Block 548 bestimmt, eine oder mehrere Dienstanforderungen 104 von der Rack-Ebenen-HQM 202 zu ziehen, sendet die Einschub-Ebenen-HQM 206a eine Pull-Anforderung für eine oder mehrere Dienstanforderungen 104 an die Rack-Ebenen-HQM 202 (Block 550). Zum Beispiel sendet die Rack-Kommunikationsschnittstelle 252 der Einschub-Ebenen-HQM 206a die Pull-Anforderung an die Einschub-Kommunikationsschnittstelle 236 der Rack-Ebenen-HQM 202.
  • Zurückkehrend zum beispielhaften Rack-Ebenen-HQM-Prozess 504, rückt die Steuerung zu Block 552 vor, wenn die Einschub-Kommunikationsschnittstelle 236 bei Block 546 bestimmt, dass sie die Pull-Anforderung von der Einschub-Ebenen-HQM 206a empfangen hat. Bei Block 552 sendet die Rack-Ebenen-HQM 202 eine oder mehrere Dienstanforderungen 104 an die Einschub-Ebenen-HQM 206a. Zum Beispiel sendet die Einschub-Kommunikationsschnittstelle 236 der Rack-Ebenen-HQM 202 in Antwort auf die bei Block 546 empfangene Pull-Anforderung eine oder mehrere der Dienstanforderungen 104 aus den Warteschlangen 238a, b an die Rack-Kommunikationsschnittstelle 252 der Einschub-Ebenen-HQM 206a.
  • Zurückkehrend zum Einschub-Ebenen-HQM-Prozess 506, empfängt die Einschub-Ebenen-HQM 206a die Dienstanforderung(en) 104 (Block 554) über die Rack-Kommunikationsschnittstelle 252 von der Rack-Ebenen-HQM 202. Die Einschub-Ebenen-HQM 206a sendet die Dienstanforderung(en) 104 an eine oder mehrere Ressourcen des Einschubs ,0' 208a (Block 558). Zum Beispiel sendet die Ressourcen-Kommunikationsschnittstelle 258 der Einschub-Ebenen-HQM 206a die Dienstanforderung(en) 104 in Antwort auf das Empfangen einer oder mehrerer Pull-Anforderungen von den Ressourcen 242a, b vom Typ Beschleuniger an eine oder mehrere Ressourcen 242a, b vom Typ Beschleuniger.
  • Nachdem die Ressource(n) des Einschubs ,0' 208a für eine oder mehrere der Dienstanforderungen 104 eine oder mehrere Funktionen als Dienst durchgeführt haben, empfängt die Einschub-Ebenen-HQM 206a ein oder mehrere entsprechende Ergebnisse von den Ressourcen (Block 560). Zum Beispiel empfängt die Ressourcen-Kommunikationsschnittstelle 258 der Einschub-Ebenen-HQM 206a ein oder mehrere Ergebnisse von den Ressourcen 242a, b vom Typ Beschleuniger. Die Einschub-Ebenen-HQM 206a sendet das/die Ergebnis(se) an die Rack-Ebenen-HQM 202 (Block 562). Zum Beispiel sendet die Rack-Kommunikationsschnittstelle 252 der Einschub-Ebenen-HQM 206a das/die Ergebnis(se) an die Einschub-Kommunikationsschnittstelle 236 der Rack-Ebenen-HQM 202.
  • Zurückkehrend zum Rack-Ebenen-HQM-Prozess 504, rückt die Steuerung zu Block 566 vor, wenn die Einschub-Kommunikationsschnittstelle 236 der Rack-Ebenen-HQM 202 bei Block 564 bestimmt, dass sie das/die Ergebnis(se) von der Einschub-Ebenen-HQM 206a empfangen hat. Bei Block 566 sendet die Rack-Ebenen-HQM 202 das/die Ergebnis(se) an die Gateway-Ebenen-HQM 106. Zum Beispiel sendet die Gateway-Kommunikationsschnittstelle 226 der Rack-Ebenen-HQM 202 das/die Ergebnis(se) an die HQM-Kommunikationsschnittstelle 136 der Gateway-Ebenen-HQM 106.
  • Zurückkehrend zum beispielhaften Gateway-Ebenen-HQM-Prozess 502 von 5A, rückt die Steuerung zu Block 570 vor, wenn die HQM-Kommunikationsschnittstelle 136 der Gateway-Ebenen-HQM 106 bei Block 568 bestimmt, dass sie das/die Ergebnis(se) von der Rack-Ebenen-HQM 202 empfangen hat. Bei Block 570 sendet die Client-Kommunikationsschnittstelle 212 das/die Ergebnis(se) an entsprechende der Client-Geräte 105. Zum Beispiel kann die Client-Kommunikationsschnittstelle 212 die Anforderung-Client-Abbildung 218 (2A) der Gateway-Ebenen-HQM 106 verwenden, um diejenigen Client-Geräte 105 zu identifizieren, die dem/den Ergebnis(sen) entsprechen, und sendet das/die Ergebnis(se) an die identifizierten Client-Geräte 105. Die beispielhaften Prozesse 502, 504, 506 der 5A und 5B enden.
  • 6 ist ein Blockdiagramm einer beispielhaften Prozessorplattform 600, die dafür strukturiert ist, die Anweisungen der 4, 5A und/oder 5B auszuführen, um die beispielhafte Gateway-Ebenen-HQM 106 (1 und 2A), die beispielhafte Rack-Ebenen-HQM 202 (2A) und/oder die beispielhaften Einschub-Ebenen-HQMs 206a, b (2B) umzusetzen. Die Prozessorplattform 600 kann zum Beispiel ein Edge-Gateway, ein Spine-Switch, ein Top-of-Rack(ToR)-Switch, ein Server, ein Computer, eine Arbeitsstation oder ein beliebiger anderer Typ Rechengerät sein, das zum Umsetzen der HQMs 106, 202, 206a, b geeignet ist.
  • Die Prozessorplattform 600 des veranschaulichten Beispiels beinhaltet einen Prozessor 612. Der Prozessor 612 des veranschaulichten Beispiels ist Hardware. Der Prozessor 612 kann zum Beispiel durch eine oder mehrere integrierte Schaltungen, Logikschaltungen, Mikroprozessoren, GPUs, DSPs oder Controller von einer beliebigen gewünschten Familie oder einem beliebigen Hersteller umgesetzt sein. Der Hardware-Prozessor 612 kann ein Gerät auf Halbleiterbasis (z. B. Siliziumbasis) sein.
  • Der Prozessor 612 des veranschaulichten Beispiels beinhaltet einen lokalen Speicher 613 (z. B. einen Cache, einen statischen Speicher mit wahlfreiem Zugriff (SRAM) usw.). Der Prozessor 612 des veranschaulichten Beispiels steht über einen Bus 618 in Verbindung mit einem Hauptspeicher, der einen flüchtigen Speicher 614 und einen nichtflüchtigen Speicher 616 beinhaltet. Der flüchtige Speicher 614 kann durch SDRAM (Synchronous Dynamic Random Access Memory), DRAM (Dynamic Random Access Memory), RAMBUS®-DRAM (RDRAM®) und/oder einen beliebigen anderen Typ Speichergerät mit wahlfreiem Zugriff umgesetzt sein. Der nichtflüchtige Speicher 616 kann durch einen Flash-Speicher und/oder einen anderen gewünschten Typ Speichergerät umgesetzt sein. Der Zugriff auf den Hauptspeicher 614, 616 wird durch einen Speicher-Controller gesteuert.
  • Die Prozessorplattform 600 des veranschaulichten Beispiels beinhaltet außerdem eine Schnittstellenschaltung 620. Die Schnittstellenschaltung 620 kann durch einen beliebigen Typ Schnittstellenstandard umgesetzt sein, wie beispielsweise eine Ethernet-Schnittstelle, ein USB (Universal Serial Bus), eine Bluetooth®-Schnittstelle, eine Nahbereichskommunikations(NFC)-Schnittstelle und/oder eine PCI-Express-Schnittstelle.
  • Bei dem veranschaulichten Beispiel sind mit der Schnittstellenschaltung 620 ein oder mehrere Eingabegeräte 622 verbunden. Das/die Eingabegeräte(e) 622 gestatten es einem Benutzer, Daten und/oder Befehle in den Prozessor 612 einzugeben. Das/die Eingabegeräte können zum Beispiel durch einen Audiosensor, ein Mikrofon, eine Kamera (Standbild oder Video), eine Tastatur, eine Taste, eine Maus, einen Touchscreen, ein Trackpad, einen Trackball, ein Isopoint und/oder ein Spracherkennungssystem umgesetzt sein.
  • Mit der Schnittstellenschaltung 620 des veranschaulichten Beispiels sind auch ein oder mehrere Ausgabegeräte 624 verbunden. Die Ausgabegeräte 624 können zum Beispiel durch Anzeigegeräte (z. B. eine Leuchtdiode (LED), eine organische Leuchtdiode (OLED), eine Flüssigkristallanzeige (LCD), eine Kathodenstrahlröhren(CRT)-Anzeige, eine In-Plane-Switching(IPS)-Anzeige, einen Touchscreen usw.), ein Gerät für eine fühlbare Ausgabe, einen Drucker und/oder einen Lautsprecher umgesetzt sein. Die Schnittstellenschaltung 620 des veranschaulichten Beispiels beinhaltet somit typischerweise eine Grafiktreiberkarte, einen Grafiktreiber-Chip und/oder einen Grafiktreiberprozessor.
  • Die Schnittstellenschaltung 620 des veranschaulichten Beispiels beinhaltet außerdem ein Kommunikationsgerät wie beispielsweise einen Sender, einen Empfänger, einen Sendeempfänger, ein Modem, ein Residential Gateway, einen drahtlosen Zugangspunkt und/oder eine Netzwerk-Schnittstelle, um den Austausch von Daten mit externen Maschinen (z. B. Rechengeräte jeder Art) über ein Netzwerk 626 zu ermöglichen. Die Kommunikation kann zum Beispiel über eine Ethernet-Verbindung, eine DSL(Digital Subscriber Line)-Verbindung, eine Telefonleitungsverbindung, ein Koaxialkabelsystem, ein Satellitensystem, ein drahtloses Sichtverbindungssystem, ein Mobilfunksystem usw. erfolgen.
  • Die Prozessorplattform 600 des veranschaulichten Beispiels beinhaltet außerdem ein oder mehrere Massenspeichergeräte 628 zum Speichern von Software und/oder Daten. Beispiele für derartige Massenspeichergeräte 628 sind Diskettenlaufwerke, Festplattenlaufwerke, CD-Laufwerke, Blu-ray-Laufwerke, RAID(Redundant Array of Independent Disks)-Systeme und DVD(Digital Versatile Disk)-Laufwerke.
  • Maschinenausführbare Anweisungen 632 zum Umsetzen der beispielhaften Prozesse 502, 504, 506 von 5A und 5B können in dem Massenspeichergerät 628, in dem flüchtigen Speicher 614, in dem nichtflüchtigen Speicher 616 und/oder auf einem entfernbaren nichtflüchtigen computerlesbaren Speichermedium wie beispielsweise einer CD oder einer DVD gespeichert sein.
  • Bei Beispielen, bei denen die Prozessorplattform 600 die Gateway-Ebenen-HQM 106 (1 und 2A) umsetzt, setzt der Prozessor 612 die Authentifizierungseinrichtung 214, die Systemverwaltung 216, den Parser 220, die Priorisierungseinrichtung 222 und den Anforderungsplaner 224 von 2A um. Des Weiteren setzt die Schnittstelle 620 die Client-Kommunikationsschnittstelle 212 (2A) und die HQM-Kommunikationsschnittstelle 136 (1 und 2A) um. Des Weiteren können die Warteschlangen 108a, b (1 und 2A) und die Anforderung-Client-Abbildung 218 (2A) von dem lokalen Speicher 613 und/oder dem flüchtigen Speicher 614 und/oder dem nichtflüchtigen Speicher 616 umgesetzt sein.
  • Bei Beispielen, bei denen die Prozessorplattform 600 die Rack-Ebenen-HQM 202 (2A) umsetzt, setzt der Prozessor 612 die Anforderungsabrufeinrichtung 228 und die Rack-Verwaltung 230 von 2A um, setzt die Schnittstelle 620 die Gateway-Kommunikationsschnittstelle 226 und die Einschub-Kommunikationsschnittstelle von 2A um und die Dienstetabelle 234 und/oder die Warteschlangen 238a, b von 2A können von dem lokalen Speicher 613 und/oder dem flüchtigen Speicher 614 und/oder dem nichtflüchtigen Speicher 616 umgesetzt sein.
  • Bei Beispielen, bei denen die Prozessorplattform 600 die Einschub-Ebenen-HQM 206a umsetzt, setzt die Schnittstelle 620 die Rack-Kommunikationsschnittstelle 252 und die Ressourcen-Kommunikationsschnittstelle 258 von 2B um und die Dienstetabelle und die Dienstregeltabelle 256 können von dem lokalen Speicher 613 und/oder dem flüchtigen Speicher 614 und/oder dem nichtflüchtigen Speicher 616 umgesetzt sein.
  • Das Folgende betrifft weitere im Vorliegenden offenbarte Beispiele.
  • Beispiel 1 ist ein System zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe von Hardware-Warteschlangenverwaltungen. Das System von Beispiel 1 beinhaltet Folgendes: eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung in einem Edge-Gateway zum Planen der Dienstanforderungen, die von Client-Geräten empfangen werden, in einer Warteschlange, eine Rack-Ebenen-Hardware-Warteschlangenverwaltung in einem physischen Rack in Verbindung mit dem Edge-Gateway, wobei die Rack-Ebenen-Hardware-Warteschlangenverwaltung für das Senden einer Pull-Anforderung für eine erste der Dienstanforderungen an die Gateway-Ebenen-Hardware-Warteschlangenverwaltung vorgesehen ist, und eine Einschub-Ebenen-Hardware-Warteschlangenverwaltung in einem Einschub des physischen Racks, wobei die Einschub-Ebenen-Hardware-Warteschlangenverwaltung für das Senden einer zweiten Pull-Anforderung für die erste der Dienstanforderungen an die Rack-Ebenen-Hardware-Warteschlangenverwaltung vorgesehen ist, wobei der Einschub eine Ressource zum Bereitstellen einer Funktion als Dienst beinhaltet, die in der ersten der Dienstanforderungen spezifiziert ist.
  • Bei Beispiel 2 kann der Gegenstand von Beispiel 1 optional eine Hardware-Warteschlangenverwaltung-Kommunikationsschnittstelle in der Gateway-Ebenen-Hardware-Warteschlangenverwaltung beinhalten, wobei die Hardware-Warteschlangenverwaltung-Kommunikationsschnittstelle für Folgendes vorgesehen ist: Senden einer Nachricht zu anhängigen Dienstanforderungen von dem Edge-Gateway an ein Peer-Edge-Gateway, wobei die Nachricht zu anhängigen Dienstanforderungen eine Menge der Dienstanforderungen angibt, die in der Warteschlange geplant sind, und Senden einer zweiten der Dienstanforderungen an das Peer-Edge-Gateway in Antwort auf eine Pull-Anforderung von dem Peer-Edge-Gateway, wobei die Pull-Anforderung von dem Peer-Edge-Gateway in Antwort auf die Nachricht zu anhängigen Dienstanforderungen erfolgt.
  • Bei Beispiel 3 kann der Gegenstand von einem der Beispiele 1 bis 2 optional beinhalten, dass die Dienstanforderungen Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen beinhalten, und kann optional eine Priorisierungseinrichtung in der Gateway-Ebenen-Hardware-Warteschlangenverwaltung beinhalten, um den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen Prioritäten zuzuordnen.
  • Bei Beispiel 4 kann der Gegenstand von einem der Beispiele 1 bis 3 optional eine Anforderung-Client-Abbildung in der Gateway-Ebenen-Hardware-Warteschlangenverwaltung beinhalten, um anhängige der Dienstanforderungen mit Kennungen entsprechender der Client-Geräte abzubilden.
  • Bei Beispiel 5 kann der Gegenstand von einem der Beispiele 1 bis 4 optional eine Client-Kommunikationsschnittstelle in der Gateway-Ebenen-Hardware-Warteschlangenverwaltung beinhalten, um basierend auf der Anforderung-Client-Abbildung ein Ergebnis, das durch die Funktion als Dienst erzeugt wird, die in der ersten der Dienstanforderungen spezifiziert ist, an ein entsprechendes der Client-Geräte zu senden.
  • Bei Beispiel 6 kann der Gegenstand von einem der Beispiele 1 bis 5 optional eine erste Dienstetabelle in der Rack-Ebenen-Hardware-Warteschlangenverwaltung, eine zweite Dienstetabelle in der Einschub-Ebenen-Hardware-Warteschlangenverwaltung und eine Systemverwaltung in der Gateway-Ebenen-Hardware-Warteschlangenverwaltung beinhalten, wobei die Systemverwaltung dafür vorgesehen ist, eine Diensttypkennung und/oder eine Dienstkennung in der ersten und der zweiten Dienstetabelle zu speichern, welche die Funktion als Dienst angeben, die durch die Ressource des Einschubs bereitgestellt ist.
  • Bei Beispiel 7 kann der Gegenstand von einem der Beispiele 1 bis 6 optional eine Ressourcen-Kommunikationsschnittstelle in der Einschub-Ebenen-Hardware-Warteschlangenverwaltung beinhalten, um von der Ressource eine dritte Pull-Anforderung zum Abrufen der ersten der Dienstanforderungen zu empfangen.
  • Bei Beispiel 8 kann der Gegenstand von einem der Beispiele 1 bis 7 optional eine Dienstregeltabelle in der Einschub-Ebenen-Hardware-Warteschlangenverwaltung beinhalten, um eine erste Richtlinienregel zu speichern, die einen Typ einer Funktion als Dienst angibt, für die eine Dienstanforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung zu ziehen ist, und eine zweite Richtlinienregel, die eine Priorität zum Verarbeiten der ersten der Dienstanforderungen angibt.
  • Beispiel 9 ist ein System zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe von Hardware-Warteschlangenverwaltungen. Das System von Beispiel 9 beinhaltet Folgendes: Mittel zum Planen der Dienstanforderungen, die von Client-Geräten empfangen werden, in einer Warteschlange eines Edge-Gateways, Mittel zum Senden einer Pull-Anforderung von einem physischen Rack an eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung für eine erste der Dienstanforderungen und Mittel zum Senden einer zweiten Pull-Anforderung von einem Einschub des physischen Racks an eine Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks für die erste der Dienstanforderungen, wobei der Einschub eine Ressource zum Bereitstellen einer Funktion als Dienst beinhaltet, die in der ersten der Dienstanforderungen spezifiziert ist.
  • Bei Beispiel 10 kann der Gegenstand von Beispiel 9 optional Mittel zum Senden einer Nachricht zu anhängigen Dienstanforderungen von dem Edge-Gateway an ein Peer-Edge-Gateway beinhalten, wobei die Nachricht zu anhängigen Dienstanforderungen eine Menge der Dienstanforderungen angibt, die in der Warteschlange geplant sind, und die Mittel zum Senden der Nachricht zu anhängigen Dienstanforderungen dafür vorgesehen sind, in Antwort auf eine Pull-Anforderung von dem Peer-Edge-Gateway eine zweite der Dienstanforderungen an das Peer-Edge-Gateway zu senden, wobei die Pull-Anforderung von dem Peer-Edge-Gateway in Antwort auf die Nachricht zu anhängigen Dienstanforderungen erfolgt.
  • Bei Beispiel 11 kann der Gegenstand von einem der Beispiele 9 bis 10 optional beinhalten, dass die Dienstanforderungen Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen beinhalten und ferner Mittel zum Zuordnen von Prioritäten zu den Dienstanforderungen basierend auf den Fristen und/oder den Umlauflatenzen und/oder den Diensttypkennungen und/oder den Dienstkennungen beinhalten.
  • Bei Beispiel 12 kann der Gegenstand von einem der Beispiele 9 bis 11 optional Mittel zum Abbilden anhängiger der Dienstanforderungen mit Kennungen entsprechender der Client-Geräte beinhalten.
  • Bei Beispiel 13 kann der Gegenstand von einem der Beispiele 9 bis 12 optional Mittel zum Senden eines Ergebnisses, das durch die Funktion als Dienst erzeugt wird, die in der ersten der Dienstanforderungen spezifiziert ist, an ein entsprechendes der Client-Geräte basierend auf der Abbildung der anhängigen der Dienstanforderungen mit den Kennungen entsprechender der Client-Geräte beinhalten.
  • Bei Beispiel 14 kann der Gegenstand von einem der Beispiele 9 bis 13 optional Mittel zum Speichern einer Diensttypkennung und/oder einer Dienstkennung in einer ersten Dienstetabelle in der Rack-Ebenen-Hardware-Warteschlangenverwaltung und in einer zweiten Dienstetabelle in dem Einschub beinhalten, wobei die Diensttypkennung und/oder die Dienstkennung die Funktion als Dienst angeben, die von der Ressource des Einschubs bereitgestellt ist.
  • Bei Beispiel 15 kann der Gegenstand von einem der Beispiele 9 bis 14 optional Mittel zum Empfangen einer dritten Pull-Anforderung von der Ressource beinhalten, um die erste der Dienstanforderungen abzurufen.
  • Bei Beispiel 16 kann der Gegenstand von einem der Beispiele 9 bis 15 optional Mittel zum Speichern einer ersten Richtlinienregel, die einen Typ einer Funktion als Dienst angibt, für den eine Dienstanforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung zu ziehen ist, und einer zweiten Richtlinienregel, die eine Priorität zum Verarbeiten der ersten der Dienstanforderungen angibt, beinhalten.
  • Beispiel 17 ist ein nichtflüchtiges computerlesbares Speichermedium, das Anweisungen umfasst, die bei Ausführung mindestens einen Prozessor zu mindestens Folgendem veranlassen: Planen von Dienstanforderungen, die von Client-Geräten empfangen werden, in einer Warteschlange eines Edge-Gateways, Senden einer Pull-Anforderung für eine erste der Dienstanforderungen von einem physischen Rack an eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung und Senden einer zweiten Pull-Anforderung für die erste der Dienstanforderungen von einem Einschub des physischen Racks an eine Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks, wobei der Einschub eine Ressource beinhaltet, um eine Funktion als Dienst bereitzustellen, die in der ersten der Dienstanforderungen spezifiziert ist.
  • Bei Beispiel 18 kann der Gegenstand von Beispiel 17 optional beinhalten, dass die Anweisungen den mindestens einen Prozessor ferner zu Folgendem veranlassen: Senden einer Nachricht zu anhängigen Dienstanforderungen von dem Edge-Gateway an ein Peer-Edge-Gateway, wobei die Nachricht zu anhängigen Dienstanforderungen eine Menge der Dienstanforderungen angibt, die in der Warteschlange geplant sind, und Senden einer zweiten der Dienstanforderungen an das Peer-Edge-Gateway in Antwort auf eine Pull-Anforderung von dem Peer-Edge-Gateway, wobei die Pull-Anforderung von dem Peer-Edge-Gateway in Antwort auf die Nachricht zu anhängigen Dienstanforderungen erfolgt.
  • Bei Beispiel 19 kann der Gegenstand von einem der Beispiele 17 bis 18 optional beinhalten, dass die Dienstanforderungen Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen beinhalten und dass die Anweisungen ferner den mindestens einen Prozessor veranlassen, den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen Prioritäten zuzuordnen.
  • Bei Beispiel 20 kann der Gegenstand von einem der Beispiele 17 bis 19 optional beinhalten, dass die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, anhängige der Dienstanforderungen mit Kennungen entsprechender der Client-Geräte in einer Anforderung-Client-Abbildung der Gateway-Ebenen-Hardware-Warteschlangenverwaltung abzubilden.
  • Bei Beispiel 21 kann der Gegenstand von einem der Beispiele 17 bis 20 optional beinhalten, dass die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, basierend auf der Anforderung-Client-Abbildung ein Ergebnis, das durch die Funktion als Dienst erzeugt wird, die in der ersten der Dienstanforderungen spezifiziert ist, an ein entsprechendes der Client-Geräte zu senden.
  • Bei Beispiel 22 kann der Gegenstand von einem der Beispiele 17 bis 21 optional beinhalten, dass die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, eine Diensttypkennung und/oder eine Dienstkennung in einer ersten Dienstetabelle in der Rack-Ebenen-Hardware-Warteschlangenverwaltung und in einer zweiten Dienstetabelle in dem Einschub zu speichern, wobei die Diensttypkennung und/oder die Dienstkennung die Funktion als Dienst angeben, die von der Ressource des Einschubs bereitgestellt ist.
  • Bei Beispiel 23 kann der Gegenstand von einem der Beispiele 17 bis 22 optional beinhalten, dass die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, eine dritte Pull-Anforderung von der Ressource zu empfangen, um die erste der Dienstanforderungen abzurufen.
  • Bei Beispiel 24 kann der Gegenstand von einem der Beispiele 17 bis 23 optional beinhalten, dass die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, in einer Dienstregeltabelle eine erste Richtlinienregel zu speichern, wobei die erste Richtlinienregel einen Typ einer Funktion als Dienst angibt, für die eine Dienstanforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung zu ziehen ist, und eine zweite Richtlinienregel, die eine Priorität zum Verarbeiten der ersten der Dienstanforderungen angibt.
  • Beispiel 25 ist ein Verfahren zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe von Hardware-Warteschlangenverwaltungen. Das Verfahren von Beispiel 25 beinhaltet Folgendes: Planen der Dienstanforderungen, die von Client-Geräten empfangen werden, in einer Warteschlange eines Edge-Gateways, Senden einer Pull-Anforderung für eine erste der Dienstanforderungen von einem physischen Rack an eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung und Senden einer zweiten Pull-Anforderung für die erste der Dienstanforderungen von einem Einschub des physischen Racks an eine Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks, wobei der Einschub eine Ressource zum Bereitstellen einer Funktion als Dienst bereitstellt, die in der ersten der Dienstanforderungen spezifiziert ist.
  • Bei Beispiel 26 kann der Gegenstand von Beispiel 25 optional das Senden einer Nachricht zu anhängigen Dienstanforderungen von dem Edge-Gateway an ein Peer-Edge-Gateway beinhalten, wobei die Nachricht zu anhängigen Dienstanforderungen eine Menge der Dienstanforderungen angibt, die in der Warteschlange geplant sind, und das Senden einer zweiten der Dienstanforderungen an das Peer-Edge-Gateway in Antwort auf eine Pull-Anforderung von dem Peer-Edge-Gateway, wobei die Pull-Anforderung von dem Peer-Edge-Gateway in Antwort auf die Nachricht zu anhängigen Dienstanforderungen erfolgt.
  • Bei Beispiel 27 kann der Gegenstand von einem der Beispiele 25 bis 26 optional beinhalten, dass die Dienstanforderungen Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen beinhalten, und kann optional das Zuordnen von Prioritäten zu den Dienstanforderungen basierend auf den Fristen und/oder den Umlauflatenzen und/oder den Diensttypkennungen und/oder den Dienstkennungen beinhalten.
  • Bei Beispiel 28 kann der Gegenstand von einem der Beispiele 25 bis 27 optional das Abbilden anhängiger der Dienstanforderungen mit Kennungen entsprechender der Client-Geräte beinhalten.
  • Bei Beispiel 29 kann der Gegenstand von einem der Beispiele 25 bis 28 optional das Senden eines Ergebnisses, das durch die Funktion als Dienst erzeugt wird, die in der ersten der Dienstanforderungen spezifiziert ist, an ein entsprechendes der Client-Geräte basierend auf dem Abbilden der anhängigen der Dienstanforderungen mit den Kennungen entsprechender der Client-Geräte beinhalten.
  • Bei Beispiel 30 kann der Gegenstand von einem der Beispiele 25 bis 29 optional das Speichern einer Diensttypkennung und/oder einer Dienstkennung in einer ersten Dienstetabelle in der Rack-Ebenen-Hardware-Warteschlangenverwaltung und in einer zweiten Dienstetabelle in dem Einschub beinhalten, wobei die Diensttypkennung und/oder Dienstkennung die Funktion als Dienst angeben, die von der Ressource des Einschubs bereitgestellt wird.
  • Bei Beispiel 31 kann der Gegenstand von einem der Beispiele 25 bis 30 optional das Empfangen einer dritten Pull-Anforderung von der Ressource zum Abrufen der ersten der Dienstanforderungen beinhalten.
  • Bei Beispiel 32 kann der Gegenstand von einem der Beispiele 25 bis 31 optional das Speichern einer ersten Richtlinienregel, die einen Typ einer Funktion als Dienst angibt, für den eine Dienstanforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung zu ziehen ist, und einer zweiten Richtlinienregel, die eine Priorität zum Verarbeiten der ersten der Dienstanforderungen angibt, beinhalten.
  • Beispiel 33 ist eine Vorrichtung zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe einer Hardware-Warteschlangenverwaltung. Die Vorrichtung von Beispiel 33 beinhaltet Folgendes: eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung in einem Edge-Gateway, wobei die Gateway-Ebenen-Hardware-Warteschlangenverwaltung für Folgendes vorgesehen ist: Parsen der Dienstanforderungen basierend auf Dienstparametern in den Dienstanforderungen, und Planen der Dienstanforderungen in einer Warteschlange basierend auf den Dienstparametern, wobei die Dienstanforderungen von Client-Geräten empfangen werden, und eine Hardware-Warteschlangenverwaltung-Kommunikationsschnittstelle zum Senden einiger der Dienstanforderungen von der Warteschlange an die Rack-Ebenen-Hardware-Warteschlangenverwaltung eines physischen Racks in Schaltung mit dem Edge-Gateway, wobei die einigen der Dienstanforderungen Funktionen als Dienst entsprechen, die durch Ressourcen in den physischen Racks bereitgestellt sind.
  • Bei Beispiel 34 kann der Gegenstand von Beispiel 33 optional eine Client-Kommunikationsschnittstelle zum Senden von Ergebnissen an die Client-Geräte entsprechend den Dienstanforderungen beinhalten, wobei die Ergebnisse durch die Funktionen als Dienst erzeugt werden, die von dem physischen Rack bereitgestellt sind.
  • Bei Beispiel 35 kann der Gegenstand von einem der Beispiele 33 bis 34 optional beinhalten, dass die Hardware-Warteschlangenverwaltung-Kommunikationsschnittstelle ferner für Folgendes vorgesehen ist: Empfangen einer Pull-Anforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung, wobei die Pull-Anforderung eine erste Kennung beinhaltet, und Bereitstellen einer der Dienstanforderungen für die Rack-Ebenen-Hardware-Warteschlangenverwaltung in Antwort auf die Pull-Anforderung, wenn die erste Kennung einer zweiten Kennung der einen der Dienstanforderungen entspricht, wobei die erste Kennung eine Diensttypkennung und/oder eine Dienstkennung ist.
  • Bei Beispiel 36 kann der Gegenstand von einem der Beispiele 33 bis 35 optional beinhalten, dass sich die Rack-Ebenen-Hardware-Warteschlangenverwaltung an einer Top-of-Rack-Switch des physischen Racks befindet.
  • Bei Beispiel 37 kann der Gegenstand von einem der Beispiele 33 bis 36 optional beinhalten, dass die Dienstparameter Fristen und/oder Umlauflatenzen beinhalten, innerhalb derer Ergebnisse entsprechender der Dienstanforderungen an entsprechenden der Client-Geräte zu empfangen sind, und kann optional eine Priorisierungseinrichtung beinhalten, um den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen Prioritäten zuzuordnen.
  • Bei Beispiel 38 kann der Gegenstand von einem der Beispiele 33 bis 37 optional beinhalten, dass die Gateway-Ebenen-Hardware-Warteschlangenverwaltung dafür vorgesehen ist, die Dienstanforderungen in der Warteschlange basierend auf den zugeordneten Prioritäten der Dienstanforderungen zu planen.
  • Bei Beispiel 39 kann der Gegenstand von einem der Beispiele 33 bis 38 optional beinhalten, dass die Hardware-Warteschlangenverwaltung-Kommunikationsschnittstelle dafür vorgesehen ist, basierend auf den zugeordneten Prioritäten einig der Dienstanforderungen von der Warteschlange an die Rack-Ebenen-Hardware-Warteschlangenverwaltung zu senden, indem zuerst Dienstanforderungen mit höherer Priorität gesendet werden, bevor Dienstanforderungen mit niedrigerer Priorität gesendet werden.
  • Bei Beispiel 40 kann der Gegenstand von einem der Beispiele 33 bis 39 optional eine Systemverwaltung beinhalten, um die Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks mit einer von Kennungen, die den Funktionen als Dienst entsprechen, die von dem physischen Rack bereitgestellt werden, und/oder Richtlinienregeln zum Priorisieren einiger der Dienstanforderungen in dem physischen Rack zu programmieren.
  • Beispiel 41 ist eine Vorrichtung zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe einer Hardware-Warteschlangenverwaltung. Die Vorrichtung von Beispiel 41 beinhaltet Folgendes: Mittel zum Parsen der Dienstanforderungen basierend auf Dienstparametern in den Dienstanforderungen, wobei die Dienstanforderungen an einer Gateway-Ebenen-Hardware-Warteschlangenverwaltung in einem Edge-Gateway von Client-Geräten empfangen werden, Mittel zum Planen der Dienstanforderungen in einer Warteschlange basierend auf den Dienstparametern und Mittel zum Senden einiger der Dienstanforderungen von der Warteschlange zu einer Rack-Ebenen-Hardware-Warteschlangenverwaltung eines physischen Racks in Schaltung mit dem Edge-Gateway, wobei die einigen der Dienstanforderungen Funktionen als Dienst entsprechen, die durch Ressourcen in dem physischen Rack bereitgestellt sind.
  • Bei Beispiel 42 kann der Gegenstand von Beispiel 41 optional Mittel zum Senden von Ergebnissen an die Client-Geräte beinhalten, wobei die Ergebnisse den Dienstanforderungen entsprechen und durch die Funktionen als Dienst erzeugt werden, die von dem physischen Rack bereitgestellt sind.
  • Bei Beispiel 43 kann der Gegenstand von einem der Beispiele 41 bis 42 optional beinhalten, dass die Mittel zum Senden der einigen der Dienstanforderungen für Folgendes vorgesehen sind: Empfangen einer Pull-Anforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung, wobei die Pull-Anforderung eine erste Kennung beinhaltet, und Bereitstellen einer der Dienstanforderungen für die Rack-Ebenen-Hardware-Warteschlangenverwaltung in Antwort auf die Pull-Anforderung, wenn die erste Kennung einer zweiten Kennung der einen der Dienstanforderungen entspricht, wobei die erste Kennung eine Diensttypkennung und/oder eine Dienstkennung ist.
  • Bei Beispiel 44 kann der Gegenstand von einem der Beispiele 41 bis 43 optional beinhalten, dass sich die Rack-Ebenen-Hardware-Warteschlangenverwaltung an einer Top-of-Rack-Switch des physischen Racks befindet.
  • Bei Beispiel 45 kann der Gegenstand von einem der Beispiele 41 bis 44 optional beinhalten, dass die Dienstparameter Fristen und/oder Umlauflatenzen beinhalten, innerhalb derer Ergebnisse entsprechender der Dienstanforderungen an entsprechenden der Client-Geräte zu empfangen sind, und kann optional Mittel zum Zuordnen von Prioritäten zu den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen beinhalten.
  • Bei Beispiel 46 kann der Gegenstand von einem der Beispiele 41 bis 45 optional beinhalten, dass die Mittel zum Planen der Dienstanforderungen in der Warteschlange die Dienstanforderungen basierend auf den zugeordneten Prioritäten der Dienstanforderungen planen.
  • Bei Beispiel 47 kann der Gegenstand von einem der Beispiele 41 bis 46 optional beinhalten, dass die Mittel zum Senden der einigen der Dienstanforderungen von der Warteschlange zur Rack-Ebenen-Hardware-Warteschlangenverwaltung die einigen der Dienstanforderungen basierend auf den zugeordneten Prioritäten senden, indem zuerst Dienstanforderungen mit höherer Priorität gesendet werden, bevor Dienstanforderungen mit niedrigerer Priorität gesendet werden.
  • Bei Beispiel 48 kann der Erfindungsgegenstand von einem der Beispiele 41 bis 47 optional Mittel zum Programmieren der Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks mit einer der Kennungen, die den Funktionen als Dienst entsprechen, die von dem physischen Rack bereitgestellt sind, und/oder Richtlinienregeln zum Priorisieren einiger der Dienstanforderungen in dem physischen Rack beinhalten.
  • Beispiel 48 ist ein nichtflüchtiges computerlesbares Speichermedium, das Anweisungen umfasst, die bei Ausführung mindestens einen Prozessor zu mindestens Folgendem veranlassen: Parsen von Dienstanforderungen basierend auf Dienstparametern in den Dienstanforderungen, wobei die Dienstanforderungen an einer Gateway-Ebenen-Hardware-Warteschlangenverwaltung in einem Edge-Gateway von Client-Geräten empfangen werden, Planen der Dienstanforderungen in einer Warteschlange basierend auf den Dienstparametern und Senden einiger der Dienstanforderungen von der Warteschlange an eine Rack-Ebenen-Hardware-Warteschlangenverwaltung eines physischen Racks in Schaltung mit dem Edge-Gateway, wobei die einigen der Dienstanforderungen Funktionen als Dienst entsprechen, die von Ressourcen in dem physischen Rack bereitgestellt sind.
  • Bei Beispiel 49 kann der Gegenstand von Beispiel 48 optional beinhalten, das die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, Ergebnisse an die Client-Geräte zu senden, wobei die Ergebnisse den Dienstanforderungen entsprechen und durch die Funktionen als Dienst erzeugt werden, die von dem physischen Rack bereitgestellt sind.
  • Bei Beispiel 50 kann der Gegenstand von einem der Beispiele 48 bis 49 optional beinhalten, dass die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu Folgendem zu veranlassen: Empfangen einer Pull-Anforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung, wobei die Pull-Anforderung eine erste Kennung beinhaltet, und Bereitstellen einer der Dienstanforderungen für die Rack-Ebenen-Hardware-Warteschlangenverwaltung in Antwort auf die Pull-Anforderung, wenn die erste Kennung einer zweiten Kennung der einen der Dienstanforderungen entspricht, wobei die erste Kennung eine Diensttypkennung und/oder eine Dienstkennung ist.
  • Bei Beispiel 51 kann der Gegenstand von einem der Beispiele 48 bis 50 optional beinhalten, dass sich die Rack-Ebenen-Hardware-Warteschlangenverwaltung an einer Top-of-Rack-Switch des physischen Racks befindet.
  • Bei Beispiel 52 kann der Gegenstand von einem der Beispiele 48 bis 51 optional beinhalten, dass die Dienstparameter Fristen und/oder Umlauflatenzen beinhalten, innerhalb derer Ergebnisse entsprechender der Dienstanforderungen an entsprechenden der Client-Geräte zu empfangen sind, und kann optional beinhalten, dass die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, den Dienstanforderungen basierend auf den Fristen und/oder den Umlauflatenzen Prioritäten zuzuordnen.
  • Bei Beispiel 54 kann der Gegenstand von einem der Beispiele 48 bis 52 optional beinhalten, dass die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, die Dienstanforderungen basierend auf den zugeordneten Prioritäten der Dienstanforderungen in der Warteschlange zu planen.
  • Bei Beispiel 55 kann der Gegenstand von einem der Beispiele 48 bis 54 optional beinhalten, dass die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, die einigen der Dienstanforderungen aus der Warteschlange basierend auf den zugeordneten Prioritäten an die Rack-Ebenen-Hardware-Warteschlangenverwaltung zu senden, indem zuerst Dienstanforderungen mit höherer Priorität gesendet werden, bevor Dienstanforderungen mit niedrigerer Priorität gesendet werden.
  • Bei Beispiel 56 kann der Gegenstand von einem der Beispiele 48 bis 55 optional beinhalten, dass die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, die Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks mit Kennungen, die den Funktionen als Dienst entsprechen, die von dem physischen Rack bereitgestellt werden, und/oder Richtlinienregeln zum Priorisieren einiger der Dienstanforderungen in dem physischen Rack zu programmieren.
  • Beispiel 57 ist ein Verfahren zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe einer Hardware-Warteschlangenverwaltung. Das Verfahren von Beispiel 57 beinhaltet Folgendes: Parsen der Dienstanforderungen basierend auf Dienstparametern in den Dienstanforderungen, wobei die Dienstanforderungen an einer Gateway-Ebenen-Hardware-Warteschlangenverwaltung in einem Edge-Gateway von Client-Geräten empfangen werden, Planen der Dienstanforderungen basierend auf den Dienstparametern in einer Warteschlange und Senden einiger der Dienstanforderungen von der Warteschlange an eine Rack-Ebenen-Hardware-Warteschlangenverwaltung eines physischen Racks in Schaltung mit dem Edge-Gateway, wobei die einigen der Dienstanforderungen Funktionen als Dienst entsprechen, die von Ressourcen in dem physischen Rack bereitgestellt werden.
  • Bei Beispiel 58 kann der Gegenstand von Beispiel 57 optional das Senden von Ergebnissen an die Client-Geräte beinhalten, wobei die Ergebnisse den Dienstanforderungen entsprechen und durch die Funktionen als Dienst erzeugt werden, die von dem physischen Rack bereitgestellt werden.
  • Bei Beispiel 59 kann der Gegenstand von einem der Beispiele 57 bis 58 optional Folgendes beinhalten: Empfangen einer Pull-Anforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung, wobei die Pull-Anforderung eine erste Kennung beinhaltet, und Bereitstellen einer der Dienstanforderungen für die Rack-Ebenen-Hardware-Warteschlangenverwaltung in Antwort auf die Pull-Anforderung, wenn die erste Kennung einer zweiten Kennung der einen der Dienstanforderungen entspricht, wobei die erste Kennung eine Diensttypkennung und/oder eine Dienstkennung ist.
  • Bei Beispiel 60 kann der Gegenstand von einem der Beispiele 57 bis 59 optional beinhalten, dass sich die Rack-Ebenen-Hardware-Warteschlangenverwaltung an einer Top-of-Rack-Switch des physischen Racks befindet.
  • Bei Beispiel 61 kann der Gegenstand von einem der Beispiele 57 bis 60 optional beinhalten, dass die Dienstparameter Fristen und/oder Umlauflatenzen beinhalten, innerhalb derer Ergebnisse entsprechender der Dienstanforderungen an entsprechenden der Client-Geräte zu empfangen sind, und kann optional das Zuordnen von Prioritäten zu den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen beinhalten.
  • Bei Beispiel 62 kann der Gegenstand von einem der Beispiele 57 bis 61 optional beinhalten, dass das Planen der Dienstanforderungen in der Warteschlange basierend auf den zugeordneten Prioritäten der Dienstanforderungen erfolgt.
  • Bei Beispiel 63 kann der Gegenstand von einem der Beispiele 57 bis 62 optional beinhalten, dass das Senden der einigen der Dienstanforderungen aus der Warteschlange an die Rack-Ebenen-Hardware-Warteschlangenverwaltung basierend auf den zugeordneten Prioritäten erfolgt, indem zuerst Dienstanforderungen mit höherer Priorität gesendet werden, bevor Dienstanforderungen mit niedrigerer Priorität gesendet werden.
  • Bei Beispiel 64 kann der Gegenstand von einem der Beispiele 57 bis 63 optional das Programmieren der Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks mit Kennungen, die den Funktionen als Dienst entsprechen, die von dem physischen Rack bereitgestellt werden, und/oder Richtlinienregeln zum Priorisieren einiger der Dienstanforderungen in dem physischen Rack beinhalten.
  • Obwohl im Vorliegenden bestimmte beispielhafte Verfahren, Vorrichtungen und Herstellungsgegenstände offenbart wurden, ist der Schutzumfang dieser Patentschrift nicht darauf beschränkt. Im Gegenteil umfasst diese Patentschrift alle Verfahren, Vorrichtungen und Herstellungsgegenstände, die billigerweise in den Geltungsbereich der Ansprüche der vorliegenden Patentschrift fallen.

Claims (64)

  1. System zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe von Hardware-Warteschlangenverwaltungen, wobei das System Folgendes umfasst: eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung in einem Edge-Gateway zum Planen der Dienstanforderungen, die von Client-Geräten empfangen werden, in einer Warteschlange, eine Rack-Ebenen-Hardware-Warteschlangenverwaltung in einem physischen Rack in Verbindung mit dem Edge-Gateway, wobei die Rack-Ebenen-Hardware-Warteschlangenverwaltung für das Senden einer Pull-Anforderung für eine erste der Dienstanforderungen an die Gateway-Ebenen-Hardware-Warteschlangenverwaltung vorgesehen ist, und eine Einschub-Ebenen-Hardware-Warteschlangenverwaltung in einem Einschub des physischen Racks, wobei die Einschub-Ebenen-Hardware-Warteschlangenverwaltung für das Senden einer zweiten Pull-Anforderung für die erste der Dienstanforderungen an die Rack-Ebenen-Hardware-Warteschlangenverwaltung vorgesehen ist, wobei der Einschub eine Ressource zum Bereitstellen einer Funktion als Dienst beinhaltet, die in der ersten der Dienstanforderungen spezifiziert ist.
  2. System nach Anspruch 1, ferner eine Hardware-Warteschlangenverwaltung-Kommunikationsschnittstelle in der Gateway-Ebenen-Hardware-Warteschlangenverwaltung beinhaltend, wobei die Hardware-Warteschlangenverwaltung-Kommunikationsschnittstelle für Folgendes vorgesehen ist: Senden einer Nachricht zu anhängigen Dienstanforderungen von dem Edge-Gateway an ein Peer-Edge-Gateway, wobei die Nachricht zu anhängigen Dienstanforderungen eine Menge der Dienstanforderungen angibt, die in der Warteschlange geplant sind, und Senden einer zweiten der Dienstanforderungen an das Peer-Edge-Gateway in Antwort auf eine Pull-Anforderung von dem Peer-Edge-Gateway, wobei die Pull-Anforderung von dem Peer-Edge-Gateway in Antwort auf die Nachricht zu anhängigen Dienstanforderungen erfolgt.
  3. System nach Anspruch 1, wobei die Dienstanforderungen Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen beinhalten, und ferner eine Priorisierungseinrichtung in der Gateway-Ebenen-Hardware-Warteschlangenverwaltung beinhaltend, um den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen Prioritäten zuzuordnen.
  4. System nach Anspruch 1, ferner eine Anforderung-Client-Abbildung in der Gateway-Ebenen-Hardware-Warteschlangenverwaltung beinhaltend, um anhängige der Dienstanforderungen mit Kennungen entsprechender der Client-Geräte abzubilden.
  5. System nach Anspruch 4, ferner eine Client-Kommunikationsschnittstelle in der Gateway-Ebenen-Hardware-Warteschlangenverwaltung beinhaltend, um basierend auf der Anforderung-Client-Abbildung ein Ergebnis, das durch die Funktion als Dienst erzeugt wird, die in der ersten der Dienstanforderungen spezifiziert ist, an ein entsprechendes der Client-Geräte zu senden.
  6. System nach Anspruch 1, ferner Folgendes beinhaltend: eine erste Dienstetabelle in der Rack-Ebenen-Hardware-Warteschlangenverwaltung, eine zweite Dienstetabelle in der Einschub-Ebenen-Hardware-Warteschlangenverwaltung und eine Systemverwaltung in der Gateway-Ebenen-Hardware-Warteschlangenverwaltung, wobei die Systemverwaltung dafür vorgesehen ist, eine Diensttypkennung und/oder eine Dienstkennung in der ersten und der zweiten Dienstetabelle zu speichern, welche die Funktion als Dienst angeben, die durch die Ressource des Einschubs bereitgestellt ist.
  7. System nach Anspruch 1, ferner eine Ressourcen-Kommunikationsschnittstelle in der Einschub-Ebenen-Hardware-Warteschlangenverwaltung beinhaltend, um von der Ressource eine dritte Pull-Anforderung zum Abrufen der ersten der Dienstanforderungen zu empfangen.
  8. System nach Anspruch 1, ferner eine Dienstregeltabelle in der Einschub-Ebenen-Hardware-Warteschlangenverwaltung beinhaltend, um eine erste Richtlinienregel zu speichern, die einen Typ einer Funktion als Dienst angibt, für die eine Dienstanforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung zu ziehen ist, und eine zweite Richtlinienregel, die eine Priorität zum Verarbeiten der ersten der Dienstanforderungen angibt.
  9. System zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe von Hardware-Warteschlangenverwaltungen, wobei das System Folgendes umfasst: Mittel zum Planen der Dienstanforderungen, die von Client-Geräten empfangen werden, in einer Warteschlange eines Edge-Gateways, Mittel zum Senden einer Pull-Anforderung von einem physischen Rack an eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung für eine erste der Dienstanforderungen und Mittel zum Senden einer zweiten Pull-Anforderung von einem Einschub des physischen Racks an eine Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks für die erste der Dienstanforderungen, wobei der Einschub eine Ressource zum Bereitstellen einer Funktion als Dienst beinhaltet, die in der ersten der Dienstanforderungen spezifiziert ist.
  10. System nach Anspruch 9, ferner Folgendes beinhaltend: Mittel zum Senden einer Nachricht zu anhängigen Dienstanforderungen von dem Edge-Gateway an ein Peer-Edge-Gateway, wobei die Nachricht zu anhängigen Dienstanforderungen eine Menge der Dienstanforderungen angibt, die in der Warteschlange geplant sind, und die Mittel zum Senden der Nachricht zu anhängigen Dienstanforderungen dafür vorgesehen sind, in Antwort auf eine Pull-Anforderung von dem Peer-Edge-Gateway eine zweite der Dienstanforderungen an das Peer-Edge-Gateway zu senden, wobei die Pull-Anforderung von dem Peer-Edge-Gateway in Antwort auf die Nachricht zu anhängigen Dienstanforderungen erfolgt.
  11. System nach Anspruch 9, wobei die Dienstanforderungen Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen beinhalten und ferner Mittel zum Zuordnen von Prioritäten zu den Dienstanforderungen basierend auf den Fristen und/oder den Umlauflatenzen und/oder den Diensttypkennungen und/oder den Dienstkennungen beinhalten.
  12. System nach Anspruch 9, ferner Mittel zum Abbilden anhängiger der Dienstanforderungen mit Kennungen entsprechender der Client-Geräte beinhaltend.
  13. System nach Anspruch 12, ferner Mittel zum Senden eines Ergebnisses, das durch die Funktion als Dienst erzeugt wird, die in der ersten der Dienstanforderungen spezifiziert ist, an ein entsprechendes der Client-Geräte basierend auf der Abbildung der anhängigen der Dienstanforderungen mit den Kennungen entsprechender der Client-Geräte beinhaltend.
  14. System nach Anspruch 9, ferner Mittel zum Speichern einer Diensttypkennung und/oder einer Dienstkennung in einer ersten Dienstetabelle in der Rack-Ebenen-Hardware-Warteschlangenverwaltung und in einer zweiten Dienstetabelle in dem Einschub beinhaltend, wobei die Diensttypkennung und/oder die Dienstkennung die Funktion als Dienst angeben, die von der Ressource des Einschubs bereitgestellt ist.
  15. System nach Anspruch 9, ferner Mittel zum Empfangen einer dritten Pull-Anforderung von der Ressource beinhaltend, um die erste der Dienstanforderungen abzurufen.
  16. System nach Anspruch 9, ferner Mittel zum Speichern einer ersten Richtlinienregel, die einen Typ einer Funktion als Dienst angibt, für den eine Dienstanforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung zu ziehen ist, und einer zweiten Richtlinienregel, die eine Priorität zum Verarbeiten der ersten der Dienstanforderungen angibt, beinhaltend.
  17. Nichtflüchtiges computerlesbares Speichermedium, das Anweisungen umfasst, die bei Ausführung mindestens einen Prozessor zu mindestens Folgendem veranlassen: Planen von Dienstanforderungen, die von Client-Geräten empfangen werden, in einer Warteschlange eines Edge-Gateways, Senden einer Pull-Anforderung für eine erste der Dienstanforderungen von einem physischen Rack an eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung und Senden einer zweiten Pull-Anforderung für die erste der Dienstanforderungen von einem Einschub des physischen Racks an eine Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks, wobei der Einschub eine Ressource beinhaltet, um eine Funktion als Dienst bereitzustellen, die in der ersten der Dienstanforderungen spezifiziert ist.
  18. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 17, wobei die Anweisungen den mindestens einen Prozessor ferner zu Folgendem veranlassen: Senden einer Nachricht zu anhängigen Dienstanforderungen von dem Edge-Gateway an ein Peer-Edge-Gateway, wobei die Nachricht zu anhängigen Dienstanforderungen eine Menge der Dienstanforderungen angibt, die in der Warteschlange geplant sind, und Senden einer zweiten der Dienstanforderungen an das Peer-Edge-Gateway in Antwort auf eine Pull-Anforderung von dem Peer-Edge-Gateway, wobei die Pull-Anforderung von dem Peer-Edge-Gateway in Antwort auf die Nachricht zu anhängigen Dienstanforderungen erfolgt.
  19. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 17, wobei die Dienstanforderungen Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen beinhalten und die Anweisungen ferner den mindestens einen Prozessor veranlassen, den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen Prioritäten zuzuordnen.
  20. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 17, wobei die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, anhängige der Dienstanforderungen mit Kennungen entsprechender der Client-Geräte in einer Anforderung-Client-Abbildung der Gateway-Ebenen-Hardware-Warteschlangenverwaltung abzubilden.
  21. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 20, wobei die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, basierend auf der Anforderung-Client-Abbildung ein Ergebnis, das durch die Funktion als Dienst erzeugt wird, die in der ersten der Dienstanforderungen spezifiziert sind, an ein entsprechendes der Client-Geräte zu senden.
  22. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 17, wobei die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, eine Diensttypkennung und/oder eine Dienstkennung in einer ersten Dienstetabelle in der Rack-Ebenen-Hardware-Warteschlangenverwaltung und in einer zweiten Dienstetabelle in dem Einschub zu speichern, wobei die Diensttypkennung und/oder die Dienstkennung die Funktion als Dienst angeben, die von der Ressource des Einschubs bereitgestellt ist.
  23. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 17, wobei die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, eine dritte Pull-Anforderung von der Ressource zu empfangen, um die erste der Dienstanforderungen abzurufen.
  24. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 17, wobei die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, in einer Dienstregeltabelle eine erste Richtlinienregel zu speichern, wobei die erste Richtlinienregel einen Typ einer Funktion als Dienst angibt, für die eine Dienstanforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung zu ziehen ist, und eine zweite Richtlinienregel, die eine Priorität zum Verarbeiten der ersten der Dienstanforderungen angibt.
  25. Verfahren zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe von Hardware-Warteschlangenverwaltungen, wobei das Verfahren Folgendes umfasst: Planen der Dienstanforderungen, die von Client-Geräten empfangen werden, in einer Warteschlange eines Edge-Gateways, Senden einer Pull-Anforderung für eine erste der Dienstanforderungen von einem physischen Rack an eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung und Senden einer zweiten Pull-Anforderung für die erste der Dienstanforderungen von einem Einschub des physischen Racks an eine Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks, wobei der Einschub eine Ressource zum Bereitstellen einer Funktion als Dienst bereitstellt, die in der ersten der Dienstanforderungen spezifiziert ist.
  26. Verfahren nach Anspruch 25, ferner Folgendes beinhaltend: Senden einer Nachricht zu anhängigen Dienstanforderungen von dem Edge-Gateway an ein Peer-Edge-Gateway, wobei die Nachricht zu anhängigen Dienstanforderungen eine Menge der Dienstanforderungen angibt, die in der Warteschlange geplant sind, und Senden einer zweiten der Dienstanforderungen an das Peer-Edge-Gateway in Antwort auf eine Pull-Anforderung von dem Peer-Edge-Gateway, wobei die Pull-Anforderung von dem Peer-Edge-Gateway in Antwort auf die Nachricht zu anhängigen Dienstanforderungen erfolgt.
  27. Verfahren nach Anspruch 25, wobei die Dienstanforderungen Fristen und/oder Umlauflatenzen und/oder Diensttypkennungen und/oder Dienstkennungen beinhalten, und ferner das Zuordnen von Prioritäten zu den Dienstanforderungen basierend auf den Fristen und/oder den Umlauflatenzen und/oder den Diensttypkennungen und/oder den Dienstkennungen beinhaltend.
  28. Verfahren nach Anspruch 25, ferner das Abbilden anhängiger der Dienstanforderungen mit Kennungen entsprechender der Client-Geräte beinhaltend.
  29. Verfahren nach Anspruch 28, ferner das Senden eines Ergebnisses, das durch die Funktion als Dienst erzeugt wird, die in der ersten der Dienstanforderungen spezifiziert ist, an ein entsprechendes der Client-Geräte basierend auf der Abbildung der anhängigen der Dienstanforderungen mit den Kennungen entsprechender der Client-Geräte beinhaltend.
  30. Verfahren nach Anspruch 25, ferner das Speichern einer Diensttypkennung und/oder einer Dienstkennung in einer ersten Dienstetabelle in der Rack-Ebenen-Hardware-Warteschlangenverwaltung und in einer zweiten Dienstetabelle in dem Einschub beinhaltend, wobei die Diensttypkennung und/oder Dienstkennung die Funktion als Dienst angeben, die von der Ressource des Einschubs bereitgestellt wird.
  31. Verfahren nach Anspruch 25, ferner das Empfangen einer dritten Pull-Anforderung von der Ressource zum Abrufen der ersten der Dienstanforderungen beinhaltend.
  32. Verfahren nach Anspruch 25, ferner das Speichern einer ersten Richtlinienregel, die einen Typ einer Funktion als Dienst angibt, für den eine Dienstanforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung zu ziehen ist, und einer zweiten Richtlinienregel, die eine Priorität zum Verarbeiten der ersten der Dienstanforderungen angibt, beinhaltend.
  33. Vorrichtung zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe einer Hardware-Warteschlangenverwaltung, wobei die Vorrichtung Folgendes umfasst: eine Gateway-Ebenen-Hardware-Warteschlangenverwaltung in einem Edge-Gateway, wobei die Gateway-Ebenen-Hardware-Warteschlangenverwaltung für Folgendes vorgesehen ist: Parsen der Dienstanforderungen basierend auf Dienstparametern in den Dienstanforderungen und Planen der Dienstanforderungen in einer Warteschlange basierend auf den Dienstparametern, wobei die Dienstanforderungen von Client-Geräten empfangen werden, und eine Hardware-Warteschlangenverwaltung-Kommunikationsschnittstelle zum Senden einiger der Dienstanforderungen von der Warteschlange an die Rack-Ebenen-Hardware-Warteschlangenverwaltung eines physischen Racks in Schaltung mit dem Edge-Gateway, wobei die einigen der Dienstanforderungen Funktionen als Dienst entsprechen, die durch Ressourcen in den physischen Racks bereitgestellt sind.
  34. Vorrichtung nach Anspruch 33, ferner eine Client-Kommunikationsschnittstelle zum Senden von Ergebnissen an die Client-Geräte entsprechend den Dienstanforderungen beinhaltend, wobei die Ergebnisse durch die Funktionen als Dienst erzeugt werden, die von dem physischen Rack bereitgestellt sind.
  35. Vorrichtung nach Anspruch 33, wobei die Hardware-Warteschlangenverwaltung-Kommunikationsschnittstelle ferner für Folgendes vorgesehen ist: Empfangen einer Pull-Anforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung, wobei die Pull-Anforderung eine erste Kennung beinhaltet, und Bereitstellen einer der Dienstanforderungen für die Rack-Ebenen-Hardware-Warteschlangenverwaltung in Antwort auf die Pull-Anforderung, wenn die erste Kennung einer zweiten Kennung der einen der Dienstanforderungen entspricht, wobei die erste Kennung eine Diensttypkennung und/oder eine Dienstkennung ist.
  36. Vorrichtung nach Anspruch 35, wobei sich die Rack-Ebenen-Hardware-Warteschlangenverwaltung an einer Top-of-Rack-Switch des physischen Racks befindet.
  37. Vorrichtung nach Anspruch 33, wobei die Dienstparameter Fristen und/oder Umlauflatenzen beinhalten, innerhalb derer Ergebnisse entsprechender der Dienstanforderungen an entsprechenden der Client-Geräte zu empfangen sind, und ferner eine Priorisierungseinrichtung beinhaltend, um den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen Prioritäten zuzuordnen.
  38. Vorrichtung nach Anspruch 37, wobei die Gateway-Ebenen-Hardware-Warteschlangenverwaltung dafür vorgesehen ist, die Dienstanforderungen in der Warteschlange basierend auf den zugeordneten Prioritäten der Dienstanforderungen zu planen.
  39. Vorrichtung nach Anspruch 38, wobei die Hardware-Warteschlangenverwaltung-Kommunikationsschnittstelle dafür vorgesehen ist, basierend auf den zugeordneten Prioritäten einige der Dienstanforderungen von der Warteschlange an die Rack-Ebenen-Hardware-Warteschlangenverwaltung zu senden, indem zuerst Dienstanforderungen mit höherer Priorität gesendet werden, bevor Dienstanforderungen mit niedrigerer Priorität gesendet werden.
  40. Vorrichtung nach Anspruch 33, ferner eine Systemverwaltung beinhaltend, um die Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks mit einer von Kennungen, die den Funktionen als Dienst entsprechen, die von dem physischen Rack bereitgestellt werden, und/oder Richtlinienregeln zum Priorisieren einiger der Dienstanforderungen in dem physischen Rack zu pro grammieren.
  41. Vorrichtung zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe einer Hardware-Warteschlangenverwaltung, wobei die Vorrichtung Folgendes umfasst: Mittel zum Parsen der Dienstanforderungen basierend auf Dienstparametern in den Dienstanforderungen, wobei die Dienstanforderungen an einer Gateway-Ebenen-Hardware-Warteschlangenverwaltung in einem Edge-Gateway von Client-Geräten empfangen werden, Mittel zum Planen der Dienstanforderungen in einer Warteschlange basierend auf den Dienstparametern und Mittel zum Senden einiger der Dienstanforderungen von der Warteschlange zu einer Rack-Ebenen-Hardware-Warteschlangenverwaltung eines physischen Racks in Schaltung mit dem Edge-Gateway, wobei die einigen der Dienstanforderungen Funktionen als Dienst entsprechen, die durch Ressourcen in dem physischen Rack bereitgestellt sind.
  42. Vorrichtung nach Anspruch 41, ferner Mittel zum Senden von Ergebnissen an die Client-Geräte beinhaltend, wobei die Ergebnisse den Dienstanforderungen entsprechen und durch die Funktionen als Dienst erzeugt werden, die von dem physischen Rack bereitgestellt sind.
  43. Vorrichtung nach Anspruch 41, wobei die Mittel zum Senden der einigen Dienstanforderungen für Folgendes vorgesehen sind: Empfangen einer Pull-Anforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung, wobei die Pull-Anforderung eine erste Kennung beinhaltet, und Bereitstellen einer der Dienstanforderungen für die Rack-Ebenen-Hardware-Warteschlangenverwaltung in Antwort auf die Pull-Anforderung, wenn die erste Kennung einer zweiten Kennung der einen der Dienstanforderungen entspricht, wobei die erste Kennung eine Diensttypkennung und/oder eine Dienstkennung ist.
  44. Vorrichtung nach Anspruch 43, wobei sich die Rack-Ebenen-Hardware-Warteschlangenverwaltung an einer Top-of-Rack-Switch des physischen Racks befindet.
  45. Vorrichtung nach Anspruch 41, wobei die Dienstparameter Fristen und/oder Umlauflatenzen beinhalten, innerhalb derer Ergebnisse entsprechender der Dienstanforderungen an entsprechenden der Client-Geräte zu empfangen sind, und ferner Mittel zum Zuordnen von Prioritäten zu den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen beinhaltend.
  46. Vorrichtung nach Anspruch 45, wobei die Mittel zum Planen der Dienstanforderungen in der Warteschlange die Dienstanforderungen basierend auf den zugeordneten Prioritäten der Dienstanforderungen planen.
  47. Vorrichtung nach Anspruch 46, wobei die Mittel zum Senden der einigen der Dienstanforderungen von der Warteschlange zur Rack-Ebenen-Hardware-Warteschlangenverwaltung die einigen der Dienstanforderungen basierend auf den zugeordneten Prioritäten senden, indem zuerst Dienstanforderungen mit höherer Priorität gesendet werden, bevor Dienstanforderungen mit niedrigerer Priorität gesendet werden.
  48. Vorrichtung nach Anspruch 41, ferner Mittel zum Programmieren der Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks mit einer der Kennungen, die den Funktionen als Dienst entsprechen, die von dem physischen Rack bereitgestellt sind, und/oder Richtlinienregeln zum Priorisieren einiger der Dienstanforderungen in dem physischen Rack beinhaltend.
  49. Nichtflüchtiges computerlesbares Speichermedium, das Anweisungen umfasst, die bei Ausführung mindestens einen Prozessor zu mindestens Folgendem veranlassen: Parsen von Dienstanforderungen basierend auf Dienstparametern in den Dienstanforderungen, wobei die Dienstanforderungen an einer Gateway-Ebenen-Hardware-Warteschlangenverwaltung in einem Edge-Gateway von Client-Geräten empfangen werden, Planen der Dienstanforderungen in einer Warteschlange basierend auf den Dienstparametern und Senden einiger der Dienstanforderungen von der Warteschlange an eine Rack-Ebenen-Hardware-Warteschlangenverwaltung eines physischen Racks in Schaltung mit dem Edge-Gateway, wobei die einigen der Dienstanforderungen Funktionen als Dienst entsprechen, die von Ressourcen in dem physischen Rack bereitgestellt werden.
  50. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 49, wobei die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, Ergebnisse an die Client-Geräte zu senden, wobei die Ergebnisse den Dienstanforderungen entsprechen und durch die Funktionen als Dienst erzeugt werden, die von dem physischen Rack bereitgestellt sind.
  51. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 49, wobei die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu Folgendem zu veranlassen: Empfangen einer Pull-Anforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung, wobei die Pull-Anforderung eine erste Kennung beinhaltet, und Bereitstellen einer der Dienstanforderungen für die Rack-Ebenen-Hardware-Warteschlangenverwaltung in Antwort auf die Pull-Anforderung, wenn die erste Kennung einer zweiten Kennung der einen der Dienstanforderungen entspricht, wobei die erste Kennung eine Diensttypkennung und/oder eine Dienstkennung ist.
  52. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 51, wobei sich die Rack-Ebenen-Hardware-Warteschlangenverwaltung an einer Top-of-Rack-Switch des physischen Racks befindet.
  53. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 49, wobei die Dienstparameter Fristen und/oder Umlauflatenzen beinhalten, innerhalb derer Ergebnisse entsprechender der Dienstanforderungen an entsprechenden der Client-Geräte zu empfangen sind, und die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen Prioritäten zuzuordnen.
  54. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 53, wobei die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, die Dienstanforderungen basierend auf den zugeordneten Prioritäten der Dienstanforderungen in der Warteschlange zu planen.
  55. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 54, wobei die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, die einigen der Dienstanforderungen aus der Warteschlange basierend auf den zugeordneten Prioritäten an die Rack-Ebenen-Hardware-Warteschlangenverwaltung zu senden, indem zuerst Dienstanforderungen mit höherer Priorität gesendet werden, bevor Dienstanforderungen mit niedrigerer Priorität gesendet werden.
  56. Nichtflüchtiges computerlesbares Speichermedium nach Anspruch 49, wobei die Anweisungen ferner dafür vorgesehen sind, den mindestens einen Prozessor zu veranlassen, die Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks mit Kennungen, die den Funktionen als Dienst entsprechen, die von dem physischen Rack bereitgestellt werden, und/oder Richtlinienregeln zum Priorisieren einiger der Dienstanforderungen in dem physischen Rack zu programmieren.
  57. Verfahren zum Planen von Dienstanforderungen in einem Netzwerk-Rechensystem mit Hilfe einer Hardware-Warteschlangenverwaltung, wobei das Verfahren Folgendes umfasst: Parsen der Dienstanforderungen basierend auf Dienstparametern in den Dienstanforderungen, wobei die Dienstanforderungen an einer Gateway-Ebenen-Hardware-Warteschlangenverwaltung an einem Edge-Gateway von Client-Geräten empfangen werden, Planen der Dienstanforderungen basierend auf den Dienstparametern in einer Warteschlange und Senden einiger der Dienstanforderungen von der Warteschlange an eine Rack-Ebenen-Hardware-Warteschlangenverwaltung eines physischen Racks in Schaltung mit dem Edge-Gateway, wobei die einigen der Dienstanforderungen Funktionen als Dienst entsprechen, die von Ressourcen in dem physischen Rack bereitgestellt werden.
  58. Verfahren nach Anspruch 57, ferner das Senden von Ergebnissen an die Client-Geräte beinhaltend, wobei die Ergebnisse den Dienstanforderungen entsprechen und durch die Funktionen als Dienst erzeugt werden, die von dem physischen Rack bereitgestellt werden.
  59. Verfahren nach Anspruch 57, ferner Folgendes beinhaltend: Empfangen einer Pull-Anforderung von der Rack-Ebenen-Hardware-Warteschlangenverwaltung, wobei die Pull-Anforderung eine erste Kennung beinhaltet, und Bereitstellen einer der Dienstanforderungen für die Rack-Ebenen-Hardware-Warteschlangenverwaltung in Antwort auf die Pull-Anforderung, wenn die erste Kennung einer zweiten Kennung der einen der Dienstanforderungen entspricht, wobei die erste Kennung eine Diensttypkennung und/oder eine Dienstkennung ist.
  60. Verfahren nach Anspruch 59, wobei sich die Rack-Ebenen-Hardware-Warteschlangenverwaltung an einer Top-of-Rack-Switch des physischen Racks befindet.
  61. Verfahren nach Anspruch 57, wobei die Dienstparameter Fristen und/oder Umlauflatenzen beinhalten, innerhalb derer Ergebnisse entsprechender der Dienstanforderungen an entsprechenden der Client-Geräte zu empfangen sind, und ferner das Zuordnen von Prioritäten zu den Dienstanforderungen basierend auf den Fristen und/oder Umlauflatenzen beinhaltend.
  62. Verfahren nach Anspruch 61, wobei das Planen der Dienstanforderungen in der Warteschlange basierend auf den zugeordneten Prioritäten der Dienstanforderungen erfolgt.
  63. Verfahren nach Anspruch 62, wobei das Senden der einigen der Dienstanforderungen aus der Warteschlange an die Rack-Ebenen-Hardware-Warteschlangenverwaltung basierend auf den zugeordneten Prioritäten erfolgt, indem zuerst Dienstanforderungen mit höherer Priorität gesendet werden, bevor Dienstanforderungen mit niedrigerer Priorität gesendet werden.
  64. Verfahren nach Anspruch 57, ferner das Programmieren der Rack-Ebenen-Hardware-Warteschlangenverwaltung des physischen Racks mit Kennungen, die den Funktionen als Dienst entsprechen, die von dem physischen Rack bereitgestellt werden, und/oder Richtlinienregeln zum Priorisieren einiger der Dienstanforderungen in dem physischen Rack beinhaltend.
DE112018007409.9T 2018-03-30 2018-03-30 Verfahren und vorrichtung zum planen von dienstanforderungen in einem netzwerk-rechensystem mit hilfe von hardware-warteschlangenverwaltungen Pending DE112018007409T5 (de)

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2018/025327 WO2019190545A1 (en) 2018-03-30 2018-03-30 Methods and apparatus to schedule service requests in a network computing system using hardware queue managers

Publications (1)

Publication Number Publication Date
DE112018007409T5 true DE112018007409T5 (de) 2021-01-07

Family

ID=62090044

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112018007409.9T Pending DE112018007409T5 (de) 2018-03-30 2018-03-30 Verfahren und vorrichtung zum planen von dienstanforderungen in einem netzwerk-rechensystem mit hilfe von hardware-warteschlangenverwaltungen

Country Status (3)

Country Link
US (2) US11533268B2 (de)
DE (1) DE112018007409T5 (de)
WO (1) WO2019190545A1 (de)

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE112018007409T5 (de) 2018-03-30 2021-01-07 Intel Corporation Verfahren und vorrichtung zum planen von dienstanforderungen in einem netzwerk-rechensystem mit hilfe von hardware-warteschlangenverwaltungen
US11533222B2 (en) * 2019-01-16 2022-12-20 Vmware, Inc. Auto-enrollment of IoT endpoints
US11575607B2 (en) * 2019-09-11 2023-02-07 Intel Corporation Dynamic load balancing for multi-core computing environments
CN111399994B (zh) * 2019-11-27 2023-10-10 杭州海康威视系统技术有限公司 请求调度方法、装置、电子设备及存储介质
US11316757B1 (en) * 2020-06-23 2022-04-26 Amdocs Development Limited System, method, and computer program for consumer requirement based management for physical edge deployment of an application
US11948010B2 (en) * 2020-10-12 2024-04-02 International Business Machines Corporation Tag-driven scheduling of computing resources for function execution
WO2022182373A1 (en) * 2021-02-27 2022-09-01 Jpmorgan Chase Bank, N.A. Method and system for handling service requests
CN113542371B (zh) * 2021-06-29 2022-05-17 西南大学 基于边缘网关的资源调度方法及系统
CN113472638B (zh) * 2021-07-05 2023-06-09 腾讯科技（深圳）有限公司 边缘网关控制方法及系统、装置、电子设备、存储介质
US20230275838A1 (en) * 2022-02-28 2023-08-31 Dell Products L.P. Edge node workload acquisition for distribution of edge workloads
CN115174296B (zh) * 2022-05-30 2024-03-22 青岛海尔科技有限公司 设备功能接入方法、装置、存储介质及电子装置

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030033463A1 (en) * 2001-08-10 2003-02-13 Garnett Paul J. Computer system storage
US8914513B2 (en) * 2011-06-23 2014-12-16 Cisco Technology, Inc. Hierarchical defragmentation of resources in data centers
EP2843548B1 (de) * 2013-09-03 2018-04-04 Fujitsu Limited Verfahren, System, und Programm zur Planung von Aufträgen in einem Rechnersystem
EP3206339B1 (de) 2014-10-31 2018-12-12 Huawei Technologies Co., Ltd. Konfigurationsverfahren für eine netzwerkkarte und ressourcenverwaltungszentrum
US20170075572A1 (en) 2015-09-11 2017-03-16 Sandisk Technologies Inc. Extending hardware queues with software queues
US9929901B2 (en) * 2015-11-10 2018-03-27 Dell Products, Lp System and method for providing proxied virtual wireless end points in a server rack of a data center
US10216668B2 (en) 2016-03-31 2019-02-26 Intel Corporation Technologies for a distributed hardware queue manager
US20170289242A1 (en) 2016-03-31 2017-10-05 David Keppel Technologies for dynamic work queue management
US10701160B2 (en) * 2016-07-28 2020-06-30 Polybit Inc. System and method for a unified interface to networked webservices
BR112016024645A2 (pt) 2016-08-11 2018-05-15 Ericsson Telecomunicacoes Sa ?método para gerenciar uma tarefa de processamento de dados requerida por um cliente, nó de gerenciamento de nuvem, programa de computador, e, carreador?
CN110297699B (zh) * 2018-03-23 2021-09-14 华为技术有限公司 调度方法、调度器、存储介质及系统
DE112018007409T5 (de) 2018-03-30 2021-01-07 Intel Corporation Verfahren und vorrichtung zum planen von dienstanforderungen in einem netzwerk-rechensystem mit hilfe von hardware-warteschlangenverwaltungen

Also Published As

Publication number Publication date
US20230142539A1 (en) 2023-05-11
US11533268B2 (en) 2022-12-20
WO2019190545A1 (en) 2019-10-03
US20200389410A1 (en) 2020-12-10

Similar Documents

Publication Publication Date Title
DE112018007409T5 (de) Verfahren und vorrichtung zum planen von dienstanforderungen in einem netzwerk-rechensystem mit hilfe von hardware-warteschlangenverwaltungen
DE102015105884B4 (de) Rechenknoten und Verfahren zur Migration einer virtuellen Maschine, Rechenzentrummanager zur Migration virtueller Maschinen, Maschinenlesbares Speichermedium und Rechenvorrichtungen
US9621648B2 (en) Peer-to-peer architecture for web traffic management
DE112014000358B4 (de) Regionales Firewall-Clustering in einer vernetzten Datenverarbeitungsumgebung
DE112013000395B4 (de) Vorrichtung, verfahren und computerlesbarer speicher zur richtliniendurchsetzung in rechenumgebung
DE112016005477T5 (de) System zum parallelen puffern und vorverarbeiten von datenströmen auf grundlage eines kontextes auf mehreren ebenen in fahrzeugdomänen
DE112017001762T5 (de) Technologien für den einsatz dynamischer underlay-netzwerke in cloud-computing-infrastrukturen
DE112018003482T5 (de) Serveranfrageverwaltung
DE202015009298U1 (de) Dynamische Anpassung von Shard-Zuweisungen
US8904395B2 (en) Scheduling events in a virtualized computing environment based on a cost of updating scheduling times or mapping resources to the event
DE112010005473T5 (de) Opportunistisches multitasking
DE112013003180T5 (de) Verfahren, System und Gerät zum Verwalten von Server-Hardware-Resourcen in einer Cloud-Scheduling-Umgebung
DE102012220514A1 (de) Steuern der nutzung von datenverarbeitungsressourcen ineiner service-datenbank
DE102020110143A1 (de) Standortbasierte virtualisierungs-workload-platzierung
DE112017003294T5 (de) Technologien für ein skalierbares Senden und Empfangen von Paketen
CN114374609B (zh) 基于rdma设备的深度学习作业运行方法及系统
CN115567251A (zh) 用于微服务集群的多业务隔离方法及系统
DE112016004319T5 (de) Technologien zur Schätzung der Netzwerkpaketumlaufzeit
DE202019005789U1 (de) Bereitstellung von Ereignisinhalten
DE112019000421T5 (de) Arbeitslastverwaltung mit datenzugriffserkennung in einem datenverarbeitungscluster
DE102019103932A1 (de) Technologien für optimierte Dienstgütebeschleunigung
DE102020114272A1 (de) Einsatz von virtuellen Node Clustern in einer mehrmittelbaren Umgebung
DE102021211927A1 (de) Verfahren, systeme, herstellungsartikel und vorrichtungen zum stapeln von funktionen
DE112021000410B4 (de) Cache-Netz-System mit mehreren Ebenen für serverlose Mehrfachnutzerumgebungen
DE102021122508A1 (de) Ausgleichen von grossrechner- und verteilten arbeitslasten auf der grundlage von leistung und kosten