Azure Well-Architected Framework-granskning av en Azure NAT-gateway
Den här artikeln innehåller metodtips för en Azure NAT-gateway. Vägledningen baseras på de fem grundpelarna för utmärkt arkitektur: kostnadsoptimering, driftseffektivitet, prestandaeffektivitet, tillförlitlighet och säkerhet.
Vi förutsätter att du har kunskaper om Azure Virtual Network NAT och Azure NAT-gateway och att du har goda kunskaper om respektive funktioner. Som en uppdatering kan du läsa den fullständiga uppsättningen Azure Virtual Network NAT dokumentation.
NAT står för network address translation. Se En introduktion till Network Address Translation.
Kostnadsoptimering
Åtkomst till PaaS-tjänster bör ske via Azure Private Link eller tjänstslutpunkter (inklusive lagring), för att undvika att använda en NAT-gateway. Private Link och tjänstslutpunkter kräver inte att NAT-gatewayen bläddrar för att få åtkomst till PaaS-tjänster. Den här metoden minskar avgiften per GB bearbetade data när du jämför kostnaderna för en NAT-gateway med Private Link eller till tjänstslutpunkter. Det finns ytterligare säkerhetsfördelar med att använda Private Link slutpunkter eller tjänstslutpunkter.
Prestandaeffektivitet
Varje NAT-gatewayresurs ger upp till 50 Gbit/s dataflöde. Du kan dela upp dina distributioner i flera undernät och sedan tilldela varje undernät eller grupper av undernät en NAT-gateway att skala ut.
Varje NAT-gateway stöder 64 000 flöden för TCP respektive UDP per tilldelad utgående IP-adress. Upp till 16 IP-adresser kan tilldelas till en NAT-gateway. IP-adresserna kan vara enskilda offentliga IP-standardadresser, offentliga IP-prefix eller båda. Mer information finns i följande avsnitt om källnätverksadressöversättning (SNAT). TCP står för Transmission Control Protocoloch UDP står för User Datagram Protocol.
SNAT-utmattning
- NAT-gatewayresurser har en standard-TIMEOUT för TCP-inaktivitet på 4 minuter. Om den här inställningen ändras till ett högre värde håller NAT på för längre flöden och kan orsaka onödigt tryck på SNAT-portinventeringen.
- Atomiska begäranden (en begäran per anslutning) är ett dåligt designval eftersom det begränsar skalning, minskar prestanda och minskar tillförlitligheten. Återanvänd i stället HTTP/S-anslutningar för att minska antalet anslutningar och associerade SNAT-portar. Återanvändning av anslutningar gör att programmet kan skalas på ett bättre sätt. Programprestandan förbättras på grund av minskade kostnader för handskakningar, omkostnader och kryptografisk åtgärd vid användning av TLS.
- DNS kan introducera många enskilda flöden på volymen när klienten inte cachelagrar DNS-matcharens resultat. Använd DNS-cachelagring för att minska mängden flöden och minska antalet SNAT-portar. DNS står vanligtvis Domain Name System, namngivningssystemet för de resurser som är anslutna till Internet eller till ett privat nätverk.
- UDP-flöden, till exempel DNS-sökning, använder SNAT-portar under tidsgränsen för inaktivitet. Ju längre tidsgränsen för inaktivitet är, desto högre är trycket på SNAT-portar. En kortare tidsgräns för inaktivitet, till exempel 4 minuter, minskar den tid som SNAT-portarna kommer att användas.
- Använd anslutningspooler för att forma anslutningsvolymen.
- Lämna aldrig ett TCP-flöde tyst och förlita dig på TCP-timers för att rensa flödet. Om du inte tillåter att TCP uttryckligen stänger anslutningen förblir TCP-anslutningen öppen. Mellanliggande system och slutpunkter behåller den här anslutningen, vilket i sin tur gör att SNAT-porten inte är tillgänglig för andra anslutningar. Det här antimönstret kan utlösa programfel och SNAT-utmattning.
- Ändra inte TCP-close-relaterade timervärden på operativsystemnivå, utan expertkunskaper om konsekvenserna. TCP-stacken återställs, men programprestandan kan påverkas negativt när slutpunkterna för en anslutning inte matchar förväntningarna. Att ändra timervärden är vanligtvis ett tecken på ett underliggande designproblem. Om det underliggande programmet har andra antimönster kan SNAT-utmattning också förstärkas om timervärdena ändras.
Läs följande riktlinjer för att förbättra tjänstens skala och tillförlitlighet:
- Utforska effekten av att minska TCP-tidsgränsen för inaktivitet till lägre värden. En standardtids tidsgräns för inaktivitet på 4 minuter kan frigöra SNAT-portinventering tidigare.
- Överväg asynkrona avsökningsmönster för långvariga åtgärder för att frigöra anslutningsresurser för andra åtgärder.
- Långlivade flöden, till exempel återanvända TCP-anslutningar, bör använda TCP-keepalives eller keepalives på programnivå för att undvika att mellanliggande system tar för lång tid. 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 går ut och det kan leda till en fördröjning och onödiga fel.
- Bra återförsöksmönster bör användas för att undvika aggressivt återförsök/ökningar under tillfälligt fel eller återställning av fel. Ett antimönster, som kallas atomiska anslutningar,är när du skapar en ny TCP-anslutning för varje HTTP-åtgärd. Atomiska anslutningar förhindrar att ditt program skalas väl och slösar resurser. Pipelines alltid flera åtgärder i samma anslutning. Ditt program drar nytta av transaktionshastighet och resurskostnader. När ditt program använder kryptering på transportnivå (till exempel TLS) finns det en betydande kostnad kopplad till bearbetningen av nya anslutningar. Se Azure Cloud Design Patterns (Designmönster för Azure-moln) för fler metodmönster.
Utmärkt driftseffektivitet
Även om NAT-gateway kan användas med Azure Kubernetes Service (AKS) hanteras den inte som en del av AKS. Om du tilldelar en NAT-gateway till CNI-undernätet aktiverar du AKS-poddar för utgående genom NAT-gatewayen.
När du använder flera NAT-gatewayer över zoner eller mellan regioner ska du hålla den utgående IP-egendomen hanterbar med hjälp av offentliga IP-prefix i Azure eller BYOIP-prefix. Om IP-prefixet är större än 16 IP-adresser kan du skapa enskilda IP-adresser från IP-prefixet och tilldela dem till NAT-gatewayen.
Använd Azure Monitor aviseringar för att övervaka och avisering om SNAT-portanvändning.
När ett undernät har konfigurerats med en NAT-gateway ersätter NAT-gatewayen alla andra utgående anslutningar till det offentliga Internet för alla virtuella datorer i det undernätet. NAT-gatewayen har företräde framför en lastbalanserare med eller utan regler för utgående trafik och över offentliga IP-adresser som tilldelas direkt till virtuella datorer. Azure spårar flödets riktning, och asymmetrisk routning sker inte. Inkommande trafik med ursprung översätts korrekt, till exempel en lastbalanserares IP-adress på frontend-sidan, och den översätts separat från utgående ursprunglig trafik via en NAT-gateway. Den här separationen gör att inkommande och utgående tjänster kan samexistera sömlöst.
NAT-gateway rekommenderas som standard för att aktivera utgående anslutning för virtuella nätverk. NAT-gatewayen är effektivare och mindre operativt komplex än andra tekniker för utgående anslutningar i Azure. NAT-gatewayer allokerar SNAT-portar på begäran och använder en mer effektiv algoritm för att förhindra SNAT-portåteranvändningskonflikter. Förlita dig inte på utgående standardanslutningar (ett antimönster) för din egendom. Definiera den i stället uttryckligen med NAT-gatewayresurser.
Tillförlitlighet
NAT-gatewayresurser har hög tillgänglig och sträcker sig över flera feldomäner. Detta gäller även om en NAT-gateway distribueras regionalt, utan tillgänglighetszoner. När du använder tillgänglighetszoner för zonisolering kan NAT-gatewayer också distribueras zonindelade.
Isolering av tillgänglighetszoner kan inte tillhandahållas, såvida inte varje undernät endast har resurser inom en viss zon. Distribuera i stället ett undernät för var och en av de tillgänglighetszoner där virtuella datorer distribueras, justera zonindelade virtuella datorer med matchande zonindelade NAT-gatewayer och skapa separata zonindelade stackar. Till exempel 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 det undernätet. Se följande diagram.
Säkerhet
En vanlig metod är att utforma ett scenario med utgående virtuell nätverksinstallation (NVA) med brandväggar från tredje part eller med proxyservrar. När en NAT-gateway distribueras till ett undernät med en VM-skalningsuppsättning med NVA:er använder dessa NVA:er NAT-gatewayadresser för utgående anslutning, till skillnad från IP-adressen för en lastbalanserare eller enskilda IP-adresser. Information om hur du använder det här Azure Firewall finns i Integrera Azure Firewall med Azure Standard Load Balancer.
Microsoft Defender for Cloud kan övervaka misstänkta utgående anslutningar via en NAT-gateway. Det här är en aviseringsfunktion i Microsoft Defender för molnet.