Azure Operator Nexus compute

Azure Operator Nexus basiert auf grundlegenden Konstrukten wie Computeservern, Speicher-Anwendung s und Netzwerk-Fabric-Geräten. Diese Computeserver, auch als Bare-Metal-Maschinen (BMMs) bezeichnet, stellen die physischen Maschinen auf dem Rack dar. Sie führen das Betriebssystem CBL-Mariner aus und bieten geschlossene Integrationsunterstützung für hochleistungsorientierte Workloads.

Diese BMMs werden als Teil der Azure Operator Nexus Automation Suite bereitgestellt. Sie sind als Knoten in einem Kubernetes-Cluster vorhanden, um verschiedene virtualisierte und containerisierte Workloads im Ökosystem zu bedienen.

Jede BMM in einer Azure Operator Nexus-Instanz wird als Azure-Ressource dargestellt. Operatoren erhalten Zugriff, um verschiedene Vorgänge auszuführen, um den Lebenszyklus des BMM wie jede andere Azure-Ressource zu verwalten.

Wichtige Funktionen des Azure Operator Nexus Compute

NUMA-Ausrichtung

Die Ausrichtung des nichtuniformen Speicherzugriffs (NUMA) ist eine Technik zur Optimierung der Leistung und Ressourcenauslastung auf mehreren Socketservern. Es umfasst das Ausrichten von Speicher- und Computeressourcen, um die Latenz zu reduzieren und den Datenzugriff innerhalb eines Serversystems zu verbessern.

Durch die strategische Platzierung von Softwarekomponenten und Workloads auf NUMA-fähige Weise können Operatoren die Leistung von Netzwerkfunktionen wie virtualisierten Routern und Firewalls verbessern. Diese Platzierung führt zu einer verbesserten Dienstbereitstellung und Reaktionsfähigkeit in ihren Telco-Cloudumgebungen.

Standardmäßig werden alle in einer Azure Operator Nexus-Instanz bereitgestellten Workloads NUMA ausgerichtet.

CPU-Pinning

Cpu-Pinning ist eine Technik, um bestimmte CPU-Kerne dedizierten Aufgaben oder Workloads zuzuweisen, die eine konsistente Leistung und Ressourcenisolation gewährleisten. Durch das Anheften kritischer Netzwerkfunktionen oder Echtzeitanwendungen an bestimmte CPU-Kerne können Operatoren Latenz minimieren und die Vorhersagbarkeit in ihrer Infrastruktur verbessern. Dieser Ansatz ist in Szenarien hilfreich, in denen strenge Qualitätsanforderungen vorhanden sind, da diese Aufgaben dedizierte Verarbeitungsleistung für eine optimale Leistung erhalten können.

Alle virtuellen Computer, die für VNF-Workloads (Virtual Network Function) oder containerisierte Netzwerkfunktion (CNF) auf azure Operator Nexus compute erstellt wurden, werden an bestimmte virtuelle Kerne angeheftet. Diese Pinning bietet eine bessere Leistung und vermeidet CPU-Diebstahl.

CPU-Isolation

Die CPU-Isolation bietet eine klare Trennung zwischen den für Workloads zugewiesenen CPUs und den CPUs, die für Steuerungsebenen- und Plattformaktivitäten zugeordnet sind. Die CPU-Isolierung verhindert Störungen und schränkt die Vorhersehbarkeit der Leistung für kritische Workloads ein. Durch das Isolieren von CPU-Kernen oder Gruppen von Kernen können Operatoren die Wirkung lauter Nachbarn mindern. Sie trägt dazu bei, die erforderliche Verarbeitungsleistung für latenzempfindliche Anwendungen zu gewährleisten.

Azure Operator Nexus reserviert eine kleine Gruppe von CPUs für das Hostbetriebssystem und andere Plattformanwendungen. Die wieder Standard verwendenden CPUs sind für die Ausführung tatsächlicher Workloads verfügbar.

Unterstützung für riesige Seiten

