TCP/IP teljesítmény-finomhangolás Azure-beli virtuális gépekhez

2025-04-21

Ez a cikk a TCP/IP teljesítményhangolási technikákat ismerteti, és néhány megfontolandó szempontot, amikor az Azure-ban futó virtuális gépekhez használja őket. Alapvető áttekintést nyújt a technikákról, és áttekinti, hogyan hangolhatók a virtuális gépek.

Gyakori TCP/IP-hangolási technikák

MTU, töredezettség és nagyméretű adatküldés tehermentesítése

MTU

A maximális átviteli egység (MTU) a hálózati adapteren keresztül küldhető bájtokban megadott legnagyobb méretű keret (csomag és hálózati hozzáférési fejlécek). Az MTU egy konfigurálható beállítás. Az Azure VM-eken használt alapértelmezett MTU, és a legtöbb hálózati eszköz alapértelmezett beállítása világszerte 1 500 bájt.

Töredezettség

Töredezettség akkor fordul elő, ha a rendszer olyan csomagot küld, amely meghaladja a hálózati adapter MTU-ját. A TCP/IP-verem kisebb darabokra (töredékekre) bontja a csomagot, amelyek megfelelnek az interfész MTU-jának. A töredezettség az IP-rétegben történik, és független az alapul szolgáló protokolltól (például TCP). Ha egy 2000 bájtos csomagot egy 1500-ás MTU-val rendelkező hálózati adapteren keresztül küldenek, a csomag egy 1500 bájtos csomagra és egy 500 bájtos csomagra lesz bontva.

A forrás és a cél közötti útvonalon található hálózati eszközök vagy az MTU-t meghaladó csomagokat helyezhetnek el, vagy kisebb darabokra tördelhetik a csomagot.

A "Ne töredeztesse" bit egy IP-csomagban

A Nem töredezett (DF) bit az IP-protokoll fejlécében lévő jelölő. A DF bit azt jelzi, hogy a feladó és a fogadó közötti útvonalon lévő hálózati eszközök nem töredezették el a csomagot. Ez a bit több okból is beállítható. (A cikk "Path MTU Discovery" című szakaszában talál egy példát.) Ha egy hálózati eszköz kap egy csomagot a Nem töredezettség bitkészlettel, és ez a csomag meghaladja az eszköz felületi MTU-ját, a szokásos viselkedés az, hogy az eszköz elveti a csomagot. Az eszköz egy ICMP 'Töredezettség szükséges' üzenetet küld vissza a csomag eredeti forrásának.

A töredezettség teljesítményre gyakorolt hatásai

A töredezettség negatív hatással lehet a teljesítményre. A teljesítményre gyakorolt hatás egyik fő oka a csomagok töredezettségének és újraszerelésének CPU-/memóriahatása. Ha egy hálózati eszköznek szét kell törnie egy csomagot, processzor-/memóriaerőforrásokat kell lefoglalnia a töredezettség végrehajtásához.

Ugyanez történik a csomag újraszerelésekor is. A hálózati eszköznek az összes töredéket el kell tárolnia, amíg meg nem kapja őket, hogy újra össze tudja őket szerelni az eredeti csomagba.

Azure és töredezettség

Az Azure nem dolgoz fel töredezett csomagokat gyorsított hálózatkezeléssel. Ha egy virtuális gép töredezett adatcsomagot kap, a gyorsítatlan útvonal feldolgozza azt. Ennek eredményeképpen a töredezett csomagok kihagyják a gyorsított hálózatkezelés előnyeit, például az alacsonyabb késést, a kisebb jittert és a másodpercenkénti nagyobb csomagokat. Ezért javasoljuk, hogy lehetőség szerint kerülje el a töredezettséget.

Az Azure alapértelmezés szerint a virtuális gépre érkező töredezett csomagokat a rendszerből elveti, ami azt jelenti, hogy a csomagok nem egyeznek a forrásvégpont átviteli sorozatával. Ez a probléma akkor fordulhat elő, ha a csomagok az interneten vagy más nagy WAN-okon keresztül utaznak.

Az MTU optimalizálása

A virtuális gép forgalmának MTU-jának növelésével javíthatja a virtuális hálózat belső átviteli sebességét. Ha azonban a virtuális gép más MTU-val rendelkező virtuális hálózaton kívüli célhelyekkel kommunikál, töredezettség léphet fel, és csökkentheti a teljesítményt.

