DE112017001762T5 - Technologien für den einsatz dynamischer underlay-netzwerke in cloud-computing-infrastrukturen - Google Patents

Technologien für den einsatz dynamischer underlay-netzwerke in cloud-computing-infrastrukturen Download PDF

Info

Publication number
DE112017001762T5
DE112017001762T5 DE112017001762.9T DE112017001762T DE112017001762T5 DE 112017001762 T5 DE112017001762 T5 DE 112017001762T5 DE 112017001762 T DE112017001762 T DE 112017001762T DE 112017001762 T5 DE112017001762 T5 DE 112017001762T5
Authority
DE
Germany
Prior art keywords
network
underlay
network controller
cloud computing
identifying
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
DE112017001762.9T
Other languages
English (en)
Inventor
Mrittika Ganguli
S. Deepak
Ananth S. Narayan
Hubert Sokolowski
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 DE112017001762T5 publication Critical patent/DE112017001762T5/de
Pending legal-status Critical Current

Links

Images

Classifications

    • 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/0876—Network utilisation, e.g. volume of load or congestion level
    • 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
    • H04L12/00—Data switching networks
    • H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
    • H04L12/46—Interconnection of networks
    • H04L12/4641—Virtual LANs, VLANs, e.g. virtual private networks [VPN]
    • 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/5051—Service on demand, e.g. definition and deployment of services in real time
    • 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
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/10—Protocols in which an application is distributed across nodes in the network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • 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
    • 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/5077—Network service management, e.g. ensuring proper service fulfilment according to agreements wherein the managed service relates to simple transport services, i.e. providing only network infrastructure
    • 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

Abstract

Technologien für den Einsatz dynamischer Underlay-Netzwerke in einer Cloud-Computing-Infrastruktur beinhalten einen Netzwerk-Controller der Cloud-Computing-Infrastruktur, der über disaggregierte Switches kommunikativ mit einem oder mehreren Rechenknoten der Cloud-Computing-Infrastruktur verbunden ist. Der Netzwerk-Controller ist konfiguriert zum Empfangen von Tenant-Netzwerk-Erzeugungsanfragen von einem Cloud-Betriebssystem (OS - Operating System) der Cloud-Computing-Infrastruktur, die darauf hinweisen, dass ein Tenant-Netzwerk in der Cloud-Computing-Infrastruktur erzeugt werden soll (z.B. für einen neuen Tenant der Cloud-Computing-Infrastruktur). Der Netzwerk-Controller ist konfiguriert zum Bereitstellen eines Underlay-Netzwerks zum Unterstützen des Tenant-Netzwerks basierend auf identifizierten physischen Ressourcen unter Verwendung von Kriterien, die durch das Cloud-OS spezifiziert werden, und zum Übertragen von Informationen des bereitgestellten Underlay-Netzwerks an das Cloud-OS, die zum Erzeugen eines in der Cloud sichtbaren Overlay-Netzwerks, das mit dem Underlay-Netzwerk assoziiert ist, nutzbar sind. Andere Ausführungsformen sind hierin beschrieben.

