VPN sunucu yükü açıklandı: kullanıcılar, CPU yoksa yukarı bağlantı mı?

0.4 yükte duran bir ağ geçidi, arkasındaki her kullanıcı için hâlâ sürünebilir. Ortalama yük, çalıştırılabilir durumdaki ya da kesintisiz uykuda takılı kalmış görevleri sayar ve dört çekirdekli bir sunucuda tek bir doymuş süreç, üç çekirdek boşta otururken onu 1.0'a doğru itmeye yeter. Bu sayıyı yedek olarak okumak, uç nokta seçimindeki en yaygın hatadır. Bir tüneli gerçekte sınırlayan şey genellikle dört şeyden biridir: meşgul bir çekirdek, yukarı bağlantı, önündeki kuyruk ya da kimsenin belgelemediği bir oturum başına ilke.

Ortalama yük görevleri sayar, iş hacmini değil

Çekirdek, çalıştırma kuyruğunu ve giriş-çıkış bekleyen görev sayısını örnekler, sonra ikisini de bir, beş ve on beş dakika boyunca düzler. Bu tanımda bayt, paket ya da tünelden söz edilmez. Depolaması tıkanmış bir sunucu neredeyse hiç trafik olmadan yüksek yük bildirebilir, çekirdeğin veri yolundan gigabit geçiren bir sunucu ise rahat bir yük bildirebilir.

Bu yüzden yükü tünel performansıyla ilişkilendirmek çekirdek başına bir bakış gerektirir. Bir çekirdek tamamen doluysa, panodaki toplam yüzde yine de iyi görünecektir:

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

Üçüncü komut VPN sunucularında en çok önem taşıyanıdır. OpenVPN 2.x'te kullanıcı alanındaki paket işleme büyük ölçüde süreç başına sıralıdır, bu yüzden tek bir meşgul iş parçacığı tavan hâline gelebilirken pano bol miktarda boş kapasite bildirir. Yavaş döneminizde bir iş parçacığı bir çekirdeğin çoğunu tutuyorsa, sunucu bir bütün olarak yetersiz donatılmış değildir; tam da önemli olan boyutta sınırlanmıştır.

Zamanlamaya da dikkat edin. On beş dakikalık ortalamalar, bir görüşmeyi mahveden patlamayı gizler, bu yüzden şikâyetten sonra alınan ekran görüntüsü zayıf bir kanıttır. Sorun sürerken örnek alın ve zaman damgasını çıktıyla birlikte saklayın.

Yukarı bağlantı ve önündeki kuyruk

Arabirim sayaçları, CPU sayılarının yanıtlayamadığı bant genişliği sorusunu yanıtlar. Kapasiteyi kayıptan da ayırırlar ve bunlar farklı düzeltmeleri olan farklı arızalardır:

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

Testiniz sırasında kendisine ayrılan hıza yakın bir bağlantı, açıklamanın kendisidir ve hiçbir boş CPU miktarı bunu değiştirmez. qdisc satırı, etkileşimli trafik için önemli ayrıntıyı ekler: birikim ve düşmeler, paketlerin çıkmadan önce kuyrukta bekleyip beklemediğini söyler. Büyük bir yükleme altında dolan bir kuyruk, insanların uzak sunucuya yüklediği belirtiyi, yani ölçümlerde hâlâ iyi görünen bir bağlantıda ağır görüşmeleri, tam olarak üretir.

Yeniden iletim sayaçları, paketlerin çıkıp hiçbir zaman temiz ulaşmadığı durumu yakalar. Yavaş pencerede yeniden iletimler artıyorsa ve arabirim kapasiteye yakın değilse, sorun sunucuda değil yoldadır ve aynı şehirdeki başka bir uç noktaya geçmek yardımcı olmaz.

Oturum sayısı talebi anlatır, yedeği değil

Her genel dizin bir miktar bağlı kullanıcı gösterir ve neredeyse hiçbiri bu kullanıcıların ne yaptığını söylemez. Etkileşimli iş yapan yirmi oturum ile büyük dosyalar çeken dört oturum, aynı donanımda çok farklı yükler üretir. İkinci örüntü kullanıcı sayısında görünmez ve bir akşamı mahveden tam da odur. Bu yüzden oturum sayısı en iyi talebe dair bir ipucu olarak okunur, asla boş kapasite hakkında bir beyan olarak değil.

Denetlediğiniz bir sunucuda durum dosyası eksik boyutu verir. OpenVPN her istemci için bayt sayaçlarını içeren düzenli anlık görüntüler yazar ve tek bir oturumun tüm yukarı bağlantıdan sorumlu olup olmadığını görmek için bu yeterlidir:

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

On saniye arayla alınan iki örnek, bu birikimli sayımları istemci başına hıza dönüştürür. Kullanıcı sayısının yerine geçen ölçüm budur ve yanlış yapılandırılmış tek bir istemcinin her gece aynı saatte bağlantıyı doyurduğunu da böyle keşfedersiniz.

Oturum başına sınırlar ilkenin içinde saklıdır

Sunucu boşta olabilir ve yine de size bant genişliği vermeyi reddedebilir. Hız sınırları, istemci başına bant genişliği tavanları ve trafik şekillendirme çoğu zaman ortak ada ya da havuza göre uygulanır, bu yüzden aynı ağ geçidindeki iki kullanıcı çok farklı sonuçlar alabilir. Mekanizma ince değildir, ama tünel her iki durumda da normal biçimde kalktığı için dışarıdan görünmez.

Şekillendirmeyi fiziksel arabirimde değil tünel arabiriminde arayın. Sınırın kullanıcıyı, sertifikayı yoksa adres havuzunu izlediğini kontrol edin. Test hesabınız tavansız havuza düşerse sunucunun iyi olduğu ve şikâyet eden kullanıcının yanıldığı sonucuna varırsınız. Bu sonuç hiç sonuç olmamasından daha kötüdür, çünkü kaydı kapatır.

İki uç noktayı tek bir sabit görevle karşılaştırın

İstemci tarafındaki deney hâlâ yapmaya değer, ama yalnızca değişkenler sabitlendiğinde. Aynı aygıtı, aynı erişim ağını, aynı protokolü ve aynı hedef dosyayı kullanın, sonra benzer mesafedeki ikinci bir uç noktaya karşı yineleyin. Koşular arasında değişen her şey, günün saati dâhil, sonucu kirletir.

Başarısızlıkları başarılar kadar dikkatle kaydedin. Üç uç noktanın çalıştığı ve birinin zaman aşımına uğradığı bir dizi, dört hız sayısından daha bilgilendiricidir, çünkü kapasiteye değil yol ya da ilke sorununa işaret eder. Her durumu en az iki kez çalıştırın; paylaşılan bir ağda tek bir yavaş örnek hiçbir şey kanıtlamaz.

Son olarak, topladığınız sayıları destekledikleri iddiayla birlikte saklayın. "Bu uç nokta aktarımı diğerinin takıldığı aynı pencerede tamamladı" savunulabilir, oysa "bu uç nokta daha hızlı" ana sayfa puanıyla kazanamayacağınız bir tartışmaya davet çıkarır. OpenVPN 2.6 kılavuzu sunucu tarafı için tam yönergelere ihtiyacınız varsa durum dosyasını ve şekillendirme seçeneklerini belgeler.