Considerazioni sulla rete per le distribuzioni cloud di Azure locale

Si applica a: Azure Local 2311.2 e versioni successive

Questo articolo illustra come progettare e pianificare una rete di sistema locale di Azure per la distribuzione cloud. Prima di continuare, acquisire familiarità con i vari modelli di rete locali di Azure 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 l'istanza locale di Azure: 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 abilita o consente le opzioni di progettazione disponibili nei passaggi successivi:

Passaggio 1: Determinare le dimensioni del cluster

Per determinare le dimensioni dell'istanza locale di Azure, usa lo strumento Azure Local sizer tool, dove puoi definire il tuo profilo come il numero di macchine virtuali, le dimensioni delle macchine virtuali e l'uso del carico di lavoro delle macchine virtuali, come Azure Virtual Desktop, SQL Server o AKS.

Come descritto nell'articolo Requisiti del computer locale di Azure, il numero massimo di computer supportati nell'istanza locale di Azure è 16. Dopo aver completato la pianificazione della capacità del carico di lavoro, è necessario avere una buona conoscenza del numero di nodi del computer 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 dell'istanza locale di Azure, vedere Panoramica dei modelli di riferimento di rete.

• Se i carichi di lavoro richiedono tre o meno nodi: è possibile scegliere configurazioni senza switch o con switch per la connettività di storage.

• Se si prevede di aumentare il numero di nodi oltre tre: è necessario usare un commutatore fisico per il traffico di rete dello storage. Qualsiasi operazione di scalabilità per le distribuzioni senza switch richiede la configurazione manuale del cablaggio di rete tra i nodi, che Microsoft non convalida attivamente come parte del suo ciclo di sviluppo software per Azure Locale.

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

Decisione	Considerazioni
Dimensioni del cluster (numero di nodi per cluster)	La configurazione senza switch tramite il portale di Azure o i modelli di Azure Resource Manager è disponibile solo per cluster a 1, 2 o 3 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 scalare il cluster usando l'orchestratore, è necessario usare un commutatore fisico per il traffico sulla rete di archiviazione.

Passaggio 2: Determinare la connettività di archiviazione del cluster

Come descritto in Requisiti di rete fisica, Azure locale 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 riguardante la connettività dello storage influenza il numero e il tipo di intenzioni di rete che è possibile definire nel passaggio successivo.

Ad esempio, per le configurazioni senza switch, è necessario definire due intenti 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 intento di rete con una sola porta dell'adattatore di rete fisica, ciò non fornisce alcuna tolleranza ai guasti. 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 switch tramite portale di Azure o distribuzione di modelli di Resource Manager è supportata solo per cluster di 1, 2 o 3 nodi. È possibile distribuire cluster di archiviazione senza switch a 1 o 2 nodi usando il portale di Azure o i modelli di Resource Manager. 3 cluster di archiviazione senza switch dei nodi possono essere implementati solo usando i template di Resource Manager. Le operazioni di scalabilità orizzontale non sono supportate con le distribuzioni senza switch. 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 intendi scalare il tuo cluster usando l'orchestratore, devi utilizzare 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 Locale di Azure, 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 Local 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. Gli adattatori di rete assegnati a questo scopo 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 hai bisogno di un'architettura senza switch, non puoi usare questo tipo di intento. Il Portale di Azure filtra automaticamente questa opzione selezionando una configurazione senza switch per la connettività di archiviazione.

• Sono consigliate almeno due porte della scheda di rete per garantire l'alta disponibilità.

• Sono necessarie interfacce di rete almeno da 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 con e senza switch, se:

• Sono disponibili almeno due porte degli adattatori di rete per ciascun intento per garantire un'alta disponibilità.

• 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 interfacce di rete di 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 intento deve usare un set diverso di porte dell'adattatore 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 richiedi una configurazione senza interruttore, non puoi utilizzare questo tipo di intento. Il portale di Azure filtra automaticamente questa opzione se si seleziona una configurazione senza interruttori per la connessione di archiviazione.

• Questa opzione richiede un commutatore fisico per RDMA.

• Per garantire la disponibilità elevata, sono consigliabili almeno due porte della scheda di rete.

• Si raccomanda di utilizzare interfacce di rete da almeno 10 Gbps per l'intento di calcolo e archiviazione, al fine di supportare il traffico RDMA.

• 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 con commutazione e senza commutazione se lo scopo di archiviazione è diverso dagli altri scopi.

• 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, si consiglia di utilizzare interfacce di rete di almeno 10 Gbps per il calcolo e l'archiviazione.

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 dell'istanza locale di Azure, è 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 dell'istanza locale di Azure usi la VLAN predefinita, che nella maggior parte dei casi viene dichiarata come ID VLAN 0. Tuttavia, se i tuoi requisiti di rete prevedono l'utilizzo di una VLAN di gestione specifica per la rete della tua infrastruttura, è necessario configurarla sulle 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 computer e prima che vengano registrate 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 rete fisica NIC1.

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 ulteriori 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 locali di Azure 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

