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

Articolo
10/31/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 del cluster, finalità del traffico di rete, connettività di gestione e configurazione della scheda di rete. Ogni decisione di progettazione abilita 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 ridimensionatore Azure Stack HCI, 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 di Azure Stack HCI, 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 conoscenza del numero di nodi del server necessari per eseguire i 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. È necessario includere un commutatore fisico con supporto per Remote Direct Memory Access (RDMA) per gestire il traffico di archiviazione. Per altre informazioni sull'architettura di rete del cluster Azure Stack HCI, vedere Panoramica dei modelli di riferimento di rete.
Se i carichi di lavoro richiedono tre o meno nodi: è possibile scegliere configurazioni senza cambio o commutato 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 cambio richiede la configurazione manuale del cablaggio 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 di portale di Azure o Azure Resource Manager è disponibile solo per 1, 2 o 3 cluster a nodi. I cluster con 4 o più nodi richiedono un commutatore fisico per il traffico di rete di archiviazione.
Requisiti di scalabilità orizzontale	Se si intende aumentare il numero di istanze del 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.
Collegare direttamente i nodi tra di essi con cavi di rete o fiber crossover per il traffico di archiviazione.

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

Come indicato in precedenza, è possibile decidere tra le due opzioni solo 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à dell'archiviazione influenza il numero e il tipo di finalità di rete che è possibile definire nel passaggio successivo.

Ad esempio, per le configurazioni senza cambio, è necessario definire due finalità del traffico di rete. Il traffico di archiviazione per le comunicazioni est-ovest che usano 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 di gestione e per i carichi di lavoro di calcolo.

Sebbene sia 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, inclusa l'archiviazione in una singola finalità di rete, nota anche come configurazione di rete host iperconvergente o completamente convergente .

Di seguito sono riportate le considerazioni riepilogate per la decisione sulla connettività dell'archiviazione cluster:

Decisione	Considerazioni
Nessun commutatore per l'archiviazione	La configurazione senza cambio tramite portale di Azure o la distribuzione di modelli di Resource Manager è supportata solo per i cluster a 1, 2 o 3 nodi. È possibile distribuire cluster senza cambio di archiviazione a 1 o 2 nodi usando i modelli di portale di Azure o Resource Manager. 3 cluster senza cambio di archiviazione dei nodi possono essere distribuiti 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 aumentare il numero di istanze del cluster usando l'agente di orchestrazione, è necessario usare un commutatore fisico per il traffico di rete di archiviazione. È possibile usare questa architettura con un numero qualsiasi di nodi compreso 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 la distribuzione di modelli di Resource Manager è supportata solo per i cluster a 1, 2 o 3 nodi.

È possibile distribuire cluster senza cambio di archiviazione a 1 o 2 nodi usando i modelli di portale di Azure o Resource Manager.

3 cluster senza cambio di archiviazione dei nodi possono essere distribuiti 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 aumentare il numero di istanze del cluster usando l'agente di orchestrazione, è necessario usare un commutatore fisico per il traffico di rete di archiviazione.

È possibile usare questa architettura con un numero qualsiasi di nodi compreso 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 il portale di Azure. Per altre informazioni sulle finalità di rete e su come risolverle, vedere Comandi ATC di rete comuni.

Questa sezione illustra le implicazioni della decisione di progettazione per le finalità del traffico di rete e il modo in cui influiscono sul passaggio successivo del framework. Per le distribuzioni cloud, è possibile scegliere 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 disponibili per le finalità di rete sono descritte nelle sezioni seguenti.

Finalità di rete: raggruppare tutto il traffico

Network ATC configura una finalità univoca che include il traffico di rete di gestione, calcolo e archiviazione. Le schede di rete assegnate a questa finalità condividono la larghezza di banda e la 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.
Sono consigliate almeno due porte della scheda di rete per garantire la disponibilità elevata.
Per supportare il traffico RDMA per l'archiviazione sono necessarie almeno 10 Gbps.

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 cambio, se:

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

Finalità di rete: raggruppare il traffico di calcolo e 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 vengono condivise con il traffico di calcolo, che richiede 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.
Per garantire la disponibilità elevata, è consigliabile almeno due porte della scheda di rete.
Per supportare il traffico RDMA, è consigliabile usare almeno interfacce di rete da 10 Gbps.
Anche quando la finalità di gestione viene dichiarata senza finalità di calcolo, Network ATC crea un commutatore virtuale Switch Embedded Teaming (SET) per fornire 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 remota, 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.
Per supportare il traffico RDMA, è consigliabile usare almeno interfacce di rete da 10 Gbps.

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

Passaggio 4: Determinare la connettività di rete di gestione e archiviazione

