Failover — faol xizmat yoki komponent ishlamay qolganda uning vazifasini zaxira komponentga o‘tkazish jarayoni. Maqsad nosozlikni butunlay yo‘qotish emas, xizmat uzilishini belgilangan darajada qisqartirishdir. Failover server, database, tarmoq yo‘li, data-markaz yoki butun region darajasida tashkil qilinishi mumkin.
Faol va zaxira topologiyalari
Active-passive tizimda bitta nusxa trafikni qabul qiladi, zaxira esa tayyor holatda kutadi. Hot standby doimiy sinxron va tez ishga tushadi; warm standby qisman tayyor; cold standby esa resurs yaratish yoki ma’lumot tiklashni talab qiladi. Tayyorlik oshgani sari xarajat ham ko‘payadi.
Active-active topologiyada bir nechta nusxa bir vaqtda trafik oladi. Bitta nusxa yo‘qolsa load balancer sog‘lom nusxalarga yo‘naltiradi. Bu resursdan samaraliroq foydalanadi, ammo shared state, session, capacity va ma’lumotlar izchilligini murakkablashtiradi.
Aniqlash va qaror
Failover health check natijasiga tayanadi. Faqat process mavjudligini tekshirish yetarli emas: ilova portni ochgan bo‘lsa ham database bilan aloqa qilolmasligi mumkin. Readiness tekshiruvi xizmatning real trafikni qayta ishlash qobiliyatini o‘lchaydi.
Bir martalik timeout darhol almashishga sabab bo‘lsa, transient tarmoq kechikishi ortiqcha failover yaratadi. Bir nechta ketma-ket xato, cooldown va turli kuzatuv nuqtalari false positive’ni kamaytiradi. Shu bilan birga juda uzoq kutish recovery time objective’ni buzadi.
Split-brain xavfi
Tarmoq bo‘linishida eski primary ham, yangi primary ham o‘zini faol deb hisoblashi mumkin. Ikki tomon yozuv qabul qilsa ma’lumotlar ajraladi. Quorum, consensus va fencing split-brain’ni cheklaydi. Fencing eski node’ning disk yoki tarmoqqa kirishini aniq to‘xtatadi; faqat “to‘xta” xabarini yuborish yetarli emas, chunki uzilgan node xabarni olmasligi mumkin.
| Mexanizm | Vazifa |
|---|---|
| Health check | Nosozlikni aniqlash |
| Election | Yangi faol nusxani tanlash |
| Fencing | Eski faol nusxani izolyatsiya qilish |
| Replication | Zaxirada ma’lumotni tayyorlash |
| Traffic switch | Mijozni yangi nusxaga yo‘naltirish |
Ma’lumot va sessiyalar
Stateless ilovani almashtirish osonroq, chunki istalgan nusxa so‘rovni qabul qiladi. Session faqat lokal xotirada bo‘lsa, node yo‘qolganda foydalanuvchi sessiyasi ham yo‘qoladi. Session tashqi store’da saqlanishi yoki token orqali mijozga berilishi mumkin.
Asinxron database replication’da primary tasdiqlagan eng yangi yozuv standby’ga hali yetmagan bo‘lishi mumkin. Failover paytida recovery point objective doirasida ma’lumot yo‘qoladi. Sinxron replication yo‘qotishni kamaytiradi, lekin yozuv latency’si va availability’ga ta’sir qiladi.
Trafikni o‘tkazish
Load balancer backend’ni pooldan chiqarishi, virtual IP yangi node’ga ko‘chishi yoki routing protokoli yangi yo‘lni e’lon qilishi mumkin. DNS orqali failover TTL, resolver cache va client behavior sabab darhol bo‘lmaydi. Uzoq yashovchi TCP ulanishlari yangi endpointga o‘z-o‘zidan ko‘chmaydi; mijoz retry va reconnect qilishi kerak.
Failback — tiklangan asl tizimga qaytish — ham nazoratli jarayon. Ma’lumot qayta sinxronlanadi, capacity tekshiriladi va trafik bosqichma-bosqich ko‘chiriladi. Avtomatik qaytish nosozlik takrorlansa ikki endpoint orasida tebranish hosil qilishi mumkin.
Sinov va kuzatuv
Zaxira mavjudligi failover ishlashini isbotlamaydi. Rejalashtirilgan drill, dependency uzilishi va region yo‘qolishi ssenariylari sinovdan o‘tkaziladi. Sinov production xavfini boshqaradigan limit, monitoring va rollback bilan bajariladi.
Metrikalar aniqlash vaqti, almashish vaqti, xato so‘rovlar, replication lag va yo‘qolgan ulanishlarni ko‘rsatadi. Runbook kim qaror qilishi, fencing qanday tasdiqlanishi va ma’lumot izchilligi qanday tekshirilishini belgilaydi.
Bog‘liq tushunchalar
High availability, Redundancy, Disaster recovery, Quorum, Fencing, Replication, Recovery time objective