DE102018202432A1

DE102018202432A1 - Strukturunterstützung für die Dienstgüte

Info

Publication number: DE102018202432A1
Application number: DE102018202432.4A
Authority: DE
Inventors: Karthik Kumar; Francesc Guim Bernat; Thomas Willhalm; Raj K. Ramanujan; Andrew J. Herdrich
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2017-02-17
Filing date: 2018-02-16
Publication date: 2018-08-23
Also published as: US20180241842A1; US11005968B2

Abstract

Offenbart wird in einem Beispiel eine Strukturschnittstellenvorrichtung, die Folgendes aufweist: eine Strukturverbindung zum kommunikativen Koppeln mit einer Struktur; eine SLA-Eingangslogik (Service Level Agreement, Service-Level-Vereinbarung) zum Empfangen einer SLA-Datenstruktur von einer Steuerung, wobei die SLA-Datenstruktur eine Ende-zu-Ende-SLA für einen von mehreren Ressourcen bereitgestellten Ressourcenstrom bereitstellt und QoS-Metriken für die Ressourcen umfasst; und eine SLA-Ausgangslogik zum Verteilen der QoS-Metriken an die Ressourcen über die Strukturverbindung.

Description

Gebiet der Beschreibung
Diese Offenbarung betrifft allgemein das Gebiet des Cloud Computing und insbesondere, wenngleich nicht ausschließlich, ein System und Verfahren zur Strukturunterstützung für die Dienstgüte.
Hintergrund
Die gegenwärtige Rechenpraxis hat sich weg von hardwarespezifischer Datenverarbeitung und hin zu „das Netzwerk ist das Gerät“ bewegt. Ein gegenwärtiges Netzwerk kann ein Datenzentrum mit einer großen Anzahl von generischen Hardwareservervorrichtungen umfassen, die, beispielsweise, in einem Serverrack enthalten und von einem Hypervisor gesteuert sein können. Jede Hardwarevorrichtung kann eine oder mehrere Instanzen einer virtuellen Vorrichtung, beispielsweise eines Arbeitslastservers oder eines virtuellen Desktops, ausführen.
In einigen Fällen kann ein virtualisiertes Netzwerk auch eine Netzwerkfunktionsvirtualisierung (NFV, Network Function Virtualization) umfassen, die bestimmte Netzwerkfunktionen als virtuelle Einrichtungen bereitstellt. Diese Funktionen können als virtuelle Netzwerkfunktionen (VNF, Virtual Network Functions) bezeichnet werden. In der Vergangenheit konnten die durch diese VNF bereitgestellten Funktionen durch speziell zugeschnittene Hardwarediensteinrichtungen bereitgestellt sein.
Daher können in einer gegenwärtigen „Cloud“-Architektur sowohl Netzwerkendpunkte als auch eine Netzwerkinfrastruktur zumindest teilweise in einer Virtualisierungsschicht bereitgestellt sein.
Figurenliste
Die vorliegende Offenbarung erschließt sich am besten aus der folgenden ausführlichen Beschreibung, wenn diese zusammen mit den begleitenden Figuren gelesen wird. Es wird betont, dass in Übereinstimmung mit der Standardpraxis in der Industrie verschiedene Merkmale nicht notwendigerweise maßstabsgetreu gezeichnet sind und nur für Darstellungszwecke verwendet werden. Wo, explizit oder implizit, ein Maßstab gezeigt ist, stellt dieser nur ein veranschaulichendes Beispiel bereit. In anderen Ausführungsformen können die Abmessungen der verschiedenen Merkmale aus Gründen der Klarheit der Erörterung beliebig vergrößert oder verkleinert sein.

1a ist ein Blockdiagramm eines Netzwerks gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
1b ist ein Blockdiagramm von ausgewählten Komponenten eines Datenzentrums in dem Netzwerk.
2 ist ein Blockdiagramm von ausgewählten Komponenten einer Endbenutzer-Rechenvorrichtung gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
3 ist ein übersichtsartiges Blockdiagramm eines Servers gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
4a ist ein Blockdiagramm eines softwaredefinierten Netzwerks (SDN, Software-Defined Networking) gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
4b ist ein Blockdiagramm einer Netzwerkfunktionsvirtualisierung (NFV, Network Function Virtualization) gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
5 ist ein Blockdiagramm einer Plattformarchitektur gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
6 ist ein Blockdiagramm eines Prozessors gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
7 ist ein Blockdiagramm des Datenzentrums als ein Computer gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
8 ist ein Blockdiagramm, das die Verteilung von SLA gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung darstellt.
9 und 10 stellen ein Beispiel für eine Ressourcenüberwachung und eine Verteilung von QoS-Metriken (Quality of Service, Dienstgüte) gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung dar.
11 ist ein Blockdiagramm eines Host Fabric Interconnect (HFI) gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
12 - 16 sind Beispiele von SLA gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
17 ist ein Flussdiagramm einer SLA-Verteilung gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.

