Share via

Operator Nexus: Voraussetzungen für die Plattform

  • Artikel

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 hier 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 hier.

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:

  1. Montieren Sie die Racks basierend auf den Rack-Höhen der SKU. Spezifische Anweisungen zur Rack-Montage werden vom Rack-Hersteller bereitgestellt.
  2. Installieren Sie nach der Montage der Racks die Fabric-Geräte in den Racks gemäß Höhendiagramm.
  3. Verkabeln Sie die Fabric-Geräte, indem Sie die Netzwerkschnittstellen gemäß Kabeldiagramm verbinden.
  4. Stellen Sie die Server gemäß Rack-Höhendiagramm zusammen und installieren Sie sie.
  5. Stellen Sie das Speichergerät gemäß Rack-Höhendiagramm zusammen und installieren Sie es.
  6. Verkabeln Sie die Server- und Speichergeräte, indem Sie die Netzwerkschnittstellen gemäß Kabeldiagramm verbinden.
  7. Verkabelung der Energieversorgung von jedem Gerät.
  8. Ü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:

Verwenden Sie in der CLI den folgenden Befehl:

sudo ogcli update system/hostname hostname=\"$TS_HOSTNAME\"

Parameter:

Parametername BESCHREIBUNG
TS_HOSTNAME Hostname des Terminalservers

Weitere Details finden Sie in der CLI-Referenz.

Schritt 2: Einrichten des Netzwerks

Zum Konfigurieren der Netzwerkeinstellungen führen Sie diese Schritte aus:

Führen Sie die folgenden Befehle in der CLI aus:

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:

  1. Überprüfen Sie mit dem folgenden Befehl, ob eine Schnittstelle auf der physischen Schnittstelle net3 und „Standard-IPv4 Static Address“ konfiguriert ist:
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
  1. Entfernen Sie die Schnittstelle, falls vorhanden:
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:

  1. Führen Sie für jedes Benutzerkonto den folgenden Befehl in der CLI aus:
ogcli create user << 'END'
description="Support Admin User"
enabled=true
groups[0]="admin"
groups[1]="netgrp"
hashed_password="$HASHED_SUPPORT_PWD"
username="$SUPPORT_USER"
END

Parameter:

Parametername BESCHREIBUNG
SUPPORT_USER Benutzer „Supportadministrator“
HASHED_SUPPORT_PWD Codiertes Kennwort des Benutzers „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:

  1. Öffnen Sie die sudo-Konfigurationsdatei:
sudo vi /etc/sudoers.d/opengear
  1. Fügen Sie die folgenden Zeilen hinzu, um sudo-Zugriff zuzuweisen:
%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:

sudo systemctl status lldpd

Sie sollten eine ähnliche Ausgabe wie die folgende erhalten, wenn der Dienst ausgeführt wird:

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:

sudo systemctl start lldpd

Lassen Sie den Dienst beim Neustart starten:

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:

ogcli get system/timezone

Festlegen der Zeitzone auf UTC:

Wenn die Zeitzone nicht auf UTC festgelegt ist, können Sie sie wie folgt festlegen:

ogcli update system/timezone timezone=\"UTC\"

Überprüfen des aktuelles Datums/der aktuellen Zeit:

Überprüfen Sie das aktuelle Datum und die Uhrzeit:

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:

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:

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

Verwenden Sie zum Konfigurieren von seriellen PURE Array-Verbindungen die folgenden Befehle:

ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X1"' <PORT_#>	Pure Storage Controller console

Parameter:

Parametername Beschreibung
PORT_# Portnummer des Terminalservers

Mit diesen Befehlen wird die Baudrate und das Anheften für die Verbindung mit der Pure Storage Controller-Konsole festgelegt.

Schritt 10: Überprüfen der Einstellungen

Führen Sie die folgenden Befehle aus, um die Konfigurationseinstellungen zu überprüfen:

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.

Beispielausgabe für LLDP-Nachbarn:

-------------------------------------------------------------------------------
LLDP neighbors:
-------------------------------------------------------------------------------
Interface:    net2, via: LLDP, RID: 2, Time: 0 day, 20:28:36
  Chassis:     
    ChassisID:    mac 12:00:00:00:00:85
    SysName:      austx502xh1.els-an.att.net
    SysDescr:     7.7.2, S9700-53DX-R8
    Capability:   Router, on
  Port:         
    PortID:       ifname TenGigE0/0/0/0/3
    PortDescr:    GE10_Bundle-Ether83_austx4511ts1_net2_net2_CircuitID__austxm1-AUSTX45_[CBB][MCGW][AODS]
    TTL:          120
