Azure Well-Architected Framework-beoordeling van een Azure NAT-gateway
Dit artikel bevat best practices voor een Azure NAT-gateway. De richtlijnen zijn gebaseerd op de vijf pijlers van hoogwaardige architectuur: Kostenoptimalisatie, operationele uitmuntendheid, prestatie-efficiëntie, betrouwbaarheid en beveiliging.
We gaan ervan uit dat u een werkende kennis hebt van Azure Virtual Network NAT en Azure NAT-gateway en dat u goed bekend bent met de respectieve functies. Bekijk ter informatie de volledige set Azure Virtual Network NAT documentatie.
NAT staat voor Network Address Translation. Zie An introduction to Network Address Translation (Een inleiding tot Network Address Translation).
Kostenoptimalisatie
Toegang tot PaaS-services moet worden Azure Private Link of service-eindpunten (inclusief opslag), om het gebruik van een NAT-gateway te voorkomen. Private Link en service-eindpunten vereisen geen doorkruising van de NAT-gateway om toegang te krijgen tot PaaS-services. Deze aanpak vermindert de kosten per GB verwerkte gegevens, wanneer de kosten van een NAT-gateway worden vergeleken met Private Link of service-eindpunten. Er zijn extra beveiligingsvoordelen voor het gebruik van Private Link of service-eindpunten.
Prestatie-efficiëntie
Elke NAT-gatewayresource biedt maximaal 50 Gbps aan doorvoer. U kunt uw implementaties opsplitsen in meerdere subnetten en vervolgens kunt u aan elk subnet of elke groep subnetten een NAT-gateway toewijzen om uit te schalen.
Elke NAT-gateway ondersteunt 64.000 stromen voor respectievelijk TCP en UDP per toegewezen uitgaand IP-adres. Er kunnen maximaal 16 IP-adressen worden toegewezen aan een NAT-gateway. De IP-adressen kunnen afzonderlijke standaard openbare IP-adressen, het openbare IP-voorvoegsel of beide zijn. Lees de volgende sectie over Source Network Address Translation (SNAT) voor meer informatie. TCP staat voor Transmission Control Protocol en UDP staat voor User Datagram Protocol.
SNAT-uitputting
- NAT-gatewayresources hebben een standaardtime-out voor TCP-inactiviteit van 4 minuten. Als deze instelling wordt gewijzigd in een hogere waarde, houdt NAT stromen langer vast en kan dit leiden tot overbodige druk op de beschikbare SNAT-poorten.
- Atomische aanvragen (één aanvraag per verbinding) zijn een slechte ontwerpkeuze, omdat de schaal wordt beperkt, de prestaties worden beperkt en de betrouwbaarheid wordt verkleind. Gebruik in plaats daarvan HTTP/S-verbindingen om het aantal verbindingen en de bijbehorende SNAT-poorten te verminderen. Met hergebruik van verbindingen kan de toepassing beter worden geschaald. De prestaties van toepassingen worden verbeterd als gevolg van minder handshakes, overhead en cryptografische bewerkingskosten bij het gebruik van TLS.
- DNS kan veel afzonderlijke stromen op volume introduceren, wanneer de client het resultaat van DNS-resolvers niet in deaching opseert. Gebruik DNS-caching om het volume van stromen te verminderen en het aantal SNAT-poorten te verminderen. DNS staat doorgaans voor Domain Name System, het naamgevingssysteem voor de resources die zijn verbonden met internet of met een particulier netwerk.
- UDP-stromen, zoals DNS-zoekups, gebruiken SNAT-poorten tijdens de time-out voor inactieve gegevens. Hoe langer de time-out voor inactiviteit, hoe hoger de druk op de SNAT-poorten. Een kortere time-out voor inactief gebruik, zoals 4 minuten, verkort de tijdsduur die de SNAT-poorten zullen gebruiken.
- Gebruik verbindingspools om vorm te geven aan het volume van uw verbindingen.
- Verlaat nooit zo maar een TCP-stroom en maak gebruik van TCP-timers om de stroom op te schonen. Als u TCP de verbinding niet expliciet laat sluiten, blijft de TCP-verbinding geopend. Tussenliggende systemen en eindpunten houden deze verbinding in gebruik, waardoor de SNAT-poort op zijn beurt niet beschikbaar is voor andere verbindingen. Dit antipatroon kan toepassingsfouten en SNAT-uitputting veroorzaken.
- Wijzig TCP-close-gerelateerde timerwaarden op besturingssysteemniveau niet, zonder deskundige kennis van de implicaties. Terwijl de TCP-stack wordt hersteld, kunnen de prestaties van uw toepassing negatief worden beïnvloed wanneer de eindpunten van een verbinding niet overeenkomende verwachtingen hebben. Het wijzigen van timerwaarden is meestal een teken van een onderliggend ontwerpprobleem. Als de onderliggende toepassing andere antipatronen heeft, kan SNAT-uitputting ook worden versterkt als de timerwaarden worden gewijzigd.
Lees de volgende richtlijnen om de schaal en betrouwbaarheid van uw service te verbeteren:
- Bekijk het effect van het verminderen van de time-out voor TCP-inactief naar lagere waarden. Een standaard time-out voor inactieve tijd van 4 minuten kan eerder SNAT-poortinventarisatie vrijmaken.
- Overweeg asynchrone pollingpatronen voor langlopende bewerkingen om uw verbindingsbronnen vrij te maken voor andere bewerkingen.
- Langdende stromen, zoals hergebruikte TCP-verbindingen, moeten TCP-keepalives of keepalives voor toepassingslagen gebruiken om te voorkomen dat tussenliggende systemen een time-out krijgen. U moet de time-out voor inactieve tijd alleen verhogen als laatste redmiddel en de hoofdoorzaak wordt mogelijk niet opgelost. Een lange time-out kan leiden tot fouten met een laag percentage, wanneer de time-out is verlopen en kan leiden tot vertraging en onnodige fouten.
- Er moeten goede patronen voor nieuwe pogingen worden gebruikt om agressieve nieuwe pogingen/bursts te voorkomen tijdens een tijdelijke storing of herstel na storingen. Een antipatroon, atomische verbindingen genoemd, is wanneer u een nieuwe TCP-verbinding maakt voor elke HTTP-bewerking. Atomische verbindingen zorgen ervoor dat uw toepassing niet goed kan worden geschaald en dat resources worden verspild. Voeg altijd meerdere bewerkingen samen in een pijplijn in dezelfde verbinding. Uw app zal er voordeel bij hebben qua transactiesnelheid en resourcekosten. Wanneer uw toepassing gebruikmaakt van transportlaagversleuteling (bijvoorbeeld TLS), zijn er aanzienlijke kosten verbonden aan de verwerking van nieuwe verbindingen. Zie Azure Cloud Design Patterns (Ontwerppatronen voor Azure Cloud) voor meer best practice-patronen.
Operationele uitmuntendheid
Hoewel nat-gateway kan worden gebruikt met Azure Kubernetes Service (AKS), wordt deze niet beheerd als onderdeel van AKS. Als u een NAT-gateway toewijst aan het CNI-subnet, stelt u AKS-pods in staat om via de NAT-gateway te gaan.
Wanneer u meerdere NAT-gateways in zones of tussen regio's gebruikt, moet u de uitgaande IP-ruimte beheerbaar houden met openbare IP-voorvoegsels van Azure of BYOIP-voorvoegsels. Als het IP-voorvoegsel groter is dan 16 IP-adressen, kunt u afzonderlijke IP-adressen maken op basis van het IP-voorvoegsel en deze toewijzen aan de NAT-gateway.
Gebruik Azure Monitor om SNAT-poortgebruik te bewaken en te waarschuwen.
Wanneer een subnet is geconfigureerd met een NAT-gateway, vervangt de NAT-gateway alle andere uitgaande verbindingen met het openbare internet voor alle VM's in dat subnet. NAT-gateway heeft voorrang op een load balancer met of zonder uitgaande regels en over openbare IP-adressen die rechtstreeks aan VM's zijn toegewezen. Azure houdt de richting van een stroom bij en asymmetrische routering vindt niet plaats. Het inkomende verkeer wordt correct vertaald, zoals een load balancer-front-end-IP en wordt afzonderlijk vertaald van uitgaand verkeer via een NAT-gateway. Door deze scheiding kunnen binnenkomende en uitgaande services naadloos naast elkaar bestaan.
NAT-gateway wordt aanbevolen als de standaardinstelling voor het inschakelen van uitgaande connectiviteit voor virtuele netwerken. NAT-gateway is efficiënter en minder operationeel complex dan andere uitgaande connectiviteitstechnieken in Azure. NAT-gateways wijzen SNAT-poorten op aanvraag toe en gebruiken een efficiënter algoritme om te voorkomen dat SNAT-poorten opnieuw worden gebruikt. Vertrouw niet op standaard uitgaande connectiviteit (een antipatroon) voor uw estate. Definieer deze in plaats daarvan expliciet met NAT-gatewaybronnen.
Betrouwbaarheid
NAT-gatewayresources zijn zeer beschikbaar en bespannen meerdere foutdomeinen. Dit geldt ook als een NAT-gateway regionaal wordt geïmplementeerd, zonder beschikbaarheidszones. Wanneer u beschikbaarheidszones gebruikt voor zone-isolatie, kunnen NAT-gateways ook zonaal worden geïmplementeerd.
Isolatie van beschikbaarheidszone kan niet worden opgegeven, tenzij elk subnet alleen resources binnen een specifieke zone heeft. Implementeer in plaats daarvan een subnet voor elk van de beschikbaarheidszones waar VM's worden geïmplementeerd, lijn de zone-VM's uit met overeenkomende zonelijke NAT-gateways en bouw afzonderlijke zonelijke stacks. Een virtuele machine in beschikbaarheidszone 1 bevindt zich bijvoorbeeld in een subnet met andere resources die zich ook alleen in beschikbaarheidszone 1 bevindt. Een NAT-gateway is geconfigureerd in beschikbaarheidszone 1 om dat subnet te bedienen. Zie het volgende diagram.
Beveiliging
Een veelgebruikte benadering is het ontwerpen van een scenario voor een virtueel netwerkapparaat (NVA) met firewalls van derden of met proxyservers. Wanneer een NAT-gateway wordt geïmplementeerd in een subnet met een virtuele-machineschaalset van NNET's, gebruiken deze NPO's het NAT-gatewayadres(en) voor uitgaande connectiviteit, in tegenstelling tot het IP-adres van een load balancer of de afzonderlijke IP-adressen. Zie Integrate Azure Firewall with Azure Azure Firewall Standard Load Balancer (Integratievan Azure Firewall met Azure Standard Load Balancer) om dit scenario met Standard Load Balancer.
Azure Security Center kunt controleren op verdachte uitgaande verbindingen via een NAT-gateway. Dit is een waarschuwingsfunctie in Azure Security Center.