Questo articolo descrive le procedure consigliate per un gateway NAT di Azure. Le linee guida si basano sui cinque pilastri dell'eccellenza architetturale: Ottimizzazione dei costi, Eccellenza operativa, Efficienza delle prestazioni, Affidabilità e Sicurezza.
Come prerequisito per questa guida, è necessario avere una conoscenza funzionante del gateway NAT di Azure e comprendere le rispettive funzionalità. Per altre informazioni, vedere la documentazione del gateway NAT di Azure.
Ottimizzazione dei costi
Configurare l'accesso alle soluzioni PaaS (Platform as a Service) tramite collegamento privato di Azure o endpoint di servizio, inclusa l'archiviazione, in modo che non sia necessario usare un gateway NAT. collegamento privato e gli endpoint di servizio non richiedono l'attraversamento del gateway NAT per accedere ai servizi PaaS. Questo approccio riduce il costo per gigabyte (GB) dei dati elaborati, rispetto al costo dell'uso di un gateway NAT. collegamento privato ed endpoint di servizio offrono anche vantaggi per la sicurezza.
Efficienza prestazionale
Ogni risorsa gateway NAT offre fino a 50 gigabit al secondo (Gbps) di velocità effettiva. È possibile suddividere le distribuzioni in più subnet e quindi assegnare un gateway NAT a ogni subnet o gruppo di subnet per aumentare il numero di istanze.
Ogni indirizzo IP pubblico del gateway NAT fornisce 64.512 porte SNAT (Source Network Address Translation). È possibile assegnare fino a 16 indirizzi IP a un gateway NAT, inclusi singoli indirizzi IP pubblici standard, il prefisso IP pubblico o entrambi. Per ogni indirizzo IP in uscita assegnato che passa allo stesso endpoint di destinazione, il gateway NAT può supportare fino a 50.000 flussi simultanei rispettivamente per Transmission Control Protocol (TCP) e User Datagram Protocol (UDP).
Esaurimento SNAT
Considerare le indicazioni seguenti per evitare l'esaurimento SNAT:
Le risorse del gateway NAT hanno un timeout di inattività TCP predefinito di quattro minuti. È possibile configurare il timeout per un massimo di 120 minuti. Se si modifica questa impostazione impostando un valore superiore rispetto all'impostazione predefinita, il gateway NAT rimane attivo per i flussi più a lungo, che può creare una pressione superflua sull'inventario delle porte SNAT.
Le richieste atomiche (una richiesta per connessione) limitano la scalabilità, riducono le prestazioni e riducono l'affidabilità. Anziché le richieste atomica, è possibile riutilizzare le connessioni HTTP o HTTPS per ridurre il numero di connessioni e le porte SNAT associate. Quando si riutilizzano le connessioni, l'applicazione può essere ridimensionata in modo migliore. Le prestazioni dell'applicazione migliorano a causa di una riduzione dei costi di handshake, overhead e operazioni di crittografia quando si usa Transport Layer Security (TLS).
Se non si memorizzano nella cache i risultati del sistema di risoluzione DNS, le ricerche DNS (Domain Name System) possono introdurre molti singoli flussi al volume. Usare la memorizzazione nella cache DNS per ridurre il volume dei flussi e ridurre il numero di porte SNAT. DNS è il sistema di denominazione che esegue il mapping dei nomi di dominio agli indirizzi IP per le risorse connesse a Internet o a una rete privata.
I flussi UDP, ad esempio le ricerche DNS, usano le porte SNAT durante il timeout di inattività. Il timer di timeout di inattività UDP è fisso a quattro minuti.
Usare i pool di connessioni per definire il volume di connessioni.
Per pulire i flussi, non abbandonare in modo invisibile all'utente i flussi TCP o basarsi sui timer TCP. Se non si consente a TCP di chiudere in modo esplicito una connessione, la connessione TCP rimane aperta. I sistemi intermedi e gli endpoint mantengono questa connessione in uso, che rende la porta SNAT non disponibile per altre connessioni. Questo antipattern può attivare errori dell'applicazione e esaurimento SNAT.
Non modificare i valori del timer correlati a chiusura TCP a livello di sistema operativo, a meno che non si conoscano le implicazioni. Se gli endpoint di una connessione hanno aspettative non corrispondenti, lo stack TCP può essere ripristinato, ma potrebbe influire negativamente sulle prestazioni dell'applicazione. In genere si verifica un problema di progettazione sottostante se è necessario modificare i valori timer. E se l'applicazione sottostante ha altri antipattern e si modificano i valori timer, è anche possibile accelerare l'esaurimento SNAT.
Esaminare le indicazioni seguenti per migliorare la scalabilità e l'affidabilità del servizio:
Prendere in considerazione gli effetti della riduzione del timeout di inattività TCP a un valore inferiore. Un timeout di inattività predefinito di quattro minuti può liberare in modo preliminare l'inventario delle porte SNAT.
Prendere in considerazione i modelli di polling asincroni per le operazioni a esecuzione prolungata per liberare le risorse di connessione per altre operazioni.
Prendere in considerazione l'uso di keepalives TCP o keep-layer dell'applicazione per i flussi TCP di lunga durata, ad esempio le connessioni TCP riutilizzate, per evitare che i sistemi intermedi eseghino il timeout. È consigliabile aumentare solo il timeout di inattività come ultima risorsa e potrebbe non risolvere la causa radice. Un timeout lungo può causare errori a bassa frequenza alla scadenza del timeout. Può anche introdurre un ritardo e errori non necessari. È possibile abilitare i keep-alive TCP da un lato di una connessione per mantenere attiva una connessione da entrambi i lati.
Prendere in considerazione l'uso di keepalives UDP per i flussi UDP di lunga durata per impedire il timeout dei sistemi intermedi. Quando si abilitano i keep-up UDP su un lato della connessione, solo un lato della connessione rimane attivo. È necessario abilitare i keep-up UDP su entrambi i lati di una connessione per mantenere attiva una connessione.
Prendere in considerazione modelli di ripetizione dei tentativi regolari per evitare tentativi aggressivi e picchi durante un errore temporaneo o un ripristino degli errori. Per le connessioni atomiche antipattern, si crea una nuova connessione TCP per ogni operazione HTTP. Le connessioni atomiche sprecano risorse e impediscono all'applicazione di ridimensionarsi correttamente.
Per aumentare la velocità delle transazioni e ridurre i costi delle risorse per l'applicazione, eseguire sempre più operazioni nella stessa connessione. Quando l'applicazione usa la crittografia del livello di trasporto, ad esempio TLS, la nuova elaborazione della connessione aumenta i costi. Per altri modelli di procedure consigliate, vedere Modelli di progettazione cloud di Azure.
Eccellenza operativa
È possibile usare un gateway NAT con servizio Azure Kubernetes (servizio Azure Kubernetes), ma la gestione del gateway NAT non è inclusa nel servizio Azure Kubernetes. Se si assegna un gateway NAT alla subnet CNI (Container Networking Interface), si abilitano i pod del servizio Azure Kubernetes in uscita tramite il gateway NAT.
Quando si usano più gateway NAT tra zone o aree, mantenere gestibile l'ambiente IP in uscita usando prefissi IP pubblici di Azure o prefissi BYOIP (Bring Your Own IP). Non è possibile assegnare una dimensione del prefisso IP maggiore di 16 indirizzi IP (/28 dimensioni del prefisso) a un gateway NAT.
Usare gli avvisi di Monitoraggio di Azure per monitorare e avvisare l'utilizzo delle porte SNAT, i pacchetti elaborati o eliminati e la quantità di dati trasmessi. Usare i log dei flussi del gruppo di sicurezza di rete (NSG) per monitorare il flusso del traffico in uscita dalle istanze di macchine virtuali (VM) in una subnet configurata dal gateway NAT.
Quando si configura una subnet con un gateway NAT, il gateway NAT sostituisce tutte le altre connessioni in uscita alla rete Internet pubblica per tutte le macchine virtuali in tale subnet. Il gateway NAT ha la precedenza su un servizio di bilanciamento del carico, indipendentemente dalle regole in uscita. Il gateway ha anche la precedenza sugli indirizzi IP pubblici assegnati direttamente alle macchine virtuali. Azure tiene traccia della direzione di un flusso e impedisce il routing asimmetrico. Il traffico in ingresso, ad esempio un ip front-end del servizio di bilanciamento del carico, viene convertito correttamente e viene convertito separatamente dal traffico originato in uscita tramite un gateway NAT. Questa separazione consente ai servizi in ingresso e in uscita di coesistere senza problemi.
È consigliabile usare un gateway NAT come impostazione predefinita per abilitare la connettività in uscita per le reti virtuali. Un gateway NAT offre efficienza e semplicità operativa rispetto ad altre tecniche di connettività in uscita in Azure. I gateway NAT allocano porte SNAT su richiesta e usano un algoritmo più efficiente per evitare conflitti di riutilizzo delle porte SNAT. Non fare affidamento sull'antipattern di connettività in uscita predefinito per l'ambiente. Definire invece in modo esplicito la configurazione con le risorse del gateway NAT.
Affidabilità
Le risorse del gateway NAT sono a disponibilità elevata in una zona di disponibilità e si estendono su più domini di errore. È possibile distribuire un gateway NAT in un'area in cui Azure seleziona automaticamente una zona per posizionare il gateway NAT o isola il gateway NAT in una zona di disponibilità specifica.
Per garantire l'isolamento della zona di disponibilità, ogni subnet deve avere risorse solo all'interno di una zona specifica. Per implementare questo approccio, è possibile:
- Distribuire una subnet per ognuna delle zone di disponibilità in cui vengono distribuite le macchine virtuali.
- Allineare le macchine virtuali di zona con i gateway NAT di zona corrispondenti.
- Creare stack di zona separati.
Nel diagramma seguente una macchina virtuale nella zona di disponibilità 1 si trova in una subnet con altre risorse che si trovano anche nella zona di disponibilità 1. Un gateway NAT è configurato nella zona di disponibilità 1 per gestire tale subnet.
Le reti virtuali e le subnet si estendono su tutte le zone di disponibilità in un'area. Non è quindi necessario suddividerle in base alle zone di disponibilità per supportare le risorse di zona.
Sicurezza
Con un gateway NAT, le singole macchine virtuali o altre risorse di calcolo non necessitano di indirizzi IP pubblici e possono rimanere completamente private. Le risorse senza un indirizzo IP pubblico possono comunque raggiungere origini esterne all'esterno della rete virtuale. È possibile associare un prefisso IP pubblico per assicurarsi di usare un set contiguo di indirizzi IP per la connettività in uscita. È possibile configurare le regole del firewall di destinazione in base a questo elenco di indirizzi IP prevedibili.
Un approccio comune consiste nel progettare uno scenario di appliance virtuale di rete (NVA) solo in uscita con firewall non Microsoft o con server proxy. Quando si distribuisce un gateway NAT in una subnet con un set di scalabilità di macchine virtuali di rete, tali appliance virtuali di rete usano uno o più indirizzi gateway NAT per la connettività in uscita anziché un INDIRIZZO IP del servizio di bilanciamento del carico o i singoli INDIRIZZI IP. Per usare questo scenario con Firewall di Azure, vedere Integrare Firewall di Azure con il servizio di bilanciamento del carico Standard di Azure.
È possibile usare la funzionalità di avviso Microsoft Defender per il cloud per monitorare eventuali connettività in uscita sospetta in un gateway NAT.
Collaboratori
Questo articolo viene gestito da Microsoft. Originariamente è stato scritto dai seguenti contributori.
Autore principale:
- Ethan Haslett | Senior Cloud Solution Architect
Per visualizzare i profili LinkedIn non pubblici, accedere a LinkedIn.
Passaggi successivi
- Microsoft Well-Architected Framework
- Esercitazione: Creare un gateway NAT usando il portale di Azure
- Consigli per l'uso di zone e aree di disponibilità