Ausführungsformen der Offenbarung
Die folgende Offenbarung stellt viele unterschiedliche Ausführungsformen oder Beispiele zum Implementieren unterschiedlicher Merkmale der vorliegenden Offenbarung bereit. Spezifische Beispiele von Komponenten und Anordnungen sind nachfolgend beschrieben, um die vorliegende Offenbarung zu vereinfachen. Diese sind natürlich lediglich Beispiele und sollen nicht beschränkend sein. Ferner kann die vorliegende Offenbarung Bezugszeichen und/oder Buchstaben in den verschiedenen Beispielen wiederholen. Diese Wiederholung dient der Einfachheit und Klarheit und soll selbst keine Beziehung zwischen den erörterten verschiedenen Ausführungsformen und/oder Konfigurationen vorschreiben. Unterschiedliche Ausführungsformen können verschiedene Vorteile haben, und kein spezieller Vorteil wird notwendigerweise von einer Ausführungsform gefordert.
In Cloud-Umgebungen kann das Konzept des „Eigentums“ einer spezifischen Ressource durch Service-Level-Vereinbarungen (SLA, Service Level Agreements) gefasst werden. Insbesondere kann der Cloud-Diensteanbieter einen Vertrag mit einem Kunden abschließen, um bestimmte Ressourcen verfügbar zu machen, die eine Anzahl von Kernen oder Prozessoren mit spezifischen Fähigkeiten, eine Mindestzuordnung von Speicher und Speicherplatz und eine Mindestdatenbandbreite umfassen können. Dem Kunden geht es nicht so sehr darum, welche Prozessoren zugeordnet werden, welche spezifischen Festplatten zugeordnet werden oder welche Verbindungen zugeordnet werden, solange die SLA erfüllt wird.
Wie viele Konzepte in einer Cloud-Infrastruktur kann diese SLA, zumindest teilweise, aus Details auf niedriger Ebene abstrahiert werden. Beispielsweise kann ein „Mandant“ in einem Datenzentrum eine SLA haben, die ein Terabyte an Speicher mit einer Mindestbandbreite von zwei Gigabit pro Sekunde erfordert. Allerdings kann die SLA bei der Umsetzung dessen tatsächlich eine bestimmte Ende-zu-Ende-Mindestleistung erfordern, die eine Anzahl von Zwischenressourcen in der Kette zwischen dem Prozessor und einem Speicherpool impliziert. Diese können, als nicht einschränkendes Beispiel, einen lokalen Cache, eine Host-Struktur-Schnittstelle (HFI, Host Fabric Interface), die Struktur selbst, eine HFI auf der Speichersteuerung, eine Zuordnung von Bandbreite auf der Speichersteuerung und eine Zuordnung von Datendiensten umfassen.
Jede dieser Ressourcen kann eine erforderliche Zuordnung haben, um die Gesamt-SLA zu erfüllen, und der Typ der Zuordnung kann für jede Ressource unterschiedlich sein. Um daher sicherzustellen, dass die Ende-zu-Ende-SLA erfüllt wird, kann sich eine Ressource mit einer globalen Sicht auf das System, wie etwa ein Orchestrator, jede einzelne Ressource ansehen und bestimmen, welche Mindestzuordnung erforderlich ist, um die Ende-zu-Ende-SLA zu erfüllen. Der Orchestrator kann aus dieser Sicht eine Datenstruktur aufbauen, die Mindestressourcenzuordnungen für jede der Ressourcen in der Kette umfasst. Der Orchestrator sendet diese Datenstruktur dann zu der Hostvorrichtung, die erforderlich ist, um die SLA bereitzustellen.
In einem Beispiel hat die Hostvorrichtung eine HFI mit einer SLA-Eingangs-Engine und einer SLA-Ausgangs-Engine. Die SLA-Eingangs-Engine umfasst Logikelemente zum Empfangen der Datenstruktur, einschließlich der einzelnen Ressourcenzuordnungen zum Erfüllen der SLA, vom Orchestrator. Die SLA-Ausgangs-Engine umfasst Logikelemente zum Aufgliedern der einzelnen Anforderungen und zum Verteilen dieser Anforderungen über die Struktur an die einzelnen Ressourcen.
Mandantenfähigkeit ist ein System, bei dem mehrere Anwendungen in einer gemeinsam genutzten Umgebung arbeiten, die Virtualisierung, Container, Anwendungsserver auf Java Virtual Machines (JVMs) und Ähnliches umfasst. Mandantenfähigkeit ist in Unternehmens- und Cloud-Systemen zunehmend gebräuchlich und bietet einige Vorteile. Allerdings bringt Mandantenfähigkeit auch zusätzliche Herausforderungen beim Verwalten von SLA.
Es kann, beispielsweise, von dem Fall von drei Anwendungen A, B und C ausgegangen werden, die in einer Plattform ausgeführt werden. Die erforderliche Antwortzeit für die Anwendung C ist X Millisekunden. Es kann sein, dass die Anwendung C nicht sehr CPU- oder speicherintensiv ist, aber einen gewissen dedizierten Teil des LLC (Last Level Cache, Cache auf der untersten Ebene) benötigt, um die Antwortzeit-SLA zu erfüllen. Wenn A oder B Cache-intensiv wären (selbst wenn nur vorübergehend), könnte dies dazu führen, dass die SLA für C nicht erfüllt wird, wodurch die Vorteile der Mandantenfähigkeit zunichtegemacht würden.
Ein gewisser Vorteil lässt sich durch ein Bereitstellen von QoS-Metriken (Quality of Service, Dienstgüte) für Hardware und deren Durchsetzung erzielen. Beispielsweise kann eine Cache-QoS verwendet werden, um Teile des LLC für eine bestimmte Anwendung vorzusehen, und ein Speicherbandbreiten-QoS kann für eine Speichervermittlung auf einem einzelnen Knoten verwendet werden.
Allerdings ist es in der modernen Praxis zunehmend zutreffend, dass „das Datenzentrum der Computer ist“. Verschiedene Faktoren tragen zu diesem Trend bei. Beispielsweise macht es eine Erhöhung der Datenvolumen und Anwendungsgrößen wünschenswert, Anwendungen horizontal auf mehrere Maschinen zu skalieren, anstatt vertikal auf größere oder leistungsfähigere Maschinen zu skalieren. Verbesserungen bei der Struktur und der Netzwerktechnologie machen die Verbindung zwischen Computern zu einem praktikablen Datenbus mit niedriger Latenz für solche Anwendungen. Und das Auftreten von gemeinsam genutzten Ressourcenpools sind mit der Struktur verbunden, einschließlich beispielsweise der „vernetzten Festplatten“ (NBOD, „networked bunch of disks“) als ein Speicherpool und dedizierte Speicherserver. Außerdem ist zu beachten, dass eine gemeinsam genutzte Ressource auch Software umfassen kann. Beispielsweise kann ein Datenbankserver Anforderungen von mehreren Anwendungsservern bedienen, wobei einige kritischer sind als andere.
Bei gemeinsam genutzten Ressourcen erhält die Vermittlung eine entscheidende Bedeutung. Beispielsweise kann ein 3D-Crosspoint-Speicherserver (3DXP) über die Struktur mit dem System verbunden sein, und verschiedene Anwendungen können Speicher von diesem Speicherserver anfordern und auf ihre Adressräume abbilden. Hier kann das gleiche Problem auftreten, dass eine sich falsch verhaltende Anwendung dazu führt, dass die SLA für andere Anwendungen nicht erfüllt wird. Der umkämpfte Zugang zu diesen gemeinsam genutzten Ressourcen kann zu mangelhaften oder unvorhersehbaren Verhaltensweisen oder zu nicht gleichförmigen und langen Latenz-Tails für die Ressourcenanforderung führen. Letztlich kann dies darin resultieren, dass Anforderungen mit hoher Priorität „verhungern“.
Als eine Lösung kann das Konzept von der QoS auf Knotenebene angewendet werden, um Architekturen horizontal zu skalieren (auch als Datenzentrums-QoS bekannt), dies bringt aber einige zusätzliche Herausforderungen mit sich. Auf der Knotenebene kann der Prozessor als eine Entität fungieren, die als ein einzelner Steuerpunkt dient, aber auf der Datenzentrumsebene ist der Steuerpunkt verschieden (beispielsweise kann der Steuerpunkt die HFI sein). Daher können eine neuartige Logik und neuartige Datenstrukturen in der HFI bereitgestellt werden, um die Steuerung zu implementieren.
Dies kann auch ein Protokoll oder einen Mechanismus auf Strukturebene zum Ermöglichen einer Verfügbarmachung von Ressourcen, eine Eingabe von SLA/QoS-Anforderungen und einen Mechanismus zum Verteilen des SLA-Schemas an das Datenzentrum erfordern.
Beim Beschreiben der bestehenden Architektur kann die folgende nicht erschöpfende und nicht einschränkende Liste von Definitionen vorteilhaft sein.
Caching Agents (CA) sind die Kohärenzagenten in einem Knoten, die Speicheranforderungen von den Kernen innerhalb desselben Knotens verarbeiten. In aktuellen Architekturen verwenden Kerne die SQ-Struktur (Super Queue), um Verbindungsanforderungen auf demselben Chip („on-die“) zu speichern, die zu dem CA gesendet werden (z. B. all die unterschiedlichen Lasten, die der Kern zu dem CA gesendet hat).
Home Agents (HA) sind die Knotencluster, die für das Verarbeiten von Speicheranforderungen von den Caching Agents verantwortlich sind, und sie wirken als „Home“ (Ausgangspunkt) für einen Teil des Speicheradressraums (ein Die kann mehrere Ausgangspunkte mit einer verteilten Adressraumabbildung haben). In Abhängigkeit von dem Adressraum, auf den die Anforderungen abzielen, können sie zu dem lokalen Speicher desselben Knotens gehen, können sie zu dem UPI-Agenten (Ultra Path Interconnect) (vormals QPI oder KTI genannt) gehen, um die Anforderung zu den anderen Prozessoren innerhalb derselben kohärenten Domäne weiterzuleiten, oder können sie durch die HFI zu Strukturen gehen, die sich außerhalb der kohärenten Domäne befinden. Alle durch UPI verbundenen Prozessoren gehören zur gleichen kohärenten Domäne. Ein System kann eine oder mehrere kohärente Domänen umfassen, wobei alle kohärenten Domänen über eine Strukturverbindung verbunden sind. Beispielsweise umfassen Hochleistungsrechenzentren (HPC, High Performance Computing) oder Datenzentren N Cluster oder Server, die miteinander unter Verwendung der Struktur kommunizieren können. Unter Verwendung der Struktur (wie STL) kann jede kohärente Domäne einige Adressbereiche für die anderen kohärenten Domänen verfügbar machen. Die HFI kann Zugang zu herkömmlichen Knotenarchitekturen bereitstellen und kann Zugang zu neueren Typen von Ressourcen, wie etwa zusammengefassten Ressourcen (Pool-Ressourcen) und Beschleunigern, bereitstellen.
Ein System und ein Verfahren zur Strukturunterstützung für die Dienstgüte wird jetzt unter genauerer Bezugnahme auf die beigefügten FIGUREN beschrieben. Es ist anzumerken, dass in den gesamten FIGUREN bestimmte Bezugszeichen wiederholt sein können, um anzuzeigen, dass eine bestimmte Vorrichtung oder ein bestimmter Block über die FIGUREN hinweg vollständig oder im Wesentlichen konsistent ist. Dies soll allerdings nicht irgendeine spezielle Beziehung zwischen den verschiedenen offenbarten Ausführungsformen implizieren. In bestimmten Beispielen kann eine Gattung von Elementen durch ein bestimmtes Bezugszeichen bezeichnet sein („Widget 10“), während einzelne Spezies oder Beispiele der Gattung durch eine mit Bindestrich versehene Zahl bezeichnet sein können („erstes spezifisches Widget 10-1“ und „zweites spezifisches Widget 10-2“).
1a ist ein Diagramm auf Netzwerkebene eines Netzwerks 100 gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. In dem Beispiel von 1a kann das Netzwerk 100 dazu ausgelegt sein, es einem oder mehreren Unternehmens-Clients 130 zu ermöglichen, Dienste oder Daten für einen oder mehrere Endbenutzer 120 bereitzustellen, die die Benutzereinrichtung 110 betreiben können, um über ein externes Netzwerk 172 auf Informationen oder Dienste zuzugreifen. Dieses Beispiel betrachtet eine Ausführungsform, bei der ein Cloud-Diensteanbieter 102 selbst ein Unternehmen ist, das Drittanbieter-NaaS-Dienste („Network as a Service“, Netzwerk als Dienst) für den Unternehmens-Client 130 bereitstellt. Allerdings ist dieses Beispiel nicht einschränkend. Der Unternehmens-Client 130 und der Cloud-Diensteanbieter (CSP, Cloud Service Provider) 102 können auch die gleiche oder eine verwandte Entität in geeigneten Ausführungsformen sein.
1a ist ein Diagramm auf Netzwerkebene eines Netzwerks 100 eines CSP 102 gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. In dem Beispiel von 1a kann das Netzwerk 100 dazu ausgelegt sein, es einem oder mehreren Unternehmens-Clients 130 zu ermöglichen, Dienste oder Daten für einen oder mehrere Endbenutzer 120 bereitzustellen, die die Benutzereinrichtung 110 betreiben können, um über ein externes Netzwerk 172 auf Informationen oder Dienste zuzugreifen. Dieses Beispiel betrachtet eine Ausführungsform, bei der ein Cloud-Diensteanbieter 102 selbst ein Unternehmen ist, das Drittanbieter-NaaS („Network as a Service“, Netzwerk als Dienst) für den Unternehmens-Client 130 bereitstellt. Allerdings ist dieses Beispiel nicht einschränkend. Der Unternehmens-Client 130 und der CSP 102 können auch die gleiche oder eine verwandte Entität in geeigneten Ausführungsformen sein.
Das Unternehmensnetzwerk 170 kann als nicht einschränkendes Beispiel jedes geeignete Netzwerk oder eine Kombination von einem oder mehreren Netzwerken sein, die auf einem oder mehreren geeigneten Netzwerkprotokollen arbeiten, einschließlich, beispielsweise, einer Struktur, einem lokalen Netzwerk (Local Area Network), einem Intranet, einem virtuellen Netzwerk, einem Weitbereichsnetzwerk (Wide Area Network), einem kabellosen Netzwerk, einem Mobilfunknetzwerk oder dem Internet (optionaler Zugriff über einen Proxy, eine virtuelle Maschine oder einen anderen ähnlichen Sicherheitsmechanismus). Das Unternehmensnetzwerk 170 kann auch einen oder mehrere Server, Firewalls, Router, Switches, Sicherheitseinrichtungen, Virenschutzserver oder andere hilfreiche Netzwerkvorrichtungen umfassen, die in einem Beispiel innerhalb des Datenzentrums 142 virtualisiert sein können. In dieser Darstellung ist das Unternehmensnetzwerk 170 aus Gründen der Einfachheit als ein einzelnes Netzwerk gezeigt, aber in einigen Ausführungsformen kann das Unternehmensnetzwerk 170 eine große Anzahl von Netzwerken umfassen, wie etwa ein oder mehrere mit dem Internet verbundene Unternehmens-Intranets, und kann Datenzentren an mehreren geografischen Orten umfassen. Das Unternehmensnetzwerk 170 kann auch Zugang zu einem externen Netzwerk, wie etwa dem Internet, über das externe Netzwerk 172 bereitstellen. Das externe Netzwerk 172 kann in ähnlicher Weise jeder geeignete Typ von Netzwerk sein.
Ein Datenzentrum 142 kann, beispielsweise, als ein virtuelles Cluster, das in einem Hypervisor auf mehreren rackmontierten Bladeservern ausgeführt wird, oder als ein Cluster von physischen Servern bereitgestellt sein. Das Datenzentrum 142 kann eine oder mehrere Serverfunktionen, eine oder mehrere VNF oder eine oder mehrere „Mikroclouds“ für einen oder mehrere Mandanten in einem oder mehreren Hypervisoren bereitstellen. Beispielsweise kann eine Virtualisierungsumgebung wie etwa vCenter die Möglichkeit bieten, mehrere „Mandanten“ zu definieren, wobei jeder Mandant funktional von jedem anderen Mandanten getrennt ist und jeder Mandant als eine Einzweck-Mikrocloud betrieben wird. Jede Mikrocloud kann eine eigene Funktion erfüllen und kann mehrere virtuelle Maschinen (VM) vieler unterschiedlicher Ausgestaltungen umfassen. In einigen Ausführungsformen kann das Datenzentrum 142 auch Mandantenfähigkeit bereitstellen, wobei eine einzelne Instanz einer Funktion mehreren Mandanten bereitgestellt werden kann, wobei die Daten für jeden Mandanten von den Daten für jeden anderen Mandanten isoliert sind.
Es sei außerdem darauf hingewiesen, dass eine gewisse Funktionalität der Benutzereinrichtung 110 auch über das Datenzentrum 142 bereitgestellt werden kann. Beispielsweise kann eine Mikrocloud einen Remote-Desktop-Hypervisor, wie etwa einen Citrix-Arbeitsbereich, bereitstellen, der es den Endbenutzern 120 erlaubt, sich von einem anderen Ort aus bei einem Remote-Desktop des Unternehmens anzumelden und auf Unternehmensanwendungen, -arbeitsbereiche und -daten zuzugreifen. In diesem Fall kann die UE 110 ein „Thin Client“, wie etwa ein Google Chromebook, sein, das nur auf einem auf das Wesentliche reduzierten Betriebssystem ausgeführt wird, und dennoch für den Benutzer 120 einen hilfreichen Zugang zu Unternehmensressourcen bereitstellt.
Eine oder mehrere Rechenvorrichtungen, die als eine Verwaltungskonsole 140 ausgelegt sind, können ebenfalls auf dem Unternehmensnetzwerk 170 betrieben werden. Die Verwaltungskonsole 140 kann ein spezieller Fall einer Benutzereinrichtung sein und kann eine Benutzerschnittstelle für einen Sicherheitsadministrator 150 bereitstellen, um Unternehmenssicherheits- und Netzwerkrichtlinien zu definieren, die die Verwaltungskonsole 140 auf dem Unternehmensnetzwerk 170 und über die Clientvorrichtungen 110 und das Datenzentrum 142 durchsetzen kann. In einem Beispiel kann die Verwaltungskonsole 140 ein Betriebssystem der Serverklasse ausführen, wie etwa Linux, Unix oder Windows Server. In einem anderen Fall kann die Verwaltungskonsole 140 als eine Webschnittstelle, auf einer Maschine der Desktopklasse oder über eine innerhalb des Datenzentrums 142 bereitgestellte VM bereitgestellt werden.
Das Netzwerk 100 kann über die Unternehmensgrenze 104 mit dem externen Netzwerk 172 kommunizieren. Die Unternehmensgrenze 104 kann eine physische, logische oder andere Grenze darstellen. Das externe Netzwerk 172 kann, beispielsweise, Websites, Server, Netzwerkprotokolle und andere netzwerkbasierte Dienste umfassen. Der CSP 102 kann auch einen Vertrag mit einem Sicherheitsdienste-Drittanbieter 190, wie etwa McAfee® oder einem anderen Sicherheitsdienstunternehmen, abschließen, um Sicherheitsdienste für das Netzwerk 100 bereitzustellen.
Es kann ein Ziel von Unternehmens-Clients sein, in sicherer Weise Netzwerkdienste für die Endbenutzer 120 über das Datenzentrum 142, wie durch den CSP 102 gehostet, bereitzustellen. Zu diesem Zweck kann der CSP 102 bestimmte vertragliche Dienstgütegarantien (QoS) und/oder Service-Level-Vereinbarungen (SLA) bereitstellen. Die QoS kann ein Maß für die Ressourcenleistungsfähigkeit sein und kann Faktoren wie Verfügbarkeit, Jitter, Bitrate, Durchsatz, Fehlerraten und Latenz, um nur einige zu nennen, umfassen. Eine SLA kann eine vertragliche Vereinbarung sein, die QoS-Faktoren sowie Faktoren wie mittlere Erholungszeit (MTTR, Mean Time To Recovery) und mittleren Ausfallabstand (MTBF, Mean Time Between Failure) umfassen kann. Im Allgemeinen kann eine SLA eine Vereinbarung auf höherer Ebene sein, die relevanter für eine Gesamterfahrung ist, wohingegen die QoS verwendet werden kann, um die Leistungsfähigkeit von einzelnen Komponenten zu messen. Allerdings sollte dies nicht als eine strikte Trennung zwischen QoS-Metriken und SLA-Metriken implizierend verstanden werden.
Bezug nehmend auf 1b kann der CSP 102, um vertragliche QoS- und SLA-Anforderungen zu erfüllen, eine gewisse Anzahl von Arbeitslastclustern 118 bereitstellen. In diesem Beispiel sind zwei Arbeitslastcluster, 118-1 und 118-2, gezeigt, wobei jedes bis zu 16 rackmontierte Server 146 in einem Gehäuse 148 bereitstellt. Diese Serverracks können sich gemeinsam in einem einzelnen Datenzentrum befinden, oder sie können sich in geografisch voneinander verschiedenen Datenzentren befinden. In Abhängigkeit von den vertraglichen Vereinbarungen können einige Server 146 speziell für bestimmte Unternehmens-Clients oder Mandanten vorgesehen sein, während andere gemeinsam genutzt sein können.
Die Auswahl einer Anzahl von Servern zur Bereitstellung in einem Datenzentrum ist eine wichtige Aufgabe für den CSP 102. Der CSP 102 möchte möglicherweise sicherstellen, dass es genug Server gibt, um die Netzwerkkapazität zu bewältigen, und Vorkehrungen für erwartete Vorrichtungsausfälle im Laufe der Zeit treffen. Allerdings kann eine Bereitstellung von zu vielen Servern 146 kostspielig sowohl im Hinblick auf die Hardwarekosten als auch im Hinblick auf den Stromverbrauch sein. Daher stellt der CSP 102 idealerweise genug Server 146 bereit, um all seine Unternehmens-Clients 130 zu versorgen und vertragliche QoS- und SLA-Richtwerte zu erfüllen, aber keine Kapazität zu verschwenden.
Die verschiedenen Vorrichtungen in dem Datenzentrum 142 können miteinander über eine Schaltstruktur 174 verbunden sein, die eine oder mehrere Hochgeschwindigkeits-Weiterleitungs- und/oder Schaltvorrichtungen umfassen kann. In einigen Fällen kann die Schaltstruktur 174 hierarchisch sein, mit, beispielsweise, einer Schaltstruktur 174-1, die für einen Arbeitslastcluster 118-1 zuständig ist, einer Schaltstruktur 174-2, die für einen Arbeitslastcluster 118-2 zuständig ist, und einer Schaltstruktur 174-3. Diese einfache Hierarchie wird gezeigt, um das Prinzip von hierarchischen Schaltstrukturen darzustellen, es sei jedoch darauf hingewiesen, dass dies im Vergleich zu Umsetzungen in der Praxis erheblich vereinfacht sein kann. In vielen Fällen kann die Hierarchie der Schaltstruktur 174 facettenreich und viel umfassender sein. Gebräuchliche Netzwerkarchitekturen umfassen Hub-and-Spoke-Architekturen und Leaf-Spine-Architekturen.
Die Struktur selbst kann durch jede geeignete Verbindung bereitgestellt sein, wie etwa Intel® Omnipath™, TrueScale™, Ultra Path Interconnect (UPI) (vormalig QPI oder KTI genannt), STL, Ethernet, PCI oder PCIe, um nur einige zu nennen. Einige von diesen sind für bestimmte Typen von Bereitstellungen besser geeignet als andere, und das Auswählen einer geeigneten Struktur für die unmittelbare Anwendung ist eine Aufgabe für Durchschnittsfachleute.
2 ist ein Blockdiagramm einer Clientvorrichtung 200 gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. Die Clientvorrichtung 200 kann jede geeignete Rechenvorrichtung sein. In verschiedenen Ausführungsformen kann eine „Rechenvorrichtung“ als nicht einschränkendes Beispiel ein Computer, eine Workstation, ein Server, ein Mainframe, eine virtuelle Maschine (egal ob emuliert oder auf einem „Bare-Metal“-Hypervisor), ein eingebetteter Computer, eine eingebettete Steuerung, ein eingebetteter Sensor, ein Personal Digital Assistant, ein Laptop-Computer, ein Mobiltelefon, ein IP-Telefon, ein Smartphone, ein Tablet-Computer, ein Convertible-Tablet-Computer, eine Recheneinrichtung, eine Netzwerkeinrichtung, ein Empfänger, ein tragbarer Computer, ein Taschenrechner oder jede andere elektronische, mikroelektronische oder mikroelektromechanische Vorrichtung zum Verarbeiten und Kommunizieren von Daten sein oder diese umfassen. Jede Rechenvorrichtung kann als ein Host auf dem Netzwerk benannt werden. Jede Rechenvorrichtung kann sich selbst als einen „lokalen Host“ bezeichnen, während jede dazu externe Rechenvorrichtung als ein „Remote-Host“ bezeichnet werden kann. Insbesondere kann die Benutzereinrichtung 110 eine Clientvorrichtung 200 sein, und in einem speziellen Beispiel ist die Clientvorrichtung 200 eine virtuelle Maschine, die für einen dezentralen Speicherdirektzugriff (RDMA, Remote Direct Memory Access) ausgelegt ist, wie hier beschrieben.
Die Clientvorrichtung 200 umfasst einen Prozessor 210, der mit einem Speicher 220 verbunden ist, wobei darin ausführbare Anweisungen zum Bereitstellen eines Betriebssystems 222 und zumindest Softwareabschnitte einer Anwendung 224 gespeichert sind. Andere Komponenten der Clientvorrichtung 200 umfassen einen Speicher 250, eine Netzwerkschnittstelle 260 und eine periphere Schnittstelle 240. Diese Architektur wird nur als Beispiel bereitgestellt und soll nicht ausschließend und nicht einschränkend sein. Ferner sind die verschiedenen offenbarten Teile nur als logische Unterteilungen gedacht und müssen nicht notwendigerweise physisch separate Hardware- und/oder Softwarekomponenten darstellen. Bestimmte Rechenvorrichtungen stellen den Hauptspeicher 220 und den Speicher 250, beispielsweise, in einer einzelnen physischen Speichervorrichtung bereit, und in anderen Fällen sind der Speicher 220 und/oder der Speicher 250 funktional über viele physische Vorrichtungen verteilt, wie etwa im Fall eines Datenzentrum-Speicherpools oder eines Speicherservers. Im Fall von virtuellen Maschinen oder Hypervisoren kann eine Funktion ganz oder teilweise in der Form von Software oder Firmware bereitgestellt sein, die über eine Virtualisierungsschicht ausgeführt wird, um die offenbarte logische Funktion bereitzustellen. In anderen Beispielen kann eine Vorrichtung, wie etwa eine Netzwerkschnittstelle 260, nur die Mindesthardwareschnittstellen bereitstellen, die erforderlich sind, um ihre logischen Operationen durchzuführen, und kann sich auf einen Softwaretreiber stützen, um eine zusätzliche erforderliche Logik bereitzustellen. Daher ist jeder hierin offenbarte logische Block im weitesten Sinne dazu bestimmt, ein oder mehrere logische Elemente zu umfassen, die dazu ausgelegt und betreibbar sind, um die offenbarte logische Operation dieses Blockes bereitzustellen.
Wie in dieser gesamten Beschreibung verwendet, können „logische Elemente“ Hardware (umfassend, beispielsweise, eine programmierbare Software, ASIC oder FPGA), externe Hardware (digital, analog oder gemischtes Signal), Software, Erwiderungssoftware, Dienste, Treiber, Schnittstellen, Komponenten, Module, Algorithmen, Sensoren, Komponenten, Firmware, Mikrocode, programmierbare Logik oder Objekte, die koordinieren können, um eine logische Operation zu erreichen, umfassen. Ferner sind einige logische Elemente durch ein materielles, nicht-flüchtiges computerlesbares Medium bereitgestellt, auf dem ausführbare Anweisungen gespeichert sind, um einen Prozessor anzuweisen, eine bestimmte Aufgabe durchzuführen. Ein solches nicht-flüchtiges Medium kann als nicht einschränkendes Beispiel, beispielsweise, eine Festplatte, einen Festkörperspeicher oder eine Festkörperplatte, einen Nur-Lese-Speicher (ROM), einen persistenten schnellen Speicher (PFM) (z. B. Intel® 3D Crosspoint), einen externen Speicher, eine redundante Anordnung unabhängiger Platten (RAID, Redundant Array of Independent Disks), eine redundante Anordnung unabhängiger Knoten (RAIN, Redundant Array of Independent Nodes), einen netzwerkgebundenen Speicher (NAS, Network-Attached Storage), einen optischen Speicher, ein Bandlaufwerk, ein Sicherungssystem, einen Cloud-Speicher oder jede Kombination des Vorgenannten umfassen. Ein solches Medium kann auch Anweisungen umfassen, die in ein feldprogrammierbares Gate-Array (FPGA, Field-Programmable Gate Array) programmiert oder in Hardware auf einem anwendungsspezifischen Schaltkreis (ASIC, Application-Specific Integrated Circuit) oder Prozessor codiert sind.
In einem Beispiel ist der Prozessor 210 über einen Speicherbus 270-3, der als Beispiel, beispielsweise, ein DMA-Bus (Direct Memory Access) für einen direkten Speicherzugriff sein kann, wenngleich andere Speicherarchitekturen möglich sind, einschließlich solcher, bei denen der Speicher 220 über einen Systembus 270-1 oder irgendeinen anderen Bus mit dem Prozessor 210 kommuniziert, kommunikativ mit dem Speicher 220 gekoppelt. In Datenzentrumsumgebungen kann der Speicherbus 270-3 die Struktur sein oder diese umfassen.
Der Prozessor 210 kann über einen Systembus 270-1 kommunikativ mit anderen Vorrichtungen gekoppelt sein. Wie in dieser gesamten Beschreibung verwendet, umfasst ein „Bus“ jede/s/n kabelgebundene oder kabellose Verbindungsleitung, Netzwerk, Verbindung, Struktur, Bündel, Einzelbus, Mehrfachbusse, Crossbar-Netzwerk, einstufige Netzwerk, mehrstufige Netzwerk oder andere Leitungsmedien, die zum Transportieren von Daten, Signalen oder Stromversorgung zwischen Teilen einer Rechenvorrichtung oder zwischen Rechenvorrichtungen betreibbar sind. Es ist anzumerken, dass diese Verwendungen nur als nicht einschränkendes Beispiel offenbart werden und dass einige Ausführungsformen einen oder mehrere der vorgenannten Busse auslassen können, während andere zusätzliche oder andere Busse einsetzen können.
In verschiedenen Beispielen kann ein „Prozessor“ jede Kombination von Logikelementen umfassen, die dazu betreibbar sind, Anweisungen auszuführen, egal ob aus dem Speicher geladen oder direkt in Hardware implementiert, einschließlich, als nicht einschränkendes Beispiel, eines Mikroprozessors, eines digitalen Signalprozessors (DSP), eines feldprogrammierbaren Gate-Arrays (FPGA, Field-Programmable Gate Array), einer Grafikverarbeitungseinheit (GPU, Graphics Processing Unit), einer programmierbaren Logikanordnung (PLA), eines anwendungsspezifischen integrierten Schaltkreises (ASIC, Application-Specific Integrated Circuit) oder eines Prozessors einer virtuellen Maschine. In bestimmten Architekturen kann ein Mehrkernprozessor vorgesehen sein, wobei in diesem Fall der Prozessor 210 je nach Situation als nur ein Kern eines Mehrkernprozessors behandelt werden kann oder als der gesamte Mehrkernprozessor behandelt werden kann. In einigen Ausführungsformen können auch ein oder mehrere Koprozessoren für spezialisierte oder Unterstützungsfunktionen vorgesehen sein.
Der Prozessor 210 kann in einer DMA-Konfiguration über den Bus 270-3 mit dem Speicher 220 verbunden sein. Zum Vereinfachen dieser Offenbarung wird der Speicher 220 als ein einzelner logischer Block offenbart, kann aber in einer physischen Ausführungsform einen oder mehrere Blöcke jeder geeigneten flüchtigen oder nicht-flüchtigen Speichertechnologie oder von geeigneten flüchtigen oder nicht-flüchtigen Speichertechnologien umfassen, einschließlich, beispielsweise, Direktzugriffsspeicher mit doppelter Datenrate (DDR-RAM, Double Data Rate Random Access Memory), statischen Direktzugriffsspeicher (SRAM, Static Random Access Memory), dynamischen Direktzugriffsspeicher (DRAM, Dynamic Random Access Memory), persistenten schnellen Speicher (PFM) (wie etwa Intel® 3D Crosspoint oder 3DXP), Cache, L1- oder L2-Speicher, On-Chip-Speicher, Register, Flash, ROM, optische Medien, virtuelle Speicherbereiche, magnetischen oder Bandspeicher oder Ähnliches. Der Speicher 220 kann lokal bereitgestellt sein oder kann an einem anderen Ort bereitgestellt sein, wie etwa im Fall eines Datenzentrums mit einem 3DXP-Speicherserver. In bestimmten Ausführungsformen kann der Speicher 220 einen flüchtigen Hauptspeicher mit relativ niedriger Latenz umfassen, während der Speicher 250 einen nicht-flüchtigen Speicher mit relativ höherer Latenz umfassen kann. Allerdings müssen der Speicher 220 und der Speicher 250 keine physisch getrennten Vorrichtungen sein und können in einigen Beispielen einfach eine logische Funktionstrennung darstellen. Diese Linien können insbesondere in Fällen verschwommen sein, in denen der einzige Langzeitspeicher ein batteriegestützter RAM ist oder in denen der Hauptspeicher als ein PFM bereitgestellt ist. Es sei auch darauf hingewiesen, dass, wenngleich DMA als nicht einschränkendes Beispiel offenbart ist, DMA nicht das einzige mit dieser Beschreibung konsistente Protokoll ist und dass andere Speicherarchitekturen verfügbar sind.
Ein Betriebssystem 222 kann bereitgestellt sein, wenngleich es nicht in allen Ausführungsformen erforderlich ist. Beispielsweise arbeiten einige eingebettete Systeme aus Gründen der Geschwindigkeit, Effizienz und Ressourcenschonung auf „Bare Metal“. Allerdings ist es in gegenwärtigen Systemen selbst für minimalistische eingebettete Systeme gebräuchlich, eine gewisse Art von Betriebssystem zu enthalten. Wo es bereitgestellt ist, kann das Betriebssystem 222 jedes geeignete Betriebssystem umfassen, wie etwa Microsoft Windows, Linux, Android, Mac OSX, Apple iOS, Unix oder Ähnliches. Einige der Vorgenannten können auf einem Typ von Vorrichtung häufiger verwendet werden als andere. Beispielsweise wird für Desktop-Computer oder technische Workstations mit höherer Wahrscheinlichkeit Microsoft Windows, Linux, Unix oder Mac OSX verwendet. Auf Laptop-Computern, die üblicherweise eine tragbare, gebrauchsfertige Vorrichtung mit weniger Anpassungsoptionen sind, wird möglicherweise mit höherer Wahrscheinlichkeit Microsoft Windows oder Mac OSX ausgeführt. Auf mobilen Vorrichtungen wird möglicherweise mit höherer Wahrscheinlichkeit Android oder iOS ausgeführt. Eingebettete Vorrichtungen verwenden häufig ein eingebettetes Linux oder ein dediziertes eingebettetes Betriebssystem, wie etwa VxWorks. Allerdings sollen diese Beispiele nicht einschränkend sein.
Der Speicher 250 kann jede Spezies des Speichers 220 sein oder kann eine separate nicht-flüchtige Speichervorrichtung sein. Der Speicher 250 kann ein oder mehrere nicht-flüchtige computerlesbare Medien umfassen, einschließlich, als nicht einschränkendes Beispiel, eine Festplatte, ein Festkörperlaufwerk, einen externen Speicher, eine redundante Anordnung unabhängiger Platten (RAID, Redundant Array of Independent Disks), eine redundante Anordnung unabhängiger Knoten (RAIN, Redundant Array of Independent Nodes), einen netzwerkgebundenen Speicher (NAS, Network-Attached Storage), einen optischen Speicher, ein Bandlaufwerk, ein Sicherungssystem, einen Cloud-Speicher oder jede Kombination des Vorgenannten. Der Speicher 250 kann eine Datenbank oder Datenbanken oder in anderen Konfigurationen gespeicherte Daten sein oder darin enthalten und kann eine gespeicherte Kopie von operativer Software umfassen, wie etwa das Betriebssystem 222 und Softwareabschnitte der Anwendung 224. In einigen Beispielen kann der Speicher 250 ein nicht-flüchtiges computerlesbares Speichermedium sein, das Hardwareanweisungen oder Logik, codiert als Prozessoranweisungen oder auf einem ASIC, umfasst. Viele andere Konfigurationen sind ebenfalls möglich und sollen im breiteren Schutzumfang dieser Beschreibung enthalten sein.
Die Netzwerkschnittstelle 260 kann bereitgestellt sein, um die Clientvorrichtung 200 mit einem kabelgebundenen oder kabellosen Netzwerk kommunikativ zu koppeln. Ein „Netzwerk“ wie in dieser gesamten Beschreibung verwendet, kann jede kommunikative Plattform oder jedes kommunikative Medium umfassen, die bzw. das betreibbar ist, um Daten oder Informationen innerhalb von oder zwischen Rechenvorrichtungen auszutauschen, einschließlich, als nicht einschränkendes Beispiel, Ethernet, WiFi, eine Struktur, ein lokales Ad-hoc-Netzwerk, eine Internetarchitektur, die Rechenvorrichtungen befähigt, elektronisch zu interagieren, ein analoges Telefonsystem (POTS, Plain Old Telephone System), das Rechenvorrichtungen verwenden können, um Transaktionen durchzuführen, bei denen sie von menschlichen Bedienern unterstützt werden können oder bei denen sie manuell Daten in ein Telefon oder eine andere geeignete elektronische Einrichtung eingeben können, jedes Paketdatennetzwerk (PDN), das eine Kommunikationsschnittstelle oder einen Austausch zwischen zwei beliebigen Knoten in einem System bietet, oder jedes Nahbereichsnetzwerk (LAN, Local Area Network), Metropolitan Area Network (MAN), Weitbereichsnetzwerk (WAN, Wide Area Network), kabellose Nahbereichsnetzwerk (WLAN, Wireless Local Area Network), virtuelle private Netzwerk (VPN, Virtual Private Network), Intranet oder jede andere geeignete Architektur oder jedes andere geeignete System, die bzw. das eine Kommunikation in einer Netzwerk- oder Telefonumgebung ermöglicht. Es ist anzumerken, dass die Netzwerkschnittstelle 260 in bestimmten Ausführungsformen eine Host-Struktur-Schnittstelle (HFI, Host Fabric Interface) sein kann oder eine solche umfassen kann.
Die Anwendung 224 ist in einem Beispiel betreibbar, um computerimplementierte Verfahren durchzuführen, wie in dieser Beschreibung beschrieben. Die Anwendung 224 kann ein oder mehrere materielle nicht-flüchtige computerlesbare Medien umfassen, auf denen ausführbare Anweisungen gespeichert sind, die betreibbar sind, um einen Prozessor anzuweisen, eine Anwendung 224 bereitzustellen. Die Anwendung 224 kann auch einen Prozessor mit entsprechenden Speicheranweisungen umfassen, die den Prozessor anweisen, das gewünschte Verfahren auszuführen. Wie in dieser gesamten Beschreibung verwendet, umfasst eine „Engine“ jede Kombination von einem oder mehreren Logikelementen von ähnlichen oder unterschiedlichen Spezies, die betreibbar und dazu ausgelegt sind, ein oder mehrere Verfahren oder Funktionen der Engine durchzuführen. In einigen Fällen kann die Anwendung 224 eine spezielle integrierte Schaltung zum Durchführen eines Verfahrens oder eines Teils desselben umfassen und kann auch Softwareanweisungen umfassen, die betreibbar sind, um einen Prozessor anzuweisen, das Verfahren durchzuführen. In einigen Fällen kann die Anwendung 224 als ein „Daemon“-Prozess ausgeführt werden. Ein „Daemon“ kann jedes Programm oder jede Serie von ausführbaren Anweisungen umfassen, egal ob in Hardware, Software, Firmware oder einer Kombination davon implementiert, die als ein Hintergrundprozess, ein TSR-Programm (Terminate-and-Stay-Resident), ein Dienst, eine Systemerweiterung, ein Steuerfeld, eine Bootup-Prozedur, eine BIOS-Unterroutine (Basic Input/Output System, Ein-/Ausgabe-System) oder jedes ähnliche Programm, das ohne direkte Benutzerinteraktion arbeitet, ausgeführt wird. In bestimmten Ausführungsformen können Daemon-Prozesse mit erhöhten Privilegien in einem „Treiberraum“ in Verbindung mit Ring 0, 1 oder 2 in einer Schutzringarchitektur ausgeführt werden. Es sei auch darauf hingewiesen, dass die Anwendung 224 als nicht einschränkendes Beispiel auch andere Hardware und Software umfassen kann, einschließlich Konfigurationsdateien, Registrierungseinträge und interaktive oder Benutzermodussoftware.
In einem Beispiel umfasst die Anwendung 224 ausführbare Anweisungen, die auf einem nicht-flüchtigen Medium gespeichert und betreibbar sind, um ein Verfahren gemäß dieser Beschreibung durchzuführen. Zu einem angemessenen Zeitpunkt, wie etwa beim Booten der Clientvorrichtung 200 oder bei einem Befehl von dem Betriebssystem 222 oder einem Benutzer 120, kann der Prozessor 210 eine Kopie der Anweisungen von dem Speicher 250 abrufen und diese in den Speicher 220 laden. Der Prozessor 210 kann dann iterativ die Anweisungen der Anwendung 224 ausführen, um das gewünschte Verfahren bereitzustellen.
Die periphere Schnittstelle 240 kann dazu ausgelegt sein, eine Schnittstelle mit jeder Zusatzvorrichtung zu bilden, die eine Verbindung zu der Clientvorrichtung 200 herstellt, die aber nicht notwendigerweise ein Teil der Kernarchitektur der Clientvorrichtung 200 ist. Eine periphere Vorrichtung kann betreibbar sein, um eine erweiterte Funktionalität für die Clientvorrichtung 200 bereitzustellen, und kann oder kann nicht vollständig von der Clientvorrichtung 200 abhängig sein. In einigen Fällen kann eine periphere Vorrichtung eine eigenständige Rechenvorrichtung sein. Periphere Vorrichtungen können als nicht einschränkendes Beispiel Eingabe- und Ausgabevorrichtungen, wie etwa Anzeigen, Terminals, Drucker, Tastaturen, Mäuse, Modems, Datenanschlüsse (z. B. seriell, parallel, Universal Serial Bus (USB), Firewire oder Ähnliches), Netzwerksteuerungen, optische Medien, externen Speicher, Sensoren, Wandler, Aktuatoren, Steuerungen, Datenerfassungsbusse, Kameras, Mikrofone, Lautsprecher oder externen Speicher umfassen.
In einem Beispiel umfassen periphere Vorrichtungen den Anzeigeadapter 242, den Audiotreiber 244 und den Eingabe-/Ausgabetreiber (EA) 246. Der Anzeigeadapter 242 kann dazu ausgelegt sein, eine menschlich lesbare visuelle Ausgabe bereitzustellen, wie etwa eine Befehlszeilenschnittstelle (CLI, Command-Line Interface) oder einen grafischen Desktop, wie etwa einen Microsoft Windows- und Apple-OSX-Desktop oder einen Unix/Linux X Window System-basierten Desktop. Der Anzeigeadapter 242 kann als nicht einschränkendes Beispiel einen Ausgang in jedem geeigneten Format bereitstellen, wie etwa einen Koaxialausgang, Composite Video, Component Video, Video Graphics Array (VGA) oder digitale Ausgänge, wie etwa Digital Video Interface (DVI) oder High-Definition Multimedia Interface (HDMI). In einigen Beispielen kann der Anzeigeadapter 242 eine Hardwaregrafikkarte umfassen, die ihren eigenen Speicher und ihre eigene Grafikverarbeitungseinheit (GPU, Graphics Processing Unit) haben kann. Der Audiotreiber 244 kann eine Schnittstelle für hörbare Klänge bereitstellen und kann, in einigen Beispielen, eine Hardwaresoundkarte umfassen. Der Tonausgang kann als nicht einschränkendes Beispiel in einem analogen Format (wie etwa einer 3,5-mm-Stereobuchse), in einem Komponentenstereoformat („RCA“) oder in einem digitalen Audioformat, wie etwa dem Sony/Philips Digital Interface Format (S/PDIF), AES3, AES47, HDMI, USB, Bluetooth oder Wi-Fi-Audio,bereitgestellt sein. Es ist anzumerken, dass in Ausführungsformen, in denen die Clientvorrichtung 200 eine virtuelle Maschine ist, periphere Vorrichtungen entfernt durch eine Vorrichtung bereitgestellt sein können, die zum Zugriff auf die virtuelle Maschine verwendet wird.
3 ist ein Blockdiagramm einer Vorrichtung der Serverklasse 300 gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. Der Server 300 kann jede geeignete Rechenvorrichtung sein, wie im Zusammenhang mit 2 beschrieben. Im Allgemeinen können die Definitionen und Beispiele von 2 als gleichermaßen auf 3 anwendbar angesehen werden, sofern nicht ausdrücklich etwas anderes angegeben ist. Der Server 300 wird hierin separat beschrieben, um darzustellen, dass in bestimmten Ausführungsformen logische Operationen im Einklang mit einem Client-Server-Modell aufgeteilt werden können, wobei die Clientvorrichtung 200 bestimmte lokalisierte Aufgaben bereitstellt, während der Server 300 bestimmte andere zentralisierte Aufgaben bereitstellt.
Es ist anzumerken, dass der Server 300 von 3 insbesondere die klassischen Aspekte der „Von-Neumann-Architektur“ von Server 300 darstellt, wobei der Schwerpunkt auf Funktionsblöcken liegt. Andere FIGUREN hierin (z. B. die 4a, 4b und 5 weiter unten) können andere Aspekte einer Client- oder Servervorrichtung darstellen, wobei ein größerer Schwerpunkt auf Virtualisierungsaspekten liegt. Diese dargestellten Ausführungsformen sollen weder gegenseitig ausschließend sein noch eine erforderliche Unterscheidung ableiten. Stattdessen sollen die verschiedenen Ansichten und Diagramme unterschiedliche Perspektiven und Aspekte dieser Vorrichtungen darstellen.
In einem bestimmten Beispiel kann die Servervorrichtung 300 ein Speicherserver sein, wie hier dargestellt.
Der Server 300 umfasst einen Prozessor 310, der mit einem Speicher 320 verbunden ist, in dem ausführbare Anweisungen zum Bereitstellen eines Betriebssystems 322 und zumindest Softwareabschnitte einer Speicherserverengine 324 gespeichert sind. Andere Komponenten des Servers 300 umfassen einen Speicher 350 und eine Host-Struktur-Schnittstelle 360. Wie in 2 beschrieben, kann jeder logische Block durch ein oder mehrere ähnliche oder unterschiedliche Logikelemente bereitgestellt sein.
In einem Beispiel ist der Prozessor 310 über den Speicherbus 370-3, der, beispielsweise, ein DMA-Bus (Direct Memory Access, Direktspeicherzugriff) sein kann, kommunikativ mit dem Speicher 320 gekoppelt. Der Prozessor 310 kann über einen Systembus 370-1 kommunikativ mit anderen Vorrichtungen gekoppelt sein.
Der Prozessor 310 kann in einer DMA-Konfiguration über den DMA-Bus 370-3 oder über jede andere geeignete Speicherkonfiguration mit dem Speicher 320 verbunden sein. Wie in 2 erörtert, kann der Speicher 320 ein oder mehrere Logikelemente jedes geeigneten Typs umfassen. Der Speicher 320 kann einen persistenten schnellen Speicher, wie etwa 3DXP oder Ähnliches, umfassen.
Der Speicher 350 kann jede Spezies des Speichers 320 sein oder kann eine separate Vorrichtung sein, wie in Verbindung mit dem Speicher 250 von 2 beschrieben. Der Speicher 350 kann eine Datenbank oder Datenbanken oder in anderen Konfigurationen gespeicherte Daten sein oder darin enthalten und kann eine gespeicherte Kopie von operativer Software umfassen, wie etwa das Betriebssystem 322 und Softwareabschnitte der Speicherserverengine 324.
Die Host-Struktur-Schnittstelle 360 kann bereitgestellt sein, um den Server 300 mit einem kabelgebundenen oder kabellosen Netzwerk, einschließlich einer Host-Struktur, kommunikativ zu koppeln. Eine Host-Struktur kann eine geschaltete Schnittstelle zum kommunikativen Koppeln von Knoten oder einer Cloud oder Cloud-ähnlichen Umgebung umfassen. Die HFI 360 wird hier als Beispiel verwendet, wenngleich jede andere geeignete Netzwerkschnittstelle (wie in Verbindung mit der Netzwerkschnittstelle 260 erörtert) verwendet werden kann.
Die Speicherserverengine 324 ist eine Engine, wie in 2 beschrieben, und umfasst, in einem Beispiel, ein oder mehrere Logikelemente, die betreibbar sind, um computerimplementierte Verfahren auszuführen, wie in dieser Beschreibung beschrieben. Softwareabschnitte der Speicherserverengine 324 können als ein Daemon-Prozess ausgeführt sein.
Der Speicherserverengine 324 kann ein oder mehrere nicht-flüchtige computerlesbare Medien umfassen, auf denen ausführbare Anweisungen gespeichert sind, die betreibbar sind, um einen Prozessor anzuweisen, die Speicherserverengine 324 bereitzustellen. Zu einem angemessenen Zeitpunkt, wie etwa beim Booten des Servers 300 oder bei einem Befehl von dem Betriebssystem 322 oder einem Benutzer 120 oder einem Sicherheitsadministrator 150, kann der Prozessor 310 eine Kopie der Speicherserverengine 324 (oder Softwareabschnitte davon) von dem Speicher 350 abrufen und diese in den Speicher 320 laden. Der Prozessor 310 kann dann iterativ die Anweisungen der Speicherserverengine 324 ausführen, um das gewünschte Verfahren bereitzustellen.
4a ist ein Blockdiagramm eines softwaredefinierten Netzwerks 400. Bei softwaredefinierten Netzwerken (SDN) ist eine Datenebene von einer Steuerebene getrennt, um bestimmte Vorteile umzusetzen. Ein SDN ist nur eine Art der Virtualisierung, die hier gezeigt ist, um eine Option für eine Netzwerkeinrichtung darzustellen.
Die Netzwerkfunktionsvirtualisierung, dargestellt in FIGUR 4b, ist eine zweite, nicht einschränkende Art der Netzwerkvirtualisierung, die häufig als eine Erweiterung oder Verbesserung des SDN behandelt wird, manchmal aber auch als eine separate Entität behandelt wird. Die Netzwerkfunktionsvirtualisierung (NFV, Network Function Virtualization) war ursprünglich als ein Verfahren zum Bereitstellen verringerter Investitionskosten (Capex, Capital expenditure) und Betriebskosten (Opex, Operating expenses) für Telekommunikationsdienste vorgesehen, die sich stark auf schnelle Diensteinrichtungen für einen einzelnen Zweck stützten. Ein wichtiges Merkmal der NFV besteht darin, proprietäre Hardwareeinrichtungen für spezielle Zwecke durch virtuelle Einrichtungen zu ersetzen, die innerhalb einer virtualisierten Umgebung auf COTS-Hardware (Commercial Off-The-Shelf) ausgeführt werden. Zusätzlich zu Capex- und Opex-Einsparungen stellt die NFV ein agileres und anpassbareres Netzwerk bereit. Wenn sich die Netzwerklasten ändern, können virtuelle Netzwerkfunktionen (VNF, Virtual Network Functions) bereitgestellt oder entfernt werden, um die Netzwerkanforderungen zu erfüllen. Beispielsweise können in Zeiten hoher Last mehr Lastausgleichs-VNF bereitgestellt werden, um Datenverkehr auf mehr Arbeitslastserver (die selbst virtuelle Maschinen sein können) zu verteilen. In Zeiten, in denen mehr verdächtiger Datenverkehr auftritt, sind möglicherweise zusätzliche Firewalls oder DPI-Einrichtungen (Deep Packet Inspection) erforderlich.
Da die NFV als Telekommunikationsfunktion eingeführt wurde, sind viele NFV-Instanzen auf die Telekommunikation fokussiert. Allerdings ist die NFV nicht auf Telekommunikationsdienste beschränkt. In einem weiten Sinne umfasst die NFV eine oder mehrere VNF, die innerhalb einer Netzwerkfunktionsvirtualisierungsinfrastruktur (NFVI, Network Function Virtualization Infrastructure) ausgeführt werden. Häufig sind die VNF Inline-Dienstfunktionen, die von Arbeitslastservern oder anderen Knoten getrennt sind (in vielen Fällen wurden Arbeitslastfunktionen längst virtualisiert). Diese VNF können zu einer Dienstkette zusammengekettet werden, die durch ein virtuelles Unternetzwerk definiert sein kann und die eine serielle Reihe von Netzwerkdiensten umfassen kann, die die Hintergrundarbeiten bereitstellen können, wie etwa Sicherheit, Protokollierung, Rechnungsstellung und Ähnliches. In einem Beispiel passiert ein eingehendes Paket eine Kette von Diensten in einer Dienstkette, wobei einer oder mehrere der Dienste durch eine VNF bereitgestellt werden, während in der Vergangenheit möglicherweise jede dieser Funktionen durch spezielle Hardware in einer physischen Diensteinrichtung bereitgestellt wurde. Da NFV bereitgestellt und entfernt werden können, um den Bedarf zu decken, kann die Zuordnung von Hardware und anderen Ressourcen effizienter gestaltet werden. Verarbeitungsressourcen können zugeordnet werden, um den höchsten Bedarf zu decken, während bei physischen Diensteinrichtungen jede ungenutzte Kapazität bei einer Einrichtung einfach verschwendet ist, und ein Erhöhen der Kapazität zum Decken des Bedarfs erforderte ein Anschließen einer physischen (teuren) maßgeschneiderten Diensteinrichtung.
Die Darstellungen der FIGUREN 4a und 4b können als funktionaler betrachtet werden, während im Vergleich dazu die Darstellung von 1 eher ein logisches Layout des Netzwerks auf einer hohen Ebene sein kann. Es versteht sich allerdings, dass das SDN 400 (4a), die NFVI 404 (4b) und das Unternehmensnetzwerk 100 das gleiche Netzwerk sein können oder separate Netzwerke sein können.
In 4a kann das SDN 400 eine SDN-Steuerung 410, mehrere Netzwerkvorrichtungen 430 und mehrere Hostvorrichtungen 440 umfassen. Einige oder alle von der SDN-Steuerung 410, den Netzwerkvorrichtungen 430 und den Hostvorrichtungen 440 können innerhalb des Arbeitslastclusters 142 von 1 ausgeführt sein oder können anderweitig einen Teil des Unternehmensnetzwerks 170 bilden.
Das SDN 400 wird durch eine SDN-Steuerung 410 gesteuert. Die SDN-Steuerung 410 ist kommunikativ mit mehreren Netzwerkvorrichtungen 430 gekoppelt. Insbesondere sind die ND1 430-1, die ND2 430-2 und die ND5 430-5 direkt kommunikativ mit der SDN-Steuerung 410 gekoppelt. Netzwerkvorrichtungen und die ND3 430-3 und die ND4 430-4 sind nicht direkt mit der SDN-Steuerung 410 gekoppelt sondern sind stattdessen über die Zwischenvorrichtungen wie etwa die ND2 430-2 und die ND5 430-5 gekoppelt.
Einige Netzwerkvorrichtungen 430 sind auch direkt kommunikativ mit den Hostvorrichtungen 440 gekoppelt. Insbesondere ist die Netzwerkvorrichtung ND1 direkt mit dem Host A 440-1 gekoppelt, der die IP-Adresse 10.0.0.10 und die MAC-Adresse FA: 16:3:01:61:8 hat. Die Netzwerkvorrichtung ND2 430-2 ist direkt mit dem Host B 440-2 gekoppelt, der die IP-Adresse 10.0.0.20 und die MAC-Adresse FA: 16:3:01:63: B3 hat. Die Netzwerkvorrichtung ND5 430-5 ist direkt mit dem Host D 440-3 gekoppelt, der die IP-Adresse 10.0.0.30 und die MAC-Adresse FA:16:3:01:54:83 hat.
Die Netzwerkvorrichtungen 430 können dazu ausgelegt sein, eine Vielzahl von Netzwerkfunktionen durchzuführen, wie etwa, als nicht einschränkendes Beispiel, Lastausgleich, Firewall, DPI (Deep Packet Inspection), DNS, Virenschutz oder jede andere geeignete Netzwerkfunktion. Die spezielle Anordnung von Verbindungen zwischen den Netzwerkvorrichtungen 430 und von den Netzwerkvorrichtungen 430 zu den Hostvorrichtungen 440 kann durch die spezielle Netzwerkkonfiguration und den Bedarf bestimmt werden. Daher sollte die spezifische Konfiguration von 4a nur als ein veranschaulichendes Beispiel verstanden werden.
Jede Netzwerkvorrichtung 430 kann mehrere Eintritts- und/oder Austrittsschnittstellen haben, wie etwa physische Ethernet- oder Strukturanschlüsse. In einem Beispiel kann jede Schnittstelle eine Beschriftung oder einen neuen Namen haben, wie etwa P1, P2, P3, P4, P5 und so weiter. Daher können bestimmte Aspekte des Netzwerklayouts durch ein Prüfen, welche Vorrichtungen an welcher Schnittstelle angeschlossen sind, bestimmt werden. Beispielsweise hat die Netzwerkvorrichtung ND1 430-1 eine Eintrittsschnittstelle zum Empfangen von Anweisungen und Kommunizieren mit der SDN-Steuerung 410. Die ND1 430-1 hat auch eine Schnittstelle P1, die kommunikativ mit dem Host A 440-1 gekoppelt ist. Die ND1 430-1 hat eine Schnittstelle P2, die kommunikativ mit der ND2 430-2 gekoppelt ist. Im Falle der ND2 430-2 ist sie auch mit der ND1 430-1 an ihrer eigenen Schnittstelle P2 gekoppelt und ist über die Schnittstelle P1 mit dem Host B 440-2 gekoppelt. Die ND2 430-2 ist über die Schnittstellen P3 bzw. P4 kommunikativ mit den Zwischenvorrichtungen ND3 430-3 und ND4 430-4 gekoppelt. Zusätzliche Schnittstellendefinitionen sind in der gesamten Figur zu sehen.
Eine Fließtabelle kann für Datenverkehr definiert werden, wenn dieser von einer Schnittstelle zu einer anderen fließt. Diese Fließtabelle wird verwendet, sodass eine Netzwerkvorrichtung, wie etwa die ND2 430-2, nach dem Empfangen eines Pakets bestimmen kann, wohin dieses als Nächstes gesendet werden soll.
Beispielsweise können die folgenden Fließtabellen für ND1 430-1 - ND4 430-4 definiert werden. Table 1. ND1-Flussregel

