Prerequisiti della piattaforma Operatore Nexus
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, criteri, autorizzazioni e controllo degli accessi in base al ruolo
- 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. Altre informazioni disponibili nella pagina sicurezza Defender per il cloud.
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, Operatore 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 una corretta implementazione e manutenzione dell'istanza locale. La distinta base è strutturata per fornire all'operatore una serie di unità di stockkeeping (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
Operatore Nexus ha creato una serie di SKU con fornitori come Dell, Pure Storage e Arista, ai quali l'operatore può fare riferimento quando effettua un ordine. Pertanto, l’operatore deve semplicemente inserire un ordine per il fornitore in base alle informazioni sullo SKU fornite da Operatore Nexus per ricevere l'elenco delle parti corrette per la compilazione.
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 di infrastruttura 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 di tipo lontano. 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
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 è connessa agli operatori dei router perimetrali del provider locale e configurata con gli indirizzi IP e le credenziali
- Il Terminal Server è accessibile dalla VPN di gestione
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 |
Per altri dettagli, vedere le informazioni di riferimento sull'interfaccia della riga di comando.
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 | Terminal server PE1 to TS NET1 IP |
TS_NET1_NETMASK | Terminal server PE1 to TS NET1 netmask |
TS_NET1_GW | Terminal server PE1 to TS NET1 gateway |
TS_NET2_IP | Terminal server PE2 to TS NET2 IP |
TS_NET2_NETMASK | Terminal server PE2 to TS NET2 netmask |
TS_NET2_GW | Terminal server PE2 to TS NET2 gateway |
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 | Terminal server NET3 Nome connessione |
- 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:
- Aprire il file di configurazione utenti sudo:
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 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 etichetta porta |
PORT_# | Numero di porta Terminal Server |
Passaggio 9: Impostazioni necessarie per le connessioni seriali PURE array
Le matrici di archiviazione pure acquistate prima del 2024 hanno 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 di archiviazione:
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 appliance di archiviazione pure più recenti e i sistemi aggiornati da R3 ai controller di archiviazione pure R4 useranno cavi della console direttamente con le impostazioni aggiornate seguenti:
Controller R4 di archiviazione pure:
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 |
---|---|
PORT_# | 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 terminal Server devono rimanere invariate e funzionano per impostazione predefinita con un cavo della console RJ45 dritto.
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 l'array 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 matrice: 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 messaggi di posta elettronica: nome di dominio del mittente messaggi di posta elettronica (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
- Subnet mask: 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
- Subnet mask: 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
- Subnet mask: 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.
Rack | Server | IP iDRAC |
---|---|---|
Rack 1 | Ruolo di lavoro 1 | 10.1.3.11/24 |
Rack 1 | Ruolo di lavoro 2 | 10.1.3.12/24 |
Rack 1 | Ruolo di lavoro 3 | 10.1.3.13/24 |
Rack 1 | Ruolo di lavoro 4 | 10.1.3.14/24 |
Rack 1 | Ruolo di lavoro 5 | 10.1.3.15/24 |
Rack 1 | Ruolo di lavoro 6 | 10.1.3.16/24 |
Rack 1 | Ruolo di lavoro 7 | 10.1.3.17/24 |
Rack 1 | Ruolo di lavoro 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 | Ruolo di lavoro 1 | 10.1.3.21/24 |
Rack 2 | Ruolo di lavoro 2 | 10.1.3.22/24 |
Rack 2 | Ruolo di lavoro 3 | 10.1.3.23/24 |
Rack 2 | Ruolo di lavoro 4 | 10.1.3.24/24 |
Rack 2 | Ruolo di lavoro 5 | 10.1.3.25/24 |
Rack 2 | Ruolo di lavoro 6 | 10.1.3.26/24 |
Rack 2 | Ruolo di lavoro 7 | 10.1.3.27/24 |
Rack 2 | Ruolo di lavoro 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 | Ruolo di lavoro 1 | 10.1.3.31/24 |
Rack 3 | Ruolo di lavoro 2 | 10.1.3.32/24 |
Rack 3 | Ruolo di lavoro 3 | 10.1.3.33/24 |
Rack 3 | Ruolo di lavoro 4 | 10.1.3.34/24 |
Rack 3 | Ruolo di lavoro 5 | 10.1.3.35/24 |
Rack 3 | Ruolo di lavoro 6 | 10.1.3.36/24 |
Rack 3 | Ruolo di lavoro 7 | 10.1.3.37/24 |
Rack 3 | Ruolo di lavoro 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 | Ruolo di lavoro 1 | 10.1.3.41/24 |
Rack 4 | Ruolo di lavoro 2 | 10.1.3.42/24 |
Rack 4 | Ruolo di lavoro 3 | 10.1.3.43/24 |
Rack 4 | Ruolo di lavoro 4 | 10.1.3.44/24 |
Rack 4 | Ruolo di lavoro 5 | 10.1.3.45/24 |
Rack 4 | Ruolo di lavoro 6 | 10.1.3.46/24 |
Rack 4 | Ruolo di lavoro 7 | 10.1.3.47/24 |
Rack 4 | Ruolo di lavoro 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, usando reti /19 sequenziali in 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 impostazioni factory predefinite
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).
S.No | Source (Sorgente) | Destination | Porta (TCP/UDP) | Bidirezionale | Scopo della regola |
---|---|---|---|---|---|
1 | Rete virtuale di Azure | Cluster | 22 TCP | No | Per i server SSH in cloud dalla subnet CM |
2 | Rete virtuale di Azure | Cluster | 443 TCP | No | Per accedere ai nodi undercloud iDRAC |
3 | Rete virtuale di Azure | Cluster | 5900 TCP | No | Gnmi |
4 | Rete virtuale di Azure | Cluster | 6030 TCP | No | Gnmi Certs |
5 | Rete virtuale di Azure | Cluster | 6443 TCP | No | Per accedere al cluster K8S undercloud |
6 | Cluster | Rete virtuale di Azure | 8080 TCP | Sì | Per il montaggio dell'immagine ISO in iDRAC, aggiornamento del runtime NNF |
7 | Cluster | Rete virtuale di Azure | 3128 TCP | No | Proxy per connettersi agli endpoint globali di Azure |
8 | Cluster | Rete virtuale di Azure | TCP 53 e UDP | No | DNS |
9 | Cluster | Rete virtuale di Azure | 123 UDP | No | NTP |
10 | Cluster | Rete virtuale di Azure | 8888 TCP | No | Connessione al servizio Web Cluster Manager |
11 | Cluster | 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 all'abbonamento 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