Die verwendung großer Seiten in Telco-Workloads bezieht sich auf die Auslastung großer Speicherseiten, in der Regel 2 MB oder 1 GB größe, anstelle der standardmäßigen 4-KB-Seiten. Dieser Ansatz trägt dazu bei, den Arbeitsspeicheraufwand zu reduzieren und die Gesamtleistung des Systems zu verbessern. Dadurch wird die TLB-Fehlerrate (Translation Look-Aside Buffer) reduziert und die Speicherzugriffseffizienz verbessert.

Telco-Workloads, die große Datasets oder intensive Speichervorgänge wie die Netzwerkpaketverarbeitung umfassen, können von einer großen Seitennutzung profitieren, da sie die Speicherleistung verbessert und speicherbezogene Engpässe reduziert. Daher sehen Benutzer einen verbesserten Durchsatz und eine reduzierte Latenz.

Alle auf Azure Operator Nexus erstellten virtuellen Computer können je nach Art des virtuellen Computers 2-MB oder 1 GB große Seiten nutzen.

Dual-Stack-Unterstützung

Die Dual-Stack-Unterstützung bezieht sich auf die Fähigkeit von Netzwerkgeräten und Protokollen, sowohl IPv4- als auch IPv6-Datenverkehr gleichzeitig zu verarbeiten. Mit der zunehmenden Akzeptanz von IPv6-Adressen und der wachsenden Akzeptanz von IPv6 ist die Dual-Stack-Unterstützung entscheidend für einen nahtlosen Übergang und die Koexistenz zwischen den beiden Protokollen.

Telco-Betreiber verwenden Dual-Stack-Unterstützung, um Kompatibilität, Interoperabilität und zukunftssicheres Arbeiten ihrer Netzwerke zu gewährleisten. Es ermöglicht ihnen, sowohl IPv4- als auch IPv6-Geräte und -Dienste aufzunehmen, während sie schrittweise auf die vollständige IPv6-Bereitstellung umsteigen.

Die Dual-Stack-Unterstützung sorgt unabhängig von ihren Netzwerkadressierungsprotokollen für eine unterbrechungsfreie Konnektivität und reibungslose Servicebereitstellung für Kunden. Azure Operator Nexus bietet Unterstützung für die IPv4- und IPv6-Konfiguration auf allen Ebenen des Stapels.

Netzwerkschnittstellenkarten

Computes in Azure Operator Nexus sind so konzipiert, dass sie die Anforderungen für die Ausführung kritischer Anwendungen erfüllen, die Telco-Klasse sind. Sie können eine schnelle und effiziente Datenübertragung zwischen Servern und Netzwerken durchführen.

Workloads können die Single-Root-E/A-Virtualisierung (SR-IOV) verwenden. SR-IOV ermöglicht die direkte Zuordnung physischer E/A-Ressourcen, z. B. Netzwerkschnittstellen, zu virtuellen Computern. Diese direkte Zuweisung umgeht die virtuelle Switchebene des Hypervisors.

Dieser direkte Hardwarezugriff verbessert den Netzwerkdurchsatz, verringert die Latenz und ermöglicht eine effizientere Nutzung von Ressourcen. Es macht SR-IOV zu einer idealen Wahl für Operatoren, die virtualisierte und containerisierte Netzwerkfunktionen ausführen.

BMM-Status

Die folgenden Eigenschaften spiegeln den Betriebszustand eines BMM wider:

• Power State gibt den Zustand als abgeleitet von einem Bare-Metal-Controller (BMC) an. Der Status kann entweder On oder Off lauten.

• Ready State stellt eine allgemeine Bewertung der BMM-Bereitschaft bereit. Es untersucht eine Kombination von Detailed Status, Power Stateund den Bereitstellungsstatus der Ressource, um zu bestimmen, ob das BMM bereit ist oder nicht. Ist Ready State dies der Zeitpunkt, ist Truedas BMM aktiviert, Detailed Status Provisionedund der Knoten, der das BMM darstellt, wurde erfolgreich dem Undercloud Kubernetes-Cluster hinzugefügt. Wenn eine dieser Bedingungen nicht erfüllt ist, Ready State ist auf .False

