Thin Provisioning Nedir

Elinizde 1 TB'lık bir depolama havuzu var ve içine her biri 100 GB tanımlı yirmi sanal makine koyuyorsunuz. Toplam 2 TB eder — ama havuz taşmıyor, hatta yarısı bile dolmuyor. Bunu mümkün kılan şey thin provisioning, yani ince tahsistir: disk alanı makineye tanımlandığı anda değil, konuk oraya gerçekten veri yazdığı anda ayrılır. Kullanılmayan alan havuzda kalır ve başka makinelerin hizmetine sunulur.

Bu son derece verimli bir yaklaşımdır ve neredeyse tüm modern sanallaştırma ve bulut altyapıları buna dayanır. Ama bir bedeli vardır ve o bedel ödendiğinde ödeme çok serttir: havuz dolduğunda tek bir makine değil, o havuzdaki tüm makineler birden etkilenir. Bu yazıda ince tahsisin nasıl çalıştığını, hangi katmanlarda uygulandığını, aşırı tahsis riskini nasıl yöneteceğinizi ve alan geri kazanımını sağlayan TRIM zincirini anlatacağım.

İnce ve Kalın Tahsis Arasındaki Fark#

Kalın tahsiste (thick provisioning) bir makineye 100 GB disk tanımladığınızda depolama havuzundan o anda 100 GB düşer. Makine ister boş dursun ister dolu, o alan ona ayrılmıştır ve başkası kullanamaz. Bu, öngörülebilirliğin en yüksek olduğu yöntemdir: havuzda ne kadar yer kaldığını toplam − tahsis edilen ile hesaplarsınız ve sürpriz olmaz.

İnce tahsiste ise 100 GB yalnızca bir üst sınır anlamına gelir. Makine ilk açıldığında belki 2 GB yazar; havuzdan düşen de 2 GB olur. Konuk df -h çalıştırdığında 100 GB'lık bir disk görür ama fiziksel gerçeklik farklıdır. Aradaki bu boşluk, tüm avantajın ve tüm riskin kaynağıdır.

Son iki satır ince tahsisin neden bu kadar yaygınlaştığını açıklıyor: anlık görüntüler ve klonlar neredeyse bedava hâle gelir. Şablondan klon üretmenin saniyeler sürmesinin altında yatan mekanizma budur; ayrıntıları için Proxmox'ta VM şablonu ve klonlama yazısına bakabilirsiniz.

İnce Tahsis Hangi Katmanda Yapılır#

Kafa karışıklığının büyük kısmı, ince tahsisin birden fazla katmanda uygulanabilmesinden gelir. Aynı sistemde üç ayrı yerde ince tahsis olabilir ve her biri farklı davranır.

Dosya tabanlı depolamada (dizin, NFS) ince tahsisi format sağlar — qcow2 doğası gereği inceden tahsis eder. Blok tabanlı depolamada (LVM-thin, ZFS) ise format rawdır ve ince tahsisi havuzun kendisi yapar. Bu ayrım, "raw kullanıyorum, o zaman diskim baştan doluyor mu?" sorusunun cevabıdır: hayır, çünkü tahsis kararı bir alt katmanda veriliyor. Format seçiminin ayrıntıları için sanal disk formatları: qcow2, raw ve vmdk yazısına bakın.

LVM-thin tarafında havuzun gerçek durumunu şu komutlarla görürsünüz:

# Thin havuzların doluluk oranını göster
lvs -o lv_name,lv_size,data_percent,metadata_percent,pool_lv
# LV        LSize    Data%  Meta%  Pool
# data      1.00t    64.20  22.10
# vm-101-disk-0  100.00g  18.40         data
# vm-102-disk-0  100.00g   9.70         data

# Havuz ayrıntıları ve otomatik genişletme ayarı
lvdisplay /dev/pve/data | grep -E "Allocated|Size"

Buradaki Data% sütunu can alıcıdır: havuzun ne kadarının gerçekten yazıldığını gösterir. Meta% ise üstveri alanının doluluğudur ve daha az bilinen bir tuzaktır — üstveri alanı dolarsa veri alanında yer olsa bile havuz yazma kabul etmez.

ZFS kullanıyorsanız karşılığı şudur:

# Havuz ve veri kümelerinin gerçek kullanımı
zfs list -o name,used,available,refer,logicalused
zpool list -o name,size,alloc,free,capacity,fragmentation

Aşırı Tahsis Riski ve Havuz Dolduğunda Ne Olur#

