Failover WAN: co dzieje się z otwartymi połączeniami przy przełączeniu łącza

Przełączanie awaryjne opisuje się zwykle w sekundach: sprawdzenie zauważa, router przełącza, łącze wraca. Ten opis zgadza się co do łącza i milczy o wszystkim, co z niego korzystało – a właśnie to zauważa najpierw ten, kto akurat rozmawia.

To, co dzieje się w chwili przełączenia, nie jest krótką przerwą w istniejących połączeniach. Jest ich końcem.

Dlaczego ginie każde połączenie

Połączenie TCP oznacza się czterema wartościami: obydwoma adresami i obydwoma portami. Ruch wychodzący przez WAN1 niesie publiczny adres WAN1, a serwer po drugiej stronie ma ten adres w swojej połowie połączenia.

Po przełączeniu ten sam ruch wychodzi przez WAN2 i przybywa z innym adresem źródłowym. Dla serwera to nie jest to samo połączenie – to pakiety nienależące do niczego, które dostają zresetowanie albo zostają odrzucone. Router nie może pomóc: stan translacji odwzorowujący połączenie wewnętrzne na adres WAN1 należy do interfejsu, który jest wyłączony.

Dlatego wyrażeniem, którego przy sprzęcie tej klasy należy unikać, jest bezszwowe przełączanie. Bezszwowa jest dostępność drogi. Sesje nie są po niej przenoszone i nie zmienia tego żadne ustawienie czasu.

Ile przełączenie naprawdę trwa

Częścią widoczną jest rachunek sprawdzania – interwał razy liczba tolerowanych niepowodzeń. Część niewidoczna przychodzi przed tym: łącze może być martwe przez niemal cały interwał, zanim pierwsze sprawdzenie w ogóle to zauważy, bo sprawdzenie, które przed chwilą się powiodło, przebiegło moment przed awarią.

najgorszy przypadek = interwał × (niepowodzenia + 1)
typowo              = interwał × (niepowodzenia + 0,5)

interwał 5 s, 3 niepowodzenia
  najlepiej   15 s
  typowo      17,5 s
  najgorzej   20 s

do tego czas, którego aplikacje potrzebują, by zauważyć stratę -
przy przekroczeniu czasu TCP znacznie więcej niż wszystko powyżej

Ostatni wiersz rozstrzyga o tym, czego doświadcza człowiek. Router wraca po piętnastu sekundach; pobieranie, które jeszcze nie zauważyło, że jego połączenie jest martwe, siedzi w powtórzeniu transmisji znacznie dłużej, a karta przeglądarki przez cały ten czas wygląda na zamrożoną.

Co przetrwa, a co nie

Wiersz o QUIC jest prawdziwym wyjątkiem i warto go znać, bo po cichu staje się regułą: identyfikator połączenia niezależny od adresu to dokładnie ta własność, która czyni zmianę drogi możliwą do przetrwania – a obie strony muszą ją obsługiwać.

Wiersz o VPN wskazuje jedyny układ, który w praktyce pomaga. Tunel odbudowujący się samodzielnie zamienia jedno przełączenie w jedno ponowne połączenie, a wszystko wewnątrz tunelu widzi krótką przerwę zamiast martwego połączenia – bo wewnątrz tunelu adresy nigdy się nie zmieniły.

Powrót kosztuje to samo jeszcze raz

Przejście z powrotem na łącze główne jest drugim przełączeniem, z drugą rundą martwych sesji. To powód, dla którego oba czasy nie powinny być symetryczne: szybko przełączyć ogranicza awarię, wolno wrócić pozwala uniknąć płacenia ceny dwukrotnie za łącze, które nie jest jeszcze stabilne.

Trzepoczące łącze z równymi czasami to najgorszy przypadek całego tematu. Każde trzepnięcie kosztuje dwie rundy zerwanych sesji, a łącze trzepoczące co kilka minut jest odczuwalnie gorsze niż takie, którego po prostu nie ma – bo to, którego nie ma, przełącza raz i potem zostaje.

Co da się z tym zrobić

Na routerze niewiele, i to należy powiedzieć wprost, zamiast kręcić ustawieniami w nadziei, że któreś z nich jest sztuczką. Pomagają trzy rzeczy.

Różne cele sprawdzania na obu łączach, żeby awaria celu nie została wzięta za awarię obu linii. Czas powrotu będący wielokrotnością czasu przełączenia, żeby trzepotanie kosztowało jedno przełączenie zamiast dziesięciu. I dla wszystkiego, co naprawdę nie może się zerwać, tunel przetrwający zmianę drogi i niosący sesje w sobie.

Poza tym uczciwą postawą jest planowanie z przerwą, a nie zaprzeczanie jej: wiedzieć, że rozmowy się urwą, że kopia zacznie od nowa i że piętnaście sekund z ustawień jest mniejszą połową tego, co awaria faktycznie kosztuje.