Failover testi: kurulmuş bir TCP akışı hayatta kalır mı?

«Yedek çalışıyor» cümlesinin içinde iki sonuç saklıdır. Yeni bir istek başarılı olur, bu kurtarmadır. Zaten sürmekte olan bir aktarım devam eder, bu sürekliliktir. Bunlar farklı vaatlerdir ve çoğu failover tasarımı ilkini verirken ikincisi sessizce zaman aşımına uğrar. Bir mekanizma seçmeden önce hangisine ihtiyacınız olduğuna karar verin ve testi ikisini ayırt edebilecek şekilde yazın.

Tek bir başarı gibi görünen iki sonuç

10.90.0.42 adresindeki bir istemcinin 198.51.100.20:443 adresine bağlantısı olduğunu düşünün. Birincil çıkış bunu bir genel adres ve bağlantı noktasına çevirir, yedek çıkış ise başka birine. İstemcinin iç adresi hiç değişmez, bu yüzden insanlar bağlantının hayatta kalmasını bekler.

Sunucu iç adresi görmez. Çevrilmiş uç noktayı görür ve bu uç nokta geçişten sonra farklıdır.

Böylece eski akış zaman aşımına uğrarken aynı hizmete yeni bağlantı hemen çalışır. İki gözlem de aynı anda doğrudur.

Çıkış değiştiğinde sunucu ne görür

Bir TCP bağlantısı dörtlüsüyle tanımlanır ve kaynak adresin veya bağlantı noktasının değişmesi, alan ana bilgisayar açısından başka bir bağlantı oluşturur. Sunucunun tanımadığı bir bağlantıda yeni kaynaktan gelen paketler atılır veya sıfırlama ile yanıtlanır. VPN istemcisinin adresinde bu değişiklik boyunca ilişkiyi koruyan hiçbir şey yoktur.

Durumlu failover tam da bundan kaçınmak için vardır ve iletme cihazları arasında çeviri durumu ile bağlantı durumunu değiş tokuş ederek çalışır. Bu, tünelin değil çiftin özelliğidir ve varsayılmak yerine tasarlanmalı ve test edilmelidir.

Birine süreklilik vaat etmeden önce çiftin gerçekten durum tutup tutmadığını kontrol edin. Aşağıdaki komutlar iki taraftaki güncel durumu gösterir.

conntrack -L -d 198.51.100.20 2>/dev/null | head
ss -tin dst 198.51.100.20
tcpdump -ni any host 198.51.100.20 -c 10

Aynı genel adres neden yeterli değil

Her iki yolda tek bir genel adres tutmak iyi bir başlangıçtır, çünkü sunucu o zaman aynı kaynak uç noktayı görür. Ancak tek başına yeterli değildir. İletme cihazı hâlâ çeviri durumuna, güvenlik duvarı durumuna ve kullanılabilir bir dönüş yoluna ihtiyaç duyar ve bunlar geçişten sonra trafiği taşıyan cihazda bulunmalıdır.

RFC 3022 adres çevirisini açıklar ve çeviri yapan cihazlar arasındaki durum alışverişini yedek tasarımın parçası olarak ele alır. Yüzen bir adres veya kopyalanmış profil yapılandırmayı taşır ama durumu taşımaz.

Bu yüzden yalnızca yedek üzerinden ping atan bir test çok az şey kanıtlar. Pingin kaybedecek bağlantı durumu yoktur.

Gereksinimin ne kadar güçlü olduğuna karar verin

Kullanıcılar bir arızdan sonra yeniden bağlanabiliyorsa tasarım bir kurtarma tasarımıdır ve kabul testi yeni bir istektir. Bir dosya aktarımı hayatta kalmalıysa tasarım durum eşitlemesine ve çok daha dikkatli bir teste ihtiyaç duyar. Uzak bir oturum hayatta kalmalıysa gereksinim daha da güçlüdür ve ağ düzeyi yerine uygulama düzeyinde bir mekanizma gerekebilir.

Gereksinimi ölçülebilir sonucu olan bir cümle olarak yazın, örneğin yükleme yeniden başlamadan tamamlanır veya operatör bir dakika içinde yeniden bağlanır. Sonra bunu karşılayan en ucuz mekanizmayı seçin ve bu çoğu zaman kurtarma tasarımıdır.

Birincil yol geri geldiğinde ne olacağını açıkça söyleyin, çünkü otomatik geri dönüş yedekte tam yeni toparlanmış bir bağlantıyı kesebilir. Bu durum test planına aittir, dipnota değil.

Eski akışı ve yeni isteği kontrol edin

Birincil yol üzerinden zararsız uzun bir aktarım başlatın, ardından aynı hizmete ayrı bir yeni istek gönderin. Uygulama bağlamını, gözlenen çıkış adresini ve saati kaydedin. Birincili onaylanmış bir şekilde koparın ve yeni isteği yedek üzerinden gönderirken özgün aktarımı izlemeye devam edin.

Üç değer bildirin: eski akış sürdü mü, sıfırlandı mı yoksa zaman aşımına mı uğradı; yeni işlem ilk kez ne zaman çalıştı; ve geri dönüş bir şeyi kesti mi. O üç satır kabul kaydıdır.

ss -tin dst 198.51.100.20
curl -sS -o /dev/null -w '%{http_code} %{time_total}\n' https://198.51.100.20/
tcpdump -ni any port 443 -c 20

İş yükü veri yazıyorsa, zaman aşımından sonra belirsiz bir işlemi körü körüne yinelemeyin. Yazma, yanıt kaybolmadan önce ulaşmış olabilir. Sonucu uygulamaya sorun veya yalnızca işlemin idempotent olduğu yerde yeniden deneyin. Ardından kabul beyanını üç bölümde yazın: yeni işlemler çıkış politikası altında kurtarılır, mevcut akışlar belgelenmiş kesinti davranışına sahiptir ve uygulama güvenle devam eder. Bu beyan test edilebilir ve tasarımın neyi vaat etmediği konusunda dürüsttür.