İnce tahsisin doğal sonucu aşırı tahsistir (overprovisioning): toplam tanımlı disk alanı, fiziksel alandan fazladır. Bu bir hata değil, kasıtlı bir stratejidir — çünkü makinelerin çoğu tanımlı alanının tamamını hiçbir zaman kullanmaz. Sorun, tahmin yanlış çıktığında ortaya çıkar.

Havuz dolduğunda olan şey, tek bir makinenin diskinin dolmasından çok daha kötüdür. Konuk sistemler df -h çıktısında hâlâ bol boş alan görür, çünkü kendi dosya sistemleri açısından yer vardır; ama alttaki havuz yeni blok veremediği için yazma istekleri başarısız olur. Sonuç genellikle şudur: dosya sistemleri salt okunur moda geçer, veritabanları bozulur ve makineler kilitlenir. Üstelik bu, havuzu paylaşan tüm makinelerde aynı anda olur.

Bu yüzden ince tahsis kullanan her kurulumda üç önlem zorunludur:

1. Doluluk eşiğinde uyarı kurun. %75 ve %85 seviyelerinde alarm üretin; %90'ı hiçbir zaman görmeyin.
2. Otomatik genişletmeyi yapılandırın. LVM-thin, havuz belirli bir orana ulaştığında kendini büyütebilir — ama yalnızca birim grubunda boş alan varsa.
3. Üstveri alanını da izleyin. Meta% genellikle unutulur ve dolduğunda havuz aynı şekilde yazma kabul etmez.

LVM-thin'de otomatik genişletme ayarları /etc/lvm/lvm.conf içindedir:

# /etc/lvm/lvm.conf - activation bölümü
activation {
    # Havuz bu orana ulaştığında otomatik genişlet
    thin_pool_autoextend_threshold = 80
    # Her genişletmede mevcut boyutun yüzde kaçı kadar büyüsün
    thin_pool_autoextend_percent = 20
}

Bu ayarı yaptıktan sonra dmeventd servisinin çalıştığından emin olun; genişletmeyi tetikleyen odur. Ayarın işe yaraması için birim grubunda tahsis edilmemiş alan bulunması şarttır — havuz zaten tüm diski kaplıyorsa otomatik genişletmenin yapabileceği bir şey yoktur.

Basit bir izleme betiği, pahalı bir izleme sistemi kurmadan da işinizi görür:

#!/bin/bash
# /usr/local/bin/thin-havuz-kontrol.sh - cron ile saatte bir çalıştırın
ESIK=80
lvs --noheadings -o lv_name,data_percent,metadata_percent --select 'lv_layout=thin,pool' \
| while read -r ad veri meta; do
    veri_tam=${veri%.*}; meta_tam=${meta%.*}
    if [ "${veri_tam:-0}" -ge "$ESIK" ] || [ "${meta_tam:-0}" -ge "$ESIK" ]; then
      echo "UYARI: $ad havuzu doluluk veri=%$veri meta=%$meta" \
        | mail -s "Thin havuz uyarisi: $(hostname)" [email protected]
    fi
  done

Doluluk sorunları ana makinede de ortaya çıkabilir; genel bir disk dolma senaryosunda ne yapılacağını disk dolu: no space left çözümü yazısında, doluluk analizini ise disk kullanımı: df, du ve ncdu yazısında ele aldım.

Alan Geri Kazanımı: TRIM Zinciri#

İnce tahsisin en çok yanlış anlaşılan yanı şudur: konuk bir dosyayı sildiğinde havuzda alan otomatik boşalmaz. Silme işlemi yalnızca konuğun dosya sistemi seviyesinde yapılır; alttaki havuz o blokların artık kullanılmadığından habersizdir ve onları dolu saymaya devam eder. Zamanla havuz, konuklardaki gerçek veriden çok daha fazla yer kaplar.

Bunu çözen mekanizma TRIM/discard'dır ve üç katmanın da açık olması gerekir. Zincirdeki tek bir halka kopuksa alan geri kazanılmaz:

Zinciri uçtan uca kurmak şu adımlarla olur:

# 1) Ana makinede: diskte discard'ı aç (VirtIO SCSI gerekir)
qm set 260 --scsihw virtio-scsi-single
qm set 260 --scsi0 local-lvm:vm-260-disk-0,discard=on,ssd=1

# 2) Konuk içinde: periyodik trim'i etkinleştir
systemctl enable --now fstrim.timer

