Freigeben über


Voraussetzungen für die Operator Nexus-Plattform

Betreiber müssen die Voraussetzungen vor der Bereitstellung der Operator Nexus-Plattformsoftware erfüllen. Einige dieser Schritte können längere Zeit dauern, daher kann eine Überprüfung dieser Voraussetzungen vorteilhaft sein.

In nachfolgenden Bereitstellungen von Operator Nexus-Instanzen können Sie zum Erstellen der lokalen Network Fabric und des Clusters überspringen.

Voraussetzungen für Azure

Wenn Sie Operator Nexus zum ersten Mal oder in einer neuen Region bereitstellen, müssen Sie zuerst einen Network Fabric Controller und dann einen Cluster-Manager erstellen, wie auf der Seite " Azure Operator Nexus Prerequisites " angegeben. Darüber hinaus müssen die folgenden Aufgaben ausgeführt werden:

  • Einrichten von Benutzern, Richtlinien, Berechtigungen und RBAC
  • Richten Sie Ressourcengruppen so ein, dass Ressourcen auf logische Weise platziert und gruppiert werden, die für die Operator Nexus-Plattform erstellt werden.
  • Einrichten der ExpressRoute-Konnektivität von Ihrem WAN zu einer Azure-Region
  • 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 auf der Seite Defender for Cloud Security .

Lokal vor Ort Voraussetzungen

Bei der Bereitstellung der lokalen Instanz von Operator Nexus in Ihrem Rechenzentrum sind wahrscheinlich verschiedene Teams beteiligt, die verschiedene 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 Kauf und Implementieren der entsprechenden Hardwaresysteme beschrieben. In diesem Abschnitt werden die Materialabrechnungen, das Diagramm mit den Gestellhöhen und das Verkabelungsdiagramm sowie die schritte erläutert, die zum Zusammenstellen der Hardware erforderlich sind.