Az MTU Azure-beli virtuális gépeken való beállításáról további információt az Azure-beli virtuális gépek maximális átviteli egységének (MTU) konfigurálása című témakörben talál.

Nagy küldési terheléscsökkentés

A nagy méretű küldési kiszervezés (LSO) javíthatja a hálózati teljesítményt azáltal, hogy a csomagok szegmentálását átruházza az ethernet adapterre. Ha az LSO engedélyezve van, a TCP/IP-verem létrehoz egy nagy TCP-csomagot, és a továbbítás előtt elküldi azt az Ethernet-adapternek szegmentálás céljából. Az LSO előnye felszabadítja a processzort attól, hogy a csomagokat az MTU-nak megfelelő méretűre szegmentálja, és kicsomagozza a feldolgozást az Ethernet-interfész hardverére. Az LSO előnyeiről további információt a nagy küldési offload támogatása című témakörben talál.

Ha az LSO engedélyezve van, az Azure-ügyfelek nagy méretű kereteket észlelhetnek a csomagrögzítések során. Előfordulhat, hogy ezek a nagy keretméretek miatt egyes ügyfelek azt feltételezik, hogy töredezettség történik, vagy hogy nagy MTU-t használnak, amikor valójában nem. Az LSO használatával az ethernet-adapter nagyobb maximális szegmensméretet (MSS) képes meghirdetni a TCP/IP-verem számára egy nagyobb TCP-csomag létrehozásához. Az Ethernet-adapter ezt a teljes nem szegmentált keretet az MTU-nak megfelelően sok kisebb keretre bontja, amelyek a virtuális gépen végrehajtott csomagrögzítés során láthatók.

TCP MSS-ablak skálázása és PMTUD

TCP-szegmens maximális mérete

A TCP maximális szegmensmérete (MSS) egy olyan beállítás, amely korlátozza a TCP szegmensek méretét, és így elkerülhető a TCP csomagok töredezettsége. Az operációs rendszerek általában ezt a képletet használják az MSS beállításához:

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

Az IP-fejléc és a TCP-fejléc egyenként 20 bájt, azaz összesen 40 bájt. Az 1500-ból álló MTU-val rendelkező interfész 1460 MSS-sel rendelkezik. Az MSS konfigurálható.

Ezt a beállítást a TCP háromirányú kézfogásában fogadjuk el, amikor egy TCP-munkamenetet beállítunk egy forrás és egy cél között. Mindkét oldal MSS-értéket küld, és a két érték közül a kisebbet használja a TCP-kapcsolat.

Ne feledje, hogy nem csak a forrás és a cél MTU-jai határozzák meg az MSS-értéket. A közbenső hálózati eszközök, például a VPN-átjárók, köztük az Azure VPN Gateway, a forrástól és a céltól függetlenül módosíthatják az MTU-t az optimális hálózati teljesítmény biztosítása érdekében.

Útvonal MTU-felderítése

Az MSS egyeztetésre kerül, de lehet, hogy nem jelzi a ténylegesen használható MSS-t. A forrás és a cél közötti útvonalon található egyéb hálózati eszközök MTU-értéke alacsonyabb lehet, mint a forrás és a cél. Ebben az esetben az eszköz, amelynek MTU-értéke kisebb, mint a csomag, eldobja a csomagot. Az eszköz egy ICMP-töredezettség szükséges (3. típus, 4. kód) üzenetet küld vissza, amely tartalmazza az MTU-t. Ez az ICMP-üzenet lehetővé teszi, hogy a forrás gazdagép megfelelően csökkentse az elérési út MTU-ját. A folyamat neve Path MTU Discovery (PMTUD).

A PMTUD-folyamat nem hatékony működése miatt csökkenti a hálózati teljesítményt. A hálózati útvonal MTU-jának túllépésekor a csomagokat alacsonyabb MSS-vel kell újraküldeni. Ha egy hálózati tűzfal blokkolja az ICMP "Töredezés szükséges" üzenetet, a feladó nem értesül arról, hogy csökkentenie kell az MSS-t, és ezért folyamatosan újraküldi a csomagot. Ezért javasoljuk, hogy ne növeljék az Azure-beli virtuális gép MTU-ját.

VPN és MTU