# 3) Elle çalıştırıp ne kadar alan bildirildiğini gör
fstrim -av
# /: 18.7 GiB (20079742976 bytes) trimmed

# 4) Ana makinede havuzun küçüldüğünü doğrula
lvs -o lv_name,data_percent | grep data

Windows konuklarda fstrim karşılığı, disk optimizasyon aracının SSD modunda çalışmasıdır; VirtIO SCSI sürücüsü kuruluysa Windows diski otomatik olarak "thin" tanır ve zamanlanmış optimizasyon TRIM gönderir. VirtIO sürücülerinin doğru kurulumu için VirtIO sürücüleri ve disk performansı yazısına bakabilirsiniz.

⚠️ Bir uyarı: eski kurulumlarda TRIM bazen ağır bir işlem olabilir ve yoğun saatlerde performans dalgalanması yaratır. Bu yüzden sürekli discard (mount -o discard) yerine zamanlanmış fstrim.timer tercih edilir — haftada bir kez, gece çalışır ve gündüz hiçbir maliyeti olmaz.

Ne Zaman Kalın Tahsis Tercih Edilmeli#

İnce tahsis çoğu senaryoda doğru seçimdir ama her senaryoda değil. Kalın tahsisi tercih etmeniz gereken durumlar şunlardır:

• Öngörülebilirliğin performanstan daha önemli olduğu kritik iş yükleri. Bir üretim veritabanının, havuzdaki komşularının davranışı yüzünden yazamaz hâle gelmesini istemezsiniz.
• Havuzu paylaşan tarafların birbirini tanımadığı ortamlar. Aşırı tahsis, ancak toplam kullanımı öngörebildiğinizde güvenlidir.
• Alan izlemenin düzenli yapılamayacağı kurulumlar. İzlenmeyen bir ince havuz, er ya da geç dolar.
• Sabit boyutlu, tamamen dolacağı bilinen diskler. Bir yedek deposu zaten tamamını kullanacaksa ince tahsisin sağladığı bir kazanç yoktur.

Pratikte en sağlıklı düzen karma yaklaşımdır: kritik üretim makineleri için ayrı bir kalın havuz, test/geliştirme ve çok sayıda benzer makine için ince havuz. Böylece verimlilikten yararlanırken kritik iş yüklerini komşu riskinden yalıtırsınız.

Sık Yapılan Hatalar#

Konuk df çıktısına bakıp havuzu doğru sanmak. Konuktaki boş alan, havuzdaki boş alan hakkında hiçbir şey söylemez. Havuzun durumunu yalnızca ana makineden lvs ya da zpool list ile görürsünüz. İzlemenizi ana makineye kurun.

Üstveri alanını izlememek. Data% %40'ta dururken Meta% %98'e çıkmış bir havuz, yazma kabul etmez. Üstveri alanı varsayılan olarak küçük ayarlanır ve çok sayıda anlık görüntü aldığınızda hızla dolar. İzleme betiğinize mutlaka ekleyin.

TRIM zincirinin bir halkasını atlamak. En sık atlanan halka discard=on ayarıdır; ikincisi konukta fstrim.timer servisinin etkinleştirilmemesidir. Zincir eksikse aylar boyunca alan biriktirirsiniz ve nedenini anlamazsınız.

Anlık görüntüleri temizlememek. İnce havuzda anlık görüntüler ucuzdur ama bedava değildir: kaynak veri değiştikçe eski bloklar tutulmaya devam eder. Aylardır duran onlarca anlık görüntü, havuzun sessizce dolmasının en yaygın sebebidir. Anlık görüntüyü geçici bir güvenlik ağı olarak kullanın; kalıcı saklama için Borg ile sunucu yedekleme yazısındaki gibi gerçek bir yedekleme kurun.

Havuz dolduğunda paniğe kapılıp makine silmek. Havuz dolduğunda ilk yapılacak şey, yeni yazmayı durdurmak (yoğun makineleri kapatmak) ve havuzu genişletmektir. Makine silmek alanı hemen geri vermeyebilir, çünkü silme işleminin kendisi de üstveri yazması gerektirir. Öncelik, birim grubuna yeni fiziksel alan ekleyip havuzu büyütmektir.

Sıkça Sorulan Sorular#

Thin provisioning performansı düşürür mü#

