Sanallaştırma ve Kurumsal Depolama Katmanında I/O Darboğazları: Queue Depth, Multipath ve I/O Scheduler Optimizasyonu

Kurumsal veri merkezlerinde en sık karşılaşılan yanılgılardan biri, All-Flash (NVMe/SSD) SAN ünitelerine veya 32Gbps+ Fibre Channel (FC) anahtarlara yatırım yapıldıktan sonra tüm I/O gecikme (latency) sorunlarının kendiliğinden çözüleceğinin düşünülmesidir. Oysa alttaki donanım ne kadar hızlı olursa olsun, hipervizör (VMware ESXi, Proxmox/KVM) ve konuk işletim sistemi (Guest OS) katmanındaki varsayılan kuyruk (Queue) ve zamanlayıcı (Scheduler) ayarları çoğu zaman geleneksel dönen diskler (HDD) veya düşük yoğunluklu iş yükleri düşünülerek yapılandırılmıştır.
Bugünkü yazımızda, ilk olarak Linux çekirdek dünyasındaki son gelişmeye değinecek, ardından sanal makinelerden fiziksel LUN’lara uzanan I/O yolundaki gizli darboğazları nasıl tespit edip optimize edeceğimizi inceleyeceğiz.

Kısa Güncel Haber: Linux Çekirdeğinde KGDB’nin Kaldırılması Tartışılıyor
Son 24 saat içinde Linux çekirdek geliştiricileri posta listesinde (LKML) önemli bir temizlik adımı gündeme geldi: KGDB (Kernel GNU Debugger) modülünün çekirdekten tamamen çıkarılması tartışılıyor. 2008 yılında Linux 2.6.26 sürümüyle çekirdeğe dahil edilen KGDB, yıllarca çekirdek seviyesinde hata ayıklama için kullanılsa da, günümüzde geliştiricilerin ve sistem mühendislerinin neredeyse tamamı QEMU/KVM tabanlı sanallaştırma hata ayıklama araçlarını (gdbstub) ve modern eBPF izleme altyapılarını tercih ediyor. Sanallaştırma katmanının bizzat kendisinin artık en güçlü çekirdek hata ayıklama aracına dönüşmüş olması, modern altyapıların geldiği noktayı göstermesi açısından oldukça dikkat çekici.

1. Linux Sanal Makinelerde I/O Scheduler Seçimi: Neden none veya mq-deadline?
Ubuntu 22.04/24.04 veya RHEL tabanlı bir sanal makine (VM) kurduğunuzda, çekirdek blok katmanı (Multi-Queue Block Layer – blk-mq) disk trafiğini sıralamak için bir I/O zamanlayıcısı atar. Ancak sanal makineniz zaten bir hipervizör (ESXi veya KVM) üzerinde çalışıyorsa ve altında kurumsal bir Storage Array (PureStorage, NetApp vb.) bulunuyorsa, sanal makine içinde karmaşık bir I/O sıralaması yapmak çifte zamanlama (double scheduling) yükü ve gereksiz CPU kullanımı (steal/wait time) yaratır.

• none (No-op): NVMe tabanlı sanal diskler ve VMware Paravirtual SCSI (PVSCSI) veya KVM virtio-scsi denetleyicileri için en ideal seçenektir. Gelen I/O isteklerini hiçbir ekstra kuyruk işlemine sokmadan doğrudan alt katmana (hipervizöre ve oradan HBA/SAN katmanına) iletir.
• mq-deadline: Yoğun veritabanı (MySQL/InnoDB, PostgreSQL) iş yüklerinde yazma açlığını (write starvation) önlemek ve okuma isteklerine belirli bir gecikme garantisi vermek için tercih edilir.

Mevcut durumu kontrol etmek ve kalıcı olarak optimize etmek:

# Sistemdeki blok cihazların aktif I/O zamanlayıcısını görüntüleyin (Köşeli parantez aktif olanı gösterir)
cat /sys/block/sda/queue/scheduler
# Çıktı: [mq-deadline] none kyber bfq

