TCP-/IP-prestaties afstemmen voor Azure-VM's

Artikel
11/16/2023

In dit artikel worden veelvoorkomende technieken voor het afstemmen van TCP/IP-prestaties besproken en enkele zaken die u moet overwegen wanneer u deze gebruikt voor virtuele machines die worden uitgevoerd in Azure. Het geeft een basisoverzicht van de technieken en verkent hoe ze kunnen worden afgestemd.

Veelgebruikte TCP/IP-afstemmingstechnieken

MTU, fragmentatie en grote send-offload

MTU

De maximale transmissie-eenheid (MTU) is het grootste frame (pakket), opgegeven in bytes, dat kan worden verzonden via een netwerkinterface. De MTU is een configureerbare instelling. De standaard MTU die wordt gebruikt op Virtuele Azure-machines en de standaardinstelling op de meeste netwerkapparaten wereldwijd, is 1500 bytes.

Fragmentatie

Fragmentatie treedt op wanneer een pakket wordt verzonden dat de MTU van een netwerkinterface overschrijdt. De TCP/IP-stack breekt het pakket op in kleinere stukken (fragmenten) die voldoen aan de MTU van de interface. Fragmentatie vindt plaats op de IP-laag en is onafhankelijk van het onderliggende protocol (zoals TCP). Wanneer een pakket van 2000 bytes wordt verzonden via een netwerkinterface met een MTU van 1500, wordt het pakket opgesplitst in één pakket van 1500 bytes en één pakket van 500 bytes.

Netwerkapparaten in het pad tussen een bron en bestemming kunnen pakketten verwijderen die de MTU overschrijden of het pakket in kleinere delen fragmenten.

De bit Niet fragment in een IP-pakket

