Тест на преминаване при отказ: оцелява ли установен TCP поток?

Два резултата се крият в изречението, че резервът работи. Нова заявка успява — това е възстановяване. Трансфер, който вече тече, продължава — това е непрекъснатост. Това са различни обещания и повечето схеми за преминаване при отказ изпълняват първото, докато второто тихо изтича. Решете кое ви е нужно, преди да изберете механизъм, и напишете теста така, че да ги различава.

Два резултата, които изглеждат като един успех

Представете си клиент на 10.90.0.42 с връзка към 198.51.100.20:443. Основният изход преобразува това в един публичен адрес и порт, а резервният изход — в друг. Вътрешният адрес на клиента никога не се променя и затова хората очакват връзката да оцелее.

Сървърът не вижда вътрешен адрес. Той вижда преобразуваната крайна точка, а тази крайна точка е друга след превключването.

Така старият поток изтича, докато нова връзка към същата услуга работи веднага. И двете наблюдения са верни едновременно.

Какво вижда сървърът, когато изходът се смени

TCP връзката се идентифицира чрез своята четворка, а промяната на изходния адрес или порт създава различна връзка от гледна точка на приемащия хост. Пакети, които пристигат от нов източник по връзка, която сървърът не познава, се отхвърлят или се отговаря с рестарт. Нищо в адреса на VPN клиента не запазва асоциацията през тази промяна.

Преминаването при отказ със състояние съществува именно за да избегне това и работи чрез обмен на състояние на преобразуване и на връзки между препращащите устройства. Това е свойство на двойката, а не на тунела, и трябва да бъде проектирано и тествано, а не приемано за дадено.

Проверете дали двойката наистина пази състояние, преди да обещаете непрекъснатост на когото и да е. Командите по-долу показват текущото състояние от двете страни.

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

Защо един и същ публичен адрес не е достатъчен

Запазването на един публичен адрес по двата пътя е добра отправна точка, защото тогава сървърът вижда същата изходна крайна точка. Само по себе си обаче не е достатъчно. Препращащото устройство все още се нуждае от състояние на преобразуване, състояние на защитната стена и използваем обратен път и те трябва да съществуват на устройството, което носи трафика след превключването.

RFC 3022 описва преобразуването на адреси и разглежда обмена на състояние между преобразуващите устройства като част от резервната схема. Плаващият адрес или копираният профил премества конфигурацията, без да премества състоянието.

Затова тест, който само пингува през резерва, доказва много малко. Ping няма състояние на връзка, което да загуби.

Решете колко силно е изискването

Ако потребителите могат да се свържат отново след отказ, схемата е схема за възстановяване и приемният тест е нова заявка. Ако файлов трансфер трябва да оцелее, схемата се нуждае от синхронизация на състоянието и много по-внимателен тест. Ако отдалечена сесия трябва да оцелее, изискването е още по-силно и може да се нуждае от механизъм на ниво приложение, а не на ниво мрежа.

Напишете изискването като изречение с измерим резултат, например качването завършва без рестарт или операторът се свързва отново в рамките на минута. След това изберете най-евтиния механизъм, който го удовлетворява, а това често е схемата за възстановяване.

Кажете изрично какво се случва, когато основният път се върне, защото автоматичното връщане може да прекъсне връзка, която току-що се е възстановила на резерва. Този случай принадлежи в тестовия план, а не в бележка под линия.

Проверете стария поток и новата заявка

Стартирайте безобиден дълготраен трансфер през основния път, след това отделна нова заявка към същата услуга. Запишете контекста на приложението, наблюдавания изходен адрес и времето. Прекъснете основния път по одобрен начин и продължете да наблюдавате първоначалния трансфер, докато изпращате новата заявка през резерва.

Съобщете три стойности: дали старият поток продължи, се нулира или изтече; кога новата операция проработи за първи път; и дали връщането прекъсна нещо. Тези три реда са приемният запис.

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

Ако работният товар записва данни, не повтаряйте несигурна операция сляпо след изтичане. Записът може да е стигнал, преди отговорът да се загуби. Попитайте приложението за резултата или повторете само там, където операцията е идемпотентна. След това напишете приемното твърдение в три части: новите операции се възстановяват според политиката за изход, съществуващите потоци имат документираното поведение при прекъсване и приложението продължава безопасно. Това твърдение е проверимо и е честно за това, което схемата не обещава.