Considerazioni sulla rete per le distribuzioni cloud di Azure Stack HCI, versione 23H2

Articolo
03/14/2024

Si applica a: Azure Stack HCI, versione 23H2

Questo articolo illustra come progettare e pianificare una rete di sistema di Azure Stack HCI versione 23H2 per la distribuzione cloud. Prima di continuare, acquisire familiarità con i vari modelli di rete di Azure Stack HCI e le configurazioni disponibili.

Framework di progettazione di rete

Il diagramma seguente illustra le varie decisioni e i passaggi che definiscono il framework di progettazione di rete per il sistema Azure Stack HCI: dimensioni del cluster, connettività di archiviazione cluster, finalità del traffico di rete, connettività di gestione e configurazione della scheda di rete. Ogni decisione di progettazione consente o consente le opzioni di progettazione disponibili nei passaggi successivi:

Passaggio 1: Determinare le dimensioni del cluster

Per determinare le dimensioni del sistema Azure Stack HCI, usare lo strumento di dimensioni HCI di Azure Stack, in cui è possibile definire il profilo, ad esempio il numero di macchine virtuali ,le dimensioni delle macchine virtuali e l'uso del carico di lavoro delle macchine virtuali, ad esempio Desktop virtuale azure, SQL Server o servizio Azure Kubernetes.

Come descritto nell'articolo Requisiti del server di sistema HCI di Azure Stack, il numero massimo di server supportati nel sistema Azure Stack HCI è 16. Dopo aver completato la pianificazione della capacità del carico di lavoro, è necessario avere una buona comprensione del numero di nodi server necessari per eseguire carichi di lavoro nell'infrastruttura.

Se i carichi di lavoro richiedono quattro o più nodi: non è possibile distribuire e usare una configurazione senza commutatori per il traffico di rete di archiviazione. Per gestire il traffico di archiviazione, è necessario includere un commutatore fisico con supporto per Remote Direct Memory Access (RDMA). Per altre informazioni sull'architettura di rete del cluster HCI di Azure Stack, vedere Panoramica dei modelli di riferimento di rete.
Se i carichi di lavoro richiedono tre o meno nodi: è possibile scegliere configurazioni senza cambio o commutate per la connettività di archiviazione.
Se si prevede di aumentare il numero di istanze successive a più di tre nodi: è necessario usare un commutatore fisico per il traffico di rete di archiviazione. Qualsiasi operazione di scalabilità orizzontale per le distribuzioni senza commutatori richiede la configurazione manuale del cablazione di rete tra i nodi che Microsoft non convalida attivamente come parte del ciclo di sviluppo software per Azure Stack HCI.

Ecco le considerazioni riepilogate per la decisione sulle dimensioni del cluster:

Decisione	Considerazioni
Dimensioni del cluster (numero di nodi per cluster)	La configurazione senza cambio tramite i modelli portale di Azure o ARM è disponibile solo per 1, 2 o 3 cluster di nodi. I cluster con 4 o più nodi richiedono il commutatore fisico per il traffico di rete di archiviazione.
Requisiti di scalabilità orizzontale	Se si intende ridimensionare il cluster usando l'agente di orchestrazione, è necessario usare un commutatore fisico per il traffico di rete di archiviazione.

Passaggio 2: Determinare la connettività di archiviazione del cluster

Come descritto in Requisiti di rete fisica, Azure Stack HCI supporta due tipi di connettività per il traffico di rete di archiviazione:

Usare un commutatore di rete fisico per gestire il traffico.
Connettere direttamente i nodi tra loro con cavi di rete incrociata o fibre per il traffico di archiviazione.

I vantaggi e gli svantaggi di ogni opzione sono documentati nell'articolo collegato sopra.

Come indicato in precedenza, è possibile decidere solo tra le due opzioni quando le dimensioni del cluster sono tre o meno nodi. Qualsiasi cluster con quattro o più nodi viene distribuito automaticamente usando un commutatore di rete per l'archiviazione.

