Hastanenin kan bankasında açık kalp ameliyatına girecek kritik bir hasta için özel bir hazırlık yapıldığını düşünün. Cerrahi ekip kan bankasına gider, hastanın kan grubuyla tam eşleşen 4 ünite taze tam kanı rezerve eder, üzerine hastanın adını ve dosya numarasını yazar: "Bu kanlar yalnızca Ahmet Bey'in ameliyatı içindir, garantilidir, başka hiçbir hastaya verilemez!" Ameliyat başlar; göğüs kafesi açılır ve beklenmedik bir arteriyel kanama patlak verir. Cerrah panikle kan bankasına haber verir: "Rezerve ettiğimiz 4 ünite kanı derhal ameliyathaneye getirin!" Kan torbaları gelir; ancak cerrah dehşetle donakalır: Kan bankası memuru, hastaneye gelen diğer acil hastalara "Nasılsa Ahmet Bey henüz ameliyata girmedi" diyerek o torbalardan gizlice şırıngayla kan çekmiş, eksilen hacmi tamamlamak için de torbaların içine serum fizyolojik (tuzlu su) basmıştır! Torbanın içinde kan değil, seyreltilmiş boyalı su vardır! Hastaya oksijen taşıyacak alyuvar kalmamıştır; hasta masada hipovolemik şoktan hayatını kaybeder. Sorumsuz memurun savunması ise akıl almazdır: "Efendim torba doluydu, biz sadece boşta duran kısmı ödünç aldık!"

Sanal sunucu (VDS / Virtual Dedicated Server) pazarında satış afişlerine büyük harflerle "Kaynaklarınız %100 Dedicated! Size Özel Ayrılmış Garanti RAM!" yazan merdiven altı sağlayıcıların hipervizör düzeyinde Memory Ballooning (Bellek Balonlama) sürücüleriyle yaptığı şey, kan torbasından gizlice kan çeken bu memurun cüretinden farksızdır.

VDS ve "Garanti Kaynak" Efsanesi

