Beban server VPN dijelaskan: pengguna, CPU, atau uplink?

Gateway dengan beban 0.4 masih bisa merangkak bagi setiap pengguna di belakangnya. Rata-rata beban menghitung tugas yang dapat dijalankan atau yang macet dalam tidur tak terputus, dan pada host empat inti satu proses jenuh sudah cukup untuk mendorongnya ke arah 1.0 sementara tiga inti duduk menganggur. Membaca angka itu sebagai cadangan adalah kesalahan paling umum dalam memilih titik akhir. Yang sebenarnya membatasi terowongan biasanya salah satu dari empat hal: satu inti sibuk, uplink, antrean di depannya, atau kebijakan per sesi yang tidak didokumentasikan siapa pun.

Rata-rata beban menghitung tugas, bukan throughput

Kernel mengambil sampel antrean eksekusi dan jumlah tugas yang menunggu input dan output, lalu menghaluskan keduanya selama satu, lima, dan lima belas menit. Tidak ada dalam definisi itu yang menyebut byte, paket, atau terowongan. Host yang penyimpanannya macet bisa melaporkan beban tinggi dengan hampir tanpa lalu lintas, dan host yang mendorong satu gigabit melalui jalur data kernel bisa melaporkan beban yang nyaman.

Karena itu, mengorelasikan beban dengan kinerja terowongan memerlukan pandangan per inti. Jika satu inti penuh, persentase agregat di dasbor akan tetap terlihat baik:

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

Perintah ketiga adalah yang paling penting pada host VPN. Pemrosesan paket di ruang pengguna pada OpenVPN 2.x sebagian besar diserialkan per proses, sehingga satu utas yang sibuk bisa menjadi batas atas sementara dasbor melaporkan kapasitas menganggur yang melimpah. Jika satu utas menahan sebagian besar inti selama periode lambat Anda, host tidak kekurangan sumber daya secara keseluruhan; host dibatasi pada dimensi yang kebetulan penting.

Perhatikan waktunya juga. Rata-rata lima belas menit menyembunyikan ledakan yang merusak panggilan, jadi tangkapan layar yang diambil setelah keluhan adalah bukti lemah. Ambil sampel selama masalah dan simpan stempel waktu bersama keluaran.

Uplink dan antrean di depannya

Penghitung antarmuka menjawab pertanyaan bandwidth yang tidak bisa dijawab angka CPU. Penghitung itu juga memisahkan kapasitas dari kehilangan, yang merupakan kegagalan berbeda dengan perbaikan berbeda:

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

Tautan yang mendekati laju yang dialokasikan selama pengujian Anda adalah penjelasannya, dan tidak ada jumlah CPU sisa yang mengubahnya. Baris qdisc menambahkan perincian yang penting bagi lalu lintas interaktif: tumpukan dan penurunan memberi tahu apakah paket menunggu dalam antrean sebelum keluar. Antrean yang terisi di bawah unggahan besar menghasilkan persis gejala yang disalahkan orang pada server jarak jauh, panggilan lambat pada koneksi yang masih bagus dalam tolok ukur.

Penghitung retransmisi menangkap kasus ketika paket keluar tetapi tidak pernah tiba dengan bersih. Jika retransmisi naik selama jendela lambat dan antarmuka jauh dari kapasitas, masalahnya ada di jalur, bukan di host, dan pindah ke titik akhir lain di kota yang sama tidak akan membantu.

Jumlah sesi menggambarkan permintaan, bukan cadangan

Setiap direktori publik menampilkan sejumlah pengguna terhubung, dan hampir tidak ada yang memberi tahu Anda apa yang dilakukan pengguna itu. Dua puluh sesi yang melakukan pekerjaan interaktif dan empat sesi yang menarik file besar menghasilkan beban yang sangat berbeda pada perangkat keras yang sama. Pola kedua tak terlihat dalam jumlah pengguna, dan itulah yang merusak malam. Jadi angka sesi paling baik dibaca sebagai petunjuk permintaan, tidak pernah sebagai pernyataan tentang kapasitas sisa.

Pada host yang Anda kendalikan, file status memberikan dimensi yang hilang. OpenVPN menulis cuplikan berkala yang mencakup penghitung byte per klien, dan itu cukup untuk melihat apakah satu sesi bertanggung jawab atas seluruh uplink:

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

Dua sampel berjarak sepuluh detik mengubah penghitung kumulatif itu menjadi laju per klien. Itulah pengukuran yang digantikan oleh jumlah pengguna, dan dengan cara itulah Anda menemukan bahwa satu klien yang salah dikonfigurasi menjenuhkan tautan setiap malam pada jam yang sama.

Batas per sesi bersembunyi di dalam kebijakan

Server bisa menganggur dan tetap menolak memberi Anda bandwidth. Batas laju, plafon bandwidth per klien, dan pembentukan lalu lintas sering diterapkan per nama umum atau per kumpulan, sehingga dua pengguna pada gateway yang sama bisa mendapatkan hasil yang sangat berbeda. Mekanismenya tidak halus, tetapi tak terlihat dari luar karena terowongan naik normal dalam kedua kasus.

Cari pembentukan pada antarmuka terowongan, bukan pada antarmuka fisik. Periksa apakah batas mengikuti pengguna, sertifikat, atau kumpulan alamat. Jika akun uji Anda jatuh ke kumpulan tanpa batas, Anda akan menyimpulkan bahwa server baik-baik saja dan pengguna yang mengeluh salah. Kesimpulan itu lebih buruk daripada tidak ada kesimpulan, karena menutup tiket.

Bandingkan dua titik akhir dengan satu tugas tetap

Eksperimen di sisi klien masih layak dijalankan, tetapi hanya jika variabelnya dipatok. Gunakan perangkat yang sama, jaringan akses yang sama, protokol yang sama, dan file tujuan yang sama, lalu ulangi terhadap titik akhir kedua pada jarak serupa. Apa pun yang berubah antar-eksekusi, termasuk waktu dalam hari, mencemari hasilnya.

Catat kegagalan seceroboh mencatat keberhasilan. Rangkaian di mana tiga titik akhir berfungsi dan satu habis waktu lebih informatif daripada empat angka kecepatan, karena menunjuk masalah jalur atau kebijakan, bukan kapasitas. Jalankan setiap kasus setidaknya dua kali; satu sampel lambat tidak membuktikan apa pun di jaringan bersama.

Terakhir, simpan angka yang Anda kumpulkan bersama klaim yang didukungnya. "Titik akhir ini menyelesaikan transfer pada jendela yang sama ketika yang lain macet" bisa dipertahankan, sedangkan "titik akhir ini lebih cepat" mengundang perdebatan yang tidak bisa Anda menangkan dengan skor halaman depan. Manual OpenVPN 2.6 mendokumentasikan file status dan opsi pembentukan jika Anda membutuhkan direktif tepat untuk sisi host.