De DF-bits (Don't Fragment) is een vlag in de HEADER van het IP-protocol. De DF-bit geeft aan dat netwerkapparaten op het pad tussen de afzender en ontvanger het pakket niet mogen fragmenten. Deze bit kan om verschillende redenen worden ingesteld. (Zie de sectie Pad MTU Discovery van dit artikel voor één voorbeeld.) Wanneer een netwerkapparaat een pakket ontvangt met de bitset Niet fragmenteren en dat pakket de interface-MTU van het apparaat overschrijdt, is het standaardgedrag dat het apparaat het pakket verwijdert. Het apparaat verzendt een ICMP-fragmentatie vereist bericht terug naar de oorspronkelijke bron van het pakket.

Gevolgen van de prestaties van fragmentatie

Fragmentatie kan negatieve gevolgen hebben voor de prestaties. Een van de belangrijkste redenen voor het effect op de prestaties is de CPU/geheugenimpact van de fragmentatie en het opnieuwassembly van pakketten. Wanneer een netwerkapparaat een pakket moet fragmenteren, moet het CPU-/geheugenbronnen toewijzen om fragmentatie uit te voeren.

Hetzelfde gebeurt wanneer het pakket opnieuw wordt verzameld. Het netwerkapparaat moet alle fragmenten opslaan totdat ze zijn ontvangen, zodat deze opnieuw in het oorspronkelijke pakket kunnen worden samengevoegd.

Azure en fragmentatie

Gefragmenteerde pakketten in Azure worden niet verwerkt door versneld netwerken. Wanneer een VIRTUELE machine een gefragmenteerd pakket ontvangt, wordt het verwerkt via het niet-versnelde pad. Dit betekent dat gefragmenteerde pakketten niet de voordelen krijgen van versneld netwerken (lagere latentie, verminderde jitter en hogere pakketten per seconde). Daarom raden we u aan om indien mogelijk fragmentatie te vermijden.

Standaard worden in Azure niet-orderfragmenten verwijderd, dat wil gezegd, gefragmenteerde pakketten die niet op de VIRTUELE machine aankomen in de volgorde waarin ze zijn verzonden vanaf het broneindpunt. Dit kan gebeuren wanneer pakketten via internet of andere grote WAN's worden verzonden. Het opnieuw ordenen van fragmenten buiten de volgorde kan in sommige gevallen worden ingeschakeld. Als een toepassing dit vereist, opent u een ondersteuningsaanvraag.

De MTU afstemmen

We raden klanten niet aan om de MTU op VM-NIC's te verhogen. Als de VIRTUELE machine moet communiceren met bestemmingen die zich niet in het virtuele netwerk bevinden met een vergelijkbare MTU-set, treedt er waarschijnlijk fragmentatie op die de prestaties vermindert.

Grote offload voor verzenden

Grote send offload (LSO) kan de netwerkprestaties verbeteren door de segmentatie van pakketten naar de Ethernet-adapter te offloaden. Wanneer LSO is ingeschakeld, maakt de TCP/IP-stack een groot TCP-pakket en verzendt het naar de Ethernet-adapter voor segmentatie voordat u het doorstuurt. Het voordeel van LSO is dat het cpu kan vrijmaken van het segmenteren van pakketten in grootten die voldoen aan de MTU en die verwerking offload naar de Ethernet-interface waar deze wordt uitgevoerd in hardware. Zie Voor meer informatie over de voordelen van LSO het ondersteunen van grote send offload.

Wanneer LSO is ingeschakeld, kunnen Azure-klanten grote framegrootten zien wanneer ze pakketopnamen uitvoeren. Deze grote framegrootten kunnen ertoe leiden dat sommige klanten denken dat er fragmentatie optreedt of dat er een grote MTU wordt gebruikt wanneer dat niet zo is. Met LSO kan de Ethernet-adapter een grotere maximale segmentgrootte (MSS) adverteren naar de TCP/IP-stack om een groter TCP-pakket te maken. Dit volledige niet-gesegmenteerde frame wordt vervolgens doorgestuurd naar de Ethernet-adapter en zou zichtbaar zijn in een pakketopname die op de VIRTUELE machine wordt uitgevoerd. Maar het pakket wordt opgesplitst in veel kleinere frames door de Ethernet-adapter, volgens de MTU van de Ethernet-adapter.

TCP MSS-venster schalen en PMTUD

Maximale segmentgrootte TCP

De maximale segmentgrootte van TCP (MSS) is een instelling die de grootte van TCP-segmenten beperkt, waardoor fragmentatie van TCP-pakketten wordt voorkomen. Besturingssystemen gebruiken deze formule doorgaans om MSS in te stellen:

MSS = MTU - (IP header size + TCP header size)

De IP-header en de TCP-header zijn elk 20 bytes of 40 bytes in totaal. Een interface met een MTU van 1500 heeft dus een MSS van 1460. Maar de MSS kan worden geconfigureerd.

Deze instelling wordt overeengekomen in de handshake van TCP in drie richtingen wanneer een TCP-sessie wordt ingesteld tussen een bron en een bestemming. Beide zijden verzenden een MSS-waarde en de onderkant van de twee wordt gebruikt voor de TCP-verbinding.

Houd er rekening mee dat de MTU's van de bron en bestemming niet de enige factoren zijn die de MSS-waarde bepalen. Tussenliggende netwerkapparaten, zoals VPN-gateways, waaronder Azure VPN Gateway, kunnen de MTU onafhankelijk van de bron en bestemming aanpassen om optimale netwerkprestaties te garanderen.

Pad MTU-detectie

MSS wordt onderhandeld, maar geeft mogelijk niet aan wat de werkelijke MSS is die kan worden gebruikt. Dit komt doordat andere netwerkapparaten in het pad tussen de bron en het doel mogelijk een lagere MTU-waarde hebben dan de bron en het doel. In dit geval zal het apparaat waarvan de MTU kleiner is dan het pakket, het pakket verwijderen. Het apparaat stuurt een ICMP-fragmentatie vereist (type 3, code 4) terug dat de MTU bevat. Met dit ICMP-bericht kan de bronhost het pad naar MTU op de juiste manier verminderen. Het proces heet Path MTU Discovery (PMTUD).

Het PMTUD-proces is inefficiënt en beïnvloedt de netwerkprestaties. Wanneer pakketten worden verzonden die de MTU van een netwerkpad overschrijden, moeten de pakketten opnieuw worden verzonden met een lagere MSS. Als de afzender het bericht ICMP-fragmentatie vereist niet ontvangt, misschien vanwege een netwerkfirewall in het pad (ook wel bekend als een BLACKHOLE voor PMTUD), weet de afzender niet dat het nodig is om de MSS te verlagen en het pakket continu opnieuw te verzenden. Daarom raden we u niet aan om de MTU van azure-VM's te verhogen.

VPN en MTU

Als u VM's gebruikt die inkapseling (zoals IPsec VPN's) uitvoeren, zijn er enkele aanvullende overwegingen met betrekking tot pakketgrootte en MTU. VPN's voegen meer headers toe aan pakketten, waardoor de pakketgrootte toeneemt en een kleinere MSS is vereist.

