DE112020007085T5

DE112020007085T5 - Verfahren und vorrichtung für arbeitslast- rückkopplungsmechanismus, der eine geschlossener-regelkreis-architektur ermöglicht

Info

Publication number: DE112020007085T5
Application number: DE112020007085.9T
Authority: DE
Inventors: Patrick KUTCH; John J. Browne; Shobhi JAIN; Jasvinder Singh; Sunku RANGANATH; Adrian Hoban; Swati SEHGAL; Tarun Viswanathan; Khawar Abbasi; Killian Muldoon
Original assignee: Intel Corp
Current assignee: Intel Corp
Priority date: 2020-04-16
Filing date: 2020-11-18
Publication date: 2023-06-22
Also published as: US20200287813A1; WO2021211167A1

Abstract

Verfahren und Vorrichtung für Arbeitslast-Rückkopplungsmechanismen, die eine Geschlossener-Regelkreis-Architektur ermöglichen. Plattformtelemetriedaten werden von einer Serverplattform gesammelt, die eine oder mehrere Hardwarekomponenten umfasst und auf der eine oder mehrere virtuelle Netzwerkfunktionen (VNFs) laufen. Eine Arbeitslastperformance, die einer oder mehreren VNFs oder einer oder mehreren Anwendungen, die der einen oder den mehreren VNFs zugeordnet ist, zugeordnet ist, wird überwacht, um zu detektieren, ob die Performance einer VNF oder einer Anwendung ein Performancekriterium, wie z. B. eine Service Level Agreement- (SLA-) Metrik, nicht erfüllt, und entsprechende Performanceangaben werden von der VNF erzeugt. Basierend auf den Plattformtelemetriedaten und den Performanceangaben wird eine Betriebskonfiguration einer oder mehrerer von den Hardwarekomponenten angepasst, um die Arbeitslastperformance zu erhöhen, um das Performancekriterium zu erfüllen oder zu übertreffen.

Description

HINTERGRUNDINFORMATIONEN
Der Einsatz von Software Defined Networking (SDN) und Network Function Virtualization (NFV) hat in den letzten Jahren ebenfalls ein schnelles Wachstum erfahren. Im Rahmen von SDN ist das System, das Entscheidungen darüber trifft, wohin der Verkehr gesendet wird (die Steuerebene), von dem zugrunde liegenden System, das den Datenverkehr an das ausgewählte Ziel (die Datenebene) weiterleitet, entkoppelt. SDN-Konzepte können zur Erleichterung der Netzwerkvirtualisierung eingesetzt werden, wodurch es Dienstanbietern ermöglicht wird, verschiedene Aspekte ihrer Netzwerkdienste über Softwareanwendungen und APIs (Application Program Interfaces; Anwendungsprogrammschnittstellen) zu managen. Im Rahmen von NFV können Netzwerkdienstanbieter durch die Virtualisierung von Netzwerkfunktionen als Software-Anwendungen Flexibilität bei der Netzwerkkonfiguration gewinnen, wodurch erhebliche Vorteile umfassend Optimierung verfügbarer Bandbreite, Kosteneinsparungen und eine schnellere Markteinführungszeit neuer Dienste ermöglicht wird.
NFV entkoppelt die Software- (SW-) von der Hardware- (HW-) Plattform. Durch die Virtualisierung der Hardware-Funktionalität wird es möglich, verschiedene Netzwerkfunktionen auf Standard-Servern auszuführen, anstatt auf einer speziell dafür entwickelten HW-Plattform. Im Rahmen von NFV werden softwarebasierte Netzwerkfunktionen auf einer physischen Netzwerk-Eingangs-Ausgangs- (IO-; input-output) Schnittstelle ausgeführt, z. B. per NIC (Network Interface Controller; Netzwerkschnittstellensteuerung), unter Verwendung von Hardwarefunktionen, die unter Verwendung einer Virtualisierungsschicht (z. B. einem Typ-1- oder Typ-2-Hypervisor oder einer Container-Virtualisierungsschicht) virtualisiert werden.
Ein Ziel von NFV ist es, mehrere VNFs (Virtualized Network Functions; virtualisierte Netzwerkfunktionen) auf einer einzigen Plattform zu platzieren und sie dann optimal nebeneinander laufen zu lassen, ohne dass sie sich gegenseitig stören; das Hinzufügen traditionellerer Arbeitslast, die neben diesen VNFs laufen, ist ein weiteres wichtiges Ziel der Branche. Diese Ziele sind jedoch in der Praxis nur schwer zu erreichen.
Mit einer ständig wachsenden Anzahl von VNFs, die auf einer Vielzahl von Infrastrukturen (z. B. VMware, KVM, OpenStack, Kubernetes, OpenShift) laufen, wird es für Integratoren sehr schwierig, die Auswirkungen der Ausführung mehrerer VNFs und Arbeitslasten auf einander zu verstehen, was die Einhaltung von Service Level Agreements (SLAs), die Bestätigung der Sicherheitslage der Plattform und der Arbeitslasten usw. betrifft. Ein Ergebnis dieser Schwierigkeiten ist, dass es in der Branche Standard ist, eine einzige VNF-Appliance auf einer einzigen Plattform zu betreiben, was zu einer erhöhten Zwischen-Plattform-Kommunikation, höheren Plattformkosten und reduzierter Ressourcenutzung führt.
Figurenliste
Die vorangehenden Aspekte und viele der dazugehörigen Vorteile dieser Erfindung werden leichter verständlich, wenn diese durch Bezugnahme auf die folgende detaillierte Beschreibung besser verstanden wird, wenn sie in Verbindung mit den beigefügten Zeichnungen genommen wird, wobei gleiche Bezugszeichen sich durch die verschiedenen Ansichten hindurch auf gleiche Teile beziehen, sofern nicht anderweitig angegeben:

1 ist gemäß einem Ausführungsbeispiel ein schematisches Diagramm, das eine Übersicht über einen Arbeitslast-Rückkopplungsmechanismus, der eine Geschlossener-Regelkreis-Architektur erleichtert, zeigt;
2 ist gemäß einem Ausführungsbeispiel ein schematisches Diagramm, das weitere Details der Arbeitslast-Aspekte der Geschlossener-Regelkreis-Architektur von 1 zeigt;
3 ist gemäß einem Ausführungsbeispiel ein schematisches Diagramm, das eine beispielhafte Einsatzarchitektur zeigt;
4 ist ein schematisches Diagramm, das eine Einsatzarchitektur umfassend eine beispielhafte Instanziierung für die Einsatzarchitektur von 3 unter Verwendung von Kubernetes zeigt;
5 ist gemäß einem Ausführungsbeispiel ein Flussdiagramm, das Operationen und Logik darstellt, die durch die Einsatzarchitekturen der 3 und 4 implementiert werden;
6 ist gemäß einem Ausführungsbeispiel ein Flussdiagramm, das Operationen und Logik darstellt, die von den hier vorgestellten Ausführungsbeispielen der Einsatzarchitekturen implementiert werden, um eine Geschlossener-Regelkreis-Architektur zu implementieren;
7 ist ein schematisches Diagramm, das eine Architektur für eine beispielhafte Implementierung einer Firewall-VNF mit einer Geschlossener-Regelkreis-Rückkopplung zeigt;
8 ist ein schematisches Diagramm, das eine Architektur für eine beispielhafte Implementierung einer Firewall-VNF mit einer Geschlossener-Regelkreis-Rückkopplung unter Einsatz eines Host-Telemetrie-Microservice zeigt;
9 ist gemäß einem Ausführungsbeispiel ein Flussdiagramm, das von dem Host-Telemetrie-Microservice und den zugeordneten Komponenten durchgeführte Operationen zeigt; und
10 ist ein schematisches Diagramm einer Serverplattform, die ausgebildet ist, Aspekte der hier beschriebenen und dargestellten Serverplattformen zu implementieren.