Description

  • QUERVERWEIS ZU VERWANDTER US-PATENTANMELDUNG
  • Die vorliegende Anmeldung beansprucht Priorität gegenüber der US-Gebrauchsmusteranmeldung mit der Seriennr. 15/087,172, mit dem Titel „TECHNOLOGIES FOR DEPLOYING DYNAMIC UNDERLAY NETWORKS IN CLOUD COMPUTING INFRASTCTURES“, welche am 31. März 2016 eingereicht wurde.
  • ALLGEMEINER STAND DER TECHNIK
  • Traditionelle Rechenzentren sind rund um den Server als die grundlegende Recheneinheit aufgebaut. In derartigen traditionellen Rechenzentren beinhaltet jeder Server üblicherweise seine eigenen dedizierten Rechenressourcen (z.B. Prozessoren, Arbeitsspeicher, Datenspeicher und Netzwerkhardware/-software), und einzelne Server können zusammen mit hoher Dichte in Racks gestapelt sein, und multiple Racks können in einem Rechenzentrum angeordnet sein. Es wurden einige moderne Rechenzentrumstechnologien eingeführt, welche Rechenressourcen disaggregieren. Insbesondere hat die Rack-Scale-Architektur das Computing-Rack als die grundlegende Einheit der Datenverarbeitung für große Rechenzentren umgestaltet. Bei derartigen Rack-Scale-Architekturen beinhaltet jedes Computing-Rack üblicherweise multiple gepoolte Systeme (z.B. Sammlungen gepoolter Rechenknoten, gepoolten Arbeitsspeicher und gepoolten Datenspeicher über eine Rack-Scale-Struktur). Durch das Disaggregieren und Poolen von Rechenressourcen gestattet die Rack-Scale-Architektur eine verbesserte Flexibilität und Skalierbarkeit von Rechenzentren. Zum Beispiel können einzelne Rechenressourcen (z.B. Rechenknoten und/oder Arbeitsspeicher) dynamisch hinzugefügt/entfernt und/oder zwischen Auslastungen partitioniert werden. Außerdem kann die Rack-Scale-Architektur Wärmemanagement und Stromverbrauch des Rechenzentrums verbessern, indem derartige Ressourcen gemeinsam genutzt werden, was wiederum Rechendichte, Leistung und Effizienz verbessern kann.
  • Bei Cloud-Computing-Infrastrukturen ist das Management der Rechenressourcenpools entscheidend für die Handhabung sich dynamisch ändernder Geschäftsstrategie- und Netzwerkanforderungen. Bei einigen Cloud-Computing-Infrastrukturen werden Netzwerkvirtualisierungstechnologien implantiert, um unabhängige Netzwerke pro Tenant (Mandant) unter Verwendung von Overlay-Netzwerken zu ermöglichen (z.B. das Erstellen einzelner virtueller lokaler Netzwerke (VLANs - Virtual Local Area Networks) für jeden Tenant, um virtuellen Netzwerkverkehr isoliert zu halten). Während Overlay-Netzwerke ihre Vorteile haben, wird jedoch ein Mehraufwand von Daten, die Zwischenknoten traversieren, eingeführt (z.B. Datenpfadmehraufwand, Verarbeitungsverzögerungen usw.), welcher in einer Minderung der Anwendungsleistung resultieren kann. Außerdem konkurrieren Overlay-Netzwerke um gemeinsam genutzte Ressourcen (z.B. gemeinsam genutzter Arbeitsspeicher, Plattenspeicher, Cache-Speicher usw.), was in Ressourcenkonflikten durch konkurrierende Overlay-Netzwerke resultieren kann. Dementsprechend wurden, aufgrund ihres Potentials, einige der Probleme, die den Overlay-Netzwerken zugeschrieben werden können, zu überwinden, Underlay-Netzwerke eingeführt; jedoch sind Underlay-Netzwerke statisch konfiguriert und werden während der Cloud-Einrichtung/-Konfiguration erzeugt. Aufgrund dessen sind derartige Underlay-Netzwerke auch anfällig dafür, überbelegt oder unterbelegt zu werden, was in einer suboptimalen Ressourcennutzung resultiert.
  • Figurenliste
  • Die hierin beschriebenen Konzepte sind als Beispiele und nicht als Einschränkungen in den beigefügten Figuren veranschaulicht. Der Einfachheit und Klarheit der Veranschaulichung halber sind die in den Figuren veranschaulichten Elemente nicht notwendigerweise maßstabsgerecht gezeichnet. Wo es als angemessen erachtet wurde, wurden Referenzkennzeichnungen zwischen den Figuren wiederholt, um entsprechende oder analoge Elemente anzugeben.
    • 1 ist ein vereinfachtes Blockdiagramm mindestens einer Ausführungsform eines Systems für den Einsatz dynamischer Underlay-Netzwerke in einer Cloud-Computing-Infrastruktur unter Verwendung einer Rack-Scale-Rechenarchitektur;
    • 2 ist ein vereinfachtes Blockdiagramm mindestens einer Ausführungsform eines Underlay-Netzwerks in dem System von 1;
    • 3 ist ein vereinfachtes Blockdiagramm mindestens einer Ausführungsform einer Umgebung, die durch einen Netzwerk-Controller des Systems von 1 aufgebaut werden kann;
    • 4 ist ein vereinfachtes Flussdiagramm mindestens einer Ausführungsform eines Verfahrens zur Leistungsüberwachung der Cloud-Computing-Infrastruktur, das durch den Netzwerk-Controller von 3 ausgeführt werden kann;
    • 5 ist ein vereinfachtes Flussdiagramm mindestens einer Ausführungsform eines Verfahrens zur Erzeugung eines Underlay-Netzwerks in der Cloud-Computing-Infrastruktur, das durch den Netzwerk-Controller von 3 ausgeführt werden kann; und
    • 6 ist ein vereinfachtes Flussdiagramm mindestens einer Ausführungsform eines Verfahrens zur Konfiguration des in 5 erzeugten Underlay-Netzwerks, das durch den Netzwerk-Controller von 3 ausgeführt werden kann.
  • DETAILLIERTE BESCHREIBUNG DER ZEICHNUNGEN
  • Während die Konzepte der vorliegenden Offenbarung empfänglich für verschiedene Modifikationen und alternative Formen sind, wurden spezifische Ausführungsformen davon als Beispiele in den Zeichnungen gezeigt und werden hierin im Detail beschrieben. Es sollte jedoch verstanden werden, dass nicht beabsichtigt wird, die Konzepte der vorliegenden Offenbarung auf die bestimmten offenbarten Formen zu beschränken, sondern dass im Gegensatz dazu die Absicht darin besteht, alle Modifikationen, Äquivalente und Alternativen, die mit der vorliegenden Offenbarung und den angefügten Ansprüchen übereinstimmen, abzudecken.
  • Verweise in der Spezifikation auf „eine Ausführungsform“, „eine veranschaulichende Ausführungsform“ usw. geben an, dass die beschriebene Ausführungsform ein/e bestimmte/s Merkmal, Struktur oder Eigenschaft beinhaltet, jedoch kann jede Ausführungsform diese/s bestimmte Merkmal, Struktur oder Eigenschaft beinhalten, muss dies jedoch nicht notwendigerweise tun. Darüber hinaus beziehen sich derartige Phrasen nicht notwendigerweise auf die gleiche Ausführungsform. Ferner wird, wenn ein/e bestimmte/s Merkmal, Struktur oder Eigenschaft in Verbindung mit einer Ausführungsform beschrieben ist, davon ausgegangen, dass es innerhalb der Kenntnisse eines Fachmanns auf dem Gebiet liegt, ein/e derartige/s Merkmal, Struktur oder Eigenschaft in Verbindung mit anderen Ausführungsformen zu bestimmen, egal ob explizit beschrieben oder nicht. Außerdem sollte verstanden werden, dass Gegenstände, die in einer Liste in der Form „mindestens eines aus A, B und C“ enthalten sind, (A); (B); (C); (A und B); (A und C); (B und C); oder (A, B und C) bedeuten können. Ähnlich können Gegenstände, die in der Form „mindestens eines aus A, B oder C“ aufgeführt sind, (A); (B); (C); (A und B); (A und C); (B und C); oder (A, B und C) bedeuten.
  • Die offenbarten Ausführungsformen können in einigen Fällen in Hardware, Firmware, Software oder jeglicher Kombination davon implementiert sein. Die offenbarten Ausführungsformen können auch als Anweisungen implementiert sein, die in einem oder mehreren transitorischen oder nicht-transitorischen maschinenlesbaren (z.B. computerlesbaren) Speichermedien (z.B. Arbeitsspeicher, Datenspeicher usw.) enthalten oder darauf gespeichert sind, welche durch einen oder mehrere Prozessoren gelesen und ausgeführt werden können. Ein maschinenlesbares Speichermedium kann als jegliches/r Speichergerät, Mechanismus oder eine andere physische Struktur zum Speichern oder Übertragen von Informationen in einer durch eine Maschine lesbaren Form verkörpert sein (z.B. ein flüchtiger oder nicht-flüchtiger Arbeitsspeicher, eine Medienplatte oder ein anderes Mediengerät).
  • In den Zeichnungen können einige Struktur- oder Verfahrensmerkmale in spezifischen Anordnungen und/oder Reihenfolgen gezeigt sein. Jedoch sollte verstanden werden, dass derartige spezifische Anordnungen und/oder Reihenfolgen möglicherweise nicht erforderlich sind. Vielmehr können derartige Merkmale in einigen Ausführungsformen in einer unterschiedlichen Art und Weise und/oder Reihenfolge als in den veranschaulichenden Figuren gezeigt angeordnet sein. Außerdem soll der Einschluss eines Struktur- oder Verfahrensmerkmals in einer bestimmten Figur nicht implizieren, dass ein derartiges Merkmal in allen Ausführungsformen erforderlich ist, und in einigen Ausführungsformen ist es möglicherweise nicht enthalten oder kann mit anderen Merkmalen kombiniert sein.
  • Nun Bezug nehmend auf 1, beinhaltet ein veranschaulichendes System 100 für den Einsatz dynamischer Underlay-Netzwerke in einer Cloud-Computing-Infrastruktur unter Verwendung einer Rack-Scale-Rechenarchitektur einen oder mehrere Endpunktknoten 102, die kommunikativ mit einem veranschaulichenden Rechenzentrum 106, das einen oder mehrere Pods 108 (d.h. Sammlungen von Computing-Racks 110 innerhalb eines gemeinsam genutzten Infrastrukturmanagementbereichs) beinhaltet, verbunden sind. Jedes der veranschaulichenden Computing-Racks 120 beinhaltet einen Netzwerk-Controller 112, der kommunikativ mit einem oder mehreren Einschüben 114 oder Modulgehäusen zur Unterbringung eines Switches 116 und eines oder mehrerer Rechenknoten 120 verbunden ist. Im Einsatz verwaltet der Netzwerk-Controller 112 die Switches 116 jedes der Einschübe 114 zum Verwalten der Bereitstellung und der Konfiguration von Underlay-Netzwerken (siehe z.B. das Underlay-Netzwerk 200 von 2).
  • Dementsprechend können die Switches 116, unter der Regie des Netzwerk-Controllers 112, die Underlay-Netzwerke dynamisch bereitstellen, indem virtuelle lokale Netzwerke (VLANs) zwischen den entsprechenden Switches 116 (d.h. diejenigen Switches 116, die mit bestimmten Rechenknoten 120 eines Tenant-Netzwerks assoziiert sind) gebildet werden, wodurch die Tenant-Netzwerke in der Cloud-Umgebung effektiv isoliert werden. Bei der Erzeugung des Underlay-Netzwerks kann eine Virtualisierungsschicht des Netzwerks (d.h. ein Overlay-Netzwerk) erzeugt werden, die einem Cloud-Betriebssystem sichtbar gemacht wird, unter Verwendung bekannter Technologien (z.B. die OpenDaylight-Plattform über ML2 (Modular Layer 2) -Plugins, Ryu, Floodlight usw.) verwaltet wird und mit dem Underlay-Netzwerk assoziiert wird. Dementsprechend kann das Cloud-Betriebssystem Host/Instanz-Sichtbarkeit, Zeitplanung, Leistungsüberwachung und Dienstqualitätsteuerung über das Underlay-Netzwerk verwalten. Ferner ist der Netzwerk-Controller 112 zum Überwachen von Leistungslevels der Switches 116 und der physischen/virtuellen Netzwerkschnittstellen der Rechenknoten 120 konfiguriert. Dementsprechend kann der Netzwerk-Controller 112 eine Zeitplanung basierend auf Leistungsmetriken (z.B. Netzwerknutzung, Dienstqualität-Telemetrie usw.) koordinieren und das Underlay-Netzwerk nach Bedarf zur Erfüllung von Dienstqualitätsanforderungen dynamisch anpassen. Während das veranschaulichende System 100 disaggregierte Hardware (d.h. gepoolte Einschübe für Computing, Arbeitsspeicher und Datenspeicher) beinhaltet, sollte verstanden werden, dass die hierin beschriebenen Funktionen in anderen Ausführungsformen auch auf standardmäßigen Rack-montierten Servern durchgeführt werden können.
  • Die Endpunktknoten 102 können als jegliche Art eines Rechen- oder Computergerätes, das zum Durchführen der hierin beschriebenen Funktionen in der Lage ist, verkörpert sein, einschließlich, ohne Einschränkung, eines tragbaren Rechengerätes (z.B. Smartphone, Tablet, Laptop, Notebook, Wearable usw.), das mobile Hardware (z.B. Prozessor, Arbeitsspeicher, Datenspeicher, drahtlose Kommunikationsschaltungen usw.) und Software (z.B. ein Betriebssystem) zum Unterstützen einer mobilen Architektur und Tragbarkeit beinhaltet, eines Computers, eines Servers (z.B. eigenständig, Rack-montiert, Blade usw.), einer Netzwerkanwendung (z.B. physisch oder virtuell), einer Web-Anwendung, eines verteilten Rechensystems, eines Prozessor-basierten Systems und/oder eines Multiprozessor-Systems.
  • Das Netzwerk 104 kann als jegliche Art eines verdrahteten und/oder drahtlosen Kommunikationsnetzwerks verkörpert sein, einschließlich eines drahtlosen lokalen Netzwerks (WLAN - Wireless Local Area Network), eines drahtlosen Kurzstreckennetzes (WPAN-Wireless Personal Area Network), eines Mobilfunknetzes (z.B. GSM (Global System for Mobile Communications), LTE (Long-Term Evolution) usw.), eines Telefonnetzes, eines DSL (Digital Subscriber Line) -Netzes, eines Kabelnetzes, eines lokalen Netzwerks (LAN - Local Area Network), eines Weitverkehrsnetzes (WAN - Wide Area Network), eines globalen Netzwerks (z.B. das Internet) oder jeglicher Kombination davon. Es sollte verstanden werden, dass das Netzwerk 104 in derartigen Ausführungsformen als ein zentralisiertes Netzwerk dienen kann und in einigen Ausführungsformen kommunikativ mit einem anderen Netzwerk (z.B. das Internet) verbunden sein kann. Dementsprechend kann das Netzwerk 104 nach Bedarf eine Vielzahl anderer Netzwerkrechengeräte (z.B. virtuelle und physische Router, Switches, Netzwerk-Hubs, Server, Speichergeräte, Rechengeräte usw.) zur Erleichterung der Kommunikation zwischen den Endpunktknoten 102 und dem Rechenzentrum 106, sowie Netzwerkgeräte zwischen Rechenzentren 106, welche zur Erhaltung der Klarheit der Beschreibung nicht gezeigt sind, beinhalten.
  • Im Einsatz übertragen und empfangen die Computing-Racks 110 Daten an andere/von anderen Computing-Racks 110 in dem gleichen Pod 108 und/oder entfernte/n Computing-Racks 110 in anderen Pods 108 (z.B. über das Netzwerk 104). Dazu kann jedes der Computing-Racks 110 einen Rack-Management-Controller (nicht gezeigt) beinhalten, der für das Verwalten von Ressourcen des entsprechenden Computing-Racks 110, wie z.B. Energieversorgung und Kühlung, verantwortlich ist. Ähnlich sollte verstanden werden, dass die Rack-Management-Controller mit Controllern des Pods 108, wie z.B. ein Pod-Management-Controller (nicht gezeigt), der zum Verwalten der logischen Managementfunktionalität über sämtliche Infrastruktur innerhalb eines entsprechenden Pods 108 hinweg konfiguriert ist, kommunizieren können.
  • Die Computing-Racks 110 können als modulare Rechengeräte verkörpert sein, die, allein oder in Kombination mit anderen Computing-Racks 110, zum Durchführen der hierin beschriebenen Funktionen in der Lage sind. Zum Beispiel kann jedes der Computing-Racks 110 als ein Chassis oder ein anderes Gehäuse zur Rack-Montage modularer Recheneinheiten, wie z.B. Rechen-Trays, Datenspeicher-Trays, Netzwerk-Trays, oder traditioneller Rack-montierter Komponenten, wie z.B. Server und/oder Switches, verkörpert sein. Wie in 1 gezeigt, beinhaltet das veranschaulichende Computing-Rack 110 den einen oder die mehreren Einschübe 114 zur Unterbringung des Switches 116 und gepoolter Rechenressourcen (d.h. die Rechenknoten 120). Die Computing-Racks 110 können auch zusätzliche gepoolte Systemressourcen, wie z.B. gepoolten Arbeitsspeicher, gepoolten Datenspeicher und gepoolte Netzwerke, sowie assoziierte Zwischenverbindungen, Peripheriegeräte, Stromversorgungen, Wärmemanagementsysteme und andere Komponenten beinhalten. Außerdem können die Computing-Racks 110, obwohl als Einschub-Level-Switches (z.B. der Switch 116) beinhaltend veranschaulicht, in einigen Ausführungsformen außerdem und/oder alternativ dazu einen ToR (Top-of-Rack) -Switch, einen EoR (Edge-of-Rack) -Switch, einen MoR (Middle-of-Rack) - Switch oder jegliche andere Art eines disaggregierten Switches beinhalten. Ferner sollte verstanden werden, dass die Computing-Racks 110 in einigen Ausführungsformen mehr als eine/s jeder/s der gepoolten Systemressourcen und/oder disaggregierten Schaltgeräte beinhalten können.
  • Wie zuvor beschrieben, wird der Netzwerk-Controller 112 veranschaulichend auf der Ebene des Computing-Racks 110 eingesetzt. Jedoch kann der Netzwerk-Controller 112 in einigen Ausführungsformen auch auf der Ebene des Pods 108 des Rechenzentrums 106 anstatt der Ebene des Computing-Racks 110 eingeschlossen sein. Der Netzwerk-Controller 112 ist als jegliche Art eines Netzwerkrechengerätes (z.B. ein Netzwerkverkehr-Managementgerät, - Verarbeitungsgerät und/oder -Weiterleitungsgerät), das zum Durchführen der hierin beschriebenen Funktionen in der Lage ist, verkörpert, wie z.B., ohne Einschränkung, ein Switch (z.B. Rack-montiert, eigenständig, vollständig verwaltet, teilweise verwaltet, für Vollduplex- und/oder Halbduplex-Kommunikation aktiviert usw.), ein Server (z.B. eigenständig, Rack-montiert, Blade usw.), eine Netzwerkanwendung (z.B. physisch oder virtuell), ein Router, eine Web-Anwendung, ein verteiltes Rechensystem, ein Prozessor-basiertes System und/oder ein Multiprozessor-System.
  • Wie in 1 gezeigt, beinhaltet der veranschaulichende Netzwerk-Controller 112 einen Prozessor 132, ein Eingabe/Ausgabe (E/A) -Subsystem 134, einen Arbeitsspeicher 136, ein Datenspeichergerät 138 und die Kommunikationsschaltungen 140. Natürlich kann der Netzwerk-Controller 112 in anderen Ausführungsformen auch andere oder zusätzliche Komponenten beinhalten, wie z.B. diejenigen, die üblicherweise in einem Netzwerkrechengerät zu finden sind. Außerdem können in einigen Ausführungsformen eine oder mehrere der veranschaulichenden Komponenten in einer anderen Komponente eingeschlossen sein oder anderweitig einen Abschnitt davon bilden. Zum Beispiel kann der Arbeitsspeicher 136, oder Abschnitte davon, in einigen Ausführungsformen in den Prozessor 132 eingeschlossen sein. Ferner können in einigen Ausführungsformen eine oder mehrere der veranschaulichenden Komponenten aus dem Netzwerk-Controller 112 weggelassen sein.
  • Der Prozessor 132 kann als jegliche Art von Prozessor, der zum Durchführen der hierin beschriebenen Funktionen in der Lage ist, verkörpert sein. Zum Beispiel kann der Prozessor 132 als (ein) Einzel- oder Mehrkern-Prozessor(en), Digitalsignal-Prozessor, Mikrocontroller oder ein anderer Prozessor oder eine Verarbeitungs-/Steuerschaltung verkörpert sein. Ähnlich kann der Arbeitsspeicher 136 als jegliche Art von flüchtigem oder nicht-flüchtigem Arbeitsspeicher oder Datenspeicher, der zum Durchführen der hierin beschriebenen Funktionen in der Lage ist, verkörpert sein. Im Betrieb kann der Arbeitsspeicher 136 verschiedene Daten und Software, die während des Betriebs des Netzwerk-Controllers 112 verwendet werden, wie z.B. Betriebssysteme, Anwendungen, Programme, Bibliotheken und Treiber, speichern.
  • Der Arbeitsspeicher 136 ist über das E/A-Subsystem 134, welches als Schaltungen und/oder Komponenten zur Erleichterung von Eingabe/Ausgabe-Operationen mit dem Prozessor 132, dem Arbeitsspeicher 136 und anderen Komponenten des Netzwerk-Controllers 112 verkörpert sein kann, kommunikativ mit dem Prozessor 132 verbunden. Zum Beispiel kann das E/A-Subsystem 134 als Arbeitsspeicher-Controller-Hubs, Eingabe/Ausgabe-Steuerungs-Hubs, Firmware-Geräte, Kommunikationsverbindungen (d.h. Punkt-zu-Punkt-Verbindungen, Bus-Verbindungen, Drähte, Kabel, Lichtleiter, Leiterplattenspuren usw.) und/oder andere Komponenten und Subsysteme zur Erleichterung der Eingabe/Ausgabe-Operationen verkörpert sein oder diese anderweitig beinhalten. In einigen Ausführungsformen kann das E/A-Subsystem 134 einen Abschnitt eines Ein-Chip-Systems (SoC - System-on-a-Chip) bilden und, zusammen mit dem Prozessor 132, dem Arbeitsspeicher 136 und anderen Komponenten des Netzwerk-Controllers 112, auf einem einzelnen integrierten Schaltungschip eingeschlossen sein.
  • Das Datenspeichergerät 138 kann als jegliche Art von Gerät oder Geräten verkörpert sein, das/die zur kurzfristigen oder langfristigen Speicherung von Daten konfiguriert ist/sind, wie zum Beispiel Arbeitsspeichergeräte und -schaltungen, Arbeitsspeicherkarten, Festplattenlaufwerke, Solid-State-Laufwerke oder andere Datenspeichergeräte. Es sollte verstanden werden, dass das Datenspeichergerät 138 und/oder der Arbeitsspeicher 136 (z.B. die computerlesbaren Speichermedien) verschiedene Daten wie hierin beschrieben speichern können, einschließlich Betriebssysteme, Anwendungen, Programme, Bibliotheken, Treiber, Anweisungen usw., die durch einen Prozessor (z.B. der Prozessor 132) des Netzwerk-Controllers 112 ausgeführt werden können.
  • Die Kommunikationsschaltungen 140 können als jegliche/s Kommunikationsschaltung, -gerät oder eine Sammlung davon, die/das zum Ermöglichen von Kommunikation zwischen dem Netzwerk-Controller 112 und anderen Rechengeräten, wie z.B. den Switches 116 der Einschübe 114, sowie einem entfernten Netzwerkrechengerät (z.B. ein anderer Netzwerk-Controller, ein Lastausgleichsnetzwerkschalter/Router, ein aggregierter Netzwerkschalter usw.) über ein Netzwerk (z.B. das Netzwerk 104) in der Lage ist, verkörpert sein. Die Kommunikationsschaltungen 140 können zum Verwenden jeglicher einen oder mehrerer Kommunikationstechnologien (z.B. drahtlose oder verdrahtete Kommunikationstechnologien) und assoziierter Protokolle (z.B. Ethernet, Bluetooth®, Wi-Fi®, WiMAX, LTE, 5G usw.) zum Bewirken einer derartigen Kommunikation konfiguriert sein.
  • In einigen Ausführungsformen kann der Netzwerk-Controller 112 zum Arbeiten in einer Software-definierten Netzwerk (SDN - Software-Defined Networking) -Umgebung (d.h. ein SDN-Controller) und/oder einer Netzwerkfunktionsvirtualisierungs- (NFV - Network Functions Virtualization) Umgebung (d.h. ein NFV-Manager und -Netzwerk-Orchestrator (MANO - Manager and Network Orchestrator)) konfiguriert sein. Dementsprechend sollte verstanden werden, dass die Steuerfunktionalität des Netzwerk-Controllers 112 und eine Platzierung innerhalb der Architektur des Rechenzentrums 106 in einigen Ausführungsformen von der Gegenwart eines Netzwerk-/Switch-Managementmoduls (siehe z.B. das Steuerebenen-Managementmodul 320 von 3), das auf dem Netzwerkrechengerät untergebracht ist, hierin als der Netzwerk-Controller 112 beschrieben, abhängen kann. Zum Beispiel kann der Netzwerk-Controller 112 in einem Netzwerkrechengerät wie oben beschrieben (z.B. ein ToR-Switch, ein EoR-Switch, ein MoR-Switch oder jegliche andere Art eines disaggregierten Switches), einem erweiterten Netzwerkschnittstellen-Controller (NIC - Network Interface Controller) (z.B. eine Host-Struktur-Schnittstelle (HFI - Host Fabric Interface)) oder jeglichem anderen Rechengerät in dem gleichen Managementnetzwerk an einem Eingangsanschluss eines entsprechenden Computing-Racks 110 untergebracht sein, sodass der Netzwerk-Controller 112, in Abhängigkeit von der Ausführungsform, mit sämtlichen Switches in einem entsprechenden Pod 108 oder Computing-Rack 110 kommunizieren kann.
  • Die Einschübe 114 können als jegliches Chassis, Tray, Modul oder anderes Gehäuse, das zum Unterstützen des Switches 116 und der Rechenknoten 120 sowie jeglicher assoziierter Zwischenverbindungen, Stromversorgungen, Wärmemanagementsysteme oder anderer assoziierter Komponenten in der Lage ist, verkörpert sein. Es sollte verstanden werden, dass jeder der Einschübe 114 multiple Module beinhalten kann, die multiple Slots für das Einführen eines Blades (Platine) (z.B. ein Rechen-Blade) innerhalb jedes Slots aufweisen. Zum Beispiel können die Einschübe 114 in einer veranschaulichenden Ausführungsform multiple Module beinhalten, in welchen der Switch 116 und/oder Blades (d.h. multiple Rechen-Blades gepoolt zum Bilden der Rechenknoten 120) eingeführt sein können. Es sollte verstanden werden, dass in einigen Ausführungsformen jeder der Einschübe 114 außerdem einen Einschubmanagement-Controller (nicht gezeigt) für das Management der Konfiguration gemeinsam genutzter und gepoolter Ressourcen (z.B. Arbeitsspeicher, Datenspeicher, Rechnen usw.) des entsprechenden Einschubs 114 beinhalten kann. In derartigen Ausführungsformen kann der Einschubmanagement-Controller zur Schnittstellenbildung mit einem oder mehreren aus einem Pod-Management-Controller, einem Rack-Management-Controller und/oder jeglichem anderen Management-Controller (z.B. auf der Modul-Ebene, der Blade-Ebene usw.) konfiguriert sein.
  • Der Switch 116 kann als jeglicher mit der Rack-Scale-Architektur konformer Switch, der zum Durchführen der hierin beschriebenen Funktionen in der Lage ist, verkörpert sein, wie z.B. ein Modul-basierter Switch (d.h. zur Einführung in ein Modul eines Einschubs 114), ein ToR-Switch, ein EoR-Switch, ein MoR-Switch oder jegliche Art eines disaggregierten Switches. Zum Beispiel kann der Switch 116 in einigen Ausführungsformen als ein verwalteter Smart-Switch, der einen Satz von Managementmerkmalen beinhaltet, konfiguriert sein, wie dies für den Switch 116 zur Bereitstellung der Underlay-Netzwerke (z.B. das Konfigurieren von VLANs) und Durchführung anderer Funktionen wie hierin beschrieben erforderlich sein kann. Der veranschaulichende Switch 116 beinhaltet multiple Switch-Ports 118 (d.h. Zugangsanschlüsse) zum Übertragen und Empfangen von Daten an den/von dem Switch 116. Dementsprechend ist der Switch 116 zum Erzeugen einer separaten Kollisionsdomäne für jeden der Switch-Ports 118 konfiguriert. Als solcher kann, in Abhängigkeit vom Netzwerkdesign des Switches und vom Betriebsmodus (z.B. Halbduplex, Vollduplex usw.), jeder Rechenknoten 120, der mit einem der Switch-Ports 118 des Switches 116 verbunden ist, jederzeit Daten an jeglichen der anderen Rechenknoten 120 übertragen, und die Übertragungen sollten sich nicht beeinträchtigen oder kollidieren.
  • Jeder Rechenknoten 120 kann als jegliche Art eines Rechengerätes, das zum Durchführen der hierin beschriebenen Funktionen in der Lage ist, verkörpert sein. Zum Beispiel kann jeder der Rechenknoten 120, ohne Einschränkung, als ein/e oder mehrere Server-Rechengeräte, Computer-Mainboards, Tochterkarten oder Erweiterungskarten, Ein-Chip-Systeme, Computerprozessoren, Unterhaltungselektronikgeräte, intelligente Geräte und/oder jegliches anderes Rechengerät oder Sammlung von Geräten, das/die zum Verarbeiten von Netzwerkkommunikation in der Lage ist, verkörpert sein. Wie in 1 gezeigt, beinhaltet der veranschaulichende Rechenknoten 120 einen Prozessor 122, ein E/A-Subsystem 124, die Kommunikationsschaltungen 128, und kann in einigen Ausführungsformen den Arbeitsspeicher 126 beinhalten. Natürlich sollte verstanden werden, dass der Rechenknoten 120 in anderen Ausführungsformen auch andere oder zusätzliche Komponenten beinhalten kann, wie z.B. diejenigen, die üblicherweise in einem Rechengerät zu finden sind (z.B. verschiedene Eingabe/Ausgabe-Geräte). Außerdem können in einigen Ausführungsformen eine oder mehrere der veranschaulichenden Komponenten in einer anderen Komponente eingeschlossen sein oder anderweitig einen Abschnitt davon bilden. Zum Beispiel kann der Arbeitsspeicher 126, oder Abschnitte davon, in einigen Ausführungsformen in den Prozessor 122 eingeschlossen sein.
  • Der Prozessor 122 kann als jegliche Art eines Prozessors, der zum Durchführen der hierin beschriebenen Funktionen in der Lage ist, verkörpert sein. Zum Beispiel kann der Prozessor 122 als ein Einzel- oder Mehrkern-Prozessor(en), Digitalsignal-Prozessor, Mikrocontroller oder ein/e andere/r Prozessor oder Verarbeitungs-/Steuerschaltung verkörpert sein. Obwohl veranschaulichend als ein Einzelprozessor 122 gezeigt, kann jeder Rechenknoten 120 in einigen Ausführungsformen multiple Prozessoren 122 beinhalten. Ähnlich kann das E/A-Subsystem 124 als Schaltungen und/oder Komponenten zur Erleichterung von Eingabe/Ausgabe-Operationen mit dem Prozessor 122, den Kommunikationsschaltungen 128, dem Arbeitsspeicher 126 und anderen Komponenten des Rechenknotens 120 verkörpert sein. Zum Beispiel kann das E/A-Subsystem 124 als Arbeitsspeicher-Controller-Hubs, Eingabe/Ausgabe-Steuerungs-Hubs, Firmware-Geräte, Kommunikationsverbindungen (d.h. Punkt-zu-Punkt-Verbindungen, Bus-Verbindungen, Drähte, Kabel, Lichtleiter, Leiterplattenspuren usw.) und/oder andere Komponenten und Subsysteme zur Erleichterung der Eingabe/Ausgabe-Operationen verkörpert sein oder diese anderweitig beinhalten. In einigen Ausführungsformen kann das E/A-Subsystem 124 einen Abschnitt eines Ein-Chip-Systems (SoC) bilden und, zusammen mit dem Prozessor 122, den Kommunikationsschaltungen 128, dem Arbeitsspeicher 126 und anderen Komponenten des Rechenknotens 120, auf einem einzelnen integrierten Schaltungschip eingeschlossen sein.
  • Der Arbeitsspeicher 126 kann als jegliche Art eines flüchtigen oder nicht-flüchtigen Arbeitsspeichers oder Datenspeichers, der zum Durchführen der hierin beschriebenen Funktionen in der Lage ist, verkörpert sein. Im Einsatz kann der Arbeitsspeicher 126 verschiedene Daten und Software, die während des Betriebs des Rechenknotens 120 verwendet werden, wie z.B. Betriebssysteme, Anwendungen, Programme, Bibliotheken und Treiber, speichern. In einigen Ausführungsformen kann der Arbeitsspeicher 126 Daten, die durch einen Arbeitsspeicher-Pool gepflegt werden, zeitweilig zwischenspeichern oder anderweitig speichern. Wie gezeigt enthält der Rechenknoten 120 in einigen Ausführungsformen möglicherweise keinen dedizierten On-Board-Arbeitsspeicher 126.
  • Die Kommunikationsschaltungen 128 können als jegliche/s Kommunikationsschaltung, -gerät oder eine Sammlung davon, die/das zum Ermöglichen von Kommunikation zwischen dem Rechenknoten 120 und anderen Rechenknoten 120, dem Switch 116 und/oder anderen entfernten Geräten in der Lage ist, verkörpert sein. Die Kommunikationsschaltungen 128 können zum Verwenden jeglicher einen oder mehrerer Kommunikationstechnologien (z.B. drahtlose oder verdrahtete Kommunikation) und assoziierter Protokolle (z.B. Ethernet, Bluetooth®, Wi-Fi®, WiMAX usw.) zum Bewirken einer derartigen Kommunikation konfiguriert sein. In der veranschaulichenden Ausführungsform beinhalten die Kommunikationsschaltungen 128 eine NIC 130, die zur Erleichterung der Übertragung/des Empfangs von Netzwerkpaketen mit dem Switch 116 einsetzbar ist.
  • Die NIC 130 kann als ein/e oder mehrere Add-in-Karten, Tochterkarten, Netzwerkschnittstellenkarten, Controller-Chips, Chipsätze oder andere Geräte, die durch den Rechenknoten 120 verwendet werden können, verkörpert sein. Zum Beispiel kann die NIC 130 in einigen Ausführungsformen in den Prozessor 122 integriert sein, als eine Erweiterungskarte, die über einen Erweiterungs-Bus (z.B. PCI Express) mit dem E/A-Subsystem 124 verbunden ist, verkörpert sein, Teil eines SoC, das einen oder mehrere Prozessoren beinhaltet, sein oder auf einem Multichip-Paket, das auch einen oder mehrere Prozessoren enthält, enthalten sein. Außerdem, oder alternativ dazu, kann die Funktionalität der NIC 130 in einigen Ausführungsformen auch in eine oder mehrere Komponenten des Rechenknotens 120 auf der Karten-Ebene, Socket-Ebene, Chip-Ebene und/oder anderen Ebenen integriert sein.
  • Es sollte verstanden werden, dass sich Underlay-Netzwerke zwischen Rechenknoten 120, die mit dem gleichen Switch 116 verbunden sind, erstrecken können (z.B. innerhalb des gleichen Einschubs 114) oder sich über multiple Switches 116 hinweg erstrecken können (z.B. über multiple Einschübe 114 hinweg). Nun Bezug nehmend auf 2, ist ein veranschaulichendes Underlay-Netzwerk 200 gezeigt, das sich über einen ersten Einschub, bezeichnet als Einschub (1) 202, und einen zweiten Einschub, bezeichnet als Einschub (2) 222, hinweg erstreckt, um drei Host-Rechenknoten 120 wie hierin beschrieben zu verbinden. Der erste Einschub (d.h. Einschub (1) 202) beinhaltet einen ersten Rechenknoten, welcher als Rechenknoten (1) 204 bezeichnet ist, einen zweiten Rechenknoten, welcher als Rechenknoten (2) 208 bezeichnet ist, und einen dritten Rechenknoten, welcher als Rechenknoten (N) 212 bezeichnet ist (d.h. der „N-te“ Rechenknoten der Rechenknoten 120 des Einschubs (1) 202, wobei „N“ eine positive Ganzzahl ist und einen oder mehrere zusätzliche Rechenknoten 120 des Einschubs (1) 202 bezeichnet). Ähnlich beinhaltet der zweite Einschub (d.h. Einschub (2) 222) einen ersten Rechenknoten, welcher als Rechenknoten (1) 224 bezeichnet ist, einen zweiten Rechenknoten, welcher als Rechenknoten (2) 228 bezeichnet ist, und einen dritten Rechenknoten, welcher als Rechenknoten (N) 232 bezeichnet ist (d.h. der „N-te“ Rechenknoten der Rechenknoten 120 des Einschubs (2) 222, wobei „N“ eine positive Ganzzahl ist und einen oder mehrere zusätzliche Rechenknoten 120 des Einschubs (2) 222 bezeichnet).
  • Jeder der Rechenknoten 120 beinhaltet Netzwerkkomponenten, die zum Instanziieren einer VLAN-Schnittstelle über zwei oder mehr physische Netzwerkschnittstellen in der Lage sind (d.h. die NICs 130 jedes der Rechenknoten 120), wie sie z.B. durch Verwendung von Standard-Betriebssystembefehlen instanziiert werden können. Dazu beinhaltet jeder der Einschübe 114 außerdem einen Switch 116, veranschaulichend als der Switch 216 von Einschub (1) 202 und der Switch 236 von Einschub (2) 222 gezeigt, durch welchen jeder der Rechenknoten 120 mit anderen Rechenknoten des gleichen Einschubs 114 sowie über unterschiedliche Einschübe 114 hinweg kommunizieren kann. Die Kommunikation zwischen den und/oder über die Einschübe/n 114 hinweg wird über die Switch-Ports 218 des Switches 216 und die Switch-Ports 238 des Switches 236 (z.B. über PCIe (Peripheral Component Interconnect express) -Verbindungen) entlang der Zwischenverbindungskabel 220, 240 erleichtert.
  • Die Zwischenverbindungskabel 220, 240 können als jegliche Hochgeschwindigkeitskommunikationsverbindungen (d.h. Punkt-zu-Punkt-Verbindungen, Bus-Verbindungen, Drähte, Kabel, Lichtleiter, Leiterplattenspuren usw.), die zum Übertragen von Daten in der Lage sind, verkörpert sein, wie sie z.B. unter Verwendung von Lichtwellenleitern, Kupfer oder jeglicher anderen Art von Material, das zum internen und/oder externen Übertragen von Daten an das Rechenzentrum 106 in der Lage ist, hergestellt werden können. Dementsprechend sollte verstanden werden, dass die Switches 216, 236 und/oder die Rechenknoten 120 in einigen Ausführungsformen spezialisierte NIC 130 -Schaltungen, wie z.B. Host-Strukturschnittstellen (HFIs - Host Fabric Interfaces) zur Schnittstellenbildung mit den Zwischenverbindungskabeln 220, 240 sowie eine Silizium-Photonik-Schaltungsstruktur und eine Reihe optischer Zwischenverbindungen beinhalten können.
  • Zum Erzeugen eines Underlay-Netzwerks, wie z.B. das veranschaulichende Underlay-Netzwerk 200 von 2, ist der Netzwerk-Controller 112 zum Übertragen von Informationen (z.B. über Anwendungsprogrammierungsschnittstellen (API) -Befehle) an den/die entsprechenden einen oder mehreren Switches 116, die mit den betreffenden Rechenknoten 120 verbunden sind, die mit dem Underlay-Netzwerk assoziiert werden sollen, konfiguriert. Bei Empfang der Anweisung kann der Switch 116 ein VLAN erzeugen (d.h. eine VLAN-Referenz zu einer Datenbank des entsprechenden Switches 116 hinzufügen) und entsprechende Switch-Ports 118 zu dem erzeugten VLAN zuweisen, um jeden der Switches 116 zu verbinden. In einigen Ausführungsformen kann eine VLAN-Schnittstelle für das erzeugte VLAN an jedem Switch 116 konfiguriert werden, gelegentlich bezeichnet als eine geschaltete virtuelle Schnittstelle (SVI - Switched Virtual Interface). Ferner ist jeder der Rechenknoten 120, die dem Underlay-Netzwerk zugewiesen werden sollen, zum Erzeugen einer VLAN-Schnittstelle über ein physisches Netzwerkschnittstellengerät der entsprechenden Rechenknoten konfiguriert (z.B. über die NICs 130).
  • In einem veranschaulichenden Beispiel wurde das Underlay-Netzwerk 200 von 2, angegeben durch eine gestrichelte Begrenzungslinie, derart konfiguriert (z.B. durch den Netzwerk-Controller 112 von 1), dass es den Rechenknoten (1) 204 und den Rechenknoten (2) 208 von Einschub (1) 202 sowie den Rechenknoten (2) 224 von Einschub (2) 228 beinhaltet. Mit anderen Worten, der Rechenknoten (1) 204, der Rechenknoten (2) 208 und der Rechenknoten (2) 224 haben jeweils eine VLAN-Schnittstelle (z.B. die VLAN-Schnittstelle 206 des Rechenknotens (1) 204, die VLAN-Schnittstelle 210 des Rechenknotens (2) 208 und die VLAN-Schnittstelle 226 des Rechenknotens (1) 224) über ihre entsprechende NIC 130 konfiguriert. Außerdem wurden, zur Unterstützung von Kommunikation untereinander über das Underlay-Netzwerk 200 hinweg, multiple Switch-Ports 218, 236 der entsprechenden Switches 216, 236 (z.B. zwei entsprechende Switch-Ports 218 des Switches 216 und ein entsprechender Switch-Port 238 des Switches 236) konfiguriert, um ein VLAN zwischen den Switches 216, 236 zu erzeugen. Es sollte verstanden werden, dass die anderen Rechenknoten 120 (z.B. der Rechenknoten (3) 212 von Einschub (1) 202 und der Rechenknoten (2) 228 und der Rechenknoten (3) 232 von Einschub (2) 222), die gegenwärtig nicht in das veranschaulichende Underlay-Netzwerk 200 eingeschlossen sind, eine konfigurierte VLAN-Schnittstelle (z.B. die VLAN-Schnittstelle 214 des Rechenknotens (3) 212, die VLAN-Schnittstelle 230 des Rechenknotens (2) 228 und die VLAN-Schnittstelle 234 des Rechenknotens (3) 232), die einem anderen Underlay-Netzwerk 200 entspricht, aufweisen können oder auch nicht.
  • Nun Bezug nehmend auf 3, baut der Netzwerk-Controller 112 in einer veranschaulichenden Ausführungsform eine Umgebung 300 während des Betriebs auf. Die veranschaulichende Umgebung 300 beinhaltet ein Anwendungsschnittstellen-Modul 310, ein Steuerebenen-Managementmodul 320, ein Datenebenenschnittstellen-Modul 330 und ein Rack-Scale-Controller-Modul 340. Die verschiedenen Module der Umgebung 300 können als Hardware, Firmware, Software oder eine Kombination davon verkörpert sein. Als solche können ein oder mehrere der Module der Umgebung 300 in einigen Ausführungsformen als Schaltungen oder eine Sammlung elektrischer Geräte verkörpert sein (z.B. eine Anwendungsschnittstellen-Schaltung 310, eine Steuerebenenmanagement-Schaltung 320, eine Datenebenenschnittstellen-Schaltung 330 und eine Rack-Scale-Controller-Schaltung 340 usw.).
  • Es sollte verstanden werden, dass in derartigen Ausführungsformen eine oder mehrere aus der Anwendungsschnittstellen-Schaltung 310, der Steuerebenenmanagement-Schaltung 320, der Datenebenenschnittstellen-Schaltung 330 und der Rack-Scale-Controller-Schaltung 340 einen Abschnitt des einen oder der mehreren der Prozessoren 132, des E/A-Subsystems 134, der Kommunikationsschaltungen 140 und/oder anderer Komponenten des Netzwerk-Controllers 112 bilden können. Außerdem können ein oder mehrere der veranschaulichenden Module in einigen Ausführungsformen einen Abschnitt eines anderen Moduls bilden und/oder ein oder mehrere der veranschaulichenden Module können unabhängig voneinander sein. Ferner können ein oder mehrere der Module der Umgebung 300 in einigen Ausführungsformen als virtualisierte Hardwarekomponenten oder eine emulierte Architektur verkörpert sein, welche durch den einen oder die mehreren Prozessoren und/oder andere Komponenten des Netzwerk-Controllers 112 aufgebaut und aufrechterhalten werden können.
  • In der veranschaulichenden Umgebung 300 beinhaltet der Netzwerk-Controller 112 ferner die Topologiedaten 302, die Fähigkeitsdaten 304, die Leistungsdaten 306 und die Strategiedaten 308, welche jeweils in einem Arbeitsspeicher und/oder Datenspeichergerät des Netzwerk-Controllers 112 gespeichert sein können. Ferner kann auf alle der Netzwerk-Topologiedaten 302, der Fähigkeitsdaten 304, der Leistungsdaten 306 und der Strategiedaten 308 jeweils durch die verschiedenen Module und/oder Submodule des Netzwerk-Controllers 112 zugegriffen werden. Außerdem sollte verstanden werden, dass in einigen Ausführungsformen die Daten, die in jeden der Netzwerk-Topologiedaten 302, der Fähigkeitsdaten 304, der Leistungsdaten 306 und der Strategiedaten 308 gespeichert sind oder anderweitig dadurch dargestellt werden, relativ zueinander möglicherweise nicht einander ausschließend sind.
  • Zum Beispiel können in einigen Implementierungen Daten, die in den Topologiedaten 302 gespeichert sind, auch als ein Abschnitt der Fähigkeitsdaten 304 gespeichert sein und/oder umgekehrt. Als solche können derartige Daten, obwohl die verschiedenen durch den Netzwerk-Controller 112 genutzten Daten hierin als bestimmte diskrete Daten beschrieben sind, in anderen Ausführungsformen kombiniert oder aggregiert werden und/oder anderweitig Abschnitte eines einzelnen oder multipler Datensätze bilden, einschließlich sich überschneidender Kopien. Es sollte ferner verstanden werden, dass der Netzwerk-Controller 112 zusätzliche und/oder alternative Komponenten, Subkomponenten, Module, Submodule und/oder Geräte beinhalten kann, die sich üblicherweise in einem Netzwerkrechengerät finden, welche der Klarheit der Beschreibung halber in 3 nicht veranschaulicht sind.
  • Es sollte verstanden werden, dass sich die Steuerfunktionalität von einem Netzwerk-Controller zum anderen unterscheiden kann. Zum Beispiel können unterschiedliche Protokolle (z.B. OpenFlow, OVSDB usw.) durch unterschiedliche Netzwerk-Controller zum Kommunizieren mit anderen Netzwerkrechengeräten (z.B. Switches, Router usw.) des Rechenzentrums 106 und darüber hinaus verwendet werden. Es sollte ferner verstanden werden, dass zusätzliche Netzwerkmanagementdienste in Verbindung mit dem Netzwerk-Controller 112 eingesetzt und kommunikativ mit dem Netzwerk-Controller 112 verbunden werden können, um virtuelle Netzwerke zu erzeugen und zu verwalten (d.h. Netzwerkvirtualisierung), wie z.B. Neutron von OpenStack, der zum Bereitstellen von „Vernetzung als ein Dienst“ zwischen Schnittstellengeräten (z.B. virtuelle NICs), die durch andere OpenStack-Dienste verwaltet werden, welche dem Netzwerk-Controller 112 freigelegt werden können (z.B. unter Verwendung von OpenDaylight), verwendet werden kann. In derartigen Ausführungsformen kann der Netzwerk-Controller 112 eine Sammlung von Agenten, Treibern und/oder Plugins beinhalten, die zum Durchführen unterschiedlicher Netzwerkaufgaben genutzt werden können. Zu derartigen Netzwerkaufgaben können die Entdeckung (z.B. Topologie, Einstellungen, Fähigkeiten usw.) der verschiedenen Netzwerkrechengeräte, zu deren Management der Netzwerk-Controller 112 konfiguriert ist, sowie die Leistungsüberwachung (d.h. Nutzungsmetriken, Netzwerkstatistiken usw.) zählen.
  • Es sollte verstanden werden, dass der Netzwerk-Controller 112, im Gegensatz zu vorhandenen Internetprotokoll (IP) -Netzwerken, welche ein Gateway als den voreingestellten Router als Zugang zum Internet verwenden, in einigen Ausführungsformen (z.B. Rack-Scale-Architektur-Ausführungsformen, die einen SDN-Controller beinhalten) auf Switches zum Verbinden eines Netzwerks (d.h. der Rechenknoten 120 über die Switches 116) anstelle von Routern basieren können. Als solches gibt es im Netzwerk derartiger Ausführungsformen möglicherweise keinen physischen Gateway-Router, und der Netzwerk-Controller 112 kann stattdessen auf einem virtuellen Gateway basieren. In einem veranschaulichenden Beispiel können ein oder mehrere dynamische Host-Konfigurationsprotokoll (DHCP - Dynamic Host Configuration Protocol) -Agenten zum Bereitstellen von DHCP-Diensten an Tenant-Netzwerke verwendet werden, ein oder mehrere L3-Agenten können zum Bereitstellen von Schicht-3 und Netzwerkadressübersetzung (NAT - Network Address Translation) -Weiterleitung zum Erlangen von externem Zugriff für virtuelle Maschinen (VMs), die in den Rechenknoten 120 in Tenant-Netzwerken instanziiert sind, verwendet werden, und/oder ein oder mehrere dynamische Netzwerk-Konfiguration- und -Nutzungs-Plugins können zur Unterstützung von internem/externem Routing und DHCP-Diensten eingesetzt werden. Außerdem können in einigen Ausführungsformen Erweiterungen verwendet werden, um die Funktionalität des Netzwerk-Controllers 112 weiter zu verbessern (d.h. um zusätzliche Fähigkeiten zu unterstützen), wie z.B. ausführbare Algorithmen zum Erzielen analytischer Ergebnisse, neue Strategie-Orchestrierung im gesamten Netzwerk usw.
  • Das Anwendungsschnittstellen-Modul 310, welches als Hardware, Firmware, Software, virtualisierte Hardware, eine emulierte Architektur und/oder eine Kombination davon verkörpert sein kann, wie oben diskutiert, ist zum Bereitstellen einer Netzwerkabstraktionsschnittstelle zu Anwendungen und Managementsystemen oben im Controller-Stapel konfiguriert, wie sie z.B. über REST (Representational State Transfer) -APIs (z.B. Northbound-APIs) bereitgestellt werden kann. Mit anderen Worten, das Anwendungsschnittstellen-Modul 310 ist zum Erleichtern der Kommunikation zwischen einer bestimmten Komponente des Netzwerks und einer Komponente einer höheren Schicht konfiguriert, wodurch es Anwendungen und/oder Orchestrierungssystemen ermöglicht wird, mindestens einen Abschnitt des Netzwerks zu verwalten oder anderweitig zu steuern und Dienste davon anzufordern.
  • Das Steuerebenen-Managementmodul 320, welches als Hardware, Firmware, Software, virtualisierte Hardware, eine emulierte Architektur und/oder eine Kombination davon verkörpert sein kann, wie oben diskutiert, ist zum Verwalten der Steuerebenenlogik konfiguriert (z.B. Abbildung logisch zu physisch, Management gemeinsam genutzter physischer Ressourcen usw.). Dazu beinhaltet das veranschaulichende Steuerebenen-Managementmodul 320 ein Netzwerkdienst-Funktionsmanagementmodul 322, ein Dienst-Abstraktionsschicht-Managementmodul 324 und ein Netzwerk-Orchestrierungsmanagementmodul 326. Es sollte verstanden werden, dass jedes des Netzwerkdienst-Funktionsmanagementmoduls 322, des Dienst-Abstraktionsschicht-Managementmoduls 324 und des Netzwerk-Orchestrierungsmanagementmoduls 326 des Steuerebenen-Managementmodul 320 getrennt als Hardware, Firmware, Software, virtualisierte Hardware, eine emulierte Architektur und/oder eine Kombination davon verkörpert sein kann. Zum Beispiel kann das Netzwerkdienst-Funktionsmanagementmodul 322 als eine Hardwarekomponente verkörpert sein, während das Dienst-Abstraktionsschicht-Managementmodul 324 und/oder das Netzwerk-Orchestrierungsmanagementmodul 326 als eine virtualisierte Hardwarekomponente oder als eine andere Kombination aus Hardware, Firmware, Software, virtualisierter Hardware, einer emulierten Architektur und/oder einer Kombination davon verkörpert sein können.
  • Das Netzwerkdienst-Funktionsmanagementmodul 322 ist zum Verwalten von Netzwerkdienstfunktionen des Netzwerk-Controllers 112 konfiguriert. Dementsprechend ist das Netzwerkdienst-Funktionsmanagementmodul 322 zum Verwalten basierend auf Netzwerkdienstfunktionen (z.B. Entdeckung, Topologie-Management, Management statistischer Daten, Host-Tracking, Schicht-2-Switching, Gruppen-basiertes Strategiemanagement, Einsatz einer virtuellen Netzwerkfunktion (VNF - Virtual Network Function) der Dienstkette, Ereignisbenachrichtigung usw.) sowie Netzwerkdienstfunktionen Dritter, wie erforderlich, konfiguriert. Das Dienst-Abstraktionsschicht-Managementmodul 324 ist zum Verwalten der Dienst-Abstraktionsschicht (SAL - Service Abstraction Layer) konfiguriert. Dazu ist das Dienst-Abstraktionsschicht-Managementmodul 324 zum Verwalten von Plugins des Netzwerk-Controllers 112 sowie zum Durchführen von Fähigkeitsabstraktion/- ankündigung, Flussprogrammierung, Bestandsaufnahme usw. konfiguriert. Das Netzwerk-Orchestrierungsmanagementmodul 326 ist zum Verwalten programmierter automatisierter Verhaltensweisen in einem Netzwerk zum Koordinieren der erforderlichen Netzwerkressourcen (z.B. Hardware, Software usw.) zur Unterstützung bestimmter Arten von Anwendungen und Diensten konfiguriert, zu welchen z.B. durch Kommunikation, die vom Endpunktknoten 102 empfangen wird, Schnittstellen gebildet werden können. Mit anderen Worten, das Netzwerk-Orchestrierungsmanagementmodul 326 ist zum Überwachen des Netzwerks und Automatisieren der Konnektivität konfiguriert.
  • Das Datenebenenschnittstellen-Modul 330, welches als Hardware, Firmware, Software, virtualisierte Hardware, eine emulierte Architektur und/oder eine Kombination davon verkörpert sein kann, wie oben diskutiert, ist zum Kommunizieren mit physischen und virtuellen Netzwerkgeräten (z.B. physische und virtuelle Switches und Router), wie z.B. über REST-APIs (z.B. Southbound-APIs), zum Konfigurieren oder anderweitigen Definieren des Verhaltens der Netzwerkgeräte konfiguriert. Mit anderen Worten, das Datenebenenschnittstellen-Modul 330 ist zum Erleichtern der Kommunikation zwischen einer bestimmten Netzwerkkomponente und einer Komponente einer tieferen Schicht konfiguriert. Dementsprechend kann das Datenebenenschnittstellen-Modul 330 Netzwerk-Topologie entdecken, Netzwerkflüsse definieren und Anfragen implementieren, die ihm über das Anwendungsschnittstellen-Modul 310 weitergeleitet werden.
  • Das Rack-Scale-Controller-Modul 340, welches als Hardware, Firmware, Software, virtualisierte Hardware, eine emulierte Architektur und/oder eine Kombination davon verkörpert sein kann, wie oben diskutiert, ist zum Verwalten einer Rack-Scale-gepoolten Systemumgebung und insbesondere der Underlay-Netzwerke konfiguriert. In einigen Ausführungsformen kann das Rack-Scale-Controller-Modul 340 zum Nutzen von Plugins, Treibern und/oder Agenten, die im Netzwerk-Controller 112 untergebracht sind, zum Verwalten der Rack-Scale-gepoolten Systemumgebung konfiguriert sein, sodass der Netzwerk-Controller 112 verschiedene Aspekte des Netzwerks verwalten kann, einschließlich Netzwerkverkehr/-fluss-Engineering, Dienstqualitätsmanagement, Ressourcenkoordinierung, Ressourcenoptimierung usw. In derartigen Ausführungsformen können die genutzten Plugins, Treiber und/oder Agenten zur Schnittstellenbildung mit einem oder mehreren der anderen Module des Netzwerk-Controllers 112 (z.B. das Anwendungsschnittstellen-Modul 310, das Steuerebenen-Managementmodul 320 und/oder das Datenebenenschnittstellen-Modul 330) konfiguriert sein.
  • Zum Verwalten der Underlay-Netzwerke beinhaltet das veranschaulichende Rack-Scale-Controller-Modul 340 ein Topologieentdeckungsmodul 342, ein Fähigkeitserkennungsmodul 344, ein Leistungskriterien-Abbildungsmodul 346, ein Underlay-Konfigurationsmanagementmodul 348 und ein Underlay-Leistungsüberwachungsmodul 350. Es sollte verstanden werden, dass jedes des Topologieentdeckungsmoduls 342, des Fähigkeitserkennungsmoduls 344 und des Leistungskriterien-Abbildungsmoduls 346 des Rack-Scale-Controller-Moduls 340 getrennt als Hardware, Firmware, Software, virtualisierte Hardware, eine emulierte Architektur und/oder eine Kombination davon verkörpert sein kann. Zum Beispiel kann das Topologieentdeckungsmodul 342 als eine Hardwarekomponente verkörpert sein, während das Fähigkeitserkennungsmodul 344 und/oder ein anderes der Submodule als eine virtualisierte Hardwarekomponente oder als eine andere Kombination aus Hardware, Firmware, Software, virtualisierter Hardware, einer emulierten Architektur und/oder einer Kombination davon verkörpert sein können.
  • Das Topologieentdeckungsmodul 342 ist zum Entdecken der physischen und virtuellen Netzwerkressourcen, einschließlich der Rechenknoten 120 und anderer Elemente des Netzwerks, sowie einer Topologie der Netzwerkressourcen konfiguriert. Dazu ist das Topologieentdeckungsmodul 342 zur Schnittstellenbildung mit den betreffenden Switches des Netzwerks (z.B. die Switches 116) konfiguriert. In einigen Ausführungsformen können die Topologie-Informationen, die durch das Topologieentdeckungsmodul 342 entdeckt werden, in den Topologiedaten 302 gespeichert werden. Das Fähigkeitserkennungsmodul 344 ist zum Erkennen oder anderweitigen Entdecken von Fähigkeiten der Rechenknoten 120 und anderer Elemente des Netzwerks konfiguriert. Dazu ist das Fähigkeitserkennungsmodul 344 zum Erkennen physischer und virtueller Ressourcenfähigkeiten konfiguriert. In einigen Ausführungsformen können die Fähigkeitsinformationen, die durch das Fähigkeitserkennungsmodul 344 erkannt werden, in den Fähigkeitsdaten 304 gespeichert werden.
  • Das Leistungskriterien-Abbildungsmodul 346 ist zum Definieren von Netzwerkleistungskriterien basierend auf einer Eingabe von einem Endnutzer und Abbilden der Leistungskriterien auf physischen Eigenschaften der Netzwerkkomponenten (z.B. die Switch-Ports 118 der Switches 116, die Rechenknoten 120 usw.) konfiguriert. Zum Beispiel kann das Leistungskriterien-Abbildungsmodul 346 zum Verwenden virtueller Hardware-Schablonen (z.B. Flavors bei OpenStack) konfiguriert sein, welche Ressourcen definieren, die zugeordnet werden sollen, wie z.B. eine Größe des RAM, der Platte, die Zahl der Prozesskerne usw. In einigen Ausführungsformen kann das Leistungskriterien-Abbildungsmodul 346 zum Abrufen von Informationen, die zum Definieren der Leistungskriterien nutzbar sind, unter Verwendung von Out-of-Band-Kommunikationskanälen konfiguriert sein. In einigen Ausführungsformen können die Informationen, die zum Definieren der Leistungskriterien nutzbar sind, und/oder die Leistungskriterien, die durch das Leistungskriterien-Abbildungsmodul 346 definiert werden, in den Leistungsdaten 306 gespeichert werden. Außerdem können die Leistungskriterien in einigen Ausführungsformen aus einer Strategie bestimmt werden, wie z.B. einer Dienstgütevereinbarung (SLA - Service Level Agreement). In derartigen Ausführungsformen kann die Strategie, oder darauf bezogene Informationen, in den Strategiedaten 308 gespeichert werden.
  • Das Underlay-Konfigurationsmanagementmodul 348 ist zum dynamischen Erzeugen von Underlay-Netzwerken konfiguriert (siehe z.B. die Verfahren 500 und 600 von 5 bzw. 6). Dementsprechend ist das Underlay-Konfigurationsmanagementmodul 348 zum Zugreifen auf Hardware-Steuerungen (z.B. über Hardware-APIs) und/oder Ausnutzen von Software-APIs zum dynamischen Erzeugen/Modifizieren der Underlay-Netzwerke konfiguriert, wie z.B. über das Netzwerk-Orchestrierungsmanagementmodul 326 auf sie zugegriffen werden kann. Zum Beispiel kann das Underlay-Konfigurationsmanagementmodul 348 zum Verwalten der VLAN-Schnittstellenkonfiguration und/oder Switch-Ports der Switches (z.B. die Switch-Ports 118 der Switches 116 von 1) konfiguriert sein, wie dies zum dynamischen Erzeugen/Modifizieren der Underlay-Netzwerke erforderlich ist.
  • Das Underlay-Leistungsüberwachungsmodul 350 ist zum Überwachen einer Leistung der Underlay-Netzwerke zum Bestimmen von Leistungsmetriken der Underlay-Netzwerke konfiguriert. Dazu kann das Underlay-Leistungsüberwachungsmodul 350 zum Überwachen der physischen und/oder virtuellen Netzwerkschnittstellen der Switches 116 und der Rechenknoten 120 konfiguriert sein. In einigen Ausführungsformen kann das Underlay-Leistungsüberwachungsmodul 350 zum Überwachen von Leistungsmetriken der Underlay-Netzwerke unter Verwendung von Out-of-Band-Kommunikationskanälen konfiguriert sein. Die Leistungsmetriken können jegliche Daten beinhalten, die ein Leistungslevel des Underlay-Netzwerks angeben, wie z.B. Nutzungsstatistiken, Dienstqualität-Telemetriedaten usw. In einigen Ausführungsformen können die Leistungsmetriken, die durch das Underlay-Leistungsüberwachungsmodul 350 erfasst werden, in den Leistungsdaten 306 gespeichert werden.
  • Nun Bezug nehmend auf 4, kann der Netzwerk-Controller 112 im Einsatz ein Verfahren 400 zur Leistungsüberwachung einer Cloud-Computing-Infrastruktur ausführen. Das Verfahren 400 beginnt mit Block 402, in welchem der Netzwerk-Controller 112 bestimmt, ob eine Leistungsüberwachung (z.B. Dienstqualitätsüberwachung) der Netzwerkressourcen, zu deren Management der Netzwerk-Controller 112 konfiguriert ist, zu initiieren ist. Wenn dem so ist, fährt das Verfahren 400 mit Block 404 fort, in welchem der Netzwerk-Controller 112 die Topologie der zugrundeliegenden Netzwerkinfrastruktur entdeckt. Zum Beispiel entdeckt der Netzwerk-Controller 112 in Block 406 die Topologie der Switches (z.B. die Switches 116) der zugrundeliegenden Netzwerkinfrastruktur. Außerdem, oder alternativ dazu, entdeckt der Netzwerk-Controller 112 in Block 408 die Topologie der Rechenknoten (z.B. die Rechenknoten 120) der zugrundeliegenden Netzwerkinfrastruktur.
  • In Block 410 führt der Netzwerk-Controller 112 eine Fähigkeitsentdeckung der Ressourcen (z.B. physisch und virtuell) der zugrundeliegenden Netzwerkinfrastruktur durch. Zum Beispiel entdeckt der Netzwerk-Controller 112 in Block 412 Fähigkeiten der Switches (z.B. die Switches 116). Außerdem, oder alternativ dazu, entdeckt der Netzwerk-Controller 112 in Block 414 Fähigkeiten der Rechenknoten (z.B. die Rechenknoten 120). In Block 416 überwacht der Netzwerk-Controller 112 Netzwerkleistungsmetriken der Ressourcen (z.B. physisch und virtuell) der zugrundeliegenden Netzwerkinfrastruktur. Dazu überwacht der Netzwerk-Controller 112 in Block 418 die Netzwerkleistungsmetriken basierend auf einem Satz von Netzwerkleistungskriterien. In einigen Ausführungsformen können die Netzwerkleistungskriterien durch einen Endnutzer (z.B. ein Administrator des Netzwerks, ein Nutzer einer Cloud-basierten Anwendung, auf die von einem der Endpunktknoten 102 zugegriffen wird, usw.) eingestellt werden, wie dies z.B. in Übereinstimmung mit einer SLA durchgeführt wird. Zum Beispiel überwacht der Netzwerk-Controller 112 in Block 420 die Switch-Ports der Switches (z.B. die Switch-Ports 118 der Switches 116) der zugrundeliegenden Netzwerkinfrastruktur. Außerdem, oder alternativ dazu, überwacht der Netzwerk-Controller 112 in Block 422 physische (z.B. NICs) und/oder virtuelle (VLAN) Schnittstellen der Rechenknoten (z.B. die Rechenknoten 120) der zugrundeliegenden Netzwerkinfrastruktur.
  • In Block 424 bestimmt der Netzwerk-Controller 112, ob die Leistungsüberwachung der Cloud-Computing-Infrastruktur fortgesetzt werden soll. Wenn dem so ist, kehrt das Verfahren 400 zu Block 416 zurück, in welchem der Netzwerk-Controller 112 mit dem Überwachen von Netzwerkleistungsmetriken der Ressourcen (z.B. physisch und virtuell) der zugrundeliegenden Netzwerkinfrastruktur fortfährt. Ansonsten kehrt, wenn der Netzwerk-Controller 112 bestimmt, die Leistungsüberwachung der Cloud-Computing-Infrastruktur nicht fortzusetzen, das Verfahren 400 zu Block 402 zurück, in welchem der Netzwerk-Controller 112 wieder bestimmt, ob die Leistungsüberwachung (z.B. Dienstqualitätsüberwachung) der Netzwerkressourcen, zu deren Management der Netzwerk-Controller 112 konfiguriert ist, initiiert werden soll.
  • Nun Bezug nehmend auf 5, kann der Netzwerk-Controller 112 im Einsatz ein Verfahren 500 zur Erzeugung eines Underlay-Netzwerks in einer Cloud-Computing-Infrastruktur ausführen. Das Verfahren 500 beginnt mit Block 502, in welchem der Netzwerk-Controller 112 bestimmt, ob ein neues Tenant-Netzwerk in der Cloud-Computing-Infrastruktur erzeugt werden soll. Zum Beispiel kann der Netzwerk-Controller 112 eine Tenant-Netzwerk-Erzeugungsanfrage von einem Cloud-Netzwerk-Betriebssystem (z.B. in der Cloud-Netzwerkschicht) empfangen, dass ein virtuelles Netzwerk erzeugt werden soll. Wenn dem so ist, fährt das Verfahren 500 mit Block 504 fort, in welchem der Netzwerk-Controller 112 Netzwerkkriterien für die Erzeugung des neuen Tenant-Netzwerks identifiziert. Die Netzwerkkriterien können jegliche Daten sein, die zum Identifizieren potentieller Ressourcen des physischen Netzwerks nutzbar sind, welche zum Erzeugen des neuen Tenant-Netzwerks verwendet werden können. Zum Beispiel identifiziert der Netzwerk-Controller 112 in Block 506 jegliche Leistungskriterien, die zur Unterstützung des neuen Tenant-Netzwerks erforderlich sind, wie z.B. Nutzungsschwellen, Dienstqualitätsanforderungen usw. Außerdem identifiziert der Netzwerk-Controller 112 in Block 508 jegliche Ressourcenkriterien, die zur Unterstützung des neuen Tenant-Netzwerks erforderlich sind, wie z.B. Rechenverfügbarkeit, Arbeitsspeicherverfügbarkeit, Datenspeicherverfügbarkeit usw.
  • In Block 510 identifiziert der Netzwerk-Controller 112 einen oder mehrere Zielrechenknoten (z.B. einen oder mehrere der Rechenknoten 120 von 1), in welchen eine oder mehrere VMs für das neue Tenant-Netzwerk instanziiert werden sollen. Außerdem identifiziert der Netzwerk-Controller 112 in Block 512 einen oder mehrere Switches (z.B. einen oder mehrere der Switches 116), die mit dem einen oder den mehreren Zielrechenknoten, die in Block 510 identifiziert wurden, assoziiert sind. In Block 514 stellt der Netzwerk-Controller 112 ein Underlay-Netzwerk zur Unterstützung des neuen Tenant-Netzwerks bereit. Dazu initialisiert der Netzwerk-Controller 112 in Block 516 eine oder mehrere VLAN-Schnittstellen über physische Netzwerkschnittstellen der entsprechenden Zielrechenknoten zum Konfigurieren eines VLAN, das mit dem neuen Tenant-Netzwerk assoziiert werden soll.
  • In Block 518 bestimmt der Netzwerk-Controller 112, ob das Underlay-Netzwerk erfolgreich erzeugt wurde. Wenn dem so ist, fährt das Verfahren 500 mit Block 520 fort, in welchem der Netzwerk-Controller 112 Informationen hinsichtlich des neuen Tenant-Netzwerks an das Cloud-Betriebssystem überträgt, von welchem in Block 502 die Tenant-Netzwerk-Erzeugungsanfrage empfangen wurde. Zum Beispiel überträgt der Netzwerk-Controller 112 in Block 522 Informationen an das Cloud-Betriebssystem, die zum Erzeugen eines in der Cloud sichtbaren Overlay-Netzwerks (d.h. das virtuelle Netzwerk), das mit dem in Block 518 erzeugten Underlay-Netzwerk assoziiert ist, nutzbar sind. Dazu können die Informationen in einigen Ausführungsformen durch ein OVSDB (Open vSwitch Database Management Protocol) -Plugin oder in anderen Ausführungsformen durch jegliches äquivalentes physisch-zu-virtuell Brücken-Plugin an das virtuelle Netzwerk übertragen werden. In Block 524 nimmt der Netzwerk-Controller 112 die Instanziierung/Bereitstellung der VM-Instanzen des neuen Tenant-Netzwerks wieder auf. In Block 526 schließt der Netzwerk-Controller 112 die instanziierten VM-Instanzen an das in der Cloud sichtbare Overlay-Netzwerk, das durch das Cloud-OS erzeugt wurde (d.h. basierend auf den in Block 520 übertragenen Informationen), an.
  • Nun Bezug nehmend auf 6, kann der Netzwerk-Controller 112 im Einsatz ein Verfahren 600 zur Konfiguration eines Underlay-Netzwerks, das in einer Cloud-Computing-Infrastruktur erzeugt wurde, ausführen. Das Verfahren 600 beginnt mit Block 602, in welchem der Netzwerk-Controller 112 bestimmt, ob eine VM-Instanz-Erzeugung für ein bestehendes Underlay-Netzwerk initiiert wurde (d.h. zur Erzeugung in einem Host-Rechenknoten 120). Wenn dem so ist, fährt das Verfahren 600 mit Block 604 fort, in welchem der Netzwerk-Controller 112 vorliegende Netzwerkleistungsmetriken für das Underlay-Netzwerk identifiziert. Dazu identifiziert der Netzwerk-Controller 112 in Block 606 die Netzwerkleistungsmetriken basierend auf einem Satz von Netzwerkleistungskriterien (z.B. ein Satz von Dienstqualitätsanforderungen, wie durch eine SLA definiert oder durch eine Anwendung/einen Dienst angewiesen).
  • In Block 608 aktualisiert der Netzwerk-Controller 112 die Netzwerkleistungskriterien. Dazu aktualisiert der Netzwerk-Controller 112 in Block 610 die Netzwerkleistungskriterien basierend auf einem oder mehreren Instanziierungsparametern für die zu erzeugende VM-Instanz. In Block 612 bildet der Netzwerk-Controller 112 die Netzwerkleistungskriterien, die in Block 608 aktualisiert wurden, auf vorliegende Einstellungen der Rechenknoten 120 und entsprechender Switches 116 des vorliegenden Underlay-Netzwerks ab. In Block 614 vergleicht der Netzwerk-Controller 112 die vorliegenden Netzwerkleistungsmetriken, die in Block 604 identifiziert wurden, mit den aktualisierten Netzwerkleistungskriterien.
  • In Block 616 bestimmt der Netzwerk-Controller 112, ob das vorliegende Underlay-Netzwerk die aktualisierten Netzwerkleistungskriterien unterstützen kann, basierend auf dem Vergleich in Block 614. Wenn dem nicht so ist, zweigt das Verfahren 600 zu Block 618 ab, in welchem der Netzwerk-Controller 112 die Erzeugung eines neuen Underlay-Netzwerks initiiert (siehe z.B. das Verfahren 500 von 5); ansonsten zweigt das Verfahren zu Block 620 ab. In Block 620 identifiziert der Netzwerk-Controller 112 einen Zielrechenknoten, in welchem die VM instanziiert werden soll, wie z.B. basierend auf dem in Block 614 durchgeführten Vergleich bestimmt werden kann. In Block 622 instanziiert der Netzwerk-Controller 112 die VM in dem Zielrechenknoten, der in Block 620 identifiziert wurde. In Block 624 schließt der Netzwerk-Controller 112 die VM, die in Block 622 in dem Zielrechenknoten instanziiert wurde, an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist, an.
  • Es sollte verstanden werden, dass ein Cloud-Netzwerkdienst, wie z.B. Neutron, die Underlay-Netzwerk-Informationen in dem Netzwerk-Controller 112 und/oder den Rechenknoten 120 aktualisieren kann sowie ein virtuelles Netzwerk erzeugen kann, das freigelegt werden kann, während die Underlay-Netzwerkinstanz erzeugt wird. Es sollte ferner verstanden werden, dass in einigen Ausführungsformen ein oder mehrere der Verfahren 400, 500 und 600 als verschiedene Anweisungen verkörpert sein können, die auf computerlesbaren Medien gespeichert sind, welche durch einen Prozessor (z.B. der Prozessor 132), die Kommunikationsschaltungen 140 und/oder andere Komponenten des Netzwerk-Controllers 112 ausgeführt werden können, um den Netzwerk-Controller 112 zum Durchführen der Verfahren 400, 500 und 600 zu veranlassen. Die computerlesbaren Medien können als jegliche Art von Medien verkörpert sein, die durch den Netzwerk-Controller 112 gelesen werden können, einschließlich, jedoch nicht darauf beschränkt, der Arbeitsspeicher 136, das Datenspeichergerät 138, andere/r Arbeitsspeicher oder Datenspeichergeräte des Netzwerk-Controllers 112, tragbare Medien, die durch ein Peripheriegerät des Netzwerk-Controllers 112 gelesen werden können, und/oder andere Medien.
  • BEISPIELE
  • Veranschaulichende Beispiele der hierin offenbarten Technologien sind unten bereitgestellt. Eine Ausführungsform der Technologien kann jegliche/s eine oder mehrere und jegliche Kombination der unten beschriebenen Beispiele beinhalten.
  • Beispiel 1 beinhaltet einen Netzwerk-Controller für den Einsatz dynamischer Underlay-Netzwerke in einer Cloud-Computing-Infrastruktur, wobei der Netzwerk-Controller einen oder mehrere Prozessoren; und ein oder mehrere Arbeitsspeichergeräte mit darin gespeicherten mehreren Anweisungen, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, den Netzwerk-Controller zum Empfangen, von einem Cloud-Betriebssystem der Cloud-Computing-Infrastruktur, einer Tenant-Netzwerk-Erzeugungsanfrage, die angibt, das ein Tenant-Netzwerk in der Cloud-Computing-Infrastruktur für einen neuen Tenant der Cloud-Computing-Infrastruktur erzeugt werden soll; Identifizieren von Netzwerkkriterien für das Tenant-Netzwerk basierend auf der empfangenen Tenant-Netzwerk-Erzeugungsanfrage; Identifizieren physischer Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des Tenant-Netzwerks nutzbar sind, basierend auf den identifizierten Netzwerkkriterien; Bereitstellen eines Underlay-Netzwerks zum Unterstützen des Tenant-Netzwerks basierend auf den identifizierten physischen Ressourcen; und Übertragen von Informationen des Underlay-Netzwerks an das Cloud-Betriebssystem, wobei die Informationen des Underlay-Netzwerks zum Erzeugen eines in der Cloud sichtbaren Overlay-Netzwerks, das mit dem Underlay-Netzwerk assoziiert ist, nutzbar sind, veranlassen, umfasst.
  • Beispiel 2 beinhaltet den Gegenstand von Beispiel 1, wobei das Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur (i) das Identifizieren eines oder mehrerer Zielrechenknoten für die Instanziierung einer oder mehrerer virtueller Maschinen, die mit dem Tenant-Netzwerk assoziiert werden sollen, und (ii) das Identifizieren eines oder mehrerer Switches, die den einen oder die mehreren identifizierten Zielrechenknoten mit der Cloud-Computing-Infrastruktur verbinden, umfasst.
  • Beispiel 3 beinhaltet den Gegenstand von einem der Beispiele 1 und 2, wobei das Bereitstellen des Underlay-Netzwerks (i) das Initialisieren einer virtuellen lokalen Netzwerk (VLAN) -Schnittstelle über eine physische Netzwerkschnittstelle des einen oder der mehreren identifizierten Zielrechenknoten und (ii) das Konfigurieren von Switch-Ports des einen oder der mehreren Switches zum Konfigurieren eines VLAN zwischen dem einen oder den mehreren Switches umfasst.
  • Beispiel 4 beinhaltet den Gegenstand von einem der Beispiele 1-3, wobei das Bereitstellen des Underlay-Netzwerks das Aufrufen von Rack-Scale-Architektur-konformen Anwendungsprogrammierungsschnittstellen-Befehlen an den einen oder die mehreren Switches umfasst.
  • Beispiel 5 beinhaltet den Gegenstand von einem der Beispiele 1-4, wobei das Empfangen der Tenant-Netzwerk-Erzeugungsanfrage das Empfangen eines Hinweises, dass eine oder mehrere virtuelle Maschinen instanziiert werden sollen, um das Tenant-Netzwerk zu unterstützen, umfasst, und wobei die mehreren Anweisungen den Netzwerk-Controller ferner zum Instanziieren der einen oder der mehreren virtuellen Maschinen an einem oder mehreren Zielrechenknoten der Cloud-Computing-Infrastruktur; und zum Anschließen der einen oder der mehreren instanziierten virtuellen Maschinen an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist, veranlassen.
  • Beispiel 6 beinhaltet den Gegenstand von einem der Beispiele 1-5, wobei das Identifizieren der Netzwerkkriterien, die zum Erzeugen des Tenant-Netzwerks nutzbar sind, das Identifizieren mindestens eines aus einem Leistungskriterium oder einem Ressourcenkriterium umfasst.
  • Beispiel 7 beinhaltet den Gegenstand von einem der Beispiele 1-6, wobei das Leistungskriterium mindestens eines aus einer Nutzungsschwelle oder einer Dienstqualitätsanforderung beinhaltet.
  • Beispiel 8 beinhaltet den Gegenstand von einem der Beispiele 1-7, wobei das Ressourcenkriterium mindestens eines aus einer Rechenverfügbarkeit, Arbeitsspeicherverfügbarkeit oder Datenspeicherverfügbarkeit beinhaltet.
  • Beispiel 9 beinhaltet den Gegenstand von einem der Beispiele 1-8, wobei die mehreren Anweisungen den Netzwerk-Controller ferner veranlassen, die physischen Ressourcen der Cloud-Computing-Infrastruktur zu entdecken, wobei das Entdecken der physischen Ressourcen das Entdecken mindestens eines aus mehreren Switches der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Switches, mehreren Rechenknoten der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Rechenknoten oder einer Topologie der physischen Ressourcen umfasst.
  • Beispiel 10 beinhaltet den Gegenstand von einem der Beispiele 1-9, wobei die mehreren Anweisungen den Netzwerk-Controller ferner veranlassen, die physischen Ressourcen basierend auf den identifizierten Netzwerkkriterien zu überwachen.
  • Beispiel 11 beinhaltet den Gegenstand von einem der Beispiele 1-10, wobei das Überwachen der physischen Ressourcen das Überwachen mindestens eines aus einer oder mehreren physischen Netzwerkschnittstellen eines oder mehrerer der mehreren Rechenknoten, einer oder mehreren virtuellen Netzwerkschnittstellen eines oder mehrerer der mehreren Rechenknoten oder einem oder mehreren Switch-Ports eines oder mehrerer der mehreren Switches umfasst.
  • Beispiel 12 beinhaltet den Gegenstand von einem der Beispiele 1-11, wobei das Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des Tenant-Netzwerks nutzbar sind, ferner auf einem Ergebnis der überwachten physischen Ressourcen basiert.
  • Beispiel 13 beinhaltet den Gegenstand von einem der Beispiele 1-12, wobei die mehreren Anweisungen den Netzwerk-Controller ferner zum Identifizieren vorliegender Netzwerkleistungsmetriken für das Underlay-Netzwerk basierend auf einem Ergebnis der überwachten physischen Ressourcen veranlassen.
  • Beispiel 14 beinhaltet den Gegenstand von einem der Beispiele 1-13, wobei die mehreren Anweisungen den Netzwerk-Controller ferner (i) zum Empfangen eines Hinweises auf eine virtuelle Maschineninstanz, die in dem Underlay-Netzwerk instanziiert werden soll, (ii) zum Identifizieren einer oder mehrerer vorliegender Netzwerkleistungsmetriken des Underlay-Netzwerks, (iii) zum Aktualisieren von Netzwerkleistungskriterien, die mit der Überwachung von Leistungslevels des Underlay-Netzwerks assoziiert sind, (iv) zum Vergleichen der einen oder der mehreren vorliegenden Netzwerkleistungsmetriken und der aktualisierten Netzwerkleistungskriterien und (v) zum Bestimmen, ob das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann, veranlassen.
  • Beispiel 15 beinhaltet den Gegenstand von einem der Beispiele 1-14, wobei die mehreren Anweisungen den Netzwerk-Controller ferner zum Initiieren, als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz nicht unterstützen kann, der Erzeugung eines neuen Underlay-Netzwerks, das die virtuelle Maschineninstanz, die instanziiert werden soll, beinhaltet, veranlassen.
  • Beispiel 16 beinhaltet den Gegenstand von einem der Beispiele 1-15, wobei die mehreren Anweisungen den Netzwerk-Controller ferner (i) zum Identifizieren, als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann, eines Zielrechenknotens, in welchem die virtuelle Maschineninstanz instanziiert werden soll, (ii) zum Instanziieren der virtuellen Maschineninstanz in dem identifizierten Zielrechenknoten und (iii) zum Anschließen der instanziierten virtuellen Maschineninstanz an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist, veranlassen.
  • Beispiel 17 beinhaltet einen Netzwerk-Controller für den Einsatz dynamischer Underlay-Netzwerke in einer Cloud-Computing-Infrastruktur, wobei der Netzwerk-Controller eine Anwendungsschnittstellen-Schaltung zum Empfangen einer Tenant-Netzwerk-Erzeugungsanfrage von einem Cloud-Betriebssystem der Cloud-Computing-Infrastruktur, wobei die Tenant-Netzwerk-Erzeugungsanfrage angibt, dass ein Tenant-Netzwerk in der Cloud-Computing-Infrastruktur für einen neuen Tenant der Cloud-Computing-Infrastruktur erzeugt werden soll; und eine Rack-Scale-Controller-Schaltung (i) zum Identifizieren von Netzwerkkriterien für das Tenant-Netzwerk basierend auf der empfangenen Tenant-Netzwerk-Erzeugungsanfrage, (ii) zum Identifizieren physischer Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des Tenant-Netzwerks nutzbar sind, basierend auf den identifizierten Netzwerkkriterien, (iii) zum Bereitstellen eines Underlay-Netzwerks zum Unterstützen des Tenant-Netzwerks basierend auf den identifizierten physischen Ressourcen und (iv) zum Übertragen von Informationen des Underlay-Netzwerks an das Cloud-Betriebssystem, wobei die Informationen des Underlay-Netzwerks zum Erzeugen eines in der Cloud sichtbaren Overlay-Netzwerks, das mit dem Underlay-Netzwerk assoziiert ist, nutzbar sind, umfasst.
  • Beispiel 18 beinhaltet den Gegenstand of Beispiel 17, wobei das Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur (i) das Identifizieren eines oder mehrerer Zielrechenknoten für die Instanziierung einer oder mehrerer virtueller Maschinen, die mit dem Tenant-Netzwerk assoziiert werden sollen, und (ii) das Identifizieren eines oder mehrerer Switches, die den einen oder die mehreren identifizierten Zielrechenknoten mit der Cloud-Computing-Infrastruktur verbinden, umfasst.
  • Beispiel 19 beinhaltet den Gegenstand von einem der Beispiele 17 und 18, wobei das Bereitstellen des Underlay-Netzwerks (i) das Initialisieren einer virtuellen lokalen Netzwerk (VLAN) -Schnittstelle über eine physische Netzwerkschnittstelle des einen oder der mehreren identifizierten Zielrechenknoten und (ii) das Konfigurieren von Switch-Ports des einen oder der mehreren Switches zum Konfigurieren eines VLAN zwischen dem einen oder den mehreren Switches umfasst.
  • Beispiel 20 beinhaltet den Gegenstand von einem der Beispiele 17-19, wobei das Bereitstellen des Underlay-Netzwerks das Aufrufen von Rack-Scale-Architektur-konformen Anwendungsprogrammierungsschnittstellen-Befehlen an den einen oder die mehreren Switches umfasst.
  • Beispiel 21 beinhaltet den Gegenstand von einem der Beispiele 17-20, wobei das Empfangen der Tenant-Netzwerk-Erzeugungsanfrage das Empfangen eines Hinweises, dass eine oder mehrere virtuelle Maschinen zum Unterstützen des Tenant-Netzwerks instanziiert werden sollen, umfasst, und welcher ferner eine Datenebenenschnittstellen-Schaltung zum Instanziieren der einen oder der mehreren virtuellen Maschinen an einem oder mehreren Zielrechenknoten der Cloud-Computing-Infrastruktur umfasst, wobei die Rack-Scale-Controller-Schaltung ferner dem Anschließen der einen oder der mehreren instanziierten virtuellen Maschinen an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist, dient.
  • Beispiel 22 beinhaltet den Gegenstand von einem der Beispiele 17-21, wobei das Identifizieren der Netzwerkkriterien, die zum Erzeugen des Tenant-Netzwerks nutzbar sind, das Identifizieren mindestens eines aus einem Leistungskriterium oder einem Ressourcenkriterium umfasst.
  • Beispiel 23 beinhaltet den Gegenstand von einem der Beispiele 17-22, wobei das Leistungskriterium mindestens eines aus einer Nutzungsschwelle oder einer Dienstqualitätsanforderung beinhaltet.
  • Beispiel 24 beinhaltet den Gegenstand von einem der Beispiele 17-23, wobei das Ressourcenkriterium mindestens eines aus einer Rechenverfügbarkeit, einer Arbeitsspeicherverfügbarkeit oder einer Datenspeicherverfügbarkeit beinhaltet.
  • Beispiel 25 beinhaltet den Gegenstand von einem der Beispiele 17-24, wobei die Rack-Scale-Controller-Schaltung ferner dem Entdecken der physischen Ressourcen der Cloud-Computing-Infrastruktur dient, wobei das Entdecken der physischen Ressourcen das Entdecken mindestens eines aus mehreren Switches der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Switches, mehreren Rechenknoten der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Rechenknoten oder einer Topologie der physischen Ressourcen umfasst.
  • Beispiel 26 beinhaltet den Gegenstand von einem der Beispiele 17-25, wobei die Rack-Scale-Controller-Schaltung ferner dem Überwachen der physischen Ressourcen basierend auf den identifizierten Netzwerkkriterien dient.
  • Beispiel 27 beinhaltet den Gegenstand von einem der Beispiele 17-26, wobei das Überwachen der physischen Ressourcen das Überwachen mindestens einer der einen oder der mehreren physischen Netzwerkschnittstellen von einem oder mehreren der mehreren Rechenknoten, einer oder mehrerer virtueller Netzwerkschnittstellen von einem oder mehreren der mehreren Rechenknoten oder eines oder mehrerer Switch-Ports von einem oder mehreren der mehreren Switches umfasst.
  • Beispiel 28 beinhaltet den Gegenstand von einem der Beispiele 17-27, wobei das Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des Tenant-Netzwerks nutzbar sind, ferner auf einem Ergebnis der überwachten physischen Ressourcen basiert.
  • Beispiel 29 beinhaltet den Gegenstand von einem der Beispiele 17-28, wobei die Rack-Scale-Controller-Schaltung ferner dem Identifizieren vorliegender Netzwerkleistungsmetriken für das Underlay-Netzwerk basierend auf einem Ergebnis der überwachten physischen Ressourcen dient.
  • Beispiel 30 beinhaltet den Gegenstand von einem der Beispiele 17-29, wobei die Rack-Scale-Controller-Schaltung ferner (i) dem Empfangen eines Hinweises auf eine virtuelle Maschineninstanz, die in dem Underlay-Netzwerk instanziiert werden soll, (ii) dem Identifizieren einer oder mehrerer vorliegender Netzwerkleistungsmetriken des Underlay-Netzwerks, (iii) dem Aktualisieren von Netzwerkleistungskriterien, die mit der Überwachung von Leistungslevels des Underlay-Netzwerks assoziiert sind, (iv) dem Vergleichen der einen oder mehreren vorliegenden Netzwerkleistungsmetriken und der aktualisierten Netzwerkleistungskriterien und (v) dem Bestimmen, ob das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann, dient.
  • Beispiel 31 beinhaltet den Gegenstand von einem der Beispiele 17-30, wobei die Rack-Scale-Controller-Schaltung ferner dem Initiieren, als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz nicht unterstützen kann, der Erzeugung eines neuen Underlay-Netzwerks, das die virtuelle Maschineninstanz, die instanziiert werden soll, beinhaltet, dient.
  • Beispiel 32 beinhaltet den Gegenstand von einem der Beispiele 17-31, wobei die Rack-Scale-Controller-Schaltung ferner (i) dem Identifizieren, als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann, eines Zielrechenknotens, in welchem die virtuelle Maschineninstanz instanziiert werden soll, (ii) dem Instanziieren der virtuellen Maschineninstanz in dem identifizierten Zielrechenknoten und (iii) dem Anschließen der instanziierten virtuellen Maschineninstanz an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist, dient.
  • Beispiel 33 beinhaltet ein Verfahren für den Einsatz dynamischer Underlay-Netzwerke in einer Cloud-Computing-Infrastruktur, wobei das Verfahren das Empfangen, durch einen Netzwerk-Controller in der Cloud-Computing-Infrastruktur, einer Tenant-Netzwerk-Erzeugungsanfrage von einem Cloud-Betriebssystem der Cloud-Computing-Infrastruktur, wobei die Tenant-Netzwerk-Erzeugungsanfrage den Netzwerk-Controller darauf hinweist, ein neues Tenant-Netzwerk in der Cloud-Computing-Infrastruktur zu erzeugen; das Identifizieren, durch den Netzwerk-Controller, von Netzwerkkriterien für das neue Tenant-Netzwerk basierend auf der empfangenen Tenant-Netzwerk-Erzeugungsanfrage; das Identifizieren, durch den Netzwerk-Controller, physischer Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des neuen Tenant-Netzwerks nutzbar sind, basierend auf den identifizierten Netzwerkkriterien; das Bereitstellen, durch den Netzwerk-Controller, eines Underlay-Netzwerks zum Unterstützen des neuen Tenant-Netzwerks basierend auf den identifizierten physischen Ressourcen; und das Übertragen, durch den Netzwerk-Controller, von Informationen des Underlay-Netzwerks an das Cloud-Betriebssystem, wobei die Informationen des Underlay-Netzwerks zum Erzeugen eines in der Cloud sichtbaren Overlay-Netzwerks, das mit dem Underlay-Netzwerk assoziiert ist, nutzbar sind, umfasst.
  • Beispiel 34 beinhaltet den Gegenstand of Beispiel 33, wobei das Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur (i) das Identifizieren eines oder mehrerer Zielrechenknoten für die Instanziierung einer oder mehrerer virtueller Maschinen, die mit dem neuen Tenant-Netzwerk assoziiert werden sollen, und (ii) das Identifizieren eines oder mehrerer Switches, die den einen oder die mehreren identifizierten Zielrechenknoten mit der Cloud-Computing-Infrastruktur verbinden, umfasst.
  • Beispiel 35 beinhaltet den Gegenstand von einem der Beispiele 33 und 34, wobei das Bereitstellen des Underlay-Netzwerks (i) das Initialisieren einer virtuellen lokalen Netzwerk (VLAN) -Schnittstelle über eine physische Netzwerkschnittstelle des einen oder der mehreren identifizierten Zielrechenknoten und (ii) das Konfigurieren von Switch-Ports des einen oder der mehreren Switches zum Konfigurieren eines VLAN zwischen dem einen oder den mehreren Switches umfasst.
  • Beispiel 36 beinhaltet den Gegenstand von einem der Beispiele 33-35, wobei das Bereitstellen des Underlay-Netzwerks das Aufrufen Rack-Scale-Architektur-konformer Anwendungsprogrammierungsschnittstellen-Befehle an den einen oder die mehreren Switches umfasst.
  • Beispiel 37 beinhaltet den Gegenstand von einem der Beispiele 33-36, wobei das Empfangen der Tenant-Netzwerk-Erzeugungsanfrage das Empfangen eines Hinweises, dass eine oder mehrere virtuelle Maschinen zum Unterstützen des neuen Tenant-Netzwerks instanziiert werden sollen, umfasst, und umfasst ferner das Instanziieren, durch den Netzwerk-Controller, der einen oder der mehreren virtuellen Maschinen in einem oder mehreren Zielrechenknoten der Cloud-Computing-Infrastruktur; und das Anschließen, durch den Netzwerk-Controller, der einen oder der mehreren instanziierten virtuellen Maschinen an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist.
  • Beispiel 38 beinhaltet den Gegenstand von einem der Beispiele 33-37, wobei das Identifizieren der Netzwerkkriterien, die zum Erzeugen des neuen Tenant-Netzwerks nutzbar sind, das Identifizieren mindestens eines aus einem Leistungskriterium oder einem Ressourcenkriterium umfasst.
  • Beispiel 39 beinhaltet den Gegenstand von einem der Beispiele 33-38, wobei das Identifizieren des Leistungskriteriums das Identifizieren mindestens eines aus einer Nutzungsschwelle oder einer Dienstqualitätsanforderung umfasst.
  • Beispiel 40 beinhaltet den Gegenstand von einem der Beispiele 33-39, wobei das Identifizieren des Ressourcenkriteriums das Identifizieren mindestens eines aus einer Rechenverfügbarkeit, einer Arbeitsspeicherverfügbarkeit oder einer Datenspeicherverfügbarkeit umfasst.
  • Beispiel 41 beinhaltet den Gegenstand von einem der Beispiele 33-40, und beinhaltet ferner das Entdecken, durch den Netzwerk-Controller, der physischen Ressourcen der Cloud-Computing-Infrastruktur, wobei das Entdecken der physischen Ressourcen das Entdecken mindestens eines aus mehreren Switches der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Switches, mehreren Rechenknoten der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Rechenknoten oder einer Topologie der physischen Ressourcen umfasst.
  • Beispiel 42 beinhaltet den Gegenstand von einem der Beispiele 33-41, und beinhaltet ferner das Überwachen, durch den Netzwerk-Controller, der physischen Ressourcen basierend auf den identifizierten Netzwerkkriterien.
  • Beispiel 43 beinhaltet den Gegenstand von einem der Beispiele 33-42, wobei das Überwachen der physischen Ressourcen das Überwachen mindestens einer der einen oder mehreren physischen Netzwerkschnittstellen von einem oder mehreren der mehreren Rechenknoten, einer oder mehrerer virtueller Netzwerkschnittstellen eines oder mehrerer der mehreren Rechenknoten oder eines oder mehrerer Switch-Ports von einem oder mehreren der mehreren Switches umfasst.
  • Beispiel 44 beinhaltet den Gegenstand von einem der Beispiele 33-43, wobei das Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des neuen Tenant-Netzwerks nutzbar sind, ferner auf einem Ergebnis der überwachten physischen Ressourcen basiert.
  • Beispiel 45 beinhaltet den Gegenstand von einem der Beispiele 33-44, und beinhaltet ferner das Identifizieren, durch den Netzwerk-Controller, vorliegender Netzwerkleistungsmetriken für das Underlay-Netzwerk basierend auf einem Ergebnis der überwachten physischen Ressourcen.
  • Beispiel 46 beinhaltet den Gegenstand von einem der Beispiele 33-45, und beinhaltet ferner das Empfangen, durch den Netzwerk-Controller, eines Hinweises auf eine virtuelle Maschineninstanz, die in dem Underlay-Netzwerk instanziiert werden soll; das Identifizieren, durch den Netzwerk-Controller, einer oder mehrerer vorliegender Netzwerkleistungsmetriken des Underlay-Netzwerks; das Aktualisieren, durch den Netzwerk-Controller, von Netzwerkleistungskriterien, die mit der Überwachung von Leistungslevels des Underlay-Netzwerks assoziiert sind; das Vergleichen, durch den Netzwerk-Controller, der einen oder der mehreren vorliegenden Netzwerkleistungsmetriken und der aktualisierten Netzwerkleistungskriterien; und das Bestimmen, durch den Netzwerk-Controller, ob das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann.
  • Beispiel 47 beinhaltet den Gegenstand von einem der Beispiele 33-46, und beinhaltet ferner das Initiieren, durch den Netzwerk-Controller und als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz nicht unterstützen kann, der Erzeugung eines neuen Underlay-Netzwerks, dass die virtuelle Maschineninstanz, die instanziiert werden soll, beinhaltet.
  • Beispiel 48 beinhaltet den Gegenstand von einem der Beispiele 33-47, und beinhaltet ferner das Identifizieren, durch den Netzwerk-Controller und als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann, eines Zielrechenknotens, in welchem die virtuelle Maschineninstanz instanziiert werden soll; das Instanziieren, durch den Netzwerk-Controller, der virtuellen Maschineninstanz in dem identifizierten Zielrechenknoten; und das Anschließen, durch den Netzwerk-Controller, der instanziierten virtuellen Maschineninstanz an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist.
  • Beispiel 49 beinhaltet einen Netzwerk-Controller, der einen Prozessor und einen Arbeitsspeicher mit mehreren darin gespeicherten Anweisungen, die, wenn sie durch den Prozessor ausgeführt werden, den Netzwerk-Controller zum Durchführen des Verfahrens von einem der Beispiele 33-48 veranlassen, umfasst.
  • Beispiel 50 beinhaltet ein oder mehrere maschinenlesbare Speichermedien, die mehrere darauf gespeicherte Anweisungen umfassen, die, als Reaktion auf deren Ausführung, darin resultieren, dass ein Netzwerk-Controller das Verfahren von einem der Beispiele 33-48 durchführt.
  • Beispiel 51 beinhaltet einen Netzwerk-Controller für den Einsatz dynamischer Underlay-Netzwerke in einer Cloud-Computing-Infrastruktur, wobei der Netzwerk-Controller eine Anwendungsschnittstellen-Schaltung zum Empfangen einer Tenant-Netzwerk-Erzeugungsanfrage von einem Cloud-Betriebssystem der Cloud-Computing-Infrastruktur, wobei die Tenant-Netzwerk-Erzeugungsanfrage den Netzwerk-Controller darauf hinweist, dass ein neues Tenant-Netzwerk in der Cloud-Computing-Infrastruktur erzeugt werden soll; Mittel zum Identifizieren von Netzwerkkriterien für das neue Tenant-Netzwerk basierend auf der empfangenen Tenant-Netzwerk-Erzeugungsanfrage; Mittel zum Identifizieren physischer Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des neuen Tenant-Netzwerks nutzbar sind, basierend auf den identifizierten Netzwerkkriterien; und Mittel zum Bereitstellen eines Underlay-Netzwerks zum Unterstützen des neuen Tenant-Netzwerks basierend auf den identifizierten physischen Ressourcen, Mittel zum Übertragen von Informationen des Underlay-Netzwerks an das Cloud-Betriebssystem, wobei die Informationen des Underlay-Netzwerks zum Erzeugen eines in der Cloud sichtbaren Overlay-Netzwerks, das mit dem Underlay-Netzwerk assoziiert ist, nutzbar sind, umfasst.
  • Beispiel 52 beinhaltet den Gegenstand of Beispiel 51, wobei das Mittel zum Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur Mittel (i) zum Identifizieren eines oder mehrerer Zielrechenknoten für die Instanziierung einer oder mehrerer virtueller Maschinen, die mit dem neuen Tenant-Netzwerk assoziiert werden sollen, und (ii) zum Identifizieren eines oder mehrerer Switches, die den einen oder die mehreren identifizierten Zielrechenknoten mit der Cloud-Computing-Infrastruktur verbinden, umfasst.
  • Beispiel 53 beinhaltet den Gegenstand von einem der Beispiele 51 und 52, wobei das Mittel zum Bereitstellen des Underlay-Netzwerks Mittel (i) zum Initialisieren einer virtuellen lokalen Netzwerk (VLAN) -Schnittstelle über eine physische Netzwerkschnittstelle des einen oder der mehreren identifizierten Zielrechenknoten und (ii) zum Konfigurieren von Switch-Ports des einen oder der mehreren Switches zum Konfigurieren eines VLAN zwischen dem einen oder den mehreren Switches umfasst.
  • Beispiel 54 beinhaltet den Gegenstand von einem der Beispiele 51-53, wobei das Mittel zum Bereitstellen des Underlay-Netzwerks Mittel zum Aufrufen von Rack-Scale-Architektur-konformen Anwendungsprogrammierungsschnittstellen-Befehlen an den einen oder die mehreren Switches umfasst.
  • Beispiel 55 beinhaltet den Gegenstand von einem der Beispiele 51-54, wobei das Empfangen der Tenant-Netzwerk-Erzeugungsanfrage das Empfangen eines Hinweises, dass eine oder mehrere virtuelle Maschinen zum Unterstützen des neuen Tenant-Netzwerks instanziiert werden sollen, umfasst, und welches ferner eine Datenebenenschnittstellen-Schaltung zum Instanziieren der einen oder der mehreren virtuellen Maschinen in einem oder mehreren Zielrechenknoten der Cloud-Computing-Infrastruktur; und Mittel zum Anschließen der einen oder der mehreren instanziierten virtuellen Maschinen an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist, umfasst.
  • Beispiel 56 beinhaltet den Gegenstand von einem der Beispiele 51-55, wobei das Mittel zum Identifizieren der Netzwerkkriterien, die zum Erzeugen des neuen Tenant-Netzwerks nutzbar sind, Mittel zum Identifizieren mindestens eines aus einem Leistungskriterium oder einem Ressourcenkriterium umfasst.
  • Beispiel 57 beinhaltet den Gegenstand von einem der Beispiele 51-56, wobei das Mittel zum Identifizieren des Leistungskriteriums Mittel zum Identifizieren mindestens eines aus einer Nutzungsschwelle oder einer Dienstqualitätsanforderung umfasst.
  • Beispiel 58 beinhaltet den Gegenstand von einem der Beispiele 51-57, wobei das Mittel zum Identifizieren des Ressourcenkriteriums Mittel zum Identifizieren mindestens eines aus einer Rechenverfügbarkeit, einer Arbeitsspeicherverfügbarkeit oder einer Datenspeicherverfügbarkeit umfasst.
  • Beispiel 59 beinhaltet den Gegenstand von einem der Beispiele 51-58, und beinhaltet ferner Mittel zum Entdecken der physischen Ressourcen der Cloud-Computing-Infrastruktur, wobei das Mittel zum Entdecken der physischen Ressourcen Mittel zum Entdecken mindestens eines aus mehreren Switches der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Switches, mehreren Rechenknoten der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Rechenknoten oder einer Topologie der physischen Ressourcen umfasst.
  • Beispiel 60 beinhaltet den Gegenstand von einem der Beispiele 51-59, und beinhaltet ferner Mittel zum Überwachen der physischen Ressourcen basierend auf den identifizierten Netzwerkkriterien.
  • Beispiel 61 beinhaltet den Gegenstand von einem der Beispiele 51-60, wobei das Mittel zum Überwachen der physischen Ressourcen Mittel zum Überwachen mindestens eines aus einer oder mehreren physischen Netzwerkschnittstellen von einem oder mehreren der mehreren Rechenknoten, einer oder mehreren virtuellen Schnittstellen von einem oder mehreren der mehreren Rechenknoten oder einem oder mehreren Switch-Ports von einem oder mehreren der mehreren Switches umfasst.
  • Beispiel 62 beinhaltet den Gegenstand von einem der Beispiele 51-61, wobei das Mittel zum Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des neuen Tenant-Netzwerks nutzbar sind, ferner auf einem Ergebnis der überwachten physischen Ressourcen basiert.
  • Beispiel 63 beinhaltet den Gegenstand von einem der Beispiele 51-62, und beinhaltet ferner Mittel zum Identifizieren vorliegender Netzwerkleistungsmetriken für das Underlay-Netzwerk basierend auf einem Ergebnis der überwachten physischen Ressourcen.
  • Beispiel 64 beinhaltet den Gegenstand von einem der Beispiele 51-63, und beinhaltet ferner Mittel zum Empfangen eines Hinweises auf eine virtuelle Maschineninstanz, die in dem Underlay-Netzwerk instanziiert werden soll; Mittel zum Identifizieren einer oder mehrerer vorliegender Netzwerkleistungsmetriken des Underlay-Netzwerks; Mittel zum Aktualisieren von Netzwerkleistungskriterien, die mit der Überwachung von Leistungslevels des Underlay-Netzwerks assoziiert sind; Mittel zum Vergleichen der einen oder der mehreren vorliegenden Netzwerkleistungsmetriken und der aktualisierten Netzwerkleistungskriterien; und Mittel zum Bestimmen, ob das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann.
  • Beispiel 65 beinhaltet den Gegenstand von einem der Beispiele 51-64, und beinhaltet ferner Mittel zum Initiieren, als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz nicht unterstützen kann, der Erzeugung eines neuen Underlay-Netzwerks, das die virtuelle Maschineninstanz, die instanziiert werden soll, beinhaltet.
  • Beispiel 66 beinhaltet den Gegenstand von einem der Beispiele 51-65, und beinhaltet ferner Mittel zum Identifizieren, als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann, eines Zielrechenknotens, in welchem die virtuelle Maschineninstanz instanziiert werden soll; Mittel zum Instanziieren der virtuellen Maschineninstanz in dem identifizierten Zielrechenknoten; und Mittel zum Anschließen der instanziierten virtuellen Maschineninstanz an das in der Cloud sichtbaren Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist.

