DE102020110143A1 - Standortbasierte virtualisierungs-workload-platzierung - Google Patents

Standortbasierte virtualisierungs-workload-platzierung Download PDF

Info

Publication number
DE102020110143A1
DE102020110143A1 DE102020110143.0A DE102020110143A DE102020110143A1 DE 102020110143 A1 DE102020110143 A1 DE 102020110143A1 DE 102020110143 A DE102020110143 A DE 102020110143A DE 102020110143 A1 DE102020110143 A1 DE 102020110143A1
Authority
DE
Germany
Prior art keywords
virtualization
network
nodes
workload
placement
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
DE102020110143.0A
Other languages
English (en)
Inventor
Brian J. Martin
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.)
Hewlett Packard Enterprise Development LP
Original Assignee
Hewlett Packard Enterprise Development LP
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 Hewlett Packard Enterprise Development LP filed Critical Hewlett Packard Enterprise Development LP
Publication of DE102020110143A1 publication Critical patent/DE102020110143A1/de
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • 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/48—Program initiating; Program switching, e.g. by interrupt
    • G06F9/4806—Task transfer initiation or dispatching
    • G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
    • G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
    • 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]
    • 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
    • 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/5083—Techniques for rebalancing the load in a distributed system
    • 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/08—Configuration management of networks or network elements
    • H04L41/0803—Configuration setting
    • H04L41/0806—Configuration setting for initial configuration or provisioning, e.g. plug-and-play
    • 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/08—Configuration management of networks or network elements
    • H04L41/0895—Configuration of virtualised networks or elements, e.g. virtualised network function or OpenFlow elements
    • 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/12—Discovery or management of network topologies
    • 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/12—Discovery or management of network topologies
    • H04L41/122—Discovery or management of network topologies of virtualised topologies, e.g. software-defined networks [SDN] or network function virtualisation [NFV]
    • 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/40—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks using virtualisation of network functions or resources, e.g. SDN or NFV entities
    • 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/06—Generation of reports
    • H04L43/065—Generation of reports related to network devices
    • 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/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0811—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking connectivity
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L45/00—Routing or path finding of packets in data switching networks
    • H04L45/02—Topology update or discovery
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/4557—Distribution of virtual machine instances; Migration and load balancing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances
    • 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/0805—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability
    • H04L43/0817—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters by checking availability by checking functioning

Landscapes

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

Abstract

In einigen Beispielen umfasst ein Verfahren Folgendes: Empfangen von Netzwerk-Lokalitätsinformationen für Virtualisierungsausrüstung mit einem Computer-Virtualisierungs-Scheduler; Empfangen von Netzwerkauslastungsinformationen für Virtualisierungsausrüstung mit dem Computer-Virtualisierungs-Scheduler; und Bestimmen der Virtualisierungsarbeitslastplatzierung mit dem Computer-Virtualisierungs-Scheduler und basierend auf den empfangenen Netzwerk-Lokalitätsinformationen und den empfangenen Netzwerkauslastungsinformationen, um die verfügbare Netzwerkbandbreite zu maximieren und die Netzwerklatenz zwischen Virtualisierungsausrüstung zu minimieren.