DETAILLIERTE BESCHREIBUNG
Ausführungsbeispiele der Verfahren und Vorrichtungen für Arbeitslast-Rückkopplungsmechanismen, die eine Geschlossener-Regelkreis-Architektur ermöglichen, hierin beschrieben sind. In der folgenden Beschreibung werden zahlreiche spezifische Details ausgeführt, um ein tiefgreifendes Verständnis von Ausführungsbeispielen der Erfindung bereitzustellen. Der Fachmann wird jedoch erkennen, dass die Erfindung auch ohne eines oder mehrere der spezifischen Details oder mit anderen Verfahren, Komponenten, Materialien etc. in der Praxis ausgeführt werden kann. In anderen Fällen werden bekannte Strukturen, Materialien oder Operationen nicht im Detail gezeigt oder beschrieben, um Aspekte der Erfindung nicht zu verunklaren.
In dieser gesamten Beschreibung bedeutet ein Bezug auf „das eine Ausführungsbeispiel“ oder „ein Ausführungsbeispiel“, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder Charakteristik, das/die in Verbindung mit dem Ausführungsbeispiel beschrieben wird, bei zumindest einem Ausführungsbeispiel der vorliegenden Erfindung umfasst ist. Somit bezieht sich das Auftreten der Phrasen „bei einem einzelnen Ausführungsbeispiel“ oder „bei einem Ausführungsbeispiel“ an verschiedenen Stellen durchgehend in dieser Beschreibung nicht bei allen notwendigerweise auf das gleiche Ausführungsbeispiel. Ferner können die bestimmten Merkmale, Strukturen, oder Charakteristika in irgendeiner geeigneten Weise bei einem oder mehreren Ausführungsbeispielen kombiniert werden.
Der Klarheit halber kann auf einzelne Komponenten in den Figuren auch durch ihre Bezeichnungen in den Figuren Bezug genommen werden, anstatt durch ein bestimmtes Bezugszeichen. Zusätzlich können Bezugszeichen, die sich auf einen bestimmten Typ von Komponente (im Gegensatz zu einer bestimmten Komponente) beziehen, mit einem Bezugszeichen gefolgt von „(typ)“, was „typisch“ bedeutet, gezeigt sein. Es versteht sich, dass die Konfiguration dieser Komponenten typisch für ähnliche Komponenten sein wird, die möglicherweise existieren, aber der Einfachheit und Klarheit halber nicht in den zeichnerischen Figuren gezeigt sind, oder für ansonsten ähnliche Komponenten, die nicht mit separaten Bezugszeichen gekennzeichnet sind. Umgekehrt soll „(typ)“ nicht so ausgelegt werden, dass es bedeutet, dass die Komponente, das Element usw. typischerweise für seine offenbarte Funktion, Implementierung, seinen Zweck usw. verwendet wird.
Ein Bereich von wachsendem Interesse für Cloud-Dienst-Anbieter, Kunden und Gerätehersteller ist die Verwendung von Plattformtelemetrie, um die Interaktionen mehrerer Arbeitslasten zu analysieren. Beispiele hierfür umfassen die Intel® Performance Monitoring Unit- (Intel® PMU-) und die Intel® Resource Director Technology- (Intel® RDT-) Telemetriemöglichkeiten, die eine große Menge an Telemetrie auf einer Pro-Kern-Basis offenlegen, das umfasst, aber nicht beschränkt sind darauf, wie stark die verschiedenen Cache-Ebenen von dem Kern (core) genutzt werden, Cache-Misses, Hits, Speicherbandbreite und vieles mehr. Andere Prozessorhersteller wie beispielsweise AMD®- und ARM®-basierte Prozessorhersteller haben ebenfalls Telemetriemöglichkeiten eingeführt.
Unter Aspekten der hier offenbarten Ausführungsbeispiele beteiligen sich die Arbeitslasten selbst an der Veröffentlichung der Metriken, von denen sie am meisten betroffen sind, an einen Host-Telemetrie-Microservice. Dieser Microservice ist spezifisch für die VNF und führt die Korrelation zwischen der für die Arbeitslast spezifischen Telemetrie, den Plattform-PMU-Metriken und den Indikatoren durch. Dieser Indikator wird dann an ein Analysesystem gesendet, das ihn zusammen mit der Gesamt-Plattform-PMU analysiert und einer Management-/Orchestrierungsentität (z. B. MANO) eine geeignete Empfehlung gibt, wie z. B. den Vorschlag an MANO, einen zusätzlichen Dienst einzurichten (spawn) oder sie zu migrieren.
Kürzlich durchgeführte Aktivitäten haben gezeigt, dass die CPU-Kernfrequenzen skaliert werden können, um erhebliche Leistungseinsparungen für eine bestimmte DPDK- (Dataplane Development Kit-) basierte Arbeitslast zu erzielen; die Standard-Betriebssystem- (-OS-) basierten Frequenzmanager funktionieren nicht für DPDK-Anwendungen, da der Kern aufgrund der Natur der DPDK Poll Mode Driver (DPDK-PMDs) immer bei 100 % Auslastung ist. Gemäß Ausführungsbeispielen ist eine Implementierung in der Lage, den eigentlichen Betrieb des DPDK-PMD basierend auf einiger PMU-Telemetrie zu detektieren; so kann in diesem Fall die Kernfrequenz basierend auf den PMU-Telemetriedaten skaliert werden, um Leistung zu sparen, was für einige VNF-Kunden von großer Bedeutung ist.
1 zeigt eine Übersicht über einen Arbeitslast-Rückkopplungsmechanismus, der eine Geschlossener-Regelkreis-Architektur erleichtert. Die Architektur 100 umfasst eine Serverplattform 102, die mehrere Mittel zur Erzeugung von Telemetriedaten umfasst, umfassend Cache-Telemetrie-Logik 104, Speicher-Telemetrie-Logik 106, Netzwerk-Telemetrie-Logik 108 und PMU 110. Die Telemetriedaten, die von den oben genannten und anderen potenziellen Telemetriedatenquellen (nicht gezeigt) erzeugt werden, werden von einem Telemetriedatensammelmechanismus 112 gesammelt, der eine Telemetriedateneingabe an einen Datenanalyseblock 114 bereitstellt. Telemetriedaten werden auch von einer VNF und/oder Anwendungen erzeugt oder gesammelt, wie durch VNF-Telemetrie 109 und eine Arbeitslast 116 dargestellt, und an den Datenanalyseblock 114 weitergeleitet. Der Datenanalyseblock 114 führt eine Datenanalyseverarbeitung seiner Eingaben durch und stellt Ausgabedaten an einen Orchestrierungsblock 118 und einen Konfigurationsblock 120, die wiederum Steuereingaben an die Serverplattform 102 bereitstellen, um die Hardwareoperationen auf der Serverplattform anzupassen.
Der heute am häufigsten verwendete Plattformtelemetriesammelmechanismus ist collectd, und dementsprechend verwendet der Telemetriedatensammelmechanismus 112 bei einem Ausführungsbeispiel collectd. Collectd verwendet Plugins zum Sammeln einer konfigurierbaren Anzahl von Metriken von Serverplattformen und veröffentlicht die gesammelten Metriken in einer Analysekomponente, z. B. dem Datenanalyseblock 114. Die Analysekomponente verwendet die Telemetrieinformationen in Verbindung mit der Anwendungstelemetrie (z. B. VNF-Telemetrie 109), um möglicherweise Änderungen an der Plattform vorzunehmen (z. B. Kernfrequenzskalierung oder Cache-Zuweisung) oder einem Planer anzuzeigen, dass eine Arbeitslast zu verschieben ist.
Um den angestrebten Automatisierungsgrad zu erreichen, beteiligt sich die Arbeitslast/Anwendung/VNF an dem Telemetrie-Exposure-Prozess. Mit der einfachen Telemetrieanzeige „SLA erfüllt“ oder „SLA nicht erfüllt“ (z. B. wie dargestellt durch eine „1“ oder „0“) ist eine Analysekomponente in der Lage, die Plattform- und OS-Telemetrie zu analysieren und versuchen, die optimalen Bedingungen für die Arbeitslast zu finden. Wenn die von der Arbeitslast bereitgestellte Telemetrie zusätzliche Gründe dafür liefern kann, warum die SLAs erfüllt werden können oder möglicherweise nicht, kann die Analysekomponente in der Lage sein, die entsprechende Plattformtelemetrie noch besser eingrenzen.
2 veranschaulicht ein Diagramm 200, das weitere Details der Arbeitslast-Aspekte der Geschlossener-Regelkreis-Architektur 100 zeigt. Zusätzlich zu den in 1 gezeigten und oben erläuterten Komponenten zeigt das Diagramm 200 eine VM 202, in der eine Arbeitslast/Anwendung/VNF 204 ausgeführt wird, und einen Container 206, in dem eine Arbeitslast/Anwendung/VNF 208 ausgeführt wird. Im Allgemeinen hostet eine bestimmte Plattform mehrere VMs oder Container, in denen Arbeitslasten/Anwendungen/VNFs ausgeführt werden. Wie dargestellt, empfängt der Datenanalyseblock 114 eine Eingabe von jeder der Arbeitslast/Anwendung/VNF 204 und 208.
Die besonderen Mechanismen, mit denen Telemetrie und zugeordnete Daten offengelegt werden, und die Form, in der die Daten offengelegt werden, liegen im Allgemeinen außerhalb des Schutzbereichs dieser Offenbarung. Ein oder mehrere bekannte Mechanismen können implementiert werden, die darüber hinaus sichere Netzwerkverbindungen und/oder bandexterne Verbindungen nutzen können. Plattformmöglichkeiten wie Hardware Queue Manager (HQM) können ebenfalls eingesetzt werden.
3 zeigt eine beispielhafte Einsatzarchitektur 300 umfassend eine Serverplattform 302 und ein Analysesystem 316 und ein Managementsystem 318. Die Serverplattform 302 umfasst eine Hardwareplattform 304, ein Betriebssystem 306, eine Hypervisor/Container-Abstraktionsschicht 308, eine VNF 310 und eine Plattformtelemetrieüberwachungseinrichtung 314. Die VNF 312 umfasst eine SLA-Überwachungseinrichtungs- und Lokal-Analyse-Komponente 312.
Wie in 3 dargestellt, wird eine Anforderung zum Einsatz eines neuen Dienstes an das Managementsystem 318 bereitgestellt. Der neue Dienst stellt eine neue Arbeitslast dar, die als oder unter Verwendung von VNF 310 zu implementieren ist. Wenn die Arbeitslast gestartet wird, werden an sie Informationen darüber bereitgestellt, wie die Arbeitslast/Anwendung/VNF-Telemetriedaten zu senden sind, sowie eine Art Schema für das Format der Daten, wie es in einem SLA-Analyse-Deskriptor 320 dargestellt ist. Bei einem Ausführungsbeispiel stellt der SLA-Analyse-Deskriptor 320 1) die zu überwachenden VNF-Metriken, 2) Schwellenwerte/Integrationsperioden und Kombinationsregeln für die Analyse und Auslöser zur Erzeugung von Verletzungen und 3) den/die Ort(e) zur Meldung von Verletzungen dar.
Die Einsatzarchitektur 300 funktioniert im Allgemeinen wie folgt. Während der laufenden Operationen werden Plattformtelemetriedaten, wie z. B. PMU-Metriken, Intel® Resource Director Technology (RDT), RAS-Daten (Zuverlässigkeit, Verfügbarkeit, Wartbarkeit; reliability, availability, serviceability), libvirt-Daten (für Linux-Plattformen) usw. von verschiedenen Telemetriequellen durch die Plattformtelemetrieüberwachungseinrichtung 314 gesammelt und an das Analysesystem 316 veröffentlicht. Die SLA-Überwachungs- und Analysekomponente 312 überwacht die SLA-Metriken für VNV 310 und meldet die VNF-SLA-Verletzungen an das Analysesystem 316. Das Analysesystem 316 führt eine Datenanalyse durch, um eine Korrelation von VNF-SLA-Verletzungen und Plattformursachen zu bestimmen, um eine Plattformkonfigurationsanpassungsempfehlung zu bestimmen, die als Eingabe an das Managementsystem 318 bereitgestellt wird. Das Managementsystem 318 stellt dann Steuereingaben an die Serverplattform 302 bereit, um eine Anpassung der Betriebskonfiguration einer oder mehrerer Hardwarekomponenten zu bewirken, z. B. die Erhöhung der Kernfrequenzen.
Im Allgemeinen kann die SLA-Überwachungseinrichtungs- und Lokal-Analyse-Komponente 312 als Software oder Hardware oder eine Kombination aus beidem implementiert werden. Bei einem Ausführungsbeispiel umfasst die SLA-Überwachungseinrichtungs- und Lokal-Analyse-Komponente 312 einen Host-Telemetrie-Microservice. Bei einem Ausführungsbeispiel empfängt die SLA-Überwachungseinrichtungs- und Lokal-Analyse-Komponente 312 1) den SLA-Analyse-Deskriptor 320; 2) überwacht periodisch die VNF-Metriken basierend auf den Deskriptor bereitgestellten Regeln; 3) leitet SLA-Verletzungen, wenn sie detektiert werden, an das Analysesystem 316 weiter; und 4) akzeptiert Änderungen an dem Analyse-Deskriptor im Falle von Skalierungsereignissen oder anderen vom Management angeforderten Änderungen.
Der VNF-SLA-Verletzungsindikator gibt Aufschluss darüber, ob die VNF normal arbeitet und den SLA-Status erfüllt oder den SLA-Status nicht erfüllt. Optional kann der VNF-Verletzungsindikator einen Hinweis darauf geben, wie gut das SLA erfüllt wird. Zum Beispiel: 98%ige SLA-Konformität Wenn die VNF 310 ein/aus- oder hoch/herunter- skaliert, kann das Managementsystem 318 eine SLA-Analyse-Deskriptor-Konfigurations-Aktualisierung an die SLA-Überwachungseinrichtungs- und Lokal-Analyse-Komponente 312 oder den Host-Telemetrie-Microservice ausgeben, der die neuen Regeln zur Bestimmung der SLA-Konformität anwendet.
4 zeigt eine Einsatzarchitektur 400 umfassend eine beispielhafte Instanziierung für die Einsatzarchitektur 300 in Kubernetes. In der Kubernetes-Nomenklatur ist ein Kubernetes-Pod eine Gruppe von Containern, die gemeinsam auf demselben Host (z. B. demselben physischen Server) eingesetzt werden. Ein Pod ist die grundlegende Ausführungseinheit einer Kubemetes-Anwendung. Ein Pod kapselt den Container (oder mehrere Container) einer Anwendung, Speicherungsressourcen, eine eindeutige Netzwerk-IP und Optionen, die festlegen, wie der/die Container ausgeführt werden sollen. Ein Pod stellt eine Einsatzeinheit dar: eine einzelne Instanz einer Anwendung in Kubernetes, die entweder aus einem einzigen Container oder aus einer kleinen Anzahl von Containern bestehen kann, die eng gekoppelt sind und Ressourcen gemeinschaftlich verwenden.
Die Einsatzarchitektur 400 umfasst einen Kubemetes-Knoten 402, der auf einer Hardwareplattform 404 implementiert ist und auf dem ein Betriebssystem 406, eine VNF 410 umfassend eine SLA-Überwachungseinrichtungs- und Lokal-Analyse-Komponente 412 und eine Plattformtelemetrieüberwachungseinrichtung 414 ausgeführt oder eingesetzt werden. Die Plattformtelemetrieüberwachungseinrichtung 414 stellt (z. B. durch Veröffentlichung) Plattformtelemetriedaten wie beispielsweise PMU-Metriken, RDT, RAS, Kubelet usw. an ein Datensammelüberwachungswerkzeug 415 bereit. Das Datensammelüberwachungswerkzeug 415 empfängt auch Informationen, die VNF-SLA-Verletzungen von der SLA-Überwachungs- und Analysekomponente 412 identifizieren. Das Datensammelüberwachungswerkzeug 415 stellt diese Daten einem Analysesystem 416 zur Verfügung, das eine Analyse dieser Daten durchführt und eine Plattformkonfigurationsanpassungsempfehlung ausgibt, die an eine Steuerung 417 in einem Kubernetes-Master 418 gesendet wird.
Wie in 4 weiter dargestellt, wird ein neuer Dienst eingesetzt, indem eine Spezifikation 422 für die auf Pod A einzusetzende VNF an den Kubernetes-Master 418 bereitgestellt wird, der auch einen SLA-Analyse-Deskriptor 420 empfängt. Der Kubernetes-Master 418 verwendet diese Eingaben, um die VNF einzusetzen und die SLA-Überwachung unter Verwendung des SLA-Deskriptors zu konfigurieren.
Bei einem Ausführungsbeispiel stellt der SLA-Analytik-Deskriptor 420 1) eine benutzerdefinierte Kubernetes-Ressource, 2) zu überwachende VNF-Metriken und 3) Schwellenwerte/Integrationsperioden und Kombinationsregeln für die Analyse und Auslöser dar, die Verletzungen erzeugen. Bei einem Ausführungsbeispiel stellt die Steuerung 417 1) eine benutzerdefinierte Kubernetes-Steuerung dar, die die SLA-Analyse-Deskriptoren beobachtet; 2) integriert sich in die Kubernetes-Steuerebene; 3) meldet Verletzungen; 4) übermittelt SLA-Überwachungseinrichtungs-Deskriptoren an SLA-Überwachungseinrichtungs- und Lokal-Analyse auf dem Pod; 5) aktualisiert SLA-Überwachungseinrichtungs-Deskriptoren bei Bedarf; und 6) logische Lösung von Regeln aus dem SLA-Analyse-Deskriptor, um Verletzungen zu identifizieren.
Die SLA-Überwachungseinrichtungs- und Lokal-Analyse-Komponente 412 oder ein Host-Telemetrie-Container wird mit der Anwendung in dem Pod eingesetzt. Sie kann zum Beispiel als Sidecar-Container oder als native Komponente eingesetzt werden. Die SLA-Überwachungseinrichtungs- und Lokal-Analyse-Komponente 412 oder ein Host-Telemetrie-Container 1) empfängt den SLA-Analyse-Deskriptor von der Steuerung; 2 überwacht periodisch die VNF-Metriken basierend auf den von dem Deskriptor bereitgestellten Regeln; 3) leitet Verletzungen, wenn sie detektiert werden, an das Datensammel- & Überwachungswerkzeug weiter; und 4) akzeptiert Änderungen an dem Analyse-Deskriptor im Falle von Skalierungsereignissen oder anderen vom Management angeforderten Änderungen.
Wie vorangehend gibt der VNF-SLA-Verletzungsindikator Aufschluss darüber, ob die VNF normal arbeitet und den SLA-Status erfüllt oder den SLA-Status nicht erfüllt. Optional kann eine VNF-SLA-Verletzung einen Hinweis darauf geben, wie gut das SLA erfüllt wird, z. B. 98 %-ige SLA-Konformität.
5 zeigt gemäß einem Ausführungsbeispiel ein Flussdiagramm 500, das Operationen und Logik darstellt, die durch die Einsatzarchitekturen 300 und 400 implementiert werden. Der Ablauf beginnt in einem Startblock 502. In einem Block 504 wird der SLA-Überwachungseinrichtungs-Deskriptor aus einem Managementspeicher (management store) abgerufen. Der SLA-Überwachungseinrichtungs-Deskriptor und andere anwendbare Einsatzkonfigurationsinformationen werden verwendet, um die VNF in einem Block 506 einzusetzen. In einem Block 508 wird die VNF-Anwendungs-SLA-Überwachungseinrichtung basierend auf dem SLA-Überwachungseinrichtungs-Deskriptors konfiguriert.
Sobald die VNF eingesetzt und die VNF-Anwendungs-SLA-Überwachungseinrichtung konfiguriert ist, wird die VNF in Betrieb genommen, wie in Startblock 510 gezeigt. In einem Block 512 werden SLA-Verletzungen basierend auf den SLA-Überwachungseinrichtungs-Deskriptor-Parametern detektiert. In einem Block 514 wird eine SLA-Verletzung an eine Managemententität und/oder eine Analyseentität gemeldet. Wie durch die Schleife zurück zum Startblock 206 dargestellt, werden die Operationen der Blöcke 512 und 514 fortlaufend durchgeführt, während die VNF in Betrieb ist.
Im Allgemeinen kann die Plattformkonfigurationsanpassungsempfehlung Informationen umfassen, die das Managementsystem in die Lage versetzen, die VNF-SLA-Verletzung zu beheben, indem es die Plattformhardware anpasst, z. B. die Frequenzen der Prozessorkerne.
6 zeigt ein Flussdiagramm, das Operationen und Logik darstellt, die von den hier vorgestellten Ausführungsbeispielen der Einsatzarchitekturen implementiert werden, um eine Geschlossener-Regelkreis-Architektur zu implementieren. Nach einem Startblock 602 werden in einem Block 604 Telemetriedaten von einer VNF abgerufen. In einem Entscheidungsblock 606 wird festgestellt, ob eine oder mehrere anwendbare SLA-Metriken erfüllt werden. Lautet die Antwort NEIN, fährt die Logik mit Block 608 fort, in dem die Plattform-Korrelation mit VNF-Ressourcen untersucht wird.
Als nächstes wird in einem Entscheidungsblock 610 festgestellt, ob eine Änderung der Plattformkonfiguration das Problem lösen kann. Lautet die Antwort JA, fährt die Logik mit einem Block 612 fort, in dem eine relevante, durchzuführende Plattformänderung bestimmt wird, gefolgt von der Durchführung der Plattformänderung in einem Block 614.
Kehrt man zu dem Entscheidungsblock 606 zurück, fährt, wenn das SLA erfüllt wird, die Logik mit einem Entscheidungsblock 606 fort, um festzustellen, ob ein Plattformwechsel unter Beibehaltung der SLA-Performancekriterien (z. B. Performancemetrik(en)) vorgenommen werden kann. So kann es beispielsweise wünschenswert sein, den Leistungsverbrauch zu reduzieren, indem die Frequenz eines oder mehrerer Prozessorkerne verringert wird. Wenn die Antwort in Entscheidungsblock 616 JA lautet, fährt die Logik mit Block 612 fort, und die Operation der Blöcke 612 und 614 wird ausgeführt, um den Plattformwechsel zu bestimmen und zu implementieren. Wenn die Antwort in Entscheidungsblock 616 NEIN lautet, kehrt die Logik zu Block 604 zurück. Ähnlich, wenn in Entscheidungsblock 610 festgestellt wird, dass ein Plattformwechsel nicht möglich ist, um das Problem zu lösen (was zu der SLA-Verletzung führt), kehrt die Logik zu Block 604 zurück.
7 zeigt eine Architektur 700, die eine beispielhafte Implementierung der Firewall-VNF mit einer Geschlossener-Regelkreis-Rückkopplung darstellt. Die Architektur 700 verwendet eine NFVI (Netzwerkfunktionen-virtualisierte Infrastruktur; Network Functions Virtualized Infrastructure) 702 mit Hardware umfassend eine Serverplattform 704 mit einer oder mehreren Komponenten, die Plattformtelemetrie 706 erzeugen, und Softwarekomponenten umfassend einen Telemetriekollektor 708 und eine Firewall-VNF 710. Die Architektur 700 umfasst ferner ein Analysesystem 716 und eine MANO 718.
Zunächst wird die Firewall-VNF 710 von MANO 718 unter Verwendung des SLA-Analyse-Deskriptors 720 in ähnlicher Weise wie oben beschrieben eingesetzt. Während der laufenden Operationen sammelt der Telemetriekollektor 708 Telemetriedaten von der Plattformtelemetrie 708 und stellt die gesammelten Telemetriedaten an das Analysesystem 716 bereit (z. B. veröffentlicht dieselben). Die Firewall-VNF 710 stellt auch Performanceangaben wie beispielsweise eine allgemeine SLA-Anzeige der SLA-Performance an das Analysesystem 716 bereit. Das Analysesystem verarbeitet ihre Eingaben, um eine Plattform-konfigurierte Anpassungsempfehlung zu erstellen, die an MANO 718 bereitgestellt wird. MANO 718 stellt dann Konfigurationseingaben 722 bereit, um die Konfiguration der anwendbaren Komponenten auf der Serverplattform 704 anzupassen.
8 zeigt eine Architektur 800, die eine detailliertere Implementierung der Architektur 700 unter Einsatz eines Host-Telemetrie-Microservice darstellt. Die NFVI 802 verwendet Hardware umfassend eine Serverplattform 804 mit einer oder mehreren Komponenten, die Plattformtelemetrie 806 erzeugen. Die Softwarekomponenten umfassen collectd 808, Firewall-VNF 810 und einen Host-Microservice 812. Die Architektur 800 umfasst ferner ein Analysesystem 816 und eine MANO 818.
Unter einem Aspekt des Verfahrens beteiligen sich die Arbeitslasten selbst an der Veröffentlichung der Metriken, von denen sie am meisten betroffen sind, an den Host-Telemetrie-Microservice (z. B. Host-Telemetrie-Microservice 812). Bei einem Ausführungsbeispiel ist der Host-Telemetrie-Microservice spezifisch für die VNF und führt die Korrelation zwischen der für die Arbeitslast spezifischen Telemetrie, den Plattform-PMU-Metriken und den Indikatoren durch, wie in einem Block 814 dargestellt. Bei einem Ausführungsbeispiel wird eine generische Performanceanzeige von dem Host-Telemetrie-Microservice 812 berechnet oder anderweitig bestimmt und die generische Anzeige wird über die VNF (810) an das Analysesystem (816) weitergeleitet. Das Analysesystem analysiert die generische Anzeige zusammen mit den allgemeinen Plattformtelemetriedaten z. B. PMU-Metriken) von collectd 808 und gibt einer Management-/Orchestrierungsinstanz (z. B. MANO) eine geeignete Empfehlung, wie z. B. den Vorschlag an MANO, einen zusätzlichen Dienst einzurichten oder sie zu migrieren.
Betrachten man einen Einsatz der Firewall-VNF 810, die hauptsächlich an einem „SLA-Verletzungs-"Szenario interessiert ist. Während des Einsatzes der Firewall-VNF setzt MANO 818 den Host-Telemetrie-Microservice 812 basierend auf dem SLA-Analyse-Deskriptor ein (nicht dargestellt, aber ähnlich dem SLA-Analyse-Deskriptor 720 in 7). Der eingesetzte Microservice wählt dann die spezifische NFVI-Telemetrie für Firewall-VNF 812 aus collectd 808 aus. Collectd 8008 meldet nun nur die ausgewählte NFVI-Telemetrie an den Host-Telemetrie-Microservice 812. Der Host-Telemetrie-Microservice korreliert dann die ausgewählten NFVI-Metriken mit den Anwendungsmetriken, z. B. Firewall-VNF-Metriken und der generischen Anzeige. Wenn der Host-Telemetrie-Microservice beispielsweise Pakete analysiert, die aufgrund einer detektierten SLA-Verletzung verworfen werden, stellt er an die VNF eine generische Anzeige bereit, wie beispielsweise „0“ (schlecht) oder „SLA verletzt“, die dieselbe an das Analysesystem weiterleitet. Das Analysesystem analysiert die generische Anzeige mit den von collectd 808 gesammelten Gesamtplattformmetriken und gibt entsprechende Empfehlungen, wie z. B. das Einrichten einer neuen VNF oder das Migrieren des Dienstes auf eine neue VM.
Im Allgemeinen kann die generische Anzeige lauten: 1 oder 0 (gut oder schlecht) oder eine Zahl zwischen 0 und 100, um die relative Performance anzugeben (z. B. 0 % oder 100 %), oder es kann eine performancebezogene Nachricht sein, wie z. B. „erfüllt mein SLA nicht“/„erfüllt mein SLA“ [`Not meeting my SLA'/‚Meeting my SLA‘]. Die generische Anzeige kann z. B. Kapazität, Durchsatz, Latenzzeit usw. darstellen. Sie könnte auch durch xml dargestellt werden wie beispielsweise <generic performance indication name><Integer range> [Generische-Performanceanzeige-Name, Ganzzahlbereich]. Außerdem kann der hier vorgeschlagene Microservice für jede neue VNF eingesetzt werden. Optional kann der Host-Telemetrie-Microservice „generisch“ sein und ein dienst-/VNF-spezifisches Plugin kann von dem Managementsystem installiert werden. Als weitere Option kann die Korrelation ausgewählter NFVI-Metriken mit Anwendungsmetriken und die generische Anzeigeoperation auch in der VNF selbst durchgeführt werden, je nach der Performancesensitivität des VNF.
9 ist gemäß einem Ausführungsbeispiel ein Flussdiagramm 900, das von dem Host-Telemetrie-Microservice und den zugeordneten Komponenten durchgeführte Operationen zeigt. In einem Block 902 werden spezifische NFVI-Telemetrieinformationen, die für die VNF relevant sind, gesammelt. Wie in einem Block 904 und einem Entscheidungsblock 906 dargestellt, wird die ausgewählte NFVI-Telemetrie mit Anwendungs-Telemetrieinformationen kombiniert, um eine generische Anzeige zu detektieren. Wenn das SLA nicht erfüllt wird, ist die Antwort auf Entscheidungsblock 906 NEIN, und die Logik fährt mit einem Block 908 fort, in dem die generische Anzeige an das Analysesystem bereitgestellt wird. In einem Block 910 verarbeitet das Analysesystem ferner die generische Anzeige mit den von dem Telemetriekollektor (z. B. collectd) empfangenen Gesamtperformancemetriken und stellt in einem Block 912 eine Konfigurationsanpassungsempfehlung an das Orchestrierungssystem (z. B. MANO) bereit
10 zeigt ein Ausführungsbeispiel einer Serverplattformarchitektur 1000, die geeignet ist, um Aspekte der hierin beschriebenen Ausführungsbeispiele zu implementieren. Die Architektur 1000 umfasst eine Hardwareschicht in dem unteren Abschnitt des Diagramms, umfassend eine Plattformhardware 1002, und eine Softwareschicht, die Softwarekomponenten umfasst, die in einem Host-Speicher 1004 laufen. Die Plattformhardware 1002 umfasst einen Prozessor 1006, der eine System-auf-einem-Chip- (SoC-; System on a Chip) Architektur aufweist, die eine zentrale Verarbeitungseinheit (CPU; central processing unit) 1008 mit M Prozessorkernen 1010 umfasst, die jeweils mit einem Level-1- und Level-2-Zwischenspeicher (L1/L2) 1012 gekoppelt sind. Jeder der Prozessorkerne und L1/L2-Caches ist mit einer Verbindung 1014 verbunden, mit der eine Speicherschnittstelle 1016 und ein Last-Level-Cache (LLC) 1018 gekoppelt ist, wodurch ein kohärenter Speicherbereich gebildet wird. Die Speicherschnittstelle wird verwendet, um auf den Host-Speicher 1004 zuzugreifen, in dem verschiedene Software-Komponenten geladen und über eine Ausführung zugeordneter Software-Anweisungen auf Prozessorkernen 1010 ausgeführt werden.
Der Prozessor 1006 umfasst ferner eine Eingangs-/Ausgangs- (I/O-) Verbindungshierarchie, die eine oder mehrere Ebenen von Verbindungsschaltungsanordnung und Schnittstellen umfasst, die der Einfachheit halber kollektiv als I/O-Verbindungen und -Schnittstellen 1020 dargestellt sind. Verschiedene Komponenten und Peripherievorrichtungen sind über entsprechende Schnittstellen (nicht alle separat dargestellt) mit dem Prozessor 1006 gekoppelt, umfassend eine Netzwerkschnittstelle 1022 und eine Firmware-Speicherungsvorrichtung 1024. Bei einem Ausführungsbeispiel ist die Firmware-Speicherungsvorrichtung 1024 über einen Link 1025, z. B. einen Enhanced Serial Peripheral Interface Bus (eSPI), mit der IO-Verbindung verbunden. Optional kann das Firmware-Speicherungsvorrichtung 1024 über einen Plattformsteuerungshub (PCH; platform controller hub) 1027 mit dem Prozessor 1006 wirksam gekoppelt sein.
Die Netzwerkschnittstelle 1022 ist mit einem Netzwerk 1030 verbunden, wie z. B. einem lokalen Netzwerk (LAN), einem privaten Netzwerk oder einem ähnlichen Netzwerk innerhalb eines Rechenzentrums. So können beispielsweise verschiedene Arten von Rechenzentrumsarchitekturen unterstützt werden, umfassend eine Architektur, die Serverplattformen einsetzt, die durch Netzwerkschalter wie Top-of-Rack- (ToR-) Schalter verbunden sind, sowie disaggregierte Architekturen wie die Rack-Scale-Design-Architektur der Intel® Corporation.
Die Plattformhardware 1002 kann auch ein Festplattenlaufwerk oder eine Solid-State-Disk (SSD) mit Steuerung 1032 umfassen, auf dem Softwarekomponenten 1034 gespeichert sind. Optional kann alles oder ein Abschnitt der Softwarekomponenten, die verwendet werden, um die Software-Aspekte der Ausführungsbeispiele hierin zu implementieren, über ein Netzwerk 1030 geladen werden, auf das z. B. durch die Netzwerkschnittstelle 1022 zugegriffen wird.
Die in 10 dargestellten Softwarekomponenten umfassen eine Container/Pod-Abstraktionsschicht 1036, die zum Hosten von n Pods Pod A, PodB, ... Pod n verwendet wird, die jeweils eine VNF 1038 umfassen, die eine oder mehrere Anwendungen 1040 implementiert. Bei einem Ausführungsbeispiel sind die Pods Kubernetes-Pods. Plattformarchitekturen, die Container einsetzen, wie beispielsweise Docker®-Typ-Container, können auf eine ähnliche Weise implementiert werden. Optional können Plattformarchitekturen, die VMs einsetzen, unter Verwendung eines Typ-1- (Bare Metal) oder Typ-2-Hypervisor oder VMM implementiert werden. Die Softwarekomponenten umfassen auch einen Telemetriekollektor 1042.
Wie in 10 weiter dargestellt, umfasst die Plattformhardware 1002 verschiedene Komponenten zur Erzeugung von Telemetriedaten, die durch die PMONs (Performance-Überwachungseinrichtungen; Performance Monitors) 1044, 1046, 1048, 1050, 1052 und eine PMU 1054 dargestellt werden. Beispiele für Telemetriedaten umfassen, sind aber nicht beschränkt auf, Prozessorkem-Telemetriedaten, Cache-bezogene Telemetriedaten, speicherbezogene Telemetriedaten, Netzwerk-Telemetriedaten und Leistungsdaten. Die Cache-bezogenen Telemetriedaten können umfassen, sind aber nicht beschränkt auf, Cache Monitoring Technology- (CMT-), Cache Allocation Technology- (CAT-) und Code and Data Prioritization- (CDP-) Telemetriedaten. CMT überwacht die LLC-Auslastung durch einzelne Threads, Anwendungen, VMs, VNFs usw. CMT verbessert die Arbeitslastcharakterisierung, ermöglicht fortschrittliche, ressourcenbewusste Planungsentscheidungen, unterstützt die Detektion von „verrauschten Nachbarn“ und verbessert die Performance-Debugging (-Fehlerbeseitigung). CAT ermöglicht eine softwaregesteuerte Neuverteilung der Cache-Kapazität, was es VMs, Container oder Anwendungen ermöglicht, von einer verbesserten Cache-Kapazität und einer reduzierter Cache-Konkurrenz zu profitieren. CDP ist eine Erweiterung von CAT, die eine separate Steuerung über Code- und Daten-Platzierung in der LLC ermöglicht. Bestimmte spezialisierte Arten von Arbeitslasten können von einem erhöhten Laufzeitdeterminismus profitieren, der eine bessere Vorhersagbarkeit der Anwendungsperformance ermöglicht.
Bei einem Ausführungsbeispiel implementiert die PMON 1050 Memory Bandwidth Monitoring (MBM; Speicherbandbreitenüberwachung). MBM ermöglicht, dass mehrere VMs, VNFs oder Anwendungen unabhängig nachverfolgt werden, was eine Speicherbandbreitenüberwachung für jeden laufenden Thread gleichzeitig ermöglicht. Die Vorteile umfassen die Detektion von verrauschten Nachbarn, die Charakterisierung und das Debugging der Performance für bandbreitenabhängige Anwendungen und eine effektivere, NUMA- (Non-Uniform Memory Access) bewusste Planung.
Obwohl einige Ausführungsbeispiele in Bezug auf bestimmte Implementierungen beschrieben wurden, sind andere Implementierungen gemäß einigen Ausführungsbeispielen möglich. Zusätzlich ist es nicht erforderlich, dass die Anordnung und/oder Reihenfolge von Elementen oder anderen Merkmalen, die in den Zeichnungen dargestellt und/oder hierin beschrieben sind, auf die bestimmte Weise angeordnet werden, die dargestellt und beschrieben ist. Viele andere Anordnungen sind gemäß einigen Ausführungsbeispielen möglich.
Bei jedem System, das in einer Figur gezeigt ist, können die Elemente in einigen Fällen jeweils ein gleiches Bezugszeichen oder ein unterschiedliches Bezugszeichen aufweisen, um vorzuschlagen, dass die repräsentierten Elemente unterschiedlich und/oder ähnlich sein könnten. Ein Element kann jedoch flexibel genug sein, um unterschiedliche Implementierungen aufzuweisen und mit einigen oder allen der hierin gezeigten oder beschriebenen Systeme zu arbeiten. Die verschiedenen Elemente, die in den Figuren gezeigt sind, können die Gleichen oder Unterschiedliche sein. Welches als ein erstes Element bezeichnet wird und welches ein zweites Element genannt wird, ist beliebig.
In der Beschreibung und in den Ansprüchen können die Begriffe „gekoppelt“ und „verbunden“ zusammen mit ihren Ableitungen verwendet werden. Es versteht sich, dass diese Ausdrücke nicht als Synonyme füreinander vorgesehen sind. Vielmehr kann bei bestimmten Ausführungsbeispielen „verbunden“ verwendet werden, um anzuzeigen, dass zwei oder mehr Elemente in direktem physischen, optischen oder elektrischen Kontakt miteinander sind. „Gekoppelt“ kann bedeuten, dass zwei oder mehr Elemente in direktem physischem oder elektrischem Kontakt sind. Der Begriff „gekoppelt“ kann jedoch auch bedeuten, dass zwei oder mehr Elemente nicht in direktem Kontakt miteinander sind, jedoch weiter miteinander zusammenarbeiten oder interagieren. Zusätzlich bedeutet „kommunikativ gekoppelt“, dass zwei oder mehr Elemente, die in direktem Kontakt zueinander sein können oder möglicherweise nicht, befähigt werden, miteinander zu kommunizieren. Zum Beispiel, falls eine Komponente A mit einer Komponente B verbunden ist, die wiederum mit einer Komponente C verbunden ist, kann die Komponente A mit der Komponente C kommunikativ gekoppelt sein, unter Verwendung der Komponente B als eine Zwischenkomponente.
Ein Ausführungsbeispiel ist eine Implementierung oder ein Beispiel der Erfindungen. Ein Bezug in der Beschreibung auf „ein Ausführungsbeispiel“, „ein einziges Ausführungsbeispiel“, „einige Ausführungsbeispiele“, oder „andere Ausführungsbeispiele“ bedeutet, dass ein bestimmtes Merkmal, eine bestimmte Struktur oder Charakteristik, das oder die in Verbindung mit den Ausführungsbeispielen beschrieben ist, in zumindest manchen Ausführungsbeispielen umfasst ist, aber nicht notwendigerweise in allen Ausführungsbeispielen, der Erfindungen. Die verschiedenen Erscheinungsbilder „ein Ausführungsbeispiel“, „ein einziges Ausführungsbeispiel“ oder „einige Ausführungsbeispielen“ beziehen sich nicht alle notwendigerweise auf dieselben Ausführungsbeispiele.
Nicht für alle Komponenten, Merkmale, Strukturen, Charakteristika etc., die hierin beschriebenen und dargestellt sind, ist es erforderlich, dass sie in einem bestimmten Ausführungsbeispiel oder Ausführungsbeispielen umfasst sind. Wenn die Beschreibung zum Beispiel beschreibt, dass eine Komponente, ein Merkmal, eine Struktur oder Charakteristik umfasst sein „kann“, „könnte“ oder „möglicherweise“ umfasst ist, ist es nicht erforderlich, dass diese bestimmte Komponente, dieses bestimmte Merkmal, diese bestimmte Struktur oder Charakteristik unbedingt umfasst ist. Wenn die Beschreibung oder der Anspruch sich auf „ein“, „eine“ oder „eines“ von Elementen bezieht, bedeutet das nicht, dass nur eines dieser Elemente vorhanden ist. Wenn die Beschreibung oder die Ansprüche sich auf „ein zusätzliches“ oder „ein weiteres“ Element beziehen, schließt das nicht aus, dass noch mehr als eines des zusätzlichen Elements vorhanden ist.
Kursiv gedruckte Buchstaben, wie z. B. ‚n‘ und ‚M‘ usw. in der vorstehenden detaillierten Beschreibung werden verwendet, um eine Ganzzahl darzustellen, und die Verwendung eines bestimmten Buchstabens ist nicht auf bestimmte Ausführungsbeispiele beschränkt. Ferner kann derselbe Buchstabe in separaten Ansprüchen verwendet werden, um separate Ganzzahlen darzustellen, oder es können unterschiedliche Buchstaben verwendet werden. Zusätzlich kann die Verwendung eines bestimmten Buchstabens in der detaillierten Beschreibung mit dem Buchstaben übereinstimmen, der in einem Anspruch verwendet wird, der sich auf denselben Gegenstand in der detaillierten Beschreibung bezieht, oder möglicherweise nicht.
Wie vorangehend erörtert, können verschiedene Aspekte der hierin beschriebenen Ausführungsbeispiele durch entsprechende Software- und/oder Firmware-Komponenten und - Anwendungen ermöglicht werden, z. B. Software und/oder Firmware, die von einem Prozessor oder Ähnlichem ausgeführt wird. Somit können Ausführungsbeispiele dieser Erfindung als ein Softwareprogramm, Softwaremodule, Firmware und/oder verteilte Software oder zur Unterstützung davon verwendet werden, die auf einer Form von Prozessor, Verarbeitungskern oder eingebetteter Logik ausgeführt werden, eine virtuelle Maschine, die auf einem Prozessor oder Kern läuft, oder anderweitig auf einem oder innerhalb eines nichtflüchtigen computerlesbaren oder maschinenlesbaren Speicherungsmediums implementiert (implemented, realized) ist. Ein nichtflüchtiges computerlesbares oder maschinenlesbares Speicherungsmedium umfasst irgendeinen Mechanismus zum Speichern oder Übertragen von Informationen in einer durch eine Maschine (z. B. einen Computer) lesbaren Form. Zum Beispiel umfasst ein nichtflüchtiges computerlesbares oder maschinenlesbares Speicherungsmedium irgendeinen Mechanismus, der Information in einer Form bereitstellt (d. h. speichert und/oder sendet), auf die durch einen Computer oder eine Rechenmaschine (z. B. Rechenvorrichtung, elektronisches System etc.) zugegriffen werden kann, wie beispielsweise beschreibbare/nicht beschreibbare Medien (z. B. Nur-Lese-Speicher (ROM; read only memory), Direktzugriffsspeicher (RAM; random acccess memory), Magnetplattenspeicherungsmedien, optische Speicherungsmedien, Flash-Speichervorrichtungen etc.) Der Inhalt kann direkt ausführbar („Objekt“ oder „ausführbare“ Form), ein Quellcode oder ein Differenzcode („Delta“ oder „Patch“ -Code) sein. Ein nichtflüchtiges computerlesbares oder maschinenlesbares Speicherungsmedium kann auch eine Speicherung oder Datenbank umfassen, aus der Inhalt heruntergeladen werden kann. Das nichtflüchtige computerlesbare oder maschinenlesbare Speicherungsmedium kann auch eine Vorrichtung oder ein Produkt umfassen, das zur Zeit des Verkaufs oder der Lieferung darauf gespeicherten Inhalt aufweist. Somit kann ein Liefern einer Vorrichtung mit gespeichertem Inhalt oder ein Anbieten von Inhalt zum Herunterladen über ein Kommunikationsmedium als Bereitstellen eines Herstellungsgegenstands, der ein nichtflüchtiges computerlesbares oder maschinenlesbares Speicherungsmedium mit solchem hierin beschriebenen Inhalt umfasst, verstanden werden.
Verschiedene Komponenten, die vorangehend als hierin beschriebene Prozesse, Server oder Werkzeuge bezeichnet werden, können ein Mittel zum Ausführen der beschriebenen Funktionen sein. Die Operationen und Funktionen, die durch verschiedene hierin beschriebene Komponenten ausgeführt werden, können durch Software, die auf einem Verarbeitungselement läuft, implementiert werden, über eingebettete Hardware oder Ähnliches oder irgendeine Kombination von Hardware und Software. Solche Komponenten können als Software-Module, Hardware-Module, Spezialzweck-Hardware (z. B. anwendungsspezifische Hardware, ASICs, DSPs etc.), eingebettete Steuerungen, festverdrahtete Schaltungsanordnung, Hardware-Logik etc. implementiert sein. Softwareinhalte (z. B. Daten, Anweisungen, Konfigurationsinformationen, etc.) können über einen Herstellungsgegenstand bereitgestellt werden, umfassend ein nichtflüchtiges computerlesbares oder maschinenlesbares Speicherungsmedium, das Inhalt bereitstellt, der Anweisungen darstellt, die ausgeführt werden können. Der Inhalt kann dazu führen, dass ein Computer verschiedene hierin beschriebene Funktionen/Operationen ausführt.
Nach hiesigem Gebrauch kann eine Liste von Gegenständen, die durch den Begriff „zumindest eine/r/s von“ verbunden sind, irgendeine Kombination der aufgezählten Begriffe bedeuten. Zum Beispiel kann der Ausdruck „zumindest eine/r/s von A, B oder C“ A; B; C; A und B; A und C; B und C; oder A, B und C bedeuten.
Die vorangehende Beschreibung von dargestellten Ausführungsbeispielen der Erfindung, umfassend was in der Zusammenfassung beschrieben ist, soll nicht erschöpfend sein oder die Erfindung auf die offenbarten genauen Formen begrenzen. Während bestimmte Ausführungsbeispiele von und Beispiele für die Erfindung hierin zu Veranschaulichungszwecken beschrieben sind, sind verschiedene äquivalente Modifikationen innerhalb des Schutzbereichs der Erfindung möglich, wie Fachleute auf dem relevanten Gebiet erkennen können.
Diese Modifikationen können an der Erfindung im Hinblick auf die obige, detaillierte Beschreibung vorgenommen werden. Die Ausdrücke, die in den folgenden Ansprüchen verwendet werden, sollten nicht derart betrachtet werden, dass sie die Erfindung auf die spezifischen Ausführungsbeispiele einschränken, die in der Beschreibung und den Zeichnungen offenbart sind. Stattdessen soll der Schutzbereich der Erfindung vollständig durch die nachfolgenden Ansprüche bestimmt sein, die gemäß etablierter Vorgaben der Anspruchsinterpretation ausgelegt werden sollen.

Claims

Ein Verfahren, umfassend: während eine oder mehrere virtuelle Netzwerkfunktionen (VNFs) auf einer Serverplattform ausgeführt werden, die Plattformhardware mit einer Mehrzahl von Hardwarekomponenten umfasst, Sammeln von Plattformtelemetriedaten, die von der Serverplattform erzeugt werden; Überwachen einer Arbeitslastperformance, die der Arbeit zugeordnet ist, die von zumindest einem der einen oder der mehreren VNFs oder der einen oder der mehreren Anwendungen, die der einen oder den mehreren VNFs zugeordnet sind, durchgeführt wird; Detektieren, dass eine Arbeitslastperformance einer VNF oder einer Anwendung ein Performancekriterium nicht erfüllt, und ansprechend darauf Erzeugen entsprechender Performanceangaben; und Anpassen einer Betriebskonfiguration einer oder mehrerer von den Hardwarekomponenten basierend auf den Plattformtelemetriedaten und den Performanceangaben, um die Arbeitslastperformance zu erhöhen, um das Performancekriterium zu erfüllen oder zu übertreffen.
Das Verfahren gemäß Anspruch 1, wobei die Hardwarekomponenten eine Mehrzahl von Prozessorkernen umfassen und das Anpassen der Betriebskonfiguration der einen oder der mehreren von den Hardwarekomponenten ein Erhöhen einer Frequenz von zumindest einem der Mehrzahl von Prozessorkernen umfasst.
Das Verfahren gemäß Anspruch 1 oder 2, ferner umfassend: Bereitstellen der Plattformtelemetriedaten, die gesammelt werden, an ein Analysesystem; Bereitstellen der Performanceangaben an das Analysesystem; und Erzeugen einer Plattformkonfigurationsanpassungsempfehlung über das Analysesystem und basierend auf den Plattformtelemetriedaten und den Performanceangaben, wobei die Plattformkonfigurationsanpassungsempfehlung verwendet wird, um die Betriebskonfiguration einer oder mehrerer von den Hardwarekomponenten anzupassen, um die Arbeitslastperformance zu erhöhen, um das Performancekriterium zu erfüllen oder zu übertreffen.
Das Verfahren gemäß Anspruch 3, ferner umfassend: Bereitstellen der Plattformkonfigurationsanpassungsempfehlung an eine Managementkomponente; und Anpassen der Betriebskonfiguration einer oder mehrerer von den Hardwarekomponenten über die Managementkomponente, um die Arbeitslastperformance zu erhöhen, um das Performancekriterium zu erfüllen oder zu übertreffen.
Das Verfahren gemäß einem der Ansprüche 1-3, wobei die entsprechenden Performanceangaben eine generische Anzeige umfassen, die anzeigt, dass eine Service Level Agreement- (SLA-) Metrik nicht erfüllt wird.
Das Verfahren gemäß Anspruch 5, ferner umfassend: Empfangen eines SLA-Analyse-Deskriptors, der eine oder mehrere zu überwachende SLA-Metriken definiert; und Einsetzen einer VNF, die ausgebildet ist, die eine oder die mehreren SLA-Metriken durch Verwendung des SLA-Analyse-Deskriptors zu überwachen.
Das Verfahren gemäß einem der Ansprüche 1-3 und 5, ferner umfassend: Implementieren eines Host-Telemetrie-Microservice; Korrelieren, mit dem Host-Telemetrie-Microservice, von Telemetriedaten, die von der Plattformhardware gesammelt werden, und Anwendungstelemetriedaten, die von einer VNF oder einer oder mehreren, der VNF zugeordneten Anwendungen erhalten werden; und Bestimmen, ob das Performancekriterium erfüllt werden, basierend auf der Korrelation.
Das Verfahren gemäß Anspruch 7, ferner umfassend: Bereitstellen einer Eingabe von dem Host-Telemetrie-Microservice an einen Telemetriekollektor, der ausgewählte Telemetrieinformationen von Interesse für die VNF identifiziert, und Bereitstellen von Telemetrieinformationen, die den ausgewählten Telemetrieinformationen von Interesse für die VNF entsprechen, über den Telemetriekollektor an den Host-Telemetrie-Microservice.
Das Verfahren gemäß einem der Ansprüche 1-3, 5 und 7, ferner umfassend: Implementieren der einen oder der mehreren VNFs in einem jeweiligen Pod; für zumindest einen Pod, Implementieren einer Service Level Agreement- (SLA-) Überwachungseinrichtungs- und Lokal-Analyse, um eine SLA-Performancelevel-Verletzung zu detektieren; und ansprechend darauf, Erzeugen entsprechender Performanceangaben, die die SLA-Performancelevel-Verletzung anzeigen.
Ein System, umfassend: Netzwerkfunktionen-virtuelle Infrastruktur (NFVI) umfassend, eine Serverplattform mit einer oder mehreren Hardwarekomponenten, die ausgebildet sind, Plattformtelemetriedaten zu erzeugen; einen Telemetriekollektor, der ausgebildet ist, Plattformtelemetriedaten zu sammeln, die von der einen oder den mehreren Hardwarekomponenten erzeugt werden; zumindest eine virtuelle Netzwerkfunktion (VNF), die ausgebildet ist, auf der Serverplattform zu laufen, um eine jeweilige Arbeitslast auszuführen und Performanceangaben zu erzeugen, die einen Arbeitslastperformancelevel der VNF anzeigen; und ein Analysesystem, das ausgebildet ist zum Empfangen von oder Zugreifen auf Plattformtelemetriedaten, die von dem Telemetriekollektor gesammelt werden, und die Performanceangaben, die von der zumindest einen VNF erzeugt werden; und Bereitstellen einer Plattformkonfigurationsanpassungsempfehlung, die zur Anpassung der Konfiguration von zumindest einer der einen oder der mehreren Hardwarekomponenten basierend auf der Analyse der Plattformtelemetriedaten und der Performanceangaben zu verwendet ist.
Das System gemäß Anspruch 10, wobei die Performanceangaben ein generischer Indikator sind, der anzeigt, dass ein Performancelevel einer VNF nicht erfüllt wird, und wobei die Plattformkonfigurationsanpassungsempfehlung verwendet wird, um die Konfiguration der zumindest einen der einen oder der mehreren Hardwarekomponenten anzupassen, um den Performancelevel der VNF zu erhöhen, um den Performancelevel zu erfüllen.
Das System gemäß Anspruch 10 oder 11, ferner umfassend eine Management- und Orchestrierungs-Komponente (MANO), die ausgebildet ist, die Plattformkonfigurationsanpassungsempfehlung von dem Analysesystem zu empfangen und eine oder mehrere Steuereingaben an die Serverplattform bereitzustellen, um die Konfiguration von zumindest einer der einen oder der mehreren Hardwarekomponenten in der Serverplattform anzupassen.
Das System gemäß Anspruch 12, wobei die MANO ferner ausgebildet ist zum: Empfangen von oder Zugreifen auf einen Service Level Agreement- (SLA-) Analyse-Deskriptor, der eines oder mehrere definiert von a) zu überwachende VNF-Metriken; und b) einen oder mehrere von Schwellenwerten, Integrationsperioden und Kombinationsregeln für Analyse und Trigger, die SLA-Verletzungen erzeugen; und Einsetzen einer VNF und Ausbilden der VNF, um SLA-Performanceangaben zu erzeugen, die von dem SLA-Analyse-Deskriptor definiert sind.
Das System gemäß einem der Ansprüche 10-12, ferner umfassend einen Host-Telemetrie-Microservice, der ausgebildet ist zum: Korrelieren von, von der Plattformhardware gesammelten Telemetriedaten und Anwendungstelemetriedaten, die von einer VNF oder einer oder mehreren, der VNF zugeordneten Anwendungen erhalten werden; und Bestimmen, ob das Performancekriterium erfüllt werden, basierend auf der Korrelation.
Das System gemäß Anspruch 14, wobei der Host-Telemetrie-Microservice ausgebildet ist, eine Eingabe an den Telemetriekollektor bereitzustellen, die ausgewählte Telemetrieinformationen von Interesse für eine VNF identifiziert, und wobei der Telemetriekollektor ausgebildet ist, an den Host-Telemetrie-Microservice Telemetrieinformationen bereitzustellen, die den ausgewählten Telemetrieinformationen von Interesse für die VNF entsprechen.
Ein nichtflüchtiges, maschinenlesbares Speicherungsmedium mit Anweisungen, die eine Mehrzahl von Softwarekomponenten umfassen, die ausgebildet sind, in einer verteilten Umgebung ausgeführt zu werden, umfassen eine erste Serverplattform mit Plattformhardware, die eine Mehrzahl von Hardwarekomponenten umfasst, wobei die Mehrzahl von Softwarekomponenten umfasst: eine Plattformtelemetrieüberwachungseinrichtung, die ausgebildet ist, auf der ersten Serverplattform ausgeführt zu werden, und die ausgebildet ist, Plattformtelemetriedaten zu sammeln, die von der ersten Serverplattform erzeugt werden, und gesammelte Plattformtelemetriedaten an eines von einem Datensammelüberwachungswerkzeug oder einem Analysesystem bereitzustellen oder zu veröffentlichen; eine erste virtuelle Netzwerkfunktion (VNF), die ausgebildet ist zum Durchführen einer Arbeitslast über die Ausführung auf der ersten Serverplattform; Überwachen einer Arbeitslastperformance; und Erzeugen von Performanceangaben basierend auf der überwachten Arbeitslastperformance; und Bereitstellen der Performanceangaben an eines von dem Datensammelüberwachungswerkzeug oder dem Analysesystem; und das Analysesystem, das ausgebildet ist zum Empfangen von oder Zugreifen auf Plattformtelemetriedaten, die von der Plattformtelemetrieüberwachungseinrichtung gesammelt werden, und Empfangen von oder Zugreifen auf die Performanceangaben, die von der ersten VNF erzeugt werden; und Bereitstellen einer Plattformkonfigurationsanpassungsempfehlung, die zur Anpassung der Konfiguration von zumindest einer der einen oder der mehreren Hardwarekomponenten auf der ersten Serverplattform basierend auf der Analyse der Plattformtelemetriedaten und der Performanceangaben zu verwendet ist.
Das nichtflüchtige maschinenlesbare Speicherungsmedium gemäß Anspruch 16, wobei die Mehrzahl von Softwarekomponenten mehrere Kubernetes-Komponenten umfassen, wobei die erste VNF einen VNF-Pod umfasst und wobei der VNP-Pod und die Plattformtelemetrieüberwachungseinrichtung in einem Kubemetes-Knoten implementiert sind, der von der Serverplattform gehostet wird.
Das nichtflüchtige maschinenlesbare Speicherungsmedium gemäß Anspruch 17, wobei die Mehrzahl von Softwarekomponenten ferner eines umfasst von einer Master- oder Management- und Orchestrierungs-Komponente (MANO), die ausgebildet ist, die Plattformkonfigurationsanpassungsempfehlung von dem Analysesystem zu empfangen und eine oder mehrere Steuereingaben an die Serverplattform bereitzustellen, um die Konfiguration von zumindest einer der einen oder der mehreren Hardwarekomponenten in der Serverplattform anzupassen.
Das nichtflüchtige maschinenlesbare Speicherungsmedium gemäß Anspruch 18, wobei der Master oder MANO ferner ausgebildet ist zum: Empfangen von oder Zugreifen auf einen Service Level Agreement- (SLA-) Analyse-Deskriptor, der eines oder mehrere definiert von, a) zu überwachende VNF-Metriken; und b) einen oder mehrere von Schwellenwerten, Integrationsperioden und Kombinationsregeln für Analyse und Trigger, die SLA-Verletzungen erzeugen; und Einsetzen der ersten VNF und Ausbilden der ersten VNF, um SLA-Performanceangaben zu erzeugen, die von dem SLA-Analyse-Deskriptor definiert sind.
Das nichtflüchtige maschinenlesbare Speicherungsmedium gemäß Anspruch 19, wobei die erste VNF eine SLA-Überwachungseinrichtungs- und Lokal-Analyse-Komponente umfasst, die ausgebildet ist zum: Überwachen der Arbeitslastperformance der ersten VNF im Hinblick auf den SLA-Analyse-Deskriptor, um eine VNF-SLA-Verletzung zu detektieren; und ansprechend auf die Detektion einer VNF-SLA-Verletzung; und Erzeugen von Performanceangaben, die anzeigen, dass eine VNF-SLA-Verletzung aufgetreten ist, und Weiterleiten der Performanceangaben an eines von dem Datensammelüberwachungswerkzeug und dem Analysesystem.