TCP/IP-prestatieoptimalisatie voor Azure VM's

Dit artikel bespreekt gangbare methoden voor het optimaliseren van TCP/IP-prestaties en enkele zaken om in overweging te nemen bij het gebruik ervan voor virtuele machines die op Azure draaien. Het biedt een eenvoudig overzicht van de technieken en verkend hoe virtuele machines kunnen worden afgestemd.

Veelvoorkomende TCP/IP optimalisatietechnieken

MTU, fragmentatie en grote verzenduitlading

MTU

De maximale transmissie-eenheid (MTU) is het grootste frame (pakket plus netwerktoegangheaders) die zijn opgegeven in bytes die kunnen worden verzonden via een netwerkinterface. De MTU is een instelbare instelling. De standaard-MTU die wordt gebruikt op Azure VMs, en de standaardinstelling op de meeste netwerkapparaten wereldwijd, is 1.500 bytes.

Fragmentatie

Fragmentatie treedt op wanneer een pakket wordt verzonden dat de MTU van een netwerkinterface overschrijdt. De TCP/IP-stack breekt het pakket 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 die de maximum transmissie-eenheid (MTU) overschrijden, laten vallen of de pakketten in kleinere stukken opdelen (fragmenteren).

De 'Niet Fragmenteren'-bit in een IP-pakket

Het Don’t Fragment (DF) bit is een vlag in de IP-protocolheader. Het DF-bit geeft aan dat netwerkapparaten op het pad tussen de verzender en ontvanger het pakket niet mogen fragmenteren. Deze bit kan om vele redenen worden ingesteld. (Zie de sectie "Path MTU Discovery" van dit artikel voor een voorbeeld.) Wanneer een netwerkapparaat een pakket ontvangt met de Don’t Fragment-bit ingesteld, en dat pakket overschrijdt de interface-MTU van het apparaat, is het standaardgedrag van het apparaat om het pakket te laten vallen. Het apparaat stuurt een ICMP Fragmentation Needed-bericht terug naar de oorspronkelijke bron van het pakket.

Prestatiegevolgen van fragmentatie

Fragmentatie kan negatieve prestatie-effecten hebben. Een van de belangrijkste redenen voor het effect op prestaties is het CPU-/geheugeneffect van de fragmentatie en het opnieuw samenvoegen 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 samengesteld. Het netwerkapparaat moet alle fragmenten opslaan totdat ze zijn ontvangen, zodat het ze opnieuw kan samenstellen tot het oorspronkelijke pakket.

Azure en fragmentatie

Azure verwerkt geen gefragmenteerde pakketten met versneld netwerken. Wanneer een virtuele machine een gefragmenteerd pakket ontvangt, wordt het niet-versnelde pad verwerkt. Hierdoor missen gefragmenteerde pakketten de voordelen van versneld netwerken, zoals lagere latentie, verminderde jitter en hogere pakketten per seconde. Om deze reden raden we aan fragmentatie, indien mogelijk, te vermijden.

Azure verwijdert standaard gefragmenteerde pakketten die niet in de juiste volgorde op de VIRTUELE machine aankomen, wat betekent dat de pakketten niet overeenkomen met de overdrachtsreeks van het broneindpunt. Dit probleem kan optreden wanneer pakketten via internet of andere grote WAN's worden verzonden.

Stel de MTU in

U kunt de doorvoer van interne virtuele netwerken verbeteren door de MTU voor het verkeer van uw VIRTUELE machine te verhogen. Als de VIRTUELE machine echter communiceert met bestemmingen buiten het virtuele netwerk met een andere MTU, kan fragmentatie optreden en de prestaties verminderen.

Zie MTU (Maximum Transmission Unit) configureren voor virtuele machines in Azure voor meer informatie over het instellen van de MTU op virtuele machines in Azure.

Grote verzenduit-lading