İlk yazmada küçük bir maliyeti vardır, çünkü blok tahsis edilmesi ve üstverinin güncellenmesi gerekir. Bir kez tahsis edilmiş alana yapılan yazmalar ise kalın tahsisle aynı hızdadır. Pratikte fark çoğu iş yükünde ölçülemeyecek kadar küçüktür. Asıl performans riski tahsis maliyetinden değil, havuzun doluluk sınırına yaklaşmasından gelir — orada parçalanma artar ve yazma belirgin biçimde yavaşlar.

Havuz dolduğunda ne olur#

Havuz yeni blok veremediği için yazma istekleri başarısız olur. Konuk sistemler kendi df çıktısında hâlâ boş alan gördüğü için bunu beklemezler; sonuç genellikle dosya sistemlerinin salt okunur moda geçmesi, veritabanlarının bozulması ve makinelerin kilitlenmesidir. Üstelik bu, havuzu paylaşan tüm makineleri aynı anda etkiler. Bu yüzden %80 eşiğinde alarm kurmak isteğe bağlı değil, zorunludur.

Ne kadar aşırı tahsis yapabilirim#

Kesin bir oran veremem, çünkü cevap iş yükünüzün gerçek büyüme hızına bağlıdır. Sağlıklı yaklaşım orandan değil, izlemeden başlamaktır: birkaç hafta boyunca havuzun gerçek büyüme eğrisini ölçün ve doluluk %80'e ne kadar sürede ulaşacağını hesaplayın. Bu süre, yeni disk tedarik etmeniz için gereken süreden belirgin biçimde uzun olmalıdır. Benzer ve öngörülebilir makinelerde daha rahat, değişken iş yüklerinde çok daha temkinli davranın.

Silinen dosyaların alanı neden geri gelmiyor#

Çünkü konuk dosyayı sildiğinde bu bilgi alttaki havuza otomatik ulaşmaz; havuz o blokları hâlâ kullanımda sayar. Alanın geri kazanılması için TRIM zincirinin uçtan uca açık olması gerekir: konukta fstrim.timer etkin, sanal diskte discard=on ayarı yapılmış ve depolama havuzu discard destekliyor olmalı. Üç halkadan biri kopuksa alan birikmeye devam eder.

LVM-thin mi ZFS mi kullanmalıyım#

İkisi de ince tahsis ve anlık görüntü sunar; seçim ihtiyaca bağlıdır. LVM-thin daha hafiftir, az RAM ister ve kurulumu basittir; öngörülebilir performans arayan çoğu kurulum için yeterlidir. ZFS ise veri bütünlüğü kontrolü, sıkıştırma, gönderme/alma tabanlı çoğaltma gibi güçlü özellikler getirir ama belirgin miktarda RAM ister. Sunucunuzda bol bellek varsa ve bu özelliklere ihtiyacınız oluyorsa ZFS, sade ve verimli bir çözüm istiyorsanız LVM-thin.

İnce tahsisli bir diski kalın tahsise çevirebilir miyim#

Doğrudan bir dönüştürme anahtarı yoktur ama pratik yolu vardır: makineyi kapatıp diski kalın tahsis kullanan bir depolamaya taşırsınız (Proxmox'ta "Move Disk"). Taşıma sırasında alanın tamamı hedefte ayrılır. Ters yön de aynı şekilde çalışır. Her iki durumda da hedef depolamada yeterli boş alan bulunduğundan emin olun ve işlem öncesi yedek alın.

Kapanış#

İnce tahsis, depolamayı çok daha verimli kullanmanın ve klon/anlık görüntü işlemlerini neredeyse bedava hâle getirmenin yoludur; modern sanallaştırmanın belkemiğidir. Ama bu verim, "havuz dolarsa herkes birden etkilenir" riskiyle birlikte gelir. Aklınızda kalması gereken dört alışkanlık şunlar: havuz doluluğunu ana makineden izleyin ve %80'de alarm kurun, üstveri alanını da izlemeyi unutmayın, TRIM zincirini üç katmanda birden açık tutun ve kritik üretim iş yüklerini komşularıyla aynı ince havuzda tutmayın.

Depolama havuzunu kendiniz kurup yönetmek istiyorsanız tam root erişimli VDS ve sanal sunucu paketlerimiz uygun bir zemin sunar; öngörülebilir ve size özel disk performansı gerektiren iş yükleri için dedicated sunucu, esnek büyüme için bulut sunucu tarafına bakabilirsiniz. Doluluk izleme, yedekleme ve kapasite planlamasını devretmek isterseniz sunucu yönetimi ve yedekleme hizmetlerimiz bu işi üstlenir.