TCP/IP performance tuning for Azure VMs
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. Ez alapvető áttekintést nyújt a technikákról, és megvizsgálja, hogyan hangolhatók.
Gyakori TCP/IP-hangolási technikák
MTU, töredezettség és nagy méretű küldési kiszervezés
MTU
A maximális átviteli egység (MTU) a legnagyobb méretű keret (csomag), amely bájtban van megadva, és amely hálózati adapteren keresztül küldhető el. Az MTU egy konfigurálható beállítás. Az Azure-beli virtuális gépeken használt alapértelmezett MTU és a legtöbb hálózati eszköz alapértelmezett beállítása globálisan 1500 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 bájtos MTU-val rendelkező hálózati adapteren keresztül küldenek, a csomag egy 1500 bájtos é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 Nem töredezett 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-ban a töredezett csomagokat a gyorsított hálózatkezelés nem dolgozza fel. Ha egy virtuális gép töredezett csomagot kap, a rendszer a nem gyorsított útvonalon dolgozza fel azt. Ez azt jelenti, hogy a töredezett csomagok nem fogják kihasználni a gyorsított hálózatkezelés előnyeit (alacsonyabb késés, csökkentett jitter és nagyobb csomagok másodpercenként). Ezért javasoljuk, hogy lehetőség szerint kerülje a töredezettség elkerülését.
Alapértelmezés szerint az Azure kiesik a rendeléstöredékekből, vagyis a töredezett csomagokból, amelyek nem a forrásvégpontról továbbított sorrendben érkeznek meg a virtuális géphez. Ez akkor fordulhat elő, ha a csomagokat az interneten vagy más nagy WAN-okon keresztül továbbítják. Bizonyos esetekben engedélyezhető a nem megfelelő töredék átrendezése. Ha egy alkalmazás ezt igényli, nyisson meg egy támogatási esetet.
Az MTU hangolása
Nem javasoljuk, hogy az ügyfelek növeljék az MTU-t a virtuálisgép-hálózati adaptereken. Ha a virtuális gépnek olyan célhelyekkel kell kommunikálnia, amelyek nem a virtuális hálózatban találhatók, és hasonló MTU-készlettel rendelkeznek, valószínűleg töredezettség fog történni, ami csökkenti a teljesítményt.
Nagy méretű küldési kiszervezés
A nagy méretű küldési kiszervezés (LSO) javíthatja a hálózati teljesítményt a csomagok ethernet-adapterre való szegmentálásának kiszervezésével. 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, hogy felszabadíthatja a processzort a csomagok olyan méretekre való szegmentálásától, amelyek megfelelnek az MTU-nak, és ki tudja kapcsolni a feldolgozást az Ethernet-adapterre, ahol a hardveren végzik. Az LSO előnyeiről további információt a nagyméretű küldési kiszervezés támogatása című témakörben talál.
Ha az LSO engedélyezve van, az Azure-ügyfelek nagy méretű kereteket láthatnak a csomagrögzítések végrehajtásakor. Ezek a nagy keretméretek arra késztethetik az ügyfeleket, hogy töredezettségről gondoljanak, vagy ha nem, akkor nagy MTU-t használnak. 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. Ezt a nem szegmentált keretet ezután a rendszer továbbítja az Ethernet-adapternek, és látható lesz a virtuális gépen végrehajtott csomagrögzítésben. A csomagot azonban az Ethernet-adapter az Ethernet-adapter MTU-jának megfelelően sok kisebb keretre bontja.
TCP MSS-ablak skálázása és PMTUD
TCP-szegmens maximális mérete
A TCP maximális szegmensmérete (MSS) olyan beállítás, amely korlátozza a TCP-szegmensek méretét, í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. Tehát egy 1500-ból álló MTU-val rendelkező felület 1460 MSS-sel rendelkezik. Az MSS azonban 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, a kettő közül pedig a kettő közül az alsót 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.
Elérési út MTU-felderítése
Az MSS egyeztetésre kerül, de lehet, hogy nem jelzi a ténylegesen használható MSS-t. Ennek az az oka, hogy a forrás és a cél közötti útvonalon lévő többi hálózati eszköz MTU-értéke alacsonyabb lehet, mint a forrás és a cél. Ebben az esetben az 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, és hatással van a hálózati teljesítményre. Ha a rendszer olyan csomagokat küld, amelyek túllépik a hálózati elérési út MTU-ját, a csomagokat egy alacsonyabb MSS-vel kell újraküldeni. Ha a feladó nem kapja meg az ICMP töredezettségére vonatkozó szükséges üzenetet, esetleg egy hálózati tűzfal miatt az elérési úton (amelyet gyakran PMTUD-feketelyuknak neveznek), a feladó nem tudja, hogy csökkentenie kell az MSS-t, és folyamatosan újra kell elküldenie a csomagot. Ezért nem javasoljuk az Azure-beli virtuális gép MTU-jának növelésé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 további szempontokat is figyelembe kell venni. A VPN-ek több fejlécet adnak hozzá a csomagokhoz, ami növeli a csomagméretet, és kisebb MSS-t igényel.
Az Azure esetében azt javasoljuk, hogy a TCP MSS-befogást 1350 bájtra, az alagút-illesztő MTU-t pedig 1400-ra állítsa. További információt a VPN-eszközök és az IPSec/IKE-paraméterek oldalán talál.
Késés, oda-vissza menetidő és TCP-ablak skálázása
Késés és oda-vissza menetidő
A hálózati késést a száloptikás hálózaton keresztüli fénysebesség szabályozza. A TCP hálózati átviteli sebességét a két hálózati eszköz közötti menetidő (RTT) is szabályozza.
| Ú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. Ez a távolság, kilométerben, hogy a fény utazik 1 ezredmásodpercben.
Vegyük példaként New Yorkot San Franciscóba. Az egyenes vonal távolsága 4148 km. Ha ezt az értéket az egyenlethez csatlakoztatja, a következőket kapjuk:
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át kap a fogadótól. Ha a feladó nem kap nyugtázást, újraküldi az adatokat. A képlet a következő:
TCP window size / TCP MSS = packets sent
Ebben a példában 65 535/ 1460 kerekítve van 45-re.
Ez a "nyugtázásra váró" á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, mielőtt további adatokat küldene.
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-késés (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 | .73 | 5,83 |
| 65,535 | 120 | .55 | 4.37 |
Ha a csomagok elvesznek, a TCP-kapcsolat maximális átviteli sebessége csökken, miközben a feladó újra elküldi a már elküldött adatokat.
TCP-ablak skálázása
A TCP-ablak skálázása egy olyan technika, amely dinamikusan növeli a TCP-ablak méretét, így több adat küldhető el, mielőtt nyugtázásra lenne szükség. Az előző példában 45 csomagot küldünk el, mielőtt nyugtázásra lenne szükség. Ha növeli az nyugtázás előtt küldhető csomagok számát, csökkenti a feladó nyugtázási várakozásainak számát, ami növeli a TCP maximális átviteli sebességét.
Ez a táblázat az alábbi kapcsolatokat szemlélteti:
| TCP-ablak mérete (bájt) | RTT-késés (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 gigabit).
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
Ezek az érvényes TCP-beállítások a következőkhöz AutoTuningLevel:
| Autotuninglevel | Méretezési tényező | Skálázási szorzó | Képlet a következőhöz: ablak maximális méretének kiszámítása |
|---|---|---|---|
| Letiltva | None | None | Ablak mérete |
| Korlátozott hozzáférésű | 4 | 2^4 | Ablak mérete * (2^4) |
| Szigorúan korlátozott | 2 | 2^2 | Ablak mérete * (2^2) |
| Normal | 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
Accelerated networking
A virtuális gépek hálózati funkciói korábban processzorigényesek voltak mind a vendég virtuális gépen, mind a hipervizoron/gazdagépen. A gazdagépen áthaladó csomagokat a gazdagép processzora dolgozza fel szoftverben, beleértve az összes virtuális hálózat beágyazást és lefejezést. Minél nagyobb a forgalom a gazdagépen, annál nagyobb a processzorterhelés. És ha a gazdagép processzora más műveletekkel van elfoglalva, az hatással lesz a hálózati teljesítményre és a késésre is. Az Azure gyorsított hálózatkezeléssel oldja meg ezt a problémát.
A gyorsított hálózatkezelés konzisztens ultralowattos hálózati késést biztosít az Azure belső programozható hardverén és az olyan technológiákon keresztül, mint az SR-IOV. A gyorsított hálózatkezelés az Azure szoftveralapú hálózatkezelési verem nagy részét a processzorok és az FPGA-alapú intelligens hálózati adapterek közé helyezi át. Ez a módosítás lehetővé teszi a végfelhasználói alkalmazások számára a számítási ciklusok visszaszerzését, ami kevesebb terhelést okoz a virtuális gépen, csökkentve a késést és az inkonzisztenciat. 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 datapathot a gazdagép SmartNIC-jével. A gyorsított hálózatkezelés néhány előnye:
Kisebb késés /nagyobb csomagok másodpercenként (pps):A virtuális kapcsoló adatútvonalról való eltávolítása megszünteti a gazdagépen a szabályzatfeldolgozáshoz szükséges időt, és növeli a virtuális gépen 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-ről bővebben a Bevezetés az oldalméretezés fogadása 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 befolyásolja a hálózat és az alkalmazás teljesítményét. Az elfoglalt virtuális gépeken, amelyek számos szoftvercsatornát nyitnak meg és zárnak be, akár ügyfélként, akár kiszolgálóként (Forrás IP:Forrásport + Cél IP-cím:Célport) a TCP normál működése során egy adott szoftvercsatorna hosszú ideig TIME_WAIT állapotba kerülhet. A TIME_WAIT állapotnak az a célja, hogy a szoftvercsatornán a lezárás előtt további adatokat is kézbesítsen. Így a TCP/IP-veremek általában megakadályozzák a szoftvercsatornák újrafelhasználását az ügyfél TCP SYN-csomagjának csendes elvetésével.
A szoftvercsatornák TIME_WAIT töltött ideje konfigurálható. Ez 30 másodperctől 240 másodpercig terjedhet. A szoftvercsatornák véges erőforrások, és az adott időpontban használható szoftvercsatornák száma konfigurálható. (Az elérhető szoftvercsatornák száma általában körülbelül 30 000.) Ha a rendelkezésre álló szoftvercsatornák használatban vannak, vagy ha az ügyfelek és a kiszolgálók nem egyeznek TIME_WAIT beállításaival, és egy virtuális gép megpróbál újra felhasználni egy szoftvercsatornát TIME_WAIT állapotban, az új kapcsolatok sikertelenek lesznek, mivel a TCP SYN-csomagok csendesen megszakadnak.
A kimenő szoftvercsatornák porttartományának értéke általában az operációs rendszer TCP/IP-veremén belül konfigurálható. Ugyanez igaz a TCP TIME_WAIT beállításaira és a szoftvercsatornák ú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 szoftvercsatornák 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 az előző, TIME_WAIT állapotban lévő 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 a hálózati teljesítmény javítása érdekében módosítható Gépház 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 számos különböző virtuálisgép-méretet és -típust kínál, 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ég mérése a virtuális gép kimenő (kimenő) forgalmán történik. 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 például 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 a korlát felé számít.
További információ: Virtuális gépek hálózati sávszélessége.
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 cél közötti oda-vissza utazás időtartamát befolyásolhatja a köztes hálózatok problémái, a "legrövidebb" távolsági útvonalat nem használó forgalom, valamint az optimálisnál rosszabb társviszony-létesítési útvonalak.
Csomagvesztés: A csomagvesztést okozhatja 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.
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. Egy küllős kialakítás például, 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 lesz a teljes 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. Például küllős kialakítás esetén, ha a forgalom egy küllős hálózati virtuális berendezésen és egy központi virtuális berendezésen halad át az internetre való átvitel előtt, a hálózati virtuális berendezések 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éterre is el vannak 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. Ezeket szét lehet különíteni láb száloptikai kábel vagy kilométeres száloptikai kábel. 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 elhelyezkedését és a két virtuális gép közötti lehetséges késést a rendelkezésre állási csoportok és a rendelkezésre állási zónák konfigurációja befolyásolhatja. 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. Pontosabban azt is mondhatjuk, hogy egy Azure-beli virtuális gép csak bizonyos számú kimenő kapcsolatot tud létrehozni egy adott időpontban. Ha eléri ezeket a korlátokat, a virtuális gép nem tud 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 közül több 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. A késés, az MTU, az MSS és az ablakméret értékeit a korábban megadott számításokba illesztheti, és összehasonlíthatja 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. A csomagvesztést is megjeleníti. 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.
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.
Az egyéb forgatókönyvek teszteléséről az alábbi cikkekben olvashat bővebben:
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ák lehetnek alkalmazásproblémák, operációsrendszer-problémák vagy egyéb problémá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, érdemes lehet elolvasni a virtuális hálózatok tervezésének egyéb szempontjait, vagy többet megtudni a virtuális hálózatok csatlakoztatásáról és konfigurálásáról.