Claims (24)

  1. Netzwerk-Controller für den Einsatz dynamischer Underlay-Netzwerke in einer Cloud-Computing-Infrastruktur, wobei der Netzwerk-Controller Folgendes umfasst: einen oder mehrere Prozessoren; und ein oder mehrere Arbeitsspeichergeräte mit mehreren darin gespeicherten Anweisungen, die, wenn sie durch den einen oder die mehreren Prozessoren ausgeführt werden, den Netzwerk-Controller zu Folgendem veranlassen: Empfangen, von einem Cloud-Betriebssystem der Cloud-Computing-Infrastruktur, einer Tenant-Netzwerk-Erzeugungsanfrage, die angibt, dass ein Tenant-Netzwerk in der Cloud-Computing-Infrastruktur für einen neuen Tenant der Cloud-Computing-Infrastruktur erzeugt werden soll; Identifizieren von Netzwerkkriterien für das Tenant-Netzwerk basierend auf der empfangenen Tenant-Netzwerk-Erzeugungsanfrage; Identifizieren physischer Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des Tenant-Netzwerks nutzbar sind, basierend auf den identifizierten Netzwerkkriterien; Bereitstellen eines Underlay-Netzwerks zum Unterstützen des Tenant-Netzwerks basierend auf den identifizierten physischen Ressourcen; und Übertragen von Informationen des Underlay-Netzwerks an das Cloud-Betriebssystem, wobei die Informationen des Underlay-Netzwerks zum Erzeugen eines in der Cloud sichtbaren Overlay-Netzwerks, das mit dem Underlay-Netzwerk assoziiert ist, nutzbar sind.
  2. Netzwerk-Controller nach Anspruch 1, wobei das Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur (i) das Identifizieren eines oder mehrerer Zielrechenknoten für die Instanziierung einer oder mehrerer virtueller Maschinen, die mit dem Tenant-Netzwerk assoziiert werden sollen, und (ii) das Identifizieren eines oder mehrerer Switches, die den einen oder die mehreren identifizierten Zielrechenknoten mit der Cloud-Computing-Infrastruktur verbinden, umfasst.
  3. Netzwerk-Controller nach Anspruch 2, wobei das Bereitstellen des Underlay-Netzwerks (i) das Initialisieren einer virtuellen lokalen Netzwerk (VLAN) -Schnittstelle über eine physische Netzwerkschnittstelle des einen oder der mehreren identifizierten Zielrechenknoten und (ii) das Konfigurieren von Switch-Ports des einen oder der mehreren Switches zum Konfigurieren eines VLAN zwischen dem einen oder den mehreren Switches umfasst.
  4. Netzwerk-Controller nach Anspruch 1, wobei das Empfangen der Tenant-Netzwerk-Erzeugungsanfrage das Empfangen eines Hinweises, dass eine oder mehrere virtuelle Maschinen zum Unterstützen des Tenant-Netzwerks instanziiert werden sollen, umfasst, und wobei die mehreren Anweisungen den Netzwerk-Controller ferner zu Folgendem veranlassen: Instanziieren der einen oder der mehreren virtuellen Maschinen in einem oder mehreren Zielrechenknoten der Cloud-Computing-Infrastruktur; und Anschließen der einen oder der mehreren instanziierten virtuellen Maschinen an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist.
  5. Netzwerk-Controller nach Anspruch 1, wobei das Identifizieren der Netzwerkkriterien, die zum Erzeugen des Tenant-Netzwerks nutzbar sind, das Identifizieren mindestens eines aus einem Leistungskriterium oder einem Ressourcenkriterium umfasst, wobei das Leistungskriterium mindestens eines aus einer Nutzungsschwelle oder einer Dienstqualitätsanforderung beinhaltet, und wobei das Ressourcenkriterium mindestens eines aus einer Rechenverfügbarkeit, einer Arbeitsspeicherverfügbarkeit oder einer Datenspeicherverfügbarkeit beinhaltet.
  6. Netzwerk-Controller nach Anspruch 1, wobei die mehreren Anweisungen den Netzwerk-Controller ferner veranlassen, die physischen Ressourcen der Cloud-Computing-Infrastruktur zu entdecken, wobei das Entdecken der physischen Ressourcen das Entdecken mindestens eines aus mehreren Switches der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Switches, mehreren Rechenknoten der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Rechenknoten oder einer Topologie der physischen Ressourcen umfasst.
  7. Netzwerk-Controller nach Anspruch 6, wobei die mehreren Anweisungen den Netzwerk-Controller ferner veranlassen, die physischen Ressourcen basierend auf den identifizierten Netzwerkkriterien zu überwachen, und wobei das Überwachen der physischen Ressourcen das Überwachen mindestens eines aus einer oder mehreren physischen Netzwerkschnittstellen eines oder mehrerer der mehreren Rechenknoten, einer oder mehreren virtuellen Netzwerkschnittstellen eines oder mehrerer der mehreren Rechenknoten oder einem oder mehreren Switch-Ports eines oder mehrerer der mehreren Switches umfasst.
  8. Netzwerk-Controller nach Anspruch 7, wobei das Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des Tenant-Netzwerks nutzbar sind, ferner auf einem Ergebnis der überwachten physischen Ressourcen basiert, wobei die mehreren Anweisungen den Netzwerk-Controller ferner zum Identifizieren vorliegender Netzwerkleistungsmetriken für das Underlay-Netzwerk basierend auf einem Ergebnis der überwachten physischen Ressourcen veranlassen.
  9. Netzwerk-Controller nach Anspruch 1, wobei die mehreren Anweisungen den Netzwerk-Controller ferner (i) zum Empfangen eines Hinweises auf eine virtuelle Maschineninstanz, die in dem Underlay-Netzwerk instanziiert werden soll, (ii) zum Identifizieren einer oder mehrerer vorliegender Netzwerkleistungsmetriken des Underlay-Netzwerks, (iii) zum Aktualisieren von Netzwerkleistungskriterien, die mit der Überwachung von Leistungslevels des Underlay-Netzwerks assoziiert sind, (iv) zum Vergleichen der einen oder der mehreren vorliegenden Netzwerkleistungsmetriken und der aktualisierten Netzwerkleistungskriterien und (v) zum Bestimmen, ob das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann, veranlassen.
  10. Netzwerk-Controller nach Anspruch 9, wobei die mehreren Anweisungen den Netzwerk-Controller ferner zum Initiieren, als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz nicht unterstützen kann, der Erzeugung eines neuen Underlay-Netzwerks, das die virtuelle Maschineninstanz, die instanziiert werden soll, beinhaltet, veranlassen.
  11. Netzwerk-Controller nach Anspruch 9, wobei die mehreren Anweisungen den Netzwerk-Controller ferner (i) zum Identifizieren, als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann, eines Zielrechenknotens, in welchem die virtuelle Maschineninstanz instanziiert werden soll, (ii) zum Instanziieren der virtuellen Maschineninstanz in dem identifizierten Zielrechenknoten und (iii) zum Anschließen der instanziierten virtuellen Maschineninstanz an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist, veranlassen.
  12. Verfahren für den Einsatz dynamischer Underlay-Netzwerke in einer Cloud-Computing-Infrastruktur, wobei das Verfahren Folgendes umfasst: Empfangen, durch einen Netzwerk-Controller in der Cloud-Computing-Infrastruktur, einer Tenant-Netzwerk-Erzeugungsanfrage von einem Cloud-Betriebssystem der Cloud-Computing-Infrastruktur, wobei die Tenant-Netzwerk-Erzeugungsanfrage den Netzwerk-Controller darauf hinweist, ein neues Tenant-Netzwerk in der Cloud-Computing-Infrastruktur zu erzeugen; Identifizieren, durch den Netzwerk-Controller, von Netzwerkkriterien für das neue Tenant-Netzwerk basierend auf der empfangenen Tenant-Netzwerk-Erzeugungsanfrage; Identifizieren, durch den Netzwerk-Controller, physischer Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des neuen Tenant-Netzwerks nutzbar sind, basierend auf den identifizierten Netzwerkkriterien; Bereitstellen, durch den Netzwerk-Controller, eines Underlay-Netzwerks zum Unterstützen des neuen Tenant-Netzwerks basierend auf den identifizierten physischen Ressourcen; und Übertragen, durch den Netzwerk-Controller, von Informationen des Underlay-Netzwerks an das Cloud-Betriebssystem, wobei die Informationen des Underlay-Netzwerks zum Erzeugen eines in der Cloud sichtbaren Overlay-Netzwerks, das mit dem Underlay-Netzwerk assoziiert ist, nutzbar sind.
  13. Verfahren nach Anspruch 12, wobei das Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur (i) das Identifizieren eines oder mehrerer Zielrechenknoten für die Instanziierung einer oder mehrerer virtueller Maschinen, die mit dem neuen Tenant-Netzwerk assoziiert werden sollen, und (ii) das Identifizieren eines oder mehrerer Switches, die den einen oder die mehreren identifizierten Zielrechenknoten mit der Cloud-Computing-Infrastruktur verbinden, umfasst.
  14. Verfahren nach Anspruch 13, wobei das Bereitstellen des Underlay-Netzwerks (i) das Initialisieren einer virtuellen lokalen Netzwerk (VLAN) -Schnittstelle über eine physische Netzwerkschnittstelle des einen oder der mehreren identifizierten Zielrechenknoten und (ii) das Konfigurieren von Switch-Ports des einen oder der mehreren Switches zum Konfigurieren eines VLAN zwischen dem einen oder den mehreren Switches umfasst.
  15. Verfahren nach Anspruch 12, wobei das Empfangen der Tenant-Netzwerk-Erzeugungsanfrage das Empfangen eines Hinweises, dass eine oder mehrere virtuelle Maschinen zum Unterstützen des neuen Tenant-Netzwerks instanziiert werden sollen, umfasst, und welches ferner Folgendes umfasst: Instanziieren, durch den Netzwerk-Controller, der einen oder der mehreren virtuellen Maschinen in einem oder mehreren Zielrechenknoten der Cloud-Computing-Infrastruktur; und Anschließen, durch den Netzwerk-Controller, der einen oder der mehreren instanziierten virtuellen Maschinen an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist.
  16. Verfahren nach Anspruch 12, wobei das Identifizieren der Netzwerkkriterien, die zum Erzeugen des neuen Tenant-Netzwerks nutzbar sind, das Identifizieren mindestens eines aus einem Leistungskriterium oder einem Ressourcenkriterium umfasst, wobei das Identifizieren des Leistungskriteriums das Identifizieren mindestens eines aus einer Nutzungsschwelle oder einer Dienstqualitätsanforderung umfasst, und wobei das Identifizieren des Ressourcenkriteriums das Identifizieren mindestens eines aus einer Rechenverfügbarkeit, einer Arbeitsspeicherverfügbarkeit oder einer Datenspeicherverfügbarkeit umfasst.
  17. Verfahren nach Anspruch 12, welches ferner das Entdecken, durch den Netzwerk-Controller, der physischen Ressourcen der Cloud-Computing-Infrastruktur umfasst, wobei das Entdecken der physischen Ressourcen das Entdecken mindestens eines aus mehreren Switches der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Switches, mehreren Rechenknoten der Cloud-Computing-Infrastruktur, Fähigkeiten jedes der mehreren Rechenknoten oder einer Topologie der physischen Ressourcen umfasst.
  18. Verfahren nach Anspruch 17, welches ferner das Überwachen, durch den Netzwerk-Controller, der physischen Ressourcen basierend auf den identifizierten Netzwerkkriterien umfasst, wobei das Überwachen der physischen Ressourcen das Überwachen mindestens eines aus einer oder mehreren physischen Netzwerkschnittstellen eines oder mehrerer der mehreren Rechenknoten, einer oder mehreren virtuellen Netzwerkschnittstellen eines oder mehrerer der mehreren Rechenknoten oder einem oder mehreren Switch-Ports eines oder mehrerer der mehreren Switches umfasst.
  19. Verfahren nach Anspruch 18, wobei das Identifizieren der physischen Ressourcen der Cloud-Computing-Infrastruktur, die zum Erzeugen des neuen Tenant-Netzwerks nutzbar sind, ferner auf einem Ergebnis der überwachten physischen Ressourcen basiert, und welches ferner das Identifizieren, durch den Netzwerk-Controller, vorliegender Netzwerkleistungsmetriken für das Underlay-Netzwerk basierend auf einem Ergebnis der überwachten physischen Ressourcen umfasst.
  20. Verfahren nach Anspruch 12, welches ferner Folgendes umfasst: Empfangen, durch den Netzwerk-Controller, eines Hinweises auf eine virtuelle Maschineninstanz, die in dem Underlay-Netzwerk instanziiert werden soll; Identifizieren, durch den Netzwerk-Controller, einer oder mehrerer vorliegender Netzwerkleistungsmetriken des Underlay-Netzwerks; Aktualisieren, durch den Netzwerk-Controller, von Netzwerkleistungskriterien, die mit der Überwachung von Leistungslevels des Underlay-Netzwerks assoziiert sind; Vergleichen, durch den Netzwerk-Controller, der einen oder der mehreren vorliegenden Netzwerkleistungsmetriken und der aktualisierten Netzwerkleistungskriterien; und Bestimmen, durch den Netzwerk-Controller, ob das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann.
  21. Verfahren nach Anspruch 20, welches ferner das Instanziieren, durch den Netzwerk-Controller und als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz nicht unterstützen kann, der Erzeugung eines neuen Underlay-Netzwerks, das die virtuelle Maschineninstanz, die instanziiert werden soll, beinhaltet, umfasst.
  22. Verfahren nach Anspruch 20, welches ferner Folgendes umfasst: Identifizieren, durch den Netzwerk-Controller und als Reaktion auf eine Bestimmung, dass das Underlay-Netzwerk eine Instanziierung der virtuellen Maschineninstanz unterstützen kann, eines Zielrechenknotens, in welchem die virtuelle Maschineninstanz instanziiert werden soll; Instanziieren, durch den Netzwerk-Controller, der virtuellen Maschineninstanz in dem identifizierten Zielrechenknoten; und Anschließen, durch den Netzwerk-Controller, der instanziierten virtuellen Maschineninstanz an das in der Cloud sichtbare Overlay-Netzwerk, das mit dem Underlay-Netzwerk assoziiert ist.
  23. Netzwerk-Controller, welcher Folgendes umfasst: einen Prozessor; und einen Arbeitsspeicher mit mehreren darin gespeicherten Anweisungen, die, wenn sie durch den Prozessor ausgeführt werden, den Netzwerk-Controller zum Durchführen des Verfahrens nach einem der Ansprüche 12-22 veranlassen.
  24. Maschinenlesbares Speichermedium bzw. maschinenlesbare Speichermedien, die mehrere darauf gespeicherte Anweisungen umfassen, die, als Reaktion auf ihre Ausführung, darin resultieren, dass ein Netzwerk-Controller das Verfahren nach einem der Ansprüche 12-22 durchführt.
