DEV Community: Hakan İSMAİL

# HA Manager: Watchdog, Fencing ve Node Affinity (Modül 3)

Hakan İSMAİL — Mon, 17 Aug 2026 05:59:07 +0000

Seri: Proxmox VE Cluster ve Corosync

Modül 1'de bir node çökünce VM'in kendiliğinden hiçbir yerde açılmadığını göstermiştim; cluster kurmak otomatik yüksek erişilebilirlik demek değildi. Bu modülde o boşluğu dolduran parçaya geçiyorum: HA Manager. Watchdog tabanlı fencing'i, gerçek bir node çökmesinde recovery'nin saniye saniye nasıl işlediğini, ve bir node affinity kuralının beklediğimden çok daha proaktif davrandığını, hepsini gerçekten test ederek öğrendim.

Bu modülde her adımı hem terminalden hem web arayüzünden gösteriyorum; ikisi aynı API'yi kullanıyor, ama bazen birini görmek diğerini daha iyi anlamana yardımcı oluyor.

HA Manager Nedir?

Proxmox VE'nin HA stack'i, Pacemaker gibi harici bir araç gerektirmiyor; kendi başına çalışan bir çözüm. İki daemon var: pve-ha-lrm (Local Resource Manager), her node'da çalışıp o node'daki servisleri kontrol ediyor; pve-ha-crm (Cluster Resource Manager), cluster genelinde kararlar alıyor, sadece bir node'da aktif "master" olabiliyor.

Fencing, bir node arızalandığında onun gerçekten "offline" olduğundan emin olma süreci. Bu kritik, çünkü fence edilmemiş bir node hâlâ shared storage'a erişebiliyor olabilir; aynı VM'i başka bir node'da başlatmak, iki node'un aynı diske aynı anda yazmasına yol açabilir. Proxmox, harici fencing donanımı gerektirmeyen bir yöntem kullanıyor: watchdog timer tabanlı self-fencing. ha-manager, watchdog timer'ı düzenli olarak resetliyor; bir arıza nedeniyle bu reset gerçekleşmezse, timer node'u otomatik olarak reboot ediyor.

Burada altta yatan tasarım felsefesi ilginç: node'un "belki çalışıyordur, belki bozuktur" gibi belirsiz bir durumda kalmasına izin verilmiyor, doğrudan tam bir reboot'a zorlanıyor. Mantığı şu: bir node yarım yamalak, tutarsız bir durumda çalışmaya devam ederse (örneğin ağı kopmuş ama diski hâlâ yazabiliyorsa), bu durum veri bozulmasına yol açabilir; oysa node tamamen durursa, en azından zarar vermeye devam etmiyor. Yanlış çalışmaya devam etmektense hiç çalışmamak, burada bilinçli bir güvenlik tercihi.

Uygulama 1: Watchdog'u Doğrulamak

Nested lab'ımda donanım watchdog yok, Proxmox varsayılan olarak softdog kernel modülüne düşüyor:

cat /etc/default/pve-ha-manager

# select watchdog module (default is softdog)
#WATCHDOG_MODULE=ipmi_watchdog

Satır yorumlu, yani varsayılan (softdog) kullanılıyor. Doğrulamak için ilk denediğim komut boş döndü:

lsmod | grep watchdog

(boş çıktı)

Bir an modülün yüklü olmadığını düşündüm. Ama hata bendeydi: "softdog" kelimesi harfi harfine "watchdog" içermiyor. Doğrusu:

lsmod | grep dog

softdog                12288  2

Modül yüklü. /dev/watchdog ve /dev/watchdog0 cihazları da mevcuttu:

ls -la /dev/watchdog*

crw------- 1 root root  10, 130 Aug 15 07:41 /dev/watchdog
crw------- 1 root root 243,   0 Aug 15 07:41 /dev/watchdog0

Uygulama 2: VM'i HA'ya Eklemek

ha-manager add vm:100 --state started
ha-manager status

quorum OK
master pve-a (active, ...)
fencing armed (CRM watchdog active)
lrm pve-a (active, watchdog active, ...)
lrm pve-b (idle, watchdog standby, ...)
lrm pve-c (idle, watchdog standby, ...)
service vm:100 (pve-a, started)

Aynı işlem web arayüzünden de yapılabiliyor: Datacenter → HA → Resources.

"Add" butonuna basıp VM'i ve başlangıç durumunu (started) seçiyorsun:

Dikkat çeken bir detay: pve-a hem VM'i barındırıyor hem de CRM master'ı. Bu, sıradaki testi daha ilginç kılıyor; pve-a'yı çökertince sadece VM'in taşınıp taşınmayacağını değil, cluster'ın yeni bir master seçip seçemeyeceğini de gözlemleyeceğim.

Uygulama 3: Gerçek Bir Çökme, Saniye Saniye

Host'tan ping'i başlattım:

ping 192.168.122.251

Sonra pve-a'yı fiziksel host'tan çökerttim:

sudo virsh destroy pve-a

Ping çıktısı Modül 1/2'deki tanıdık deseni tekrarladı: önce sessiz paket kaybı, sonra gateway'in aktif "Destination Host Unreachable" demesi.

İlk kontrolüm (çökmeden ~10 saniye sonra), pve-b'den:

ha-manager status

quorum OK
master pve-c (active, ...)
fencing armed (CRM watchdog active)
lrm pve-a (active, watchdog active, ...)
lrm pve-b (idle, watchdog standby, ...)
lrm pve-c (idle, watchdog standby, ...)
service vm:100 (pve-a, started)

Yeni master seçimi hızlı gerçekleşmişti (master pve-c olmuştu), ama VM henüz taşınmamıştı; bu, sürecin ortasında bir "anlık fotoğraf". Birkaç dakika sonra aynı komutu tekrar çalıştırdım:

ha-manager status

quorum OK
master pve-c (active, ...)
fencing armed (CRM watchdog active)
lrm pve-a (old timestamp - dead?, watchdog standby, ...)
lrm pve-b (active, watchdog active, ...)
lrm pve-c (idle, watchdog standby, ...)
service vm:100 (pve-b, started)

VM gerçekten pve-b'ye taşınmış. lrm pve-a'nın durumu da ilginçti: sistem bile kesin konuşmuyor, "old timestamp - dead?" diye soru işaretiyle yazıyor.

Tam Zaman Çizelgesi

Tahmin etmek yerine pve-c'nin (master) CRM loglarına baktım:

journalctl -u pve-ha-crm --since "19:46:00" --until "19:50:00"

19:46:53  node 'pve-a': state changed from 'online' => 'unknown'
19:47:43  service 'vm:100': state changed from 'started' to 'fence'
19:47:43  node 'pve-a': state changed from 'unknown' => 'fence'
19:48:43  successfully acquired lock 'ha_agent_pve-a_lock'
19:48:43  fencing: acknowledged - got agent lock for node 'pve-a'
19:48:43  service 'vm:100': state changed from 'fence' to 'recovery'
19:48:43  recover service 'vm:100' from fenced node 'pve-a' to node 'pve-b'
19:48:43  service 'vm:100': state changed from 'recovery' to 'started'  (node = pve-b)

pve-a'yı çökerttiğim an ~19:46:33'tü. Üç net faz ortaya çıktı:

Algılama (~20 saniye): çökme → online => unknown (19:46:53). Corosync'in kaybı fark edip CRM'e bildirmesi.

Fence kararı (tam 50 saniye): unknown → fence (19:47:43). Muhtemelen ani bir yanlış pozitiften kaçınmak için bekletilen bir politika süresi.

Watchdog güvenlik beklemesi (tam 60 saniye): fence → lock alındı, VM pve-b'de başladı (19:48:43). Bu rakam tesadüf değil; watchdog'un kendi kendini resetleyeceği tam süreyi (tipik 60 saniye) bekliyor, "belki node hâlâ hayatta ve VM'i çalıştırıyordur" ihtimalini sıfırlıyor.

Toplam: ~130 saniye (virsh destroy'dan VM'in yeni node'da çalışmasına kadar).

Uygulama 4: Double-Start'ın Yapısal Olarak İmkansız Olduğunu Kanıtlamak

En kritik soru: pve-a geri gelince VM'i ikinci kez başlatmaya çalışacak mı? İki node'un aynı diske aynı anda yazması gerçek bir felaket senaryosu olurdu.

sudo virsh start pve-a

Boot tamamlandıktan sonra, pve-a'da:

qm status 100

Configuration file 'nodes/pve-a/qemu-server/100.conf' does not exist

Bu, Modül 1'de gördüğüm birebir aynı hata mesajı, ama tamamen farklı bir anlamda. Modül 1'de bu, "kimse bu VM'i başlatmayacak" demekti. Burada ise: fencing + recovery süreci, VM'in config dosyasını pmxcfs üzerinden gerçekten pve-b'nin dizinine taşımış. pve-a'da böyle bir dosya artık hiç yok. Bu, double-start'ı sadece "önlenmiş" değil, yapısal olarak imkansız kılıyor: pve-a geri gelse bile, elinde VM'i başlatacak bir config bile bulamıyor.

Bunu iki node'dan bağımsız olarak doğruladım. pve-b'de:

pvecm status
ha-manager status

Nodes:            3
Quorate:          Yes
Total votes:      5
Quorum:           3
Flags:            Quorate Qdevice
...
quorum OK
master pve-c (active, ...)
fencing armed (CRM watchdog active)
lrm pve-a (idle, watchdog standby, ...)
lrm pve-b (active, watchdog active, ...)
lrm pve-c (idle, watchdog standby, ...)
service vm:100 (pve-b, started)

pve-a'da, aynı anda:

pvecm status
ha-manager status

Nodes:            3
Quorate:          Yes
Total votes:      5
Quorum:           3
Flags:            Quorate Qdevice
...
quorum OK
master pve-c (active, ...)
fencing armed (CRM watchdog active)
lrm pve-a (idle, watchdog standby, ...)
lrm pve-b (active, watchdog active, ...)
lrm pve-c (idle, watchdog standby, ...)
service vm:100 (pve-b, started)

Birebir tutarlı: 5 oy, 3 node, vm:100 (pve-b, started), fencing armed. lrm pve-a, hiçbir manuel müdahale gerekmeden, kendiliğinden "old timestamp - dead?" durumundan "idle"a döndü.

Uygulama 5: Node Affinity, Beklediğimden Daha Proaktif

Her şey sağlıklıyken, VM'in tercihen pve-a'da kalmasını söyleyen bir kural tanımladım:

ha-manager rules add node-affinity prefer-pve-a --resources vm:100 --nodes pve-a

Aynı işlem web arayüzünden: Datacenter → HA → Rules.

"Add" → "Node Affinity Rule" diyip kaynağı ve tercih edilen node'u seçiyorsun:

Beklentim şuydu: bu kural sadece bir sonraki arıza/recovery anında devreye girer, halihazırda sağlıklı çalışan bir servisi kendiliğinden taşımaz. Yanılmışım.

Kuralı ekledikten saniyeler sonra, tekrar baktığımda:

ha-manager status

service vm:100 (pve-b, migrate)

VM zaten taşınmaya başlamıştı; hem de fence ya da relocate değil, migrate durumunda; yani VM durdurulup yeniden başlatılmadı, gerçek bir canlı migration tetiklendi. ~25-30 saniye sonra, tekrar:

ha-manager status

service vm:100 (pve-a, started)

Tamamlanmıştı. Hiçbir arıza olmadan, ben sadece bir tercih tanımladığım için, HA Manager kendiliğinden mevcut durumu istenen duruma yakınsatmış. Bu, HA Manager'ın sadece reaktif (arızaya tepki veren) değil, aynı zamanda proaktif (deklare edilen tercihe kendiliğinden yaklaşan) bir sistem olduğunu gösterdi; bunu önceden bilmiyordum, test etmeden öğrenemezdim.

Son doğrulama:

qm status 100

status: running

pvecm status
ha-manager status
ha-manager rules list

Nodes:            3
Quorate:          Yes
Total votes:      5
Quorum:           3
...
service vm:100 (pve-a, started)
...
┌──────────────┐
│ rule         │
╞══════════════╡
│ prefer-pve-a │
└──────────────┘

Tamamen tutarlı: VM çalışıyor, cluster quorate, kural hâlâ kayıtlı.

Genel Değerlendirme

Bu modülde üç şey beni özellikle şaşırttı.

Birincisi, fencing'in üç net fazlı, toplamda ~130 saniyelik bir süreç olması. "HA var, arıza olunca hemen düzelir" gibi belirsiz bir beklentim vardı; gerçekte sistem, her biri ayrı bir amaca hizmet eden (algılama, yanlış pozitiften kaçınma, watchdog güvenlik payı) üç ayrı bekleme süresinden geçiyor. Bu, hız değil, güvenlik önceliğiyle tasarlanmış bir sistem.

İkincisi, pve-a'nın config dosyasının gerçekten pve-b'ye taşınmış olması. Double-start korumasını "kilitli bir mekanizma" gibi hayal etmiştim; gerçekte çok daha basit ve zarif: VM'i başlatacak bilgi artık orada yok, o yüzden başlatılamıyor.

Üçüncüsü, node affinity kuralının proaktif davranışı. Bu, testin planımı tersine çevirdiği bir andı; "muhtemelen böyle çalışır" diye düşünüp geçebilirdim, ama gerçekten test edince tam tersini gördüm. Modül 2'de de benzer bir şey olmuştu (split-brain'i tetiklemeye çalışıp başaramamak); bu serinin tekrar eden bir teması gibi görünüyor: varsayımlarım, gerçek testlerden daha az güvenilir çıkıyor.

Bir sonraki modülde, HA Manager'ı biraz daha zorlayacağım: birden fazla VM ile resource affinity kurallarını (aynı node'da tutma/ayrı tutma), ve CRS'in (Cluster Resource Scheduler) yük dengeleme davranışını test edeceğim.

Bu seri, resmi Proxmox VE dokümantasyonundan (pve.proxmox.com) derleniyor. Buradaki gözlemler bir homelab ortamına dayanıyor; production kararları için resmi dokümantasyon ve deneyimli sistem yöneticileri referans alınmalıdır.

Quorum Kaybını Tetiklemek, QDevice Kurmak ve Shared Storage'a Geçmek (Modül 2)

Hakan İSMAİL — Fri, 14 Aug 2026 07:03:26 +0000

Seri: Proxmox VE Cluster ve Corosync

Modül 1'de cluster'ı kurdum, canlı migration'ın çalıştığını kanıtladım, ve bir node çökünce VM'in kendiliğinden başka bir yerde açılmadığını gösterdim. Bu modülde asıl arkasındaki mekanizmaya iniyorum: quorum. Ne zaman kaybediliyor, pmxcfs'i nasıl etkiliyor, QDevice bu denklemi nasıl değiştiriyor, ve "quorum'u zorla" demenin (pvecm expected) gerçekten ne kadar tehlikeli olduğunu, kendim tetiklemeye çalışarak öğrendim. Sona da, Modül 1'de yarım kalan bir şeyi tamamladım: gerçek bir shared storage kurup, migration'ın --with-local-disks olmadan nasıl çalıştığını gösterdim.

Bu modülde bir hipotezimin yanlış çıktığını da saklamayacağım; yanlış çıkması, doğru sonuçtan daha fazla şey öğretti.

Quorum Nedir, Neden Var?

Quorum, dağıtık bir sistemde bir işlemi (özellikle konfigürasyon değişikliği) gerçekleştirmek için gereken minimum oy sayısı. Proxmox VE'de her node varsayılan olarak bir oy taşıyor. Formül basit: quorum = floor(toplam_oy / 2) + 1. Ağ bölünmesi (partition) olduğunda, sadece çoğunluğa sahip taraf işlemeye devam edebiliyor; bu, split-brain'i (iki tarafın da "ben doğruyum" deyip aynı kaynağı bağımsız yönetmeye çalışmasını) önlüyor.

3 node'lu cluster'ımızda quorum eşiği 2 (3'ün çoğunluğu). Bir node izole olursa, kalan iki node çoğunluğu oluşturduğu için çalışmaya devam ediyor; izole olan tek node ise azınlıkta kalıp durabiliyor.

Uygulama 1: Quorum Kaybını Gerçekten Tetiklemek

Bunu Modül 1'deki node çökertme testinden farklı yapmak istedim: orada tüm node'u (virsh destroy) öldürmüştüm, burada sadece Corosync ağını kesip node'u canlı tutuyorum; management ağı hâlâ açık, SSH ile erişebiliyorum.

Fiziksel host'tan pve-c'nin corosync-net arayüzünü düşürdüm:

sudo virsh domif-setlink pve-c vnet15 down

pve-c'de:

pvecm status

Nodes:            1
Quorate:          No
Total votes:      1
Quorum:           3 Activity blocked

Beklendiği gibi: tek başına kalan pve-c, quorum eşiğini (3, bu noktada QDevice henüz yoktu) karşılayamıyor.

pmxcfs'e yazmayı denedim:

touch /etc/pve/test-readonly.txt

touch: cannot touch '/etc/pve/test-readonly.txt': Permission denied

Modül 1'de gördüğüm "read-only file system" davranışının bir başka görünümü; burada hata mesajı farklı (Permission denied vs Read-only file system) ama sonuç aynı: quorum'suz bir node, konfigürasyona yazamıyor.

Çoğunluk tarafında (pve-a, iki node) durum farklıydı: Quorate: Yes olarak kaldı, hiç kesinti yaşamadı. Bu, quorum mekanizmasının tam olarak tasarlandığı gibi çalıştığının kanıtı: azınlık durur, çoğunluk devam eder.

Ağı geri açtım (up), birkaç saniye içinde cluster kendiliğinden 3/3 quorate'e döndü.

Uygulama 2: QDevice'i Devreye Almak

qdevice-1 VM'ine Modül 0'da zaten corosync-qnetd paketini kurmuştum, ama hiç yapılandırmamıştım. Şimdi gerçekten devreye alma zamanı.

Beklenmedik Uyarı: Odd Node Count

pvecm qdevice setup 192.168.122.20

Clusters with an odd node count are not officially supported!

Bu beni şaşırttı. Araştırınca öğrendim: pvecm, node sayısı tek olduğunda varsayılan olarak duruyor. Sebep, QDevice'in iki farklı algoritması var: çift node sayısı için varsayılan ffsplit (her node'a eşit davranıp QDevice'e her zaman tam 1 oy veren), tek node sayısı için ise --force ile devreye giren lms (Last Man Standing). 3 node'lu cluster'ım tek sayı olduğu için bu uyarıyı tetikledi.

pvecm qdevice setup 192.168.122.20 --force

Bu sefer kurulum tamamlandı: sertifikalar üç node'a da dağıtıldı, corosync-qdevice.service her node'da otomatik enable + start edildi.

`lms` Algoritmasının Etkisini Doğrulamak

pvecm status

Expected votes:   5
Total votes:      5
Quorum:           3
Membership information
    Nodeid      Votes    Qdevice Name
0x00000001          1    A,V,NMW 10.10.10.11
0x00000002          1    A,V,NMW 10.10.10.12
0x00000003          1    A,V,NMW 10.10.10.13 (local)
0x00000000          2            Qdevice

Burada dikkatimi çeken şey: Qdevice satırında 2 oy var, 1 değil. ffsplit'te QDevice her zaman 1 oy verirken, lms'de N-1 oy veriyor (N = node sayısı). Bizim durumumuzda 3-1=2. corosync.conf'a bakınca bunu doğruladım:

quorum {
  device {
    model: net
    net {
      algorithm: lms
      host: 192.168.122.20
      tls: on
    }
  }
}

Toplam matematik: 3 node × 1 + QDevice × 2 = 5 oy, quorum eşiği 3.

Uygulama 3: QDevice'in Değerini Kanıtlamak

Modül 1'de, tek bir node çoğunluğu asla oluşturamıyordu. QDevice'in asıl var oluş sebebi, bunu belirli senaryolarda değiştirmek. Test ettim: iki node'u aynı anda çökerttim.

sudo virsh destroy pve-b
sudo virsh destroy pve-c

Tek kalan pve-a'da:

pvecm status

Nodes:            1
Total votes:      3
Quorum:           3
Quorate:          Yes

Matematik: pve-a (1 oy) + QDevice (2 oy) = 3, eşik de 3. Quorate: Yes. QDevice olmadan bu imkansız olurdu; tek bir node kendi başına asla çoğunluk oluşturamaz.

Kanıtı tamamlamak için:

touch /etc/pve/qdevice-test.txt

Başarılı oldu; dosya /etc/pve altında göründü. Modül 1'deki "tek node = read-only" bulgusunun tam tersi; burada tek node ama QDevice sayesinde quorate, pmxcfs yazılabilir.

İki node'u da geri getirdim, birkaç dakika içinde cluster tam olarak (5 oy, 3 node) toparlandı.

Uygulama 4: Split-Brain'i Tetiklemeye Çalışmak

pvecm expected komutu, bir node'u zorla "quorate" göstermenin bir yolu; teoride tehlikeli, çünkü izole bir node kendini haklı sanıp bağımsız kararlar almaya başlayabilir. Bunu bilerek tetiklemeye çalıştım.

İlk Deneme: Yanlış Anlaşılan Bir Hata

pve-c'yi izole ettim, ama down komutundan hemen sonra yanlışlıkla up'ı da çalıştırdım; izolasyon çok kısa sürdü. pve-c'de:

pvecm expected 1

Hiçbir hata almadım, ama sonraki denemede (hem pve-c'de hem pve-a'da):

Unable to set expected votes: CS_ERR_INVALID_PARAM

İlk başta bunun QDevice'e özgü bir kısıtlama olduğunu düşündüm. Yanılmışım. Gerçek sebep daha basit: votequorum_setexpected API'si, sadece zaten quorum'suz olan bir partition'ı kurtarmak için çalışıyor; zaten quorate olan bir partition'ın oy eşiğini manuel düşürmene izin vermiyor. Bizim denemelerimiz, node zaten (kısa izolasyondan sonra ya da QDevice'in sağladığı fazladan oyla) quorate durumdayken yapıldığı için reddedildi. Bu, QDevice'in özel bir davranışı değil, corosync'in her zaman var olan bir güvenlik kuralı.

İkinci Deneme: Doğru İzolasyon

Bu sefer pve-c'yi gerçekten izole tuttum, geri açmadım:

sudo virsh domif-setlink pve-c vnet15 down

pve-c'de doğruladım:

Nodes:            1
Quorate:          No
Total votes:      1
Quorum:           3

Gerçekten quorum'suz. Şimdi:

pvecm expected 1
pvecm status

Beklenmedik bir şey oldu:

Expected votes:   3
Quorum:           2
Quorate:          No

1 istedim, sistem 3 verdi. Ve pve-c (1 oy) bu yeni eşiği (2) bile karşılayamadığı için Quorate: No kaldı, touch yine Permission denied verdi.

Bu Neden Oldu?

Bunu araştırdım. Proxmox'un kurucu geliştiricilerinden Thomas Lamprecht, 2018 tarihli bir mailing list yazışmasında Corosync'in expected_votes davranışını şöyle açıklıyor:

"Highest expected can not be smaller then the actual online quorate nodes."

Yani Corosync, expected_votes değerini online ve quorate node sayısının altında tutmuyor. Thomas'ın verdiği örneğe göre, manuel olarak expected_votes: 16 ayarlanmışsa ve 28 node online/quorate durumdaysa, Corosync 16 yerine 28'i kullanıyor. Bunu kabaca şu şekilde ifade ediyor:

expected = max(user_set_expected, #nodes_quorate_online)

Ancak online/quorate node sayısı manuel olarak belirlenen değere eşit veya daha düşükse, Corosync'in bu değeri koruması mümkün. Thomas ayrıca last_man_standing etkinleştirildiğinde, yeterli node kaldığı sürece belirli bir süre sonunda highest expected değerinin aşağı doğru yeniden hesaplanabileceğini belirtiyor. Proxmox Lists

Bunun QDevice'in lms algoritmasından kaynaklandığını düşünüyorum; muhtemelen QDevice'in oy hesaplaması sağlıklı kalabilsin diye expected_votes'un cluster'da tanımlı gerçek node sayısının (3) altına hiç düşürülmesine izin verilmiyor, o an kaç node'un online olduğundan bağımsız olarak. Ama bunu kaynak koda bakmadan kesin olarak iddia edemem; bu, dokümante edilmiş bir davranıştan çok, gözlemlenip mantıklı görünen bir çıkarım.

Sonuç ne olursa olsun, pratik etkisi net: split-brain'i kasıtlı olarak tetiklemeye çalıştım, QDevice'li ortamda başaramadım.

Toparlamak

pvecm expected 5
sudo virsh domif-setlink pve-c vnet15 up

Birkaç saniye sonra cluster tam olarak (5 oy, 3 node, Quorate: Yes) geri döndü.

Uygulama 5: Shared Storage ile Migration'ı Yeniden Denemek

Modül 1'de canlı migration'ı test ederken --with-local-disks flag'ini kullanmak zorunda kalmıştım; çünkü VM'in diski shared storage'da değil, sadece kaynak node'un yerel LVM'sindeydi. Bir arkadaşımın önerisiyle bunu düzeltmeye karar verdim: gerçek bir SAN/NAS kurmak yerine, kendi laptop'umu (CachyOS host) NFS sunucusu olarak kullanıp bunu üç node'a paylaşımlı storage olarak eklemek.

Baştan söylemek isterim: bu, gerçek bir shared storage değil, homelab için taklit edilmiş bir tanesi. Kullandığım no_root_squash ve insecure export seçenekleri, gerçek bir ortamda asla böyle bırakılmaz; root'un uzaktan tam yetkiyle yazmasına izin veriyor, güvenlik açısından savunmasız. Burada sadece lab kolaylığı için var.

NFS Sunucusunu Host'ta Kurmak

CachyOS (Arch tabanlı) olduğu için paket ismi Debian'dan farklı; tek paket hem sunucu hem client araçlarını içeriyor:

sudo pacman -S nfs-utils
sudo mkdir -p /srv/nfs/proxmox-shared
sudo chown nobody:nobody /srv/nfs/proxmox-shared
sudo chmod 777 /srv/nfs/proxmox-shared

/etc/exports:

/srv/nfs/proxmox-shared 192.168.122.0/24(rw,sync,no_subtree_check,no_root_squash,insecure)

sudo systemctl enable --now rpcbind nfs-server
sudo exportfs -arv

Beklenmedik Engel: Firewall

İlk mount denemesi pve-a'dan başarısız oldu:

mount.nfs: Connection refused for 192.168.122.1:/srv/nfs/proxmox-shared on /mnt/test-nfs

Servisler çalışıyordu, export tanımlıydı, portlar (2049, 111) dinliyordu; sorun firewalld'ın aktif olmasıydı:

sudo firewall-cmd --get-active-zones

libvirt
  interfaces: virbr-coro virbr0

virbr0 (management) ve virbr-coro (corosync-net) ikisi de libvirt zone'undaydı, ama bu zone'a NFS servisleri hiç eklenmemişti:

sudo firewall-cmd --permanent --zone=libvirt --add-service=nfs
sudo firewall-cmd --permanent --zone=libvirt --add-service=rpc-bind
sudo firewall-cmd --permanent --zone=libvirt --add-service=mountd
sudo firewall-cmd --reload

Bu düzeltmeden sonra manuel mount çalıştı, touch ve ls başarılı oldu.

Proxmox'a Eklemek ve Disk Taşımak

pvesm add nfs nfs-shared --server 192.168.122.1 --export /srv/nfs/proxmox-shared --content images

Name              Type     Status     Total (KiB)      Used (KiB) Available (KiB)        %
nfs-shared         nfs     active       486256640        72509440       412091392   14.91%

VM 100'ün diskini taşıdım:

qm move-disk 100 scsi0 nfs-shared

Beklenmedik Bir Detay: Hayalet Disk Referansı

İlk migration denemesinde (pve-b'den pve-c'ye) log'da hâlâ "copying local disk images" adımı çıktı, 8GB'lık bir kopyalama yaptı; disk zaten NFS'te olması gerekirken. qm config 100'e baktığımda sebebi gördüm:

scsi0: nfs-shared:100/vm-100-disk-0.raw,...
unused0: local-lvm:vm-100-disk-0

move-disk diski gerçekten NFS'e taşımıştı, ama eski local-lvm referansını unused0 olarak arkada bırakmıştı. Migration da bağlı her diski (kullanılan/kullanılmayan farketmeksizin) taşımaya çalıştığı için bu hayalet referansı da kopyalamıştı. lvremove ile temizlemeye çalışınca üç node'da da "Failed to find logical volume" hatası aldım; migration'ın kendisi log'un sonunda zaten Logical volume "vm-100-disk-0" successfully removed demişti, yani gerçek disk çoktan silinmişti, sadece config'te unutulmuş bir referans kalmıştı:

qm unlink 100 --idlist unused0

Temiz Migration: Öncesi/Sonrası

Hayalet referans temizlendikten sonra tekrar denedim (pve-c'den pve-a'ya):

2026-08-14 09:06:34 starting migration of VM 100 to node 'pve-a'
2026-08-14 09:06:34 starting VM 100 on remote node 'pve-a'
2026-08-14 09:06:36 starting online/live migration
2026-08-14 09:06:37 average migration speed: 1.0 GiB/s - downtime 15 ms
2026-08-14 09:06:37 migration completed, transferred 158.5 MiB VM-state
2026-08-14 09:06:39 migration finished successfully (duration 00:00:05)

"Copying local disk images" adımı tamamen yok; disk hiç dokunulmadı, sadece VM'in bellek durumu (158.5 MiB) taşındı.

	Modül 1 (local disk, `--with-local-disks`)	Bu test (NFS shared storage)
Disk kopyalama	Var, ~8 GB, ~13 saniye	Yok
Toplam süre	~20 saniye	~5 saniye
Downtime	43 ms	15 ms
Taşınan veri	Disk + VM state	Sadece VM state (158.5 MiB)

Ping testi bu sırada da kesintisizdi; 40'tan fazla paket, hiç kayıp yok, gecikme 0.3-1.3ms aralığında sabit kaldı.

Bu karşılaştırma, --with-local-disks'in neden var olduğunu somutlaştırdı: o flag olmadan disk paylaşımlı değilse migration mümkün değil; flag'in kendisi de aslında bir kısayol değil, "diski de taşımak zorundayım çünkü paylaşımlı değil" itirafı. Gerçek shared storage'da bu ihtiyaç tamamen ortadan kalkıyor, migration da doğal olarak hızlanıyor.

Genel Değerlendirme

Bu modülde planladığımdan farklı bir sona vardım. Amacım split-brain riskini göstermekti; onun yerine, QDevice'in bu riski nasıl engellediğini gösterdim. Sanırım bu, orijinal planımdan daha iyi bir sonuç.

En çok üzerinde durduğum üç nokta:

Birincisi, ffsplit ve lms arasındaki oy farkı (1 vs N-1). Bu küçük bir detay gibi görünüyor ama gerçek bir kararı etkiliyor: tek sayılı bir cluster'da QDevice'in matematiği, çift sayılı bir cluster'dakinden temelden farklı çalışıyor.

İkincisi, pvecm expected'in "zaten quorate olan bir partition'ı düşüremezsin" kuralı. İlk denemem bu yüzden başarısız oldu, ve bunu QDevice'e yanlış bağladım; doğrusunu bulmak için araştırmam gerekti. Yanlış bir hipotezle başlayıp onu düzeltmek, doğru hipotezle başlamaktan daha çok şey öğretti.

Üçüncüsü, ikinci (doğru) denemede gördüğüm 1'den 3'e yuvarlanma. Bunun tam mekanizmasını hâlâ %100 kesinlikle açıklayamıyorum; genel corosync davranışı bunu tam karşılamıyor, QDevice'e özgü bir şey olduğunu düşünüyorum ama kaynak koda inmeden kesin konuşamam. Bu belirsizliği olduğu gibi bırakmayı, uydurma bir kesinlik sunmaya tercih ettim.

Sonuç olarak: quorum kaybını gerçekten tetikledim, pmxcfs'in read-only davranışını iki farklı şekilde (host çökmesi, ağ izolasyonu) doğruladım, QDevice'i kurdum ve onun olmadan imkansız olacak bir senaryoyu ayakta tuttum, split-brain'i kasıtlı olarak tetiklemeye çalışıp başaramadım, ve son olarak Modül 1'deki --with-local-disks zorunluluğunu shared storage kurarak ortadan kaldırdım. Bu son kısım kendi başına küçük bir hikaye oldu: NFS kurulumu, firewall'ın gerçek engel olduğunu bulmam, ve migration'ın arkada bıraktığı hayalet disk referansını çözmem; hiçbiri planladığım gibi sorunsuz gitmedi, ama her biri gerçek bir öğrenme anıydı.

Bir sonraki modülde HA Manager'a geçiyorum: watchdog tabanlı fencing, node/resource affinity kuralları, ve Modül 1'de gördüğümüz "VM kendiliğinden açılmadı" sonucunu bu sefer tersine çevirmek.

Bu seri, resmi Proxmox VE dokümantasyonundan (pve.proxmox.com) ve topluluk kaynaklarından (pve-user mailing list, corosync/votequorum man sayfaları) derleniyor. Buradaki gözlemler bir homelab ortamına dayanıyor; production kararları için resmi dokümantasyon ve deneyimli sistem yöneticileri referans alınmalıdır.

# Proxmox Cluster Kurmak: Kavramlar, GUI/CLI ve Gerçek Hatalar (Modül 1)

Hakan İSMAİL — Tue, 11 Aug 2026 06:06:19 +0000

Seri: Proxmox VE Cluster ve Corosync

Modül 0'da dört sanal makineyi (pve-a, pve-b, pve-c, qdevice-1) kurdum, ağlarını yapılandırdım ve birbirlerine ulaşabildiklerini doğruladım. Lab artık hazır. Bu modüld asıl kavramlara ve gerçek cluster kurulumuna geçiyorum: pvecm, Corosync ve pmxcfs nedir, ne işe yarar, ve cluster'ı hem GUI'den hem CLI'dan kurunca neler yaşadım.

Bu modülde işleri bilerek iki farklı yoldan yaptım: cluster'ı web arayüzünden oluşturdum, bir node'u terminalden, bir node'u web arayüzünden kattım. Amaç sadece "iki yöntem de mümkün" demek değildi; iki yöntemi karıştırınca ortaya çıkan gerçek bir hatayı da görmek istedim, ve gördüm.

Neden Cluster?

Tek bir Proxmox node'u zaten kendi başına çalışan bir hipervizör; web arayüzü var, VM/container yönetimi var. Cluster, birden fazla node'u bir araya getirip merkezi bir yönetim deneyimi sunuyor: tek bir web arayüzünden tüm node'ları yönetmek, VM'leri node'lar arası taşımak, ortak firewall ve HA politikaları tanımlamak.

Mimari olarak dikkat çeken bir nokta var: Proxmox cluster'ı multi-master. Yani tek bir "merkezi yönetim sunucusu" yok; her node, cluster'ın tamamını yönetebilecek yetkiye sahip. Bu, VMware'in vCenter'ı gibi ayrı bir yönetim katmanına ihtiyaç duymuyor; yönetim mantığı doğrudan node'ların kendisine gömülü.

Üç Parça: pvecm, Corosync, pmxcfs

pvecm, cluster'ı yönetmek için kullandığım komut satırı aracı. Node oluşturma, ekleme, çıkarma, durum sorgulama gibi işlemler buradan geçiyor. Web arayüzünün "Cluster" sekmesi de aslında aynı işlemleri, aynı API üzerinden yapıyor; ikisi farklı arayüz, aynı motor.

Corosync Cluster Engine, node'lar arası güvenilir grup iletişimini sağlayan alt katman. Hem pvecm hem web arayüzü bunun üzerine kurulu. Node sayısında sert bir teknik sınır yok; pratikte ağ ve donanım performansı sınırlıyor, üst düzey donanımla 50'den fazla node'lu production cluster'lar bile rapor edilmiş.

pmxcfs (Proxmox Cluster File System), /etc/pve altında mount edilen, FUSE tabanlı bir dosya sistemi. Cluster'daki tüm konfigürasyon dosyaları burada tutuluyor ve Corosync üzerinden tüm node'lara gerçek zamanlı olarak replike ediliyor. En kritik davranışı şu: node quorum'u kaybettiğinde bu dosya sistemi read-only'e geçiyor.

Uygulama 1: pmxcfs'i Kümelenmeden Önce Gözlemlemek

Cluster'ı kurmadan önce, pve-a üzerinde henüz tek başınayken pmxcfs'e baktım.

systemctl status pve-cluster

Servis active (running), pmxcfs process'i çalışıyor. Log satırlarında ilginç bir detay vardı:

pmxcfs[806]: [main] notice: resolved node name 'pve-a' to '192.168.122.11' for default node IP address

pmxcfs, node adını çözümlerken management ağının IP'sini (192.168.122.11) varsayılan olarak almış. Bu gözlem, ileride başıma geleceklerin habercisi oldu; birazdan neden önemli olduğunu göreceğiz.

ls -la /etc/pve/nodes/

/etc/pve/nodes/ dizininde sadece pve-a'yı gördüm; bu, "öncesi" fotoğrafıydı.

Uygulama 2: Cluster'ı Kurmak

Cluster'ı GUI'den Oluşturmak

pve-a'nın web arayüzünden Datacenter → Cluster → Create Cluster dedim, isim olarak lab-cluster verdim, Link 1 için corosync-net arayüzünü (10.10.10.11) seçtim. İşlem birkaç saniyede tamamlandı.

Hata: TLS Sertifika Doğrulaması

pve-b'yi katılırken ilk aklıma gelen, doğrudan corosync-net IP'sini (10.10.10.11) hedef göstermekti. Mantığım şuydu: bu ağı zaten Corosync trafiği için ayırmıştım, cluster'a katılma işlemi de bir "cluster" işlemiydi, o yüzden bu IP'yi kullanmak bana doğru geldi.

pvecm add 10.10.10.11 --link1 10.10.10.12

Establishing API connection with host '10.10.10.11'
The authenticity of host '10.10.10.11' can't be established.
X509 SHA256 key fingerprint is FF:59:FA:...
Are you sure you want to continue connecting (yes/no)? yes
500 Can't connect to 10.10.10.11:8006 (hostname verification failed)

Meğerse yanılmışım. pvecm add'in ilk parametresi, Corosync trafiği değil; pve-a'nın API'sine (:8006 portu, yani web arayüzünün kendisi) HTTPS üzerinden bağlanıp "beni bu cluster'a ekle" demek. Bu, Uygulama 1'de gördüğüm pmxcfs gözlemiyle doğrudan bağlantılıydı: pve-a'nın self-signed sertifikası, management IP/hostname için üretilmiş. pve-b, 10.10.10.11 üzerinden bu API'ye bağlanmaya çalışınca sertifika o adresi tanımıyor, hostname doğrulaması çöküyor.

Yani karıştırdığım şey şuydu: corosync-net'in var olma amacı (Corosync'in kendi trafiği) ile join işleminin gerçekte ne olduğu (bir API çağrısı) aynı şey değil. --link1 parametresi zaten Corosync trafiğinin hangi arayüzden gideceğini ayrıca belirtiyor; ilk parametrenin de aynı ağdan olması gerekmiyor, çünkü o bambaşka bir iletişim katmanı.

Doğrusu, join/API bağlantısı için management IP'yi, Corosync trafiği için --link1'i ayrı ayrı kullanmaktı:

pvecm add 192.168.122.11 --link1 10.10.10.12

Join request OK, finishing setup locally
stopping pve-cluster service
backup old database to '/var/lib/pve-cluster/backup/config-1786335821.sql.gz'
waiting for quorum...OK
(re)generate node files
generate new node certificate
merge authorized SSH keys
generated new node certificate, restart pveproxy and pvedaemon services
successfully added node 'pve-b' to cluster.

Çalıştı. pve-b cluster'a katıldı.

`pve-c`'yi GUI'den Katılmak

Bu sefer terminale hiç dokunmadan, tamamen web arayüzünden gitmek istedim. pve-a'nın arayüzünde Datacenter → Cluster → Join Information, kopyala butonuna bastım; encode edilmiş bir bilgi bloğu (peer address, fingerprint, cluster network bilgisi hepsi içinde) verdi.

pve-c'nin kendi arayüzüne geçip Join Cluster dedim, kopyaladığım bilgiyi yapıştırdım, root parolasını girdim. Ekran otomatik olarak Peer Address, Fingerprint alanlarını doldurdu, ve Cluster Network kısmında "Link: 1" yazıp 10.10.10.13'ü önerdi.

"Join 'lab-cluster'" dedim.

Not: Join Information bloğu cluster ismini, node adreslerini (management ve corosync IP'leri) ve sertifika fingerprint'ini kodluyor; root parolası bunun dışında, ayrıca giriliyor. Yani bu string'i tek başına ele geçirmek cluster'a katılmaya yetmiyor. Yine de gerçek bir ortamda bu blok ağ topolojisini açığa çıkarıyor, bu yüzden production sistemlerde bu tür ekran görüntülerini herkese açık paylaşmadan önce IP'leri kırpmak/bulanıklaştırmak makul bir alışkanlık. Burada gösterdiğim IP'ler (192.168.122.x, 10.10.10.x) private adresler ve sadece kendi laptopumdaki izole lab ağında anlamlı olduğu için olduğu gibi bıraktım.

Task viewer ekranı "stopping pve-cluster service" satırında donmuş gibi görünüyordu, "Download" butonu bile aktif olmamıştı. İlk anda başarısız olduğunu düşündüm. Ama bu, bilinen bir kozmetik davranış: pve-cluster.service yeniden başlarken pveproxy/pvedaemon de kendini yeniden başlatıyor, bu da tarayıcının o anki task log bağlantısını kesiyor. Arka planda işlem gerçekte tamamlanmış oluyor; sadece tarayıcı bunu görmüyor.

Bunu terminalden doğruladım.

Sonucu Doğrulamak

pve-a'da, pve-b katıldıktan sonra:

Nodes:            2
Quorate:          Yes
Expected votes:   2
Total votes:      2
Quorum:           2

pve-c katıldıktan sonra:

Nodes:            3
Quorate:          Yes
Expected votes:   3
Total votes:      3
Quorum:           2

pvecm nodes:

    Nodeid      Votes Name
         1          1 pve-a (local)
         2          1 pve-b
         3          1 pve-c

Web arayüzünde de Datacenter → Cluster altında aynı bilgi: üç node, her biri 1 oy, Link 1 sütununda üçünün de doğru corosync-net IP'sini gösterdiğini gördüm. GUI ve CLI, aynı gerçekliği iki farklı pencereden gösteriyordu; bu benim için iyi bir doğrulama oldu, tek bir kaynağa güvenmek yerine ikisini çapraz kontrol etmiş oldum.

pmxcfs'in Canlı Senkronizasyonu

pve-a'da bir dosya oluşturdum:

echo "cluster calisiyor" > /etc/pve/test-sync.txt

pve-b ve pve-c'de, saniyeler içinde:

cat /etc/pve/test-sync.txt

cluster calisiyor

pve-c'nin pve-cluster.service loglarına baktığımda senkronizasyonun nasıl gerçekleştiğini de gördüm:

[status] notice: received sync request (epoch 1/1632/00000003)
[dcdb] notice: received all states
[dcdb] notice: leader is 1/1632
[dcdb] notice: synced members: 1/1632, 2/2612
[dcdb] notice: waiting for updates from leader
[status] notice: all data is up to date
[dcdb] notice: update complete - trying to commit (got 47 inode updates)
[dcdb] notice: all data is up to date

pve-c'nin katıldığı anda, pve-a'nın (leader'ın) tarafında ne olduğunu da görmek istedim:

[status] notice: received sync request (epoch 1/1632/00000003)
[dcdb] notice: received all states
[dcdb] notice: leader is 1/1632
[dcdb] notice: synced members: 1/1632, 2/2612
[dcdb] notice: start sending inode updates
[dcdb] notice: sent all (47) updates
[dcdb] notice: all data is up to date
[status] notice: received all states
[status] notice: all data is up to date

leader is 1/1632 satırı özellikle dikkatimi çekti: pmxcfs'in kendi içinde bir "leader" kavramı var, senkronizasyon bu leader üzerinden koordine ediliyor. İki log da aynı sayıyı, 47 update'i, konuşuyor; biri "gönderdim" diyor, diğeri "aldım" diyor. Dağıtık bir sistemde iki bağımsız node'un aynı olayı aynı sayılarla anlatması, bana pmxcfs'in gerçekten tutarlı çalıştığına dair küçük ama tatmin edici bir kanıt oldu.

`/etc/pve/nodes/` Dizininin Son Hali

ls -la /etc/pve/nodes/

Modül 1'in başında pve-a'da sadece kendi node'unu görmüştüm. Şimdi:

drwxr-xr-x 2 root www-data 0 Aug  5 17:57 pve-a
drwxr-xr-x 2 root www-data 0 Aug 10 07:23 pve-b
drwxr-xr-x 2 root www-data 0 Aug 10 07:26 pve-c

Bu dizin listesi, hem pve-a'da hem pve-b'de hem pve-c'de birebir aynı; üçü de aynı gerçekliği paylaşıyor. Bu, "öncesi/sonrası" karşılaştırmasının en net hali: bir dizin, tek bir node'a özgü değil, artık cluster'ın ortak hafızasının bir parçası.

Test: Migration ve Node Arızası Simülasyonu

Buraya kadar cluster'ı kurdum, quorate olduğunu doğruladım, pmxcfs'in senkronize çalıştığını gördüm. Ama bir arkadaşım haklı bir eksiği fark etti: cluster'a özgü hiçbir şey (bir VM'i node'lar arası taşımak) hiç denenmemişti. "Cluster kurdum" demek, "kurdum ve gerçekten işe yarıyor" demenin garantisi değil.

Küçük Bir VM ile Migration Testi

pve-a üzerinde minimal bir Alpine Linux VM'i (VMID 100) oluşturdum, vmbr0 (management ağı) üzerine bağladım; corosync-net'e değil, çünkü o ağ sadece Corosync trafiği için izole tutulmuş durumda, guest trafiğini oraya karıştırmak istemedim.

İlk migration denemem başarısız oldu:

qm migrate 100 pve-b --online --with-local-disks

found local disk 'local:iso/alpine-standard-3.24.1-x86_64.iso' (attached)
can't migrate local disk 'local:iso/alpine-standard-3.24.1-x86_64.iso': local cdrom image
ERROR: migration aborted (duration 00:00:01): Problem found while scanning volumes - can't migrate VM - check log

Kurulumdan kalan ISO hâlâ sanal CD-ROM olarak bağlıydı; bu, ne shared storage'da ne de replike ediliyor, sadece pve-a'nın diskinde duruyor, migration bunu taşıyamıyor. CD-ROM'u çıkarıp tekrar denedim:

qm set 100 --ide2 none
qm migrate 100 pve-b --online --with-local-disks

Bu sefer çalıştı. pve-b'de doğruladım:

qm status 100

status: running

Cluster genelinde de aynı bilgiyi pve-a'dan görebiliyordum:

pvesh get /cluster/resources --type vm

│ id       │ type │ ... │ name   │
│ qemu/100 │ qemu │ ... │ alpine │

VM pve-b üzerinde, çalışır durumda görünüyordu.

Node'u Çökertmek

Asıl test buradaydı. Önce ping'i başlattım (host laptop'umdan):

ping 192.168.122.251

64 bytes from 192.168.122.251: icmp_seq=1 ttl=64 time=0.842 ms
64 bytes from 192.168.122.251: icmp_seq=2 ttl=64 time=0.969 ms
...
64 bytes from 192.168.122.251: icmp_seq=19 ttl=64 time=1.08 ms

Sonra pve-b'yi, temiz bir kapanış değil, gerçek bir çökme gibi simüle ettim; fiziksel host'tan (nested VM olduğu için mümkün):

sudo virsh destroy pve-b

Domain 'pve-b' destroyed

pve-a'dan cluster durumuna baktım:

pvecm status

Nodes:            2
Quorate:          Yes
Expected votes:   3
Total votes:      2
Quorum:           2
Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.10.10.11 (local)
0x00000003          1 10.10.10.13

Tam beklendiği gibi: pve-b (nodeid 2) membership listesinden düştü, ama kalan iki node (pve-a, pve-c) hâlâ çoğunluğu oluşturduğu için Quorate: Yes kaldı.

Ping çıktısında ilginç bir detay vardı: pve-b öldükten hemen sonra paketler önce sessizce kayboldu (ne cevap ne hata, muhtemelen ARP kaydı hâlâ geçerliydi), birkaç düzine paket sonra gateway (192.168.122.1, libvirt'ün NAT'ı) aktif olarak "Destination Host Unreachable" demeye başladı:

64 bytes from 192.168.122.251: icmp_seq=19 ttl=64 time=1.08 ms
From 192.168.122.1 icmp_seq=52 Destination Host Unreachable
From 192.168.122.1 icmp_seq=53 Destination Host Unreachable
ping: sendmsg: No route to host

Yani arıza algılama anlık değil, kademeli: önce sessizlik, sonra açık ret.

VM'i Başka Bir Yerde Başlatmayı Denemek

Şimdi asıl soru: VM 100, pve-b çökmüşken başka bir node'da kendiliğinden açılır mı?

qm start 100

Configuration file 'nodes/pve-a/qemu-server/100.conf' does not exist

Hayır, açılmadı; ama hatanın kendisi beklediğimden daha ince bir şey söylüyor. Hata "pve-b'ye ulaşamıyorum" demiyor; "pve-a'nın kendi node dizininde böyle bir config dosyası yok" diyor. Sebep şu: pmxcfs, nodes/pve-b/qemu-server/100.conf dosyasını cluster genelinde senkronize ediyor, pve-a bile bu dosyayı görebiliyor (pvesh get /cluster/resources bunu az önce gösterdi). Ama qm start, sadece komutu çalıştırdığın node'un kendi dizinindeki config'lere bakıyor. VM 100'ün config'i pve-b'nin dizininde olduğu için, pve-a üzerinde qm start 100 demek, "burada böyle bir VM yok" demekle aynı şey.

Bu ayrım önemli: pmxcfs veriyi her yere kopyalıyor, ama "bu VM'i sahiplenip başka bir node'da başlat" kararını kimse otomatik almıyor. Veri paylaşılıyor, karar paylaşılmıyor. Bunu yapacak mekanizma (HA Manager, fencing, watchdog) henüz devrede değil.

Toparlamak ve Doğrulamak

pve-b'yi geri başlattım:

sudo virsh start pve-b

Birkaç dakika sonra pve-a'dan tekrar baktım:

pvecm status

Nodes:            3
Quorate:          Yes
Expected votes:   3
Total votes:      3
Quorum:           2
Membership information
----------------------
    Nodeid      Votes Name
0x00000001          1 10.10.10.11 (local)
0x00000002          1 10.10.10.12
0x00000003          1 10.10.10.13

Üç node da geri döndü, cluster kendiliğinden toparlandı; hiçbir manuel müdahale gerekmedi. pve-b geri geldikten sonra qm start 100'ü pve-a'dan tekrar denedim, aynı hatayı aldım; bu da tutarlıydı, çünkü hatanın sebebi "node kapalı" değil "config burada değil" olduğu için, pve-b geri gelmesi bu durumu değiştirmiyor. VM'i başlatmanın doğru yolu, pve-b'ye SSH ile bağlanıp oradan qm start 100 demekti; ki VM zaten orada duruyordu, hiç kapanmamıştı bile (sadece host çöktüğü için o da düşmüştü).

Genel Değerlendirme

Bu modülde, işleri hem GUI'den hem CLI'dan yapmaya çalışınca gerçek bir hatayla karşılaştım: TLS hostname doğrulaması. Bu, Modül 1'in başında yaptığım pmxcfs gözlemiyle (node adının management IP'sine çözümlenmesi) doğrudan bağlantılıydı; o gözlemi yapmamış olsaydım, hatanın kaynağını bulmak daha uzun sürerdi. Bir kavramı önceden anlamış olmak, karşılaştığın hatayı çok daha hızlı okumanı sağlıyor.