In questo passaggio si definisce lo spazio 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 prevedere eventuali requisiti di routing, firewall o 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 dispongano del driver più recente fornito dall'OEM o dal fornitore dell'interfaccia di rete. Le funzionalità importanti delle schede di rete potrebbero non essere presenti 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 dell'infrastruttura usando PowerShell se le dimensioni del pool pianificato in origine vengono esaurite.

Quando si definisce il pool IP per la subnet dell'infrastruttura durante la distribuzione, è necessario soddisfare le condizioni seguenti:

#	Condizione
1	L'intervallo IP deve usare indirizzi IP consecutivi e tutti gli INDIRIZZI IP devono essere disponibili all'interno di tale intervallo. Questo intervallo IP non può essere modificato dopo la distribuzione.
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 di indirizzi 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.
5	Gli indirizzi IP di gestione richiedono l'accesso a Internet in uscita.

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 configurarla 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 di 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 aver configurato gli INDIRIZZI IP dei nodi nelle schede di rete fisiche, l'agente di orchestrazione legge questo valore 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 per qualsiasi altra macchina virtuale dell'infrastruttura necessaria durante la distribuzione. Non è possibile impostare l'ID VLAN di gestione durante la distribuzione cloud da portale di Azure perché questo comporta il rischio di interrompere la connettività tra i nodi e Azure se le VLAN del commutatore fisico non vengono instradate 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 ed è necessario usare un ID VLAN specifico, seguire questa procedura:

1. Creare un commutatore virtuale con la convenzione di denominazione consigliata

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

È consigliabile denominare i nomi dei commutatori virtuali con la stessa convenzione di denominazione. Il nome consigliato per i commutatori virtuali è il seguente:

"ConvergedSwitch($IntentName)", dove $IntentName deve corrispondere al nome della finalità digitata nel portale durante la distribuzione. Questa stringa deve corrispondere anche al nome della scheda di rete virtuale usata per la gestione, come descritto nel passaggio successivo.

L'esempio seguente illustra come creare il commutatore virtuale con PowerShell usando la convenzione di denominazione consigliata con $IntentName. 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 $true

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

Dopo aver creato il commutatore virtuale e la scheda di rete virtuale di gestione associata, assicurarsi che il nome della scheda di rete sia conforme agli standard di denominazione network ATC.

In particolare, il nome della scheda di rete virtuale usata per il traffico di gestione deve usare le convenzioni seguenti:

Il nome della scheda di rete e della scheda di rete virtuale deve usare vManagement($intentname).
Questo nome fa distinzione tra maiuscole e minuscole.
$Intentname può essere qualsiasi stringa, ma deve essere lo stesso nome usato per il commutatore virtuale. Assicurarsi di usare la stessa stringa in portale di Azure quando si definisce il nome della Mgmt finalità.

Per aggiornare il nome della scheda di rete virtuale di gestione, usare i comandi seguenti:

$IntentName = "MgmtCompute"

#Rename VMNetworkAdapter for management because during creation, Hyper-V uses the vSwitch name for the virtual network adapter.
Rename-VmNetworkAdapter -ManagementOS -Name "ConvergedSwitch(MgmtCompute)" -NewName "vManagement(MgmtCompute)"

#Rename NetAdapter because during creation, Hyper-V adds the string “vEthernet” to the beginning of the name.
Rename-NetAdapter -Name "vEthernet (ConvergedSwitch(MgmtCompute))" -NewName "vManagement(MgmtCompute)"

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

Dopo aver creato il commutatore virtuale e la scheda di rete virtuale di gestione, è possibile specificare l'ID VLAN necessario per questa scheda. Anche se sono 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 necessario, è 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 in modo da usare l'ID 8 VLAN anziché l'impostazione predefinita:

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

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

Sebbene la scheda di rete virtuale appena creata sia disponibile durante la distribuzione 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 gestione e calcolo, è 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. È necessario specificare le schede di rete fisiche che si desidera utilizzare per le finalità di rete e mai le schede di rete virtuale.

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 trasportato 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 del modello di Resource Manager.

Indirizzi IP personalizzati per l'archiviazione

Per impostazione predefinita, network ATC assegnerà automaticamente gli indirizzi IP e le VLAN per l'archiviazione dalla tabella seguente:

Adattatore di archiviazione	Indirizzo IP e subnet	VLAN
pNIC1	10.71.1.x	711
pNIC2	10.71.2.x	712
pNIC3	10.71.3.x	713

Tuttavia, se i requisiti di distribuzione non rientrano in tali indirizzi IP e VLAN predefiniti, è possibile usare indirizzi IP, subnet e VLAN personalizzati per l'archiviazione. Questa funzionalità è disponibile solo quando si distribuiscono cluster usando modelli di Resource Manager ed è necessario specificare i parametri seguenti nel modello.