# Anlık olarak 'none' moduna geçirmek için:
echo "none" | sudo tee /sys/block/sda/queue/scheduler

Bu ayarı sunucu yeniden başladığında da korumak için /etc/udev/rules.d/60-io-scheduler.rules dosyasına aşağıdaki kuralı ekleyebilirsiniz:

# Sanal diskler (sd* ve vd*) için I/O scheduler'ı otomatik olarak 'none' yap
ACTION=="add|change", KERNEL=="sd[a-z]|vd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="none"

2. VMware ESXi ve KVM Katmanında Queue Depth (Kuyruk Derinliği) Darboğazı
Yüksek IOPS üreten veritabanı veya log/indeksleme (OpenSearch/Elasticsearch, Kafka) sunucularında disk gecikmelerinin (await) artmasının bir numaralı sebebi Queue Depth (Kuyruk Derinliği) limitleridir.
VMware ESXi Tarafı (PVSCSI & HBA):
ESXi üzerinde yüksek I/O trafiği olan sanal makinelerde varsayılan LSI Logic SAS yerine mutlaka VMware Paravirtual (PVSCSI) denetleyicisi kullanılmalıdır. Ancak PVSCSI’nin bile varsayılan cihaz kuyruk derinliği 64’tür. Yoğun anlarda bu kuyruk dolar ve ESXi seviyesinde QUED (Queue Latency) oluşur.
ESXi host üzerinde esxtop çalıştırıp d (disk adapter) veya u (disk device) tuşuna bastığınızda dikkat etmeniz gereken üç kritik metrik vardır:

• DAVG/cmd (Device Average Latency): HBA’dan fiziksel SAN ünitesine (Brocade SAN switch üzerinden Storage Array’e) gidip gelen süredir. All-Flash sistemlerde 1-2 ms altında olmalıdır. Yüksekse sorun SAN/Storage veya FC fabric tarafındadır.
• KAVG/cmd (Kernel Average Latency): İsteğin ESXi VMkernel kuyruğunda beklediği süredir. 0 ms’ye çok yakın olmalıdır. Eğer KAVG yükseliyorsa, LUN veya HBA Queue Depth sınırına takılıyorsunuz demektir.
• GAVG/cmd (Guest Average Latency): DAVG + KAVG toplamıdır; sanal makinenin gördüğü gerçek gecikmedir.

KVM / Proxmox VE Tarafı (virtio-scsi-single ve iothread):
KVM altyapılarında her sanal diskin kendi I/O iş parçacığına (thread) sahip olması için denetleyici tipi olarak VirtIO SCSI single seçilmeli ve disk ayarlarında iothread=1 ile aio=native (veya io_uring) aktif edilmelidir. Bu sayede vCPU’lar I/O kesmeleriyle (interrupts) bloklanmaz.
3. Linux Device-Mapper Multipath (multipathd) İnce Ayarı
Fiziksel Linux sunucularınızı veya KVM/Proxmox düğümlerinizi Fibre Channel (FC) veya iSCSI üzerinden yedekli (redundant) olarak SAN ünitelerine bağladığınızda dm-multipath devreye girer. Varsayılan multipath yapılandırmaları genellikle bağlantı koptuğunda I/O’yu çok uzun süre kuyrukta bekletir ve küme (cluster) servislerinin zaman aşımına uğramasına yol açar.
Kurumsal ortamlarda /etc/multipath.conf içinde mutlaka gözden geçirilmesi gereken parametreler:

defaults {
    user_friendly_names yes
    find_multipaths yes
    path_grouping_policy multibus
    # Yük dengeleme algoritması: 'service-time 0' anlık I/O yüküne göre en boş yolu seçer (round-robin'den çok daha verimlidir)
    path_selector "service-time 0"
    # Tüm yollar koptuğunda sonsuza kadar kuyrukta bekletmek yerine 12 deneme sonra üst katmana I/O hatası dön (Cluster failover için kritik!)
    no_path_retry 12
    polling_interval 5
}