Condividi tramite


Progettazione per la disponibilità elevata con Azure ExpressRoute

Azure ExpressRoute è progettato per la disponibilità elevata, offrendo connettività di rete privata di livello operatore alle risorse Microsoft. Ciò significa che non esiste un singolo punto di errore all'interno della rete Microsoft. Per ottimizzare la disponibilità, è consigliabile progettare sia i segmenti dei clienti che dei provider di servizi del circuito Azure ExpressRoute per la disponibilità elevata. Questo articolo illustra le considerazioni sull'architettura di rete per la creazione di una connettività affidabile usando Azure ExpressRoute e le funzionalità di ottimizzazione per migliorare la disponibilità elevata del circuito Azure ExpressRoute.

Nota

I concetti descritti in questo articolo si applicano allo stesso modo se viene creato un circuito Azure ExpressRoute in rete WAN virtuale o all'esterno di esso.

Considerazioni sull'architettura

La figura seguente illustra il modo consigliato per connettersi usando un circuito Azure ExpressRoute per ottimizzare la disponibilità.

Diagramma del modo consigliato per connettersi usando Azure ExpressRoute per la disponibilità elevata.

Per la disponibilità elevata, è essenziale mantenere la ridondanza in tutta la rete end-to-end. Ciò significa mantenere la ridondanza all'interno della rete locale e non compromettere la ridondanza all'interno della rete del provider di servizi. Come minimo, ciò comporta l'evitare singoli punti di errore di rete. L'alimentazione ridondante e il raffreddamento per i dispositivi di rete migliorano ulteriormente la disponibilità elevata.

Considerazioni sulla progettazione del livello fisico del primo miglio

Se si terminano sia le connessioni primarie che secondarie di un circuito Azure ExpressRoute nella stessa attrezzatura locale del cliente(CPE), si compromette la disponibilità elevata all'interno della rete locale. Inoltre, la configurazione di entrambe le connessioni usando la stessa porta di un CPE impone al partner di compromettere la disponibilità elevata nel segmento di rete. Ciò può verificarsi terminando le due connessioni in sottointerfazioni diverse o unendo le due connessioni all'interno della rete partner, come illustrato di seguito.

Diagramma della connettività dell'ultimo miglio non ottimale per i circuiti ExpressRoute.

La terminazione delle connessioni primarie e secondarie di un circuito Azure ExpressRoute in posizioni geografiche diverse può compromettere le prestazioni di rete. Se il traffico è attivamente con carico bilanciato tra connessioni terminate in posizioni diverse, differenze sostanziali nella latenza di rete tra i due percorsi possono comportare prestazioni non ottimali.

Per considerazioni sulla progettazione con ridondanza geografica, vedere Progettazione per il ripristino di emergenza con Azure ExpressRoute.

Connessioni attivo-attivo

La rete Microsoft gestisce le connessioni primarie e secondarie dei circuiti Azure ExpressRoute in modalità attivo-attivo. Tuttavia, è possibile forzare le connessioni ridondanti a funzionare in modalità attiva-passiva tramite gli annunci di route. Annunciare route più specifiche e anteporre il percorso AS BGP è alla base delle comuni tecniche per rendere un percorso preferito rispetto all'altro.

Per migliorare la disponibilità elevata, Microsoft consiglia di usare entrambe le connessioni in modalità attiva-attiva. Ciò consente alla rete Microsoft di bilanciare il carico del traffico tra le connessioni in base al flusso.

L'esecuzione di connessioni in modalità attiva-passiva rischia l'esito negativo di entrambe le connessioni se il percorso attivo ha esito negativo. Le cause comuni dell'errore includono la mancanza di gestione attiva della connessione passiva e l'annuncio di route obsolete da parte della connessione passiva.

In alternativa, l'esecuzione di connessioni in modalità attiva-attiva comporta il fallimento di circa la metà dei flussi, che vengono successivamente reindirizzati, migliorando significativamente il tempo medio per il ripristino (MTTR).

Nota

Durante la manutenzione o gli eventi non pianificati che influiscono su una connessione, Microsoft userà il prepending del percorso AS per deviare il traffico verso la connessione funzionante. Assicurarsi che il traffico possa instradarsi sul percorso integro quando il percorso anteposto è configurato da Microsoft e gli annunci di route necessari vengono impostati in modo appropriato per evitare interruzioni del servizio.

NAT per il peering Microsoft

