DE102022212157A1 - Absichtsbasierte clusterverwaltung - Google Patents

Absichtsbasierte clusterverwaltung Download PDF

Info

Publication number
DE102022212157A1
DE102022212157A1 DE102022212157.0A DE102022212157A DE102022212157A1 DE 102022212157 A1 DE102022212157 A1 DE 102022212157A1 DE 102022212157 A DE102022212157 A DE 102022212157A DE 102022212157 A1 DE102022212157 A1 DE 102022212157A1
Authority
DE
Germany
Prior art keywords
unconditional
policies
slo
intent
infrastructure
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
DE102022212157.0A
Other languages
English (en)
Inventor
Adrian Hoban
Thijs Metsch
Francesc Guim Bernat
John J. Browne
Kshitij Arun Doshi
Mark Yarvis
Bin Li
Susanne M. Balle
Benjamin Walker
David Cremins
Mats Gustav Agerstam
Marcos E. Carranza
Mikko Ylinen
Dario N. Oliver
John Mangan
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 DE102022212157A1 publication Critical patent/DE102022212157A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • G06F21/577—Assessing vulnerabilities and evaluating computer system security
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/51—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems at application loading time, e.g. accepting, rejecting, starting or inhibiting executable software based on integrity or source reliability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3206—Monitoring of events, devices or parameters that trigger a change in power modality
    • G06F1/3228—Monitoring task completion, e.g. by use of idle timers, stop commands or wait commands
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F1/00—Details not covered by groups G06F3/00 - G06F13/00 and G06F21/00
    • G06F1/26—Power supply means, e.g. regulation thereof
    • G06F1/32—Means for saving power
    • G06F1/3203—Power management, i.e. event-based initiation of a power-saving mode
    • G06F1/3234—Power saving characterised by the action undertaken
    • G06F1/3296—Power saving characterised by the action undertaken by lowering the supply or operating voltage
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3433—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment for load management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3495—Performance evaluation by tracing or monitoring for systems
    • 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/30—Arrangements for executing machine instructions, e.g. instruction decode
    • G06F9/38—Concurrent instruction execution, e.g. pipeline or look ahead
    • G06F9/3867—Concurrent instruction execution, e.g. pipeline or look ahead using instruction pipelines
    • G06F9/3875—Pipelining a single stage, e.g. superpipelining
    • 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/445—Program loading or initiating
    • G06F9/44505—Configuring for program initiating, e.g. using registry, configuration files
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06N—COMPUTING ARRANGEMENTS BASED ON SPECIFIC COMPUTATIONAL MODELS
    • G06N20/00—Machine learning
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5009—Determining service level performance parameters or violations of service level contracts, e.g. violations of agreed response time or mean time between failures [MTBF]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5003—Managing SLA; Interaction between SLA and QoS
    • H04L41/5019—Ensuring fulfilment of SLA
    • H04L41/5025—Ensuring fulfilment of SLA by proactively reacting to service quality change, e.g. by reconfiguration after service quality degradation or upgrade
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/50—Network service management, e.g. ensuring proper service fulfilment according to agreements
    • H04L41/5041—Network service management, e.g. ensuring proper service fulfilment according to agreements characterised by the time relationship between creation and deployment of a service
    • H04L41/5054—Automatic deployment of services triggered by the service manager, e.g. service implementation by automatic configuration of network components
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0823—Errors, e.g. transmission errors
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/72—Admission control; Resource allocation using reservation actions during connection setup
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/821—Prioritising resource allocation or reservation requests
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/82—Miscellaneous aspects
    • H04L47/822—Collecting or measuring resource availability data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/70—Admission control; Resource allocation
    • H04L47/83—Admission control; Resource allocation based on usage prediction
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis
    • 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
    • H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
    • 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/14—Session management
    • H04L67/146—Markers for unambiguous identification of a particular session, e.g. session cookie or URL-encoding
    • 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/52—Network services specially adapted for the location of the user terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/875—Monitoring of systems including the internet
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2209/00—Indexing scheme relating to G06F9/00
    • G06F2209/50—Indexing scheme relating to G06F9/50
    • G06F2209/503—Resource availability
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
    • G06F2221/033—Test or assess software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F2221/2135—Metering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Business, Economics & Management (AREA)
  • Environmental & Geological Engineering (AREA)
  • Quality & Reliability (AREA)
  • Economics (AREA)
  • Mathematical Physics (AREA)
  • Data Mining & Analysis (AREA)
  • Marketing (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Vision & Pattern Recognition (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Development Economics (AREA)
  • Artificial Intelligence (AREA)
  • Operations Research (AREA)
  • Human Resources & Organizations (AREA)
  • Evolutionary Computation (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Strategic Management (AREA)
  • Tourism & Hospitality (AREA)
  • Medical Informatics (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Databases & Information Systems (AREA)
  • Multi Processors (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

Hierin sind verschiedene Systeme und Verfahren zum Implementieren einer absichtsbasierten Clusterverwaltung beschrieben. Ein Orchestratorsystem beinhaltet: einen Prozessor; und einen Speicher zum Speichern von Anweisungen, die bei Ausführung durch den Prozessor das Orchestratorsystem zu Folgendem veranlassen: Empfangen, am Orchestratorsystem, eines administrativen absichtsbasierten Service-Level-Ziels (SLO) für eine Infrastrukturkonfiguration einer Infrastruktur; Abbilden des administrativen absichtsbasierten SLO auf einen Satz unbedingter Richtlinien; Bereitstellen des Satzes unbedingter Richtlinien an die Infrastruktur; Überwachen der Leistungsfähigkeit der Infrastruktur; Detektieren einer Nichtkonformität mit dem Satz unbedingter Richtlinien; und Modifizieren des administrativen absichtsbasierten SLO, um einen revidierten Satz unbedingter Richtlinien zu erzeugen, die bewirken, dass die Leistungsfähigkeit der Infrastruktur mit dem revidierten Satz unbedingter Richtlinien konform ist.

Description

  • PRIORITÄTSANSPRUCH
  • Diese Anmeldung beansprucht die Priorität der vorläufigen US-Patentanmeldung Nr. 63/280.001 , eingereicht am 16 November 2021, die hiermit durch Bezugnahme in ihrer Gesamtheit aufgenommen wird.
  • TECHNISCHES GEBIET
  • Hierin beschriebene Ausführungsformen betreffen allgemein Netzwerküberwachung und abstimmung und insbesondere ein System und Verfahren zum Implementieren einer absichtsbasierten Clusterverwaltung.
  • HINTERGRUND
  • Edge-Computing bezieht sich auf einer allgemeinen Ebene auf den Übergang von Rechen- und Speicherungsressourcen näher an Endpunktvorrichtungen (z. B. Verbraucher-Datenverarbeitungsvorrichtungen, Benutzergerät usw.), um die Gesamtbetriebskosten zu optimieren, eine Anwendungslatenz zu reduzieren, Dienstfähigkeiten zu verbessern und die Einhaltung von Sicherheits- oder Datenschutzanforderungen zu verbessern. Edge-Computing kann in einigen Szenarien einen Cloud-ähnlichen verteilten Dienst bereitstellen, der eine Orchestrierung und Verwaltung für Anwendungen unter vielen Arten von Speicherungs- und Rechenressourcen bietet. Infolgedessen wurden manche Implementierungen von Edge-Computing als „Edge-Cloud“ (Rand-Cloud) oder „Fog“ (Nebel) bezeichnet, da leistungsstarke Rechenressourcen, die zuvor nur in großen entfernten Datenzentren verfügbar waren, näher an Endpunkte verlagert und zur Verwendung durch Verbraucher am „Rand“ des Netzwerks verfügbar gemacht werden.
  • Es wurden Anwendungsfälle von Edge-Computing in Mobilnetzumgebungen zur Integration mit Ansätzen des Edge-Computing mit Mehrfachzugriff (MEC) entwickelt, die auch als „Mobiles Edge-Computing“ bezeichnet werden. MEC-Ansätze sind dazu ausgelegt, Anwendungsentwicklern und Inhaltsanbietern zu ermöglichen, auf Rechenfähigkeiten und eine Informationstechnologie (IT)-Service-Umgebung in dynamischen Mobilnetzumgebungen am Rand des Netzes zuzugreifen. Von der Industriespezifikationsgruppe (ISG) des European Telecommunications Standards Institute (ETSI) wurden begrenzte Standards entwickelt, um gemeinsame Schnittstellen zum Betrieb von MEC-Systemen, Plattformen, Hosts, Diensten und Anwendungen zu definieren.
  • Edge-Computing, MEC und verwandte Technologien versuchen, eine reduzierte Latenz, eine erhöhte Ansprechempfindlichkeit und mehr verfügbare Rechenleistung bereitzustellen, als sie in herkömmlichen Cloud-Netzwerkdiensten und Weitverkehrsnetzverbindungen angeboten werden. Die Integration von Mobilität und dynamisch gestarteten Diensten in manche Fälle der Mobilitätsnutzung und der Vorrichtungsverarbeitung hat jedoch zu Einschränkungen und Bedenken hinsichtlich Orchestrierung, funktioneller Koordination und Ressourcenverwaltung geführt, insbesondere in komplexen Mobilitätseinstellungen, in denen viele Teilnehmer (Vorrichtungen, Hosts, Mandanten, Dienstanbieter, Betreiber) involviert sind.
    Auf ähnliche Weise sind Netzwerke und Vorrichtungen des Internets der Dinge (Internet of Things, IoT) dazu ausgelegt, eine verteilte Rechenanordnung von einer Vielfalt von Endpunkten zu bieten. IoT-Vorrichtungen sind physische oder virtualisierte Objekte, die in einem Netzwerk kommunizieren können und Sensoren, Aktuatoren und andere Eingabe/Ausgabe-Komponenten beinhalten können, die verwendet werden können, um Daten zu sammeln oder Aktionen in einer realen Umgebung durchzuführen. IoT-Vorrichtungen können zum Beispiel leistungsarme Endpunktvorrichtungen beinhalten, die eingebettet oder an Alltagsdingen angebracht sind, wie etwa Gebäuden, Fahrzeugen, Paketen usw., um ein zusätzliches Niveau künstlicher Sinneswahrnehmung dieser Dinge bereitzustellen. In jüngster Zeit wurden IoT-Vorrichtungen immer beliebter, und deshalb haben sich Anwendungen, die diese Vorrichtungen verwenden, stark vermehrt.
  • Durch den Einsatz verschiedener Edge-, Fog-, MEC- und IoT-Netzwerke, - Vorrichtungen und Dienste wurden mehrere fortgeschrittene Anwendungsfälle und Szenarien eingeführt, die am und hin zum Rand des Netzwerks auftreten. Diese fortgeschrittenen Anwendungsfälle haben jedoch unter vielen anderen Problemen auch mehrere entsprechende technische Herausforderungen bezüglich Orchestrierung, Sicherheit, Verarbeitung und Netzwerkressourcen, Dienstverfügbarkeit und effizienz, Sicherstellung der Dienstgüte mit sich gebracht, zumal mehr Typen von Rechensystemen und Konfigurationen eingesetzt werden.
  • Figurenliste
  • In den Zeichnungen, die nicht unbedingt maßstabsgetreu gezeichnet sind, können gleiche Ziffern ähnliche Komponenten in unterschiedlichen Ansichten beschreiben. Gleiche Ziffern mit unterschiedlichen Buchstabensuffixen können unterschiedliche Instanzen ähnlicher Komponenten repräsentieren. Manche Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der begleitenden Zeichnungen veranschaulicht, in denen:
  • In den Zeichnungen, die nicht unbedingt maßstabsgetreu gezeichnet sind, können gleiche Ziffern ähnliche Komponenten in unterschiedlichen Ansichten beschreiben. Gleiche Ziffern mit unterschiedlichen Buchstabensuffixen können unterschiedliche Instanzen ähnlicher Komponenten repräsentieren. Manche Ausführungsformen sind beispielhaft und nicht einschränkend in den Figuren der begleitenden Zeichnungen veranschaulicht; diese sind:
    • 1 veranschaulicht einen Überblick über eine Edge-Cloud-Konfiguration für Edge-Computing gemäß einer Ausführungsform;
    • 2 veranschaulicht Betriebsschichten zwischen Endpunkten, einer Edge-Cloud und Cloud-Rechenumgebungen gemäß einer Ausführungsform;
    • 3 veranschaulicht einen beispielhaften Ansatz für Vernetzung und Dienste in einem Edge-Computing-System gemäß einer Ausführungsform;
    • 4 veranschaulicht den Einsatz einer virtuellen Edge-Konfiguration in einem Edge-Computing-System, das zwischen mehreren Edge-Knoten und mehreren Mandanten betrieben wird, gemäß einer Ausführungsform;
    • 5 veranschaulicht verschiedene Rechenanordnungen, die Container in einem Edge-Computing-System einsetzen, gemäß einer Ausführungsform;
    • 6A stellt einen Überblick über Beispielkomponenten zur Berechnung, die an einem Rechenknoten in einem Edge-Computing-System eingesetzt werden, gemäß einer Ausführungsform bereit;
    • 6B stellt einen weiteren Überblick über Beispielkomponenten innerhalb einer Rechenvorrichtung in einem Edge-Computing-System gemäß einer Ausführungsform bereit;
    • 7 veranschaulicht eine beispielhafte Softwareverteilungsplattform zum Verteilen von Software, wie etwa den beispielhaften computerlesbaren Anweisungen von 6B, an eine oder mehrere Vorrichtungen gemäß einer Ausführungsform;
    • 8 ist ein Blockdiagramm, das ein serverloses Datenzentrum gemäß einer Ausführungsform veranschaulicht;
    • 9 ist ein Blockdiagramm, das eine Betriebsumgebung mit mehreren Hardwaresystemen veranschaulicht, und gemäß einer Ausführungsform;
    • 10 ist ein Blockdiagramm, das eine Orchestrierungssteuerebene gemäß einer Ausführungsform veranschaulicht;
    • 11 ist ein Blockdiagramm, das einen Daten- und Steuerfluss in einem Orchestrierungssystem veranschaulicht, gemäß einer Ausführungsform;
    • 12 ist ein Flussdiagramm, das ein Verfahren zum Implementieren einer absichtsbasierten Orchestrierung gemäß einer Ausführungsform veranschaulicht;
    • 13 ist ein Blockdiagramm, das eine Orchestrierungsarchitektur mit administrativen Erweiterungen gemäß einer Ausführungsform veranschaulicht;
    • 14 ist ein Blockdiagramm, das einen Daten- und Steuerfluss zum Implementieren administrativer Absichten gemäß einer Ausführungsform veranschaulicht;
    • 15 ist ein Flussdiagramm, das ein Verfahren zur absichtsbasierten Clusterverwaltung gemäß einer Ausführungsform veranschaulicht;
    • 16 ist ein Blockdiagramm, das einen Daten- und Steuerfluss zum Implementieren von Gebühren und Abrechnung in einer absichtsbasierten Orchestrierungsumgebung gemäß einer Ausführungsform veranschaulicht; und
    • 17 ist ein Flussdiagramm, das ein Verfahren zum Implementieren eines Schnellstartlebenszyklus gemäß einer Ausführungsform veranschaulicht.
  • AUSFÜHRLICHE BESCHREIBUNG
  • Hierin beschriebene Systeme und Verfahren stellen eine absichtsbasierte Clusterverwaltung bereit. Aktuelle Orchestrierungslösungen verwenden eine sehr zwingende Art und Weise, um eine Verwaltung der Dienstgüte (QoS) zu erreichen. Bei der QoS-Verwaltung geht es vor allem darum, die richtige Menge an Ressourcen (z. B. die Anzahl der virtuellen Zentraleinheiten (vCPUs)) oder Hardwarefunktionen zur Unterstützung der Arbeitslasten in der Cloud und am Edge anzufordern. Das Durchführen einer Orchestrierung auf diese Weise bringt mehrere Probleme mit sich. Es führt zu einer unerwünschten Anbieterbindung, da bestimmte von einem Verkäufer spezifizierte Funktionen in den Geräten eines anderen Anbieters möglicherweise nicht verfügbar sind. Ferner zeigt die Erfahrung, dass falsche Informationen in der QoS-Anforderung angegeben werden und daher zu einer suboptimalen Leistungsfähigkeit führen. Schließlich haben diese Deklarationen einen Kontext, der nicht in das QoS-Verwaltungsschema einbezogen ist. Beispielsweise kann der Plattformtyp, auf dem die Anwendung läuft (z. B. Xeon-Kern- im Vergleich zu Atom-Kern-Prozessoren), die Bereitstellungsentscheidungen beeinflussen, um eine bestimmte QoS-Anforderung zu erfüllen.
  • Außerdem wird es für die Kunden immer schwieriger, die richtigen Ressourcenzuweisungen für die Arbeitslasten selbst auszuwählen, da sich die Arbeitslasten von einem monolithischen Stil zu einem Mikrodienst-Stil bewegen. Dies kann dazu führen, dass die Kunden die Ressourcen überversorgen, was zu höheren Kosten führt.
  • Da Hardwareplattformen heterogener werden (z. B. Verwenden mehrerer XPUs anstelle einer einzigen CPU), kommt es darauf an, dass der Benutzer nicht mehr die Vielzahl kontextbezogener Details in einer Orchestrierungsanforderung definieren müssen sollte, sondern sich stattdessen darauf das Nötige konzentrieren kann, um eine bestimmte Reihe von Zielen für die betreffenden Dienste zu erreichen. Ein absichtsgesteuertes Modell stellt diese Abstraktion für den Benutzer bereit und führt zu einer guten Performanz für den Diensteigentümer sowie einer guten Investitionsrendite für den Ressourceneigentümer. Es muss also eine Möglichkeit gefunden werden, Absichten (definiert als Service-Level-Ziele) über einen Satz von Systemen und deren Ressourcen abzubilden, um die erforderlichen Niveaus der Dienstgüte zu erreichen.
  • Eine Dienstleistungsvereinbarung (SLA: Service Level Agreement) ist eine Vereinbarung zwischen einem Dienstanbieter und einem Kunden. SLAs sind Verträge zwischen Dritten, in denen Dienstziele oder andere Geschäftsziele festgelegt sind. SLAs können Sanktionen für Parteien vorsehen, die ein Ziel nicht erfüllen. Zum Beispiel kann eine teilweise Rückerstattung der Gebühren durchgesetzt werden, wenn ein Dienst innerhalb eines Zeitraums von 90 Tagen über mehr als einen prozentualen Schwellenwert nicht verfügbar ist.
  • Service-Level-Ziele (SLOs: Service Level Objectives) stellen präzise numerische Ziele für verschiedene Systemfähigkeiten bereit. Typische SLOs beziehen sich auf Verfügbarkeit oder Betriebszeit von Diensten, die Latenz von Diensten, die Bereitstellung einer Dienstbandbreite usw. SLOs werden häufig als Prozentsätze ausgedrückt, wie etwa ein Erfordernis von „99,9 % Betriebszeit über einen Zeitraum von 30 Tagen“ oder „Antwortzeit von weniger als 100 ms bei mindestens 95 % der empfangenen Anforderungen“.
  • Leistungskennzahlen (KPIs: Key Performance Indicators) sind quantifizierbare Messgrößen für die Leistung im Zeitverlauf für ein bestimmtes Ziel. Zur Messung der SLO-Richtlinien werden KPI-Metriken erhoben. Beispielhafte KPIs sind u. a. eine Anzahl von Dienstfehlern, Ausfallzeiten, Cache-Fehlversuche, Bilder pro Sekunde (FPS), Latenz, Anweisungen pro Zyklus (IPC), Sicherheitsfehler, fehlgeschlagene Anmeldungen usw. KPIs können abgeleitete Werte sein (z. B. durchschnittliche Latenz über ein gleitendes 30-Sekunden-Fenster). KPIs können auch auf Vergleichen basieren (z. B. prozentuale Abweichung vom historischen Durchschnitt).
  • Dienstgüteziele können als statistische und deterministische Spezifikationen erfasst werden, die eine geschichtete Top-Down-Struktur bilden, aber nicht zwangsläufig einem Baum- oder DAG-Muster entsprechen müssen. Zum Beispiel kann eine Metasprache verwendet werden, um wichtige Leistungsindikatoren (KPIs) auszudrücken und zu beschreiben, wie sie kombiniert werden, um eine gesamte Dienstgüte (QoS) oder ein Service-Level-Ziel (SLO: Service Level Objective) zu bewerten. Verschiedene Bereiche, Vergleiche, Schwellen, Einschränkungen oder dergleichen an den KPIs können mit einer Metasprache ausgedrückt werden. Die meisten realen Softwarelösungen müssen viele komplizierte Anforderungen an Leistungsfähigkeit, Skalierung, Genauigkeit und Verfügbarkeit erfüllen, und diese Anforderungen sind nicht unbedingt für alle Zeiten oder Situationen festgelegt. Ebenso wie Programme in einer Sprache wie C oder Python einem Programmierer ein hohes Maß an Flexibilität bei der Formulierung des zu Berechnenden ermöglichen, kann eine Metasprache verwendet werden, die die dynamischen Anforderungen ausdrückt, die von Schedulern von Ressourcen erfüllt werden müssen. Ein Metaprogramm, das in einer solchen Metasprache geschrieben ist, kann Variablen einführen, die zum Beispiel verschiedene Kalibrierungen widerspiegeln, die am Verhalten von Programmen, Laufzeiten, Betriebssystemen, Infrastrukturdiensten, Netzwerkausrüstung und so weiter vorgenommen werden. Diese Variablen werden dann in die Variablen und Ergebnisse der Metaprogramme auf höherer Ebene eingeflochten und steuern wiederum korrigierende, reaktive, warnende und andere Aktionen von Metaprogrammen an. Die Strukturierung erfolgt schichtweise, so dass Metaprogramme zur Abstraktion und Reduktion von Details und zur Annäherung an die vorgegebenen Ziele auf höheren Ebenen ausgelegt sind.
  • Es wird eine offene Architektur wird bereitgestellt, sodass die Schichtung von Richtlinien, Heuristiken usw. nicht allein durch Logikregeln beschränkt ist, sondern die Fähigkeit ermöglicht, datenprogrammierte Intelligenzen wie etwa neuronale Netze, Support Vector Machines (SVM), Entscheidungsbäume usw. einzubinden. Das übergeordnete Ziel besteht darin, einen Teil der Berechnungen auf solche Metaprogramme umzuleiten und eine strikte Trennung zwischen den Berechnungen, die Teil der Struktur einer Anwendung sind, und den Berechnungen, die dazu ausgelegt sind, ein Dienstgüteziel während der Ausführung der Anwendung zu erreichen, zu vermeiden. Somit ist die übliche Unterscheidung zwischen einer Steuerungs-/Verwaltungsebene wie Kubernetes und einer containerisierten Anwendung, unter der sie läuft, unscharf, und Informationen über die Absicht und die Leistungsfähigkeit zu dieser Absicht können auf verschiedenen Tiefenschichten bidirektional fließen. Dementsprechend können autokorrigierende und autoindikative Fähigkeiten zwischen den Flüssen in den Dienstzielen und Dienstgütezielen mitentwickelt werden. Ein Vorteil besteht darin, dass die Software beginnt, sich selbst oder gemeinsam mit der Umgebung, in der sie aktiviert wird, anzupassen.
  • Statistische Zulassungssteuerungsrichtlinien, die versuchen, die Erfüllung von Dienstleistungsvereinbarungen (SLA: Service Level Agreements) zu maximieren, stehen zur Verfügung und betreffen jitterempfindliche Netzwerksysteme. Mit zunehmender Abstraktion und der Implementierung von Scheduling in serverlosen oder hochgradig virtualisierten Systemen sowie der Just-in-Time-Zuweisung von Ressourcen durch Container, die bei Bedarf erstellt werden, nimmt die Komplexität des Scheduling von Ressourcen jedoch weiter zu. Sehr große Datenzentren können beträchtliche Kapazitäten für den reaktiven Lastausgleich bereitstellen und die Ablehnung der Zulassung bis die extremsten Nachfragespitzen aufschieben, aber kleinere und weniger elastische Infrastrukturanbieter müssen selbst bei statistischen Richtlinien harte Entscheidungen treffen, wenn ein Cutoff bei einem Ausreißer der Tail-Latenz vorgenommen wird. Es ist äußerst schwierig, große Nachfrageschübe zu bewältigen, die eine Kaskade von Latenzüberschreitungen verursachen können. Als Alternative dazu implementieren die hierin beschriebenen Systeme und Verfahren SLAs, die sowohl verschachtelt als auch abgestuft sind und somit Burst-akkommodierend sind.
  • Man stelle sich ein Token-Bucket-Modell mit einer einzelnen Warteschlange an einem ratenbegrenzten Server vor: Eine statistische Projektion für die neueste Ankunft hat eine mittlere Antwortzeit auf, die proportional zur Länge der Warteschlange ist, die von der neuen Ankunft gesehen wird. Eine naive Richtlinie wäre es, die neue Ankunft abzulehnen, falls diese voraussichtliche Antwortzeit eine Beschränkung der Tail-Latenz; eine etwas weniger naive Richtlinie wäre es, die neue Ankunft je nach Länge der Warteschlange und der Anzahl der bereits aufgetretenen Verstöße mit einer gewissen Wahrscheinlichkeit abzulehnen. Man stelle sich nun eine Verallgemeinerung vor, bei der der grundlegende Single-Queue-, Single-Rate-Server in eine zweistufige Richtlinie aufgeteilt wird, bei der die neueste Ankunft in der zweiten Warteschlange platziert wird, wo ihr eine niedrigere Dienstrate garantiert wird, aber eine entspanntere Tail-Latenz erlaubt ist. Falls also zum Beispiel die erste Warteschlange eine P99-Latenz von 10 ms aufwies, kann die zweite Warteschlange ein kombiniertes SLO mit einer P95-Latenz von 10 ms und einer P99-Latenz von 20 ms aufweisen. Da extreme Bursts selten sind, muss der Kapazitätsanteil der zweiten Warteschlange nicht hoch sein, da ihre durchschnittliche Warteschlangenlänge gering ist. In einem Datenzentrum wird durch die Verschiebung in eine zweite Warteschlange die marginale Anforderung (diejenige, die wahrscheinlich gegen eine strenge Latenzgrenze verstößt) einem weniger ausgelasteten, aber mit weniger Ressourcen ausgestatteten Überlauf-Cluster mit entsprechend entspannterem SLO zugewiesen. Dieses Schema kann verallgemeinert werden, so dass, wenn sich die zweite Warteschlange ihrer Sättigung in Bezug auf die Antwortzeit nähert, eine dritte Warteschlange mit noch großzügigerem SLO den Überlauf absorbiert. Auf diese Weise können zusammengesetzte verschachtelte SLOs innerhalb einer SLA erstellt werden, die sich an Bursts anpassen lässt. Der Anbieter kann ein ähnlich gestaffeltes Kostenmodell aushandeln, bei dem die Einsparungen, die dadurch entstehen, dass er keine großen Spitzenkapazitäten bereitstellen muss, um eine unelastische SLA zu erfüllen, an Kunden weitergegeben werden, die eine verschachteltes SLA akzeptieren.
  • Im Gegensatz zu hierarchischen Dienstleistungsvereinbarungen führen die hier beschriebenen Systeme und Verfahren SLAs ein, die sowohl verschachtelt als auch abgestuft sind. Anstatt sich auf klassische Schwellenwertbildung zu verlassen und anstatt festgesetzte „einzelne“ Klauselregeln prüfen zu müssen, kann eine verschachtelte Teilklausel der SLA in Kombination mit anderen Teilklauseln bewertet werden, um die SLA insgesamt zu evaluieren. Dies ermöglicht komplexere Regeln. Außerdem ermöglicht ein „Parsen“ der Teilklauseln, dass die Ergebnisse jeder Klausel eine gemeinsame Nutzung ungenutzter Ressourcen bewirken. Dieser Ansatz ermöglicht mehr Flexibilität bei den SLA-Regeln und eine bessere Nutzung der Clusterressourcen. Die Flexibilität kann als „Absicht“ und nicht als Ressourcenspezifikation eingeführt werden, die dann auf verschachtelte/abgestufte SLA-Regeln abgebildet wird, die dann überwacht und durchgesetzt werden.
  • Bei Produktionsbereitstellungen ist es ein übliches Vorgehen, neue Instanzen einer Anwendung auf einem Teil der Umgebung bereitzustellen und mit einer kleinen Teilgruppe der Benutzerbasis zu testen, bevor sie auf die breite Benutzerschaft ausgeweitet wird (d. h. Canary-Rollout). Da die Zuordnung von SLAs zu immer niedrigeren Ebenen von Service-Level-Zielen einen iterativen Ansatz erfordert (sowohl für Optimierungs- als auch für Abhilfezwecke), beinhaltet der neue Arbeitsablauf für diese SLA-Zerlegung auch die Möglichkeit einer teilweisen Bereitstellung entweder in einer begrenzten End-to-End-Form oder als Teilkomponenten der E2E-Lösung, um die Auswirkungen auf die SLA-Einhaltung zu ermitteln.
  • Zusammenfassend stellen die hierin beschriebenen Systeme und Verfahren einen neuen Weg zum Erreichen einer Orchestrierung bereit, indem sie von einem aktuellen Modell zu einem zielgesteuerten Ansatz übergehen, bei dem der Kunde nur die Absicht (z. B. Latenz-, Durchsatz- und Zuverlässigkeitseigenschaften) äußert und der Orchestrierungsstapel selbst die Plattform zur Erreichung dieser Absicht einrichtet. Mit zunehmender Verbreitung serverloser Infrastrukturen werden Cloud-native (Mikrodienst-)Arbeitslasten letztendlich einen Weg der absichtsgesteuerten Orchestrierung erfordern. Diese Funktionen und andere sind unten ausführlicher beschrieben.
  • 1 ist ein Blockdiagramm 100, das einen Überblick über eine Konfiguration für Edge-Computing zeigt, die eine Verarbeitungsschicht beinhaltet, die in vielen der folgenden Beispiele als „Edge-Cloud“ bezeichnet wird. Wie gezeigt, befindet sich die Edge-Cloud 110 an einem Edge-Standort wie etwa einem Zugangspunkt oder einer Basisstation 140, einem lokalen Verarbeitungs-Hub 150 oder einer Zentrale 120 und kann somit mehrere Entitäten, Vorrichtungen und Geräteinstanzen beinhalten. Die Edge-Cloud 110 befindet sich viel näher an den Endpunkt- (Verbraucher und Erzeuger)-Datenquellen 160 (z. B. autonome Fahrzeuge 161, Benutzergeräte 162, Geschäfts- und Industrieausrüstung 163, Videoaufnahmevorrichtungen 164, Drohnen 165, intelligente Städte- und Gebäudevorrichtungen 166, Sensoren und IoT-Vorrichtungen 167 usw.) als das Cloud-Datenzentrum 130. Rechen-, Speicher- und Speicherungsressourcen, die an den Rändern in der Edge-Cloud 110 angeboten werden, sind kritisch für das Bereitstellen von Antwortzeiten mit ultraniedriger Latenz für Dienste und Funktionen, die durch die Endpunktdatenquellen 160 verwendet werden, sowie für das Reduzieren von Netzwerk-Backhaul-Verkehr von der Edge-Cloud 110 zum Cloud-Datenzentrum 130, wodurch Energieverbrauch und Gesamtnetzwerknutzungen unter anderen Vorteilen verbessert werden.
  • Berechnung, Speicher und Speicherung sind knappe Ressourcen und nehmen im Allgemeinen in Abhängigkeit vom Edge-Standort ab (wobei z. B. weniger Verarbeitungsressourcen an Verbraucherendpunktvorrichtungen verfügbar sind als an einer Basisstation als an einer Zentrale). Je näher sich der Edge-Standort jedoch am Endpunkt (z. B. dem Benutzergerät (UE: user equipment)) befindet, desto mehr sind Raum und Leistung häufig eingeschränkt. Somit versucht Edge-Computing die Menge an Ressourcen, die für Netzwerkdienste benötigt werden, durch die Verteilung von mehr Ressourcen, die sich sowohl geographisch als auch in der Netzwerkzugriffszeit näher befinden, zu reduzieren. Auf diese Weise versucht Edge-Computing, die Rechenressourcen gegebenenfalls zu den Arbeitslastdaten zu bringen oder die Arbeitslastdaten zu den Rechenressourcen zu bringen.
  • Im Folgenden werden Aspekte einer Edge-Cloud-Architektur beschrieben, die mehrere potenzielle Einsätze abdeckt und Einschränkungen berücksichtigt, die manche Netzbetreiber oder Dienstanbieter in ihren eigenen Infrastrukturen aufweisen können. Diese beinhalten die Variation von Konfigurationen basierend auf dem Edge-Standort (weil Ränder auf einer Basisstationsebene zum Beispiel weiter eingeschränkte Leistungsfähigkeit und Fähigkeiten in einem mandantenfähigen Szenario aufweisen können); Konfigurationen basierend auf der Art der Berechnung, des Speichers, der Speicherung, der Fabric, der Beschleunigung oder ähnlichen Ressourcen, die für Edge-Orte, Ebenen von Orten oder Gruppen von Orten verfügbar sind; die Dienst-, Sicherheits- und Verwaltungs- und Orchestrierungsfähigkeiten; und verwandte Ziele, um Nutzbarkeit und Leistungsfähigkeit von Enddiensten zu erreichen. Diese Einsätze können eine Verarbeitung in Netzwerkschichten bewerkstelligen, die in Abhängigkeit von Latenz-, Entfernungs- und Zeitmerkmalen als „Near-Edge“-, „Close-Edge“-, „Local-Edge“-, „Middle-Edge“- oder „Far-Edge“-Schichten betrachtet werden können.
  • Edge-Computing ist ein sich entwickelndes Paradigma, bei dem die Berechnung an oder näher am „Edge“ (Rand) eines Netzwerks durchgeführt wird, typischerweise durch die Verwendung einer Rechenplattform (z. B. x86- oder ARM-Rechenhardwarearchitektur), die an Basisstationen, Gateways, Netzwerkroutern oder anderen Vorrichtungen implementiert ist, die sich viel näher an Endpunktvorrichtungen befinden, die Daten erzeugen und verbrauchen. Edge-Gateway-Server können zum Beispiel mit Pools von Speicher und Speicherungsressourcen ausgestattet sein, um eine Berechnung in Echtzeit für Verwendungsfälle mit niedriger Latenz (z. B. autonomes Fahren oder Videoüberwachung) für verbundene Client-Vorrichtungen durchzuführen. Oder es können als Beispiel Basisstationen mit Rechen- und Beschleunigungsressourcen erweitert werden, um Dienstarbeitslasten für verbundene Benutzergeräte direkt zu verarbeiten, ohne weiter Daten über Backhaul-Netzwerke zu kommunizieren. Oder es kann als anderes Beispiel die Hardware für das Netzwerkmanagement in der Zentrale durch standardisierte Rechenhardware ersetzt werden, die virtualisierte Netzwerkfunktionen ausführt und Rechenressourcen für die Ausführung von Diensten und Verbraucherfunktionen für angeschlossene Vorrichtungen anbietet. Innerhalb von Edge-Computing-Netzwerken kann es Szenarien in Diensten geben, bei denen die Rechenressource zu den Daten „verschoben“ wird, sowie Szenarien, bei denen die Daten zur Rechenressource „verschoben“ werden. Oder es können als Beispiel Berechnungs-, Beschleunigungs- und Netzwerkressourcen der Basisstation Dienste bereitstellen, um die Arbeitslastanforderungen nach Bedarf durch Aktivieren ruhender Kapazität (Subskription, Kapazität nach Bedarf) zu skalieren, um Eckfälle, Notfälle zu verwalten oder Langlebigkeit für eingesetzte Ressourcen über einen wesentlich längeren implementierten Lebenszyklus bereitzustellen.
  • 2 veranschaulicht Betriebsschichten zwischen Endpunkten, eine Edge-Cloud und Cloud-Computing-Umgebungen. Insbesondere stellt 2 Beispiele für Rechenanwendungsfälle 205 dar, bei denen die Edge-Cloud 110 auf mehreren veranschaulichenden Schichten der Netzwerkberechnung eingesetzt wird. Die Schichten beginnen bei einer Endpunktschicht (Vorrichtungen und Dinge) 200, die auf die Edge-Cloud 110 zugreift, um Aktivitäten zur Datenerzeugung, analyse und nutzung durchzuführen. Die Edge-Cloud 110 kann mehrere Netzwerkschichten überspannen, wie etwa eine Edge-Vorrichtungsschicht 210 mit Gateways, Vor-Ort-Servern oder Netzwerkgeräten (Knoten 215), die sich in physisch nahen Randsystemen befinden; eine Netzwerkzugangsschicht 220, umfassend Basisstationen, Funkverarbeitungseinheiten, Netzwerk-Hubs, regionale Datenzentren (DC) oder lokale Netzwerkgeräte (Geräte 225); und beliebige Geräte, Vorrichtungen oder Knoten, die sich dazwischen befinden (in Schicht 212, nicht ausführlich veranschaulicht). Die Netzwerkkommunikationen innerhalb der Edge-Cloud 110 und zwischen den verschiedenen Schichten können über eine beliebige Anzahl drahtgebundener oder drahtloser Medien stattfinden, einschließlich über Konnektivitätsarchitekturen und Technologien, die nicht dargestellt sind.
  • Beispiele für Latenz, die sich aus der Netzwerkkommunikationsdistanz- und Verarbeitungszeitbeschränkungen ergeben, können von weniger als einer Millisekunde (ms), wenn inmitten der Endpunktschicht 200, unter 5 ms an der Edge-Vorrichtungsschicht 210, sogar zwischen 10 und 40 ms, wenn mit Knoten an der Netzwerkzugangsschicht 220 kommuniziert wird, reichen. Jenseits der Edge-Cloud 110 befinden sich die Schichten des Kernnetzwerks 230 und des Cloud-Datenzentrums 240, jeweils mit zunehmender Latenz (z. B. zwischen 50 und 60 ms auf der Kernnetzwerkschicht 230 und 100 oder mehr ms auf der Schicht des Cloud-Datenzentrums). Infolgedessen werden Operationen in einem Kernnetzwerk-Datenzentrum 235 oder einem Cloud-Datenzentrum 245 mit Latenzen von mindestens 50 bis 100 ms oder mehr nicht in der Lage sein, viele zeitkritische Funktionen der Anwendungsfälle 205 zu realisieren. Jeder dieser Latenzwerte wird zu Veranschaulichungs- und Gegenüberstellungszwecken bereitgestellt; es versteht sich, dass die Verwendung anderer Zugangsnetzwerkmedien und -technologien die Latenzen weiter reduzieren kann. In manchen Beispielen können jeweilige Teile des Netzwerks relativ zu einer Netzwerkquelle und einem Netzwerkziel als „Close-Edge“-, „Local-Edge“-, „Near-Edge“-, „Middle-Edge“- oder „Far-Edge“-Schichten kategorisiert sein. Beispielsweise kann aus der Perspektive des Kernnetzwerk-Datenzentrums 235 oder eines Cloud-Datenzentrums 245 eine Zentrale oder ein Inhaltsdatennetzwerk als in einer „Near-Edge“-Schicht befindlich betrachtet werden („nahe“ zur Cloud, mit hohen Latenzwerten bei der Kommunikation mit den Vorrichtungen und Endpunkten der Anwendungsfälle 205), wohingegen ein Zugangspunkt, eine Basisstation, ein Vor-Ort-Server oder ein Netzwerk-Gateway als in einer „Far-Edge“-Schicht („fern“ von der Cloud, mit niedrigen Latenzwerten bei der Kommunikation mit den Vorrichtungen und Endpunkten der Anwendungsfälle 205) befindlich betrachtet werden können. Es versteht sich, dass andere Kategorisierungen einer speziellen Netzwerkschicht als einen „Close“-, „Local“-, „Near“-, „Middle“ oder „Far“-Edge bildend auf Latenz, Entfernung, Anzahl von Netzwerksprüngen oder anderen messbaren Charakteristiken basieren können, wie von einer Quelle in einer beliebigen der Netzwerkschichten 200-240 gemessen.
  • Die diversen Anwendungsfälle 205 können aufgrund mehrerer Dienste, die Edge-Cloud nutzen, auf Ressourcen unter Verwendungsdruck von eingehenden Strömen zugreifen. Um Ergebnisse mit niedriger Latenz zu erzielen, gleichen die Dienste, die innerhalb der Edge-Cloud 110 ausgeführt werden, schwankende Anforderungen in Bezug auf Folgendes aus: (a) Priorität (Durchsatz oder Latenz) und Dienstgüte (QoS: Quality of Service) (z. B. kann Verkehr für ein autonomes Auto eine höhere Priorität hinsichtlich der Antwortzeitanforderung als ein Temperatursensor aufweisen; oder eine Leistungsempfindlichkeit/ein Leistungsengpass kann an einer Rechen-/Beschleuniger-, Speicher-, Speicherungs- oder Netzwerkressource in Abhängigkeit von der Anwendung vorhanden sein); (b) Zuverlässigkeit und Widerstandsfähigkeit (z. B. müssen manche Eingabeströme bearbeitet und der Verkehr mit missionskritischer Zuverlässigkeit geleitet werden, wobei manche anderen Eingabeströme je nach Anwendung einen gelegentlichen Ausfall tolerieren können); und (c) physikalische Einschränkungen (z. B. Leistung, Kühlung und Formfaktor).
  • Die Ende-zu-Ende-Dienstansicht für diese Anwendungsfälle beinhaltet den Begriff eines Dienstflusses und ist einer Transaktion zugeordnet. Die Transaktion beschreibt genau die Gesamtdienstanforderung für die Entität, die den Dienst in Anspruch nimmt, sowie die zugehörigen Dienste für die Ressourcen, Arbeitslasten, Arbeitsabläufe und Geschäftsfunktions- und Geschäftsebenenanforderungen. Die Dienste, die mit den beschriebenen „Begriffen“ ausgeführt werden, können in jeder Schicht auf eine Weise verwaltet werden, dass Echtzeit- und Laufzeitvertragskonformität für die Transaktion während des Lebenszyklus des Dienstes sichergestellt wird. Wenn einer Komponente in der Transaktion ihre vereinbarte SLA fehlt, kann das System als Ganzes (Komponenten in der Transaktion) die Fähigkeit bereitstellen, (1) die Auswirkung der SLA-Verletzung zu verstehen und (2) andere Komponenten im System zu erweitern, um die gesamte Transaktions-SLA wiederaufzunehmen, und (3) Schritte zu implementieren, um Abhilfe zu schaffen.
  • Dementsprechend kann unter Berücksichtigung dieser Variationen und Dienstleistungsmerkmale Edge-Computing innerhalb der Edge-Cloud 110 die Fähigkeit bereitstellen, mehrere Anwendungen der Anwendungsfälle 205 (z. B. Objektverfolgung, Videoüberwachung, verbundene Autos usw.) in Echtzeit oder nahezu Echtzeit zu bedienen und auf diese zu reagieren und Anforderungen an ultraniedrige Latenz für diese mehreren Anwendungen zu erfüllen. Diese Vorteile ermöglichen eine ganze neue Klasse von Anwendungen (Virtual Network Functions (VNFs), Function as a Service (FaaS), Edge as a Service (FaaS), Standardprozesse usw.), die das Cloud-Computing aufgrund der Latenz oder anderer Einschränkungen nicht nutzen können.
  • Mit den Vorteilen des Edge-Computing sind jedoch auch die folgenden Vorbehalte verbunden. Die Vorrichtungen am Edge sind häufig ressourcenbeschränkt, so dass Druck auf die Nutzung von Edge-Ressourcen besteht. Typischerweise wird dies durch das Bündeln von Speicher- und Speicherungsressourcen zur Verwendung durch mehrere Benutzer (Mandanten) und Vorrichtungen adressiert. Der Edge kann leistungs- und kühlungsbeschränkt sein, so dass der Leistungsverbrauch durch die Anwendungen berücksichtigt werden muss, die die meiste Leistung verbrauchen. Bei diesen gebündelten Speicherressourcen kann es zu einem inhärenten Kompromiss zwischen Leistungsversorgung und Leistungsfähigkeit kommen, da viele von ihnen wahrscheinlich neu aufkommende Speichertechnologien verwenden, wo mehr Leistung eine größere Speicherbandbreite benötigt. Gleichermaßen sind eine verbesserte Sicherheit der Hardware und der vertrauenswürdigen Root-of-Trust-Funktionen auch erforderlich, da Edge-Standorte unbemannt sein können und sogar eine Zugriffsberechtigung benötigen können (z. B. wenn sie an einem Drittparteistandort untergebracht sind). Solche Probleme werden in der Edge-Cloud 110 in einer Umgebung mit mehreren Mandanten, mehreren Eigentümern oder mehreren Zugängen noch verschärft, in der Dienste und Anwendungen von vielen Benutzern angefordert werden, insbesondere da die Netzwerknutzung dynamisch schwankt und sich die Zusammensetzung der mehreren Beteiligten, Anwendungsfälle und Dienste ändert.
  • Auf einer allgemeineren Ebene kann ein Edge-Computing-System so beschrieben werden, dass es eine beliebige Anzahl von Bereitstellungen an den zuvor erläuterten Schichten umfasst, die in der Edge-Cloud 110 (Netzwerkschichten 200-240) arbeiten, die eine Koordination von Client- und verteilten Rechenvorrichtungen bereitstellen. Ein oder mehrere Edge-Gateway-Knoten, ein oder mehrere Edge-Aggregationsknoten und ein oder mehrere Kerndatenzentren können über Schichten des Netzwerks verteilt sein, um eine Implementierung des Edge-Computing-Systems durch oder im Auftrag eines Telekommunikationsdienstanbieters („Telko“ oder „TSP“), Internet-der-Dinge-Dienstanbieters, Cloud-Dienstanbieters (CSP), einer Unternehmensentität oder einer beliebigen anderen Anzahl von Entitäten bereitzustellen. Verschiedene Implementierungen und Konfigurationen des Edge-Computing-Systems können dynamisch bereitgestellt werden, wie etwa orchestriert, um Dienstziele zu erfüllen.
  • Im Einklang mit den hierin bereitgestellten Beispielen kann ein Client-Rechenknoten als eine beliebige Art von Endpunktkomponente, vorrichtung, einrichtung oder anderem Ding ausgebildet sein, die bzw. das dazu in der Lage ist, als Erzeuger oder Verbraucher von Daten zu kommunizieren. Ferner bedeutet die Bezeichnung „Knoten“ oder „Vorrichtung“, wie sie im Edge-Computing-System verwendet wird, nicht notwendigerweise, dass ein solcher Knoten oder eine solche Vorrichtung in einer Client- oder Agenten-/Minion-/Folgerrolle arbeitet; vielmehr beziehen sich beliebige der Knoten oder Vorrichtungen im Edge-Computing-System auf einzelne Entitäten, Knoten oder Teilsysteme, die diskrete oder verbundene Hardware- oder Softwarekonfigurationen aufweisen, um die Edge-Cloud 110 zu erleichtern oder zu verwenden.
  • Von daher ist die Rand-Cloud 110 aus Netzwerkkomponenten und funktionalen Merkmalen gebildet, die durch und innerhalb von Edge-Gateway-Knoten, Edge-Aggregationsknoten oder anderen Edge-Rechenknoten auf den Netzwerkschichten 210-230 betrieben werden. Die Edge-Cloud 110 kann somit als eine beliebige Art von Netzwerk umgesetzt sein, das Edge-Computing- und/oder Speicherungsressourcen bereitstellt, die sich nahe an funkzugangsnetz- (RAN-)fähigen Endpunktvorrichtungen (z. B. Mobilrechenvorrichtungen, IoT-Vorrichtungen, intelligente Vorrichtungen usw.) befinden, die hierin besprochen werden. Mit anderen Worten kann die Edge-Cloud 110 als ein „Edge“ gedacht werden, der die Endpunktvorrichtungen und traditionelle Netzzugangspunkte, die als ein Eingangspunkt in Dienstanbieter-Kernnetzwerke dienen, verbindet, einschließlich der Netze von Mobilfunkanbietern (z. B. Global System for Mobile Communications (GSM)-Netze, Long-Term Evolution (LTE)-Netze, 5G/6G-Netze usw.), und gleichzeitig Speicherungs- und/oder Rechenfähigkeiten bereitstellt. Andere Arten und Formen des Netzzugangs (z. B. Wi-Fi, drahtlose Weitverkehrsnetze, drahtgebundene Netze einschließlich optischer Netze) können auch anstelle von oder in Kombination mit solchen 3GPP-Trägernetzen genutzt werden.
  • Bei den Netzwerkkomponenten der Edge-Cloud 110 kann es sich um Server, mandantenfähige Server, Gerätedatenverarbeitungsvorrichtungen und/oder jede andere Art von Rechenvorrichtungen handeln. Zum Beispiel kann die Edge-Cloud 110 eine Gerätedatenverarbeitungsvorrichtung beinhalten, die eine eigenständige elektronische Vorrichtung einschließlich eines Gehäuses, eines Chassis, einer Hülle oder einer Schale ist. Unter Umständen kann das Gehäuse für eine Portabilität dimensioniert sein, so dass es von einem Menschen getragen und/oder versandt werden kann. Beispielhafte Gehäuse können Materialien beinhalten, die eine oder mehrere Außenflächen bilden, die Inhalte des Geräts teilweise oder vollständig schützen, wobei der Schutz Wetterschutz, Schutz in gefährlichen Umgebungen (z. B. EMI, Vibration, extreme Temperaturen) beinhalten kann und/oder Eintauchbarkeit ermöglichen kann. Beispielhafte Gehäuse können ein Leistungsschaltungsanordnung beinhalten, um Leistung für stationäre und/oder tragbare Implementierungen bereitzustellen, wie etwa AC-Leistungseingänge, DC-Leistungseingänge, AC/DC- oder DC/AC-Wandler, Leistungsregler, Transformatoren, Ladeschaltungsanordnungen, Batterien, drahtgebundene Eingänge und/oder drahtlose Leistungseingänge. Beispielhafte Gehäuse und/oder deren Oberflächen können Befestigungselemente enthalten oder mit diesen verbunden sein, um eine Befestigung an Strukturen wie etwa Gebäuden, Telekommunikationsstrukturen (z. B. Masten, Antennenstrukturen usw.) und/oder Racks (z. B. Server-Racks, Blade-Halterungen usw.) zu ermöglichen. Beispielhafte Gehäuse und/oder deren Oberflächen können einen oder mehrere Sensoren (z. B. Temperatursensoren, Vibrationssensoren, Lichtsensoren, Akustiksensoren, kapazitive Sensoren, Näherungssensoren usw.) tragen. Ein oder mehrere solcher Sensoren können in der Oberfläche enthalten, von dieser getragen oder anderweitig eingebettet und/oder an der Oberfläche des Geräts montiert sein. Beispielhafte Gehäuse und/oder deren Oberflächen können mechanische Verbindungen tragen, wie etwa Antriebskomponenten (z. B. Räder, Propeller usw.) und/oder Gelenkkomponenten (z. B. Roboterarme, schwenkbare Fortsätze usw.). Unter manchen Umständen können die Sensoren eine beliebige Art von Eingabevorrichtungen beinhalten, wie etwa Benutzerschnittstellenhardware (z. B. Tasten, Schalter, Wählscheiben, Schieber usw.). Unter manchen Umständen beinhalten beispielhafte Gehäuse Ausgabevorrichtungen, die darin, getragen durch, eingebettet darin und/oder daran angebracht sind. Ausgabevorrichtungen können Anzeigen, Touchscreens, Leuchten, LEDs, Lautsprecher, E/A-Ports (z. B. USB) usw. umfassen. Unter Umständen sind Edge-Vorrichtungen Vorrichtungen, die in dem Netzwerk für einen spezifischen Zweck (z. B. eine Ampel) präsentiert werden, können aber Verarbeitungs- und/oder andere Kapazitäten aufweisen, die für andere Zwecke genutzt werden können. Solche Edge-Vorrichtungen können unabhängig von anderen vernetzten Vorrichtungen sein und können mit einem Gehäuse bereitgestellt sein, das einen Formfaktor aufweist, der für ihren primären Zweck geeignet ist, aber dennoch für andere Rechenaufgaben verfügbar sein, die ihre primäre Aufgabe nicht stören. Edge-Vorrichtungen beinhalten Vorrichtungen des Internets der Dinge. Die Geräterechenvorrichtung kann Hardware- und Softwarekomponenten beinhalten, um lokale Probleme wie etwa Vorrichtungstemperatur, Vibration, Ressourcennutzung, Aktualisierungen, Leistungsprobleme, physische und Netzwerksicherheit usw. zu verwalten. Beispielhafte Hardware zum Implementieren einer Geräterechenvorrichtung ist in Verbindung mit 6B beschrieben. Die Edge-Cloud 110 kann auch einen oder mehrere Server und/oder einen oder mehrere mandantenfähige Server beinhalten. Ein solcher Server kann ein Betriebssystem beinhalten und eine virtuelle Rechenumgebung implementieren. Eine virtuelle Rechenumgebung kann einen Hypervisor beinhalten, der eine oder mehrere virtuelle Maschinen, einen oder mehrere Container usw. verwaltet (z. B. erzeugt, einsetzt, zerstört usw.). Solche virtuellen Rechenumgebungen stellen eine Ausführungsumgebung bereit, in der eine oder mehrere Anwendungen und/oder andere Software, anderer Code oder andere Skripte ausgeführt werden können, während sie von einer oder mehreren anderen Anwendungen, Software, Code oder Skripten isoliert sind.
  • In 3 tauschen verschiedene Client-Endpunkte 310 (in Form von Mobilvorrichtungen, Computern, autonomen Fahrzeugen, Geschäftsrechenanlagen, industriellen Verarbeitungsanlagen) Anforderungen und Antworten aus, die für den Typ der Endpunktnetzwerkaggregation spezifisch sind. Beispielsweise können Client-Endpunkte 310 Netzwerkzugang über ein drahtgebundenes Breitbandnetzwerk erhalten, indem Anforderungen und Antworten 322 durch ein Vor-Ort-Netzwerksystem 332 ausgetauscht werden. Manche Client-Endpunkte 310 wie etwa mobile Rechenvorrichtungen können Netzwerkzugang über ein drahtloses Breitbandnetzwerk erhalten, indem Anfragen und Antworten 324 durch einen Zugangspunkt (z. B. Mobilfunkturm) 334 ausgetauscht werden. Manche Client-Endpunkte 310 wie etwa autonome Fahrzeuge können Netzwerkzugang für Anfragen und Antworten 326 über ein drahtloses Fahrzeugnetzwerk durch ein straßengebundenes Netzwerksystem 336 erhalten. Unabhängig von der Art des Netzwerkzugangs kann der TSP jedoch Aggregationspunkte 342, 344 innerhalb der Edge-Cloud 110 einsetzen, um Verkehr und Anfragen zu aggregieren. Somit kann der TSP innerhalb der Edge-Cloud 110 verschiedene Rechen- und Speicherressourcen einsetzen, wie etwa an Edge-Aggregationsknoten 340, um angeforderten Inhalt bereitzustellen. Die Edge-Aggregationsknoten 340 und andere Systeme der Edge-Cloud 110 sind mit einer Cloud oder einem Datenzentrum 360 verbunden, das ein Backhaul-Netzwerk 350 verwendet, um Anforderungen mit höherer Latenz von einer Cloud/einem Datenzentrum für Websites, Anwendungen, Datenbankserver usw. zu erfüllen. Zusätzliche oder konsolidierte Instanzen der Edge-Aggregationsknoten 340 und der Aggregationspunkte 342, 344, einschließlich jener, die auf einem einzigen Server-Framework eingesetzt werden, können auch innerhalb der Edge-Cloud 110 oder anderer Bereiche der TSP-Infrastruktur vorhanden sein.
  • 4 veranschaulicht Einsatz und Orchestrierung für virtualisierte und containerbasierte Edge-Konfigurationen über ein Edge-Computing-System, das zwischen mehreren Edge-Knoten und mehreren Mandanten (z. B. Benutzern, Anbietern) betrieben wird, die solche Edge-Knoten verwenden. Insbesondere stellt 4 eine Koordination eines ersten Edge-Knotens 422 und eines zweiten Edge-Knotens 424 in einem Edge-Computing-System 400 dar, um Anforderungen und Antworten für verschiedene Client-Endpunkte 410 (z. B. intelligente Städte / Gebäudesysteme, mobile Vorrichtungen, Rechenvorrichtungen, Geschäfts-/Logistiksysteme, Industriesysteme usw.) zu erfüllen, die auf verschiedene virtuelle Edge-Instanzen zugreifen. Hier stellen die virtuellen Edge-Instanzen 432, 434 Edge-Rechenfähigkeiten und eine Verarbeitung in einer Edge-Cloud mit Zugriff auf eine Cloud/ein Datenzentrum 440 für Anforderungen mit höherer Latenz für Websites, Anwendungen, Datenbankserver usw. bereit. Die Edge-Cloud ermöglicht jedoch eine Koordination der Verarbeitung zwischen mehreren Edge-Knoten für mehrere Mandanten oder Entitäten.
  • Im Beispiel von 4 umfassen diese virtuellen Edge-Instanzen: einen ersten virtuelle Edge 432, der einem ersten Mandanten (Mandanten 1) angeboten wird, der eine erste Kombination aus Edge-Speicherung, Berechnung und Diensten anbietet; und einen zweite virtuellen Edge 434, der eine zweite Kombination aus Edge-Speicherung, Berechnung und Diensten anbietet. Die virtuellen Edge-Instanzen 432, 434 sind unter den Edge-Knoten 422, 424 verteilt und können Szenarien aufweisen, in denen eine Anforderung und Antwort von demselben oder unterschiedlichen Edge-Knoten erfüllt werden. Die Konfiguration der Edge-Knoten 422, 424 für einen verteilten, aber koordinierten Betrieb erfolgt auf der Grundlage der Edge-Bereitstellungsfunktionen 450. Die Funktionalität der Edge-Knoten 422, 424 zum Bereitstellen eines koordinierten Betriebs für Anwendungen und Dienste unter mehreren Mandanten erfolgt auf der Grundlage der Orchestrierungsfunktionen 460.
  • Es versteht sich, dass manche der Vorrichtungen in 410 Multi-Mandanten-Vorrichtungen sind, wobei Mandant 1 innerhalb eines Mandant-1 ,Slice' funktionieren kann, während ein Mandant 2 innerhalb eines Mandant-2-Slice funktionieren kann (und in weiteren Beispielen können zusätzliche oder Submandanten existieren; und jeder Mandant kann sogar spezifisch berechtigt und transaktionell an einen spezifischen Satz von Merkmalen bis hin zu spezifischen Hardwaremerkmalen gebunden sein). Eine vertrauenswürdige Multi-Mandanten-Vorrichtung kann ferner einen mandantenspezifischen kryptografischen Schlüssel enthalten, so dass die Kombination aus Schlüssel und Slice als eine „Root of Trust“ (RoT) oder mandantenspezifische RoT angesehen werden kann. Eine RoT kann ferner dynamisch unter Verwendung einer DICE-Architektur (DICE: Device Identity Composition Engine) berechnet werden, so dass ein einziger DICE-Hardwarebaustein verwendet werden kann, um geschichtete vertrauenswürdige Rechenbasiskontexte zum Schichten von Vorrichtungsfähigkeiten (wie etwa ein feldprogrammierbares Gate-Array (FPGA)) zu konstruieren. Die RoT kann ferner für einen vertrauenswürdigen Rechenkontext verwendet werden, um ein „Fan-Out“ zu ermöglichen, das zum Unterstützen einer Multi-Mandantenschaft nützlich ist. Innerhalb einer Multi-Mandanten-Umgebung können die jeweiligen Edge-Knoten 422, 424 als Durchsetzungspunkte für Sicherheitsmerkmale für lokale Ressourcen fungieren, die mehreren Mandanten pro Knoten zugewiesen sind. Zusätzlich dazu können Mandanten-Laufzeit- und Anwendungsausführung (z. B. in den Fällen 432, 434) als Durchsetzungspunkt für ein Sicherheitsmerkmal dienen, das eine virtuelle Edge-Abstraktion von Ressourcen erzeugt, die potenziell mehrere physische Hosting-Plattformen überspannen. Schließlich können die Orchestrierungsfunktionen 460 an einer Orchestrierungsentität als Durchsetzungspunkt für Sicherheitsmerkmale zum Lenken von Ressourcen entlang von Mandantengrenzen arbeiten.
  • Edge-Computing-Knoten können Ressourcen (Speicher, Zentralverarbeitungseinheit (CPU), Grafikverarbeitungseinheit (GPU), Interruptsteuerung, Eingabe/Ausgabe (E/A)-Steuerung, Speichersteuerung, Bussteuerung usw.) partitionieren, wobei jeweilige Partitionen eine RoT-Fähigkeit enthalten können und wobei ein Fan-Out und eine Schichtbildung gemäß einem DICE-Modell ferner auf Edge-Knoten angewendet werden können. Cloud-Computing-Knoten verwenden häufig Container, FaaS-Engines, Servlets, Server oder eine andere Berechnungsabstraktion, die gemäß einer DICE-Schichtungs- und Fan-Out-Struktur partitioniert werden können, um jeweils einen RoT-Kontext zu unterstützen. Dementsprechend können die jeweiligen RoTs, die die Vorrichtungen 410, 422 und 440 überspannen, die Einrichtung einer verteilten vertrauenswürdigen Rechenbasis (DTCB: Distributed Trusted Computing Base) koordinieren, so dass ein mandantenspezifischer virtueller vertrauenswürdiger sicherer Kanal, der alle Elemente von Ende zu Ende verbindet, eingerichtet werden kann.
  • Ferner versteht es sich, dass ein Container daten- oder arbeitslastspezifische Schlüssel aufweisen kann, die seinen Inhalt vor einem vorherigen Edge-Knoten schützen. Als Teil der Migration eines Containers kann eine Pod-Steuerung an einem Quell-Edge-Knoten einen Migrationsschlüssel von einer Pod-Steuerung eines Ziel-Edge-Knotens erhalten, wobei der Migrationsschlüssel zum Verpacken der containerspezifischen Schlüssel verwendet wird. Wenn der Container/Pod zu, Ziel-Edge-Knoten migriert wird, wird der Entpackungsschlüssel der Pod-Steuerung preisgegeben, die dann die verpackten Schlüssel entschlüsselt. Die Schlüssel können nun zur Durchführung von Operationen an behälterspezifischen Daten verwendet werden. Die Migrationsfunktionen können durch korrekt attestierte Randknoten und Pod-Manager (wie oben beschrieben) torgesteuert werden.
  • In weiteren Beispielen wird ein Edge-Computing-System erweitert, um eine Orchestrierung mehrerer Anwendungen durch die Verwendung von Containern (einer eingebundenen, einsetzbaren Softwareeinheit, die Code und benötigte Abhängigkeiten bereitstellt) in einer Multi-Eigentümer-, Multi-Mandanten-Umgebung bereitzustellen. Ein Multi-Mandanten-Orchestrator für die Schlüsselverwaltung, die Verwaltung von Vertrauensankem und andere Sicherheitsfunktionen in Bezug auf die Bereitstellung und den Lebenszyklus des vertrauenswürdigen „Slice“-Konzepts in 4 durchzuführen. Beispielsweise kann ein Edge-Computing-System dazu konfiguriert sein, Anforderungen und Antworten für verschiedene Client-Endpunkte von mehreren virtuellen Edge-Instanzen (und von einer Cloud oder einem entfernten Datenzentrum) zu erfüllen. Die Verwendung dieser virtuellen Edge-Instanzen kann mehrere Mandanten und mehrere Anwendungen (z. B. Augmented Reality (AR)/Virtual Reality (VR), Unternehmens anwendungen, Inhaltslieferung, Spielen, Rechen-Offload) gleichzeitig unterstützen. Ferner kann es mehrere Arten von Anwendungen innerhalb der virtuellen Edge-Instanzen geben (z. B. normale Anwendungen; latenzempfindliche Anwendungen; latenzkritische Anwendungen; Benutzerebenenanwendungen; Vernetzungsanwendungen usw.). Die virtuellen Edge-Instanzen können auch über Systeme mehrerer Eigentümer an unterschiedlichen geografischen Orten (oder jeweilige Rechensysteme und Ressourcen, die von mehreren Eigentümern gleichzeitig besessen oder mitverwaltet werden) überspannt sein.
  • Beispielsweise kann jeder Edge-Knoten 422, 424 die Verwendung von Containern implementieren, wie etwa unter Verwendung eines Containers „Pod“ 426, 428, der eine Gruppe von einem oder mehreren Containern bereitstellt. In einem Szenario, das einen oder mehrere Container-Pods verwendet, ist eine Pod-Steuerung oder ein Orchestrator für die lokale Steuerung und Orchestrierung der Container im Pod verantwortlich. Verschiedene Edge-Knotenressourcen (z. B. Speicherung, Berechnung, Dienste, dargestellt mit Hexagonen), die für die jeweiligen Edge-Slices 432, 434 bereitgestellt werden, werden gemäß den Bedürfnissen jedes Containers partitioniert.
  • Bei der Verwendung von Container-Pods beaufsichtigt eine Pod-Steuerung die Partitionierung und Zuweisung von Containern und Ressourcen. Die Pod-Steuerung empfängt Anweisungen von einem Orchestrator (z. B. dem Orchestrator 460), der die Steuerung darüber anweist, wie und für welche Dauer physische Ressourcen am besten zu partitionieren sind, wie etwa durch Empfangen von KPI-Zielen (KPI: Key Performance Indicator) basierend auf SLA-Verträgen. Die Pod-Steuerung bestimmt, welcher Container welche Ressourcen wie lange benötigt, um die Arbeitslast abzuschließen und die SLA zu erfüllen. Die Pod-Steuerung verwaltet auch Operationen des Container-Lebenszyklus wie etwa: Erzeugen des Containers, Versehen desselben mit Ressourcen und Anwendungen, Koordinieren von Zwischenergebnissen zwischen mehreren Containern, die auf einer verteilten Anwendung zusammenarbeiten, Zerlegen von Containern, wenn die Arbeitslast abgeschlossen ist, und dergleichen. Zusätzlich dazu kann eine Pod-Steuerung eine Sicherheitsrolle spielen, die eine Zuweisung von Ressourcen verhindert, bis sich der richtige Mandant authentifiziert, oder eine Bereitstellung von Daten oder einer Arbeitslast an einen Container verhindert, bis ein Attestierungsergebnis erfüllt ist.
  • Auch bei der Verwendung von Container-Pods können Mandantengrenzen weiterhin existieren, jedoch im Kontext jedes Pods von Containern. Falls jeder mandantenspezifische Pod eine mandantenspezifische Pod-Steuerung aufweist, wird es eine gemeinsam genutzte Pod-Steuerung geben, die Ressourcenzuweisungsanforderungen konsolidiert, um typische Ressourcenmangelsituationen zu vermeiden. Weitere Steuerungen können vorgesehen sein, um eine Attestierung und Vertrauenswürdigkeit des Pods und der Pod-Steuerung zu gewährleisten. Beispielsweise kann der Orchestrator 460 lokalen Pod-Steuerungen, die eine Attestierungsverifizierung durchführen, eine Attestierungsverifizierungsrichtlinie bereitstellen. Falls eine Attestierung eine Richtlinie für eine erste Mandanten-Pod-Steuerung, aber nicht eine zweite Mandanten-Pod-Steuerung erfüllt, dann könnte der zweite Pod zu einem anderen Edge-Knoten migriert werden, der sie erfüllt. Alternativ dazu kann die Ausführung des ersten Pods erlaubt werden, und eine andere gemeinsam genutzte Pod-Steuerung wird installiert und aufgerufen, bevor der zweite Pod ausgeführt wird.
  • 5 veranschaulicht zusätzliche Rechenanordnungen, die Container in einem Edge-Computing-System einsetzen. Als vereinfachtes Beispiel stellen die Systemanordnungen 510, 520 Einstellungen dar, bei denen eine Pod-Steuerung (z. B. Containermanager 511, 521 und Containerorchestrator 531) dazu ausgelegt ist, containerisierte Pods, Funktionen, und Functions-as-a-Service-Instanzen durch Ausführung über Rechenknoten (515 in Anordnung 510) oder separat containerisierte virtualisierte Netzwerkfunktionen durch Ausführung über Rechenknoten (523 in Anordnung 520) auszuführen. Diese Anordnung ist zur Verwendung mehrerer Mandanten in der Systemanordnung 530 (unter Verwendung des Rechenknotens 537) eingerichtet, wobei containerisierte Pods (z. B. Pods 512), Funktionen (z. B. Funktionen 513, VNFs 522, 536) und Functions-as-a-Service-Instanzen (z. B. FaaS-Instanz 514) innerhalb virtueller Maschinen (z. B. VMs 534, 535 für Mandanten 532, 533) gestartet werden, die für jeweilige Mandanten spezifisch sind (abgesehen von der Ausführung virtualisierter Netzwerkfunktionen). Diese Anordnung ist ferner zur Verwendung in der Systemanordnung 540 eingerichtet, die Container 542, 543 oder die Ausführung der verschiedenen Funktionen, Anwendungen und Funktionen auf den Rechenknoten 544 bereitstellt, wie durch ein containerbasiertes Orchestrierungssystem 541 koordiniert.
  • Die in 5 dargestellten Systemanordnungen stellen eine Architektur bereit, die VMs, Container und Funktionen hinsichtlich der Anwendungszusammensetzung gleich behandelt (und resultierende Anwendungen sind Kombinationen dieser drei Bestandteile). Jeder Bestandteil kann die Verwendung einer oder mehrerer Beschleunigerkomponenten (FPGA, ASIC) als ein lokales Backend beinhalten. Auf diese Weise können Anwendungen über mehrere Edge-Eigentümer aufgeteilt werden, die durch einen Orchestrator koordiniert werden.
  • Im Zusammenhang mit 5 können die Pod-Steuerung/der Containermanager, der Containerorchestrator und die einzelnen Knoten einen Punkt zur Durchsetzung der Sicherheit bereitstellen. Die Mandantenisolierung kann jedoch orchestriert werden, wo sich die einem Mandanten zugewiesenen Ressourcen von den einem zweiten Mandanten zugewiesenen Ressourcen unterscheiden, aber Edge-Eigentümer kooperieren, um sicherzustellen, dass die Ressourcenzuweisungen nicht über Mandantengrenzen hinweg geteilt werden. Oder Ressourcenzuweisungen könnten über Mandantengrenzen hinweg isoliert werden, da Mandanten eine „Verwendung“ über eine Subskriptions- oder Transaktions-/Vertragsbasis ermöglichen könnten. In diesen Zusammenhängen können Virtualisierungs-, Containerisierungs-, Enklaven- und Hardwarepartitionierungsschemata von Edge-Eigentümern verwendet werden, um die Mandanten zu vollziehen. Andere Isolationsumgebungen können beinhalten: (dedizierte) Bare-Metal-Ausrüstung, virtuelle Maschinen, Container, virtuelle Maschinen auf Containern oder Kombinationen davon.
  • In weiteren Beispielen können Aspekte von softwaredefinierter oder gesteuerter Siliciumhardware und anderer konfigurierbarer Hardware mit den Anwendungen, Funktionen und Diensten eines Edge-Computing-Systems integrieren. Softwaredefiniertes Silicium (SDSi) kann verwendet werden, um die Fähigkeit sicherzustellen, dass ein Ressourcen- oder Hardwarebestandteil einen Vertrag oder eine Dienstleistungsvereinbarung erfüllt, basierend auf der Fähigkeit des Bestandteils, einen Teil von sich selbst oder die Arbeitslast zu korrigieren (z. B. durch eine Aktualisierung, Neukonfiguration oder Bereitstellung neuer Merkmale innerhalb der Hardwarekonfiguration selbst).
  • In weiteren Beispielen können beliebige der Rechenknoten oder Vorrichtungen, die unter Bezugnahme auf die vorliegenden Edge-Computing-Systeme und die vorliegende Umgebung erörtert wurden, basierend auf den in 6A und 6B dargestellten Komponenten erfüllt werden. Jeweilige Edge-Rechenknoten können als ein Typ von Vorrichtung, Gerät, Computer oder anderem „Ding“ umgesetzt sein, die in der Lage sind, mit anderen Edge-, Netzwerk- oder Endpunktkomponenten zu kommunizieren. Zum Beispiel kann eine Edge-Rechenvorrichtung als ein Personal Computer, Server, Smartphone, eine mobile Rechenvorrichtung, ein Smart-Gerät, ein fahrzeuginternes Rechensystem (z. B. ein Navigationssystem), eine eigenständige Vorrichtung mit einem Außengehäuse, einer Ummantelung usw. oder eine andere Vorrichtung oder ein anderes System, die/das in der Lage ist, die beschriebenen Funktionen durchzuführen, umgesetzt sein.
  • In dem in 6A dargestellten vereinfachten Beispiel beinhaltet ein Edge-Rechenknoten 600 eine Rechen-Engine (hier auch als „Rechenschaltungsanordnung“ bezeichnet) 602, ein Eingabe/Ausgabe-(E/A-) Subsystem (hier auch als „E/A-Schaltungsanordnung“ bezeichnet) 608, eine Datenspeicherung (hier auch als „Datenspeicherungsschaltungsanordnung“ bezeichnet) 610, ein Kommunikationsschaltungsanordnungs-Subsystem 612 und optional eine oder mehrere Peripherievorrichtungen (hier auch als „Peripherievorrichtungsschaltungsanordnung“ bezeichnet) 614. In anderen Beispielen können jeweilige Rechenvorrichtungen andere oder zusätzliche Komponenten umfassen, wie diejenigen, die üblicherweise in einem Computer zu finden sind (z.B. eine Anzeige, periphere Einrichtungen usw.). Zusätzlich können in manchen Beispielen eine oder mehrere der veranschaulichenden Komponenten in eine andere Komponente integriert sein oder anderswie einen Teil davon bilden.
  • Der Rechenknoten 600 kann als eine beliebige Art von Engine, Vorrichtung oder Sammlung von Vorrichtungen ausgebildet sein, die in der Lage sind, verschiedene Rechenfunktionen durchzuführen. In manchen Beispielen kann der Rechenknoten 600 als eine einzelne Vorrichtung umgesetzt sein, wie etwa eine integrierte Schaltung, ein eingebettetes System, ein feldprogrammierbares Gate-Array (FPGA), ein System-on-a-Chip (SOC) oder ein anderes integriertes System oder eine andere integrierte Vorrichtung. Im veranschaulichenden Beispiel beinhaltet der Rechenknoten 600 einen Prozessor (hier auch als „Prozessorschaltungsanordnung“ bezeichnet) 604 und einen Speicher (hier auch als „Speicherschaltungsanordnung“ bezeichnet) 606 oder ist als diese ausgeführt. Der Prozessor 604 kann als beliebige Art von Prozessor(en) umgesetzt sein, der/die in der Lage ist/sind, die hierin beschriebenen Funktionen (z. B. Ausführen einer Anwendung) durchzuführen. Der Prozessor 604 kann zum Beispiel als ein oder mehrere Mehrkernprozessoren, ein Mikrocontroller, eine Verarbeitungseinheit, eine Spezial- oder Sonderverarbeitungseinheit oder ein anderer Prozessor oder eine andere Verarbeitungs-/Steuerschaltung umgesetzt sein.
  • In manchen Beispielen kann der Prozessor 604 als FPGA, anwendungsspezifische integrierte Schaltung (ASIC), rekonfigurierbare Hardware oder Hardwareschaltungsanordnung oder andere spezialisierte Hardware umgesetzt sein, diese beinhalten oder mit diesen gekoppelt sein, um eine Leistungsfähigkeit der hierin beschriebenen Funktionen zu ermöglichen. In manchen Beispielen kann der Prozessor 604 auch als spezialisierte x-Verarbeitungseinheit (x-PU) umgesetzt sein, die auch als Datenverarbeitungseinheit (DPU), Infrastrukturverarbeitungseinheit (IPU) oder eine Netzwerkverarbeitungseinheit (NPU) bekannt ist. Eine solche x-PU kann als eine eigenständige Schaltung oder ein eigenständiges Schaltungspaket umgesetzt sein, innerhalb eines SOC integriert sein oder mit einer Vernetzungsschaltungsanordnung (z. B. in einer SmartNIC oder erweiterten SmartNIC), einer Beschleunigungsschaltungsanordnung, Speichervorrichtungen, Speicherplatten oder KI-Hardware (z. B. GPUs oder programmierte FPGAs) integriert sein. Eine solche x-PU kann dazu ausgelegt sein, eine Programmierung zu empfangen, abzurufen und/oder anderweitig zu erhalten, um einen oder mehrere Datenströme zu verarbeiten und spezifische Aufgaben und Aktionen für die Datenströme durchzuführen (wie etwa das Hosten von Mikrodiensten, Durchführen einer Dienstverwaltung oder Orchestrierung, Organisieren oder Verwalten von Server- oder Datenzentrums-Hardware, Verwalten von Dienstnetzen oder Sammeln und Verteilen von Telemetrie) außerhalb der CPU oder Universalverarbeitungshardware. Es versteht sich jedoch, dass eine x-PU, ein SOC, eine CPU und andere Variationen des Prozessors 604 koordiniert miteinander arbeiten können, um viele Arten von Operationen und Anweisungen innerhalb des Rechenknotens 600 und für diesen auszuführen.
  • Der Speicher 606 kann als eine beliebige Art flüchtiger (z. B. dynamischer Direktzugriffsspeicher (DRAM) usw.) oder nichtflüchtiger Speicher oder Datenspeicher umgesetzt sein, der in der Lage ist, die hier beschriebenen Funktionen durchzuführen. Flüchtiger Speicher kann ein Speicherungsmedium sein, das Leistung benötigt, um den Zustand von durch das Medium gespeicherten Daten aufrechtzuerhalten. Nichteinschränkende Beispiele für flüchtigen Speicher können verschiedene Arten von Direktzugriffsspeicher (RAM) wie DRAM oder statischen Direktzugriffsspeicher (SRAM) beinhalten. Eine bestimmte Art von DRAM, die in einem Speichermodul verwendet werden kann, ist ein synchroner dynamischer Direktzugriffsspeicher (SDRAM: Synchronous Dynamic Random Access Memory).
  • In einem Beispiel ist die Speichervorrichtung (z. B. Speicherschaltungsanordnung) eine beliebige Anzahl von blockadressierbaren Speichervorrichtungen, wie etwa jene, die auf NAND- oder NOR-Technologien basieren (zum Beispiel Single-Level-Cell („SLC“), Multi-Level-Cell („MLC“), Quad-Level-Cell („QLC“), Tri-Level-Cell („TLC“) oder irgendein anderes NAND). In manchen Beispielen beinhaltet/beinhalten der/die Speichervorrichtung(en) eine byteadressierbaren dreidimensionale Kreuzungspunktspeichervorrichtung mit ortsfestem Schreiben oder andere byteadressierbare nichtflüchtige Speichervorrichtungen (NVM) wie etwa Ein- oder Mehrebenen-Phasenwechselspeicher (PCM) oder Phasenwechselspeicher mit einem Schalter (PCMS), NVM-Vorrichtungen, die ein Chalkogenid-Phasenwechselmaterial (zum Beispiel Chalkogenidglas) verwenden, resistiven Speicher mit Metalloxidbasis, Sauerstoffleerstelle-Basis und Conductive Bridge Random Access Memory (CB-RAM), Nanodrahtspeicher, Direktzugriffsspeicher mit ferroelektrischem Transistor (FeTRAM), magnetoresistiven Direktzugriffsspeicher (MRAM), der Memristortechnologie beinhaltet, Spintransferdrehmoment (STT)-MRAM, eine Spintronik-Magnetübergangsspeicher-basierte Vorrichtung, eine MTJ-basierte (MTJ: Magnetic Tunnel Junction) Vorrichtung, eine DW (Domain Wall)- und SOT (Spin Orbit Transfer)-basierte Vorrichtung, eine Speichervorrichtung auf Thyristorbasis, eine Kombination beliebiger der Obigen oder einen anderen geeigneten Speicher. Eine Speichervorrichtung kann auch eine dreidimensionale Kreuzungspunktspeichervorrichtung (z. B. Intel@-3 D XPointTM-Speicher) oder andere byteadressierbare nichtflüchtige Speichervorrichtungen zum Schreiben an Ort und Stelle beinhalten. Die Speichervorrichtung kann sich auf den Rohchip selbst und/oder auf ein gehäustes Speicherprodukt beziehen. In manchen Beispielen kann der 3D-Kreuzungspunktspeicher (z. B. Speicher Intel® 3D XPoint™) eine transistorlose stapelbare Kreuzungspunktarchitektur beinhalten, bei der Speicherzellen am Schnittpunkt von Wortleitungen und Bitleitungen sitzen und einzeln adressierbar sind und bei der die Bitspeicherung auf einer Änderung des Volumenwiderstands basiert. In manchen Beispielen kann der gesamte oder ein Teil des Speichers 606 in den Prozessor 604 integriert sein. Der Speicher 606 kann verschiedene Software und Daten speichern, die während des Betriebs verwendet werden, wie etwa eine oder mehrere Anwendungen, Daten, die durch die Anwendung(en) bearbeitet werden, Bibliotheken und Treiber.
  • In manchen Beispielen beinhalten widerstandsbasierte und/oder transistorlose Speicherarchitekturen Phasenwechselspeichervorrichtungen (PCM: Phase Change Memory) im Nanometermaßstab, in denen sich ein Volumen an Phasenwechselmaterial zwischen mindestens zwei Elektroden befindet. Teile des beispielhaften Phasenwechselmaterials zeigen variierende Grade an kristallinen Phasen und amorphen Phasen auf, wobei variierende Grade an Widerstand zwischen den wenigstens zwei Elektroden gemessen werden können. In manchen Beispielen ist das Phasenwechselmaterial ein Glas auf Chalkogenidbasis. Solche resistiven Speichervorrichtungen werden manchmal als memristive Vorrichtungen bezeichnet, die sich an die Historie des Stroms erinnern, der zuvor durch sie geflossen ist. Gespeicherte Daten werden von beispielhaften PCM-Vorrichtungen abgerufen, indem der elektrische Widerstand gemessen wird, wobei die kristallinen Phasen einen oder mehrere relativ niedrigere Widerstandswerte (z. B. logisch „0“) im Vergleich zu den amorphen Phasen mit einem oder mehreren relativ höheren Widerstandswerten (z. B. logisch „1“) aufweisen.
  • Beispielhafte PCM-Vorrichtungen speichern Daten über lange Zeiträume (z. B. etwa 10 Jahre bei Raumtemperatur). Schreiboperationen zu beispielhaften PCM-Vorrichtungen (z. B. Setzen auf logisch „0“, Setzen auf logisch „1“, Setzen auf einen Zwischenwiderstandswert) werden durch Anlegen eines oder mehrerer Strompulse an die mindestens zwei Elektroden erreicht, wobei die Impulse eine bestimmte Stromstärke und dauer aufweisen. Beispielsweise bewirkt ein langer Niedrigstromimpuls (SET), der an die wenigstens zwei Elektroden angelegt wird, dass sich die beispielhafte PCM-Vorrichtung in einem kristallinen Zustand mit niedrigem Widerstand befindet, während ein vergleichsweise kurzer Hochstromimpuls (RESET), der an die mindestens zwei Elektroden angelegt wird, bewirkt, dass sich die beispielhafte PCM-Vorrichtung in einem amorphen Zustand mit hohem Widerstand befindet.
  • In manchen Beispielen ermöglicht die Implementierung von PCM-Vorrichtungen Nicht-von-Neumann-Rechenarchitekturen, die In-Memory-Rechenfähigkeiten ermöglichen. Allgemein gesprochen beinhalten traditionelle Rechenarchitekturen eine Zentralverarbeitungseinheit (CPU), die über einen Bus kommunikativ mit einer oder mehreren Speichervorrichtungen verbunden ist. Von daher wird eine endliche Energiemenge und Zeit verbraucht, um Daten zwischen der CPU und dem Speicher zu übertragen, was ein bekannter Engpass von von-Neumann-Rechenarchitekturen ist. PCM-Vorrichtungen minimieren und eliminieren jedoch in manchen Fällen Datentransfers zwischen der CPU und dem Speicher, indem manche Rechenoperationen innerhalb des Speichers durchgeführt werden. Anders ausgedrückt, speichern PCM-Vorrichtungen nicht nur Informationen, sondern führen auch Rechenaufgaben aus. Solche Nicht-von-Neumann-Rechenarchitekturen können Vektoren mit einer relativ hohen Dimensionalität implementieren, um hyperdimensionales Rechnen zu erleichtern, wie etwa Vektoren mit 10.000 Bits. Vektoren mit relativ großer Bitbreite ermöglichen die Computing-Paradigmen, die nach dem menschlichen Gehirn modelliert sind, das ebenfalls Informationen analog zu breiten Bitvektoren verarbeitet.
  • Die Rechenschaltungsanordnung 602 ist kommunikativ mit anderen Komponenten des Rechenknotens 600 über das E/A-Untersystem 608 gekoppelt, das als eine Schaltungsanordnung und/oder Komponenten umgesetzt sein kann, um Eingabe/Ausgabe-Operationen mit der Rechenschaltungsanordnung 602 (z. B. mit dem Prozessor 604 und/oder dem Hauptspeicher 606) und anderen Komponenten der Rechenschaltungsanordnung 602 zu ermöglichen. Das E/A-Subsystem 608 kann zum Beispiel als Speichersteuerungs-Hubs, Eingabe/Ausgabe-Steuerungs-Hubs, integrierte Sensor-Hubs, Firmwarevorrichtungen, Kommunikationsverbindungen (z. B. Punkt-zu-Punkt-Verbindungen, Busverbindungen, Drähte, Kabel, Lichtleiter, Leiterbahnen von Leiterplatten usw.) und/oder andere Komponenten und Subsysteme umgesetzt sein oder diese anderweitig beinhalten, um die Eingabe/Ausgabe-Operationen zu erleichtern. In manchen Beispielen kann das E/A-Subsystem 608 einen Teil eines System-on-a-Chip (SoC) bilden und zusammen mit dem Prozessor 604 und/oder dem Speicher 606 und/oder anderen Komponenten der Rechenschaltungsanordnung 602 in die Rechenschaltungsanordnung 602 integriert sein.
  • Die eine oder mehreren veranschaulichenden Datenspeicherungsvorrichtungen/Datenspeicherungsplatten 610 können als ein oder mehrere beliebige Arten von physischen Vorrichtungen ausgebildet sein, die zur kurzfristigen oder langfristigen Speicherung von Daten konfiguriert sind, wie zum Beispiel Speichervorrichtungen, Speicher, Schaltungsanordnungen, Speicherkarten, Flashspeicher, Festplattenlaufwerke, Festkörperlaufwerke (SSDs) und/oder andere Datenspeicherungsvorrichtungen/-platten. Individuelle Datenspeicherungsvorrichtungen/-platten 610 können eine Systempartition beinhalten, die Daten und Firmwarecode für die Datenspeicherungsvorrichtung/-platte 610 speichert. Einzelne Datenspeicherungsvorrichtungen/-platten 610 können auch eine oder mehrere Betriebssystempartitionierungen beinhalten, die Datendateien und ausführbare Dateien für Betriebssysteme in Abhängigkeit von zum Beispiel der Art des Rechenknotens 600 speichern.
  • Die Kommunikationsschaltungsanordnung 612 kann als eine beliebige Kommunikationsschaltung, -vorrichtung oder -sammlung davon umgesetzt sein, die in der Lage ist, Kommunikationen über ein Netzwerk zwischen der Rechenschaltungsanordnung 602 und einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway eines implementierenden Edge-Computing-Systems) zu ermöglichen. Die Kommunikationsschaltungsanordnung 612 kann dazu konfiguriert sein, eine oder mehrere beliebige Kommunikationstechnologien (z. B. drahtgebundene oder drahtlose Kommunikationen) und assoziierte Protokolle (z. B. ein zellulares Netwerkprotokoll wie etwa einen 3GPP-, 4G- oder 5G-Standard, ein drahtloses lokales Netzwerkprotokoll wie etwa IEEE 802.11/Wi-Fi®, ein drahtloses Weitverkehrsnetzwerkprotokoll, Ethernet, Bluetooth®, Bluetooth Low Energy, ein IoT-Protokoll wie etwa IEEE 802.15.4 oder ZigBee®, LPWAN(Low-Power Wide Area Network)- oder LPWA(Low-Power Wide Area)-Protokolle usw.) zu verwenden, um eine solche Kommunikation zu bewirken.
  • Die veranschaulichende Kommunikationsschaltungsanordnung 612 beinhaltet eine Netzwerkschnittstellensteuerung (NIC) 620, die auch als eine Host-Fabric-Schnittstelle (HFI: Host Fabric Interface) bezeichnet werden kann. Die NIC 620 kann als eine oder mehrere Zusatzplatinen, Tochterkarten, Netzwerkschnittstellenkarten, Steuerungschips, Chipsätze oder andere Vorrichtungen umgesetzt sein, die durch den Rechenknoten 600 verwendet werden können, um sich mit einer anderen Rechenvorrichtung (z. B. einem Edge-Gateway-Knoten) zu verbinden. In manchen Beispielen kann die NIC 620 als Teil eines System-on-Chip (SoC) umgesetzt sein, das einen oder mehrere Prozessoren beinhaltet, oder kann auf einem Mehrchip-Paket enthalten sein, das auch einen oder mehrere Prozessoren beinhaltet. In manchen Beispielen kann die NIC 620 einen lokalen Prozessor (nicht gezeigt) und/oder einen lokalen Speicher (nicht gezeigt) beinhalten, die beide lokal zur NIC 620 sind. In solchen Beispielen kann der lokale Prozessor der NIC 620 dazu in der Lage sein, eine oder mehrere der Funktionen der hierin beschriebenen Rechenschaltungsanordnung 602 durchzuführen. Zusätzlich oder alternativ dazu kann in solchen Beispielen der lokale Speicher der NIC 620 in eine oder mehrere Komponenten des Client-Rechenknotens auf Platinenebene, Sockelebene, Chipebene und/oder anderen Ebenen integriert sein.
  • Zusätzlich kann in manchen Beispielen ein jeweiliger Rechenknoten 600 eine oder mehrere Peripherievorrichtungen 614 beinhalten. Solche Peripherievorrichtungen 614 können eine beliebige Art von Peripherievorrichtung beinhalten, die in Abhängigkeit von der speziellen Art des Rechenknotens 600 in einer Rechenvorrichtung oder einem Server zu finden ist, wie etwa Audioeingabevorrichtungen, eine Anzeige, andere Eingabe-/Ausgabevorrichtungen, Schnittstellenvorrichtungen und/oder andere Peripherievorrichtungen. In weiteren Beispielen kann der Rechenknoten 600 durch einen jeweiligen Edge-Rechenknoten (ob ein Client, Gateway oder Aggregationsknoten) in einem Edge-Computing-System oder ähnlichen Formen von Geräten, Computern, Subsystemen, Schaltungen oder anderen Komponenten umgesetzt sein.
  • In einem ausführlicheren Beispiel veranschaulicht 6B ein Blockdiagramm eines Beispiels für Komponenten, die in einem Edge-Computing-Knoten 650 zum Implementieren der hierin beschriebenen Techniken (z. B. Operationen, Prozesse, Verfahren und Methodologien) vorhanden sein können. Dieser Edge-Computing-Knoten 650 stellt eine nähere Ansicht der jeweiligen Komponenten des Knotens 600 bereit, wenn er als oder als Teil einer Rechenvorrichtung (z. B. als eine mobile Vorrichtung, eine Basisstation, ein Server, ein Gateway usw.) implementiert wird. Der Edge-Computing-Knoten 650 kann eine beliebige Kombination der hierin referenzierten Hardware oder logischen Komponenten beinhalten, und er kann eine beliebige Vorrichtung, die mit einem Edge-Kommunikationsnetzwerk oder einer Kombination solcher Netzwerke verwendbar ist, beinhalten oder mit dieser gekoppelt sein Die Komponenten können als integrierte Schaltungen (ICs), Teile davon, diskrete elektronische Vorrichtungen oder andere Module, Befehlssätze, programmierbare Logik oder Algorithmen, Hardware, Hardwarebeschleuniger, Software, Firmware oder eine Kombination davon, die im Edge-Computing-Knoten 650 angepasst sind, oder als Komponenten, die anderweitig in einem Chassis eines größeren Systems integriert sind, implementiert sein.
  • Die Edge-Computing-Vorrichtung 650 kann eine Verarbeitungsschaltungsanordnung in Form eines Prozessors 652 beinhalten, bei es sich um einen Mikroprozessor, einen Mehrkernprozessor, einen Multithreadprozessor, einen Ultraniederspannungsprozessor, einen eingebetteten Prozessor, eine x-PU/DPU/IPU/NPU, eine Spezialverarbeitungseinheit, eine spezialisierte Verarbeitungseinheit oder andere bekannte Verarbeitungselemente handeln kann. Der Prozessor 652 kann Teil eines System-on-Chip (SoC) sein, bei dem der Prozessor 652 und andere Komponenten zu einer einzigen integrierten Schaltung oder einem einzigen Package ausgebildet sind, wie etwa die Edison™- oder Galileo™-SoC-Platinen der Intel Corporation, Santa Clara, Kalifornien. Als Beispiel kann der Prozessor 652 einen auf Intel® Architecture Core™ basierenden CPU-Prozessor, wie etwa einen Quark™-, einen Atom™-, einen i3-, einen i5-, einen i7-, einen i9-oder einen MCU-Klasse-Prozessor oder einen anderen solchen Prozessor, der von Intel® ist, beinhalten. Es kann jedoch eine beliebige Anzahl anderer Prozessoren verwendet werden, wie etwa erhältlich von Advanced Micro Devices, Inc. (AMD®) aus Sunnyvale, Kalifornien, ein MIPS®-basiertes Design der Firma MIPS Technologies, Inc. aus Sunnyvale, Kalifornien, ein ARM®-basiertes Design, lizenziert von ARM Holdings, Ltd. oder ein Kunde davon oder deren Lizenznehmer oder Anwender. Die Prozessoren können Einheiten beinhalten, wie etwa einen Prozessor A5 bis A13 von Apple® Inc., einen Snapdragon™-Prozessor von QualCommon® Technologies, Inc. oder einen OMAP™-Prozessor von Texas Instruments, Inc. Der Prozessor 652 und die begleitende Schaltungsanordnung können in einem einzigen Sockelformfaktor, mehreren Sockelformfaktoren oder einer Vielfalt anderer Formate bereitgestellt sein, einschließlich in beschränkten Hardwarekonfigurationen oder Konfigurationen, die weniger als alle in 20B gezeigten Elemente beinhalten.
  • Der Prozessor 652 kann über eine Zwischenverbindung 656 (z. B. einen Bus) mit einem Systemspeicher 654 kommunizieren. Es kann eine beliebige Anzahl von Speichervorrichtungen verwendet werden, um eine gegebene Menge an Systemspeicher bereitzustellen. Bei dem Speicher 654 kann es sich beispielsweise um einen Direktzugriffsspeicher (RAM) handeln, der einem Entwurf des Joint Electron Devices Engineering Council (JEDEC) wie den DDR- oder mobilen DDR-Standards (z. B. LPDDR, LPDDR2, LPDDR3 oder LPDDR4) entspricht. In besonderen Beispielen kann eine Speicherkomponente einem von der JEDEC veröffentlichten DRAM-Standard entsprechen, wie etwa JESD79F für DDR-SDRAM, JESD79-2F für DDR2-SDRAM, JESD79-3F für DDR3-SDRAM, JESD79-4A für DDR4-SDRAM, JESD209 für Low Power DDR (LPDDR), JESD209-2 für LPDDR2, JESD209-3 für LPDDR3 und JESD209-4 für LPDDR4. Solche Standards (und ähnliche Standards) können als DDR-basierte Standards bezeichnet werden, und Kommunikationsschnittstellen der Speicherungsvorrichtungen, die solche Standards implementieren, können als DDR-basierte Schnittstellen bezeichnet werden. Bei verschiedenen Implementierungen können die einzelnen Speichervorrichtungen von einer beliebigen Anzahl von verschiedenen Gehäusetypen sein, wie etwa Single-Die-Gehäuse (SDP), Dual-Die-Gehäuse (DDP) oder Quad-Die-Gehäuse (Q17P). Diese Vorrichtungen können in manchen Beispielen direkt auf eine Hauptplatine gelötet werden, um eine Lösung mit niedrigerem Profil bereitzustellen, während die Vorrichtungen in anderen Beispielen als ein oder mehrere Speichermodule konfiguriert sind, die wiederum durch einen gegebenen Verbinder mit der Hauptplatine gekoppelt sind. Es kann eine beliebige Anzahl anderer Speicherimplementierungen verwendet werden, wie etwa andere Typen von Speichermodulen, z. B. Dual-Inline-Speichermodule (DIMMs) unterschiedlicher Sorten, einschließlich unter anderem MicroDIMMs oder MiniDIMMs.
  • Um eine dauerhafte Speicherung von Informationen wie etwa Daten, Anwendungen, Betriebssystemen und so weiter bereitzustellen, kann eine Speicherung 658 auch über die Zwischenverbindung 656 mit dem Prozessor 652 gekoppelt sein. In einem Beispiel kann die Speicherung 658 über ein Solid-State-Laufwerk (SSDD) implementiert sein. Andere Vorrichtungen, die für die Speicherung 658 verwendet werden können, beinhalten Flash-Speicherkarten, wie etwa Secure Digital (SD)-Karten, microSD-Karten, extreme Digital (XD)-Bildkarten und dergleichen und Universal Serial Bus (USB)-Flash-Laufwerke. In einem Beispiel kann es sich bei der Speichervorrichtung um Speichervorrichtungen, die Chalkogenidglas verwenden, NAND-Flash-Speicher mit mehreren Schwellenpegeln, NOR-Flash-Speicher, Phasenwechselspeicher mit einzelnen oder mehreren Pegeln (PCM), einen resistiven Speicher, Nanodrahtspeicher, Direktzugriffsspeicher mit ferroelektrischem Transistor (FeTRAM), antiferroelektrischen Speicher, Speicher mit magnetoresistivem Direktzugriffsspeicher (MRAM), der Memristortechnologie beinhaltet, resistiven Speicher mit Metalloxidbasis, Sauerstoffleerstellen-Basis und und Conductive Bridge Random Access Memory (CB-RAM) oder Spintransferdrehmoment (STT)-MRAM, eine Spintronik-Magnetübergangsspeicher-basierte Vorrichtung, eine MTJ-basierte (MTJ: Magnetic Tunnel Junction) Vorrichtung, eine DW (Domain Wall)- und SOT (Spin Orbit Transfer)-basierte Vorrichtung, eine Speichervorrichtung auf Thyristorbasis, eine Kombination beliebiger der Obigen oder einen anderen geeigneten Speicher handeln oder diese kann solche beinhalten.
  • Bei Niedrigleistungsimplementierungen kann die Speicherung 658 ein On-Die-Speicher oder Register sein, die mit dem Prozessor 652 assoziiert sind. In manchen Beispielen kann die Speicherung 658 jedoch unter Verwendung eines Mikrofestplattenlaufwerks (HDD) implementiert sein. Ferner kann eine beliebige Anzahl neuer Technologien für die Speicherung 658 zusätzlich zu oder anstelle der beschriebenen Technologien verwendet werden, wie etwa unter anderem Widerstandswechselspeicher, Phasenwechselspeicher, holografische Speicher oder chemische Speicher.
  • Die Komponenten können über die Zwischenverbindung 656 kommunizieren. Die Zwischenverbindung 656 kann eine beliebige Anzahl von Technologien beinhalten, einschließlich Industriestandardarchitektur (ISA), erweiterte ISA (EISA), Peripheral Component Interconnect (PCI), Peripheral Component Interconnect extended (PCIx), PCI express (PCIe) oder eine beliebige Anzahl anderer Technologien. Die Zwischenverbindung 656 kann ein proprietärer Bus sein, der zum Beispiel in einem SoC-basierten System verwendet wird. Andere Bussysteme können enthalten sein, wie etwa unter anderem eine Inter-Integrated Circuit (I2C)-Schnittstelle, eine Serial Peripheral Interface (SPI)-Schnittstelle, Punkt-zu-Punkt-Schnittstellen und ein Leistungsbus.
  • Die Zwischenverbindung 656 kann den Prozessor 652 mit einem Sendeempfänger 666 zur Kommunikation mit den verbundenen Edge-Vorrichtungen 662 koppeln. Der Sendeempfänger 666 kann eine beliebige Anzahl von Frequenzen und Protokollen verwenden, wie etwa 2,4-Gigahertz (GHz)-Übertragungen nach dem IEEE 802.15.4-Standard, unter Verwendung des Bluetooth®-Low-Energy (BLE)-Standards, wie unter anderem von der Bluetooth® Special Interest Group definiert, oder des ZigBee®-Standards. Für die Verbindungen zu den angeschlossenen Edge-Vorrichtungen 662 kann eine beliebige Anzahl von Funkgeräten, die für ein bestimmtes Drahtloskommunikationsprotokoll konfiguriert sind, verwendet werden. Zum Beispiel kann eine WLAN (Wireless Local Area Network)-Einheit verwendet werden, um Wi-Fi®-Kommunikationen gemäß dem Standard IEEE (Institute of Electrical and Electronics Engineers) 802.11 zu implementieren. Außerdem können Drahtlos-Weitbereichskommunikationen, z. B. gemäß einem zellularen oder anderen Drahtlos-Weitbereichsprotokoll über eine drahtlose Weitbereichsnetzwerk (WWAN)-Einheit stattfinden.
  • Der Drahtlosnetzwerk-Sendeempfänger 666 (oder mehrere Sendeempfänger) kann unter Verwendung mehrerer Standards oder Funkgeräte für Kommunikationen in einer anderen Reichweite kommunizieren. Zum Beispiel kann der Edge-Computing-Knoten 650 mit nahen Vorrichtungen, z. B. innerhalb von etwa 10 Metern unter Verwendung eines lokalen Sendeempfängers basierend auf Bluetooth Low Energy (BLE) oder einem anderen Niedrigleistungsfunkgerät kommunizieren, um Leistung zu sparen. Entferntere verbundene Edge-Vorrichtungen 662, z. B. innerhalb von etwa 50 Metern, können über ZigBee® oder andere Mittelleistungsfunkgeräte erreicht werden. Beide Kommunikationstechniken können über ein einziges Funkgerät mit unterschiedlichen Leistungspegeln stattfinden oder können über separate Sendeempfänger stattfinden, zum Beispiel einen lokalen Sendeempfänger, der BLE verwendet, und einen separaten Mesh-Sendeempfänger, der ZigBee® verwendet.
  • Ein Drahtlosnetzwerk-Sendeempfänger 666 (z. B. ein Funksendeempfänger) kann enthalten sein, um mit Vorrichtungen oder Diensten in einer Cloud (z. B. einer Edge-Cloud 695) über Lokal- oder Weitverkehrsnetzwerkprotokolle zu kommunizieren. Der Drahtlosnetzwerk-Sendeempfänger 666 kann ein LPWA-Sendeempfänger (LPWA: Low Power Wide Area) sein, der unter anderem den Standards IEEE 802.15.4 oder IEEE 802.15.4g folgt. Der Edge-Computing-Knoten 650 kann über einen weiten Bereich unter Verwendung von LoRaWAN™ (Long Range Wide Area Network) kommunizieren, das von Semtech und der LoRa Alliance entwickelt wurde. Die hierin beschriebenen Techniken sind nicht auf diese Technologien beschränkt, sondern können mit einer beliebigen Anzahl anderer Cloud-Sendeempfänger verwendet werden, die Kommunikationen mit großer Reichweite und niedriger Bandbreite implementieren, wie etwa Sigfox und andere Technologien. Ferner können andere Kommunikationstechniken, wie etwa Kanalspringen mit Zeitschlitzen, das in der IEEE 802.15.4e-Spezifikation beschrieben ist, verwendet werden.
  • Zusätzlich zu den für den Drahtlosnetzwerksendeempfänger 666 erwähnten Systemen kann eine beliebige Anzahl anderer Funkkommunikationen und Protokolle verwendet werden, wie hierin beschrieben. Zum Beispiel kann der Sendeempfänger 666 einen zellularen Sendeempfänger beinhalten, der Spreizspektrum (SPA/SAS)-Kommunikationen zum Implementieren von Hochgeschwindigkeitskommunikationen verwendet. Ferner kann eine beliebige Anzahl anderer Protokolle verwendet werden, wie etwa Wi-Fi®-Netzwerke für Kommunikationen mittlerer Geschwindigkeit und Bereitstellung von Netzwerkkommunikationen. Der Sendeempfänger 666 kann Funkgeräte beinhalten, die mit einer beliebigen Anzahl von 3GPP-Spezifikationen (3GPP: Third Generation Partnership Project) kompatibel sind, wie etwa Long Term Evolution (LTE)- und Kommunikationssysteme der fünften Generation (5G), die am Ende der vorliegenden Offenbarung ausführlicher besprochen werden. Eine Netzwerkschnittstellensteuerung (NIC) 668 kann enthalten sein, um eine drahtgebundene Kommunikation zu Knoten der Edge-Cloud 695 oder zu anderen Vorrichtungen wie etwa den verbundenen Edge-Vorrichtungen 662 (die z. B. in einem Netz arbeiten) bereitzustellen. Die drahtgebundene Kommunikation kann eine Ethernet-Verbindung bereitstellen oder kann auf anderen Arten von Netzwerken basieren, wie etwa Controller Area Network (CAN), Local Interconnect Network (LIN), DeviceNet, ControlNet, Data Highway+, PROFIBUS oder PROFINET unter vielen anderen. Eine zusätzliche NIC 668 kann enthalten sein, um das Verbinden mit einem zweiten Netzwerk zu ermöglichen, wobei zum Beispiel eine erste NIC 668 Kommunikationen mit der Cloud über Ethernet bereitstellt und eine zweite NIC 668 Kommunikationen mit anderen Vorrichtungen über einen anderen Typ von Netzwerk bereitstellt.
  • Angesichts der Vielfalt von Typen anwendbarer Kommunikationen von der Vorrichtung zu einer anderen Komponente oder einem anderen Netzwerk kann eine anwendbare Kommunikationsschaltungsanordnung, die von der Vorrichtung verwendet wird, eine oder mehrere beliebige der Komponenten 664, 666, 668 oder 670 beinhalten oder durch diese umgesetzt sein. Dementsprechend können in verschiedenen Beispielen anwendbare Mittel zum Kommunizieren (z. B. Empfangen, Senden usw.) durch eine solche Kommunikationsschaltungsanordnung umgesetzt sein.
  • Der Edge-Computing-Knoten 650 kann eine Beschleunigungsschaltungsanordnung 664 beinhalten oder mit dieser gekoppelt sein, die durch einen oder mehrere Beschleuniger für künstliche Intelligenz (KI), einen neuronalen Rechenstick, neuromorphe Hardware, ein FPGA, eine Anordnung von GPUs, eine Anordnung aus x-PUs/DPUs/IPU/NPUs, einem oder mehreren SoCs, einer oder mehreren CPUs, einem oder mehreren Digitalsignalprozessoren, dedizierten ASICs oder anderen Formen spezialisierter Prozessoren oder Schaltungsanordnungen umgesetzt sein kann, die zum Erfüllen einer oder mehrerer spezialisierter Aufgaben ausgelegt sind. Diese Aufgaben können eine KI-Verarbeitung (einschließlich Maschinenlern-, Trainings-, Inferenz- und Klassifizierungsoperationen), visuelle Datenverarbeitung, Netzwerkdatenverarbeitung, Objektdetektion, Regelanalyse oder dergleichen beinhalten. Diese Aufgaben können auch die spezifischen Edge-Computing-Aufgaben für Dienstverwaltung und Dienstoperationen umfassen, die an anderer Stelle in diesem Dokument erörtert werden.
  • Die Zwischenverbindung 656 kann den Prozessor 652 mit einem Sensor-Hub oder einer externen Schnittstelle 670 koppeln, die zum Verbinden zusätzlicher Vorrichtungen oder Subsysteme verwendet wird. Die Vorrichtungen können Sensoren 672, wie etwa Beschleunigungsmesser, Füllstandssensoren, Durchflusssensoren, optische Lichtsensoren, Kamerasensoren, Temperatursensoren, Sensoren eines globalen Navigationssystems (z. B. GPS), Drucksensoren, barometrische Drucksensoren und dergleichen beinhalten. Der Hub oder die Schnittstelle 670 kann ferner verwendet werden, um den Edge-Computing-Knoten 650 mit Aktuatoren 674 wie etwa Leistungsschaltern, Ventilaktuatoren, einem akustischen Tongenerator, einer visuellen Warnvorrichtung und dergleichen zu verbinden.
  • In manchen optionalen Beispielen können verschiedene Eingabe/Ausgabe (E/A)-Vorrichtungen innerhalb des Edge-Computing-Knotens 650 vorhanden oder mit diesem verbunden sein. Beispielsweise kann eine Anzeige oder eine andere Ausgabevorrichtung 684 enthalten sein, um Informationen wie etwa Sensormesswerte oder Aktuatorposition zu zeigen. Eine Eingabevorrichtung 686 wie etwa ein Touchscreen oder eine Tastatur kann enthalten sein, um eine Eingabe anzunehmen. Eine Ausgabevorrichtung 684 kann eine beliebige Anzahl von Formen einer Audio- oder visuellen Anzeige beinhalten, einschließlich einfacher visueller Ausgaben wie etwa binärer Statusindikatoren (z. B. Leuchtdioden (LEDs)) und visueller Mehrzeichenausgaben oder komplexere Ausgaben wie etwa Anzeigebildschirme (z. B. Flüssigkristallanzeige (LCD)-Bildschirme), wobei die Ausgabe von Zeichen, Grafiken, Multimediaobjekten und dergleichen aus dem Betrieb des Edge-Computing-Knotens 650 erzeugt oder erzeugt wird. Eine Anzeige- oder Konsolenhardware kann im Kontext des vorliegenden Systems verwendet werden, um eine Ausgabe und einen Empfang einer Eingabe eines Edge-Computing-Systems bereitzustellen; Komponenten oder Dienste eines Edge-Computing-Systems zu verwalten; einen Zustand einer Edge-Computing-Komponente oder eines Edge-Computing-Dienstes zu identifizieren; oder eine beliebige andere Anzahl von Management- oder Verwaltungsfunktionen oder Dienstnutzungsfällen durchzuführen.
  • Eine Batterie 676 kann den Edge-Computing-Knoten 650 mit Strom versorgen, obwohl er in Beispielen, in denen der Edge-Computing-Knoten 650 an einem festen Ort montiert ist, eine Stromversorgung aufweisen kann, die mit einem Stromnetz gekoppelt ist, oder die Batterie kann als Ausfallsicherheit oder für temporäre Fähigkeiten verwendet werden. Die Batterie 676 kann eine Lithium-Ionen-Batterie oder eine Metall-Luft-Batterie wie etwa eine Zink-Luft-Batterie, eine Aluminium-Luft-Batterie, eine Lithium-Luft-Batterie und dergleichen sein.
  • Eine Batterieüberwachungsvorrichtung/ladevorrichtung 678 kann im Edge-Computing-Knoten 650 enthalten sein, um den Ladezustand (SoCh) der Batterie 676, falls enthalten, zu verfolgen. Die Batterieüberwachungsvorrichtung/ladevorrichtung 678 kann verwendet werden, um andere Parameter der Batterie 676 zu überwachen, um Ausfallvorhersagen wie etwa den Gesundheitszustand (SoH) und den Funktionszustand (SoF) der Batterie 676 bereitzustellen. Die Batterieüberwachungsvorrichtung/-ladevorrichtung 678 kann eine integrierte Batterieüberwachungsschaltung beinhalten, wie etwa einen LTC4020 oder einen LTC2990 von Linear Technologies, einen ADT7488A von ON Semiconductor in Phoenix Arizona oder einen IC der UCD90xxx-Familie von Texas Instruments in Dallas, TX. Die Batterieüberwachungsvorrichtung/ladevorrichtung 678 kann die Informationen über die Batterie 676 über die Zwischenverbindung 656 an den Prozessor 652 kommunizieren. Die Batterieüberwachungsvorrichtung/ladevorrichtung 678 kann auch einen Analog-DigitalWandler (ADC) beinhalten, der es dem Prozessor 652 ermöglicht, die Spannung der Batterie 676 oder den Stromfluss von der Batterie 676 direkt zu überwachen. Die Batterieparameter können verwendet werden, um Handlungen zu bestimmen, die der Edge-Computing-Knoten 650 durchführen kann, wie etwa Übertragungsfrequenz, Mesh-Netzwerkbetrieb, Erfassungsfrequenz und dergleichen.
  • Ein Leistungsblock 680 oder eine andere Leistungsversorgung, die mit einem Stromnetz gekoppelt ist, kann mit der Batterieüberwachungsvorrichtung/ladevorrichtung 678 gekoppelt sein, um die Batterie 676 zu laden. In manchen Beispielen kann der Leistungsblock 680 durch einen Drahtlosleistungsempfänger ersetzt werden, um die Leistung drahtlos, zum Beispiel über eine Schleifenantenne in dem Edge-Computing-Knoten 650, zu erhalten. Eine drahtlose Batterieladeschaltung wie etwa unter anderem ein LTC4020-Chip von Linear Technologies in Milpitas, Kalifornien, kann in der Batterieüberwachungsvorrichtung/- ladevorrichtung 678 enthalten sein. Die spezifischen Ladeschaltungen können basierend auf der Größe der Batterie 676 und somit dem erforderlichen Strom ausgewählt werden. Das Laden kann unter anderem unter Verwendung des von der Airfuel Alliance veröffentlichten Airfuel-Standards, des von dem Wireless Power Consortium veröffentlichten Qi-Drahtlosladestandards oder des von der Alliance für Wireless Power veröffentlichten Rezence-Ladestandards durchgeführt werden.
  • Die Speicherung 658 kann Anweisungen 682 in der Form von Software, Firmware oder Hardwarebefehlen zum Implementieren der hierin beschriebenen Techniken beinhalten. Obwohl solche Anweisungen 682 als Codeblöcke gezeigt sind, die in dem Speicher 654 und der Speicherung 658 enthalten sind, versteht es sich, dass beliebige der Codeblöcke durch festverdrahtete Schaltungen ersetzt werden können, die zum Beispiel in einer anwendungsspezifischen integrierten Schaltung (ASIC: Application Specific Integrated Circuit) eingebaut sind.
  • In einem Beispiel können die Anweisungen 682, die über den Speicher 654, die Speicherung 658 oder den Prozessor 652 bereitgestellt werden, als ein nichtflüchtiges maschinenlesbares Medium 660 umgesetzt sein, das Code beinhaltet, um den Prozessor 652 anzuweisen, elektronische Operationen im Edge-Computing-Knoten 650 durchzuführen. Der Prozessor 652 kann über die Zwischenverbindung 656 auf das nichtflüchtige maschinenlesbare Medium 660 zugreifen. Beispielsweise kann das nicht transitorische maschinenlesbare Medium 660 durch Vorrichtungen ausgebildet sein, die für die Speicherung 658 beschrieben sind, oder kann spezifische Speicherungseinheiten beinhalten, wie etwa Speicherungsvorrichtungen und/oder Speicherungsplatten, die optische Platten (z. B. Digital Versatile Disk (DVD), Compact Disk (CD), CD-ROM, Blu-ray-Disk), Flash-Laufwerke, Disketten, Festplatten (z. B. SSDs) oder eine beliebige Anzahl anderer Hardwarevorrichtungen beinhalten, in denen Informationen für eine beliebige Dauer (z. B. für längere Zeiträume, permanent, kurzzeitig, zum temporären Puffern und/oder Zwischenspeichern) gespeichert sind. Das nichtflüchtige maschinenlesbare Medium 660 kann Anweisungen beinhalten, um den Prozessor 652 anzuweisen, eine bestimmte Abfolge oder einen spezifischen Ablauf von Aktionen durchzuführen, wie zum Beispiel mit Bezug auf das eine oder die mehreren Flussdiagramme und Blockdiagramme von Operationen und Funktionalität, die oben dargestellt sind, beschrieben. Wie hierin verwendet, sind die Begriffe „maschinenlesbares Medium“ und „computerlesbares Medium“ austauschbar. Wie hierin verwendet, ist der Begriff „nichtflüchtiges computerlesbares Medium“ ausdrücklich so definiert, dass er eine beliebige Art von computerlesbarer Speicherungsvorrichtung und/oder Speicherungsplatte beinhaltet und sich ausbreitende Signale ausschließt und Übertragungsmedien ausschließt.
  • Auch können in einem spezifischen Beispiel die Anweisungen 682 auf dem Prozessor 652 (separat oder in Kombination mit den Anweisungen 682 des maschinenlesbaren Mediums 660) die Ausführung oder Operation einer vertrauenswürdigen Ausführungsumgebung (TEE: Trusted Execution Environment) 690 konfigurieren. In einem Beispiel arbeitet die TEE 690 als geschützter Bereich, auf den der Prozessor 652 zur sicheren Ausführung von Anweisungen und zum sicheren Zugriff auf Daten zugreifen kann. Verschiedene Implementierungen der TEE 690 und eines begleitenden sicheren Bereichs in dem Prozessor 652 oder dem Speicher 654 können beispielsweise durch Verwendung von Intel® Software Guard Extensions (SGX) oder ARM® TrustZone® Hardware-Sicherheitserweiterungen, Intel® Management Engine (ME) oder Intel® Converged Security Manageability Engine (CSME) bereitgestellt werden. Andere Aspekte von Sicherheitshärtung, Hardware-Roots-of-Trust und vertrauenswürdigen oder geschützten Operationen können in der Vorrichtung 650 durch die TEE 690 und den Prozessor 652 implementiert werden.
  • Obwohl die veranschaulichten Beispiele für 6A und 6B Beispielkomponenten für einen Rechenknoten bzw. eine Rechenvorrichtung beinhalten, sind die hierin offenbarten Beispiele nicht darauf beschränkt. Wie hierin verwendet, kann ein „Computer“ manche oder alle der Beispielkomponenten der 6A und/oder 6B in verschiedenen Arten von Rechenumgebungen beinhalten. Beispielhafte Rechenumgebungen beinhalten Edge-Computing-Vorrichtungen (z.B. Edge-Computer) in einer verteilten Netzwerkanordnung, so dass bestimmte teilnehmende Edge-Computing-Vorrichtungen heterogene oder homogene Vorrichtungen sind. Wie hierin verwendet, kann ein „Computer“ u. a. ein Personalcomputer, ein Server, ein Benutzergerät, ein Beschleuniger usw. sein, einschließlich beliebiger Kombinationen davon. In manchen Beispielen beinhaltet verteilte Vernetzung und/oder verteiltes Rechnen eine beliebige Anzahl solcher Edge-Computing-Vorrichtungen, wie in 6A und/oder 6B veranschaulicht ist, die jeweils unterschiedliche Subkomponenten, unterschiedliche Speicherkapazitäten, E/A-Fähigkeiten usw. beinhalten können. Da zum Beispiel manche Implementierungen von verteilter Vernetzung und/oder verteiltem Rechnen mit der bestimmten gewünschten Funktionalität assoziiert sind, beinhalten hier offenbarte Beispiele unterschiedliche Kombinationen von Komponenten, die in 6A und/oder 6B veranschaulicht sind, um Funktionsziele verteilter Rechenaufgaben zu erfüllen. In manchen Beispielen beinhaltet der Begriff „Rechenknoten“ oder „Computer“ nur den beispielhaften Prozessor 604, den Speicher 606 und das E/A-Subsystem 608 von 6A. In manchen Beispielen beruhen eine oder mehrere Zielfunktionen einer oder mehrerer verteilter Rechenaufgaben auf einer oder mehreren alternativen Vorrichtungen/Strukturen, die sich in unterschiedlichen Teilen einer Edge-Netzwerkumgebung befinden, wie etwa Vorrichtungen zum Unterbringen einer Datenspeicherung (z. B. der beispielhaften Datenspeicherung 610), Eingabe/Ausgabe-Fähigkeiten (z. B. die beispielhafte(n) Peripherievorrichtung(en) 614) und/oder Netzwerkkommunikationsfähigkeiten (z. B. die beispielhafte NIC 620).
  • In manchen Beispielen sind Computer, die in einer verteilten Rechen- und/oder verteilten Netzwerkumgebung (z. B. einem Edge-Netzwerk) arbeiten, dafür strukturiert, eine bestimmte Zielfunktionalität auf eine Weise unterzubringen, die Rechenverschwendung reduziert. Da ein Computer beispielsweise eine Teilmenge der in 6A und 6B offenbarten Komponenten beinhaltet, erfüllen solche Computer die Ausführung der Zielfunktionen des verteilter Rechnens, ohne eine Rechenstruktur zu enthalten, die ansonsten ungenutzt und/oder unzureichend ausgelastet wäre. Von daher schließt der Begriff „Computer“, wie hierin verwendet, eine beliebige Kombination der Struktur von 6A und/oder 6B ein, die in der Lage ist, Zielfunktionen verteilter Rechenaufgaben zu erfüllen und/oder anderweitig auszuführen. In manchen Beispielen sind Computer auf eine Weise strukturiert, die entsprechenden Zielfunktionen des verteilten Rechnens entspricht, auf eine Weise, die in Verbindung mit dynamischem Bedarf herabskaliert oder hochskaliert. In manchen Beispielen werden unterschiedliche Computer hinsichtlich ihrer Fähigkeit, eine oder mehrere Aufgaben der verteilten Rechenanforderung(en) zu verarbeiten, aufgerufen und/oder anderweitig instanziiert, so dass ein beliebiger Computer, der in der Lage ist, die Aufgaben zu erfüllen, mit einer solchen Rechenaktivität fortfährt.
  • In den veranschaulichten Beispielen aus 6A und 6B umfassen Datenverarbeitungsvorrichtungen Betriebssysteme. Wie hierin verwendet, ist ein „Betriebssystem“ Software zum Steuern beispielhafter Computing-Vorrichtungen, wie etwa des beispielhaften Edge-Rechenknotens 600 von 6A und/oder des beispielhaften Edge-Rechenknotens 650 von 6B. Beispielhafte Betriebssysteme beinhalten unter anderem verbraucherbasierte Betriebssysteme (z.B. Microsoft® Windows® 10, Google® Android® OS, Apple® Mac® OS usw.). Beispielhafte Betriebssysteme beinhalten unter anderem auch industriefokussierte Betriebssysteme, wie etwa Echtzeitbetriebssysteme, Hypervisoren usw. Ein beispielhaftes Betriebssystem auf einem ersten Edge-Rechenknoten kann das gleiche oder ein anderes als ein beispielhaftes Betriebssystem auf einem zweiten Edge-Rechenknoten sein. In manchen Beispielen ruft das Betriebssystem alternative Software auf, um eine oder mehrere Funktionen und/oder Operationen zu ermöglichen, die nicht betreibssystemeigen sind, wie etwa bestimmte Kommunikationsprotokolle und/oder Interpreter. In manchen Beispielen instanziiert das Betriebssystem verschiedene Funktionalitäten, die dem Betriebssystem nicht eigen sind. In manchen Beispielen beinhalten Betriebssysteme variierende Grade an Komplexität und/oder Fähigkeiten. Beispielsweise beinhaltet ein erstes Betriebssystem, das einem ersten Edge-Rechenknoten entspricht, ein Echtzeitbetriebssystem, das bestimmte Leistungsfähigkeitserwartungen hinsichtlich des Ansprechens auf dynamische Eingabebedingungen aufweist, und ein zweites Betriebssystem, das einem zweiten Edge-Rechenknoten entspricht, beinhaltet Fähigkeiten einer grafischen Benutzeroberfläche, um Endbenutzer-E/A zu ermöglichen.
  • Die Anweisungen 682 können ferner über ein Kommunikationsnetzwerk unter Verwendung eines Übertragungsmediums über den Drahtlosnetzwerk-Sendeempfänger 466 gesendet oder empfangen werden, der ein beliebiges einer Anzahl von drahtlosen Lokalbereichsnetzwerk- bzw. WLAN-Übertragungsprotokollen nutzt (z. B. Frame Relay, Internetprotokoll (IP), Übertragungssteuerungsprotokoll (TCP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP) usw.). Beispielhafte Kommunikationsnetzwerke können ein lokales Netzwerk (LAN), ein Weitverkehrsnetzwerk (WAN), ein Paketdatennetzwerk (z. B. das Internet), Mobiltelefonnetzwerke (z. B. zellulare Netzwerke), Plain Old Telephone (POTS)-Netzwerke und drahtlose Datennetzwerke beinhalten. Kommunikationen über die Netzwerke können ein oder mehrere unterschiedliche Protokolle beinhalten, wie etwa die 802.11-Familie von Standards des Institute of Electrical and Electronics Engineers (IEEE), die u. a. bekannt ist als Wi-Fi, IEEE 802.16-Familie von Standards, IEEE 802.15.4-Familie von Standards, eine LTE-Familie (Long Term Evolution) von Standards, eine UMTS-Familie (Universal Mobile Telecommunications System) von Standards, Peer-to-Peer- bzw. P2P-Netzwerke, ein Next-Generation-Standard (NG)/ ein 5.-Generation-Standard (5G).
  • Es ist anzumerken, dass sich der Begriff „Schaltungsanordnung“, wie hierin verwendet, auf Hardwarekomponenten wie etwa eine elektronische Schaltung, eine Logikschaltung, einen Prozessor (gemeinsam genutzt, dediziert oder als Gruppe) und/oder einen Speicher (gemeinsam genutzt, dediziert oder als Gruppe), eine anwendungsspezifische integrierte Schaltung (ASIC: Application Specific Integrated Circuit), eine feldprogrammierbare Vorrichtung (FPD) (z. B. ein feldprogrammierbares Gate-Array (FPGA), eine programmierbare Logikvorrichtung (PLD), eine komplexe PLD (CPLD), eine PLD mit hoher Kapazität (HCPLD), eine strukturierte ASIC oder ein programmierbares SoC), digitale Signalprozessoren (DSPs) usw., die dazu ausgelegt sind, die beschriebene Funktionalität bereitzustellen, bezieht, Teil davon ist oder diese beinhaltet. In manchen Ausführungsformen kann die Schaltungsanordnung ein oder mehrere Software- oder Firmware-Programme ausführen, um mindestens einen Teil der beschriebenen Funktionalität bereitzustellen. Der Begriff „Schaltungsanordnung“ kann sich auch auf eine Kombination aus einem oder mehreren Hardwareelementen (oder eine Kombination von Schaltungen, die in einem elektrischen oder elektronischen System verwendet werden) mit dem Programmcode beziehen, der zum Ausführen der Funktionalität dieses Programmcodes verwendet wird. Bei diesen Ausführungsformen kann die Kombination von Hardwareelementen und Programmcode als eine bestimmte Art von Schaltungsanordnung bezeichnet werden.
  • Der Begriff „Prozessorschaltungsanordnung“ oder „Prozessor“, wie hierin verwendet, bezieht sich somit auf eine Schaltungsanordnung, die in der Lage ist, sequenziell und automatisch eine Abfolge arithmetischer oder logischer Operationen auszuführen oder digitale Daten aufzuzeichnen, zu speichern und/oder zu übertragen, ist Teil davon oder beinhaltet eine solche. Der Begriff „Prozessorschaltungsanordnung“ oder „Prozessor“ kann auf einen oder mehrere Anwendungsprozessoren, einen oder mehrere Basisbandprozessoren, eine physische Zentralverarbeitungseinheit (CPU), einen Einzel- oder einen Mehrkernprozessor und/oder eine beliebige andere Vorrichtung verweisen, die in der Lage ist, computerausführbare Anweisungen auszuführen oder anderweitig zu betreiben, wie etwa Programmcode, Softwaremodule und/oder funktionale Prozesse.
  • Beliebige der hierin beschriebenen Funkverbindungen können gemäß einer/einem oder mehreren der folgenden Funkkommunikationstechnologien und/oder Standards arbeiten, darunter unter anderem: eine GSM-Funkkommunikationstechnologie (Global System for Mobile Communications), einer GPRS-Funkkommunikationstechnologie (General Packet Radio Service), einer EDGE-Funkkommunikationstechnologie (Enhanced Data Rate for GSM Evolution) und/oder einer 3GPP-Funkkommunikationstechnologie (Third Generation Partnership Project), zum Beispiel Universal Mobile Telecommunications System (UMTS), Freedom of Multimedia Access (FOMA), 3GPP Long Term Evolution (LTE), 3GPP Long Term Evolution Advanced (LTE Advanced), Code Division Multiple Access 2000 (CDMA2000), zellbasierte Digitalpaketdaten (CDPD), Mobitex, dritte Generation (3G), leitungsvermittelte Daten (CSD), leitungsvermittelte Hochgeschwindigkeitsdaten (HSCSD), Universal Mobile Telecommunications System (dritte Generation) (3G), Wideband Code Division Multiple Access (Universal Mobile Telecommunications System) (W-CDMA (UMTS)), High Speed Packet Access (HSPA), High-Speed Downlink Packet Access (HSDPA), High-Speed Uplink Packet Access (HSUPA), High-Speed Uplink Packet Access (HSUPA), High-Speed Packet Access Plus (HSPA+), Universal Mobile Telecommunications System-Zeitmultiplex (UMTS-TDD), Time Division Multiple Access (TD-CDMA), Time Division-Synchronous Code Division Multiple Access (TD-CDMA), 3rd Generation Partnership Project Release 8 (vor der 4. Generation) (3GPP Rel. 8 (Pre-4G)), 3GPP Rel. 9 (3rd Generation Partnership Project Release 9), 3GPP Rel. 10 (3rd Generation Partnership Project Release 10), 3GPP Rel. 11 (3rd Generation Partnership Project Release 11), 3GPP Rel. 12 (3rd Generation Partnership Project Release 12), 3GPP Rel. 13 (3rd Generation Partnership Project Release 13), 3GPP Rel. 14 (3rd Generation Partnership Project Release 14), 3GPP Rel. 15 (3rd Generation Partnership Project Release 15), 3GPP Rel. 16 (3rd Generation Partnership Project Release 16), 3GPP Rel. 17 (3rd Generation Partnership Project Release 17) und darauf folgende Releases (wie Rel. 18, Rel. 19 usw.), 3 GPP 5G, 5G, 5G New Radio (5G NR), 3 GPP 5G New Radio, 3GPP LTE Extra, LTE-Advanced Pro, LTE Licensed-Assisted Access (LAA), MuLTEfire, UMTS Terrestrial Radio Access (UTRA), Evolved UMTS Terrestrial Radio Access (E-UTRA), Long Term Evolution Advanced (4. Generation) (LTE Advanced (4G)), cdmaOne (2G), Code Division Multiple Access 2000 (dritte Generation) (CDMA2000 (3G)), Evolution-Data Optimized oder Evolution-Data Only (EV-DO), Advanced Mobile Phone System (1. Generation) (AMPS (1G)), Total Access Communication System/Extended Total Access Communication System (TACS/ETACS), Digital AMPS (2. Generation) (D-AMPS (2G)), Push-to-talk (PTT), Mobil Telephone System (MTS), Improved Mobile Telephone System (IMTS), Advanced Mobile Telephone System (AMTS), OLT (Norwegian für Offentlig Landmobil Telefoni, Public Land Mobile Telephony), MTD (schwedische Abkürzung für Mobiltelefonisystem D oder Mobiltelefoniesystem D), Public Automated Land Mobile (Autotel/PALM), ARP (Finnisch für Autoradiopuhelin, „Autofimktelefon“), NMT (Nordic Mobile Telephony), Hochkapazitätsversion von NTT (Nippon Telegraph and Telephone) (Hicap), Cellular Digital Packet Data (CDPD), Mobitex, DataTAC, Integrated Digital Enhanced Network (iDEN), Personal Digital Cellular (PDC), Circuit Switched Data (CSD), Personal Handy Phone System (PHS), Wideband Integrated Digital Enhanced Network (WiDEN), iBurst, Unlicensed Mobile Access (Unlizenzierter Mobilzugang) (UMA), auch als 3GPP-GENERIC Access Network oder GAN-Standard bezeichnet), Zigbee-, Bluetooth(r)-, Wireless Gigabit Alliance (WiGig)-Standard, mmWave-Standards im Allgemeinen (Drahtlossysteme, die bei 10-300 GHz und darüber arbeiten, wie etwa WiGig, IEEE 802.11ad, IEEE 802.11ay usw.), Technologien, die über 300 GHz- und THz-Bändern arbeiten, (3 GPP/LTE-basiert oder IEEE 802.11p oder IEEE 802.11bd und andere) Fahrzeug-zu-Fahrzeug (V2V)- und Fahrzeug-zu-X (V2X)- und Fahrzeug-zu-Infrastruktur (V2I)- und Infrastruktur-zu-Fahrzeug (I2V)-Kommunikationstechnologien, 3GPP zellulares V2X, DSRC (Dedicated Short Range Communications)-Kommunikationssysteme, wie etwa Intelligent-Transport-Systeme und andere (die typischerweise bei 5850 MHz bis 5925 MHz oder mehr arbeiten (typischerweise bis zu 5935 MHz nach Änderungsvorschlägen in CEPT-Bericht 71)), das europäische ITS-G5-System (d. h. die europäische Variante von IEEE 802.11p-basiertem DSRC, einschließlich ITS-G5A (d. h. Betrieb von ITS-G5 in europäischen ITS-Frequenzbändern, die für ITS für sicherheitsbezogene Anwendungen im Frequenzbereich von 5,875 GHz bis 5,905 GHz dediziert sind), ITS-G5B (d. h. Betrieb in europäischen ITS-Frequenzbändern, die für ITS für Nichtsicherheitsanwendungen im Frequenzbereich von 5,855 GHz bis 5,875 GHz dediziert sind), ITS-G5C (d. h. Betrieb von ITS-Anwendungen im Frequenzbereich von 5,470 GHz bis 5,725 GHz), DSRC in Japan im 700-MHz-Band (einschließlich 715 MHz bis 725 MHz), IEEE 802.11bd-basierte Systeme usw.
  • Hier beschriebene Aspekte können im Kontext eines beliebigen Spektrumverwaltungsschemas verwendet werden, das dediziertes lizenziertes Spektrum, unlizenziertes Spektrum, lizenziertes ausgenommenes Spektrum, (lizenziertes) gemeinsam genutztes Spektrum (wie etwa LSA = Licensed Shared Access in 2,3-2,4 GHz, 3,4-3,6 GHz, 3,6-3,8 GHz und weiteren Frequenzen und SAS = Spectrum Access System / CBRS = Citizen Broadband Radio System in 3,55-3,7 GHz und weiteren Frequenzen) einschließt. Anwendbare Spektrumsbänder beinhalten ein IMT-Spektrum (International Mobile Telecommunications) sowie andere Arten von Spektrum/Bändern, wie etwa Bänder mit nationaler Zuordnung (einschließlich 450-470 MHz, 902-928 MHz (Anmerkung: zugeordnet zum Beispiel in den USA (FCC Part 15)), 863-868,6 MHz (Anmerkung: zugeordnet zum Beispiel in der Europäischen Union (ETSI EN 300 220)), 915,9-929,7 MHz (Anmerkung: zugeordnet zum Beispiel in Japan), 917-923,5 MHz (Anmerkung: zugeordnet zum Beispiel in Südkorea), 755-779 MHz und 779-787 MHz (Anmerkung: zugeordnet zum Beispiel in China), 790-960 MHz, 1710-2025 MHz, 2110--2200 MHz, 2300-2400 MHz, 2,4-2,4835 GHz (Anmerkung: es ist ein ISM-Band mit globaler Verfügbarkeit und wird von der Wi-Fi-Technologiefamilie (11b/g/n/ax) sowie von Bluetooth genutzt), 2500-2690 MHz, 698-790 MHz, 610-790 MHz, 3400-3600 MHz, 3400-3800 MHz, 3800-4200 MHz, 3,55-3,7 GHz (Anmerkung: zugeordnet zum Beispiel in den USA für Citizen Broadband Radio Service), 5,15-5,25 GHz und 5,25-5,35 GHz und 5,47-5,725 GHz und 5,725-5,85 GHz (Anmerkung: zugeordnet zum Beispiel in den USA (FCC Teil 15), besteht aus vier U-NII-Bändern im Spektrum von insgesamt 500 MHz), 5,725-5,875 GHz (Anmerkung: zugeordnet zum Beispiel in der EU (ETSI EN 301 893)), 5,47-5,65 GHz (Anmerkung: zugeordnet zum Beispiel in Südkorea, 5925-7085 MHz und 5925-6425 MHz (Anmerkung: in US bzw. EU in Betracht gezogen. Es wird erwartet, dass das Wi-Fi-System der nächsten Generation das 6-GHz-Spektrum als Betriebsband beinhaltet, aber es wird angemerkt, dass das Wi-Fi-System im Dezember 2017 in diesem Band noch nicht erlaubt ist. Es wird erwartet, dass die Regelung im Zeitrahmen 2019-2020 abgeschlossen ist), IMT-Advanced-Spektrum, IMT-2020-Spektrum (es wird erwartet, dass es 3600-3800-MHz-, 3800-4200-MHz-, 3,5-GHz-Bänder, 700-MHz-Bänder, Bänder innerhalb des Bereichs von 24,25-86 GHz beinhaltet, usw.), unter der 5G-Initiative „Spectrum Frontier“ der FCC verfügbar gemachtes Spektrum (einschließlich 27,5-28,35 GHz, 29,1-29,25 GHz, 31-31,3 GHz, 37-38,6 GHz, 38,6-40 GHz, 42-42,5 GHz, 57-64 GHz, 71-76 GHz, 81-86 GHz und 92-94 GHz usw.), das ITS (Intelligent Transport Systems)-Band von 5,9 GHz (typischerweise 5,85-5,925 GHz) und 63-64 GHz, die derzeit WiGig zugewiesenen Bänder wie etwa WiGig Band 1 (57,24-59,40 GHz), WiGig Band 2 (59,40-61,56 GHz) und WiGig Band 3 (61,56-63,72 GHz) und WiGig Band 4 (63,72-65,88 GHz), 57-64/66 GHz (Anmerkung: dieses Band weist eine beinahe globale Bezeichnung für Multi-Gigabit-Drahtlossysteme (MGWS)/WiGig auf. In den USA (FCC Part 15) werden insgesamt 14 GHz Spektrum zugewiesen, während in der EU (ETSI EN 302 567 und ETSI EN 301 217-2 für Fixed P2P) insgesamt 9 GHz Spektrum zugewiesen werden), das Band von 70,2 GHz bis 71 GHz und jedes Band zwischen 65,88 GHz und 71 GHz, Bänder, die derzeit Kraftfahrzeug-Radaranwendungen zugewiesen sind, wie 76-81 GHz, sowie zukünftige Bänder, einschließlich 94-300 GHz und darüber. Des Weiteren kann das System auf einer sekundären Basis auf Bändern wie den TV-White-Space-Bändern (typischerweise unterhalb von 790 MHz) verwendet werden, wobei insbesondere das 400-MHz- und das 700-MHz-Band viel versprechende Kandidaten sind. Neben zellulären Anwendungen können spezifische Anwendungen für vertikale Märkte adressiert werden, wie etwa PMSE (Program Making and Special Events), medizinische, gesundheitliche, chirurgische, Automobil-, Niederlatenz-, Drohnen usw. Anwendungen.
  • 7 veranschaulicht eine beispielhafte Softwareverteilungsplattform 705 zum Verteilen von Software, wie etwa den beispielhaften computerlesbaren Anweisungen 682 von 6B, an eine oder mehrere Vorrichtungen, wie etwa beispielhafte Prozessorplattform(en) 710 und/oder beispielhafte verbundene Edge-Vorrichtungen. Die beispielhafte Softwareverteilungsplattform 705 kann durch einen beliebigen Computerserver, eine beliebige Dateneinrichtung, einen beliebigen Cloud-Dienst usw. implementiert werden, der in der Lage ist, Software zu speichern und zu anderen Rechenvorrichtungen (z. B. Dritte, die beispielhaften angeschlossenen Edge-Vorrichtungen) zu übertragen. Bei den beispielhaften angeschlossenen Edge-Geräten kann es sich beispielsweise um Kunden, Clients, Verwaltungsvorrichtungen (z. B. Server) oder Drittparteien (z. B. Kunden einer Entität, die Eigentümer und/oder Betreiber der Softwareverteilungsplattform 705 ist) handeln. Beispielhafte angeschlossene Edge-Vorrichtungen können in kommerziellen und/oder Heimautomatisierungsumgebungen arbeiten. In manchen Beispielen ist eine Drittpartei ein Entwickler, ein Verkäufer und/oder ein Lizenzgeber von Software, wie etwa den beispielhaften computerlesbaren Anweisungen 682 von 6B. Die Drittparteien können Verbraucher, Benutzer, Einzelhändler, OEMs usw. sein, die die Software zur Verwendung kaufen und/oder lizenzieren und/oder wiederverkaufen und/oder sublizenzieren. In manchen Beispielen veranlasst die verteilte Software die Anzeige einer oder mehrerer Benutzeroberflächen (UIs) und/oder grafischer Benutzeroberflächen (GUIs), die eine oder mehreren Vorrichtungen (z. B. verbundene Edge-Vorrichtungen) zu identifizieren, die geografisch und/oder logisch voneinander getrennt sind (z. B. physisch getrennte IoT-Vorrichtungen, die mit der Steuerung der Wasserverteilung (z. B. Pumpen), der Stromverteilung (z. B. Relais) usw. beauftragt sind).
  • Im veranschaulichten Beispiel von 7 beinhaltet die Softwareverteilungsplattform 705 einen oder mehrere Server und eine oder mehrere Speicherungsvorrichtungen. Die Speicherungsvorrichtungen speichern die computerlesbaren Anweisungen 682. Der eine oder die mehreren Server der beispielhaften Softwareverteilungsplattform 705 sind in Kommunikation mit Netzwerk 715, das dem Internets und/oder jeglichen der oben beschriebenen beispielhaften Netzwerke entsprechen kann. In einigen Beispielen reagieren der eine oder die mehreren Server auf Anforderungen zur Übertragung der Software an eine anfordernde Partei als Teil einer kommerziellen Transaktion. Die Zahlung für die Lieferung, den Verkauf und/oder die Lizenz der Software kann durch den einen oder die mehreren Server der Softwareverteilungsplattform und/oder über eine Drittparteienzahlungsentität gehandhabt werden. Die Server ermöglichen Käufern und/oder Lizenzgebern, die computerlesbaren Anweisungen 682 von der Softwareverteilungsplattform 605 herunterzuladen. Zum Beispiel kann die Software, die den beispielhaften computerlesbaren Anweisungen entsprechen kann, auf die beispielhafte(n) Prozessorplattform(en) 700 (z. B. beispielhafte verbundene Edge-Vorrichtungen) heruntergeladen werden, die die computerlesbaren Anweisungen 682 ausführen sollen, um die Inhaltseinfügung an einem Switch zu implementieren. In manchen Beispielen sind ein oder mehrere Server der Softwareverteilungsplattform 705 kommunikativ mit einer oder mehreren Sicherheitsdomänen und/oder Sicherheitsvorrichtungen verbunden, durch die Anforderungen und Übertragungen der beispielhaften computerlesbaren Anweisungen 682 laufen müssen. In manchen Beispielen bieten ein oder mehrere Server der Softwareverteilungsplattform 705 periodisch Aktualisierungen an, übertragen und/oder erzwingen diese an die Software (z. B. die beispielhaften computerlesbaren Anweisungen 682 von 6B), um sicherzustellen, dass Verbesserungen, Patches, Aktualisierungen usw. verteilt und auf die Software an den Endbenutzervorrichtungen angewandt werden.
  • Im veranschaulichten Beispiel von 7 sind die computerlesbaren Anweisungen 682 auf Speichervorrichtungen der Softwareverteilungsplattform 705 in einem speziellen Format gespeichert. Ein Format von computerlesbaren Anweisungen beinhaltet unter anderem eine spezielle Codesprache (z. B. Java, JavaScript, Python, C, C#, SQL, HTML usw.) und/oder einen speziellen Codezustand (z. B. unkompilierter Code (z. B. ASCII), interpretierter Code, verknüpfter Code, ausführbarer Code (z. B. a binär) usw.). In manchen Beispielen befinden sich die computerlesbaren Anweisungen 682, die in der Softwareverteilungsplattform 705 gespeichert sind, in einem ersten Format, wenn sie an die beispielhafte(n) Prozessorplattform(en) 710 übertragen werden. In manchen Beispielen ist das erste Format eine ausführbare Binärdatei, in der bestimmte Typen der Prozessorplattform(en) 710 ausgeführt werden können. In manchen Beispielen ist das erste Format jedoch unkompilierter Code, der eine oder mehrere Vorbereitungsaufgaben erfordert, um das erste Format in ein zweites Format umzuwandeln, um eine Ausführung auf der (den) beispielhaften Prozessorplattform(en) 710 zu ermöglichen. Beispielsweise müssen die empfangende(n) Prozessorplattform(en) 710 möglicherweise die computerlesbaren Anweisungen 682 im ersten Format kompilieren, um ausführbaren Code in einem zweiten Format zu erzeugen, das in der Lage ist, auf der(den) Prozessorplattform(en) 710 ausgeführt zu werden. In noch anderen Beispielen ist das erste Format interpretierter Code, der beim Erreichen der Prozessorplattform(en) 710 durch einen Interpreter interpretiert wird, um die Ausführung von Anweisungen zu erleichtern.
  • 8 ist ein Blockdiagramm, das ein serverloses Datenzentrum 800 gemäß einer Ausführungsform veranschaulicht. Das Datenzentrum 800 ist in logischen Dienstblöcken angeordnet. Die in 8 veranschaulichten Dienstblöcke weisen Universalrechendienste 802, ML-Dienste (ML: Machine Learning) und KI-Dienste (KI: Künstliche Intelligenz) 804, Rechenspeicherungsdienste 806 und Beschleunigungsdienste 808 auf. Die Dienstblöcke sind mit einer intelligenten Netzwerkstruktur 810 gekoppelt.
  • Mit dieser Art von serverlosem Datenzentrum 800 kann eine neue Art der Orchestrierung erreicht werden, die von aktuellen Praktiken zu einem zielgesteuerten Ansatz übergeht, bei dem der Kunde nur die Absicht äußert und der Orchestrierungsstapel selbst die Plattform zum Erreichen dieser Absicht einrichtet.
  • Manche existierenden Software-as-a-Service-(SaaS)-Modelle bieten ihren Verbrauchern typischerweise einen dienstspezifischen Satz von Service-Level-Zielen (SLO). Beispielsweise kann eine Datenanalyseplattform eine Anzahl von Jobs pro Stunde fördern, die berechnet werden können. Dies ist aus Benutzersicht großartig, erfordert aber immer noch, dass der SaaS-Anbieter SLOs präventiv den benötigten Ressourcen zuordnet, bevor er Anforderungen an den Ressourcenorchestrator sendet. Die Dienstanbieter sind nicht in der Lage, automatisch Ressourcentypen basierend auf SLOs auszuwählen.
  • Die hierin beschriebenen Systeme und Verfahren veranschaulichen, wie Absichten (Ziele) automatisch, dynamisch und direkt auf Plattformeinstellungen abgebildet werden können. Absichten werden als Ziele höherer Ebene empfangen und im gesamten Orchestrierungsstapel auf Einstellungen niedrigerer Ebene abgebildet.
  • Ein Beispiel: Eine Anwendung verlangt, dass ein bestimmter Prozentsatz innerhalb eines bestimmten Zeitfensters abgeschlossen wird, was hier als „P50-Latenz“ bezeichnet wird. Es können auch andere Begriffe verwendet werden, die ähnlich sein können, wie etwa „P50-Ziel“ oder „P50-Abschlüsse“, um anzugeben, dass Aufgaben, Projekte, Anforderungen oder dergleichen in mindestens 50 % der Fälle rechtzeitig abgeschlossen werden müssen oder dass eine Wahrscheinlichkeit von mindestens 50 % besteht, dass die Aufgabe rechtzeitig abgeschlossen wird. Diese Absicht wird auf Einstellungen niedrigerer Ebene abgebildet, wie etwa zur Angabe einer Priorität auf Threadebene und von dort aus auf einen CPU-Cache-Weg/eine Profilzuweisung/Ressourcenzuweisung. Auf der Eingabe/Ausgabe (E/A)-Seite kann die Absicht auf Netzwerkeinstellungen abgebildet werden, um sicherzustellen, dass ausreichend Kommunikationsressourcen verfügbar sind, um die Anfrage und Antwort zu übertragen und zu empfangen.
  • Um sich dynamisch an sich ändernde Bedingungen anzupassen, verwenden die Systeme und Verfahren Regelkreise auf verschiedenen Ebenen in der Architektur. Die Regelkreise können Kreditsysteme, Nutzen-/Kostenfunktionen, Planungs- und Lösungsmethoden usw. einsetzen. Die Regelkreise können in Abhängigkeit davon, wie schnell das überwachte System angepasst werden muss, mit unterschiedlichen Geschwindigkeiten ausgeführt werden. Solche Regelkreise sind besonders wichtig und nützlich, wenn die Dynamik von Rechensystemen berücksichtigt wird. Beispielsweise kann Netzwerkverkehr täglich variieren. Müssen Kunden die Ressourcenanforderungen selbst ändern, so werden sie zusätzlich belastet, um den Dienstanbieter zu verwenden. Zusätzlich dazu können solche Änderungen schwierig sein, weil die Informationen, die für solche Entscheidungen benötigt werden, dem Kunden möglicherweise nicht zugänglich sind. Bei Verwendung der hier beschriebenen Systeme und Verfahren muss der Kunde stattdessen nur die Absicht angeben, und das System passt die Ressourcen automatisch an. Dies kann zu Kosteneinsparungen sowohl für den Kunden als auch für den Dienstanbieter führen.
  • Die Dynamik des Systems gilt auch für die Pläne, die erstellt werden. Diese Pläne weisen ein zeitliche Komponente auf. Zum Beispiel kann ein Plan vorübergehend (z. B. in der Größenordnung von Minuten) darauf abzielen, einer Arbeitslast eine Fülle von Ressourcen zuzuweisen, um eine SLA unter der Aufsicht eines schnellen Regelkreises einzuholen, und dann über einen längeren Zeitraum (z. B, monatlich) versuchen, ein akzeptables und realisierbares Ressourcenzuweisungsmuster unter der Aufsicht eines langsameren Regelkreises zu erreichen. Der Plan kann entweder automatisch oder teilweise manuell ausgelöst werden, indem beispielsweise zuerst der Plan als eine Empfehlung an einen menschlichen Bediener gesendet wird, um eine menschliche Führung zu ermöglichen.
  • Zusätzlich kann der zeitliche Aspekt eines Plans auch unter dem Gesichtspunkt einer kontinuierlichen Verbesserung nützlich sein. Ein Plan, der alle SLOs im System der Systeme erfüllt, könnte durch einen anderen Plan ersetzt werden, der ebenfalls alle SLOs erfüllt, aber eine andere Einrichtung, Konfiguration oder einen anderen Satz von Richtlinien auslöst. Zur Vorbereitung von Wartungsarbeiten kann ein SLO beispielsweise Ressourcen effizienter nutzen, Platz für neue Arbeitslasten/Dienste schaffen oder dergleichen.
  • Mit einer dezentralen dienstorientierten Plattform nimmt die Komplexität der Orchestrierung noch weiter zu. Die hier beschriebenen Systeme und Verfahren befassen sich mit der Orchestrierung über mehrere Standorte hinweg, die Eigentum unterschiedlicher Akteure sein können. Die einzelnen Teile können Verhandlung und Koordinierung implementieren, um eine übergeordnete Absicht zu erreichen, die im Vordergrund steht, wenn es keine zentralisierte Orchestrierung gibt.
  • Bei einer Implementierung kann ein Dienstanbieter eine Recheneinheit (z. B. einen Pod) mit Anwendungskontext-Metadaten bereitstellen, so dass der Knoten in einem schnellen Regelkreis geeignetere Anwendungsentscheidungen treffen kann und sich möglicherweise dafür entscheiden kann, eine Arbeitslast mit niedriger Priorität nicht zu depriorisieren, weil sie sich auf die gesamte Lebensdauer auswirkt. Dies erfordert jedoch eine E2E-Ansicht und beinhaltet Konzepte von Co-Scheduling und Co-Priorisierung von Knoten, die Sicherheitsfunktionen gegenüber Daten (einschließlich Datenherkunft, Konformität und Aufzeichnung) mit anderen Rechenknoten, die Operationen in höheren Schichten des Stapels durchführen, bereitstellen müssen. In Kubernetes ist ein Pod die kleinste einsetzbare Recheneinheit, die Sie erzeugen und verwalten können. Ein Pod ist eine Gruppe von einem oder mehreren Containern mit gemeinsam genutzten Speicherungs- und Netzwerkressourcen und einer Spezifikation für die Ausführung der Container. Die Inhalte eines Pods befinden sich zusammen an einem Ort und werden gemeinsam geplant und laufen in einem gemeinsam genutzten Kontext.
  • Mit dem Übergang zu absichtsgesteuerten Systemen konzentriert sich das System statt auf die Bereitstellungsfunktion darauf, ob Ressourcen potenziell verfügbar gemacht werden können und wie das System neu konfiguriert werden kann, um sie verfügbar zu machen. Ressourcen können von unterschiedlichen Typen sein, während sie in derselben Kategorie sind: z. B. Hochleistungsprozessoren (z. B. Intel® Xeon CPUs) gegenüber mehreren rechenschwachen Prozessoren (z. B. Xeon-Ds) oder eine einzelne große XPU gegenüber mehreren kleineren XPUs. Des Weiteren kann eine Ressource selbst unterschiedliche Typen von Unterressourcen/-komponenten enthalten, zum Beispiel effiziente und leistungsfähige Kerne usw.
  • Bei manchen Implementierungen geht das System die Herausforderung des administrativen Steuerns komplexer, verteilter Infrastruktur an, indem es den Administratoren von Clustern und Infrastrukturen eine am Service-Level-Ziel ausgerichtete Steuerung an die Hand gibt und sie von der Last befreit, möglicherweise fehlerhafte Konfigurationsdetails auf niedriger Ebene spezifizieren zu müssen. Ein Admin-Richtliniensteuerungs- und ein Admin-Richtlinienübersetzungsmodul können in der Orchestrierungsarchitektur implementiert sein, und ein Arbeitsablauf zum Verwalten mehrerer Ebenen absichtsgesteuerter Admin-Richtlinien kann im Arbeitsablauf zur Bereitstellung von Arbeitslasten verwendet werden. Es kann eine Regelung administrativer Richtlinien verwendet werden, einschließlich der Frage, wie sie durch mehrfache Iterationen bei zwingenden Konfigurationen erreicht werden. Sie kann die Platzierung und Neuverteilung der Arbeitslast bei sich ändernden Richtlinien oder bei Nichteinhaltung der Richtlinien beeinflussen.
  • Das System kann ein neues Modell für die Steuerung des Kubernetes-Lebenszyklusmanagements (LCM) implementieren, das die Bedürfnisse der Anwendung und nicht die Annahmen des Kubernetes-Administrators widerzuspiegelt. Die Anwendung wird vorübergehend bereitgestellt (zur Unterstützung des Schnellstarts) und anschließend wird eine neue Kubernetes-Instanz mit den Richtlinien auf Cluster- und Knotenebene eingesetzt, die dem Bedarf der Anwendung besser gerecht wird. Die Arbeitslast wird anschließend auf den neuen Cluster verschoben.
  • Aktuelle Verfahren zum gemeinsamen Nutzen gemeinsamer Ressourcen wie etwa Cache-Zuordnungstechnologie (CAT) und Speicherbandbreitenzuordnung (MBA), und Leistung beruhen auf den KPIs der Anwendung, die durch eine spezifische dynamische Steuerung (z. B. Ressourcenverwaltungsdaemon (RMD), dynamische Ressourcensteuerung (DRC), Anwendungen usw.) überwacht werden oder ein telemetriebewusstes Scheduling verwenden, um eine Erschöpfung zu bewältigen. Ein in die Orchestrierung integrierter „Ressourcenanforderungsmakler“ kann ein nachrichtenbasiertes System aufweisen, das unabhängig von den Anwendungs-KPIs ist (die von der Anwendung selbst überwacht werden). Der Makler kann einen lokalen Agenten auf der Plattform haben, da Zeit ein Faktor bei der Aufteilung ist, und kann lokale Entscheidungen basierend auf einer Cluster-„Anteil“-Richtlinie treffen. Einzelne Pods können sich für statische Verträge, „garantierte Ressourcenverträge“, Verträge mit gleichen Anteilen oder dynamische (Ausschreibungs-)Verträge entscheiden. Konkurrierende Anforderungen werden durch den lokalen Makleragenten arbitriert, der ein Gebots-/Angebotsschema betreiben kann, beispielsweise „Ich bin bereit, Ressource X für Ressource Y für den Zeitraum N auszugeben“
  • Sicherheitsrisiken entstehen, wenn Komponenten über mehrere Ressourcen verteilt sind. Bei der absichtsbasierten Orchestrierung kann das System, ähnlich wie bei den QoS-Klassen, Benutzern die Möglichkeit zu geben, zu definieren, wie „empfindlich“ sie gegenüber bestimmten Aspekten der Sicherheit oder des Vertrauens in der Umgebung sind bzw. wie viel Risiko sie bereit sind, in Kauf zu nehmen. Das System kann einen Satz zusätzlicher Komponenten zur Orchestrierungssteuerungsebene enthalten, um Risiken zu überwachen, zu analysieren und auf sie zuzugreifen, sowie eine Komponente, die in der Lage ist, die Bewertung in eine Reihe von Richtlinien, Ressourcenzuweisungen usw. umzusetzen.
  • 9 ist ein Blockdiagramm, das eine Betriebsumgebung 900 mit mehreren Hardwaresystemen 902A und 902B gemäß einer Ausführungsform veranschaulicht. Die Betriebsumgebung 900 kann als ein „System von Systemen“ betrachtet werden, das sich in Nord-Süd-Richtung (z. B. der gesamte Stapel) und Ost-West-Richtung (z. B. E2E) erstreckt. Auf jeder Schicht in einem System 902A oder 902B können unterschiedliche Arten von Absichten vom Norden nach Süden oder von Osten nach Westen auf SLOs abgebildet werden. SLOs auf verschiedenen Schichten in dem Stapel können in Bildern pro Sekunde (FPS), Latenz, Anweisungen pro Zyklus (IPC) usw. beschrieben werden. SLOs zwischen Unternehmen oder Systemen können hinsichtlich dessen beschrieben werden, wie einzelne Anwendungen, die den Dienst bilden, interagieren müssen, um die Gesamtziele der Absicht zu erreichen. Beispielsweise können die E2E-SLOs eine Anforderung an die P99-Latenz < 100 ms, Frontend-max 10 ms, Backend 5 ms, Caching max 10 ms usw. beinhalten. Um die Ziele von Vollstapel-SLOs und E2E-SLOs zu erreichen, setzt das System Richtlinien von höheren Schichten zu niedrigeren Schichten durch und koordiniert oder verhandelt systemübergreifend zwischen Komponenten innerhalb einer Schicht.
  • SLOs, entweder Vollstapel oder E2E (z. B. von System zu System), können im Laufe der Zeit variiert werden, mit einem Bereich (z. B. einem minimalen und maximalen zulässigen Wert) ausgedrückt werden, eine Abweichung oder Varianz außerhalb von Bereichen für einen gewissen Zeitraum ermöglichen, als bevorzugt oder unter Verwendung anderer Priorisierungsschemata ausgedrückt werden oder dergleichen. Ein Beispiel kann sein, dass die Aufgabe 99 % der Zeit während 60 Minuten P99-konform sein muss, während 10 ms nicht überschritten werden dürfen, und mit einem bevorzugten Konformitätsniveau von 5 ms läuft.
  • Bei manchen Implementierungen wird auf einem Knoten ein Satz von Sidecars verwendet, die mit ihrer Arbeitslast assoziiert sind. Die Sidecars koordinieren sich, um sicherzustellen, dass der Knoten, die Plattform, Einrichtungen usw. korrekt eingerichtet sind, damit die Ziele ihrer Arbeitslast erreicht werden können. Die Sidecars können eine spezielle Einrichtung überwachen und die korrekten Richtlinien durchsetzen, die korrekten Ressourcen zuweisen, die Einstellungen so abstimmen, dass die Absichten der Pods erfüllt werden können usw.
  • Bei manchen Installationen besteht eine Herausforderung darin, die vom Orchestrierungssystem beschlossene Ressourcenzuweisung mit Gebühren-/Abrechnungsbeschränkungen zu versehen, wenn für eine Arbeitslast Eingabeparameter basierend auf Service-Level-Zielen vorliegen. Zwei neue Komponenten ermöglichen eine absichtsgesteuerte Gebührenaufstellung und eine absichtsgesteuerte Abrechnung: 1) Gebührenleitplankenfunktion und 2) SLO-Planungsfunktion. Das Konzept einer Gebührenleitplankenfunktion wird in den Bereitstellungsarbeitsablauf eingeführt, der einen logisch zentralen Punkt in der Orchestrierungsarchitektur darstellt. Sie fungiert als die Entität, die für das Steuern und Führen der SLO-orientierten Ressourcenplanungskomponente verantwortlich ist, um sicherzustellen, dass die zugewiesenen Ressourcen für den Benutzer erschwinglich sind. Die SLO-Planungsfunktion muss die Kostenbasis für zugewiesene Ressourcen und nicht nur ihre Eignung zur wahrscheinlichen Einhaltung der Arbeitslast-SLA berücksichtigen.
  • 10 ist ein Blockdiagramm, das einen Orchestrierungssteuerungsebene 1000 gemäß einer Ausführungsform veranschaulicht. Die Orchestrierungssteuerungsebene 1000 ist unter Verwendung einer Anwendungsprogrammierschnittstelle (API) 1002 zugänglich oder konfigurierbar. Einstellungen, Daten oder andere Informationen können in einer Datenbank 1004 gespeichert werden. Die Orchestrierungssteuerungsebene 1000 weist einen Ressourcenmanager 1006, Steuerungen 1008, Scheduler 1010, einen Planer 1012, einen Monitor 1014, ein Modul zur kontinuierlichen Verbesserung (CIM) 1016 und einen Beobachtbarkeitsstapel 1018 auf. Der Planer 1012, das CIM 1016, der Monitor 1014 oder andere Komponenten des Orchestrierungssteuerungsebene 1000 können auf Daten in einer Wissensdatenbank 1020 zugreifen oder diese speichern. Die Wissensdatenbank 1020 kann verschiedene Daten beinhalten, die zum Beispiel als Eingabe für den Planer oder die Scheduler dienen. Die Wissensdatenbank 1020 kann Informationen zur Netzwerktopologie beinhalten, die zur Bestimmung der Platzierung von Aufgaben und der Nutzung von Ressourcen verwendet werden können.
  • Der Planer 1012 kann mit einer festverdrahteten Schaltung, einer programmierbaren Hardwarevorrichtung (z. B. einer ASIC) oder als Anweisungen implementiert sein, die auf einer Hardwareplattform (z. B. auf einer allgemeinen CPU) ausgeführt werden. Der Planer 1012 kann konfiguriert, entworfen, programmiert oder anderweitig angepasst werden, um Absichten oder Ziele auf SLOs abzubilden. Der Planer 1012 kann SLOs auch in umsetzbare Pläne aufschlüsseln. Der Planer 1012 kann verwendet werden, um SLO-Anforderungen automatisch in geeignete Pod-Spezifikationen zu übersetzen oder darin abzubilden, die Ressourcenanforderungen, Plattformmerkmale oder Richtlinien für die Bereiche Datenverarbeitung, Netzwerk, Speicher und Einrichtungen (z. B. Energie) umfassen können. Bei der Abbildung von Zielen auf Richtlinien und Zielvorgaben auf unterer Ebene können heuristische Mechanismen, Mechanismen des maschinellen Lernens (ML) oder der künstlichen Intelligenz (KI), Charakterisierungen der Arbeitslast (z. B. abgeleitet aus Online-Daten oder durch Offline-Experimente oder durch Sandboxing) oder Richtlinien von Ressourceneigentümern eingesetzt werden, um die Nutzung des Systems des Eigentümers anzuleiten.
  • Der Planer 1012 kann außerdem zur Koordinierung von System zu System (z. B. E2E) mit einem anderen Planer 1022 verwendet werden und mehrere Points-of-Presence (PoPs) abbilden, die potenziell verschiedenen Beteiligten gehören. Es können verschiedene Arten von Koordinations-und Verhandlungsschemata verwendet werden. Beispielsweise kann ein MAUT-Modell (MAUT: Multiple Attribute User Theory) verwendet werden, um die Ressourcenzuweisung auszuhandeln.
  • Der Planer 1012 beaufsichtigt die Umsetzung von Absichten in Handlungsrichtlinien, Systemeinstellungen, Ressourcenanforderungen und dergleichen. Dies geschieht auf der Grundlage der in der Wissensdatenbank 1020 gespeicherten Erkenntnisse. Sobald ein Plan verfügbar ist, wird er durch die Scheduler 1010 implementiert und durchgesetzt.
  • Ein Plan kann mit mehreren SLOs auf verschiedenen Ebenen in der Orchestrierungssteuerungsebene 1000 definiert werden. Beispielsweise können SLOs auf höheren Ebenen der Orchestrierungssteuerungsebene 1000 zur Regulierung und Steuerung von FPS und SLOs auf niedrigeren Ebenen der Orchestrierungs-Steuerungsebene 1000 zur Regulierung und Steuerung von IPC verwendet werden. Anbieter, Benutzer und Dienstanbieter können SLOs in einem standardisierten Format definieren. SLOs können auch Leitplanken beinhalten, die eine gewisse Variation von den Ziel- oder Grenzwerten bereitstellen. Beispielsweise kann eine Leitplanke eine 10%-ige Überschreitung der P95 für bis zu 10 Minuten zulassen. Leitplanken können auch bedingt sein. Beispielsweise kann eine Leitplanke eine eine 10%-ige Überschreitung von P95 für bis zu 10 Minuten zulassen, wenn das System danach die Einhaltung von P99 garantiert.
  • Mit zunehmender Heterogenität von Recheneinrichtungen und XPU-Umgebungen können die Orchestrierungs- und Ressourcenmanager der unteren Ebenen so konfiguriert werden, dass sie Co-Scheduling und Co-Priorisierung von Arbeitslasten auf einer sehr granularen Ebene unterstützen.
  • Beim Zuweisen von Aufgaben zu Ressourcen ist das Platzierungsproblem schwer zu lösen. Im Gegensatz zur clusterbasierten Planung ermöglicht dieses System die Neupriorisierung lokaler Ressourcen basierend auf der Nähe der Operation zum erforderlichen Abschlusstermin neu zu priorisieren. Lastausgleich und automatische Skalierungsaktionen, die lokal an Graphen-Engpässen eingeleitet werden, ohne dass sie von einem zentralen Scheduler angesteuert werden müssen. Diese Aktionenn sind auch zeitlich begrenzt im Vergleich zu dauerhaften Anweisungen eines zentralisierten oder hierarchischen Schedulers.
  • Manche Ressourcen wie etwa Prozessoren können auf eine Weise orchestriert werden, dass die Leistungsaufnahme optimiert wird. Die Leistungsstufen des Prozessors (z. B. PL1, PL2, PL3 usw.) werden zur Festlegung des Schwellenwertes für die Leistungsaufnahme verwendet. Die Systemplattform passt diese PL-Werte und andere Leistungswerte (Kappung, P-Zustand, Uncore-Frequenz) kontinuierlich feinkörnig an. Da es sich hierbei jedoch um eine komplexe Zuordnung handelt, da die Übertragungsfunktion, die Leistung und SLAs miteinander verbindet, stark zeit- und situationsabhängig ist, werden die Anpassungen durch vortrainierte Modelle gesteuert. Die vortrainierten Modelle verwenden als Eingaben verschiedene aus Zeitreihen abgeleitete Trendsignale über Auslastung und Leistung, und es kann sich im Allgemeinen um Modelle handeln, die auf grobkörnige Arten von Arbeitslastmischungen (z. B. „KI“, „gRPC heavy“, „Medien“ usw.) trainiert wurden.
  • Wenn der Kunde beim Registrieren von Funktionen Speicherungszugriffsabsichten äußert, stellen diese Registrierungsabsichten der Infrastrukturschicht ausreichenden Kontext bereit, um eine effiziente Datenverschiebung von der Speicherungsschicht zur Funktion zu ermöglichen. Dies erfolgt entweder durch Terminieren der Funktion direkt neben den Daten, durch den Einsatz von Rechenbeschleunigern auf Servern, die die Daten enthalten, oder durch Verwenden effizienter Datenübertragungsmechanismen innerhalb oder zwischen Servern. Der entscheidende Punkt ist, dass dies erreicht wird, ohne dass die Funktion spezifische Kenntnisse über den Standort des Servers benötigt oder spezifische Rechenressourcen oder Übertragungsmechanismen programmieren muss. Das Scheduling/die Platzierung ist eine Funktion zu Beginn eines Prozesses. Da die Zugriffsmuster zum Zeitpunkt der Bereitstellung möglicherweise nicht offensichtlich sind, implementiert dieses System auch eine Laufzeitbewertung der Datenlokalisierung und der Übertragungsraten und nutzt diese Erkenntnisse, um automatische Umplanungsereignisse auszulösen, z. B. Histogramme, die zeigen, welche Funktion/welcher Mikrodienst für die Verarbeitung welcher Art von Daten geeignet ist.
  • Das CIM 1016 sucht nach Möglichkeiten, den laufenden Betrieb effizienter zu gestalten, analysiert Kompromisse oder Änderungen in der Politik und ist für die Vorhersage des zukünftigen Verhaltens des Systems zuständig. Diese Vorhersage ist entscheidend für eine proaktive Planung. Es kann entweder eine reaktive oder eine proaktive Planung mit verschiedenen Zeitskalen verwendet werden (um die verschiedenen schnellen/langsamen Regelkreise zu erfüllen).
  • Der Monitor 1014 erhält Eingaben aus dem Beobachtbarkeitsstapel 1018 und verwendet diese Informationen, um den Planer 1012 und das CIM 1016 zu speisen oder auszulösen. Des Weiteren ist der Beobachtbarkeitsstapel 1018 dafür verantwortlich, dass die Erkenntnisse, Heuristiken usw. in der Wissensdatenbank 1020 durch Online-und Offline-Lernprozesse korrekt sind. Das Offline-Lernen kann durch eine experimentelle Charakterisierung der Arbeitslast erreicht werden. Der Beobachtbarkeitsstapel 1018 kann Trainingsdaten sammeln, damit sich die Architektur durch eine Analytik, die die gesammelten Daten verwendet, selbst weiterentwickelt. Die Trainingsdaten können aus realen Daten abgeleitet werden, die von Monitoren erfasst werden. Alternativ dazu können die Trainingsdaten offline aufbereitet und dem Beobachtbarkeitsstapel 1018 bereitgestellt werden. Die Verwendung eines CIM 1016 bietet den Vorteil, dass das System Fähigkeiten zur kontinuierlichen Verbesserungs aufweist und sich selbst anpasst, selbst heilt und optimiert.
  • Um für eine kontinuierliche Verbesserung zu sorgen, können mehrere Regelkreise implementiert werden. 11 ist ein Blockdiagramm, das einen Daten-und Steuerfluss in einem Orchestrierungssystem veranschaulicht, gemäß einer Ausführungsform. Absichtsbasierte SLOs werden an einem SLO-Übersetzer 1102 empfangen, der die übersetzten SLOs einem Dienstmonitor 1104 zuführt. Der SLO-Übersetzer 1102 kann eine Instanz, eine Komponente oder ein Bestandteil des Planers 1012 sein. Der Dienstmonitor 1104 kann eine Instanz, eine Komponente oder ein Bestandteil des Monitors 1014 sein.
  • Der SLO-Übersetzer 1102 kann eine Datenbank mit Regeln und Wörterbuchen (z. B. eine Wissensdatenbank 1020) verwenden, um das absichtsbasierte SLO auf drei Aspekte abzubilden: 1) Überwachungsparameter, 2) Konfigurationsparameter und 3) Zeitdomänenparameter.
  • Die Überwachungsparameter werden von dem Dienstmonitor 1104 bei der Überwachung von Diensten, Aufgaben oder Jobs verwendet. Zu den Überwachungsparametern können eine Reihe flexibler Leitplanken und die erforderliche Telemetrie gehören, damit der Dienstmonitor 1104 die Vorgänge aktiv überwachen kann.
  • Leitplanken können eine zeitlich und räumlich begrenzte Flexibilität bieten, so dass sie kontextsensitiv und situationsadaptiv werden. Die Leitplanken, die für die Funktion eines Orchestrators gelten, können sich daher sehr langsam, aber nahtlos verschieben, um eine Maximierung eines wünschenswerten Ende-zu-Ende-Ziels durch eine Reihe lokalisierter Spielräume zu ermöglichen. Die Idee besteht darin, drei wichtige Flexibilitäten zu erreichen: a) man nimmt die härteste Einschränkung - wie die P99.9-Latenz - und erlaubt ihr, sich von einem festen Schwellenwert in einen Schwellenwertbereich zu bewegen, sagen wir +10 Prozent für eine kurze Zeitspanne, um später durch eine noch bessere P99.9-Latenz für einen längeren Zeitraum zu kompensieren, b) man verschiebt eine möglicherweise kostspielige Anpassung der Ressourcenzuweisung zu einem bestimmten Zeitpunkt um eine bestimmte Zeitspanne und weicht in der Zwischenzeit die Leitplanken auf, so dass zufriedenstellende Lösungen weiterhin ausgeführt werden können, und c) man ermöglicht eine umfassendere Reaktion des Systems auf Notfälle, Anforderungen usw., um mit vorübergehenden Ausfällen in anderen Teilen eines Rechenzentrums fertig zu werden, die eine flexiblere gemeinsame Nutzung von Ressourcen erfordern, bis die Reparatur und der anschließende Normalbetrieb wieder aufgenommen werden können.
  • Bei den derzeitigen Verfahren für Leitplanken werden Schwellenwerte und die Integration über einen vordefinierten Zeitraum verwendet, um einen Leitplankenübergang und die anschließende Sanierung zu bewerten. Durch die Möglichkeit, Leitplanken „zustandsbasiert“ oder „kontextbasiert“ zu machen, können harte Beschränkungen unter bestimmten Bedingungen aufgeweicht werden. Beispielsweise kann die CPU-Auslastung bei der ersten Bereitstellung der Arbeitslast einen Spitzenwert erreichen, da die Arbeitslast Daten zwischenspeichert, aber nach dieser Zeit kann eine übermäßige CPU-Auslastung im normalen Betrieb eine Leitplankenüberschreitung auslösen. Das System fügt Kenntnisse über Kontext, einschließlich Lebenszyklus-Staging, in Dienstaktualisierungen, HA-Failover, Dienst-Mesh-Neustarts usw., als Kontextinformationen zum Implementieren von Leitplanken hinzu.
  • Die Konfigurationsparameter werden von Orchestratoren und Ressourcenmanagern verwendet, um Rechen-, Netzwerk-, Speicher- und andere Ressourcen zu konfigurieren. Die Konfigurationsparameter können als eine Reihe von Orchestrierungszielen ausgedrückt werden, die dem Orchestrierungssystem auf höchster Ebene zugeführt und von jeder unteren Schicht des Orchestrierungsstapels in eine Reihe von Subzielen umgewandelt werden. Am unteren Ende des Orchestrierungsstapels befinden sich physische Hardwarekomponenten, die mit feinkörniger Steuerung abgestimmt werden können. Von daher kann eine Reihe von Ressourcensteuerungen Richtlinien auf der Rechenplattform durchsetzen. Bei der Rechenplattform kann es sich um eine CPU, GPU, FPGA, einen Beschleuniger, eine IPU oder eine andere Art von Verarbeitungsvorrichtung handeln.
  • Die Zeitdomänenparameter werden zur Konfiguration der Regelkreise verwendet, um die Überwachungszyklen und die Häufigkeit von Änderungen der Konfigurationsparameter festzulegen. Der SLO-Übersetzer 1102 erzeugt Zeitdömänen für die SLO-Überwachung, die von der Nichtechtzeitüberwachung bis zur Echtzeitüberwachung reichen. Die Zeitdomänen spezifizieren strenge Rückmeldeantwortzeiten der Überwachung und Orchestrierung für das entsprechende SLO. Die Zeitdomänen sind in 11 in subjektiver Terminologie als „langsamer“, „langsam“ und „schneller“ dargestellt, können aber in jedem beliebigen Zeitmaß angegeben werden, wie z. B. Mikrosekunden, Stunden, Tage oder dergleichen, je nach den Anforderungen, die der SLO-Übersetzer 1102 dem Zeitbereich zuordnet. Diese Zeitdomänenparameter können feststehen, automatisch aktualisiert werden oder separat konfigurierbar sein.
  • Der Dienstmonitor 1104 weist Schichten auf, die Telemetrie 1106, Nichtechtzeit-Telemetrie 1108, echtzeitnahe Telemetrie oder Echtzeit-Telemetrie 1110 überwachen. Jede Schicht hat einen entsprechenden Regelkreis, der unterschiedliche Zeitdomänenparameter aufweisen kann.
  • Der SLO-Übersetzer 1102 wandelt die Absichten in eine „Service-Level-Überwachung“ für E2E, langsame Ressourcenüberwachung und schnelle Ressourcenüberwachung um. Basierend auf Regeln, Richtlinien und gelernten Erkenntnissen ordnet der SLO-Übersetzer 1102 die Absicht einem oder mehreren Dienstmonitoren zu ab, die basierend auf der Art der Absicht, der erforderlichen Reaktionsgeschwindigkeit oder anderen Anforderungen instanziiert werden können. Der SLO-Übersetzer 1102 konfiguriert die Dienstmonitore so, dass sie Benachrichtigungen an Entitäten im Orchestrierungsstapel liefern, wenn die „physischen SLAs“ oder „physischen SLOs“ außerhalb der Grenzen liegen. Dienstmonitore können klassische Dienstsicherungslösungen zum Überwachen von E2E-SLAs mit passiven oder aktiven Sonden, softwaredefinierter Netzwerksteuerungen (SDN) oder SDN-Analysesysetemen beinhalten. Schnellere Dienstüberwachungen können nach Bedarf auf den Plattformen kolokalisiert werden, um die Reaktionszeit zu erreichen, die von dem abgebildeten SLO benötigt wird.
  • Das System kann Verfahren zur intelligenten Beobachtung einsetzen, zum Beispiel beim Einsatz von Komponenten und wie die Überwachung am richtigen Ort automatisch einzusetzen ist. Nach dem Einsatz der Komponenten kann das System einen Teil des Regelkreises bilden, der eine automatische SLW-Abhilfe erreicht. Wenn ein Abhilfefall vorliegt, stellt das System sicher, dass ausreichend Steuerungen an Ort und Stelle sind, um eine Abhilfemaßnahme bereitzustellen, die effektiv ist und sich nicht unbeabsichtigt auf andere Dienste auswirkt.
  • Wie in 11 veranschaulicht, kann absichtsbasierte Orchestrierung unter Verwendung einer Hierarchie von Orchestratoren 1112-1114 implementiert werden. Ein Standard-Orchestrator ermöglicht es dem Benutzer, eine Anwendung als einen Satz von Komponenten und Anforderungen zum Landen dieser Komponenten auf Plattformen zu beschreiben. Eine hierarchische Orchestrierung kann verwendet werden, um ein Problem in Teile zerlegen und verteilen zu können, wobei ein Suborchestrator für das Planen einer Teilmenge der Anwendung auf einer Teilmenge von Knoten verantwortlich ist und ein anderer Suborchestrator für das Planen einer anderen Teilmenge der Anwendung auf einer anderen Teilmenge von Knoten verantwortlich ist.
  • Im Gegensatz zu einer standardmäßigen unbedingten Orchestrierung kann eine absichtsbasierte Orchestrierung aktiviert werden, indem dem Benutzer ermöglicht wird, als Teil der Anforderungen einer Komponente eine Absicht zu beschreiben. Dies ist ein deklarativer Mechanismus, bei dem der Benutzer ein gewünschtes Ergebnis deklariert. Anstatt spezifische Regeln oder Parameter anzugeben (wie etwa bei unbedingten Mechanismen), kann der Benutzer ein gewünschtes Ergebnis angeben. Ein Beispiel wäre die Erreichung eines bestimmten Verfügbarkeitsniveaus oder einer maximalen Verarbeitungslatenz, für die mehrere Instanzen auf Knoten mit bestimmten Eigenschaften bereitgestellt werden können, um dieses Ziel zu erreichen. Eine Absicht ist ein deklarativer Ausdruck.
  • Anstatt eine absichtsbasierte Orchestrierung tief in den Scheduler eines Standard-Orchestrators zu integrieren, kann ein absichtsbasierter Scheduling-Algorithmus in einem Suborchestrator eingesetzt werden. In diesem Fall kann der Standard-Orchestrator der obersten Ebene, wenn er die Anwendungsbeschreibung empfängt, eine Absicht erkennen, die für eine oder mehrere Komponenten der Anwendung spezifiziert ist. Er kann kann einen absichtsbasierten Sub-Orchestrator mit der Planung dieser Komponenten beauftragen. Jeder absichtsbasierte Orchestrator oder Suborchestrator kann sich auf die Erfüllung bestimmter Arten von Absichten spezialisieren. Der absichtsbasierte Suborchestrator kann das Problem weiter in andere Suborchestratoren aufteilen.
  • Man betrachte zum Beispiel eine Videoanalysepipeline, die aus einem Aufnahmeschritt, einem Verarbeitungsschritt und einem Betätigungsschritt besteht. Die Gesamtanwendung kann als eine Aufnahmekomponente für jede Kamera, ein Verarbeitungsschritt mit einer Absicht von höchstens 100 ms Latenz und eine Betätigungskomponente für jeden Aktuator beschrieben werden. Der Orchestrator der obersten Ebene kann die Bereitstellung der Einnahme- und Betätigungskomponenten handhaben. Die Verarbeitung könnte an einen absichtsbasierten Orchestrator übergeben werden, der bestimmen könnte, wie viele Verarbeitungskomponenten benötigt werden, um die Last auszugleichen und die gewünschte Latenz zu erreichen. Der absichtsbasierte Orchestrator kann die Aufgabe sogar auf zusätzliche Suborchestratoren aufteilen, so dass mehrere Cluster von Knoten verwendet werden, um die Absicht zu erreichen (oder vielleicht eine zusätzliche Absicht der Hochverfügbarkeit auf Clusterebene zu ermöglichen).
  • Dieser Ansatz hat mehrere Vorteile. Erstens ist es nicht notwendig, die komplexe Entscheidungsfindung bestehender Scheduling-Algorithmen in bestehenden Orchestratoren mit der gleichermaßen komplexen Entscheidungsfindung der absichtsbasierten Orchestrierung zu kombinieren. Jeder kann für die wichtigsten Teile des Problems verwendet werden. Außerdem ermöglicht die verteilte Entscheidungsfindung, die Entscheidung in die Nähe der Verarbeitung zu verlagern. Dies kann eine schnellere Reaktionsfähigkeit ermöglichen, wodurch schnelle Regelkreise in industriellen Anwendungsfällen möglich werden.
  • In verschiedenen Ausführungsformen ist ein Orchestrator der obersten Ebene dazu ausgelegt, programmiert oder anderweitig angepasst, Absichten von einem Kunden zu empfangen, zu erkennen, wann eine absichtsbasierte Suborchestrierung erforderlich ist, und Interaktionen zwischen dem Orchestrator der obersten Ebene und Suborchestratoren zu definieren. Der Orchestrator der obersten Ebene kann ein Standard-Orchestrator sein und die Suborchestratoren können ein absichtsbasierter Orchestrator sein, wie etwa einer, der in 10 beschrieben ist. Durch Verwenden einer Hierarchie von Orchestratoren wird das Problem nach unten verlagert, wobei zwischen dem übergeordneten Orchestrator und dem Sub-Orchestrator eine SLA vereinbart wird. Der Suborchestrator kann dem anfordernden Orchestrator mitteilen, wann er die SLA nicht mehr einhalten kann.
  • Um diese Organisation von Orchestratoren zu erreichen, sollten Absichten so ausgedrückt werden, dass sie mit Standard-Orchestratoren kompatibel sind, und diese Standard-Orchestratoren sollten in der Lage sein zu erkennen, wann eine absichtsbasierte Suborchestrierung erforderlich ist. Zwischen dem anfordernden Orchestrator und den Suborchestratoren, die zum Erfüllen der Anforderungen des anfragenden Orchestrators eingesetzt werden, kann ein Protokoll verwendet werden.
  • Wenn eine Anwendung in Komponenten aufgeteilt wird, die separat orchestriert werden, können sie ferner Ordnungsabhängigkeiten aufweisen, die Gesamtorchestrierung beeinflussen. Wenn solche Ordnungsabhängigkeiten vorhanden sind, können sie abstrakt beschrieben werden. In einem Anwendungsfall eines Erzeuger-Verbraucher-Flusses kann zum Beispiel spezifiziert werden, dass die erzeugende Komponente X Einheiten von Daten, Ereignissen, Frames usw. wunschgemäß vor der Verbrauchskomponente bereithalten soll. Dementsprechend können die Suborchestratoren für jede Komponente bedingte Zuständigkeiten für die Zuweisung von Ressourcen haben (der Verbraucher benötigt weniger Ressourcen zum Zeitpunkt T0 als zum Zeitpunkt T0+Delta, während der Erzeuger mehr Ressourcen zum Zeitpunkt T0-Delta benötigt als zum Zeitpunkt T0). Diese „Ressourcenflüsse“ werden unter den Suborchestratoren eng koordiniert, so dass der Erzeuger und Verbraucher in unserem Beispiel kollektiv einen X-Anteil der CPU, des Caches, der Speicherbandbreite usw. erhalten, wobei die Ressourcen jedoch nahtlos gemäß der choreographierten Aufteilung zwischen ihnen fließen. Gleichermaßen müssen Prioritätsumkehrungen verhindert werden; so kann ein Erzeuger zwar eine niedrigere Priorität haben, weil etwa der Verbraucher sich bemüht, aufzuholen und den Abstand zum Erzeuger zu verringern, aber wenn der Verbraucher den Abstand weiterhin so schnell verringert, dass der Erzeuger nun darum kämpfen muss, vorne zu bleiben, dann ist es sinnvoll, dass die Prioritäten als Funktion des Abstands schnell zwischen den beiden fließen, anstatt dass die Planungssoftware aufwändig eingestellt werden muss.
  • Um die geforderten Absichten/Ziele zu erreichen, kann der Bedarf an Beschleunigungstechnologie (FPGAs, GPUs usw.) sowie an Hardwarefunktionen zur Unterstützung des Gesamtaufbaus (z. B. DRC) implementiert werden. Häufig führen Beschleuniger und XPUs Operationen aus, die ein Entwickler des CPU-Codes nicht direkt über Anweisungen steuert. Somit können sensible Operationen, die mit einem gewissen Hardwareprivileg in einem Beschleuniger oder einer XPU oder auf eine für gewöhnliche Software undurchsichtige Weise in höheren Ebenen des Stapels durchgeführt werden, die Sicherheitsgrenzen vereinfachen, die anderenfalls eine gemeinsame Planung von Sicherheitsfilterungsoperationen erfordern würden. Des Weiteren müssen untergeordnete Funktionen die verschiedenen Regelkreise darüber informieren, was in schnellen Regelkreisen geschieht. Diese Art der Berichterstattung erfordert Erweiterungen/die Nutzung von Beobachtbarkeitsrahmen zum Verfolgen, Protokollieren und Überwachen.
  • 12 ist ein Flussdiagramm, das ein Verfahren 1200 zum Implementieren einer absichtsbasierten Orchestrierung veranschaulicht, gemäß einer Ausführungsform. Bei 1202 wird ein absichtsbasiertes Service-Level-Ziel (SLO) zur Ausführung einer Aufgabe an einem Orchestrator empfangen.
  • Bei 1204 wird das SLO auf mehrere Richtlinien abgebildet. Die Abbildung kann auf einer statischen Karte basieren. Alternativ dazu kann die Abbildung unter Verwendung von Heuristiken oder anderen intelligenten Mechanismen durchgeführt werden.
  • Bei 1206 werden die mehreren Richtlinien an mehrere Suborchestratoren verteilt, wobei jeder der mehreren Suborchestratoren die Ausführung eines Teils der Aufgabe verwaltet. Richtlinien können nach Art, Ressource oder anderen Faktoren gruppiert oder getrennt werden. Die Suborchestratoren können für eine Gruppe von Ressourcen, einen Ressourcentyp, einen speziellen Knoten oder Satz von Knoten oder dergleichen verantwortlich sein.
  • Bei 1208 wird die Ausführung der Aufgabe überwacht. Die Aufgabenüberwachung kann durch Definieren von KPIs von Interesse und dann wiederkehrendes Erhalten von Daten zu diesen KPIs durchgeführt werden.
  • Bei 1210 wird eine Abhilfemaßnahme basierend auf der Überwachung initiiert. Abhilfemaßnahmen können Operationen wie Migration, Ressourcenzuweisung oder freigabe, Neustarten oder Aussetzen eines Prozesses, Containers, Pods oder Mikrodienstes oder dergleichen beinhalten.
  • In bestehenden orchestrierten, verteilten Rechenumgebungen können Hunderte oder sogar Tausende von Mikrodiensten eingesetzt werden. Ein großer Schwerpunkt bei absichtsgesteuerten Orchestrierungsmodellen liegt auf der Absicht aus der Benutzer- oder Mandantenperspektive. Die oben in den 8 bis 12 besprochenen Implementierungen sind hauptsächlich aus der Perspektive des Hosts oder der Plattform gesehen. Es gibt mehrere andere Perspektiven, wie etwa die des Cloud-Administrators oder dem InfrastrukturAdministrators, die auch von der Spezifizierung ihrer Service-Level-Ziele (SLOs) im dem Datenzentrum oder Cluster profitieren können.
  • In einem Infrastruktur-as-a-Service (IaaS)-Modell und vielen ContainerClustermodellen basiert die administrative Steuerung auf einer unbedingten Stilspezifikation von Konfigurationen, die Administratoren in das System laden. Zum Beispiel kann eine Region „Stapeln“ von VMs auf Server priorisieren, bis der gesamte Speicher zugewiesen ist, bevor VMs auf dem nächsten Server zugewiesen werden. Dies ist eine unbedingte Anfrage, die zu SLO-Fehltreffern auf Mandantenebene führen kann, zum Beispiel aufgrund rauschbehafteter Nachbareffekte, die durch diese Konfiguration eingeführt werden. Der Administrator wollte wahrscheinlich als Ziel erreichen, den Leistungsverbrauch im Cluster zu minimieren, und nahm an, dass ein kapazitätsbasiertes Packen der Speicher und Ruhezustandsserver der beste Weg zur Erreichung dieses Ziels sei. In diesem konstruierten Beispiel kann ein unerwartetes Ergebnis sein, dass Arbeitslasten aufgrund der beschränkten Ressourcen länger ausgeführt werden mussten, um die Jobs abzuschließen, und schlussendlich insgesamt mehr Leistung verbraucht wurde. Obwohl der Administrator versucht hat, eine Konfiguration auf unterer Ebene an Ort und Stelle zu platzieren, um ihren Wunsch zu erfüllen, führt die fehlende Sichtbarkeit auf einer höheren Ebene daher zu Ineffizienzen.
  • Wie erörtert, ermöglichen bestehende Techniken den Administratoren, unbedingte Richtlinien darüber festzulegen, wie genau ein Cluster reagieren sollte, wenn ihm ein Satz von (auch unbedingten) Einsatzkriterien auferlegt wird. Die Administratoren können dann komplexe Richtlinien definieren, um den Cluster zu prüfen und sicherzustellen, dass er konfiguriert ist, um diese Kriterien widerzuspiegeln. Wichtig ist jedoch, dass die Richtlinienauditierungsfunktion nicht prüft, dass das Verhalten wie beabsichtigt ist. Es wird eine Möglichkeit benötigt, das administrative Modell in eine Absicht oder SLO-Domäne zu verschieben, so dass Administratoren das Verhalten spezifizieren können, das sie wünschen (z. B. Absicht), anstatt wie es zu erreichen ist.
  • Hier beschriebene Systeme und Verfahren stellen eine Möglichkeit bereit, zu evaluieren, welches Verhalten der administrative Benutzer vom Cluster wünscht. Dies steht im Gegensatz zu Systemen, die es Administratoren ermöglichen, mit Aussagen zu definieren, wie der Cluster arbeitet. Die Systeme und Verfahren behandeln die Herausforderung, komplexe, verteilte Infrastruktur administrativ zu regeln, indem SLO-orientierte Steuerungen den Cluster-und Infrastrukturadministratoren an die Hand gegeben werden, wodurch sie von der Last befreit werden, Konfigurationsdetails auf unterer Ebene spezifizieren zu müssen, die falsch sein können oder unbeabsichtigt Ineffizienzen verursachen können.
  • 13 ist ein Blockdiagramm, das eine Orchestrierungsarchitektur 1300 mit administrativen Erweiterungen gemäß einer Ausführungsform veranschaulicht. Zur Orchestrierungsarchitektur 1300 werden eine administrative Richtliniensteuerungs-Engine 1302 (APC: Administrative Policy Control) und eine administrative Richtlinienübersetzungs-Engine 1304 (APT: Administrative Policy Translation) hinzugefügt.
  • Ein Arbeitsablauf zum Verwalten mehrerer Ebenen absichtsgesteuerter Verwaltungsrichtlinien in dem Arbeitsablauf der Arbeitslastbereitstellung nutzt die Richtliniensteuerung und Richtlinienübersetzungskomponenten. Eine Regelung administrativer Richtlinien wird verwendet, um absichtsbasierte SLOs zu überwachen und zu prüfen. Das Orchestrierungssystem kann eine Platzierung und Neuverteilung der Arbeitslast als Reaktion auf sich ändernde administrative Richtlinien oder bei Nichteinhaltung administrativen Richtlinien beeinflussen.
  • Die APC-Engine 1302 verwaltet die absichtsbasierte SLO-Spezifikation des Administrators. Sie übernimmt administrative SLOs als Eingabe und überwacht die Cluster/Server auf Erfüllung der genannten Ziele. Die APC-Engine 1302 kann einen Zeitrahmen der Beurteilung, „Burst“-artige Untererfüllung/Übererfüllung der Konformität und statistische Einhaltung der SLOs berücksichtigen. Sie kann auch dazu dienen, hörbare Daten zur Einhaltung einer absichtsbasierten SLA höherer Ordnung zu erfassen.
  • Die APT-Engine 1304 bildet die Eingabe-SLOs als unbedingte Konfigurationen ab. Die APT-Engine 1304 optimiert auch dynamisch die Abbildung basierend auf Eingaben von der APC 1302, um Clusterkonfigurationen zu erzeugen, die mit der absichtsbasierten administrativen SLA konsistent sind. Die Abbildungen können statische Abbildungen sein, die vorbestimmt sind. Die Abbildungen können zeitbasierte Abbildungen sein, die sich mit der Zeit entwickeln, rotieren oder sich ändern. Die Abbildungen können unter Verwendung von maschinellem Lernen bestimmt werden. Die Abbildungen können unter Verwendung unterschiedlicher Kostenfunktionen unter unterschiedlichen Bedingungen (z. B., wie eine Zuweisung einer speziellen Ressource zu einem Teil der Anwendung den SLO beeinflusst) bestimmt werden.
  • Die APT-Engine 1304 arbitriert und interpretiert die Priorität zwischen verschiedenen SLOs und verschiebt Konfigurationen in die Infrastruktur. Beispielsweise kann die APT-Engine 1304 eine Schnittstelle mit einem Scheduler 1308, einer Steuerung 1310 oder einem Ressourcenmanager 1312 bilden. Sobald sich neue Richtlinien in der Infrastruktur befinden, können typische Orchestrierungsanweisungsverwaltungsmaschinen arbeiten, um den Cluster in den erforderlichen Zustand zu versetzen.
  • Unter Verwendung der API 1306 ist ein administrativer Benutzer in der Lage, absichtsbasierte SLAs zu übermitteln, die Anwendungsausführung zu überwachen, Richtlinienausnahmen zu überwachen, Konfigurationsänderungen zu überwachen und dergleichen. Es gibt einen breiten potentiellen Satz von Zielen, die Cluster- und Infrastrukturadministratoren berücksichtigen müssen. Dazu gehören unter anderem: Leistungsüberwachung, Leistungsbudget und Leistungsbegrenzung, HardwareInfrastrukturkonfiguration, Netzwerkkonnektivität auf Knoten- und Leaf-/Spine-/Rack-Ebene, Ressourcenbestandsverwaltung, Aktivierungen, Aktualisierungen, Abstufungen, End-of-Life-Ereignisse, Sicherheit und Datenschutz pro Mandant, Resilienz- und Redundanzattribute usw.
  • Die APC-Engine 1302 kann die Infrastruktur überwachen, und falls es danach aussieht, dass eine SLO-Anforderung verfehlt wird, kann die APC-Engine 1302 die APT-Engine 1304 anweisen, eine korrigierende oder Abhilfemaßnahme zu ergreifen. Die APC-Engine 1302 kann Telemetrie von einem Beobachtbarkeitsstapel 1314 empfangen. Der Beobachtbarkeitsstapel 1314 kann Infrastrukturtelemetrie, Plattformtelemetrie, Arbeitsablauftelemetrie, Anwendungsausführungstelemetrie oder dergleichen aggregieren, analysieren oder sammeln.
  • Als Beispiel kann im Kontext eines Aktualisierungsarbeitsablaufs eine Absicht als Ziel festgelegt werden, die neueste Version des Betriebssystems an 95 % der Knoten innerhalb von drei Tagen nach Beginn des Arbeitsablaufs der Aktualisierung mit höchstens 0,1 % Stillstandszeit für kritische Arbeitslasten und höchstens 1 % Stillstandszeit für Arbeitslasten mit niedriger Priorität während der Aktualisierungen einzusetzen. Falls während der Ausführung des Aktualisierungsarbeitsablaufs eine Anforderung anscheinend Gefahr läuft, nicht erfüllt zu werden, kann eine korrigierende Maßnahme ausgeführt werden. Die korrigierende Maßnahme kann darin bestehen, eine maximale Zusammenstellung von Arbeitslasten innerhalb der Umgebung zu unterzubringen, so dass Server freigegeben werden können, um den Fortgang der Aktualisierung zu gewährleisten, während die Betriebsbereitschaft aufrechterhalten wird. Dies kann auf Kosten eines Leistungsabfalls der Arbeitslast gehen, der basierend auf den SLOs als akzeptabel angenommen wird. Außerdem erfordern zustandsorientierte Arbeitslasten, insbesondere bei großvolumigen Zustandsaktualisierungen, eine größere Sorgfalt bei der Arbeitslastmigration. Daher kann die administrative Richtlinie zusätzlich zum Planen für Wartungsereignisse vorschreiben, dass diese Arten von Arbeitslasten eine gestufte Migration (Colokation) mit einer Reihe progressiver Checkpunkte erfahren, gefolgt von einer aktiven Spiegelung, bevor ein Hot-Cutover durchgeführt und Server für das Upgrade freigegeben werden.
  • Administrative Richtlinien können für eine Vielzahl von Kontexten verwendet werden. Administrative Richtlinien können zeitbasierte Einschränkungen beinhalten. Beispielsweise können lange laufende „Batch-Jobs“ zeitlich verschoben werden, um Möglichkeiten zur Kolokation mit anderen Jobs mit komplementärem Ressourcenverbrauch oder SLA-Charakteristiken zu maximieren. Verwaltungsrichtlinien auf Cluster-Ebene können auch Direktiven und Mechanismen zum Maximieren von Auslastung, Leistungseffizienz, Lokalisierung und Cache-Effizienzen durch Gruppen-Scheduling beinhalten, die nachträglich eine zeitliche Anpassung bereitstellen. Um solche Richtlinien zu implementieren, kann die APC-Engine 1302 anfänglich eine Greedy-Strategie verwenden, um die Ausführung erst zu starten, und dann eine Lademigration durchführen, um den gewünschten Multiplextyp zu erreichen.
  • Ein Infrastrukturadministrator ist eine von anderen Arten von Systemadministratoren getrennte Rolle. Der Infrastrukturadministrator ist zuständig für Leistungsüberwachung, Leistungsbudget, Leistungsbegrenzung, Konfiguration der Hardwareinfrastruktur (Außer-Band und In-Band), Sicherheit und Datenschutz, Resilienz, L3-Netzwerkkonnektivität (Leaf/Spine, Rack usw.), Inventarverwaltung und dergleichen.
  • Für jede dieser Zuständigkeiten kann eine absichtsbasierte administrative Richtlinie definiert werden. Die APC-Engine 1302 interpretiert die Richtlinie, was zu einer Abbildung auf SLO-Richtlinien führt, die durch domänenspezifische Infrastruktur- und Vernetzungssteuerungen durchgesetzt werden.
  • Ein anderer Aspekt der Orchestrierungsarchitektur 1300 stellt Datenschutz und Anonymisierung bereit. Unter Verwendung der API 1306 kann ein administrativer Benutzer, Mandant oder eine Anwendung eine Datenanonymisierungsabsicht bereitstellen. Beispielsweise kann es sensible KPIs geben, die zugrundeliegende Informationen offenbaren, die der Benutzer, Mandant oder die Anwendung nicht preisgeben möchte. Verschiedene Transformationen können vom Telemetriesammler (z. B. Beobachtbarkeitsstapel 1314) verwendet werden. Transformationen, die die Daten auf unterschiedliche Weisen verschleiern, können für unterschiedliche Niveaus des Datenschutzes oder der Datenempfindlichkeit verwendet werden. Es kann einer Anwendung erlaubt sein, bestimmte Infrastrukturbibliotheken zu verwenden, die in einer Sicherheitsenklave laufen würden. Die Bibliotheken können die KPI verarbeiten und sie der Infrastruktur als eine aussagekräftige KPI bereitstellen. Daten können auf eine Weise verschleiert werden, die eine gemeinsame Nutzung von Daten zwischen Entitäten ermöglicht (z. B. Verwenden eines gemeinsamen Schlüssels oder eines anderen Mechanismus, um verschiedenen Parteien zu ermöglichen, die KPI-Daten zu verstehen).
  • Ein anderer Aspekt der Orchestrierungsarchitektur 1300 ist durch den Dienstanbieter oder Ressourceneigentümer konfigurierbar. Unter Verwendung der API 1306 oder eines anderen Mechanismus kann ein administrativer Benutzer Richtlinien oder Leitplanken festlegen, die die Orchestrierungsarchitektur 1300 konfigurieren , um eine absichtsgesteuerte Orchestrierung zu ermöglichen. Die Menge an Flexibilität, Betriebsfähigkeit oder Fähigkeiten einer Plattform oder eines Clusters kann basierend auf dem Kundentyp, Kundengebühren oder dergleichen angepasst werden. Beispielsweise werden Kunden mit niedriger Zahlung möglicherweise nicht das gleiche QoS-Niveau wie Kunden mit hoher Zahlung bereitgestellt, selbst wenn beide Kunden ähnliche Absichten ausdrücken. Dieser Mechanismus kann Wege zum Abstimmen und Verschieben von Dienstprogrammfunktionen, die Systeme lenken, und die Verwendung von Ressourcen nutzen, während der Kunde nur mit Zielen arbeitet.
  • Ein anderer Aspekt der Orchestrierungsarchitektur 1300 stellt eine Möglichkeit bereit, eine verfügbare „Reserve“ von Ressourcen auszudrücken. Bei verschiedenen Implementierungen kann die Orchestrierungsarchitektur 1300 Metriken offenlegen, die Latenzgrenzen, Bandbreitengrenzen, CPU-Zyklusgrenzen oder dergleichen angeben. Zum Beispiel kann die Orchestrierungsarchitektur 1300 veröffentlichen, dass eine Arbeitslast X innerhalb der Grenzen von 10 ms < Latenz < 100 ms basierend auf verfügbaren Ressourcen ausgeführt werden kann.
  • Ein anderer Aspekt der Orchestrierungsarchitektur 1300 stellt eine Ressourcenreservierung bereit. Ein Kunde kann eine Absicht bereitstellen, die einen zukünftigen Bedarf an einer Ressource angibt. Anwendungen können einen Mechanismus zum Ausdrücken zukünftiger Absichten aufweisen, die in SLAs abgebildet werden. Dies kann berücksichtigt werden, um eine bessere SLA/ein besseres SLO bereitzustellen. Das Reservieren von Ressourcen kann ein kostenbasierter Dienst sein. Eine Anwendung kann eine Reservierung aufheben. In Abhängigkeit von der SLA oder anderen Faktoren kann die Aufhebung immer noch eine Gebühr verursachen.
  • Ein anderer Aspekt der Orchestrierungsarchitektur 1300 bietet eine Strategie des Teilens und Herrschens für die Bereitstellung. Insbesondere kann die Orchestrierungsarchitektur 1300 Strategien des Teilens und Herrschens zur Skalierung anwenden, indem der Gesamtfluss in mehrere gleichzeitige clusterweite parallele Operationen aufgeteilt wird, die wie folgt sind: (a) Anfragen nach und Empfangen potenzieller Ressourcenverfügbarkeit und Kostenfunktionen in großem Maßstab ohne einen zentralisierten Koordinator, (b) Bewerten von Antworten und Identifizieren bester Anpassungen und (c) Reservieren/Bereitstellen und Versenden von Anforderungen auf bereitgestellten Ressourcen (Scheduling), Sammeln von Ergebnissen und Bewerten.
  • Eine ICN-Lite-Strategie für Telemetrieflüsse kann verwendet werden, um Verfügbarkeitsinformationen (a) dezentral zu erhalten, die dezentral zwischen Anforderungspunkten und Zustellungspunkten aggregiert sind, und dies ermöglicht eine lokale Filterung nach Ressourcen, die bereits für eine Berechnung mit höherer Priorität und/oder Infrastrukturdienste zugesichert oder zugesagt sind. Anforderungen und ihre Kostenbeschränkungen können mit solchen Informationen an mehreren Abgleichern im Netzwerk in (b) abgeglichen werden und optimal angepasste Abgleichungen sowohl an Anforderer als auch Lieferanten gesendet werden. Und in (c) führt die Steuerebene dann die notwendige Bereitstellung und Versendung durch, bewertet aber auch die Ergebnisse dieser Entscheidungen, so dass Abgleich und Bewertung in nachfolgenden Operationen verbessert werden können (Operationen a und b). Mit dem Ankündigen von Verfügbarkeiten von Ressourcen anstatt zu warten, dass sich Anforderungen erfüllen, können Anbieter Interessenpakete oder Nachrichten senden, in denen sie verfügbare Ressourcen für Zeitintervalle angeben, die in nachfolgenden Nachrichten zu revidieren sind. Somit können diese Interaktionen durch Bieter, Lieferanten sowie Zuordner, die verfügbare Ressourcen in ähnlichen Kostenklassen für die Bieter oder Lieferanten aggregieren, frei initiiert werden.
  • Ein anderer Aspekt der Orchestrierungsarchitektur 1300 stellt eine Orchestrierung von Hardwarekonfigurationen sowie Softwarekonfigurationen bereit. Die Orchestrierungsarchitektur 1300 kann Softwarekonfigurationen eines Hypervisors, Gast-OS, Infrastruktur-und Vernetzungssoftwarebibliotheken, Sprachhostsysteme wie virtuelle Java-Maschinen (JVMs) usw. steuern. Die Scheduler 1308 sind in der Lage, eine Knotenmerkmalsentdeckung oder Knotenprofilentdeckung zu verwenden, um Knotenkonfigurationen zu inspizieren.
  • Ein anderer Aspekt der Orchestrierungsarchitektur 1300 stellt eine Knotenwartung bereit. Die Knotenwartung wird zu einem größeren und komplexeren Problem, da die Anzahl an Knoten und Arbeitslasten im Cluster wächst. Wenn ein Knoten eine Wartung benötigt, müssen gegenwärtig ausgeführte Arbeitslasten ausgeleitet werden und der Knoten außer Dienst gestellt werden. Eine absichtsgesteuerte Knotenverwaltungslösung kann verwendet werden, um die Wartung eines Satzes von Knoten im Cluster zu unterstützen. Da Knoten wahrscheinlich hinsichtlich der Fähigkeiten heterogen sind, sind auch Arbeitslasten heterogener Natur mit unterschiedlichen Anforderungen und Einschränkungen. Die Orchestrierungsarchitektur 1300 dient dazu, um die betriebliche Auswirkung von Arbeitslasten zu minimieren und die Verwaltungseffizienz zu maximieren, während Arbeitslasten von Knoten migriert werden, die in den Wartungsmodus gesetzt werden, indem die Arbeitslastplatzierung und Auswahl davon beeinflusst wird, welche Knoten nicht parallel außer Dienst gestellt werden.
  • Ein anderer Aspekt der Orchestrierungsarchitektur 1300 stellt eine gestufte Migration bereit. Zustandsorientierte Arbeitslasten, insbesondere bei großvolumigen Zustandsaktualisierungen, erfordern größere Sorgfalt bei der Arbeitslastmigration. Daher kann die Orchestrierungsarchitektur 1300 zusätzlich zur Planung für Wartungsereignisse eine gestufte Migration einer Reihe progressiver Checkpunkte gefolgt von aktiver Spiegelung durchführen, bevor ein Hot-Cutover durchgeführt wird. Es kann eine progressive Zustandskonvergenz durchgeführt werden, ohne die echten wenigen großen Kerne zu dedizieren, und somit können große Kerne spät in der Migration zugewiesen werden, erst dann, wenn ein Hot-Cutover mit minimalem Latenzjitter notwendig ist. Eine gestufte Migration kann als Teil einer absichtsbasierten Richtlinie ausgedrückt werden.
  • 14 ist ein Blockdiagramm, das einen Daten- und Steuerfluss zum Implementieren administrativer Absichten veranschaulicht, gemäß einer Ausführungsform. Beim Starten eines Clusters (Zustand 1400) werden administrative Absichtsrichtlinien definiert (Operation 1402). Die Absichtsrichtlinien können Richtlinien auf Cluster-Ebene oder Richtlinien auf Knoten-Ebene oder eine Kombination sein. Die Richtlinien werden an die administrative Richtliniensteuerlogik 1404 und die administrative Richtlinienübersetzungslogik 1406 weitergeleitet.
  • Die Verwaltungsrichtlinienübersetzungslogik 1406 wandelt die Absichtsrichtlinien in unbedingte Konfigurationen um und setzt die Konfigurationen ein (Operation 1408). Unter Verwendung eines mehrschichtigen Ansatzes werden SLAs mit Absichten in SLOs übersetzt. Die SLOs und die Absicht werden dann in Richtlinien übersetzt, die dann als Konfigurationen implementiert werden. Es kann Abbildungen zwischen jeder Schicht geben. Beispielsweise kann ein Satz von Absichten zu einem Satz von Richtlinien führen, die wiederum zu einem Satz von Konfigurationen führen. Welche Konfiguration zu welchem Zeitpunkt ausgewählt wird, hängt von einer Gesamtorchestrierungsstrategie ab.
  • Ein Ereignis, das angibt, dass sich die Richtlinien geändert haben, wird ausgelöst (1410), was eine Wiederbereitstellung von Arbeitslasten initiiert hat (Operation 1412).
  • In dem Ablauf der Arbeitslastbereitstellung 1414 wird bei der anfänglichen Bereitstellung die Arbeitslastbereitstellungsspezifikation verarbeitet (Operation 1416) und die Arbeitslast wird bereitgestellt (Operation 1418). Die Arbeitslast wird überwacht (Operation 1420) und Richtlinien auf Arbeitslastebene können in Abhängigkeit von der Telemetrie durchgesetzt werden.
  • Die Verwaltungsrichtliniensteuerlogik 1404 empfängt Telemetrie von der Infrastrukturüberwachung (1422) und verwendet die Telemetrie, um zu bestimmen, ob Verwaltungsrichtlinien gefährdet sind. Die administrative Richtliniensteuerlogik 1404 prüft auf Konformität (Entscheidungsblock 1424). Dies kann periodisch (z. B. alle 10 Sekunden) oder basierend auf Ereignisauslösern (z. B. CPU-Nutzung über einem Schwellenwert) erfolgen. Falls die Infrastruktur einer administrativen Richtlinie entspricht, dann fährt die Überwachung fort.
  • Falls eine administrative Richtlinie nicht konform ist, dann sendet die administrative Richtliniensteuerlogik 1404 eine Steuernachricht an die administrative Richtlinienübersetzungslogik 1406, die angibt, dass die Absicht neu evaluiert und eine neue unbedingte Abbildung bestimmt werden soll (Operation 1426). Die administrative Richtlinienübersetzungslogik 1406 erzeugt neue unbedingte Konfigurationen und verschiebt sie zur Bereitstellung (Operationen 1408, 1410, 1412, 1418).
  • 15 ist ein Flussdiagramm, das ein Verfahren 1500 zur absichtsbasierten Clusterverwaltung gemäß einer Ausführungsform veranschaulicht. Bei 1502 beinhaltet das Verfahren 1500 Empfangen, an einem Orchestratorsystem, eines administrativen absichtsbasierten Service-Level-Ziels (SLO) für eine Infrastrukturkonfiguration einer Infrastruktur. Bei einer Ausführungsform beinhaltet das administrative absichtsbasierte SLO eine zeitbasierte Beschränkung. Bei einer verwandten Ausführungsform beinhaltet das administrative absichtsbasierte SLO eine gestufte Migrationsanweisung.
  • Bei 1504 beinhaltet das Verfahren 1500 Abbilden des administrativen absichtsbasierten SLO auf einen Satz unbedingter Richtlinien. Bei einer Ausführungsform beinhaltet das Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien Verwenden einer statischen vorbestimmten Abbildung. Bei einer verwandten Ausführungsform beinhaltet das Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien Verwenden einer zeitbasierten Abbildung, die sich Zeitverlauf ändert. Bei einer verwandten Ausführungsform beinhaltet das Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien Verwenden eines Maschinenlernmodells, um den Satz unbedingter Richtlinien abzuleiten. Bei einer verwandten Ausführungsform beinhaltet das Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien Verwenden einer Kostenfunktion.
  • Bei 1506 beinhaltet das Verfahren 1500 Bereitstellen des Satzes unbedingter Richtlinien an die Infrastruktur. Bei einer Ausführungsform regelt der Satz unbedingter Richtlinien die Leistungsüberwachung. Bei einer verwandten Ausführungsform regelt der Satz unbedingter Richtlinien das Leistungsbudget und die Leistungsbegrenzung. Bei einer verwandten Ausführungsform regelt der Satz unbedingter Richtlinien die HardwareInfrastrukturkonfiguration. Bei einer verwandten Ausführungsform regelt der Satz unbedingter Richtlinien die Netzwerkkonnektivität auf Knotenebene, die Netzwerkkonnektivität auf Leaf-Ebene, die Netzwerkkonnektivität auf Spine-Ebene oder die Netzwerkkonnektivität auf Rack-Ebene. Bei einer verwandten Ausführungsform regelt der Satz unbedingter Richtlinien die Ressourcenbestandsverwaltung. Bei einer verwandten Ausführungsform regelt der Satz unbedingter Richtlinien die Mandantensicherheit und den Datenschutz.
  • Bei 1508 beinhaltet das Verfahren 1500 Überwachen einer Leistungsfähigkeit der Infrastruktur. Die Leistungsfähigkeitsüberwachung kann KPI-Messwerte erzeugen. Die Leistungsfähigkeit kann durch Bereitstellen eines oder mehrerer Softwareagenten, softwarebasierter Operatoren oder dergleichen überwacht werden.
  • In bestehenden orchestrierten, verteilten Rechenumgebungen können Hunderte oder sogar Tausende von Mikrodiensten eingesetzt werden. Softwarebasierte oder softwareimplementierte Operatoren werden verwendet, um die verteilten Ressourcen und ausführbaren Komponenten zu verwalten. Ein Bediener kann Hardware oder Software basierend auf SLO/SLA-Richtlinien konfigurieren. Die meisten Operatoren, die Hardware verwalten, gehören dem Plattformanbieter oder werden von diesem bereitgestellt, aber einige Operatoren, die Software verwalten, können vom Kunden bereitgestellt werden. Im Allgemeinen sind Operatoren Softwarekonstrukte, die verwendet werden, um Operationen auf des Ebene des Datenzentrums einzurichten, zu überwachen, zu konfigurieren und durchzuführen. Ein softwareimplementierter Operator kann mit einem Container oder einer Arbeitslast eingesetzt werden. In Kubernetes ist ein Betreiber eine anwendungsspezifische Steuerung, die dazu beiträgt, eine Kubernetes-Anwendung zu paketisieren, einzusetzen und zu verwalten. Die Betreiber erweitern die Funktionalität von Kubernetes und stellen eine Automatisierung bereit. Softwareagenten, einrichtungen und dienste können den gleichen oder einen ähnlichen Dienst wie Betreiber bereitstellen.
  • Bei 1510 beinhaltet das Verfahren 1500 Detektieren von Nichtkonformität mit dem Satz unbedingter Richtlinien. Eine Nichtkonformität kann durch Vergleichen von KPI-Messwerten im Laufe der Zeit ermittelt werden, um festzustellen, dass eine Richtlinie verletzt wurde.
  • Bei 1512 beinhaltet das Verfahren 1500 ein Modifizieren des administrativen absichtsbasierten SLO, um einen revidierten Satz unbedingter Richtlinien zu erzeugen, die bewirken, dass die Leistungsfähigkeit der Infrastruktur mit dem revidierten Satz unbedingter Richtlinien konform ist. Bei einer Ausführungsform beinhaltet das Modifizieren des administrativen absichtsbasierten SLO, um den revidierten Satz unbedingter Richtlinien zu erzeugen, Folgendes: Arbitrieren zwischen mehreren SLOs, die auf der Infrastruktur in Kraft sind; und Modifizieren des administrativen absichtsbasierten SLO basierend auf einer Priorität des administrativen absichtsbasierten SLO in Bezug auf die mehreren SLOs, die auf der Infrastruktur in Kraft sind.
  • Bei einer Ausführungsform beinhaltet das Verfahren 1500 Empfangen eines Anwendungs-SLO für eine Anwendung; Bestimmen einer vorgeschlagenen Ressourcenzuweisung zum Ausführen der Anwendung; Überprüfen der vorgeschlagenen Ressourcenzuweisung unter Verwendung einer Gebührenleitplankenfunktion, wobei die Gebührenleitplankenfunktion konfiguriert ist, um eine Abrechnung für die vorgeschlagene Ressourcenzuweisung vorherzusagen; und Benachrichtigen einer Planungskomponente, um fortzufahren, wenn die vorgeschlagene Ressourcenzuweisung die Gebührenleitplankenfunktion nicht verletzt.
  • Bei einer Ausführungsform beinhaltet das Verfahren 1500: Ermitteln, ob ein Schnellstartlebenszyklusmechanismus aktiviert ist; Bereitstellen eines Dienstes in einer Sandkasteninstanz, wenn der Schnellstartlebenszyklusmechanismus aktiviert ist; und Migrieren des Dienstes vom Sandkasten in eine Produktionsumgebung.
  • Die Verschiebung zu deklarativen, beabsichtigten angetriebenen Modellen zur Orchestrierung impliziert, dass Benutzer keine spezifischen Ressourcenanforderungen von der Infrastruktur als Dienst (IaaS) stellen müssen. Traditionell wurden diese spezifischen Ressourcenanforderungen oder eine explizite Zuordnung von Servern (VMs/Arbeitsknoten) zu einer Arbeitslast verwendet, um die Gebühren- und Abrechnungsuntersysteme zu bestimmen, und waren die primäre Eingabe für das Kostenmanagement. Durch den Übergang zu einem absichtsbasierten SLO-Ansatz (SLO: Service Level Objective) entfällt jedoch diese entscheidende Eingabe in die Gebühren- und Abrechnungsinfrastruktur. Hierin beschriebene Systeme und Verfahren steuern die Gebühren oder Abrechnung absichtsbasierter SLO-Orchestrierungsmodelle an.
  • Vorherige Lösungen konzentrieren sich auf Software-as-a-Service (SaaS)-Nutzungsmodelle, bei denen der SaaS-Anbieter den Kunden basierend auf dem geleisteten Dienst abrechnet. Unter der Oberfläche verwaltet der SaaS-Anbieter das traditionelle ressourcenverbrauchsbasierte Abrechnungsmodell, berücksichtigt dieses in den Gesamtbetriebskosten (TCO) und hält diese vor dem Endbenutzer verborgen. Die bisherige Lösung befasste sich nicht mit dem Problem, eine Gebühr/Abrechnung basierend auf SLO-Spezifikationen auf der laaS-Schicht zu ermöglichen. Existierende Lösungen arbeiten nur auf der SaaS-Schicht.
  • Es gibt „Autopilot“-Modelle, die ermöglichen, dass Instanztypen durch den IaaS-Anbieter ausgewählt werden. Diese befreien den mit der Verwaltung konfrontierten Mandanten davon, Instanztypen auswählen zu müssen. Die „Autopilot“-Modelle nutzen keine Absichts- oder SLO-Eingaben zur Auswahl der Instanztypen. Stattdessen betrachten sie Lastmetriken und weisen unterschiedliche Instanztypen basierend auf den Metriken zu. Der Mangel besteht darin, dass die Last nicht ausreicht, um die unterschiedlichen SLO-Aspekte zu repräsentieren, und daher die zugewiesenen Instanzen möglicherweise nicht zum Adressieren des gewünschten SLO geeignet sind. Als ein Beispiel gibt eine einfache CPU-Lastmetrik nicht die Verwendung von Ressourcen an, die Anwendungen abhängen, wie etwa Speicher, Beschleuniger, GPU, Leistung, CPU-Gesundheit und mehr. Ein allgemeinerer Ansatz ist erforderlich.
  • Hierin beschriebene Systeme und Verfahren gehen die Herausforderung an, die Ressourcenzuweisung. über die das Orchestrierungssystem entschieden hat, mit Gebühren- und Abrechnungsbeschränkungen zu versehen, wenn SLO-basierte Eingabeparameter für eine Arbeitslast präsentiert werden. Zwei neue Komponenten werden zu einem Orchestrierungssystem hinzugefügt, um absichtsgesteuerte Gebühren und eine absichtsgesteuerte Abrechnung zu ermöglichen. Diese Komponenten sind eine Gebührenleitplankenfunktion und eine SLO-Planungsfunktion.
  • Die Gebührenleitplankenfunktion wird in den Bereitstellungsarbeitsablauf eingeführt. Sie ist ein logisch zentraler Punkt in der Orchestrierungsarchitektur. Sie fungiert als die Entität, die für die Steuerung und Führung der SLO-orientierten Ressourcenplanungskomponente verantwortlich ist, um sicherzustellen, dass die zugewiesenen Ressourcen für den Benutzer gewährt werden. Die SLO-Planungsfunktion muss dann die Kostenbasis für zugewiesene Ressourcen und nicht nur ihre Eignung zur wahrscheinlichen Einhaltung der Arbeitslast-SLA berücksichtigen. Die SLO-Planungsfunktion ist eine Entität, die für das Auswählen verantwortlich ist, welche Infrastrukturressourcen der Arbeitslast zugewiesen sind, um die SLA einzuhalten. Eine solche Komponente ist ohne eine Art Ladesteuerung nicht einsetzbar. Die SLO-Planungsfunktion ist ein primärer Einflusspunkt in der Orchestrierungsarchitektur.
  • Als Hintergrund basiert das Gebühren in einem laaS-Modell und vielen Containerclustermodellen auf der Zuweisung von Instanztypen, typischerweise VMs, zu einem speziellen Cluster. Eine herkömmliche laaS- oder Container-Orchestrierungs-Engine-Initialisierungssequenz kann die folgenden Operationen beinhalten: 1) Admin wählt Instanztypen aus, 2) Admin wählt eine Anzahl von Instanzen jedes Typs aus, 3) Verschiedene Instanztypen und ihre Attribute (z. B. präemptierbare Charakteristiken und/oder erwartete Langlebigkeit) diktieren den Preis und 4) Admin kann Abrechnungen für den nächsten Abrechnungszyklus schätzen. Ein verbessertes System ist in 16 veranschaulicht.
  • 16 ist ein Blockdiagramm, das einen Daten-und Steuerfluss zum Implementieren von Gebühren und Abrechnung in einer absichtsbasierten Orchestrierungsumgebung veranschaulicht, gemäß einer Ausführungsform. Nachdem ein Cluster gestartet wurde, stellt ein Administrator die Gebührenleitplankenfunktion bereit (Operation 1602). Die Gebührenleitplankenfunktion beinhaltet eine Spezifikation mehrerer Aspekte, die sich auf benutzerspezifische SLOs auswirken. Die Leitplanken sind ein Satz von Regeln, die durch den Cluster-Administrator konfiguriert werden. Beispiele für Regeln beinhalten: Festlegen der zulässigen Finanzgrenzen und Zeitskalen, z. B. Gesamt-Dollar/Monat, durchschnittliche Dollar/Monat; Festlegen von zulässigen Burst-Finanzgrenzen Dollar/min und die Dauer und Menge, für die eine Finanzleitplanke überschritten werden kann; Festlegen von Konfigurationen zum Ausgleichen der SLO-Einhaltung gegenüber dem Überschreiten finanzieller Leitplanken; Festlegen von Regeln für Leitplanken, wie etwa Erlaubnis, sich zu ändern und Häufigkeit der Änderung von Instanztypen zum Ausführen von Arbeitslasten; und Festlegen von Leitplanken für die Typen von Benutzern, Bevorzugungsniveau und Priorität von SLO-Anfragen.
  • Der Administrator stellt der SLO-Planungsfunktion (Operation 1604) auch Kostenspezifikationen für verschiedene Ressourcen in der Infrastruktur bereit, die zugewiesen werden können. Die Spezifikation kann relativ oder absolut sein und verschiedene zuordnungsbezogene Attribute aufweisen, wie etwa dedizierte Zuordnung, gemeinsam genutzte Zuordnung, Potenzial für präemptive Zuordnungen usw.
  • Bei 1606 spezifiziert ein Benutzer SLAs/SLOs. Benutzer-SLOs können eine Bevorzugungsstufe und Priorität beinhalten, die mit der spezifischen Benutzerrolle assoziiert sind. Der Benutzer initiiert eine Arbeitslastbereitstellung.
  • Bei 1608 parst die SLO-Planungsfunktion SLOs und bestimmt einen Ressourcenzuweisungsvorschlag. Der Ressourcenzuweisungsvorschlag ist ein bevorzugter Startpunkt für Ressourcenzuweisung basierend auf der SLA/dem SLO. Die SLO-Planungsfunktion stellt die Ressourcenzuweisung zur Überprüfung der Gebührenleitplankenfunktion bereit.
  • Die Gebührenleitplankenfunktion wird an der Ausgabe der SLO-Planungsfunktion abonniert. Die Gebührenleitplankenfunktion sagt die Abrechnung basierend auf dem Ressourcenzuweisungsvorschlag voraus, der durch die SLO-Planungsfunktion vorbereitet wird, und bestimmt, ob die Ressourcenzuweisung mit der SLO-Richtlinie konform ist (Entscheidung 1610). Falls die Zuweisung konform ist, benachrichtigt die Gebührenleitplankenfunktion (über den Nachrichtenbus) die SLO-Planungsfunktion, dass die Bereitstellung fortfahren kann, und je nach der vorhergesagten Rechnung und den Richtlinien, wie lange die Bereitstellung auf der spezifizierten Ressourcenebene fortfahren kann (Operation 1612). Die Arbeitslast wird dann bereitgestellt (Operation 1614).
  • Im Fall einer Nichterfüllung der Richtlinie benachrichtigt die Gebührenleitplankenfunktion die SLO-Planungsfunktion über Nichterfüllung und den Betrag über oder eine prozentuale Überführung (Operation 1616). Die SLO-Planungsfunktion berechnet dann eine suboptimale (aus SLO-Perspektive) Ressourcenzuweisung neu, die kostengünstiger als die anfängliche Zuweisung ist. Die Nichtkonformitätsangabe von der Gebührenleitplankenfunktion kann Folgendes beinhalten: 1) Grund für Nichtkonformität (fehlgeschlagene Regel oder Regeln); 2) Schwere von Nichtkonformität; 3) Dauer von Nichtkonformität (falls aus Zeitraumgründen abgewiesen); und 4) Anzahl von nicht konformen Problemen.
  • Bei einem anderen Aspekt der Clusterverwaltung ändern die hier beschriebenen Systeme und Verfahren, anstatt eine Arbeitslast an einen Cluster anzupassen, die Art und Weise, wie Lebenszyklusverwaltung durchgeführt wird. Traditionell würde zuerst der Lebenszyklus der Infrastruktur abgeschlossen werden, gefolgt von der Lebenszyklusverwaltung der Dienste. Unter Verwendung dieses Modells können Einstellungen und Richtlinienkonfigurationen, die während des Infrastrukturdesigns vorgenommen werden, nicht einfach geändert werden und sind potenziell suboptimal für die später eingesetzten Dienste. Die hier beschriebenen innovativen Systeme bringen den Gesamtlebenszyklus in Synchronisation und der Gesamtstapel wird gemäß den Bedürfnissen (z. B. Absichten/SLOs) des spielenden Dienstes eingerichtet. Bei einem anderen Aspekt zerlegt das System große suboptimale Cluster in einen Satz kleinerer Cluster, die für maximale Effizienz und SLO-Konformität eingerichtet sind.
  • Manche existierenden Produkte stellen einen gemeinsamen Einsatz des Clusters und der Arbeitslast durch den Arbeitslasteigentümer bereit. Bei dieser Einrichtung muss der Infrastruktureigentümer dem Arbeitslastadministrator nur die Kapazität (z. B. VMs oder Bare-Metal) zuweisen und der Arbeitslastadministrator stellt seinen eigenen Cluster bereit. Die Nachteile dieser Art von Anordnung sind, dass die Cluster-Lebenszyklusverwaltung als Teil eines vertikal integrierten Stapels bereitgestellt werden muss, der die Kundenauswahl einschränkt, und dass der Einsatz eine statische Approximation dessen ist, was die Arbeitslast für den vollen Lebenszyklus der Arbeitslast benötigt, was statische Richtlinien für die Dauer der Existenz impliziert. Infolgedessen werden Administratoren belastet, um vorab auszuwählen, was sie für Arbeitslasten benötigt haben, und diese Best-Effort-Schätzung weitgehend statisch vorzunehmen.
  • Im Gegensatz dazu konzentrieren sich die hier beschriebenen verbesserten Systeme und Verfahren auf ein neues Modell zum Fahren von Lebenszyklusverwaltung, um die Bedürfnisse der Anwendung anstelle der Annahmen des Infrastrukturadministrators widerzuspiegeln. In diesem Fall ist Infrastruktur, einschließlich alles von der Orchestrierungssoftware bis hinunter zum Host (einschließlich rekonfigurierbarer Hardware), dazu konfiguriert, mit dem übereinzustimmen, was die Arbeitslast benötigt. Operationen mit geschlossenem Regelkreis überwachen kontinuierlich die Konfiguration, um sicherzustellen, dass die Anwendungs-SLOs eingehalten werden. Dies gibt dem Dienstliefersystem ausreichend Spielraum, um alle Aspekte des Infrastrukturstapels zu steuern und das optimalste Benutzererlebnis zu liefern, wodurch ermöglicht wird, dass der Ressourcenanbieter entsprechend lädt.
  • Bei einer Implementierung wird die Anwendung temporär eingesetzt (um einen Schnellstart zu unterstützen) und anschließend wird eine neue Instanz von Containern mit den Richtlinien auf Cluster-und Knotenebene eingesetzt, die die Bedürfnisse der Anwendung besser widerspiegeln. Die Arbeitslast wird anschließend auf den neuen Cluster verschoben. Während versucht wird, die bestmögliche Einrichtung einzurichten, kann eine Zwischen-Sandboxeinrichtung verwendet werden, um versorgende Dienste und ihre Anwendungen zu starten. Das Abstimmen der Richtlinien für die spezifischen Bedürfnisse kann Vorteile für Diensteigentümer und Ressourcenanbieter bereitstellen, um den TCO der Ressourcen an Ort und Stelle zu optimieren.
  • Beispielhafte Richtlinien beinhalten unter anderem Einstellungen auf Plattformebene; Betriebssystem, Middleware und Virtualisierungsabstimmung; und Einstellungen auf Anwendungsebene. Plattformeinstellungen beinhalten optimale Konfigurationen für Leistungs-/Wärmemanagement, E/A-Einstellungen usw. Betriebssystem, Middleware und Virtualisierungsabstimmung können Auswählen der richtigen OS-Scheduler-Richtlinien, TCP/IP-Netzwerkstapeleinstellungen, NUMA-Einstellungen, CPU-Manager, VM-Einstellungen, Einstellungen der RDT/DRC-QoS-Klassen usw. beinhalten.
  • Manche dieser Richtlinien können sogar erfordern, dass ein Neustart der physischen Hardware wirksam wird. Bisher lag ein Neustart der Plattform außerhalb des Umfangs der Dienstorchestrierungssysteme und Ressourcenorchestrierungssysteme, da ein Neustart potenziell Dienste unterbrechen könnte. Unter Verwendung der verbesserten Systeme und Verfahren hier können Reboots geplant und implementiert werden, um die Auswirkung auf Dienste durch die geplante Evakuierung von Diensten zu eliminieren.
  • Während Schritte durchgeführt werden, um Einstellungen auf Plattformebene oder Betriebssystem-/Middleware-/Virtualisierungsabstimmung bereitzustellen, oder bis gewisse Schritte in dem Gesamtlebenszyklus durchgeführt werden können, bestimmt das System den optimalen Satz von Richtlinien, die für eine gewisse Arbeitslast auszurollen sind. Zusätzlich können zusätzliche Lebenszyklusschritte eingeführt werden. Die erste Stufe ist eine „Schnellstart“-Stufe. Die zweite Stufe ist eine „schnellstartüberwachte“ Stufe, da eine Überwachung erforderlich ist, um Informationen über die Ressourcenbedürfnisse, das Anwendungsverhalten und den Dienstbedarf zu sammeln (und Zeit benötigt, um dynamisch einzusetzen), und dann ist die dritte Stufe eine „Canary-Aktualisierung“-Stufe, bei der die Arbeitslast verfügbar gemacht wird, wodurch abgeleitete Ressourcenabhängigkeiten auf die neue Clusterbereitstellung übertragen werden.
  • Ein anfänglicher Sandkasteneinsatz kann verwendet werden, um zu verstehen, wie sich die Arbeitslast verhält. Die Profilabbildung ist eine Möglichkeit, das Verhalten verschiedener Arbeitslasten zu behandeln. Ein Cluster kann mehrere Profile aufweisen, die in eine Anwendung abgebildet werden können. Für Anwendungen, die kein abgebildetes Profil aufweisen, wird ein Bruch der Anwendung/des Dienstes ausgeführt, um das beste Profil für die Anwendung zu entdecken. Gleichermaßen kann das System lernen, da derselbe Dienst wiederholt im Laufe der Zeit ausgeführt wird, was die besten Profile für den Dienst/die Anwendung sind. Die Profilentscheidung kann mit den Eingaben in die Anwendung korreliert werden, die detektiert werden (z. B. eingehender Verkehr). Profile können als Charakteristiken definiert sein, die in statische Charakteristiken (in manchen Fällen dynamisch) gebunden sind, die typischerweise mit Rechen- oder Hardwarecharakteristiken zusammenhängen, wie sie durch einen Beobachtbarkeitsstapel abgeleitet werden. Der Beobachtbarkeitsstapel stellt Verfolgungs-, Protokollierungs- und Telemetriedaten-Einrichtungen bereit.
  • 17 ist ein Flussdiagramm, das ein Verfahren 1700 zum Implementieren eines Schnellstartlebenszyklus veranschaulicht, gemäß einer Ausführungsform. Bei 1702 wird eine Dienstanforderung für einen Dienst empfangen. Es wird bestimmt, ob Richtlinien bereits für den Dienst verfügbar sind (Entscheidungsblock 1704). Falls es keine Richtlinien gibt, verwendet das Verfahren 1700 einen Sandkasten, um Richtlinien zu bestimmen. Bei 1706 wird der Dienst in einem Sandkasten bereitgestellt. Er wird überwacht (Operation 1708) und die Telemetrie und andere Informationen, die während der Überwachung gewonnen werden, werden zum Lernen verwendet (Operation 1710).
  • Richtlinien werden basierend auf dem Lernen bestimmt (Operation 1712). Bei einer Implementierung wird eine Sandkastenumgebung verwendet, um zwei Arten von Richtlinien zu testen, um zu bestimmen, welche die höhere Wahrscheinlichkeit aufweist, Dienstziele zu erfüllen. Wenn zur Produktion übergegangen wird, wird die Richtlinie mit der höheren Wahrscheinlichkeit ausgewählt, die Ziele zu erfüllen. Das Lernen und die statistische Analyse hilft beim Bestimmen, welche Richtlinie die effektivere ist.
  • Nachdem die Richtlinien bestimmt wurden, kann der Dienst aus dem Sandkasten entfernt werden (Operation 1714). Sobald die Richtlinien für den Dienst bestimmt sind, kann der Dienst einem Produktionscluster bereitgestellt werden (Operationen 1722-1730).
  • Falls bestimmt wird, dass Richtlinien für den Dienst verfügbar sind (Entscheidungsblock 1704), dann fährt das Verfahren 1700 fort, zu bestimmen, ob der Dienst mit einem Schnellstart bereitgestellt werden soll (Entscheidung 1716). Ein Schnellstart ermöglicht eine schnelles Hochfahren des Dienstes unter Verwendung lokaler Ressourcen. Obwohl die lokalen Ressourcen möglicherweise nicht die vom Dienst erwartete Langzeit-QoS bereitstellen, werden die lokalen Ressourcen nur für einen schnelleren Start verwendet.
  • Falls ein Schnellstart für den Dienst aktiviert ist, dann stellt das Verfahren 1700 den Dienst in einem Sandkasten bereit (Operation 1718). Gleichzeitig beginnt das Verfahren 1700 auch den Bereitstellungsprozess auf dem Produktionscluster (Operation 1722). Der Dienst arbeitet im Sandkasten, während das Produktionssystem online gebracht wird (Operation 1720). Sobald das Produktionssystem läuft, wird der Dienst unter Verwendung von Canary-Aktualisierungen migriert (Operation 1728), wobei das Übertragen Ressourcenabhängigkeiten zur neuen Clusterbereitstellung ableitet.
  • Ist kein Schnellstart für den Dienst ermöglicht, so stellt das Verfahren 1700 den Dienst auf dem Produktionscluster bereit. Ein Produktionscluster wird bereitgestellt (Operation 1722) und Richtlinien werden auf dem Cluster eingerichtet (Operation 1724). Der Dienst wird auf dem Produktionscluster bereitgestellt (Operation 1726) und Canary-Aktualisierungen können für weitverbreiteten Rollout verwendet werden (Operation 1728). Der Dienst und die Infrastruktur werden überwacht (Operation 1730). Die Überwachung kann unter Verwendung des Beobachtbarkeitsstapels erreicht werde n, um Metriken zu analysieren, Protokollierungs- und Verfolgungsinformationen zum Lernen zu verwenden (z. B. unter Verwendung einer statistischen ML- oder KI-Analyse) und schließlich zu entscheiden, eine bestimmte Operation durchzuführen.
  • Die Plattform kann verschiedene Arten von Telemetrie erzeugen: Rohtelemetrie, vorgefilterte Telemetrie und Warnungen. Diese Telemetrie kann von der Hardware, dem virtuellen Switch, der Virtualisierungsschicht, der Container-Ressourcenschicht, der Dienst-Mesh-Schicht und der Anwendungsschicht stammen. Die Telemetrie kann wie gestreamt, gebatcht oder auf Anforderung exportieren. Telemetrie kann dann auf mehrere unterschiedliche Weisen gespeichert und aufgenommen werden.
  • Ein Richtlinienprofil definiert Folgendes: 1) Telemetriedaten-Geltungsbereich; 2) Vorfilterungsebene; 3) Exportverfahren; 4) Speicherungsverfahren; 5) Belegungsziele; und 6) Endpunktschnittstellentypen.
  • Das Richtlinienprofil definiert dann den Lebenszyklus für die Konfiguration von Infrarot-Telemetriekomponenten, Dienst-Mesh-Telemetrie, Exportern, Speicherung und Ingestoren. Dies beinhaltet die Clusterebenenkollektoren, Aggregatoren und Analyse-Engine-Ingestoren.
  • Die Telemetrie kann Daten aufweisen, die normalerweise nicht als Plattformtelemetrie angesehen werden. Fehler, Anomalien/Warnungen und Übergänge verschiedener Typen in Softwareschichten können zum Beispiel erfasst, aufgezeichnet und als Telemetrie gemeldet werden. Übergänge in Softwareschichten können Ereignisse beinhalten, wie etwa eine Anzahl von Malen, die vmscan aktiviert wird, oder eine Anzahl von Malen, die NUMA startet oder NUMA-Migrationen durchführt.
  • Für manche Typen von Zählungen werden Filteroperationen verwendet. Für andere Arten von Telemetrie werden Kontextdaten gesammelt, um die Analyse oder Interpretation davon zu unterstützen, was durch Überwachung beobachtet wird. Falls zum Beispiel viele vmscans beobachtet werden, dann ist es nützlich, zu wissen, welche Prozesse in einem kürzlich erfolgten Zeitintervall schnell in ihrem RSS gewachsen sind und ob diese Prozesse Prozesse mit hoher Priorität sind oder nicht. Allgemein erfordern, wie das Beispiel veranschaulicht, Gebäudeeinsichten aus Telemetrie das Sammeln erheblicher Evidenz, die zeitausgerichtet, prozessausgerichtet und aktivitätsausgerichtet ist. Daher ist eine deklarative Spezifikation von einer Anwendung nützlich, die schreibt, welche Bedingungen auslösen sollten, welche anderen Informationen zu sammeln sind und wie schnell dies durchzuführen ist. Eine andere Art von verteiltem Profilieren und Filtern ist „ein Tag in der Lebensdauer von X“-Profilieren, wobei eine spezielle Anforderung markiert wird und dieses Tag eine verteilte Sammlung alles auslöst, das die markierte Anforderung erfüllt, oder der Objekte, auf die zugegriffen wird, während die markierte Anforderung verarbeitet wird.
  • Entstehende Arbeitslasten, z. B. visuelles Rechnen usw. verwenden eine Kombination heterogener XPU, einschließlich Pipelining solcher XPUs. Benötigt wird ein Mechanismus zum Behandeln der dynamischen Änderung von XPU-Ressourcen, Speicherung usw., die von einer Arbeitslast im Laufe der Zeit benötigt werden, und der kontinuierlichen Neuanpassung von Ressourcen, um die SLAs zu erfüllen. Der Mechanismus stellt eine Möglichkeit bereit, dies durchzuführen, einschließlich Definieren der Steuerpunkte.
  • Des Weiteren können viele Hardwaremerkmale in diesem Gesamtaufbau verwendet werden, wie etwa RDT/DRC-Arbeitslastverwaltung oder TSC/TCC. Das System identifiziert dynamisch Anforderungen für die Arten von Plattformen, die am besten auf die gegenwärtig laufenden Arbeitslasten anwendbar wären, und wählt dann spezifische Knoten aus, die rekonfiguriert werden sollen, um den Bedarf zu erfüllen. TCC kann Daten-Pipelines vom Speicher zur CPU oder anderen E/A erzeugen, die spezifische Arten von Leistungsfähigkeit optimieren. Bei einer Implementierung findet diese Konfiguration zur Boot-Zeit statt. Somit kann ein Agent einer absichtsbasierten Orchestrierung einen Bedarf identifizieren, einen Knoten rekonfigurieren und den Knoten neu starten. Nach dem Booten befindet sich der Knoten dann in dem Pool von Ressourcen, die für die absichtsbasierte Orchestrierung verfügbar sind, um über diese neuen Ressourcen neu zu optimieren.
  • Für spezialisierte XPUs (z. B., Nicht-CPU) können Anwendungen mit einer gemeinsamen API präsentiert werden, hinter der XPU-Heterogenität verborgen ist und Planungsmechanismen die variable Zuweisung heterogener XPU-Ressourcen zu Anwendungsabteilen (Containern, Sandkästen, Threads usw.) auf eine Hintergrund-Außer-Band-Weise unterstützen. In-Band-Zuordnungsschnittstellen stehen für aufgehellte Anwendungen zur Verfügung, die kokonzipiert/kooptimiert sind. Unter der Annahme, dass der Zeitplan zum Zuweisen bekannt oder vorab vorhergesagt ist, können sogar die leichten Overhead des Rekonfigurierens verborgen werden, indem solche Zusammensetzungen nur rechtzeitig vorab durchgeführt werden.
  • Bei einem anderen Aspekt können Kunden Währung erwerben oder haben, die zum Makeln von Ressourcen verwendet werden kann. Die Kosten der Ressourcen werden angekündigt und die Kosten können von den Ressourcenanbietern in Abhängigkeit von ihren eigenen Metriken (z. B. aktuelle Nutzung, aktueller TDP, Sättigung usw.) erzeugt werden. Die Kosten können auch von der Verfügbarkeit oder Art von Ressourcen abhängen, die gemakelt werden (z. B. bei Sättigung im Speicher). Ferner kann die abgefragte Plattform als Dienst (PaaS) zu unterschiedlichen Kosten führen. Die Verwendung von Vorhersagen zukünftiger Lasten kann in die Kostenschätzungen einfließen. Die Dienste können an die verschiedenen Anbieter gemakelt werden. Ferner können administrative Richtlinien öffentlich gemacht werden, wodurch dem Verbraucher ermöglicht wird, basierend auf den veröffentlichten SLO/Admin-Richtlinien zu entscheiden, ob der Cloud/Cluster-Dienst verwendet werden soll.
  • Der Orchestrator oder Orchestrierungssysteme, die in diesem Dokument beschrieben sind, können in einem Gerät, einer Endpunktkomponente, einer Vorrichtung, einer Client-Vorrichtung, einer Rechenvorrichtung, einem Knoten, einem Server, einem eigenständigen Knoten, der separat verkauft und in ein anderes System integriert wird usw. implementiert werden. Eine Systemarchitektur kann ein Orchestrierungssystem in einer beliebigen Installation implementieren.
  • Ausführungsformen können in Hardware, Firmware oder Software oder einer Kombination davon implementiert sein. Ausführungsformen können auch als Anweisungen implementiert sein, die auf einer maschinenlesbaren Speicherungsvorrichtung gespeichert sind, die durch mindestens einen Prozessor gelesen und ausgeführt werden können, um die hierin beschriebenen Operationen durchzuführen. Eine maschinenlesbare Speicherungsvorrichtung kann einen beliebigen nicht-flüchtigen Mechanismus zum Speichern von Informationen in einer Form beinhalten, die durch eine Maschine (z. B. einen Computer) lesbar ist. Eine maschinenlesbare Speicherungsvorrichtung kann zum Beispiel Nur-Lese-Speicher (ROM), Direktzugriffsspeicher (RAM), Magnetplattenspeichermedien, optische Speichermedien, Flash-Speichervorrichtungen und andere Speichervorrichtungen und Medien beinhalten.
  • Beispiele, wie hierin beschrieben, können Logik oder eine Anzahl von Komponenten, wie etwa Module, IP-Blöcke (IP: Intellectual Property) oder Kerne, Engines oder Mechanismen, beinhalten oder auf diesen arbeiten. Eine solche Logik oder solche Komponenten können Hardware, softwarekonfigurierte Hardware oder Firmware sein, die kommunikativ mit einem oder mehreren Prozessoren gekoppelt ist, um die hier beschriebenen Operationen auszuführen. Logik oder Komponenten können Hardwaremodule (z. B. IP-Block) sein und als solche als greifbare Entitäten erachtet werden, die vorgegebene Operationen durchführen können, und können auf eine gewisse Weise konfiguriert oder angeordnet sein. In einem Beispiel können Schaltungen auf eine bestimmte Weise als ein IP-Block, IP-Kern, Ein-Chip-System (SoC) oder dergleichen (z. B. intern oder in Bezug auf externe Entitäten, wie andere Schaltungen) angeordnet sein.
  • In einem Beispiel kann das Ganze oder ein Teil eines oder mehrerer Computersysteme (e.g., ein eigenständiges, Client-oder Server-Computersystem) oder ein oder mehrere Hardwareprozessoren durch Firmware oder Software (e.g., Anweisungen, einen Anwendungsteil oder eine Anwendung) als ein Modul konfiguriert sein, das betrieben wird, um spezifizierte Operationen durchzuführen. In einem Beispiel kann sich die Software auf einem maschinenlesbaren Medium befinden. In einem Beispiel veranlasst die Software, wenn sie durch die zugrundeliegende Hardware des Moduls ausgeführt wird, dass die Hardware die spezifizierten Operationen durchführt. Dementsprechend versteht sich der Begriff Hardwaremodul so, dass er eine greifbare Entität umfasst, egal, ob es sich um eine Entität handelt, die physisch konstruiert ist, eigens konfiguriert (z. B. festverdrahtet) ist oder temporär (z. B. transitorisch) konfiguriert (z. B. programmiert) ist, um auf eine angegebene Weise zu arbeiten oder einen Teil oder die Gesamtheit eines beliebigen hierin beschriebenen Vorgangs durchzuführen.
  • Betrachtet man Beispiele, in denen Module temporär konfiguriert sind, muss nicht jedes der Module zu irgendeinem Zeitpunkt instanziiert sein. Wenn die Module zum Beispiel einen Universal-Hardwareprozessor umfassen, der unter Verwendung von Software konfiguriert ist, kann der Universal-Hardwareprozessor zu unterschiedlichen Zeiten jeweils als unterschiedliche Module konfiguriert sein. Software kann dementsprechend einen Hardwareprozessor konfigurieren, zum Beispiel, um zu einem Zeitpunkt ein bestimmtes Modul zu bilden und zu einem anderen Zeitpunkt ein anderes Modul zu bilden. Module können auch Software- oder Firmwaremodule sein, die arbeiten, um die hierin beschriebenen Methodiken durchzuführen.
  • Ein IP-Block (auch als IP-Kern bezeichnet) ist eine wiederverwendbare Einheit aus Logik, Zelle oder integrierter Schaltung. Ein IP-Block kann als ein Teil eines feldprogrammierbaren Gatearrays (FPGA), einer anwendungsspezifischen integrierten Schaltung (ASIC), einer programmierbaren Logikvorrichtung (PLD), eines Ein-Chip-Systems (SoC) oder dergleichen verwendet werden. Er kann für einen bestimmten Zweck konfiguriert sein, wie etwa digitale Signalverarbeitung oder Bildverarbeitung. Zu beispielhaften IP-Kernen gehören Zentralverarbeitungseinheitskerne (CPU-Kerne), integrierte Grafiken, Sicherheit, Eingabe/Ausgabe- bzw. E/A-Steuerung, ein System-Agent, eine Grafikverarbeitungseinheit (GPU), künstliche Intelligenz, neuronale Prozessoren, eine Bildverarbeitungseinheit, Kommunikationsschnittstellen, eine Speichersteuerung, eine Peripherievorrichtungssteuerung, ein Plattformsteuerungshub oder dergleichen.
  • Zusätzliche Anmerkungen und Beispiele:
  • Beispiel 1 ist ein Orchestratorsystem zum Implementieren einer absichtsbasierten Clusterverwaltung, das Folgendes umfasst: einen Prozessor; und einen Speicher zum Speichern von Anweisungen, die bei Ausführung durch den Prozessor das Orchestratorsystem zu Folgendem veranlassen: Empfangen, am Orchestratorsystem, eines administrativen absichtsbasierten Service-Level-Ziels (SLO) für eine Infrastrukturkonfiguration einer Infrastruktur; Abbilden des administrativen absichtsbasierten SLO auf einen Satz unbedingter Richtlinien; Bereitstellen des Satzes unbedingter Richtlinien an die Infrastruktur; Überwachen der Leistungsfähigkeit der Infrastruktur; Detektieren einer Nichtkonformität mit dem Satz unbedingter Richtlinien; und Modifizieren des administrativen absichtsbasierten SLO, um einen revidierten Satz unbedingter Richtlinien zu erzeugen, die bewirken, dass die Leistung der Infrastruktur mit dem revidierten Satz unbedingter Richtlinien konform ist.
  • In Beispiel 2 beinhaltet der Gegenstand des Beispiels 1, dass der Satz unbedingter Richtlinien die Leistungsüberwachung regelt.
  • In Beispiel 3 beinhaltet der Gegenstand der Beispiele 1 bis 2, dass der Satz unbedingter Richtlinien das Leistungsbudget und die Leistungsabdeckung regelt.
  • In Beispiel 4 beinhaltet der Gegenstand der Beispiele 1 bis 3, dass der Satz unbedingter Richtlinien die Hardwareinfrastrukturkonfiguration regelt.
  • In Beispiel 5 beinhaltet der Gegenstand der Beispiele 1 bis 4, dass der Satz unbedingter Richtlinien die Netzwerkkonnektivität auf Knotenebene, die Netzwerkkonnektivität auf Leaf-Ebene, die Netzwerkkonnektivität auf Spine-Ebene oder die Netzwerkkonnektivität auf Rack-Ebene regelt.
  • In Beispiel 6 beinhaltet der Gegenstand der Beispiele 1 bis 5, dass der Satz unbedingter Richtlinien die Inventarverwaltung regelt.
  • In Beispiel 7 beinhaltet der Gegenstand der Beispiele 1 bis 6, dass der Satz unbedingter Richtlinien Mandantensicherheit und Datenschutz regelt.
  • In Beispiel 8 beinhaltet der Gegenstand der Beispiele 1 bis 7, dass das administrative absichtsbasierte SLO eine zeitbasierte Beschränkung beinhaltet.
  • In Beispiel 9 beinhaltet der Gegenstand der Beispiele 1 bis 8, dass das administrative absichtsbasierte SLO eine gestufte Migrationsanweisung beinhaltet.
  • In Beispiel 10 beinhaltet der Gegenstand der Beispiele 1 bis 9, dass zum Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien das System dazu ausgelegt ist, ein statisches vorbestimmtes Abbilden zu verwenden.
  • In Beispiel 11 beinhaltet der Gegenstand der Beispiele 1 bis 10, dass zum Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien das System dazu ausgelegt ist, ein zeitbasiertes Abbilden zu verwenden, das sich im Zeitverlauf ändert.
  • In Beispiel 12 beinhaltet der Gegenstand der Beispiele 1 bis 11, dass das System zum Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien dazu ausgelegt ist, ein Maschinenlernmodell zu verwenden, um den Satz unbedingter Richtlinien abzuleiten.
  • In Beispiel 13 beinhaltet der Gegenstand der Beispiele 1 bis 12, dass das System zum Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien dazu ausgelegt ist, eine Kostenfunktion zu verwenden.
  • In Beispiel 14 beinhaltet der Gegenstand der Beispiele 1 bis 13, dass zum Modifizieren des administrativen absichtsbasierten SLO, um den revidierten Satz unbedingter Richtlinien zu erzeugen, das System ausgelegt ist zum: Arbitrieren zwischen mehreren SLOs, die auf der Infrastruktur in Kraft sind; und Modifizieren des administrativen absichtsbasierten SLO basierend auf einer Priorität des administrativen absichtsbasierten SLO mit Bezug auf die mehreren SLOs, die auf der Infrastruktur in Kraft sind.
  • In Beispiel 15 beinhaltet der Gegenstand der Beispiele 1 bis 14, dass das System ausgelegt ist zum: Empfangen eines Anwendungs-SLO für eine Anwendung; Bestimmen einer vorgeschlagenen Ressourcenzuweisung zum Ausführen der Anwendung; Überprüfen der vorgeschlagenen Ressourcenzuweisung unter Verwendung einer Gebührenleitplankenfunktion, wobei die Gebührenleitplankenfunktion dazu konfiguriert ist, eine Abrechnung für die vorgeschlagene Ressourcenzuweisung vorherzusagen; und Benachrichtigen einer Planungskomponente, um fortzufahren, wenn die vorgeschlagene Ressourcenzuweisung die Gebührenleitplankenfunktion nicht verletzt.
  • In Beispiel 16 beinhaltet der Gegenstand der Beispiele 1 bis 15, dass das System ausgelegt ist zum: Ermitteln, ob ein Schnellstartlebenszyklusmechanismus aktiviert ist; Bereitstellen eines Dienstes in einer Sandkasteninstanz, wenn der Schnellstartlebenszyklusmechanismus aktiviert ist; und Migrieren des Dienstes vom Sandkasten in eine Produktionsumgebung.
  • Beispiel 17 ist ein Verfahren zum Implementieren einer absichtsbasierten Clusterverwaltung, das Folgendes umfasst: Empfangen, an einem Orchestratorsystem, eines administrativen absichtsbasierten Service-Level-Ziels (SLO) für eine Infrastrukturkonfiguration einer Infrastruktur; Abbilden des administrativen absichtsbasierten SLO auf einen Satz unbedingter Richtlinien; Bereitstellen des Satzes unbedingter Richtlinien an die Infrastruktur; Überwachen der Leistungsfähigkeit der Infrastruktur; Detektieren einer Nichtkonformität mit dem Satz unbedingter Richtlinien; und Modifizieren des administrativen absichtsbasierten SLO, um einen revidierten Satz unbedingter Richtlinien zu erzeugen, die bewirken, dass die Leistungsfähigkeit der Infrastruktur mit dem revidierten Satz unbedingter Richtlinien konform ist.
  • In Beispiel 18 beinhaltet der Gegenstand des Beispiels 17, dass der Satz unbedingter Richtlinien die Leistungsüberwachung regelt.
  • In Beispiel 19 beinhaltet der Gegenstand der Beispiele 17 bis 18, dass der Satz unbedingter Richtlinien ein Leistungsbudget und eine Leistungsbegrenzung regelt.
  • In Beispiel 20 beinhaltet der Gegenstand der Beispiele 17 bis 19, dass der Satz unbedingter Richtlinien die Konfiguration der Hardwareinfrastruktur regelt.
  • In Beispiel 21 beinhaltet der Gegenstand der Beispiele 17 bis 20, dass der Satz unbedingter Richtlinien die Netzwerkkonnektivität auf Knotenebene, die Netzwerkkonnektivität auf Leaf-Ebene, die Netzwerkkonnektivität auf Spine-Ebene oder die Netzwerkkonnektivität auf Rack-Ebene regelt.
  • In Beispiel 22 beinhaltet der Gegenstand der Beispiele 17 bis 21, dass der Satz unbedingter Richtlinien die Inventarverwaltung regelt.
  • In Beispiel 23 beinhaltet der Gegenstand der Beispiele 17 bis 22, dass der Satz unbedingter Richtlinien Mandantensicherheit und Datenschutz regelt.
  • In Beispiel 24 beinhaltet der Gegenstand der Beispiele 17 bis 23, dass das administrative absichtsbasierte SLO eine zeitbasierte Beschränkung beinhaltet.
  • In Beispiel 25 beinhaltet der Gegenstand der Beispiele 17 bis 24, dass das administrative absichtsbasierte SLO eine gestufte Migrationsanweisung beinhaltet.
  • In Beispiel 26 beinhaltet der Gegenstand der Beispiele 17 bis 25, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eine statischen vorbestimmten Abbildens beinhaltet.
  • In Beispiel 27 beinhaltet der Gegenstand der Beispiele 17 bis 26, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eines zeitbasierten Abbildens beinhaltet, das sich im Zeitverlauf ändert.
  • In Beispiel 28 beinhaltet der Gegenstand der Beispiele 17 bis 27, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eines Maschinenlernmodells zum Ableiten des Satzes unbedingter Richtlinien beinhaltet.
  • In Beispiel 29 beinhaltet der Gegenstand der Beispiele 17 bis 28, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden einer Kostenfunktion beinhaltet.
  • Bei Beispiel 30 beinhaltet der Gegenstand der Beispiele 17 bis 29, dass ein Modifizieren des administrativen absichtsbasierten SLO, um den revidierten Satz unbedingter Richtlinien zu erzeugen, Folgendes beinhaltet: Arbitrieren zwischen mehreren SLOs, die auf der Infrastruktur in Kraft sind; und Modifizieren des administrativen absichtsbasierten SLO basierend auf einer Priorität des administrativen absichtsbasierten SLO mit Bezug auf die mehreren SLOs, die auf der Infrastruktur in Kraft sind.
  • In Beispiel 31 beinhaltet der Gegenstand der Beispiele 17 bis 30 Empfangen eines Anwendungs-SLO für eine Anwendung; Bestimmen einer vorgeschlagenen Ressourcenzuweisung zum Ausführen der Anwendung; Überprüfen der vorgeschlagenen Ressourcenzuweisung unter Verwendung einer Gebührenleitplankenfunktion, wobei die Gebührenleitplankenfunktion konfiguriert ist, um eine Abrechnung für die vorgeschlagene Ressourcenzuweisung vorherzusagen; und Benachrichtigen einer Planungskomponente, um fortzufahren, wenn die vorgeschlagene Ressourcenzuweisung die Gebührenleitplankenfunktion nicht verletzt.
  • In Beispiel 32 beinhaltet der Gegenstand der Beispiele 17 bis 31 Ermitteln, ob ein Schnellstartlebenszyklusmechanismus aktiviert ist; Bereitstellen eines Dienstes in einer Sandkasteninstanz, wenn der Schnellstartlebenszyklusmechanismus aktiviert ist; und Migrieren des Dienstes vom Sandkasten in eine Produktionsumgebung.
  • Beispiel 33 ist mindestens ein maschinenlesbares Medium, das Anweisungen beinhaltet, die bei Ausführung durch eine Maschine die Maschine veranlassen, Operationen eines der Verfahren der Beispiele 17 bis 32 durchzuführen.
  • Beispiel 34 ist eine Einrichtung, die Mittel zum Durchführen eines der Verfahren der Beispiele 17 bis 32 umfasst.
  • Beispiel 35 ist mindestens ein maschinenlesbares Medium, das Anweisungen zum Implementieren einer absichtsbasierten Clusterverwaltung beinhaltet, die bei Ausführung durch eine Maschine die Maschine veranlassen, Operationen durchzuführen, die Folgendes umfassen: Empfangen, am Orchestratorsystem, eines administrativen absichtsbasierten Service-Level-Ziels (SLO) für eine Infrastrukturkonfiguration einer Infrastruktur; Abbilden des administrativen absichtsbasierten SLO auf einen Satz unbedingter Richtlinien; Bereitstellen des Satzes unbedingter Richtlinien an die Infrastruktur; Überwachen der Leistungsfähigkeit der Infrastruktur; Detektieren einer Nichtkonformität mit dem Satz unbedingter Richtlinien; und Modifizieren des administrativen absichtsbasierten SLO, um einen revidierten Satz unbedingter Richtlinien zu erzeugen, die bewirken, dass die Leistungsfähigkeit der Infrastruktur mit dem revidierten Satz unbedingter Richtlinien konform ist.
  • In Beispiel 36 beinhaltet der Gegenstand des Beispiels 35, dass der Satz unbedingter Richtlinien die Leistungsüberwachung regelt.
  • In Beispiel 37 beinhaltet der Gegenstand der Beispiele 35 bis 36, dass der Satz unbedingter Richtlinien ein Leistungsbudget und eine Leistungsbegrenzung regelt.
  • In Beispiel 38 beinhaltet der Gegenstand der Beispiele 35 bis 37, dass der Satz unbedingter Richtlinien die Konfiguration der Hardwareinfrastruktur regelt.
  • In Beispiel 39 beinhaltet der Gegenstand der Beispiele 35 bis 38, dass der Satz unbedingter Richtlinien die Netzwerkkonnektivität auf Knotenebene, die Netzwerkkonnektivität auf Leaf-Ebene, die Netzwerkkonnektivität auf Spine-Ebene oder die Netzwerkkonnektivität auf Rack-Ebene regelt.
  • In Beispiel 40 beinhaltet der Gegenstand der Beispiele 35 bis 39, dass der Satz unbedingter Richtlinien die Inventarverwaltung regelt.
  • In Beispiel 41 beinhaltet der Gegenstand der Beispiele 35 bis 40, dass der Satz unbedingter Richtlinien Mandantensicherheit und Datenschutz regelt.
  • In Beispiel 42 beinhaltet der Gegenstand der Beispiele 35 bis 41, dass das administrative absichtsbasierte SLO eine zeitbasierte Beschränkung beinhaltet.
  • In Beispiel 43 beinhaltet der Gegenstand der Beispiele 35 bis 42, dass das administrative absichtsbasierte SLO eine gestufte Migrationsanweisung beinhaltet.
  • In Beispiel 44 beinhaltet der Gegenstand der Beispiele 35 bis 43, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eine statischen vorbestimmten Abbildens beinhaltet.
  • In Beispiel 45 beinhaltet der Gegenstand der Beispiele 35 bis 44, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eines zeitbasierten Abbildens beinhaltet, das sich im Zeitverlauf ändert.
  • In Beispiel 46 beinhaltet der Gegenstand der Beispiele 35 bis 45, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eines Maschinenlernmodells zum Ableiten des Satzes unbedingter Richtlinien beinhaltet.
  • In Beispiel 47 beinhaltet der Gegenstand der Beispiele 35 bis 46, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden einer Kostenfunktion beinhaltet.
  • Bei Beispiel 48 beinhaltet der Gegenstand der Beispiele 35 bis 47, dass ein Modifizieren des administrativen absichtsbasierten SLO, um den revidierten Satz unerlässlicher Richtlinien zu erzeugen, Folgendes beinhaltet: Arbitrieren zwischen mehreren SLOs, die auf der Infrastruktur in Kraft sind; und Modifizieren des administrativen absichtsbasierten SLO basierend auf einer Priorität des administrativen absichtsbasierten SLO mit Bezug auf die mehreren SLOs, die auf der Infrastruktur in Kraft sind.
  • Bei Beispiel 49 beinhaltet der Gegenstand der Beispiele 35 bis 48 Anweisungen zum Durchführen von Operationen, die Folgendes beinhalten: Empfangen eines Anwendungs-SLO für eine Anwendung; Bestimmen einer vorgeschlagenen Ressourcenzuweisung zum Ausführen der Anwendung; Überprüfen der vorgeschlagenen Ressourcenzuweisung unter Verwendung einer Gebührenleitplankenfunktion, wobei die Gebührenleitplankenfunktion konfiguriert ist, um eine Abrechnung für die vorgeschlagene Ressourcenzuweisung vorherzusagen; und Benachrichtigen einer Planungskomponente, um fortzufahren, wenn die vorgeschlagene Ressourcenzuweisung die Gebührenleitplankenfunktion nicht verletzt.
  • In Beispiel 50 beinhaltet der Gegenstand der Beispiele 35 bis 49 Anweisungen zum Durchführen von Operationen, die Folgendes beinhalten: Ermitteln, ob ein Schnellstartlebenszyklusmechanismus aktiviert ist; Bereitstellen eines Dienstes in einer Sandkasteninstanz, wenn der Schnellstartlebenszyklusmechanismus aktiviert ist; und Migrieren des Dienstes vom Sandkasten in eine Produktionsumgebung.
  • Beispiel 51 ist eine Einrichtung zum Implementieren einer absichtsbasierten Clusterverwaltung, die Folgendes umfasst: Mittel zum Empfangen, am Orchestratorsystem, eines administrativen absichtsbasierten Service-Level-Ziels (SLO) für eine Infrastrukturkonfiguration einer Infrastruktur; Mittel zum Abbilden des administrativen absichtsbasierten SLO auf einen Satz unbedingter Richtlinien; Mittel zum Bereitstellen des Satzes unbedingter Richtlinien an die Infrastruktur; Mittel zum Überwachen der Leistungsfähigkeit der Infrastruktur; Mittel zum Detektieren einer Nichtkonformität mit dem Satz unbedingter Richtlinien; und Mittel zum Modifizieren des administrativen absichtsbasierten SLO, um einen revidierten Satz unbedingter Richtlinien zu erzeugen, die bewirken, dass die Leistung der Infrastruktur mit dem revidierten Satz unbedingter Richtlinien konform ist.
  • In Beispiel 52 beinhaltet der Gegenstand des Beispiels 51, dass der Satz unbedingter Richtlinien die Leistungsüberwachung regelt.
  • In Beispiel 53 beinhaltet der Gegenstand der Beispiele 51 bis 52, dass der Satz unbedingter Richtlinien ein Leistungsbudget und eine Leistungsbegrenzung regelt.
  • In Beispiel 54 beinhaltet der Gegenstand der Beispiele 51 bis 53, dass der Satz unbedingter Richtlinien die Konfiguration der Hardwareinfrastruktur regelt.
  • In Beispiel 55 beinhaltet der Gegenstand der Beispiele 51 bis 54, dass der Satz unbedingter Richtlinien die Netzwerkkonnektivität auf Knotenebene, die Netzwerkkonnektivität auf Leaf-Ebene, die Netzwerkkonnektivität auf Spine-Ebene oder die Netzwerkkonnektivität auf Rack-Ebene regelt.
  • In Beispiel 56 beinhaltet der Gegenstand der Beispiele 51 bis 55, dass der Satz unbedingter Richtlinien die Inventarverwaltung regelt.
  • In Beispiel 57 beinhaltet der Gegenstand der Beispiele 51 bis 56, dass der Satz unbedingter Richtlinien Mandantensicherheit und Datenschutz regelt.
  • In Beispiel 58 beinhaltet der Gegenstand der Beispiele 51 bis 57, dass das administrative absichtsbasierte SLO eine zeitbasierte Beschränkung beinhaltet.
  • In Beispiel 59 beinhaltet der Gegenstand der Beispiele 51 bis 58, dass das administrative absichtsbasierte SLO eine gestufte Migrationsanweisung beinhaltet.
  • In Beispiel 60 beinhaltet der Gegenstand der Beispiele 51 bis 59, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eines statischen vorbestimmten Abbildens beinhaltet.
  • In Beispiel 61 beinhaltet der Gegenstand der Beispiele 51 bis 60, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eines zeitbasierten Abbildens beinhaltet, das sich im Zeitverlauf ändert.
  • In Beispiel 62 beinhaltet der Gegenstand der Beispiele 51 bis 61, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eines Maschinenlernmodells zum Ableiten des Satzes unbedingter Richtlinien beinhaltet.
  • In Beispiel 63 beinhaltet der Gegenstand der Beispiele 51 bis 62, dass ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden einer Kostenfunktion beinhaltet.
  • Bei Beispiel 64 beinhaltet der Gegenstand der Beispiele 51 bis 63, dass ein Modifizieren des administrativen absichtsbasierten SLO, um den revidierten Satz unbedingter Richtlinien zu erzeugen, Folgendes beinhaltet: Arbitrieren zwischen mehreren SLOs, die auf der Infrastruktur in Kraft sind; und Modifizieren des administrativen absichtsbasierten SLO basierend auf einer Priorität des administrativen absichtsbasierten SLO mit Bezug auf die mehreren SLOs, die auf der Infrastruktur in Kraft sind.
  • Bei Beispiel 65 beinhaltet der Gegenstand der Beispiele 51 bis 64 Anweisungen zum Durchführen von Operationen, die Folgendes beinhalten: Empfangen eines Anwendungs-SLO für eine Anwendung; Bestimmen einer vorgeschlagenen Ressourcenzuweisung zum Ausführen der Anwendung; Überprüfen der vorgeschlagenen Ressourcenzuweisung unter Verwendung einer Gebührenleitplankenfunktion, wobei die Gebührenleitplankenfunktion konfiguriert ist, um eine Abrechnung für die vorgeschlagene Ressourcenzuweisung vorherzusagen; und Benachrichtigen einer Planungskomponente, um fortzufahren, wenn die vorgeschlagene Ressourcenzuweisung die Gebührenleitplankenfunktion nicht verletzt.
  • In Beispiel 66 beinhaltet der Gegenstand der Beispiele 51 bis 65 Anweisungen zum Durchführen von Operationen, die Folgendes beinhalten: Ermitteln, ob ein Schnellstartlebenszyklusmechanismus aktiviert ist; Bereitstellen eines Dienstes in einer Sandkasteninstanz, wenn der Schnellstartlebenszyklusmechanismus aktiviert ist; und Migrieren des Dienstes vom Sandkasten in eine Produktionsumgebung.
  • Beispiel 67 ist mindestens ein maschinenlesbares Medium, das Anweisungen beinhaltet, die bei Ausführung durch eine Verarbeitungsschaltungsanordnung bewirken, dass die Verarbeitungsschaltungsanordnung Operationen zum Implementieren nach einem der Beispiele 1 bis 66 durchführt.
  • Beispiel 68 ist eine Einrichtung, die Mittel zum Implementieren eines der Beispiele 1 bis 66 umfasst.
  • Beispiel 69 ist ein System zum Implementieren eines der Beispiele 1 bis 66.
  • Beispiel 70 ist ein Verfahren zum Implementieren eines der Beispiele 1 bis 66.
  • Die obige ausführliche Beschreibung beinhaltet Referenzen auf die begleitenden Zeichnungen, die einen Teil der ausführlichen Beschreibung bilden. Die Zeichnungen zeigen zur Veranschaulichung spezifische Ausführungsformen, die umgesetzt werden können. Diese Ausführungsformen werden hier auch als „Beispiele“ bezeichnet. Solche Beispiele können Elemente zusätzlich zu jenen gezeigten oder beschriebenen beinhalten. Es kommen jedoch auch Beispiele in Betracht, die die gezeigten oder beschriebenen Elemente beinhalten. Darüber hinaus sind auch Beispiele denkbar, bei denen beliebige Kombination oder Permutation der gezeigten oder beschriebenen Elemente (oder eines oder mehrerer Aspekte davon) verwendet wird, entweder in Bezug auf ein bestimmtes Beispiel (oder einen oder mehrere Aspekte davon) oder in Bezug auf andere Beispiele (oder einen oder mehrere Aspekte davon), die hierin gezeigt oder beschrieben sind.
  • Veröffentlichungen, Patente und Patentdokumente, auf die in diesem Dokument Bezug genommen wird, sind hierin in ihrer Gesamtheit durch Bezugnahme eingebunden, als ob sie einzeln durch Bezugnahme eingebunden wären. Bei widersprüchlicher Verwendungen zwischen diesem Dokument und den durch Bezugnahme aufgenommenen Dokumenten ergänzt die Verwendungen in der/den aufgenommenen Referenz(en) diejenige dieses Dokuments; bei unüberbrückbaren Widersprüchen hat die Verwendung in diesem Dokument Vorrang.
  • In diesem Dokument werden die Begriffe „ein“ oder „ein“ verwendet, wie es in Patentdokumenten üblich ist, um eine oder mehr als eines einzuschließen, unabhängig von anderen Instanzen oder Verwendungen von „mindestens ein“ oder „ein oder mehreren“. In diesem Dokument wird der Begriff „oder“ verwendet, um sich auf ein nichtexklusives Oder zu beziehen, so dass „A oder B“ „A, aber nicht B“, „B, aber nicht A“ und „A und B“ beinhaltet, sofern nicht anders angegeben. In den beigefügten Ansprüchen werden die Begriffe „beinhaltend/einschließlich“ und „in denen“ als einfach verständliche Äquivalente der jeweiligen Begriffe „umfassend“ und „wobei“ verwendet. Außerdem werden in den folgenden Ansprüchen die Begriffe „beinhaltend“ und „umfassend“ offen verwendet, das heißt, ein System, eine Vorrichtung, ein Artikel oder ein Prozess, der Elemente zusätzlich zu jenen beinhaltet, die nach solch einem Begriff in einem Anspruch aufgelistet sind, werden noch als in den Schutzumfang dieses Anspruchs fallend angesehen. Zudem werden in den folgenden Ansprüchen die Begriffe „erster“, „zweiter“ und „dritter“ usw. lediglich als Bezeichnungen verwendet und sollen keine numerische Reihenfolge für ihre Objekte andeuten.
  • Die obige Beschreibung soll veranschaulichend und nicht einschränkend sein. Zum Beispiel können die oben beschriebenen Beispiele (oder ein oder mehrere Aspekte davon) in Kombination mit anderen verwendet werden. Andere Ausführungsformen können verwendet werden, wie etwa durch einen Durchschnittsfachmann beim Überprüfen der obigen Beschreibung. Die Zusammenfassung soll es dem Leser ermöglichen, die Natur der technischen Offenbarung schnell zu ermitteln. Sie wird mit dem Verständnis eingereicht, dass sie dazu verwendet wird, den Schutzumfang oder die Bedeutung der Ansprüche zu interpretieren oder zu beschränken. Außerdem können in der obigen ausführlichen Beschreibung verschiedene Merkmale gruppiert werden, um die Offenbarung zu straffen. Die Ansprüche legen jedoch möglicherweise nicht jedes hier offenbarte Merkmal dar, da Ausführungsformen eine Teilmenge der Merkmale aufweisen können. Ferner können Ausführungsformen weniger Merkmale als jene beinhalten, die in einem bestimmten Beispiel offenbart sind. Deshalb sind die folgenden Ansprüche hiermit in die ausführliche Beschreibung aufgenommen, wobei ein Anspruch eigenständig als eine separate Ausführungsform steht. Der Umfang der hierin offenbarten Ausführungsformen sollte in Bezug auf die angefügten Patentansprüche zusammen mit dem vollen Umfang von Äquivalenten ermittelt werden, zu denen derartige Patentansprüche berechtigt sind.
  • ZITATE ENTHALTEN IN DER BESCHREIBUNG
  • Diese Liste der vom Anmelder aufgeführten Dokumente wurde automatisiert erzeugt und ist ausschließlich zur besseren Information des Lesers aufgenommen. Die Liste ist nicht Bestandteil der deutschen Patent- bzw. Gebrauchsmusteranmeldung. Das DPMA übernimmt keinerlei Haftung für etwaige Fehler oder Auslassungen.
  • Zitierte Patentliteratur
    • US 63280001 [0001]

