Pianificazione dell'integrazione di rete per l'hub di Azure Stack
Questo articolo fornisce informazioni sull'infrastruttura di rete dell'hub di Azure Stack per decidere come integrare al meglio l'hub di Azure Stack nell'ambiente di rete esistente.
Nota
Per risolvere i nomi DNS esterni dall'hub di Azure Stack (ad esempio, www.bing.com), è necessario fornire ai server DNS di inoltrare le richieste DNS. Per altre informazioni sui requisiti DNS dell'hub di Azure Stack, vedere Integrazione del data center dell'hub di Azure Stack - DNS.
Progettazione di rete fisica
La soluzione hub di Azure Stack richiede un'infrastruttura fisica resiliente e a disponibilità elevata per supportare il funzionamento e i servizi. Per integrare l'hub di Azure Stack alla rete, sono necessari uplink dai commutatori Top-of-Rack (ToR) al commutatore o router più vicino, che in questa documentazione viene indicato come Border. I tor possono essere collegati a una singola o a una coppia di bordi. Il toR è preconfigurato dallo strumento di automazione, prevede un minimo di una connessione tra ToR e Border quando si usa il routing BGP e un minimo di due connessioni (una per ToR) tra ToR e Border quando si usa il routing statico, con un massimo di quattro connessioni su entrambe le opzioni di routing. Queste connessioni sono limitate ai supporti SFP+ o SFP28 e a una velocità minima di un GB. Rivolgersi al fornitore dell'hardware oem (Original Equipment Manufacturer) per la disponibilità. Il diagramma seguente presenta la progettazione consigliata:
Allocazione della larghezza di banda
L'hub di Azure Stack viene creato usando le tecnologie Windows Server 2019 Failover Cluster e Spaces Direct. Una parte della configurazione della rete fisica dell'hub di Azure Stack viene eseguita per usare la separazione del traffico e le garanzie di larghezza di banda per garantire che le comunicazioni di archiviazione diretta di Spaces possano soddisfare le prestazioni e la scalabilità necessarie per la soluzione. La configurazione di rete usa classi di traffico per separare le comunicazioni basate su Spaces Direct e RDMA da quella dell'utilizzo della rete dall'infrastruttura e/o dal tenant dell'hub di Azure Stack. Per allinearsi alle procedure consigliate correnti definite per Windows Server 2019, l'hub di Azure Stack sta cambiando in modo da usare una classe di traffico aggiuntiva o una priorità per separare ulteriormente la comunicazione tra server e server a supporto della comunicazione del controllo clustering di failover. Questa nuova definizione della classe di traffico verrà configurata per riservare il 2% della larghezza di banda fisica disponibile. Questa configurazione della prenotazione della larghezza di banda e della classe di traffico viene eseguita da una modifica nei commutatori top-of-rack (ToR) della soluzione hub di Azure Stack e nell'host o nei server dell'hub di Azure Stack. Si noti che le modifiche non sono necessarie nei dispositivi di rete border del cliente. Queste modifiche offrono una migliore resilienza per la comunicazione del cluster di failover e sono progettate per evitare situazioni in cui la larghezza di banda di rete viene usata completamente e di conseguenza i messaggi di controllo del cluster di failover vengono interrotti. Si noti che la comunicazione del cluster di failover è un componente critico dell'infrastruttura dell'hub di Azure Stack e, se interrotta per lunghi periodi, può causare instabilità nei servizi di archiviazione di Spazi diretti o in altri servizi che avranno un impatto sulla stabilità del carico di lavoro del tenant o dell'utente finale.
Nota
Le modifiche descritte vengono aggiunte a livello di host di un sistema hub di Azure Stack nella versione 2008. Contattare l'OEM per organizzare le modifiche necessarie nei commutatori di rete ToR. Questa modifica di ToR può essere eseguita prima dell'aggiornamento alla versione 2008 o dopo l'aggiornamento alla versione 2008. Per migliorare le comunicazioni del cluster di failover, è necessario modificare la configurazione delle opzioni ToR.
Reti logiche
Le reti logiche rappresentano un'astrazione dell'infrastruttura di rete fisica sottostante. Vengono usati per organizzare e semplificare le assegnazioni di rete per host, macchine virtuali e servizi. Nell'ambito della creazione della rete logica, i siti di rete vengono creati per definire le reti locali virtuali (VLAN), le subnet IP e le coppie subnet/VLAN IP associate alla rete logica in ogni posizione fisica.
La tabella seguente illustra le reti logiche e gli intervalli di subnet IPv4 associati che è necessario pianificare:
| Rete logica | Descrizione | Dimensione |
|---|---|---|
| Indirizzo VIP pubblico | L'hub di Azure Stack usa un totale di 31 indirizzi da questa rete e il resto viene usato dalle macchine virtuali tenant. Da 31 indirizzi, vengono usati 8 indirizzi IP pubblici per un piccolo set di servizi dell'hub di Azure Stack. Se si prevede di usare servizio app e i provider di risorse SQL, vengono usati altri 7 indirizzi. I restanti 16 indirizzi IP sono riservati per i servizi di Azure futuri. | /26 (62 host) - /22 (1022 host) Consigliato = /24 (254 host) |
| Infrastruttura switch | Indirizzi IP da punto a punto per scopi di routing, interfacce di gestione dei commutatori dedicati e indirizzi di loopback assegnati al commutatore. | /26 |
| Infrastruttura | Usato per comunicare i componenti interni dell'hub di Azure Stack. | /24 |
| Privato | Usato per la rete di archiviazione, indirizzi VIP privati, contenitori dell'infrastruttura e altre funzioni interne. Per altri dettagli, vedere la sezione Rete privata in questo articolo. | /20 |
| Baseboard Management Controller (BMC) | Usato per comunicare con i bare metal sugli host fisici. | /26 |
Nota
Un avviso nel portale ricorderà all'operatore di eseguire il cmdlet PEP Set-AzsPrivateNetwork per aggiungere un nuovo spazio IP privato /20. Per altre informazioni e indicazioni sulla selezione dello spazio IP privato /20, vedere la sezione Rete privata in questo articolo.
Infrastruttura di rete
L'infrastruttura di rete per l'hub di Azure Stack è costituita da diverse reti logiche configurate nei commutatori. Il diagramma seguente illustra queste reti logiche e come si integrano con i commutatori top-of-rack (TOR), il controller di gestione delle schede base (BMC) e i commutatori border (customer network).
Rete BMC
Questa rete è dedicata alla connessione di tutti i controller di gestione della scheda di base (noti anche come BMC o processori di servizio) alla rete di gestione. Gli esempi includono: iDRAC, iLO, iBMC e così via. Per comunicare con qualsiasi nodo BMC viene usato un solo account BMC. Se presente, l'host del ciclo di vita hardware (HLH) si trova in questa rete e può fornire software specifico dell'OEM per la manutenzione o il monitoraggio hardware.
HLH ospita anche la macchina virtuale di distribuzione (DVM). La DVM viene usata durante la distribuzione dell'hub di Azure Stack e viene rimossa al termine della distribuzione. La DVM richiede l'accesso a Internet negli scenari di distribuzione connessa per testare, convalidare e accedere a più componenti. Questi componenti possono trovarsi all'interno e all'esterno della rete aziendale, ad esempio NTP, DNS e Azure. Per altre informazioni sui requisiti di connettività, vedere la sezione NAT nell'integrazione del firewall dell'hub di Azure Stack.
Rete privata
Questa rete /20 (4096 IP) è privata per l'area dell'hub di Azure Stack (non indirizza oltre i dispositivi del commutatore di bordo del sistema hub di Azure Stack) ed è divisa in più subnet, di seguito sono riportati alcuni esempi:
- Rete di archiviazione: una rete /25 (128 IP) usata per supportare l'uso del traffico di archiviazione SMB (Spaces Direct and Server Message Block) e della migrazione in tempo reale delle macchine virtuali.
- Rete IP virtuale interna: rete /25 dedicata agli indirizzi VIP solo interni per il servizio di bilanciamento del carico software.
- Rete contenitore: una rete /23 (512 IP) dedicata al traffico solo interno tra contenitori che eseguono servizi di infrastruttura.
Il sistema hub di Azure Stack richiede uno spazio IP interno privato /20 aggiuntivo. Questa rete sarà privata per il sistema hub di Azure Stack (non instrada oltre i dispositivi del commutatore di bordo del sistema hub di Azure Stack) e può essere riutilizzata in più sistemi hub di Azure Stack all'interno del data center. Anche se la rete è privata in Azure Stack, non deve sovrapporsi ad altre reti nel data center. Lo spazio IP privato /20 è suddiviso in più reti che consentono di eseguire l'infrastruttura dell'hub di Azure Stack nei contenitori. Questo nuovo spazio IP privato consente inoltre di ridurre lo spazio IP instradabile necessario prima della distribuzione. L'obiettivo di eseguire l'infrastruttura dell'hub di Azure Stack nei contenitori è ottimizzare l'utilizzo e migliorare le prestazioni. Inoltre, lo spazio IP privato /20 viene usato anche per abilitare le attività in corso che ridurranno lo spazio IP instradabile necessario prima della distribuzione. Per indicazioni sullo spazio IP privato, è consigliabile seguire RFC 1918.
Per i sistemi distribuiti prima del 1910, questa subnet /20 sarà una rete aggiuntiva da immettere nei sistemi dopo l'aggiornamento al 1910. La rete aggiuntiva dovrà essere fornita al sistema tramite il cmdlet Set-AzsPrivateNetwork PEP.
Nota
L'input /20 funge da prerequisito per l'aggiornamento successivo dell'hub di Azure Stack dopo il 1910. Quando l'aggiornamento successivo dell'hub di Azure Stack dopo le versioni 1910 e si tenta di installarlo, l'aggiornamento avrà esito negativo se non è stato completato l'input /20 come descritto nei passaggi di correzione come indicato di seguito. Un avviso verrà visualizzato nel portale di amministrazione fino al completamento dei passaggi di correzione precedenti. Vedere l'articolo Integrazione rete datacenter per comprendere come verrà utilizzato questo nuovo spazio privato.
Procedura di correzione: per correggere, seguire le istruzioni per aprire una sessione PEP. Preparare un intervallo IP interno privato di dimensioni /20 ed eseguire il cmdlet seguente nella sessione PEP usando l'esempio seguente: . Set-AzsPrivateNetwork -UserSubnet 10.87.0.0/20 Se l'operazione viene eseguita correttamente, si riceverà il messaggio Azs Internal Network range aggiunto alla configurazione. Se l'avviso viene completato correttamente, l'avviso verrà chiuso nel portale di amministrazione. Il sistema hub di Azure Stack può ora eseguire l'aggiornamento alla versione successiva.
Rete dell'infrastruttura dell'hub di Azure Stack
Questa rete /24 è dedicata ai componenti interni dell'hub di Azure Stack in modo che possano comunicare e scambiare dati tra loro. Questa subnet può essere instradabile esternamente dalla soluzione hub di Azure Stack al data center, non è consigliabile usare indirizzi IP instradabili Pubblici o Internet in questa subnet. Questa rete viene pubblicizzata al border, ma la maggior parte dei relativi INDIRIZZI IP è protetta da elenchi di Controllo di accesso (ACL). Gli indirizzi IP consentiti per l'accesso sono all'interno di un intervallo ridotto equivalente a una rete /27 e ai servizi host, ad esempio il punto finale con privilegi (PEP) e backup dell'hub di Azure Stack.
Rete VIP pubblica
La rete VIP pubblica viene assegnata al controller di rete in Azure Stack. Non è una rete logica sul commutatore. Il bilanciamento del carico software usa il pool di indirizzi e assegna le reti /32 per i carichi di lavoro del tenant. Nella tabella di routing del commutatore questi indirizzi IP /32 vengono annunciati come route disponibili tramite BGP. Questa rete contiene gli indirizzi IP pubblici o accessibili dall'esterno. L'infrastruttura dell'hub di Azure Stack riserva i primi 31 indirizzi da questa rete VIP pubblica mentre il resto viene usato dalle macchine virtuali tenant. Le dimensioni di rete in questa subnet possono variare da un minimo di /26 (64 host) a un massimo di /22 (1022 host). È consigliabile pianificare una rete /24.
Connessione alle reti locali
L'hub di Azure Stack usa reti virtuali per le risorse dei clienti, ad esempio macchine virtuali, servizi di bilanciamento del carico e altri.
Sono disponibili diverse opzioni per la connessione dalle risorse all'interno della rete virtuale alle risorse locali/aziendali:
- Usare gli indirizzi IP pubblici dalla rete VIP pubblica.
- Usare Rete virtuale gateway o appliance virtuale di rete.
Quando si usa un tunnel VPN da sito a sito per connettere le risorse a o dalle reti locali, è possibile che si verifichi uno scenario in cui una risorsa abbia anche un indirizzo IP pubblico assegnato e che non sia più raggiungibile tramite tale indirizzo IP pubblico. Se l'origine tenta di accedere all'indirizzo IP pubblico rientra nello stesso intervallo di subnet definito nelle route del gateway di rete locale (gateway Rete virtuale) o nella route definita dall'utente per le soluzioni di appliance virtuali di rete, l'hub di Azure Stack tenta di instradare il traffico in uscita all'origine tramite il tunnel S2S, in base alle regole di routing configurate. Il traffico restituito usa l'indirizzo IP privato della macchina virtuale, anziché essere nated di origine come indirizzo IP pubblico:
Esistono due soluzioni a questo problema:
- Instradare il traffico diretto alla rete VIP pubblica a Internet.
- Aggiungere un dispositivo NAT a NAT a qualsiasi IP di subnet definito nel gateway di rete locale indirizzato alla rete VIP pubblica.
Commutare la rete dell'infrastruttura
Questa rete /26 è la subnet che contiene le subnet IP da punto a punto instradabili /30 (due indirizzi IP host) e i loopback, che sono subnet /32 dedicate per la gestione dei commutatori in banda e l'ID router BGP. Questo intervallo di indirizzi IP deve essere instradabile all'esterno della soluzione hub di Azure Stack al data center. Possono essere indirizzi IP privati o pubblici.
Rete di gestione dei commutatori
Questa rete /29 (sei indirizzi IP host) è dedicata alla connessione delle porte di gestione dei commutatori. Consente l'accesso fuori banda per la distribuzione, la gestione e la risoluzione dei problemi. Viene calcolato dalla rete dell'infrastruttura del commutatore menzionata in precedenza.
Reti consentite
Il foglio di lavoro distribuzione include un campo che consente all'operatore di modificare alcuni elenchi di controllo di accesso (ACL) per consentire l'accesso alle interfacce di gestione dei dispositivi di rete e all'host del ciclo di vita hardware (HLH) da un intervallo di rete data center attendibile. Con la modifica dell'elenco di controllo di accesso, l'operatore può consentire alle macchine virtuali jumpbox di gestione all'interno di un intervallo di rete specifico di accedere all'interfaccia di gestione dei commutatori e al sistema operativo HLH. L'operatore può fornire una o più subnet a questo elenco, se lasciato vuoto, per impostazione predefinita nega l'accesso. Questa nuova funzionalità sostituisce la necessità di un intervento manuale post-distribuzione come descritto nella sezione Modificare impostazioni specifiche nella configurazione del commutatore dell'hub di Azure Stack.
Passaggi successivi
- Routing del traffico di rete virtuale
- Informazioni sulla pianificazione della rete: Connettività border.