Se i cluster hanno meno di tre nodi, la decisione di connettività di archiviazione influenza il numero e il tipo di finalità di rete che è possibile definire nel passaggio successivo.

Ad esempio, per configurazioni senza cambio, è necessario definire due finalità del traffico di rete. Il traffico di archiviazione per le comunicazioni a est-ovest usando i cavi crossover non ha connettività nord-sud ed è completamente isolato dal resto dell'infrastruttura di rete. Ciò significa che è necessario definire una seconda finalità di rete per la connettività in uscita e per i carichi di lavoro di calcolo.

Anche se è possibile definire ogni finalità di rete con una sola porta della scheda di rete fisica, che non fornisce alcuna tolleranza di errore. Di conseguenza, è sempre consigliabile usare almeno due porte di rete fisiche per ogni finalità di rete. Se si decide di usare un commutatore di rete per l'archiviazione, è possibile raggruppare tutto il traffico di rete, incluso l'archiviazione in una singola finalità di rete, nota anche come configurazione di rete host iperconvergente o completamente convergente .

Ecco le considerazioni riepilogate per la decisione di connettività dell'archiviazione cluster:

Decisione	Considerazioni
Nessun commutatore per l'archiviazione	La configurazione senza cambio tramite portale di Azure o distribuzione di modelli di Resource Manager è supportata solo per 1, 2 o 3 cluster di nodi. È possibile distribuire cluster senza commutatori di archiviazione a 1 o 2 nodi usando i modelli portale di Azure o ARM. È possibile distribuire 3 cluster senza commutatori di archiviazione dei nodi solo usando i modelli di Resource Manager. Le operazioni di scalabilità orizzontale non sono supportate con le distribuzioni senza cambio. Qualsiasi modifica al numero di nodi dopo la distribuzione richiede una configurazione manuale. Quando si usa la configurazione senza commutatori di archiviazione, sono necessarie almeno 2 finalità di rete.
Commutatore di rete per l'archiviazione	Se si intende ridimensionare il cluster usando l'agente di orchestrazione, è necessario usare un commutatore fisico per il traffico di rete di archiviazione. È possibile usare questa architettura con qualsiasi numero di nodi compresi tra 1 e 16. Anche se non viene applicata, è possibile usare una singola finalità per tutti i tipi di traffico di rete (Gestione, calcolo e archiviazione)

Decisione

Considerazioni

Nessun commutatore per l'archiviazione

La configurazione senza cambio tramite portale di Azure o distribuzione di modelli di Resource Manager è supportata solo per 1, 2 o 3 cluster di nodi.

È possibile distribuire cluster senza commutatori di archiviazione a 1 o 2 nodi usando i modelli portale di Azure o ARM.

È possibile distribuire 3 cluster senza commutatori di archiviazione dei nodi solo usando i modelli di Resource Manager.

Le operazioni di scalabilità orizzontale non sono supportate con le distribuzioni senza cambio. Qualsiasi modifica al numero di nodi dopo la distribuzione richiede una configurazione manuale.

Quando si usa la configurazione senza commutatori di archiviazione, sono necessarie almeno 2 finalità di rete.

Commutatore di rete per l'archiviazione

Se si intende ridimensionare il cluster usando l'agente di orchestrazione, è necessario usare un commutatore fisico per il traffico di rete di archiviazione.

È possibile usare questa architettura con qualsiasi numero di nodi compresi tra 1 e 16.

Anche se non viene applicata, è possibile usare una singola finalità per tutti i tipi di traffico di rete (Gestione, calcolo e archiviazione)

Il diagramma seguente riepiloga le opzioni di connettività di archiviazione disponibili per varie distribuzioni:

Passaggio 3: Determinare le finalità del traffico di rete

Per Azure Stack HCI, tutte le distribuzioni si basano su Network ATC per la configurazione della rete host. Le finalità di rete vengono configurate automaticamente durante la distribuzione di Azure Stack HCI tramite la portale di Azure. Per altre informazioni sulle finalità di rete e su come risolvere i problemi, vedere Comandi atC di rete comuni.