Nota

Dopo la distribuzione di un'istanza locale di Azure, la modifica del nome della finalità di gestione o del nome del commutatore virtuale non è supportata. Se è necessario aggiornare o ricreare la finalità dopo la distribuzione, è necessario usare lo stesso nome di finalità e lo stesso nome del commutatore virtuale.

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. Assicurati di usare la stessa stringa nel portale di Azure quando si definisce il nome dell'intento Mgmt.

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 computer con Azure Arc.
2	Usare passaggi specifici quando è necessario un commutatore virtuale prima di registrare i computer 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 sottorete	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 ARM 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'istanza locale di Azure a due nodi con switch di rete per l'archiviazione, in cui gli indirizzi IP di archiviazione sono personalizzati Implementazione a 2 nodi con indirizzi IP di archiviazione personalizzati

Assegnazione ip del nodo e del cluster

Per l'istanza locale di Azure sono disponibili due opzioni per assegnare indirizzi IP per i nodi del computer 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 del nodo del computer 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.

Considerazioni sul server DNS

Le distribuzioni locali di Azure basate su Active Directory richiedono un server DNS in grado di risolvere il dominio locale e gli endpoint pubblici Internet. Nell'ambito della distribuzione è necessario definire gli stessi server DNS per l'intervallo di indirizzi IP dell'infrastruttura configurato nei nodi. La VM del piano di controllo di Azure Resource Bridge e il piano di controllo di AKS useranno gli stessi server DNS per la risoluzione dei nomi. Al termine della distribuzione, non è supportato modificare gli indirizzi IP dei server DNS e non sarà possibile aggiornare gli indirizzi nello stack della piattaforma locale di Azure.

I server DNS usati per Azure Local devono essere esterni e operativi prima della distribuzione. Non è supportata l'esecuzione come macchine virtuali locali di Azure.

Ecco le considerazioni riepilogate per gli indirizzi dei server DNS:

#	Considerazioni
1	I server DNS in tutti i nodi del cluster devono essere uguali.
2	I server DNS dell'intervallo di indirizzi IP dell'infrastruttura devono essere gli stessi usati per i nodi.
3	Il piano di controllo delle VM di Azure Resource Bridge e il piano di controllo di AKS utilizzeranno i Server DNS configurati nell'intervallo di indirizzi IP dell'infrastruttura.
4	Non è supportato modificare i server DNS dopo la distribuzione. Assicurarsi di pianificare la strategia DNS prima di eseguire la distribuzione locale di Azure.
5	Quando si definisce un array di più server DNS in un modello di ARM per la rete di infrastruttura, assicurarsi che ogni valore sia racchiuso tra virgolette "" e separato da virgole, come nell'esempio seguente.
6	Non è supportato eseguire i server DNS usati dall'infrastruttura locale di Azure nelle macchine virtuali in esecuzione all'interno dell'istanza locale di Azure.

"dnsServers": [
                        "10.250.16.124",
                        "10.250.17.232",
                        "10.250.18.107"
                    ]

Requisiti del proxy

Un proxy è probabilmente necessario per accedere a Internet all'interno dell'infrastruttura locale. Azure Local 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 computer. 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 ad AKS, assicurando loro 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 WinINET, WinHTTP e le variabili di ambiente.
3	Il Controllo ambiente garantisce che la configurazione del proxy sia coerente in tutti i componenti del 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 Locale 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 locale di Azure per valutare l'idoneità alla distribuzione per Azure Locale.

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 classificate in base al tipo di traffico di rete (gestione, calcolo e archiviazione) con cui vengono utilizzate. 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 computer per l'ambiente locale di Azure, è necessario disporre di almeno una scheda qualificata per la gestione, il calcolo e l'archiviazione, perché tutti e tre i tipi di traffico sono necessari in Locale di Azure. 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: imposta il valore su false se vuoi disabilitare RDMA per le schede di rete.
• Tecnologia di rete diretta: impostare questo valore su RoCEv2 o iWarp.
• Priorità del traffico Datacenter Bridging (DCB): imposta le priorità che soddisfano i tuoi 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 Locale.
3	Assicurarsi che le proprie schede di rete siano supportate per Azure Locale usando il Catalogo 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 per l'archiviazione. In alcuni casi, l'IP automatico dell'archiviazione non è supportato ed è necessario specificare l'IP di ciascun adattatore di rete di archiviazione utilizzando i modelli di Resource Manager.

Passaggi successivi

• Informazioni sulla distribuzione locale di Azure.