Description

  • HINTERGRUND
  • Cloud Computing hat die Art und Weise, wie die Infrastruktur der Informationstechnologie („IT“) genutzt wird, erheblich beeinflusst. Mit Hilfe der Virtualisierungstechnologie ist es möglich, Arbeitslasten über eine Vielzahl virtueller Infrastrukturen bereitzustellen, die von öffentlichen Cloud-Umgebungen bis hin zu Rechenzentren vor Ort reichen, die auf lokaler Hardware basieren. Es werden ständig neue Arbeitslasten für Anwendungen gegeneine solche virtuelle Infrastruktur erstellt, bereitgestellt und verbraucht.
  • Figurenliste
    • ist ein Flussdiagramm für eine Methode nach einem Beispiel.
    • ist eine Illustration einer beispielhaften „Standard“-Einstellung des Netzstandortes.
    • ist eine Illustration einer beispielhaften „lokalen“ Netzwerklokalitätseinstellung .
    • ist eine Illustration eines Beispiels für die Einstellung „benachbarter“ Netzstandorte.
    • ist eine Illustration eines Beispiels für die „direkte“ Einstellung einer Netzwerklokalität.
    • ist ein Schema einer Rechenanlage nach einem Beispiel.
    • ist ein Schema eines maschinenlesbaren Speichermediums nach einem Beispiel.
  • DETAILLIERTE BESCHREIBUNG
  • Die folgende Diskussion ist auf verschiedene Beispiele der Offenlegung gerichtet. Obwohl eines oder mehrere dieser Beispiele bevorzugt werden können, sollten die hier offengelegten Beispiele nicht so interpretiert oder anderweitig verwendet werden, dass sie den Umfang der Offenlegung, einschließlich der Ansprüche, einschränken. Darüber hinaus hat die folgende Beschreibung eine weite Anwendung, und die Erörterung eines Beispiels soll nur beschreibend für dieses Beispiel sein und nicht den Eindruck erwecken, dass der Umfang der Offenbarung, einschließlich der Ansprüche, auf dieses Beispiel beschränkt ist. Darüber hinaus bedeutet der Begriff „einschliesslich“, wie er hier verwendet wird, einschliesslich, aber nicht beschränkt auf, der Begriff „einschliesslich“ bedeutet einschliesslich, aber nicht beschränkt auf. Der Begriff „basierend auf“ bedeutet, zumindest teilweise basierend auf.
  • Virtuelle Maschinen („VMs“) sind ein beliebter Mechanismus für die Bereitstellung von Cloud-Computing-Anwendungsinfrastrukturen. In einigen Implementierungen können sich mehrere Instanzen einer VM dieselbe physische Hardware teilen, und jede Anwendungs-VM kann ihren eigenen Satz von Betriebssystem, Netzwerk und Speicher haben. Unter bestimmten Umständen kann es vorzuziehen sein, einen Anwendungs-Workload mit virtualisierten Containern statt mit VMs bereitzustellen. Wie hier verwendet, kann sich der Begriff „Container“ beispielsweise auf eine Virtualisierung auf Betriebssystemebene beziehen, bei der ein Kernel oder ein anderer Mechanismus mehrere isolierte User-Space-Instanzen ermöglicht. Solche Instanzen können z.B. als Container, Partitionen, Virtualisierungsmaschinen („VEs“), Gefängnisse oder ein anderer geeigneter Begriff bezeichnet werden. Solche Instanzen können z.B. so gestaltet werden, dass sie aus der Sicht der darin laufenden Programme wie echte Computer aussehen. Im Vergleich zu einem herkömmlichen Computerprogramm, bei dem alle Ressourcen (z.B. angeschlossene Geräte, Dateien und Ordner, Netzwerkfreigaben, Leistung der Zentraleinheit („CPU“), quantifizierbare Hardware-Fähigkeiten) des Computers, auf dem das Programm läuft, sichtbar sind, können Programme, die innerhalb eines Containers laufen, so gestaltet werden, dass die Sichtbarkeit auf den Inhalt des Containers und bestimmte dem Container zugewiesene Geräte beschränkt ist. Solche Container können in einigen Implementierungen zusätzliche Isolationsmechanismen enthalten, die Ressourcenverwaltungsfunktionen bereitstellen, um die Auswirkungen der Aktivitäten eines Containers auf andere Container zu begrenzen.
  • Containerisierte Infrastruktur ist heute einer der am schnellsten wachsenden Märkte im IT-Bereich. Kubernetes ist zum De-facto-Standard für die Verwaltung von Container-Clustern und die Orchestrierung der Arbeitslast geworden, und doch sind ihr Netzwerktopologie und -nutzung völlig unbekannt. Das heißt, im Gegensatz zu CPU/Speicher und Storage fehlt das Netzwerk - die dritte Säule der IT-Infrastruktur von DevOps - völlig bei der Planung und Platzierung von Workloads. Es ist daher möglich, ja wahrscheinlich, dass Anwendungskapseln nach dem Zufallsprinzip auf über den gesamten Cluster verteilte Knoten (z.B. Server) verteilt werden, möglicherweise mit höherer als notwendiger oder gewünschter Netzwerk-Latenzzeit zwischen mehreren Containern, die einen bestimmten Mikrodienst oder eine Anwendung implementieren. Dies kann z.B. die Gesamteffizienz von Netzwerken und Rechenzentren senken und die Industrie zu überdimensionierten Netzwerkdesigns treiben. Bestehende Ansätze zur Knotennähe sind mit Affinitätsbeschränkungen verfügbar. Diese beschränken jedoch die Zeitplanung auf genau denselben Knoten und nicht auf einen Knoten, der direkt mit denselben Netzwerk-Switch(s) wie vorhandene Anwendungs-Pods verbunden ist. Weitere Ansätze verwenden manuelle Knoten- und Pod-Beschriftungen, um den Standort für die Proximity-Planung zu identifizieren. Keiner dieser Ansätze ist automatisiert oder automatisierbar, und sie können auch keine Kriterien für die Netzwerkauslastung enthalten.
  • Die Platzierung der Arbeitslast ist ein kritisches Problem bei der Verwaltung der Rechenzentrumseffizienz. Bestimmte Implementierungen der vorliegenden Offenlegung sind auf eine standortbasierte Virtualisierungs-Workload-Platzierung ausgerichtet. In einigen Implementierungen kann eine Methode zum Beispiel Folgendes umfassen: (a) Empfangen, mit einem Computer-Virtualisierungs-Scheduler, von Netzwerk-Lokalitätsinformationen für Virtualisierungsausrüstung; (b) Empfangen, mit dem Computer-Virtualisierungs-Scheduler, von Netzwerkauslastungsinformationen für Virtualisierungsausrüstung; und (c) Bestimmen, mit dem Computer-Virtualisierungs-Scheduler und basierend auf den empfangenen Netzwerk-Lokalitätsinformationen und den empfangenen Netzwerkauslastungsinformationen, der Virtualisierungs-Workload-Platzierung, um die verfügbare Netzwerkbandbreite zu maximieren und die Netzwerklatenz zwischen Virtualisierungsausrüstung zu minimieren. Bestimmte Implementierungen der vorliegenden Offenlegung sind darauf ausgerichtet, Netzwerkbewusstsein und Automatisierung in die Container-Pod-Planung von Kubernetes einzuführen und Implementierungen für OpenShift und natives Kubernetes zu detaillieren. Ein solcher Ansatz kann in einigen Situationen zu einer verbesserten Ressourceneffizienz von OpenShift mit Kubernetes-Scheduler-Erweiterungen für die Netzwerklokalisierung auf Rechenknoten und zusammensetzbaren Strukturen führen.
  • Wie hier verwendet, können sich „zusammensetzbare Struktur“ und verwandte Begriffe beispielsweise auf eine softwaredefinierte Netzwerkstruktur beziehen, die speziell für eine arbeitslastabhängige Leistung und Skalierung entwickelt wurde. Eine solche Struktur kann zum Beispiel Probleme auf der Datenebene, der Steuerungsebene und der Integrationsebene behandeln. Auf der Datenebene können Rack-Konnektivitätsmodule z. B. eine zusammensetzbare Netzwerk-Fabric oder Datenebene ABB.en, die physische Konnektivität, Topologie und Daten-/Paketweiterleitung bietet. In einer solchen Fabric können z. B. Konnektivität und Routing in einem einzigen Baustein zusammengefasst werden, ohne dass dedizierte Spine-Switches verwendet werden müssen. In einer solchen Fabric kann die Steuer- und Verwaltungsebene beispielsweise die in der Datenebene verwendeten eingebetteten Protokolle ergänzen und einen einzigen Verwaltungspunkt für das Netzwerk bereitstellen, während sie gleichzeitig APIs zur direkten Manipulation des Netzwerkzustands und von Objekten aus externen Systemen bereitstellt.
  • Bestimmte Implementierungen der vorliegenden Offenlegung sehen vor, dass ein Anwendungs- oder Arbeitsbelastungs-Orchestrierungssystem in der Lage ist, das Netzwerk nach Eingaben zur Arbeitsbelastungsplatzierung abzufragen.
  • Bestimmte Implementierungen der vorliegenden Offenlegung können die Netzwerknähe bei der Planung containerisierter Anwendungen nutzen, um Latenzzeiten zu reduzieren und die Gesamteffizienz des Netzwerks zu erhöhen. Bestimmte Implementierungen der vorliegenden Offenlegung ermöglichen es dem Orchestrierungssystem, das Netzwerk abzufragen und eine Reihe von Ressourcen zu erhalten, die bestimmte leistungsbezogene Anforderungen erfüllen. Anhand dieser Informationen kann das Orchestrierungssystem beispielsweise die Workload-Platzierung so abstimmen, dass die Anforderungen an Ressourcenverfügbarkeit und Leistung erfüllt werden. Weitere Vorteile der hier vorgestellten Implementierungen werden nach Durchsicht der Beschreibung und der Zahlen deutlich.
  • illustriert ein Flussdiagramm für eine Beispielmethode 100 in Bezug auf die standortbasierte Platzierung von Virtualisierungs-Workloads. In einigen Implementierungen kann die Methode 100 durch die Verwendung von ausführbaren Befehlen, die auf einer Speicherressource (z.B. der Speicherressource des Rechengeräts von ) gespeichert sind, ausführbaren maschinenlesbaren Befehlen, die auf einem Speichermedium (z.B. dem Medium von ) in Form einer elektronischen Schaltung (z.B. auf einer anwendungsspezifischen integrierten Schaltung (ASIC)) und/oder einer anderen geeigneten Form gespeichert sind, implementiert oder anderweitig ausgeführt werden. Obwohl sich die Beschreibung der Methode 100 hierin in erster Linie auf Schritte bezieht, die zur Veranschaulichung auf einem Server ausgeführt werden, wird es geschätzt, dass in einigen Implementierungen die Methode 100 auf einem anderen Computergerät innerhalb einer vernetzten Umgebung oder bei der Datenkommunikation innerhalb einer vernetzten Umgebung ausgeführt werden kann. In einigen Implementierungen kann die Methode 100 auf Netzwerkgeräten parallel ausgeführt werden (z.B. in einer verteilten Rechnerumgebung).
  • Methode 100 umfasst das Empfangen (bei Block 102) mit einem Computer-Virtualisierungs-Scheduler von Netzwerk-Lokalitätsinformationen für Virtualisierungsausrüstung. Der Computer-Virtualisierungs-Scheduler kann z.B. ein containerisierter Anwendungs-Scheduler oder ein Container-Anwendungs-Pod-Scheduler sein, wie hier näher beschrieben wird. Der hier verwendete Begriff „Virtualisierungsausrüstung“ und verwandte Begriffe können sich beispielsweise auf jede für die Virtualisierung geeignete Ausrüstung beziehen, wie z.B. bestimmte Server, Netzwerk-Switches, Speichergeräte usw.
  • Der Begriff „Informationen zum Netzwerkstandort“ und verwandte Begriffe, die hier verwendet werden, können sich zum Beispiel auf Informationen zur physischen Topologie von Virtualisierungsgeräten innerhalb eines einzelnen Racks und/oder mehrerer Racks eines Rechenzentrums beziehen. Weitere Beispiele für solche Informationen zum Netzwerkstandort werden hier gegeben. In einigen Implementierungen werden die Informationen zum Netzwerkstandort von einem Netzwerkadministrator über Etiketten eingegeben. In einigen Implementierungen werden die Informationen zum Netzwerkstandort automatisch auf der Grundlage der konfigurierten Netzwerktopologieinformationen eingegeben.
  • Methode 100 umfasst den Empfang (bei Block 104) mit dem Computer-Virtualisierungs-Scheduler von Netzwerkauslastungsinformationen für Virtualisierungsausrüstung. Der hier verwendete Begriff „Netzwerkauslastungsinformationen“ und verwandte Begriffe können sich beispielsweise auf Latenzstufen, Bandbreitenstufen und/oder Switch-Konnektivitätsinformationen beziehen. Weitere Beispiele für solche Netzwerkauslastungsinformationen werden hier in Bezug auf spezifische Beispielimplementierungen der vorliegenden Offenlegung gegeben.
  • Verfahren 100 umfasst die Bestimmung (bei Block 106), mit dem Computer-Virtualisierungs-Scheduler und auf der Grundlage der empfangenen Netzwerk-Ortsinformationen und der empfangenen Netzwerkauslastungsinformationen, die Platzierung der Virtualisierungsarbeitslast, um die verfügbare Netzwerkbandbreite zu maximieren und die Netzwerklatenz zwischen den Virtualisierungsgeräten zu minimieren. Der Begriff „Workload-Platzierung“ und verwandte Begriffe, die hier verwendet werden, können sich beispielsweise auf die Auswahl einer Vielzahl von Servern zur Ausführung einer virtualisierten Ressource beziehen, wie z.B. eines containerisierten Mikrodienstes oder einer Anwendung.
  • Die Platzierung der Arbeitsbelastung von Block 106 kann zum Beispiel durch eine Reihe von geeigneten Faktoren bestimmt werden, die über die oben ausdrücklich genannten hinausgehen. Bei einigen Implementierungen kann sie zum Beispiel auf Faktoren wie CPU-, Speicher- und Speicherauslastung basieren. In einigen Implementierungen wird die Workload-Platzierung so festgelegt, dass eine Anzahl von Netzwerk-Switch-Transits (oder „Hops“) zwischen den Knoten der Virtualisierungsausrüstung minimiert wird.
  • Die Platzierung der Arbeitsbelastung von Block 106 kann z.B. durch Priorisierung und/oder Rangfolge bestimmter Knoten auf der Grundlage bestimmter oben beschriebener Faktoren oder anderer geeigneter Faktoren bestimmt werden. In einigen Implementierungen ermöglicht die Platzierung der Arbeitslast beispielsweise die Einstufung der Gruppe potenzieller Containerisierungsknoten in eine Rangfolge, um sie im Hinblick auf niedrige Latenz, hohe Bandbreite und/oder direkte Switch-Konnektivität zu optimieren. In einigen Implementierungen umfasst die Bestimmung der Virtualisierungs-Workload-Platzierung die Priorisierung von Knoten auf der Grundlage der Netzwerkumgebung. In einigen Implementierungen wird die Workload-Platzierung durch Priorisierung der Virtualisierungsausrüstung bestimmt, was zu einer Reduzierung der Anzahl der Hops für eine containerisierte Anwendung führt. In einigen Implementierungen wird die Workload-Platzierung durch die Priorisierung von Verbindungen mit hoher Bandbreite zwischen Knoten in einem Rechenzentrum bestimmt. In einigen Implementierungen wird die Workload-Platzierung durch die Einstufung verfügbarer Knoten in einem Rechenzentrum bestimmt, die zum Teil auf Standort und Bandbreite basiert. In einigen Implementierungen wird die Workload-Platzierung durch die Einstufung einer Reihe potenzieller Containerisierungsknoten anhand der Netzwerkauslastung der Knoten bestimmt. In einigen Implementierungen ermöglicht die Workload-Platzierung die Einstufung der potentiellen Containerisierungsknoten in eine Rangfolge, während gleichzeitig eine anwendungsspezifische Anpassung des in eine Rangfolge gebrachten Satzes potentieller Containerisierungsknoten möglich ist.
  • In einigen Implementierungen können verschiedene vorbestimmte Konfigurationen zur Bestimmung der Arbeitsplatzposition bereitgestellt werden. Im Folgenden sind einige Beispielkonfigurationen aufgeführt:
    • Vorgabe (siehe 2)
      • • Filter - Keine Anpassung
      • • Priorisieren - Hinzufügen von Netzwerk-/Fabriknutzung zu bestehenden CPU/Mem/Disk-Kriterien
    • Lokal (siehe 3)
      • • Filter - Knoten, die weiter als einen Switch-Hop von bestehenden Projekt-/Anwendungsknoten entfernt sind
      • • Priorisieren - Netzwerkauslastungskriterien hinzufügen; nach Fabric-Auslastung sortieren
    • Nebenstehend (siehe 4)
      • • Filter - Knoten, die weiter als ein Rack von bestehenden Projekt-/Anwendungsknoten entfernt sind, entfernen
      • • Priorisieren - Netzwerkauslastungskriterien hinzufügen; nach Fabric-Auslastung sortieren
    • Direkt (siehe 5)
      • • Filter - Knoten entfernen, die sich nicht in einem oder mehreren Rack(s) befinden, die bereits vom Projekt/von der Anwendung verwendet werden
      • • Priorisieren - Hinzufügen der Netzwerkauslastung zu bestehenden CPU/Mem/Disk-Kriterien
  • Es wird geschätzt, dass eine oder mehrere Operationen der Methode 100 periodisch durchgeführt werden können. Beispielsweise können in einigen Implementierungen einer oder mehrere der Blöcke 102, 104 und 106 (oder andere hier beschriebene Operationen) periodisch ausgeführt werden. Die verschiedenen Periodenzeiten für die Blöcke 102, 104 und 106 (oder andere hier beschriebene Operationen) können die gleichen oder unterschiedliche Zeiten sein. In einigen Implementierungen beträgt z.B. die Periode von Block 102 alle 1 Minute und die Periode von Block 104 alle 2 Minuten. Es wird ferner geschätzt, dass die Periode für einen bestimmten Block regelmäßig (z.B. alle 1 Minute) oder unregelmäßig sein kann (z.B. alle 2 Minuten während einer ersten Bedingung und alle 3 Minuten während einer zweiten Netzbedingung). In einigen Implementierungen können einer oder mehrere der Blöcke 102, 104 und 106 (oder andere hier beschriebene Vorgänge) nicht periodisch sein und durch irgendein Netzwerk- oder anderes Ereignis ausgelöst werden.
  • Obwohl das Flussdiagramm von eine bestimmte Reihenfolge der Ausführung zeigt, ist es zu begrüßen, dass diese Reihenfolge in eine andere geeignete Reihenfolge umgewandelt werden kann, gleichzeitig oder teilweise gleichzeitig oder in einer Kombination davon ausgeführt werden kann. Ebenso können geeignete zusätzliche und/oder vergleichbare Schritte zu Methode 100 oder anderen hier beschriebenen Methoden hinzugefügt werden, um die gleiche oder vergleichbare Funktionalität zu erreichen. Bei einigen Implementierungen werden ein oder mehrere Schritte weggelassen. Beispielsweise kann in einigen Implementierungen der Block 104 des Empfangs von Netzwerkauslastungsinformationen in Methode 100 weggelassen oder von einem anderen Gerät ausgeführt werden. Es wird geschätzt, dass Blöcke, die zusätzlicher oder alternativer Funktionalität anderer hier beschriebener Implementierungen entsprechen, in Methode 100 aufgenommen werden können. Beispielsweise können Blöcke, die der Funktionalität verschiedener Aspekte von Implementierungen entsprechen, die hier anderweitig beschrieben sind, in Methode 100 aufgenommen werden, selbst wenn diese Funktionalität hier nicht ausdrücklich als Block in Methode 100 gekennzeichnet ist.
  • Verschiedene Beispielimplementierungen für die vorliegende Offenlegung werden nun beschrieben. Es wird geschätzt, dass diese Beispiele bestimmte Aspekte anderer hier beschriebener Implementierungen enthalten oder sich auf diese beziehen können (und umgekehrt), aber sie sind nicht als Beschränkung auf andere hier beschriebene Implementierungen gedacht. Darüber hinaus ist es zu begrüßen, dass bestimmte Aspekte dieser Implementierungen auf andere hier beschriebene Implementierungen angewendet werden können.
  • Bei einigen Implementierungen der vorliegenden Offenlegung werden Daten über die Netzwerktopologie des Rechenzentrums und Ortsdaten über bestehende Mechanismen (Labels und/oder Anmerkungen) zur Infrastruktur des Kubernetes hinzugefügt. Eine netzwerktopologiebewusste Pod-Scheduling-Engine ist mit dem bestehenden Kubernetes-Scheduler-Erweiterungsrahmen verbunden, um Scheduling-Module zum Filtern und Priorisieren von Knoten für die Pod-Scheduling-Planung unter Verwendung von Netzwerkdaten hinzuzufügen. Diese Erweiterungen können z.B. die Cluster-Scheduling-Fähigkeiten von Kubernetes so erweitern, dass sie die Netzwerknähe und Einschränkungen des Rechenzentrums berücksichtigen. Einschränkungen bei der netzwerknahen Planung können z.B. für niedrige Latenz, hohe Bandbreite oder direkte Switch-Konnektivität optimiert werden und die Identifizierung vorhandener laufender Pods für den jeweiligen Mikrodienst oder die jeweilige Anwendung einschließen.
  • Es wird geschätzt, dass die Netzwerktopologie eines Rechenzentrums beispielsweise in mehreren Phasen aufgebaut werden kann. Die erste Phase wird auf den Serverknoten implementiert und besteht darin, die physische Netzwerkkonfiguration jedes Servers zu erfassen und den Kubernetes Application Programming Interface („API“)-Eintrag für diesen Serverknoten mit der physischen Netzwerkkonfiguration zu annotieren, insbesondere die Media Access Control („MAC“)-Adresse jedes physischen Netzwerkschnittstellen-Controllers („NIC“). Die zweite Phase wird auf dem Netzwerk-Controller des Rechenzentrums unter Verwendung von Verbindungsdaten (Peering) von den Rechenzentrums-Switches implementiert, die alle internen Verbindungen zwischen den Rechenzentrums-Switches angeben. Diese Daten können verwendet werden, um eine Konnektivitätsabbildung zwischen den Datencenter-Switches einschließlich der potenziell verfügbaren Bandbreite zwischen den Peer-Switches zu erstellen. Die Netzwerkadapter des Serverknotens können dann der Netzwerktopologie des Rechenzentrums mithilfe von Netzwerk-Nachbarschaftsanzeigen (Link Layer Discovery Protocol („LLDP“-Pakete)) oder der direkten MAC-Adressensuche von den Rechenzentrums-Switches aus zugeordnet werden. Auf diese Weise wird eine vollständige Abbildung der Netzwerktopologie einschließlich der Rechenzentrumsswitches und Serverknoten erstellt, einschließlich aller verfügbaren Verbindungspfade und einschließlich der verfügbaren Bandbreite auf jedem Verbindungspfad.
  • Gemäß bestimmten Implementierungen der vorliegenden Offenlegung kann Kubernetes Pod-Planung mit netzwerkbewussten Filter- und Priorisierungsmethoden durch bestehende Scheduler-Erweiterungsmechanismen verbessert werden. Die Filtermethode kann z.B. Kandidatenknoten eliminieren, die nicht mit der gewünschten Netzwerklokalität übereinstimmen. Eine Priorisierungsmethode, die von bestimmten Implementierungen der vorliegenden Offenlegung verwendet wird, kann z.B. die verbleibenden Knoten (nach der Filterung) in der Reihenfolge der verfügbaren Fabric-Bandbreite zu/von jedem verbleibenden Knoten ordnen.
  • Bei bestimmten Implementierungen kann eine Reihe von Einstellungen für den Netzstandort angefordert werden, einschließlich direkt ( ), benachbart ( ), lokal ( ), Standard ( ) oder deaktiviert. Jede Einstellung kann clusterweit oder anwendungsspezifisch sein. Eine solche „direkte“ lokale Einstellung kann z. B. anfordern, dass die Container-Pods einer bestimmten Anwendung/eines bestimmten Projekts/eines bestimmten Namensraums (im Folgenden nur „Anwendung“) auf Knoten geplant werden, die alle mit demselben oder denselben Rechenzentrums-Switch bzw. denselben Rechenzentrums-Switches verbunden sind. Eine solche „benachbarte“ Standort-Einstellung kann z.B. anfordern, dass Anwendungs-Container-Pods auf Knoten geplant werden, die mit Switches verbunden sind, die einen einzigen Hop entfernt sind (keine dazwischenliegenden Switches), und zwar mit der größten verfügbaren Bandbreite zwischen diesen Switches. Eine solche „lokale“ Ortseinstellung kann z.B. anfordern, dass Anwendungscontainer-Pods auf Knoten geplant werden, die mit Switches verbunden sind, die einen einzelnen Hop entfernt sind (keine dazwischenliegenden Switches), und zwar unabhängig von der verfügbaren Bandbreite zwischen diesen Switches. Eine solche „Standard“-Ortseinstellung kann z.B. die Platzierung auf jedem beliebigen Knoten im Cluster ermöglichen. Eine solche „deaktivierte“ Ortseinstellung kann z.B. Netzwerküberlegungen aus dem Planungsprozess von Kubernetes vollständig entfernen. In allen oben genannten Fällen (mit Ausnahme der Deaktivierung in einigen Implementierungen) können verfügbare Kandidatenknoten z.B. nach der verfügbaren Bandbreite priorisiert werden.
  • Einige der vorgeschlagenen Implementierungen können Kubernetes z.B. einen clusterweiten Standard-Scheduling-Algorithmus sowie benutzerdefinierbare Overrides pro Anwendung oder für bestimmte Container-Pods innerhalb einer Anwendung zur Verfügung stellen. Diese benutzerdefinierbaren Überschreibungen können einfach durch die Verwendung bestehender Kennzeichnungsmechanismen in der Kubernetes-API mit definierten Kennzeichnungsnamen und -werten erreicht werden.
  • Es wird geschätzt, dass sich bestimmte Implementierungen der vorliegenden Offenlegung auf eine einzige Ebene konzentrieren können - das Netzwerk des Datenzentrums und die Optimierung eines Ortes innerhalb dieser Struktur, einschließlich nicht-hierarchischer Netzwerktopologien. Bestimmte bestehende Lösungen beziehen sich auf das Konzept der Knotennähe für die Planung im Bereich der Nähe von Fehlerdomänen. Solche Lösungen versuchen zu verhindern, dass zu viele Anwendungscontainer-Pods innerhalb einer bestimmten Fehlerdomäne geplant werden. Die vorliegende Offenlegung ergänzt diese Arbeit, da sie sich auf Entitäten jenseits eines einzelnen Knotens, aber innerhalb der Fehlerdomäne einer einzelnen Struktur konzentriert. Beide Lösungen könnten in einer einzigen Umgebung koexistieren, wobei ein Satz von Scheduling-Erweiterungen die Pods relativ zu den definierten Grenzen weiter auseinander schiebt und die anderen Pods innerhalb der Grenzen näher zusam menrücken.
  • Bestimmte bestehende Lösungen befassen sich eher mit der Planung einzelner Behälter als mit der Sammlung von Anwendungsbehältern. Bei einer solchen Lösung ist es wahrscheinlich, dass ein erster Knoten zufällig ausgewählt wird. Wenn dieser Knoten als ungeeignet erachtet wird, wird ein „zweiter“ Knoten aus der Matrix ausgewählt. Bestimmte Implementierungen der vorliegenden Offenlegung beinhalten einen kooperativen Ansatz, bei dem Attribute der Netzwerklokalitäten (z.B. Latenz und/oder „Entfernung“ der Bandbreite) in einen größeren Knotenauswahlprozess einbezogen werden, der unter anderem CPU-Last, Speicherlast, Plattennutzung und Affinität/Anti-Affinität in einem ganzheitlichen Planungsprozess einschließt.
  • 6 ist ein Diagramm eines Computergerätes 108, das z.B. als ein containerisiertes Anwendungsplanungssystem in Übereinstimmung mit der vorliegenden Offenlegung dienen kann. Das Rechengerät 108 kann z.B. in Form eines Servers oder eines anderen geeigneten Rechengeräts innerhalb einer Netzwerkumgebung oder in Kommunikation mit einer Netzwerkumgebung oder deren Ausrüstung sein. Wie weiter unten näher beschrieben, enthält die Recheneinheit 108 eine Verarbeitungsressource 110 und eine Speicherressource 114, die die maschinenlesbaren Befehle 116 und 118 speichert. Zur Veranschaulichung wird in der Beschreibung von Rechengerät 108 auf verschiedene Aspekte bestimmter Diagramme, Methoden und anderer spezifischer Implementierungen verwiesen. Es wird jedoch geschätzt, dass die Recheneinheit 108 zusätzliche, alternative oder weniger Aspekte, Funktionen usw. als die an anderer Stelle hierin beschriebenen Implementierungen enthalten kann, und es ist nicht beabsichtigt, durch die damit verbundene Offenlegung eingeschränkt zu werden.
  • Die auf der Speicherressource 114 gespeicherte Anweisung 116 soll, wenn sie von der Verarbeitungsressource 110 ausgeführt wird, bewirken, dass die Verarbeitungsressource 110 einen Satz potenzieller Containerisierungsknoten innerhalb eines Rechenzentrums in eine Rangfolge bringt, die zum Teil auf der physischen Position jedes Knotens im Vergleich zu anderen Knoten innerhalb des Rechenzentrums basiert. Die Anweisung 116 kann einen oder mehrere Aspekte von Blöcken der Methode 100 oder einen anderen geeigneten Aspekt anderer hier beschriebener Implementierungen enthalten (und umgekehrt). In einigen Implementierungen soll beispielsweise die Anweisung 116 die Verarbeitungsressource dazu veranlassen, die Menge der potenziellen Containerisierungsknoten auf der Grundlage der Netzwerkauslastung der Knoten zu ordnen. Die auf der Speicherressource 114 gespeicherte Anweisung 118 soll, wenn sie von der Verarbeitungsressource 110 ausgeführt wird, die Verarbeitungsressource 110 veranlassen, Knoten auszuwählen, um eine containerisierte Anwendung auf der Grundlage der Rangfolge der Knoten auszuführen. Anweisung 116 kann einen oder mehrere Aspekte von Blöcken der Methode 100 oder einen anderen geeigneten Aspekt anderer hier beschriebener Implementierungen enthalten (und umgekehrt).
  • Die Verarbeitungsressource 110 des Rechengeräts 108 kann z.B. in Form einer Zentraleinheit (CPU), eines Mikroprozessors auf Halbleiterbasis, eines digitalen Signalprozessors (DSP), wie z.B. einer digitalen Bildverarbeitungseinheit, anderer Hardwaregeräte oder Verarbeitungselemente, die geeignet sind, in der Speicherressource 114 gespeicherte Befehle abzurufen und auszuführen, oder geeignete Kombinationen davon sein. Die Verarbeitungsressource 110 kann z.B. einzelne oder mehrere Kerne auf einem Chip, mehrere Kerne über mehrere Chips, mehrere Kerne über mehrere Geräte oder geeignete Kombinationen davon umfassen. Die Verarbeitungsressource 110 kann zum Abrufen, Decodieren und Ausführen von Befehlen wie hier beschrieben funktionieren. Alternativ oder zusätzlich zum Abrufen und Ausführen von Befehlen kann die Verarbeitungsressource 110 beispielsweise mindestens einen integrierten Schaltkreis (IC), eine andere Steuerlogik, andere elektronische Schaltkreise oder eine geeignete Kombination davon umfassen, die eine Reihe von elektronischen Komponenten zur Ausführung der Funktionalität von Befehlen enthalten, die auf der Speicherressource 114 gespeichert sind. Der Begriff „Logik“ kann in einigen Implementierungen eine alternative oder zusätzliche Verarbeitungsressource zur Ausführung einer bestimmten hier beschriebenen Aktion und/oder Funktion usw. sein, die Hardware, z.B. verschiedene Formen von Transistorlogik, anwendungsspezifische integrierte Schaltungen (ASICs) usw., im Gegensatz zu maschinenausführbaren Befehlen, z.B. Software-Firmware usw., die im Speicher gespeichert und von einem Prozessor ausführbar sind, umfaßt. Die Verarbeitungsressource 110 kann z.B. über mehrere Verarbeitungseinheiten hinweg implementiert werden, und Befehle können von verschiedenen Verarbeitungseinheiten in verschiedenen Bereichen des Rechengeräts 108 implementiert werden.
  • Die Speicherressource 114 des Datenverarbeitungsgeräts 108 kann z.B. die Form eines nicht vorübergehenden maschinenlesbaren Speichermediums haben, wie z.B. ein geeignetes elektronisches, magnetisches, optisches oder anderes physikalisches Speichergerät zur Aufnahme oder Speicherung von Informationen wie die maschinenlesbaren Befehle 116 und 118. Solche Anweisungen können wirksam sein, um eine oder mehrere hierin beschriebene Funktionen auszuführen, wie z.B. die hierin in Bezug auf Methode 100 oder andere hierin beschriebene Methoden beschriebenen. Die Speicherressource 114 kann z.B. innerhalb desselben Gehäuses untergebracht werden wie die Verarbeitungsressource 110 für das Rechengerät 108, wie z.B. in einem Gehäuse für das Rechengerät 108 (in Implementierungen, bei denen das Rechengerät 108 in einem Gehäuse für den Rechnerturm untergebracht ist). In einigen Implementierungen sind die Speicherressource 114 und die Verarbeitungsressource 110 in unterschiedlichen Gehäusen untergebracht. Der hier verwendete Begriff „maschinenlesbares Speichermedium“ kann z.B. Random Access Memory (RAM), Flash-Speicher, ein Speicherlaufwerk (z.B. eine Festplatte), jede Art von Speicherplatte (z.B. ein Compact Disc Read Only Memory (CD-ROM), jede andere Art von Compact Disc, eine DVD usw.) und ähnliches oder eine Kombination davon umfassen. In einigen Implementierungen kann die Speicherressource 114 einem Speicher entsprechen, der einen Hauptspeicher, wie z.B. einen Arbeitsspeicher mit wahlfreiem Zugriff (Random Access Memory, RAM), in dem sich die Software während der Laufzeit befinden kann, und einen Sekundärspeicher umfasst. Der Sekundärspeicher kann beispielsweise einen nichtflüchtigen Speicher umfassen, in dem eine Kopie von maschinenlesbaren Befehlen gespeichert ist. Es wird geschätzt, dass sowohl maschinenlesbare Befehle als auch verwandte Daten auf Speichermedien gespeichert werden können und dass mehrere Medien für Beschreibungszwecke als ein einziges Medium behandelt werden können.
  • Die Speicherressource 114 kann über eine Kommunikationsverbindung 112 mit der Verarbeitungsressource 110 in Verbindung stehen. Jede Kommunikationsverbindung 112 kann lokal oder entfernt zu einer Maschine (z.B. einem Rechengerät) sein, die mit der Verarbeitungsressource 110 verbunden ist. Beispiele für eine lokale Kommunikationsverbindung 112 können einen elektronischen Bus innerhalb einer Maschine (z.B. eines Rechengeräts) umfassen, wobei die Speicherressource 114 ein flüchtiges, nichtflüchtiges, festes und/oder entfernbares Speichermedium ist, das über den elektronischen Bus mit der Verarbeitungsressource 110 kommuniziert.
  • In einigen Implementierungen können ein oder mehrere Aspekte des Datenverarbeitungsgeräts 108 in Form von Funktionsmodulen vorliegen, die z.B. operativ sein können, um einen oder mehrere Prozesse der Anweisungen 116 oder 118 oder andere hier beschriebene Funktionen in Bezug auf andere Implementierungen der Offenlegung auszuführen. Wie hierin verwendet, bezieht sich der Begriff „Modul“ auf eine Kombination aus Hardware (z.B. ein Prozessor, wie eine integrierte Schaltung oder ein anderer Schaltkreis) und Software (z.B. maschinen- oder prozessorausführbare Anweisungen, Befehle oder Code, wie Firmware, Programmierung oder Objektcode). Eine Kombination von Hardware und Software kann nur Hardware (d.h. ein Hardware-Element ohne Software-Elemente), Software, die auf Hardware gehostet wird (z.B. Software, die in einem Speicher gespeichert und auf einem Prozessor ausgeführt oder interpretiert wird), oder Hardware und Software, die auf Hardware gehostet wird, umfassen. Es wird ferner geschätzt, dass der Begriff „Modul“ sich zusätzlich auf ein oder mehrere Module oder eine Kombination von Modulen beziehen soll. Jedes Modul der Recheneinheit 108 kann zum Beispiel ein oder mehrere maschinenlesbare Speichermedien und einen oder mehrere Computerprozessoren umfassen.
  • In Anbetracht des oben Gesagten ist es zu begrüßen, dass die verschiedenen oben beschriebenen Anweisungen der Rechenanlage 108 getrennten und/oder kombinierten Funktionsmodulen entsprechen können. Zum Beispiel kann die Anweisung 116 einem „Ranglistenmodul“ entsprechen, um einen Satz potenzieller Containerisierungsknoten innerhalb eines Datenzentrums in eine Rangfolge zu bringen, die zum Teil auf der physikalischen Lage jedes Knotens im Vergleich zu anderen Knoten innerhalb des Datenzentrums basiert. Ebenso kann die Anweisung 118 einem „Knotenauswahlmodul“ entsprechen, um Knoten zur Ausführung einer containerisierten Anwendung auf der Grundlage der Rangfolge der Knoten auszuwählen. Es wird ferner geschätzt, dass ein bestimmtes Modul für mehrere Funktionen verwendet werden kann. Wie nur ein Beispiel: In einigen Implementierungen kann ein einzelnes Modul sowohl für die Rangfolge potentieller Containerisierungsknoten (z.B. entsprechend der Funktionalität der Anweisung 116) als auch für die Auswahl von Knoten (z.B. entsprechend der Funktionalität der Anweisung 118) verwendet werden.
  • Eine oder mehrere Implementierungen der vorliegenden Offenlegung können darüber hinaus ein geeignetes Kommunikationsmodul enthalten, um eine vernetzte Kommunikation zwischen Netzwerkgeräten zu ermöglichen. Ein solches Kommunikationsmodul kann z.B. einen NetzwerkSchnittstellen-Controller mit einem Ethernet-Anschluss und/oder einem Fibre-Channel-Anschluss umfassen. In einigen Implementierungen kann ein solches Kommunikationsmodul eine drahtgebundene oder drahtlose Kommunikationsschnittstelle enthalten und in einigen Implementierungen virtuelle Netzwerkanschlüsse bereitstellen. In einigen Implementierungen umfasst ein solches Kommunikationsmodul Hardware in Form einer Festplatte, zugehörige Firmware und andere Software, die es der Festplatte ermöglicht, operativ mit anderen Netzwerkgeräten zu kommunizieren. Das Kommunikationsmodul kann z.B. maschinenlesbare Anweisungen zur Verwendung mit der Kommunikation des Kommunikationsmoduls enthalten, wie z.B. Firmware zur Implementierung physischer oder virtueller Netzwerkanschlüsse.
  • zeigt ein maschinenlesbares Speichermedium 120 mit verschiedenen Anweisungen, die von einem Computerprozessor oder einer anderen Verarbeitungsressource ausgeführt werden können. In einigen Implementierungen kann das Medium 120 in einem Server, auf einem anderen Computergerät innerhalb einer Netzwerkumgebung oder in einer lokalen oder entfernten drahtgebundenen oder drahtlosen Datenkommunikation innerhalb einer Netzwerkumgebung untergebracht sein. Zur Veranschaulichung bezieht sich die hier vorliegende Beschreibung des maschinenlesbaren Speichermediums 120 auf verschiedene Aspekte des Computergeräts 108 (z.B. Verarbeitungsressource 110) und andere Implementierungen der Offenlegung (z.B. Methode 100). Obwohl ein oder mehrere Aspekte des Datenverarbeitungsgeräts 108 (sowie Anweisungen wie die Anweisungen 116 und 118) auf das Medium 120 angewendet oder anderweitig in das Medium 120 integriert werden können, wird es geschätzt, dass in einigen Implementierungen das Medium 120 getrennt von einem solchen System gespeichert oder untergebracht werden kann. Zum Beispiel kann in einigen Implementierungen das Medium 120 in Form von Random Access Memory (RAM), Flash-Speicher, einem Speicherlaufwerk (z.B. einer Festplatte), jeder Art von Speicherplatte (z.B. einer Compact Disc Read Only Memory (CD-ROM), jeder anderen Art von Compact Disc, einer DVD usw.) und ähnlichem oder einer Kombination davon vorliegen.
  • Medium 120 enthält maschinenlesbare Anweisungen 122, die darauf gespeichert sind, um die Verarbeitungsressource 110 dazu zu veranlassen, die Containerisierung der Anwendungsauslastung auf der Grundlage von Informationen über den Standort der Ausrüstung innerhalb eines gemeinsamen Rechenzentrums zu bestimmen. Anweisung 116 kann beispielsweise einen oder mehrere Aspekte von Block 106 der Methode 100 oder einen anderen geeigneten Aspekt anderer hier beschriebener Implementierungen enthalten (und umgekehrt). In einigen Implementierungen wird die Platzierung der Arbeitslast beispielsweise so festgelegt, dass eine Anzahl von Sprüngen zwischen den Knoten der Virtualisierungsausrüstung minimiert wird.
  • Medium 120 enthält maschinenlesbare Anweisungen 124, die darauf gespeichert sind, um die Verarbeitungsressource 110 zu veranlassen, der Virtualisierungsausrüstung innerhalb des Rechenzentrums auf der Grundlage der Informationen über den Standort der Ausrüstung eine Arbeitslast zuzuweisen, um die Gesamtnetzwerkauslastung zu verbessern. Die Anweisungen 118 können beispielsweise einen oder mehrere Aspekte von Block 106 der Methode 100 oder einen anderen geeigneten Aspekt anderer hier beschriebener Implementierungen (und umgekehrt) enthalten.
  • Während bestimmte Implementierungen oben gezeigt und beschrieben wurden, können verschiedene Änderungen in Form und Details vorgenommen werden. Beispielsweise können einige Merkmale, die in Bezug auf eine Implementierung und/oder einen Prozess beschrieben wurden, mit anderen Implementierungen in Beziehung stehen. Mit anderen Worten: Prozesse, Merkmale, Komponenten und/oder Eigenschaften, die in Bezug auf eine Implementierung beschrieben wurden, können in anderen Implementierungen nützlich sein. Darüber hinaus sollte man sich darüber im Klaren sein, dass die hier beschriebenen Systeme und Methoden verschiedene Kombinationen und/oder Unterkombinationen der Komponenten und/oder Eigenschaften der verschiedenen beschriebenen Implementierungen enthalten können. So können Merkmale, die in Bezug auf eine oder mehrere Implementierungen beschrieben werden, mit anderen hier beschriebenen Implementierungen kombiniert werden.
  • Wie hier verwendet, ist „Logik“ eine alternative oder zusätzliche Verarbeitungsressource zur Ausführung einer bestimmten hier beschriebenen Aktion und/oder Funktion usw., die Hardware, z.B. verschiedene Formen der Transistorlogik, anwendungsspezifische integrierte Schaltungen (ASICs) usw., im Gegensatz zu maschinenausführbaren Befehlen, z.B. Software-Firmware usw., die im Speicher gespeichert und von einem Prozessor ausführbar sind, umfasst. Ferner kann sich, wie hier verwendet, „a“ oder „eine Anzahl von“ etwas auf eine oder mehrere solcher Dinge beziehen. Zum Beispiel kann sich „eine Anzahl von Widgets“ auf ein oder mehrere Widgets beziehen. Auch „eine Mehrzahl von“ irgendetwas kann sich, wie hier verwendet, auf mehr als eines dieser Dinge beziehen.