Questa sezione illustra le implicazioni della decisione di progettazione per le finalità del traffico di rete e come influiscono sul passaggio successivo del framework. Per le distribuzioni cloud, è possibile selezionare tra quattro opzioni per raggruppare il traffico di rete in una o più finalità. Le opzioni disponibili dipendono dal numero di nodi nel cluster e dal tipo di connettività di archiviazione usato.

Le opzioni di finalità di rete disponibili vengono illustrate nelle sezioni seguenti.

Finalità di rete: raggruppare tutto il traffico

Network ATC configura una finalità univoca che include traffico di rete di gestione, calcolo e archiviazione. Le schede di rete assegnate a questa larghezza di banda di condivisione finalità e velocità effettiva per tutto il traffico di rete.

Questa opzione richiede un commutatore fisico per il traffico di archiviazione. Se è necessaria un'architettura senza cambio, non è possibile usare questo tipo di finalità. portale di Azure filtra automaticamente questa opzione se si seleziona una configurazione senza cambio per la connettività di archiviazione.
È consigliabile garantire la disponibilità elevata almeno due porte della scheda di rete.
Sono necessarie almeno 10 Gbps per supportare il traffico RDMA per l'archiviazione.

Finalità di rete: Gestione del gruppo e traffico di calcolo

Network ATC configura due finalità. La prima finalità include la gestione e il traffico di rete di calcolo e la seconda finalità include solo il traffico di rete di archiviazione. Ogni finalità deve avere un set diverso di porte della scheda di rete.

È possibile usare questa opzione per la connettività di archiviazione commutata e senza commutatori, se:

Almeno due porte della scheda di rete sono disponibili per ogni finalità per garantire la disponibilità elevata.
Un commutatore fisico viene usato per RDMA se si usa il commutatore di rete per l'archiviazione.
Sono necessarie almeno 10 Gbps per supportare il traffico RDMA per l'archiviazione.

Finalità di rete: Raggruppare il calcolo e il traffico di archiviazione

Network ATC configura due finalità. La prima finalità include il traffico di rete di calcolo e archiviazione e la seconda finalità include solo il traffico di rete di gestione. Ogni finalità deve usare un set diverso di porte della scheda di rete.

Questa opzione richiede un commutatore fisico per il traffico di archiviazione come le stesse porte sono condivise con il traffico di calcolo, che richiedono la comunicazione nord-sud. Se è necessaria una configurazione senza cambio, non è possibile usare questo tipo di finalità. portale di Azure filtra automaticamente questa opzione se si seleziona una configurazione senza cambio per la connettività di archiviazione.
Questa opzione richiede un commutatore fisico per RDMA.
È consigliabile garantire la disponibilità elevata almeno due porte della scheda di rete.
È consigliabile usare almeno 10 Gbps per la finalità di calcolo e archiviazione per supportare il traffico RDMA.
Anche quando la finalità di gestione viene dichiarata senza una finalità di calcolo, Network ATC crea un commutatore virtuale Switch Embedded Teaming (SET) per offrire disponibilità elevata alla rete di gestione.

Finalità di rete: configurazione personalizzata

Definire fino a tre finalità usando la propria configurazione, purché almeno una delle finalità includa il traffico di gestione. È consigliabile usare questa opzione quando è necessaria una seconda finalità di calcolo. Gli scenari per questo secondo requisito di finalità di calcolo includono il traffico di archiviazione remoto, il traffico di backup delle macchine virtuali o una finalità di calcolo separata per tipi distinti di carichi di lavoro.

