Betreiber müssen vor der Bereitstellung der Operator Nexus-Plattformsoftware die Voraussetzungen erfüllen. Einige dieser Schritte können längere Zeit in Anspruch nehmen. Eine Bewertung dieser Voraussetzungen kann daher von Vorteil sein.
In nachfolgenden Bereitstellungen von Operator Nexus-Instanzen können Sie zu dem Erstellen des lokalen Network Fabrics und des Clusters springen.
Voraussetzungen für Azure
Wenn Sie Operator Nexus zum ersten Mal oder in einer neuen Region bereitstellen, müssen Sie wie auf der Seite Voraussetzungen für Azure Operator Nexus beschrieben zunächst einen Netzwerk-Fabric Controller und anschließend einen Cluster-Manager erstellen. Darüber hinaus müssen die folgenden Aufgaben ausgeführt werden:
Richten Sie Benutzer, Richtlinien, Berechtigungen und die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) ein.
Richten Sie Ressourcengruppen ein, um Ressourcen, die für die Operator Nexus-Plattform erstellt werden, auf logische Weise zu platzieren und zu gruppieren.
Richten Sie ExpressRoute-Konnektivität zwischen Ihrem WAN und einer Azure-Region ein.
Um Microsoft Defender for Endpoint für lokale Bare-Metal-Computer (BMMs) zu aktivieren, müssen Sie vor der Bereitstellung einen Defender for Servers-Plan in Ihrem Operator Nexus-Abonnement ausgewählt haben.
Weitere Informationen finden Sie auf der Seite Defender for Cloud-Sicherheit.
Voraussetzungen für die lokale Umgebung
Bei der Bereitstellung einer lokalen Operator Nexus-Instanz in Ihrem Rechenzentrum sind wahrscheinlich verschiedene Teams beteiligt, die eine Vielzahl von Rollen ausführen. Die folgenden Aufgaben müssen genau ausgeführt werden, um eine erfolgreiche Plattformsoftwareinstallation sicherzustellen.
Physische Hardwareeinrichtung
Ein Betreiber, der den Operator Nexus-Dienst nutzen möchte, muss Hardwareressourcen erwerben, installieren, konfigurieren und betreiben. In diesem Abschnitt des Dokuments werden die erforderlichen Komponenten und Bemühungen zum Erwerben und Implementieren der entsprechenden Hardwaresysteme beschrieben. In diesem Abschnitt werden die Materialliste, das Rack-Höhendiagramm und das Verkabelungsdiagramm sowie die erforderlichen Schritte zum Zusammenstellen der Hardware erläutert.
Verwenden der Stückliste (Bill of Materials, BOM)
Um eine nahtlose Betreibererfahrung zu gewährleisten, hat Operator Nexus eine BOM für die für den Dienst erforderliche Hardwareakquisition entwickelt. Diese BOM ist eine umfassende Liste der erforderlichen Komponenten und Mengen, die zur Implementierung der Umgebung für eine erfolgreiche Implementierung und Wartung der lokalen Instanz erforderlich sind. Die BOM ist so strukturiert, dass der Betreiber eine Reihe von Lagerhaltungseinheiten (SKU) erhält, die von Hardwareanbietern bestellt werden können. SKUs werden später im Dokument erläutert.
Verwenden des Höhendiagramms
Das Rack-Höhendiagramm ist ein grafischer Verweis, der veranschaulicht, wie die Server und andere Komponenten in die montierten und konfigurierten Racks passen. Das Rack-Höhendiagramm wird als Teil der allgemeinen Buildanweisungen bereitgestellt. Es hilft Betreibern, alle für den Dienstbetrieb erforderlichen Hardwarekomponenten ordnungsgemäß zu konfigurieren und zu installieren.
Verkabelungsdiagramm
Verkabelungsdiagramme sind grafische Darstellungen der Kabelverbindungen, die für die Bereitstellung von Netzwerkdiensten für Komponenten erforderlich sind, die in den Racks installiert sind. Nach dem Verkabelungsdiagramm wird die ordnungsgemäße Implementierung der verschiedenen Komponenten im Build sichergestellt.
So wird es basierend auf der SKU geordnet
SKU-Definition
Eine SKU ist eine Bestandsverwaltungs- und Nachverfolgungsmethode, die das Gruppieren mehrerer Komponenten in einen einzelnen Kennzeichner ermöglicht. Eine SKU ermöglicht es einem Operator, alle erforderlichen Komponenten mit einer SKU-Nummer zu bestellen. Die SKU beschleunigt die Betreiber- und Lieferanteninteraktion und reduziert gleichzeitig Fehler bei der Bestellung aufgrund komplexer Teilelisten.
Platzieren einer SKU-basierten Bestellung
Operator Nexus hat eine Reihe von SKUs mit Anbietern wie Dell, Pure Storage und Arista erstellt, auf die der Betreiber beim Aufgeben einer Bestellung verweisen kann. So muss ein Betreiber einfach eine Bestellung basierend auf den SKU-Informationen, die von Operator Nexus bereitgestellt werden, an den Anbieter richten, um die richtige Teileliste für den Build zu erhalten.
So erstellen Sie den physischen Hardwarespeicherbedarf
Der physische Hardwarebuild wird über eine Reihe von Schritten ausgeführt, die in diesem Abschnitt beschrieben werden.
Es gibt drei erforderliche Schritte vor der Buildausführung. In diesem Abschnitt werden auch Annahmen über die Fähigkeiten der Mitarbeiter des Betreibers zur Ausführung des Builds erörtert.
Bestellen und Erhalt der spezifischen Hardwareinfrastruktur-SKU
Die Bestellung der entsprechenden SKU und die Lieferung der Hardware an den Standort muss vor dem Beginn des Builds erfolgen. Für diesen Schritt sollte ein angemessener Zeitraum gewährt werden. Wir empfehlen dem Betreiber, frühzeitig mit dem Lieferanten der Hardware zu kommunizieren, um Lieferzeitrahmen sicherzustellen und zu verstehen.
Vorbereiten des Standorts
Der Installationsstandort muss in der Lage sein, die Hardwareinfrastruktur in Bezug auf Platz, Energie und Netzwerk zu unterstützen. Die spezifischen Standortanforderungen werden von der für den Standort erworbenen SKU definiert. Dieser Schritt kann nach der Bestellung und vor dem Eingang der SKU ausgeführt werden.
Planen von Ressourcen
Der Buildprozess erfordert mehrere unterschiedliche Mitarbeiter, um den Build durchzuführen, z. B. Ingenieure für die Bereitstellung von Energie, Netzwerkzugriff und Verkabelung und Systemmitarbeiter für die Zusammenzustellung von Racks, Switches und Servern, um nur einige zu nennen. Um sicherzustellen, dass der Build zeitnah durchgeführt wird, empfehlen wir, diese Teammitglieder im Voraus basierend auf dem Lieferungszeitplan einzuplanen.
Annahmen zu Mitarbeiterkompetenzen in Bezug auf Builds
Die Mitarbeiter, die den Build durchführen, sollten Erfahrungen bei der Montage von Systemhardware wie Racks, Switches, PDUs und Servern haben. In den Anweisungen werden die Schritte des Prozesses erläutert, während sie auf Rack-Höhen- und Verkabelungsdiagramme verweisen.
Übersicht über den Buildprozess
Wenn die Standortvorbereitung für die Unterstützung der bestellten SKU abgeschlossen und überprüft ist, erfolgt der Buildvorgang in den folgenden Schritten:
Montieren Sie die Racks basierend auf den Rack-Höhen der SKU. Spezifische Anweisungen zur Rack-Montage werden vom Rack-Hersteller bereitgestellt.
Installieren Sie nach der Montage der Racks die Fabric-Geräte in den Racks gemäß Höhendiagramm.
Verkabeln Sie die Fabric-Geräte, indem Sie die Netzwerkschnittstellen gemäß Kabeldiagramm verbinden.
Stellen Sie die Server gemäß Rack-Höhendiagramm zusammen und installieren Sie sie.
Stellen Sie das Speichergerät gemäß Rack-Höhendiagramm zusammen und installieren Sie es.
Verkabeln Sie die Server- und Speichergeräte, indem Sie die Netzwerkschnittstellen gemäß Kabeldiagramm verbinden.
Verkabelung der Energieversorgung von jedem Gerät.
Überprüfen Sie den Build über die Checklisten, die von Operator Nexus und anderen Anbietern bereitgestellt werden.
So überprüfen Sie die physische Hardwareinstallation visuell
Es wird empfohlen, während des Prozesses alle Kabel nach ANSI/TIA 606-Standards oder den Standards des Betreibers zu beschriften. Im Buildprozess sollte auch eine Reversezuordnung für die Verkabelung von einem Switchport zu einer Fernendverbindung erstellt werden. Die Reversezuordnung kann mit dem Kabeldiagramm verglichen werden, um die Installation zu überprüfen.
Terminalserver- und Speicherarray-Setup
Nachdem die physische Installation und Validierung abgeschlossen wurde, werden die nächsten Schritte zum Konfigurieren der Standardeinstellungen durchgeführt, die vor der Installation von Plattformsoftware erforderlich sind.
Einrichten des Terminalservers
Der Terminalserver wurde wie folgt bereitgestellt und konfiguriert:
Der Terminalserver ist für die Out-of-Band-Verwaltung konfiguriert.
Anmeldeinformationen für die Authentifizierung wurden eingerichtet.
Der DHCP-Client ist auf dem Out-of-Band-Verwaltungsport aktiviert
HTTP-Zugriff ist aktiviert.
Die Terminalserverschnittstelle ist mit den lokalen Provider-Edge-Routern (PEs) des Betreibers verbunden und mit den IP-Adressen und Anmeldeinformationen konfiguriert
Auf den Terminalserver kann über das Verwaltungs-VPN (virtuelles privates Netzwerk) zugegriffen werden.
Schritt 1: Einrichten des Hostnamens
Führen Sie die folgenden Schritte aus, um den Hostnamen für Ihren Terminalserver einzurichten:
Zum Konfigurieren der Netzwerkeinstellungen führen Sie diese Schritte aus:
Führen Sie die folgenden Befehle in der CLI aus:
Bash
sudo ogcli create conn << 'END'
description="PE1 to TS NET1"
mode="static"
ipv4_static_settings.address="<TS_NET1_IP>"
ipv4_static_settings.netmask="<TS_NET1_NETMASK>"
ipv4_static_settings.gateway="<TS_NET1_GW>"
physif="net1"
END
sudo ogcli create conn << 'END'
description="PE2 to TS NET2"
mode="static"
ipv4_static_settings.address="<TS_NET2_IP>"
ipv4_static_settings.netmask="<TS_NET2_NETMASK>"
ipv4_static_settings.gateway="<TS_NET2_GW>"
physif="net2"
END
Parameter:
Parametername
BESCHREIBUNG
TS_NET1_IP
Terminalserver-IP-Adresse für die Verbindung zwischen PE1 und TS NET1
TS_NET1_NETMASK
Terminalserver-Netzwerkmaske für die Verbindung zwischen PE1 und TS NET1
TS_NET1_GW
Terminalservergateway für die Verbindung zwischen PE1 und TS NET1
TS_NET2_IP
Terminalserver-IP-Adresse für die Verbindung zwischen PE2 und TS NET2
TS_NET2_NETMASK
Terminalserver-Netzwerkmaske für die Verbindung zwischen PE2 und TS NET2
TS_NET2_GW
Terminalserver-Gateway für die Verbindung zwischen PE2 und TS NET2
Hinweis
Stellen Sie sicher, dass Sie diese Parameter durch geeignete Werte ersetzen.
Schritt 3: Löschen der net3-Schnittstelle (falls vorhanden)
Führen Sie diese Schritte aus, um die net3-Schnittstelle zu löschen:
Überprüfen Sie mit dem folgenden Befehl, ob eine Schnittstelle auf der physischen Schnittstelle net3 und „Standard-IPv4 Static Address“ konfiguriert ist:
Bash
ogcli get conns
description="Default IPv4 Static Address"
name="<TS_NET3_CONN_NAME>"
physif="net3"
Parameter:
Parametername
Beschreibung
TS_NET3_CONN_NAME
Name der Terminalserver-NET3-Verbindung
Entfernen Sie die Schnittstelle, falls vorhanden:
Bash
ogcli delete conn "<TS_NET3_CONN_NAME>"
Hinweis
Stellen Sie sicher, dass Sie diese Parameter durch geeignete Werte ersetzen.
Schritt 4: Einrichten des Supportadministratorbenutzerkontos
Führen Sie die folgenden Schritte aus, um das Supportadministratorbenutzerkonto einzurichten:
Führen Sie für jedes Benutzerkonto den folgenden Befehl in der CLI aus:
Bash
ogcli create user << 'END'
description="Support Admin User"
enabled=true
groups[0]="admin"
groups[1]="netgrp"
password="<SUPPORT_PWD>"
username="<SUPPORT_USER>"
END
Parameter:
Parametername
BESCHREIBUNG
SUPPORT_USER
Benutzer „Supportadministrator“
SUPPORT_PWD
Kennwort der Benutzerrolle „Supportadministrator“
Hinweis
Stellen Sie sicher, dass Sie diese Parameter durch geeignete Werte ersetzen.
Schritt 5: Hinzufügen der sudo-Unterstützung für Administratorbenutzerkonten
Führen Sie die folgenden Schritte aus, um die sudo-Unterstützung für Administratorbenutzerkonten hinzuzufügen:
Öffnen Sie die sudo-Konfigurationsdatei:
Bash
sudo vi /etc/sudoers.d/opengear
Fügen Sie die folgenden Zeilen hinzu, um sudo-Zugriff zuzuweisen:
Bash
%netgrp ALL=(ALL) ALL
%admin ALL=(ALL) NOPASSWD: ALL
Hinweis
Achten Sie darauf, die Änderungen nach der Bearbeitung der Datei zu speichern.
Diese Konfiguration ermöglicht es Mitgliedern der Gruppe „netgrp“, jeden Befehl unter Verwendung eines beliebigen Benutzerkontos auszuführen, und Mitgliedern der Gruppe „admin“, jeden Befehl unter Verwendung eines beliebigen Benutzerkontos ohne Passwort auszuführen.
Schritt 6: Sicherstellen der Verfügbarkeit des LLDP-Diensts
Führen Sie die folgenden Schritte aus, um sicherzustellen, dass der LLDP-Dienst auf Ihrem Terminalserver verfügbar ist:
Überprüfen Sie, ob der LLDP-Dienst ausgeführt wird:
Bash
sudo systemctl status lldpd
Sie sollten eine ähnliche Ausgabe wie die folgende erhalten, wenn der Dienst ausgeführt wird:
Output
lldpd.service - LLDP daemon
Loaded: loaded (/lib/systemd/system/lldpd.service; enabled; vendor preset: disabled)
Active: active (running) since Thu 2023-09-14 19:10:40 UTC; 3 months 25 days ago
Docs: man:lldpd(8)
Main PID: 926 (lldpd)
Tasks: 2 (limit: 9495)
Memory: 1.2M
CGroup: /system.slice/lldpd.service
├─926 lldpd: monitor.
└─992 lldpd: 3 neighbors.
Notice: journal has been rotated since unit was started, output may be incomplete.
Wenn der Dienst nicht aktiv ist (ausgeführt wird), starten Sie ihn:
Bash
sudo systemctl start lldpd
Lassen Sie den Dienst beim Neustart starten:
Bash
sudo systemctl enable lldpd
Hinweis
Führen Sie diese Schritte aus, um sicherzustellen, dass der LLDP-Dienst immer verfügbar ist und beim Neustart automatisch gestartet wird.
Schritt 7: Überprüfen des Systemdatums/der Systemzeit
Stellen Sie sicher, dass das Systemdatum/die Systemzeit richtig festgelegt ist und die Zeitzone für den Terminalserver in UTC liegt.
Zeitzoneneinstellung überprüfen:
So überprüfen Sie die aktuelle Zeitzoneneinstellung:
Bash
ogcli get system/timezone
Festlegen der Zeitzone auf UTC:
Wenn die Zeitzone nicht auf UTC festgelegt ist, können Sie sie wie folgt festlegen:
Bash
ogcli update system/timezone timezone=\"UTC\"
Überprüfen des aktuelles Datums/der aktuellen Zeit:
Überprüfen Sie das aktuelle Datum und die Uhrzeit:
Bash
date
Korrigieren Sie das Datum/die Zeit, falls sie falsch sind:
Wenn das Datum/die Uhrzeit falsch sind, können Sie es wie folgt korrigieren:
Bash
ogcli replace system/time
Reading information from stdin. Press Ctrl-D to submit and Ctrl-C to cancel.
time="<CURRENT_DATE_TIME>"
Parameter:
Parametername
Beschreibung
CURRENT_DATE_TIME
Aktuelle Datumszeit im Format hh:mm MMM DD, JJJJ
Hinweis
Stellen Sie sicher, dass das Systemdatum/die Systemzeit genau ist, um Probleme mit Anwendungen oder Diensten zu verhindern, die diese benötigen.
Schritt 8: Bezeichnen von Terminalserverports (falls sie fehlen/falsch sind)
Verwenden Sie zum Bezeichnen von Terminalserverports den folgenden Befehl:
Bash
ogcli update port "port-<PORT_#>" label=\"<NEW_NAME>\" <PORT_#>
Parameter:
Parametername
Beschreibung
NEW_NAME
Portbezeichnungsname
PORT_#
Portnummer des Terminalservers
Schritt 9: Erforderliche Einstellungen für serielle PURE Array-Verbindungen
Pure Storage-Arrays, die vor 2024 erworben wurden, verfügen über Controller der Revision R3, die Rollover-Konsolenkabel verwenden und die folgenden benutzerdefinierten Befehle für die Verbindung mit dem seriellen Anschluss erfordern:
Pure Storage R3-Controller:
Bash
ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X1"' <PORT_#> Pure Storage Controller console
Neuere Pure Storage-Appliances und Systeme, die von Pure Storage-Controllern R3 auf R4 aktualisiert wurden, verwenden gerade Durchgangskonsolenkabel mit den aktualisierten Einstellungen unten:
Pure Storage R4-Controller:
Bash
ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X2"' <PORT_#> Pure Storage Controller console
Parameter:
Parametername
Beschreibung
PORT_#
Portnummer des Terminalservers
Mit diesen Befehlen werden die Baudrate und die Pinbelegung für die Verbindung mit der Pure Storage Controller-Konsole festgelegt.
Hinweis
Alle anderen Einstellungen für die Terminalserver-Anschlusskonfiguration sollten gleich bleiben und standardmäßig mit einem geraden RJ45-Durchgangskonsolenkabel funktionieren.
Schritt 10: Überprüfen der Einstellungen
Führen Sie die folgenden Befehle aus, um die Konfigurationseinstellungen zu überprüfen:
Bash
ping <PE1_IP> -c 3 # Ping test to PE1 //TS subnet +2
ping <PE2_IP> -c 3 # Ping test to PE2 //TS subnet +2
ogcli get conns # Verify NET1, NET2, NET3 Removed
ogcli get users # Verify support admin user
ogcli get static_routes # Ensure there are no static routes
ip r # Verify only interface routes
ip a # Verify loopback, NET1, NET2
date # Check current date/time
pmshell # Check ports labelled
sudo lldpctl
sudo lldpcli show neighbors # Check LLDP neighbors - should show data from NET1 and NET2
Hinweis
Vergewissern Sie sich, dass die LLDP-Nachbarn wie erwartet sind und erfolgreiche Verbindungen zu PE1 und PE2 anzeigen.
Es ist am besten, wenn der Operator vor der Bereitstellung des Nexus-Clusters die iDRAC-IP-Adressen beim Organisieren der Hardwaregestelle festlegt. Hier erfahren Sie, wie Sie Server IP-Adressen zuordnen:
Weisen Sie IP-Adressen basierend auf den einzelnen Serverpositionen innerhalb des Racks zu.
Verwenden Sie den vierten /24-Block aus dem für Fabric zugewiesenen Subnetz „/19“.
Beginnen Sie mit der Zuweisung von IP-Adressen vom untersten Server aufwärts in jedem Rack, beginnend mit 0.11.
Weisen Sie im Anschluss dem ersten Server unten im nächsten Rack sequenziell IP-Adressen zu.
Beispiel
Fabric-Bereich: 10.1.0.0–10.1.31.255: Das iDRAC-Subnetz im vierten /24-Block ist 10.1.3.0/24.
Rack
Server
iDRAC-IP-Adresse
Rack 1
Worker 1
10.1.3.11/24
Rack 1
Worker 2
10.1.3.12/24
Rack 1
Worker 3
10.1.3.13/24
Rack 1
Worker 4
10.1.3.14/24
Rack 1
Worker 5
10.1.3.15/24
Rack 1
Worker 6
10.1.3.16/24
Rack 1
Worker 7
10.1.3.17/24
Rack 1
Worker 8
10.1.3.18/24
Rack 1
Controller 1
10.1.3.19/24
Rack 1
Controller 2
10.1.3.20/24
Rack 2
Worker 1
10.1.3.21/24
Rack 2
Worker 2
10.1.3.22/24
Rack 2
Worker 3
10.1.3.23/24
Rack 2
Worker 4
10.1.3.24/24
Rack 2
Worker 5
10.1.3.25/24
Rack 2
Worker 6
10.1.3.26/24
Rack 2
Worker 7
10.1.3.27/24
Rack 2
Worker 8
10.1.3.28/24
Rack 2
Controller 1
10.1.3.29/24
Rack 2
Controller 2
10.1.3.30/24
Rack 3
Worker 1
10.1.3.31/24
Rack 3
Worker 2
10.1.3.32/24
Rack 3
Worker 3
10.1.3.33/24
Rack 3
Worker 4
10.1.3.34/24
Rack 3
Worker 5
10.1.3.35/24
Rack 3
Worker 6
10.1.3.36/24
Rack 3
Worker 7
10.1.3.37/24
Rack 3
Worker 8
10.1.3.38/24
Rack 3
Controller 1
10.1.3.39/24
Rack 3
Controller 2
10.1.3.40/24
Rack 4
Worker 1
10.1.3.41/24
Rack 4
Worker 2
10.1.3.42/24
Rack 4
Worker 3
10.1.3.43/24
Rack 4
Worker 4
10.1.3.44/24
Rack 4
Worker 5
10.1.3.45/24
Rack 4
Worker 6
10.1.3.46/24
Rack 4
Worker 7
10.1.3.47/24
Rack 4
Worker 8
10.1.3.48/24
Rack 4
Controller 1
10.1.3.49/24
Rack 4
Controller 2
10.1.3.50/24
Ein Beispielentwurf von drei lokalen Instanzen desselben NFC/CM-Paars unter Verwendung sequenzieller /19-Netzwerke in einem /16-Block:
Instanz
Fabric-Bereich
iDRAC-Subnetz
Instanz 1
10.1.0.0–10.1.31.255
10.1.3.0/24
Instanz 2
10.1.32.0–10.1.63.255
10.1.35.0/24
Instanz 3
10.1.64.0–10.1.95.255
10.1.67.0/24
Standardsetup für andere installierte Geräte
Alle Netzwerk-Fabric-Geräte (mit Ausnahme des Terminalservers) sind auf den ZTP-Modus festgelegt.
Server verfügen über Standardwerkseinstellungen
Firewallregeln zwischen Azure und Nexus-Cluster
Um Firewallregeln zwischen Azure und dem Nexus-Cluster einzurichten, muss der Operator die angegebenen Ports öffnen. Dadurch wird die ordnungsgemäße Kommunikation und Konnektivität für erforderliche Dienste mit TCP (Transmission Control-Protokoll) und UDP (User Datagram-Protokoll) sichergestellt.
S.-Nr.
Quelle
Destination
Port (TCP/UDP)
Bidirektional
Regelzweck
1
Azure Virtual Network
Cluster
22 TCP
No
Für eine SSH-Verbindung mit Undercloud-Servern aus dem CM-Subnetz
2
Azure Virtual Network
Cluster
443 TCP
No
Für den Zugriff auf iDRAC mit Untercloud-Knoten
3
Azure Virtual Network
Cluster
5900 TCP
No
gNMI
4
Azure Virtual Network
Cluster
6030 TCP
No
gNMI-Zertifikate
5
Azure Virtual Network
Cluster
6443 TCP
No
Für den Zugriff auf einen Untercloud-K8S-Cluster
6
Cluster
Azure Virtual Network
8080 TCP
Ja
Zum Einbinden des ISO-Images in iDRAC, NNF-Runtimeupgrade
7
Cluster
Azure Virtual Network
3128 TCP
No
Proxy zum Herstellen einer Verbindung mit globalen Azure-Endpunkten
8
Cluster
Azure Virtual Network
53 TCP und UDP
No
Domain Name System
9
Cluster
Azure Virtual Network
123 UDP
No
NTP
10
Cluster
Azure Virtual Network
8888 TCP
No
Herstellen einer Verbindung mit dem Cluster-Manager-Webdienst
11
Cluster
Azure Virtual Network
514 TCP und UDP
No
Zum Zugreifen auf Undercloud-Protokolle über den Cluster-Manager
Installieren der CLI-Erweiterungen und Anmelden bei Ihrem Azure-Abonnement
Azure HPC ist eine zweckorientierte Cloudfunktion für HPC- und KI-Workloads, die modernste Prozessoren und InfiniBand-Verbindungen der HPC-Klasse verwendet, um die beste Anwendungsleistung, Skalierbarkeit und den besten Nutzen zu erzielen. Mit Azure HPC können Benutzer Innovationen, Produktivität und geschäftliche Agilität mithilfe einer hochverfügbaren Palette von HPC- und KI-Technologien nutzen, die dynamisch zugeordnet werden können, wenn sich Ihre geschäftlichen und technischen Anforderungen ändern. Bei
Zeigen Sie Ihre Kenntnisse zu Entwurf, Implementierung und Wartung der Azure-Netzwerkinfrastruktur, zum Lastenausgleich für Datenverkehr, zum Netzwerkrouting u. v. m.