• Cordon State spiegelt die Fähigkeit wider, alle Arbeitslasten auf einem Computer auszuführen. Gültige Werte sind Cordoned und Uncordoned. Cordoned nutzt die Erstellung neuer Workloads auf dem Computer. Uncordoned stellt sicher, dass Workloads jetzt auf diesem BMM ausgeführt werden können.

• Detailed Status gibt den aktuellen Status des Computers wieder:

  • Preparing: Der Computer wird für die Bereitstellung vorbereitet.
  • Provisioning: Die Bereitstellung wird ausgeführt.
  • Provisioned: Das Betriebssystem wird auf dem Computer bereitgestellt.
  • Available: Der Computer ist für die Teilnahme am Cluster verfügbar. Der Computer wurde erfolgreich bereitgestellt, ist aber zurzeit deaktiviert.
  • Error: Der Computer konnte nicht bereitgestellt werden.

  Preparing und Provisioning sind transitorische Zustände. Provisioned, Availableund Error sind Endzustandsstatus.

• MachineRoles hilft dabei, die Rolle(n) zu identifizieren, die BMM im Nexus-Cluster erfüllt. Die folgenden Rollen werden BMM-Ressourcen zugewiesen:

  • Control plane: Diese BMM führt die Kubernetes Steuerflugzeug-Agenten für Nexus-Plattformcluster aus.
  • Management plane: Die BMM führt die Nexus-Plattform-Agents mit Controllern und Erweiterungen aus.
  • Compute plane: Die BMM, die für die Ausführung der tatsächlichen Mandantenarbeitslasten verantwortlich ist, einschließlich Nexus Kubernetes-Clustern und virtuellen Computern.

  Weitere Informationen zu Computerrollen finden Sie unter diesem Link .

BMM-Vorgänge

• Update/Patch BareMetal Machine: Aktualisieren der BMM-Ressourceneigenschaften.
• List/Show BareMetal Machine: Abrufen von BMM-Informationen.
• Reimage BareMetal Machine: Stellen Sie eine BMM neu her, die mit der Imageversion übereinstimmt, die im gesamten Cluster verwendet wird.
• Ersetzen Sie BareMetal Machine: Ersetzen Sie eine BMM als Teil des Aufwands, die Maschine zu bedienen.
• Starten Sie den BareMetal-Computer neu: Starten Sie ein BMM neu.
• Ausschalten des BareMetal-Computers: Schalten Sie ein BMM aus.
• Starten Sie den BareMetal-Computer: Schalten Sie ein BMM ein.
• Cordon BareMetal Machine: Verhindern Sie die Planung von Workloads auf dem angegebenen Kubernetes-Knoten des BMM. Optional können Sie die Evakuierung der Workloads vom Knoten zulassen.
• Uncordon BareMetal Machine: Allow scheduling of workloads on the specified BMM's Kubernetes node.
• BareMetalMachine Validate: Auslösen der Hardwareüberprüfung eines BMM.
• BareMetalMachine Run: Zulassen, dass der Kunde ein Skript ausführen kann, das direkt in der Eingabe für das zielorientierte BMM angegeben ist.
• BareMetalMachine Run Data Extract: Zulassen, dass der Kunde eine oder mehrere Datenextraktionen für ein BMM ausführen kann.
• BareMetalMachine Run Read-only: Zulassen, dass der Kunde einen oder mehrere schreibgeschützte Befehle für ein BMM ausführen kann.

Hinweis

Kunden können BMMs nicht direkt erstellen oder löschen. Diese Maschinen werden nur als Realisierung des Clusterlebenszyklus erstellt. Implementierung blockiert Erstellungs- oder Löschanforderungen von jedem Benutzer und ermöglicht nur interne/anwendungsgesteuerte Erstellungs- oder Löschvorgänge.

Formularfaktorspezifische Informationen

Azure Operator Nexus bietet eine Gruppe von lokalen Cloudlösungen, die sowohl Nah-Edge- als auch Far-Edge-Umgebungen erfüllen.