Disponibilità elevata di Gateway RAS

È possibile usare questo argomento per informazioni sulle configurazioni a disponibilità elevata per il gateway multi-tenant Servizio di accesso remoto per la rete SDN (Software Defined Networking).

Questo argomento include le sezioni seguenti.

• RAS Gateway Overview

• Panoramica dei pool di gateway

• Panoramica della distribuzione del gateway Servizio di accesso remoto

• Integrazione del gateway Servizio di accesso remoto con controller di rete

RAS Gateway Overview

Se l'organizzazione è un provider di servizi di configurazione (CSP) o un'organizzazione con più tenant, è possibile distribuire il gateway Servizio di accesso remoto in modalità multi-tenant per fornire il routing del traffico di rete da e verso reti virtuali e fisiche, Internet incluso.

È possibile distribuire gateway Servizio di accesso remoto in modalità multi-tenant come gateway perimetrale per instradare il traffico di rete del cliente tenant alle reti virtuali e alle risorse tenant.

Quando si distribuiscono più istanze di macchine virtuali gateway Servizio di accesso remoto che offrono disponibilità elevata e failover, si distribuisce un pool di gateway. In Windows Server 2012 R2 tutte le macchine virtuali del gateway hanno formato un singolo pool, che ha reso un po' difficile la separazione logica della distribuzione del gateway. Il gateway Windows Server 2012 R2 offre una distribuzione di ridondanza 1:1 per le macchine virtuali del gateway, il che ha comportato una sottoutilizzazione della capacità disponibile per le connessioni VPN da sito a sito (S2S).

Questo problema viene risolto in Windows Server 2016, che fornisce più pool di gateway, che possono essere di tipi diversi per la separazione logica. La nuova modalità di ridondanza M+N consente una configurazione di failover più efficiente.

Per altre informazioni generali sul gateway Servizio di accesso remoto, vedere Gateway Servizio di accesso remoto.

Panoramica dei pool di gateway

In Windows Server 2016 è possibile distribuire i gateway in uno o più pool.

La figura seguente illustra diversi tipi di pool di gateway che forniscono il routing del traffico tra reti virtuali.

Ogni ambito è caratterizzato dalle proprietà seguenti.

• Ogni pool è M+N ridondanti. Ciò significa che viene eseguito il backup di un numero 'M' di macchine virtuali gateway attive da parte di un numero 'N' di macchine virtuali gateway di standby. Il valore di N (gateway di standby) è sempre minore o uguale a M (gateway attivi).

• Un pool può eseguire una delle singole funzioni del gateway, come Internet Key Exchange versione 2 (IKEv2) S2S, Layer 3 (L3) e Generic Routing Encapsulation (GRE), oppure il pool è in grado di eseguire tutte queste funzioni.

• È possibile assegnare un singolo indirizzo IP pubblico a tutti i pool o a un subset di pool. In questo modo, si riduce notevolmente il numero di indirizzi IP pubblici che è necessario usare, perché è possibile che tutti i tenant si connettano al cloud con un singolo indirizzo IP. La sezione seguente relativa alla disponibilità elevata e al bilanciamento del carico descrive il funzionamento di tale operazione.

• È possibile scalare facilmente un pool di gateway verso l'alto o verso il basso aggiungendo o rimuovendo le macchine virtuali gateway nel pool. Rimozione o aggiunta di gateway non interrotti i servizi forniti da un pool. È inoltre possibile aggiungere e rimuovere l'intero pool di gateway.

• Le connessioni di un singolo tenant possono terminare in più pool e più gateway in un pool. Tuttavia, se un tenant ha connessioni che terminano in un pool di gateway di tipo Tutti, non può sottoscrivere altri pool di gateway di tipo Tutti o tipi di gateway singoli.

I pool di gateway offrono anche la flessibilità necessaria per abilitare scenari aggiuntivi:

• Pool a tenant singolo: è possibile creare un pool da usare da un tenant.

• Se si vendono servizi cloud tramite canali partner (rivenditori), è possibile creare set separati di pool per ogni rivenditore.