Claims (20)

  1. Ein Verfahren, die Folgendes umfasst: mit einem Computer-Virtualisierungs-Scheduler Informationen über den Netzwerkstandort für Virtualisierungsausrüstung zu erhalten; mit dem Computer-Virtualisierungs-Scheduler Netzwerkauslastungsinformationen für Virtualisierungsausrüstung zu erhalten; und mit dem Computer-Virtualisierungs-Scheduler und auf der Grundlage der empfangenen Informationen zum Netzwerkstandort und der empfangenen Informationen zur Netzwerkauslastung die Platzierung der Virtualisierungsarbeitslast zu bestimmen, um die verfügbare Netzwerkbandbreite zu maximieren und die Netzwerklatenz zwischen den Virtualisierungsgeräten zu minimieren.
  2. Verfahren nach Anspruch 1, bei dem der Computer-Virtualisierungs-Scheduler ein containerisierter Anwendungs-Scheduler ist.
  3. Verfahren nach Anspruch 1, bei dem der Scheduler für die Computer-Virtualisierung ein Pod-Scheduler für Containeranwendungen ist.
  4. Verfahren nach Anspruch 1, bei dem die Virtualisierungsausrüstung Server zur Ausführung containerisierter Anwendungen umfasst.
  5. Verfahren nach Anspruch 1, wobei die Virtualisierungsausrüstung Netzwerk-Switches umfasst.
  6. Verfahren nach Anspruch 1, wobei die Bestimmung der Virtualisierungs-Workload-Platzierung weiterhin auf anderen Faktoren basiert, einschließlich Zentraleinheit (CPU), Speicher- und Speicherauslastung.
  7. Verfahren nach Anspruch 1, bei der die Informationen über den Netzwerkstandort Informationen über die physikalische Topologie der Virtualisierungsausrüstung innerhalb mehrerer Racks eines Datenzentrums umfassen.
  8. Verfahren nach Anspruch 1, bei der die Informationen über den Netzwerkstandort Informationen über die physische Topologie der Virtualisierungsausrüstung innerhalb eines einzelnen Racks eines Datenzentrums umfassen.
  9. Verfahren nach Anspruch 1, wobei die festgelegte Virtualisierungs-Workload-Platzierung die Auswahl einer Vielzahl von Servern zur Ausführung eines containerisierten Mikrodienstes oder einer Anwendung umfasst.
  10. Verfahren nach Anspruch 1, bei der die Ortsangaben des Netzwerks von einem Netzwerkadministrator über Etiketten eingegeben werden.
  11. Verfahren nach Anspruch 1, wobei die Bestimmung der Platzierung der Virtualisierungsarbeitslast die Priorisierung von Knoten auf der Grundlage der Netzwerklokalität einschließt.
  12. Ein nicht-flüchtigesmaschinenlesbares Speichermedium mit darauf gespeicherten maschinenlesbaren Befehlen, die einen Computerprozessor dazu veranlassen: Bestimmung der Platzierung des Anwendungs-Workloads in Containern auf der Grundlage von Informationen über den Standort der Ausrüstung in einem gemeinsamen Rechenzentrum; und den Virtualisierungsgeräten innerhalb des Rechenzentrums auf der Grundlage der Informationen über den Standort der Geräte eine Arbeitslast zuzuweisen, um die Gesamtauslastung des Netzwerks zu verbessern.
  13. Medium von Anspruch 12, bei dem die Platzierung der Arbeitslast so festgelegt wird, dass eine Anzahl von Sprüngen zwischen den Knoten der Virtualisierungsausrüstung minimiert wird.
  14. Medium des Anspruchs 12, bei dem die Platzierung der Arbeitslast durch die Priorisierung von Virtualisierungsausrüstung bestimmt wird, die zu einer Reduzierung der Anzahl von Hops für eine containerisierte Anwendung führt.
  15. Medium von Anspruch 12, bei dem die Platzierung der Arbeitslast durch Priorisierung von Verbindungen mit hoher Bandbreite zwischen Knoten in einem Datenzentrum bestimmt wird.
  16. Medium von Anspruch 12, bei dem die Platzierung der Arbeitslast durch eine Rangfolge der verfügbaren Knoten in einem Datenzentrum bestimmt wird, die zum Teil auf Standort und Bandbreite basiert.
  17. Ein containerisiertes Anwendungsplanungssystem, bestehend aus eine Verarbeitungsressource; und eine Speicherressource, die maschinenlesbare Anweisungen speichert, die die Verarbeitungsressource dazu veranlassen: eine Reihe potenzieller Containerisierungsknoten innerhalb eines Rechenzentrums in eine Rangfolge zu bringen, die zum Teil auf dem physischen Standort jedes Knotens im Vergleich zu anderen Knoten innerhalb des Rechenzentrums basiert; und Knoten auswählen, um eine containerisierte Anwendung basierend auf der Rangfolge der Knoten auszuführen.
  18. System aus Anspruch 17, wobei die Anweisungen bewirken sollen, dass die Verarbeitungsressource die Menge der potenziellen Containerisierungsknoten auf der Grundlage der Netzwerkauslastung der Knoten einordnet.
  19. System aus Anspruch 17, wobei die Anweisungen einen Standardansatz für die Rangfolge der potentiellen Containerisierungsknoten bereitstellen sollen, während gleichzeitig eine anwendungsspezifische Anpassung der Rangfolge der potentiellen Containerisierungsknoten ermöglicht wird.
  20. System aus Anspruch 17, bei dem die Anweisungen den Satz potenzieller Containerisierungsknoten in eine Rangfolge bringen sollen, um für niedrige Latenz, hohe Bandbreite und/oder direkte Switch-Konnektivität zu optimieren.
