I den här artikeln beskrivs metodtips för en Azure NAT-gateway. Vägledningen baseras på de fem grundpelarna för arkitekturkvalitet: kostnadsoptimering, driftseffektivitet, prestandaeffektivitet, tillförlitlighet och säkerhet.
Som en förutsättning för den här vägledningen bör du ha en fungerande kunskap om Azure NAT Gateway och förstå dess respektive funktioner. Mer information finns i Dokumentation om Azure NAT Gateway.
Kostnadsoptimering
Konfigurera åtkomst till PaaS-lösningar (plattform som en tjänst) via Azure Private Link eller tjänstslutpunkter, inklusive lagring, så att du inte behöver använda en NAT-gateway. Private Link- och tjänstslutpunkter kräver inte bläddering av NAT-gatewayen för att få åtkomst till PaaS-tjänster. Den här metoden minskar kostnaden per gigabyte (GB) för bearbetade data jämfört med kostnaden för att använda en NAT-gateway. Private Link och tjänstslutpunkter ger också säkerhetsfördelar.
Prestandaeffektivitet
Varje NAT-gatewayresurs ger upp till 50 gigabit per sekund (Gbit/s) dataflöde. Du kan dela upp dina distributioner i flera undernät och sedan tilldela en NAT-gateway till varje undernät eller grupp med undernät som ska skalas ut.
Varje offentlig IP-adress för NAT-gatewayen innehåller 64 512 SNAT-portar (Source Network Address Translation). Du kan tilldela upp till 16 IP-adresser till en NAT-gateway, inklusive enskilda offentliga IP-standardadresser, det offentliga IP-prefixet eller båda. För varje tilldelad utgående IP-adress som går till samma målslutpunkt kan NAT-gatewayen stödja upp till 50 000 samtidiga flöden för TCP (Transmission Control Protocol) respektive UDP (User Datagram Protocol).
SNAT-uttömning
Överväg följande vägledning för att förhindra SNAT-överbelastning:
NAT-gatewayresurser har en standardtidsgräns för TCP-inaktivitet på fyra minuter. Du kan konfigurera tidsgränsen i upp till 120 minuter. Om du ändrar den här inställningen till ett högre värde än standardvärdet håller NAT-gatewayen fast vid flöden längre, vilket kan skapa onödigt tryck på SNAT-portinventeringen.
Atomiska begäranden (en begäran per anslutning) begränsar skalan, minskar prestanda och minskar tillförlitligheten. I stället för atomiska begäranden kan du återanvända HTTP- eller HTTPS-anslutningar för att minska antalet anslutningar och associerade SNAT-portar. När du återanvänder anslutningar kan programmet skalas bättre. Programmets prestanda förbättras på grund av minskade kostnader för handskakningar, omkostnader och kryptografiska åtgärder när du använder TLS (Transport Layer Security).
Om du inte cachelagrar DNS-matcharens resultat kan DNS-sökningar (Domain Name System) introducera många enskilda flöden på volymen. Använd DNS-cachelagring för att minska mängden flöden och minska antalet SNAT-portar. DNS är det namngivningssystem som mappar domännamn till IP-adresser för resurser som är anslutna till Internet eller till ett privat nätverk.
UDP-flöden, till exempel DNS-sökningar, använder SNAT-portar under tidsgränsen för inaktivitet. Tidsgränsen för udp-inaktiviteten är fast vid fyra minuter.
Använd anslutningspooler för att forma anslutningsvolymen.
Om du vill rensa flöden ska du inte tyst överge TCP-flöden eller förlita dig på TCP-timers. Om du inte tillåter att TCP uttryckligen stänger en anslutning förblir TCP-anslutningen öppen. Mellanliggande system och slutpunkter håller anslutningen i bruk, vilket gör SNAT-porten otillgänglig för andra anslutningar. Det här antimönstret kan utlösa programfel och SNAT-överbelastning.
Ändra inte TCP-close-relaterade timervärden på OS-nivå om du inte känner till konsekvenserna. Om slutpunkterna för en anslutning har felmatchade förväntningar kan TCP-stacken återställas, men det kan påverka programmets prestanda negativt. Du har vanligtvis ett underliggande designproblem om du behöver ändra tidsinställda värden. Och om det underliggande programmet har andra antimönster och du ändrar timervärden kan du också påskynda SNAT-överbelastning.
Läs följande vägledning för att förbättra tjänstens skala och tillförlitlighet:
Överväg effekterna av att minska tidsgränsen för TCP-inaktivitet till ett lägre värde. En standardtimeout för inaktivitet på fyra minuter kan i förebyggande syfte frigöra SNAT-portinventering.
Överväg asynkrona avsökningsmönster för långvariga åtgärder för att frigöra anslutningsresurser för andra åtgärder.
Överväg att använda TCP keepalives eller keepalives på programnivå för långlivade TCP-flöden, till exempel återanvända TCP-anslutningar, för att förhindra att mellanliggande system överskrider tidsgränsen. Du bör bara öka tidsgränsen för inaktivitet som en sista utväg och det kanske inte löser rotorsaken. En lång timeout kan orsaka fel med låg hastighet när tidsgränsen upphör att gälla. Det kan också medföra en fördröjning och onödiga fel. Du kan aktivera TCP keepalives från ena sidan av en anslutning för att hålla en anslutning vid liv från båda sidor.
Överväg att använda UDP keepalives för långlivade UDP-flöden för att förhindra att mellanliggande system överskrider tidsgränsen. När du aktiverar UDP keepalives på ena sidan av anslutningen är endast en sida av anslutningen aktiv. Du måste aktivera UDP keepalives på båda sidor av en anslutning för att hålla en anslutning vid liv.
Överväg graciösa återförsöksmönster för att undvika aggressiva återförsök och bursts under tillfälligt fel eller återställning av fel. För antipattern-atomiska anslutningar skapar du en ny TCP-anslutning för varje HTTP-åtgärd. Atomiska anslutningar slösar resurser och förhindrar att programmet skalar bra.
Om du vill öka transaktionshastigheten och minska resurskostnaderna för ditt program kan du alltid pipelines flera åtgärder till samma anslutning. När ditt program använder kryptering på transportnivå, till exempel TLS, ökar kostnaden för ny anslutningsbearbetning. Mer metodtips finns i Designmönster för Azure-moln.
Driftsäkerhet
Du kan använda en NAT-gateway med Azure Kubernetes Service (AKS), men NAT-gatewayhantering ingår inte i AKS. Om du tilldelar en NAT-gateway till CNI-undernätet (Container Networking Interface) gör du det möjligt för AKS-poddar att ta sig ut via NAT-gatewayen.
När du använder flera NAT-gatewayer mellan zoner eller regioner ska du hålla den utgående IP-egendomen hanterbar med azures offentliga IP-prefix eller BYOIP-prefix (bring-your-own IP). Du kan inte tilldela en IP-prefixstorlek som är större än 16 IP-adresser (/28 prefixstorlek) till en NAT-gateway.
Använd Azure Monitor-aviseringar för att övervaka och varna om SNAT-portanvändning, bearbetade eller borttagna paket och mängden överförda data. Använd flödesloggar för nätverkssäkerhetsgrupp (NSG) för att övervaka utgående trafikflöde från virtuella datorinstanser (VM) i ett NAT-gatewaykonfigurerat undernät.
När du konfigurerar ett undernät med en NAT-gateway ersätter NAT-gatewayen alla andra utgående anslutningar till det offentliga Internet för alla virtuella datorer i undernätet. NAT-gatewayen har företräde framför en lastbalanserare, oavsett regler för utgående trafik. Gatewayen har också företräde framför offentliga IP-adresser som tilldelas direkt till virtuella datorer. Azure spårar flödets riktning och förhindrar asymmetrisk routning. Inkommande trafik, till exempel en frontend-IP för lastbalanseraren, översätts korrekt och översätts separat från utgående trafik via en NAT-gateway. Den här separationen gör att inkommande och utgående tjänster kan samexistera sömlöst.
Vi rekommenderar en NAT-gateway som standard för att aktivera utgående anslutning för virtuella nätverk. En NAT-gateway ger effektivitet och driftsmässig enkelhet jämfört med andra utgående anslutningstekniker i Azure. NAT-gatewayer allokerar SNAT-portar på begäran och använder en effektivare algoritm för att förhindra konflikter vid återanvändning av SNAT-portar. Förlita dig inte på standardregeln för utgående anslutning för din egendom. Definiera i stället uttryckligen konfigurationen med NAT-gatewayresurser.
Tillförlitlighet
NAT-gatewayresurser är mycket tillgängliga i en tillgänglighetszon och omfattar flera feldomäner. Du kan distribuera en NAT-gateway till en no zone där Azure automatiskt väljer en zon för att placera NAT-gatewayen eller isolera NAT-gatewayen till en specifik tillgänglighetszon.
För att tillhandahålla isolering av tillgänglighetszoner måste varje undernät endast ha resurser inom en viss zon. Om du vill implementera den här metoden kan du:
- Distribuera ett undernät för var och en av tillgänglighetszonerna där virtuella datorer distribueras.
- Justera de zonindeala virtuella datorerna med matchande zonindeliga NAT-gatewayer.
- Skapa separata zonstackar.
I följande diagram finns en virtuell dator i tillgänglighetszon 1 i ett undernät med andra resurser som också bara finns i tillgänglighetszon 1. En NAT-gateway konfigureras i tillgänglighetszon 1 för att betjäna undernätet.
Virtuella nätverk och undernät omfattar alla tillgänglighetszoner i en region. Du behöver inte dela upp dem efter tillgänglighetszoner för att hantera zonindeliga resurser.
Säkerhet
Med en NAT-gateway behöver enskilda virtuella datorer eller andra beräkningsresurser inte offentliga IP-adresser och kan förbli helt privata. Resurser utan en offentlig IP-adress kan fortfarande nå externa källor utanför det virtuella nätverket. Du kan associera ett offentligt IP-prefix för att säkerställa att du använder en sammanhängande uppsättning IP-adresser för utgående anslutning. Du kan konfigurera målbrandväggsregler baserat på den här förutsägbara IP-listan.
En vanlig metod är att utforma ett scenario med utgående virtuell nätverksinstallation (NVA) med brandväggar som inte kommer från Microsoft eller med proxyservrar. När du distribuerar en NAT-gateway till ett undernät med en VM-skalningsuppsättning med NVA:er använder dessa NVA:er en eller flera NAT-gatewayadresser för utgående anslutning i stället för en lastbalanserares IP-adress eller enskilda IP-adresser. Information om hur du använder det här scenariot med Azure Firewall finns i Integrera Azure Firewall med Azure Standard Load Balancer.
Du kan använda aviseringsfunktionen Microsoft Defender för molnet för att övervaka misstänkt utgående anslutning i en NAT-gateway.
Deltagare
Den här artikeln underhålls av Microsoft. Det har ursprungligen skrivits av följande medarbetare.
Huvudförfattare:
- Ethan Haslett | Senior Cloud Solution Architect
Om du vill se icke-offentliga LinkedIn-profiler loggar du in på LinkedIn.
Nästa steg
- Microsoft Well-Architected Framework
- Självstudie: Skapa en NAT-gateway med hjälp av Azure-portalen
- Rekommendationer för användning av tillgänglighetszoner och regioner