Thin provisioning — storage resursiga katta mantiqiy sig‘im ko‘rsatib, fizik joyni ma’lumot haqiqatan yozilganda ajratish usuli. Masalan, 1 TiB logical volume yaratilishi mumkin, ammo unda 20 GiB data bo‘lsa backend dastlab taxminan shu miqdorga yaqin blok ishlatadi. Bu usul sig‘imdan samarali foydalanadi, biroq qat’iy monitoring talab qiladi.
Thick allocation’dan farqi
Thick provision qilingan volume uchun kerakli physical capacity yaratish paytida to‘liq rezerv qilinadi. Thin volume’da esa adres maydoni darhol mavjud, bloklar esa first write vaqtida thin pooldan olinadi. Bir nechta volume logical hajmlarining yig‘indisi poolning real hajmidan katta bo‘lishi mumkin; bu overcommit deb ataladi.
Overcommit barcha workloadlar bir vaqtda maksimal hajmni ishlatmasligi haqidagi taxminga tayanadi. U yangi fizik sig‘im yaratmaydi. Taxmin noto‘g‘ri chiqsa pool to‘ladi va yozuvlar kechikishi, read-only holat yoki I/O xatosi yuz berishi mumkin.
Mapping va metadata
Thin provisioning qatlami logical blokni physical blokka bog‘laydigan mapping metadata’sini saqlaydi. O‘qilmagan, hali ajratilmagan hudud odatda nol sifatida qaytariladi. Birinchi yozuvda allocator bo‘sh physical extent tanlaydi va mappingni atomar yangilaydi.
Data maydoni bilan metadata maydoni alohida limitga ega bo‘lishi mumkin. Millionlab mayda, tarqoq yozuvlar metadata’ni tezroq sarflaydi. Shuning uchun monitoring faqat data foiziga emas, metadata bandligiga ham alert beradi.
Snapshot va clone
Thin snapshot original volume bilan mavjud bloklarni bo‘lishadi. Original yoki snapshot blokka yozsa copy-on-write yangi blok ajratadi va ikkinchi ko‘rinish eski blokni saqlaydi. Clone ham umumiy boshlang‘ich data sabab tez yaratiladi. Vaqt o‘tishi bilan ikkala variant o‘zgargani sari real joy sarfi ortadi.
Snapshot o‘chirilganda reference qolmagan bloklar poolga qaytariladi. Bu jarayon metadata va garbage collection ishini keltirishi mumkin. Snapshotni ko‘p va uzoq saqlash performance hamda capacity rejasiga kiritiladi.
Bo‘sh joyni qaytarish
Guest file system faylni o‘chirganda odatda faqat o‘z metadata’sini yangilaydi; storage qatlami eski blok endi kerak emasligini bilmasligi mumkin. Discard yoki TRIM buyruqlari bo‘shatilgan logical range’ni backendga bildiradi. Online discard har o‘chirishda, periodik trim esa jadval bo‘yicha ishlashi mumkin.
Discardning qo‘llanishi device, hypervisor va encryption qatlamlaridan o‘tishi kerak. Uning latency hamda data remanence xususiyatlari platformaga qarab baholanadi. Zero yozish har doim blokni deallocate qilish bilan teng emas.
Capacity boshqaruvi
Pool uchun warning va critical thresholdlar, o‘sish sur’ati hamda fizik kengaytirish vaqti kuzatiladi. Faqat 90 foiz alert kech bo‘lishi mumkin: tez o‘sayotgan workload qolgan joyni bir necha daqiqada sarflaydi. Forecast yozuv tezligini ham hisobga oladi.
Auto-extend mavjud bo‘lsa uning ostidagi VG yoki storage tizimida haqiqiy bo‘sh joy bo‘lishi kerak. Noto‘g‘ri avtomatika logical volume’ni kattalashtirib, pool physical limitini yashira olmaydi. Quota workloadning butun umumiy poolni egallashini cheklaydi.
Failure va tiklash
Pool to‘lganda xatti-harakat storage implementatsiyasiga bog‘liq. Database durability uchun kutilmagan I/O error juda xavfli; emergency reserve va oldindan sinovdan o‘tgan runbook zarur. Capacity qo‘shilgach ham file system yoki application xatosini tekshirish kerak.
Thin provisioning backup emas. Mapping metadata yoki barcha physical device yo‘qolsa ko‘p logical volume birga zararlanadi. Metadata backup va redundant storage tiklash imkonini yaxshilaydi, foydalanuvchi data’si esa alohida backup siyosatiga ega bo‘ladi.
Bog‘liq tushunchalar
Logical volume, Storage pool, Overcommit, Copy-on-write, Snapshot, Discard, TRIM, Capacity planning