• Più pool possono fornire la stessa funzione gateway, ma capacità diverse. Ad esempio, è possibile creare un pool di gateway che supporti connessioni IKEv2 S2S con velocità effettiva sia elevata che bassa.

Panoramica della distribuzione del gateway Servizio di accesso remoto

La figura seguente illustra una tipica distribuzione del provider di servizi cloud (CSP) del gateway Servizio di accesso remoto.

Con questo tipo di distribuzione, i pool di gateway vengono distribuiti dietro un servizio di bilanciamento del carico software (SLB), che consente al CSP di assegnare un singolo indirizzo IP pubblico per l'intera distribuzione. Più connessioni gateway di un tenant possono terminare in più pool di gateway e anche in più gateway all'interno di un pool. Questo è illustrato tramite le connessioni IKEv2 S2S nel diagramma precedente, ma lo stesso è applicabile anche ad altre funzioni del gateway, ad esempio L3 e GATEWAY GRE.

Nell'illustrazione, il dispositivo MT BGP è un gateway multi-tenant Servizio di accesso remoto con BGP. Il protocollo BGP multi-tenant viene usato per il routing dinamico. Il routing per un tenant è centralizzato: ovvero un singolo punto, denominato RR (Route Reflector), gestisce il peering BGP per tutti i siti tenant. La RR stessa viene distribuita in tutti i gateway di un pool. Ciò comporta una configurazione in cui le connessioni di un tenant (percorso dati) terminano su più gateway, ma l’RR per il tenant (punto di peering BGP - percorso di controllo) si trova su uno solo dei gateway.

Il router BGP è separato nel diagramma per rappresentare tale concetto di routing centralizzato. L'implementazione BGP del gateway fornisce anche il routing di transito, che consente al cloud di fungere da punto di transito per il routing tra due siti tenant. Queste funzionalità BGP sono applicabili a tutte le funzioni del gateway.

Integrazione del gateway Servizio di accesso remoto con controller di rete

Il gateway Servizio di accesso remoto è completamente integrato con Controller di rete in Windows Server 2016. Quando vengono distribuiti gateway Servizio di accesso remoto e Controller di rete, il controller di rete esegue le funzioni seguenti.

• Distribuzione dei pool di gateway

• Configurazione delle connessioni tenant in ciascun gateway

• Passaggio del traffico di rete a un gateway di standby in caso di errore del gateway

Le sezioni seguenti forniscono informazioni dettagliate sul gateway Servizio di accesso remoto e sul Controller di rete.

• Provisioning e bilanciamento del carico delle connessioni gateway (IKEv2, L3 e GRE)

• Disponibilità elevata per IKEv2 S2S

• Disponibilità elevata per GRE

• Disponibilità elevata per i gateway di inoltro L3

Provisioning e bilanciamento del carico delle connessioni gateway (IKEv2, L3 e GRE)

Quando un tenant richiede una connessione gateway, la richiesta viene inviata al Controller di rete. Il Controller di rete è configurato con informazioni su tutti i pool di gateway, inclusa la capacità di ciascun pool e di ogni gateway in ciascuno di essi. Il Controller di rete seleziona il pool e il gateway corretti per la connessione. Questa selezione si basa sul requisito di larghezza di banda per la connessione. Il Controller di rete usa un algoritmo "più adatto" per selezionare le connessioni in modo efficiente all’interno di un pool. Inoltre, il punto di peering BGP per la connessione viene designato in questo momento nel caso in cui si tratti della prima connessione del tenant.

Dopo che il Controller di rete seleziona un gateway Servizio di accesso remoto per la connessione, il Controller di rete effettua il provisioning della configurazione necessaria per la connessione al gateway. Se la connessione è una connessione IKEv2 S2S, il Controller di rete effettua anche il provisioning di una regola NAT (Network Address Translation) nel pool SLB; questa regola NAT nel pool SLB indirizza le richieste di connessione dal tenant al gateway designato. I tenant sono differenziati in base all'IP di origine, che dovrebbe essere univoco.