Task viewer'ın donması ise ayrı bir ders: arayüzün "bir şey oluyormuş gibi görünmemesi", arka planda bir şey olmadığı anlamına gelmiyor. Terminal üzerinden çapraz doğrulama yapmak, GUI'ye kör güvenmemek için iyi bir alışkanlık.

En değerlisi ise sona sakladığım migration testiydi. Cluster'ı kurmuş olmak, ona güvenmek için yeterli değil; gerçekten bir workload'u taşımadan, bir node'u çökertmeden, "çalışıyor" demek bir iddiadan ibaret kalıyor. Test, iki şeyi net gösterdi: birincisi, live migration gerçekten çalışıyor, VM kesintisiz taşınabiliyor. İkincisi, ve daha önemlisi, cluster kurmak otomatik yüksek erişilebilirlik anlamına gelmiyor. Bir node çöktüğünde, üzerindeki VM kendiliğinden başka bir yerde açılmıyor; pmxcfs veriyi her yere kopyalasa da, "bu VM'i devral" kararını hiçbir mekanizma otomatik almıyor. Bunu yapacak parça (HA Manager, fencing, watchdog) ayrı bir modülün konusu.

Sonuç olarak: cluster çalışıyor, üç node quorate, pmxcfs gerçek zamanlı senkronize oluyor, migration gerçekten işe yarıyor, ve otomatik failover'ın olmadığını da artık varsayım değil, test ederek biliyorum. VMware serisinde her adımı önceden hazırlanmış bir manuel yönlendiriyordu; burada hem TLS hatasının kaynağını hem de HA'nın sınırlarını kendim bulmam gerekti. Daha yorucu, ama muhtemelen daha kalıcı bir öğrenme biçimi.

Bir sonraki yazıda Modül 2'ye geçiyorum: quorum'u gerçekten kırıp gözlemleyeceğim, pvecm expected'in riskini test edeceğim, ve QDevice'i devreye alacağım.

Bu seri, resmi Proxmox VE dokümantasyonundan (pve.proxmox.com) derlenen bir müfredatı takip ediyor. Buradaki gözlemler bir homelab ortamına dayanıyor; production kararları için resmi dokümantasyon ve deneyimli sistem yöneticileri referans alınmalıdır.

Kendi Laboratuvarını Kurmak: Lab Ortamı Hazırlığı (Modül 0)

Hakan İSMAİL — Fri, 07 Aug 2026 06:01:43 +0000

Seri: Proxmox VE Cluster ve Corosync | Hazırlık

vSAN serisinde VMware'in hazırladığı bir HOL ortamı üzerinden ilerlemiştim; ekran adımları, önceden kurulmuş cluster'lar, tek yapmam gereken doğru yere tıklamaktı. Bu seri farklı bir yerden başlıyor: Proxmox VE için böyle hazır bir lab yok. Yani cluster'ı, ağı, hatta sanal makineleri bile sıfırdan ben kuruyorum.

Bunun bir bedeli var: her adım biraz daha uzun sürüyor, hata yapma ihtimalim daha yüksek. Ama bir avantajı da var: bir HOL asla veremeyeceği kadar derin bir öğrenme sağlıyor, çünkü her kararı (kaç node, hangi ağ mimarisi, ne kadar kaynak) kendim veriyorum ve neden öyle verdiğimi de anlamak zorundayım.

Bu ilk yazı bir "modül" değil, bir hazırlık; asıl Modül 1 (Cluster, Corosync, pmxcfs kavramları) bir sonraki yazıda geliyor. Ama o kavramları anlamlandırmadan önce, üzerinde çalışacağım zemini kurmam gerekiyordu; bu yazı o zemini nasıl hazırladığımı anlatıyor.

Ortam Hakkında Bir Not

Bu lab kendi dizüstü bilgisayarımda çalışıyor: CachyOS (Arch tabanlı), 11. nesil Intel Core i7-11800H (8 çekirdek/16 iş parçacığı), 32 GB RAM, NVMe depolama. Production bir ortam değil; nested virtualization ile tek bir fiziksel makinede dört sanal makineyi birbirine "cluster" olarak bağlıyorum. Gerçek sahada birden fazla fiziksel sunucu, ayrı switch'ler, gerçek ağ gecikmeleri olurdu; burada hepsi tek bir kutunun içinde simüle ediliyor.

Bunu baştan söylüyorum çünkü Corosync'in gerçek gereksinimlerinden biri düşük gecikmeli bir ağ (5 milisaniyenin altı); nested bir ortamda bu neredeyse otomatik olarak sağlanıyor (sanal switch üzerinden iletişim gerçek bir fiziksel ağdan çok daha hızlı), bu yüzden bazı gerçek dünya sorunlarını (ağ gecikmesi, switch arızası) burada birebir yaşayamayacağım. Ama cluster mantığını, quorum'u, fencing'i anlamak için bu ortam fazlasıyla yeterli.

Lab Mimarisi: Neden Nested Virtualization, Neden libvirt

