Problemen met uitgaande verbindingen oplossen

Dit artikel is bedoeld om oplossingen te bieden voor veelvoorkomende problemen die zich kunnen voordoen met uitgaande verbindingen van een Azure Load Balancer. De meeste problemen met uitgaande connectiviteit die klanten ervaren, worden veroorzaakt door SNAT-poortuitputting (Source Network Address Translation) en time-outs van verbindingen die leiden tot uitgevallen pakketten. Dit artikel bevat stappen voor het oplossen van elk van deze problemen.

SNAT vermijden

De beste manier om SNAT-poortuitputting te voorkomen, is om, indien mogelijk, de noodzaak voor SNAT te elimineren. In sommige gevallen is dit mogelijk niet mogelijk. Bijvoorbeeld wanneer u verbinding maakt met openbare eindpunten. In sommige gevallen is dit echter mogelijk en kan dit worden bereikt door privé verbinding te maken met resources. Als u verbinding maakt met Azure-services zoals Storage, SQL, Cosmos DB of een andere van de Azure-servicesdie hier worden vermeld, elimineert het gebruik van Azure Private Link de noodzaak voor SNAT. Als gevolg hiervan loopt u geen risico op een mogelijk verbindingsprobleem vanwege uitputting van de SNAT-poort.

Private Link-service wordt ook ondersteund door Snowflake, MongoDB, Confluent, Elastic en andere dergelijke services.

Uitputting van SNAT-poort (PAT) beheren

Kortstondige poorten die worden gebruikt voor PAT zijn een uitputtingsresource, zoals beschreven in Zelfstandige VM zonder openbaar IP-adres en VM met load balanced zonder openbaar IP-adres. U kunt uw gebruik van kortstondige poorten bewaken en deze vergelijken met uw huidige toewijzing om het risico op SNAT-uitputting te bepalen of te bevestigen met behulp van deze handleiding.

Als u weet dat u veel uitgaande TCP- of UDP-verbindingen met hetzelfde doel-IP-adres en dezelfde poort initieert en u merkt dat uitgaande verbindingen mislukken of door ondersteuning wordt geadviseerd dat u SNAT-poorten (vooraf toegewezen kortstondige poorten die worden gebruikt door PAT)uitputt, hebt u verschillende algemene oplossingsopties. Bekijk deze opties en bepaal wat beschikbaar en het beste is voor uw scenario. Het is mogelijk dat een of meer u kunnen helpen bij het beheren van dit scenario.

Als u problemen hebt met het begrijpen van het gedrag van de uitgaande verbinding, kunt u IP-stackstatistieken (netstat) gebruiken. Het kan ook handig zijn om verbindingsgedrag te observeren met behulp van pakketopnamen. U kunt deze pakketopnamen uitvoeren in het gast-besturingssysteem van uw exemplaar of Network Watcher voor pakketopname.

Handmatig SNAT-poorten toewijzen om de SNAT-poorten per VM te maximaliseren

Zoals gedefinieerd in vooraf toegewezen poorten,wijst load balancer automatisch poorten toe op basis van het aantal VM's in de back-end. Dit wordt standaard voorzichtig gedaan om schaalbaarheid te garanderen. Als u het maximum aantal VM's in de back-end weet, kunt u handmatig SNAT-poorten toewijzen in elke uitgaande regel. Als u bijvoorbeeld weet dat u maximaal 10 VM's hebt, kunt u 6.400 SNAT-poorten per VM toewijzen in plaats van de standaardwaarde 1024.

De toepassing wijzigen om verbindingen opnieuw te gebruiken

U kunt de vraag naar kortstondige poorten die voor SNAT worden gebruikt, verminderen door verbindingen in uw toepassing opnieuw te gebruiken. Hergebruik van verbindingen is vooral relevant voor protocollen zoals HTTP/1.1, waarbij hergebruik van verbindingen de standaardinstelling is. En andere protocollen die HTTP als transport gebruiken (bijvoorbeeld REST), kunnen daar op zijn beurt van profiteren.