Se il routing BGP è abilitato per la connessione, il peering BGP viene avviato dal gateway Servizio di accesso remoto e i percorsi vengono scambiati tra gateway locali e cloud. I percorsi appresi da BGP (o che sono percorsi configurati in modo statico se BGP non viene usato) vengono inviati al Controller di rete. Il Controller di rete esegue quindi il plumbing dei percorsi fino agli host Hyper-V in cui vengono installate le macchine virtuali tenant. A questo punto, il traffico tenant può essere instradato al sito locale corretto. Il Controller di rete crea anche i criteri di virtualizzazione di rete Hyper-V associati che specificano i percorsi del gateway e li distribuisce agli host Hyper-V.

Disponibilità elevata per IKEv2 S2S

Un gateway Servizio di accesso remoto all’innterno di un pool è costituito da connessioni e peering BGP di tenant diversi. Ogni pool ha gateway attivi "M" e gateway di standby "N".

Il Controller di rete gestisce l'errore dei gateway nel modo seguente.

• Il Controller di rete esegue costantemente il ping dei gateway in tutti i pool e può rilevare un gateway in errore o privo di errori. Il Controller di rete può rilevare i tipi seguenti di errori del gateway Servizio di accesso remoto.

  • Errore della macchina virtuale del gateway Servizio di accesso remoto

  • Errore dell'host Hyper-V in cui è in esecuzione il gateway Servizio di accesso remoto

  • Errore del servizio gateway Servizio di accesso remoto

  Il Controller di rete archivia la configurazione di tutti i gateway attivi distribuiti. La configurazione è costituita da impostazioni di connessione e impostazioni di routing.

• Quando un gateway rimanda una risposta di errore, influisce sulle connessioni tenant nel gateway, nonché sulle connessioni tenant che si trovano in altri gateway, ma la cui RR risiede nel gateway in errore. Il tempo inattivo delle ultime connessioni è minore di quello precedente. Quando il Controller di rete rileva un gateway in errore, esegue le attività seguenti.

  • Rimuove i percorsi delle connessioni interessati dagli host di calcolo.

  • Rimuove i criteri di virtualizzazione della rete Hyper-V in questi host.

  • Seleziona un gateway di standby, lo converte in un gateway attivo e configura il gateway.

  • Modifica i mapping NAT nel pool SLB per indirizzare le connessioni al nuovo gateway.

• Contemporaneamente, man mano che viene attivata la configurazione nel nuovo gateway attivo, vengono ristabilite le connessioni IKEv2 S2S e il peering BGP. Le connessioni e il peering BGP possono essere avviati dal gateway cloud o dal gateway locale. I gateway aggiornano i percorsi e li inviano al Controller di rete. Dopo che il Controller di rete apprende i nuovi percorsi individuati dai gateway, il Controller di rete invia i percorsi e i criteri di virtualizzazione di rete Hyper-V associati agli host Hyper-V in cui risiedono le macchine virtuali dei tenant interessati dagli errori. Questa attività del Controller di rete è simile alla circostanza di una nuova configurazione di connessione, ma solo su larga scala.

Disponibilità elevata per GRE

Il processo di risposta al failover del gateway Servizio di accesso remoto da parte del Controller di rete, tra cui il rilevamento degli errori, la copia della configurazione di connessione e routing al gateway di standby, il failover del routing BGP/statico delle connessioni interessate (incluso il ritiro e la ripetizione del plumbing dei percorsi negli host di calcolo e il re-peering BGP) e la riconfigurazione dei criteri di virtualizzazione della rete Hyper-V negli host di calcolo, è lo stesso per i gateway e le connessioni GRE. Tuttavia, la ricreazione delle connessioni GRE avviene in modo diverso e la soluzione a disponibilità elevata per GRE ha alcuni requisiti aggiuntivi.

Al momento della distribuzione del gateway, a ogni macchina virtuale del gateway Servizio di accesso remoto viene assegnato un indirizzo IP dinamico (DIP). Inoltre, a ogni macchina virtuale del gateway viene assegnato un indirizzo IP virtuale (VIP) per la disponibilità elevata GRE. Gli indirizzi VIP vengono assegnati solo ai gateway nei pool che possono accettare connessioni GRE e non a pool che non sono in grado di accettare connessioni GRE. I VIP assegnati vengono annunciati ai commutatori top of rack (TOR) usando BGP, che quindi annuncia ulteriormente i VIP nella rete fisica cloud. In questo modo i gateway sono raggiungibili dai router remoti o dai dispositivi di terze parti in cui risiede l'altra estremità della connessione GRE. Questo peering BGP è diverso dal peering BGP a livello di tenant per lo scambio di percorsi del tenant.