Ha beágyazást végző virtuális gépeket (például IPsec VPN-eket) használ, a csomagméretet és az MTU-t illetően van néhány egyéb szempont. A VPN-ek további fejléceket adnak hozzá a csomagokhoz. A hozzáadott fejlécek növelik a csomag méretét, és kisebb MSS-t igényelnek.

Az Azure esetében azt javasoljuk, hogy a TCP MSS befogást 1350 bájtra, az alagút interfész MTU-t pedig 1400-ra állítsa. További információkért tekintse meg a VPN-eszközök és az IPsec/IKE paraméterek oldalát.

Késés, oda-vissza menetidő és TCP-ablak skálázása

Késés és oda-vissza menetidő

A fénysebesség határozza meg a száloptikai hálózaton keresztüli hálózati késést. A két hálózati eszköz közötti menetidő (RTT) szabályozza a TCP hálózati átviteli sebességét.

Útvonal	Távolság	Egyirányú idő	RTT
New York – San Francisco	4,148 km	21 ms	42 ms
New York–London	5585 km	28 ms	56 ms
New York–Sydney	15 993 km	80 ms	160 ms

Ez a táblázat két hely közötti egyenes vonalat mutatja. A hálózatokban a távolság általában hosszabb, mint az egyenes vonal. Íme egy egyszerű képlet a minimális RTT kiszámításához a fénysebességnek megfelelően:

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

A propagálás sebességéhez használhat 200-et. A propagálás sebessége az a távolság, kilométerben, amely a fény 1 ezredmásodpercben halad.

Vegyük példának a New York-San Francisco útvonalat. Az egyenes vonal távolsága 4148 km. Ha ezt az értéket beírja az egyenletbe, az a következő egyenletet eredményezi:

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

Az egyenlet kimenete ezredmásodpercben van.

Ha a legjobb hálózati teljesítményt szeretné elérni, a logikai lehetőség az, hogy a lehető legrövidebb távolsággal válassza ki a célhelyeket. A virtuális hálózatot úgy is megtervezheti, hogy optimalizálja a forgalom útvonalát, és csökkentse a késést. További információkért tekintse meg a cikk "Hálózattervezési szempontok" című szakaszát.

Késési és oda-visszaúti időhatások a TCP-n

Az oda-vissza menetidő közvetlen hatással van a TCP maximális átviteli sebességére. A TCP protokollban az ablakméret a TCP-kapcsolaton keresztül küldhető forgalom maximális mennyisége, mielőtt a feladónak nyugtát kell kapnia a fogadótól. Ha a TCP MSS értéke 1460, a TCP-ablak mérete pedig 65 535, a feladó 45 csomagot küldhet, mielőtt nyugtázni szeretné a fogadótól. Ha a feladó nem kap visszaigazolást, újraküldi az adatokat. A képlet a következő:

TCP window size / TCP MSS = packets sent

Ebben a példában a 65 535/1 460 kerekítve 45 lesz.

Ez a "várakozás a nyugtázásra" állapot, amely az adatok megbízható kézbesítését biztosító mechanizmus, az okozza, hogy az RTT hatással van a TCP átviteli sebességére. Minél tovább vár a feladó a nyugtázásra, annál tovább kell várnia a további adatok elküldése előtt.

Az alábbi képlet egyetlen TCP-kapcsolat maximális átviteli sebességének kiszámítására használható:

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

Ez a táblázat egyetlen TCP-kapcsolat maximális megabájt/másodpercenkénti átviteli sebességét mutatja. (Az olvashatóság érdekében megabájtot használunk a mértékegységhez.)

TCP-ablak mérete (bájt)	RTT-latencia (ms)	Maximális megabájt/másodperc átviteli sebesség	Maximális megabit/másodperc átviteli sebesség
65,535	1	65.54	524.29
65,535	30	2.18	17.48
65,535	60	1.09	8.74
65,535	90	0.73	5,83
65,535	Százhúsz	0.55	4.37

Ha a csomagok elvesznek, a TCP-kapcsolat maximális átviteli sebessége csökken, miközben a feladó újra elküldi az elküldött adatokat.

TCP-ablak skálázása

A TCP-ablakméretezés egy olyan technika, amely dinamikusan növeli a TCP-ablak méretét, hogy több adatot küldhessenek el, mielőtt nyugtázásra lenne szükség. Az előző példában 45 csomagot küldenek, mielőtt nyugtázásra lenne szükség. Ha növeli azoknak a csomagoknak a számát, amelyeket még a nyugtázás előtt el lehet küldeni, azzal csökkenti, hogy a feladó hány alkalommal vár nyugtázásra.

