Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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:
- Montiert die Racks basierend auf den Gestellhöhen der SKU. Spezifische Anweisungen zur Gestellmontage werden vom Gestellhersteller bereitgestellt.
- Installieren Sie nach der Montage der Racks die Fabric-Geräte in den Racks entsprechend dem Höhendiagramm.
- Verbinden Sie die Fabric-Geräte, indem Sie die Netzwerkschnittstellen gemäß dem Kabeldiagramm verkabeln.
- Stellen Sie die Server gemäß dem Rack-Elevationsdiagramm zusammen und installieren Sie sie.
- Einrichten und installieren des Speichergeräts gemäß Rack-Höhendiagramm.
- Verkabeln Sie die Server- und Speichergeräte, indem Sie die Netzwerkschnittstellen laut Kabeldiagramm verbinden.
- Kabelleistung von jedem Gerät.
- Ü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:
- Ü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 |
- 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:
- 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:
- Öffnen Sie die Sudoers-Konfigurationsdatei:
sudo vi /etc/sudoers.d/opengear
- 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
- Der Operator muss die Speicherarray-Hardware gemäß der Stückliste und der Rack-Höhe im Aggregationsrack installieren.
- Der Betreiber muss dem Speicherarraytechniker Informationen bereitstellen, damit der Speicherarraytechniker vor Ort eintreffen kann, um die Appliance zu konfigurieren.
- 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
- 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.
- Der Operator muss die Speicherarray-Hardware gemäß der Stückliste und der Rack-Höhe im Aggregationsrack installieren.
- Der Betreiber muss dem Speicherarraytechniker Informationen bereitstellen, damit der Speicherarraytechniker vor Ort eintreffen kann, um die Appliance zu konfigurieren.
- 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
- 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
ZTPModus festgelegt. - Server weisen standardmäßige Factoryeinstellungen auf, einschließlich der minimalen BIOS-Einstellungen.
Minimale empfohlene BIOS- und Firmwareversionen für die Nexus Cluster-Laufzeitumgebung
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.