Claims (25)

  1. Orchestratorsystem zum Implementieren einer absichtsbasierten Clusterverwaltung, das Folgendes umfasst: einen Prozessor; und Speicher zum Speichern von Anweisungen, die bei Ausführung durch den Prozessor das Orchestratorsystem zu Folgendem veranlassen: Empfangen, am Orchestratorsystem, eines administrativen absichtsbasierten Service-Level-Ziels (SLO) für eine Infrastrukturkonfiguration einer Infrastruktur; Abbilden des administrativen absichtsbasierten SLO auf einen Satz unbedingter Richtlinien; Bereitstellen des Satzes unbedingter Richtlinien an die Infrastruktur; Überwachen der Leistungsfähigkeit der Infrastruktur; Detektieren einer Nichterfüllung des Satzes unbedingter Richtlinien; und Modifizieren des administrativen absichtsbasierten SLO, um einen revidierten Satz unbedingter Richtlinien zu erzeugen, die bewirken, dass die Leistungsfähigkeit der Infrastruktur mit dem revidierten Satz unbedingter Richtlinien konform ist.
  2. Orchestratorsystem nach Anspruch 1, wobei der Satz unbedingter Richtlinien die Leistungsüberwachung regelt.
  3. Orchestratorsystem nach einem der Ansprüche 1 bis 2, wobei der Satz unbedingter Richtlinien ein Leistungsbudget und eine Leistungsbegrenzung regelt.
  4. Orchestratorsystem nach einem der Ansprüche 1 bis 3, wobei der Satz unbedingter Richtlinien die Konfiguration der Hardwareinfrastruktur regelt.
  5. Orchestratorsystem nach einem der Ansprüche 1 bis 4, wobei der Satz unbedingter Richtlinien die Netzwerkkonnektivität auf Knotenebene, die Netzwerkkonnektivität auf Leaf-Ebene, die Netzwerkkonnektivität auf Spine-Ebene oder die Netzwerkkonnektivität auf Rack-Ebene regelt.
  6. Orchestratorsystem nach einem der Ansprüche 1 bis 5, wobei der Satz unbedingter Richtlinien die Inventarverwaltung regelt.
  7. Orchestratorsystem nach einem der Ansprüche 1 bis 6, wobei der Satz unbedingter Richtlinien die Mandantensicherheit und den Datenschutz regelt.
  8. Orchestratorsystem nach einem der Ansprüche 1 bis 7, wobei das administrative absichtsbasierte SLO eine zeitbasierte Beschränkung beinhaltet.
  9. Orchestratorsystem nach einem der Ansprüche 1 bis 7, wobei das administrative absichtsbasierte SLO eine gestufte Migrationsanweisung beinhaltet.
  10. Orchestratorsystem nach einem der Ansprüche 1 bis 9, wobei zum Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien das System dazu ausgelegt ist, ein statisches vorbestimmtes Abbilden zu verwenden.
  11. Orchestratorsystem nach einem der Ansprüche 1 bis 9, wobei zum Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien das System dazu ausgelegt ist, ein zeitbasiertes Abbilden zu verwenden, das sich im Zeitverlauf ändert.
  12. Orchestratorsystem nach einem der Ansprüche 1 bis 9, wobei das System zum Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien dazu ausgelegt ist, ein Maschinenlernmodell zu verwenden, um den Satz unbedingter Richtlinien abzuleiten.
  13. Orchestratorsystem nach einem der Ansprüche 1 bis 12, wobei zum Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien das System dazu ausgelegt ist, eine Kostenfunktion zu verwenden.
  14. Orchestratorsystem nach einem der Ansprüche 1 bis 13, wobei das System zum Modifizieren des administrativen absichtsbasierten SLO, um den revidierten Satz unbedingter Richtlinien zu erzeugen, ausgelegt ist zum: Arbitrieren zwischen mehreren SLOs, die auf der Infrastruktur in Kraft sind; und Modifizieren des administrativen absichtsbasierten SLO basierend auf einer Priorität des administrativen absichtsbasierten SLO mit Bezug auf die mehreren SLOs, die auf der Infrastruktur in Kraft sind.
  15. Orchestratorsystem nach einem der Ansprüche 1 bis 14, wobei das System ausgelegt ist zum: Empfangen eines Anwendungs-SLO für eine Anwendung; Bestimmen einer vorgeschlagenen Ressourcenzuweisung zum Ausführen der Anwendung; Überprüfen der vorgeschlagenen Ressourcenzuweisung unter Verwendung einer Gebührenleitplankenfunktion, wobei die Gebührenleitplankenfunktion dazu ausgelegt ist, eine Abrechnung für die vorgeschlagene Ressourcenzuweisung vorherzusagen; und Benachrichtigen einer Planungskomponente, um fortzufahren, wenn die vorgeschlagene Ressourcenzuweisung die Gebührenleitplankenfunktion nicht verletzt.
  16. Orchestratorsystem nach einem der Ansprüche 1 bis 15, wobei das System ausgelegt ist zum: Ermitteln, ob ein Schnellstartlebenszyklusmechanismus aktiviert ist; Bereitstellen eines Dienstes in einer Sandkasteninstanz, wenn der Schnellstartlebenszyklusmechanismus aktiviert ist; und Migrieren des Dienstes vom Sandkasten in eine Produktionsumgebung.
  17. Verfahren zum Implementieren einer absichtsbasierten Clusterverwaltung, das Folgendes umfasst: Empfangen, an einem Orchestratorsystem, eines administrativen absichtsbasierten Service-Level-Ziels (SLO) für eine Infrastrukturkonfiguration einer Infrastruktur; Abbilden des administrativen absichtsbasierten SLO auf einen Satz unbedingter Richtlinien; Bereitstellen des Satzes unbedingter Richtlinien an die Infrastruktur; Überwachen der Leistungsfähigkeit der Infrastruktur; Detektieren einer Nichtkonformität mit dem Satz unbedingter Richtlinien; und Modifizieren des administrativen absichtsbasierten SLO, um einen revidierten Satz unbedingter Richtlinien zu erzeugen, die bewirken, dass die Leistungsfähigkeit der Infrastruktur mit dem revidierten Satz unbedingter Richtlinien konform ist.
  18. Verfahren nach Anspruch 17, wobei ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eines zeitbasierten Abbildens beinhaltet, das sich im Zeitverlauf ändert.
  19. Verfahren nach einem der Ansprüche 17 bis 18, wobei ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden eines Maschinenlernmodells zum Ableiten des Satzes unbedingter Richtlinien beinhaltet.
  20. Verfahren nach einem der Ansprüche 17 bis 19, wobei ein Abbilden des administrativen absichtsbasierten SLO auf den Satz unbedingter Richtlinien ein Verwenden einer Kostenfunktion beinhaltet.
  21. Verfahren nach einem der Ansprüche 17 bis 20, wobei ein Modifizieren des administrativen absichtsbasierten SLO, um den revidierten Satz unbedingter Richtlinien zu erzeugen, Folgendes beinhaltet: Arbitrieren zwischen mehreren SLOs, die auf der Infrastruktur in Kraft sind; und Modifizieren des administrativen absichtsbasierten SLO basierend auf einer Priorität des administrativen absichtsbasierten SLO mit Bezug auf die mehreren SLOs, die auf der Infrastruktur in Kraft sind.
  22. Verfahren nach einem der Ansprüche 17 bis 21, das Folgendes beinhaltet: Empfangen eines Anwendungs-SLO für eine Anwendung; Bestimmen einer vorgeschlagenen Ressourcenzuweisung zum Ausführen der Anwendung; Überprüfen der vorgeschlagenen Ressourcenzuweisung unter Verwendung einer Gebührenleitplankenfunktion, wobei die Gebührenleitplankenfunktion dazu ausgelegt ist, eine Abrechnung für die vorgeschlagene Ressourcenzuweisung vorherzusagen; und Benachrichtigen einer Planungskomponente, um fortzufahren, wenn die vorgeschlagene Ressourcenzuweisung die Gebührenleitplankenfunktion nicht verletzt.
  23. Verfahren nach einem der Ansprüche 17 bis 22, das Folgendes beinhaltet: Ermitteln, ob ein Schnellstartlebenszyklusmechanismus aktiviert ist; Bereitstellen eines Dienstes in einer Sandkasteninstanz, wenn der Schnellstartlebenszyklusmechanismus aktiviert ist; und Migrieren des Dienstes vom Sandkasten in eine Produktionsumgebung.
  24. Mindestens ein maschinenlesbares Medium mit Anweisungen, die bei Ausführung durch eine Maschine die Maschine veranlassen, Operationen nach einem der Verfahren nach einem der Ansprüche 17 bis 23 durchzuführen.
  25. Einrichtung zum Implementieren einer absichtsbasierten Clusterverwaltung, die Folgendes umfasst: Mittel zum Empfangen, am Orchestratorsystem, eines administrativen absichtsbasierten Service-Level-Ziels (SLO) für eine Infrastrukturkonfiguration einer Infrastruktur; Mittel zum Abbilden des administrativen absichtsbasierten SLO auf einen Satz unbedingter Richtlinien; Mittel zum Bereitstellen des Satzes unbedingter Richtlinien an die Infrastruktur; Mittel zum Überwachen der Leistungsfähigkeit der Infrastruktur; Mittel zum Detektieren einer Nichtkonformität mit dem Satz unbedingter Richtlinien; und Mittel zum Modifizieren des administrativen absichtsbasierten SLO, um einen revidierten Satz unbedingter Richtlinien zu erzeugen, die bewirken, dass die Leistungsfähigkeit der Infrastruktur mit dem revidierten Satz unbedingter Richtlinien konform ist.