Usare questa opzione per la connettività di archiviazione commutata e senza cambio se la finalità di archiviazione è diversa dalle altre finalità.
Usare questa opzione quando è necessaria un'altra finalità di calcolo o quando si desidera separare completamente i tipi distinti di traffico su schede di rete diverse.
Usare almeno due porte della scheda di rete per ogni finalità per garantire la disponibilità elevata.
È consigliabile usare almeno 10 Gbps per la finalità di calcolo e archiviazione per supportare il traffico RDMA.

Il diagramma seguente riepiloga le opzioni di finalità di rete disponibili per varie distribuzioni:

Passaggio 4: Determinare la connettività di rete di gestione

In questo passaggio viene definito lo spazio degli indirizzi della subnet dell'infrastruttura, il modo in cui questi indirizzi vengono assegnati al cluster e, se è presente un requisito di ID proxy o VLAN per i nodi per la connettività in uscita a Internet e ad altri servizi Intranet, ad esempio Dns (Domain Name System) o Active Directory Services.

I componenti della subnet dell'infrastruttura seguenti devono essere pianificati e definiti prima di avviare la distribuzione in modo da poter prevedere qualsiasi routing, firewall o requisiti della subnet.

Driver della scheda di rete

Dopo aver installato il sistema operativo e prima di configurare la rete nei nodi, è necessario assicurarsi che le schede di rete abbiano il driver più recente fornito dal fornitore oem o dell'interfaccia di rete. Le funzionalità importanti delle schede di rete potrebbero non essere disponibili quando si usano i driver Microsoft predefiniti.

Pool IP di gestione

Quando si esegue la distribuzione iniziale del sistema Azure Stack HCI, è necessario definire un intervallo IP di indirizzi IP consecutivi per i servizi di infrastruttura distribuiti per impostazione predefinita.

Per garantire che l'intervallo disponga di indirizzi IP sufficienti per i servizi di infrastruttura correnti e futuri, è necessario usare un intervallo di almeno sei indirizzi IP disponibili consecutivi. Questi indirizzi vengono usati per : l'IP del cluster, la macchina virtuale del bridge di risorse di Azure e i relativi componenti.

Se si prevede di eseguire altri servizi nella rete dell'infrastruttura, è consigliabile assegnare un buffer aggiuntivo di indirizzi IP dell'infrastruttura al pool. È possibile aggiungere altri pool IP dopo la distribuzione per la rete di infrastruttura usando PowerShell se le dimensioni del pool pianificato originariamente vengono esaurite.

Le condizioni seguenti devono essere soddisfatte quando si definisce il pool IP per la subnet dell'infrastruttura durante la distribuzione:

#	Condizione
1	L'intervallo IP deve usare indirizzi IP consecutivi e tutti gli INDIRIZZI IP devono essere disponibili all'interno di tale intervallo.
2	L'intervallo di indirizzi IP non deve includere gli INDIRIZZI IP di gestione dei nodi del cluster, ma deve trovarsi nella stessa subnet dei nodi.
3	Il gateway predefinito definito per il pool IP di gestione deve fornire la connettività in uscita a Internet.
4	I server DNS devono garantire la risoluzione dei nomi con Active Directory e Internet.

ID VLAN di gestione

È consigliabile che la subnet di gestione del cluster Azure HCI usi la VLAN predefinita, che nella maggior parte dei casi viene dichiarata come ID VLAN 0. Tuttavia, se i requisiti di rete devono usare una VLAN di gestione specifica per la rete dell'infrastruttura, è necessario configurarlo nelle schede di rete fisiche che si prevede di usare per il traffico di gestione.

Se si prevede di usare due schede di rete fisiche per la gestione, è necessario impostare la VLAN in entrambe le schede. Questa operazione deve essere eseguita come parte della configurazione bootstrap dei server e prima di essere registrati in Azure Arc, per assicurarsi di registrare correttamente i nodi usando questa VLAN.

Per impostare l'ID VLAN nelle schede di rete fisiche, usare il comando powerShell seguente:

In questo esempio viene configurato l'ID VLAN 44 nella scheda di NIC1rete fisica.

Set-NetAdapter -Name "NIC1" -VlanID 44

