Troubleshooting network performance

Áttekintés

Az Azure stabil és gyors módot biztosít a helyszíni hálózat azure-hoz való csatlakoztatására. Az olyan megoldások segítségével, mint a helyek közötti VPN és az ExpressRoute, kisebb és nagyobb szervezetek is sikerrel futtathatják üzleti folyamataikat az Azure-ban. De mi történik, ha a teljesítmény nem felel meg a várakozásnak vagy a korábbi élménynek? Ez a cikk segíthet szabványosítani az adott környezet tesztelésének és alapkonfigurációjának módját.

Megtudhatja, hogyan tesztelheti egyszerűen és következetesen a hálózati késést és a sávszélességet két gazdagép között. Emellett tanácsokkal is szolgál az Azure-hálózat megvizsgálásának módjaihoz a problémapontok elkülönítéséhez. A tárgyalt PowerShell-szkripthez és eszközökhöz két gazdagépre van szükség a hálózaton (a tesztelt hivatkozás mindkét végén). Az egyik gazdagépnek Windows Server vagy Asztali, a másik pedig Windows vagy Linux rendszerű lehet.

Hálózati összetevők

Mielőtt belevágunk a hibaelhárításba, beszéljünk meg néhány gyakori kifejezést és összetevőt. Ez a vitafórum biztosítja, hogy a végpontok közötti lánc minden olyan összetevőjére gondoljunk, amely lehetővé teszi a kapcsolatot az Azure-ban.

A legmagasabb szinten három fő hálózati útválasztási tartomány található:

• Az Azure-hálózat (kék felhő)
• Az internet vagy a WAN (zöld felhő)
• A vállalati hálózat (narancssárga felhő)

A diagramot jobbról balra tekintve tekintsük át röviden az egyes összetevőket:

• Virtuális gép – A kiszolgáló több hálózati adapterrel is rendelkezhet. Győződjön meg arról, hogy a statikus útvonalak, az alapértelmezett útvonalak és az operációs rendszer beállításai úgy küldik és fogadják a forgalmat, ahogyan ön gondolja. Emellett minden virtuálisgép-termékváltozat sávszélesség-korlátozással rendelkezik. Ha kisebb virtuálisgép-termékváltozatot használ, a forgalmat a hálózati adapter számára elérhető sávszélesség korlátozza. Javasoljuk, hogy a teszteléshez használjon DS5v2-t a megfelelő sávszélesség biztosítása érdekében a virtuális gépen.

• Hálózati adapter – Győződjön meg arról, hogy ismeri a szóban forgó hálózati adapterhez rendelt magánhálózati IP-címet.

• NIC NSG – Előfordulhat, hogy a hálózati adapter szintjén bizonyos NSG-k vannak alkalmazva, és győződjön meg arról, hogy az NSG-szabálykészlet megfelelő a átadni kívánt forgalomhoz. Például győződjön meg arról, hogy az iPerf 5201-hez, az RDP-hez a 3389-hez vagy az SSH-hoz készült 22-s port nyitva van, hogy a tesztforgalom áthaladhasson.

• Virtuális hálózatok alhálózata – A hálózati adapter egy adott alhálózathoz van rendelve, győződjön meg arról, hogy melyiket és az alhálózathoz társított szabályokat.

• Alhálózati NSG – A hálózati adapterhez hasonlóan az NSG-k is alkalmazhatók az alhálózaton. Győződjön meg arról, hogy az NSG-szabálykészlet megfelelő az áthárítani kívánt forgalomhoz. A hálózati adapter felé irányuló forgalom esetében először az NSG alhálózat, majd a hálózati adapter NSG-je érvényes. Amikor a forgalom kifelé halad a virtuális gépről, a hálózati adapter NSG-je először az alhálózati NSG-t alkalmazza.

• Alhálózati UDR – A felhasználó által definiált útvonalak köztes ugráshoz (például tűzfalhoz vagy terheléselosztóhoz) irányíthatják a forgalmat. Győződjön meg arról, hogy van-e UDR a forgalom számára. Ha igen, akkor ismerje meg, hogy hová kerül, és mi lesz a következő ugrás a forgalommal. Egy tűzfal például átadhat bizonyos forgalmat, és megtagadhatja a többi forgalmat ugyanazon két gazdagép között.