Grote send offload (LSO) kan de netwerkprestaties verbeteren door de segmentatie van pakketten naar de ethernetadapter te offloaden. Wanneer LSO is ingeschakeld, maakt de TCP/IP-stack een groot TCP-pakket en verzendt het naar de ethernetadapter voor segmentatie voordat het wordt doorgestuurd. Het voordeel van LSO is dat het de CPU vrijmaakt van het moeten segmenteren van pakketten in groottes die passen bij de MTU en deze verwerking overlaat aan de ethernet interface hardware. Voor meer informatie over de voordelen van LSO, zie Ondersteuning van groot verzenden offload.

Wanneer LSO is ingeschakeld, merken Azure-klanten mogelijk grote framegrootten tijdens pakketopnamen. Deze grote framegrootten kunnen ertoe leiden dat sommige klanten aannemen dat er fragmentatie optreedt of dat er een grote MTU wordt gebruikt wanneer dat niet zo is. Met LSO kan de ethernetadapter de maximale segmentgrootte (MSS) vergroten die wordt geadverteerd naar de TCP/IP-stack, zodat er een groter TCP-pakket kan worden gemaakt. De ethernetadapter breekt dit volledige niet-gesegmenteerde frame vervolgens af in veel kleinere frames volgens de MTU, die zichtbaar zijn in een pakketopname die op de VIRTUELE machine wordt uitgevoerd.

TCP MSS-vensterschaling en PMTUD

TCP maximale segmentgrootte

TCP maximum segment size (MSS) is een instelling die de grootte van TCP-segmenten beperkt, om fragmentatie van TCP-pakketten te 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 een MSS van 1460. De MSS kan worden geconfigureerd.

Deze instelling wordt overeengekomen in de TCP three-way handshake wanneer een TCP-sessie wordt opgezet tussen een bron en een bestemming. Beide zijden sturen een MSS-waarde, en de lagere 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, inclusief Azure VPN Gateway, kunnen de MTU onafhankelijk van de bron en bestemming aanpassen om optimale netwerkprestaties te garanderen.

Path MTU-ontdekking

MSS wordt onderhandeld, maar het geeft mogelijk niet de daadwerkelijke MSS aan die kan worden gebruikt. Andere netwerkapparaten in het pad tussen de bron en het doel hebben mogelijk een lagere MTU-waarde dan de bron en het doel. In dit geval laat het apparaat het pakket vallen als de MTU kleiner is dan het pakket. Het apparaat stuurt een ICMP Fragmentation Needed (Type 3, Code 4) bericht terug dat de MTU bevat. Dit ICMP-bericht stelt de broncomputer in staat om zijn Path MTU op passende wijze te verminderen. De procedure heet Path MTU Discovery (PMTUD).

Het PMTUD-proces vermindert de netwerkprestaties vanwege de inefficiëntie. Wanneer de MTU van een netwerkpad wordt overschreden, moeten pakketten opnieuw worden verzonden met een lagere MSS. Als een netwerkfirewall het bericht ICMP-fragmentatie vereist blokkeert, blijft de afzender zich niet bewust van de noodzaak om de MSS te verlagen en het pakket herhaaldelijk opnieuw te verzenden. Daarom raden we u af 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 andere overwegingen met betrekking tot pakketgrootte en MTU. VPN's voegen meer headers toe aan pakketten. De toegevoegde headers vergroten de pakketgrootte en vereisen een kleinere MSS.

Voor Azure raden we aan om TCP MSS-clamping in te stellen op 1.350 bytes en de MTU van de tunnelinterface op 1.400. Voor meer informatie, zie de VPN devices and IPsec/IKE parameters page.

Latentie, reistijd en TCP window scaling

Latentie en rondreis tijd

De snelheid van het licht bepaalt de netwerklatentie via een glasvezelnetwerk. De retourtijd (RTT) tussen twee netwerkapparaten bepaalt tcp-netwerkdoorvoer.

