Asosiy kontentga o’tish

DNS bilan failover: TTL va’da qiladi, resolver bajaradi

TTL’ni 60 soniyaga tushirish failover’ni bir daqiqalik qilmaydi. Trafikning qaytishi sizning sozlamangizga emas, boshqalarning kesh xatti-harakatiga bog’liq.

DDoS
/
2026-05-28
/
4 daqiqa o’qishga

TTL — ko’rsatma, kafolat emas

DNS yozuvidagi TTL resolver’ga «bu javobni shuncha vaqt saqlashing mumkin» deydi. U «shuncha vaqtdan keyin albatta yangilaysan» demaydi.

Amalda ko’p resolver TTL’ni o’zicha o’zgartiradi. Ba’zilari minimal chegara qo’yadi va 60 soniyani 300 soniyaga ko’taradi. Ba’zilari, aksincha, maksimal chegara qo’yadi. Korporativ tarmoqlardagi ichki resolver’lar esa ko’pincha eng eskirgan sozlama bilan ishlaydi.

Shuning uchun failover vaqtini hisoblashda TTL boshlang’ich nuqta, natija emas. Haqiqiy o’tish vaqti — TTL ustiga resolver zanjiridagi har bir bo’g’inning xatti-harakati qo’shilgan qiymat.

Zanjirda kim o’tirgan

Foydalanuvchi va sizning DNS serveringiz orasida odatda kamida uchta kesh bor: operatsion tizim keshi, brauzer keshi va provayder yoki korporativ resolver keshi.

Brauzer keshi ayniqsa noqulay: u ba’zan TTL’ni umuman e’tiborga olmaydi va o’z muddatini qo’llaydi. Sahifa ochiq turgan foydalanuvchi eski manzilga o’n daqiqalab urinaverishi mumkin.

Bunga ulanish darajasidagi «yopishqoqlik» ham qo’shiladi: ochiq TCP ulanish DNS o’zgarganidan keyin ham eski manzil bilan ishlashda davom etadi. U yangilanish uchun avval uzilishi kerak.

Sxema 1TTL tugagach hamma birdan yangilanmaydi. Trafik pog’ona-pog’ona ko’chadi, va oxirgi foiz eng uzoq kutadi — aynan shu oraliq rejaga kirmay qoladi.

Apex domen muammosi

Failover odatda CNAME orqali qilinadi: `www` yozuvi provayderning nomiga ishora qiladi va provayder kerakli manzilni beradi. Lekin standart apex domenda — ya’ni `example.uz` da — CNAME’ga ruxsat bermaydi.

Shuning uchun apex uchun A yozuvi qo’yiladi, u esa statik. Provayder manzilni almashtirsa, sizning apex yozuvingiz eski manzilda qolib ketadi.

Ba’zi DNS provayderlar buni nostandart yechim bilan hal qiladi. Ammo eng ishonchli yo’l boshqacha: domen zonasini butunlay provayderga delegatsiya qilish, ya’ni NS yozuvlarini o’zgartirish. Shunda apex ham, boshqa yozuvlar ham bitta joydan boshqariladi.

Sog’liqni tekshirish qayerdan qilinadi

Failover’ning sifati tekshiruv nuqtalariga bog’liq. Bitta joydan qilingan tekshiruv o’sha nuqtaning tarmoq muammosini butun dunyo uchun avariya deb o’qiydi.

Shuning uchun tekshiruv bir necha mintaqadan bajariladi va qaror ovoz berish bilan chiqariladi: uchtadan ikkitasi «yiqildi» desa, o’tkazish boshlanadi.

Ikkinchi nozik joy — tekshiruvning o’zi nimani so’rayotgani. TCP portining ochiqligi hech narsani anglatmaydi: server ishlab turgan, lekin ma’lumotlar bazasi yiqilgan holat eng ko’p uchraydigan avariya. Tekshiruv haqiqiy sahifani so’rashi va javob mazmunini ko’rishi kerak.

