Operator Nexus: Voraussetzungen für die Plattform
Betreiber müssen vor der Bereitstellung der Operator Nexus-Plattformsoftware die Voraussetzungen erfüllen. Einige dieser Schritte können längere Zeit in Anspruch nehmen. Eine Bewertung dieser Voraussetzungen kann daher von Vorteil sein.
In nachfolgenden Bereitstellungen von Operator Nexus-Instanzen können Sie zu dem Erstellen des lokalen Network Fabrics und des Clusters springen.
Voraussetzungen für Azure
Wenn Sie Operator Nexus zum ersten Mal oder in einer neuen Region bereitstellen, müssen Sie wie auf der Seite Voraussetzungen für Azure Operator Nexus beschrieben zunächst einen Netzwerk-Fabric Controller und anschließend einen Cluster-Manager erstellen. Darüber hinaus müssen die folgenden Aufgaben ausgeführt werden:
- Richten Sie Benutzer, Richtlinien, Berechtigungen und die rollenbasierte Zugriffssteuerung (Role-Based Access Control, RBAC) ein.
- Richten Sie Ressourcengruppen ein, um Ressourcen, die für die Operator Nexus-Plattform erstellt werden, auf logische Weise zu platzieren und zu gruppieren.
- Richten Sie ExpressRoute-Konnektivität zwischen Ihrem WAN und einer Azure-Region ein.
- Um Microsoft Defender for Endpoint für lokale Bare-Metal-Computer (BMMs) zu aktivieren, müssen Sie vor der Bereitstellung einen Defender for Servers-Plan in Ihrem Operator Nexus-Abonnement ausgewählt haben. Weitere Informationen finden Sie auf der Seite Defender for Cloud-Sicherheit.
Voraussetzungen für die lokale Umgebung
Bei der Bereitstellung einer lokalen Operator Nexus-Instanz in Ihrem Rechenzentrum sind wahrscheinlich verschiedene Teams beteiligt, die eine Vielzahl von Rollen ausführen. Die folgenden Aufgaben müssen genau ausgeführt werden, um eine erfolgreiche Plattformsoftwareinstallation sicherzustellen.
Physische Hardwareeinrichtung
Ein Betreiber, der den Operator Nexus-Dienst nutzen möchte, muss Hardwareressourcen erwerben, installieren, konfigurieren und betreiben. In diesem Abschnitt des Dokuments werden die erforderlichen Komponenten und Bemühungen zum Erwerben und Implementieren der entsprechenden Hardwaresysteme beschrieben. In diesem Abschnitt werden die Materialliste, das Rack-Höhendiagramm und das Verkabelungsdiagramm sowie die erforderlichen Schritte zum Zusammenstellen der Hardware erläutert.
Verwenden der Stückliste (Bill of Materials, BOM)
Um eine nahtlose Betreibererfahrung zu gewährleisten, hat Operator Nexus eine BOM für die für den Dienst erforderliche Hardwareakquisition entwickelt. Diese BOM ist eine umfassende Liste der erforderlichen Komponenten und Mengen, die zur Implementierung der Umgebung für eine erfolgreiche Implementierung und Wartung der lokalen Instanz erforderlich sind. Die BOM ist so strukturiert, dass der Betreiber eine Reihe von Lagerhaltungseinheiten (SKU) erhält, die von Hardwareanbietern bestellt werden können. SKUs werden später im Dokument erläutert.
Verwenden des Höhendiagramms
Das Rack-Höhendiagramm ist ein grafischer Verweis, der veranschaulicht, wie die Server und andere Komponenten in die montierten und konfigurierten Racks passen. Das Rack-Höhendiagramm wird als Teil der allgemeinen Buildanweisungen bereitgestellt. Es hilft Betreibern, alle für den Dienstbetrieb erforderlichen Hardwarekomponenten ordnungsgemäß zu konfigurieren und zu installieren.
Verkabelungsdiagramm
Verkabelungsdiagramme sind grafische Darstellungen der Kabelverbindungen, die für die Bereitstellung von Netzwerkdiensten für Komponenten erforderlich sind, die in den Racks installiert sind. Nach dem Verkabelungsdiagramm wird die ordnungsgemäße Implementierung der verschiedenen Komponenten im Build sichergestellt.
So wird es basierend auf der SKU geordnet
SKU-Definition
Eine SKU ist eine Bestandsverwaltungs- und Nachverfolgungsmethode, die das Gruppieren mehrerer Komponenten in einen einzelnen Kennzeichner ermöglicht. Eine SKU ermöglicht es einem Operator, alle erforderlichen Komponenten mit einer SKU-Nummer zu bestellen. Die SKU beschleunigt die Betreiber- und Lieferanteninteraktion und reduziert gleichzeitig Fehler bei der Bestellung aufgrund komplexer Teilelisten.
Platzieren einer SKU-basierten Bestellung
Operator Nexus hat eine Reihe von SKUs mit Anbietern wie Dell, Pure Storage und Arista erstellt, auf die der Betreiber beim Aufgeben einer Bestellung verweisen kann. So muss ein Betreiber einfach eine Bestellung basierend auf den SKU-Informationen, die von Operator Nexus bereitgestellt werden, an den Anbieter richten, um die richtige Teileliste für den Build zu erhalten.
So erstellen Sie den physischen Hardwarespeicherbedarf
Der physische Hardwarebuild wird über eine Reihe von Schritten ausgeführt, die in diesem Abschnitt beschrieben werden. Es gibt drei erforderliche Schritte vor der Buildausführung. In diesem Abschnitt werden auch Annahmen über die Fähigkeiten der Mitarbeiter des Betreibers zur Ausführung des Builds erörtert.
Bestellen und Erhalt der spezifischen Hardwareinfrastruktur-SKU
Die Bestellung der entsprechenden SKU und die Lieferung der Hardware an den Standort muss vor dem Beginn des Builds erfolgen. Für diesen Schritt sollte ein angemessener Zeitraum gewährt werden. Wir empfehlen dem Betreiber, frühzeitig mit dem Lieferanten der Hardware zu kommunizieren, um Lieferzeitrahmen sicherzustellen und zu verstehen.
Vorbereiten des Standorts
Der Installationsstandort muss in der Lage sein, die Hardwareinfrastruktur in Bezug auf Platz, Energie und Netzwerk zu unterstützen. Die spezifischen Standortanforderungen werden von der für den Standort erworbenen SKU definiert. Dieser Schritt kann nach der Bestellung und vor dem Eingang der SKU ausgeführt werden.
Planen von Ressourcen
Der Buildprozess erfordert mehrere unterschiedliche Mitarbeiter, um den Build durchzuführen, z. B. Ingenieure für die Bereitstellung von Energie, Netzwerkzugriff und Verkabelung und Systemmitarbeiter für die Zusammenzustellung von Racks, Switches und Servern, um nur einige zu nennen. Um sicherzustellen, dass der Build zeitnah durchgeführt wird, empfehlen wir, diese Teammitglieder im Voraus basierend auf dem Lieferungszeitplan einzuplanen.
Annahmen zu Mitarbeiterkompetenzen in Bezug auf Builds
Die Mitarbeiter, die den Build durchführen, sollten Erfahrungen bei der Montage von Systemhardware wie Racks, Switches, PDUs und Servern haben. In den Anweisungen werden die Schritte des Prozesses erläutert, während sie auf Rack-Höhen- und Verkabelungsdiagramme verweisen.
Übersicht über den Buildprozess
Wenn die Standortvorbereitung für die Unterstützung der bestellten SKU abgeschlossen und überprüft ist, erfolgt der Buildvorgang in den folgenden Schritten:
- Montieren Sie die Racks basierend auf den Rack-Höhen der SKU. Spezifische Anweisungen zur Rack-Montage werden vom Rack-Hersteller bereitgestellt.
- Installieren Sie nach der Montage der Racks die Fabric-Geräte in den Racks gemäß Höhendiagramm.
- Verkabeln Sie die Fabric-Geräte, indem Sie die Netzwerkschnittstellen gemäß Kabeldiagramm verbinden.
- Stellen Sie die Server gemäß Rack-Höhendiagramm zusammen und installieren Sie sie.
- Stellen Sie das Speichergerät gemäß Rack-Höhendiagramm zusammen und installieren Sie es.
- Verkabeln Sie die Server- und Speichergeräte, indem Sie die Netzwerkschnittstellen gemäß Kabeldiagramm verbinden.
- Verkabelung der Energieversorgung von jedem Gerät.
- Überprüfen Sie den Build über die Checklisten, die von Operator Nexus und anderen Anbietern bereitgestellt werden.
So überprüfen Sie die physische Hardwareinstallation visuell
Es wird empfohlen, während des Prozesses alle Kabel nach ANSI/TIA 606-Standards oder den Standards des Betreibers zu beschriften. Im Buildprozess sollte auch eine Reversezuordnung für die Verkabelung von einem Switchport zu einer Fernendverbindung erstellt werden. Die Reversezuordnung kann mit dem Kabeldiagramm verglichen werden, um die Installation zu überprüfen.
Terminalserver- und Speicherarray-Setup
Nachdem die physische Installation und Validierung abgeschlossen wurde, werden die nächsten Schritte zum Konfigurieren der Standardeinstellungen durchgeführt, die vor der Installation von Plattformsoftware erforderlich sind.
Einrichten des Terminalservers
Der Terminalserver wurde wie folgt bereitgestellt und konfiguriert:
- Der Terminalserver ist für die Out-of-Band-Verwaltung konfiguriert.
- Anmeldeinformationen für die Authentifizierung wurden eingerichtet.
- Der DHCP-Client ist auf dem Out-of-Band-Verwaltungsport aktiviert
- HTTP-Zugriff ist aktiviert.
- Die Terminalserverschnittstelle ist mit den lokalen Provider-Edge-Routern (PEs) des Betreibers verbunden und mit den IP-Adressen und Anmeldeinformationen konfiguriert
- Auf den Terminalserver kann über das Verwaltungs-VPN (virtuelles privates Netzwerk) zugegriffen werden.
Schritt 1: Einrichten des Hostnamens
Führen Sie die folgenden Schritte aus, um den Hostnamen für Ihren Terminalserver einzurichten:
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:
- Ü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 |
- 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:
- 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"
password="<SUPPORT_PWD>"
username="<SUPPORT_USER>"
END
Parameter:
| Parametername | BESCHREIBUNG |
|---|---|
| SUPPORT_USER | Benutzer „Supportadministrator“ |
| SUPPORT_PWD | Kennwort der Benutzerrolle „Supportadministrator“ |
Hinweis
Stellen Sie sicher, dass Sie diese Parameter durch geeignete Werte ersetzen.
Schritt 5: Hinzufügen der sudo-Unterstützung für Administratorbenutzerkonten
Führen Sie die folgenden Schritte aus, um die sudo-Unterstützung für Administratorbenutzerkonten hinzuzufügen:
- Öffnen Sie die sudo-Konfigurationsdatei:
sudo vi /etc/sudoers.d/opengear
- 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
Pure Storage-Arrays, die vor 2024 erworben wurden, verfügen über Controller der Revision R3, die Rollover-Konsolenkabel verwenden und die folgenden benutzerdefinierten Befehle für die Verbindung mit dem seriellen Anschluss erfordern:
Pure Storage R3-Controller:
ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X1"' <PORT_#> Pure Storage Controller console
Neuere Pure Storage-Appliances und Systeme, die von Pure Storage-Controllern R3 auf R4 aktualisiert wurden, verwenden gerade Durchgangskonsolenkabel mit den aktualisierten Einstellungen unten:
Pure Storage R4-Controller:
ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X2"' <PORT_#> Pure Storage Controller console
Parameter:
| Parametername | Beschreibung |
|---|---|
| PORT_# | Portnummer des Terminalservers |
Mit diesen Befehlen werden die Baudrate und die Pinbelegung für die Verbindung mit der Pure Storage Controller-Konsole festgelegt.
Hinweis
Alle anderen Einstellungen für die Terminalserver-Anschlusskonfiguration sollten gleich bleiben und standardmäßig mit einem geraden RJ45-Durchgangskonsolenkabel funktionieren.
Schritt 10: Überprüfen der Einstellungen
Führen Sie die folgenden Befehle aus, um die Konfigurationseinstellungen zu überprüfen:
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
- Der Operator muss die Speicherarrayhardware gemäß der Stückliste sowie die Rackerhöhung im Aggregation Rack montieren.
- Der Betreiber muss dem Speicherarraytechniker Informationen zur Verfügung stellen, damit dieser die Appliance vor Ort konfigurieren kann.
- 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:
- Für alle Installationen geltende Daten, die der Operator erhält und die dem Speicherarraytechniker zur Verfügung gestellt werden:
- Purity-Codeebene: Informieren Sie sich über die unterstützten Purity-Versionen.
- Abgesicherter Modus: Deaktiviert
- Array-Zeitzone: UTC
- DNS (Domain Name System) Server-IP-Adresse: nicht vom Operator während des Setups festgelegt
- DNS-Domänensuffix: wird 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: 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: Wird während des Setups nicht vom Operator festgelegt
- 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: Wird während des Setups nicht vom Operator festgelegt
- 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: Wird während des Setups nicht vom Operator festgelegt
- Subnetzmaske: 255.255.255.0
- MTU: 1.500
- Bond: Wird während des Setups nicht vom Operator festgelegt
- 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.