DE102020110143.0A 2019-04-26 2020-04-14 Standortbasierte virtualisierungs-workload-platzierung Pending DE102020110143A1 (de)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US16/396,591 2019-04-26
US16/396,591 US11650837B2 (en) 2019-04-26 2019-04-26 Location-based virtualization workload placement

Publications (1)

Publication Number Publication Date
DE102020110143A1 true DE102020110143A1 (de) 2020-10-29

Family

ID=72840153

Family Applications (1)

Application Number Title Priority Date Filing Date
DE102020110143.0A Pending DE102020110143A1 (de) 2019-04-26 2020-04-14 Standortbasierte virtualisierungs-workload-platzierung

Country Status (3)

Country Link
US (1) US11650837B2 (de)
CN (1) CN111857946B (de)
DE (1) DE102020110143A1 (de)

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11144362B1 (en) * 2020-05-05 2021-10-12 International Business Machines Corporation Container scheduling in a container orchestration system
CN112559186B (zh) * 2020-12-22 2021-09-24 北京云思畅想科技有限公司 一种Kubernetes容器资源扩缩容方法
US11375006B1 (en) * 2020-12-28 2022-06-28 Pensando Systems, Inc. Methods and systems for rating workloads based on network interface device resources and for optimal scheduling
US11736348B2 (en) 2021-06-28 2023-08-22 Dell Products L.P. System and method for network services based functionality provisioning in a VDI environment
US20220414577A1 (en) * 2021-06-28 2022-12-29 Dell Products L.P. System and method for performance-centric workload placement in a hybrid cloud environment
US11924107B2 (en) 2021-10-04 2024-03-05 Cisco Technology, Inc. Cloud-native workload optimization
US11782798B2 (en) * 2022-02-11 2023-10-10 Dell Products, L.P. Method and apparatus for predicting and exploiting aperiodic backup time windows on a storage system
US20240152396A1 (en) * 2022-11-04 2024-05-09 Oracle International Corporation Supercluster network of graphical processing units (gpus)