Ez a táblázat az alábbi kapcsolatokat szemlélteti:

TCP-ablak mérete (bájt)	RTT-latencia (ms)	Maximális megabájt/másodperc átviteli sebesség	Maximális megabit/másodperc átviteli sebesség
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

A TCP-ablak méretének TCP-fejlécértéke azonban csak 2 bájt hosszú, ami azt jelenti, hogy egy fogadóablak maximális értéke 65 535. A maximális ablakméret növelése érdekében tcp-ablakméret-tényezőt vezetünk be.

A méretezési tényező egy olyan beállítás is, amelyet egy operációs rendszerben konfigurálhat. Íme a TCP-ablak méretének méretezési tényezőkkel történő kiszámítására szolgáló képlet:

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

Íme egy 3-ás ablakméret-tényező és egy 65 535-ös ablakméret kiszámítása:

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

A 14-es méretezési tényező 14-es TCP-ablakméretet eredményez (a maximális eltolás megengedett). A TCP-ablak mérete 1 073 725 440 bájt (8,5 gigabites).

TCP-ablak skálázásának támogatása

A Windows különböző skálázási tényezőket állíthat be a különböző kapcsolattípusokhoz. (A kapcsolatok osztályai közé tartozik az adatközpont, az internet stb.) A Get-NetTCPConnection PowerShell-paranccsal megtekintheti az ablakméretezési kapcsolat típusát:

Get-NetTCPConnection

A Get-NetTCPSetting PowerShell-paranccsal megtekintheti az egyes osztályok értékeit:

Get-NetTCPSetting

A Windows kezdeti TCP-ablakméretét és TCP-méretezési tényezőt a Set-NetTCPSetting PowerShell-paranccsal állíthatja be. További információ: Set-NetTCPSetting.

Set-NetTCPSetting

A következő értékek az érvényes TCP-beállítások AutoTuningLevel:

Automatikus Hangolási Szint	Méretezési tényező	Skálázási szorzó	Képlet a következők szerint: ablak maximális méretének kiszámítása
Letiltva	Egyik sem	Egyik sem	Ablak mérete
Korlátozott	4	2^4	Ablak mérete * (2^4)
Szigorúan korlátozott	2	2^2	Ablak mérete * (2^2)
Normál	8	2^8	Ablak mérete * (2^8)
Kísérleti	14	2^14	Ablak mérete * (2^14)

Ezek a beállítások a legnagyobb valószínűséggel befolyásolják a TCP teljesítményét, de ne feledje, hogy az interneten az Azure-on kívül számos egyéb tényező is befolyásolhatja a TCP teljesítményét.

Gyorsított hálózatkezelés és fogadóoldali skálázás

Gyorsított hálózatkezelés

A virtuális gépek hálózati funkciói korábban processzorigényesek mind a vendég virtuális gépen, mind a hipervizoron/gazdagépen. A gazdagép CPU-ja szoftveres úton feldolgozza az összes csomagot, amelyek áthaladnak a gazdagépen, beleértve az összes virtuális hálózati beágyazást és kibontást. Minél több forgalom halad át a gazdagépen, annál nagyobb a processzorterhelés. Ha a gazdagép processzora más olyan műveletekkel van elfoglalva, amelyek befolyásolják a hálózati átviteli sebességet és a késleltetést. Az Azure gyorsított hálózatkezeléssel oldja meg ezt a problémát.

A gyorsított hálózatkezelés állandó, rendkívül alacsony hálózati késleltetést biztosít az Azure házon belüli programozható hardverével és az olyan technológiákon keresztül, mint az SR-IOV. A gyorsított hálózatépítés az Azure szoftveresen definiált hálózati stack nagy részét a CPU-król az FPGA-alapú SmartNIC-kre helyezi át. Ez a módosítás lehetővé teszi, hogy a végfelhasználói alkalmazások visszanyerjenek olyan számítási ciklusokat, amelyek kevesebb terhelést helyeznek a virtuális gépre, csökkentve a jittert és az inkonzisztencia késését. Más szóval, a teljesítmény determinisztikusabb lehet.

