Esaminare il modello di riferimento della rete di distribuzione a doppio collegamento per l'archiviazione a tre nodi senza commutatori, doppio tor per Azure locale
> Si applica a: Locale di Azure, versione 23H2 e successive
In questo articolo vengono fornite informazioni sullo switchless di archiviazione a tre nodi con due commutatori TOR L3 e due modelli di riferimento di rete con collegamenti full-mesh che è possibile usare per distribuire la soluzione locale di Azure.
Nota
I modelli di riferimento di rete senza cambio nodo descritti in questo articolo sono stati testati e convalidati da Microsoft. Per informazioni sui modelli di rete senza commutatori a due nodi, vedere Modelli di distribuzione della rete locale di Azure.
Scenari
Gli scenari per questo modello di rete includono laboratori, fabbriche, succursali e data center.
Prendere in considerazione l'implementazione di questo modello quando si cerca una soluzione conveniente con tolleranza di errore in tutti i componenti di rete. I servizi SDN L3 sono completamente supportati in questo modello. I servizi di routing come BGP (Border Gateway Protocol) possono essere configurati direttamente nelle opzioni TOR se supportano i servizi L3. Le funzionalità di sicurezza di rete, ad esempio la micro segmentazione o QoS, non richiedono una configurazione aggiuntiva del dispositivo firewall, perché vengono implementate a livello di scheda di rete virtuale.
Componenti di connettività fisica
Come illustrato nel diagramma precedente, questo modello include i componenti di rete fisica seguenti:
Per la comunicazione verso nord e verso sud, l'istanza locale di Azure richiede due commutatori TOR nella configurazione MLAG (Multi-Chassis Link Aggregation Group).
Due schede di rete che usano il commutatore virtuale SET per gestire la gestione e il traffico di calcolo, connessi ai commutatori TOR. Ogni scheda di interfaccia di rete è connessa a un tor diverso.
Quattro schede di interfaccia di rete RDMA in ogni nodo in una configurazione a doppio collegamento mesh completa per il traffico East-West per l'archiviazione. Ogni nodo del sistema ha una connessione ridondante con due percorsi all'altro nodo del sistema.
| Reti | Gestione e calcolo | Storage |
|---|---|---|
| Velocità di collegamento | Almeno 1 GBps. 10 GBps consigliato | Almeno 10 GBps |
| Tipo interfaccia | RJ45, SFP+ o SFP28 | SFP+ o SFP28 |
| Porte e aggregazioni | Due porte in team | Quattro porte autonome |
Reti logiche
Come illustrato nel diagramma seguente, questo modello include i componenti di rete logici seguenti:
Reti di interconnessione dei nodi VLAN per il traffico SMB (archiviazione e migrazione in tempo reale)
Il traffico basato sulle finalità di archiviazione è costituito da sei singole subnet che supportano il traffico RDMA. Ogni interfaccia è dedicata a una rete di interconnessione dei nodi separata. Questo traffico è destinato solo a spostarsi tra i tre nodi. Il traffico di archiviazione in queste subnet è isolato senza connettività ad altre risorse.
Ogni coppia di adattatori di archiviazione tra i nodi opera in subnet IP diverse. Per abilitare una configurazione senza cambio, ogni nodo connesso supporta la stessa subnet corrispondente del relativo adiacente.
Quando si distribuiscono tre nodi in una configurazione senza commutatori, Network ATC ha i requisiti seguenti:
Supporta solo una singola VLAN per tutte le subnet IP usate per la connettività di archiviazione.
StorageAutoIPil parametro deve essere impostato su false,Switchlessil parametro deve essere impostato su true e l'utente è responsabile di specificare gli indirizzi IP nel modello di Resource Manager usato per distribuire l'istanza locale di Azure da Azure.Per le distribuzioni cloud locale di Azure versione 23H2:
I sistemi senza cambio di archiviazione con scalabilità orizzontale non sono supportati.
È possibile distribuire questo scenario a tre nodi solo usando i modelli di Resource Manager.
Per altre informazioni, vedere Distribuire tramite il modello di distribuzione di Azure Resource Manager.
VLAN di gestione
Tutti gli host di calcolo fisici devono accedere alla rete logica di gestione. Ai fini della pianificazione degli indirizzi IP, ogni host deve avere almeno un indirizzo IP assegnato dalla rete logica di gestione.
Un server DHCP può assegnare automaticamente indirizzi IP per la rete di gestione oppure assegnare manualmente indirizzi IP statici. Quando DHCP è il metodo di assegnazione IP preferito, sono consigliate le prenotazioni DHCP senza scadenza.
Per informazioni, vedere Considerazioni sulla rete DHCP per la distribuzione cloud.
La rete di gestione supporta due diverse configurazioni VLAN per il traffico: nativo e contrassegnato:
La VLAN nativa per la rete di gestione non richiede di fornire un ID VLAN.
La VLAN con tag per la rete di gestione richiede la configurazione dell'ID VLAN nelle schede di rete fisiche o nella scheda di rete virtuale di gestione prima di registrare i nodi in Azure Arc.
Le porte del commutatore fisico devono essere configurate correttamente per accettare l'ID VLAN nelle schede di gestione.
Se la finalità include tipi di traffico di gestione e calcolo, le porte del commutatore fisico devono essere configurate in modalità trunk per accettare tutte le VLAN necessarie per i carichi di lavoro di gestione e calcolo.
La rete di gestione supporta il traffico usato dall'amministratore per la gestione del sistema, tra cui Desktop remoto, Windows Admin Center e Active Directory.
Per altre informazioni, vedere Considerazioni sulla rete VLAN di gestione.
VLAN di calcolo
In alcuni scenari non è necessario usare Rete virtuale SDN con incapsulamento VXLAN. È invece possibile usare le VLAN tradizionali per isolare i carichi di lavoro del tenant. Tali VLAN devono essere configurate sulla porta dei commutatori TOR in modalità trunk. Quando si connettono nuove macchine virtuali a queste VLAN, il tag VLAN corrispondente viene definito nella scheda di rete virtuale.
Rete PA (HNV Provider Address)
La rete ip-V Network Virtualization Provider Address (HNV PA) funge da rete fisica sottostante per il traffico tenant (interno interno) est-ovest, il traffico del tenant nord-sud (interno-esterno) e lo scambio di informazioni di peering BGP con la rete fisica. Questa rete è necessaria solo quando è necessario distribuire reti virtuali usando l'incapsulamento VXLAN per un livello aggiuntivo di isolamento e multi-tenancy di rete.
Per altre informazioni, vedere Pianificare un'infrastruttura di rete definita dal software.
Finalità di Network ATC
Per i modelli senza commutatori di archiviazione a tre nodi, vengono create due finalità di Network ATC. La prima finalità è per la gestione e il traffico di rete di calcolo e la seconda è per il traffico di archiviazione.
Finalità di gestione e calcolo
- Tipo di finalità: Gestione e calcolo
- In modalità tenda: modalità cluster
- Raggruppamento: Sì. pNIC01 e pNIC02 team.
- VLAN di gestione predefinita: la VLAN configurata per le schede di gestione non viene modificata.
- VLAN e VLAN di calcolo: l'ATC di rete è trasparente per le vNIC PA e le VLAN o le VLAN di calcolo vNIC e VLAN.
Finalità di archiviazione
Tipo di finalità: Archiviazione
In modalità tenda: modalità cluster
Raggruppamento: No. Le schede di interfaccia di rete RDMA usano SMB multicanale per fornire resilienza e aggregazione della larghezza di banda.
VLAN predefinite: VLAN singola per tutte le subnet.
IP automatico dell'archiviazione: False. Questo modello richiede la configurazione IP manuale o la definizione IP del modello di Resource Manager.
Sei subnet necessarie (definite dall'utente):
- Rete di archiviazione 1: 10.0.1.0/24 –
Node1 -> Node2 - Rete di archiviazione 2: 10.0.2.0/24 –
Node1 -> Node2 - Rete di archiviazione 3: 10.0.3.0/24 –
Node2 -> Node3 - Rete di archiviazione 4: 10.0.4.0/24 –
Node1 -> Node3 - Rete di archiviazione 5: 10.0.5.0/24 –
Node1 -> Node3 - Rete di archiviazione 6: 10.0.6.0/24 –
Node2 -> Node3
- Rete di archiviazione 1: 10.0.1.0/24 –
Per altre informazioni, vedere Distribuire la rete host con Network ATC.
Esempio di configurazione delle reti delle finalità di archiviazione del modello di Resource Manager
È possibile usare il modello arm per l'archiviazione a 3 nodi senza cambio, doppio TOR e doppio collegamento.
"storageNetworkList": {
"value": [
{
"name": "StorageNetwork1",
"networkAdapterName": "SMB1",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.1.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.1.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.5.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork2",
"networkAdapterName": "SMB2",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.2.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.2.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.4.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork3",
"networkAdapterName": "SMB3",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.5.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.3.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.3.3",
"subnetMask": "255.255.255.0"
}
]
},
{
"name": "StorageNetwork4",
"networkAdapterName": "SMB4",
"vlanId": "711",
"storageAdapterIPInfo": [
{
"physicalNode": "Node1",
"ipv4Address": "10.0.4.2",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node2",
"ipv4Address": "10.0.6.1",
"subnetMask": "255.255.255.0"
},
{
"physicalNode": "Node3",
"ipv4Address": "10.0.6.3",
"subnetMask": "255.255.255.0"
}
]
}
]
},