DE102022212157.0A 2021-11-16 2022-11-15 Absichtsbasierte clusterverwaltung Pending DE102022212157A1 (de)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US202163280001P 2021-11-16 2021-11-16
US63/280,001 2021-11-16
US17/561,181 US20220121455A1 (en) 2021-11-16 2021-12-23 Intent-based cluster administration
US17/561,181 2021-12-23

Publications (1)

Publication Number Publication Date
DE102022212157A1 true DE102022212157A1 (de) 2023-05-17

Family

ID=80122872

Family Applications (2)

Application Number Title Priority Date Filing Date
DE102022212157.0A Pending DE102022212157A1 (de) 2021-11-16 2022-11-15 Absichtsbasierte clusterverwaltung
DE102022212115.5A Pending DE102022212115A1 (de) 2021-11-16 2022-11-15 Systeme und verfahren zur reaktiven, absichtsgesteuerten end-to-end-orchestrierung

Family Applications After (1)

Application Number Title Priority Date Filing Date
DE102022212115.5A Pending DE102022212115A1 (de) 2021-11-16 2022-11-15 Systeme und verfahren zur reaktiven, absichtsgesteuerten end-to-end-orchestrierung

Country Status (5)

Country Link
US (6) US20220121455A1 (de)
KR (2) KR20230073371A (de)
CN (1) CN117501246A (de)
DE (2) DE102022212157A1 (de)
WO (1) WO2023091036A1 (de)

