VPN-szerver terhelése magyarázva: felhasználók, CPU vagy feltöltő sáv?

Egy 0.4 terhelésen álló átjáró még mindig vánszoroghat minden mögötte lévő felhasználónak. Az átlagos terhelés azokat a feladatokat számolja, amelyek futtathatók vagy megszakíthatatlan alvásban ragadtak, és egy négymagos gazdagépen egyetlen telített folyamat is elég ahhoz, hogy 1.0 felé tolja, miközben három mag tétlenül ül. Ezt a számot tartalékként olvasni a leggyakoribb hiba a végpont kiválasztásakor. Amit egy alagutat valójában korlátoz, az általában négy dolog egyike: egy elfoglalt mag, a feltöltő sáv, az előtte álló sor vagy egy munkamenetenkénti házirend, amelyet senki nem dokumentált.

Az átlagos terhelés feladatokat számol, nem áteresztőképességet

A kernel mintát vesz a futtatási sorból és a bemenetre-kimenetre váró feladatok számából, majd mindkettőt kisimítja egy, öt és tizenöt perc alatt. Semmi ebben a meghatározásban nem említ bájtokat, csomagokat vagy alagutakat. Egy elakadt tárolású gazdagép magas terhelést jelenthet szinte forgalom nélkül, és egy gazdagép, amely egy gigabitet továbbít a kernel adatútvonalán, kényelmes terhelést jelenthet.

A terhelés és az alagút teljesítményének összekapcsolása ezért magonkénti nézetet igényel. Ha egy mag teljesen le van terhelve, az irányítópult összesített százaléka még mindig jól fog kinézni:

cat /proc/loadavg
mpstat -P ALL 1 1
top -H -b -n 1 | head -n 20

A harmadik parancs az, amely a legtöbbet számít VPN-gazdagépeken. A felhasználói térben végzett csomagfeldolgozás az OpenVPN 2.x-ben nagyrészt folyamatonként sorosított, így egyetlen elfoglalt szál lehet a plafon, miközben az irányítópult bőséges szabad kapacitást jelent. Ha egy szál a lassú időszakban egy mag nagy részét lefoglalja, a gazdagép összességében nincs alulméretezve; abban a dimenzióban korlátozott, amely éppen számít.

Figyeljen az időzítésre is. A tizenöt perces átlagok elrejtik azt a rohamot, amely tönkretett egy hívást, ezért a panasz után készült képernyőkép gyenge bizonyíték. A probléma alatt vegyen mintákat, és őrizze meg az időbélyeget a kimenettel együtt.

A feltöltő sáv és az előtte álló sor

Az interfész-számlálók megválaszolják a sávszélesség kérdését, amelyre a CPU-számok nem képesek. Elválasztják a kapacitást a veszteségtől is, amelyek különböző meghibásodások különböző javításokkal:

ip -s link show dev eth0
tc -s qdisc show dev eth0
nstat -az TcpRetransSegs TcpExtTCPLostRetransmit

Az a kapcsolat, amely a teszt alatt közel van a kiosztott sebességéhez, a magyarázat, és semmilyen mennyiségű szabad CPU nem változtat rajta. A qdisc sor hozzáadja azt a részletet, amely az interaktív forgalom szempontjából számít: a felhalmozódás és a veszteségek megmondják, várnak-e a csomagok sorban, mielőtt elindulnak. Az a sor, amely egy nagy feltöltés alatt megtelik, pontosan azt a tünetet kelti, amelyet az emberek a távoli szerverre fognak, vagyis lassú hívásokat egy kapcsolaton, amely a mérésekben még mindig jól szerepel.

Az újraküldési számlálók elkapják azt az esetet, amikor a csomagok elindulnak, de soha nem érkeznek meg tisztán. Ha az újraküldések a lassú időablakban nőnek, és az interfész messze van a kapacitásától, a probléma az útvonalban van, nem a gazdagépen, és nem segít, ha ugyanabban a városban másik végpontra vált.