Deze tabel toont de luchtlijnafstand tussen twee locaties. In netwerken is de afstand doorgaans langer dan de rechte lijn afstand. Hier is een eenvoudige formule om de minimale RTT te berekenen zoals bepaald door de lichtsnelheid:

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

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

Laten we New York naar San Francisco als voorbeeld nemen. De rechtlijnige afstand is 4.148 km. Als u die waarde invoert in de vergelijking, resulteert dit in de volgende vergelijking:

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

De output van de vergelijking is in milliseconden.

Als je de beste netwerkprestaties wilt behalen, is de logische optie om bestemmingen te selecteren met de kortste afstand ertussen. U moet ook uw virtuele netwerk ontwerpen om het pad van het verkeer te optimaliseren en de latentie te verminderen. Voor meer informatie, zie het gedeelte "Netwerkontwerp overwegingen" van dit artikel.

De effecten van latentie en rondreis vertraging op TCP

De round-trip time heeft een direct effect op de 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 1460 en de GROOTTE van het TCP-venster is ingesteld op 65.535, kan de afzender 45 pakketten verzenden voordat deze wordt erkend door de ontvanger. Als de afzender geen bevestiging krijgt, worden de gegevens opnieuw verzonden. Hier is de formule:

TCP window size / TCP MSS = packets sent

In dit voorbeeld wordt 65.535 / 1.460 afgerond naar boven tot 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 meer gegevens worden verzonden.

Hier is de formule voor het berekenen van de maximale doorvoer van een enkele TCP-verbinding:

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

Deze tabel toont de maximale megabytes per seconde doorvoer van een enkele TCP-verbinding. (Voor de leesbaarheid wordt megabytes gebruikt als maateenheid.)

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

TCP-window-schaalvergroting

TCP-vensterversnelling is een techniek waarmee de grootte van het TCP-venster 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.

Deze tabel illustreert die relaties.

Maar de TCP-headerwaarde voor TCP-venstergrootte is slechts 2 bytes lang, wat betekent dat de maximale waarde voor een ontvangstvenster 65.535 is. Om de maximale venstergrootte te vergroten, werd een TCP-vensterschaalfactor geïntroduceerd.

De schaalfactor is ook een instelling die je in een besturingssysteem kunt configureren. Hier is 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 is 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 verschuiving). De GROOTTE van het TCP-venster is 1.073.725.440 bytes (8,5 gigabits).

Ondersteuning voor TCP window scaling

Windows kan verschillende schaalfactoren instellen voor verschillende verbindingstypen. (Klassen van verbindingen omvatten datacenter, internet, enzovoort.) U gebruikt de Get-NetTCPConnection PowerShell-opdracht om het vensterschaaltype van de verbinding te bekijken.

Get-NetTCPConnection

U kunt de PowerShell-opdracht Get-NetTCPSetting gebruiken om de waarden van elke klasse te bekijken.

Get-NetTCPSetting

Je kunt de initiële TCP-venstergrootte en de TCP-schaalfactor in Windows instellen met behulp van de PowerShell-opdracht. Voor meer informatie, zie Set-NetTCPSetting.

Set-NetTCPSetting

De volgende waarden zijn de effectieve TCP-instellingen voor AutoTuningLevel:

Deze instellingen hebben waarschijnlijk de meeste invloed op de TCP-prestaties, maar houd er rekening mee dat veel andere factoren op het internet, buiten de controle van Azure, eveneens de TCP-prestaties kunnen beïnvloeden.

Versneld netwerk en ontvangstzijde-schaalbaarheid

Versneld netwerkgebruik

Netwerkfuncties van virtuele machines zijn historisch cpu-intensief op zowel de gast-VM als de hypervisor/host. De host-CPU verwerkt in software alle pakketten die door de host worden verzonden, inclusief alle inkapseling en decapsulatie van virtuele netwerken. Hoe meer verkeer de host doorloopt, hoe hoger de CPU-belasting. Als de host-CPU bezig is met andere bewerkingen die van invloed zijn op de netwerkdoorvoer en -latentie. Azure lost dit probleem op met versnelde netwerken.

