Progettazione del ripristino di emergenza con peering privato ExpressRoute

ExpressRoute è progettato per la disponibilità elevata per fornire connettività di rete privata di livello carrier alle risorse Microsoft. In altre parole, non esiste un singolo punto di errore nel percorso ExpressRoute all'interno della rete Microsoft. Per considerazioni sulla progettazione per ottimizzare la disponibilità di un circuito ExpressRoute, vedere Progettazione per la disponibilità elevata con ExpressRoute e Framework ben progettato

Tuttavia, con riferimento alla famosa legge di Murphy "se qualcosa può andare storto, lo farà, in questo articolo ci concentreremo sulle soluzioni che vanno oltre gli errori che possono essere risolti usando un singolo circuito ExpressRoute. Verranno esaminate le considerazioni sull'architettura di rete per la creazione di una connettività di rete back-end affidabile per il ripristino di emergenza usando circuiti ExpressRoute con ridondanza geografica.

Nota

I concetti descritti in questo articolo si applicano allo stesso modo sia che il circuito ExpressRoute venga creato nella rete WAN virtuale o all'esterno di essa.

Necessità di una soluzione di connettività ridondante

Esistono possibilità e istanze in cui le località di peering di ExpressRoute o un intero servizio a livello di area presentano gravi problemi di prestazioni. La causa principale di questo tipo di interruzione del servizio a livello di area include le calamità naturali. È quindi importante pianificare il ripristino di emergenza per la continuità aziendale e le applicazioni cruciali.

Nota

Quando è necessario implementare una progettazione di ripristino di emergenza in una situazione in cui il tempo è un aspetto critico, ad esempio per mantenere la continuità aziendale durante un'emergenza naturale, è necessario tenere conto dei fattori seguenti:

• Questo documento fornisce indicazioni su come implementare una progettazione affidabile per il ripristino di emergenza per più circuiti ExpressRoute configurati tramite località di peering diverse. Questo scenario presuppone che siano disponibili tempo e risorse sufficienti per configurare i circuiti ExpressRoute.
• Se è necessario configurare rapidamente una progettazione di ripristino di emergenza per un singolo circuito ExpressRoute senza ridondanza geografica, esistono le alternative seguenti:
  • Usare una VPN da sito a sito come backup per il traffico di peering privato.
  • Usare la connettività Internet come backup per il traffico di peering Microsoft.

Indipendentemente dal fatto che si eseguano applicazioni cruciali in un'area di Azure o 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 per piccole e medie imprese con Azure Site Recovery

Se la connettività ExpressRoute tra la rete locale e Microsoft è cruciale, è necessario considerare quanto segue per pianificare il ripristino di emergenza tramite ExpressRoute:

• uso di circuiti ExpressRoute con ridondanza geografica
• uso di reti di provider di servizi diversi per un circuito ExpressRoute diverso
• progettazione di ogni circuito ExpressRoute per la disponibilità elevata
• terminazione del circuito ExpressRoute diverso in una località diversa nella rete del cliente
• uso di gateway di rete virtuale ExpressRoute con riconoscimento della zona di disponibilità

Problemi per l'uso di più circuiti ExpressRoute

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. In presenza di entità con stato, come NAT o firewall nel percorso, il routing asimmetrico potrebbe bloccare il flusso del traffico. In genere, tramite il percorso di peering privato di ExpressRoute non si attraversano entità con stato, come NAT o firewall. Di conseguenza, il routing asimmetrico tramite il peering privato di ExpressRoute non blocca necessariamente il flusso del traffico.

Tuttavia, se si bilancia il carico del traffico tra percorsi paralleli con ridondanza geografica, indipendentemente dal fatto che siano presenti o meno entità con stato, si potrebbero riscontrare prestazioni di rete incoerenti. Questi percorsi paralleli con ridondanza geografica possono attraversare la stessa area metropolitana o un'area metropolitana diversa presente nella pagina Provider per località.

Ridondanza con circuiti ExpressRoute nella stessa area metropolitana

Molte aree metropolitane hanno due località ExpressRoute. Ad esempio, Amsterdam e Amsterdam2. Quando si progetta la ridondanza, è possibile creare due percorsi paralleli in Azure con entrambe le località nella stessa area metropolitana. Questa attività viene eseguita con lo stesso provider oppure è possibile scegliere di collaborare con un provider di servizi diverso per migliorare la resilienza. Un altro vantaggio di questa progettazione è che, quando si verifica il failover dell'applicazione, la latenza end-to-end tra le applicazioni locali e Microsoft rimane approssimativamente la stessa. Tuttavia, se si verifica un disastro naturale, ad esempio un terremoto, la connettività per entrambi i percorsi potrebbe non essere più disponibile.

Ridondanza con circuiti ExpressRoute in aree metropolitane diverse