-------------------------------------------------------------------------------
Interface:    net1, via: LLDP, RID: 1, Time: 0 day, 20:28:36
  Chassis:     
    ChassisID:    mac 12:00:00:00:00:05
    SysName:      austx501xh1.els-an.att.net
    SysDescr:     7.7.2, S9700-53DX-R8
    Capability:   Router, on
  Port:         
    PortID:       ifname TenGigE0/0/0/0/3
    PortDescr:    GE10_Bundle-Ether83_austx4511ts1_net1_net1_CircuitID__austxm1-AUSTX45_[CBB][MCGW][AODS]
    TTL:          120
-------------------------------------------------------------------------------

Hinweis

Stellen Sie sicher, dass die Ausgabe Ihren Erwartungen entspricht und dass alle Konfigurationen korrekt sind.

Einrichten des Speicherarrays

  1. Der Operator muss die Speicherarrayhardware gemäß der Stückliste sowie die Rackerhöhung im Aggregation Rack montieren.
  2. Der Betreiber muss dem Speicherarraytechniker Informationen zur Verfügung stellen, damit dieser die Appliance vor Ort konfigurieren kann.
  3. Folgende standortspezifische Daten müssen dem Speicherarraytechniker zur Verfügung gestellt werden:
    • Kundenname:
    • Datum der physischen Inspektion:
    • Seriennummer des Chassis:
    • Hostname des Speicherarrays:
    • CLLI-Code (Common Language Location Identifier):
    • Installationsadresse:
    • FIC/Rack/Stapelposition:
  4. Für alle Installationen geltende Daten, die der Operator erhält und die dem Speicherarraytechniker zur Verfügung gestellt werden:
    • Purity-Codeebene: 6.5.1
    • Abgesicherter Modus: Deaktiviert
    • Zeitzone des Arrays: UTC
    • IP-Adresse des DNS-Servers (Domain Name System): 172.27.255.201
    • DNS-Domänensuffix: wird während des Setups nicht vom Operator festgelegt
    • IP-Adresse des NTP-Servers (Network Time Protocol, Netzwerkzeitprotokoll) oder FQDN: 172.27.255.212
    • Syslog primär: 172.27.255.210
    • Syslog sekundär: 172.27.255.211
    • SMTP-Gateway-IP-Adresse oder FQDN: Werden während des Setups nicht vom Operator festgelegt
    • Domänenname des E-Mail-Absenders: Domänenname des Absenders der E-Mail (example.com)
    • Zu benachrichtigende E-Mail-Adressen: Werden während der Einrichtung nicht vom Betreiber festgelegt
    • Proxyserver und Port: Werden während des Setups nicht vom Operator festgelegt
    • Verwaltung: Virtuelle Schnittstelle
      • IP-Adresse: 172.27.255.200
      • Gateway: 172.27.255.1
      • Subnetzmaske: 255.255.255.0
      • MTU: 1.500
      • Bond: Wird während des Setups nicht vom Operator festgelegt
    • Verwaltung: Controller 0
      • IP-Adresse: 172.27.255.254
      • Gateway: 172.27.255.1
      • Subnetzmaske: 255.255.255.0
      • MTU: 1.500
      • Bond: Wird während des Setups nicht vom Operator festgelegt
    • Verwaltung: Controller 1
      • IP-Adresse: 172.27.255.253
      • Gateway: 172.27.255.1
      • Subnetzmaske: 255.255.255.0
      • MTU: 1.500
      • Bond: Wird während des Setups nicht vom Operator festgelegt
    • VLAN-Nummer/Präfix: 43
    • ct0.eth10: Wird während des Setups nicht vom Operator festgelegt
    • ct0.eth11: Wird während des Setups nicht vom Operator festgelegt
    • ct0.eth18: Wird während des Setups nicht vom Operator festgelegt
    • ct0.eth19: Wird während des Setups nicht vom Operator festgelegt
    • ct1.eth10: Wird während des Setups nicht vom Operator festgelegt
    • ct1.eth11: Wird während des Setups nicht vom Operator festgelegt
    • ct1.eth18: Wird während des Setups nicht vom Operator festgelegt
    • ct1.eth19: Wird während des Setups nicht vom Operator festgelegt
    • Anzuwendende reine Optimierung:
      • puretune -set PS_ENFORCE_IO_ORDERING 1 "PURE-209441";
      • puretune -set PS_STALE_IO_THRESH_SEC 4 "PURE-209441";
      • puretune -set PS_LANDLORD_QUORUM_LOSS_TIME_LIMIT_MS 0 "PURE-209441";
      • puretune -set PS_RDMA_STALE_OP_THRESH_MS 5000 "PURE-209441";
      • puretune -set PS_BDRV_REQ_MAXBUFS 128 "PURE-209441";

iDRAC-IP-Zuweisung

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

Installieren Sie die aktuelle Version der erforderlichen CLI-Erweiterungen.

Azure-Abonnementanmeldung

  az login
  az account set --subscription $SUBSCRIPTION_ID
  az account show

Hinweis

Das Konto muss über Berechtigungen zum Lesen/Schreiben/Veröffentlichen im Abonnement verfügen.