VPN server yükü izahı: istifadəçilər, CPU, yoxsa yuxarı kanal?

0.4 yükdə dayanan bir şlüz arxasındakı hər istifadəçi üçün yenə də sürünə bilər. Orta yük icra edilə bilən və ya kəsilməz yuxuda ilişib qalan tapşırıqları sayır və dörd nüvəli hostda tək bir doymuş proses onu 1.0-a doğru itələməyə kifayət edir, halbuki üç nüvə boş oturur. Bu rəqəmi ehtiyat kimi oxumaq son nöqtə seçimində ən geniş yayılmış səhvdir. Tuneli əslində məhdudlaşdıran adətən dörd şeydən biridir: bir məşğul nüvə, yuxarı kanal, onun qarşısındakı növbə və ya heç kimin sənədləşdirmədiyi sessiya siyasəti.

Orta yük tapşırıqları sayır, ötürmə qabiliyyətini yox

Nüvə icra növbəsindən və giriş-çıxış gözləyən tapşırıqların sayından nümunə götürür, sonra hər ikisini bir, beş və on beş dəqiqə ərzində hamarlayır. Bu tərifdə bayt, paket və ya tunel qeyd olunmur. Yaddaşı ilişib qalmış host demək olar ki, trafik olmadan yüksək yük göstərə bilər, nüvə məlumat yolundan gigabit keçirən host isə rahat bir göstərici verə bilər.

Buna görə yükü tunel məhsuldarlığı ilə əlaqələndirmək üçün nüvə üzrə baxış lazımdır. Bir nüvə tam yüklənibsə, paneldəki ümumi faiz yenə də yaxşı görünəcək:

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

Üçüncü əmr VPN hostlarında ən çox əhəmiyyət kəsb edəndir. OpenVPN 2.x-də istifadəçi məkanında paket emalı əsasən hər proses üzrə ardıcıldır, ona görə də tək məşğul bir axın tavan ola bilər, halbuki panel bol boş güc bildirir. Yavaş dövrünüzdə bir axın nüvənin böyük hissəsini tutursa, host ümumilikdə az təchiz olunmayıb; o, sadəcə əhəmiyyətli olan ölçüdə məhdudlaşıb.

Vaxta da diqqət yetirin. On beş dəqiqəlik ortalamalar zəngi korlayan partlayışı gizlədir, ona görə şikayətdən sonra çəkilmiş ekran görüntüsü zəif sübutdur. Problemin özü zamanı nümunə götürün və vaxt möhürünü çıxışla birlikdə saxlayın.

Yuxarı kanal və onun qarşısındakı növbə

İnterfeys sayğacları CPU rəqəmlərinin cavab verə bilmədiyi bant genişliyi sualına cavab verir. Onlar həmçinin tutumu itkidən ayırır, bunlar isə fərqli həlləri olan fərqli nasazlıqlardır:

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

Testiniz zamanı ayrılmış sürətinə yaxın olan bir link izahatdır və heç bir boş CPU bunu dəyişmir. qdisc sətri interaktiv trafik üçün vacib detalı əlavə edir: yığım və itkilər paketlərin yola düşməzdən əvvəl növbədə gözlədiyini göstərir. Kütləvi yükləmə altında dolan növbə məhz insanların uzaq serveri günahlandırdığı simptomu yaradır: benchmarkda hələ də yaxşı görünən bağlantıda ləng zənglər.

Yenidən ötürmə sayğacları paketlərin çıxıb tam çatmadığı halı tutur. Yavaş pəncərədə yenidən ötürmələr artırsa və interfeys tutumdan uzaqdırsa, problem hostda deyil, yoldadır və eyni şəhərdə başqa son nöqtəyə keçmək kömək etməyəcək.

Sessiya sayları tələbi təsvir edir, ehtiyatı yox

Hər ictimai kataloq müəyyən sayda qoşulmuş istifadəçi göstərir və onların demək olar heç biri bu istifadəçilərin nə etdiyini demir. İnteraktiv iş görən iyirmi sessiya və böyük fayllar çəkən dörd sessiya eyni avadanlıqda çox fərqli yüklər yaradır. İkinci model istifadəçi sayında görünmür və məhz o, axşamı korlayır. Buna görə sessiya rəqəmi ən yaxşı halda tələbə işarə kimi oxunur, heç vaxt boş tutum barədə bəyanat kimi yox.

Nəzarət etdiyiniz hostda status faylı çatışmayan ölçünü verir. OpenVPN hər müştəri üzrə bayt sayğaclarını əhatə edən dövri görüntü yazır və bu, bir sessiyanın bütün yuxarı kanala cavabdeh olub-olmadığını görmək üçün kifayətdir:

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

On saniyə ara ilə iki nümunə bu yığılmış sayğacları müştəri üzrə sürətə çevirir. Bu, istifadəçi sayının əvəz etdiyi ölçüdür və həm də səhv konfiqurasiya edilmiş bir müştərinin hər gecə eyni saatda linki doyurduğunu belə kəşf edirsiniz.

Sessiya limitləri siyasətin içində gizlənir

Server boş dayana və yenə də sizə bant genişliyi verməkdən imtina edə bilər. Sürət limitləri, müştəri üzrə bant genişliyi tavanları və trafik şəkilləndirməsi çox vaxt ümumi ad və ya hovuz üzrə tətbiq olunur, ona görə eyni şlüzdə iki istifadəçi tamamilə fərqli nəticələr ala bilər. Mexanizm incə deyil, amma kənardan görünmür, çünki tunel hər iki halda normal qalxır.

Şəkilləndirməni fiziki interfeysdə deyil, tunel interfeysində axtarın. Limitin istifadəçini, sertifikatı yoxsa ünvan hovuzunu izlədiyini yoxlayın. Test hesabınız limitsiz hovuza düşərsə, serverin qaydasında olduğu və şikayət edən istifadəçinin səhv etdiyi qənaətinə gələcəksiniz. Bu qənaət heç bir qənaətdən pisdir, çünki bileti bağlayır.

İki son nöqtəni tək sabit tapşırıqla müqayisə edin

Müştəri tərəfindəki təcrübə hələ də aparmağa dəyər, ancaq dəyişənlər sabitlənsə. Eyni cihazı, eyni giriş şəbəkəsini, eyni protokolu və eyni hədəf faylı istifadə edin, sonra oxşar məsafədə ikinci son nöqtəyə qarşı təkrarlayın. Gedişlər arasında dəyişən hər şey, o cümlədən günün vaxtı, nəticəni çirkləndirir.

Uğursuzluqları uğurlar qədər diqqətlə qeyd edin. Üç son nöqtənin işlədiyi və birinin vaxt aşımına uğradığı sıra dörd sürət rəqəmindən daha məlumatlıdır, çünki tutum deyil, yol və ya siyasət probleminə işarə edir. Hər halı ən azı iki dəfə işə salın; paylaşılan şəbəkədə tək yavaş nümunə heç nə sübut etmir.

Nəhayət, topladığınız rəqəmləri dəstəklədikləri iddia ilə birlikdə saxlayın. "Bu son nöqtə köçürməni digərinin ilişdiyi eyni pəncərədə yerinə yetirdi" müdafiə oluna bilər, halbuki "bu son nöqtə daha sürətlidir" ana səhifə balı ilə qazana bilməyəcəyiniz mübahisəyə dəvət edir. OpenVPN 2.6 təlimatı host tərəfi üçün dəqiq direktivlər lazımdırsa, status faylını və şəkilləndirmə seçimlərini sənədləşdirir.