Progettazione del ripristino di emergenza

rete WAN virtuale consente di aggregare, connettere, gestire centralmente e proteggere tutte le distribuzioni globali. Le distribuzioni globali possono includere qualsiasi combinazione di rami diversi, point-of-presence (PoP), utenti privati, uffici, reti virtuali di Azure e altre distribuzioni multi-cloud. È possibile usare SD-WAN, VPN da sito a sito, VPN da punto a sito ed ExpressRoute per connettere i diversi siti a un hub virtuale. Se si dispone di più hub virtuali, tutti gli hub sarebbero interconnessi in una rete mesh completa in una distribuzione standard di rete WAN virtuale.

In questo articolo, esaminiamo come architettare diversi tipi di opzioni di connettività rete come servizio che la rete WAN virtuale supporta per il ripristino di emergenza.

Opzioni di connettività di rete come servizio della WAN virtuale

rete WAN virtuale supporta le opzioni di connettività back-end seguenti:

• Connettività utente remoto
• Succursale/Office/SD-WAN/VPN da sito a sito
• Connettività privata (peering privato ExpressRoute)

Per ognuna di queste opzioni di connettività, rete WAN virtuale distribuisce un set separato di istanze del gateway all'interno di un hub virtuale.

Intrinsecamente, Virtual WAN è progettato per offrire una soluzione di aggregazione di rete altamente disponibile di livello carrier. Per la disponibilità elevata, la rete WAN virtuale crea più istanze quando ognuno di questi diversi tipi di gateway viene distribuito all'interno di un hub della rete WAN virtuale. Per altre informazioni sulla disponibilità elevata di ExpressRoute, vedere Progettazione per la disponibilità elevata con ExpressRoute.

Con il gateway VPN da punto a sito, il numero minimo di istanze distribuite è due. Con il gateway VPN da punto a sito, è possibile scegliere la capacità di trasmissione aggregata dei gateway da punto a sito e il provisioning di più istanze avviene automaticamente. Si sceglie la capacità di aggregazione in base al numero di client o utenti che si intende connettere all'hub virtuale. Dal punto di vista della connessione client, le istanze del gateway VPN da punto a sito sono nascoste dietro il nome di dominio completo (FQDN) del gateway.

Per il gateway VPN da sito a sito, due istanze del gateway vengono distribuite all'interno di un hub virtuale. Ogni istanza del gateway viene distribuita con un proprio set di indirizzi IP pubblici e privati. Le due istanze forniscono due endpoint di tunnel indipendenti per stabilire la connettività VPN da sito a sito dalle vostre filiali. Per ottimizzare l'alta disponibilità, vedere Selezione del percorso di Azure tra più collegamenti degli ISP.

Ottimizzare la disponibilità elevata dell'architettura di rete è un primo passaggio fondamentale per continuità aziendale e ripristino di emergenza. Nel resto di questo articolo, come indicato in precedenza, andiamo oltre la disponibilità elevata e parliamo di come progettare la rete di connettività rete WAN virtuale per BCDR.

Esigenza di progettazione del ripristino di emergenza

Il disastro potrebbe colpire in qualsiasi momento, ovunque. È possibile che si verifichi un disastro nelle aree di un provider cloud, in una rete di un provider di servizi o all'interno di una rete locale. L'impatto regionale di un servizio cloud o di rete a causa di determinati fattori quali calamità naturali, errori umani, guerra, terrorismo, configurazione errata sono difficili da escludere. Pertanto, per garantire la continuità delle applicazioni critiche per l'azienda, è necessario disporre di una progettazione del ripristino di emergenza. Per una progettazione completa del ripristino di emergenza, è necessario identificare tutte le dipendenze che potrebbero fallire nel percorso di comunicazione end-to-end e creare ridondanze separate per ognuna di esse.

Indipendentemente dal fatto che si eseguano applicazioni cruciali in un'area di Azure, in locale o in qualsiasi altra posizione, è possibile usare un'altra area di Azure come sito di failover. Gli articoli seguenti illustrano il ripristino di emergenza dal punto di vista delle applicazioni e dell'accesso front-end:

• Ripristino di emergenza di livello aziendale
• Ripristino di emergenza con Azure Site Recovery

Problemi relativi all'uso della connettività ridondante

Quando si interconnette lo stesso set di reti usando più di una connessione, si introducono percorsi paralleli tra le reti. I percorsi paralleli, se non correttamente progettati, potrebbero portare a condizioni di routing asimmetrico. Se nel percorso sono presenti entità con stato (ad esempio NAT, firewall), il routing asimmetrico potrebbe bloccare il flusso del traffico. In genere, sulla connettività privata non saranno presenti o non si incontreranno entità con stato, ad esempio NAT o Firewall. Pertanto, il routing asimmetrico sulla connettività privata non blocca necessariamente il flusso del traffico.