Al momento del provisioning della connessione GRE, il Controller di rete seleziona un gateway, configura un endpoint GRE nel gateway selezionato e restituisce l'indirizzo VIP del gateway assegnato. Questo indirizzo VIP viene quindi configurato come indirizzo del tunnel GRE di destinazione nel router remoto.

Quando un gateway rimanda un errore, il Controller di rete copia l'indirizzo VIP del gateway non riuscito e altri dati di configurazione nel gateway di standby. Quando il gateway di standby diventa attivo, annuncia l'indirizzo VIP al commutatore TOR e oltre nella rete fisica. I router remoti continuano a connettere i tunnel GRE allo stesso indirizzo VIP e l'infrastruttura di routing garantisce che i pacchetti vengano instradati al nuovo gateway attivo.

Disponibilità elevata per i gateway di inoltro L3

Un gateway di inoltro Hyper-V Network Virtualization L3 è un ponte tra l'infrastruttura fisica nel data center e l'infrastruttura virtualizzata nel cloud di virtualizzazione della rete Hyper-V. In un gateway di inoltro L3 multi-tenant ogni tenant usa la propria rete logica con tag VLAN per la connettività con la rete fisica del tenant.

Quando un nuovo tenant crea un nuovo gateway L3, Gestione servizi gateway controller di rete seleziona una macchina virtuale gateway disponibile e configura una nuova interfaccia tenant con un indirizzo IP dello spazio dell'indirizzo IP del cliente (CA) a disponibilità elevata (dalla rete logica con tag VLAN del tenant). L'indirizzo IP viene usato come indirizzo IP peer nel gateway remoto (rete fisica) ed è l'hop successivo per raggiungere la rete di virtualizzazione Hyper-V del tenant.

A differenza delle connessioni di rete IPsec o GRE, il commutatore TOR non apprenderà la rete VLAN con tag del tenant in modo dinamico. Il routing per la rete con tag VLAN del tenant deve essere configurato sul commutatore TOR e su tutti i commutatori intermedi e i router tra l'infrastruttura fisica e il gateway per garantire la connettività end-to-end. Di seguito è riportato un esempio di configurazione della rete virtuale CSP, come illustrato nella figura seguente.

Di seguito sono riportate le configurazioni del gateway tenant di esempio, come illustrato nella figura seguente.

Di seguito è riportata l'illustrazione di queste configurazioni in un data center CSP.

Gli errori del gateway, il rilevamento degli errori e il processo di failover del gateway nel contesto di un gateway di inoltro L3 sono simili ai processi per i gateway RAS IKEv2 e GRE. Le differenze sono il modo in cui vengono gestiti gli indirizzi IP esterni.

Quando lo stato della macchina virtuale del gateway diventa non integro, il Controller di rete seleziona uno dei gateway di standby dal pool e effettua nuovamente il provisioning delle connessioni di rete e del routing nel gateway di standby. Durante lo spostamento delle connessioni, anche l'indirizzo IP dello spazio CA a disponibilità elevata del gateway di inoltro L3 viene spostato nella nuova macchina virtuale del gateway insieme all'indirizzo IP BGP dello spazio CA del tenant.

Poiché l'indirizzo IP di peering L3 viene spostato nella nuova macchina virtuale del gateway durante il failover, l'infrastruttura fisica remota è nuovamente in grado di connettersi a questo indirizzo IP e, successivamente, raggiungere il carico di lavoro Virtualizzazione rete Hyper-V. Per il routing dinamico BGP, poiché l’indirizzo IP dello spazio CA BGP viene spostato nella macchina virtuale del nuovo gateway, il router BGP remoto può ristabilire il peering e apprendere di nuovo tutti percorsi di virtualizzazione della rete Hyper-V.