Chayqalishning oldini olish

Avtomatik o’tkazishning eng katta xavfi — chayqalish: tizim bir necha daqiqada oldinga va orqaga o’tib turadi, natijada foydalanuvchilarning bir qismi har safar boshqa serverga tushadi.

Buning oldini olish uchun ikkita chegara qo’yiladi: o’tkazish uchun ketma-ket nechta muvaffaqiyatsiz tekshiruv kerak va qaytish uchun nechta muvaffaqiyatli. Qaytish har doim sekinroq bo’lishi kerak.

Va qaytish odatda avtomatik bo’lmasligi ma’qul. Server tiklandimi yoki faqat tekshiruvga javob berayaptimi — buni odam qaraydi. Avtomatik qaytish tugallanmagan tiklanishning ustiga trafik yuboradi.

Sxema 2Foydalanuvchi va sizning zonangiz orasida kamida uchta kesh bor. TTL faqat oxirgi bo’g’inga ko’rsatma beradi, qolganlari o’z qoidalari bilan ishlaydi.

Sessiya va ma’lumot masalasi

DNS trafikni boshqa manzilga yuboradi, lekin foydalanuvchi holatini ko’chirmaydi. Sessiya faqat bitta serverda saqlansa, o’tkazishdan keyin hamma qaytadan kirishga majbur bo’ladi.

Xuddi shu narsa ma’lumotlarga ham tegishli. Rezerv nusxa faqat o’qish uchun bo’lsa, o’tkazishdan keyin sayt ochiladi, lekin buyurtma qabul qilinmaydi — bu ba’zan yiqilishdan yomonroq, chunki nosozlik ko’rinmaydi.

Shuning uchun failover rejasi doim ikkita savolga javob berishi kerak: o’tkazishdan keyin foydalanuvchi tizimga kirgan holida qoladimi, va yozish amallari ishlaydimi?

DNS failover nima uchun baribir kerak

Yuqoridagi cheklovlar DNS failover’ni foydasiz qilmaydi. Ular uni «bir daqiqada o’tadi» degan va’dadan «o’n-o’n besh daqiqada foydalanuvchilarning katta qismi o’tadi» degan haqiqatga tushiradi.

Ko’p holat uchun bu yetarli. Butun ma’lumotlar markazi yoki provayder yiqilganda, o’n daqiqada trafikning 80 foizini boshqa joyga olib o’tish — bu juda yaxshi natija.

Muhim narsa — kutilma to’g’ri qo’yilishi. Agar biznes bir daqiqalik uzilishga chidamasa, DNS yechim emas: bunday holatda anycast yoki ikki tomonlama faol arxitektura kerak, va ular ancha qimmat.

Sxema 3Apex domen CNAME qabul qilmaydi, shuning uchun statik A yozuvi failover paytida eski manzilda qolib ketadi. Zonani delegatsiya qilish ikkalasini bitta boshqaruvga olib keladi.

O’tkazishni qanday sinash kerak

Rejani mashqsiz ishonch deb qabul qilmang. O’tkazishni rejalashtirilgan holda, tunda emas, ish kunida sinang — chunki tunda sizda kesh ham, foydalanuvchi ham yo’q.

Sinov paytida uchta narsani o’lchang: birinchi foydalanuvchi qachon yangi manzilga tushdi, foydalanuvchilarning 90 foizi qachon o’tdi, va oxirgi 1 foiz qancha kutdi. Uchinchi raqam odatda hammasini hayratda qoldiradi.

Va qaytishni ham sinang. Ko’pchilik faqat o’tishni mashq qiladi, keyin haqiqiy avariyada qaytish paytida ikkinchi uzilishni oladi.

Barcha maqolalar

Tanishamizmi?

Domeningizni ko’rsatsangiz, hozirgi tashqi holatingiz bo’yicha dastlabki tahlil beramiz. Bu bosqichda hech narsa o’zgartirilmaydi.

Boshlaymiz
Bog’lanish
Bog’lanish