Tuttavia, se si bilancia il carico del traffico tra percorsi paralleli con ridondanza geografica, si riscontrano prestazioni di rete incoerenti a causa della differenza nel percorso fisico delle connessioni parallele. È quindi necessario considerare le prestazioni del traffico di rete sia durante lo stato stabile (stato non di errore) che uno stato di errore come parte della progettazione del ripristino di emergenza.

Ridondanza della rete di accesso

La maggior parte dei servizi SD-WAN (soluzioni gestite o altro) fornisce connettività di rete tramite più tipi di trasporto (ad esempio Internet broadband, MPLS, LTE). Per evitare errori di rete del trasporto, scegliere la connettività su più reti di trasporto. Per uno scenario utente domestico, è possibile prendere in considerazione l'uso della rete mobile come backup per la connettività di rete a banda larga.

Se la connettività di rete su un tipo di trasporto diverso non è possibile, scegliere la connettività di rete tramite più provider di servizi. Se si ottiene la connettività tramite più provider di servizi, assicurarsi che i provider di servizi mantengano reti di accesso indipendenti non sovrapposte.

Considerazioni sulla connettività degli utenti remoti

La connettività utente remota viene stabilita usando una VPN da punto a sito tra un dispositivo finale e una rete. In seguito a un errore di rete, il dispositivo finale perde la connessione e tenta di ripristinare il tunnel VPN. Pertanto, per la VPN da punto a sito, la progettazione del ripristino di emergenza deve mirare a ridurre al minimo il tempo di ripristino dopo un errore. La ridondanza di rete seguente consente di ridurre al minimo il tempo di ripristino. A seconda della criticità delle connessioni, è possibile scegliere alcune o tutte queste opzioni.

• Ridondanza della rete di accesso (descritta in precedenza).
• Gestione dell'hub virtuale ridondante per la terminazione VPN da punto a sito. Quando si dispone di più hub virtuali con gateway da punto a sito, la rete WAN virtuale fornisce un elenco globale dei profili di tutti gli endpoint da punto a sito. Con il profilo globale, i dispositivi finali possono connettersi all'hub virtuale più vicino disponibile che offre le migliori prestazioni di rete. Se tutte le distribuzioni di Azure si trovano in una singola area e i dispositivi finali che si connettono si trovano in prossimità dell'area, è possibile avere hub virtuali ridondanti all'interno dell'area. Se la distribuzione e i dispositivi finali vengono distribuiti in più aree, è possibile distribuire l'hub virtuale con il gateway da punto a sito in ogni area selezionata. rete WAN virtuale dispone di una gestione traffico predefinita che seleziona automaticamente l'hub migliore per la connettività utente remota.

Il diagramma seguente illustra il concetto di gestione dell'hub virtuale ridondante con il rispettivo gateway da punto a sito all'interno di un'area.

Nel diagramma precedente, le linee verdi solide mostrano le connessioni VPN da punto a sito primarie e le linee gialle punteggiate mostrano le connessioni di backup stand-by. Il profilo globale da punto a sito della rete WAN virtuale seleziona le connessioni primarie e di backup in base alle prestazioni di rete. Vedere Scaricare un profilo globale per i client VPN utente per ulteriori informazioni sul profilo globale.

Considerazioni sulla VPN da sito a sito

Si consideri ora l'esempio di connessione VPN da sito a sito illustrata nel diagramma seguente per la discussione. Per stabilire una connessione VPN da sito a sito con tunnel attivo-attivo a disponibilità elevata, vedere Esercitazione: Creare una connessione da sito a sito con rete WAN virtuale di Azure.

Topologia a più collegamenti

Per proteggersi dai guasti dell'apparecchiatura CPE VPN presso un sito di filiale, è possibile configurare collegamenti VPN paralleli a un gateway VPN utilizzando dispositivi CPE paralleli nel sito di filiale. Oltre a proteggersi da errori di rete di un provider di servizi dell'ultimo miglio per la succursale, è possibile configurare collegamenti VPN diversi su una rete del provider di servizi diversa. Il diagramma seguente mostra più collegamenti VPN provenienti da due CPE diversi di un sito di succursale che terminano nello stesso gateway VPN.

È possibile configurare fino a quattro collegamenti a un sito di succursale da un gateway VPN dell'hub virtuale. Durante la configurazione di un collegamento a un sito di succursale, è possibile identificare il provider di servizi e la velocità effettiva associata al collegamento. Quando si configurano collegamenti paralleli tra un sito di succursale e un hub virtuale, il gateway VPN per impostazione predefinita bilancia il carico del traffico tra i collegamenti paralleli. Il bilanciamento del carico del traffico sarebbe basato su ECMP (Equal-Cost Multi-Path) su base per flusso.