• Átjáró alhálózata / NSG/UDR – A virtuálisgép-alhálózathoz hasonlóan az átjáró alhálózata is rendelkezhet NSG-kkel és UDR-ekkel. Győződjön meg arról, hogy ott vannak, és milyen hatással vannak a forgalomra.

• VNet Gateway (ExpressRoute) – Ha a társviszony -létesítés (ExpressRoute) vagy a VPN engedélyezve van, nincs sok olyan beállítás, amely befolyásolhatja a forgalmi útvonalak módját vagy állapotát. Ha egy virtuális hálózati átjáró több ExpressRoute-kapcsolatcsoporthoz vagy VPN-alagúthoz csatlakozik, ismernie kell a kapcsolat súlyának beállításait. A kapcsolat súlya befolyásolja a kapcsolati beállításokat, és meghatározza a forgalom elérési útját.

• Útvonalszűrő (Nem jelenik meg) – Útvonalszűrőre van szükség a Microsoft-társviszony ExpressRoute-on keresztüli használatakor. Ha nem kap útvonalakat, ellenőrizze, hogy az útvonalszűrő konfigurálva van-e, és megfelelően van-e alkalmazva a kapcsolatcsoportra.

Ezen a ponton a hivatkozás WAN-részén van. Ez az útválasztási tartomány lehet a szolgáltató, a vállalati WAN vagy az internet. Ezek a hivatkozások számos ugrással, eszközzel és vállalattal foglalkoznak, ami megnehezítheti a hibaelhárítást. Először ki kell zárnia az Azure-t és a vállalati hálózatokat is, mielőtt megvizsgálhatja a köztes ugrásokat.

Az előző ábrán a bal szélen található a vállalati hálózat. A vállalat méretétől függően ez az útválasztási tartomány lehet néhány hálózati eszköz Ön és a WAN között, vagy egy campus/nagyvállalati hálózat több eszközrétege.

A három különböző magas szintű hálózati környezet összetettsége miatt. Gyakran optimális a széleken kezdeni, és megpróbálni megmutatni, hogy hol jó a teljesítmény, és hol romlik. Ez a megközelítés segíthet azonosítani a három probléma útválasztási tartományát. Ezután a hibaelhárítást az adott környezetre összpontosíthatja.

Tools

A legtöbb hálózati probléma elemezhető és elkülöníthető olyan alapvető eszközökkel, mint a pingelés és a nyomkövetés. Ritka, hogy olyan mélyre kell mennie, mint egy csomagelemzés az olyan eszközökkel, mint a Wireshark.

A hibaelhárítás megkönnyítése érdekében az Azure Csatlakozás ivity Toolkit (AzureCT) úgy lett kifejlesztve, hogy néhány eszközt egy egyszerű csomagba helyezzen. A teljesítményteszteléshez az olyan eszközök, mint az iPerf és a PSPing, információt nyújthatnak a hálózatról. Az iPerf egy gyakran használt eszköz az alapvető teljesítménytesztekhez, és meglehetősen könnyen használható. A PSPing a SysInternals által kifejlesztett pingelési eszköz. A PSPing ICMP- és TCP-pingelést is képes elvégezni egy távoli gazdagép eléréséhez. Mindkét eszköz egyszerű, és egyszerűen "telepítve" van, ha a fájlokat a gazdagép egyik könyvtárába rögzíti.

Ezek az eszközök és metódusok egy PowerShell-modulba (AzureCT) vannak csomagolva, amelyet telepíthet és használhat.

AzureCT – az Azure Csatlakozás ivity Toolkit

Az AzureCT PowerShell-modul két összetevőből áll: rendelkezésre állási tesztelés és teljesítménytesztelés. Ez a dokumentum csak a teljesítményteszteléssel foglalkozik, így a PowerShell-modulban található két Hivatkozási teljesítmény parancsra összpontosíthat.

Az eszközkészlet a teljesítményteszteléshez három alapvető lépésből áll.

1. A PowerShell-modul telepítése.

   (new-object Net.WebClient).DownloadString("https://aka.ms/AzureCT") | Invoke-Expression
   
   

   Ez a parancs letölti a PowerShell-modult, és helyileg telepíti.