Versnelde netwerkverbinding biedt een consistente ultralage netwerklatentie via de in-house programmeerbare hardware van Azure en technologieën zoals SR-IOV. Versnelde netwerkverbindingen verplaatsen een groot deel van de Azure-softwaregedefinieerde netwerkstack van de CPU's naar op FPGA gebaseerde SmartNICs. Met deze wijziging kunnen eindgebruikerstoepassingen rekencycli vrijmaken die minder belasting op de VM veroorzaken, waardoor jitter en inconsistentie in latentie afnemen. Met andere woorden, prestaties kunnen meer deterministisch zijn.

Versneld netwerk verbetert de prestaties door de gast-VM in staat te stellen de host te omzeilen en een gegevenspad direct met een host's SmartNIC op te zetten. Hier zijn enkele voordelen van versnelde netwerken:

• Lagere latentie / meer pakketten per seconde (pps): Het verwijderen van de virtuele switch uit het datapad elimineert de tijd die pakketten doorbrengen in de host voor beleidverwerking en vergroot het aantal pakketten dat in de VM kan worden verwerkt.

• Reduced jitter: De verwerking van de virtuele switch is afhankelijk van de hoeveelheid beleid die moet worden toegepast en de belasting van de CPU die de verwerking uitvoert. Het uitbesteden van de handhaving van het beleid aan de hardware verwijdert die variabiliteit door pakketten direct aan de VM te leveren, waardoor de communicatie tussen host en VM wordt geëlimineerd, evenals alle softwareonderbrekingen en contextwisselingen.

• Verminderde CPU-belasting: Het omzeilen van de virtuele switch in de host leidt tot minder CPU-belasting voor het verwerken van netwerkverkeer.

nl-NL: Om versnelde netwerken te gebruiken, moet u deze expliciet inschakelen op elke toepasselijke VM. Zie Een Linux-virtuele machine maken met versnelde netwerkverbinding voor instructies.

Ontvangkant-schaalbaarheid

Receive side scaling (RSS) is een netwerkstuurprogramma-technologie die de ontvangst van netwerkverkeer efficiënter verdeelt door de verwerking van de ontvangst te verdelen over meerdere CPU's in een multiprocessorsysteem. In eenvoudige bewoordingen stelt RSS een systeem in staat om meer binnenkomend verkeer te verwerken, omdat het alle beschikbare CPU's gebruikt in plaats van slechts één. Voor een meer technische bespreking van RSS, zie Introduction to receive side scaling.

Om de beste prestaties te behalen wanneer Accelerated Networking is ingeschakeld op een VM, moet u RSS inschakelen. RSS kan ook voordelen bieden voor virtuele machines die geen gebruik maken van versnelde netwerken. Voor een overzicht van hoe u kunt bepalen of RSS is ingeschakeld en hoe u het kunt inschakelen, zie Optimaliseer netwerkdoorvoer voor Azure virtuele machines.

TCP TIME_WAIT en beëindiging van TIME_WAIT

TCP-TIME_WAIT is een andere algemene instelling die van invloed is op netwerk- en toepassingsprestaties. Drukke VM's openen en sluiten vaak veel sockets, ofwel als clients of servers. Tijdens normale TCP-bewerkingen voert een socket vaak de status TIME_WAIT in en blijft daar gedurende een langere periode. Deze status zorgt ervoor dat alle resterende gegevens op de socket worden geleverd voordat deze wordt gesloten. Als gevolg hiervan voorkomen TCP/IP-stacks doorgaans hergebruik van sockets door het TCP SYN-pakket van de client op de achtergrond te verwijderen.

