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.
TTL’ni 60 soniyaga tushirish failover’ni bir daqiqalik qilmaydi. Trafikning qaytishi sizning sozlamangizga emas, boshqalarning kesh xatti-harakatiga bog’liq.
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.
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.
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.
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.
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.
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?
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.
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.
Domeningizni ko’rsatsangiz, hozirgi tashqi holatingiz bo’yicha dastlabki tahlil beramiz. Bu bosqichda hech narsa o’zgartirilmaydi.