A gyorsított hálózatkezelés javítja a teljesítményt azáltal, hogy lehetővé teszi a vendég virtuális gép számára, hogy megkerülje a gazdagépet, és közvetlenül hozzon létre egy adatfolyamot a gazdagép SmartNIC-jével. A gyorsított hálózatkezelés néhány előnye:

Alacsonyabb késés / több csomag másodpercenként (pps): A virtuális kapcsoló eltávolítása az adatútvonalról megszünteti a gazdagépen a szabályzatfeldolgozáshoz szükséges időt, és növeli a virtuális gép által feldolgozható csomagok számát.
Csökkentett jitter: A virtuális kapcsolók feldolgozása az alkalmazandó szabályzat mennyiségétől és a feldolgozást végző processzor számítási feladataitól függ. A szabályzatkényszerítés hardverre való kiszervezése eltávolítja ezt a variabilitást azáltal, hogy csomagokat kézbesít közvetlenül a virtuális gépnek, kiküszöbölve a gazdagép és a virtuális gép közötti kommunikációt, valamint az összes szoftveres megszakítást és környezeti kapcsolót.
Csökkentett CPU-kihasználtság: A gazdagép virtuális kapcsolójának megkerülése kevesebb processzorhasználatot eredményez a hálózati forgalom feldolgozásához.

A gyorsított hálózatkezelés használatához explicit módon engedélyeznie kell azt minden alkalmazható virtuális gépen. Útmutatásért lásd : Linux rendszerű virtuális gép létrehozása gyorsított hálózatkezeléssel .

Oldalméretezés fogadása

A fogadóoldali skálázás (RSS) egy olyan hálózati illesztőprogram-technológia, amely hatékonyabban osztja el a hálózati forgalom fogadását azáltal, hogy a fogadási feldolgozást több PROCESSZOR között osztja el egy többprocesszoros rendszerben. Egyszerű értelemben az RSS lehetővé teszi, hogy a rendszer több fogadott forgalmat dolgoz fel, mert az egyetlen helyett az összes rendelkezésre álló PROCESSZORt használja. Az RSS technikai részleteiről a Bevezetés a fogadói oldalon történő skálázáshoz című témakörben olvashat.

Ahhoz, hogy a lehető legjobb teljesítményt érje el, ha a gyorsított hálózatkezelés engedélyezve van egy virtuális gépen, engedélyeznie kell az RSS-t. Az RSS olyan virtuális gépeken is előnyös lehet, amelyek nem használnak gyorsított hálózatkezelést. Az RSS engedélyezésének és engedélyezésének módjáról az Azure-beli virtuális gépek hálózati átviteli teljesítményének optimalizálása című témakörben talál áttekintést.

TCP-TIME_WAIT és TIME_WAIT gyilkosság

A TCP TIME_WAIT egy másik gyakori beállítás, amely hatással van a hálózat és az alkalmazás teljesítményére. Az elfoglalt virtuális gépek gyakran nyitnak meg és zárnak be számos socketet, akár ügyfélként, akár kiszolgálóként. Normál TCP-műveletek során a socketek gyakran TIME_WAIT állapotba kerülnek, és hosszabb ideig ott maradnak. Ez az állapot biztosítja, hogy a csatlakozón lévő fennmaradó adatok kézbesítve legyenek, mielőtt bezárul. Ennek eredményeképpen a TCP/IP-veremek általában megakadályozzák a socketek újrafelhasználását az ügyfél TCP SYN-csomagjának csendes elvetésével.

Konfigurálhatja, hogy a csatlakozó mennyi ideig marad TIME_WAIT állapotban. Az időtartam 30 másodperctől 240 másodpercig terjedhet. A csatlakozók véges erőforrások, és a rendelkezésre állásuk konfigurálható. Általában körülbelül 30 000 foglalat érhető el adott időpontban. Ha a rendszer az összes elérhető szoftvercsatornát felhasználja, vagy ha az ügyfelek és a kiszolgálók nem egyező TIME_WAIT beállításokat használnak, előfordulhat, hogy a virtuális gép megpróbál újra felhasználni egy szoftvercsatornát, amely még TIME_WAIT állapotban van. Ilyen esetekben az új kapcsolatok meghiúsulnak, mert a TCP SYN-csomagok csendesen el vannak dobva.