Hergebruik is altijd beter dan afzonderlijke atomische TCP-verbindingen voor elke aanvraag. Hergebruik resulteert in beter presterende, zeer efficiënte TCP-transacties.

De toepassing wijzigen voor het gebruik van verbindingsgroepering

U kunt een schema voor verbindingsgroepering in uw toepassing gebruiken, waarbij aanvragen intern worden verdeeld over een vaste set verbindingen (waar mogelijk opnieuw worden gebruikt). Dit schema beperkt het aantal kortstondige poorten dat in gebruik is en maakt een meer voorspelbare omgeving. Dit schema kan ook de doorvoer van aanvragen verhogen door meerdere gelijktijdige bewerkingen toe te staan wanneer één verbinding wordt geblokkeerd bij het beantwoorden van een bewerking.

Verbindingsgroepering bestaat mogelijk al binnen het framework dat u gebruikt voor het ontwikkelen van uw toepassing of de configuratie-instellingen voor uw toepassing. U kunt verbindingspooling combineren met hergebruik van verbindingen. Uw meerdere aanvragen verbruiken vervolgens een vast, voorspelbaar aantal poorten naar hetzelfde DOEL-IP-adres en dezelfde poort. De aanvragen profiteren ook van efficiënt gebruik van TCP-transacties die de latentie en het resourcegebruik verminderen. UDP-transacties kunnen ook profiteren, omdat het beheren van het aantal UDP-stromen op zijn beurt uitputtingsomstandigheden kan voorkomen en het gebruik van de SNAT-poort kan beheren.

Wijzig de toepassing om minder agressieve logica voor opnieuw proberen te gebruiken

Wanneer vooraf toegewezen kortstondige poorten die worden gebruikt voor PAT zijn uitgeput of toepassingsfouten optreden, agressieve of brute force nieuwe pogingen zonder verval en logica voor terugval veroorzaken uitputting of persistentie. U kunt de vraag naar kortstondige poorten verminderen met behulp van een minder agressieve logica voor opnieuw proberen.

Kortstondige poorten hebben een time-out voor inactieve 4 minuten (niet aanpasbaar). Als de nieuwe aanvallen te agressief zijn, kan de uitputting niet zelf worden geweken. Daarom is het een essentieel onderdeel van het ontwerp om na te gaan hoe vaak de toepassing transacties opnieuw moet proberen uit te proberen.

Een openbaar IP-adres toewijzen aan elke VM

Als u een openbaar IP-adres toewijst, verandert uw scenario in Openbaar IP-adres in een VM. Alle kortstondige poorten van het openbare IP-adres die voor elke VM worden gebruikt, zijn beschikbaar voor de VM. (In tegenstelling tot scenario's waarin kortstondige poorten van een openbaar IP-adres worden gedeeld met alle VM's die zijn gekoppeld aan de respectieve back-endpool.) Er zijn afwegingen waar u rekening mee moet houden, zoals de extra kosten van openbare IP-adressen en de mogelijke impact van het filteren van een groot aantal afzonderlijke IP-adressen.

Notitie

Deze optie is niet beschikbaar voor webwerkrollen.

Meerdere frontends gebruiken

Wanneer u openbare Standard Load Balancer, wijst u meerdere front-end-IP-adressen toe voor uitgaande verbindingen en vermenigvuldigt u het aantal beschikbare SNAT-poorten. Maak een front-end-IP-configuratie, -regel en -back-en -pool om het programmeren van SNAT te activeren op het openbare IP-adres van de front-end. De regel hoeft niet te werken en een statustest hoeft niet te slagen. Als u ook meerdere frontends gebruikt voor inkomende gegevens (in plaats van alleen voor uitgaand verkeer), moet u aangepaste statustests gebruiken om betrouwbaarheid te garanderen.

Notitie

