Test przełączania: czy istniejący strumień TCP przetrwa?

W zdaniu, że zapas działa, ukrywają się dwa wyniki. Nowe żądanie kończy się sukcesem, to odzyskanie. Trwający już transfer jest kontynuowany, to ciągłość. To różne obietnice, a większość projektów przełączania realizuje pierwszą, podczas gdy druga po cichu kończy się przekroczeniem czasu. Zdecyduj, której potrzebujesz, zanim wybierzesz mechanizm, i napisz test tak, aby potrafił je rozróżnić.

Dwa wyniki, które wyglądają jak jeden sukces

Wyobraź sobie klienta pod 10.90.0.42 z połączeniem do 198.51.100.20:443. Główne wyjście tłumaczy to na jeden publiczny adres i port, a wyjście zapasowe na inny. Wewnętrzny adres klienta nigdy się nie zmienia, dlatego ludzie oczekują, że połączenie przetrwa.

Serwer nie widzi wewnętrznego adresu. Widzi przetłumaczony punkt końcowy, a ten punkt po przełączeniu jest inny.

Stary strumień kończy się więc przekroczeniem czasu, podczas gdy nowe połączenie do tej samej usługi działa natychmiast. Oba spostrzeżenia są prawdziwe jednocześnie.

Co widzi serwer, gdy zmienia się wyjście

Połączenie TCP jest identyfikowane przez swoją czwórkę, a zmiana adresu lub portu źródłowego tworzy inne połączenie z punktu widzenia hosta odbierającego. Pakiety przychodzące z nowego źródła na połączeniu, którego serwer nie zna, są odrzucane lub odpowiada się na nie resetem. Nic w adresie klienta VPN nie zachowuje powiązania przez tę zmianę.

Przełączanie ze stanem istnieje właśnie po to, by tego uniknąć, i działa przez wymianę stanu tłumaczenia oraz stanu połączeń między urządzeniami przekazującymi. To cecha pary, a nie tunelu, i trzeba ją zaprojektować i przetestować, a nie zakładać.

Sprawdź, czy para rzeczywiście utrzymuje stan, zanim komukolwiek obiecasz ciągłość. Poniższe polecenia pokazują bieżący stan po obu stronach.

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

Dlaczego ten sam publiczny adres nie wystarcza

Utrzymanie jednego publicznego adresu na obu ścieżkach to dobry początek, bo serwer widzi wtedy ten sam punkt źródłowy. Samo w sobie to jednak nie wystarcza. Urządzenie przekazujące nadal potrzebuje stanu tłumaczenia, stanu zapory i użytecznej drogi powrotnej, a to musi istnieć na urządzeniu, które po przełączeniu niesie ruch.

RFC 3022 opisuje tłumaczenie adresów i traktuje wymianę stanu między urządzeniami tłumaczącymi jako część projektu zapasowego. Adres pływający lub skopiowany profil przenosi konfigurację, ale nie przenosi stanu.

Dlatego test, który tylko pinguje przez zapas, dowodzi bardzo niewiele. Ping nie ma stanu połączenia, który mógłby utracić.

Zdecyduj, jak silne jest wymaganie

Jeśli użytkownicy mogą po awarii połączyć się ponownie, projekt jest projektem odzyskiwania, a test akceptacyjny to nowe żądanie. Jeśli transfer pliku musi przetrwać, projekt potrzebuje synchronizacji stanu i znacznie staranniejszego testu. Jeśli sesja zdalna musi przetrwać, wymaganie jest jeszcze silniejsze i może wymagać mechanizmu na poziomie aplikacji, a nie sieci.

Zapisz wymaganie jako zdanie z mierzalnym wynikiem, na przykład przesyłanie kończy się bez ponownego uruchamiania albo operator łączy się ponownie w ciągu minuty. Następnie wybierz najtańszy mechanizm, który je spełnia, a często jest to projekt odzyskiwania.

Powiedz wprost, co się dzieje, gdy główna ścieżka wraca, bo automatyczny powrót może przerwać połączenie, które właśnie odzyskało sprawność na zapasie. Ten przypadek należy do planu testów, a nie do przypisu.

Sprawdź stary strumień i nowe żądanie

Rozpocznij nieszkodliwy długi transfer przez główną ścieżkę, a potem osobne nowe żądanie do tej samej usługi. Zapisz kontekst aplikacji, zaobserwowany adres wyjściowy i czas. Przerwij główną ścieżkę w zatwierdzony sposób i nadal obserwuj pierwotny transfer, wysyłając nowe żądanie przez zapas.

Zgłoś trzy wartości: czy stary strumień trwał, został zresetowany czy zakończył się przekroczeniem czasu; kiedy nowa operacja zadziałała po raz pierwszy; oraz czy powrót coś przerwał. Te trzy wiersze to protokół odbioru.

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

Jeśli obciążenie zapisuje dane, nie powtarzaj niepewnej operacji na ślepo po przekroczeniu czasu. Zapis mógł dotrzeć, zanim odpowiedź zaginęła. Zapytaj aplikację o wynik albo ponów próbę tylko tam, gdzie operacja jest idempotentna. Następnie zapisz oświadczenie odbiorcze w trzech częściach: nowe operacje odzyskują sprawność zgodnie z polityką wyjścia, istniejące strumienie mają udokumentowane zachowanie przy przerwaniu, a aplikacja wznawia pracę bezpiecznie. To oświadczenie jest testowalne i uczciwe co do tego, czego projekt nie obiecuje.