A kimenő szoftvercsatornák porttartományának értéke konfigurálható az operációs rendszer TCP/IP-veremén belül. Ugyanez igaz a TCP TIME_WAIT beállításaira és a socketek újrafelhasználására is. A számok módosítása javíthatja a méretezhetőséget. A helyzettől függően azonban ezek a változások együttműködési problémákat okozhatnak. Körültekintőnek kell lennie, ha módosítja ezeket az értékeket.

A skálázási korlátozás kezelésére használhatja TIME_WAIT merényletet. TIME_WAIT merénylet lehetővé teszi, hogy a socketek bizonyos helyzetekben újra felhasználhatók legyenek, például ha az új kapcsolat IP-csomagjának sorszáma meghaladja az előző kapcsolat utolsó csomagjának sorszámát. Ebben az esetben az operációs rendszer lehetővé teszi az új kapcsolat létrehozását (elfogadja az új SYN/ACK-et), és kényszeríti a TIME_WAIT állapotban lévő előző kapcsolat bezárását. Ez a funkció az Azure-beli Windows rendszerű virtuális gépeken támogatott. A többi virtuális gép támogatásáról az operációsrendszer-gyártónál tájékozódhat.

A TCP TIME_WAIT beállításainak és forrásporttartományának konfigurálásáról további információt a hálózati teljesítmény javítása érdekében módosítható beállítások című témakörben talál.

A teljesítményt befolyásoló virtuális hálózati tényezők

Virtuális gép maximális kimenő átviteli sebessége

Az Azure különböző virtuálisgép-méreteket és típusokat biztosít, amelyek mindegyike különböző teljesítménybeli képességekkel rendelkezik. Az egyik ilyen képesség a hálózati átviteli sebesség (vagy sávszélesség), amelyet megabit/másodpercben (Mbps) mérnek. Mivel a virtuális gépeket megosztott hardveren üzemeltetik, a hálózati kapacitást igazságosan kell megosztani az azonos hardvert használó virtuális gépek között. A nagyobb virtuális gépek nagyobb sávszélességet kapnak, mint a kisebb virtuális gépek.

Az egyes virtuális gépekhez lefoglalt hálózati sávszélességet a rendszer a virtuális gép kimenő (kimenő) forgalmán méri. A virtuális gépet elhagyó összes hálózati forgalom beleszámít a lefoglalt korlátba, a céltól függetlenül. Ha egy virtuális gépre 1000 Mb/s-os korlát vonatkozik, ez a korlát azt határozza meg, hogy a kimenő forgalom egy másik virtuális gépre irányul-e ugyanabban a virtuális hálózaton vagy az Azure-on kívül.

A bejövő forgalom nincs közvetlenül mérve vagy korlátozva. Vannak azonban más tényezők is, például a cpu- és a tárolási korlátok, amelyek befolyásolhatják a virtuális gépek bejövő adatok feldolgozásának képességét.

A gyorsított hálózatkezelés célja a hálózati teljesítmény javítása, beleértve a késést, az átviteli sebességet és a processzorhasználatot. A gyorsított hálózatkezelés javíthatja a virtuális gépek átviteli sebességét, de ezt csak a virtuális gép lefoglalt sávszélességén keresztül teheti meg.

Az Azure-beli virtuális gépekhez legalább egy hálózati adapter csatlakozik. Lehet, hogy több is van. A virtuális géphez lefoglalt sávszélesség a géphez csatlakoztatott összes hálózati adapter kimenő forgalmának összege. Más szóval a sávszélesség virtuális gépenként van lefoglalva, függetlenül attól, hogy hány hálózati adapter van csatlakoztatva a géphez.

A várt kimenő átviteli sebesség és az egyes virtuálisgép-méretek által támogatott hálózati adapterek száma az Azure-beli Windows rendszerű virtuális gépek méreteiben található. A maximális átviteli sebesség megtekintéséhez válasszon ki egy típust (például általános célú), majd keresse meg a méretsorról szóló szakaszt az eredményül kapott oldalon (például "Dv2-sorozat"). Minden adatsorhoz tartozik egy táblázat, amely az utolsó oszlopban tartalmazza a hálózatkezelési specifikációkat, amelynek címe "Maximális hálózati adapterek / Várható hálózati sávszélesség (Mbps)."

Az átviteli korlát a virtuális gépre vonatkozik. Az átviteli sebességet nem befolyásolják ezek a tényezők:

Hálózati adapterek száma: A sávszélesség-korlát a virtuális gépről érkező összes kimenő forgalom összegére vonatkozik.
Gyorsított hálózatkezelés: Bár ez a funkció hasznos lehet a közzétett korlát eléréséhez, nem módosítja a korlátot.
Forgalom célhelye: Minden célhely a kimenő korlát felé számít.
Protokoll: Az összes protokoll kimenő forgalma beleértendő a korlátba.

További információ: Virtuális gépek hálózati sávszélessége.

Linux rendszerű virtuális gépek (VM-ek) optimalizálása

A modern Linux-kernelek olyan funkciókkal rendelkeznek, amelyek segíthetnek a konzisztenciában és a teljesítményben, amelyeket bizonyos számítási feladatok néha megkövetelnek.

További információ: Hálózati sávszélesség optimalizálása Azure-beli virtuális gépeken

Az internet teljesítményével kapcsolatos szempontok

A cikk során ismertetett módon az interneten és az Azure-on kívüli tényezők hatással lehetnek a hálózati teljesítményre. Íme néhány ilyen tényező:

Késés: A két végpont közötti oda-vissza menetidőt a köztes hálózatok problémái, a "legrövidebb" távolsági útvonalat nem használó forgalom és az optimálisnál rosszabb társviszony-létesítési útvonalak befolyásolják.
Csomagvesztés: A csomagvesztést a hálózati torlódás, a fizikai elérési út problémái és az alulteljesítő hálózati eszközök okozzák.
MTU-méret/töredezettség: Az útvonal töredezettsége késést okozhat az adatérkezésben vagy a rendelésen kívül érkező csomagokban, ami befolyásolhatja a csomagok kézbesítését.

A Traceroute jó eszköz a hálózati teljesítmény jellemzőinek (például csomagvesztés és késés) mérésére a forráseszköz és a céleszköz közötti minden hálózati útvonal mentén.

Hálózattervezési szempontok

A cikkben korábban tárgyalt szempontok mellett a virtuális hálózat topológiája hatással lehet a hálózat teljesítményére. Például egy küllős kialakítás, amely egy egyközpontos virtuális hálózatra irányuló globális forgalmat irányít vissza, hálózati késést eredményez, ami hatással van az általános hálózati teljesítményre.

A hálózati forgalom által áthaladó hálózati eszközök száma az általános késést is befolyásolhatja. Küllős és központi kialakítás esetén, ha a forgalom egy küllős hálózati virtuális eszközön, majd egy központi virtuális eszközön keresztül halad az internet felé, a hálózati virtuális eszközök némi késést okozhatnak.

Azure-régiók, virtuális hálózatok és késés

Az Azure-régiók több adatközpontból állnak, amelyek egy általános földrajzi területen belül léteznek. Előfordulhat, hogy ezek az adatközpontok fizikailag nem egymás mellett vannak. Bizonyos esetekben akár 10 kilométer is el van választva egymástól. A virtuális hálózat egy logikai átfedés az Azure fizikai adatközpont-hálózatán. A virtuális hálózatok nem utalnak konkrét hálózati topológiára az adatközponton belül.

Például két virtuális gép, amelyek ugyanabban a virtuális hálózatban és alhálózatban találhatók, különböző állványokban, sorokban vagy akár adatközpontokban is lehetnek. Elválaszthatók lábnyi vagy kilométernyi száloptikai kábellel. Ez a változat változó késést (néhány ezredmásodperc különbséget) eredményezhet a különböző virtuális gépek között.

A virtuális gépek földrajzi elhelyezését és a két virtuális gép közötti lehetséges késést a rendelkezésre állási csoportok, a közelségi elhelyezési csoportok és a rendelkezésre állási zónák konfigurációja befolyásolja. A régióban lévő adatközpontok közötti távolság azonban régióspecifikus, és elsősorban a régió adatközpont-topológiája befolyásolja.

Forrás NAT-portok kimerülése

Az Azure-beli üzembe helyezés képes kommunikálni az Azure-on kívüli végpontokkal a nyilvános interneten és/vagy a nyilvános IP-térben. Amikor egy példány kimenő kapcsolatot kezdeményez, az Azure dinamikusan leképezi a privát IP-címet egy nyilvános IP-címre. Miután az Azure létrehozta ezt a leképezést, a kimenő forgalom visszatérési forgalma is elérheti azt a privát IP-címet, ahonnan a folyamat származik.