Dopo aver impostato l'ID VLAN e gli INDIRIZZI IP dei nodi vengono configurati nelle schede di rete fisiche, l'agente di orchestrazione legge questo valore di ID VLAN dalla scheda di rete fisica usata per la gestione e lo archivia, in modo che possa essere usato per la macchina virtuale di Azure Resource Bridge o qualsiasi altra macchina virtuale infrastruttura necessaria durante la distribuzione. Non è possibile impostare l'ID VLAN di gestione durante la distribuzione cloud da portale di Azure perché ciò comporta il rischio di interrompere la connettività tra i nodi e Azure se l'opzione fisica non viene instradata correttamente.

ID VLAN di gestione con un commutatore virtuale

In alcuni scenari è necessario creare un commutatore virtuale prima dell'avvio della distribuzione.

Nota

Prima di creare un commutatore virtuale, assicurarsi di abilitare il ruolo Hype-V. Per altre informazioni, vedere Installare il ruolo windows richiesto.

Se è necessaria una configurazione del commutatore virtuale e è necessario usare un ID VLAN specifico, seguire questa procedura:

1. Creare un commutatore virtuale con convenzione di denominazione consigliata

Le distribuzioni di Azure Stack HCI si basano su Network ATC per creare e configurare le opzioni virtuali e le schede di rete virtuale per la gestione, il calcolo e le finalità di archiviazione. Per impostazione predefinita, quando Network ATC crea l'opzione virtuale per le finalità, usa un nome specifico per il commutatore virtuale.

Anche se non è necessario, è consigliabile assegnare una denominazione alle opzioni virtuali con la stessa convenzione di denominazione. Il nome consigliato per le opzioni virtuali è il seguente:

Nome dell'opzione virtuale: "ConvergedSwitch($IntentName)", Dove $IntentName può essere qualsiasi stringa. Questa stringa deve corrispondere al nome della scheda di rete virtuale per la gestione, come descritto nel passaggio successivo.

Nell'esempio seguente viene illustrato come creare l'opzione virtuale con PowerShell usando la convenzione di denominazione consigliata con $IntentName la descrizione dello scopo del commutatore virtuale. L'elenco dei nomi delle schede di rete è un elenco delle schede di rete fisiche che si prevede di usare per la gestione e il traffico di rete di calcolo:

$IntentName = "MgmtCompute"
New-VMSwitch -Name "ConvergedSwitch($IntentName)" -NetAdapterName "NIC1","NIC2" -EnableEmbeddedTeaming $true -AllowManagementOS $false

2. Configurare la scheda di rete virtuale di gestione usando la convenzione di denominazione network ATC necessaria per tutti i nodi

Dopo aver configurato il commutatore virtuale, è necessario creare la scheda di rete virtuale di gestione. Il nome della scheda di rete virtuale usata per il traffico di gestione deve usare la convenzione di denominazione seguente:

Nome della scheda di rete e della scheda di rete virtuale: vManagement($intentname).
Il nome è distinzione tra maiuscole e minuscole.
$Intentname può essere qualsiasi stringa, ma deve essere lo stesso nome usato per il commutatore virtuale.

Per aggiornare il nome della scheda di rete virtuale di gestione, usare il comando seguente:

$IntentName = "MgmtCompute"
Add-VMNetworkAdapter -ManagementOS -SwitchName "ConvergedSwitch($IntentName)" -Name "vManagement($IntentName)"

#NetAdapter needs to be renamed because during creation, Hyper-V adds the string “vEthernet “ to the beginning of the name

Rename-NetAdapter -Name "vEthernet (vManagement($IntentName))" -NewName "vManagement($IntentName)"

3. Configurare l'ID VLAN per la gestione della scheda di rete virtuale per tutti i nodi

Dopo aver creato l'opzione virtuale e la scheda di rete virtuale di gestione, è possibile specificare l'ID VLAN necessario per questa scheda. Sebbene siano disponibili opzioni diverse per assegnare un ID VLAN a una scheda di rete virtuale, l'unica opzione supportata consiste nell'usare il Set-VMNetworkAdapterIsolation comando.