Üç ayrı fiziksel sunucum olmadığı için, tek makinede nested virtualization kullanıyorum: fiziksel makinede QEMU/KVM çalışıyor, bunun üzerinde dört sanal makine var, bu sanal makinelerin üçü Proxmox VE (cluster node'ları), biri de QDevice için minimal bir Debian.

Bunu iki şekilde yapabilirdim: Proxmox VE'yi fiziksel makineye kurup içine nested Proxmox VM'leri koymak (bu, topluluk kaynaklarında sık görülen bir yöntem), ya da doğrudan Linux masaüstümde çalışan libvirt/QEMU'yu kullanmak. İkincisini seçtim, çünkü zaten kurulu ve çalışır durumdaydı; fazladan bir sanallaştırma katmanı eklemek (host'ta Proxmox, onun içinde nested Proxmox'lar) gereksiz karmaşıklık olurdu. Masaüstümü de kullanmaya devam edebiliyorum, bu da pratik bir avantaj.

Nested Virtualization Kontrolü

Bunu kurmadan önce doğrulamam gereken bir şey vardı: fiziksel CPU'nun nested virtualization'ı destekleyip desteklemediği. Bu, "VM içindeki VM'in de donanım hızlandırmalı çalışması" anlamına geliyor; olmazsa Proxmox node'larının içine koyacağım test VM'leri (ileride HA testleri için) çok yavaş çalışır.

cat /sys/module/kvm_intel/parameters/nested

Çıktı Y geldi. Bu, i7-11800H'nin (Tiger Lake mimarisi) nested virtualization'ı sorunsuz desteklediğini doğruladı.

Kaynak Planlaması

Donanımı (8 çekirdek/16 iş parçacığı, 32 GB RAM, NVMe üzerinde ~419 GB boş alan) dört VM'e nasıl paylaştıracağıma karar vermem gerekiyordu. Amaç, host masaüstünün (GNOME) rahatça çalışmaya devam etmesi, aynı zamanda cluster node'larının gerçekçi bir şekilde test edilebilmesiydi.

VM	vCPU	RAM	Disk (qcow2, thin)	Rol
pve-a	2	6 GB	40 GB	Cluster node 1
pve-b	2	6 GB	40 GB	Cluster node 2
pve-c	2	6 GB	40 GB	Cluster node 3
qdevice-1	1	1 GB	8 GB	QDevice
Toplam	7	19 GB	128 GB

Bu paylaşım, 16 iş parçacığından 7'sini, 32 GB RAM'in 19 GB'ını kullanıyor; host için 9 iş parçacığı ve ~13 GB rahatça kalıyor. Disk thin-provisioned (qcow2) olduğu için 128 GB tahsis etsem bile gerçek kullanım başlangıçta çok daha az.

Üç cluster node'una eşit kaynak verdim (2 vCPU / 6 GB); QDevice'e ise çok daha az (1 vCPU / 1 GB), çünkü QDevice'in işi ağır değil, sadece bir oy sağlamak.

ISO'ları İndirmek ve Doğrulamak

Proxmox VE 9.2 ve QDevice için minimal bir Debian 13 (Trixie) ISO'su indirdim. Burada bir adımı atlamamak önemli: checksum doğrulaması.

echo "65273beed27b2df543b68b65630ba525cfbad8df2b12035732b2dff87d6664e7  debian-13.6.0-amd64-netinst.iso" | sha256sum -c -

echo "4e88fe416df9b527624a175f24c9aa07c714d3332afb1ee3dbf3879573ef2c6c  proxmox-ve_9.2-1.iso" | sha256sum -c -

Bu adımı bir lab ortamında bile atlamamaya çalışıyorum; alışkanlık, üretim ortamında da aynı disiplini otomatik hale getiriyor. Bozuk bir indirme, kurulumun ortasında garip hatalar olarak geri dönüp saatler kaybettirebiliyor; iki saniyelik bir kontrol bunun önüne geçiyor.

Ağ Mimarisi: NAT ve İzole Corosync Ağı

Gerçek bir Proxmox cluster kurulumunda Corosync trafiğinin ayrı, adanmış bir ağda olması öneriliyor; VM trafiği veya storage trafiğiyle paylaşılan bir ağda gecikme dalgalanmaları Corosync'i etkileyebiliyor. Bunu nested lab'ımda da simüle etmek istedim, bu yüzden iki ayrı sanal ağ kurdum:

default ağı: libvirt'ün standart NAT ağı (192.168.122.0/24). İnternete çıkış (apt update, paket indirme) ve Proxmox web arayüzüne host'tan erişim için kullanılıyor.

corosync-net ağı: Kendi tanımladığım, izole bir ağ (10.10.10.0/24). Dışarıya çıkışı yok; sadece bu ağa bağlı VM'ler birbirini görebiliyor. Bunu, gerçek sahadaki "Corosync için adanmış NIC ve switch" pratiğinin bir simülasyonu olarak düşünebilirsin.

<network>
  <name>corosync-net</name>
  <bridge name='virbr-coro' stp='on' delay='0'/>
  <ip address='10.10.10.1' netmask='255.255.255.0'>
    <dhcp>
      <range start='10.10.10.10' end='10.10.10.100'/>
    </dhcp>
  </ip>
</network>

Her VM'e iki ağ arayüzü atadım: biri default'a, biri corosync-net'e. Proxmox kurulum sihirbazı sırasında sadece birinci arayüzü (default/NAT) yapılandıracağım; ikinci arayüzü (corosync-net) kurulumdan sonra Proxmox web arayüzünden elle ayarlayacağım. Bu ayrım bilinçli: yönetim/internet trafiği ile cluster'ın kendi iç iletişimini daha kurulum aşamasında birbirinden ayırmış oluyorum.

corosync-net'i bilinçli olarak XML dosyası yazıp virsh net-define ile tanımladım; virt-manager'ın "Create Virtual Network" sihirbazı da aynı işi yapardı, ama XML'i elle yazmak beni bridge adı, IP aralığı ve DHCP range gibi alanların her birini tek tek düşünmeye zorladı. Sihirbazda "ileri, ileri, bitir" derken çoğu ayarı görmeden geçebiliyorsun; XML'de her satırı kendin yazdığın için ne yaptığını daha net biliyorsun.

Burada küçük ama can sıkıcı bir ayrıntıyla karşılaştım: virsh'i normal kullanıcı olarak çalıştırdığımda, varsayılan olarak qemu:///session'a bağlanıyor; bu, kullanıcıya özel, izole bir libvirt oturumu ve default ağı dahil hiçbir sistem-geneli kaynağı görmüyor. Oysa virt-manager'ın oluşturduğu VM'ler ve default NAT ağı qemu:///system altında yaşıyor. virsh net-define'ı sudo olmadan çalıştırınca ağı yanlış tarafa (session) tanımlamış oldum; sonuç olarak corosync-net, VM'lerin ağ listesinde hiç görünmedi. Çözüm basitti: komutu sudo virsh net-define ... ile, yani sistem bağlantısı üzerinden çalıştırmak. Aynı ayrım pool-define-as ve diğer virsh komutları için de geçerli; hepsini sudo ile ya da -c qemu:///system ile çalıştırmak gerekiyor, aksi halde sessizce yanlış (görünmez) bir yere yazıyorsunuz.

Storage Pool ve VM'ler: Geri Kalanı Arayüzden

Ağı XML ile tanımladıktan sonra, storage pool'u ve dört VM'i virt-manager'ın grafik arayüzünden oluşturdum. "Create a new virtual machine" sihirbazında sırasıyla: ISO dosyasını seçtim, bellek/vCPU değerlerini yukarıdaki tabloya göre girdim, disk boyutunu ayarladım (qcow2, thin-provisioned), ve ağ sekmesinde iki arayüzü de (default ve corosync-net) ekledim. CPU modeli için "Copy host CPU configuration" seçeneğini işaretledim; bu, host-passthrough ile aynı işi görüyor, fiziksel CPU'nun VMX özelliğini VM'e taşıyor ve nested virtualization zincirinin ikinci halkasını tamamlıyor.

Aynı sihirbazı pve-a, pve-b, pve-c için üç kez, qdevice-1 için çok daha hafif kaynaklarla bir kez daha çalıştırdım.

Kurulumu Tamamlamak: Proxmox VE ve Debian

VM'leri oluşturup ISO dosyalarını bağladıktan sonra kurulumları doğrudan virt-manager konsolundan tamamladım. İlk aşamada her sanal makineye yalnızca Management (NAT) ağı bağlıydı. Böylece Proxmox VE ve Debian kurulumları herhangi bir ek ağ yapılandırmasına ihtiyaç duymadan tamamlanabildi.

pve-a, pve-b ve pve-c için Proxmox VE kurulumu standart sihirbaz üzerinden ilerledi. Hedef disk seçimi (tek bir VirtIO disk), ülke ve saat dilimi, root parolası ve son olarak Management Network Configuration ekranında ilk ağ arayüzüne yönetim IP adreslerini atadım.

qdevice-1 için ise masaüstü ortamı kurmadan, yalnızca SSH server ve standard system utilities paketlerini seçerek minimal bir Debian 13 kurulumu yaptım.

Kurulum tamamlandıktan sonra artık virt-manager konsoluna ihtiyaç kalmadı. Bundan sonraki tüm yapılandırmayı kendi terminalim üzerinden SSH ile yaptım. Bunun iki önemli avantajı vardı:

Komutları doğrudan kopyala-yapıştır ile çalıştırabilmek,
Yapılan değişiklikleri daha rahat takip edip gerektiğinde tekrar edebilmek.

Proxmox VE'de root kullanıcısıyla SSH erişimi varsayılan olarak açık geldiği için ek bir ayar yapmam gerekmedi. Debian tarafında ise güvenlik nedeniyle root ile SSH oturumu varsayılan olarak kapalıydı. Bu nedenle /etc/ssh/sshd_config dosyasında aşağıdaki satırı düzenledim:

PermitRootLogin yes

Ardından SSH servisini yeniden başlatarak root kullanıcısıyla uzaktan bağlantıyı etkinleştirdim.

systemctl restart sshd.service

İlk kurulum tamamlandıktan sonra ikinci ağ arayüzünü (corosync-net) yapılandırdım. Proxmox node'larında bunu /etc/network/interfaces dosyası üzerinden yaptım; Debian tarafında da aynı yöntemle Corosync ağı için statik IP adresini tanımladım.

Son durumda lab ortamının ağ planı şu şekilde oluştu:

Makine	Management (NAT)	Corosync
pve-a	192.168.122.11	10.10.10.11
pve-b	192.168.122.12	10.10.10.12
pve-c	192.168.122.13	10.10.10.13
qdevice-1	192.168.122.20	10.10.10.20

Kurulum sırasında hostnameleri de son hâlleriyle belirledim. Bu lab'da .home.arpa alan adını kullanıyorum:

pve-a.home.arpa
pve-b.home.arpa
pve-c.home.arpa
qdevice-1.home.arpa

Bunun iki önemli sebebi var. Birincisi, .home.arpa RFC 8375 ile yalnızca ev ve yerel ağlar için ayrılmış özel bir alan adıdır. Gerçek internette hiçbir zaman çözümlenmez; dolayısıyla ileride gerçek bir alan adıyla çakışma riski bulunmaz. İkincisi ise sıkça kullanılan .local uzantısının mDNS (Multicast DNS) tarafından rezerve edilmiş olmasıdır. Linux sistemlerde Avahi, macOS'ta Bonjour ve diğer mDNS uygulamaları .local alanını kullandığından, özellikle cluster ortamlarında isim çözümleme problemlerine yol açabilir. Bu nedenle Proxmox'un da önerdiği yaklaşımlardan biri olan .home.arpa daha doğru ve geleceğe dönük bir tercih oluyor.

📌 Not: Bu aşamadan sonra dört makine de birbirine Management ağı üzerinden SSH ile erişebilir, Corosync ağı ise tamamen hazır durumda bekliyor. Artık cluster oluşturma aşamasına geçebiliriz.

Bağlantıyı Doğrulamak

Dört node'un birbirini gerçekten görüp görmediğini, pve-a'dan her iki ağ üzerinden ping atarak test ettim:

Sıfır paket kaybı, gecikmeler milisaniyenin çok altında (Corosync'in gerektirdiği 5ms sınırının çok altında, beklendiği gibi; nested bir ortamda ağ gecikmesi neredeyse ölçülemeyecek kadar düşük). Aynı testi pve-b ve pve-c'den de tekrarladım, sonuçlar aynı; hepsi birbirini her iki ağdan da görüyor.

Bu noktada lab hazır: dört makine kurulu, isimlendirilmiş, iki ayrı ağdan birbirine ulaşabiliyor. Bir sonraki yazıda artık kuruluma değil, doğrudan kavramlara geçebiliyorum.

Küçük bir not: qdevice-1 üzerine corosync-qnetd paketini de bu aşamada kurup servisi etkinleştirdim; ileride QDevice'i devreye alacağım modülde hazır beklesin diye. Asıl QDevice kurulumu ve testleri (pvecm qdevice setup, 2-node senaryosu, quorum matematiği) kendi modülünde ayrıca işlenecek; burada sadece "ortam hazır" demek istedim.

Genel Değerlendirme

Bu modülde henüz tek bir Proxmox komutu çalıştırmadım; her şey "cluster'ı kuracağım ortamı hazırlamak" üzerineydi. Ama bu hazırlık aşaması, VMware serisindeki gibi hazır bir HOL kullanırken hiç düşünmek zorunda kalmadığım kararları öne çıkardı.

En çok üzerinde durduğum nokta ağ mimarisiydi. VMware HOL'da Corosync'e denk bir kavram yoktu, ama vSAN serisinin Modül 4'ünde (Stretched Cluster) gördüğüm "witness trafiğini ayrı tutma" mantığıyla burada kurduğum NAT/corosync-net ayrımı aslında aynı prensibi paylaşıyor: kritik, düşük gecikmeli bir iletişim kanalını, genel amaçlı trafikten izole tutmak. Farklı ürünler, aynı temel disiplin.

İkinci nokta, checksum doğrulamasını bir lab ortamında bile atlamamaktı. Küçük bir şey ama bunun bir HOL'da hiç düşünmem gereken bir adım olduğunu fark ettim; VMware zaten doğrulanmış bir ortam sunuyordu. Kendi lab'ını kurunca, bu tür "sıradan" disiplinlerin aslında ne kadar bilinçli bir seçim olduğunu görüyorsun.

Üçüncü nokta, ağı XML ile tanımlarken fark ettiğim şey. Storage pool ve VM'leri virt-manager sihirbazıyla oluşturmak hızlı ve rahattı, ama tam olarak neyi neden yaptığımı hatırlamıyorum diyebilirim; sihirbaz benim adıma çoğu kararı verdi. Ağı XML ile yazarken ise her alanı (bridge adı, IP aralığı, DHCP range) kendim belirlemek zorunda kaldım; bu yüzden şu an o ağın nasıl çalıştığını çok daha net açıklayabiliyorum. Bu, aslında GUI'nin kötü olduğu anlamına gelmiyor, sadece "hızlı yapmak" ile "anlayarak yapmak" arasında küçük bir ödünleşim olduğunu gösteriyor.

Bir sonraki yazıda Modül 1'e geçiyorum: lab artık tamamen hazır ve doğrulanmış durumda, sırada Cluster, Corosync ve pmxcfs kavramları, ve cluster'ı kurmadan hemen önce pmxcfs'in tek-node haldeki davranışını gözlemlemek var.

Bu seri, resmi Proxmox VE dokümantasyonundan (pve.proxmox.com) derlenen bir müfredatı takip ediyor; hazır bir lab ortamı olmadığı için her adımı kendim kuruyor ve test ediyorum. Buradaki gözlemler bir homelab ortamına dayanıyor; production kararları için resmi dokümantasyon ve deneyimli sistem yöneticileri referans alınmalıdır.

vSAN Data Protection: Snapshot, Protection Group ve Immutability (Modül 7)

Hakan İSMAİL — Sun, 26 Jul 2026 14:08:18 +0000

Altı haftadır SPBM'den File Services'e kadar vSAN'ın farklı katmanlarını gezdim. Modül 7, serinin son modülü ve konusu net: Data Protection. Bu modülde snapshot almayı, VM'leri "protection group" adı verilen politikalarla korumayı, silinmiş bir VM'i geri getirmeyi ve ransomware senaryolarına karşı değiştirilemez (immutable) koruma gruplarını görüyoruz.

Bu modül önceki altısına göre daha "hikaye anlatan" bir yapıya sahip. Sadece bir özelliği açıp kapatmıyoruz; bir VM oluşturup koruyoruz, siliyoruz, geri getiriyoruz, klonluyoruz. Bu akış, konuyu soyut bir özellik listesinden çıkarıp gerçek bir operasyonel senaryoya dönüştürüyor.

vSAN Data Protection Nedir?

vSAN Data Protection (DP), vSAN 8.0 Update 3'te tanıtılan bir özellik. Amaç, VM'leri operasyonel hatalardan veya ransomware saldırılarından hızlıca kurtarabilmek; bunu vSAN cluster üzerinde yerel olarak saklanan native snapshot'larla yapıyor.

Mimari olarak birkaç önemli nokta var:

Policy tabanlı "protection group" kavramıyla çalışıyor; hangi VM'lerin korunacağını, snapshot sıklığını ve saklama (retention) süresini bu gruplar üzerinden yönetiyorsunuz.
Yanlışlıkla silinen VM'leri kurtarmak veya operasyonel çeviklik için VM'leri hızlıca klonlamak için kullanılabiliyor.
VMware Live Cyber Recovery çözümüyle entegre olarak ransomware senaryolarından kurtarmayı da destekliyor (bu ayrı bir lisans gerektiriyor).
Sadece vSAN ESA (Express Storage Architecture) ile çalışan HCI cluster'larda destekleniyor.

Mimari tarihçesi de ilginç: vSAN 8.0u3'te bu servis ayrı indirilebilir bir "vSAN Snapmanager Appliance" olarak geliyordu. vSAN 9.0 ile birlikte vSAN Data Protection, vSphere Replication ve VMware Live Recovery tek bir appliance'da birleşti. HOL'da bu appliance zaten kurulu ve vCenter'a kayıtlı; biz doğrudan vSphere Client üzerinden Data Protection'ı kullanıyoruz.

Bir not daha: vSAN 9'da protection group'lar, vCenter'lar arası vSAN-to-vSAN replikasyon içeren VMware Live Recovery ile entegre olabiliyor. Bu modül sadece yerel snapshot'ları kapsıyor; replikasyonun aksiyonda görülmesi için ayrı bir lab (HOL-2634-03-VCF-L) öneriliyor.

vSAN ESA Snapshot'ları: Temel Mekanik

ESA, VM'in durumunu ve verisini snapshot alındığı andaki haliyle koruyan entegre, yüksek performanslı bir snapshot mekanizması sunuyor. Birkaç teknik detay:

Snapshot alındığında VM'in o anki çalışan durumu yakalanıyor; snapshot'lar "quiesced" (uygulama seviyesinde tutarlılık için duraklatılmış) değil.
Snapshot'lar bireysel VM'ler üzerinde çalışıyor; her VM ayrı bir snapshot gerektiriyor.
Her vSAN snapshot'ı, VM'in namespace nesnesinin ve virtual disk nesnelerinin durumunu içeriyor.
Protection group'lardaki VM'lerin snapshot'ları zamanlanmış aralıklarla alınıyor ve yerel olarak vSAN datastore'da saklanıyor.

Bu, geleneksel vSphere snapshot mekanizmasından farklı bir zihniyetle çalışıyor; snapshot almak burada manuel bir "şimdi al" işlemi değil, bir politikanın parçası olarak zamanlanmış bir süreç.

Data Protection Arayüzüne Giriş

cluster-esa-01a > Configure > vSAN > Data Protection

Genel Bakış (Overview)

Overview bölümünde, cluster'daki 7 VM'den 4'ünün korunduğu görülüyor. Grafik bu korumanın türünü (yerel, replikasyon veya korumasız) gösteriyor.

"vSAN Snapshot Space Usage" bölümünde snapshot'ların kullandığı kapasitenin dökümü var. Burada dikkat çeken bir uyarı kutusu var: datastore kullanımı %70'i aştığında zamanlanmış snapshot'lar alınmıyor.

Bu %70 eşiği bana Modül 1'deki Reserved Capacity konseptini hatırlattı; orada da benzer bir "belirli bir doluluk oranından sonra sistem kendini korumaya alır" mantığı vardı. Burada aynı mantık, snapshot alma sürecine uygulanmış.

Protection Groups

HOL ortamında iki protection group önceden tanımlı:

Core PG: Sadece yerel snapshot alıyor, bir VM'i aktif olarak koruyor.
Remote Acct PG: Site B'ye vSAN replikasyonu yapıyor, üç VM'i koruyor.

Her ikisi de "Active" durumda, yani zamanlanmış snapshot'lar konfigüre edildiği gibi alınıyor. Core PG'nin iki yerel snapshot'ı var; en son snapshot belirli bir tarihte alınmış.

Existing VMs, Removed VMs, Incoming VMs

VMs sekmesi, cluster'daki VM'leri üç kategoride gruplandırıyor:

Existing VMs: Şu anda vSAN'da aktif olarak bulunan VM'ler.
Removed VMs: Silinmiş ama hâlâ mevcut bir snapshot tarafından korunan VM'ler.
Incoming VMs: Bu cluster'a replike edilmekte olan VM'ler.

Her VM için protection group'u, yerel koruma durumu, replikasyon durumu ve (varsa) hangi peer cluster'a replike edildiği gösteriliyor.

Removed VMs sekmesinde core-c adlı bir VM görülüyor; bu VM silinmiş ama snapshot'ı hâlâ mevcut, yani geri getirilebilir durumda.

Replication Pairs

REPLICATION sekmesinde vSAN replikasyon sunucu çiftleri görülüyor. Site A cluster'ı (cluster-esa-01a), Site B cluster'ına (vsan-client-cluster-01b) eşleştirilmiş ve Remote Acct PG protection group'undaki üç VM'i replike ediyor. Bu özelliğin VMware Live Recovery lisansı gerektirdiği belirtiliyor.

Bu ekran, Modül 5'te gördüğümüz Storage Cluster/Compute Cluster ayrımının farklı bir versiyonunu hatırlattı bana; orada da farklı cluster'lar birbirine bir hizmet sağlıyordu, burada ise koruma amaçlı bir replikasyon ilişkisi var.

Yeni Bir Protection Group Oluşturmak

Modülün pratik kısmı burada başlıyor. Amacımız, "sales-" ön ekiyle başlayan satış uygulaması VM'lerini koruyan bir protection group oluşturmak.

Genel Ayarlar

Protection Groups > Create Protection Group

İsim: Sales Apps PG
Protection type: üç seçenek var:
- Local protection and replication: Yerel snapshot alıp başka bir vSAN cluster'a da replike ediyor (VMware Live Recovery lisansı gerekiyor).
- Local protection: Sadece yerel snapshot alıyor.
- Replication: Sadece başka bir cluster'a replike ediyor (VMware Live Recovery gerekiyor).

Bu HOL'da Local protection seçiliyor.

Immutability mode kutusu şimdilik işaretsiz bırakılıyor (bu konuya modülün sonunda dönülüyor).
VM seçim yöntemi olarak Dynamic VM name patterns seçiliyor.
NEXT

VM İsim Deseni Eklemek

sales* deseni giriliyor (tüm satış uygulaması VM'leri sales-xxxx-y adlandırma kuralını kullanıyor). Add'e tıklandığında, eşleşen sales-app-01, sales-db-01 ve sales-web-01 VM'leri listede görünüyor.

Bu dinamik isimlendirme yaklaşımı bence modülün en pratik fikri. Sabit bir VM listesi tutmak yerine bir isim deseni tanımlamak, gelecekte oluşturulacak yeni VM'lerin de otomatik olarak korunmasını sağlıyor; bunu birazdan test edeceğiz.

Snapshot Zamanlaması

Burada önemli bir teknik sınır var: vSAN ESA snapshot'ları, nesne başına en fazla 200 kopyaya kadar ölçekleniyor. Snapshot sıklığı ve saklama süresi kombinasyonu bu sınırı aşarsa, protection group oluşturulmadan önce düzenlenmesi gerekiyor.

Bu HOL'da:

Snapshot sıklığı: her 8 saatte bir
Saklama süresi: 2 ay
NEXT

Bir protection group için birden fazla snapshot zamanlaması tanımlamak da mümkün, ama bu lab'da tek bir zamanlama kullanılıyor.

200 kopya sınırını akılda tutarak hızlıca bir hesap yaptım: 8 saatte bir snapshot, günde 3 kopya demek. 2 aylık saklama süresinde bu yaklaşık 180 kopyaya denk geliyor, sınırın altında ama yakınında. Bu tür bir hesabı protection group tasarlarken önceden yapmak, ileride "limit aşıldı" hatasıyla karşılaşmamak için gerekli.

Review ve Oluşturma

Review ekranında dikkat çeken bir not var: standart vSphere Client "snapshot" arayüzünün aksine, vSAN Data Protection snapshot'ları hemen oluşturmuyor, bunun yerine zamanlıyor. Ama istenirse manuel bir snapshot da alınabileceği hatırlatılıyor. CREATE ile protection group oluşturuluyor.

Manuel Snapshot Almak

Protection group oluşturulduğunda henüz hiçbir snapshot yok; bu yüzden bir uyarı üçgeni ile işaretleniyor. 8 saat beklemek yerine manuel snapshot alınabiliyor.

Sales Apps PG'nin üç nokta menüsünden "Take local snapshot" seçiliyor.

Snapshot ismi varsayılan olarak protection group adı, oluşturma yöntemi ve zaman damgasını içeren açıklayıcı bir isim alıyor. Saklama süresi olarak "1 gün" seçiliyor, TAKE SNAPSHOT tıklanıyor.

Recent Tasks panelinden işlem takip ediliyor; tamamlandığında uyarı üçgeni kayboluyor ve üç Sales VM'i için snapshot'lar görünüyor.

Dinamik İsimlendirmeyi Test Etmek: Yeni Bir VM Oluşturmak

Bu bölüm, dinamik isim deseninin gerçekten çalıştığını kanıtlıyor. sales- ön ekiyle yeni bir VM oluşturursak, protection group'a manuel müdahale etmeden otomatik olarak dahil olması bekleniyor.

cluster-esa-01a üzerine sağ tık → New Virtual Machine → Create a new virtual machine. Sihirbaz adımları:

İsim: sales-lab, Sales klasörü seçili
Compute resource: cluster-esa-01a
Storage: vsan-esa-01a_Datastore
Compatibility: varsayılan (ESX 9.0 ve üzeri)
Guest OS: Linux, VMware Photon OS (64-bit)
Hardware: varsayılan ayarlar, FINISH

VM oluşturulduktan sonra vCenter inventory'de kayıtlı olduğu doğrulanıyor.

Data Protection'a dönülüp Sales Apps PG için tekrar manuel snapshot alınıyor (yeni VM'in zamanlanmış aralığı beklemesine gerek kalmadan test etmek için). İşlem tamamlandığında dört VM'in korunduğu görülüyor: orijinal üç sales VM'i ve yeni oluşturulan sales-lab.

Burada altı çizilen önemli nokta şu: yeni VM eklendiğinde protection group'un yeniden yapılandırılmasına gerek kalmadı, çünkü dinamik isimlendirme seçeneği kullanılmıştı. Bu, production ortamında sürekli yeni VM oluşturulan bir ortamda (örneğin bir CI/CD pipeline veya self-service VM provisioning sürecinde) manuel takip yükünü ortadan kaldıran bir tasarım.

VM'leri Geri Yüklemek

Mevcut Bir VM'i Önceki Bir Ana Geri Döndürmek

Bu senaryoda core-a VM'i, mevcut bir snapshot noktasına geri döndürülüyor. Önce core-a'nın açık (powered on) olduğu doğrulanıyor.

VMs > core-a seçili > Restore VM

Data Protection burada bir uyarı veriyor: VM kapatılacak ve geri yükleme öncesinde, ileride "ileri sarma" (mevcut duruma dönme) seçeneği olabilmesi için yeni bir snapshot otomatik olarak alınacak. Mevcut snapshot'lardan biri seçilip RESTORE'a tıklanıyor.

📌 [Resim: Restore VM ekranı - core-a için snapshot seçimi ve uyarı]

İşlem tamamlandığında core-a'nın kapalı (powered off) olduğu görülüyor, tıpkı uyarıldığı gibi. Snapshot sütununda snapshot sayısının 2'den 3'e çıktığı da fark ediliyor; bu, restore işleminin kendisinin de bir snapshot bıraktığını gösteriyor.

Bu davranış bana mantıklı geldi: bir restore işlemi, geri dönülemez bir işlem değil. Restore öncesi durumun da bir snapshot olarak saklanması, "yanlışlıkla yanlış snapshot'a döndüm" senaryosunda ikinci bir güvenlik ağı sağlıyor.

Silinmiş Bir VM'i Geri Getirmek

Bu, modülün en dramatik anı: tamamen silinmiş bir VM'in snapshot'tan yeniden oluşturulması.

VMs > Removed VMs > core-c seçili > Restore VM

Sihirbaz adımları:

Bir snapshot seçiliyor, NEXT
İsim ve klasör: varsayılan olarak orijinal isim core-c korunuyor, dc-a kök klasöründe kalıyor, NEXT
Compute resource: varsayılan cluster-esa-01a, NEXT
RESTORE

İşlem tamamlandığında core-c, vCenter inventory'sinde tekrar görünüyor, açılmaya hazır durumda. VM'in adı "core" ile başladığı için, cluster'da kaldığı sürece otomatik olarak zaten var olan Core PG protection group'u tarafından korunmaya devam ediyor.

Bu son detay dikkatimi çekti: dinamik isimlendirme kullanan bir protection group, sadece yeni oluşturulan VM'leri değil, geri getirilen VM'leri de otomatik olarak kapsıyor. İsim deseni eşleştiği sürece, VM'in "geçmişi" (silinmiş olması) önemli değil.

VM Klonlamak

vSAN Data Protection, protection group'a atanmış herhangi bir VM'den hızlıca klon oluşturma imkanı da sunuyor. Bu klonlar ESA snapshot'larına dayanıyor ve linked-clone mimarisi kullanıyor; hızlı oluşturma ve yüksek performans sağlıyor, ama bunlar kalıcı VM'ler değil, araştırma veya VM içindeki belirli verileri kurtarma amaçlı geçici kopyalar olarak düşünülmeli.

Önemli bir ayrım: Data Protection'ın ürettiği klonlar, vCenter'ın geleneksel "clone" işleminden farklı ve bu klonlar vSAN Data Protection tarafından korunmaya aday değil.

Klonlama Adımları

VMs > Existing VMs > core-a seçili > Clone VM

Bir snapshot seçiliyor, NEXT
İsim: varsayılan core-a-clone, dc-a kök klasörü, NEXT
Compute resource: varsayılan cluster-esa-01a, NEXT
CLONE

Klon tamamlandığında core-a-clone vCenter inventory'de görünüyor. VMs panelinde bu klonun durumu "Not protected" olarak işaretleniyor.

Klonların Neden Korunmadığını Doğrulamak

Bunu somut olarak görmek için Core PG protection group'u Edit ile açılıyor, "Individual VM selection" seçiliyor. Bu ekranda vSAN Data Protection açıkça uyarıyor: linked-clone VM'ler protection group'larda desteklenmiyor. core-a-clone, aday VM listesinden zaten filtrelenmiş durumda.

Bu kısıtlama mantıklı: bir linked-clone, zaten bir snapshot'a bağımlı bir yapı. Onu tekrar bir protection group'a dahil edip snapshot almaya çalışmak, muhtemelen mimari olarak dairesel bir bağımlılık yaratırdı. Data Protection bu senaryoyu en baştan engelliyor.

Immutable Protection Groups: Ransomware'e Karşı Bir Kilit

Modülün son ve bence en önemli konsepti burada: değiştirilemez (immutable) protection group'lar.

Bir protection group immutable olarak oluşturulduğunda, oluşturulduktan sonra değiştirilemiyor veya iptal edilemiyor. Korunan VM kriterleri (dinamik isimlendirme, bireysel VM seçimi veya ikisinin kombinasyonu), snapshot zamanlaması ve saklama süresi ilk konfigürasyondan sonra sabitleniyor. Protection group da silinemiyor.

Bu tasarımın amacı açık: kötü niyetli aktörlerin (bad actors) koruma planlarına müdahale etmesini veya onları silmesini engellemek. Bu, ransomware saldırısı senaryosunda özellikle anlamlı; bir saldırgan sisteme erişim sağlasa bile, snapshot'ları ve koruma politikasını silip kurtarma imkanını ortadan kaldıramıyor.

Immutable Protection Group Oluşturmak

Protection Groups > Create Protection Group

İsim: Immutable Core Apps
Protection type: Local protection
Immutability mode kutusu işaretleniyor; bu grup oluşturulduktan sonra düzenlenemeyeceğine dair bir uyarı beliriyor
VM seçimi: Dynamic VM name patterns
NEXT

VM isim deseni olarak core* giriliyor. Bu desenle üç VM eşleşiyor: core-a, core-a-clone ve core-c.
Immutable Core Apps

Not: Manuel burada ilginç bir detay veriyor; core-a-clone isim deseni ile eşleşse de (çünkü "core" ile başlıyor), daha önce gördüğümüz gibi linked-clone VM'ler zaten protection group'lardan otomatik filtreleniyor. Yani isim eşleşmesi, filtrelemenin önüne geçmiyor.

Snapshot zamanlaması olarak her 1 günde bir snapshot, 3 aylık saklama süresi belirleniyor. NEXT, sonra CREATE.

Immutability'nin Etkisini Doğrulamak

Yeni oluşturulan protection group'un üç nokta menüsüne bakıldığında, Edit, Pause ve Delete seçeneklerinin gri renkte (devre dışı) olduğu görülüyor. Bu yetenekler immutable protection group'lar için izin verilmiyor.

Dinamik isimlendirme kullanıldığı için, "core" ile başlayan yeni VM'ler vSAN datastore'lara eklendiğinde otomatik olarak korunacak ve snapshot'ları, VM'ler daha sonra silinse bile 3 ay boyunca saklanacak.

Genel Değerlendirme

Modül 7, serinin kapanışı için iyi bir seçim olmuş; çünkü burada gördüğümüz her şey, önceki altı modülde öğrendiğimiz kavramların üzerine inşa ediliyor. Protection group'lar SPBM'in mantığını (politika tanımla, sistem uygula) hatırlatıyor. Replication pairs, Modül 5'teki cluster-arası ilişkileri andırıyor. %70 doluluk eşiği, Modül 1'deki Reserved Capacity mantığıyla aynı prensibi paylaşıyor.

Benim için en dikkat çekici üç nokta şunlardı:

Birincisi, dinamik isim deseninin gücü. Bir VM isim kuralı tanımlamak, gelecekteki tüm uyumlu VM'lerin otomatik korunmasını sağlıyor; bu, "her yeni VM için manuel yapılandırma" yükünü ortadan kaldıran zarif bir tasarım. Aynı zamanda bunun disiplinli bir isimlendirme kuralı gerektirdiğini de görmek gerekiyor; "sales-" ile başlamayan bir satış VM'i sessizce korumasız kalabilir.

İkincisi, restore işleminin kendisinin bir snapshot bırakması. Bu, "geri dönülemez işlem" korkusunu azaltan küçük ama önemli bir güvenlik katmanı.

Üçüncüsü, Immutable Protection Groups. Bu özellik, teknik bir yetenekten çok bir tehdit modeline cevap veriyor: eğer bir saldırgan (ya da yanlışlıkla yetkili bir kullanıcı) sisteme erişim kazanırsa, koruma planının kendisi saldırı yüzeyi olmamalı. Bu, "backup'ınız varsa güvendesiniz" varsayımının yeterli olmadığı, backup'ın kendisinin de korunması gerektiği fikrinin somut bir uygulaması.

Seri Üzerine Kapanış Notu

Yedi modül boyunca vSAN'ı SPBM'den başlayıp izleme, şifreleme, stretched cluster, storage cluster ayrımı, file services ve şimdi data protection'a kadar bir yolculuk olarak takip ettim. HOL formatının en büyük avantajı, hiçbir şeyi bozma korkusu olmadan bu kadar geniş bir yüzeyi tek bir ortamda gezebilmekti.

Ama başta da söylediğim gibi, bunun sınırlarını da net tutmak istiyorum: gerçek bir production ortamında bu kararların her biri, burada göremediğimiz baskılarla (bütçe, mevcut donanım, ekip deneyimi, değişim yönetimi süreçleri) birlikte alınıyor. Bu seri, o kararları alacak kişi olmaya değil, o kararların neye dayandığını anlayacak bir zemine sahip olmaya yardımcı olmayı amaçladı.

Serinin geri kalanını okuyanlara teşekkürler. Bir sonraki öğrenme serisinde görüşmek üzere.

Bu seri VMware HOL ortamı (HOL-2634-01-VCF-L) üzerinden yürütülmektedir. Buradaki gözlemler lab bağlamında değerlendirilmeli, production ortamı kararları için mutlaka resmi VMware dokümantasyonu ve deneyimli mühendisler referans alınmalıdır.

vSAN File Services: Datastore Üzerinde Dosya Paylaşımı (Modül 6)

Hakan İSMAİL — Sun, 19 Jul 2026 12:58:34 +0000

Beş haftadır vSAN'ın blok depolama tarafını (VMDK'lar, storage policy'ler, cluster mimarileri) işledim. Modül 6 farklı bir katmana giriyor: File Services. Bu modülde vSAN datastore üzerinde NFS ve SMB paylaşımları oluşturmayı, bunları izlemeyi ve gerçek bir client'tan mount edip dosya yazmayı görüyoruz.

Bu konu ilk bakışta "neden vSAN bir NAS gibi davransın ki" sorusunu akla getirebiliyor. Ama mantığını anlayınca aslında oldukça pratik bir kullanım alanı ortaya çıkıyor: zaten var olan vSAN altyapısını, ayrı bir dosya sunucusu kurmadan, dosya paylaşımı ihtiyaçları için de kullanabilmek.

vSAN File Services Nedir?

vSAN File Services, vSAN datastore üzerinde dosya paylaşımları (file share) oluşturmayı sağlıyor; bu paylaşımlara client workstation'lar veya VM'ler erişebiliyor. Desteklenen protokoller: SMB, NFSv3 ve NFSv4.1.

Mimarinin altında vSAN Distributed File System (vDFS) yatıyor. Bu, vSAN nesnelerini birleştirerek ölçeklenebilir bir dosya sistemi sağlıyor. File share'ler, mevcut Storage Policy Based Management mekanizmasına entegre; yani her paylaşıma, VMDK'lara atadığımız gibi bir storage policy atanabiliyor.

Teknik olarak dikkat çeken bir nokta: File Service etkinleştirildiğinde vSAN, cluster için tek bir vDFS dağıtık dosya sistemi oluşturuyor ve bunu her host üzerinde container'lar halinde çalıştırıyor. Bu container'lar hypervisor ile sıkı entegre, dosya servislerini sağlamanın birincil aracı olarak çalışıyorlar.

IP Havuzu Mantığı

File Service etkinleştirilirken statik bir IP adres havuzu tanımlanması gerekiyor. Bu havuzdaki adreslerden biri "primary IP" olarak atanıyor; SMB ve NFSv4.1 referral mekanizması sayesinde, tüm paylaşımlara bu tek IP üzerinden erişilebiliyor.

Her IP adresi için ayrı bir file server başlatılıyor, ama paylaşımlar bu sunucular arasında dengeli dağıtılıyor. İdeal performans için IP adres sayısının, vSAN cluster'ındaki host sayısına eşit olması öneriliyor. Bu IP'lerin DNS'te forward ve reverse lookup kayıtlarının olması da gerekiyor.

Bu detayı okurken şunu düşündüm: bu, tipik bir load-balanced servis mimarisi. Tek bir giriş noktası (primary IP) sunarken arkada birden fazla worker'a (file server) dağıtım yapması, kullanıcı deneyimini basitleştirirken ölçeklenebilirliği koruyor.

Bir Kısıtlama: Stretched Cluster Desteklenmiyor

Manuel'de net bir uyarı var: File Services şu anda vSAN Stretched Cluster üzerinde desteklenmiyor, sadece normal (standart) bir vSAN cluster üzerinde etkinleştirilebiliyor. Bu, Modül 4'te öğrendiğimiz stretched cluster mimarisiyle File Services'i aynı cluster'da birleştiremeyeceğimiz anlamına geliyor; bu iki özelliği aynı anda isteyen bir tasarım için ayrı cluster'lar planlamak gerekecek.

Ağ Gereksinimleri

File Services'i etkinleştirmeden önce birkaç ağ gereksinimi karşılanmalı:

Dosya paylaşımlarına tek erişim noktası olacak statik IP adresleri; en iyi performans için host sayısı kadar.
Bu IP'lerin DNS'te forward ve reverse lookup zone'larında kayıtlı olması.
Tüm statik IP'lerin aynı subnet'te olması.
DVS (Distributed Virtual Switch) sürüm 6.6.0 veya üzeri; File Service için ayrı bir dedicated port group oluşturulması.
Promiscuous Mode ve Forged Transmits'in, File Services etkinleştirme süreci sırasında otomatik olarak açılması. NSX tabanlı ağlar kullanılıyorsa bu ayarların NSX admin konsolundan da yapılması gerekiyor.

HOL'da File Services zaten önceden etkinleştirilmiş durumda; biz bu adımları uygulamıyoruz, ama gerçek bir kurulumda networking hazırlığının en az storage cluster networking'i kadar dikkat gerektirdiğini not etmek istedim (Modül 5'teki front-end/back-end ayrımına benzer bir dikkat seviyesi burada da geçerli).

File Services'in Etkin Olduğunu Doğrulamak

Site B vCenter'a giriş yapılıyor (vc-mgmt-b). Doğrulama adımları:

dc-b > vsan-storage-cluster-01b > Configure > vSAN > Services

Aşağı kaydırılınca File Service bölümünün "Enabled" durumda olduğu görülüyor.

Bu bölümde file service'in ağ detayları da görünüyor. Sol panelde vsan-storage-cluster-01b altında vSAN File Service node'larının oluşturulduğu görülüyor; her vSAN node için bir tane. Her File Service VM'i (FSVM) en fazla 50 paylaşım destekliyor, cluster başına toplam paylaşım limiti 500 (bunun içinde en fazla 100 tanesi SMB paylaşımı olabiliyor).

Bu limitleri görünce aklıma şu geldi: 500 paylaşım/cluster gibi bir üst sınır, küçük-orta ölçekli dosya paylaşımı ihtiyaçları için gayet yeterli, ama büyük bir dosya sunucusu konsolidasyonu planlıyorsanız bu sınırı erkenden hesaba katmak gerekiyor.

File Server Health Check

File Service'in sağlığını kontrol etmek için Skyline Health'e dönüyoruz, artık tanıdık bir akış:

Monitor > vSAN > Skyline Health > Health findings > ALL > Category filtresi > File Service

"File Server Health" bulgusunun üç nokta menüsünden "View Current Result" seçiliyor. Bu ekran, File Servers Service'e katkı veren host'ları, her file server node'unda çalışan servisleri ve atanmış IP adreslerini detaylı olarak gösteriyor.

Bu adım, Modül 3'teki (şifreleme) health check akışıyla neredeyse birebir aynı desende ilerliyor: kategori filtrele, bulguyu seç, View Current Result ile detaya in. vSAN'ın health check mimarisinin tutarlılığı, farklı özellikler için bile aynı zihinsel modeli kullanmanıza izin veriyor.

NFS Paylaşımı Oluşturmak

Paylaşım isimlendirmesi için birkaç kural var, not almaya değer:

ASCII olmayan karakterler içeren kullanıcı adları paylaşım verisine erişim için kullanılabiliyor.
Paylaşım isimleri sadece İngilizce karakterler içerebiliyor.
Salt NFSv4 tipi paylaşımlarda dosya ve dizin isimleri herhangi bir UTF-8 uyumlu karakter içerebiliyor.
Salt NFSv3 ve NFSv3+NFSv4 paylaşımlarında dosya ve dizin isimleri sadece ASCII uyumlu olabiliyor.

Bu kısıtlama listesi ilk okuyuşta teknik bir detay gibi görünüyor, ama gerçek bir ortamda özellikle Türkçe karakterler (ç, ş, ğ, ı, ö, ü) içeren dosya/dizin isimleriyle çalışırken, protokol seçiminin (salt NFSv4 mü, yoksa NFSv3 uyumlu mu) doğrudan bir etkisi olacağını gösteriyor.

Oluşturma Adımları

vsan-storage-cluster-01b > Configure > vSAN > File Shares > ADD

General sayfası:

İsim: VMSharesNFS
Protokol: NFS, hem NFS 4.1 hem NFS 3 versiyonları seçili
Storage Policy: vsan-storage-cluster-01b - Optimal Datastore Default Policy - RAID5
Share warning threshold 5 GB, share hard quota 10 GB olarak etkinleştiriliyor
NEXT

Net access control sayfası:

"Allow access from any IP" seçiliyor
NEXT

Review sayfası: Girilen bilgiler gözden geçirilip FINISH ile paylaşım oluşturuluyor.

Burada dikkatimi çeken şey, storage policy'nin ve quota ayarlarının (warning threshold, hard quota) aynı wizard içinde birlikte tanımlanması. Bu, bir dosya paylaşımının sadece "nerede depolanacağını" değil, aynı zamanda "ne kadar büyüyebileceğini" de aynı yerde yönetmenizi sağlıyor.

Oluşturulan Paylaşımı Görüntülemek

Paylaşım listesinde VMSharesNFS, atanmış storage policy, kullanım/kota ve gerçek kullanım bilgileriyle görünüyor. "Show or Hide Columns" ile Hard Quota ve Warning Threshold sütunları da eklenebiliyor.

Paylaşımı Başka Sistemlere Mount Etmek

Bu bölüm, HOL'un daha "elle dokunulan" kısımlarından biri; gerçekten bir Linux terminalinden mount komutu çalıştırıp dosya yazıyoruz.

Bağlantı Yolunu Kopyalamak

VMShareNFS seçilip "COPY PATH" dropdown'ından NFS 3 veya NFS 4.1 seçilebiliyor. NFS 4.1 seçildiğinde örnek bağlantı dizesi şöyle görünüyor:

NFSv3: vsan-fs-06a.vcf.sddc.lab:/VMSharesNFS
NFSv4.1: vsan-fs-01a.vcf.sddc.lab:/vsanfs/VMSharesNFS

Not: NFSv4.1 referral mekanizmasıyla mount etmek için, mount path'inde kök paylaşımı (/vsanfs) dahil edilmesi gerekiyor.

Terminal Üzerinden Mount Etmek

Terminal açılıp şu komut çalıştırılıyor:

sudo mount vsan-fs-07b.site-b.vcf.lab:/VMSharesNFS /mnt/newfs

Şifre istendiğinde VMware123!VMware123! giriliyor. Mount'un başarılı olduğu şu komutla doğrulanıyor:

sudo mount | grep /mnt/newfs

Manuel'de bir not var: NFS 4.1 aynı zamanda varsayılan mount versiyonu; eğer protokol belirtilmezse, client sunucuyla en yüksek uyumlu protokolü otomatik müzakere ediyor, vSAN 9 Native File Services için bu NFS v4.1.

Dosya Yazıp Okumak

cd /mnt/newfs
echo "NFS 4 Share" >> newfs.txt
cat newfs.txt

Bu üç komutla paylaşıma bir dosya yazılıyor ve tekrar okunarak doğrulanıyor.

Bu basit test, aslında modülün en somut kanıtı: vSAN üzerinde oluşturduğumuz bir "storage policy'ye bağlı nesne", gerçek bir Linux client'tan standart NFS protokolüyle erişilebilir, yazılabilir bir dosya sistemi olarak çalışıyor. Bunun arkasında vDFS, container'lar, IP havuzu gibi karmaşık bir mimari olsa da, client tarafında deneyim sıradan bir NFS mount'undan farksız.

vSAN Nesne Görünümü ve Placement Details

Paylaşımın vSAN'ın kendi nesne yapısına nasıl entegre olduğunu görmek için:

vsan-storage-cluster-01b > Monitor > vSAN > Virtual Objects

VMSharesNFS seçilip "VIEW PLACEMENT DETAILS" tıklanıyor.

Bu ekran, dosya paylaşımının bileşenlerinin hangi host'larda ve hangi fiziksel storage cihazlarında yerleştiğini gösteriyor.

Bu, Modül 1'de bir VM'in VMDK'sı için gördüğümüz Placement Details ekranıyla aynı arayüz, aynı mantık. Bir dosya paylaşımının da tıpkı bir sanal disk gibi vSAN nesnesi olarak ele alınması ve aynı görselleştirme aracıyla incelenebilmesi, vSAN'ın "her şey bir nesne" felsefesinin tutarlılığını gösteriyor.

File Service Health'i Tekrar Kontrol Etmek

Yeni paylaşım oluşturulduktan sonra Skyline Health'e dönülüp RETEST yapılıyor (health check zaten periyodik çalışıyor, ama yeni bir servis eklendiği için manuel tetiklemek öneriliyor).

Filtre yine File Service kategorisine ayarlanıyor. Bu sefer "Share Health" bulgusunun üç nokta menüsünden "View Current Result" seçiliyor.

Sonuç, oluşturduğumuz paylaşımın sağlıklı olduğunu gösteriyor.

Performans ve Kapasite İzleme

File Services için de, önceki modüllerde gördüğümüz izleme mantığı geçerli.

Performans:

vsan-storage-cluster-01b > Monitor > vSAN > Performance > FILE SHARE > VMSharesNFS

Burada file service için toplanan çeşitli metrikler görülüyor.

Kapasite:

Monitor > vSAN > Capacity, aşağı kaydırılıp "Usage breakdown" bölümünde "User Data" genişletilerek File Shares kapasite kullanımı görülüyor.

Bu iki ekran, Modül 2'de öğrendiğimiz izleme çerçevesinin (Skyline Health, Kapasite, Performans) File Services için de birebir geçerli olduğunu gösteriyor. Yeni bir özellik öğrenirken sıfırdan bir izleme mantığı öğrenmek yerine, var olan çerçeveyi yeni bir nesne tipine uygulamak yeterli oluyor.

Genel Değerlendirme

Bu modül, vSAN'ın "sadece blok depolama" olmadığını gösteren iyi bir örnekti. File Services, temelde aynı vSAN altyapısını (aynı disk grupları, aynı SPBM mekanizması, aynı health check çerçevesi) kullanarak farklı bir erişim modeli (dosya paylaşımı) sunuyor.

Benim için en dikkat çekici üç nokta şunlardı:

Birincisi, IP havuzu ve primary IP mekanizmasının load-balancing mantığıyla çalışması. Host sayısı kadar IP tanımlayıp bunları file server'lara dağıtmak, basit ama etkili bir ölçeklenebilirlik yaklaşımı.

İkincisi, paylaşım isimlendirme kurallarındaki ASCII/UTF-8 ayrımı. Küçük bir detay gibi görünüyor ama gerçek bir ortamda, özellikle Türkçe gibi ASCII-dışı karakterler kullanan dil ortamlarında, protokol seçiminin doğrudan pratik bir etkisi oluyor.

Üçüncüsü, tüm bu modül boyunca "yeni bir şey öğreniyormuşum" hissinden çok, "tanıdık araçları yeni bir nesne tipine uyguluyormuşum" hissi baskındı. Placement Details, Skyline Health akışı, Performance ve Capacity sekmeleri; hepsi önceki modüllerden tanıdık. Bu tutarlılık, vSAN'ın farklı özelliklerini öğrenirken kümülatif bir öğrenme eğrisi sağlıyor: her yeni modül, sıfırdan başlamak yerine önceki modüllerin üzerine inşa ediyor.

Bir sonraki hafta son modül olan Modül 7'ye geçiyorum: Data Protection.

vSAN Storage Cluster: Compute'u Storage'dan Ayırmak (Modül 5)

Hakan İSMAİL — Sun, 12 Jul 2026 10:51:18 +0000

Dört haftadır Site A üzerinde çalışıyordum: SPBM, izleme, şifreleme, stretched cluster. Modül 5 ile birlikte ilk kez Site B'ye geçiyorum ve konu da farklı bir yöne kırılıyor: vSAN Storage Cluster.

Bu modül, önceki dördünden kavramsal olarak ayrı bir yerde duruyor. Şimdiye kadar gördüğümüz her şey HCI (Hyper-Converged Infrastructure) mantığıyla çalışıyordu; yani her host hem compute hem storage sağlıyordu. Storage Cluster ise bu ikisini birbirinden ayırıyor. Bunun neden var olduğunu ve HOL'da nasıl göründüğünü aktarayım.

vSAN Storage Cluster Nedir?

vSAN Storage Cluster, eski adıyla vSAN Max, vSphere cluster'ları için dağıtık, scale-out bir depolama sistemi. vSAN ESA tarafından güç alıyor, yani ESA'nın sunduğu tüm yeteneklere sahip, ama sadece depolama sağlayan bir cluster olarak çalışıyor.

Buradaki kritik ayrım şu: Normal vSAN'da (HCI modelinde) bir host hem VM'leri çalıştırır hem de kendi diskini vSAN datastore'a katkı verir. Storage Cluster modelinde ise bazı cluster'lar sadece depolama sağlıyor (compute çalıştırmıyor), bazı cluster'lar ise sadece compute sağlayıp bu depolamayı uzaktan tüketiyor.

Bu, disaggregation (ayrıştırma) dediğimiz bir mimari yaklaşım. Compute ve storage kaynaklarını ayrı ayrı ölçeklendirebiliyorsunuz; storage ihtiyacınız artınca sadece storage cluster'ı büyütüyorsunuz, compute cluster'a dokunmadan.

Cross-cluster iletişim için vSAN'ın kendi native protokolü ve data path'i kullanılıyor. Bu, yönetim deneyimini koruyor ve dağıtık bir depolama sistemi için mümkün olan en yüksek performans ve esnekliği sağlıyor iddiasında.

HOL Ortamındaki İki Cluster

Site B'de iki cluster önceden hazır geliyor:

vsan-storage-cluster-01b: Depolama sağlayan cluster.
vsan-client-cluster-01b: Bu depolamayı tüketen compute cluster.

Bu ayrımı doğrulamak için ilk yapılan şey, her iki cluster'ın Configure sekmesinden vSAN > Services altındaki "Cluster type" alanına bakmak.

vsan-storage-cluster-01b için Cluster type "vSAN Storage Cluster" olarak görünüyor; bu cluster diğer compute cluster'lara depolama sağlamaya adanmış.

vsan-client-cluster-01b için ise Cluster type "vSAN Compute Cluster" olarak görünüyor; bu cluster diğer vSAN storage cluster'ların depolamasını tüketmeye adanmış.

Bu iki etiketin ayrı ayrı görünmesi bana önemli geldi. Sistem, bir cluster'ın rolünü GUI seviyesinde açıkça belirtiyor; "bu cluster ne için var" sorusuna dolaşmadan cevap veriyor.

Mount Edilmiş Datastore'u Görmek

Compute cluster'ın, storage cluster'daki datastore'u gerçekten kullandığını doğrulamak için:

vsan-client-cluster-01b > Configure > vSAN > Datastore Management

Burada vsan_SC_Datastore adlı datastore'un, vsan-storage-cluster-01b cluster'ında bulunduğu ve compute cluster tarafından mount edildiği görülüyor.

Bu ekran, HCI modelindeki "VM burada, disk de burada" basitliğinden farklı bir gerçekliği gösteriyor: VM'in compute'u bir cluster'da, verinin fiziksel olarak bulunduğu yer başka bir cluster'da.

Ağ Trafiği Ayrımı: Front-End ve Back-End

Bu modülün bence en önemli teknik detayı burada. VCF 9.0 ile vSAN Storage Cluster'lara yeni bir yapılandırma seçeneği geldi: depolama performansını artıran, ağ trafiği izolasyonunu ve güvenliği iyileştiren bir ayrım.

İki tür trafik tanımlanıyor:

Guest VM I/O (front-end trafik): Guest VM'e giden/gelen, vSAN datastore'a erişen trafik.

vSAN I/O (back-end trafik): vSAN datastore'daki node'lar arasında akan trafik; yani vSAN'ın kendi iç senkronizasyon ve replikasyon trafiği.

VCF 9.0 için vSAN, bu iki trafiği ayrı VMkernel portları üzerinden ayırma yeteneği getiriyor. Bu ayrım, Modül 2'de gördüğümüz cluster seviyesindeki front-end/back-end trafik ayrımıyla kavramsal olarak aynı fikri paylaşıyor, ama burada fiziksel port seviyesinde uygulanıyor.

Storage Cluster Node'unun VMkernel Arayüzleri

esx-05b.site-b.vcf.lab üzerinde iki vSAN'a özgü VMkernel portu inceleniyor:

vmk2: vSAN servisi için etkin. Storage Cluster bağlamında bu port, storage cluster node'ları arasındaki vSAN I/O'dan (back-end trafik) sorumlu.

vmk3: vSAN Storage Cluster Client servisi için etkin. Bu port, storage cluster node'larının, client cluster'daki vSAN VMkernel portlarıyla iletişim kurup Guest VM I/O'yu (front-end trafik) taşımasından sorumlu.

Compute Cluster Node'unun VMkernel Arayüzü

esx-09b.site-b.vcf.lab üzerinde ise tek bir vSAN'a özgü VMkernel portu var:

vmk2: vSAN servisi için etkin. Compute Cluster bağlamında bu port, storage cluster node'larındaki vSAN Storage Cluster Client portlarıyla iletişim kurup Guest VM I/O'yu (front-end trafik) taşıyor.

Burada dikkatimi çeken şey, storage cluster node'unda iki ayrı port varken (biri back-end, biri front-end için), compute cluster node'unda sadece bir port olması. Mantıklı: compute cluster kendi verisini tutmuyor, sadece storage cluster'a Guest VM I/O gönderiyor; kendi içinde bir back-end senkronizasyon trafiğine ihtiyacı yok.

Bu ayrım, gerçek bir ortamda ağ tasarımı yaparken önemli bir referans noktası. Storage cluster tarafında iki ayrı VMkernel portu (ve muhtemelen iki ayrı fiziksel NIC veya VLAN) planlamak, front-end ve back-end trafiğinin birbirini etkilememesi için gerekli.

Compute Cluster'a VM Deploy Etmek

Bu bölümde core-b VM'i klonlanarak vsan-client-cluster-01b compute cluster'ına deploy ediliyor. Manuel'de vurgulanan önemli nokta şu: bu süreç, normal bir vSAN HCI cluster'ına VM deploy etmekle aynı. Tek fark, compute resource olarak compute cluster'ı, datastore olarak da storage cluster'daki vSAN datastore'unu seçmeniz.

Adımlar

core-b üzerine sağ tık → Clone → Clone to Virtual Machine
İsim: clone-vm-b
Compute resource: vsan-client-cluster-01b
VM Storage Policy: cluster-esa-01b - Optimal Datastore Default Policy - RAID1
Datastore: vsan_SC_Datastore

Bu akış, Modül 1'de core-a VM'ini klonlarken gördüğümüz sürecin neredeyse birebir aynısı. Aradaki fark sadece hangi cluster'ın compute, hangi datastore'un hedef olarak seçildiği; SPBM mekanizması, wizard akışı, hepsi tanıdık.

Sonucu Doğrulamak

Klon tamamlandıktan sonra clone-vm-b > Summary > Related Objects bölümünde şunlar görülüyor:

VM, vsan-client-cluster-01b compute cluster'ında bulunuyor.
VM'in verisi ise vsan_SC_Datastore datastore'unda duruyor.

Bu iki bilginin ayrı ayrı, ayrı nesneler olarak görünmesi, disaggregated mimarinin özünü gösteriyor: VM'in "nerede çalıştığı" ile verisinin "nerede durduğu" artık aynı host'a bağlı değil.

Genel Değerlendirme

Bu modül kısa ama kavramsal olarak önceki dördünden farklı bir zihniyet gerektiriyor. HCI modelinde "compute ve storage aynı host'ta" varsayımı o kadar yerleşik ki, bunu ayırmanın ne gibi bir esneklik getirdiğini görmek için ayrı bir cluster çiftini incelemek gerekiyordu.

Benim için en dikkat çekici iki nokta şunlardı:

Birincisi, front-end/back-end trafik ayrımının VMkernel port seviyesinde somutlaşması. Modül 2'de bu ayrımı sadece bir monitoring sekmesi (Backend vs VM sekmeleri) olarak görmüştüm; burada aynı ayrımın fiziksel ağ tasarımına nasıl yansıdığını görmek, kavramı daha somut hale getirdi. Storage cluster node'unda iki ayrı port, compute cluster node'unda tek port olması, hangi tarafın hangi trafiği taşıdığını networking seviyesinde de ayırt edilebilir kılıyor.

İkincisi, VM deploy etme sürecinin HCI'dakiyle neredeyse aynı olması. Bu bana şunu gösterdi: vSAN Storage Cluster, kullanıcı deneyimi açısından büyük bir öğrenme eğrisi getirmiyor; asıl fark mimari seviyede, admin'in cluster'ları nasıl tasarladığında. Bir VM deploy eden birisi için "bu storage cluster'dan mı geliyor, yoksa HCI'dan mı" ayrımı büyük ölçüde görünmez kalıyor, ki bu da tasarımın amaçladığı şey.

Gerçek sahada bu mimariyi ne zaman tercih edeceğim sorusunu düşününce, akla gelen ilk senaryo şu: storage ve compute ihtiyaçlarının farklı oranlarda büyüdüğü ortamlar. Compute-yoğun ama storage-hafif workload'lar için (ya da tam tersi) ayrı ayrı ölçeklendirme yapabilmek, her host'a hem compute hem storage eklemek zorunda kalmaktan daha esnek bir yaklaşım olabilir. Ama bunun getirdiği ek ağ tasarımı karmaşıklığını (front-end/back-end ayrımı, ek VMkernel portları) da hesaba katmak gerekiyor.

Bir sonraki hafta Modül 6'ya geçiyorum.

vSAN Stretched Cluster: Site Koruması ve Local Affinity (Modül 4)

Hakan İSMAİL — Sun, 05 Jul 2026 07:51:38 +0000

Üç haftadır SPBM, izleme ve şifreleme konularını işledim. Bu hafta Modül 4'e geçiyorum: vSAN Stretched Cluster. Önceki modüllere göre bu konu kavramsal olarak biraz daha zorlayıcı geldi; tek bir cluster'ı iki fiziksel siteye yaymak, hem ağ mimarisi hem de failure senaryoları açısından yeni bir düşünme biçimi gerektiriyor.

Şunu baştan belirtmek isterim: HOL ortamı bunu tam olarak simüle edemiyor, manuel de bunu açıkça söylüyor. İki site arası gerçek bir 10GbE bağlantısı ya da crossover kablo burada yok. Ama stretched cluster'ı hazırlama adımları ve witness trafiğini ayırma mantığı, gerçek bir direct-connect cluster'da yapılanla aynı.

Stretched Cluster Nedir, Neden Var?

Normal bir vSAN cluster'ı tek bir lokasyonda çalışır. Stretched cluster ise aynı cluster'ı iki fiziksel siteye yayıyor: veri her iki sitede de bir kopya halinde tutuluyor. Amaç, bir sitenin tamamen kaybedilmesi durumunda bile VM'lerin diğer sitede çalışmaya devam etmesi.

Bunu mümkün kılan üçüncü bir bileşen var: Witness Host. Bu, veri taşımayan, sadece quorum (çoğunluk kararı) sağlayan özel bir sanal cihaz. 1+1+1 mimarisi şöyle işliyor: Site 1'de en az bir host, Site 2'de en az bir host, ve ayrı bir yerde bir witness host.

2-Node Direct Connect Senaryosu

vSAN 6.5'ten itibaren 2-node konfigürasyonlarda doğrudan crossover kablo kullanımı destekleniyor. Bu özellikle ROBO (remote office/branch office) senaryolarında değerli: her lokasyona 10GbE switch altyapısı kurmak maliyetli ve karmaşık olabiliyor. İki host'u doğrudan birbirine bağlamak bu maliyeti ortadan kaldırıyor, aynı zamanda karmaşıklığı azaltıp güvenilirliği artırıyor.

Preferred Site Kavramı

Stretched cluster'da "preferred site" (tercih edilen site) diye bir kavram var. Bu, vSAN'a "iletişim koptuğunda hangi tarafın ayakta kalmasını istiyorum" demenin yolu. Denilebilir ki preferred site, en güvenilir olması beklenen taraf.

Mantık şöyle işliyor: Site 1 ile Site 2 arasındaki bağlantı koparsa ama her iki site de witness host'a erişebiliyorsa, preferred site çalışmaya devam ediyor ve bileşenleri aktif kalıyor. Preferred olmayan site'daki storage ise "down" olarak işaretleniyor, bileşenler "absent" durumuna geçiyor.

Bu, klasik bir split-brain önleme mekanizması. Witness, kimin "doğru" taraf olduğuna karar veren hakem rolünü oynuyor.

Read Locality: Okuma Trafiğini Yerel Tutmak

Bu kısım benim için modülün en pratik bilgisi oldu. Normal vSAN'da okuma istekleri, verinin tüm replika kopyaları arasında round-robin şeklinde dağıtılıyor. Stretched cluster'da ise bu davranış değişiyor.

Read locality algoritması, okumaların yüzde yüzünü compute'un bulunduğu site'daki yerel veri kopyasından yapıyor. Mantığı açık: VM'in compute kaynağı Site 1'deyse, okuma isteklerini Site 2'ye göndermek gereksiz bir ağ gecikmesi (latency) yaratır. Bu yeni algoritma, okuma işlemlerindeki gecikmeyi azaltmak için tasarlanmış.

Manuel'de ilginç bir eşik veriyor: Eğer siteler arası gecikme 5ms'nin altındaysa ve yeterli bant genişliği varsa, read locality kapatılabiliyor. Ama bunu kapatmak, okuma trafiğinin yarısının uzak siteye gitmesi anlamına geliyor; bu da ağ bant genişliği planlaması için ciddi bir fark yaratıyor. Manuel ayrıca bunun yalnızca VMware Global Support Services rehberliğinde ve sadece son derece düşük gecikme olan ortamlarda yapılması gerektiğini özellikle vurguluyor. Yani bu varsayılan davranışı kapatmak bir "ileri seviye ayar" değil, neredeyse bir istisna durumu.

Bununla ilgili gizli bir advanced parameter de var: VSAN.DOMOwnerForceWarmCache. Bu, vSphere Web Client'ta görünmüyor, sadece CLI üzerinden erişilebiliyor. Bunun gizli tutulması bana mantıklı geldi; yanlışlıkla değiştirildiğinde etkisi geniş olabilecek bir ayar.

Witness Host: Cluster'ın Dışında Kalan Üye

Burada altı önemle çizilen bir kural var: Stretched cluster yapılandırılırken sadece data host'lar cluster objesinin içinde olmalı. Witness host, cluster dışında kalmalı ve hiçbir aşamada cluster'a eklenmemeli.

HOL ortamında witness host önceden deploy edilmiş durumda: esx-11a.site-a.vcf.lab. Inventory görünümünde bu host'un sunucu ikonunda küçük bir işaret var; bunun normal bir ESX host değil, vSAN 2-Node ve Stretched Cluster mimarilerini desteklemek için kullanılan özel bir sanal cihaz olduğunu gösteriyor.

Witness Networking: İki Ayrı Arayüz

Witness appliance'ın iki ağ adaptörü var, iki ayrı standart switch'e bağlı:

Management VMkernel (vmk0): vCenter ile iletişim için, appliance yönetimi amacıyla.
secondaryPG (vmk1): vSAN ağıyla iletişim için.

Bu ayrım önerilen konfigürasyon. Bu iki arayüz farklı ya da aynı ağlara bağlanabilir, yeter ki ilgili servislere erişimleri olsun. Management arayüzü vSAN trafiğini de taşıyacak şekilde tag'lenebilir, ama bu durumda vmk0'ın hem vCenter'a hem vSAN ağına erişimi olması gerekiyor.

Manuel'de nested ortamlar için ilginç bir not var: VMware'in bu HOL için kullandığı platform gibi birçok nested ESX ortamında, promiscuous mode'u etkinleştirme önerisi var. Sebebi şu: sanal switch, tanımadığı nested vmnic'ler için paketleri düşürebiliyor; promiscuous mode bunu önlüyor. HOL'da bu zaten yapılandırılmış durumda, ama gerçek bir nested ortamda bu ayarı unutursanız witness trafiği sessizce kaybolabilir; bunu hatırlamak gerekiyor.

Witness üzerinde secondaryPg adında önceden tanımlanmış bir portgroup var, vSAN trafiği için kullanılan VMkernel port burada görünüyor. vSAN ağında DHCP sunucusu yoksa (ki genelde yok), VMkernel adaptörünün geçerli bir IP adresi olmayacaktır; bu durumda manuel IP ataması gerekiyor.

Static Route Gerekliliği

Stretched cluster yapılandırılmadan önceki son adım, her sitedeki host'lar ile witness host arasında bağlantının sağlandığından emin olmak. Bu bağlantıyı yapılandırmadan önce doğrulamak önemli.

vSAN ağı, veri siteleri arasında stretched bir L2 broadcast domain olarak öneriliyor, ama witness appliance'ın vSAN ağına ulaşmak için L3 (routing) gerekiyor. Bu yüzden veri host'ları ile witness arasında static route'lar tanımlanması gerekiyor; ama farklı sitelerdeki veri host'larının birbiriyle iletişimi için bu gerekmiyor, çünkü onlar zaten aynı L2 domain'de.

Bir static route eklemek için kullanılan esxcli komutu manuel'de örnek olarak veriliyor; route bilgisini görüntülemek için ayrı komutlar da mevcut (network komşularını listeleyen ve gateway bilgisini gösteren komutlar). Bu adımın her host için tekrarlanması gerektiği özellikle vurgulanıyor.

Bu kısmı okurken şunu düşündüm: GUI üzerinden yapılan çoğu adımın aksine, bu networking hazırlığı CLI bilgisi gerektiriyor. HOL'da bu adım atlanmış, zaten hazır geliyor, ama gerçek bir kurulumda muhtemelen en çok zaman alacak ve en çok hata yapılacak adım burası olurdu.

Mevcut Cluster'ı Stretched Cluster'a Dönüştürmek

HOL'da var olan 4-node cluster'ı (esx-05a, 06a, 07a, 08a) stretched cluster'a çeviriyoruz. İki host daha (esx-09a, esx-10a) cluster'a ekleniyor, toplam 6 node oluyor.

Host'ları Cluster'a Eklemek

Önce her iki host'ta da (esx-09a ve esx-10a) vSAN VMkernel adaptörünün doğru yapılandırıldığı, Configure > VMkernel Adapters üzerinden kontrol ediliyor.

Ardından host'lar sürükle-bırak ile cluster'a ekleniyor. Açılan onay penceresi varsayılan ayarlarla geçiliyor. Host cluster'a eklendikten sonra, eğer maintenance mode'daysa sağ tık ile Exit Maintenance Mode uygulanıyor. Bu işlem birkaç dakika sürebiliyor, Recent Tasks üzerinden takip edilebiliyor.

Fault Domain Yapılandırması

Asıl dönüşüm burada başlıyor:

cluster-esa-01a > Configure > vSAN > Fault Domains > CONFIGURE STRETCHED CLUSTER

Açılan ekranda host'lar iki domain'e ayrılıyor. Varsayılan olarak hepsi "preferred" tarafında görünüyor; esx-08a, esx-09a ve esx-10a seçilip >> ile secondary domain'e taşınıyor.

Sonraki adımda witness host seçiliyor: esx-11a. vSAN burada otomatik bir uyumluluk kontrolü çalıştırıyor; witness'ın bu cluster ile kullanılabilir olup olmadığını doğruluyor.

Review ekranında vSAN, oluşturacağı cluster konfigürasyonunun özetini gösteriyor; burada, dönüştürme işlemi tamamlanmadan önce düzeltme yapma fırsatı da veriliyor. FINISH ile cluster oluşturuluyor.

İşlem sırasında Recent Tasks panelinden ilerleme izlenebiliyor; tüm görevler "Completed" olana kadar beklemek gerekiyor.

Sonucu Doğrulamak

cluster-esa-01a > Configure > vSAN > Fault Domains ekranına dönüldüğünde:

Failures To Tolerate (FTT) değeri 1 olarak görünüyor. Bu, cluster'ın herhangi bir site'ın (ya da witness host'un) kaybını tolere edip VM'leri çalışır tutabileceği anlamına geliyor.
İki fault domain ve bunlara ait host'lar listede görünüyor.

Manuel'de önemli bir mimari notu var: Site Mirroring ile FTT=1 kombinasyonu, stretched cluster'lar için önerilen standart mimari. 6 node ve üzeri büyük stretched cluster'larda, site içi ek koruma katmanı da isteğe bağlı olarak yapılandırılabiliyor; bu seçimler tipik vSAN politikalarıyla (RAID-1 mirroring, RAID-5 ve RAID-6 erasure coding) uyumlu. Yani site-level koruma ile site-içi koruma birbirinden ayrı, üst üste konumlandırılabilen iki katman.

Nested Ortam Uyarıları

HOL, nested bir vSphere ortamında çalıştığı için vCenter, vSAN cluster'ının sağlığı hakkında birkaç uyarı gösteriyor. Manuel açıkça şunu söylüyor: bu lab kapsamında bu uyarıları görmezden gelmek veya susturmak sorun değil, ama gerçek workload barındıran herhangi bir "canlı" vSAN cluster'ında bu tür uyarıları Skyline Health servisi üzerinden detaylıca araştırmak gerekiyor.

Bu küçük ama önemli bir uyarı; HOL'da görülen "her şey kırmızı/sarı" görünümünün gerçek ortamda aynı ciddiyetle ele alınmaması gerektiğini hatırlatıyor, ama aynı zamanda gerçek ortamda bu uyarıların asla göz ardı edilmemesi gerektiğini de.

Skyline Health: Stretched Cluster'a Özel Kontroller

Cluster oluşturulduktan sonra Skyline Health'te yeni bulgular ortaya çıkıyor. RETEST'e basıldığında "vSAN optimal datastore default policy configuration" başlıklı bir uyarı görülüyor; üç nokta menüsünden TROUBLESHOOT seçilince detaylar açılıyor.

Datastore Default Policy'yi Güncellemek

Cluster yapısı değiştiği için (standart cluster'dan, her sitede üç host olan bir stretched cluster'a geçiş), Skyline Health iki değişiklik öneriyor:

Standart cluster'dan stretched cluster'a (site mirroring ile) geçiş.
Her site içinde RAID-5'ten RAID-1'e geçiş.

"UPDATE Cluster DS Policy" butonuna basılıyor.

Açılan onay penceresinde OK tıklanıyor. Default policy değiştirildiği için, orijinal policy'i kullanan VM'lerin yeni policy'e geçmesi için ayrıca reapply işlemi gerekiyor. Bu ortamdaki VM'ler varsayılan ESA RAID-5 policy'sini kullandığından, policy'yi manuel olarak yeni Optimal Storage Policy'ye değiştirmek gerekiyor.

Mevcut VM'lere Yeni Policy'i Uygulamak

Policies and Profiles menüsüne gidilip yeni oluşan cluster-esa-01a - Optimal Datastore Default Policy - stretched RAID1 policy'si seçiliyor, REAPPLY'a tıklanıyor. Bir uyarı, bu işlemin zaman alabileceğini ve birkaç VM'i etkileyeceğini bildiriyor; OK ile onaylanıyor.

Skyline Health'e dönülüp tekrar RETEST yapıldığında, policy uyarısının kaybolduğu görülüyor. Manuel'de bir not daha var: bazen bu uyarı bir kez daha görünebiliyor, RETEST ile geçiyor.

Stretched cluster'a özel diğer health check'leri görmek için filtre üzerinden "Stretched cluster" kategorisi seçilebiliyor.

vSAN health check, vSAN kurulumlarının performans ve sağlık testlerine derinlemesine inmek için değerli bir araç; vSAN ortamını izlemek için gidilecek ilk yer olmalı. Güncel durumu görmek için health check'i düzenli olarak yeniden çalıştırmak iyi bir pratik.

vSAN Site Affinity: Her VM'in Çok Site Koruması İstemediği Durumlar

Modülün ikinci yarısı farklı bir soruna eğiliyor. Bir veri merkezinde, uygulama seviyesinde zaten dahili yüksek erişilebilirlik veya yedeklilik sağlayan pek çok workload var. Ama tipik production workload'ları çoğunlukla daha iyi veri yedekliliği için çok-site koruması gerektiriyor. Peki, kopyaların farklı sitelerde tutulmasını gerektirmeyen workload'lar için ne yapılabilir?

Bu soruya cevap: Local Affinity.

Local Affinity Mantığı

Local Affinity, bir policy aracılığıyla veriyi tek bir site'da tutmayı sağlıyor. Bunun teknik karşılığı Primary Failures To Tolerate (PFTT) değerinin 0 olarak ayarlanması. PFTT=0 olduğunda nesneler ikincil siteye replike edilmiyor, bu da siteler arası gereken bant genişliğini azaltıyor. Ayrıca affinity kuralları kullanılarak VM/VMDK atamaları belirli host'lara da sabitlenebiliyor.

Manuel, test senaryosu olarak şu kombinasyonu öneriyor: PFTT=0, Secondary Failures To Tolerate (SFTT)=2, Failure Tolerance Method (FTM)=RAID-5. Bu kombinasyonla tüm I/O'nun yerel olarak yapılması, hiçbirinin ikincil siteye gitmemesi bekleniyor. Yani site koruması olmadan, host/disk seviyesinde koruma sorunsuzca elde edilmiş oluyor.

Birkaç kısıtlama da var:

Affinity, sadece Stretched Cluster etkinleştirilmiş cluster'larda kullanılabiliyor.
DRS/HA kuralları, data locality ile uyumlu olmalı.
OSA'da Hybrid konfigürasyonlarda RAID-0 ve RAID-1 destekleniyor, All-Flash'te RAID-0, RAID-1, RAID-5 ve RAID-6 destekleniyor.

Bu son madde aklımda kaldı: Local Affinity kullanılırken DRS/HA kurallarının manuel olarak hizalanması gerekiyor. Bu, "policy ayarladım, iş bitti" diyemeyeceğiniz, cluster'ın diğer otomasyon katmanlarıyla da koordinasyon gerektiren bir özellik.

Single Site Storage Policy Oluşturmak

Policies and Profiles > VM Storage Policies > CREATE

İsim: Single Site Storage Policy. "Enable rules for vSAN storage" seçiliyor.

Availability sekmesinde:

Site disaster tolerance: None - keep data on Preferred (stretched cluster)
Failures to tolerate: 1 failure - RAID-1 (Mirroring)

Datastore uyumluluğu doğrulanıyor (vsan-esa-01a_Datastore Compatible görünmeli), FINISH ile policy tamamlanıyor.

Local Affinity Policy ile VM Oluşturmak

core-a VM'i klonlanarak Local Affinity VM adıyla yeni bir VM oluşturuluyor. Clone wizard'ında:

Datacenter: dc-a
Cluster: cluster-esa-01a
Storage Policy: Single Site Storage Policy
Datastore: vsan-esa-01a_Datastore (compatible olarak görünüyor)

Klon tamamlandığında VM Summary'den policy'nin atandığı ve "Compliant" olduğu doğrulanıyor.

Yerleşimi Doğrulamak: Preferred Fault Domain

cluster-esa-01a > Configure > vSAN > Fault Domains ekranından preferred fault domain'in hangi host'ları içerdiği görülüyor. HOL'daki örnekte esx-05a, esx-06a ve esx-07a preferred domain'de.

Local Affinity VM > Monitor > vSAN > Physical disk placement ekranından, bileşenlerin gerçekten preferred fault domain üzerinde konumlandığı doğrulanıyor.

Bu doğrulama adımı önemli, çünkü policy'nin "doğru göründüğünü" varsaymak yerine bileşenlerin gerçekte nerede oturduğunu kontrol etmek, "compliant" etiketinin arkasındaki gerçekliği teyit ediyor.

Policy'i Değiştirip Site Geçişini Görmek

Modülün son kısmında, Single Site Storage Policy düzenlenerek Site disaster tolerance ayarı "None - keep data on Secondary" olarak değiştiriliyor. Bu, verinin artık preferred yerine secondary site'da tutulmasını söylüyor.

Policy zaten bir VM tarafından kullanıldığı için, "Reapply to VMs" seçeneği "Now" olarak ayarlanıp YES ile onaylanıyor.

Son doğrulama adımında Local Affinity VM > Monitor > vSAN > Physical disk placement tekrar kontrol ediliyor; bu sefer bileşenlerin Secondary Fault Domain'e taşındığı görülüyor.

Bu son adım, Local Affinity'nin sadece statik bir yerleşim olmadığını, policy değiştiğinde verinin gerçekten fiziksel olarak başka bir site'a taşındığını gösteriyor. vMotion gibi VM'in compute'unun taşınması değil, doğrudan storage nesnelerinin yeniden yerleştirilmesi (re-placement) söz konusu.

Genel Değerlendirme

Bu modül, önceki üçünden farklı bir karaktere sahip. SPBM, izleme ve şifreleme tek bir site içinde çalışan kavramlardı. Stretched cluster ise coğrafi/fiziksel bir boyut ekliyor; ağ topolojisi, gecikme süreleri ve "hangi taraf hayatta kalmalı" gibi sorular devreye giriyor.

Benim için en çok düşündüren üç nokta şunlardı:

Birincisi, witness host'un cluster'ın dışında tutulması gerekliliği. İlk bakışta tuhaf geliyor; quorum sağlayan bir bileşenin neden cluster üyesi olmadığını sorgulamak doğal. Ama mantığı şu: witness veri taşımıyor, sadece karar verici. Cluster üyesi olsaydı, kendisi de bir failure noktası haline gelebilirdi.

İkincisi, read locality'nin varsayılan davranış olması ve kapatılmasının neredeyse istisnai bir durum olarak tanımlanması. Bu, "ne zaman varsayılanı değiştirmemeliyim" sorusuna iyi bir örnek; bazen en iyi karar, ayarı olduğu gibi bırakmak.

Üçüncüsü, Local Affinity'nin son demosu; policy değiştiğinde verinin fiziksel olarak taşındığını göstermesi. Bu, SPBM'in sadece "uyumlu/uyumsuz" etiketlemekle kalmadığını, gerçek veri hareketini tetiklediğini somut olarak gösteriyor. Modül 1'de gördüğümüz Placement Details ekranının burada da işe yaraması, serinin kendi içinde nasıl bağlandığını da hissettirdi.

HOL'un nested ortam kısıtlamaları burada daha belirgin hissettiriyor kendini; gerçek bir stretched cluster kurulumunda WAN gecikmesi, bant genişliği sınırlamaları ve gerçek bir site kaybı senaryosu test etmek, bu modülün kapsamının çok ötesinde bir konu. Ama temel kavramları, doğru terminolojiyle ve doğru sırayla görmüş olmak, gerçek bir tasarım dokümanını okurken işe yarayacak bir zemin oluşturuyor.

Bir sonraki hafta Modül 5'e geçiyorum.

vSAN Şifreleme ve Güvenlik: HOL Notları (Modül 3)

Hakan İSMAİL — Sun, 28 Jun 2026 08:59:25 +0000

İki haftadır SPBM ve izleme konularını işledim. Bu hafta Modül 3'e geçiyorum: vSAN şifreleme ve güvenlik. Modül kısa ama içerik yoğun. Şifreleme konuları genelde "evet, şifreleyelim" deyip geçilen yerler değil; anahtar yönetimi, reboot davranışı ve performans etkisi gibi detaylar production'da gerçekten fark ediyor.

Bu yazıda iki ana konu var: data-in-transit (aktarım sırasında) şifreleme ve data-at-rest (durağan veri) şifreleme. İkisi birbirinden bağımsız, ayrı ayrı açılıp kapatılabiliyor.

İki Şifreleme Türü, İki Farklı Amaç

vSAN iki tür şifreleme sunuyor:

Data-in-transit encryption: Host'lar arasında akan tüm vSAN verisi ve metadata trafiğini şifreliyor.

Data-at-rest encryption: Veriyi, deduplikasyon gibi diğer işlemler tamamlandıktan sonra şifreliyor. Bir disk cluster'dan fiziksel olarak çıkarılsa bile üzerindeki veri korunmuş oluyor.

Bu ayrımı net tutmak önemli: birini açmak diğerini otomatik açmıyor. Tehdit modeline göre ikisi farklı senaryoları kapatıyor. Data-in-transit, ağ üzerinde dinleme (sniffing) riskine karşı; data-at-rest, fiziksel disk hırsızlığına veya yanlış imha edilen donanıma karşı.

Data-In-Transit Encryption: Detaylar

Bu özelliğin birkaç teknik özelliği var, not almaya değer:

AES-256 bit şifreleme kullanılıyor.
Data-at-rest şifrelemesiyle ilişkisi yok; ikisi bağımsız açılıp kapatılabiliyor.
Forward secrecy uygulanıyor (yani bir anahtar ele geçirilse bile geçmiş trafiği deşifre etmek için kullanılamıyor).
Data host'ları ile witness host'ları arasındaki trafik de şifreleniyor.
File service trafiği (VDFS proxy ile VDFS server arası) de kapsam içinde.

En dikkat çeken kısım şu: şifreleme için bir Key Management Server'a ihtiyaç yok. Host'lar bir bağlantı kurduklarında dinamik olarak simetrik bir anahtar üretiyor ve bu anahtarla aralarındaki trafiği şifreliyorlar. Bir host cluster'a katıldığında doğrulanıyor, cluster'dan çıkarıldığında ise sertifikası kaldırılıyor.

Bu, data-at-rest şifrelemesine kıyasla operasyonel olarak çok daha hafif bir özellik. Tek bir toggle, anahtar yönetimi derdi yok. Bu yüzden "neden açmayalım ki" sorusuna cevap vermek daha kolay.

Etkinleştirme Adımları

vSphere Client üzerinden:

cluster-esa-01a seçiliyor
Configure
vSAN > Services
Data Services bölümü genişletilip EDIT'e tıklanıyor

Açılan ekranda Data-In-Transit Encryption toggle'ı açılıyor ve APPLY'a basılıyor. Bir de "rekey interval" var; varsayılan 1 gün, ihtiyaca göre özelleştirilebiliyor. Bu rekey periyodu, anahtarların ne sıklıkla yenileneceğini belirliyor.

Data-At-Rest Encryption: Anahtar Hiyerarşisi

Burası modülün biraz daha karmaşık kısmı, ama mantığını anladığınızda aslında oldukça temiz bir tasarım.

Üç seviyeli bir anahtar hiyerarşisi var:

KEK (Key Encryption Key): vCenter, KMS'ten AES-256 bir KEK talep ediyor. Ama vCenter bu anahtarın kendisini saklamıyor, sadece ID'sini tutuyor.

DEK (Data Encryption Key): ESX host, diski AES-256 XTS modunda şifrelerken DEK kullanıyor. OSA'da her disk için ayrı, rastgele üretilmiş bir DEK var. ESA'da ise cluster'daki tüm diskler aynı DEK'i kullanıyor.

Host Key: Core dump'ları şifrelemek için kullanılıyor, veri için değil. Aynı cluster'daki tüm host'lar aynı host key'i paylaşıyor. Support bundle toplarken core dump'lar rastgele bir anahtarla yeniden şifreleniyor; bu anahtara bir şifre de atayabiliyorsunuz.

Burada OSA-ESA farkı dikkatimi çekti. OSA'da disk başına ayrı DEK varken ESA'da tüm cluster için tek bir DEK kullanılması, anahtar yönetimini basitleştiriyor ama "tek anahtar = tek başarısızlık noktası" sorusunu da aklımıza getiriyor. Tabii bu DEK zaten KEK ile şifrelenmiş halde diskte duruyor, host KEK'i almadan DEK'i kullanamıyor; yani anahtarın kendisi tek başına bir şey ifade etmiyor.

Reboot Davranışı: Dikkat Edilmesi Gereken Bir Nokta

Şunu production açısından önemli buluyorum: Host reboot olduğunda, disk grup'ları KEK'i alana kadar mount edilmiyor. Bu işlem birkaç dakika veya daha uzun sürebiliyor. Yani bir host restart sonrası "neden disk grupları hemen görünmüyor" diye panik yapmadan önce, bu sürecin normal olduğunu bilmek gerekiyor. Durumu vSAN health service > Physical disks > Software state health üzerinden takip edebiliyorsunuz.

Bu, KMS'in erişilebilirliğinin de ne kadar kritik olduğunu gösteriyor. KMS'e erişilemiyorsa host KEK'i alamaz, disk grupları mount olmaz. KMS'in yüksek erişilebilirlikli olması bu yüzden boş bir öneri değil.

DISA STIG ve FIPS 140-2

vSAN, vSAN 6.7'den itibaren FIPS 140-2 doğrulamalı ilk yazılım tabanlı çözüm olma iddiasında. vSAN doğrudan hypervisor'a entegre olduğu için vSphere'in kullandığı kernel modülünü kullanıyor ve bu modül FIPS 140-2 doğrulamasına sahip.

Bu, ABD federal hükümeti gibi belirli regülasyon gereksinimleri olan kurumlar için önemli bir kutu işaretleme maddesi. Aynı zamanda DISA onaylı bir STIG'e (Security Technical Implementation Guide) sahip olan ilk HCI çözümü olarak konumlandırılıyor.

Türkiye'deki bir okuyucu için bu spesifik sertifikasyonlar doğrudan bir gereksinim olmayabilir, ama "bu seviyede bir doğrulamadan geçmiş" bilgisi, ürünün güvenlik mimarisinin ne kadar olgun olduğu konusunda bir gösterge.

Key Management Server: Native Key Provider Kurulumu

vSAN encryption, harici bir Key Management Server, vCenter Server ve ESXi host'ları arasında çalışıyor. vCenter, KMS'ten anahtar talep ediyor; KMS anahtarları üretip saklıyor, vCenter ise sadece anahtar ID'lerinin listesini tutuyor.

HOL'da harici bir KMS kurmak yerine vSAN'ın "Native Key Provider" özelliğini kullanıyoruz. Bu, vCenter'a gömülü bir key provider; ayrı bir KMS sunucusu kurmaya gerek kalmıyor.

Kurulum Adımları

vc-mgmt-a.site-a.vcf.lab vCenter'ı seçiliyor
Configure
Security > Key Providers
ADD
Add Native Key Provider

Sonra şu bilgiler giriliyor:

İsim: vSAN-Native-KP
"Use key provider only with TPM..." kutusu işaretsiz bırakılıyor (nested bir lab ortamı olduğu için TPM mevcut değil)
ADD KEY PROVIDER

Key Provider eklendiğinde Type "Native", Status ise "Not backed up" olarak görünüyor.

Yedekleme: Atlanmaması Gereken Adım

Burada gerçekten önemli bir nokta var. Key Provider eklendikten sonra BACK-UP butonuna basıp "BACK UP KEY PROVIDER" seçeneği seçiliyor.

Yedekleme tamamlandığında status "Active" oluyor.

Bu adımın HOL'da bir formalite gibi görünmesi mümkün ama gerçek ortamda kritik: Native Key Provider'ın yedeği yoksa ve vCenter kaybedilirse, şifrelenmiş veriye erişim de kaybedilebilir. "Not backed up" durumundaki bir key provider, encryption'ı aktif etmeden önce mutlaka yedeklenmesi gereken bir uyarı sinyali.

vSAN Encryption'ı Etkinleştirmek

vSAN Encryption, vSAN 6.6'dan beri mevcut ve ilk native HCI şifreleme çözümü olarak tanıtılıyor. Birkaç tıkla tüm vSAN datastore için açılıp kapatılabiliyor; ekstra bir adım gerekmiyor.

Hypervisor seviyesinde çalıştığı için VM'den bağımsız (VM Encryption gibi VM'e özgü değil). Donanımdan bağımsız olduğu için de Self-Encrypting Drive (SED) gibi özel ve daha maliyetli donanımlara ihtiyaç yok.

HOL'da data-at-rest encryption zaten önceden etkinleştirilmiş durumda. Bu bölümde yapılan, "shallow rekey" denilen bir işlem; bu, encryption'ı ilk kez açmakla aynı adımları takip ediyor.

Adımlar

cluster-esa-01a seçiliyor
Configure
vSAN > Services
Data Services altında EDIT

Açılan ekranda:

Data-at-rest Encryption zaten açık görünüyor
Key Provider, nk1'den vSAN-Native-KP'ye değiştiriliyor (her seçenek için bilgi (i) butonuna tıklanarak detay görülebiliyor)
APPLY

İşlem tamamlandığında Data Services genişletilip Key Provider'ın vSAN-Native-KP olarak ayarlandığı doğrulanıyor. Bu noktadan sonra vSAN datastore'a eklenen tüm veri şifreleniyor. Bir anahtar süresi dolarsa veya ele geçirilirse yeni anahtar üretme seçeneği de burada.

Burada dikkatimi çeken şey, bu işlemin "shallow rekey" olarak tanımlanması. Yani mevcut şifrelenmiş veri tamamen yeniden şifrelenmiyor (bu "deep rekey" olurdu, çok daha pahalı bir operasyon); sadece anahtar değişiyor. Production'da deep rekey'in I/O üzerindeki etkisini ayrıca araştırmak gerekir, ama bu HOL bunun ayrımını yapmamıza yardımcı oluyor.

vSAN Encryption Health Check

vSAN, encryption'ın etkin ve sağlıklı olduğunu doğrulamak için health check'lere sahip. Bunlara erişim:

cluster-esa-01a seçili, Monitor
vSAN > Skyline Health
Health findings altında ALL seçiliyor
Category sütunundaki filtre ikonuna tıklanıyor
"Data-at-rest encryption" işaretleniyor

Bu kategoride iki health check var.

Kontrol 1: KMS Bağlantısı

"vCenter and all hosts are connected to Key Management Servers" bulgusunun yanındaki üç noktalı menüden "View Current Result" seçiliyor.

Bu kontrol, ESX Key Provider durumunu, bağlantı durumunu ve anahtar durumunu (key state) listeliyor.

Kontrol 2: AES-NI

Aynı kategori altında "CPU AES-NI is enabled on hosts" bulgusunun üç noktalı menüsünden "View Current Result" seçiliyor.

Bu kontrol, cluster'daki ESX host'ların CPU AES-NI özelliğine sahip olup olmadığını doğruluyor. AES-NI, Intel ve AMD işlemcilerde AES şifreleme/deşifreleme işlemlerini hızlandırmak için tasarlanmış bir donanım uzantısı.

Bu kontrolün burada olması mantıklı: AES-NI olmadan şifreleme yazılımsal olarak yapılır ve bu CPU üzerinde belirgin bir yük oluşturur. Modern sunucu işlemcilerinin büyük çoğunluğunda AES-NI zaten var, ama eski donanımla çalışan ortamlarda bu kontrolün kırmızı çıkması, "şifrelemeyi açtık ama performans neden düştü" sorusunun cevabı olabilir.

Genel Değerlendirme

Bu modül, önceki ikisine göre daha "arka plan" bir konuyu işliyor; şifreleme açıldıktan sonra günlük operasyonda görünür bir şey değişmiyor, ama yanlış yapılandırıldığında ya da KMS erişilemez olduğunda etkisi çok görünür hale geliyor.

Benim için en dikkat çekici üç nokta şunlardı:

Birincisi, data-in-transit encryption'ın KMS gerektirmemesi ve tamamen dinamik anahtarlarla çalışması. Bu, "açmamak için bahane bulmak zor" bir özellik; operasyonel yük neredeyse sıfır.

İkincisi, host reboot sırasında disk gruplarının KEK'i bekleyerek mount olması. Bu, KMS'in yüksek erişilebilirlik gereksinimini soyut bir "best practice" maddesinden çıkarıp somut bir bağımlılığa dönüştürüyor. KMS düşerse, sadece yeni anahtar talepleri değil, reboot sonrası disk mount süreçleri de etkileniyor.

Üçüncüsü, Native Key Provider'ın "Not backed up" uyarısı. HOL'da bu adım hızlıca geçiliyor ama gerçek bir ortamda bu, encryption'ı açmadan önce check-list'in en üstünde olması gereken bir madde gibi duruyor.

vSAN'ın şifreleme tarafı, "aç ve unut" gibi pazarlanıyor ve büyük ölçüde de öyle. Ama anahtar yönetimi her zaman böyle; basit görünen arayüzün ardında, bir şeyler ters gittiğinde önemli hale gelen bir bağımlılık zinciri var.

Bir sonraki hafta Modül 4'e geçiyorum.

vSAN İzleme: Sağlık, Kapasite ve Performans: HOL Notları (Modül 2)

Hakan İSMAİL — Sun, 21 Jun 2026 07:20:16 +0000

Geçen hafta SPBM'i, policy yönetimini ve cluster'ı büyütüp küçültmeyi incelemiştim. Bu hafta Modül 2 ile devam ediyorum. Konu: vSAN ortamının sağlığını izlemek, kapasiteyi takip etmek ve performans verilerini okumak.

Bu modül biraz farklı bir yerden başlıyor. Bir şey kurup yapılandırmak yerine, kurulu ortamı "gözetlemeyi" öğreniyoruz. Kulağa pasif geliyor ama değil; hangi ekrana ne zaman bakacağını bilmek, bir sorun çıktığında saatleri kurtarabilir.

vSAN Health Check: Neden Önemli?

vSAN 6.0'dan bu yana sistemde yerleşik bir sağlık kontrol mekanizması var. Yüzden fazla hazır kontrol içeriyor. Ağ bağlantısı, donanım uyumluluğu, disk durumu, VM nesneleri, konfigürasyon tutarsızlıkları gibi başlıkları kapsıyor.

Yeni bir cluster kurduktan sonra yapılacak ilk şeylerden biri bu kontrolü çalıştırmak. Bir ağ sorununu erkenden yakalamak ile haftalar sonra performans şikayetleri gelince fark etmek arasındaki farkı bu araç belirleyebilir.

Skyline Health Üzerinden Kontrol

vSphere Client'ta şu yola gidiyoruz:

cluster-esa-01a > Monitor > vSAN > Skyline Health

Açılan ekranda üç şey görüyorsunuz:

Cluster Health Score (sayısal bir puan)
Health Score Trend (zaman serisi)
Health Findings (aktif sorunlar)

Trend görünümünde "VIEW DETAILS" diyince geçmişe de bakabiliyorsunuz; sorunun ne zaman başladığını görmek için işe yarıyor.

Kontrolleri kategoriye göre filtrelemek de mümkün. "Category" filtresinden "Network" seçince sadece ağ katmanıyla ilgili testler listeleniyor. Her testin yanındaki >> ikonuna tıklayınca sağ panelde o kontrolün ne anlama geldiği ve nasıl düzeltileceği açıklıyor. KB makalesi bağlantısı da genellikle orada.

Kasıtlı Arıza: Sistemi Test Etmek

HOL'un bu kısımda yaptığı ilginç: bir host'u kasıtlı olarak disconnect edip health check'in bunu nasıl yakaladığını gösteriyor.

esx-05a.site-a.vcf.lab üzerine sağ tık, Connection > Disconnect diyoruz. Ardından Skyline Health'e dönüp RETEST'e basıyoruz.

Birkaç saniye içinde "UNHEALTHY" bölümünde esx-05a'nın vCenter'dan koptuğuna dair uyarı çıkıyor. TROUBLESHOOT'a basınca hangi host'un sorunlu olduğu, durumu ve KB bağlantısı görünüyor.

Sonra aynı host'u yeniden connect edip RETEST yapıyoruz. Uyarı kayboluyor, health score normale dönüyor.

Bu adımın değeri şu: Sistemin gerçekten alarm üretip üretmediğini, doğru kaynağı gösterip göstermediğini ve çözüm önerisi sunup sunmadığını ellerin kirletmeden görmek.

Kapasite İzleme

Kapasite takibi için birkaç farklı giriş noktası var. En doğrudan olanı datastore görünümü.

Datastores Icon > dc-a > vsan-esa-01a_Datastore > Summary > VIEW CAPACITY

Açılan ekranda iki önemli bölüm var:

Capacity Overview: Toplam kapasite, kullanılan alan ve boş alan. Standart bir disk kullanım göstergesi.

What-if Analysis: Burası daha ilginç. Seçtiğiniz bir storage policy bazında "etkin boş alan" hesaplıyor. Thin provisioning açısından datastore'un oversubscribed olup olmadığını da gösteriyor. Yani gerçek fiziksel alan ile politika gereği ayrılması gereken alan arasındaki farkı görünür kılıyor.

Kullanım Detayı (Usage Breakdown)

"EXPAND ALL" diyince vSAN datastore üzerindeki nesne tiplerinin dökümü geliyor:

VMDK'lar (sanal diskler)
VM Home namespace'leri
Swap nesneleri
Performans servisi veritabanı
Dosya sistemi ve checksum overhead
Diğerleri (template, ISO gibi kategorize edilmemiş nesneler)

Yüzdeler anlık kullanıma göre değişiyor. Ortam henüz az doluysa overhead kalemleri orantısız büyük görünebiliyor; bu normal.

Performans İzleme

vSAN'ın yerleşik performans servisi vSAN 9 ile cluster seviyesinde otomatik olarak aktif geliyor. Bu servis her host üzerinde çalışıyor, veri topluyor ve sonuçları vSAN datastore üzerinde ayrı bir nesne olarak saklıyor.

Birkaç detay kayda değer:

Metrikler 90 gün saklanıyor.
5 dakikalık aralıklarla kaydediliyor.
Performans veritabanı vCenter'dan bağımsız bir vSAN nesnesi. vCenter erişilemez olsa bile veriler orada duruyor, ama görüntüleyemezsiniz.
Veritabanına da bir storage policy atanmış; bu nedenle "Configure > vSAN > Services > Performance Service" altında Stats DB'nin Compliant olduğunu görebilirsiniz.

Üç Seviyede Performans Görünümü

Performans verilerini üç farklı seviyede inceleyebiliyorsunuz:

Cluster Seviyesi

cluster-esa-01a > Monitor > vSAN > Performance

Burada VM, Backend, File Share ve IOInsight sekmelerini göreceksiniz. Önemli bir ayrım var:

"Front-end" trafik: VM'lerin doğrudan oluşturduğu okuma/yazma trafiği.
"Back-end" trafik: Replika ve senkronizasyon trafiği; vSAN VMkernel arayüzü üzerinden akıyor. Bu iki trafiği ayrı izlemek, bir yavaşlamanın VM'den mi yoksa vSAN'ın arka plan operasyonlarından mı kaynaklandığını anlamak için gerekli.

Host Seviyesi

esx-05a.site-a.vcf.lab > Monitor > vSAN > Performance

Cluster görünümüne kıyasla daha fazla sekme var: VM, Backend, Disks, Physical Adapters, Host Network ve I/O Insight. Bir performans sorununun hangi katmandan geldiğini daraltmak için bu seviye daha kullanışlı.

VM Seviyesi

acct-app-01 > Monitor > vSAN > Performance

Sanal disk bazında IOPS, throughput ve latency. Belirli bir VM'den şikayet geldiğinde buradan başlamak doğru.

VCF Operations ile Çok Cluster İzleme

Şimdiye kadar gördüklerimiz vCenter içindeydi ve tek cluster'a bakıyordu. Birden fazla cluster'ı, birden fazla workload domain'i izlemek gerektiğinde VCF Operations devreye giriyor.

HOL'da yeni bir sekmede VCF Operations'a giriş yapıyoruz:

Infrastructure Operations > Storage Operations

Storage Operations: Ne Görünüyor?

Ekran üç katmanda bilgi sunuyor:

Üst kısım:

Storage Alert Trends: Tüm storage instance'larında kaç uyarı var.
Usage and Distribution: vSAN ve vSAN dışı storage'ları kapsayan toplam/boş kapasite.

Orta kısım:

vSAN Cluster Health Score: Tüm cluster'ların Skyline health skoru bir arada.
vSAN Cluster Types: HOL ortamında ne var ne yok görünüyor: 1 ESA cluster, 2 OSA cluster, 1 Storage Cluster, 1 Compute Cluster. Bu dağılım modül bazlı hangi konuların ayrı cluster türleri gerektirdiğini göstermesi açısından da ilginç.
vSAN Cluster Performance: Tüm cluster'ların IOPS, throughput ve latency değerleri; tek ekranda.

Alt kısım: Cluster bazında daha granüler metrikler.

Hazır Dashboard'lar

Dashboards & Reports menüsüne geçip arama kutusuna "vsan" yazınca hazır dashboard listesi çıkıyor. "vSAN ESA Performance" dashboard'unu açıp bir cluster seçince IOPS, latency ve throughput verilerini görselleştirilmiş halde görüyorsunuz.

Bu dashboard'ların önemli bir özelliği var: VCF Operations içinde tek bir cam yüzeyi sunuyorlar. vCenter'da cluster cluster dolaşmak yerine buradan konsolidasyon yapılabiliyor.

Genel Değerlendirme

Bu modül bir öncekinden farklı bir kas grubu çalıştırıyor. Kurulum ve yapılandırma değil, okudum anlama.

Bir şey dikkat çekti: vSAN'ın izleme araçları birbiriyle iç içe geçmiş ama her biri farklı bir soruya cevap veriyor. Skyline Health "sorun var mı" sorusu için. Kapasite ekranı "ne kadar yerim kaldı ve bu yeter mi" için. Performans servisi "sistem iyi çalışıyor mu, darboğaz nerede" için. VCF Operations ise bu üçünü birden tek pencerede görmek ve birden fazla cluster'ı karşılaştırmak için.

Gerçek ortamda bu ayrımı bilmeden izleme yapmak, doğru araçla yanlış soruyu sormak anlamına gelebilir. Mesela kapasite doluyken performans grafiklerine bakmak, asıl problemi kaçırmanıza neden olabilir.

Bir diğer gözlem: Performans veritabanının vCenter'dan bağımsız bir vSAN nesnesi olarak depolanması teorik olarak temiz bir tasarım. Ama bu nesne erişilemez hale gelirse performans geçmişine de ulaşamazsınız. Production'da bu nesnenin politikasını ve sağlığını ayrıca takip etmek gerekiyor; HOL'da bunu görüp not aldım.

Bir sonraki hafta Modül 3'e geçiyorum: vSAN şifreleme ve güvenlik.

VMware vSAN ile Başlarken: Depolama Politikası, Kullanılabilirlik ve HOL Notları (Modül 1)

Hakan İSMAİL — Sat, 13 Jun 2026 17:36:05 +0000

Birkaç haftadır "VMware vSAN - Getting Started and Advanced Topics" başlıklı HOL (Hands-on Lab) üzerinde çalışıyorum. Bu yazı, o serinin ilk modülünden çıkardığım notların ve gözlemlerin bir dökümü. Baştan söyleyeyim: burada anlatılanlar gerçek bir üretim ortamından değil, tamamen HOL ortamından geliyor. Kendi adıma bu ayrımı net tutmak önemliydi çünkü sahadaki dinamikler ile simüle bir ortam arasında her zaman fark var. Ama bu fark, HOL'u değersiz kılmıyor; tam tersine, kavramları karşılıklı test edip yanılma maliyeti sıfır olarak görmek için iyi bir zemin.

Şimdi Modül 1'de neyle karşılaştığımı aktarayım.

Ortam Hakkında Kısa Bir Not

Lab iki siteden oluşuyor: Site A ve Site B. İlk dört modül tamamen Site A üzerinde ilerliyor. Yönetim cluster'larına dokunulmaksızın sadece workload cluster'larında çalışıyoruz. Bu ayrım, özellikle VCF (VMware Cloud Foundation) bağlamında düşününce mantıklı: yönetim katmanına gereksiz yandan temas, gerçek ortamlarda da kaçınılan bir şey.

vSAN Nedir, Neden Var?

vSAN 2014'te hayatımıza girdi. Temel fikir şu: birden fazla ESXi host'unun yerel disklerini bir araya getirip tek, merkezi olarak yönetilen bir depolama havuzu oluşturmak. Ayrı bir storage donanımına gerek kalmıyor, en azından teoride.

Bunun anlamı şu: vSAN doğrudan vSphere hypervisor'ına gömülü. Yani bir storage OS yönetmiyorsunuz, ayrı bir SAN fabric kurmuyor değilsiniz. Compute ve storage, vSphere Client üzerinden tek elden yönetiliyor. TCO açısından geleneksel storage'a kıyasla yüzde elliye varan maliyet düşüşü iddiası var. Bunu elbette ortam büyüklüğüne, lisans yapısına ve mevcut altyapıya göre ayrı değerlendirmek gerek, ama kavramsal olarak mantığı oturuyor.

Data resilience tarafında erasure coding (silme kodlaması) kullanılıyor. RAID-5 ve RAID-6 burada saf disk mirroring'e göre daha verimli kapasite kullanımı sağlıyor.

vSAN 9'da Neler Değişti?

Bu HOL, vSAN 9 üzerine kurulu. vSAN 9'da öne çıkan başlıklara bakmak istedim çünkü önceki sürümlerle karşılaştırma yapmadan nelerin "yeni" olduğunu anlamak zor.

Gerçek hayatta şunu sormak gerekir: mevcut donanımınız ESA'yı destekliyor mu? ESA'nın VMware HCL gereksinimleri daha kısıtlayıcı. Bu, HOL'da görmediğiniz ama sahaya geçince sizi ilk duraksatan şeylerden biri olabilir.

VMware Live Recovery ile DR

vSAN cluster'ları artık VMware Live Recovery entegrasyonuyla korunabiliyor. RPO 1 dakikaya kadar inebiliyormuş. Bu özellik Modül 7'de işleniyor, burada sadece genel bir bilgi olarak geçiyor.

File Services ve Kubernetes

vSAN artık Kubernetes pod'ları için file-based persistent volume destekliyor. Aynı zamanda cluster başına 500 adet file share'e kadar çıkılabiliyor (vSAN 9 ile gelen bir iyileştirme). Bu konu Modül 6'da detaylandırılıyor.

Dying Disk Handling (DDH)

ESA'da disk latency değerlerini izleyip önceden belirlenen eşik aşılırsa otomatik müdahale edebiliyor. Cache drive arızalarını da proaktif olarak yakalıyor. Bu tür şeyler production ortamında görünmez çalışmasını beklediğiniz mekanizmalar; genelde var olduğunu ancak bir sorun çıktığında fark ediyorsunuz.

Global Deduplication (Sınırlı Yayın)

OSA'da deduplikasyon alanı disk grubuyla sınırlıydı. ESA ile bu kapsam tüm cluster'a genişliyor; tekrar eden bloklar cluster genelinde tek depolama ihtiyacına düşüyor. Veri azaltma oranları teorik olarak daha iyi. VCF 9.0 P01 ile TQR programı kapsamında geliyor.

Storage Policy Based Management (SPBM)

Bu modülün asıl konusu SPBM. Burada anlatmak istediğim şeyin "politika" kısmına takılmamak lazım; bu bir kurumsal yazılım sloganı değil, gerçekten işe yarayan bir mekanizma.

Temel mantık şu: VM'e "şu datastore'a yerleştir" demiyorsunuz. Onun yerine bir politika tanımlıyorsunuz, "bu VM en az 1 arıza tolere edebilmeli, RAID-5 ile" gibi. vSAN bu politikaya uyan yerleşimi kendisi buluyor. VM o politikaya uymakta zorlanırsa bunu da raporluyor: "Compliant" ya da "Non-compliant."

Bu yaklaşım, özellikle büyük ortamlarda her VM için ayrı ayrı storage konfigürasyonu yapmak yerine politika bazlı bir standart getiriyor. Dezavantajı şu olabilir: politika sayısı artınca bunları kim/ne zaman güncelleyecek, eski politikalara kim sahip çıkacak sorularına önceden cevap vermek gerekiyor.

Default Policy ve Optimal Datastore Default Policy

vSAN'ın bir "default storage policy"si var. Bu, herhangi bir politika atanmadan oluşturulan VM'lere otomatik atanıyor. Bunu silemiyorsunuz, ama kopyalayıp üzerine kendi politikanızı kurabiliyorsunuz.

vSAN 8.0 U1 ile gelen "Auto-Policy Management" özelliği ise bunu bir adım öteye taşıyor. Cluster'daki host sayısına ve konfigürasyonuna bakarak size özel bir "cluster-esa-01a - Optimal Datastore Default Policy - RAID5" gibi bir politika oluşturuyor. Bu otomatik politika RAID seviyesini cluster büyüklüğüne göre belirliyor. HOL'da bu özellik zaten etkin hale getirilmiş.

İlk Uygulama: VM Deploy Etmek

Bu bölümde mevcut bir VM'i (core-a) vSAN datastore'a klonluyoruz. Adımlar gayet açık:

vSphere Client'tan VM'e sağ tık → Clone → Clone to Virtual Machine
İsim: clone-vm-a
Cluster: cluster-esa-01a
Datastore: vsan-esa-01a_Datastore
Storage Policy: cluster-esa-01a - Optimal Datastore Default Policy - RAID 5

Klon işlemi tamamlanınca VM Summary ekranından politikanın atanmış ve "Compliant" olduğunu doğrulamak mümkün.

VM vSAN Üzerinde Nasıl Depolanıyor?

Bu kısım bence modülün en ilginç parçası. vSAN ESA'nın log-structured file system mimarisine bakınca şunu görüyorsunuz:

Yazma işlemi iki aşamada gerçekleşiyor:

Performance Leg (RAID-1): Gelen yazma önce RAID-1 olarak iki host arasında mirroring ile saklanıyor. Hızlı write acknowledgement için. Veri henüz kalıcı konumuna geçmedi.

Capacity Leg (RAID-5 veya RAID-6): Küçük yazmaların yeterince birikmesiyle vSAN bunları full-stripe write olarak RAID-5/6 formatında kalıcı kapasiteye indiriyor (destage). Bu, IO amplifikasyonunu azaltmak için tasarlanmış.

HOL'da bunu "Monitor > vSAN > Virtual Objects" üzerinden görebiliyorsunuz. VM'in hard diskini seçip "View Placement Details"e tıklayınca bileşenlerin hangi host üzerinde bulunduğunu görüyorsunuz.

Bu dağılımı görmek, "storage siyah bir kutu" algısını kırıyor. Veriyi görünür kılıyor.

Cluster'ı Büyütmek: Scale Out

RAID-5 ve RAID-6 için host sayısı gereksinimleri önemli:

Mimari	RAID-5 Minimum	RAID-6 Minimum
OSA	4 host	6 host
ESA	3 host (2+1 şeması, 1.5x kapasite)	6 host

ESA'da 6 veya daha fazla host varsa RAID-5 şeması 4+1'e geçiyor ve kapasite verimliliği artıyor (1.25x). Bu geçiş host sayısı değiştikten 24 saat sonra otomatik.

Yeni Host Eklemek

HOL'da cluster başlangıçta 4 host ile geliyor. İki ek host (esx-09a ve esx-10a) dışarıda bekliyor. Bu host'ları sürükle-bırak ile cluster'a ekliyorsunuz.

ESA'da artık "disk group" kavramı yok. Onun yerine "disk pool" var; host üzerindeki tüm uyumlu sürücüler havuza dahil oluyor. "vSAN Managed Disk Claim" etkinse eklenen host'un uyumlu sürücüleri otomatik olarak algılanıp vSAN datastore'a dahil ediliyor. HOL'da bu özellik etkin.

Disk Management: eklenen host'un sürücüleri" width="800" height="339">

Skyline Health ve Otomatik Policy Önerisi

İki host eklendikten sonra Skyline Health'i açtığımızda bir uyarı görüyoruz: cluster 6 host'a çıktığı için Auto Policy Management yeni bir politika öneriyor.

"TROUBLESHOOT" dediğinizde mevcut politika (RAID-5) ile önerilen politika (RAID-6) yan yana görünüyor. Mantıklı: 6 host ile RAID-6 hem mümkün hem daha resilient.

"UPDATE CLUSTER DS POLICY" diyebilirsiniz; bu noktadan sonra oluşturulan VM'ler RAID-6 politikası alıyor. Mevcut VM'leri de Policies and Profiles > REAPPLY ile güncelleyebiliyorsunuz. HOL'da bu adım zaman kazanmak için atlanıyor.

İleri Düzey Policy: Compression'ı Kapatmak

ESA'da sıkıştırma (compression) artık storage policy seviyesinde yönetiliyor. Varsayılan olarak açık, çünkü replica trafiği de compressed olarak taşınıyor. Ama bazı durumlarda kapatmak gerekebilir: kendi sıkıştırmasını yapan uygulamalar (veritabanları gibi) için ekstra sıkıştırma hem CPU israfı hem de veri azaltma oranlarını yanıltabilir.

Bu bölümde şunu yapıyoruz:

Mevcut vSAN ESA Default Policy - RAID5 politikasını klonla.
Yeni politikaya isim ver: vSAN ESA No Compression - RAID 5
Storage rules > Storage tier: "No space efficiency" seç (sıkıştırma bu şekilde devre dışı kalıyor)
Uyumluluk kontrolü: vsan-esa-01a_Datastore compatible göründüğünü doğrula
Finish

Ardından mevcut clone-vm-a VM'ine bu yeni politikayı atıyoruz: VM > Configure > Policies > EDIT VM STORAGE POLICIES. Dropdown'dan yeni politikayı seçince bir süre sonra VM "Compliant" statüsüne geçiyor.

Reserved Capacity

vSAN'ın tüm kapasitesi varsayılan olarak workload'lara açık. Ama cluster'da bir rebuild veya rebalancing operasyonu başladığında o an doluysa ne olacak? İşte "Reserved Capacity" tam buna yönelik.

İki tür rezervasyon var:

Operations Reserve: Cluster içi operasyonlar (policy reconfig, vb.) için ayrılan alan.

Host Rebuild Reserve: Bir host arızalandığında veri yeniden inşası için ayrılan alan. Bu rezervasyon, cluster'daki en büyük host'un kapasitesine göre belirleniyor. Minimum 4 host gereksinimi var.

HOL'da bu özelliği etkinleştirme ekranını görüyoruz: uyarı eşikleri %70, hata eşikleri %90 olarak ayarlanmış. Sonra iptal ediliyor çünkü iç içe geçmiş (nested) lab ortamında gerçek anlamda reserve etmek için yeterli kapasite yok.

Bu noktada şunu düşünmeden geçemedim: gerçek ortamlarda bu rezervasyonu kurmak ne zaman anlam taşıyor? Disk kapasitesi kısıtlıysa reserve etmek kısa vadede sizi zorlar. Ama o buffer olmadan bir host çöktüğünde rebuild yetersiz kapasiteye çarpar, bu daha büyük bir risk. Denge kurmak gerekiyor.

Bir kısıtlama notu: Stretched cluster, fault domain kullanılan cluster'lar, ROBO cluster ve 4'ten az host içeren cluster'larda bu özellik desteklenmiyor.

Scale In: Node Çıkarmak

Scale out kadar konuşulmayan ama production'da bir o kadar önemli olan şey: cluster'ı küçültmek. vSAN cluster'ı minimum 3 host ile çalışır. Host çıkarmadan önce şunlara bakmak gerekiyor:

Kalan compute ve storage kapasitesi yeterli mi?
Mevcut VM storage policy'leri compliant kalmaya devam edecek mi?

Data Migration Pre-Check

Bu araç, "şu host'u çıkarsam ne etkilenir?" sorusunun cevabını veriyor. HOL'da esx-10a seçilip "Full data migration" tercih edildiğinde hiçbir nesnenin etkilenmeyeceği görülüyor. Ardından direkt "ENTER MAINTENANCE MODE" adımına geçilebiliyor.

Maintenance Mode ve Host Kaldırma

Maintenance mode'a alınan host sonra drag & drop ile cluster dışına (datacenter seviyesine) taşınıyor. Aynı adımlar esx-09a için de tekrarlanıyor. Cluster böylece 4'e iniyor.

Genel Değerlendirme

HOL formatı bu konu için iyi çalışıyor. Her adım ekran yönlendirmesiyle geldiği için "nerede tıklamalıyım" sancısı yaşamıyorsunuz; odağınız tamamen mantığı anlamaya kayıyor. Ama şunu da söylemeliyim: HOL sizi hiçbir şeyin bozulmadığı, kapasitesinin üstünde çalışmayan bir ortamda karşılıyor. Gerçek sahada bu adımların her birinin yanına "peki bunu değişken bir ortamda nasıl yapacaksın, işler ters giderse ne olur" soruları ekleniyor.

Modülün beni en çok düşündüren kısmı RAID şeması geçişleri ve bunların kapasite verimliliğine yansımaları oldu. ESA'nın adaptif RAID-5'i (3-5 host için 1.5x, 6+ host için 1.25x) storage planlaması açısından gerçekten önemli bir ayrıntı. Host ekledikten 24 saat sonra otomatik geçiş yapması şık, ama o 24 saatte neler olabileceğini de takip etmek gerekir.

Bir sonraki haftada Modül 2'ye; sağlık izleme, kapasite takibi ve performans raporlaması konularına geçeceğim.

Local LLM Ops: Building an Observable, GPU-Accelerated AI Cloud at Home with Docker & Grafana

Hakan İSMAİL — Fri, 13 Feb 2026 19:50:35 +0000

Why I Built My Own Local AI Stack: Prioritizing Privacy & ROI

Integrating AI into a development workflow usually starts with a compromise: you either send your proprietary code to a third-party API (risking Data Privacy and Compliance) or you watch your "pay-per-token" bill spiral out of control (Operational Overhead).

As a Systems Administrator, I prefer a third option: Data Sovereignty. I wanted a private, secure, and fully observable AI environment, eliminating data leak risks (GDPR/KVKK compliance) while achieving significant Long-term ROI by running on my own hardware (Arch Linux + NVIDIA RTX 3050 Ti).

The real challenge wasn't just downloading an LLM; it was engineering a Scalable AI Infrastructure that runs efficiently on consumer hardware. I'm documenting how I orchestrated this microservices-based stack with Docker Compose, optimized Resource Management for limited VRAM, and established Full-Stack Observability with Grafana and Prometheus.

Scalable Microservices Architecture

I went with a modular, containerized approach to ensure internal Scalability and keep the host system clean:

Inference Management: Ollama
Secure Hardware Integration: NVIDIA Container Toolkit
User Experience (UX): OpenWebUI (for a polished RAG-capable interface).
The Observability Layer:
- NVIDIA DCGM Exporter for real-time hardware telemetry.
- Prometheus & Grafana for SLA monitoring and data retention.

Infrastructure & GPU Passthrough

Before deploying the containers, we must ensure the host operating system (Arch Linux in my case) allows Docker to access the GPU hardware. This is not enabled by default.

1.1 The Prerequisites: NVIDIA Container Toolkit

The bridge between Docker containers and the physical GPU is the NVIDIA Container Toolkit. Without this, the containers would only see the CPU, resulting in painfully slow inference speeds (0.5 tokens/sec).

Since I am running Arch Linux, the setup was straightforward:

# Install the toolkit
sudo pacman -S nvidia-container-toolkit

# Configure the Docker daemon to use the NVIDIA runtime
sudo nvidia-ctk runtime configure --runtime=docker

# Restart Docker to apply changes
sudo systemctl restart docker

To verify the passthrough is working, I ran a quick ephemeral container. If nvidia-smi prints the GPU stats inside Docker, we are green.

docker run --rm --gpus all nvidia/cuda:12.4.1-runtime-ubuntu22.04 nvidia-smi

Container Orchestration

I believe in "defining once, running everywhere." Instead of running disparate docker run commands, I defined the entire stack in a single docker-compose.yml file.

This file handles network isolation (creating a private ai-net), volume persistence (so our chat history isn't lost on reboot), and most importantly, GPU resource reservation.

Here is the complete configuration:

services:
  # 🧠 1. AI ENGINE: Ollama
  # This is the backend that runs the LLM inference.
  ollama:
    image: ollama/ollama:latest
    container_name: ollama
    ports:
      - "11434:11434"
    volumes:
      - ollama_storage:/root/.ollama
    # Critical: This section reserves the NVIDIA GPU for this container
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    restart: unless-stopped
    networks:
      - ai-net

  # 💻 2. INTERFACE: OpenWebUI
  # A user-friendly frontend that connects to Ollama.
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    volumes:
      - openwebui_storage:/app/backend/data
    depends_on:
      - ollama
    restart: unless-stopped
    networks:
      - ai-net

  # 🕵️ 3. METRICS EXPORTER: NVIDIA DCGM
  # This container scrapes GPU metrics (Temp, Power, Utilization).
  dcgm-exporter:
    image: nvidia/dcgm-exporter:latest
    container_name: dcgm-exporter
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: 1
              capabilities: [gpu]
    environment:
      - DCGM_EXPORTER_NO_HOSTNAME=1
    ports:
      - "9400:9400"
    restart: unless-stopped
    networks:
      - ai-net

  # 🗄️ 4. TIME-SERIES DB: Prometheus
  # Collects the metrics exposed by dcgm-exporter.
  prometheus:
    image: prom/prometheus:latest
    container_name: prometheus
    ports:
      - "9090:9090"
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
    restart: unless-stopped
    networks:
      - ai-net

  # 📊 5. VISUALIZATION: Grafana
  # Displays the metrics in a dashboard.
  grafana:
    image: grafana/grafana:latest
    container_name: grafana
    ports:
      - "3001:3000"
    volumes:
      - grafana_storage:/var/lib/grafana
    restart: unless-stopped
    networks:
      - ai-net

volumes:
  ollama_storage:
  openwebui_storage:
  prometheus_data:
  grafana_storage:

networks:
  ai-net:
    driver: bridge

Prometheus Scraper Configuration

Prometheus needs to know exactly where to pull metrics from. I configured a 5-second scrape_interval. While 15s-30s is more common for production, a 5s interval is better for a local lab where we want to track immediate power spikes during token generation.

global:
  scrape_interval: 5s # Scrape often for real-time visibility

scrape_configs:
  - job_name: "gpu-metrics"
    static_configs:
      - targets: ["dcgm-exporter:9400"]

With the configuration files in place, a single command boots the entire cloud infrastructure:

docker compose up -d

Resource Management: Optimizing for 4GB VRAM

The infrastructure setup is the foundation, but Cost-Sensitive Resource Allocation, selecting a model that runs effectively on limited hardware, is where the real value lies. I optimized this build for an NVIDIA RTX 3050 Ti with 4GB of VRAM.

The VRAM Constraint

Popular models like DeepSeek R1 or Llama 3 (8B) usually require 5GB to 6GB of VRAM just to load. Offloading these models to system RAM via PCIe on a 4GB card results in unusable generation speeds, often dropping to 1-2 tokens per second.

I needed a model that fits entirely within the 4GB ceiling while remaining capable for coding tasks.

Choosing the right model: Qwen 2.5 Coder (3B)

I used Hugging Face to cross-reference benchmarks and VRAM requirements for various 1B, 3B, and 7B models. After evaluating the trade-offs between parameter count and inference speed, I settled on Qwen 2.5 Coder (3B Instruct).

Since it only occupies roughly 2.2 GB of VRAM, it leaves enough headroom for the context window without triggering a bottleneck. It's significantly faster than larger models that would force the system to swap to system RAM.

I specifically used the Instruct version; it's much better at actual code logic than the base model.

You can pull it with:

docker exec -it ollama ollama run qwen2.5-coder:3b

Verifying Telemetry

Once the containers are up, query the DCGM exporter directly to ensure the GPU is communicating correctly with Docker:

curl http://localhost:9400/metrics

You'll see keys like DCGM_FI_DEV_GPU_TEMP and DCGM_FI_DEV_POWER_USAGE. Now we need to visualize these in Grafana.

Dashboard Configuration

Since Grafana and Prometheus are on the same Docker network (ai-net), they communicate via container names.

Log in to Grafana (http://localhost:3001, default admin/admin).
Add Prometheus as a data source and use the URL: http://prometheus:9090.

Import Dashboard ID 12239 (NVIDIA DCGM Exporter).

The result is a comprehensive command center for your local AI hardware.

Real-World Business Value & Metrics

I tested the stack with a typical DevOps automation request:

"Write a bash script that detects zombie processes and logs the action."

Full-Stack Observability Analysis

Checking the Grafana dashboard during inference gives the ultimate validation of the setup, proving System Reliability:

VRAM Efficiency: Usage peaked at 2.8 GB. This confirms that the 3B model is the sweet spot: fluent generation with Zero Licensing Overhead.
Scalability Benchmarks: ~438 prompt tokens/s and ~10 generation tokens/s. Proving that high-performance AI is possible without cloud dependency.

Operational Sustainability: The GPU pulled a steady 20W and stayed at 64°C. This is a Low-Cost/High-Performance local solution.

Summary: Driving Innovation Internally

Building a local AI stack isn't just a technical exercise; it's a strategic move for Business Continuity and Data Security. By combining Docker, NVIDIA's toolkit, and a comprehensive observability layer, I've created a dev environment that's both secure and cost-efficient, proving that significant AI ROI can be achieved on existing on-premise hardware.

DEV Community: Hakan İSMAİL

# HA Manager: Watchdog, Fencing ve Node Affinity (Modül 3)

HA Manager Nedir?

Uygulama 1: Watchdog'u Doğrulamak

Uygulama 2: VM'i HA'ya Eklemek

Uygulama 3: Gerçek Bir Çökme, Saniye Saniye

Tam Zaman Çizelgesi

Uygulama 4: Double-Start'ın Yapısal Olarak İmkansız Olduğunu Kanıtlamak

Uygulama 5: Node Affinity, Beklediğimden Daha Proaktif

Genel Değerlendirme

Quorum Kaybını Tetiklemek, QDevice Kurmak ve Shared Storage'a Geçmek (Modül 2)

Quorum Nedir, Neden Var?

Uygulama 1: Quorum Kaybını Gerçekten Tetiklemek

Uygulama 2: QDevice'i Devreye Almak

Beklenmedik Uyarı: Odd Node Count

lms Algoritmasının Etkisini Doğrulamak

Uygulama 3: QDevice'in Değerini Kanıtlamak

Uygulama 4: Split-Brain'i Tetiklemeye Çalışmak

İlk Deneme: Yanlış Anlaşılan Bir Hata

İkinci Deneme: Doğru İzolasyon

Bu Neden Oldu?

Toparlamak

Uygulama 5: Shared Storage ile Migration'ı Yeniden Denemek

NFS Sunucusunu Host'ta Kurmak

Beklenmedik Engel: Firewall

Proxmox'a Eklemek ve Disk Taşımak

Beklenmedik Bir Detay: Hayalet Disk Referansı

Temiz Migration: Öncesi/Sonrası

Genel Değerlendirme

# Proxmox Cluster Kurmak: Kavramlar, GUI/CLI ve Gerçek Hatalar (Modül 1)

Neden Cluster?

Üç Parça: pvecm, Corosync, pmxcfs

Uygulama 1: pmxcfs'i Kümelenmeden Önce Gözlemlemek

Uygulama 2: Cluster'ı Kurmak

Cluster'ı GUI'den Oluşturmak

Hata: TLS Sertifika Doğrulaması

pve-c'yi GUI'den Katılmak

Sonucu Doğrulamak

pmxcfs'in Canlı Senkronizasyonu

/etc/pve/nodes/ Dizininin Son Hali

Test: Migration ve Node Arızası Simülasyonu

Küçük Bir VM ile Migration Testi

Node'u Çökertmek

VM'i Başka Bir Yerde Başlatmayı Denemek

Toparlamak ve Doğrulamak

Genel Değerlendirme

Kendi Laboratuvarını Kurmak: Lab Ortamı Hazırlığı (Modül 0)

Ortam Hakkında Bir Not

Lab Mimarisi: Neden Nested Virtualization, Neden libvirt

Nested Virtualization Kontrolü

Kaynak Planlaması

ISO'ları İndirmek ve Doğrulamak

Ağ Mimarisi: NAT ve İzole Corosync Ağı

Storage Pool ve VM'ler: Geri Kalanı Arayüzden

Kurulumu Tamamlamak: Proxmox VE ve Debian

Bağlantıyı Doğrulamak

Genel Değerlendirme

vSAN Data Protection: Snapshot, Protection Group ve Immutability (Modül 7)

vSAN Data Protection Nedir?

vSAN ESA Snapshot'ları: Temel Mekanik

Data Protection Arayüzüne Giriş

Genel Bakış (Overview)

Protection Groups

Existing VMs, Removed VMs, Incoming VMs

Replication Pairs

Yeni Bir Protection Group Oluşturmak

Genel Ayarlar

VM İsim Deseni Eklemek

Snapshot Zamanlaması

Review ve Oluşturma

Manuel Snapshot Almak

Dinamik İsimlendirmeyi Test Etmek: Yeni Bir VM Oluşturmak

VM'leri Geri Yüklemek

Mevcut Bir VM'i Önceki Bir Ana Geri Döndürmek

Silinmiş Bir VM'i Geri Getirmek

VM Klonlamak

Klonlama Adımları

Klonların Neden Korunmadığını Doğrulamak

Immutable Protection Groups: Ransomware'e Karşı Bir Kilit

Immutable Protection Group Oluşturmak

`lms` Algoritmasının Etkisini Doğrulamak

`pve-c`'yi GUI'den Katılmak

`/etc/pve/nodes/` Dizininin Son Hali