Families Citing this family (38)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11159650B2 (en) * 2018-11-02 2021-10-26 Lg Electronics Inc. Broadcast signal transmission apparatus, broadcast signal transmission method, broadcast signal reception apparatus and broadcast signal reception method
US20220300344A1 (en) * 2019-06-12 2022-09-22 Arigato Machine, Inc., Dba Manifold Flexible credential supported software service provisioning
CN110618871B (zh) * 2019-09-21 2022-07-22 苏州浪潮智能科技有限公司 一种fpga云平台加速资源的分配方法与系统
US11544113B2 (en) * 2019-11-20 2023-01-03 Google Llc Task scheduling for machine-learning workloads
CN114846444A (zh) * 2019-12-19 2022-08-02 皇家飞利浦有限公司 基于动态要求的动态个性化平台生成
US11570638B2 (en) * 2020-06-26 2023-01-31 Intel Corporation Automated network control systems that adapt network configurations based on the local network environment
US11770377B1 (en) * 2020-06-29 2023-09-26 Cyral Inc. Non-in line data monitoring and security services
EP4193302A1 (de) * 2020-08-05 2023-06-14 Avesha, Inc. Durchführung einer lastausgleichsselbsteinstellung in einer anwendungsumgebung
US11671484B2 (en) * 2020-09-25 2023-06-06 Verizon Patent And Licensing Inc. Methods and systems for orchestrating a distributed computing service based on latency performance levels
US20210081271A1 (en) * 2020-09-25 2021-03-18 Intel Corporation Dynamic tracing control
US11972193B1 (en) * 2020-10-01 2024-04-30 Synopsys, Inc. Automatic elastic CPU for physical verification
KR102650892B1 (ko) * 2021-04-12 2024-03-26 한국전자통신연구원 지역적으로 분산된 다중 클라우드 환경에서의 컨테이너 오케스트레이션 장치 및 이를 이용한 방법
US20220350675A1 (en) 2021-05-03 2022-11-03 Avesha, Inc. Distributed computing system with multi tenancy based on application slices
US11916951B2 (en) * 2021-06-14 2024-02-27 Jamf Software, Llc Mobile device management for detecting and remediating common vulnerabilities and exposures
US11726894B2 (en) * 2021-08-12 2023-08-15 Sap Se Runtime entropy-based software operators
US11575696B1 (en) * 2021-09-20 2023-02-07 Normalyze, Inc. Cloud data attack detection based on cloud security posture and resource network path tracing
US20230222045A1 (en) * 2022-01-13 2023-07-13 Dell Products L.P. System and method for enhanced container deployment
US11971990B2 (en) 2022-01-13 2024-04-30 Dell Products L.P. System and method for container validation
US11880950B2 (en) * 2022-03-14 2024-01-23 Meta Platforms Technologies, Llc Selective offload of workloads to edge devices
US20220245903A1 (en) * 2022-03-14 2022-08-04 Facebook Technologies, Llc Selective Offload of Workloads to Edge Devices
US11743108B1 (en) * 2022-03-15 2023-08-29 Cisco Technology, Inc. Dynamic customization of network controller data path based on controller internal state awareness
US20230344714A1 (en) * 2022-04-22 2023-10-26 Microsoft Technology Licensing, Llc Global intent-based configuration to local intent targets
US11989200B2 (en) * 2022-05-25 2024-05-21 Nutanix, Inc. System and method for lambda buckets
US11853176B1 (en) * 2022-06-09 2023-12-26 Sap Se Service-compatible fault tolerance and acclimation
US20230409307A1 (en) * 2022-06-15 2023-12-21 Harness Inc. Automatic progressive rollout of software update
WO2023247042A1 (en) * 2022-06-23 2023-12-28 Telefonaktiebolaget Lm Ericsson (Publ) Detection of host container monitoring
US11886864B1 (en) * 2022-07-18 2024-01-30 International Business Machines Corporation Enhanced edge application deployment and processing in a network
US11915059B2 (en) * 2022-07-27 2024-02-27 Oracle International Corporation Virtual edge devices
CN115412609B (zh) * 2022-08-16 2023-07-28 中国联合网络通信集团有限公司 一种业务处理方法、装置、服务器及存储介质
US11863404B1 (en) * 2022-08-23 2024-01-02 Verizon Patent And Licensing Inc. Systems and methods for calculating optimum customer access paths for applications provided by multi-cloud providers through private networks
CN117724764A (zh) * 2022-09-09 2024-03-19 达发科技(苏州)有限公司 网络处理单元的算法分析方法及装置和存储介质
US11907230B1 (en) 2023-01-10 2024-02-20 Dell Products L.P. System and method for distributed management of hardware based on intent
US11929891B1 (en) * 2023-01-10 2024-03-12 Dell Products L.P. System and method for distributed management of hardware through relationship management
US11763006B1 (en) * 2023-01-19 2023-09-19 Citibank, N.A. Comparative real-time end-to-end security vulnerabilities determination and visualization
US11748491B1 (en) * 2023-01-19 2023-09-05 Citibank, N.A. Determining platform-specific end-to-end security vulnerabilities for a software application via a graphical user interface (GUI) systems and methods
US11874934B1 (en) 2023-01-19 2024-01-16 Citibank, N.A. Providing user-induced variable identification of end-to-end computing system security impact information systems and methods
CN116467068A (zh) * 2023-03-14 2023-07-21 浙江大学 资源调度方法、设备及存储介质
CN117349034B (zh) * 2023-12-05 2024-02-23 创意信息技术股份有限公司 一种大语言模型分层加载方法及装置

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09179235A (ja) 1995-12-27 1997-07-11 Konica Corp ハロゲン化銀写真感光材料及びその処理方法
US11824784B2 (en) * 2019-12-20 2023-11-21 Intel Corporation Automated platform resource management in edge computing environments
CN112073531B (zh) * 2020-09-15 2021-10-19 常熟理工学院 一种基于边缘计算的物联网实时监测系统的实现方法
US20210014133A1 (en) * 2020-09-25 2021-01-14 Intel Corporation Methods and apparatus to coordinate edge platforms

