Zonal disk — cloud block storage resursi bo‘lib, ma’lum availability zone scope’ida yaratiladi va odatda faqat shu zonadagi virtual machine yoki nodega biriktiriladi. Provider disk bloklarini zona ichida bir necha qurilmada durable saqlashi mumkin, ammo zone to‘liq yo‘qolganda boshqa zonadan diskka darhol kirish kafolatlanmaydi.
Compute bilan bog‘lanish
VM va disk zone’i mos bo‘lishi kerak. Scheduler stateful workloadni boshqa zonaga ko‘chirsa mavjud diskni attach qila olmasligi mumkin. Kubernetes kabi muhitda volume topology constraint podni disk turgan zonaga rejalashtiradi. Bu constraintni bilmaslik pending pod yoki uzoq failoverga olib keladi.
Disk detach va attach operatsiyasi instance halokatidan keyin fencing talab qilishi mumkin. Ikki node bir vaqtda bir xil filesystemga yozsa corruption yuz beradi. Multi-attach funksiyasi mavjud bo‘lsa ham application yoki cluster filesystem distributed lockingni qo‘llashi shart.
Durability va availability
Diskning zona ichidagi replicationi hardware failurega chidamlilik beradi, lekin zonalararo availability emas. Disk SLA, annual failure rate va replication usuli providerga bog‘liq. “Replicated disk” iborasidan uning regional ekanini xulosa qilib bo‘lmaydi.
Database high availability uchun har zonadagi replica o‘z zonal diskiga yozishi mumkin. Database log orqali izchillikni boshqaradi. Faqat bitta zonal diskni snapshot bilan vaqti-vaqti boshqa zonaga ko‘chirish recovery beradi, ammo real-time failover emas.
Ko‘chirish va tiklash
Boshqa zonaga ko‘chirish ko‘pincha snapshot yaratish, target zonada yangi disk ochish va workloadni o‘sha diskka ulashdan iborat. Snapshot asynchronous tugashi va oxirgi yozuvlarni qamramasligi mumkin; application-consistent snapshot uchun filesystem freeze yoki database backup protokoli ishlatiladi.
Regional snapshot xizmati zonal diskdan kengroq failure domainda saqlanishi mumkin. Retention, encryption key va restore permissionlar tekshiriladi. Snapshotning mavjudligi restore tezligini kafolatlamaydi; katta diskni hydrate qilish performancega ta’sir qiladi.
Performance va xarajat
Disk turi IOPS, throughput, latency va burst limitlariga ega. Instance-to-disk bandwidth ham alohida chegara bo‘lishi mumkin. Monitoring queue depth, latency, throttling va capacityni ko‘radi. Disk to‘lishi database va filesystemni to‘xtatishi mumkin.
Zonal disk arzon va past latencyli state storage uchun qulay. Arxitektura zone loss RTO/RPO talabini baholab, replica, snapshot yoki regional diskni tanlaydi; resurs nomining o‘zi talabga javob bermaydi.
Kubernetesdagi holat
StorageClass volume binding rejimi diskni pod rejalashtirilgunga qadar kutishi mumkin. WaitForFirstConsumer schedulerga podning zone talabini bilib, diskni o‘sha zonada yaratish imkonini beradi. Disk oldindan tasodifiy zonada yaratilsa podning CPU yoki accelerator talabi boshqa zonaga mos kelib, scheduling deadlock yuzaga kelishi mumkin.
StatefulSet replika soni disk replicasini avtomatik anglatmaydi; har podning alohida volume’i bo‘ladi va data replicationni database yoki storage tizimi bajaradi. Pod boshqa zonada qayta yaratilganda eski zonal volume ko‘chmaydi. Volume snapshot controller recovery artifact yaratishi mumkin, ammo crash-consistent yoki application-consistent ekani workload qoidalariga bog‘liq. Restore drill manifest, key va snapshot permissionlari ham mavjudligini tekshiradi.
Diskni o‘chirish policy workload lifecycle’dan alohida ko‘riladi. Test environment avtomatik tozalansa ham production PersistentVolume uchun retain siyosati tasodifiy data loss xavfini kamaytiradi. Orphan disklar esa xarajat va sensitive data retention muammosini keltiradi.
Bog‘liq tushunchalar
Block storage, Availability zone, Regional disk, Snapshot, Persistent volume, Fencing, IOPS, Disaster recovery