Family Cites Families (36)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN100364279C (zh) * 2005-12-07 2008-01-23 中国科学院计算技术研究所 结构化p2p系统的分布式负载均衡方法
CN101465875B (zh) * 2008-11-12 2011-12-07 湖南大学 一种基于网络定位的负载均衡方法
US9888067B1 (en) * 2014-11-10 2018-02-06 Turbonomic, Inc. Managing resources in container systems
US8683023B1 (en) * 2010-06-30 2014-03-25 Amazon Technologies, Inc. Managing communications involving external nodes of provided computer networks
US9582221B2 (en) * 2012-08-24 2017-02-28 Vmware, Inc. Virtualization-aware data locality in distributed data processing
US9130844B1 (en) * 2014-11-11 2015-09-08 Citigroup Technology, Inc. Systems and methods for harvesting excess compute capacity across domains
US10007584B2 (en) * 2015-01-28 2018-06-26 Red Hat, Inc. Automated container migration in a platform-as-a-service system
CN106034144B (zh) * 2015-03-12 2019-10-15 中国人民解放军国防科学技术大学 一种基于负载均衡的虚拟资产数据存储方法
US10579403B2 (en) 2015-06-29 2020-03-03 Vmware, Inc. Policy based provisioning of containers
US10613888B1 (en) * 2015-12-15 2020-04-07 Amazon Technologies, Inc. Custom placement policies for virtual machines
US9954758B2 (en) * 2016-02-17 2018-04-24 Dell Products L.P. Virtual network function resource allocation and management system
JP6680901B2 (ja) * 2016-04-08 2020-04-15 華為技術有限公司Ｈｕａｗｅｉ Ｔｅｃｈｎｏｌｏｇｉｅｓ Ｃｏ．，Ｌｔｄ． 管理方法および装置
US10757048B2 (en) * 2016-04-08 2020-08-25 Microsoft Technology Licensing, Llc Intelligent personal assistant as a contact
US11169706B2 (en) * 2016-05-26 2021-11-09 Nutanix, Inc. Rebalancing storage I/O workloads by storage controller selection and redirection
US10432532B2 (en) * 2016-07-12 2019-10-01 Cisco Technology, Inc. Dynamically pinning micro-service to uplink port
US10034407B2 (en) * 2016-07-22 2018-07-24 Intel Corporation Storage sled for a data center
US20180097845A1 (en) * 2016-10-05 2018-04-05 Rapid Focus Security, Llc Self-Managed Intelligent Network Devices that Protect and Monitor a Distributed Network
US20180136931A1 (en) 2016-11-14 2018-05-17 Ca, Inc. Affinity of microservice containers
US11044162B2 (en) 2016-12-06 2021-06-22 Cisco Technology, Inc. Orchestration of cloud and fog interactions
US11087087B1 (en) * 2017-02-15 2021-08-10 Robert Mayer Comparative expression processing
US10542104B2 (en) 2017-03-01 2020-01-21 Red Hat, Inc. Node proximity detection for high-availability applications
US10467052B2 (en) 2017-05-01 2019-11-05 Red Hat, Inc. Cluster topology aware container scheduling for efficient data transfer
US10705881B2 (en) * 2017-05-12 2020-07-07 Red Hat, Inc. Reducing overlay network overhead across container hosts
US10467046B2 (en) 2017-05-30 2019-11-05 Red Hat, Inc. Fast and greedy scheduling machine based on a distance matrix
US10728135B2 (en) * 2017-10-13 2020-07-28 Keysight Technologies, Inc. Location based test agent deployment in virtual processing environments
US10871998B2 (en) * 2018-01-18 2020-12-22 Red Hat, Inc. Usage instrumented workload scheduling
US10516601B2 (en) * 2018-01-19 2019-12-24 Citrix Systems, Inc. Method for prioritization of internet traffic by finding appropriate internet exit points
US10691986B2 (en) * 2018-02-23 2020-06-23 International Business Machines Corporation Cloning a computing environment
US10908940B1 (en) * 2018-02-26 2021-02-02 Amazon Technologies, Inc. Dynamically managed virtual server system
US10805215B2 (en) * 2018-03-20 2020-10-13 Cisco Technology, Inc. Intra-host and end-to-end packet path and treatment tracing using in-situ OAM in container networking architecture
US10585714B2 (en) * 2018-04-05 2020-03-10 International Business Machines Corporation Workload management with data access awareness using an ordered list of hosts in a computing cluster
US11169856B2 (en) * 2019-01-31 2021-11-09 Hewlett Packard Enterprise Development Lp Container management
US11030009B2 (en) * 2019-03-28 2021-06-08 Atlassian Pty Ltd. Systems and methods for automatically scaling compute resources based on demand
US11016819B2 (en) * 2019-08-16 2021-05-25 Cisco Technology, Inc. Optimizing clustered applications in a clustered infrastructure
US11513842B2 (en) * 2019-10-03 2022-11-29 International Business Machines Corporation Performance biased resource scheduling based on runtime performance
US11444855B2 (en) * 2020-07-07 2022-09-13 Juniper Networks, Inc. System and method for determining a data flow path in an overlay network

