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

Si applica a: Locale di Azure, versione 23H2

Questo articolo illustra come progettare e pianificare una rete di sistema locale di Azure versione 23H2 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, usare lo strumento Di ridimensionatore locale di Azure, 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 computer di sistema 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 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 aumento del numero di istanze 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 locale.

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

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

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

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

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

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à.

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:

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:

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'istanza locale di Azure a due nodi con commutatore di rete per l'archiviazione, in cui gli indirizzi IP di archiviazione sono personalizzati 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 relative ai server DNS

Le distribuzioni locali di Azure basate su Active Directory richiedono un server DNS in grado di risolvere il dominio in sede e gli endpoint pubblici di 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.

Ecco le considerazioni riepilogate per gli indirizzi dei server DNS

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

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:

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

Passaggi successivi

• Informazioni sulla distribuzione locale di Azure versione 23H2.