Failover sinovi: o'rnatilgan TCP oqimi omon qoladimi?

«Zaxira ishlaydi» degan gapning ichida ikki natija yashiringan. Yangi so'rov muvaffaqiyatli bo'ladi, bu tiklanish. Davom etayotgan uzatish davom etadi, bu uzluksizlik. Bular har xil va'dalar, va ko'pchilik failover loyihalari birinchisini beradi, ikkinchisi esa jimgina vaqt tugab tugaydi. Mexanizm tanlashdan oldin qaysi biri kerakligini hal qiling va sinovni ikkalasini ajrata oladigan qilib yozing.

Bitta muvaffaqiyatga o'xshab ko'rinadigan ikki natija

10.90.0.42 dagi mijozning 198.51.100.20:443 ga ulanishi bor deb tasavvur qiling. Asosiy chiqish buni bitta ommaviy manzil va portga aylantiradi, zaxira chiqish esa boshqasiga. Mijozning ichki manzili hech qachon o'zgarmaydi, shuning uchun odamlar ulanish omon qoladi deb kutadi.

Server ichki manzilni ko'rmaydi. U aylantirilgan oxirgi nuqtani ko'radi, va bu nuqta almashtirishdan keyin boshqacha.

Shunday qilib eski oqim vaqt tugab tugaydi, xuddi shu xizmatga yangi ulanish esa darhol ishlaydi. Ikkala kuzatuv ham bir vaqtda to'g'ri.

Chiqish o'zgarganda server nima ko'radi

TCP ulanish o'zining to'rtligi bilan aniqlanadi, manba manzili yoki portning o'zgarishi qabul qiluvchi xost uchun boshqa ulanish yaratadi. Server bilmaydigan ulanishga yangi manbadan kelgan paketlar tashlanadi yoki qayta o'rnatish bilan javob beriladi. VPN mijozi manzilida bu o'zgarish davomida aloqani saqlaydigan hech narsa yo'q.

Holatli failover aynan shundan qochish uchun mavjud va uzatuvchi qurilmalar o'rtasida aylantirish holati va ulanish holatini almashtirish orqali ishlaydi. Bu juftlikning xususiyati, tunnelning emas, va uni taxmin qilish o'rniga loyihalash va sinash kerak.

Birovga uzluksizlik va'da qilishdan oldin juftlik haqiqatan holat saqlaydimi, tekshiring. Quyidagi buyruqlar ikki tomondagi joriy holatni ko'rsatadi.

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

Nima uchun bitta ommaviy manzil yetarli emas

Ikki yo'lda bitta ommaviy manzilni saqlash yaxshi boshlanish, chunki unda server bir xil manba oxirgi nuqtasini ko'radi. Ammo yolg'iz o'zi yetarli emas. Uzatuvchi qurilmaga hali ham aylantirish holati, xavfsizlik devori holati va ishlatish mumkin bo'lgan qaytish yo'li kerak, va ular almashtirishdan keyin trafikni ko'taradigan qurilmada bo'lishi shart.

RFC 3022 manzillarni aylantirishni tavsiflaydi va aylantiruvchi qurilmalar o'rtasidagi holat almashinuvini zaxira loyihasining qismi deb biladi. Suzuvchi manzil yoki nusxalangan profil konfiguratsiyani ko'chiradi, holatni ko'chirmaydi.

Shuning uchun faqat zaxira orqali ping qiladigan sinov juda oz narsani isbotlaydi. Pingning yo'qotadigan ulanish holati yo'q.

Talab qanchalik kuchli ekanini hal qiling

Agar foydalanuvchilar nosozlikdan keyin qayta ulana olsa, loyiha tiklanish loyihasi va qabul sinovi yangi so'rov. Agar fayl uzatish omon qolishi kerak bo'lsa, loyihaga holat sinxronizatsiyasi va ancha ehtiyotkor sinov kerak. Agar masofaviy sessiya omon qolishi kerak bo'lsa, talab yanada kuchliroq va tarmoq darajasi o'rniga ilova darajasidagi mexanizm kerak bo'lishi mumkin.

Talabni o'lchanadigan natijaga ega gap sifatida yozing, masalan yuklash qayta boshlanmasdan tugaydi yoki operator bir daqiqada qayta ulanadi. Keyin uni qanoatlantiradigan eng arzon mexanizmni tanlang, va bu ko'pincha tiklanish loyihasi bo'ladi.

Asosiy yo'l qaytganda nima bo'lishini aniq ayting, chunki avtomatik qaytish zaxirada hozir tiklangan ulanishni uzishi mumkin. Bu holat sinov rejasiga tegishli, izohga emas.

Eski oqim va yangi so'rovni tekshiring

Asosiy yo'l orqali zararsiz uzoq uzatishni boshlang, so'ng xuddi shu xizmatga alohida yangi so'rov yuboring. Ilova kontekstini, kuzatilgan chiqish manzilini va vaqtni yozib oling. Asosiyni tasdiqlangan usulda uzing va yangi so'rovni zaxira orqali yuborayotganda asl uzatishni kuzatishda davom eting.

Uch qiymatni bildiring: eski oqim davom etdimi, qayta o'rnatildimi yoki vaqt tugab tugadimi; yangi amal birinchi marta qachon ishladi; va qaytish biror narsani uzdingmi. O'sha uch qator qabul yozuvidir.

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

Agar ish yuki ma'lumot yozsa, vaqt tugagandan keyin noaniq amalni ko'r-ko'rona qaytarmang. Yozuv javob yo'qolishidan oldin yetib kelgan bo'lishi mumkin. Ilovadan natijani so'rang yoki amal idempotent bo'lgan joyda faqat qayta urinib ko'ring. So'ng qabul bayonini uch qismda yozing: yangi amallar chiqish siyosati ostida tiklanadi, mavjud oqimlar hujjatlashtirilgan uzilish xatti-harakatiga ega, va ilova xavfsiz davom etadi. Bu bayon tekshiriladi va loyiha nima va'da qilmasligi haqida halol.