Also Published As

Publication number Publication date
US20220124009A1 (en) 2022-04-21
US20220113790A1 (en) 2022-04-14
US20220124005A1 (en) 2022-04-21
KR20230073371A (ko) 2023-05-25
US20220114251A1 (en) 2022-04-14
US20220116455A1 (en) 2022-04-14
CN117501246A (zh) 2024-02-02
DE102022212115A1 (de) 2023-05-17
WO2023091036A1 (en) 2023-05-25
US20220121455A1 (en) 2022-04-21
KR20230073372A (ko) 2023-05-25

Similar Documents

Publication Publication Date Title
DE102022212157A1 (de) Absichtsbasierte clusterverwaltung
DE102021209145A1 (de) Verfahren und vorrichtung zum koordinieren von edge-plattformen
EP3998720A2 (de) Orchestrator-ausführungsplanung unter verwendung eines verteilten ledgers
DE102021209146A1 (de) Adaptive edge-ressourcenverwaltung mit begrenzter dauer
DE102022203247A1 (de) Disintermedierte Attestierung in einem MEC-Service-MESH-Framework
DE112020003742T5 (de) Verfahren, systeme, erzeugnisse und vorrichtungen zur verbesserung von jobplanungseffizienz
DE102021209282A1 (de) Verfahren, einrichtungen und systeme zur gemeinsamen nutzung von rechenressourcen zwischen edge-rechenknoten unter verwendung eines overlay-managers
EP4156745A1 (de) Unlizenzierte spektrumsnutzung mit kollaborativer spektrumserfassung in netzwerken der nächsten generation
DE102021207160A1 (de) Verfahren und einrichtung zur verwaltung der dienstgüte in bezug auf service-level-agreements in einer rechenvorrichtung
DE102022203249A1 (de) Mehrfachzugriff-edge-computing- (mec-) fahrzeug-zu-alles-(v2x-) interoperabilitätsunterstützung für mehrere v2x-nachrichtenbroker
US20210011823A1 (en) Continuous testing, integration, and deployment management for edge computing
DE102021117809A1 (de) Einrichtungen, Systeme, Fabrikate und Verfahren zur Datenlebenszyklusverwaltung in einer Edge-Umgebung
US20210328933A1 (en) Network flow-based hardware allocation
DE102021210882A1 (de) Erweitertes peer-to-peer (p2p) mit edge-vernetzung
US20220014947A1 (en) Dynamic slice reconfiguration during fault-attack-failure-outage (fafo) events
DE112020007229T5 (de) Föderiertes mec-framework für kraftfahrzeugdienste
DE102022208684A1 (de) Verfahren und einrichtung für resilienz mithilfe digitaler zwillinge
DE102022212395A1 (de) Ende-zu-ende-netzwerk-slicing (ens) vom ran- zum kernnetz für kommunikationen der nächsten generation (ng)
US20220116289A1 (en) Adaptive cloud autoscaling
DE102021211772A1 (de) Verfahren und einrichtung zur ermöglichung von sicherem multikohärentem poolspeicher in einem edge-netzwerk
DE102021209043A1 (de) Methods and apparatus to select a location of execution of a computation
DE102022128300A1 (de) Verfahren und einrichtungen zum implementieren einer edge-skalierbaren adaptiv granulierten überwachung und telemetrieverarbeitung für multi-qos-dienste
DE102022208681A1 (de) Schichtübergreifende automatisierte fehlernachverfolgung und anomaliedetektion
DE102021121267A1 (de) Verfahren, Systeme, Vorrichtungen und Erzeugnisse zur Verwaltung des Zugriffs auf dezentrale Data Lakes
US20230020732A1 (en) Adaptable sensor data collection