DE112017001762.9T 2016-03-31 2017-03-01 Technologien für den einsatz dynamischer underlay-netzwerke in cloud-computing-infrastrukturen Pending DE112017001762T5 (de)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US15/087,172 US20170289002A1 (en) 2016-03-31 2016-03-31 Technologies for deploying dynamic underlay networks in cloud computing infrastructures
US15/087,172 2016-03-31
PCT/US2017/020234 WO2017172218A1 (en) 2016-03-31 2017-03-01 Technologies for deploying dynamic underlay networks in cloud computing infrastructures

Publications (1)

Publication Number Publication Date
DE112017001762T5 true DE112017001762T5 (de) 2018-12-13

Family

ID=59962098

Family Applications (1)

Application Number Title Priority Date Filing Date
DE112017001762.9T Pending DE112017001762T5 (de) 2016-03-31 2017-03-01 Technologien für den einsatz dynamischer underlay-netzwerke in cloud-computing-infrastrukturen

Country Status (3)

Country Link
US (1) US20170289002A1 (de)
DE (1) DE112017001762T5 (de)
WO (1) WO2017172218A1 (de)

Families Citing this family (59)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10454714B2 (en) 2013-07-10 2019-10-22 Nicira, Inc. Method and system of overlay flow control
US10749711B2 (en) 2013-07-10 2020-08-18 Nicira, Inc. Network-link method useful for a last-mile connectivity in an edge-gateway multipath system
US10498652B2 (en) 2015-04-13 2019-12-03 Nicira, Inc. Method and system of application-aware routing with crowdsourcing
US10135789B2 (en) 2015-04-13 2018-11-20 Nicira, Inc. Method and system of establishing a virtual private network in a cloud service for branch networking
US10425382B2 (en) 2015-04-13 2019-09-24 Nicira, Inc. Method and system of a cloud-based multipath routing protocol
US9921997B2 (en) * 2016-04-01 2018-03-20 Intel Corporation Mechanism for PCIE cable topology discovery in a rack scale architecture environment
US10135712B2 (en) * 2016-04-07 2018-11-20 At&T Intellectual Property I, L.P. Auto-scaling software-defined monitoring platform for software-defined networking service assurance
US10298516B2 (en) * 2016-04-19 2019-05-21 Hyland Switzerland Sàrl System and methods for sharing resources among application modules
US10833969B2 (en) * 2016-07-22 2020-11-10 Intel Corporation Methods and apparatus for composite node malleability for disaggregated architectures
US10034407B2 (en) * 2016-07-22 2018-07-24 Intel Corporation Storage sled for a data center
US10992558B1 (en) 2017-11-06 2021-04-27 Vmware, Inc. Method and apparatus for distributed data network traffic optimization
US20180219765A1 (en) 2017-01-31 2018-08-02 Waltz Networks Method and Apparatus for Network Traffic Control Optimization
US11706127B2 (en) 2017-01-31 2023-07-18 Vmware, Inc. High performance software-defined core network
US10992568B2 (en) 2017-01-31 2021-04-27 Vmware, Inc. High performance software-defined core network
US11121962B2 (en) 2017-01-31 2021-09-14 Vmware, Inc. High performance software-defined core network
US20200036624A1 (en) 2017-01-31 2020-01-30 The Mode Group High performance software-defined core network
US11252079B2 (en) 2017-01-31 2022-02-15 Vmware, Inc. High performance software-defined core network
US10778528B2 (en) 2017-02-11 2020-09-15 Nicira, Inc. Method and system of connecting to a multipath hub in a cluster
US10491567B2 (en) * 2017-03-17 2019-11-26 Verizon Patent And Licensing Inc. Dynamic firewall configuration based on proxy container deployment
US10523539B2 (en) 2017-06-22 2019-12-31 Nicira, Inc. Method and system of resiliency in cloud-delivered SD-WAN
US20200220919A1 (en) * 2017-08-22 2020-07-09 Convida Wireless, Llc Overlay resource trees in a communication network
US11115480B2 (en) 2017-10-02 2021-09-07 Vmware, Inc. Layer four optimization for a virtual network defined over public cloud
US10999165B2 (en) 2017-10-02 2021-05-04 Vmware, Inc. Three tiers of SaaS providers for deploying compute and network infrastructure in the public cloud
US10666460B2 (en) 2017-10-02 2020-05-26 Vmware, Inc. Measurement based routing through multiple public clouds
US10999100B2 (en) 2017-10-02 2021-05-04 Vmware, Inc. Identifying multiple nodes in a virtual network defined over a set of public clouds to connect to an external SAAS provider
US11089111B2 (en) 2017-10-02 2021-08-10 Vmware, Inc. Layer four optimization for a virtual network defined over public cloud
US11223514B2 (en) 2017-11-09 2022-01-11 Nicira, Inc. Method and system of a dynamic high-availability mode based on current wide area network connectivity
CN107896374A (zh) * 2017-11-30 2018-04-10 南京信息工程大学 一种面向移动终端设备的朵云动态部署方法
KR102052652B1 (ko) * 2017-12-05 2019-12-06 광주과학기술원 클라우드 서비스 시스템
CN109962788B (zh) * 2017-12-14 2022-03-29 中国电信股份有限公司 多控制器调度方法、装置和系统及计算机可读存储介质
US10613893B2 (en) * 2018-02-02 2020-04-07 Nutanix, Inc. System and method for reducing downtime during hypervisor conversion
US10721133B2 (en) 2018-08-08 2020-07-21 Cisco Technology, Inc. Underlay network formation
JP2021535681A (ja) * 2018-08-27 2021-12-16 ドライブネッツ リミテッド ネットワーククラウドソフトウェアを使用するためのシステム及び方法
US11418399B2 (en) * 2019-04-30 2022-08-16 Cisco Technology, Inc. Multi-fabric deployment and management platform
US11252105B2 (en) 2019-08-27 2022-02-15 Vmware, Inc. Identifying different SaaS optimal egress nodes for virtual networks of different entities
CN110868394A (zh) * 2019-09-25 2020-03-06 上海数荃数据科技有限公司 OpenStack云环境安全检测方法、装置、服务器以及存储介质
CN112702372B (zh) * 2019-10-22 2024-04-05 中兴通讯股份有限公司 一种云服务管理方法、云服务管理装置及可读存储介质
US11044190B2 (en) 2019-10-28 2021-06-22 Vmware, Inc. Managing forwarding elements at edge nodes connected to a virtual network
CA3158104A1 (en) * 2019-11-25 2021-06-03 Mircea Orban Automated lifecycle management flexible scaling and dynamic resource allocation for virtualized cable data plane applications
US11489783B2 (en) 2019-12-12 2022-11-01 Vmware, Inc. Performing deep packet inspection in a software defined wide area network
US11394640B2 (en) 2019-12-12 2022-07-19 Vmware, Inc. Collecting and analyzing data regarding flows associated with DPI parameters
CN111147345B (zh) * 2019-12-20 2022-01-07 航天信息股份有限公司 云环境网络隔离装置、方法及云系统
US11722925B2 (en) 2020-01-24 2023-08-08 Vmware, Inc. Performing service class aware load balancing to distribute packets of a flow among multiple network links
US11245641B2 (en) 2020-07-02 2022-02-08 Vmware, Inc. Methods and apparatus for application aware hub clustering techniques for a hyper scale SD-WAN
US11709710B2 (en) 2020-07-30 2023-07-25 Vmware, Inc. Memory allocator for I/O operations
US11943150B2 (en) 2020-10-08 2024-03-26 Cisco Technology, Inc. Tracking application scaling for network bandwidth allocation
US11575591B2 (en) 2020-11-17 2023-02-07 Vmware, Inc. Autonomous distributed forwarding plane traceability based anomaly detection in application traffic for hyper-scale SD-WAN
US11575600B2 (en) 2020-11-24 2023-02-07 Vmware, Inc. Tunnel-less SD-WAN
US11929903B2 (en) 2020-12-29 2024-03-12 VMware LLC Emulating packet flows to assess network links for SD-WAN
CN116783874A (zh) 2021-01-18 2023-09-19 Vm维尔股份有限公司 网络感知的负载平衡
US11979325B2 (en) 2021-01-28 2024-05-07 VMware LLC Dynamic SD-WAN hub cluster scaling with machine learning
US11388086B1 (en) 2021-05-03 2022-07-12 Vmware, Inc. On demand routing mesh for dynamically adjusting SD-WAN edge forwarding node roles to facilitate routing through an SD-WAN
US11729065B2 (en) 2021-05-06 2023-08-15 Vmware, Inc. Methods for application defined virtual network service among multiple transport in SD-WAN
US11489720B1 (en) 2021-06-18 2022-11-01 Vmware, Inc. Method and apparatus to evaluate resource elements and public clouds for deploying tenant deployable elements based on harvested performance metrics
US11375005B1 (en) 2021-07-24 2022-06-28 Vmware, Inc. High availability solutions for a secure access service edge application
US11943146B2 (en) 2021-10-01 2024-03-26 VMware LLC Traffic prioritization in SD-WAN
JP7412405B2 (ja) * 2021-12-23 2024-01-12 株式会社日立製作所 情報処理システム、情報処理方法
CN114338500B (zh) * 2021-12-30 2023-10-31 北京青云科技股份有限公司 一种数据转发方法、装置、设备及存储介质
US11909815B2 (en) 2022-06-06 2024-02-20 VMware LLC Routing based on geolocation costs