Eintrittsschnitts teile Ursprun gs-MAC Ziel-Mac Ursprun gs-IP Ziel- IP Akti on

P1 BELIEBI G fa:16:3e:01:5 4:a3 BELIEBI G 10.0.0. 30 P2

Table 2. ND2-Flussregel

Eintrittsschnittstelle Ursprungs-MAC Ziel-Mac Ursprungs-IP Ziel- IP Aktion

P2 BELIEBI G fa:16:3e:01:5 4:a3 BELIEBI G 10.0.0. 30 P4

Table 3. ND3-Flussregel

Eintrittsschnittstelle Ursprungs-MAC Ziel-Mac Ursprungs-IP Ziel- IP Aktion

P1 BELIEBI G fa:16:3e:01:5 4:a3 BELIEBI G 10.0.0. 30 P3

Table 4. ND4-Flussregel

Eintrittsschnittstelle Ursprungs-MAC Ziel-Mac Ursprungs-IP Ziel- IP Aktion

P3 BELIEBI G fa:16:3e:01:5 4:a3 BELIEBI G 10.0.0. 30 P1
4b ist ein Blockdiagramm einer Netzwerkfunktionsvirtualisierungsarchitektur (NFV, Network Function Virtualization) gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. Wie das SDN ist die NFV eine Untermenge der Netzwerkvirtualisierung. Daher kann das Netzwerk, wie in 4b dargestellt, anstatt von oder zusätzlich zu dem Netzwerk von 4a definiert werden. Mit anderen Worten können sich bestimmte Abschnitte des Netzwerks auf das SDN stützen, während sich andere Abschnitte (oder die gleichen Abschnitte) auf die NFV stützen können.
In dem Beispiel von 4b koordiniert ein NFV-Orchestrator 402 eine Anzahl von VNF, die auf einer NFVI 404 ausgeführt werden. Die NFV erfordert eine wichtige Ressourcenverwaltung, wie etwa ein Zuordnen eines sehr großen Pools an Rechenressourcen zwischen geeigneten Anzahlen von Instanzen von jeder VNF, ein Verwalten von Verbindungen zwischen VNF, ein Bestimmen, wie viele Instanzen von jeder VNF zuzuordnen sind, und ein Verwalten von Speicher, Speicherplatz und Netzwerkverbindungen. Dies kann eine komplexe Softwareverwaltung erfordern, wodurch sich die Notwendigkeit eines NFV-Orchestrators 402 ergibt.
Es ist anzumerken, dass der VNF-Orchestrator 402 selbst üblicherweise virtualisiert ist (anstatt einer Hardwareeinrichtung für einen speziellen Zweck). Der NFV-Orchestrator 402 kann innerhalb eines bestehenden SDN-Systems integriert sein, wobei ein Betriebsunterstützungssystem (OSS, Operations Support System) das SDN verwaltet. Dieses kann mit Cloud-Ressourcenverwaltungssystemen (z. B. OpenStack) interagieren, um eine NVF-Orchestrierung bereitzustellen. Es gibt viele kommerziell erhältliche, handelsübliche, proprietäre und Open-Source-Lösungen für die NFV-Orchestrierung und -Verwaltung (manchmal als NFV MANO bezeichnet). Zusätzlich zu dem NFV-Orchestrator 402 kann NFV MANO auch Funktionen umfassen, wie etwa eine virtualisierte Infrastrukturverwaltung (VIM, Virtualized Infrastructure Management) und einen VNF-Manager.
Eine NFVI 404 kann die Hardware, Software und andere Infrastruktur umfassen, um ein Ausführen der VNF zu ermöglichen. Dies kann, beispielsweise, ein Rack oder mehrere Racks mit Blade- oder Slotservern (einschließlich, z. B., Prozessoren, Speicher und Speicherplatz), ein oder mehrere Datenzentren, andere Hardwareressourcen, die über einen oder mehrere geografische Orte verteilt sind, Hardwareswitches oder Netzwerkschnittstellen umfassen. Eine NFVI 404 kann auch die Softwarearchitektur umfassen, die das Ausführen von Hypervisoren und deren Verwaltung durch den NFV-Orchestrator 402 ermöglicht. Die NFVI 402 kann NFVI-Einwählknoten (Points of Presence, NFVI-PoPs) umfassen, wobei die VNF durch den Betreiber bereitgestellt werden.
Auf der NFVI 404 wird eine Anzahl von virtuellen Maschinen ausgeführt, von denen jede, in diesem Beispiel, eine VNF ist, die eine virtuelle Diensteinrichtung bereitstellt. Diese umfassen, als nicht einschränkende und veranschaulichende Beispiele, die VNF 1 410, die eine Firewall ist, die VNF 2 412, die ein Angrifferkennungssystem ist, die VNF 3 414, die ein Lastausgleicher ist, die VNF 4 416, die ein Router ist, die VNF 5 418, die ein Session Border Controller ist, die VNF 6 420, die ein DPI-Dienst (Deep Packet Inspection) ist, die VNF 7 422, die ein Netzwerkadressübersetzungsmodul (NAT, Network Address Translation) ist, die VNF 8 424, die Anrufsicherheitsverbindung (Call Security Association) bereitstellt, und die VNF 9 426, die ein zweiter Lastausgleicher ist, der bereitgestellt wird, um eine erhöhte Nachfrage zu erfüllen.
Die Firewall 410 ist eine Sicherheitseinrichtung, die den Datenverkehr basierend auf einem Vergleichen des Datenverkehrs mit einer Liste von „Firewall-Regeln“ überwacht und steuert (sowohl eingehenden als auch ausgehenden). Die Firewall 410 kann eine Sperre zwischen einem relativ vertrauenswürdigen (z. B. internen) Netzwerk und einem relativ nicht vertrauenswürdigen Netzwerk (z. B. dem Internet) sein. Sobald der Datenverkehr die Prüfung durch die Firewall 410 passiert hat, kann er zu anderen Teilen des Netzwerks weitergeleitet werden.
Die Angrifferkennung 412 überwacht das Netzwerk auf schädliche Aktivitäten oder Richtlinienverletzungen. Vorfälle können an den Sicherheitsadministrator 150 gemeldet oder durch ein Sicherheitsinformations- und Ereignisverwaltungssystem (SIEM, Security Information and Event Management) erfasst und analysiert werden. In einigen Fällen kann die Angrifferkennung 412 auch Virenschutz- oder Antimalware-Scanner umfassen.
Die Lastausgleicher 414 und 426 können Datenverkehr an eine Gruppe von im Wesentlichen identischen Arbeitslastservern auslagern, um die Arbeit in einer fairen Weise zu verteilen. In einem Beispiel stellt ein Lastausgleicher eine Anzahl von Datenverkehrs-„Buckets“ bereit und weist jeden Bucket einem Arbeitslastserver zu. Eingehender Datenverkehr wird einem Bucket basierend auf einem Faktor zugewiesen, wie etwa einem Hash der Ursprungs-IP-Adresse. Da davon ausgegangen wird, dass die Hashes ziemlich gleichmäßig verteilt sind, empfängt jeder Arbeitslastserver eine angemessene Menge an Datenverkehr.
Der Router 416 leitet Pakete zwischen Netzwerken oder Unternetzwerken weiter. Beispielsweise kann der Router 416 eine oder mehrere Eintrittsschnittstellen und mehrere Austrittsschnittstellen umfassen, wobei jede Austrittsschnittstelle einer Ressource, einem Unternetzwerk, einem virtuellen privaten Netzwerk oder einer anderen Unterteilung zugeordnet ist. Wenn Datenverkehr an einer Eintrittsschnittstelle eingeht, bestimmt der Router 416, zu welchem Ziel dieser gehen soll, und leitet das Paket zu der geeigneten Austrittsschnittstelle weiter.
Der Session Border Controller 418 steuert die VoIP-Signalisierung (Voice over IP) sowie die Medienströme zum Einrichten, Durchführen und Beenden von Anrufen. In diesem Kontext bezieht sich „Session“ (Sitzung) auf ein Kommunikationsereignis (z. B. einen „Anruf“). „Border“ (Grenze) bezieht sich auf eine Abgrenzung zwischen zwei unterschiedlichen Teilen eines Netzwerks (ähnlich einer Firewall).
Die DPI-Einrichtung 420 stellt Deep Packet Inspection bereit, einschließlich eines Untersuchens nicht nur des Headers, sondern auch des Inhalts eines Pakets, um nach potenziell unerwünschtem Inhalt (PUC, Potentially Unwanted Content), wie etwa Protokoll-Nichtkonformität, Malware, Viren, Spam oder Angriffen, zu suchen.
Das NAT-Modul 422 stellt Netzwerkadressübersetzungsdienste bereit, um einen IP-Adressraum in einen anderen erneut abzubilden (z. B. Abbilden von Adressen innerhalb eines privaten Unternetzwerks auf das größere Internet).
Die Anrufsicherheitsverbindung 424 erzeugt eine Security Association für einen Anruf oder eine andere Sitzung (siehe Session Border Controller 418 weiter oben). Das Aufrechterhalten dieser Security Association kann kritisch sein, da der Anruf beendet werden kann, wenn die Security Association unterbrochen wird.
Die Darstellung von 4 zeigt, dass eine Anzahl von VNF bereitgestellt wurde und innerhalb der NFVI 404 vorhanden ist. Diese Figur stellt nicht notwendigerweise eine Beziehung zwischen den VNF und dem größeren Netzwerk dar.
5 stellt ein Blockdiagramm von Komponenten einer Rechenplattform 500 gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung dar. In der dargestellten Ausführungsform umfasst die Rechenplattform 500 mehrere Plattformen 502 und die Systemverwaltungsplattform 506, die über das Netzwerk 508 miteinander gekoppelt sind. In anderen Ausführungsformen kann ein Rechensystem jede geeignete Anzahl (d. h. eine oder mehrere) von Plattformen umfassen. In einigen Ausführungsformen (z. B., wenn ein Rechensystem nur eine einzelne Plattform umfasst), kann die Systemverwaltungsplattform 506 ganz oder teilweise in einer Plattform 502 enthalten sein. Eine Plattform 502 kann eine Plattformlogik 510 mit einer oder mehreren zentralen Verarbeitungseinheiten (CPU, Central Processing Units) 512, Speichern 514 (die jede Anzahl von unterschiedlichen Modulen umfassen können), Chipsätzen 516, Kommunikationsschnittstellen 518 und jeder anderen geeigneten Hardware und/oder Software zum Ausführen eines Hypervisors 520 oder ein anderes Betriebssystem, das in der Lage ist, Arbeitslasten im Zusammenhang mit auf Plattform 502 ausgeführten Anwendungen auszuführen, umfassen. In einigen Ausführungsformen kann eine Plattform 502 als eine Hostplattform für ein oder mehrere Gastsysteme 522, die diese Anwendungen aufrufen, fungieren. Die Plattform 500 kann jede geeignete Rechenumgebung darstellen, wie etwa eine Hochleistungsrechenumgebung, ein Datenzentrum, eine Kommunikationsdiensteanbieterinfrastruktur (z. B. einen oder mehrere Abschnitte eines Kernnetzes (EPC, Evolved Packet Core)), eine speicherinterne Rechenumgebung, ein Rechensystem eines Fahrzeugs (z. B. eines Automobils oder Flugzeugs), eine Internet-der-Dinge-Umgebung, ein industrielles Steuersystem, eine andere Rechenumgebung oder eine Kombination davon.
In verschiedenen Ausführungsformen der vorliegenden Offenbarung werden die akkumulierte Belastung und/oder Belastungsraten, die in mehreren Hardwareressourcen (z. B. Kernen (Cores) und Uncores) akkumuliert sind, überwacht, und Entitäten (z. B. die Systemverwaltungsplattform 506, der Hypervisor 520 oder ein anderes Betriebssystem) der Rechenplattform 500 können Hardwareressourcen der Plattformlogik 510 zuweisen, um Arbeitslasten in Übereinstimmung mit den Belastungsinformationen durchzuführen. Beispielsweise können die Systemverwaltungsplattform 506, der Hypervisor 520 oder ein anderes Betriebssystem oder die CPU 512 basierend auf den Belastungsinformationen einen oder mehrere Kerne bestimmen, auf denen eine Arbeitslast geplant werden soll. In einigen Ausführungsformen können Selbstdiagnosefähigkeiten mit der Belastungsüberwachung kombiniert werden, um die Integrität der Hardwareressourcen noch genauer zu bestimmen. Solche Ausführungsformen können eine Optimierung in Bereitstellungen ermöglichen, die eine Netzwerkfunktionsvirtualisierung (NFV, Network Function Virtualization), ein softwaredefiniertes Netzwerk (SDN, Software Defined Networking) oder missionskritische Anwendungen einschließen. Beispielsweise können die Belastungsinformationen während der anfänglichen Platzierung von virtuellen Netzwerkfunktionen (VNF, Virtual Network Functions) oder zur Migration von einer Plattform auf eine andere hinzugezogen werden, um die Zuverlässigkeit und die Kapazitätsausnutzung zu verbessern.
Jede Plattform 502 kann eine Plattformlogik 510 umfassen. Die Plattformlogik 510 umfasst, neben anderer Logik, ein Ermöglichen der Funktionalität der Plattform 502, eine oder mehrere CPU 512, den Speicher 514, einen oder mehrere Chipsätze 516 und die Kommunikationsschnittstelle 518. Wenngleich drei Plattformen dargestellt sind, kann die Rechenplattform 500 jede geeignete Anzahl von Plattformen umfassen. In verschiedenen Ausführungsformen kann sich eine Plattform 502 auf einer Leiterplatte befinden, die in einem Gehäuse, Rack oder einer anderen geeigneten Struktur, die mehrere durch das Netzwerk 508 miteinander gekoppelte Plattformen umfasst, (was, z. B., ein Rack oder einen Backplane-Switch umfassen kann), installiert ist.
Die CPU 512 können jeweils jede geeignete Anzahl von Prozessorkernen und Unterstützungslogik (z. B. Uncores) umfassen. Die Kerne können über eine oder mehrere Steuerungen, die sich auf der CPU 612 und/oder dem Chipsatz 516 befinden, miteinander, mit dem Speicher 514, mit zumindest einem Chipsatz 516 und/oder mit der Kommunikationsschnittstelle 518 gekoppelt sein. In bestimmten Ausführungsformen ist eine CPU 612 innerhalb eines Sockels ausgeführt, der dauerhaft oder entfernbar mit der Plattform 502 gekoppelt ist. Die CPU 612 wird ausführlicher in Verbindung mit 2 beschrieben. Wenngleich vier CPU gezeigt sind, kann eine Plattform 502 jede geeignete Anzahl von CPU umfassen.
Der Speicher 514 kann jede Form von flüchtigem oder nicht-flüchtigem Speicher umfassen, einschließlich, ohne Einschränkung, magnetische Medien (z. B. ein oder mehrere Bandlaufwerke), optische Medien, Direktzugriffsspeicher (RAM, Random Access Memory), Nur-Lese-Speicher (ROM, Read-Only Memory), Flash-Speicher, entfernbare Medien oder jede andere geeignete lokale oder entfernte Speicherkomponente oder alle anderen geeigneten lokalen oder entfernten Speicherkomponenten. Der Speicher 514 kann für eine kurz-, mittel- und/oder langfristige Speicherung durch die Plattform 502 verwendet werden. Der Speicher 514 kann alle geeigneten Daten oder Informationen, die von der Plattformlogik 510 verwendet werden, speichern, einschließlich in einem computerlesbaren Medium eingebetteter Software und/oder codierter Logik, die in Hardware integriert oder anderweitig gespeichert ist (z. B. Firmware). Der Speicher 514 kann Daten speichern, die von Kernen der CPU 512 verwendet werden. In einigen Ausführungsformen kann der Speicher 514 auch Speicher für Anweisungen umfassen, die durch die Kerne der CPU 512 oder andere Verarbeitungselemente (z. B. auf den Chipsätzen 516 befindliche Logik) ausgeführt werden können, um eine Funktionalität in Verbindung mit der Handhabbarkeits-Engine 526 oder anderen Komponenten der Plattformlogik 510 bereitzustellen. Zusätzlich oder alternativ dazu können die Chipsätze 516 jeweils einen Speicher umfassen, der jede der hierin in Bezug auf den Speicher 514 beschriebenen Eigenschaften aufweisen kann. Der Speicher 514 kann auch die Ergebnisse und/oder Zwischenergebnisse der verschiedenen Berechnungen und Bestimmungen, die von den CPU 512 oder Verarbeitungselementen auf den Chipsätzen 516 durchgeführt werden, speichern. In verschiedenen Ausführungsformen kann der Speicher 514 ein oder mehrere Systemspeichermodule umfassen, die über Speichersteuerungen (die bezogen auf die CPU 512 extern oder mit diesen verbunden sein können) mit den CPU gekoppelt sind. In verschiedenen Ausführungsformen können ein oder mehrere bestimmte Module des Speichers 514 für eine bestimmte CPU 612 oder eine andere Verarbeitungsvorrichtung vorgesehen sein oder können von mehreren CPU 512 oder anderen Verarbeitungsvorrichtungen gemeinsam genutzt werden.
In verschiedenen Ausführungsformen kann der Speicher 514 Belastungsinformationen speichern (wie etwa akkumulierte Belastungswerte in Verbindung mit Hardwareressourcen der Plattformlogik 510 im nicht-flüchtigen Speicher, sodass, bei einem Ausfall der Stromversorgung, die akkumulierten Belastungswerte erhalten bleiben). In bestimmten Ausführungsformen kann eine Hardwareressource nicht-flüchtigen Speicher (z. B. auf demselben Die wie die bestimmte Hardwareressource) zum Speichern des akkumulierten Belastungswerts der Hardwareressource umfassen.
Eine Plattform 502 kann auch einen oder mehrere Chipsätze 516 umfassen, die eine geeignete Logik zum Unterstützen des Betriebs der CPU 512 umfassen. In verschiedenen Ausführungsformen kann sich der Chipsatz 516 auf demselben Die oder im selben Gehäuse wie eine CPU 612 oder auf bzw. in einem oder mehreren unterschiedlichen Dies oder Gehäusen befinden. Jeder Chipsatz kann jede geeignete Anzahl von CPU 512 unterstützen. Ein Chipsatz 516 kann auch eine oder mehrere Steuerungen umfassen, um andere Komponenten der Plattformlogik 510 (z. B die Kommunikationsschnittstelle 518 oder den Speicher 514) mit einer oder mehreren CPU zu koppeln. Zusätzlich oder alternativ dazu können die CPU 512 integrierte Steuerungen umfassen. Beispielsweise kann die Kommunikationsschnittstelle 518 über integrierte EA-Steuerungen, die sich auf jeder CPU befinden, direkt mit der CPU 512 gekoppelt werden.
In der dargestellten Ausführungsform umfasst jeder Chipsatz 516 auch eine Handhabbarkeits-Engine 526. Die Handhabbarkeits-Engine 526 kann jede geeignete Logik zum Unterstützen des Betriebs des Chipsatzes 516 umfassen. In einer bestimmten Ausführungsform ist die Handhabbarkeits-Engine 526 (die auch als eine Innovations-Engine bezeichnet werden kann) in der Lage, Echtzeit-Telemetriedaten von dem Chipsatz 516, der bzw. den CPU 512 und/oder dem durch den Chipsatz 516 verwalteten Speicher 514, anderen Komponenten der Plattformlogik 510 und/oder verschiedenen Verbindungen zwischen Komponenten der Plattformlogik 510 zu erfassen. In verschiedenen Ausführungsformen umfassen die erfassten Telemetriedaten die hierin beschriebenen Belastungsinformationen.
In verschiedenen Ausführungsformen arbeitet die Handhabbarkeits-Engine 526 als ein bandexterner asynchroner Rechenagent, der in der Lage ist, mit den verschiedenen Elementen der Plattformlogik 510 in Verbindung zu treten, um Telemetriedaten ohne oder mit nur minimaler Störung der auf den CPU 512 ausgeführten Prozesse zu erfassen. Beispielsweise kann die Handhabbarkeits-Engine 526 ein dediziertes Verarbeitungselement (z. B. einen Prozessor, eine Steuerung oder eine andere Logik) auf dem Chipsatz 516 umfassen, das die Funktionalität der Handhabbarkeits-Engine 526 bereitstellt (z. B. durch Ausführen von Softwareanweisungen) und so Verarbeitungszyklen der CPU 512 für Operationen in Verbindung mit den von der Plattformlogik 510 durchgeführten Arbeitslasten einspart. Darüber hinaus kann die dedizierte Logik für die Handhabbarkeits-Engine 526 asynchron in Bezug auf die CPU 512 arbeiten und kann zumindest einige der Telemetriedaten erfassen, ohne die Last auf die CPU zu erhöhen.
Die Handhabbarkeits-Engine 526 kann von ihr erfasste Telemetriedaten verarbeiten (spezifische Beispiele der Verarbeitung von Belastungsinformationen werden hierin bereitgestellt). In verschiedenen Ausführungsformen meldet die Handhabbarkeits-Engine 526 die von ihr erfassten Daten und/oder die Ergebnisse ihrer Verarbeitung an andere Elemente im Rechensystem, wie etwa einen oder mehrere Hypervisoren 520 oder andere Betriebssysteme und/oder Systemverwaltungssoftware (die auf einer geeigneten Logik, wie etwa der Systemverwaltungsplattform 506, ausgeführt werden kann). In einigen Ausführungsformen werden die Telemetriedaten periodisch aktualisiert und an eine oder mehrere dieser Entitäten gemeldet. In bestimmten Ausführungsformen kann ein kritisches Ereignis, wie etwa ein Kern, der eine übermäßige Menge an Belastung akkumuliert hat, vor dem normalen Intervall zum Melden von Telemetriedaten gemeldet werden (z. B. kann eine Benachrichtigung unmittelbar beim Erfassen gesendet werden).
In verschiedenen Ausführungsformen kann eine Handhabbarkeits-Engine 526 programmierbaren Code umfassen, der dazu konfigurierbar ist, festzulegen, welche CPU 512 ein bestimmter Chipsatz 516 verwalten wird und/oder welche Telemetriedaten erfasst werden.
Die Chipsätze 516 umfassen auch eine Kommunikationsschnittstelle 528. Die Kommunikationsschnittstelle 528 kann für die Kommunikation von Signalisierung und/oder Daten zwischen dem Chipsatz 516 und einer oder mehreren EA-Vorrichtungen, einem oder mehreren Netzwerken 508 und/oder einer oder mehreren mit dem Netzwerk 508 gekoppelten Vorrichtungen (z. B. der Systemverwaltungsplattform 506) verwendet werden. Beispielsweise kann die Kommunikationsschnittstelle 528 verwendet werden, um Netzwerkverkehr, wie etwa Datenpakete, zu senden und zu empfangen. In einer bestimmten Ausführungsform umfasst die Kommunikationsschnittstelle 528 eine oder mehrere physische Netzwerkschnittstellensteuerungen (NIC, Network Interface Controllers), die auch als Netzwerkschnittstellenkarten oder Netzwerkadapter bekannt sind. Eine NIC kann eine elektronische Schaltungsanordnung zum Kommunizieren unter Verwendung eines geeigneten Standards für die physische Schicht und die Datenverbindungsschicht, wie etwa Ethernet (z. B. wie durch einen IEEE-Standard 802.3 definiert), Fibre Channel, InfiniBand, Wi-Fi oder eines anderen geeigneten Standards umfassen. Eine NIC kann einen oder mehrere physische Anschlüsse umfassen, die mit einem Kabel (z. B. einem Ethernet-Kabel) gekoppelt sein können. Eine NIC kann eine Kommunikation zwischen einem geeigneten Element des Chipsatzes 516 (z. B. der Handhabbarkeits-Engine 526 oder dem Switch 530) und einer anderen mit dem Netzwerk 508 gekoppelten Vorrichtung ermöglichen. In einigen Ausführungsformen kann das Netzwerk 508 einen Switch mit Überbrückungs- und/oder Weiterleitungsfunktionen umfassen, der extern zu der Plattform 502 ist und betreibbar ist, um verschiedene NIC, die auf der gesamten Rechenplattform 500 verteilt sind (z. B. auf unterschiedlichen Plattformen), miteinander zu koppeln. In verschiedenen Ausführungsformen kann eine NIC mit dem Chipsatz verbunden sein (d. h., sie kann auf der gleichen integrierten Schaltung oder Leiterplatte wie der Rest der Chipsatzlogik sein) oder kann auf einer anderen integrierten Schaltung oder Leiterplatte sein, die elektromechanisch mit dem Chipsatz gekoppelt ist.
In bestimmten Ausführungsformen kann die Kommunikationsschnittstelle 528 eine Kommunikation von Daten (z. B. zwischen der Handhabbarkeits-Engine 526 und der Systemverwaltungsplattform 506) in Verbindung mit Verwaltungs- und Überwachungsfunktionen, die von der Handhabbarkeits-Engine 526 durchgeführt werden, ermöglichen. In verschiedenen Ausführungsformen kann die Handhabbarkeits-Engine 526 Elemente (z. B. eine oder mehrere NIC) der Kommunikationsschnittstelle 528 verwenden, um die Telemetriedaten (z. B. an die Systemverwaltungsplattform 506) zu melden, um eine Nutzung von NIC der Kommunikationsschnittstelle 518 für Operationen in Verbindung mit Arbeitslasten, die von der Plattformlogik 510 durchgeführt werden, zu reservieren. In einigen Ausführungsformen kann es die Kommunikationsschnittstelle 528 auch EA-Vorrichtungen, die mit der Plattform verbunden oder extern zu dieser sind (z. B. Plattenlaufwerke, andere NIC usw.), ermöglichen, mit den CPU-Kernen zu kommunizieren.
Der Switch 530 kann mit verschiedenen Anschlüssen (z. B. durch NIC bereitgestellt) der Kommunikationsschnittstelle 528 gekoppelt sein und kann Daten zwischen diesen Anschlüssen und verschiedenen Komponenten des Chipsatzes 516 (z. B. eine oder mehrere PCIe-Spuren (Peripheral Component Interconnect express), die mit den CPU 512 gekoppelt sind) schalten. Der Switch 530 kann ein physischer oder ein virtueller (d. h. Software-) Schalter sein.
Die Plattformlogik 510 kann eine zusätzliche Kommunikationsschnittstelle 518 umfassen. Ähnlich wie die Kommunikationsschnittstelle 528 kann die Kommunikationsschnittstelle 518 für die Kommunikation von Signalisierung und/oder Daten zwischen der Plattformlogik 510 und einem oder mehreren Netzwerken 508 und einer oder mehreren mit dem Netzwerk 508 gekoppelten Vorrichtungen verwendet werden. Beispielsweise kann die Kommunikationsschnittstelle 518 verwendet werden, um Netzwerkverkehr, wie etwa Datenpakete, zu senden und zu empfangen. In einer bestimmten Ausführungsform umfasst die Kommunikationsschnittstelle 518 eine oder mehrere physische NIC. Diese NIC können eine Kommunikation zwischen jedem geeigneten Element der Plattformlogik 510 (z. B. den CPU 512 oder dem Speicher 514) und einer anderen mit dem Netzwerk 508 gekoppelten Vorrichtung (z. B. Elementen von anderen Plattformen oder externe, mit dem Netzwerk 508 über ein oder mehrere Netzwerke gekoppelte Rechenvorrichtungen) ermöglichen. In bestimmten Ausführungsformen kann es die Kommunikationsschnittstelle 518 Vorrichtungen, die extern zu der Plattform sind (z. B. Plattenlaufwerken, anderen NIC usw.), ermöglichen, mit den CPU-Kernen zu kommunizieren. In verschiedenen Ausführungsformen können NIC der Kommunikationsschnittstelle 518 über EA-Steuerungen (die bezogen auf die CPU 512 extern oder mit diesen verbunden sein können) mit den CPU gekoppelt sein.
Die Plattformlogik 510 kann alle geeigneten Typen von Arbeitslasten empfangen und durchführen. Eine Arbeitslast kann eine Anforderung umfassen, eine oder mehrere Ressourcen der Plattformlogik 510, wie etwa einen oder mehrere Kerne oder eine zugehörige Logik, zu verwenden. Beispielsweise kann eine Arbeitslast eine Anforderung, eine Softwarekomponente zu instanziieren, wie etwa einen EA-Vorrichtungstreiber 524 oder ein Gastsystem 522; eine Anforderung, ein von einer virtuellen Maschine 532 oder einer bezogen auf die Plattform 502 externen Vorrichtung (wie etwa einem mit dem Netzwerk 508 gekoppelten Netzwerkknoten) empfangenes Netzwerkpaket zu verarbeiten; eine Anforderung, einen Prozess oder Thread in Verbindung mit einem Gastsystem 522, einer auf der Plattform 502 ausgeführten Anwendung, einem Hypervisor 520 oder einem anderem auf der Plattform 502 ausgeführten Betriebssystem auszuführen; oder eine andere geeignete Verarbeitungsanforderung umfassen.
In verschiedenen Ausführungsformen kann die Plattform 502 eine beliebige Anzahl von Gastsystemen 522 ausführen. Ein Gastsystem kann eine einzelne virtuelle Maschine (z. B. die virtuelle Maschine 532a oder 532b) oder mehrere zusammenarbeitende virtuelle Maschinen (z. B. eine virtuelle Netzwerkfunktion (VNF) 534 oder eine Dienstfunktionskette (SFC, Service Function Chain) 536) sein. Wie dargestellt, können verschiedene Ausführungsformen eine Vielzahl von Typen von Gastsystemen 522, die auf der gleichen Plattform 502 vorhanden sind, umfassen.
Eine virtuelle Maschine 532 kann ein Rechensystem mit seiner eigenen dedizierten Hardware emulieren. Eine virtuelle Maschine 532 kann ein Gastbetriebssystem über dem Hypervisor 520 ausführen. Die Komponenten der Plattformlogik 510 (z. B. die CPU 512, der Speicher 514, der Chipsatz 516 und die Kommunikationsschnittstelle 518) können derart virtualisiert werden, dass das Gastbetriebssystem davon ausgeht, dass die virtuelle Maschine 532 ihre eigenen dedizierten Komponenten hat.
Eine virtuelle Maschine 532 kann eine virtualisierte NIC (vNIC) haben, die von der virtuellen Maschine als ihre Netzwerkschnittstelle verwendet wird. Einer vNIC kann eine Medienzugriffssteuerungsadresse (MAC, Media Access Control) oder eine andere Kennung zugewiesen werden, wodurch es ermöglicht wird, dass mehrere virtuelle Maschinen 532 in einem Netzwerk einzeln adressierbar sind.
In einigen Ausführungsformen kann eine virtuelle Maschine 532b paravirtualisiert sein. Beispielsweise kann die virtuelle Maschine 532b erweiterte Treiber umfassen (z. B. Treiber, die eine höhere Leistungsfähigkeit bieten oder Schnittstellen mit höherer Bandbreite für zugrunde liegende Ressourcen oder Fähigkeiten, die durch den Hypervisor 520 bereitgestellt werden, haben). Beispielsweise kann ein erweiterter Treiber eine schnellere Schnittstelle für den zugrunde liegenden virtuellen Switch 538 für höhere Netzwerkleistungsfähigkeit im Vergleich zu Standardtreibern aufweisen.
Die VNF 534 kann eine Softwareimplementierung eines funktionalen Bausteins mit definierten Schnittstellen und Verhalten umfassen, der in einer virtualisierten Infrastruktur bereitgestellt werden kann. In bestimmten Ausführungsformen kann eine VNF 534 eine oder mehrere virtuelle Maschinen 532 umfassen, die gemeinsam spezifische Funktionalitäten (z. B. Optimierung des Weitbereichsnetzwerks (WAN, Wide Area Network), Terminierung des virtuellem privatem Netzwerks (VPN, Virtual Private Network), Firewallbetrieb, Lastausgleichsbetrieb, Sicherheitsfunktionen usw.) bereitstellen. Eine VNF 534, die auf der Plattformlogik 510 ausgeführt wird, kann die gleiche Funktionalität bereitstellen, wie herkömmliche Netzwerkkomponenten, die durch dedizierte Hardware implementiert werden. Beispielsweise kann eine VNF 534 Komponenten zum Durchführen von allen geeigneten NFV-Arbeitslasten umfassen, wie etwa vEPC-Komponenten (virtualized Evolved Packet Core), Mobilitätsverwaltungsentitäten, Komponenten für die Steuer- und Datenebene nach 3GPP (3rd Generation Partnership Project) usw.
Die SFC 536 ist eine Gruppe von VNF 534, die als eine Kette zum Durchführen einer Serie von Operationen, wie etwa Netzwerkpaketverarbeitungsoperationen, organisiert ist. Die Dienstfunktionsverkettung kann die Möglichkeit bieten, eine geordnete Liste von Netzwerkdiensten (z. B. Firewalls, Lastausgleicher) zu definieren, die im Netzwerk zusammengefügt sind, um eine Dienstkette zu erstellen.
Ein Hypervisor 520 (auch als Virtual-Machine-Monitor bekannt) kann eine Logik umfassen, um die Gastsysteme 522 zu erstellen und auszuführen. Der Hypervisor 520 kann Gastbetriebssysteme präsentieren, die von virtuellen Maschinen mit einer virtuellen Betriebsplattform ausgeführt werden (d. h., die virtuellen Maschinen gehen davon aus, dass sie auf separaten physischen Knoten ausgeführt werden, wenn sie tatsächlich auf einer einzigen Hardwareplattform konsolidiert sind), und die Ausführung der Gastbetriebssysteme durch die Plattformlogik 510 verwalten. Dienste des Hypervisors 520 können durch Virtualisieren in Software oder durch hardwareunterstützte Ressourcen, die einen minimalen Softwareeingriff erfordern, oder beides bereitgestellt werden. Mehrere Instanzen einer Vielzahl von Gastbetriebssystemen können durch den Hypervisor 520 verwaltet werden. Jede Plattform 502 kann eine separate Instanziierung eines Hypervisors 520 haben.
Der Hypervisor 520 kann ein systemeigener oder Bare-Metal-Hypervisor sein, der direkt auf der Plattformlogik 510 ausgeführt wird, um die Plattformlogik zu steuern und die Gastbetriebssysteme zu verwalten. Alternativ kann der Hypervisor 520 ein gehosteter Hypervisor sein, der auf einem Hostbetriebssystem ausgeführt wird und die Gastbetriebssysteme von dem Hostbetriebssystem abstrahiert. Verschiedene Ausführungsformen können eine oder mehrere nicht virtualisierte Plattformen 502 umfassen, wobei in diesem Fall alle hierin beschriebenen geeigneten Eigenschaften oder Funktionen des Hypervisors 520 auf ein Betriebssystem der nicht virtualisierten Plattform anwendbar sein können.
Der Hypervisor 520 kann einen virtuellen Switch 538 umfassen, der virtuelle Schalt- und/oder Weiterleitungsfunktionen für virtuelle Maschinen der Gastsysteme 522 bereitstellt. Der virtuelle Switch 538 kann eine logische Schaltstruktur umfassen, die die vNIC der virtuellen Maschinen 532 miteinander koppelt und so ein virtuelles Netzwerk erstellt, durch das virtuelle Maschinen miteinander kommunizieren können. Der virtuelle Switch 538 kann auch über physische NIC der Kommunikationsschnittstelle 518 mit einem oder mehreren Netzwerken (z. B. dem Netzwerk 508) gekoppelt werden, um eine Kommunikation zwischen den virtuellen Maschinen 532 und einem oder mehreren bezogen auf die Plattform 502 externen Netzwerkknoten zu ermöglichen (z. B. einer virtuellen Maschine, die auf einer anderen Plattform 502 ausgeführt wird, oder einem Knoten, der über das Internet oder ein anderes Netzwerk mit der Plattform 502 gekoppelt ist). Der virtuelle Switch 538 kann ein Softwareelement umfassen, das unter Verwendung von Komponenten der Plattformlogik 510 ausgeführt wird. In verschiedenen Ausführungsformen kann der Hypervisor 520 mit jeder geeigneten Entität (z. B. einer SDN-Steuerung) in Kommunikation sein, die bewirken kann, dass der Hypervisor 520 die Parameter des virtuellen Switches 538 in Reaktion auf sich ändernde Bedingungen bei der Plattform 502 (z. B. die Hinzufügung oder Löschung von virtuellen Maschinen 532 oder eine Identifizierung von Optimierungen, die vorgenommen werden können, um die Leistungsfähigkeit der Plattform zu verbessern) neu konfiguriert.
Der Hypervisor 520 kann auch die Ressourcenzuordnungslogik 544 umfassen, die eine Logik zum Bestimmen einer Zuordnung von Plattformressourcen basierend auf den Telemetriedaten (die Belastungsinformationen umfassen können) umfassen kann. Die Ressourcenzuordnungslogik 544 kann auch eine Logik zum Kommunizieren mit verschiedenen Komponenten der Plattformlogikentitäten 510 der Plattform 502 zum Implementieren einer solchen Optimierung umfassen, wie etwa Komponenten der Plattformlogik 502. Beispielsweise kann die Ressourcenzuordnungslogik 544 basierend auf Belastungsinformationen anweisen, welche Hardwareressourcen der Plattformlogik 510 zum Durchführen von Arbeitslasten verwendet werden.
Jede geeignete Logik kann eine oder mehrere dieser Optimierungsentscheidungen treffen. Beispielsweise kann die Systemverwaltungsplattform 506; die Ressourcenzuordnungslogik 544 des Hypervisors 520 oder eines anderen Betriebssystems oder eine andere Logik der Plattform 502 oder der Rechenplattform 500 in der Lage sein, solche Entscheidungen zu treffen (entweder allein oder in Kombination mit anderen Elementen der Plattform 502). In einer bestimmten Ausführungsform kann die Systemverwaltungsplattform 506 mit dem Hypervisor 520 kommunizieren (unter Verwendung von bandinterner oder bandexterner Kommunikation), um die Optimierungen anzugeben, die verwendet werden sollen, um auf der Systemverwaltungsplattform gespeicherte Richtlinien zu erfüllen.
In verschiedenen Ausführungsformen kann die Systemverwaltungsplattform 506 Telemetriedaten von mehreren Plattformen 502 empfangen und die Arbeitslastplatzierung über diese hinweg verwalten. Die Systemverwaltungsplattform 506 kann mit den Hypervisoren 520 (z. B. in einer bandexternen Weise) oder anderen Betriebssystemen der verschiedenen Plattformen 502 kommunizieren, um durch die Systemverwaltungsplattform angewiesene Arbeitslastplatzierungen zu implementieren.
Die Elemente der Plattformlogik 510 können in jeder geeigneten Weise miteinander gekoppelt werden. Beispielsweise kann ein Bus beliebige der Komponenten miteinander koppeln. Ein Bus kann jede bekannte Verbindung umfassen, wie etwa einen Multi-Drop-Bus, eine Maschenverbindung, eine Ringverbindung, eine Punkt-zu-Punkt-Verbindung, eine serielle Verbindung, einen parallelen Bus, einen kohärenten (z. B. Cache-kohärenten) Bus, eine geschichtete Protokollarchitektur, einen differenziellen Bus oder einen GTL-Bus (Gunning Transceiver Logic).
Elemente der Rechenplattform 500 können in jeder geeigneten Weise miteinander gekoppelt werden, wie etwa durch ein oder mehrere Netzwerke 508. Ein Netzwerk 508 kann jedes geeignete Netzwerk oder jede Kombination von einem oder mehreren Netzwerken sein, die unter Verwendung von einem oder mehreren geeigneten Netzwerkprotokollen arbeiten. Ein Netzwerk kann eine Serie von Knoten, Punkten und verbundenen Kommunikationspfaden zum Empfangen und Übertragen von Paketen von Informationen, die über ein Kommunikationssystem verteilt werden, darstellen. Beispielsweise kann ein Netzwerk eine/n oder mehrere Firewalls, Router, Switches, Sicherheitseinrichtungen, Virenschutzserver oder andere hilfreiche Netzwerkvorrichtungen umfassen. Ein Netzwerk bietet kommunikative Schnittstellen zwischen Quellen und/oder Hosts und kann jedes Nahbereichsnetzwerk (LAN, Local Area Network), kabellose Nahbereichsnetzwerk (WLAN; Wireless Local Area Network), MAN (Metropolitan Area Network), Intranet, Extranet, Internet, Weitbereichsnetzwerk (WAN, Wide Area Network), virtuelle private Netzwerk (VPN, Virtual Private Network), Mobilfunknetzwerk oder jede andere geeignete Architektur oder jedes andere geeignete System, die bzw. das Kommunikationen in einer Netzwerkumgebung ermöglicht, umfassen. Ein Netzwerk kann eine beliebige Anzahl von Hardware- oder Softwareelementen, die über ein Kommunikationsmedium miteinander gekoppelt sind (und miteinander in Kommunikation stehen), umfassen. In verschiedenen Ausführungsformen können die Gastsysteme 522 durch das Netzwerk 508 mit Knoten kommunizieren, die bezogen auf die Rechenplattform 500 extern sind.
6 stellt ein Blockdiagramm einer zentralen Verarbeitungseinheit (CPU, Central Processing Unit) 612 in Übereinstimmung mit bestimmten Ausführungsformen dar. Wenngleich die CPU 612 eine bestimmte Konfiguration darstellt, können die Kerne und andere Komponenten der CPU 612 in jeder geeigneten Weise angeordnet sein. Die CPU 612 kann jeden Prozessor oder jede Verarbeitungsvorrichtung, wie etwa einen Mikroprozessor, einen eingebetteten Prozessor, einen Digitalsignalprozessor (DSP), einen Netzwerkprozessor, einen Anwendungsprozessor, einen Koprozessor, ein System-on-a-Chip (SOC) oder eine andere Vorrichtung zum Ausführen von Code umfassen. Die CPU 612 umfasst in der dargestellten Ausführungsform vier Verarbeitungselemente (die Kerne 630 in der dargestellten Ausführungsform), die asymmetrische Verarbeitungselemente oder symmetrische Verarbeitungselemente umfassen können. Allerdings kann die CPU 612 eine beliebige Anzahl von Verarbeitungselementen umfassen, die symmetrisch oder asymmetrisch sein können.
In einer Ausführungsform bezieht sich ein Verarbeitungselement auf eine Hardware oder Logik zum Unterstützen eines Softwarethreads. Beispiele von Hardwareverarbeitungselementen umfassen: eine Threadeinheit, einen Threadschlitz, einen Thread, eine Prozesseinheit, einen Kontext, eine Kontexteinheit, einen logischen Prozessor, einen Hardwarethread, einen Kern und/oder jedes andere Element, das in der Lage ist, einen Zustand für einen Prozessor, wie etwa einen Ausführungszustand oder einen architektonischen Zustand, zu halten. Mit anderen Worten bezieht sich ein Verarbeitungselement in einer Ausführungsform auf jede Hardware, die in der Lage ist, unabhängig mit Code, wie etwa einem Softwarethread, einem Betriebssystem, einer Anwendung oder einem anderem Code verbunden zu sein. Ein physischer Prozessor (oder Prozessorsockel) bezieht sich in der Regel auf eine integrierte Schaltung, die potenziell eine beliebige Anzahl von anderen Verarbeitungselementen, wie etwa Kerne oder Hardwarethreads, umfasst.
Ein Kern kann sich auf eine Logik beziehen, die sich auf einer integrierten Schaltung befindet und in der Lage ist, einen unabhängigen architektonischen Zustand zu halten, wobei jeder unabhängig gehaltene architektonische Zustand mit zumindest einigen dedizierten Ausführungsressourcen verbunden ist. Ein Hardwarethread kann sich auf jede Logik beziehen, die sich auf einer integrierten Schaltung befindet und in der Lage ist, einen unabhängigen architektonischen Zustand zu halten, wobei die unabhängig gehaltenen architektonische Zustände einen Zugriff auf Ausführungsressourcen gemeinsam nutzen. Wie zu sehen ist, überschneidet sich die begriffliche Linie zwischen einem Hardwarethread und einem Kern, wenn bestimmte Ressourcen gemeinsam genutzt werden und andere speziell für einen architektonischen Zustand vorgesehen sind. Dennoch werden ein Kern und ein Hardwarethread durch ein Betriebssystem häufig als individuelle logische Prozessoren betrachtet, wobei das Betriebssystem in der Lage ist, Operationen auf jedem logischen Prozessor individuell zu planen.
Die physische CPU 612 kann eine beliebige geeignete Anzahl von Kernen umfassen. In verschiedenen Ausführungsformen können Kerne einen oder mehrere Out-of-order-Prozessorkerne (in anderer Reihenfolge) oder einen oder mehrere In-order-Prozessorkerne (in der Reihenfolge) umfassen. Allerdings können Kerne einzeln aus jedem Kerntyp ausgewählt werden, wie etwa einem systemeigenen Kern, einem softwareverwalteten Kern, einem Kern, der zum Ausführen einer systemeigenen Befehlssatzarchitektur (ISA, Instruction Set Architecture) angepasst ist, einem Kern, der zum Ausführen einer übersetzten ISA angepasst ist, einem partizipatorisch entwickelten Kern oder einem anderen bekannten Kern. In einer heterogenen Kernumgebung (d. h. asymmetrische Kerne) kann eine gewisse Form von Übersetzung, wie etwa eine binäre Übersetzung, verwendet werden, um Code auf einem oder beiden Kernen zu planen oder auszuführen.
In der dargestellten Ausführungsform umfasst der Kern 630A einen Out-of-order-Prozessor (in anderer Reihenfolge), der eine Frontend-Einheit 670 hat, die zum Abrufen von eingehenden Anweisungen, Durchführen verschiedener Verarbeitungen (z. B. Zwischenspeichern, Decodieren, Sprungvorhersage usw.) und Weiterleiten von Anweisungen/Operationen zu einer Out-of-order-Engine (OOO) 680 verwendet wird. Die OOO-Engine 680 führt eine weitere Verarbeitung bei decodierten Anweisungen durch.
Ein Frontend 670 kann ein Decodiermodul umfassen, das gekoppelt ist, um eine Logik zum Decodieren abgerufener Elemente abzurufen. Die Abruflogik umfasst in einer Ausführungsform individuelle Sequenzierer in Verbindung mit Threadschlitzen der Kerne 630. Üblicherweise ist ein Kern 630 mit einer ersten ISA verbunden, die auf dem Kern 630 ausführbare Anweisungen definiert/angibt. Häufig umfassen Maschinencodeanweisungen, die Teil der ersten ISA sind, einen Abschnitt der Anweisung (als ein Opcode bezeichnet), der eine Anweisung oder durchzuführende Operation referenziert/angibt. Das Decodiermodul kann eine Schaltungsanordnung umfassen, die diese Anweisungen ausgehend von deren Opcodes erkennt und die decodierten Anweisungen in der Verarbeitungspipeline zur Verarbeitung, wie durch die erste ISA definiert, weiterleitet. Beispielsweise können Decodierer in einer Ausführungsform eine Logik umfassen, die dazu ausgestaltet oder angepasst ist, spezifische Anweisungen, wie etwa transaktionale Anweisungen, zu erkennen. Als ein Ergebnis der Erkennung durch die Decodierer führt die Architektur des Kerns 630 spezifische, vordefinierte Aktionen durch, um Aufgaben in Verbindung mit der entsprechenden Anweisung durchzuführen. Es ist wichtig anzumerken, dass alle der hierin beschriebenen Aufgaben, Blöcke, Operationen und Verfahren in Reaktion auf eine einzelne oder mehrere Anweisungen durchgeführt werden können; von denen einige neue oder alte Anweisungen sein können. Decodierer der Kerne 630 erkennen in einer Ausführungsform die gleiche ISA (oder eine Untermenge davon). Alternativ kann in einer heterogenen Kernumgebung ein Decodierer von einem oder mehreren Kernen (z. B. dem Kern 630B) eine zweite ISA erkennen (entweder eine Untermenge der ersten ISA oder eine andere ISA).
In der dargestellten Ausführungsform umfasst die Out-of-order-Engine 680 eine Zuordnungseinheit 682 zum Empfangen von decodierten Anweisungen, die in der Form von einer oder mehreren Mikroanweisungen oder Uops sein können, von der Frontend-Einheit 670, und Zuordnen derselben zu entsprechenden Ressourcen, wie etwa Registern und so weiter. Danach werden die Anweisungen einer Reservierungsstation 684 bereitgestellt, die Ressourcen reserviert und für eine Ausführung auf einer von mehreren Ausführungseinheiten 686A-686N plant. Verschiedene Typen von Ausführungseinheiten können vorhanden sein, einschließlich, beispielsweise, unter anderem arithmetische Logikeinheiten (ALU, Arithmetic Logic Units), Last- und Speichereinheiten, Vektorverarbeitungseinheiten (VPU, Vector Processing Units), Gleitkomma-Ausführungseinheiten. Ergebnisse von diesen unterschiedlichen Ausführungseinheiten werden einem Neuordnungspuffer (ROB, Reorder Buffer) 688 bereitgestellt, der nicht geordnete Ergebnisse nimmt und diese wieder in die korrekte Programmreihenfolge bringt.
In der dargestellten Ausführungsform sind sowohl die Frontend-Einheit 670 als auch die Out-of-order-Engine 680 mit unterschiedlichen Ebenen einer Speicherhierarchie gekoppelt. Genauer gezeigt ist ein Anweisungsebenencache 672, der seinerseits mit einem Cache auf mittlerer Ebene 676 gekoppelt ist, der wiederum mit einem Cache auf der untersten Ebene 695 gekoppelt ist. In einer Ausführungsform wird der Cache auf der untersten Ebene 695 in einer On-Chip-Einheit 690 (manchmal als Uncore bezeichnet) implementiert. Der Uncore 690 kann mit dem Systemspeicher 699 kommunizieren, der in der dargestellten Ausführungsform über eingebetteten DRAM (eDRAM) implementiert wird. Die verschiedenen Ausführungseinheiten 686 innerhalb der Out-of-order-Engine 680 sind mit einem Cache auf erster Ebene 674 in Kommunikation, der auch mit dem Cache auf mittlerer Ebene 676 in Kommunikation ist. Die zusätzlichen Kerne 630B - 630D können ebenfalls mit dem Cache auf der untersten Ebene 695 gekoppelt sein.
In verschiedenen Ausführungsformen kann der Uncore 690 (manchmal als ein Systemagent bezeichnet) jede geeignete Logik umfassen, die nicht ein Teil des Kerns 630 ist. Beispielsweise kann der Uncore 690 einen oder mehrere aus einem Cache auf der untersten Ebene, eine Cachesteuerung, eine mit einem Systemspeicher gekoppelte On-Die-Speichersteuerung, eine Prozessorverbindungssteuerung (z. B. ein Quick Path Interconnect oder eine ähnliche Steuerung), eine On-Die-EA-Steuerung oder eine andere geeignete On-Die-Logik umfassen.
In bestimmten Ausführungsformen kann sich der Uncore 690 in einer Spannungsdomäne und/oder einer Frequenzdomäne befinden, die von Spannungsdomänen und/oder Frequenzdomänen der Kerne getrennt ist. Das heißt, dass der Uncore 690 durch eine Versorgungsspannung gespeist werden kann, die sich von den Versorgungsspannungen, die zum Speisen der Kerne verwendet werden, unterscheidet, und/oder bei einer Frequenz betrieben werden kann, die sich von den Betriebsfrequenzen der Kerne unterscheidet.
Die CPU 612 kann auch eine Leistungssteuereinheit (PCU, Power Control Unit) 640 umfassen. In verschiedenen Ausführungsformen kann die PCU 640 die Versorgungsspannungen und die Betriebsfrequenzen, die auf die einzelnen Kerne (kernweise) und auf den Uncore angewendet werden, steuern. Die PCU 640 kann auch einen Kern oder einen Uncore anweisen, in einen Ruhezustand (wo keine Spannung und kein Takt bereitgestellt werden) zu wechseln, wenn keine Arbeitslast durchgeführt wird.
In verschiedenen Ausführungsformen kann die PCU 640 eine oder mehrere Belastungseigenschaften einer Hardwareressource, wie etwa des Kerns und des Uncore, erfassen. Eine Belastungseigenschaft kann eine Anzeige eines Belastungswerts umfassen, der die Hardwareressource ausgesetzt wird. Als Beispiele kann eine Belastungseigenschaft eine Spannung oder Frequenz, die an die Hardwareressource angelegt wird; ein Leistungspegel, Strompegel oder Spannungspegel, der an der Hardwareressource erfasst wird; eine Temperatur, die an der Hardwareressource erfasst wird; oder eine andere geeignete Messung sein. In verschiedenen Ausführungsformen können mehrere Messungen (z. B. an unterschiedlichen Orten) einer bestimmten Belastungseigenschaft durchgeführt werden, wenn die Belastungseigenschaft an einer bestimmten Zeitinstanz erfasst wird. In verschiedenen Ausführungsformen kann die PCU 640 Belastungseigenschaften bei jedem geeigneten Intervall erfassen.
In verschiedenen Ausführungsformen kann die PCU 640 einen Mikrocontroller umfassen, der eingebettete Firmware ausführt, um verschiedene Operationen in Verbindung mit der hierin beschriebenen Belastungsüberwachung durchzuführen. In einer Ausführungsform führt die PCU 640 einige oder alle der hierin beschriebenen PCU-Funktionen unter Verwendung von Hardware durch, ohne dabei Softwareanweisungen auszuführen. Beispielsweise kann die PCU 640 eine feste und/oder programmierbare Logik umfassen, um die Funktionen der PCU durchzuführen.
In verschiedenen Ausführungsformen ist die PCU 640 eine Komponente, die bezogen auf die Kerne 630 eigenständig ist. In bestimmten Ausführungsformen wird die PCU 640 bei einer Taktfrequenz ausgeführt, die sich von den durch die Kerne 630 verwendeten Taktfrequenzen unterscheidet. In einigen Ausführungsformen, in denen die PCU ein Mikrocontroller ist, führt die PCU 640 Anweisungen gemäß einer ISA aus, die sich von der durch die Kerne 630 verwendeten ISA unterscheidet.
In verschiedenen Ausführungsformen kann die CPU 612 auch einen nicht-flüchtigen Speicher 650 umfassen, um Belastungsinformationen (wie etwa Belastungseigenschaften, inkrementelle Belastungswerte, akkumulierte Belastungswerte, Belastungsakkumulierungsraten oder andere Belastungsinformationen) in Verbindung mit den Kernen 630 oder dem Uncore 690 derart zu speichern, dass bei einem Ausfall der Stromversorgung die Belastungsinformationen erhalten bleiben.
7 ist ein Blockdiagramm eines Datenzentrums 700 als der Computer gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
Das Datenzentrum 700 kann dazu ausgelegt sein, SLA für bestimmte Ressourcen bereitzustellen. Beispielsweise umfasst das Datenzentrum 700 einen Knoten 0 708, der zwei Sockel von Intel® Xeon®-Prozessoren bereitstellt, die durch einen Uplink verbunden sind. Der Knoten 1 704 ist ein Speicherserver, der persistenten 3DXP-Speicher (3D Crosspoint) mit N 3DXP-Knoten bereitstellt. Der Knoten 2 710 ist ein Speicherserver („vernetzte Festplatten“ (NBOD, „networked bunch of disks“)). Der Knoten 3 706 ist ein zweiter Server, der zwei Sockel von Intel® Xeon®-Prozessoren bereitstellt, die durch einen Uplink verbunden sind. Jeder Knoten umfasst eine Host-Struktur-Schnittstelle (HFI, Host Fabric Interface) 772, die dazu ausgelegt ist, den Knoten kommunikativ mit einer Struktur 770 zu koppeln, die eine Intel® Omnipath-Struktur umfassen kann, die auch (oder stattdessen) Intel® Quick Path Interconnect (QPI) unterstützen kann. Es ist anzumerken, dass Intel® Omnipath mit entsprechenden HFI hierin als nicht einschränkendes Beispiel verwendet wird, dass aber auch andere Verbindungen verwendet werden können. Beispielsweise sind PCIe, Ethernet und andere Verbindungen mit der SLA-Architektur und dem SLA-Verfahren kompatibel, wobei in diesem Fall geeignete Schnittstellen verwendet werden können, wie in Verbindung mit 2 erörtert.
Um eine ganzheitliche SLA zwischen den unterschiedlichen Anforderern und Anbietern in dem System bereitzustellen, kann eine gemeinsame Semantik definiert werden. Die unterschiedlichen Nachrichten und Aktionen basieren auf dieser gemeinsamen konzeptuellen Grundlinie. In ähnlicher Weise kann der Softwarestapel (z. B. Anwendungen, Bibliotheken oder Betriebssysteme) auch dazu ausgelegt sein, die gleiche Semantik zu verstehen und dieser zu folgen, um auf verfügbar gemachte und erweiterte SLA-Dienste zuzugreifen.
In einem Beispiel umfasst eine Erweiterungsarchitektur Folgendes:

