Routing Anycast con il server di route di Azure
È possibile distribuire l'applicazione in zone di disponibilità in una singola area di Azure per ottenere una disponibilità più elevata, ma a volte potrebbe essere necessario distribuire le applicazioni in più aree, per ottenere una resilienza più elevata, prestazioni migliori per gli utenti in tutto il mondo o una migliore continuità aziendale. Esistono diversi approcci che è possibile adottare per indirizzare gli utenti a una delle posizioni in cui viene distribuita un'applicazione in più aree: approcci basati su DNS, ad esempio Gestione traffico di Azure, servizi basati sul routing come Frontdoor di Azure o Load Balancer tra aree di Azure.
I servizi di Azure precedenti sono consigliati per consentire agli utenti di passare alla posizione dell'applicazione migliore tramite Internet pubblico usando indirizzi IP pubblici, ma non supportano reti private e indirizzi IP. Questo articolo illustra l'uso di un approccio basato su route (anycast IP) per fornire distribuzioni di applicazioni multi-area e con rete privata.
L'ip anycast consiste essenzialmente nella pubblicità esattamente dello stesso indirizzo IP da più di una posizione, in modo che i pacchetti provenienti dagli utenti dell'applicazione vengano instradati all'area più vicina (in termini di routing). Fornire la raggiungibilità in più aree su anycast offre alcuni vantaggi rispetto agli approcci basati su DNS, ad esempio non dover fare affidamento sui client che non memorizzano nella cache le risposte DNS e non richiedono di modificare la progettazione DNS per l'applicazione.
Topologia
Nella progettazione di questo scenario, lo stesso indirizzo IP viene annunciato dalle reti virtuali in aree di Azure diverse, in cui le appliance virtuali di rete annunciano l'indirizzo IP dell'applicazione tramite il server di route di Azure. Il diagramma seguente illustra due topologie hub-spoke semplici, ognuna in un'area di Azure diversa. Un'appliance virtuale di rete in ogni area annuncia la stessa route (a.b.c.d/32 in questo esempio) al server di route di Azure locale (il prefisso di route non deve sovrapporsi alle reti locali e di Azure). Le route vengono propagate ulteriormente alla rete locale tramite ExpressRoute. Quando gli utenti dell'applicazione vogliono accedere all'applicazione dall'ambiente locale, l'infrastruttura DNS (non coperta da questo documento) risolve il nome DNS dell'applicazione nell'indirizzo IP anycast (a.b.c.d), che i dispositivi di rete locali instradano a una delle due aree.
La decisione di quale delle aree disponibili è selezionata è interamente basata sugli attributi di routing. Se le route di entrambe le aree sono identiche, la rete locale usa in genere il routing ECMP (Equal-Cost Multi-Path) per inviare ogni flusso dell'applicazione a ogni area. È anche possibile modificare gli annunci generati da ogni appliance virtuale di rete in Azure per scegliere una delle aree preferite. Ad esempio, usando il percorso AS BGP in sospeso per stabilire un percorso deterministico dall'ambiente locale al carico di lavoro di Azure.
Importante
Le appliance virtuali di rete che annunciano le route devono includere un meccanismo di controllo integrità per interrompere la pubblicità della route quando l'applicazione non è disponibile nelle rispettive aree geografiche, per evitare il traffico di blackholing.
Restituire il traffico
Quando il traffico dell'applicazione dal client locale arriva a una delle appliance virtuali di rete in Azure, l'appliance virtuale di rete esegue il proxy inverso della connessione o DNAT (Destination Network Address Translation). Invia quindi i pacchetti all'applicazione effettiva, che in genere risiede in una rete virtuale spoke con peering alla rete virtuale hub in cui viene distribuita l'appliance virtuale di rete. Il traffico di ritorno dall'applicazione torna attraverso l'appliance virtuale di rete, che si verifica naturalmente se l'appliance virtuale di rete esegue il proxy inverso della connessione (o esegue NAT di origine anche a NAT di destinazione).
In caso contrario, il traffico in arrivo all'applicazione viene ancora originato dall'indirizzo IP del client locale originale. In questo caso, i pacchetti possono essere reindirizzati all'appliance virtuale di rete con route definite dall'utente . È necessario prestare particolare attenzione se in ogni area sono presenti più istanze di appliance virtuali di rete, perché il traffico potrebbe essere asimmetrico (il traffico in ingresso e in uscita attraversa istanze di appliance virtuali di rete diverse). Il traffico asimmetrico non è in genere un problema se le appliance virtuali di rete sono senza stato, ma genera errori se le appliance virtuali di rete tengono traccia degli stati di connessione, ad esempio i firewall.