Тэст пераключэння: ці выжывае ўсталяваны 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

Калі нагрузка запісвае даныя, не паўтарайце нявызначаную аперацыю наўздагад пасля тайм-аўту. Запіс мог дайсці да месца, перш чым адказ знік. Спытайце вынік у праграмы або паўтарайце толькі там, дзе аперацыя ідэмпатэнтная. Затым запішыце заяву аб прыёмцы з трох частак: новыя аперацыі аднаўляюцца ў межах палітыкі выхаду, існуючыя патокі маюць дакументаваныя паводзіны пры перарыванні, і праграма бяспечна працягвае працу. Такая заява правераная і сумленная наконт таго, чаго схема не абяцае.

Падобныя артыкулы