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 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 server DNS per 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 le operazioni e i servizi. Per integrare l'hub di Azure Stack alla rete, sono necessari collegamenti uplink dalle opzioni Top-of-Rack (ToR) al commutatore o router più vicino, che in questa documentazione viene definito Border. È possibile collegare i tor a una singola o a una coppia di bordi. 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 routing statico, con un massimo di quattro connessioni in entrambe le opzioni di routing. Queste connessioni sono limitate a supporti SFP+ o SFP28 e una velocità minima di un GB. Per la disponibilità, consultare il fornitore dell'hardware oem (Original Equipment Manufacturer). Il diagramma seguente presenta la progettazione consigliata:

Recommended Azure Stack network design

Allocazione della larghezza di banda

L'hub di Azure Stack viene creato usando Windows tecnologie cluster di failover e spazi di failover server 2019. 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 le classi di traffico per separare le comunicazioni basate su Spaces Direct e RDMA da quella dell'utilizzo della rete dall'infrastruttura dell'hub di Azure Stack e/o del tenant. Per allineare le procedure consigliate correnti definite per Windows Server 2019, l'hub di Azure Stack sta cambiando per usare una classe di traffico aggiuntiva o una priorità aggiuntiva per separare ulteriormente il server per la comunicazione server in 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 classe di traffico e della larghezza di banda viene eseguita da una modifica nelle opzioni 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 del bordo del cliente. Queste modifiche forniscono una maggiore resilienza per la comunicazione del cluster di failover e sono destinati a evitare situazioni in cui la larghezza di banda di rete viene completamente utilizzata 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 diretta spazi o in altri servizi che avranno un impatto finale 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 nelle opzioni di rete ToR. Questa modifica di ToR può essere eseguita prima dell'aggiornamento alla versione 2008 o dopo l'aggiornamento a 2008. La modifica della configurazione alle opzioni ToR è necessaria per migliorare le comunicazioni del cluster di failover.

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 di rete logica, i siti di rete vengono creati per definire le reti di area locale virtuale (VLAN), le subnet IP e le coppie ip subnet/VLAN associate alla rete logica in ogni posizione fisica.

La tabella seguente illustra le reti logiche e gli intervalli di subnet IPv4 associati per cui è 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. Dagli indirizzi 31 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 7 altri indirizzi. I rimanenti 16 indirizzi IP sono riservati ai servizi di Azure futuri. /26 (62 host) - /22 (1022 host)

Consigliato = /24 (254 host)
Infrastruttura commutatore 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 i componenti interni dell'hub di Azure Stack per comunicare. /24
Privato Usato per la rete di archiviazione, i indirizzi VIP privati, i contenitori dell'infrastruttura e altre funzioni interne. Per altre informazioni, vedere la sezione Rete privata in questo articolo. /20
Baseboard Management Controller (BMC) Usato per comunicare con i BMC negli host fisici. /26

Nota

Un avviso nel portale ricorda 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 nelle opzioni. Il diagramma seguente illustra queste reti logiche e come si integrano con le opzioni top-of-rack (TOR), controller di gestione delle schede di base (BMC) e border (rete clienti).

Logical network diagram and switch connections

Rete BMC

Questa rete è dedicata alla connessione di tutti i controller di gestione della scheda di base (noti anche come processori di servizio o BMC) alla rete di gestione. Esempi includono: iDRAC, iLO, iBMC e così via. Viene usato un solo account BMC per comunicare con qualsiasi nodo 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.

L'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 connessi 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 all'area hub di Azure Stack (non instrada i dispositivi del commutatore di bordo del sistema hub di Azure Stack) ed è suddivisa in più subnet, ecco alcuni esempi:

  • Archiviazione rete: 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 della macchina virtuale.
  • Rete IP virtuale interna: una rete /25 dedicata agli INDIRIZZI IP interni per il servizio di bilanciamento del carico software.
  • Rete contenitore: 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 aggiuntivo /20. 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. Sebbene la rete sia privata per Azure Stack, non deve sovrapporsi ad altre reti nel data center. Lo spazio IP privato /20 è diviso in più reti che consentono di eseguire l'infrastruttura dell'hub di Azure Stack nei contenitori. Inoltre, questo nuovo spazio IP privato consente di ridurre lo spazio IP instradabile richiesto prima della distribuzione. L'obiettivo di eseguire l'infrastruttura dell'hub di Azure Stack nei contenitori consiste nell'ottimizzare l'utilizzo e migliorare le prestazioni. Inoltre, lo spazio IP privato /20 viene usato anche per consentire sforzi in corso che ridurranno lo spazio IP instradabile richiesto 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à presente nel portale di amministrazione fino al completamento dei passaggi di correzione precedenti. Per informazioni su come verrà usato questo nuovo spazio privato, vedere l'articolo sull'integrazione della rete datacenter .

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, verrà visualizzato il messaggio Azs Internal Network range aggiunto alla configurazione. Se 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:

Route traffic

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.

Route traffic solution

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, al sistema operativo HLH e al BMC 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