Voor Azure raden we u aan TCP MSS-klem in te stellen op 1.350 bytes en tunnelinterface MTU op 1400. Zie de pagina met VPN-apparaten en DE parameters IPSec/IKE voor meer informatie.

Latentie, retourtijd en schalen van TCP-vensters

Latentie en retourtijd

Netwerklatentie wordt bepaald door de snelheid van licht via een glasvezelnetwerk. Netwerkdoorvoer van TCP wordt ook effectief beheerd door de retourtijd (RTT) tussen twee netwerkapparaten.

Route	Afstand	Eenmalige tijd	RTT
New York naar San Francisco	4.148 km	21 ms	42 ms
New York naar Londen	5.585 km	28 ms	56 ms
New York naar Sydney	15.993 km	80 ms	160 ms

In deze tabel ziet u de rechte lijnafstand tussen twee locaties. In netwerken is de afstand doorgaans langer dan de rechte lijnafstand. Hier volgt een eenvoudige formule om de minimale RTT te berekenen, zoals bepaald door de snelheid van het licht:

minimum RTT = 2 * (Distance in kilometers / Speed of propagation)

U kunt 200 gebruiken voor de snelheid van doorgifte. Dit is de afstand, in kilometers, dat licht in 1 milliseconde reist.

Laten we New York als voorbeeld nemen naar San Francisco. De rechte lijnafstand is 4.148 km. Als u deze waarde in de vergelijking aansluit, krijgen we het volgende:

Minimum RTT = 2 * (4,148 / 200)

De uitvoer van de vergelijking is in milliseconden.

Als u de beste netwerkprestaties wilt krijgen, is de logische optie om bestemmingen te selecteren met de kortste afstand ertussen. U moet ook uw virtuele netwerk ontwerpen om het pad van verkeer te optimaliseren en latentie te verminderen. Zie de sectie 'Overwegingen voor netwerkontwerp' van dit artikel voor meer informatie.

Latentie- en retourtijdeffecten op TCP

Retourtijd heeft een direct effect op maximale TCP-doorvoer. In het TCP-protocol is de venstergrootte de maximale hoeveelheid verkeer dat kan worden verzonden via een TCP-verbinding voordat de afzender bevestiging van de ontvanger moet ontvangen. Als de TCP MSS is ingesteld op 1.460 en de GROOTTE van het TCP-venster is ingesteld op 65.535, kan de afzender 45 pakketten verzenden voordat deze bevestiging van de ontvanger moet ontvangen. Als de afzender geen bevestiging krijgt, worden de gegevens opnieuw verzonden. Dit is de formule:

TCP window size / TCP MSS = packets sent

In dit voorbeeld wordt 65.535 / 1.460 afgerond op 45.

Deze status 'wachten op bevestiging', een mechanisme om betrouwbare levering van gegevens te garanderen, is wat ervoor zorgt dat RTT de TCP-doorvoer beïnvloedt. Hoe langer de afzender wacht op bevestiging, hoe langer het moet wachten voordat er meer gegevens worden verzonden.

Hier volgt de formule voor het berekenen van de maximale doorvoer van één TCP-verbinding:

Window size / (RTT latency in milliseconds / 1,000) = maximum bytes/second

In deze tabel ziet u de maximale megabytes/per seconde doorvoer van één TCP-verbinding. (Voor leesbaarheid wordt megabytes gebruikt voor de maateenheid.)

TCP-venstergrootte (bytes)	RTT-latentie (ms)	Maximale megabyte/seconde doorvoer	Maximale megabit/seconde doorvoer
65,535	1	65.54	524.29
65,535	30	2.18	17.48
65,535	60	1.09	8.74
65,535	90	.73	5,83
65,535	120	55.	4.37