Also Published As

Publication number Publication date
US11650837B2 (en) 2023-05-16
US20200341794A1 (en) 2020-10-29
CN111857946A (zh) 2020-10-30
CN111857946B (zh) 2023-11-28

Similar Documents

Publication Publication Date Title
DE102020110143A1 (de) Standortbasierte virtualisierungs-workload-platzierung
DE102019133923B4 (de) Anwendungsverwendung in einem behältermanagementsystem
DE112013006063B4 (de) Funktionsübernahme für einen Datenübertragungskanal in einem Netzwerk mit Hochleistungsdatenverarbeitung
DE112016001075B4 (de) Verteiltes speichern und abrufen von datensätzen
DE112011101633B4 (de) Virtualisierung und dynamische Ressourcenzuweisung berücksichtigendes Neuordnen von Speicherebenen
DE60016283T2 (de) Arbeitsbelastungsverwaltung in einer rechnerumgebung
DE102022107621A1 (de) Resourcenauswahl, die zum teil auf der arbeitslast basiert
DE112013003180T5 (de) Verfahren, System und Gerät zum Verwalten von Server-Hardware-Resourcen in einer Cloud-Scheduling-Umgebung
DE102016104478A1 (de) Kryptographische Verfahren, die Arbeitsnachweise in Systemen untereinander verbundener Knoten realisieren
DE102010001985A1 (de) Vorrichtung zum Schalten des Betriebs einer virtuellen Maschine zwischen mehreren Computern, die der gleichen Computerplattform zugeordnet sind, und entsprechende Schaltverfahren
DE112011100094T5 (de) Verfahren und System zum Abstrahieren eines auf nichtfunktionalen Anforderungen beruhenden Einsatzes von virtuellen Maschinen
DE102020201834A1 (de) Technologien für netzvorrichtungslastausgleichseinrichtungen für beschleunigte funktionen-als-dienst
DE102009031126A1 (de) Aktivieren der funktionalen Abhängigkeit in einem Multifunktionsgerät
DE102022104207A1 (de) Pooling von Netzwerkverarbeitungsressourcen
DE112011105481T5 (de) Ermöglichen des Einsatzes einer anderen Rechenvorrichtung durch eine Rechenvorrichtung
DE112010004017T5 (de) Einzelstapel-ReaI-Time-Betriebssystem für eingebettete Systeme
DE112014002799B4 (de) Bereitstellen einer sicheren Kundendomäne in einer virtualisierten Mehr-Mieter-Umgebung
DE112013000395T5 (de) Richtliniendurchsetzung in Rechenumgebung
DE102019102883A1 (de) Technologien zum Bewegen von Arbeitslasten zwischen Hardwarewarteschlangenmanagern
DE112011101019T5 (de) Verarbeitung von Befehlen mit mehreren Prioritäten zwischen Back-End-Prozessoren
DE112017003294T5 (de) Technologien für ein skalierbares Senden und Empfangen von Paketen
DE102018204577A1 (de) Techniken zum Erfüllen von Dienstgüteanforderungen für eine Fabric-Punkt-zu-Punkt-Verbindung
DE102016105595A1 (de) Bedarfsleistungsmanagement in einer vernetzten Computerumgebung
DE112011105911T5 (de) Server mit Switch-Schaltungen
DE112016004367T5 (de) Technologien für automatische Prozessorkern-Zuordnungsverwaltung und -Kommunikation unterVerwendung direkter Datenplatzierung in private Zwischenspeicher

Legal Events

Date Code Title Description
R083 Amendment of/additions to inventor(s)
R082 Change of representative

Representative=s name: HL KEMPNER PATENTANWAELTE, SOLICITORS (ENGLAND, DE

Representative=s name: HL KEMPNER PATENTANWALT, RECHTSANWALT, SOLICIT, DE

R081 Change of applicant/patentee

Owner name: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, SPR, US

Free format text: FORMER OWNER: HEWLETT PACKARD ENTERPRISE DEVELOPMENT LP, HOUSTON, TEX., US

R012 Request for examination validly filed