Kullanıcılar VPS (Virtual Private Server) ile VDS (Virtual Dedicated Server) arasındaki farkı araştırdıklarında karşılarına şu tanım çıkar:

  • VPS: Kaynakların paylaşıldığı, komşulardan etkilenebilen sanal sunucu.
  • VDS: Kaynakların (özellikle RAM ve CPU'nun) hipervizör düzeyinde doğrudan fiziksel olarak ayrıldığı (Hardware Isolation), komşuların birbirini asla etkileyemediği güvenli sanal sunucu.

Bu tanım teorik olarak KVM veya VMware'in ideal konfigürasyonunda doğrudur. Birçok işletme ve yazılımcı da bu söze güvenerek normal VPS'in 2-3 katı para ödeyip "VDS" satın alır.

Ancak Türkiye'deki birçok açgözlü sağlayıcı için donanım satışı bir ahlak değil, bir sihirbazlık gösterisidir:
Ana fiziksel sunucuda (Host Node) toplamda 128 GB fiziksel ECC RAM vardır. Sağlayıcı müşterilere "16 GB Garanti RAM VDS" satar.
Kaç tane satar? 8 tane mi? Hayır!
Tam 20 tane satar!
Toplamda müşterilere vadedilen ve "garanti" edilen RAM: 320 GB! (Fiziksel kapasite: 128 GB).

Peki, olmayan bu 192 GB RAM hipervizörde nasıl varmış gibi gösterilir?
Cevap: VirtIO Memory Ballooning (Bellek Balonlama).

Memory Ballooning Mekanizması: Sanal Odadaki Canavar

Memory Ballooning, sanallaştırma teknolojisinde (KVM / QEMU / VMware) kaynak verimliliğini artırmak için geliştirilmiş meşru bir araçtır; ancak kötü niyetli sağlayıcıların elinde organize bir dolandırıcılık silahına dönüşür.

Sanal makinenizin işletim sisteminin (Ubuntu, Debian, AlmaLinux) içine bir hipervizör sürücüsü yüklenir: virtio_balloon.

Bu mekanizma şöyle çalışır:

[SİZİN SANAL SUNUCUNUZ (16 GB RAM Satın Aldınız)]
- İşletim sisteminiz ekranda "16 GB RAM" görür.
- Normal zamanda siteniz sadece 3 GB RAM tüketmektedir.
- Kalan 13 GB RAM boşta (Idle) beklemektedir.
         │
         ▼
[HİPERVİZÖR HOST NODE: FİZİKSEL RAM TÜKENDİ!]
Komşu sunucu aniden belleğe yüklendi. Ana makinede RAM bitti!
         │
         ▼
[BALON ŞİŞİRİLİYOR! (BALLOON INFLATE)]
1. Hipervizör sizin sanal makinenizdeki `virtio_balloon` sürücüsüne gizli emir verir:
   "Sanal makinenin içindeki 10 GB boş belleği kendi içine çek ve kitle!"
2. Balon sürücüsü sizin sanal RAM'inizin 10 GB'ını şişirerek içine çeker!
3. Çekilen o 10 GB fiziksel RAM, ana makine tarafından zorla elinizden alınır
   ve komşu sunucuya verilir!
         │
         ▼
[KRİZ ANI: SİZİN RAM'E İHTİYACINIZ OLDUĞUNDA]
Sitenize anlık trafik gelir. MySQL 6 GB RAM istemeye başlar.
İşletim sisteminiz bakar: "Benim 16 GB RAM'im vardı, neden bellek yok?!"
         │
         ▼
[LINUX KERNEL ÇÖKER: OOM KILLER DEVREYE GİRER!] ❌
Hipervizör balonu zamanında söndüremez (Deflate lag).
MySQL servisi anında öldürülür!

Patolojinin Semptomları: Çalınan Belleğin İzi

Bu kurgunun içinde yaşayan bir sistem yöneticisi şu akıl almaz belirtilerle karşılaşır:

  1. free -m Çıktısında Açıklanamayan Boşluk:
    Terminalde free -m yazarsınız. Toplam RAM 16 GB görünür. Kullanılan RAM 4 GB'tır. Ancak yeni bir Docker konteyneri ayağa kaldırmak istediğinizde veya MySQL büyük bir buffer havuzu açmaya çalıştığında sistem feryat eder: Cannot allocate memory!. Diskte ve bellekte yer varken sistem bellek tahsis edemez!
  2. Kswapd0 ve Ani CPU Patlamaları:
    Linux çekirdeği bellek bulamadığı için çılgınlar gibi takas alanı (Swap) aramaya başlar. kswapd0 çekirdek süreci CPU'yu %100'e kilitler. Sunucu donar kalır.
  3. Hipervizör Takılmaları (Balloon Lag):
    Balonun şişmesi ve sönmesi mikrosaniyelik bir işlem değildir. Sizin sitenize anlık 500 ziyaretçi girdiğinde o RAM'e o milisaniyede ihtiyacınız vardır. Balonun sönmesi 2 saniye gecikirse, Linux çekirdeği beklemez; doğrudan OOM Killer'ı devreye sokarak veritabanınızın boynunu vurur.

"Dedicated" Kelimesinin İğdiş Edilmesi

Müşteri destek bileti açar:
"Ben sizden VDS aldım. 'Dedicated RAM' dediniz. Neden MySQL servisim belleğe sığmayıp çöküyor?"

Sağlayıcının yanıtı yine o yüzsüz kurumsal jargonla gelir:
"Sayın müşterimiz, VDS paketlerimizde sanallaştırma KVM altyapısıyla sağlanmaktadır. Bellek yönetimimiz dinamik optimizasyon kurallarına göre dinamik olarak yönetilmektedir. Sunucunuzun anlık bellek ihtiyacı için swapfile oluşturmanızı veya bir üst paketimiz olan 32 GB VDS'e geçmenizi öneririz."

Müşteriye açıkça şunu söyleyemezler: "Biz sizin parasını ödediğiniz 16 GB RAM'i 3 farklı müşteriye daha sattık; siz kullanmıyorken komşunuza verdik, siz aniden isteyince de yetiştiremedik!"

Teşhis: Balonun Ağzını Yakalamak

Kendi sanal sunucunuzda Memory Ballooning kurbanı olup olmadığınızı anlamak için terminalde şu kontrolleri yapın:

# 1. VirtIO Balloon modülünün devrede olup olmadığını kontrol edin:
lsmod | grep balloon
 
# Çıktıda şunu görüyorsanız balon sürücüsü çalışıyordur:
# virtio_balloon         24576  0
 
# 2. Çekirdek bellek istatistiklerinde balon boyutunu inceleyin:
cat /sys/kernel/debug/virtio-ports/*/balloon_size 2>/dev/null || vmstat -m | grep -i balloon

Eğer sisteminizde virtio_balloon yüklüyse ve hipervizör bunu dinamik olarak kullanıyorsa; sözleşmenizde yazan "Garanti Dedicated RAM" ibaresi bir yalandan ibarettir.

Gerçek "Dedicated" RAM Nasıl Olmalıdır?

Gerçek ve kurumsal bir VDS sağlayıcısında hipervizör seviyesinde şu iki kural tavizsiz uygulanır:

  1. Zero Ballooning (Balonsuz Mimari):
    Hipervizörde sanal makine yapılandırılırken balloon aygıtı tamamen devre dışı bırakılır (<memballoon model='none'/>).
  2. Bellek Kilitleme (Memory Pre-allocation & Pinning):
    Sanal sunucu ayağa kalktığı anda, hipervizör ana makinenin fiziksel RAM bloklarından 16 GB'ı doğrudan ayırır ve kilitler (mlock çağrısı). Siz o belleği kullansanız da kullanmasanız da o 16 GB fiziksel RAM başka hiçbir komşuya verilemez.

Bu mimariyle çalışan bir sunucuda 1 baytlık bellek çalınması bile yaşanmaz. Fiyatı biraz daha yüksektir; ancak gece yarısı MySQL'inizin katledilmeyeceğinin tek gerçek teminatı budur.

Sonuç

Kan bankasında rezerve ettiğiniz kan torbasından gizlice kan çeken zihniyet hastanın katilidir; "Garanti RAM" satıp arka planda Memory Ballooning ile belleğinizi komşuya peşkeş çeken sağlayıcı da sistemlerinizin celladıdır.

Sözleşmelerdeki "Dedicated" kelimesine gözü kapalı güvenmeyin. Belleğinizi test edin, donanım izolasyonunu sorgulayın. Gerçek mühendislik boşlukta kalan kaynakları hırsız gibi aşırmak değil; müşterinin parasını ödediği her bir megabaytı bir emanet namusuyla kilit altında tutabilmektir.