Availability zone — cloud region ichidagi, elektr, sovitish va ayrim network infratuzilmasi bo‘yicha boshqa zonalardan imkon qadar ajratilgan failure domain. Bir regiondagi zonalar odatda past latencyli private network bilan ulangan. Zone chegarasi nosozlik ta’sirini kamaytiradi, ammo mutlaq mustaqillik yoki barcha xizmatlar bir vaqtda hech qachon buzilmasligini kafolatlamaydi.
Scope va identifikator
Virtual machine, block disk va ayrim IP resurslar zonal bo‘ladi: ular ma’lum zonada yaratiladi va ko‘pincha faqat shu zonadagi compute bilan biriktiriladi. Managed load balancer yoki database esa regional control plane orqali bir nechta zonani qamrashi mumkin. Har xizmatning scope’i provider hujjatidan tekshiriladi.
Ba’zi cloudlarda zone-a kabi nomlar turli accountlarda boshqa fizik zonaga mapping qilinishi mumkin. Cross-account placement uchun barqaror zone ID kerak bo‘ladi. Faqat bir xil harfga qarab shared failure domain taxmin qilish noto‘g‘ri.
Multi-zone arxitektura
High availability uchun instance va data replicas kamida ikki yoki uch zonaga tarqatiladi. Load balancer sog‘lom zonalarga traffic beradi. Stateful tizimda quorum a’zolari zonalar bo‘yicha joylashtiriladi; ikki zonali uch tugunli cluster bir zonada ikki voter saqlasa o‘sha zona yo‘qolganda quorum ham yo‘qoladi.
Ilovaning zonalararo bo‘lishi yetarli emas. Bitta zonadagi NAT gateway, disk, secrets endpoint yoki message broker barcha nusxalar uchun yashirin dependency bo‘lishi mumkin. Dependency inventory va zone failure drill buni ochadi.
Capacity va xarajat
Zone nosozligida qolgan zonalar butun yukni ko‘tara olishi kerak. Autoscaling yangi capacity topolmasligi mumkin, shuning uchun reserved capacity yoki normal paytda headroom rejalashtiriladi. Cross-zone traffic uchun data transfer haqi va qo‘shimcha latency bo‘lishi mumkin.
Topology-aware routing bir zonadagi clientni o‘sha zonadagi servicega yo‘naltirib xarajatni kamaytiradi. Biroq zone local endpoint ishdan chiqsa boshqa zonaga fallback saqlanishi kerak; faqat locality uchun resilience qurbon qilinmaydi.
Operatsion tekshiruv
Deployment anti-affinity yoki topology spread bilan bir zonaga yig‘ilib qolishdan himoyalanadi. Monitoring instance count, replica health va trafficni zone bo‘yicha ajratadi. Test faqat bitta VMni o‘chirish emas, zona networki va zonal dependencylar yo‘qolgandagi xatti-harakatni ham qamraydi.
Availability zone region-level falokatdan himoya qilmaydi. Data residency va disaster recovery talabi bo‘lsa boshqa regiondagi backup yoki replica alohida loyihalanadi.
Zone tanlash
Har regionda barcha instance turi, accelerator yoki managed service har zonada mavjud bo‘lmasligi mumkin. Deployment oldidan capability va quota zonalar bo‘yicha tekshiriladi. Auto scheduler faqat arzon yoki bo‘sh zonani tanlasa replicas bir failure domainga yig‘ilishi mumkin; placement constraint va anti-affinity buni cheklaydi.
Zone chegarasi application uchun label sifatida metadata orqali keladi. Bu metadata ishonchli deployment input bo‘lishi, user yuborgan headerga tayanmasligi kerak. Log va tracega zone label qo‘shish partial regional incidentni aniqlashga yordam beradi. Biroq user privacy yoki security tokeniga fizik zone nomini keraksiz chiqarish talab etilmaydi. Service level objective zone loss kabi kutilgan failure rejimida ham o‘lchanadi, faqat oddiy instance restart bilan cheklanmaydi.
Zone maintenance e’loni mavjud bo‘lsa operator trafficni oldindan kamaytirishi mumkin, lekin arxitektura bunday ogohlantirishga bog‘lanmaydi. Kutilmagan uzilish asosiy failure modeli bo‘lib qoladi.
Bog‘liq tushunchalar
Cloud region, Failure domain, Multi-zone deployment, Zonal resource, Quorum, High availability, Disaster recovery, Cross-zone traffic