Quando si usano aree metropolitane diverse per la ridondanza, è necessario selezionare la località secondaria nella stessa area geopolitica. Per scegliere una località esterna all'area geopolitica, è necessario usare lo SKU Premium per entrambi i circuiti nei percorsi paralleli. Il vantaggio di questa configurazione è la minore probabilità che un'emergenza naturale causi un'interruzione di entrambi i collegamenti, ma a costo di una maggiore latenza end-to-end.

Nota

L'abilitazione di BFD nei circuiti ExpressRoute sarà utile per rilevare più rapidamente gli errori di collegamento tra i dispositivi Microsoft Enterprise Edge (MSEE) e i router Customer Edge/Partner Edge (CE/PE). Tuttavia, il failover complessivo e la convergenza nel sito ridondante possono richiedere fino a 180 secondi in alcune condizioni di errore e potrebbe verificarsi un aumento della latenza o una riduzione delle prestazioni durante questo periodo.

Questo articolo illustra come affrontare i problemi che possono verificarsi durante la configurazione di percorsi con ridondanza geografica.

Considerazioni sulle reti locali piccole/medie

Si consideri la rete di esempio illustrata nel diagramma seguente. Nell'esempio la connettività ExpressRoute con ridondanza geografica viene stabilita tra una posizione locale di Contoso e la rete virtuale di Contoso in un'area di Azure. Nel diagramma la linea blu continua indica il percorso preferito (tramite ExpressRoute 1) e quella punteggiata rappresenta il percorso di stand-by (tramite ExpressRoute 2).

Per impostazione predefinita, se si annunciano route in modo identico su tutti i percorsi ExpressRoute, Azure bilancia il carico del traffico associato in locale tra tutti i percorsi ExpressRoute usando il routing ECMP (Equal-Cost Multi-Path).

Tuttavia, con i circuiti ExpressRoute con ridondanza geografica è necessario prendere in considerazione prestazioni di rete diverse con percorsi di rete diversi (in particolare per la latenza di rete). Per ottenere prestazioni di rete più uniformi durante il normale funzionamento, è consigliabile preferire il circuito ExpressRoute che offre la latenza minima.