Verwenden der Stückliste (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 Gestellansichtsdiagramm wird als Teil der allgemeinen Build-Anweisungen bereitgestellt. Es hilft den 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. Die Befolgung des Verkabelungsdiagramms stellt die ordnungsgemäße Implementierung der verschiedenen Komponenten im Aufbau sicher.

So wird's geordnet, basierend auf der SKU

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 einzigen SKU-Nummer zu bestellen. Die SKU beschleunigt die Interaktion zwischen Bediener und Lieferant, während die Bestellfehler aufgrund komplexer Teilelisten reduziert werden.

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 verweisen kann, wenn er eine Bestellung abgibt. 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 Hardware-Fußabdruck

Der physische Hardwarebuild wird über eine Reihe von Schritten ausgeführt, die in diesem Abschnitt beschrieben werden. Es gibt drei notwendige 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.

Bestellung und Empfang der spezifischen Hardwareinfrastruktur-SKU

Die Bestellung der entsprechenden SKU und die Lieferung von Hardware an den Standort muss vor Dem Baubeginn erfolgen. Für diesen Schritt sollten angemessene Zeit gewährt werden. Wir empfehlen dem Betreiber, frühzeitig mit dem Lieferanten der Hardware zu kommunizieren, um Lieferzeitrahmen sicherzustellen und zu verstehen.

Websitevorbereitung

Der Installationsstandort kann die Hardwareinfrastruktur aus Sicht von Raum, Energie und Netzwerk unterstützen. Die spezifischen Websiteanforderungen werden von der für die Website erworbenen SKU definiert. Dieser Schritt kann nach der Bestellung und vor dem Eingang der SKU erreicht werden.

Planen von Ressourcen

Der Buildprozess erfordert mehrere unterschiedliche Mitarbeiter, um den Build durchzuführen, z. B. Ingenieure, um Energie, Netzwerkzugriff und Kabel bereitzustellen, Systemmitarbeiter, um die Racks, Switches und Server zusammenzustellen, um einige zu nennen. Um sicherzustellen, dass der Build zeitnah durchgeführt wird, empfehlen wir, diese Teammitglieder im Voraus basierend auf dem Übermittlungszeitplan zu planen.

Annahmen zum Aufbau von Mitarbeiterkompetenzen

Das Personal, das den Build durchführt, sollte erfahren in der Montage von Systemhardware wie Racks, Switches, PDUs und Servern sein. In den anweisungen werden die Schritte des Prozesses erläutert, während sie auf Gestellhöhen und Verkabelungsdiagramme verweisen.

Übersicht über den Buildprozess

Wenn die Standortvorbereitung abgeschlossen und validiert ist, um die bestellte SKU zu unterstützen, erfolgt der Erstellungsprozess in den folgenden Schritten:

  1. Montiert die Racks basierend auf den Gestellhöhen der SKU. Spezifische Anweisungen zur Gestellmontage werden vom Gestellhersteller bereitgestellt.
  2. Installieren Sie nach der Montage der Racks die Fabric-Geräte in den Racks entsprechend dem Höhendiagramm.
  3. Verbinden Sie die Fabric-Geräte, indem Sie die Netzwerkschnittstellen gemäß dem Kabeldiagramm verkabeln.
  4. Stellen Sie die Server gemäß dem Rack-Elevationsdiagramm zusammen und installieren Sie sie.
  5. Einrichten und installieren des Speichergeräts gemäß Rack-Höhendiagramm.
  6. Verkabeln Sie die Server- und Speichergeräte, indem Sie die Netzwerkschnittstellen laut Kabeldiagramm verbinden.
  7. Kabelleistung von jedem Gerät.
  8. Überprüfen/validieren Sie den Build mit den Checklisten, die von Operator Nexus und anderen Anbietern bereitgestellt werden.

So überprüfen Sie die physische Hardwareinstallation visuell

Es wird empfohlen, während des Bauprozesses alle Kabel nach ANSI/TIA 606 Standards oder den Standards des Betreibers zu beschriften. Der Buildprozess sollte auch eine Reversezuordnung für die Verkabelung von einem Switchport zu einer Fernendverbindung erstellen. Die Rückwärtszuordnung kann mit dem Kabeldiagramm verglichen werden, um die Installation zu validieren.

Terminalserver- und Speicherarray-Setup

Nachdem die physische Installation und Validierung abgeschlossen wurde, wurden die nächsten Schritte zum Konfigurieren der Standardeinstellungen durchgeführt, die vor der Installation von Plattformsoftware erforderlich sind.

Einrichten des Terminalservers

Hinweis

Dieses Handbuch wurde mit Opengear Firmware Version 24.11.2 überprüft, das von Version 22.06.0 aktualisiert wurde und mit Nexus Network Fabric-Laufzeitversion 5.0.0 unterstützt wird.

Terminalserver wurde wie folgt bereitgestellt und konfiguriert:

  • Terminalserver ist für die Out-of-Band-Verwaltung konfiguriert.
    • Authentifizierungsanmeldeinformationen wurden eingerichtet
    • DHCP-Client ist für den Out-of-Band-Verwaltungsport aktiviert.
    • HTTP-Zugriff ist aktiviert
  • Die Terminalserverschnittstelle ist mit den Edgeroutern des lokalen Anbieters der Betreiber (PEs) verbunden und mit den IP-Adressen und Zugangsdaten konfiguriert.
  • Der Terminalserver kann über das Verwaltungs-VPN zugegriffen werden.
  • Informationen zum Upgrade des Terminalservers auf Betriebssystem, Version 24.11.2 , finden Sie unter
  • Informationen zum Einrichten von Einzelsitzungs- und Sitzungstimeouts für serielle Konsolen finden Sie unter

Schritt 1: Einrichten des Hostnamens

Führen Sie die folgenden Schritte aus, um den Hostnamen für Ihren Terminalserver einzurichten:

Verwenden Sie den folgenden Befehl in der CLI:

sudo ogcli update system/hostname hostname=\"<TS_HOSTNAME>\"

Parameter:

Parametername Description
TS_HOSTNAME Terminalserver-Hostname

Weitere Informationen finden Sie in der CLI-Referenz .

Schritt 2: Einrichten des Netzwerks

Führen Sie die folgenden Schritte aus, um Netzwerkeinstellungen zu konfigurieren:

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 Description
TS_NET1_IP Terminalserver PE1 mit TS NET1 IP-Adresse
TS_NET1_NETMASK Terminalserver PE1 bis TS NET1 Netzmaske
TS_NET1_GW Terminalserver PE1 zu TS NET1-Gateway
TS_NET2_IP Terminalserver PE2 zu TS NET2 IP
TS_NET2_NETMASK Terminalserver PE2 zu TS NET2 Netmask
TS_NET2_GW Terminalserver PE2 zum TS NET2-Gateway

Hinweis

Stellen Sie sicher, dass Sie diese Parameter durch geeignete Werte ersetzen.

Schritt 3: Löschen der Net3-Schnittstelle (sofern vorhanden)

Führen Sie die folgenden Schritte aus, um die Net3-Schnittstelle zu löschen:

  1. Überprüfen Sie mithilfe des folgenden Befehls, ob auf der physischen Schnittstelle net3 und der Standardadresse IPv4 (statisch) eine Schnittstelle konfiguriert ist:
ogcli get conns
  description="Default IPv4 Static Address"
  name="<TS_NET3_CONN_NAME>"
  physif="net3"

Parameter:

Parametername Description
TS_NET3_CONN_NAME Terminalserver NET3-Verbindungsname
  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 Supportadministratorbenutzers

Führen Sie die folgenden Schritte aus, um den Supportadministratorbenutzer einzurichten:

  1. Führen Sie für jeden Benutzer den folgenden Befehl in der CLI aus:
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 Description
SUPPORT_USER Supportadministratorbenutzer
SUPPORT_PWD Support-Administrator-Benutzerpasswort

Hinweis

Stellen Sie sicher, dass Sie diese Parameter durch geeignete Werte ersetzen.

Schritt 5: Hinzufügen der sudo-Unterstützung für Administratorbenutzer

Führen Sie die folgenden Schritte aus, um die sudo-Unterstützung für Administratorbenutzer hinzuzufügen:

  1. Öffnen Sie die Sudoers-Konfigurationsdatei:
sudo vi /etc/sudoers.d/opengear
  1. Fügen Sie die folgenden Zeilen hinzu, um Sudo-Zugriff zu gewähren:
%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 Mitgliedern der Gruppe "netgrp", jeden Befehl als beliebiger Benutzer auszuführen und Mitgliedern der Gruppe "admin", jeden Befehl als beliebiger Benutzer auszuführen, ohne ein Kennwort zu benötigen.

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

Wenn der Dienst ausgeführt wird, sollte die Ausgabe ähnlich wie folgt angezeigt werden:

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 (ausgeführt) ist, starten Sie den Dienst:

sudo systemctl start lldpd

Aktivieren Sie den Dienst, um beim Neustart automatisch zu 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

Zeitzone auf UTC festlegen:

Wenn die Zeitzone nicht auf UTC festgelegt ist, können Sie sie mithilfe von:

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

Aktuelles Datum/Uhrzeit überprüfen:

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

date

Datum/Uhrzeit korrigieren, wenn falsch:

Wenn Datum und Uhrzeit falsch sind, können Sie diese mithilfe der folgenden Schritte ändern:

ogcli replace system/time
Reading information from stdin. Press Ctrl-D to submit and Ctrl-C to cancel.
time="<CURRENT_DATE_TIME>"

Parameter:

Parametername Description
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 darauf vertrauen.

Schritt 8: Bezeichnen von Terminalserverports (falls fehlt/falsch)

Verwenden Sie zum Bezeichnen von Terminalserverports den folgenden Befehl:

ogcli update port "port-<PORT_#>"  label=\"<NEW_NAME>\" <PORT_#>

Parameter:

Parametername Description
NEW_NAME Portbezeichnungsname
PORT_# Terminalserver-Portnummer

Schritt 9: Für serielle PURE Array-Verbindungen erforderliche Einstellungen

Pure Storage-Arrays, die vor 2024 erworben wurden, sind mit Revision R3-Controllern ausgestattet, die Rollover-Konsolen-Kabel verwenden und die folgenden benutzerdefinierten Befehle für die serielle Portverbindung erfordern:

Reine Speicher-R3-Controller:

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 R3 auf R4 Pure Storage-Controller aktualisiert wurden, verwenden gerade Durchgangskonsolenkabel mit den aktualisierten Einstellungen unten:

Reine Speicher-R4-Controller:

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 Description
PORT_# Terminalserver-Portnummer

Mit diesen Befehlen werden die Baudrate und die Pinbelegung für die Verbindung mit der Pure Storage Controller Konsole festgelegt.

Hinweis

Alle anderen Terminalserver-Portkonfigurationseinstellungen sollten mit einem straight-through RJ45-Konsolenkabel standardmäßig gleich bleiben und funktionieren.

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

Stellen Sie sicher, dass die LLDP-Nachbarn wie erwartet sind und die erfolgreichen Verbindungen mit 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.

Bestimmen, ob SafeMode für Speicherarrays aktiviert werden soll

Reine Speicherarrays unterstützen ein Feature namens SafeMode, das entwickelt wurde, um vor Ransomware-Angriffen und anderen schädlichen Aktivitäten zu schützen. Wenn diese Option aktiviert ist, werden in regelmäßigen Abständen Momentaufnahmen von Volumes erstellt, die nicht vollständig gelöscht oder für einen konfigurierbaren Aufbewahrungszeitraum geändert werden können. Das Aktivieren von SafeMode bietet Schutz vor Datenverlust, verwendet aber auch mehr Speicherkapazität auf dem Array.

Die Operator Nexus-Plattform unterstützt das Aktivieren von SafeMode auf Speicherarrays. Volumes unterliegen dem Schutz, solange die Standardschutzgruppen mindestens einen mit aktivierter SafeMode-Funktion enthalten. Es interagiert jedoch nicht direkt mit den generierten Momentaufnahmen, und Sie müssen mit Ihrem Pure-Supportmitarbeiter zusammenarbeiten, wenn Sie Daten aus einer Momentaufnahme wiederherstellen müssen.

SafeMode ist standardmäßig für reine Speicherarrays über eine Standardschutzgruppe aktiviert. Wenn Sie sie deaktivieren möchten, können Sie dies tun, indem Sie diese Standardschutzgruppe löschen. Wenn Sie SafeMode mit unterschiedlichen Snapshothäufigkeits- oder Aufbewahrungseinstellungen aktivieren möchten, können Sie ihn durch eine neue SafeMode-fähige Schutzgruppe durch Ihre gewünschten Einstellungen ersetzen.

Weitere Informationen zu SafeMode und ihren Auswirkungen finden Sie in der Pure Storage-Dokumentation (Anmeldung erforderlich). Wenden Sie sich an Ihren Pure-Supportmitarbeiter, um weitere Fragen zu SafeMode und seiner Konfiguration zu erhalten.

Einrichten des ersten Speicherarrays

  1. Der Operator muss die Speicherarray-Hardware gemäß der Stückliste und der Rack-Höhe im Aggregationsrack installieren.
  2. Der Betreiber muss dem Speicherarraytechniker Informationen bereitstellen, damit der Speicherarraytechniker vor Ort eintreffen kann, um die Appliance zu konfigurieren.
  3. Erforderliche standortspezifische Daten, die mit dem Speicher-Array-Techniker geteilt werden:
    • Kundenname:
    • Physisches Inspektionsdatum:
    • Seriennummer des Chassis:
    • Speicherarray-Hostname:
    • CLLI-Code (Common Language Location Identifier):
    • Installationsadresse:
    • FIC/Rack/Grid Standort
  4. Daten, die dem Betreiber zur Verfügung gestellt und mit dem Speicherarraytechniker geteilt werden, was für alle Installationen gilt:
    • Reinheitscodestufe: Verweisen auf unterstützte Reinheitsversionen
    • Abgesicherter Modus: Ermitteln, ob SafeMode für Speicherarrays aktiviert werden soll
    • Array-Zeitzone: UTC
    • DNS(Domain Name System) Server-IP-Adresse: nicht vom Operator während des Setups festgelegt
    • DNS-Domänensuffix: während des Setups nicht vom Operator festgelegt
    • NTP (Network Time Protocol) Server-IP-Adresse oder FQDN: während des Setups nicht vom Operator festgelegt
    • Syslog Primary: nicht vom Operator während des Setups festgelegt
    • Syslog Secondary: nicht vom Operator während des Setups festgelegt
    • SMTP-Gateway-IP-Adresse oder FQDN: 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: nicht vom Operator während des Setups festgelegt
    • Proxyserver und Port: während des Setups nicht vom Operator festgelegt
    • Verwaltung: Virtuelle Schnittstelle
      • IP-Adresse: 172.27.255.200
      • Gateway: während des Setups nicht vom Operator festgelegt
      • Subnetzmaske: 255.255.255.0
      • MTU: 1500
      • Bond: nicht vom Operator während des Setups festgelegt
    • Verwaltung: Controller 0
      • IP-Adresse: 172.27.255.254
      • Gateway: während des Setups nicht vom Operator festgelegt
      • Subnetzmaske: 255.255.255.0
      • MTU: 1500
      • Bond: nicht vom Operator während des Setups festgelegt
    • Verwaltung: Controller 1
      • IP-Adresse: 172.27.255.253
      • Gateway: während des Setups nicht vom Operator festgelegt
      • Subnetzmaske: 255.255.255.0
      • MTU: 1500
      • Bond: nicht vom Operator während des Setups festgelegt
    • ct0.eth10: nicht vom Operator während der Einrichtung festgelegt
    • ct0.eth11: nicht vom Operator während der Einrichtung festgelegt
    • ct0.eth18: nicht vom Operator während der Einrichtung festgelegt
    • ct0.eth19: nicht vom Operator während der Einrichtung festgelegt
    • ct1.eth10: nicht vom Operator während der Einrichtung festgelegt
    • ct1.eth11: nicht vom Operator während der Einrichtung festgelegt
    • ct1.eth18: nicht vom Operator während der Einrichtung festgelegt
    • ct1.eth19: nicht vom Operator während der Einrichtung festgelegt
    • Die Anwendung von Pure Tunable:
      • 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";

(Optional) Einrichten des zweiten Speicherarrays

Hinweis

Dieser Abschnitt ist optional. Sie müssen sie nur ausführen, wenn Sie eine Azure Operator Nexus-Instanz mit zwei Speichergeräten bereitstellen. Weitere Informationen, einschließlich Einschränkungen für unterstützte Hardware, finden Sie unter Azure Operator Nexus multiple storage appliances.

  1. Der Operator muss die Speicherarray-Hardware gemäß der Stückliste und der Rack-Höhe im Aggregationsrack installieren.
  2. Der Betreiber muss dem Speicherarraytechniker Informationen bereitstellen, damit der Speicherarraytechniker vor Ort eintreffen kann, um die Appliance zu konfigurieren.
  3. Erforderliche standortspezifische Daten, die mit dem Speicher-Array-Techniker geteilt werden:
    • Kundenname:
    • Physisches Inspektionsdatum:
    • Seriennummer des Chassis:
    • Speicherarray-Hostname:
    • CLLI-Code (Common Language Location Identifier):
    • Installationsadresse:
    • FIC/Rack/Grid Standort
  4. Daten, die dem Betreiber zur Verfügung gestellt und mit dem Speicherarraytechniker geteilt werden, was für alle Installationen gilt:
    • Reinheitscodestufe: Verweisen auf unterstützte Reinheitsversionen
    • Abgesicherter Modus: Ermitteln, ob SafeMode für Speicherarrays aktiviert werden soll
    • Array-Zeitzone: UTC
    • DNS(Domain Name System) Server-IP-Adresse: nicht vom Operator während des Setups festgelegt
    • DNS-Domänensuffix: während des Setups nicht vom Operator festgelegt
    • NTP (Network Time Protocol) Server-IP-Adresse oder FQDN: während des Setups nicht vom Operator festgelegt
    • Syslog Primary: nicht vom Operator während des Setups festgelegt
    • Syslog Secondary: nicht vom Operator während des Setups festgelegt
    • SMTP-Gateway-IP-Adresse oder FQDN: 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: nicht vom Operator während des Setups festgelegt
    • Proxyserver und Port: während des Setups nicht vom Operator festgelegt
    • Verwaltung: Virtuelle Schnittstelle
      • IP-Adresse: 172.27.255.201
      • Gateway: während des Setups nicht vom Operator festgelegt
      • Subnetzmaske: 255.255.255.0
      • MTU: 1500
      • Bond: nicht vom Operator während des Setups festgelegt
    • Verwaltung: Controller 0
      • IP-Adresse: 172.27.255.251
      • Gateway: während des Setups nicht vom Operator festgelegt
      • Subnetzmaske: 255.255.255.0
      • MTU: 1500
      • Bond: nicht vom Operator während des Setups festgelegt
    • Verwaltung: Controller 1
      • IP-Adresse: 172.27.255.252
      • Gateway: während des Setups nicht vom Operator festgelegt
      • Subnetzmaske: 255.255.255.0
      • MTU: 1500
      • Bond: nicht vom Operator während des Setups festgelegt
    • ct0.eth10: nicht vom Operator während der Einrichtung festgelegt
    • ct0.eth11: nicht vom Operator während der Einrichtung festgelegt
    • ct0.eth18: nicht vom Operator während der Einrichtung festgelegt
    • ct0.eth19: nicht vom Operator während der Einrichtung festgelegt
    • ct1.eth10: nicht vom Operator während der Einrichtung festgelegt
    • ct1.eth11: nicht vom Operator während der Einrichtung festgelegt
    • ct1.eth18: nicht vom Operator während der Einrichtung festgelegt
    • ct1.eth19: nicht vom Operator während der Einrichtung festgelegt
    • Die Anwendung von Pure Tunable:
      • 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

Vor der Einrichtung des Nexus Clusters ist es am besten, wenn der Bediener die iDRAC-IPs beim Organisieren der Racks einstellt. Hier erfahren Sie, wie Sie Server IPs zuordnen:

  • Weisen Sie IPs basierend auf der Position jedes Servers innerhalb des Racks zu.
  • Verwenden Sie den vierten /24-Block aus dem für Fabric zugewiesenen Subnetz "/19".
  • Beginnen Sie mit dem Zuweisen von IPs vom unteren Server nach oben in jedem Rack, beginnend mit 0,11.
  • Weisen Sie IPs weiterhin sequenziert dem ersten Server am unteren Rand des nächsten Racks zu.

Example

Fabric range: 10.1.0.0-10.1.31.255 – iDRAC Subnet beim vierten /24 ist 10.1.3.0/24.

Rack Server iDRAC IP
Rack 1 Arbeiter 1 10.1.3.11/24
Rack 1 Arbeiter 2 10.1.3.12/24
Rack 1 Arbeiter 3 10.1.3.13/24
Rack 1 Arbeit 4 10.1.3.14/24
Gestell 1 Mitarbeiter 5 10.1.3.15/24
Rack 1 Arbeit 6 10.1.3.16/24
Rack 1 Arbeiter 7 10.1.3.17/24
Rack 1 Arbeit 8 10.1.3.18/24
Rack 1 Steuergerät 1 10.1.3.19/24
Rack 1 Controller 2 10.1.3.20/24
Rack 2 Arbeiter 1 10.1.3.21/24
Rack 2 Arbeiter 2 10.1.3.22/24
Rack 2 Arbeiter 3 10.1.3.23/24
Rack 2 Arbeit 4 10.1.3.24/24
Rack 2 Mitarbeiter 5 10.1.3.25/24
Rack 2 Arbeit 6 10.1.3.26/24
Rack 2 Arbeiter 7 10.1.3.27/24
Rack 2 Arbeit 8 10.1.3.28/24
Rack 2 Steuergerät 1 10.1.3.29/24
Rack 2 Controller 2 10.1.3.30/24
Rack 3 Arbeiter 1 10.1.3.31/24
Gestell 3 Arbeiter 2 10.1.3.32/24
Rack 3 Arbeiter 3 10.1.3.33/24
Rack 3 Arbeit 4 10.1.3.34/24
Rack 3 Mitarbeiter 5 10.1.3.35/24
Rack 3 Arbeit 6 10.1.3.36/24
Rack 3 Arbeiter 7 10.1.3.37/24
Rack 3 Arbeit 8 10.1.3.38/24
Rack 3 Steuergerät 1 10.1.3.39/24
Gestell 3 Controller 2 10.1.3.40/24
Rack 4 Arbeiter 1 10.1.3.41/24
Rack 4 Arbeiter 2 10.1.3.42/24
Rack 4 Arbeiter 3 10.1.3.43/24
Rack 4 Arbeit 4 10.1.3.44/24
Rack 4 Mitarbeiter 5 10.1.3.45/24
Rack 4 Arbeit 6 10.1.3.46/24
Rack 4 Arbeiter 7 10.1.3.47/24
Rack 4 Arbeit 8 10.1.3.48/24
Rack 4 Steuergerät 1 10.1.3.49/24
Rack 4 Controller 2 10.1.3.50/24

Ein Beispielentwurf von drei lokalen Instanzen aus dem gleichen NFC/CM-Paar unter Verwendung sequenzieller /19-Netzwerke in einem /16:

Instance Stoffsortiment 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 weisen standardmäßige Factoryeinstellungen auf, einschließlich der minimalen BIOS-Einstellungen.

Als Best Practice müssen die folgenden BIOS- und Firmwareversionen vor der Bereitstellung auf den Servern installiert werden, basierend auf der ausgewählten Laufzeitversion und dem BOM. Zur Referenz ist Version N die neueste verfügbare Laufzeitversion. N-1 und N-2 sind die vorherigen unterstützten Laufzeitversionen.

Nexus Cluster-Laufzeitversion N

BOM 1.7.3
Komponente Version
BIOS 1.18.1
Speicher-Array-Controller (PERC H755) 52.30.0-6115
iDRAC 7.20.30.55
Nicht-Expander Storage Backplane Passive SEP Firmware (15G Ohne Expander) 7.10
CPLD 1.1.1
Mellanox ConnectX-6 DX-Adapter 22.41.10.00
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 23.21.6
BOM 2.0.0
Komponente Version
BIOS 2.7.5
Speicher-Array-Controller (PERC H755) 52.30.0-6115
iDRAC 7.20.30.55
SAS Expander Backplane Firmware (R760) 1.61
Nicht erweiterbarer Storage-Backplane-Firmware (R660) 7.10
CPLD 1.2.6
Mellanox ConnectX-6 DX-Adapter 22.41.10.00
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 23.21.6

Nexus Cluster Laufzeitversion N-1

BOM 1.7.3
Komponente Version
BIOS 1.17.2
Speicher-Array-Controller (PERC H755) 52.26.0-5179
iDRAC 7.20.30.00
Nicht-Expander Storage Backplane Passive SEP Firmware (15G Ohne Expander) 7.10
CPLD 1.1.1
Mellanox ConnectX-6 DX-Adapter 22.41.10.00
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 23.21.6
BOM 2.0.0
Komponente Version
BIOS 2.6.3
Speicher-Array-Controller (PERC H755) 52.26.0-5179
iDRAC 7.20.30.00
SAS Expander Backplane Firmware (R760) 1.61
Nicht erweiterbarer Storage-Backplane-Firmware (R660) 7.10
CPLD 1.2.6
Mellanox ConnectX-6 DX-Adapter 22.41.10.00
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 23.21.6

Nexus Cluster Laufzeitversion N-2

BOM 1.7.3
Komponente Version
BIOS 1.15.2
Speicher-Array-Controller (PERC H755) 52.26.0-5179
iDRAC 7.10.90.00
Nicht-Expander Storage Backplane Passive SEP Firmware (15G Ohne Expander) 7.10
CPLD 1.1.1
Mellanox ConnectX-6 DX-Adapter 22.41.10.00
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 22.91.5
BOM 2.0.0
Komponente Version
BIOS 2.4.4
Speicher-Array-Controller (PERC H755) 52.26.0-5179
iDRAC 7.10.90.00
SAS Expander Backplane Firmware (R760) 1.61
Nicht erweiterbarer Storage-Backplane-Firmware (R660) 7.10
CPLD 1.2.6
Mellanox ConnectX-6 DX-Adapter 22.41.10.00
NVIDIA ConnectX-6 Lx 2x 25G SFP28 26.41.10.00
Broadcom 5720 Quad Port 1GbE BASE-T Adapter 22.91.5

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 Protocol) und UDP (User Datagram Protocol) sichergestellt.