Minden kimenő kapcsolat esetében az Azure Load Balancernek bizonyos ideig fenn kell tartania ezt a leképezést. Az Azure több-bérlős jellegéből adódóan a leképezés fenntartása minden virtuális gép minden kimenő folyamatához erőforrás-igényes lehet. Vannak tehát olyan korlátok, amelyek az Azure Virtual Network konfigurációja alapján vannak beállítva és alapulnak. Vagy, ha azt mondjuk, hogy pontosabban, egy Azure-beli virtuális gép csak bizonyos kimenő kapcsolatokat tud létrehozni egy adott időpontban. Ha eléri ezeket a korlátokat, a virtuális gép nem fog több kimenő kapcsolatot létesíteni.

Ez a viselkedés azonban konfigurálható. Az SNAT-ről és az SNAT-portok kimerüléséről ebben a cikkben talál további információt.

Hálózati teljesítmény mérése az Azure-ban

A cikkben szereplő teljesítménykorlátok nagy része a két virtuális gép közötti hálózati késéshez/oda-visszaúthoz (RTT) kapcsolódik. Ez a szakasz néhány javaslatot tartalmaz a késés/RTT tesztelésére, valamint a TCP-teljesítmény és a virtuálisgép-hálózat teljesítményének tesztelésére. Az ebben a szakaszban ismertetett technikákkal hangolhatja és tesztelheti a korábban tárgyalt TCP/IP- és hálózati értékeket. Adja meg a késés, az MTU, az MSS és az ablakméret értékeit a korábban megadott számításokba, és hasonlítsa össze az elméleti maximumokat a tesztelés során megfigyelt tényleges értékekkel.

Utazási idő és csomagvesztés mérése

A TCP-teljesítmény nagymértékben támaszkodik az RTT-ra és a csomagvesztésre. A Windowsban és Linuxban elérhető PING segédprogram a legegyszerűbb módszert kínálja az RTT és a csomagvesztés mérésére. A PING kimenete a forrás és a cél közötti minimális/maximális/átlagos késést jeleníti meg. Csomagvesztést mutat. A PING alapértelmezés szerint az ICMP protokollt használja. A PSPing használatával tesztelheti a TCP RTT-t. További információ: PsPing.

Az ICMP- és TCP-pingek nem mérik a gyorsított hálózati adatúthálózatot. A datapath méréséhez olvassa el ebben a cikkben a Latte-ről és a SockPerfről szóló cikket.

Virtuális gép tényleges sávszélességének mérése

Az Azure-beli virtuális gépek sávszélességének pontos méréséhez kövesse ezt az útmutatót.

A többi forgatókönyv teszteléséről az alábbi cikkekben talál további információt:

Nem hatékony TCP-viselkedések észlelése

A csomagrögzítésekben az Azure-ügyfelek tcp-jelzőkkel (SACK, DUP ACK, RETRANSMIT és FAST RETRANSMIT) rendelkező TCP-csomagokat láthatnak, amelyek hálózati teljesítményproblémákat jelezhetnek. Ezek a csomagok kifejezetten a csomagvesztésből eredő hálózati hatékonysági hiányosságokat jelzik. A csomagvesztést azonban nem feltétlenül az Azure teljesítményproblémái okozzák. A teljesítményproblémákat az alkalmazás, az operációs rendszer vagy más olyan problémák okozhatják, amelyek nem feltétlenül kapcsolódnak közvetlenül az Azure-platformhoz.

Ne feledje továbbá, hogy néhány újraközvetítés és duplikált ACK-k normálisak a hálózaton. A TCP-protokollok megbízhatónak lettek létrehozva. Ezeknek a TCP-csomagoknak a csomagrögzítésben való bizonyítéka nem feltétlenül jelent rendszerszintű hálózati problémát, kivéve, ha túlzottak.

Ezek a csomagtípusok azonban azt jelzik, hogy a TCP-átviteli sebesség nem éri el a maximális teljesítményt a cikk más szakaszaiban ismertetett okok miatt.

Következő lépések

Most, hogy megismerte az Azure-beli virtuális gépek TCP/IP-teljesítményének finomhangolását, fontolja meg a virtuális hálózatok tervezésének egyéb tényezőinek feltárását. A virtuális hálózatok csatlakoztatásáról és konfigurálásáról is többet tudhat meg.