Dopo aver configurato l'ID VLAN richiesto, è possibile assegnare l'indirizzo IP e i gateway alla scheda di rete virtuale di gestione per verificare che abbia connettività con altri nodi, DNS, Active Directory e Internet.

Nell'esempio seguente viene illustrato come configurare la scheda di rete virtuale di gestione per l'uso dell'ID VLAN 8 anziché l'impostazione predefinita:

Set-VMNetworkAdapterIsolation -ManagementOS -VMNetworkAdapterName "vManagement($IntentName)" -AllowUntaggedTraffic $true -IsolationMode Vlan -DefaultIsolationID

4. Fare riferimento alle schede di rete fisiche per la finalità di gestione durante la distribuzione

Anche se la scheda di rete virtuale appena creata mostra come disponibile quando si distribuisce tramite portale di Azure, è importante ricordare che la configurazione di rete è basata su Network ATC. Ciò significa che quando si configura la gestione o la finalità di calcolo e gestione, è comunque necessario selezionare le schede di rete fisiche usate per tale finalità.

Nota

Non selezionare la scheda di rete virtuale per la finalità di rete.

La stessa logica si applica ai modelli di Azure Resource Manager (ARM). È necessario specificare le schede di rete fisiche da usare per le finalità di rete e non le schede di rete virtuali.

Ecco le considerazioni riepilogate per l'ID VLAN:

#	Considerazioni
1	L'ID VLAN deve essere specificato nella scheda di rete fisica per la gestione prima di registrare i server con Azure Arc.
2	Usare passaggi specifici quando è necessario un commutatore virtuale prima di registrare i server in Azure Arc.
3	L'ID VLAN di gestione viene eseguito dalla configurazione host alle macchine virtuali dell'infrastruttura durante la distribuzione.
4	Non esiste alcun parametro di input ID VLAN per la distribuzione portale di Azure o per la distribuzione di modelli di Resource Manager.

Assegnazione IP del nodo e del cluster

Per il sistema Azure Stack HCI, sono disponibili due opzioni per assegnare indirizzi IP per i nodi del server e per l'IP del cluster.

Sono supportati sia i protocolli DHCP (Static e Dynamic Host Configuration Protocol).
L'assegnazione IP del nodo appropriata è chiave per la gestione del ciclo di vita del cluster. Decidere tra le opzioni statiche e DHCP prima di registrare i nodi in Azure Arc.
Macchine virtuali e servizi dell'infrastruttura, ad esempio Arc Resource Bridge e Controller di rete, continuano a usare indirizzi IP statici dal pool IP di gestione. Ciò implica che, anche se si decide di usare DHCP per assegnare gli INDIRIZZI IP ai nodi e all'INDIRIZZO IP del cluster, il pool IP di gestione è ancora necessario.

Le sezioni seguenti illustrano le implicazioni di ogni opzione.

Assegnazione IP statico

Se gli INDIRIZZI IP statici vengono usati per i nodi, il pool IP di gestione viene usato per ottenere un INDIRIZZO IP disponibile e assegnarlo automaticamente all'INDIRIZZO IP del cluster durante la distribuzione.

È importante usare indirizzi IP di gestione per i nodi che non fanno parte dell'intervallo IP definito per il pool IP di gestione. Gli INDIRIZZI IP del nodo server devono trovarsi nella stessa subnet dell'intervallo IP definito.

È consigliabile assegnare un solo INDIRIZZO IP di gestione per il gateway predefinito e per i server DNS configurati per tutte le schede di rete fisiche del nodo. Ciò garantisce che l'INDIRIZZO IP non cambi una volta creata la finalità di rete di gestione. Ciò garantisce inoltre che i nodi mantengano la connettività in uscita durante il processo di distribuzione, incluso durante la registrazione di Azure Arc.