Als pakketten verloren gaan, wordt de maximale doorvoer van een TCP-verbinding verminderd terwijl de afzender gegevens die al zijn verzonden, opnieuw verzendt.

TCP-venster schalen

Schalen van TCP-vensters is een techniek waarmee de TCP-venstergrootte dynamisch wordt vergroot, zodat er meer gegevens kunnen worden verzonden voordat een bevestiging is vereist. In het vorige voorbeeld worden 45 pakketten verzonden voordat er een bevestiging is vereist. Als u het aantal pakketten verhoogt dat kan worden verzonden voordat een bevestiging nodig is, vermindert u het aantal keren dat een afzender wacht op bevestiging, waardoor de maximale TCP-doorvoer wordt verhoogd.

Deze tabel illustreert deze relaties:

TCP-venstergrootte (bytes)	RTT-latentie (ms)	Maximale megabyte/seconde doorvoer	Maximale megabit/seconde doorvoer
65,535	30	2.18	17.48
131,070	30	4.37	34.95
262,140	30	8.74	69.91
524,280	30	17.48	139.81

Maar de TCP-headerwaarde voor tcp-venstergrootte is slechts 2 bytes lang, wat betekent dat de maximumwaarde voor een ontvangstvenster 65.535 is. Er is een TCP-vensterschaalfactor geïntroduceerd om de maximale venstergrootte te vergroten.

De schaalfactor is ook een instelling die u in een besturingssysteem kunt configureren. Hier volgt de formule voor het berekenen van de TCP-venstergrootte met behulp van schaalfactoren:

TCP window size = TCP window size in bytes * (2^scale factor)

Hier volgt de berekening voor een vensterschaalfactor van 3 en een venstergrootte van 65.535:

65,535 * (2^3) = 524,280 bytes

Een schaalfactor van 14 resulteert in een TCP-venstergrootte van 14 (de maximaal toegestane offset). De grootte van het TCP-venster is 1.073.725.440 bytes (8,5 gigabit).

Ondersteuning voor schalen van TCP-vensters

Windows kan verschillende schaalfactoren instellen voor verschillende verbindingstypen. (Klassen verbindingen zijn onder andere datacenter, internet, enzovoort.) U gebruikt de Get-NetTCPConnection PowerShell-opdracht om het verbindingstype voor het schalen van vensters weer te geven:

Get-NetTCPConnection

U kunt de Get-NetTCPSetting PowerShell-opdracht gebruiken om de waarden van elke klasse weer te geven:

Get-NetTCPSetting

U kunt de eerste TCP-venstergrootte en TCP-schaalfactor in Windows instellen met behulp van de Set-NetTCPSetting PowerShell-opdracht. Zie Set-NetTCPSetting voor meer informatie.

Set-NetTCPSetting

Dit zijn de effectieve TCP-instellingen voor AutoTuningLevel:

Autotuninglevel	Schaalfactor	Vermenigvuldiger schalen	Formule voor maximale venstergrootte berekenen
Uitgeschakeld	Geen	Geen	Venstergrootte
Beperkt	4	2^4	Venstergrootte * (2^4)
Zeer beperkt	2	2^2	Venstergrootte * (2^2)
Normaal	8	2^8	Venstergrootte * (2^8)
Experimenteel	14	2^14	Venstergrootte * (2^14)

Deze instellingen zijn de meest waarschijnlijke invloed op TCP-prestaties, maar houd er rekening mee dat veel andere factoren op internet, buiten het beheer van Azure, ook van invloed kunnen zijn op TCP-prestaties.

Versneld netwerken en schalen aan de ontvangstzijde

Versneld netwerken

Netwerkfuncties van virtuele machines zijn historisch cpu-intensief geweest op zowel de gast-VM als de hypervisor/host. Elk pakket dat door de host wordt verzonden, wordt verwerkt in software door de host-CPU, inclusief alle inkapseling en decapsulatie van virtuele netwerken. Hoe meer verkeer de host doorloopt, hoe hoger de CPU-belasting. En als de host-CPU bezig is met andere bewerkingen, is dit ook van invloed op de netwerkdoorvoer en -latentie. Azure lost dit probleem op met versneld netwerken.