U kunt configureren hoe lang een socket in de status TIME_WAIT blijft. De duur kan variëren van 30 seconden tot 240 seconden. Sockets zijn een eindige resource en hun beschikbaarheid kan worden geconfigureerd. Normaal gesproken zijn er op elk gewenst moment ongeveer 30.000 sockets beschikbaar voor gebruik. Als het systeem alle beschikbare sockets verbruikt of als clients en servers niet-overeenkomende TIME_WAIT-instellingen gebruiken, probeert de VM mogelijk een socket opnieuw te gebruiken die nog steeds de status TIME_WAIT heeft. In dergelijke gevallen mislukken nieuwe verbindingen omdat de TCP SYN-pakketten op de achtergrond worden verwijderd.

De waarde voor poortbereik voor uitgaande sockets kan worden geconfigureerd binnen de TCP/IP-stack van een besturingssysteem. Hetzelfde geldt voor TCP TIME_WAIT-instellingen en socket-hergebruik. Het wijzigen van deze getallen kan de schaalbaarheid mogelijk verbeteren. Maar, afhankelijk van de situatie, kunnen deze veranderingen interoperabiliteitsproblemen veroorzaken. Je moet voorzichtig zijn als je deze waarden verandert.

U kunt TIME_WAIT-moord gebruiken om deze schaalbeperkingen aan te pakken. TIME_WAIT-assassinatie maakt het mogelijk om een socket opnieuw te gebruiken in bepaalde situaties, bijvoorbeeld wanneer het volgnummer in het IP-pakket van de nieuwe verbinding het volgnummer overschrijdt van het laatste pakket van de vorige verbinding. In dit geval staat het besturingssysteem toe dat de nieuwe verbinding tot stand wordt gebracht (het accepteert de nieuwe SYN/ACK) en dwingt u de vorige verbinding die zich in een TIME_WAIT status bevindt, af te sluiten. Deze functionaliteit wordt ondersteund op Windows-VM's in Azure. Om meer te weten te komen over ondersteuning in andere VM's, neem contact op met de OS-leverancier.

Om meer te leren over het configureren van TCP TIME_WAIT-instellingen en bronpoortbereik, zie Instellingen die kunnen worden aangepast om de netwerkprestaties te verbeteren.

Factoren van virtuele netwerken die de prestaties kunnen beïnvloeden

Maximale uitgaande doorvoersnelheid van VM

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 megabit per seconde (Mbps). Omdat virtuele machines worden gehost op gedeelde hardware, moet de netwerkcapaciteit eerlijk worden verdeeld onder de virtuele machines die dezelfde hardware gebruiken. 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. Alle netwerkverkeer dat de virtuele machine verlaat, wordt meegeteld bij de toegewezen limiet, ongeacht de bestemming. Als een virtuele machine een limiet van 1000 Mbps heeft, is deze limiet van toepassing of het uitgaande verkeer is bestemd voor een andere virtuele machine in hetzelfde virtuele netwerk of een buiten Azure.

Toegang wordt niet direct gemeten of beperkt. Maar er zijn andere factoren, zoals processor- en opslagbeperkingen, die de capaciteit van een virtuele machine om binnenkomende gegevens te verwerken kunnen beïnvloeden.

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

Azure-virtuele machines hebben ten minste één netwerkinterface die eraan is gekoppeld. Ze hebben er misschien meerdere. De toegewezen bandbreedte aan een virtuele machine is de som van al het uitgaande verkeer via alle netwerkinterfaces die aan de machine zijn gekoppeld. Met andere woorden, de bandbreedte wordt toegewezen op basis van elke virtuele machine, ongeacht hoeveel netwerkinterfaces aan de machine zijn gekoppeld.

De verwachte uitgaande doorvoersnelheid en het aantal netwerkinterfaces dat door elke VM-grootte wordt ondersteund, worden gedetailleerd beschreven in Maten voor Windows virtual machines in Azure. Zie de maximale doorvoer door een type te selecteren, zoals Algemeen doel. Zoek vervolgens de sectie over de reeks groottes op de resulterende pagina (bijv. "Dv2-serie"). Voor elke serie is er een tabel die netwerkspecificaties biedt in de laatste kolom, die is getiteld "Maximaal aantal NICs / Verwachte netwerkbandbreedte (Mbps)."