2. Telepítse a támogató alkalmazásokat.

   Install-LinkPerformance
   

   Ez az AzureCT-parancs egy új könyvtárba C:\ACTToolstelepíti az iPerf és a PSPing fájlt, és megnyitja a Windows tűzfalportokat is, hogy engedélyezze az ICMP és az 5201-s (iPerf) port forgalmát.

3. Futtassa a teljesítménytesztet.

   Először is a távoli gazdagépen telepítenie és futtatnia kell az iPerf-et kiszolgáló módban. Győződjön meg arról is, hogy a távoli gazdagép figyeli a 3389-et (WINDOWS RDP) vagy a 22-et (Linux SSH), és engedélyezi az iPerf 5201-s port forgalmát. Ha a távoli gazdagép Windows, telepítse az AzureCT-t, és futtassa az Install-LinkPerformance parancsot. A parancs beállítja az iPerf-et és az iPerf kiszolgáló módban való sikeres indításához szükséges tűzfalszabályokat.

   Ha a távoli gép elkészült, nyissa meg a PowerShellt a helyi gépen, és indítsa el a tesztet:

   Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 10
   

   Ez a parancs egyidejű terhelés- és késéstesztek sorozatát futtatja a hálózati kapcsolat sávszélesség-kapacitásának és késésének becsléséhez.

4. Tekintse át a tesztek kimenetét.

   A PowerShell kimeneti formátuma a következőhöz hasonló:

   

   Az összes iPerf- és PSPing-teszt részletes eredményei az AzureCT-eszközök "C:\ACTTools" könyvtárának egyes szövegfájljaiban találhatók.

Hibaelhárítás

Ha a teljesítményteszt nem a várt eredményeket adja, megtudhatja, miért érdemes lépésről lépésre haladni. Tekintettel az elérési út összetevőinek számára, a szisztematikus megközelítés gyorsabb megoldást kínál, mint a megkerülés. A rendszeres hibaelhárítással megakadályozhatja, hogy többször is elvégezze a szükségtelen tesztelést.

Megjegyzés:

Az alábbi forgatókönyv teljesítményproblémát, nem csatlakozási problémát jelent. Az Azure-hálózathoz való kapcsolódási probléma elkülönítéséhez kövesse az ExpressRotue kapcsolati cikkét.

Először is, vitatja a feltételezéseket. Ésszerű az elvárás? Ha például 1 Gb/s-os ExpressRoute-kapcsolatcsoporttal és 100 ms késéssel rendelkezik. Nem ésszerű a teljes 1 Gb/s forgalomra számítani, tekintettel a TCP teljesítményjellemzőire a nagy késésű kapcsolatokon keresztül. A teljesítményfeltevésekről további információt a Hivatkozások szakaszban talál.

Ezután azt javasoljuk, hogy kezdje az útválasztási tartományok közötti peremhálózatokat, és próbálja meg elkülöníteni a problémát egyetlen fő útválasztási tartományra. A vállalati hálózatban, a WAN-ban vagy az Azure Networkben kezdheti. Kapcsolatok gyakran a "fekete dobozt" okolják az útvonalon. Bár a fekete dobozt könnyű hibáztatni, jelentősen késleltetheti a felbontást. Különösen akkor, ha a probléma olyan területen van, ahol módosításokat végezhet a probléma megoldásához. Mielőtt átadnák a szolgáltatónak vagy az internetszolgáltatónak, győződjön meg arról, hogy kellő gondossággal jár el.

Miután azonosította a problémát tartalmazó fő útválasztási tartományt, létre kell hoznia egy diagramot a szóban forgó területről. Diagram készítésekor módszeresen végigjárhatja és elkülönítheti a problémát. Megtervezheti a tesztelési pontokat, és frissítheti a térképet, miközben megtisztítja a területeket, vagy mélyebbre ás a tesztelés előrehaladása során.

Most, hogy elkészült egy diagram, kezdje el szegmensekre osztani a hálózatot, és szűkítse le a problémát. Megtudhatja, hol működik, és hol nem. Folytassa a tesztelési pontok áthelyezését, hogy elkülönítse a sértő összetevőt.