Versneld netwerken bieden consistente ultralow-netwerklatentie via de interne programmeerbare hardware van Azure en technologieën zoals SR-IOV. Versneld netwerken verplaatsen veel van de door Azure software gedefinieerde netwerkstack van de CPU's en naar SmartNICs op basis van FPGA. Met deze wijziging kunnen eindgebruikerstoepassingen rekencycli vrijmaken, waardoor de VM minder wordt belast, waardoor jitter en inconsistentie in latentie afnemen. Met andere woorden, prestaties kunnen meer deterministisch zijn.

Versneld netwerken verbeteren de prestaties doordat de gast-VM de host kan omzeilen en een gegevenspad rechtstreeks met de SmartNIC van een host tot stand kan brengen. Hier volgen enkele voordelen van versneld netwerken:

Lagere latentie/hogere pakketten per seconde (pps):als u de virtuele switch van het gegevenspad verwijdert, worden de tijd die pakketten in de host worden besteed voor beleidsverwerking verwijderd en wordt het aantal pakketten dat in de VIRTUELE machine kan worden verwerkt, verhoogd.
Verminderde jitter: de verwerking van virtuele switches is afhankelijk van de hoeveelheid beleid die moet worden toegepast en de werkbelasting van de CPU die de verwerking uitvoert. Door het afdwingen van het beleid naar de hardware te offloaden, wordt deze variabiliteit verwijderd door pakketten rechtstreeks aan de VIRTUELE machine te leveren, waardoor de communicatie tussen de host en alle softwareonderbrekingen en contextswitches wordt geëlimineerd.
Verminderd CPU-gebruik: het omzeilen van de virtuele switch in de host leidt tot minder CPU-gebruik voor het verwerken van netwerkverkeer.

Als u versneld netwerken wilt gebruiken, moet u deze expliciet inschakelen op elke toepasselijke VM. Zie Een virtuele Linux-machine maken met versneld netwerken voor instructies.

Schalen aan de ontvangstzijde

RSS (Receive Side Scaling) is een technologie voor netwerkstuurprogramma's die het ontvangen van netwerkverkeer efficiënter distribueert door ontvangstverwerking over meerdere CPU's in een multiprocessorsysteem te distribueren. In eenvoudige termen kan rss een systeem meer ontvangen verkeer verwerken omdat het alle beschikbare CPU's gebruikt in plaats van slechts één. Zie Inleiding tot schalen aan de zijkant voor een technischere bespreking van RSS.

Als u de beste prestaties wilt krijgen wanneer versneld netwerken is ingeschakeld op een virtuele machine, moet u RSS inschakelen. RSS kan ook voordelen bieden op VM's die geen versneld netwerken gebruiken. Zie Netwerkdoorvoer optimaliseren voor virtuele Azure-machines voor een overzicht van hoe u kunt bepalen of RSS is ingeschakeld en hoe u deze inschakelt.

TCP-TIME_WAIT en TIME_WAIT moord

TCP-TIME_WAIT is een andere algemene instelling die van invloed is op netwerk- en toepassingsprestaties. Op drukke VM's die veel sockets openen en sluiten, hetzij als clients of als servers (bron-IP:bronpoort + doel-IP:doelpoort), tijdens de normale werking van TCP kan een bepaalde socket lange tijd in een TIME_WAIT status terechtkomen. De status TIME_WAIT is bedoeld om toe te staan dat eventuele extra gegevens op een socket worden geleverd voordat deze worden gesloten. TCP/IP-stacks verhinderen dus over het algemeen het hergebruik van een socket door het TCP SYN-pakket van de client op de achtergrond te verwijderen.

De hoeveelheid tijd die een socket in TIME_WAIT is geconfigureerd. Het kan variëren van 30 seconden tot 240 seconden. Sockets zijn een eindige resource en het aantal sockets dat op elk gewenst moment kan worden gebruikt, kan worden geconfigureerd. (Het aantal beschikbare sockets is doorgaans ongeveer 30.000.) Als de beschikbare sockets worden gebruikt of als clients en servers niet overeenkomen TIME_WAIT instellingen en een VIRTUELE machine probeert een socket opnieuw te gebruiken in een TIME_WAIT status, mislukken nieuwe verbindingen omdat TCP SYN-pakketten op de achtergrond worden verwijderd.

