VPN oturumlarını role göre ölçekleyin, ardından arıza payını kontrol edin

İkinci bir ağ geçidi eklersiniz, konsol iki sağlıklı üye gösterir ve oturum tavanı neredeyse hareket etmez, çünkü hiçbir şey istemcilere yeni kutuya nasıl ulaşacaklarını söylemedi. Bir VPN hizmetini ölçeklemek sırayla iki karardır: bu bağlantı türü için istemcileri hangi mekanizmanın dağıttığı ve en kötü tek kaybedişten sonra ne kadar kapasite kaldığı. Bunları ters sırayla alırsanız, gereksiz görünen ve tam ihtiyaç duyulduğunda bozulan bir tasarım elde edersiniz. Konsoldan başlayın, sonra aritmetiği yapın.

Mekanizmayı oturum türüyle eşleştirin

Uzak kullanıcılar, siteler arası eşler ve sürekli açık cihaz tünelleri birbirinin yerine geçebilen oturumlar değildir. Bunlardan biri için oluşturulmuş bir dağıtım özelliği normalde bir istemciyi görüşme sırasında yönlendirir; bu, zaten sabit bir adresi ve statik yapılandırması olan bir eş için hiçbir şey ifade etmez.

Cisco'nun ASA yüksek kullanılabilirlik kılavuzu üç yeteneği ayrı tutar: uzaktan erişim VPN yük dengelemesi, durum bilgili yük devretme ve siteler arası kümeleme. Yalnızca ilki uygun bir istemciyi grup girdisinden bir üyeye taşır ve LAN-LAN bağlantıları bu dağıtımın dışında kalır. Genel bir TCP yük dengeleyici protokolün kendi yönlendirme adımının yerini alamaz, çünkü tünel el sıkışması bir proxy'nin yeniden yazabileceği düz HTTP değildir. Pratik sonuç, bağlantıyı kabul eden ve yine de istemcinin tünel kuramamasına yol açan bir dengeleyicidir.

İkinci bir cihaz sipariş etmeden önce özellik listesini oturum türünüze göre okuyun. Lisans satırı ve mekanizma satırı ayrı girdilerdir ve biri diğerini gerektirmez.

Örneği tahmin etmek yerine hesaplayın

Diyelim ki üç ağ geçidi, onayladığınız iş yükü altında her biri 800 eşzamanlı tünel için doğrulanmış olsun; bu toplam 2,400 eder. Yoğun saat hedefi 1,650, bir birim kaybedilene kadar rahat görünür; sonra hayatta kalan çift, sert 1,600'e karşı 1,650 tutmak zorundadır. Tasarım zaten başarısız oldu ve hiçbir yük devretme ayarı aritmetiği onarmaz.

Hedefi, hayatta kalan küme hâlâ karşılayacak şekilde belirleyin; üç üyeli bir grup için bu, toplamın üçte ikisinin altında kalmak demektir. Bu oran aritmetiğin bir özelliğidir, herhangi bir ürünün değil; bu yüzden bir üyenin doğrulanan rakamı değiştiğinde yeniden hesaplayın. Lisanslı sayıyı, belgelenmiş üst sınırı ve kendi ölçtüğünüz rakamı üç sütunda tutun, çünkü nadiren anlaşırlar ve en küçük olan belirler. Gözlenen yoğun saat tepesi için dördüncü bir sütun, planı ilk aydan sonra dürüst tutar.

Yalnızca kararlı durumu değil, yeniden bağlanma dalgasını da bütçeleyin

Başarısız bir üye üzerindeki oturumlar sessizce başka bir yerde yeniden görünmez. Mekanizmaya bağlı olarak durumla devredilir, sıfırdan yeniden görüşür veya uygulamanın kendi takvimine göre yeniden denemesini bekler.

Bir dakika içinde yeniden deneyen birkaç bin istemci, istikrarlı bir 1,650'den farklı bir olaydır ve kimlik doğrulama sunucuları bunu ilk hisseder. Havuz alanını da kontrol edin, çünkü yönlendirme ona danışmaz: adres ayıramayan bir üye istemciyi yine kabul eder ve sonra trafiğini düşürür.

Kapasiteyi havuz ve rota elinizdeyken doğrulayın

Doğrulama, bir bakım penceresi açılmadan önce tasarım hatalarının çoğunu yakalayan salt okunur bir alıştırmadır. Üye başına havuzu, etkin oturum sayısını ve istemci alt ağına dönüş yolunu toplayın, sonra her birini planla karşılaştırın. Havuzun tükenmesi ve eksik bir dönüş yolu, ikisi de kimlik doğrulayan ve sonra trafiğini kaybeden bir istemci olarak görünür.

show vpn-sessiondb summary
show running-config ip local pool
show vpn load-balancing
show route 10.40.12.0 255.255.255.0

Bu okumaları her üye üzerinde sakin bir saatte değil, normal bir yoğun saatte çalıştırın. Oturum bildiren ama boş adresi olmayan bir üye, lisans ne derse desin, zaten pratik sınırındadır. Komut adları sürümler arasında değiştiği için her çıktının yanına firmware sürümünü not edin.

Kaybı bir kez bilerek, mesai saatleri dışında prova edin ve olurken hayatta kalan üyelerin ne bildirdiğini kaydedin. Yönlendirmeyi kabul eden ama havuz alanı olmayan bir üye başarısız ayırma olarak görünür; bunu ek bant genişliği asla düzeltmez. Doğrulanan rakamları tarihle birlikte planın yanında saklayın, böylece bir sonraki kapasite incelemesi bir lisans tablosundan değil kanıtlardan başlar. O provanın sonucunu, rakamlar planla uyuşsa bile aynı sayfaya ekleyin.