S.No Quelle Bestimmungsort Port (TCP/UDP) Bidirektional Regelzweck
1 Virtuelles Azure-Netzwerk Cluster 22 TCP Nein Für SSH-Verbindungen zu Untercloud-Servern aus dem CM-Subnetz,
2 Virtuelles Azure-Netzwerk Cluster 443 TCP Nein So greifen Sie auf Untercloudknoten iDRAC zu
3 Virtuelles Azure-Netzwerk Cluster 5900 TCP Nein Gnmi
4 Virtuelles Azure-Netzwerk Cluster 6030 TCP Nein gNMI-Zertifikate
5 Virtuelles Azure-Netzwerk Cluster 6443 TCP Nein So greifen Sie auf undercloud K8S-Cluster zu
6 Cluster Virtuelles Azure-Netzwerk 8080 TCP Yes Für das Mounten eines ISO-Images in iDRAC im Rahmen eines NNF-Laufzeit-Upgrades
7 Cluster Virtuelles Azure-Netzwerk 3128 TCP Nein Proxy zum Herstellen einer Verbindung mit globalen Azure-Endpunkten
8 Cluster Virtuelles Azure-Netzwerk 53 TCP und UDP Nein DNS
9 Cluster Virtuelles Azure-Netzwerk 123 UDP Nein NTP
10 Cluster Virtuelles Azure-Netzwerk 8888 TCP Nein Herstellen einer Verbindung mit Cluster-Manager-Webdienst
11 Cluster Virtuelles Azure-Netzwerk 514 TCP und UDP Nein So greifen Sie über den Cluster-Manager auf Undercloud-Logs zu.

Installieren von CLI-Erweiterungen und Anmelden bei Ihrem Azure-Abonnement

Installieren Sie die neueste Version der erforderlichen CLI-Erweiterungen.

Azure-Abonnement-Anmeldung

  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.