De waarde voor poortbereik voor uitgaande sockets kan meestal worden geconfigureerd binnen de TCP/IP-stack van een besturingssysteem. Hetzelfde geldt voor TCP-TIME_WAIT-instellingen en hergebruik van sockets. Als u deze getallen wijzigt, kan de schaalbaarheid mogelijk worden verbeterd. Maar afhankelijk van de situatie kunnen deze wijzigingen interoperabiliteitsproblemen veroorzaken. Wees voorzichtig als u deze waarden wijzigt.

U kunt TIME_WAIT moord gebruiken om deze schaalbeperking aan te pakken. TIME_WAIT moord kan een socket in bepaalde situaties opnieuw worden gebruikt, bijvoorbeeld wanneer het volgnummer in het IP-pakket van de nieuwe verbinding het volgnummer van het laatste pakket van de vorige verbinding overschrijdt. In dit geval staat het besturingssysteem toe dat de nieuwe verbinding tot stand wordt gebracht (het accepteert de nieuwe SYN/ACK) en sluit de vorige verbinding die zich in een TIME_WAIT status bevindt. Deze mogelijkheid wordt ondersteund op Virtuele Windows-machines in Azure. Neem contact op met de leverancier van het besturingssysteem voor meer informatie over ondersteuning in andere VM's.

Zie Instellingen die kunnen worden gewijzigd om de netwerkprestaties te verbeteren voor meer informatie over het configureren van TCP-TIME_WAIT-instellingen en bronpoortbereik.

Factoren van het virtuele netwerk die van invloed kunnen zijn op de prestaties

Maximale uitgaande doorvoer van vm's

Azure biedt verschillende VM-grootten en -typen, elk met een andere combinatie van prestatiemogelijkheden. Een van deze mogelijkheden is netwerkdoorvoer (of bandbreedte), die wordt gemeten in megabits per seconde (Mbps). Omdat virtuele machines worden gehost op gedeelde hardware, moet de netwerkcapaciteit redelijk worden gedeeld tussen de virtuele machines die gebruikmaken van dezelfde hardware. Grotere virtuele machines krijgen meer bandbreedte toegewezen dan kleinere virtuele machines.

De netwerkbandbreedte die aan elke virtuele machine is toegewezen, wordt gemeten op uitgaand (uitgaand) verkeer van de virtuele machine. Al het netwerkverkeer dat de virtuele machine verlaat, wordt meegeteld bij de toegewezen limiet, ongeacht de bestemming. Als een virtuele machine bijvoorbeeld een limiet van 1000 Mbps heeft, is die limiet van toepassing of het uitgaande verkeer is bestemd voor een andere virtuele machine in hetzelfde virtuele netwerk of een buiten Azure.

Inkomend verkeer wordt niet rechtstreeks gemeten of beperkt. Er zijn echter andere factoren, zoals CPU- en opslaglimieten, die van invloed kunnen zijn op de mogelijkheid van een virtuele machine om binnenkomende gegevens te verwerken.

Versneld netwerken is ontworpen om de netwerkprestaties te verbeteren, waaronder latentie, doorvoer en CPU-gebruik. Versneld netwerken kunnen de doorvoer van een virtuele machine verbeteren, maar dat kan alleen tot de toegewezen bandbreedte van de virtuele machine.

Virtuele Azure-machines hebben ten minste één netwerkinterface eraan gekoppeld. Misschien hebben ze er meerdere. De bandbreedte die aan een virtuele machine is toegewezen, is de som van al het uitgaande verkeer via alle netwerkinterfaces die aan de machine zijn gekoppeld. Met andere woorden, de bandbreedte wordt toegewezen per virtuele machine, ongeacht het aantal netwerkinterfaces dat aan de machine is gekoppeld.

Verwachte uitgaande doorvoer en het aantal netwerkinterfaces dat door elke VM-grootte wordt ondersteund, worden beschreven in grootten voor virtuele Windows-machines in Azure. Als u de maximale doorvoer wilt zien, selecteert u een type, zoals Algemeen gebruik, en zoekt u vervolgens de sectie over de groottereeks op de resulterende pagina (bijvoorbeeld 'Dv2-serie'). Voor elke reeks is er een tabel met netwerkspecificaties in de laatste kolom, met de titel Max NIC's/Verwachte netwerkbandbreedte (Mbps).'

