Failover testi: mövcud TCP axını sağ qalırmı?

Ehtiyatın işlədiyi cümləsinin içində iki nəticə gizlənir. Yeni sorğu uğur qazanır — bu bərpadır. Artıq davam edən ötürmə davam edir — bu davamlılıqdır. Bunlar fərqli vədlərdir və əksər failover dizaynları birincisini verir, ikincisi isə səssizcə vaxt aşımına düşür. Mexanizm seçməzdən əvvəl hansına ehtiyacınız olduğunu qərar verin və testi elə yazın ki, onları ayıra bilsin.

Bir uğur kimi görünən iki nəticə

Təsəvvür edin ki, 10.90.0.42 ünvanındakı müştərinin 198.51.100.20:443 ünvanına bağlantısı var. Əsas çıxış bunu bir publik ünvan və porta çevirir, ehtiyat çıxış isə başqasına. Müştərinin daxili ünvanı heç vaxt dəyişmir, buna görə də insanlar bağlantının sağ qalacağını gözləyir.

Server daxili ünvan görmür. O, çevrilmiş son nöqtəni görür və bu son nöqtə keçiddən sonra fərqlidir.

Beləliklə, köhnə axın vaxt aşımına düşür, eyni xidmətə təzə bağlantı isə dərhal işləyir. Hər iki müşahidə eyni vaxtda doğrudur.

Çıxış dəyişdikdə server nə görür

TCP bağlantısı dördlü tuple ilə müəyyən edilir və mənbə ünvanının və ya portunun dəyişməsi qəbul edən host üçün fərqli bağlantı yaradır. Serverin tanımadığı bağlantıya yeni mənbədən gələn paketlər atılır və ya reset ilə cavablandırılır. VPN müştərisinin ünvanında heç nə bu dəyişiklik boyunca əlaqəni qorumur.

Vəziyyətli failover məhz bunun qarşısını almaq üçün mövcuddur və ötürücü cihazlar arasında çevirmə və bağlantı vəziyyətini mübadilə etməklə işləyir. Bu, tunelin deyil, cütün xüsusiyyətidir və fərz edilmək əvəzinə dizayn edilməli və test edilməlidir.

Kiməsə davamlılıq vəd etməzdən əvvəl cütün həqiqətən vəziyyət saxladığını yoxlayın. Aşağıdakı əmrlər hər iki tərəfdə cari vəziyyəti göstərir.

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

Niyə eyni publik ünvan kifayət etmir

Hər iki yolda bir publik ünvan saxlamaq yaxşı başlanğıcdır, çünki server o zaman eyni mənbə son nöqtəsini görür. Tək başına bu kifayət deyil. Ötürücü cihaz hələ də çevirmə vəziyyətinə, firewall vəziyyətinə və işlək geri dönüş yoluna ehtiyac duyur və bunlar keçiddən sonra trafiki daşıyan hansı cihazdırsa, orada olmalıdır.

RFC 3022 ünvan çevrilməsini təsvir edir və çevirən cihazlar arasında vəziyyət mübadiləsini ehtiyat dizaynın hissəsi kimi qəbul edir. Üzən ünvan və ya kopyalanmış profil konfiqurasiyanı daşıyır, vəziyyəti isə daşımır.

Buna görə yalnız ehtiyat vasitəsilə ping edən test çox az şey sübut edir. Ping-in itiriləsi bağlantı vəziyyəti yoxdur.

Tələbin nə qədər güclü olduğunu qərar verin

İstifadəçilər nasazlıqdan sonra yenidən qoşula bilirsə, dizayn bərpa dizaynıdır və qəbul testi təzə sorğudur. Fayl ötürməsi sağ qalmalıdırsa, dizayn vəziyyət sinxronizasiyasına və daha diqqətli testə ehtiyac duyur. Uzaq sessiya sağ qalmalıdırsa, tələb daha da güclüdür və şəbəkə səviyyəli mexanizm əvəzinə tətbiq səviyyəli mexanizm tələb edə bilər.

Tələbi ölçülə bilən nəticəsi olan bir cümlə kimi yazın, məsələn yükləmə yenidən başlamadan tamamlanır və ya operator bir dəqiqə ərzində yenidən qoşulur. Sonra onu ödəyən ən ucuz mexanizmi seçin və bu çox vaxt bərpa dizaynı olur.

Əsas geri qayıtdıqda nə baş verdiyini açıq deyin, çünki avtomatik failback ehtiyatda yenicə bərpa olunmuş bağlantını kəsə bilər. Bu hal test planına aiddir, kənar qeydə deyil.

Köhnə axını və yeni sorğunu yoxlayın

Əsas vasitəsilə zərərsiz, uzunmüddətli ötürmə başladın, sonra eyni xidmətə ayrıca təzə sorğu göndərin. Tətbiq kontekstini, müşahidə olunan çıxış ünvanını və vaxtı qeyd edin. Əsası təsdiqlənmiş üsulla pozun və yeni sorğunu ehtiyat vasitəsilə göndərərkən ilkin ötürməni izləməyə davam edin.

Üç dəyər bildirin: köhnə axın davam etdi, reset oldu, yoxsa vaxt aşımına düşdü; yeni əməliyyat ilk dəfə nə vaxt işlədi; və failback nəyisə kəsdimi. Bu üç sətir qəbul qeydidir.

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ü məlumat yazırsa, vaxt aşımından sonra qeyri-müəyyən əməliyyatı kor-koranə təkrarlamayın. Cavab itməzdən əvvəl yazma yerinə çatmış ola bilər. Nəticəni tətbiqdən soruşun və ya yalnız əməliyyat idempotent olduqda yenidən cəhd edin. Sonra qəbul bəyanatını üç hissədə yazın: yeni əməliyyatlar çıxış siyasəti çərçivəsində bərpa olunur, mövcud axınlar sənədləşdirilmiş kəsmə davranışına malikdir və tətbiq təhlükəsiz şəkildə davam edir. Bu bəyanat test edilə biləndir və dizaynın nə vəd etmədiyi barədə dürüstdür.