Topologia multi-hub a più collegamenti

La topologia a più collegamenti protegge da guasti dei dispositivi CPE e da un guasto della rete del provider di servizi presso la filiale sul posto. Inoltre, per proteggersi da qualsiasi interruzione di un gateway VPN dell'hub virtuale, è utile la topologia a più hub e più collegamenti. Il diagramma seguente illustra la topologia, in cui più hub virtuali sono configurati in un'istanza di rete WAN virtuale all'interno di un'area:

Nella topologia precedente, poiché la latenza all'interno della regione di Azure sulla connessione tra gli hub è trascurabile, è possibile usare tutte le connessioni VPN da sito a sito tra l'ambiente locale e i due hub virtuali in stato attivo-attivo distribuendo le reti virtuali spoke negli hub. Nella topologia, per impostazione predefinita, il traffico tra una rete virtuale locale e una rete virtuale spoke attraversa direttamente l'hub virtuale a cui è connessa la rete virtuale spoke durante lo stato stabile e usa un altro hub virtuale come backup solo durante uno stato di errore. Il traffico attraversa l'hub connesso direttamente nello stato stabile, perché le route BGP annunciate dall'hub connesso direttamente avranno un percorso AS più breve rispetto all'hub di backup.

La topologia a più collegamenti multi-hub protegge e offre continuità aziendale nella maggior parte degli scenari di errore. Tuttavia, se un errore irreversibile arresta l'intera area di Azure, per resistere all'errore è necessaria una topologia a più aree e più collegamenti.

Topologia multi-regione a multi-collegamenti

La topologia a più aree protegge da un errore irreversibile di un'intera area, oltre alle protezioni offerte dalla topologia multi-hub multi-link illustrata in precedenza. Il diagramma seguente illustra la topologia a più aree e più collegamenti. Gli hub virtuali in un'area diversa possono essere configurati nella stessa istanza di rete WAN virtuale.

Dal punto di vista della progettazione del traffico, è necessario prendere in considerazione una differenza sostanziale tra la presenza di hub ridondanti all'interno di un'area rispetto alla presenza dell'hub di backup in un'area diversa. La differenza è la latenza risultante dalla distanza fisica tra le aree primarie e secondarie. Pertanto, è possibile distribuire le risorse del servizio con stato stabile nell'area più vicina agli utenti del ramo o agli utenti finali e usare l'area remota esclusivamente per il backup.

Se le posizioni dei rami locali vengono distribuite in due o più aree di Azure, la topologia multi-collegamento in più aree sarà più efficace nella distribuzione del carico e nell'ottenere un'esperienza di rete migliore durante lo stato stabile. Il diagramma seguente mostra la topologia a più aree e più collegamenti con succursali in aree diverse. In questo scenario, la topologia fornirà anche un'efficace continuità operativa e ripristino di emergenza (BCDR).

Considerazioni su ExpressRoute

Le considerazioni sul ripristino di emergenza per il peering privato di ExpressRoute sono illustrate in Progettazione per il ripristino di emergenza con il peering privato di ExpressRoute. Come indicato nell'articolo, i concetti descritti in questo articolo si applicano allo stesso modo ai gateway ExpressRoute creati all'interno di un hub virtuale. L'uso di un hub virtuale ridondante all'interno dell'area, come illustrato nel diagramma seguente, è l'unico miglioramento della topologia consigliato per considerazioni sulla rete locale di piccole e medie dimensioni.

Nel diagramma precedente, il circuito ExpressRoute 2 viene terminato in un gateway ExpressRoute separato all'interno di un secondo hub virtuale nell'area.

Passaggi successivi

In questo articolo abbiamo discusso della progettazione del ripristino di emergenza per la rete WAN virtuale. Gli articoli seguenti illustrano il ripristino di emergenza dal punto di vista delle applicazioni e dell'accesso front-end:

• Ripristino di emergenza di livello aziendale
• Ripristino di emergenza con Azure Site Recovery

Per creare una connettività da punto a sito a rete WAN virtuale, vedere Esercitazione: Creare una connessione VPN utente con Azure rete WAN virtuale. Per creare una connettività da sito a sito a rete WAN virtuale vedere Esercitazione: Creare una connessione da sito a sito con Azure rete WAN virtuale. Per associare un circuito ExpressRoute a rete WAN virtuale, vedere Esercitazione: Creare un'associazione ExpressRoute usando Azure rete WAN virtuale.