Emellett ne felejtse el megnézni az OSI-modell többi rétegét is. Könnyen összpontosíthat a hálózatra és az 1–3. rétegre (fizikai, adat- és hálózati rétegek), de a problémák az alkalmazásréteg 7. rétegében is megjelenhetnek. Tartsa szem előtt, és ellenőrizze a feltételezéseket.

Speciális ExpressRoute-hibaelhárítás

Ha nem biztos abban, hogy hol van valójában a felhő peremhálózata, az Azure-összetevők elkülönítése kihívást jelenthet. Az ExpressRoute használatakor az edge egy Microsoft Enterprise Edge (M Standard kiadás E) nevű hálózati összetevő. Az ExpressRoute használatakor az M Standard kiadás E az első kapcsolódási pont a Microsoft hálózatába, és az utolsó ugrás a Microsoft-hálózat elhagyásakor. Amikor kapcsolatobjektumot hoz létre a virtuális hálózati átjáró és az ExpressRoute-kapcsolatcsoport között, ténylegesen kapcsolatot létesít az M Standard kiadás E-hez. Az M Standard kiadás E felismerése első vagy utolsó ugrásként attól függően, hogy a forgalom milyen irányban nélkülözhetetlen az Azure hálózati problémáinak elkülönítéséhez. Annak ismerete, hogy melyik irány bizonyítja, hogy a probléma az Azure-ban vagy a WAN vagy a vállalati hálózat további rétegeiben található.

Megjegyzés:

Figyelje meg, hogy az M Standard kiadás E nincs az Azure-felhőben. Az ExpressRoute valójában nem az Azure-ban, hanem a Microsoft-hálózat peremén található. Miután csatlakozott az ExpressRoute-hoz egy M Standard kiadás E-hez, csatlakozik a Microsoft hálózatához, innen bármelyik felhőszolgáltatáshoz, például a Microsoft 365-höz (Microsoft Társviszony-létesítéssel) vagy az Azure-hoz (privát és/vagy Microsoft-társviszony-létesítéssel) léphet.

Ha két virtuális hálózat csatlakozik ugyanahhoz az ExpressRoute-kapcsolatcsoporthoz, tesztsorozattal elkülönítheti a problémát az Azure-ban.

Tesztterv

1. Futtassa a Get-LinkPerformance tesztet a VM1 és a VM2 között. Ez a teszt bemutatja, hogy a probléma helyi-e vagy sem. Ha ez a teszt elfogadható késést és sávszélességet eredményez, megjelölheti a helyi virtuális hálózatot jóként.

2. Ha a helyi virtuális hálózati forgalom jó, futtassa a Get-LinkPerformance tesztet a VM1 és a VM3 között. Ez a teszt a Microsoft-hálózaton keresztül gyakorolja a kapcsolatot az M Standard kiadás E felé, majd vissza az Azure-ba. Ha ez a teszt elfogadható késést és sávszélességet eredményez, megjelölheti az Azure-hálózatot jóként.

3. Ha az Azure ki van zárva, hasonló tesztsorozatot végezhet a vállalati hálózaton. Ha ez is jól működik, ideje együttműködni a szolgáltatóval vagy az internetszolgáltatóval a WAN-kapcsolat diagnosztizálásához. Példa: Futtassa ezt a tesztet két fiókiroda, illetve az asztal és egy adatközpont-kiszolgáló között. Attól függően, hogy mit tesztel, keresse meg azokat a végpontokat, például a kiszolgálókat és az ügyfélszámítógépeket, amelyek gyakorolhatják ezt az útvonalat.

Fontos

Kritikus fontosságú, hogy minden tesztnél megjelölje a teszt futtatásának időpontját, és rögzítse az eredményeket egy közös helyen. Minden tesztfuttatásnak azonos kimenettel kell rendelkeznie, így összehasonlíthatja az eredményül kapott adatokat a tesztfuttatások során, és nem lehetnek "lyukak" az adatokban. A több teszt közötti konzisztencia az elsődleges oka annak, hogy az AzureCT-t használjuk a hibaelhárításhoz. A varázslat nem a pontosan futtatott terhelési forgatókönyvekben van, hanem az a varázslat, hogy minden egyes tesztből egységes tesztet és adatkimenetet kapunk. Az idő rögzítése és a konzisztens adatok minden egyes alkalommal történő rögzítése különösen hasznos, ha később azt tapasztalja, hogy a probléma szórványos. Legyen szorgalmas az adatgyűjtéssel, és elkerülheti, hogy órákon át tesztelje ugyanazokat a forgatókönyveket.