a. Eine Anzahl von gemeinsam genutzten Ressourcen (R₀...R_m).
b. Verfügbar gemachte Knotenschnittstellen (R_N0...R_Nn) (z. B. die HFI 772).
c. Eine Verbindung (z. B. eine Struktur 770) verbindet die Ressourcen und die Knotenschnittstelle, beschrieben durch einen Satz von gemeinsam genutzten Ressourcen (LR₀ ...LR_o).

Die Erweiterungsarchitektur ist für einen Satz von Anwendungen (A₀ ...A_p), die auf einem Satz von Knoten (AN₀ ...AN_q) ausgeführt werden (z. B. Software, wie etwa eine Anwendung 224, die auf dem Knoten 708 ausgeführt wird), zugänglich. Es ist anzumerken, dass eine „Anwendung“ wie hierin verwendet als nicht einschränkendes Beispiel jede geeignete Softwareentität umfassen kann, wie etwa ein Betriebssystem, eine Bibliothek, eine Benutzerraumanwendung, einen Daemon-Prozess oder einen Treiber.
Gemäß der hierin definierten Semantik kann eine Ressource einen Typ, eine Liste von QoS-Metriken, eine Implementierung und einen verfügbar gemachten Mechanismus zum Einrichten der SLA sowie einen Implementierungsmechanismus zum Erfassen von Konflikten und zum Drosseln von Knoten oder Anwendungen in dem System haben.
Als nicht einschränkendes Beispiel kann der Ressourcentyp Folgendes umfassen:

a. Zusammengefasste Ressourcen (z. B. zusammengefasster Speicher auf einem Speicherserver, zusammengefasster Speicherplatz oder eine andere zusammengefasste Ressource).
b. Struktur- und Netzwerkressourcen.
c. Knotenressourcen, die als eine gemeinsam genutzte Ressource verfügbar gemacht sind (z. B. Knotenspeicher, der als gemeinsam genutzter Speicher verfügbar gemacht ist).
d. Software, die als eine gemeinsam genutzte Ressource verfügbar gemacht ist.
e. Beschleuniger, die als eine gemeinsam genutzte Ressource verfügbar gemacht sind.

Die QoS-Metriken können ein Array aus Name-Wert-Paaren oder anderen Paaren der Form {<ID,Unit>} sein. Beispielsweise kann die ID „BW“ (Bandbreite, Bandwidth) die Einheit „GB/S“ (Gigabit pro Sekunde) haben.
Die Struktur 770 stellt einen Mechanismus zum Senden spezifischer Nachrichten zwischen Knoten (z. B. Tunneling-Nachrichten im QPI-Vierschichtenprotokoll) für SLA und Drosselung bereit. Die HFI 772 macht Mechanismen für Anwendungen verfügbar und stellt diese bereit, um SLA-Anforderungen an externe, gemeinsam genutzte Ressourcen zu senden, auf die über andere Knotenschnittstellen zugegriffen wird.
Wenn eine HFI 772 eine SLA-Anforderung empfängt, kann sie die Anforderung an ihre lokale Steuerung abtreten, die die gemeinsam genutzte Ressource, auf die die Anforderung abzielt, steuert. Wenn beispielsweise die lokale Ressource ein Speicher-Pool ist, kann die HFI 772 eine SLA-Anforderung empfangen oder weiterleiten, die für einen bestimmten Strom bestimmt ist. Ein „Strom“ bedeutet in diesem Kontext jede identifizierte Dateneinheit oder jeden Strom, die bzw. der eine angeforderte SLA empfangen soll. Ein Strom kann mit einem Benutzerkonto, einem Mandanten, einem Softwarepaket, einem bestimmten Knoten, einer spezifischen Vorrichtung oder einer anderen Quelle verbunden sein. Ströme können durch einen identifizierten Tunnel, Unternetzwerke oder ein virtuelles Unternetzwerk, virtuelle IP-Adressen (VIP), eine Endpunktkennung (EID, Endpoint Identifier), ein Paketheaderfeld oder einen anderen, zum Identifizieren eines Stroms geeigneten Mechanismus identifiziert oder mit diesen verbunden sein.
8 stellt ein Blockdiagramm eines Datenzentrums gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung dar. In dem Beispiel von 8 hat ein Orchestrator 802 globale Sicht auf das Datenzentrum und die Ressourcen, Knoten und anderen Einheiten, aus denen das Datenzentrum besteht. In diesem Fall kann für einen SLA-Zielknoten 804 eine bestimmte SLA oder andere QoS-Metrik garantiert werden. Beispielsweise kann der SLA-Zielknoten 804 einem Kunden oder Endbenutzer zugeordnet werden, der eine garantierte Ende-zu-Ende-Speicherbandbreite von 2 GB/s haben soll.
Um diese garantierte Bandbreite umzusetzen, muss möglicherweise eine ganzheitliche SLA auf nachgelagerte Vorrichtungen 806 verteilt werden. Der Orchestrator 802 hat eine globale Sicht auf die Datenstruktur und ist daher in einer Position, um eine Ende-zu-Ende-SLA-Richtlinie zu konstruieren, die die Zwischenelemente berücksichtigt, die sich auf die SLA auswirken können. Der Orchestrator 802 kann auch Administratorrechte haben, um SLA im gesamten Datenzentrum durchzusetzen, und kann Zugriff auf Daten, wie etwa Kundenverträge oder Benutzeranforderungen, haben. Es ist anzumerken, dass der Orchestrator 802 in diesem Kontext im weitesten Sinn jeden Orchestrator, jede Steuerung, jeden Hypervisor, jeden Manager einer virtuellen Maschine oder jede andere Steuerentität umfassen soll, der bzw. die die Sicht und den Zugriff hat, um die Orchestratorfunktion auszuführen.
Um die ganzheitliche oder Ende-zu-Ende-SLA bereitzustellen, kann der Orchestrator 802 eine „SLA-Struktur“ 812 konstruieren, die eine Datenstruktur ist, die die zum Durchsetzen der SLA erforderlichen Informationen umfasst. Die SLA-Datenstruktur 812 kann, beispielsweise, eine Identifizierung des Stroms, der die SLA empfangen soll, und Kennungen für eine oder mehrere Vorrichtungen oder Ressourcen, die die SLA beeinflussen, zusammen mit den semantischen Name-Wert-Paaren (wie oben beschrieben), die die QoS-Metrik oder -Metriken für jede Ressource bereitstellen, umfassen.
Beispielsweise kann die SLA angeben, dass ein bestimmter Mandant ein Minimum von 32 Gigabyte an persistentem 3DXP-Speicher bei einer Mindestdatenrate von 2 Gigabit pro Sekunde erhalten soll. Aus der Kundenperspektive ist der wichtige Aspekt, dass diese SLA angegeben und bereitgestellt ist. Der Kunde muss sich keine Gedanken darüber machen, wo sich der Speicher befindet oder wie das Datenzentrum eingerichtet ist.
Der Orchestrator 802 hat Sicht in diese SLA sowie eine globale Sicht auf das Datenzentrum und die QoS-Metriken, die durchgesetzt werden müssen, um diese SLA bereitzustellen.
Beispielsweise kann, wieder Bezug nehmend auf 7, die Software des Mandanten auf dem Knoten 0 708 gehostet sein, wobei der Xeon®-Sockel 0 einen Vierkernprozessor bereitstellt, der diesem Mandanten zugeordnet wurde. Daher kann eine QoS-Metrik die Vorsehung von einem Xeon®-Prozessor auf dem Knoten 0 an den Mandanten sein: {<PROC, XEON_CPU>}, wobei der Wert „1“ zugewiesen ist, was bedeutet, dass für die QoS-Metrik „PROC“ (Verarbeitungszuordnung), mit der Metrik XEON_CPU (Anzahl der Xeon®-CPU, die der Aufgabe zugeordnet sind), eine CPU zugewiesen ist. Eine zweite QoS-Metrik kann sein, dass die HFI 772 des Knotens 0 708 eine bestimmte dedizierte Bandbreite für 3DXP-Speicheroperationen bereitstellen muss. Diese Operationen müssen möglicherweise eine Queuing-Priorität vor bestimmten anderen Typen von Operationen erhalten. Daher kann die Metrik einen Strom identifizieren (z. B. einen bestimmten QPI-Tunnel), der 3DXP-Speicheroperationen enthält, und sie kann erfordern, dass diesem Strom eine Mindestdatenbandbreite von 2 Gb/s zugeordnet wird: {<FABRIC_BW, Gb/s>}, wobei der Wert „2“ zugewiesen wird (z. B. wird die Strukturbandbreite in Gb/s gemessen, und der zugewiesene Wert ist 2).
Andere QoS-Metriken können als nicht einschränkendes Beispiel eine Mindestbandbreite auf der Struktur 770, eine Mindestzuordnung von 3DXP-Knoten auf dem 3DXP-Server 704 und eine Mindestzuordnung von Datenbandbreite auf der HFI 772 des Knotens 1 704 umfassen. Alle diese QoS-Metriken arbeiten zusammen, um die gewünschte SLA bereitzustellen.
Nach dem Konstruieren einer SLA-Datenstruktur 812 zum Durchsetzen der Ende-zu-Ende-SLA sendet der Orchestrator 802 die SLA-Datenstruktur 812 zu dem SLA-Zielknoten 804. Der SLA-Zielknoten 804 ist der Knoten, der den Vorteil der SLA erhalten soll (d. h., in diesem Beispiel, der Knoten 0 708). Der SLA-Zielknoten 804 kann eine SLA-Eingangslogikstruktur, einschließlich einer geeigneten Schaltungsanordnung und optional Software oder Firmware, zum Empfangen der SLA-Datenstruktur 812 von dem Orchestrator 802 haben. Der SLA-Zielknoten 804 kann dann die SLA-Datenstruktur 812 aufgliedern, um die einzelnen QoS-Metriken für verschiedene nachgelagerte Ressourcen 806 zu trennen. Nach dem Aufgliedern der einzelnen QoS-Metriken kann der SLA-Zielknoten 804 eine Ausgangslogikstruktur der QoS-Metrik betreiben, einschließlich einer geeigneten Schaltungsanordnung und optional Software oder Firmware, um die einzelnen QoS-Metriken an die entsprechenden Ressourcen zu verteilen. Mit anderen Worten kann der SLA-Zielknoten 804 eine HFI-Metrik für seine eigene HFI bereitstellen und kann an die Struktur die geeignete Strukturmetrik und an den Knoten 3 704 die Metriken, die auf diesen Knoten durchgesetzt werden sollen, verteilen.
Es ist anzumerken, dass im vorherigen Beispiel die „SLA-Struktur“ als von „QoS-Metriken“ verschieden besprochen wird. Dies soll keine erforderliche strenge Definition von „SLA“ im Gegensatz zu „QoS“ implizieren. Stattdessen wird „SLA“ in dieser gesamten Beschreibung verwendet, um von der Architektur „auf höherer Ebene“ zu sprechen, die ein zu erreichendes Ende-zu-Ende-Gesamtergebnis angibt, während sich „QoS-Metriken“ auf die Spezifikationen oder Zuordnungen beziehen, die einzelne Vorrichtungen oder Ressourcen bereitzustellen angewiesen werden, um die gewünschte SLA zu erreichen. Daher sind diese Begriffe als im weiteren Sinne jede solche kompatible Struktur umfassend zu verstehen.
Unterstützung für diese Architektur kann in mehr als einem Teil des Datenzentrums umgesetzt werden.
In einem Beispiel kann das Strukturprotokoll erweitert werden, um eine neue Spezies von Strömen bereitzustellen (z. B. Ströme auf der QPI-Schicht 4), die SLA-Anforderungen und -Reaktionen transportieren, einschließlich der Verteilung von QoS-Metriken. Diese Ströme können von Knoten oder Anwendungen verwendet werden, um eine Ende-zu-Ende-SLA einzurichten, wobei die HFI Zugriff auf die gemeinsam genutzte Ressource bereitstellt.
Die HFI kann erweitert werden, um Mechanismen für Anwendungs- oder Knotenkomponenten bereitzustellen, um SLA-Nachrichten für dezentrale, gemeinsam genutzte Ressourcen zu erzeugen, wie ausführlicher in 11 dargestellt. Im umgekehrten Fall kann die HFI auch eingehende Anforderungen verarbeiten, um eine QoS-Metrik für eine Ressource einzurichten, für die die HFI Zugriff bereitstellt.
Die Struktur selbst kann auch erweitert werden, um ein zentralisiertes oder verteiltes Verzeichnis bereitzustellen, wo sich Anwendungen oder Knoten registrieren und wo sie ermitteln können, welche über die Struktur verbundenen gemeinsam genutzten Ressourcen SLA-Semantik implementieren und welche QoS-Metriken verwendet werden, um die SLA darzustellen.
Es ist anzumerken, dass, während die hierin dargestellten Ausführungsformen eine Struktur wie etwa Omnipath erörtern, die Lehren dieser Beschreibung auch mit anderen Typen von Netzwerktechnologien kompatibel sind, einschließlich, beispielsweise, Ethernet, wie in 12 - 15 dargestellt.
9 ist eine Blockdiagrammdarstellung eines Datenzentrums, die eine QoS-Überwachung gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung darstellt.
Auch hier hostet der Knoten 0 708 eine Anwendung, die ein Ziel für eine SLA sein kann. Der Knoten 0 708 ist über die Struktur 770 kommunikativ mit dem Knoten 1 704, einem 3DXP-Server, gekoppelt.
Wie oben erörtert, tragen mehrere QoS-Metriken zur Bereitstellung einer ganzheitlichen Ende-zu-Ende-SLA für die Anwendung bei. Das Bereitstellen der SLA kann als ein zweiphasiger Prozess beschrieben werden. In der ersten Phase, wie in 9 gezeigt, werden Ressourcenüberwachungen auf die verschiedenen Ressourcen angewendet, die sich auf eine künftige SLA auswirken können. Beispielsweise sind in diesem Fall der Prozessor 902, die HFI 772-1, eine Eintrittsschnittstelle auf der Struktur 770, interne Ressourcen der Struktur 770, eine Austrittsschnittstelle auf der Struktur 770, die HFI 772-2 und eine Zuordnung von 3DXP-Knoten allesamt Ressourcen, die ein Faktor in der gewünschten SLA zum Bereitstellen einer bestimmten Speicherbandbreite sind.
Daher können sieben verschiedene Ressourcenüberwachungen eingesetzt werden, um die Ressourcenausnutzung zu überwachen und zu bestimmen, ob aktuelle Datenzentrumsanforderungen erfüllt werden. Es ist anzumerken, dass in dieser Phase eine spezifische Ende-zu-Ende-SLA möglicherweise noch nicht eingerichtet werden kann. Stattdessen kann das Netzwerk überwacht werden, um sicherzustellen, dass bestehende Anforderungen erfüllt werden. In einer Ausführungsform kann Intel® Resource Director Technology™ (RDT) eine wertvolle Ressource zum Messen und Verfügbarmachen von QoS- und Leistungsmetriken für verschiedene Ressourcen sein.
In diesem Fall kann die Ressourcenüberwachung 1 den Prozessor 902 überwachen und bestimmen, ob die Zuordnung von einem Mehrkernprozessor ausreicht, um die Anforderungen zu erfüllen. Die Ressourcenüberwachung 2 überwacht die HFI 772-1 und hilft zu bestimmen, ob die Datenbandbreite, die auf der HFI 772-1 zugeordnet ist, ausreicht, um die Anforderungen zu erfüllen. Die Ressourcenüberwachung 3 überwacht eine Eintrittsschnittstelle auf der Struktur 770. Die Ressourcenüberwachung 4 überwacht die Zuordnung von internen Ressourcen (z. B. Verarbeitungsbandbreite, Prioritäts-Queuing) auf der Struktur 770. Die Ressourcenüberwachung 5 überwacht eine Austrittsschnittstelle auf der Struktur 770. Die Ressourcenüberwachung 6 überwacht die Zuordnung von Ressourcen auf der HFI 772-2 des Knotens 1 704. Die Ressourcenüberwachung 7 überwacht die Zuordnung von 3DXP-Speicherknoten auf dem Knoten 1 704. In einem Beispiel dient HFI die 772-1 als der Agent zum Verteilen der Ressourcenüberwachungen und Erfassen von Eingängen, ähnlich der in 8 beschriebenen Verteilung von QoS-Metriken. In diesem Fall kann der Orchestrator 802 eine Ressourcenüberwachungsdatenstruktur, einschließlich Ressourcenüberwachungen für die Zielressourcen, an die HFI 772-1 senden. Die HFI 772-1 kann dann diese Ressourcenüberwachungen an die Ressourcen verteilen. In einigen Ausführungsformen können Ressourcen direkt an den Orchestrator 802 melden, während in anderen Ausführungsformen die HFI 772-1 Ressourcennutzungsberichte erfassen und zusammenfassen und diese wieder dem Orchestrator 802 bereitstellen kann.
Durch ein Überwachen der Ressourcen mit Ressourcenüberwachungen identifiziert der Orchestrator 802, welche Ressourcen als Engstellen bei der Erfüllung aktueller Netzwerkanforderungen wirken können, und er kann bestimmen, dass möglicherweise eine SLA eingerichtet werden muss, um die Netzwerkanforderungen zu erfüllen.
10 ist ein Blockdiagramm des Datenzentrums 700, das eine zweite Phase darstellt, in der QoS-Metriken an die verschiedenen Ressourcen verteilt werden. Es ist anzumerken, dass das hier gezeigte Verfahren keine „Phase 2“ sein muss. Das zweiphasige Verfahren wird hierin als ein Möglichkeit zum Einrichten einer SLA offenbart. In anderen Ausführungsformen kann eine SLA einfach durch einen menschlichen Benutzer, durch Vertrag oder durch andere geeignete Mittel eingerichtet werden.
In diesem Beispiel ist die HFI 772-1 der Agent zum Verteilen von Ressourcen. Dies ist vorteilhaft, da in vielen modernen Architekturen die HFI 772 mit dem Prozessor verbunden sein kann und daher mit dem Prozessor mit nahezu Hardwaregeschwindigkeit kommunizieren kann.
Wie in Verbindung mit 8 erörtert, können QoS-Metriken an alle Ressourcen verteilt werden, die in der Kette von Ressourcen, die die SLA beeinflussen, identifiziert sind. Wie oben erörtert, kann jede von diesen ein Name-Wert-Paar umfassen, das eine für die Ressource geeignete Metrik angibt.
In einem Beispiel können einige oder alle Ressourcen eine Schnittstelle verfügbar machen, um:

a. jeder Anwendung A_i (in einem Knoten RN_j ausgeführt) zu erlauben, eine SLA (oder eine QoS-Metrik, die eine SLA unterstützt) für die Ressource R_i (dargestellt durch ein RN_j) einzurichten
b. jedem Knoten RN_j zu erlauben, eine SLA (oder eine QoS-Metrik, die eine SLA unterstützt) für eine Ressource R_i (dargestellt durch ein RN_j) einzurichten

Wie oben dargestellt, entspricht eine QoS-Metrik, als Teil einer SLA, einem Zuordnen einer angegebenen Menge einer Ressource. Die Zuordnung kann zu einem spezifischen Knoten (RN_x), einer Anwendung (A_y) oder einer anderen identifizierbaren Entität, die zum Empfangen der SLA bestimmt ist, erfolgen.
Beim Verteilen von QoS-Metriken zur Unterstützung der SLA können die Metriken in einer einzelnen „Kette“ verteilt werden, was in diesem Fall der Ordinalnummerierung der Ressourcenüberwachungen und QoS-Metriken entspricht. In diesem Fall können die QoS-Metrik 1 und die QoS-Metrik 2 selbstüberwachend sein, da sie sich auf dem „Zielknoten“ für die SLA befinden.
Wenn die HFI 772-1 die verbleibenden QoS-Metriken sendet, können diese in einer Kette ausgehen, sodass sie der Reihe nach auf die ordinalen Ressourcen 3 - 7 treffen. Wenn die einzelnen QoS-Metriken ihre Zielressource treffen, verteilt die Nachricht die QoS-Metrik über die auf der Ressource verfügbar gemachte API an die Ressource. Nach dem Empfangen der QoS-Metrik kann die Ressource bestimmen, ob sie in der Lage ist, die Metrik zu unterstützen. Wenn dies der Fall ist, sendet sie ein ACK zurück stromaufwärts zu dem Zielknoten, wodurch angezeigt wird, dass die Metrik unterstützt wird. Wenn die Ressource die Metrik nicht unterstützen kann (z. B. wenn die Metrik auf irgendeine Weise falsch konfiguriert ist oder die Ressource bereits zu viele zusätzliche QoS unterstützt und die SLA nicht garantieren kann), sendet sie ein NAK zurück stromaufwärts. Wenn die HFI ein NAK von einem der Knoten in der Kette empfängt, schlägt die SLA fehl. Bei einem SLA-Fehler muss möglicherweise eine Abhilfemaßnahme eingeleitet werden, wie etwa ein Bereitstellen zusätzlicher Ressourcen auf dem Datenzentrum zum Unterstützen der SLA.
11 ist ein Blockdiagramm einer HFI 772 gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung. In dieser Ansicht sind bestimmte ausgewählte Elemente gezeigt, um relevante Merkmale der HFI 772 darzustellen. Insbesondere sind hier die Strukturschnittstellenlogik 1170, die QPI-Schnittstellenlogik 1172, die HFI-Logik 1104, die SLA-Eingangslogik 1116 und die Metrikausgangslogik 1112 dargestellt.
Die „Logik“ jedes der folgenden Blöcke kann eine Engine für die relevante Funktion implementieren, die spezifische Hardware, die dazu ausgelegt ist, die Funktion der Engine durchzuführen (z. B. einen ASIC, FPGA oder Ähnliches), einen programmierbaren Prozessor oder eine andere programmierbare Logik und Firmware oder Software, die Anweisungen zum Ausführen der Funktion der Engine bereitstellt, umfassen kann. Es ist anzumerken, dass Logik als materielles, nicht-flüchtiges computerlesbares Medium angesehen werden kann, egal ob sie in Hardware (z. B. Hardwareanweisungen auf einem ASIC), oder in Software (z. B. Softwareanweisungen zum Programmieren eines programmierbaren Prozessors) codiert ist.
Die beispielhafte QPI-Schnittstelle 1172 stellt eine mechanische und elektrische Verbindung mit einem QPI-Bus auf dem Knoten 708 bereit. QPI wird als ein nicht einschränkendes Beispiel eines Datenbusses verwendet, und es ist anzumerken, dass andere Datenbusse verwendet werden können, wie etwa PCI, PCIe, USB oder eine andere serielle oder parallele Schnittstellentechnologie. In diesem Beispiel stellt die QPI-Schnittstelle 1172 eine Kommunikation mit dem Knoten bereit.
Die Strukturschnittstellenlogik 1170 stellt eine mechanische und elektrische Verbindung mit der Struktur 770 bereit. Die Strukturschnittstellenlogik 1170 kann eine Verbindung mit, beispielsweise, Intel® Omnipath® oder einer anderen Strukturverbindung sein.
Die HFI-Logik 1104 stellt eine interne Logik zum Weiterleiten von Kommunikationspaketen von der QPI-Schnittstelle 1172 zu der Strukturschnittstellenlogik 1170 bereit und ermöglicht ansonsten die Fähigkeit des Knotens 708, über die Struktur 770 mit dem Datenzentrum in seiner Gesamtheit zu kommunizieren.
Die SLA-Eingangslogik 1116 und die Metrikausgangslogik 1112 sind neuartige Logikblöcke, die dazu ausgelegt sind, eine Ende-zu-Ende-SLA bereitzustellen, wie hierin beschrieben. In diesem Beispiel werden die SLA-Eingangslogik 1116 und die QoS-Metrikausgangslogik 1112 als auf der HFI 772 gehostet dargestellt. Allerdings können die zwei Engines gemeinsam als eine SLA-Durchsetzungsschaltung aufgefasst werden, und eine SLA-Durchsetzungsschaltung kann, im allgemeinen Fall, auf jeder Plattform gehostet sein. Daher kann eine SLA-Durchsetzungsschaltung, allgemein gesprochen, jede Kombination von Hardware, optional mit unterstützender Software oder Firmware, die dazu ausgelegt ist, die Ende-zu-Ende- oder ganzheitliche SLA der vorliegenden Beschreibung auszuführen, umfassen.
Die SLA-Eingangslogik 1116 ist eine Engine, die eine SLA-Datenstruktur von dem Orchestrator 802 empfängt. Wie oben beschrieben, kann die SLA-Datenstruktur eine Liste von Ressourcen umfassen, denen gegebene QoS-Metriken zugeordnet sein müssen, und sie kann auch einen Strom identifizieren, der ein Ziel für die SLA ist.
Die SLA-Durchsetzungsschaltung gliedert die SLA in mehrere einzelne QoS-Metrikdatenstrukturen auf, und die Metrikausgangslogik 1112 drückt diese QoS-Metrikdatenstrukturen über die Struktur 770 zu nachgelagerten Vorrichtungen.
In einem Beispiel umfasst die SLA-Eingangslogik 1116 Strukturen (wie etwa eine SLA-Ressourcen-ID-Tabelle), die eine Abbildung von allen den unterschiedlichen gemeinsam genutzten Ressourcen, die in dem Knoten gehostet werden und die SLA-Anforderungen akzeptieren, enthalten. Jede Ressource kann eine eindeutige On-Die-Verbindungskennung (wird verwendet, um die SLA-Anforderung durch einen ENQ-Befehl zu dem Agenten weiterzuleiten, der die Ressource steuert) und die davon akzeptierten QoS-Metriken enthalten.
Die SLA-Ressourcen-ID-Tabelle kann zum Zeitpunkt des Hochfahrens konfiguriert werden und kann über alle unterschiedlichen Teile des Datenzentrums kohärent sein. Daher kann ein dezentraler Knoten SLA-Anforderungen für spezifische Knoten und spezifische Ressourcen, die von diesem Knoten gehostet werden, erzeugen.
Von der Anwendungsperspektive aus kann die SLA-Durchsetzungsschaltung Mechanismen bereitstellen, um zu ermitteln, welche Ressourcen im System verfügbar sind, welche von ihnen eine QoS-Metrik empfangen können und was diese QoS-Metriken sind. Diese Ermittlung kann durch jedes geeignete Mittel bereitgestellt werden. Als nicht einschränkendes Beispiel:

a. Ein bestehender Knotenmechanismus kann verwendet werden, wie etwa CPUID.
b. Die HFI-Architektur kann erweitert werden, um die Informationen, die in einem spezifischen Bereich im physischen Speicher gespeichert sind, mit dem Ort dieses Speichers, verfügbar zu machen. Intel® Resource Director Technology™ (RDT) kann hilfreiche Vorrichtungen, wie etwa Register, zum Verfügbarmachen dieser Speicherorte bereitstellen.
c. Eine neuartige zentralisierte oder verteilte Strukturkomponente kann bereitgestellt sein, um als ein Verzeichnis für Ressourcen-QoS-Daten zu fungieren.

12 - 16 stellen ein nicht einschränkendes Beispiel von unterschiedlichen Typen von Ressourcen dar, die das Ziel einer SLA sein können. In diesem Beispiel werden Ressourcen, als nicht einschränkendes Beispiel, in fünf unterschiedliche Klassen unterteilt. In jedem der dargestellten Beispiele ist eine SLA gezeigt. Die dargestellte SLA kann die „Ziel“-SLA für den identifizierten Strom sein, oder sie können, in Verbindung mit anderen Ressourcen, angegebene QoS-Metriken sein, die einen Teil einer SLA bilden. Daher sollte der Begriff „SLA“, wie er in diesen Figuren verwendet wird, als im weiten Sinne beide Verwendungen umfassend angesehen werden.
Insbesondere stellt 12 ein Beispiel einer SLA für eine zusammengefasste Ressource dar. In diesem Beispiel werden mehrere SLA einem Speicher zugeordnet, der in diesem Fall ein persistenter schneller Speicher ist, wie 3DXP, und der auf einem dedizierten Speicherserver 704 gehostet wird. Es ist anzumerken, dass die mehreren SLA nebeneinander bestehen und sich nicht gegenseitig ausschließen. Außerdem ist anzumerken, dass die SLA unterschiedliche Servicelevel zuordnen können. Diese SLA können nebeneinander in einem einzelnen System bestehen, solange die SLA, wie zugeordnet, nicht die Fähigkeit des Systems überfordern, die Anforderungen zu erfüllen. Wenn der Bedarf an SLA die verfügbaren Ressourcen überschreitet, können neue Ressourcen hinzugefügt werden. Es ist anzumerken, dass diese neuen Ressourcen, um mit der Ende-zu-Ende-SLA-Architektur kompatibel zu sein, dazu ausgelegt sein sollten, die geeigneten API zum Akzeptieren von QoS-Metriken verfügbar zu machen, wie oben erörtert.
13 stellt ein Beispiel dar, bei dem mehrere SLA auf die Struktur gerichtet sind. In diesem Fall kann jede SLA eine bereitzustellende Strukturbandbreite angeben. Auch hier schließen sich die SLA nicht gegenseitig aus und können gleichzeitig unterstützt werden, solange die Struktur selbst ausreichend verfügbare Bandbreite hat.
14 stellt ein Beispiel dar, bei dem eine oder mehrere Knotenressourcen als eine gemeinsam genutzte Ressource verfügbar gemacht werden. In diesem Beispiel ist der Knoten 1104, wie der Knoten 708, ein gewöhnlicher Verarbeitungsknoten, der zwei Xeon®-Prozessorsockel und Speicherressourcen, die zur gemeinsamen Nutzung für andere Knoten verfügbar gemacht werden, umfasst. Auch hier können mehrere SLA zugeordnet werden und sind akzeptabel, solange der Knoten 1104 in der Lage ist, die SLA zu unterstützen.
15 stellt ein Beispiel dar, bei dem Software, die auf dem Knoten 1204 ausgeführt wird, als eine gemeinsam genutzte Ressource verfügbar gemacht wird. In diesem Beispiel ist die Software ein dezentrales Datenbankspeicherprotokoll (d. h., der Knoten 1204 kann als ein Datenbankserver fungieren). SLA können für Mindestdatenbankzugriffsgeschwindigkeiten angegeben werden. Auch hier können mehrere SLA angegeben werden und sind akzeptabel, solange der Knoten 1204 in der Lage ist, die verschiedenen SLA weiter zu unterstützen.
17 ist ein Flussdiagramm eines Verfahrens 1700 zum Registrieren einer QoS-Metrik zur Unterstützung einer SLA gemäß einem oder mehreren Beispielen der vorliegenden Beschreibung.
In Block 1702 möchte eine Anwendung, wie etwa die Anwendung 224, die auf dem Knoten 0 708 ausgeführt wird, eine SLA für eine Ressource anfordern, auf die über die Struktur und eine Kette von Ressourcen zugegriffen werden kann, von denen jede eine bestimmte QoS-Metrik erfordern kann. Die abschließende Ressource in der Kette kann als die Endpunktressource angesehen werden und kann das letztliche Ziel der SLA sein.
In Block 1702 empfängt die HFI für den Knoten, der die Anwendung hostet, von der Steuerung, wie etwa dem Orchestrator 802, eine SLA-Datenstruktur, die Daten umfasst, die zum Verteilen der SLA an die Knoten erforderlich sind, wie etwa mehrere QoS-Metriken für jede Ressource in der Kette.
In Block 1704 gliedert die HFI die QoS-Metriken für die einzelnen Ressourcen auf oder bereitet sich anderweitig darauf vor, die SLA an die Knoten in der Kette zu verteilen. Es ist anzumerken, dass die SLA-Datenstruktur in einigen Ausführungsformen bereits in einem geeigneten Format zum Verteilen vorliegen kann, wobei in diesem Fall ein Aufgliedern möglicherweise nicht erforderlich ist.
In Block 1706 sendet die Anwendung die QoS-Metriken an die HFI. In einem Beispiel kann dies über eine UPI-Nachricht vom Typ „ENQ“ (Enquiry, Abfrage) erfolgen. Der Befehl enthält die Speicheradresse, an der die SLA-Parameter gespeichert sind. Die HFI liest die Parameter aus dem Speicher und erzeugt eine geeignete Nachricht für die Struktur, wie etwa „FABRIC_SLA“, wobei die Nachricht auf die Endpunktressource abzielt. Da die Zwischenressourcen in der Kette sind, die zur Endpunktressource führt, wird die Nachricht dadurch naturgemäß an diese Ressourcen verteilt.
Jede der Ressourcen in der Kette prüft, ob sie die SLA unterstützen kann, indem sie die darauf anwendbare(n) QoS-Metrik oder - Metriken erfüllt. Wenn die Ressource die SLA unterstützen kann, sendet sie ein ACK stromaufwärts zurück zu der HFI und fährt dann fort, die Nachricht entlang der Kette weiter zu verteilen. Wenn sie es nicht kann, sendet sie ein NAK stromaufwärts zurück, wodurch angezeigt wird, dass sie die SLA nicht wie angefordert unterstützen kann.
In dem Entscheidungsblock 1708 prüft die HFI, ob ein ACK von jeder Ressource in der Kette empfangen wurde. Wenn alle entsprechenden ACK empfangen wurden, ist das Verfahren in Block 1798 beendet.
Zurückkehrend zu Block 1708, schlägt das Verfahren in Block 1799 fehl, wenn eine oder mehrere Ressourcen ein NAK zurückgegeben haben, wodurch angezeigt wird, dass sie die SLA nicht unterstützen können. In diesem Fall muss möglicherweise eine geeignete Abhilfemaßnahme eingeleitet werden, wie etwa ein Reparieren der Datenstruktur oder ein Zuordnen von mehr Ressourcen zum Unterstützen der neuen SLA.
Es ist anzumerken, dass, während das vorherige Beispiel einen ENQ-Befehl darstellt, andere bestehende Schnittstellen, wie etwa PQoS, verwendet werden können.
Das vorherige Beispiel geht außerdem davon aus, dass die Anforderung durch eine Anwendung initiiert wird. Allerdings können auch Nicht-Software-Ressourcen (z. B. die HFI) SLA-Anforderungen an dezentrale Ressourcen initiieren.
In einigen Ausführungsformen kann ein einzelner Strom mehrere SLA einrichten, die einige gebräuchliche Anforderungen oder Ressourcen gemeinsam haben. Dies kann die Antwortzeit beim Einrichten einer Ende-zu-Ende-SLA deutlich verringern.
Das Vorgenannte stellt Merkmale verschiedener Ausführungsformen dar, sodass Fachleute verschiedene Aspekte der vorliegenden Offenbarung besser verstehen können. Für Fachleute versteht es sich, dass sie die vorliegende Offenbarung als eine Grundlage zum Konzipieren oder Modifizieren anderer Prozesse und Strukturen zum Ausführen derselben Zwecke und/oder Erreichen der gleichen Vorteile der hierin eingeführten Ausführungsformen leicht verwenden können. Fachleute sollten auch erkennen, dass solche äquivalenten Konstruktionen nicht vom Geist und Schutzumfang der vorliegenden Offenbarung abweichen und dass sie hieran verschiedene Änderungen, Ersetzungen und Abwandlungen vornehmen können, ohne vom Geist und Schutzumfang der vorliegenden Offenbarung abzuweichen.
Jedes hier offenbarte Hardwareelement kann ganz oder teilweise leicht in einem System-on-a-Chip (SoC) bereitgestellt werden, einschließlich in einem CPU-Gehäuse (Central Processing Unit, zentrale Verarbeitungseinheit). Ein SoC stellt eine integrierte Schaltung (IC, Integrated Circuit) dar, die Komponenten eines Computers oder eines anderen elektronischen System in einem einzelnen Chip integriert. Somit können, beispielsweise, Clientvorrichtungen oder Servervorrichtungen, ganz oder teilweise, in einem SoC bereitgestellt werden. Das SoC kann digitale, analoge, Mischsignal- und Funkfrequenzfunktionen enthalten, von denen alle auf einem einzelnen Chipsubstrat bereitgestellt werden können. Andere Ausführungsformen können ein Multichipmodul (MCM) umfassen, bei dem sich mehrere Chips innerhalb eines einzelnen elektronischen Gehäuses befinden und dazu ausgelegt sind, durch das elektronische Gehäuse eng miteinander zu interagieren. In verschiedenen anderen Ausführungsformen können die hierin offenbarten Rechenfunktionalitäten in einem oder mehreren Siliziumkernen in anwendungsspezifischen integrierten Schaltkreisen (ASIC, Application Specific Integrated Circuits), feldprogrammierbaren Gate-Arrays (FPGA, Field Programmable Gate Arrays) und anderen Halbleiterchips implementiert sein.
Es ist außerdem anzumerken, dass in bestimmten Ausführungsformen einige der Komponenten ausgelassen oder konsolidiert sein können. In einem allgemeinen Sinn können die in den Figuren dargestellten Anordnungen in ihren Repräsentationen logischer sein, während eine physische Architektur verschiedene Umsetzungen, Kombinationen und/oder Hybride aus diesen Elementen umfassen kann. Es ist wesentlich anzumerken, dass unzählige mögliche Ausführungskonfigurationen verwendet werden können, um die hier dargestellten operativen Ziele zu erreichen. Entsprechend hat die zugehörige Infrastruktur eine Myriade von Ersatzanordnungen, Ausführungsauswahlen, Vorrichtungsmöglichkeiten, Hardwarekonfigurationen, Softwareimplementierungen und Geräteoptionen.
In einem allgemeinem Sinn kann jeder geeignet konfigurierte Prozessor jeden Typ von Anweisungen in Verbindung mit den Daten ausführen, um die hierin ausführlich beschriebenen Operationen zu erreichen. Jeder hierin offenbarte Prozessor kann ein Element oder einen Artikel (zum Beispiel Daten) von einem Zustand oder Ding in einen anderen Zustand oder ein anderes Ding umwandeln. In einem anderen Beispiel können einige der hierin dargestellten Aktivitäten mit fester Logik oder programmierbarer Logik implementiert sein (beispielsweise von einem Prozessor ausgeführte Software und/oder Computeranweisungen), und die hierin identifizierten Elemente können ein beliebiger Typ eines programmierbaren Prozessors, eine programmierbare digitale Logik (beispielsweise ein feldprogrammierbares Gate-Array (FPGA, Field Programmable Gate Array), ein löschbarer, programmierbarer Nur-Lese-Speicher (EPROM, Erasable Programmable Read Only Memory), ein elektrisch löschbarer, programmierbarer Nur-Lese-Speicher (EEPROM, Electrically Erasable Programmable Read Only Memory), ein ASIC, der digitale Logik umfasst, Software, Code, elektronische Anweisungen, Flash-Speicher, optische Platten, CD-ROM, DVD-ROM, magnetische oder optische Karten, andere Typen von maschinenlesbaren Medien, die zum Speichern von elektronischen Anweisungen geeignet sind, oder jede geeignete Kombination davon sein.
Im Betrieb kann ein Speicher Informationen in jedem geeigneten Typ von materiellem, nicht-flüchtigem Speichermedium (beispielsweise Direktzugriffsspeicher (RAM, Random Access Memory), Nur-Lese-Speicher (ROM, Read Only Memory), feldprogrammierbares Gate-Array (FPGA, Field Programmable Gate Array), löschbarer, programmierbarer Nur-Lese-Speicher (EPROM, Erasable Programmable Read Only Memory), elektrisch löschbarer, programmierbarer Nur-Lese-Speicher (EEPROM, Electrically Erasable Programmable Read Only Memory) usw.), Software, Hardware (beispielsweise Prozessoranweisungen oder Mikrocode) oder in jeder bzw. jedem anderen geeigneten Komponente, Vorrichtung, Element oder Objekt, wo angemessen und basierend auf speziellen Anforderungen, speichern. Ferner können die Informationen, die nachverfolgt, gesendet, empfangen oder in einem Prozessor gespeichert werden, in jeder bzw. jedem Datenbank, Register, Tabelle, Cache, Queue, Steuerliste oder Speicherstruktur, basierend auf speziellen Anforderungen und Implementierungen, die allesamt in jedem geeigneten Zeitrahmen referenziert werden können, bereitgestellt werden. Jedes der hierin offenbarten Speicher- oder Speicherplatzelemente sollte wie zutreffend als innerhalb der weiten Begriffe „Speicher“ und „Speicherplatz“ umfasst ausgelegt werden. Ein nicht-flüchtiges Speichermedium hierin soll ausdrücklich jede nicht-flüchtige Hardware für einen bestimmten Zweck oder programmierbare Hardware umfassen, die dazu ausgelegt ist, die offenbarten Operationen bereitzustellen oder einen Prozessor zu veranlassen, die offenbarten Operationen durchzuführen.
Computerprogrammlogik, die die hierin beschriebene Funktionalität ganz oder teilweise implementiert, ist in verschiedenen Formen ausgeführt, einschließlich, aber in keiner Weise darauf beschränkt, eine Quellcodeform, eine computerausführbare Form, Maschinenanweisungen oder Mikrocode, programmierbare Hardware und verschiedene Zwischenformen (beispielsweise Formen, die durch einen Assembler, Compiler, Linker oder Locator erzeugt werden). In einem Beispiel umfasst Quellcode eine Serie von Computerprogrammanweisungen, die in verschiedenen Programmiersprachen implementiert sind, wie etwa einem Objektcode, einer Assembly-Sprache oder einer höheren Sprache wie OpenCL, FORTRAN, C, C++, JAVA oder HTML zur Verwendung mit verschiedenen Betriebssystemen oder Betriebsumgebungen, oder in Hardwarebeschreibungssprachen, wie Spice, Verilog und VHDL. Der Quellcode kann verschiedene Datenstrukturen und Kommunikationsnachrichten definieren und verwenden. Der Quellcode kann in einer computerausführbaren Form (z. B. über einen Interpreter) vorliegen, oder der Quellcode kann in eine computerausführbare Form umgewandelt (z. B. über einen Translator, Assembler oder Compiler) oder in eine Zwischenform, wie etwa einen Bytecode, umgewandelt sein. Wo angemessen, kann jedes des Vorgenannten verwendet werden, um geeignete diskrete oder integrierte Schaltungen zu bauen oder zu beschreiben, egal ob sequenziell, kombinatorisch, Zustandsmaschinen oder anderweitig.
In einer Ausführungsform kann eine beliebige Anzahl von elektrischen Schaltungen der FIGUREN auf einer Platte einer zugehörigen elektronischen Vorrichtung implementiert sein. Die Platte kann eine allgemeine Leiterplatte sein, die verschiedene Komponenten des internen elektronischen Systems der elektronischen Vorrichtung tragen und, ferner, Verbindungselemente für andere periphere Vorrichtungen bereitstellen kann. Genauer kann die Platte die elektrischen Verbindungen bereitstellen, über die die anderen Komponenten des Systems elektrisch kommunizieren können. Jeder geeignete Prozessor und Speicher kann basierend auf bestimmten Konfigurationsanforderungen, Verarbeitungsanforderungen und Rechenausführungen in geeigneter Weise mit der Platte gekoppelt sein. Andere Komponenten, wie etwa externer Speicher, zusätzliche Sensoren, Steuerungen für die Audio-/Videoanzeige und periphere Vorrichtungen, können an der Platte als Plugin-Karten, über Kabel angeschlossen oder in die Platte selbst integriert sein. In einem anderen Beispiel können die elektrischen Schaltungen der FIGUREN als eigenständige Module (z. B. eine Vorrichtung mit zugehörigen Komponenten und einer Schaltungsanordnung, die dazu ausgelegt sind, eine spezifische Anwendung oder Funktion durchzuführen) implementiert sein oder als Plugin-Module in anwendungsspezifischer Hardware von elektronischen Vorrichtungen implementiert sein.
Es ist anzumerken, das bei den zahlreichen hierin angegebenen Beispielen eine Interaktion in Bezug auf zwei, drei, vier oder mehr elektrische Komponenten beschrieben sein kann. Dies erfolgte allerdings nur aus Gründen der Klarheit und als Beispiel. Es versteht sich, dass das System in jeder geeigneten Weise konsolidiert oder neu konfiguriert werden kann. Zusammen mit ähnlichen Ausführungsalternativen kann jede/s der dargestellten Komponenten, Module und Elemente der FIGUREN in verschiedenen möglichen Konfigurationen kombiniert werden, die allesamt innerhalb des breiten Schutzumfangs dieser Beschreibung liegen. In bestimmten Fällen kann es einfacher sein, eine oder mehrere der Funktionalitäten eines gegebenen Satzes von Strömen zu beschreiben, indem nur auf eine begrenzte Anzahl von elektrischen Elementen Bezug genommen wird. Es versteht sich, dass die elektrischen Schaltungen der FIGUREN und ihre Lehren leicht skalierbar sind und eine große Anzahl von Komponenten sowie kompliziertere/komplexere Anordnungen und Konfigurationen beinhalten können. Entsprechend sollen die bereitgestellten Beispiele nicht den Schutzumfang begrenzen oder die breiten Lehren der elektrischen Schaltungen als potenziell auf eine Myriade von anderen Architekturen angewendet hemmen.
Zahlreiche andere Änderungen, Ersetzungen, Variationen, Abwandlungen und Modifikationen können für Fachleute festgestellt werden, und die vorliegende Offenbarung soll all diese Änderungen, Ersetzungen, Variationen, Abwandlungen und Modifikationen als in den Schutzumfang der beigefügten Ansprüche fallend umfassen. Zur Unterstützung des United States Patent and Trademark Office (USPTO) und, zusätzlich, aller Leser jedes auf der Grundlage dieser Anmeldung erteilten Patents bei der Auslegung der hier beigefügten Ansprüche möchte der Anmelder anmerken, dass der Anmelder: (a) nicht beabsichtigt, dass einer der beigefügten Ansprüche Paragraph sechs (6) von 35 U.S.C. Abschnitt 112 (vor-AIA) oder Paragraph (f) desselben Abschnitts (nach-AIA), wie zum Zeitpunkt dieser Anmeldung vorhanden, anführt, sofern nicht die Wörter „Mittel zu“ oder „Schritte für“ spezifisch in den bestimmten Ansprüchen verwendet werden; und (b) nicht beabsichtigt, diese Offenbarung durch irgendeine Aussage in der Beschreibung in einer Weise einzuschränken, die ansonsten nicht ausdrücklich in den beigefügten Ansprüchen widergespiegelt wird.
Beispielhafte Implementierungen
Offenbart wird in einem Beispiel eine Strukturschnittstellenvorrichtung, die Folgendes umfasst: eine Strukturverbindung zum kommunikativen Koppeln mit einer Struktur; eine SLA-Eingangslogik (Service Level Agreement, Service-Level-Vereinbarung) zum Empfangen einer SLA-Datenstruktur von einer Steuerung, wobei die SLA-Datenstruktur eine Ende-zu-Ende-SLA für einen von mehreren Ressourcen bereitgestellten Ressourcenstrom bereitstellt und QoS-Metriken für die Ressourcen bereitstellt; und eine SLA-Ausgangslogik zum Verteilen der QoS-Metriken an die Ressourcen über die Strukturverbindung.
Außerdem wird ein Beispiel offenbart, bei dem die SLA-Eingangslogik ferner von der Steuerung eine Ressourcenüberwachungsdatenstruktur empfangen soll, die Ressourcenüberwachungen für die Ressourcen umfasst.
Außerdem wird ein Beispiel offenbart, bei dem die SLA-Ausgangslogik ferner die Ressourcenüberwachungen über die Struktur zu den Ressourcen verteilen soll.
Außerdem wird ein Beispiel offenbart, bei dem die SLA-Eingangslogik ferner eine Ressourcen-QoS-Rückkopplung von den Ressourcen empfangen soll.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen eine zusammengefasste Ressource umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen einen persistenten schnellen Speicher umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen einen Speicherpool umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen eine Strukturschnittstelle umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken eine Datenbandbreite umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken eine Speichergrößenzuordnung umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken Software umfassen, die als ein Dienst verfügbar gemacht wird.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken eine Knotenressource umfassen, die als eine gemeinsam genutzte Ressource verfügbar gemacht wird.
Außerdem wird ein Beispiel einer SLA-Durchsetzungsschaltung (Service Level Agreement, Service-Level-Vereinbarung) offenbart, die Folgendes umfasst: eine SLA-Eingangslogik (Service Level Agreement, Service-Level-Vereinbarung) zum Empfangen einer SLA-Datenstruktur von einer Steuerung, wobei die SLA-Datenstruktur eine Ende-zu-Ende-SLA für einen von mehreren Ressourcen bereitgestellten Ressourcenstrom bereitstellt und QoS-Metriken für die Ressourcen umfasst; und eine SLA-Ausgangslogik zum Verteilen der QoS-Metriken an die Ressourcen über die Strukturverbindung.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen eine zusammengefasste Ressource umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen einen persistenten schnellen Speicher umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen einen Speicherpool umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen eine Strukturschnittstelle umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken eine Datenbandbreite umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken eine Speichergrößenzuordnung umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken Software umfassen, die als ein Dienst verfügbar gemacht wird.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken eine Knotenressource umfassen, die als eine gemeinsam genutzte Ressource verfügbar gemacht wird.
Außerdem wird ein Beispiel einer Host-Struktur-Schnittstelle offenbart, die die SLA-Durchsetzungsschaltung umfasst.
Außerdem wird ein Beispiel eines Rechenknotens offenbart, der die SLA-Durchsetzungsschaltung umfasst.
Außerdem wird ein Beispiel eines Verfahrens zum Verwalten von Service-Level-Vereinbarungen (SLA, Service Level Agreements) auf einer Cloud-Architektur offenbart, das Folgendes umfasst: ein kommunikatives Koppeln mit einer Verbindung; ein Empfangen einer SLA-Datenstruktur von einer Steuerung, wobei die SLA-Datenstruktur eine Ende-zu-Ende-SLA für einen von mehreren Ressourcen bereitgestellten Ressourcenstrom bereitstellt und QoS-Metriken für die Ressourcen umfasst; und ein Verteilen der QoS-Metriken über die Strukturverbindung an die Ressourcen.
Außerdem wird ein Beispiel offenbart, das ferner Folgendes umfasst: ein Bereitstellen von Ressourcenüberwachungen für die mehreren Ressourcen und ein Bestimmen über die Ressourcenüberwachungen, dass eine gewünschte Dienstgüte (QoS, Quality of Service) für das Datenzentrum nicht erfüllt ist.
Außerdem wird ein Beispiel 4 offenbart, das ferner ein kommunikatives Koppeln mit einer Struktur umfasst.
Außerdem wird ein Beispiel offenbart, das ferner ein Empfangen einer Ressourcenüberwachungsdatenstruktur, die Ressourcenüberwachungen für die Ressourcen umfasst, von einer Steuerung umfasst.
Außerdem wird ein Beispiel offenbart, bei dem die SLA-Ausgangslogik ferner die Ressourcenüberwachungen über die Struktur zu den Ressourcen verteilen soll.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen eine zusammengefasste Ressource umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen einen persistenten schnellen Speicher umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen einen Speicherpool umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die Ressourcen eine Strukturschnittstelle umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken eine Datenbandbreite umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken eine Speichergrößenzuordnung umfassen.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken Software umfassen, die als ein Dienst verfügbar gemacht wird.
Außerdem wird ein Beispiel offenbart, bei dem die QoS-Metriken eine Knotenressource umfassen, die als eine gemeinsam genutzte Ressource verfügbar gemacht wird.
Außerdem wird ein Beispiel einer Einrichtung offenbart, die ein Mittel zum Durchführen des Verfahrens umfasst.
Außerdem wird ein Beispiel offenbart, bei dem das Mittel eine SLA-Durchsetzungsschaltung (Service Level Agreement, Service-Level-Vereinbarung) umfasst.
Außerdem wird ein Beispiel offenbart, bei dem das Mittel eine Host-Struktur-Schnittstelle umfasst.

Claims

Strukturschnittstellenvorrichtung, die Folgendes umfasst: eine Strukturverbindung zum kommunikativen Koppeln mit einer Struktur; eine SLA-Eingangslogik (Service Legal Agreement, rechtliche Service-Vereinbarung) zum Empfangen einer SLA-Datenstruktur von einer Steuerung, wobei die SLA-Datenstruktur eine Ende-zu-Ende-SLA für einen von mehreren Ressourcen bereitgestellten Ressourcenstrom bereitstellt und QoS-Metriken für die Ressourcen umfasst; und eine SLA-Ausgangslogik zum Verteilen der QoS-Metriken über die Strukturverbindung an die Ressourcen.
Strukturschnittstelle nach Anspruch 1, wobei die SLA-Eingangslogik ferner von der Steuerung eine Ressourcenüberwachungsdatenstruktur, die Ressourcenüberwachungen für die Ressourcen umfasst, empfangen soll.
Strukturschnittstelle nach Anspruch 2, wobei die SLA-Ausgangslogik ferner die Ressourcenüberwachungen über die Struktur an die Ressourcen verteilen soll.
Strukturschnittstelle nach Anspruch 2, wobei die SLA-Eingangslogik ferner die Ressourcen-QoS-Rückkopplung von den Ressourcen empfangen soll.
Strukturschnittstelle nach einem der Ansprüche 1-4, wobei die Ressourcen eine zusammengefasste Ressource umfassen.
Strukturschnittstelle nach Anspruch 5, wobei die Ressourcen einen persistenten schnellen Speicher umfassen.
Strukturschnittstelle nach Anspruch 5, wobei die Ressourcen einen Speicherpool umfassen.
Strukturschnittstelle nach einem der Ansprüche 1-4, wobei die Ressourcen eine Strukturschnittstelle umfassen.
Strukturschnittstelle nach einem der Ansprüche 1-4, wobei die QoS-Metriken eine Datenbandbreite umfassen.
Strukturschnittstelle nach einem der Ansprüche 1-4, wobei die QoS-Metriken eine Speichergrößenzuordnung umfassen.
Strukturschnittstelle nach einem der Ansprüche 1-4, wobei die QoS-Metriken Software umfassen, die als ein Dienst verfügbar gemacht wird.
Strukturschnittstelle nach einem der Ansprüche 1-4, wobei die QoS-Metriken eine Knotenressource umfassen, die als eine gemeinsam genutzte Ressource verfügbar gemacht wird.
SLA-Durchsetzungsschaltung (Service Legal Agreement, rechtliche Service-Vereinbarung), die Folgendes umfasst: eine SLA-Eingangslogik (Service Legal Agreement, rechtliche Service-Vereinbarung) zum Empfangen einer SLA-Datenstruktur von einer Steuerung, wobei die SLA-Datenstruktur eine Ende-zu-Ende-SLA für einen von mehreren Ressourcen bereitgestellten Ressourcenstrom bereitstellt und QoS-Metriken für die Ressourcen umfasst; und eine SLA-Ausgangslogik zum Verteilen der QoS-Metriken über die Strukturverbindung an die Ressourcen.
SLA-Durchsetzungsschaltung nach Anspruch 13, wobei die Ressourcen eine zusammengefasste Ressource umfassen.
SLA-Durchsetzungsschaltung nach Anspruch 14, wobei die Ressourcen einen persistenten schnellen Speicher umfassen.
SLA-Durchsetzungsschaltung nach Anspruch 14, wobei die Ressourcen einen Speicherpool umfassen.
SLA-Durchsetzungsschaltung nach Anspruch 13, wobei die Ressourcen eine Strukturschnittstelle umfassen.
SLA-Durchsetzungsschaltung nach Anspruch 13, wobei die QoS-Metriken eine Datenbandbreite umfassen.
SLA-Durchsetzungsschaltung nach Anspruch 13, wobei die QoS-Metriken eine Speichergrößenzuordnung umfassen.
SLA-Durchsetzungsschaltung nach Anspruch 13, wobei die QoS-Metriken Software umfassen, die als ein Dienst verfügbar gemacht wird.
SLA-Durchsetzungsschaltung nach Anspruch 13, wobei die QoS-Metriken eine Knotenressource umfassen, die als eine gemeinsam genutzte Ressource verfügbar gemacht wird.
Host-Struktur-Schnittstelle (Host Fabric Interface), die die SLA-Durchsetzungsschaltung nach einem der Ansprüche 13-21 umfasst.
Rechenknoten, der die SLA-Durchsetzungsschaltung nach einem der Ansprüche 13-21 umfasst.
Verfahren zum Verwalten von Service-Level-Vereinbarungen (SLA, Service Level Agreements) auf einer Cloud-Architektur, das Folgendes umfasst: kommunikatives Koppeln mit einer Verbindung; Empfangen einer SLA-Datenstruktur von einer Steuerung, wobei die SLA-Datenstruktur eine Ende-zu-Ende-SLA für einen von mehreren Ressourcen bereitgestellten Ressourcenstrom bereitstellt und QoS-Metriken für die Ressourcen umfasst; und Verteilen der QoS-Metriken über die Strukturverbindung an die Ressourcen.
Verfahren nach Anspruch 24, das ferner Folgendes umfasst: Bereitstellen von Ressourcenüberwachungen für mehrere Ressourcen und Bestimmen über die Ressourcenüberwachungen, dass eine gewünschte Dienstgüte (QoS, Quality of Service) des Datenzentrums nicht erfüllt ist.