Allocazione della larghezza di banda del gateway

Si applica a: Windows Server 2022, Windows Server 2019, Azure Stack HCI, versioni 22H2, 21H2 e 20H2

In Windows Server 2016 la larghezza di banda del tunnel individuale per IPsec, GRE e L3 era un rapporto della capacità totale del gateway. Di conseguenza, i clienti fornivano la capacità del gateway in base alla larghezza di banda TCP standard prevista dalla macchina virtuale del gateway.

Inoltre, la larghezza di banda massima del tunnel IPsec nel gateway era limitata a (3/20)*Capacità del gateway fornita dal cliente. Ad esempio, impostando la capacità del gateway su 1000 Mbps, la capacità del tunnel IPsec è di 150 Mbps. I rapporti equivalenti per i tunnel GRE e L3 sono rispettivamente 1/5 e 1/2.

Anche se questo ha funzionato per la maggior parte delle distribuzioni, il modello a rapporto fisso non era appropriato per gli ambienti con velocità effettiva elevata. Anche quando le frequenze di trasferimento dei dati erano elevate (ad esempio, superiori a 40 Gbps), la velocità effettiva massima dei tunnel del gateway SDN era limitata a causa di fattori interni.

In Windows Server 2019, per un tipo di tunnel, la velocità effettiva massima è fissa. Anche se l'host del gateway o la macchina virtuale supporta schede di interfaccia di rete con velocità effettiva molto più elevata, la velocità effettiva massima disponibile del tunnel è fissa. Un altro problema di cui si occupa è il provisioning arbitrario dei gateway, che si verifica quando si fornisce un numero molto elevato per la capacità del gateway.

La velocità effettiva massima disponibile per diversi tipi di tunnel è:

  • IPsec = 5 Gbps

  • GRE = 15 Gbps

  • L3 = 5 Gbps

Nota

Per impostazione predefinita, l'allocazione della larghezza di banda IPsec usa il comportamento di Windows Server 2016 descritto più avanti in questo articolo. Per ottenere la velocità effettiva massima (5 Gbps), seguire questa procedura in ogni macchina virtuale del gateway:

  1. Eseguire il comando seguente per abilitare il servizio gateway:

    Set-Service gatewayservice -StartupType Automatic -Status Running
    
  2. Riavviare la macchina virtuale del gateway.

Calcolo della capacità del gateway

Idealmente, è possibile impostare la capacità di velocità effettiva del gateway sulla velocità effettiva disponibile per la macchina virtuale del gateway. Ad esempio, se si dispone di una singola macchina virtuale gateway e la velocità effettiva della scheda di interfaccia di rete host sottostante è di 25 Gbps, la velocità effettiva del gateway può essere impostata anche su 25 Gbps.

Se si usa un gateway solo per le connessioni IPsec, la capacità fissa massima disponibile è di 5 Gbps. Ad esempio, se si effettua il provisioning delle connessioni IPsec nel gateway, è possibile effettuare il provisioning solo in una larghezza di banda aggregata (in ingresso e in uscita) a 5 Gbps.

Se si usa il gateway per la connettività IPsec e GRE, è possibile effettuare il provisioning di un massimo di 5 Gbps di velocità effettiva IPsec o un massimo di 15 Gbps della velocità effettiva GRE. Ad esempio, se si effettua il provisioning di 2 Gbps di velocità effettiva IPsec, rimangono 3 Gbps di velocità effettiva IPsec da effettuare sul gateway o 9 Gbps di velocità di trasmissione GRE.

Per dirla in termini più matematici:

  • Capacità totale del gateway = 25 Gbps

  • Capacità IPsec totale disponibile = 5 Gbps (fissa)

  • Capacità GRE totale disponibile = 15 Gbps (fissa)

  • Rapporto velocità effettiva IPsec per questo gateway = 25/5 = 5 Gbps

  • Rapporto velocità effettiva GRE per questo gateway = 25/15 = 5/3 Gbps

Ad esempio, se si allocano 2 Gbps di velocità effettiva IPsec a un cliente:

Capacità disponibile rimanente nel gateway = Capacità totale del gateway - rapporto di velocità effettiva IPsec*Velocità effettiva IPsec allocata (capacità usata)

      25–5*2 = 15 Gbps

Velocità effettiva IPsec rimanente che è possibile allocare nel gateway

      5-2 = 3 Gbps

Velocità effettiva GRE rimanente che è possibile allocare nel gateway = Capacità rimanente del rapporto di velocità effettiva gateway/GRE

      15*3/5 = 9 Gbps

Il rapporto di velocità effettiva varia a seconda della capacità totale del gateway. Una cosa da notare è che è necessario impostare la capacità totale sulla larghezza di banda TCP disponibile per la macchina virtuale del gateway. Se nel gateway sono ospitate più macchine virtuali, è necessario modificare di conseguenza la capacità totale del gateway.

Inoltre, se la capacità del gateway è inferiore alla capacità totale disponibile del tunnel, la capacità totale disponibile del tunnel viene impostata sulla capacità del gateway. Ad esempio, se si imposta la capacità del gateway su 4 Gbps, la capacità totale disponibile per IPsec, L3 e GRE è impostata su 4 Gbps, lasciando il rapporto di velocità effettiva per ogni tunnel a 1 Gbps.

Comportamento di Windows Server 2016

L'algoritmo di calcolo della capacità del gateway per Windows Server 2016 rimane invariato. In Windows Server 2016 la larghezza di banda massima del tunnel IPsec era limitata a (3/20)*Capacità gateway in un gateway. I rapporti equivalenti per i tunnel GRE e L3 erano rispettivamente 1/5 e 1/2.

Se si esegue l'aggiornamento da Windows Server 2016 a Windows Server 2019:

  1. Tunnel GRE e L3: la logica di allocazione di Windows Server 2019 diventa effettiva dopo l'aggiornamento dei nodi del controller di rete a Windows Server 2019

  2. Tunnel IPSec: la logica di allocazione del gateway di Windows Server 2016 continua a funzionare fino a quando tutti i gateway nel pool di gateway non vengono aggiornati a Windows Server 2019. Per tutti i gateway nel pool di gateway, è necessario impostare il servizio gateway di Azure su automatico.

Nota

È possibile che, dopo l'aggiornamento a Windows Server 2019, un gateway venga sottoposto a provisioning eccessivo (man mano che la logica di allocazione cambia da Windows Server 2016 a Windows Server 2019). In questo caso, le connessioni esistenti nel gateway continuano a esistere. La risorsa REST per il gateway genera un avviso che indica che viene eseguito il provisioning eccessivo del gateway. In questo caso, è necessario spostare alcune connessioni a un altro gateway.