A probléma elszigetelt, most mi?

Minél jobban elkülöníti a problémát, annál gyorsabban találja meg a megoldást. Néha elér egy pontot, ahol nem tud továbbhaladni a hibaelhárítással. Láthatja például, hogy a szolgáltató a komlókat európán keresztül viszi végig, de azt várja, hogy az útvonal ázsiában is megmaradjon. Ezen a ponton forduljon valakihez segítségért. A megkérdezett személy attól az útválasztási tartománytól függ, amelytől elkülöníti a problémát. Ha le tudja szűkíteni egy adott összetevőre, amely még jobb lenne.

Vállalati hálózati problémák esetén a belső informatikai részleg vagy szolgáltató segíthet az eszközkonfigurációban vagy a hardverek javításában.

A WAN hibaelhárításához ajánlott a tesztelési eredmények megosztása a szolgáltatóval vagy az internetszolgáltatóval, mivel ez segíthet nekik a munkájukban. A teszteredmények azt is elkerülhetik, hogy ugyanazokat a feladatokat hajtsa végre újra, mint korábban. Előfordulhat azonban, hogy maguk is ellenőrizni szeretnék az eredményeket. Ez a bizalom elvén alapul, de ellenőrizze.

Ha az Azure-ban a lehető legrészletesebben elkülöníti a problémát, ideje áttekinteni az Azure hálózati dokumentációját , majd ha mégis szükség van rá , nyisson meg egy támogatási jegyet.

References

Késési/sávszélesség-várakozások

Tipp.

A tesztelt végpontok közötti földrajzi késés (mérföld vagy kilométer) messze a késés legnagyobb összetevője. Bár a berendezések késése (fizikai és virtuális összetevők, ugrások száma stb.) is szerepet játszik, a wan-kapcsolatok kezelése során a földrajzi hely bizonyult a teljes késés legnagyobb összetevőjének. Azt is fontos megjegyezni, hogy a távolság nem az egyenes vonal vagy az úttérkép távolsága, hanem a szálfuttatás távolsága. Ez a távolság hihetetlenül nehéz, hogy bármilyen pontossággal. Ennek eredményeképpen általában egy városi távolság kalkulátort használunk az interneten, és tudjuk, hogy ez a módszer egy bruttóan pontatlan mérték, de elegendő egy általános elvárás beállításához.

Van például egy ExpressRoute-beállítás Seattle-ben, Washingtonban az USA-ban. Az alábbi táblázat a különböző Azure-helyeken végzett tesztelés késését és sávszélességét mutatja be. Becsültük a teszt mindkét vége közötti földrajzi távolságot.

Tesztbeállítás:

• Egy 10 Gb/s hálózati adapterrel rendelkező Windows Server 2016 rendszerű fizikai kiszolgáló, amely ExpressRoute-kapcsolatcsoporthoz csatlakozik.

• Egy 10 Gb/s-os Prémium ExpressRoute-kapcsolatcsoport a privát társviszony-létesítés engedélyezésével azonosított helyen.

• Egy Azure-beli virtuális hálózat ultraperformancia-átjáróval a megadott régióban.

• Windows Server 2016-ot futtató DS5v2 virtuális gép a virtuális hálózaton. A virtuális gép nem volt tartományhoz csatlakoztatva, az alapértelmezett Azure-rendszerképből lett létrehozva (nincs optimalizálás vagy testreszabás) az AzureCT telepítve.

• Minden teszt az AzureCT Get-LinkPerformance parancsot használja egy 5 perces terhelési teszttel a hat teszt mindegyikéhez. Például:

  Get-LinkPerformance -RemoteHost 10.0.0.1 -TestSeconds 300
  

• Az egyes tesztek adatfolyamai a helyszíni fizikai kiszolgálóról (Seattle iPerf-ügyfél) egészen az Azure-beli virtuális gépig (a felsorolt Azure-régió iPerf-kiszolgálói) felé áramlottak.

• A "Késés" oszlop adatai a Nincs terheléses tesztből származnak (tcp-késési teszt iPerf futtatása nélkül).