Family Cites Families (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7054943B1 (en) * 2000-04-28 2006-05-30 International Business Machines Corporation Method and apparatus for dynamically adjusting resources assigned to plurality of customers, for meeting service level agreements (slas) with minimal resources, and allowing common pools of resources to be used across plural customers on a demand basis
US20040210623A1 (en) * 2003-03-06 2004-10-21 Aamer Hydrie Virtual network topology generation
WO2005032042A1 (en) * 2003-09-24 2005-04-07 Infoexpress, Inc. Systems and methods of controlling network access
US7733802B2 (en) * 2005-09-15 2010-06-08 Tp Lab, Inc. Method to dynamically create a virtual network
US9049146B2 (en) * 2008-10-22 2015-06-02 Accenture Global Services Limited Automatically connecting remote network equipment through a graphical user interface
US8370481B2 (en) * 2009-05-13 2013-02-05 Verizon Patent And Licensing Inc. Inventory management in a computing-on-demand system
US8665747B2 (en) * 2009-12-03 2014-03-04 Cisco Technology, Inc. Preventing loops on network topologies built with virtual switches and VMS
WO2012120557A1 (ja) * 2011-03-07 2012-09-13 株式会社日立製作所 ネットワーク管理装置、ネットワーク管理方法及びネットワーク管理システム
JP2012199644A (ja) * 2011-03-18 2012-10-18 Nec Corp 仮想ネットワーク管理システム、仮想ネットワーク管理方法および仮想ネットワーク管理用プログラム
US9300548B2 (en) * 2011-10-14 2016-03-29 Alcatel Lucent Providing dynamic reliability and security in communications environments
US9705704B2 (en) * 2012-01-13 2017-07-11 Verizon Patent And Licensing Inc. Method and system of forming a mobile virtual network
US9223635B2 (en) * 2012-10-28 2015-12-29 Citrix Systems, Inc. Network offering in cloud computing environment
JP2015142167A (ja) * 2014-01-27 2015-08-03 富士通株式会社 管理装置、管理プログラムおよびネットワーク装置の設定情報管理方法

Also Published As

Publication number Publication date
US20170289002A1 (en) 2017-10-05
WO2017172218A1 (en) 2017-10-05

Similar Documents

Publication Publication Date Title
DE112017001762T5 (de) Technologien für den einsatz dynamischer underlay-netzwerke in cloud-computing-infrastrukturen
DE102015105884B4 (de) Rechenknoten und Verfahren zur Migration einer virtuellen Maschine, Rechenzentrummanager zur Migration virtueller Maschinen, Maschinenlesbares Speichermedium und Rechenvorrichtungen
KR101714279B1 (ko) 폴리시 기반 데이터센터 네트워크 자동화를 제공하는 시스템 및 방법
DE102020132078A1 (de) Ressourcenzuteilung basierend auf anwendbarem service level agreement
DE112011100392B4 (de) Ressourcenaffinität durch dynamisches hinzufügen oder entfernen von warteschlangenpaaren für netzadapter mit software zur empfangsseitigen skalierung (rss)
DE112013000395B4 (de) Vorrichtung, verfahren und computerlesbarer speicher zur richtliniendurchsetzung in rechenumgebung
DE102020201834A1 (de) Technologien für netzvorrichtungslastausgleichseinrichtungen für beschleunigte funktionen-als-dienst
DE102022107621A1 (de) Resourcenauswahl, die zum teil auf der arbeitslast basiert
DE102018214774A1 (de) Technologien zum dynamischen Managen der Zuverlässigkeit disaggregierter Betriebsmittel in einem gemanagten Knoten
DE102022104207A1 (de) Pooling von Netzwerkverarbeitungsressourcen
DE112021006003T5 (de) Intelligente datenebenenbeschleunigung durch auslagern zu verteilten smart- network-interfaces
DE102015118705A1 (de) Technologien für leistungsbasierte Außer-der-Reihe-Task-Planung für Datenzentren
DE102019130686A1 (de) Technologien zur bereitstellung dynamischer auswahl von edge- und lokalen beschleunigerressourcen
CN110088732A (zh) 一种数据包处理方法、主机和系统
CN111880902A (zh) 一种pod创建方法、装置、设备及可读存储介质
DE102018004111B4 (de) Rechensystem, computerlesbares medium und bedarfsskalierungsengine zum kommunikativen koppeln an einen prozessor
WO2018201856A1 (en) System and method for self organizing data center
DE112016005933T5 (de) Technologien zum Durchsetzen einer Netzwerkzugriffssteuerung fiir virtuelle Maschinen
DE102018202432A1 (de) Strukturunterstützung für die Dienstgüte
CN112181585A (zh) 虚拟机的资源分配方法及装置
DE102020110143A1 (de) Standortbasierte virtualisierungs-workload-platzierung
DE102018129112A1 (de) Systemdecoder für Trainingsbeschleuniger
US11140091B2 (en) Openflow protocol-based resource control method and system, and apparatus
US20160057206A1 (en) Application profile to configure and manage a software defined environment
DE112017001654T5 (de) Technologien für regionsgerichtete cacheverwaltung

Legal Events

Date Code Title Description
R079 Amendment of ipc main class

Free format text: PREVIOUS MAIN CLASS: H04L0029080000

Ipc: H04L0065000000

R012 Request for examination validly filed