De doorvoerlimiet geldt voor 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.

• Accelerated networking: Hoewel deze functie nuttig kan zijn bij het behalen van de gepubliceerde limiet, verandert het de limiet niet.

• Verkeersbestemming: Alle bestemmingen tellen mee voor de uitgaande limiet.

• Protocol: Al het uitgaande verkeer over alle protocollen telt mee voor de limiet.

Voor meer informatie, zie Netwerkbandbreedte van virtuele machines.

Optimalisatie van virtuele Linux-machines (VM's)

Moderne Linux-kernels hebben functies die kunnen helpen bij het bereiken van consistentie en prestaties, soms vereist voor bepaalde workloads.

Zie Netwerkbandbreedte optimaliseren op Azure-VM's voor meer informatie

Overwegingen voor internetprestaties

Zoals in dit artikel besproken, kunnen factoren op het internet en buiten de controle van Azure de netwerkprestaties beïnvloeden. Hier zijn enkele van die factoren:

• Latentie: De retourtijd tussen twee eindpunten wordt beïnvloed door problemen in tussenliggende netwerken, door verkeer dat niet het 'kortste' afstandspad neemt en door suboptimale peeringpaden.

• Pakketverlies: pakketverlies wordt veroorzaakt door netwerkcongestie, problemen met fysieke paden en onderbewerkende netwerkapparaten.

• MTU-grootte/Fragmentatie: Fragmentatie langs het pad kan leiden tot vertragingen bij de data-aanvoer of het niet in de juiste volgorde aankomen van pakketten, wat de levering van pakketten kan beïnvloeden.

Traceroute is een goed hulpmiddel voor het meten van netwerkkarakteristieken, zoals pakketverlies en latentie, langs elke netwerkroute tussen een bronapparaat en een doelapparaat.

Overwegingen bij netwerkontwerp

Naast de eerder in dit artikel besproken overwegingen kan de topologie van een virtueel netwerk de prestaties van het netwerk beïnvloeden. Een hub-and-spoke-ontwerp dat wereldwijd verkeer naar een enkel virtueel netwerk stuurt, kan bijvoorbeeld netwerklatentie veroorzaken, wat de algehele netwerkprestaties beïnvloedt.

Het aantal netwerkapparaten waar netwerkverkeer doorheen gaat kan ook de algehele latentie beïnvloeden. In een hub-and-spoke-ontwerp, als verkeer via een virtueel spoke-netwerkapparaat en een hub virtueel apparaat gaat voordat het naar internet gaat, introduceren de virtuele netwerkapparaten enige latentie.

Azure-regio's, virtuele netwerken en latentie

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

Bijvoorbeeld, twee VMs die zich in hetzelfde virtuele netwerk en subnet bevinden, kunnen zich in verschillende racks, rijen of zelfs datacenters bevinden. Ze kunnen worden gescheiden door voeten van glasvezelkabel of door kilometers glasvezelkabel. Deze variatie kan variabele latentie (een verschil van enkele milliseconden) tussen verschillende virtuele machines introduceren.

De geografische plaatsing van VM's en de mogelijke resulterende latentie tussen twee VM's wordt beïnvloed door de configuratie van beschikbaarheidssets, nabijheidsplaatsingsgroepen en beschikbaarheidszones. Maar de afstand tussen datacenters in een regio is regiospecifiek en wordt voornamelijk beïnvloed door de topologie van datacenters in de regio.

Uitputting van Source NAT-poorten

Een implementatie in Azure kan communiceren met eindpunten buiten Azure op het openbare internet en/of in de openbare IP-ruimte. Wanneer een instantie een uitgaande verbinding initieert, mapt Azure dynamisch het private IP-adres naar een openbaar IP-adres. Nadat Azure deze mapping heeft gemaakt, kan retourverkeer voor de uitgaand gestarte stroom ook het privé-IP-adres bereiken waar de stroom is gestart.

Voor elke uitgaande verbinding moet de Azure Load Balancer deze toewijzing enige tijd handhaven. Met de multitenant natuur van Azure kan het bijhouden van deze mapping voor elke uitgaande stroom voor elke VM veel middelen vergen. Dus, er zijn limieten ingesteld op basis van de configuratie van het Azure Virtual Network. Of om dat precies te zeggen, kan een Virtuele Azure-machine slechts enkele uitgaande verbindingen op een bepaald moment maken. Wanneer deze limieten zijn bereikt, maakt de VIRTUELE machine geen uitgaande verbindingen meer.

Maar dit gedrag is configureerbaar. Voor meer informatie over SNAT en SNAT-poortuitputting, zie dit artikel.

De netwerkprestaties op Azure meten

Veel van de prestatielimieten in dit artikel zijn gerelateerd aan de netwerklatentie/retourtijd (RTT) tussen twee VM's. Deze sectie biedt enkele suggesties voor het testen van latentie/RTT en het testen van de TCP-prestaties en de netwerkprestaties van VM's. U kunt afstemmen en prestatietesten uitvoeren op de TCP/IP- en netwerkwaarden die eerder besproken zijn, door de in dit gedeelte beschreven technieken te gebruiken. Voer latentie-, MTU-, MSS- en venstergroottewaarden in de berekeningen in die eerder zijn opgegeven en vergelijk theoretische maximumwaarden met werkelijke waarden die tijdens het testen zijn waargenomen.

Meet de round-trip time en pakketverlies

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. De uitvoer van PING toont de minimale/maximum/gemiddelde latentie tussen een bron en doel. Het geeft pakketverlies aan. PING gebruikt standaard het ICMP-protocol. U kunt PsPing gebruiken om de TCP-RTT te testen. Voor meer informatie, zie PsPing.

ICMP- en TCP-pings meten niet het versnelde netwerkdatapad. Lees meer over Latte en SockPerf in dit artikel om het gegevenspad te meten.

Meet de werkelijke bandbreedte van een virtuele machine.

Om de bandbreedte van Azure-VM's nauwkeurig te meten, volgt u deze richtlijnen.

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

• Problemen oplossen met de Expressroute-netwerkprestaties

• Hoe VPN-doorvoer naar een virtueel netwerk te valideren

Detecteer inefficiënt TCP-gedrag

In pakketopnamen kunnen Azure-klanten TCP-pakketten zien met TCP-vlaggen (SACK, DUP ACK, RETRANSMIT en FAST RETRANSMIT) die op netwerkprestatieproblemen kunnen wijzen. Deze pakketten wijzen specifiek op netwerkinefficiënties die het gevolg zijn van pakketverlies. Maar pakketverlies wordt niet noodzakelijkerwijs veroorzaakt door prestatieproblemen in Azure. Prestatieproblemen kunnen het gevolg zijn van een applicatie, een besturingssysteem, of andere problemen die mogelijk niet direct gerelateerd zijn aan het Azure-platform.

Houd er rekening mee dat sommige hertransmissies en dubbele ACK's normaal zijn in een netwerk. TCP-protocollen zijn ontworpen om betrouwbaar te zijn. Bewijs van deze TCP-pakketten in een packet capture duidt niet noodzakelijk op een systemisch netwerkprobleem, tenzij ze overmatig zijn.

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

Volgende stappen

Nu u hebt geleerd over TCP/IP-prestaties afstemmen voor Azure-VM's, kunt u andere factoren voor het plannen van virtuele netwerken verkennen. U kunt ook meer informatie vinden over het verbinden en configureren van virtuele netwerken.