De doorvoerlimiet is van toepassing op de virtuele machine. De doorvoer wordt niet beïnvloed door deze factoren:

Aantal netwerkinterfaces: de bandbreedtelimiet is van toepassing op de som van al het uitgaande verkeer van de virtuele machine.
Versneld netwerken: hoewel deze functie nuttig kan zijn bij het bereiken van de gepubliceerde limiet, wordt de limiet niet gewijzigd.
Verkeersbestemming: alle bestemmingen tellen mee voor de uitgaande limiet.
Protocol: Al het uitgaande verkeer via alle protocollen telt mee voor de limiet.

Zie netwerkbandbreedte voor virtuele machines voor meer informatie.

Overwegingen voor internetprestaties

Zoals besproken in dit artikel, kunnen factoren op internet en buiten het beheer van Azure van invloed zijn op de netwerkprestaties. Hier volgen enkele van deze factoren:

Latentie: De retourtijd tussen twee bestemmingen kan worden beïnvloed door problemen op tussenliggende netwerken, door verkeer dat niet het 'kortste' afstandspad neemt en door suboptimale peeringpaden.
Pakketverlies: pakketverlies kan worden veroorzaakt door netwerkcongestie, problemen met fysieke paden en ondermaats presterende netwerkapparaten.
MTU-grootte/fragmentatie: Fragmentatie langs het pad kan leiden tot vertragingen bij het binnenkomen van gegevens of in pakketten die niet in orde zijn, wat van invloed kan zijn op de levering van pakketten.

Traceroute is een goed hulpmiddel voor het meten van netwerkprestatiekenmerken (zoals pakketverlies en latentie) langs elk netwerkpad tussen een bronapparaat en een doelapparaat.

Overwegingen voor netwerkontwerp

Samen met de overwegingen die eerder in dit artikel zijn besproken, kan de topologie van een virtueel netwerk van invloed zijn op de prestaties van het netwerk. Een hub-and-spoke-ontwerp dat wereldwijd verkeer naar een virtueel netwerk met één hub backhault, leidt bijvoorbeeld tot netwerklatentie, wat van invloed is op de algehele netwerkprestaties.

Het aantal netwerkapparaten dat het netwerkverkeer doorgeeft, kan ook van invloed zijn op de algehele latentie. Als in een hub-and-spoke-ontwerp bijvoorbeeld verkeer via een virtueel spoke-netwerkapparaat en een virtueel hubapparaat passeert voordat ze naar internet worden verzonden, kunnen de virtuele netwerkapparaten latentie veroorzaken.

Azure-regio's, virtuele netwerken en latentie

Azure-regio's bestaan uit meerdere datacenters die zich in een algemeen geografisch gebied bevinden. Deze datacenters bevinden zich mogelijk niet fysiek naast elkaar. In sommige gevallen worden ze gescheiden door zo veel als 10 kilometer. Het virtuele netwerk is een logische overlay boven op het fysieke datacenternetwerk van Azure. Een virtueel netwerk impliceert geen specifieke netwerktopologie binnen het datacenter.

Twee VM's die zich in hetzelfde virtuele netwerk en subnet bevinden, bevinden zich bijvoorbeeld in verschillende racks, rijen of zelfs datacenters. Ze kunnen worden gescheiden door voeten van glasvezelkabel of door kilometers glasvezelkabel. Deze variatie kan leiden tot variabele latentie (een paar milliseconden verschil) tussen verschillende VM's.

De geografische plaatsing van VM's en de mogelijke resulterende latentie tussen twee VM's kan worden beïnvloed door de configuratie van beschikbaarheidssets en Beschikbaarheidszones. Maar de afstand tussen datacenters in een regio is regiospecifiek en wordt voornamelijk beïnvloed door de datacentertopologie in de regio.

Bron-NAT-poortuitputting

