Condividi tramite


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:

  1. Assemblare i rack in base alle elevazioni rack dello SKU. Le istruzioni specifiche per l'assemblaggio rack verranno fornite dal produttore del rack.
  2. Dopo l'assemblaggio dei rack, installare i dispositivi di infrastruttura nei rack in base al diagramma di elevazione.
  3. Collegare i dispositivi di infrastruttura collegando le interfacce di rete in base al diagramma di cablaggio.
  4. Assemblare e installare i server in base al diagramma di elevazione rack.
  5. Assemblare e installare il dispositivo di archiviazione in base al diagramma di elevazione rack.
  6. Collegare il server e i dispositivi di archiviazione connettendo le interfacce di rete in base al diagramma di cablaggio.
  7. Alimentazione via cavo di ogni dispositivo.
  8. 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:

  1. 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
  1. 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:

  1. 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:

  1. Aprire il file di configurazione utenti sudo:
sudo vi /etc/sudoers.d/opengear
  1. 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

  1. 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.
  2. L'operatore deve fornire le informazioni al tecnico dell'array di archiviazione, affinché questo arrivi in loco per configurare l'appliance.
  3. 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:
  4. 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 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