• A "Maximális sávszélesség" oszlop adatai a 16 TCP-forgalom terhelési tesztből származnak, 1 Mb-os ablakmérettel.

Késési/sávszélesség-eredmények

Fontos

Ezek a számok csak általános referenciaként szolgálnak. Számos tényező befolyásolja a késést, és bár ezek az értékek általában konzisztensek az idő függvényében, az Azure-ban vagy a szolgáltatók hálózatában lévő feltételek bármikor különböző útvonalakon küldhetik a forgalmat, így a késés és a sávszélesség is befolyásolható. A változások hatásai általában nem eredményeznek jelentős különbségeket.

ExpressRoute Hely	Azure Region	Becsült Távolság (km)	Latency	1 Munkamenet Bandwidth	Maximum Bandwidth
Seattle	West US 2	191 km	5 ms	262,0 Mbit/s	3,74 Gbits/s
Seattle	West US	1094 km	18 ms	82,3 Mbit/s	3,70 Gbits/s
Seattle	Central US	2357 km	40 ms	38,8 Mbit/s	2,55 Gbits/s
Seattle	South Central US	2877 km	51 ms	30,6 Mbit/s	2,49 Gbits/s
Seattle	North Central US	2792 km	55 ms	27,7 Mbit/s	2,19 Gbits/s
Seattle	East US 2	3769 km	73 ms	21,3 Mbit/s	1,79 Gbits/s
Seattle	East US	3699 km	74 ms	21,1 Mbit/s	1,78 Gbits/s
Seattle	Japan East	7705 km	106 ms	14,6 Mbit/s	1,22 Gbits/s
Seattle	UK South	7708 km	146 ms	10,6 Mbit/s	896 Mbit/s
Seattle	West Europe	7834 km	153 ms	10,2 Mbit/s	761 Mbit/s
Seattle	Australia East	12 484 km	165 ms	9,4 Mbit/s	794 Mbit/s
Seattle	Southeast Asia	12 989 km	170 ms	9,2 Mbit/s	756 Mbit/s
Seattle	Dél-Brazília *	10 930 km	189 ms	8,2 Mbit/s	699 Mbit/s
Seattle	South India	12 918 km	202 ms	7,7 Mbit/s	634 Mbit/s

* A brazíliai késés jó példa arra, hogy az egyenes vonal távolsága jelentősen eltér a szálas futási távolságtól. A várt késés 160 ms lenne, de valójában 189 ms. A késés különbsége úgy tűnik, hogy hálózati problémát jelez valahol. De a valóság az, hogy a szálvonal nem megy Brazíliába egyenes vonalban. Ezért érdemes további 1000 km-t várnia, hogy Seattle-ből Brazíliába jusson.

Megjegyzés:

Bár ezeket a számokat figyelembe kell venni, azokat a PowerShellen keresztül a Windows IPERF-ben működő AzureCT használatával tesztelték. Ebben a forgatókönyvben az IPERF nem tartja be a skálázási tényező alapértelmezett Windows TCP-beállításait, és sokkal alacsonyabb műszakszámot használ a TCP-ablak méretéhez. Az itt bemutatott számok alapértelmezett IPERF-értékekkel lettek végrehajtva, és csak általános hivatkozásra szolgálnak. Az IPERF-parancsok kapcsolóval és nagy TCP-ablakmérettel történő -w finomhangolásával nagyobb átviteli sebesség érhető el nagy távolságokon, jelentősen jobb átviteli sebességet mutatva. Emellett annak biztosítása érdekében, hogy az ExpressRoute a teljes sávszélességet használja, ideális az IPERF többszálas változatban való futtatása egyszerre több gépről annak érdekében, hogy a számítási kapacitás elérje a maximális kapcsolati teljesítményt, és ne korlátozza egyetlen virtuális gép feldolgozási kapacitása. A Windowson a legjobb Iperf-eredmények eléréséhez használja a "Set-NetTCPSetting -AutoTuningLevelLocal Experimental" parancsot. Mielőtt bármilyen módosítást végez, ellenőrizze a szervezeti szabályzatokat.

További lépések

• Az Azure Csatlakozás ivity Toolkit letöltése
• Kövesse a hivatkozás teljesítményének tesztelésére vonatkozó utasításokat