A munkamenetek száma a keresletet írja le, nem a tartalékot

Minden nyilvános könyvtár mutat valamennyi csatlakozott felhasználót, és szinte egyik sem árulja el, mit csinálnak ezek a felhasználók. Húsz interaktív munkát végző munkamenet és négy nagy fájlt letöltő munkamenet nagyon különböző terhelést okoz ugyanazon a hardveren. A második minta láthatatlan a felhasználók számában, és éppen ez teszi tönkre az estét. Ezért a munkamenetek számát a legjobb a keresletre utaló jelzésként olvasni, soha nem a szabad kapacitásról szóló állításként.

Az Ön által vezérelt gazdagépen az állapotfájl adja a hiányzó dimenziót. Az OpenVPN rendszeres pillanatképet ír, amely kliensenkénti bájtszámlálókat tartalmaz, és ez elég ahhoz, hogy lássa, egy munkamenet felelős-e a teljes feltöltő sávért:

status /run/openvpn/server.status 10
# then, after at least one interval
grep -E "^CLIENT_LIST" /run/openvpn/server.status

Két minta tíz másodperc különbséggel ügyfélenkénti sebességgé alakítja azokat a halmozott számlálókat. Ez az a mérés, amelynek helyét a felhasználók száma átveszi, és így fedezheti fel, hogy egyetlen rosszul beállított kliens minden éjjel ugyanabban az órában telíti a kapcsolatot.

A munkamenetenkénti korlátok a házirendben rejtőznek

Egy szerver lehet tétlen, és mégis megtagadhatja a sávszélességet. A sebességkorlátok, a kliensenkénti sávszélesség-plafonok és a forgalomformálás gyakran közös név vagy készlet szerint érvényesülnek, így két felhasználó ugyanazon az átjárón nagyon különböző eredményeket kaphat. A mechanizmus nem finom, de kívülről láthatatlan, mert az alagút mindkét esetben normálisan felépül.

A formálást az alagút interfészén keresse, ne a fizikain. Ellenőrizze, hogy a korlát a felhasználót, a tanúsítványt vagy a címkészletet követi-e. Ha a tesztfiókja a korlát nélküli készletbe kerül, arra a következtetésre jut, hogy a szerver rendben van, és a panaszos felhasználó téved. Ez a következtetés rosszabb a semminél, mert lezárja a jegyet.

Hasonlítson össze két végpontot egyetlen rögzített feladattal

Az ügyféloldali kísérletet még mindig érdemes lefuttatni, de csak akkor, ha a változók rögzítettek. Használja ugyanazt az eszközt, ugyanazt a hozzáférési hálózatot, ugyanazt a protokollt és ugyanazt a célfájlt, majd ismételje meg egy második, hasonló távolságú végponttal szemben. Bármi, ami a futások között változik, beleértve a napszakot, beszennyezi az eredményt.

A kudarcokat ugyanolyan gondosan jegyezze fel, mint a sikereket. Az a sorozat, amelyben három végpont működik és egy időtúllépésbe fut, informatívabb négy sebességszámnál, mert útvonal- vagy házirendproblémára utal, nem kapacitásra. Minden esetet futtasson legalább kétszer; egyetlen lassú minta semmit sem bizonyít megosztott hálózaton.

Végül tartsa a gyűjtött számokat azzal az állítással együtt, amelyet alátámasztanak. "Ez a végpont ugyanabban az ablakban bonyolította le az átvitelt, amelyben a másik elakadt" védhető, míg "ez a végpont gyorsabb" olyan vitát hív elő, amelyet nyitólapi pontszámmal nem lehet megnyerni. Az OpenVPN 2.6 kézikönyv dokumentálja az állapotfájlt és a formálási lehetőségeket, ha a gazdagép oldalához pontos irányelvekre van szüksége.