In de meeste gevallen is uitputting van SNAT-poorten een teken van een slecht ontwerp. Zorg ervoor dat u begrijpt waarom u poorten uitput voordat u meer front-enden gebruikt om SNAT-poorten toe te voegen. Mogelijk maskert u een probleem dat later tot fouten kan leiden.

Uitschalen

Vooraf toegewezen poorten worden toegewezen op basis van de grootte van de back-endpool en gegroepeerd in lagen om onderbrekingen te minimaliseren wanneer sommige poorten opnieuw moeten worden toegewezen om ruimte te bieden aan de volgende grotere back-endpoollaag. Mogelijk hebt u een optie om het SNAT-poortgebruik voor een bepaalde front-end te verhogen door uw back-endpool te schalen naar de maximale grootte voor een bepaalde laag. Houd er rekening mee dat de standaardpoorttoewijzing vereist is om de toepassing efficiënt uit te schalen zonder risico op SNAT-uitputting.

Twee virtuele machines in de back-endpool hebben bijvoorbeeld 1024 SNAT-poorten per IP-configuratie, waardoor er in totaal 2048 SNAT-poorten beschikbaar zijn voor de implementatie. Als de implementatie zou worden verhoogd tot 50 virtuele machines, hoewel het aantal vooraf toegewezen poorten constant per virtuele machine blijft, kunnen er in totaal 51.200 (50 x 1024) SNAT-poorten worden gebruikt door de implementatie. Als u uw implementatie wilt uitschalen, controleert u het aantal vooraf toegewezen poorten per laag om ervoor te zorgen dat u de uitschaal naar het maximum voor de respectieve laag vormt. Als u in het vorige voorbeeld had gekozen om uit te schalen naar 51 in plaats van 50 exemplaren, zou u naar de volgende laag gaan en uiteindelijk minder SNAT-poorten per VM en in totaal hebben.

Als u uitschaalt naar de eerstvolgende grotere back-endpoollaag, kan er voor sommige uitgaande verbindingen een time-out worden gemaakt als de toegewezen poorten opnieuw moeten worden toegewezen. Als u slechts een deel van uw SNAT-poorten gebruikt, is uitschalen over de volgende grotere back-endpool niet-opeenvolgende. De helft van de bestaande poorten wordt elke keer dat u naar de volgende back-endpoollaag gaat, opnieuw toegewezen. Als u niet wilt dat dit gebeurt, moet u uw implementatie vormgeven naar de laaggrootte. Of zorg ervoor dat uw toepassing zo nodig kan detecteren en het opnieuw kan proberen. TCP-keepalives kunnen helpen bij het detecteren wanneer SNAT-poorten niet meer werken vanwege een nieuwe toewijzing.

Keepalives gebruiken om de time-out voor inactieve uitgaande gegevens opnieuw in te stellen

Uitgaande verbindingen hebben een time-out voor inactieve verbindingen van 4 minuten. Deze time-out is aanpasbaar via uitgaande regels. U kunt ook transport (bijvoorbeeld TCP-keepalives) of toepassingslaag-keepalives gebruiken om een niet-actieve stroom te vernieuwen en deze time-out voor inactieve gegevens indien nodig opnieuw in te stellen.

Wanneer u TCP-keepalives gebruikt, is het voldoende om ze aan één zijde van de verbinding in te stellen. Het is bijvoorbeeld voldoende om ze alleen in te stellen aan de serverzijde om de niet-actieve timer van de stroom opnieuw in te stellen en het is niet nodig dat beide zijden TCP-keepalives initiëren. Er bestaan vergelijkbare concepten voor de toepassingslaag, waaronder client-serverconfiguraties voor databases. Controleer aan de serverzijde welke opties er bestaan voor toepassingsspecifieke keepalives.

Volgende stappen

We willen altijd de ervaring van onze klanten verbeteren. Als u problemen ondervindt met uitgaande connectiviteit die niet worden vermeld of opgelost in dit artikel, kunt u feedback verzenden via GitHub via de onderkant van deze pagina. Wij zullen uw feedback zo snel mogelijk bespreken.