enableStorageAutoIP: questo parametro, quando non viene specificato è impostato su true. Per abilitare gli INDIRIZZI IP di archiviazione personalizzati durante la distribuzione, questo parametro deve essere impostato su false.
storageAdapterIPInfo: questo parametro ha una dipendenza con il parametro "enableStorageAutoIP" ed è sempre obbligatorio quando il parametro IP automatico dell'archiviazione è impostato su false. All'interno del parametro "storageAdapterIPInfo" nel modello arm è necessario specificare anche i parametri "ipv4Address" e "subnetMask" per ogni nodo e scheda di rete con i propri INDIRIZZI IP e subnet mask.
vlanId: come descritto in precedenza nella tabella, questo parametro userà le VLAN predefinite di Network ATC se non è necessario modificarle. Tuttavia, se le VLAN predefinite non funzionano nella rete, è possibile specificare i propri ID VLAN per ognuna delle reti di archiviazione.

Il modello di Resource Manager seguente include un esempio di un cluster HCI a due nodi con commutatore di rete per l'archiviazione, in cui gli indirizzi IP di archiviazione sono personalizzati 2 nodi di distribuzione con indirizzi IP di archiviazione personalizzati

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 che Dynamic Host Configuration Protocol).
L'assegnazione IP del nodo corretta è fondamentale per la gestione del ciclo di vita del cluster. Scegliere tra le opzioni statiche e DHCP prima di registrare i nodi in Azure Arc.
Le macchine virtuali e i servizi dell'infrastruttura, ad esempio Arc Resource Bridge e Controller di rete, continuano a usare indirizzi IP statici dal pool di indirizzi IP di gestione. Ciò implica che anche se si decide di usare DHCP per assegnare gli indirizzi IP ai nodi e all'IP del cluster, il pool di indirizzi IP di gestione è ancora necessario.

Le sezioni seguenti illustrano le implicazioni di ogni opzione.

Assegnazione ip statica

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

È importante usare gli INDIRIZZI IP di gestione per i nodi che non fanno parte dell'intervallo IP definito per il pool di indirizzi IP di gestione. Gli indirizzi IP dei nodi del 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. In questo modo si garantisce che l'INDIRIZZO IP non cambi una volta creata la finalità di rete di gestione. Ciò garantisce anche 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 di Arc, portale di Azure convalida se è configurato più di un gateway predefinito.

Se durante la configurazione del sistema operativo sono stati creati un commutatore virtuale e una scheda di rete virtuale di gestione, 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 comporta 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 l'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. È quindi importante creare una prenotazione DHCP per l'INDIRIZZO IP del nodo.

La logica di convalida di rete usata durante la distribuzione cloud avrà esito negativo se rileva più interfacce di rete fisiche con un gateway predefinito nella configurazione. Se è necessario usare DHCP per le assegnazioni IP host, è necessario creare in precedenza il commutatore virtuale SET (switch embedded teaming) e la scheda di rete virtuale di gestione come descritto in precedenza, quindi solo la scheda di rete virtuale di gestione acquisisce un indirizzo IP dal server DHCP.

Considerazioni sull'IP del nodo del cluster

Ecco le considerazioni riepilogate per gli indirizzi IP:

#	Considerazioni
1	Gli indirizzi IP dei nodi 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 di indirizzi IP di gestione non deve includere indirizzi IP del nodo. Usare le esclusioni DHCP quando viene usata l'assegnazione IP dinamica.
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'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 per 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 automaticamente trasportata alla macchina virtuale Arc Resource Bridge e al servizio Azure Kubernetes, assicurandosi di avere accesso a Internet durante la distribuzione.

Di seguito sono riportate 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 di ambiente WinINET, WinHTTP e WinINET.
3	Controllo ambiente garantisce che la configurazione del proxy sia coerente in 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 Azure Stack HCI per valutare l'idoneità della 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	Controllo 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) con cui vengono usate. Quando si esamina il catalogo di Windows Server, la certificazione Windows Server 2022 indica per quale traffico di rete le schede sono qualificate.

Prima di acquistare un server per Azure Stack HCI, è necessario avere almeno una scheda qualificata per la gestione, il calcolo e l'archiviazione perché tutti e tre i tipi di traffico sono necessari 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 in Impostazioni di rete del cluster. È consigliabile usare i valori predefiniti. Se necessario, è possibile eseguire l'override delle opzioni seguenti usando portale di Azure o modelli di Resource Manager:

VLAN di archiviazione: impostare questo valore sulle VLAN 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 di rete diretta: 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 perché 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 fisici per Azure Stack HCI.
3	Assicurarsi che le schede di rete siano supportate per Azure Stack HCI usando il catalogo di Windows Server.
4	Quando si accettano le impostazioni predefinite, Network ATC configura automaticamente gli INDIRIZZI IP e le VLAN della scheda di rete di archiviazione. Questa operazione è nota come configurazione IP automatico dell'archiviazione. In alcuni casi, l'ip automatico dell'archiviazione non è supportato ed è 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.

Condividi tramite