Nota
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare ad accedere o modificare le directory.
L'accesso a questa pagina richiede l'autorizzazione. È possibile provare a modificare le directory.
Gli operatori devono completare i prerequisiti prima della distribuzione del software della piattaforma Operatore Nexus. Alcuni di questi passaggi possono richiedere molto tempo, pertanto può essere utile consultare questi prerequisiti.
Nelle distribuzioni successive delle istanze di Operatore Nexus è possibile passare alla creazione di Network Fabric locale e del cluster.
Prerequisiti di Azure
Quando si distribuisce Operator Nexus per la prima volta o in una nuova area, è prima necessario creare un controller di infrastruttura di rete e quindi un Cluster Manager come specificato nella pagina Dei prerequisiti di Nexus dell'operatore di Azure. Inoltre, è necessario eseguire le attività seguenti:
- Configurare utenti, politiche, permessi e RBAC
- Configurare i gruppi di risorse per inserire e raggruppare in modo logico le risorse che verranno create per la piattaforma Operatore Nexus.
- Stabilire la connettività ExpressRoute dalla rete WAN a un'area di Azure
- Per abilitare Microsoft Defender per endpoint per computer bare metal locali (BMM), è necessario aver selezionato un piano Defender per server nella sottoscrizione Operatore Nexus prima della distribuzione. Ulteriori informazioni sono disponibili sulla pagina Defender for Cloud Security.
Informazioni sui prerequisiti locali
Quando si distribuisce l'istanza locale di Operatore Nexus nel data center, è probabile che vari team eseguano diversi ruoli. Per garantire un'installazione corretta del software della piattaforma, è necessario eseguire le attività seguenti in modo accurato.
Configurazione hardware fisico
Un operatore che vuole sfruttare i vantaggi del servizio Operatore Nexus deve acquistare, installare, configurare e gestire risorse hardware. Questa sezione del documento descrive i componenti e gli sforzi necessari per acquistare e implementare i sistemi hardware appropriati. Questa sezione illustra la distinta base, il diagramma di elevazione dei rack e il diagramma di cablaggio, così come i passaggi necessari per assemblare l'hardware.
Utilizzo della distinta base
Per garantire un'esperienza operatore fluida, Operator Nexus ha sviluppato una distinta base per l'acquisizione dell’hardware necessario per il servizio. Questa distinta base è un elenco completo dei componenti e delle quantità necessarie per implementare l'ambiente per un'implementazione e manutenzione di successo dell'istanza locale. La distinta base è strutturata per fornire all'operatore una serie di unità di stock keeping (SKU) che possono essere ordinate ai fornitori di hardware. Gli SKU vengono descritti in seguito nel documento.
Uso del diagramma di elevazione
Il diagramma di elevazione del rack è un riferimento grafico che illustra il modo in cui i server e gli altri componenti si adattano ai rack assemblati e configurati. Il diagramma di elevazione del rack viene fornito come parte delle istruzioni generali di compilazione. Aiuterà gli operatori a configurare e installare correttamente tutti i componenti hardware necessari per il funzionamento del servizio.
Diagramma di cablaggio
I diagrammi di cablaggio sono rappresentazioni grafiche delle connessioni via cavo necessarie per fornire servizi di rete ai componenti installati all'interno dei rack. Seguire il diagramma di cablaggio garantisce un'implementazione corretta dei vari componenti nella compilazione.
Come ordinare in base allo SKU
Definizione di SKU
Uno SKU è un metodo di gestione e rilevamento dell'inventario che consente di raggruppare più componenti in un singolo indicatore. Uno SKU consente a un operatore di ordinare tutti i componenti necessari specificando un numero di SKU. Lo SKU accelera l'interazione dell'operatore e del fornitore riducendo gli errori negli ordini dovuti a elenchi di parti complessi.
Inserimento di un ordine basato su SKU
Operator Nexus ha creato una serie di SKU con fornitori come Dell, Pure Storage e Arista che l'operatore può fare riferimento quando effettua un ordine. Pertanto, l’operatore deve semplicemente inserire un ordine al fornitore in base alle informazioni sullo SKU fornite da Operatore Nexus per ricevere l'elenco delle parti corrette per l'assemblaggio.
Come creare il footprint hardware fisico
La costruzione hardware fisica viene eseguita tramite una serie di passaggi, che verranno descritti in dettaglio in questa sezione. Prima dell'esecuzione della costruzione sono necessari tre passaggi preliminari. Questa sezione illustra anche i presupposti relativi alle competenze necessarie degli operatori perché possano occuparsi della costruzione.
Ordine e ricezione dello specifico SKU dell'infrastruttura hardware
L'ordine dello SKU appropriato e la consegna dell'hardware al sito devono essere eseguiti prima dell'inizio della costruzione. Per questo passaggio dovrebbe essere consentito un tempo adeguato. È consigliabile che l'operatore si metta in contatto con il fornitore dell'hardware all'inizio del processo per garantire e comprendere le tempistiche di consegna.
Operazioni preliminari
Il sito di installazione può supportare l'infrastruttura hardware dal punto di vista di spazio, alimentazione e rete. I requisiti specifici del sito verranno definiti dallo SKU acquistato per il sito. Questo passaggio può essere eseguito dopo l'invio dell'ordine e prima della ricezione dello SKU.
Pianificazione delle risorse
Il processo di costruzione coinvolge diverse figure, ad esempio ingegneri per fornire alimentazione, accesso alla rete e cablaggio, sistemisti per assemblare i rack, i commutatori e i server, solo per citarne alcuni. Per garantire che la costruzione venga eseguita entro i tempi previsti, è consigliabile organizzare questi membri del team in anticipo, in base alla programmazione della consegna.
Presupposti delle competenze del personale di costruzione
Il personale che si occupa della costruzione deve essere esperto nell'assemblaggio di hardware di sistemi, ad esempio rack, commutatori, PDU e server. Le istruzioni fornite illustrano i passaggi del processo, facendo riferimento ai diagrammi di elevazione e cablaggio dei rack.
Panoramica del processo di costruzione
Se la preparazione del sito è stata completata e convalidata per supportare lo SKU ordinato, il processo di compilazione viene eseguito nei passaggi seguenti:
- Assemblare i rack in base alle elevazioni rack dello SKU. Le istruzioni specifiche per l'assemblaggio rack verranno fornite dal produttore del rack.
- Dopo l'assemblaggio dei rack, installare i dispositivi Fabric nei rack in base al diagramma di elevazione.
- Collegare i dispositivi di infrastruttura collegando le interfacce di rete in base al diagramma di cablaggio.
- Assemblare e installare i server in base al diagramma di elevazione rack.
- Assemblare e installare il dispositivo di archiviazione in base al diagramma di elevazione rack.
- Collegare il server e i dispositivi di archiviazione connettendo le interfacce di rete in base al diagramma di cablaggio.
- Alimentazione via cavo di ogni dispositivo.
- Controllare/verificare la costruzione tramite gli elenchi di controllo forniti da Operatore Nexus e dagli altri fornitori.
Come controllare visivamente l'installazione dell’hardware fisico
È consigliabile etichettare tutti i cavi seguendo gli standard ANSI/TIA 606 o gli standard dell'operatore, durante il processo di costruzione. Il processo di costruzione deve creare anche il mapping inverso per il cablaggio da una porta switch a una connessione con estremità lontana. Il mapping inverso può essere comparato al diagramma di cablaggio per convalidare l'installazione.
Installazione dell'array di archiviazione e del Terminal Server
Ora che l'installazione fisica e la convalida sono state completate, i passaggi successivi comportano la configurazione delle impostazioni predefinite necessarie prima dell'installazione del software della piattaforma.
Configurare il Terminal Server
Nota
Questa guida è stata convalidata con il firmware Opengear versione 24.11.2, aggiornata dalla versione 22.06.0 ed è supportata con il runtime di Nexus Network Fabric versione 5.0.0.
Il Terminal Server è stato distribuito e configurato come segue:
- Il Terminal Server è configurato per la gestione fuori banda
- Le credenziali di autenticazione sono state configurate
- Il client DHCP è abilitato sulla porta di gestione fuori banda
- L'accesso HTTP è abilitato
- L'interfaccia del Terminal Server è collegata ai router Provider Edge locali degli operatori e configurata con gli indirizzi IP e le credenziali.
- Il Terminal Server è accessibile dalla VPN di gestione
- Per aggiornare il server terminal alla versione 24.11.2 del sistema operativo , vedere
- Per configurare una sessione singola e il timeout della sessione per la console seriale , fare riferimento a
Passaggio 1: Configurazione del nome host
Per configurare il nome host del Terminal Server, seguire questa procedura:
Usare il comando seguente nell'interfaccia della riga di comando:
sudo ogcli update system/hostname hostname=\"<TS_HOSTNAME>\"
Parametri:
| Nome parametro | Descrizione |
|---|---|
| TS_HOSTNAME | Nome host del Terminal Server |
Vedere Riferimento CLI per ulteriori dettagli.
Passaggio 2: Configurazione della rete
Per configurare le impostazioni di rete, seguire questa procedura:
Eseguire i comandi seguenti nell'interfaccia della riga di comando:
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
Parametri:
| Nome parametro | Descrizione |
|---|---|
| TS_NET1_IP | Da PE1 all'indirizzo IP del server terminal TS NET1 |
| TS_NET1_NETMASK | Pe1 da Terminal Server a TS NET1 netmask |
| TS_NET1_GW | Gateway del server terminale da PE1 a TS NET1 |
| TS_NET2_IP | Da server terminale PE2 a TS NET2 IP |
| TS_NET2_NETMASK | Server di terminale PE2 alla maschera di rete TS NET2 |
| TS_NET2_GW | Gateway da PE2 a TS NET2 del server terminal |
Nota
Assicurarsi di sostituire questi parametri con i valori appropriati.
Passaggio 3: Cancellazione dell'interfaccia net3 (se esistente)
Per cancellare l'interfaccia net3, seguire questa procedura:
- Verificare la presenza di qualsiasi interfaccia configurata nell'interfaccia fisica net3 e "Indirizzo statico IPv4 predefinito" usando il comando seguente:
ogcli get conns
description="Default IPv4 Static Address"
name="<TS_NET3_CONN_NAME>"
physif="net3"
Parametri:
| Nome parametro | Descrizione |
|---|---|
| TS_NET3_CONN_NAME | Nome connessione NET3 Terminal Server |
- Rimuovere l'interfaccia, se esistente:
ogcli delete conn "<TS_NET3_CONN_NAME>"
Nota
Assicurarsi di sostituire questi parametri con i valori appropriati.
Passaggio 4: Configurazione dell'utente amministratore del supporto
Per configurare l'utente amministratore del supporto, seguire questa procedura:
- Per ogni utente, eseguire il comando seguente nell'interfaccia della riga di comando:
ogcli create user << 'END'
description="Support Admin User"
enabled=true
groups[0]="admin"
groups[1]="netgrp"
password="<SUPPORT_PWD>"
username="<SUPPORT_USER>"
END
Parametri:
| Nome parametro | Descrizione |
|---|---|
| SUPPORT_USER | Utente amministratore del supporto |
| SUPPORT_PWD | Password dell'utente amministratore del supporto |
Nota
Assicurarsi di sostituire questi parametri con i valori appropriati.
Passaggio 5: Aggiunta del supporto sudo per gli utenti amministratori
Per aggiungere il supporto sudo per gli utenti amministratori, seguire questa procedura:
- Apri il file di configurazione sudoers:
sudo vi /etc/sudoers.d/opengear
- Aggiungere le righe seguenti per concedere l'accesso sudo:
%netgrp ALL=(ALL) ALL
%admin ALL=(ALL) NOPASSWD: ALL
Nota
Assicurarsi di salvare le modifiche dopo aver aggiornato il file.
Questa configurazione consente ai membri del gruppo "netgrp" di eseguire qualsiasi comando come qualsiasi utente e ai membri del gruppo "admin" di eseguire qualsiasi comando come qualsiasi utente senza richiedere una password.
Passaggio 6: Garantire la disponibilità del servizio LLDP
Per assicurarsi che il servizio LLDP sia disponibile nel Terminal Server, seguire questa procedura:
Controllare se il servizio LLDP è in esecuzione:
sudo systemctl status lldpd
Se il servizio è in esecuzione, verrà visualizzato un output simile al seguente:
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.
Se il servizio non è attivo (in esecuzione), avviare il servizio:
sudo systemctl start lldpd
Abilitare il servizio per l'avvio automatico al riavvio.
sudo systemctl enable lldpd
Nota
Assicurarsi di eseguire questi passaggi per assicurarsi che il servizio LLDP sia sempre disponibile e venga avviato automaticamente al riavvio.
Passaggio 7: Controllo della data/ora di sistema
Assicurarsi che la data/ora di sistema sia impostata correttamente e che il fuso orario del Terminal Server sia in formato UTC.
Controllare l'impostazione del fuso orario:
Per controllare l'impostazione del fuso orario corrente:
ogcli get system/timezone
Impostare il fuso orario su UTC:
Se il fuso orario non è impostato su UTC, è possibile impostarlo usando:
ogcli update system/timezone timezone=\"UTC\"
Controllare la data/ora corrente:
Controllare la data e l'ora correnti:
date
Correggere data/ora in caso di errore:
Se la data/ora non è corretta, è possibile correggerla usando:
ogcli replace system/time
Reading information from stdin. Press Ctrl-D to submit and Ctrl-C to cancel.
time="<CURRENT_DATE_TIME>"
Parametri:
| Nome parametro | Descrizione |
|---|---|
| CURRENT_DATE_TIME | Data/ora corrente nel formato hh:mm MMM GG, AAAA |
Nota
Assicurarsi che la data/ora di sistema sia accurata per evitare problemi con applicazioni o servizi basati su di essa.
Passaggio 8: Etichettatura delle porte del Terminal Server (se mancante/non corretta)
Per etichettare le porte del Terminal Server, usare il comando seguente:
ogcli update port "port-<PORT_#>" label=\"<NEW_NAME>\" <PORT_#>
Parametri:
| Nome parametro | Descrizione |
|---|---|
| NEW_NAME | Nome dell'etichetta della porta |
| PORTO_ # | Numero di porta Terminal Server |
Passaggio 9: Impostazioni necessarie per le connessioni seriali PURE array
Gli array Pure Storage acquistati prima del 2024 presentano controller R3 di revisione che usano cavi della console di rollover e richiedono i comandi di connessione della porta seriale personalizzati seguenti:
Controller R3 Pure Storage:
ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X1"' <PORT_#> Pure Storage Controller console
Le più recenti appliance di Pure Storage, e i sistemi aggiornati da R3 ai controller Pure Storage R4, utilizzeranno cavi console straight-through con le seguenti impostazioni aggiornate:
Controller R4 Pure Storage:
ogcli update port ports-<PORT_#> 'baudrate="115200"' <PORT_#> Pure Storage Controller console
ogcli update port ports-<PORT_#> 'pinout="X2"' <PORT_#> Pure Storage Controller console
Parametri:
| Nome parametro | Descrizione |
|---|---|
| PORTO_ # | Numero di porta Terminal Server |
Questi comandi impostano la velocità baud e il pinout per la connessione alla console pure storage Controller.
Nota
Tutte le altre impostazioni delle porte di Terminal Server devono rimanere invariate e funzionare per impostazione predefinita con un cavo console RJ45 diretto.
Passaggio 10: Verifica delle impostazioni
Per verificare le impostazioni di configurazione, eseguire i comandi seguenti:
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
Nota
Assicurarsi che i vicini LLDP siano come previsto, indicando le connessioni riuscite verso PE1 e PE2.
Esempio di output dei vicini LLDP:
-------------------------------------------------------------------------------
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
-------------------------------------------------------------------------------
Nota
Verificare che l'output corrisponda alle aspettative e che tutte le configurazioni siano corrette.
Configurare la prima matrice di archiviazione
- L'operatore deve installare l'hardware dell'array di archiviazione all'interno del rack di aggregazione come specificato dalla distinta base e dall'elevazione del rack.
- L'operatore deve fornire le informazioni al tecnico dell'array di archiviazione, affinché questo arrivi in loco per configurare l'appliance.
- Dati specifici della posizione necessari, condivisi con il tecnico dell'array di archiviazione:
- Nome cliente:
- Data ispezione fisica:
- Numero di serie dello chassis:
- Nome host dell'array di archiviazione:
- Codice CLLI (identificatore di posizione Common Language):
- Indirizzo di installazione:
- Posizione FIC/Rack/Griglia:
- Dati forniti all'operatore e condivisi con il tecnico dell'array di archiviazione, che saranno comuni a tutte le installazioni:
- Livello codice Purity: fare riferimento alle versioni Purity supportate
- Modalità provvisoria: disabilitata
- Fuso orario array: UTC
- Indirizzo IP del server DNS (Domain Name System): non impostato dall'operatore durante l'installazione
- Suffisso di dominio DNS: non impostato dall'operatore durante l'installazione
- Indirizzo IP del server NTP (Network Time Protocol) o FQDN: non impostato dall'operatore durante l'installazione
- Syslog Primary: non impostato dall'operatore durante l'installazione
- Syslog Secondary: non impostato dall'operatore durante l'installazione
- Indirizzo IP del gateway SMTP o FQDN: non impostato dall'operatore durante l'installazione
- Nome di dominio del mittente dell'email: nome di dominio del mittente dell'email (example.com)
- Indirizzi e-mail da avvisare: non impostato dall'operatore durante l'installazione
- Server proxy e porta: non impostato dall'operatore durante l'installazione
- Gestione: Interfaccia virtuale
- Indirizzo IP: 172.27.255.200
- Gateway: non impostato dall'operatore durante l'installazione
- Maschera di sottorete: 255.255.255.0
- MTU: 1500
- Bond: non impostato dall'operatore durante l'installazione
- Gestione: Controller 0
- Indirizzo IP: 172.27.255.254
- Gateway: non impostato dall'operatore durante l'installazione
- Maschera di sottorete: 255.255.255.0
- MTU: 1500
- Bond: non impostato dall'operatore durante l'installazione
- Gestione: Controller 1
- Indirizzo IP: 172.27.255.253
- Gateway: non impostato dall'operatore durante l'installazione
- Maschera di sottorete: 255.255.255.0
- MTU: 1500
- Bond: non impostato dall'operatore durante l'installazione
- ct0.eth10: non impostato dall'operatore durante l'installazione
- ct0.eth11: non impostato dall'operatore durante l'installazione
- ct0.eth18: non impostato dall'operatore durante l'installazione
- ct0.eth19: non impostato dall'operatore durante l'installazione
- ct1.eth10: non impostato dall'operatore durante l'installazione
- ct1.eth11: non impostato dall'operatore durante l'installazione
- ct1.eth18: non impostato dall'operatore durante l'installazione
- ct1.eth19: non impostato dall'operatore durante l'installazione
- Pure Tunable da applicare:
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";
(Facoltativo) Configurare la seconda matrice di archiviazione
Nota
Questa sezione è facoltativa. È necessario eseguirlo solo se si distribuisce un'istanza Di Azure Operator Nexus con due appliance di archiviazione. Per altre informazioni, incluse le restrizioni relative all'hardware supportato, vedere Azure Operator Nexus multiple storage appliances (Operatore Nexus di Azure per più appliance di archiviazione).
- L'operatore deve installare l'hardware dell'array di archiviazione all'interno del rack di aggregazione come specificato dalla distinta base e dall'elevazione del rack.
- L'operatore deve fornire le informazioni al tecnico dell'array di archiviazione, affinché questo arrivi in loco per configurare l'appliance.
- Dati specifici della posizione necessari, condivisi con il tecnico dell'array di archiviazione:
- Nome cliente:
- Data ispezione fisica:
- Numero di serie dello chassis:
- Nome host dell'array di archiviazione:
- Codice CLLI (identificatore di posizione Common Language):
- Indirizzo di installazione:
- Posizione FIC/Rack/Griglia:
- Dati forniti all'operatore e condivisi con il tecnico dell'array di archiviazione, che saranno comuni a tutte le installazioni:
- Livello codice Purity: fare riferimento alle versioni Purity supportate
- Modalità provvisoria: disabilitata
- Fuso orario array: UTC
- Indirizzo IP del server DNS (Domain Name System): non impostato dall'operatore durante l'installazione
- Suffisso di dominio DNS: non impostato dall'operatore durante l'installazione
- Indirizzo IP del server NTP (Network Time Protocol) o FQDN: non impostato dall'operatore durante l'installazione
- Syslog Primary: non impostato dall'operatore durante l'installazione
- Syslog Secondary: non impostato dall'operatore durante l'installazione
- Indirizzo IP del gateway SMTP o FQDN: non impostato dall'operatore durante l'installazione
- Nome di dominio del mittente dell'email: nome di dominio del mittente dell'email (example.com)
- Indirizzi e-mail da avvisare: non impostato dall'operatore durante l'installazione
- Server proxy e porta: non impostato dall'operatore durante l'installazione
- Gestione: Interfaccia virtuale
- Indirizzo IP: 172.27.255.201
- Gateway: non impostato dall'operatore durante l'installazione
- Maschera di sottorete: 255.255.255.0
- MTU: 1500
- Bond: non impostato dall'operatore durante l'installazione
- Gestione: Controller 0
- Indirizzo IP: 172.27.255.251
- Gateway: non impostato dall'operatore durante l'installazione
- Maschera di sottorete: 255.255.255.0
- MTU: 1500
- Bond: non impostato dall'operatore durante l'installazione
- Gestione: Controller 1
- Indirizzo IP: 172.27.255.252
- Gateway: non impostato dall'operatore durante l'installazione
- Maschera di sottorete: 255.255.255.0
- MTU: 1500
- Bond: non impostato dall'operatore durante l'installazione
- ct0.eth10: non impostato dall'operatore durante l'installazione
- ct0.eth11: non impostato dall'operatore durante l'installazione
- ct0.eth18: non impostato dall'operatore durante l'installazione
- ct0.eth19: non impostato dall'operatore durante l'installazione
- ct1.eth10: non impostato dall'operatore durante l'installazione
- ct1.eth11: non impostato dall'operatore durante l'installazione
- ct1.eth18: non impostato dall'operatore durante l'installazione
- ct1.eth19: non impostato dall'operatore durante l'installazione
- Pure Tunable da applicare:
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";
Assegnazione IP iDRAC
Prima di distribuire il cluster Nexus, è consigliabile che l'operatore imposti gli indirizzi IP iDRAC durante l'organizzazione dei rack hardware. Ecco come eseguire il mapping dei server agli indirizzi IP:
- Assegnare indirizzi IP in base alla posizione di ogni server all'interno del rack.
- Usare il quarto blocco /24 della subnet /19 allocata per Fabric.
- Iniziare ad assegnare gli IP dal server inferiore verso l'alto in ogni rack, iniziando da 0,11.
- Continuare ad assegnare gli IP in sequenza al primo server nella parte inferiore del rack successivo.
Esempio
Intervallo di infrastruttura: 10.1.0.0-10.1.31.255 - la subnet iDRAC al quarto /24 è 10.1.3.0/24.
| Armadio dati | Servidor | IP iDRAC |
|---|---|---|
| Rack 1 | Lavoratore 1 | 10.1.3.11/24 |
| Rack 1 | Operaio 2 | 10.1.3.12/24 |
| Rack 1 | Lavoratore 3 | 10.1.3.13/24 |
| Rack 1 | Lavoratore 4 | 10.1.3.14/24 |
| Rack 1 | Lavoratore 5 | 10.1.3.15/24 |
| Rack 1 | Lavoratore 6 | 10.1.3.16/24 |
| Rack 1 | Lavoratore 7 | 10.1.3.17/24 |
| Rack 1 | Lavoratore 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 | Lavoratore 1 | 10.1.3.21/24 |
| Rack 2 | Operaio 2 | 10.1.3.22/24 |
| Rack 2 | Lavoratore 3 | 10.1.3.23/24 |
| Rack 2 | Lavoratore 4 | 10.1.3.24/24 |
| Rack 2 | Lavoratore 5 | 10.1.3.25/24 |
| Rack 2 | Lavoratore 6 | 10.1.3.26/24 |
| Rack 2 | Lavoratore 7 | 10.1.3.27/24 |
| Rack 2 | Lavoratore 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 | Lavoratore 1 | 10.1.3.31/24 |
| Rack 3 | Operaio 2 | 10.1.3.32/24 |
| Rack 3 | Lavoratore 3 | 10.1.3.33/24 |
| Rack 3 | Lavoratore 4 | 10.1.3.34/24 |
| Rack 3 | Lavoratore 5 | 10.1.3.35/24 |
| Rack 3 | Lavoratore 6 | 10.1.3.36/24 |
| Rack 3 | Lavoratore 7 | 10.1.3.37/24 |
| Rack 3 | Lavoratore 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 | Lavoratore 1 | 10.1.3.41/24 |
| Rack 4 | Operaio 2 | 10.1.3.42/24 |
| Rack 4 | Lavoratore 3 | 10.1.3.43/24 |
| Rack 4 | Lavoratore 4 | 10.1.3.44/24 |
| Rack 4 | Lavoratore 5 | 10.1.3.45/24 |
| Rack 4 | Lavoratore 6 | 10.1.3.46/24 |
| Rack 4 | Lavoratore 7 | 10.1.3.47/24 |
| Rack 4 | Lavoratore 8 | 10.1.3.48/24 |
| Rack 4 | Controller 1 | 10.1.3.49/24 |
| Rack 4 | Controller 2 | 10.1.3.50/24 |
Esempio di progettazione di tre istanze locali della stessa coppia NFC/CM, utilizzando reti /19 sequenziali all'interno di un /16.
| Istanza | Intervallo Fabric | Subnet iDRAC |
|---|---|---|
| Istanza 1 | 10.1.0.0-10.1.31.255 | 10.1.3.0/24 |
| Istanza 2 | 10.1.32.0-10.1.63.255 | 10.1.35.0/24 |
| Istanza 3 | 10.1.64.0-10.1.95.255 | 10.1.67.0/24 |
Configurazione predefinita per altri dispositivi installati
- Tutti i dispositivi dell'infrastruttura di rete (ad eccezione del Terminal Server) sono impostati sulla modalità
ZTP - I server hanno le impostazioni predefinite della factory, incluse le impostazioni minime del BIOS.
Versione minima consigliata del BIOS e del firmware per il runtime di Nexus Cluster
Come procedura consigliata, a partire dalle versioni minime consigliate di BIOS e firmware vengono implementate in base al cluster Nexus, in base alla versione di runtime selezionata e all'elenco materiali:
Versione runtime di Nexus Cluster 4.4.x
BOM 1.7.3
| Componente | Versione |
|---|---|
| BIOS | 1.15.2 |
| Controller array di archiviazione (PERC H755) | 52.26.0-5179 |
| iDRAC | 7.10.90.00 |
| Firmware SEP passivo backplane di archiviazione non-espansore (15G non espansore) | 7.10 |
| CPLD (Dispositivo Logico Programmabile Complesso) | 1.1.1 |
| Adattatore DX Mellanox ConnectX-6 | 22.41.1000 |
| NVIDIA ConnectX-6 Lx 2x 25G SFP28 | 26.41.1000 |
| Scheda Broadcom 5720 Quad Port 1GbE BASE-T | 22.91.5 |
BOM 2.0.0
| Componente | Versione |
|---|---|
| BIOS | 2.4.4 |
| Controller array di archiviazione (PERC H755) | 52.26.0-5179 |
| iDRAC | 7.10.90.00 |
| Firmware backplane espansore SAS (R760) | 1.61 |
| Firmware backplane di archiviazione non espansore (R660) | 7.10 |
| CPLD (Dispositivo Logico Programmabile Complesso) | 1.2.6 |
| Adattatore DX Mellanox ConnectX-6 | 22.41.10.00 |
| NVIDIA ConnectX-6 Lx 2x 25G SFP28 | 26.41.10.00 |
| Scheda Broadcom 5720 Quad Port 1GbE BASE-T | 22.91.5 |
Runtime di Nexus Cluster versione 4.1.x
BOM 1.7.3
| Componente | Versione |
|---|---|
| BIOS | 1.13.2 |
| Controller array di archiviazione (PERC H755) | 52.26.0-5179 |
| iDRAC | 7.10.30.00 |
| Firmware SEP passivo backplane di archiviazione non-espansore (15G non espansore) | 7.10 |
| CPLD (Dispositivo Logico Programmabile Complesso) | 1.0.9 |
| Adattatore DX Mellanox ConnectX-6 | 22.35.10.12 |
| Scheda Broadcom 5720 Quad Port 1GbE BASE-T | 22.61.8 |
BOM 2.0.0
| Componente | Versione |
|---|---|
| BIOS | 2.2.7 |
| Controller array di archiviazione (PERC H755) | 52.26.0-5179 |
| iDRAC | 7.10.30.00 |
| Firmware backplane espansore SAS (R760) | 1.61 |
| Firmware backplane di archiviazione non espansore (R660) | 7.10 |
| CPLD (Dispositivo Logico Programmabile Complesso) | 1.2.1 |
| Adattatore DX Mellanox ConnectX-6 | 22.39.10.02 |
| Scheda Broadcom 5720 Quad Port 1GbE BASE-T | 22.91.5 |
Regole firewall tra Azure e il cluster Nexus.
Per stabilire regole firewall tra Azure e il cluster Nexus, l'operatore deve aprire le porte specificate. Ciò garantisce la comunicazione e la connettività appropriate per i servizi necessari tramite TCP (Transmission Control Protocol) e UDP (User Datagram Protocol).
| Numero s. | Sorgente | Destinazione | Porta (TCP/UDP) | Bidirezionale | Scopo della regola |
|---|---|---|---|---|---|
| 1 | Rete virtuale di Azure | Raggruppamento | 22 TCP | NO | Per SSH ai server undercloud della subnet CM |
| 2 | Rete virtuale di Azure | Raggruppamento | 443 TCP | NO | Per accedere ai nodi undercloud iDRAC |
| 3 | Rete virtuale di Azure | Raggruppamento | 5900 TCP | NO | Gnmi |
| 4 | Rete virtuale di Azure | Raggruppamento | 6030 TCP | NO | Gnmi Certificati |
| 5 | Rete virtuale di Azure | Raggruppamento | 6443 TCP | NO | Per accedere al cluster K8S undercloud |
| 6 | Raggruppamento | Rete virtuale di Azure | 8080 TCP | Sì | Per montare l'immagine ISO in iDRAC e aggiornare il runtime NNF |
| 7 | Raggruppamento | Rete virtuale di Azure | 3128 TCP | NO | Proxy per connettersi agli endpoint globali di Azure |
| 8 | Raggruppamento | Rete virtuale di Azure | TCP e UDP 53 | NO | Sistema dei Nomi di Dominio (DNS) |
| 9 | Raggruppamento | Rete virtuale di Azure | 123 UDP | NO | NTP |
| 10 | Raggruppamento | Rete virtuale di Azure | 8888 TCP | NO | Connessione al servizio Web Cluster Manager |
| 11 | Raggruppamento | Rete virtuale di Azure | 514 TCP e UDP | NO | Per accedere ai log undercloud da Cluster Manager |
Installare le estensioni dell'interfaccia della riga di comando e accedere alla sottoscrizione di Azure
Installare la versione più recente delle estensioni dell'interfaccia della riga di comando necessarie.
Accesso alla sottoscrizione di Azure
az login
az account set --subscription <SUBSCRIPTION_ID>
az account show
Nota
L'account deve disporre delle autorizzazioni di lettura/scrittura/pubblicazione nella sottoscrizione