Paliwanag sa load ng VPN server: mga user, CPU o uplink?

Ang gateway na nasa 0.4 na load ay maaari pa ring gumapang para sa bawat user sa likod nito. Binibilang ng average na load ang mga task na maaaring patakbuhin o nakabaon sa hindi maputol na pagtulog, at sa host na may apat na core, sapat na ang isang puspos na proseso para itulak ito patungo sa 1.0 habang tatlong core ang nakaupo nang walang ginagawa. Ang basahin ang bilang na iyon bilang reserba ang pinakakaraniwang pagkakamali sa pagpili ng endpoint. Ang tunay na naglilimita sa isang tunnel ay karaniwang isa sa apat na bagay: isang abalang core, ang uplink, ang pila sa harap nito o isang patakaran bawat session na walang nagdokumento.

Binibilang ng average na load ang mga task, hindi ang throughput

Nagsa-sample ang kernel ng run queue at ng bilang ng mga task na naghihintay ng input at output, pagkatapos ay pinapantay ang dalawa sa loob ng isa, lima at labinlimang minuto. Wala sa kahulugang iyon ang tumutukoy sa bytes, packet o tunnel. Ang host na may stuck na storage ay makapag-uulat ng mataas na load na halos walang trapiko, at ang host na nagtutulak ng gigabit sa data path ng kernel ay makapag-uulat ng komportableng load.

Kaya ang pag-uugnay ng load sa performance ng tunnel ay nangangailangan ng pananaw bawat core. Kung puno ang isang core, magmumukha pa ring maayos ang pinagsamang porsyento sa dashboard:

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

Ang ikatlong command ang pinakamahalaga sa mga VPN host. Ang pagproseso ng packet sa user space sa OpenVPN 2.x ay halos naka-serial bawat proseso, kaya ang isang abalang thread ay maaaring maging kisame habang nag-uulat ang dashboard ng saganang bakanteng kapasidad. Kung hawak ng isang thread ang malaking bahagi ng isang core sa mabagal na panahon mo, hindi kulang ang host sa kabuuan; nalilimitahan ito sa dimensyong nagkataong mahalaga.

Pansinin din ang oras. Binabalot ng labinlimang minutong average ang pagsabog na sumira sa isang tawag, kaya ang screenshot na kinuha pagkatapos ng reklamo ay mahinang ebidensya. Kumuha ng sample habang may problema, at itago ang timestamp kasama ng output.

Ang uplink at ang pila sa harap nito

Sinasagot ng mga counter ng interface ang tanong sa bandwidth na hindi kayang sagutin ng mga numero ng CPU. Hinihiwalay din nila ang kapasidad sa pagkawala, at ito ay magkaibang mga failure na may magkaibang solusyon:

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

Ang link na malapit sa inilaan nitong bilis habang nagtetest ka ang paliwanag, at walang dami ng bakanteng CPU ang makakabago niyon. Ang linyang qdisc ay nagdaragdag ng detalyeng mahalaga sa interactive na trapiko: ang pagkaipon at pagpatak ay nagsasabi kung naghihintay ang mga packet sa pila bago umalis. Ang pila na napupuno sa ilalim ng malaking upload ay gumagawa ng eksaktong sintomas na ipinapataw ng mga tao sa malayong server, bukod dito ay ang mabagal na tawag sa isang koneksyon na mahusay pa rin sa benchmark.

Nahuhuli ng mga retransmission counter ang kaso kung saan umaalis ang mga packet pero hindi kailanman dumarating nang malinis. Kung tumataas ang retransmission sa mabagal na window at malayo pa ang interface sa kapasidad, nasa landas ang problema at hindi sa host, at ang paglipat sa ibang endpoint sa parehong lungsod ay hindi makakatulong.

Inilalarawan ng bilang ng session ang demand, hindi ang reserba

Bawat pampublikong direktoryo ay nagpapakita ng ilang bilang ng konektadong user, at halos wala sa kanila ang nagsasabi kung ano ang ginagawa ng mga user na iyon. Dalawampung session na gumagawa ng interactive na trabaho at apat na session na humihila ng malalaking file ay gumagawa ng napakakaibang load sa parehong hardware. Ang ikalawang pattern ay di-nakikita sa bilang ng user, at iyon ang sumisira sa isang gabi. Kaya ang bilang ng session ay pinakamainam basahin bilang pahiwatig tungkol sa demand, hindi kailanman bilang pahayag tungkol sa bakanteng kapasidad.

Sa host na kinokontrol mo, ibinibigay ng status file ang kulang na dimensyon. Ang OpenVPN ay nagsusulat ng pana-panahong snapshot na may kasamang byte counter bawat client, at sapat iyon para makita kung isang session ang responsable sa buong uplink:

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

Ang dalawang sample na sampung segundo ang layo ay ginagawang rate bawat client ang mga cumulative count na iyon. Iyon ang pagsukat na pinapalitan ng bilang ng user, at gayon din mo natutuklasan na ang isang maling naka-configure na client ay nagsasaturate ng link tuwing gabi sa parehong oras.

Nagtago sa patakaran ang mga limitasyon bawat session

Ang server ay maaaring walang ginagawa at tumanggi pa ring bigyan ka ng bandwidth. Ang mga limitasyon sa rate, kisame ng bandwidth bawat client at traffic shaping ay madalas na inilalapat bawat common name o bawat pool, kaya dalawang user sa parehong gateway ay makakakuha ng magkaibang resulta. Ang mekanismo ay hindi banayad, pero di-nakikita mula sa labas dahil normal na tumataas ang tunnel sa dalawang kaso.

Hanapin ang shaping sa interface ng tunnel at hindi sa pisikal. Tingnan kung sinusundan ng limitasyon ang user, ang certificate o ang pool ng address. Kung mapunta sa pool na walang kisame ang test account mo, maghihinuha ka na maayos ang server at mali ang nagrereklamong user. Ang gayong konklusyon ay mas masama kaysa walang konklusyon, dahil isinasara nito ang ticket.

Paghambingin ang dalawang endpoint sa isang takdang gawain

Ang eksperimento sa panig ng client ay sulit pa ring gawin, pero kung nakapirming ang mga variable. Gamitin ang parehong device, parehong access network, parehong protocol at parehong destinasyong file, pagkatapos ay ulitin laban sa ikalawang endpoint sa katulad na layo. Anumang nagbabago sa pagitan ng mga run, kasama na ang oras ng araw, ay nagdudumi sa resulta.

Itala ang mga pagkabigo nang kasing-ingat ng mga tagumpay. Ang serye kung saan tatlong endpoint ang gumagana at isa ang nag-timeout ay mas nagbibigay-kaalaman kaysa apat na bilang ng bilis, dahil itinuturo nito ang problema sa landas o patakaran at hindi sa kapasidad. Patakbuhin ang bawat kaso nang hindi bababa sa dalawang beses; ang isang mabagal na sample ay walang pinapatunayan sa isang pinagsasaluhang network.

Sa huli, itago ang mga bilang na nakalap mo kasama ng pahayag na sinusuportahan nila. Ang "Tinapos ng endpoint na ito ang paglilipat sa parehong window kung saan natigil ang isa" ay maipagtatanggol, samantalang ang "mas mabilis ang endpoint na ito" ay nag-aanyaya ng pagtatalo na hindi mo kayang panaluhin sa isang score sa homepage. Dokumentado ng manwal ng OpenVPN 2.6 ang status file at ang mga opsyon sa shaping kung kailangan mo ang eksaktong direktiba para sa panig ng host.