Che cos'è SDN Multisite?
Si applica a: Azure Stack HCI, versione 23H2
Si applica a: Windows Server 2025 (anteprima)
Importante
SDN Multisite in Windows Server 2025 è disponibile in ANTEPRIMA. Queste informazioni sono relative alla versione non definitiva del prodotto, che potrebbe subire modifiche significative prima della release definitiva. Microsoft non fornisce alcuna garanzia, esplicita o implicita, in relazione alle informazioni contenute in questo documento.
Questo articolo offre una panoramica del multisito SDN, inclusi i vantaggi e le limitazioni correnti. È possibile usarlo come guida per progettare la topologia di rete e il piano di ripristino di emergenza.
SDN Multisito consente di espandere le funzionalità di SDN tradizionale distribuite in posizioni fisiche diverse. Il multisito SDN consente la connettività nativa di livello 2 e livello 3 in posizioni fisiche diverse per carichi di lavoro virtualizzati. In questo articolo tutti i riferimenti ai siti indicano posizioni fisiche.
Per informazioni su come gestire il multisito SDN, vedere Gestire multisito SDN per Azure Stack HCI.
Per informazioni su come gestire il multisito SDN, vedere Gestire multisito SDN per Azure Stack HCI.
Vantaggi
Ecco i vantaggi dell'uso di SDN Multisite:
- Sistema di gestione dei criteri unificato. Con le reti virtuali condivise e le configurazioni dei criteri, è possibile gestire e configurare le reti multisito da qualsiasi sito.
- Migrazione senza problemi del carico di lavoro. Eseguire facilmente la migrazione dei carichi di lavoro tra siti fisici senza dover riconfigurare indirizzi IP o gruppi di sicurezza di rete preesistenti.
- Raggiungibilità automatica alle nuove macchine virtuali. Ottenere la raggiungibilità automatica delle macchine virtuali appena create nelle reti virtuali, insieme alla gestibilità automatica a qualsiasi gruppo di sicurezza di rete associato nelle posizioni fisiche.
Limiti
La funzionalità multisito SDN presenta attualmente alcune limitazioni:
- Supportato solo tra due siti.
- I siti devono essere connessi tramite una rete privata, perché non viene fornito il supporto della crittografia per i siti connessi tramite Internet.
- Il bilanciamento del carico interno non è supportato tra siti.
Peering multisito
Il multisito richiede il peering tra siti, che viene avviato come il peering di rete virtuale. Una connessione viene avviata automaticamente in entrambi i siti tramite Windows Admin Center. Una volta stabilita una connessione, il peering viene completato correttamente. Per istruzioni su come stabilire il peering, vedere Stabilire il peering.
Il multisito richiede il peering tra siti, che viene avviato come il peering di rete virtuale. Una connessione viene avviata automaticamente in entrambi i siti tramite Windows Admin Center. Una volta stabilita una connessione, il peering viene completato correttamente. Per istruzioni su come stabilire il peering, vedere Stabilire il peering.
Le sezioni seguenti descrivono i ruoli di ogni sito all'interno di un ambiente multisito e il modo in cui le risorse vengono gestite e sincronizzate tra siti.
Ruoli del sito primario e secondario
In un ambiente SDN multisito, un sito viene designato come primario e l'altro come secondario. Il sito primario gestisce la sincronizzazione delle risorse. Durante il peering multisito, il sito primario viene selezionato automaticamente, che è possibile modificare in un secondo momento usando Windows Admin Center.
Gestione delle risorse
Se il sito primario non è raggiungibile, le risorse globali e le risorse che richiedono la convalida globale o le allocazioni dell'indirizzo del cliente globale (CA) non possono essere aggiornate tramite il sito secondario. Tuttavia, è possibile aggiornare altre risorse locali tramite il sito secondario.
Esempi di risorse che richiedono la convalida globale includono:
- Pool MAC.
- Pool di rete/IP logico.
Esempi di allocazioni di CA globali includono:
- Bilanciamento del carico interno per la subnet virtuale. Attualmente, questa funzionalità non è supportata tramite multisito.
- Connessioni gateway per la subnet virtuale.
Se il sito secondario non è raggiungibile, le risorse possono essere aggiornate tramite il sito primario. Tuttavia, il sito secondario potrebbe avere risorse non aggiornati fino a quando non viene ripristinata la connettività. Una volta ripristinata la connettività, la sincronizzazione riprende.
Se il sito primario diventa inattivo, è possibile designare il sito secondario come nuovo sito primario per eseguire aggiornamenti ai gruppi di sicurezza di rete e alle reti virtuali. Tuttavia, qualsiasi sincronizzazione dei dati in sospeso dal sito primario precedente andrà persa. Per risolvere questo problema, applicare le stesse modifiche nel nuovo sito primario dopo che il sito primario precedente è di nuovo online. Tuttavia, può anche causare conflitti di allocazione ca globali.
Sincronizzazione delle risorse
Quando si abilita il multisito SDN, non tutte le risorse di ogni sito vengono sincronizzate in tutti i siti. Ecco gli elenchi di risorse sincronizzate e che rimangono non sincronizzate.
Risorse sincronizzate
Queste risorse vengono sincronizzate in tutti i siti dopo la creazione del peering. È possibile aggiornare queste risorse da qualsiasi sito, ad esempio primario o secondario. Tuttavia, il sito primario è responsabile di garantire che queste risorse vengano applicate e sincronizzate tra siti. Le linee guida e le istruzioni per la gestione di queste risorse rimangono invariate in un ambiente SDN a sito singolo.
- Reti virtuali. Per istruzioni su come gestire le reti virtuali, vedere Gestire le reti virtuali tenant. Si noti che le reti logiche non vengono sincronizzate tra siti. Tuttavia, se le reti virtuali fanno riferimento a una rete logica, la rete logica con lo stesso nome deve esistere in entrambi i siti.
- Gruppi di sicurezza di rete (NSG). Per istruzioni su come configurare il gruppo di sicurezza di rete con Windows Admin Center e PowerShell, vedere Configurare i gruppi di sicurezza di rete con Windows Admin Center e Configurare i gruppi di sicurezza di rete con PowerShell.
- Routing definito dall'utente. Per istruzioni su come usare il routing definito dall'utente, vedere Usare appliance virtuali di rete in una rete virtuale.
Risorse sincronizzate
Queste risorse vengono sincronizzate in tutti i siti dopo la creazione del peering. È possibile aggiornare queste risorse da qualsiasi sito, ad esempio primario o secondario. Tuttavia, il sito primario è responsabile di garantire che queste risorse vengano applicate e sincronizzate tra siti. Le linee guida e le istruzioni per la gestione di queste risorse rimangono invariate in un ambiente SDN a sito singolo.
- Reti virtuali. Per istruzioni su come gestire le reti virtuali, vedere Gestire le reti virtuali tenant. Si noti che le reti logiche non vengono sincronizzate tra siti. Tuttavia, se le reti virtuali fanno riferimento a una rete logica, la rete logica con lo stesso nome deve esistere in entrambi i siti.
- Gruppi di sicurezza di rete (NSG). Per istruzioni su come configurare il gruppo di sicurezza di rete con Windows Admin Center e PowerShell, vedere Configurare i gruppi di sicurezza di rete con Windows Admin Center e Configurare i gruppi di sicurezza di rete con PowerShell.
- Routing definito dall'utente. Per istruzioni su come usare il routing definito dall'utente, vedere Usare appliance virtuali di rete in una rete virtuale.
Risorse non sincronizzate
Queste risorse non vengono sincronizzate dopo aver stabilito il peering:
- Criteri di bilanciamento del carico.
- Indirizzi IP virtuali (VIP).
- Criteri del gateway.
- Reti logiche. Anche se le reti logiche non sono sincronizzate tra siti, i pool IP vengono controllati per verificare la sovrapposizione e tale sovrapposizione non è consentita.
Questi criteri vengono creati nel sito locale e, se si desiderano gli stessi criteri nell'altro sito, è necessario crearli manualmente. Se le macchine virtuali back-end per i criteri di bilanciamento del carico si trovano in un singolo sito, la connettività tramite SLB funzionerà correttamente senza alcuna configurazione aggiuntiva. Tuttavia, se si prevede che le macchine virtuali back-end vengano spostate da un sito all'altro, per impostazione predefinita, la connettività funziona solo se sono presenti macchine virtuali back-end dietro un indirizzo VIP nel sito locale. Se tutte le macchine virtuali back-end vengono spostate in un altro sito, la connettività su tale indirizzo VIP ha esito negativo.
Flusso del traffico est-ovest e condivisione di subnet
Il multisito consente alle macchine virtuali in siti diversi con SDN distribuito di comunicare tramite la stessa subnet senza dover configurare le connessioni gateway SDN. Ciò semplifica la topologia di rete e riduce la necessità di più macchine virtuali e subnet. Il percorso dei dati tra macchine virtuali in siti diversi si basa sull'infrastruttura fisica sottostante.
Gli scenari seguenti confrontano il modo in cui viene stabilita la comunicazione tra due siti fisici in una configurazione SDN tradizionale rispetto a una configurazione multisito SDN.
Comunicazione da macchina virtuale a macchina virtuale senza sito multisito SDN
In una configurazione tradizionale con SDN distribuito in due siti fisici, è necessario stabilire una connessione gateway L3 o GRE per la comunicazione tra siti. È anche necessario fornire più subnet per le applicazioni. Ad esempio, se ogni sito ospita applicazioni front-end, è necessario allocare intervalli di subnet separati come 10.1/16 e 10.6/16. Inoltre, quando si configura una connessione gateway, è anche necessario allocare più macchine virtuali per le macchine virtuali del gateway e gestirle successivamente.
Comunicazione da macchina virtuale a macchina virtuale con multisito SDN
Con il multisito SDN in due posizioni fisiche, è possibile avere connettività nativa di livello 2 per la comunicazione tra siti. In questo modo è possibile avere un singolo intervallo di subnet per le applicazioni che si estendono in entrambe le posizioni, eliminando la necessità di configurare la connessione gateway SDN. Ad esempio, come illustrato nel diagramma seguente, le applicazioni front-end in entrambe le posizioni possono usare la stessa subnet, ad esempio 10.1/16, anziché mantenere due distinte. Con questa configurazione, il flusso di dati da una macchina virtuale a un'altra si basa esclusivamente sull'infrastruttura fisica sottostante, evitando la necessità di attraversare un'altra macchina virtuale del gateway SDN.
Servizi di bilanciamento del carico software e le relative limitazioni
Attualmente, i servizi di bilanciamento del carico software sono risorse locali per ognuno dei siti fisici. Ciò significa che i criteri e le configurazioni di bilanciamento del carico non vengono sincronizzati tra siti tramite multisito. Tenere presente questo aspetto quando si esegue la migrazione di macchine virtuali da una posizione a un'altra in una configurazione multisito SDN.
Bilanciamento del carico in SDN multisito: scenario di esempio
Le sezioni seguenti illustrano il bilanciamento del carico in multisito tramite uno scenario di esempio, che illustra sia senza che con la migrazione delle macchine virtuali del carico di lavoro. Si supponga di avere due cluster Azure Stack HCI con SDN Multisito abilitato, ognuno con la propria infrastruttura SDN distribuita e configurata. In questo scenario, un client vuole raggiungere VM1 con indirizzo IP 10.0.0.5 e INDIRIZZO VIP 11.0.0.5.
Bilanciamento del carico nel multisito SDN senza eseguire la migrazione delle macchine virtuali del carico di lavoro
In SDN multisito, se non è presente alcuna migrazione di macchine virtuali tra posizioni, i pacchetti di dati vengono inoltrati come di consueto, analogamente alla configurazione SDN tradizionale. L'animazione seguente illustra il percorso dei dati dal computer client a VM1 tramite SLB MUX1 nel cluster 2.
Bilanciamento del carico nel multisito SDN con la migrazione di macchine virtuali del carico di lavoro
Se si decide di eseguire la migrazione di una macchina virtuale o di tutte le macchine virtuali dietro l'indirizzo VIP all'altro sito, è possibile che si verifichino situazioni in cui la macchina virtuale che si sta tentando di raggiungere non sia raggiungibile tramite l'indirizzo VIP, a seconda della posizione. Ciò si verifica perché le risorse del servizio di bilanciamento del carico sono locali per ogni cluster Azure Stack HCI. Quando le macchine virtuali del carico di lavoro vengono spostate, le configurazioni nei MUX non sono globali, lasciando l'altro sito non a conoscenza delle migrazioni. L'animazione seguente illustra la migrazione delle macchine virtuali dal cluster 2 al cluster 1 e il modo in cui il percorso del pacchetto di dati ha esito negativo dopo la migrazione.
Per ovviare a questa limitazione, è possibile usare il servizio di bilanciamento del carico esterno che controlla la disponibilità delle macchine virtuali back-end in ogni sito e instrada il traffico di conseguenza. Vedere Usare il servizio di bilanciamento del carico esterno in più siti con la migrazione delle macchine virtuali del carico di lavoro.
Usare il servizio di bilanciamento del carico esterno in più siti con la migrazione delle macchine virtuali del carico di lavoro
È possibile abilitare un servizio di bilanciamento del carico esterno per verificare se sono presenti macchine virtuali back-end dietro un servizio di bilanciamento del carico in uno dei siti. Se non sono presenti macchine virtuali back-end dietro un servizio di bilanciamento del carico, l'indirizzo VIP per MUX non viene annunciato fino al servizio di bilanciamento del carico esterno e qualsiasi probe di integrità inviato ha esito negativo. Questo servizio di bilanciamento del carico esterno garantisce la connettività ai carichi di lavoro anche quando le macchine virtuali passano da un sito a un altro.
Tuttavia, se la distribuzione di un servizio di bilanciamento del carico esterno non è fattibile, usare la soluzione di bilanciamento del carico software come descritto in Bilanciamento del carico in sito multisito SDN senza eseguire la migrazione delle macchine virtuali del carico di lavoro purché non siano presenti macchine virtuali del carico di lavoro di migrazione.
Gateway e relative limitazioni
SDN multisito non sincronizza le risorse locali, ad esempio le connessioni gateway tra siti. Ogni sito ha le proprie macchine virtuali gateway e le connessioni gateway. Quando una macchina virtuale del carico di lavoro viene creata o migrata in un sito, ottiene la configurazione del gateway locale, ad esempio le route del gateway. Se si crea una connessione gateway per una determinata rete virtuale in un sito, le macchine virtuali di tale sito perdono la connettività del gateway durante la migrazione all'altro sito. Affinché le macchine virtuali mantengano la connettività del gateway durante la migrazione, è necessario configurare una connessione gateway separata per la stessa rete virtuale nell'altro sito.