Per evitare problemi di routing e per identificare quale IP verrà usato per la connettività in uscita e la registrazione arc, portale di Azure convalida se è configurato più di un gateway predefinito.

Se un commutatore virtuale e una scheda di rete virtuale di gestione sono stati creati durante la configurazione del sistema operativo, l'IP di gestione per il nodo deve essere assegnato a tale scheda di rete virtuale.

Assegnazione IP DHCP

Se gli indirizzi IP per i nodi vengono acquisiti da un server DHCP, viene usato anche un INDIRIZZO IP dinamico per l'IP del cluster. Le macchine virtuali e i servizi dell'infrastruttura richiedono comunque indirizzi IP statici e ciò implica che l'intervallo di indirizzi del pool IP di gestione deve essere escluso dall'ambito DHCP usato per i nodi e l'IP del cluster.

Ad esempio, se l'intervallo IP di gestione è definito come 192.168.1.20/24 a 192.168.1.30/24 per gli INDIRIZZI IP statici dell'infrastruttura, l'ambito DHCP definito per la subnet 192.168.1.0/24 deve avere un'esclusione equivalente al pool IP di gestione per evitare conflitti IP con i servizi di infrastruttura. È anche consigliabile usare le prenotazioni DHCP per gli INDIRIZZI IP del nodo.

Il processo di definizione dell'IP di gestione dopo la creazione della finalità di gestione prevede l'uso dell'indirizzo MAC della prima scheda di rete fisica selezionata per la finalità di rete. Questo indirizzo MAC viene quindi assegnato alla scheda di rete virtuale creata a scopo di gestione. Ciò significa che il primo indirizzo IP ottenuto dalla prima scheda di rete fisica dal server DHCP è lo stesso indirizzo IP usato dalla scheda di rete virtuale come IP di gestione. Pertanto, è importante creare una prenotazione DHCP per l'INDIRIZZO IP del nodo.

Considerazioni sull'IP del nodo del cluster

Ecco le considerazioni riepilogate per gli indirizzi IP:

#	Considerazioni
1	Gli INDIRIZZI IP del nodo devono trovarsi nella stessa subnet dell'intervallo di pool IP di gestione definito, indipendentemente dal fatto che siano indirizzi statici o dinamici.
2	Il pool IP di gestione non deve includere indirizzi IP del nodo. Usare le esclusioni DHCP quando viene usata l'assegnazione dinamica DI IP.
3	Usare le prenotazioni DHCP per i nodi il più possibile.
4	Gli indirizzi DHCP sono supportati solo per gli INDIRIZZI IP del nodo e l'INDIRIZZO IP del cluster. I servizi di infrastruttura usano indirizzi IP statici dal pool di gestione.
5	L'indirizzo MAC dalla prima scheda di rete fisica viene assegnato alla scheda di rete virtuale di gestione dopo la creazione della finalità di rete di gestione.

Requisiti del proxy

Un proxy è probabilmente necessario accedere a Internet all'interno dell'infrastruttura locale. Azure Stack HCI supporta solo configurazioni proxy non autenticate. Dato che l'accesso a Internet è necessario per registrare i nodi in Azure Arc, la configurazione del proxy deve essere impostata come parte della configurazione del sistema operativo prima della registrazione dei nodi del server. Per altre informazioni, vedere Configurare le impostazioni proxy.

Il sistema operativo Azure Stack HCI include tre diversi servizi (WinInet, WinHTTP e variabili di ambiente) che richiedono la stessa configurazione proxy per garantire che tutti i componenti del sistema operativo possano accedere a Internet. La stessa configurazione proxy usata per i nodi viene eseguita automaticamente nella macchina virtuale Arc Resource Bridge e nel servizio Azure Kubernetes, assicurandosi che abbiano accesso a Internet durante la distribuzione.

Ecco le considerazioni riepilogate per la configurazione del proxy:

#	Considerazioni
1	Prima di registrare i nodi in Azure Arc, è necessario completare la configurazione del proxy.
2	La stessa configurazione proxy deve essere applicata per le variabili winINET, WinHTTP e di ambiente.
3	Il controllo ambiente garantisce che la configurazione del proxy sia coerente tra tutti i componenti proxy.
4	La configurazione proxy della macchina virtuale Arc Resource Bridge e del servizio Azure Kubernetes viene eseguita automaticamente dall'agente di orchestrazione durante la distribuzione.
5	Sono supportati solo i proxy non autenticati.

Requisiti del firewall

È attualmente necessario aprire diversi endpoint Internet nei firewall per assicurarsi che Azure Stack HCI e i relativi componenti possano connettersi correttamente. Per un elenco dettagliato degli endpoint necessari, vedere Requisiti del firewall.

Prima di registrare i nodi in Azure Arc, è necessario eseguire la configurazione del firewall. È possibile usare la versione autonoma del controllo dell'ambiente per verificare che i firewall non blocchino il traffico inviato a questi endpoint. Per altre informazioni, vedere Controllo dell'ambiente HCI di Azure Stack per valutare la conformità alla distribuzione per Azure Stack HCI.

Ecco le considerazioni riepilogate per il firewall:

#	Considerazioni
1	Prima di registrare i nodi in Azure Arc, è necessario eseguire la configurazione del firewall.
2	Il controllo dell'ambiente in modalità autonoma può essere usato per convalidare la configurazione del firewall.

Passaggio 5: Determinare la configurazione della scheda di rete

Le schede di rete sono qualificate dal tipo di traffico di rete (gestione, calcolo e archiviazione) usate. Durante la revisione del catalogo di Windows Server, la certificazione Windows Server 2022 indica per quale traffico di rete sono qualificate le schede.

Prima di acquistare un server per Azure Stack HCI, è necessario disporre di almeno una scheda qualificata per la gestione, il calcolo e l'archiviazione in quanto sono necessari tutti e tre i tipi di traffico in Azure Stack HCI. La distribuzione cloud si basa su Network ATC per configurare le schede di rete per i tipi di traffico appropriati, quindi è importante usare schede di rete supportate.

I valori predefiniti usati da Network ATC sono documentati nelle impostazioni di rete del cluster. È consigliabile usare i valori predefiniti. Con questo detto, se necessario, è possibile eseguire l'override delle opzioni seguenti usando modelli di portale di Azure o ARM:

VLAN di archiviazione: impostare questo valore sulle reti virtuali necessarie per l'archiviazione.
Pacchetti Jumbo: definisce le dimensioni dei pacchetti jumbo.
Network Direct: impostare questo valore su false se si vuole disabilitare RDMA per le schede di rete.
Tecnologia diretta di rete: impostare questo valore su RoCEv2 o iWarp.
Priorità del traffico Datacenter Bridging (DCB): impostare le priorità che soddisfano i requisiti. È consigliabile usare i valori DCB predefiniti in quanto vengono convalidati da Microsoft e dai clienti.

Ecco le considerazioni riepilogate per la configurazione della scheda di rete:

#	Considerazioni
1	Usare le configurazioni predefinite il più possibile.
2	I commutatori fisici devono essere configurati in base alla configurazione della scheda di rete. Vedere Requisiti di rete fisica per Azure Stack HCI.
3	Assicurarsi che le schede di rete siano supportate per Azure Stack HCI usando Windows Server Catalog.
4	Quando si accettano le impostazioni predefinite, Network ATC configura automaticamente gli INDIRIZZI IP e le reti virtuali della scheda di archiviazione. Questa operazione è nota come Configurazione IP automatica dell'archiviazione. In alcuni casi, l'IP automatico dell'archiviazione non è supportato e è necessario dichiarare ogni ip della scheda di rete di archiviazione usando i modelli di Resource Manager.

Passaggi successivi

Informazioni sulla distribuzione di Azure Stack HCI versione 23H2.