Een implementatie in Azure kan communiceren met eindpunten buiten Azure op het openbare internet en/of in de openbare IP-ruimte. Wanneer een exemplaar een uitgaande verbinding initieert, wordt het privé-IP-adres dynamisch toegewezen aan een openbaar IP-adres. Nadat Azure deze toewijzing heeft gemaakt, kan retourverkeer voor de uitgaande stroom ook het privé-IP-adres bereiken waar de stroom vandaan komt.

Voor elke uitgaande verbinding moet de Azure Load Balancer deze toewijzing gedurende een bepaalde periode onderhouden. Met de multitenant-aard van Azure kan het onderhouden van deze toewijzing voor elke uitgaande stroom voor elke VIRTUELE machine resource-intensief zijn. Er zijn dus limieten die zijn ingesteld en op basis van de configuratie van het virtuele Azure-netwerk. Of om dat precies te zeggen, kan een Virtuele Azure-machine slechts een bepaald aantal uitgaande verbindingen op een bepaald moment maken. Wanneer deze limieten zijn bereikt, kan de VIRTUELE machine geen uitgaande verbindingen meer maken.

Maar dit gedrag kan worden geconfigureerd. Zie dit artikel voor meer informatie over SNAT- en SNAT-poortuitputting.

Netwerkprestaties meten in Azure

Een aantal prestatielimieten in dit artikel is gerelateerd aan de netwerklatentie/retourtijd (RTT) tussen twee VM's. Deze sectie bevat enkele suggesties voor het testen van latentie/RTT en het testen van TCP-prestaties en vm-netwerkprestaties. U kunt de TCP/IP- en netwerkwaarden die eerder zijn besproken, afstemmen en testen met behulp van de technieken die in deze sectie worden beschreven. U kunt latentie-, MTU-, MSS- en venstergroottewaarden aansluiten op de berekeningen die u eerder hebt opgegeven en theoretische maximumwaarden vergelijken met de werkelijke waarden die u tijdens het testen ziet.

Retourtijd en pakketverlies meten

TCP-prestaties zijn sterk afhankelijk van RTT en pakketverlies. Het PING-hulpprogramma dat beschikbaar is in Windows en Linux, biedt de eenvoudigste manier om RTT en pakketverlies te meten. In de uitvoer van PING wordt de minimale/maximale/gemiddelde latentie tussen een bron en doel weergegeven. Ook wordt pakketverlies weergegeven. PING maakt standaard gebruik van het ICMP-protocol. U kunt PsPing gebruiken om TCP RTT te testen. Zie PsPing voor meer informatie.

De werkelijke bandbreedte van een virtuele machine meten

Volg deze richtlijnen om de bandbreedte van virtuele Azure-machines nauwkeurig te meten.

Zie de volgende artikelen voor meer informatie over het testen van andere scenario's:

Inefficiënt TCP-gedrag detecteren

In pakketopnamen kunnen Azure-klanten TCP-pakketten met TCP-vlaggen (SACK, DUP ACK, RETRANSMIT en FAST RETRANSMIT) zien die kunnen duiden op problemen met de netwerkprestaties. Deze pakketten geven specifiek netwerkefficiënties aan die het gevolg zijn van pakketverlies. Maar pakketverlies wordt niet noodzakelijkerwijs veroorzaakt door prestatieproblemen in Azure. Prestatieproblemen kunnen het gevolg zijn van toepassingsproblemen, problemen met het besturingssysteem of andere problemen die mogelijk niet rechtstreeks zijn gerelateerd aan het Azure-platform.

Houd er ook rekening mee dat sommige retransmissie en dubbele ACL's normaal zijn in een netwerk. TCP-protocollen zijn gebouwd om betrouwbaar te zijn. Bewijs van deze TCP-pakketten in een pakketopname geeft niet noodzakelijkerwijs een systeemprobleem aan, tenzij ze overmatig zijn.

Toch zijn deze pakkettypen indicaties dat TCP-doorvoer de maximale prestaties niet bereikt, om redenen die worden besproken in andere secties van dit artikel.

Volgende stappen

Nu u hebt geleerd over TCP/IP-prestaties afstemmen voor Virtuele Azure-machines, kunt u meer lezen over andere overwegingen voor het plannen van virtuele netwerken of meer informatie over het verbinden en configureren van virtuele netwerken.

Share via