È possibile indurre Azure a preferire un circuito ExpressRoute rispetto a un altro usando una delle tecniche seguenti (elencate nell'ordine di efficacia):

• annuncio di una route più specifica sul circuito ExpressRoute preferito rispetto ad altri circuiti ExpressRoute
• configurazione di un peso della connessione superiore per la connessione che collega la rete virtuale al circuito ExpressRoute preferito
• annuncio delle route su un circuito ExpressRoute meno preferito con percorso AS più lungo (anteposizione del percorso AS)

Route più specifica

Il diagramma seguente illustra come influenzare la selezione del percorso di ExpressRoute usando un annuncio di una route più specifica. Nell'esempio illustrato, l'intervallo IP /24 locale di Contoso viene annunciato come due intervalli di indirizzi /25 tramite il percorso preferito (ExpressRoute 1) e come /24 tramite il percorso di stand-by (ExpressRoute 2).

Poiché /25 è più specifico, rispetto a /24, Azure invierà il traffico destinato a 10.1.11.0/24 tramite ExpressRoute 1 nello stato normale. Se entrambe le connessioni di ExpressRoute 1 diventano non disponibili, la rete virtuale visualizzerà l'annuncio di route 10.1.11.0/24 solo tramite ExpressRoute 2 e quindi verrà usato il circuito di standby in questo stato di errore.

Peso della connessione

Lo screenshot seguente illustra la configurazione del peso di una connessione ExpressRoute tramite il portale di Azure.

Il diagramma seguente illustra come influenzare la selezione del percorso di ExpressRoute usando il peso della connessione. Il peso predefinito della connessione è 0. Nell'esempio seguente il peso della connessione per ExpressRoute 1 è configurato come 100. Quando una rete virtuale riceve un prefisso di route annunciato tramite più circuiti ExpressRoute, la rete virtuale preferisce la connessione con il peso più elevato.

Se entrambe le connessioni di ExpressRoute 1 diventano non disponibili, la rete virtuale visualizzerà l'annuncio di route 10.1.11.0/24 solo tramite ExpressRoute 2 e quindi verrà usato il circuito di standby in questo stato di errore.

Anteposizione del percorso AS

Il diagramma seguente illustra come influenzare la selezione del percorso di ExpressRoute usando l'anteposizione del percorso AS. Nel diagramma l'annuncio di route su ExpressRoute 1 indica il comportamento predefinito di EBGP. Nell'annuncio di route su ExpressRoute 2, l'ASN della rete locale viene anteposto anche al percorso AS della route. Quando la stessa route viene ricevuta tramite più circuiti ExpressRoute, in base al processo di selezione della route EBGP, la rete virtuale preferisce la route con il percorso AS più breve.

Se entrambe le connessioni di ExpressRoute 1 diventano non disponibili, la rete virtuale visualizzerà l'annuncio di route 10.1.11.0/24 solo tramite ExpressRoute 2. Di conseguenza, il percorso AS più lungo diventerebbe irrilevante. Verrebbe pertanto usato il circuito di standby in questo stato di errore.

Se si influenza la preferenza di Azure per uno dei percorsi ExpressRoute usando una di queste tecniche, è inoltre necessario assicurarsi che anche la rete locale preferisca lo stesso percorso ExpressRoute per il traffico associato ad Azure per evitare flussi asimmetrici. In genere, il valore della preferenza locale viene usato per influenzare la rete locale in modo che preferisca un circuito ExpressRoute rispetto ad altri. La preferenza locale è una metrica IBGP (Internal BGP). Viene preferita la route BGP con il valore di preferenza locale più alto.

Importante

Quando si usano determinati circuiti ExpressRoute come stand-by, è necessario gestirli attivamente e testare periodicamente le operazioni di failover.

Rete aziendale distribuita di grandi dimensioni

In presenza di una rete aziendale distribuita di grandi dimensioni, è probabile che siano disponibili più circuiti ExpressRoute. In questa sezione viene illustrato come progettare il ripristino di emergenza usando i circuiti ExpressRoute attivo-attivo senza dover usare altri circuiti di stand-by.

Si consideri l'esempio illustrato nel diagramma seguente. Nell'esempio Contoso ha due località locali connesse a due distribuzioni IaaS Contoso in due aree di Azure diverse tramite circuiti ExpressRoute in due località di peering diverse.

Il modo in cui si progetta il ripristino di emergenza influisce sul modo in cui viene instradato il traffico tra aree e località (da area1/area2 a località2/località1). Si considerino due architetture di emergenza diverse che instradano il traffico tra aree e località in modo diverso.

Scenario 1

Nel primo scenario si progetta il ripristino di emergenza in modo che tutto il traffico tra un'area di Azure e la rete locale passi attraverso il circuito ExpressRoute locale nello stato stabile. In caso di errori del circuito ExpressRoute locale, viene usato il circuito ExpressRoute remoto per tutti i flussi di traffico tra Azure e la rete locale.

Lo scenario 1 è illustrato nel diagramma seguente. Nel diagramma le linee verdi indicano i percorsi per il flusso del traffico tra la rete virtuale 1 e le reti locali. Le linee blu indicano i percorsi per il flusso del traffico tra la rete virtuale 2 e le reti locali. Le linee continue indicano il percorso desiderato nello stato stabile e le linee tratteggiate indicano il percorso del traffico in caso di errore del circuito ExpressRoute corrispondente che trasporta il flusso di traffico con stato stabile.

È possibile progettare lo scenario usando il peso della connessione per influenzare le reti virtuali in modo che preferiscano la connessione alla località di peering locale ExpressRoute per il traffico associato alla rete locale. Per completare la soluzione, è necessario garantire il flusso del traffico inverso simmetrico. È possibile usare le preferenze locali nella sessione IBGP tra i router BGP (su cui i circuiti ExpressRoute vengono terminati sul lato locale) in modo da preferire un circuito ExpressRoute. La soluzione è illustrata nel diagramma seguente.

Scenario 2

Lo scenario 2 è illustrato nel diagramma seguente. Nel diagramma le linee verdi indicano i percorsi per il flusso del traffico tra la rete virtuale 1 e le reti locali. Le linee blu indicano i percorsi per il flusso del traffico tra la rete virtuale 2 e le reti locali. Nello stato stabile (linee continue nel diagramma) tutto il traffico tra reti virtuali e posizioni locali scorre normalmente usando il backbone Microsoft e passa attraverso l'interconnessione tra posizioni locali solo nello stato di errore (linee punteggiate nel diagramma) di un circuito ExpressRoute.

La soluzione è illustrata nel diagramma seguente. Come illustrato, è possibile progettare lo scenario usando una route più specifica (opzione 1) o l'anteposizione di un percorso AS (opzione 2) per influenzare la selezione del percorso della rete virtuale. Per influenzare la selezione della route di rete locale per il traffico associato ad Azure, è necessario configurare l'interconnessione tra la posizione locale come meno preferibile. La procedura per configurare il collegamento di interconnessione come preferibile dipende dal protocollo di routing usato all'interno della rete locale. È possibile usare la preferenza locale con IBGP o la metrica con IGP (OSPF o IS-IS).

Importante

Quando uno o più circuiti ExpressRoute sono connessi a più reti virtuali, il traffico tra le reti virtuali può essere instradato tramite ExpressRoute. Si tratta però un'operazione sconsigliata. Per abilitare la connettività tra reti virtuali, configurare il peering di rete virtuale.

Passaggi successivi

In questo articolo è stato illustrato come progettare per il ripristino di emergenza di una connettività di peering privato di un circuito ExpressRoute. 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 per piccole e medie imprese con Azure Site Recovery