Il peering Microsoft è progettato per la comunicazione tra endpoint pubblici. In genere, gli endpoint privati locali sono sottoposti a Network Address Translation (NAT) con indirizzi IP pubblici sulla rete del cliente o del partner prima di comunicare tramite peering Microsoft. L'uso di connessioni primarie e secondarie in un'installazione attiva influisce sulla velocità di ripristino da un errore in una delle connessioni. Di seguito sono illustrate due diverse opzioni NAT:

Diagramma delle opzioni NAT per il peering Microsoft con ExpressRoute.

Opzione 1:

NAT viene applicato dopo la suddivisione del traffico tra le connessioni primarie e secondarie. Pool NAT indipendenti vengono usati per i dispositivi primari e secondari per soddisfare i requisiti NAT con stato. Il traffico di ritorno arriva sullo stesso dispositivo perimetrale attraverso il quale il flusso è in uscita.

Se una connessione Di Azure ExpressRoute non riesce, il pool NAT corrispondente diventa non raggiungibile, interrompendo tutti i flussi di rete. Questi flussi devono essere ristabiliti da TCP o dal livello di applicazione dopo il timeout della finestra. Durante l'errore, Azure non riesce a raggiungere i server locali usando il nat corrispondente fino a quando non viene ripristinata la connettività.

Opzione 2:

Prima di suddividere il traffico tra le connessioni primarie e secondarie, viene usato un pool NAT comune. Questo non introduce un singolo punto di errore, mantenendo quindi la disponibilità elevata.

Il pool NAT rimane raggiungibile anche se la connessione primaria o secondaria ha esito negativo, consentendo al livello di rete di reindirizzare i pacchetti e ripristinare più velocemente.

Nota

  • Se si usa l'opzione NAT 1 (pool NAT indipendenti per le connessioni primarie e secondarie) e si esegue il mapping di una porta di un indirizzo IP da un pool NAT a un server locale, il server non sarà raggiungibile tramite il circuito Azure ExpressRoute se la connessione corrispondente non riesce.
  • La terminazione delle connessioni BGP di Azure ExpressRoute su dispositivi con stato può causare problemi durante il failover durante la manutenzione pianificata o non pianificata da Microsoft o dal provider Azure ExpressRoute. Testare la configurazione per assicurarsi che il failover funzioni correttamente e, quando possibile, terminare le sessioni BGP nei dispositivi senza stato.

Messa a punto delle funzionalità per il peering privato

Questa sezione esamina le funzionalità facoltative che consentono di migliorare la disponibilità elevata del circuito Azure ExpressRoute, a seconda della distribuzione di Azure e della sensibilità a MTTR. In particolare, viene illustrata la distribuzione consapevole della zona dei gateway di rete virtuale di Azure ExpressRoute e il rilevamento del forwarding bidirezionale (BFD).

Gateway di rete virtuale con riconoscimento della zona di disponibilità di Azure ExpressRoute

Una zona di disponibilità in un'area di Azure combina un dominio di errore e un dominio di aggiornamento. Per ottenere la massima resilienza e disponibilità, configurare un gateway di rete virtuale Azure ExpressRoute a ridondanza di zona. Per ulteriori informazioni, vedere Informazioni sui gateway di rete virtuale con ridondanza zonale nelle Zone di Disponibilità di Azure. Per configurare un gateway di rete virtuale con ridondanza della zona, vedere Creare un gateway di rete virtuale con ridondanza della zona nelle zone di disponibilità di Azure.

Miglioramento del tempo di rilevamento degli errori

Azure ExpressRoute supporta BFD tramite peering privato, riducendo il tempo di rilevamento degli errori nella rete di livello 2 tra Microsoft Enterprise Edge (MSEE) e i relativi vicini BGP sul lato locale da circa 3 minuti (impostazione predefinita) a meno di un secondo. Il rilevamento rapido degli errori consente di accelerare il ripristino. Per altre informazioni, vedere Configurare BFD su Azure ExpressRoute.

Passaggi successivi

Questo articolo ha illustrato la progettazione per la disponibilità elevata di un circuito Azure ExpressRoute. Un punto di peering del circuito ExpressRoute di Azure viene assegnato a una posizione geografica e può essere influenzato da guasti catastrofici che influiscono sull'intera posizione.

Per considerazioni sulla progettazione per creare la connettività di rete con ridondanza geografica al backbone Microsoft che può resistere a guasti catastrofici che interessano un'intera regione, vedere Progettazione per il ripristino di emergenza con il peering privato di Azure ExpressRoute.