DEV Community: Hakan İSMAİL

Proxmox Otomasyonu Faz 2: Serial ile Kimliklendirilmiş Depolama, Kesintisiz LVM + XFS

Hakan İSMAİL — Fri, 04 Sep 2026 06:15:59 +0000

Bir önceki fazda pipeline'ın temelini attık: tek bir terraform apply Ubuntu 26.04 imajını indirip golden template'i kuruyor, cloud-init'li klonu (vm-test-01, VMID 200) ayağa kaldırıyor, ilk temas playbook'u Ansible'la yönetim kanalını açıyordu. VM hâlâ ayakta, guest agent çalışıyor, repo git'te. Ama o makine tek diskli ve production'da hiçbir DB sunucusu tek diskle çalışmıyor: /var, log, data, backup ayrı LUN'larda, her biri kendi büyüme takvimiyle.

Şeffaflık adına küçük bir not, inşa bölümlerine girmeden önce: bu rehberin arkasındaki saha oturumu, Faz 2'nin başında lab'ı sıfırdan kurdu. Yani buradaki transkriptleri taşıyan makine birebir Faz 1'in bitirdiği VM değildi; aynı pipeline'ın, aynı koddan ürettiği taze bir klondu. Ama rebuild'in kendisi bu rehberin en değerli iki sorun giderme satırını hediye etti: temizlik sırasında silinmeyip kalan bir template'e çarpan ilk apply ve ilk girişte karşılayan taze SSH host anahtarları. İkisi de aşağıda, gerçek transkriptleriyle.

Hedef: dört disk, kalıcı kimlik

Faz 2'nin tamamı yine tek cümleye sığıyor: DB sınıfı bir iş yükünün dört diski Terraform'da tanımlanmalı, her diskin kalıcı bir kimliği olmalı, guest tarafı bu kimliklerden LVM üstünden XFS'e uzanan bir zincirle bağlanmalı ve büyüme isteği tek değişkenle, makine çalışırken çözülmeli.

Bileşen	Sürüm/Not
Proxmox VE	9.2
Terraform	1.15.x
bpg/proxmox provider	0.111.1
ansible-core	2.20
Yeni bağımlılık	community.general, ansible.posix
Dosya sistemi	XFS

Kapsam, Faz 1'deki gibi bilinçli olarak dar tutuluyor; her hareketli parça tek başına doğrulanabilsin diye:

Faz 2'de var	Sonraki fazlara ertelendi
Workload VM'de dört serial etiketli veri diski	Golden template'in kendisine disk eklemek (kalıp sade kalıyor)
PV, VG, LV, XFS ve fstab'ı tek idempotent playbook'un yönetmesi	`/var` gibi canlı dizinleri yeni disklere taşımak (canlı veri taşıma)
Online büyütme: tfvars düzenle, apply, playbook'u tekrar çalıştır	Küçültme (tasarım gereği imkânsız: provider sert hata, XFS'in kendi sınırı)
Doğrulama çıktıları: lsblk, df, serial eşleşmesi	Kullanım izleme (Zabbix Faz 3'te geliyor)
Community collection'ları yönetilen bir bağımlılık olarak tutmak	Terraform state'ten beslenen dinamik envanter (Faz 4)

Problem: disk tahmini ve elle büyütme

Bu fazı şekillendiren gereksinimler sahadan geldi ve tekrar etmeye değer, çünkü başarının neye benzediğini tanımlıyorlar. O ortamdaki DB sunucuları OS diski dışında dört beş disk taşıyor: /var, log, data, backup, her biri kendi LUN'unda, kendi büyüme takviminde. Bir müşteri /data'ya yer istediğinde önce birinin hangi hipervizör diskinin gerçekten o olduğunu bulması, sonra doğru olanı büyütmesi, sonra guest içinde dosya sisteminin yeni alanı görmesi için bir komut zincirini adım adım işletmesi gerekiyordu.

Sorunun özü, Linux'ta disk harflerinin bir kimlik değil, bir numaralandırma kazası olması. Kernel, SCSI aygıtlarını bus'ın tarama sırasına göre numaralandırıyor; bu sıra, sürücü probing'i ve aygıt kaydının zamanlamasının bir yan etkisi. Genelde konfigürasyon sırasıyla eşleşiyor, bu yüzden /dev/sdb sinsi ve yanıltıcı bir güvenceye dönüşüyor: eşleşme, tam da bir gün artık geçerli olmayana kadar (tipik olarak bir reboot'tan, bir hotplug olayından ya da bir disk daha eklendiğinde) istikrarlı görünüyor. Sistemde scsi3'ün, yapılandırdığınız üçüncü disk olduğuna dair hiçbir söz yok.

Bunun sonucu, deneme-yanılmayla büyütmeydi: hipervizörde bir diski tanınabilir bir miktar büyüt, guest içinde hangi disk harfinin boyutunun değiştiğini gözle, ancak o zaman hangi diske dokunduğunu öğren. Bu deneme sürecini bir grup içindeki on sunucuyla çarpınca hata payı ciddileşiyor: yanlış diski büyütmek zararsız ama bir bakım penceresini boşa harcıyor; yanlış diski formatlamak ise bir veri kaybı olayı. Çözüm daha fazla dikkat değil, numaralandırmayı atlatan bir kimlik.

Doğru disk bulunduktan sonra ritüelin kendisi beş komutluk bir silsileden ibaretti: partition'ı genişletmek için growpart ya da fdisk, LVM'e yeni boyutu öğretmek için pvresize, mantıksal volümü büyütmek için lvextend, dosya sistemini büyütmek için xfs_growfs. Bu adımların hiçbiri zor değil; hepsi unutulması kolay, sıraya bağlı ve on terminal aynı anda açıkken yanlış aygıta karşı çalıştırılması kolay. Faz 2 bu ritüeli, beş komutu scriptleştirerek değil, "bu disk hangisi" sorusunu baştan belirsiz olmaktan çıkararak siliyor.

Tasarım: kimlik serial'da

Disk harfi, kernel'in diski nerede bulduğudur. Serial, diskin ne olduğudur. Diskleri ne olduklarıyla adresle.

Bu tasarımdaki her disk, Terraform'da set edilen, Proxmox konfigürasyonundan geçen, QEMU tarafından guest'e sunulan ve kernel tarafından lsblk'nin SERIAL kolonunda raporlanan bir serial string taşıyor. Serial, bütün yığını değişmeden dolaşıyor; onu bir etiket değil bir kimlik yapan da bu: tfvars dosyasında, PVE konfigürasyonunda ve guest'in kendi disklerine dair kernel görüşünde aynı değer.

Saha testi bu zincire bir ders ekledi ve aşağıdaki tablo bu durumu bütün çıplaklığıyla gösteriyor:

Katman	Değer
terraform.tfvars	`data_disk_size_gb = 20`
terraform (vm.tf)	`disk { interface = "scsi3" serial = "data01" size = 20 }`
pve-a (`qm config 200`)	`scsi3: nfs-shared:vm-200-disk-2,size=20,serial=data01`
pve-a (`qm showcmd 200`)	scsi-hd aygıt satırında `serial=data01`
guest (`lsblk -o SERIAL`)	`sdc disk 20G data01` ← kernel'in gördüğü
ansible (02_storage.yml)	`dev: "/dev/sdc"` (lsblk'den taze çözülmüş)
sonuç	`vg_data/lv_data`, `/srv/data`'ya bağlı

Ders, son iki halkada yatıyor. Bu playbook'un ilk sürümü serial'leri klasik udev yolu /dev/disk/by-id üzerinden çözüyordu; bu yığında o dizin serial-adlı girdileri hiç oluşturmadı. Kernel lsblk'de dört serial'i de raporluyordu, by-id ise hiçbirini sunmuyordu; yani Ubuntu 26.04, virtio-scsi üzerinde bu symlink'leri garanti etmiyor. Playbook bu yüzden kernel görüşünü doğrudan okuyor; çözdüğü disk harfleri de tam bu yüzden güvenle kullanılabiliyor: LVM fiziksel volümleri UUID'yle takip ediyor, fstab /dev/vg/lv device-mapper yollarını bağlıyor, eşleşme her çalıştırmada sıfırdan yeniden kuruluyor. Harf, playbook'un bir çalıştırma döngüsü süresince geçerli bir tutamaç; serial, VG ve LV ise kalıcı kimlikler.

Tasarımın üç dayanağı, kod okunmadan varsayılmadı; bpg/proxmox 0.111.1'in kaynağından doğrudan alındı:

İddia	Kaynak kanıtı	Tasarıma yansıması
Mevcut bir VM'e disk eklemek yeniden oluşturmaya zorlamıyor	disk.go'daki disk bloğunda hiç ForceNew bayrağı yok	Dört disk, çalışan VM 200'e yerinde ekleniyor; destroy yok, re-clone yok
Diski büyütmek online bir API çağrısı	vm.go, boyut artışları için resize API'yi çağırıyor; yalnızca datastore taşımaları shutdownForDisksRequired işaretliyor	Büyütme demosu reboot'suz çalışıyor; datastore'lar arası taşıma hâlâ kesinti isteyen tek depolama değişikliği
Küçültme yüksek sesle reddediliyor	vm.go "Cannot shrink ... it is not supported" hatasını döndürüyor	Sadece-büyüme kuralı provider katmanında zaten dayatılıyor; playbook bununla savaşmak yerine uyum sağlıyor

Bu garantilerin üstüne beş yerleşim kararı geliyor:

Karar	Gerekçe
Disk başına bir VG ve bir LV	Disk büyür, VG'si büyür, LV'si büyür: net ve bire bir bir zincir. Paylaşımlı bir VG tahsiste daha esnek ama hangi fiziksel diskin hangi LV'yi beslediğini bulanıklaştırıyor
LV, VG'nin yüzde yüzü	LV her zaman diskine eşit; VG büyüyünce `lvol` onu otomatik uzatıyor, hiçbir şey değişmediğinde no-op olarak boş dönüyor
XFS, ext4 değil	Hedef ortamdaki DB-sunucu pratiği; `xfs_growfs`'le online büyüyor; küçültülememesi provider'ın sadece-büyüme kuralıyla zaten örtüşüyor
Lab, `/srv/*` altına bağlanıyor	Canlı `/var`'ın üstüne taze bir dosya sistemi bağlamak önce bir veri taşıma ister; lab, makineyi güvenli bağlama noktalarında kanıtlıyor, production veri taşımasıyla uyguluyor
Boyutlar tfvars parametresi	Golden template her VM için sade ve aynı kalıyor; VM başına boyutlar iş yükü parametresi; tam olarak Faz 4'ün istek formunun dolduracağı şey

Bu yerleşimin bir özelliği erkenden içselleştirilmeye değer, çünkü bütün bir endişe sınıfını ortadan kaldırıyor: tasarım sadece büyümeyi destekliyor ve bu bir eksiklik değil, bilinçli bir tasarım tercihi. Provider küçültmeyi reddediyor, XFS bir dosya sistemini küçültemiyor, playbook lvol'ü shrink: false ile çalıştırıyor ki hiç denemesin. Bir volüm gerçekten küçülmek zorundaysa doğru ve sağlıklı yöntem doğru boyutta yeni bir disk artı bir veri taşıma; yerinde yapılan bir göz boyama değil, planlı bir göç.

Terraform: dört diski tanımlamak

Faz 2'nin Terraform tarafı tek bir kavramın dört kez uygulanması: serial'li bir disk bloğu. Aşağıdaki ek, vm.tf'e Faz 1'in mevcut scsi0 OS disk bloğunun hemen ardına giriyor. Neyin eksik olduğuna dikkat: provider'a özel geçici çözüm yok, ignore yok, lifecycle bloğu yok. Kimlik şeması, hipervizöre olduğu gibi geçen bir string özniteliğinden fazlasını istemiyor.

disk {
  datastore_id = var.storage_id
  interface    = "scsi1"
  size         = var.var_disk_size_gb
  serial       = "var01"
  ssd          = true
  discard      = "on"
}
disk {
  datastore_id = var.storage_id
  interface    = "scsi2"
  size         = var.log_disk_size_gb
  serial       = "log01"
  ssd          = true
  discard      = "on"
}
disk {
  datastore_id = var.storage_id
  interface    = "scsi3"
  size         = var.data_disk_size_gb
  serial       = "data01"
  ssd          = true
  discard      = "on"
}
disk {
  datastore_id = var.storage_id
  interface    = "scsi4"
  size         = var.backup_disk_size_gb
  serial       = "backup01"
  ssd          = true
  discard      = "on"
}

ssd ve discard bayrakları OS diskiyle birebir aynı, ki beş disk NFS backend'inde aynı şekilde davransın: SSD emülasyonu guest'in TRIM göndermesine izin veriyor, discard on paylaşımda thin provisioning'in doğru ve sağlıklı çalışmasını sağlıyor. Arayüzler açıkça sabitlenmiş, scsi1'den scsi4'e; çünkü provider, state ile gerçeği eşleştirirken diskleri tam olarak arayüzden okuyor; sabit bir pin, diff'i temiz tutuyor.

Boyutlar, hepsi varsayılanlı dört yeni değişkenden geliyor; mevcut bir tfvars dosyasını kırmayan da tam bu: hiçbir satır değişmeden çalışmaya devam ediyor.

# terraform.tfvars.example (Faz 2 eki)
var_disk_size_gb    = 10  # scsi1 serial=var01    -> /srv/var
log_disk_size_gb    = 10  # scsi2 serial=log01    -> /srv/log
data_disk_size_gb   = 20  # scsi3 serial=data01   -> /srv/data (büyütme demosu)
backup_disk_size_gb = 15  # scsi4 serial=backup01 -> /srv/backup

Değişken	Varsayılan	Serial	Bağlama noktası
var_disk_size_gb	10	var01	/srv/var
log_disk_size_gb	10	log01	/srv/log
data_disk_size_gb	20 (demoda 30'a çıkıyor)	data01	/srv/data
backup_disk_size_gb	15	backup01	/srv/backup

Repo güncellenince, mevcut Faz 1 state'ine karşı çekilen plan bir yerinde güncelleme gösteriyor, bir yer değiştirme değil. Bu, üçüncü bölümdeki ForceNew-yok kanıtının gerçek çıktıda görünür olduğu an ve dikkatle okunmaya değer: plan tam olarak bir kaynağın değiştiğini, sıfır kaynağın yok edildiğini göstermeli.

~ resource "proxmox_virtual_environment_vm" "test_vm" {
    ~ agent { enabled = true }
    ~ disk {
        ~ serial = "data01" -> (known after apply)
        # (5 değişmeyen öznitelik gizlendi)
      }
    + disk {
        + datastore_id = "nfs-shared"
        + interface    = "scsi1"
        + serial       = "var01"
        + size         = 10
      }
    + disk { ... scsi2, serial "log01", size 10 ... }
    + disk { ... scsi3, serial "data01", size 20 ... }
    + disk { ... scsi4, serial "backup01", size 15 ... }
  }

Plan: 0 to add, 1 to change, 0 to destroy.

Diff'in tam görünümü provider sürümüne göre değişiyor ama özet satır sözleşmenin ta kendisi: 0 to add, 1 to change, 0 to destroy. Bir plan bir boyut düzenlemesinden sonra VM'in yeniden oluşturulacağını gösterirse dur ve yes yazmadan önce diff'i oku; bu tasarımda yeniden oluşturmanın tek meşru sebepleri VMID ya da klon kaynağı gibi kimlik özniteliklerinin değişmesi, asla bir disk boyutu değil.

Apply: disk, VM çalışırken beliriyor

Disk eklemesini apply etmek tasarım gereği sıradan: provider, VM konfigürasyonunu API üzerinden güncelliyor, NFS datastore'da dört disk dosyası oluşturuyor, çalışan VM de hotplug ile dört yeni virtio-scsi aygıtı görüyor. Zamanlanacak bir kesinti penceresi yok, açılacak bir konsol yok; tüm operasyon NFS'te disk başına saniyeler sürüyor.

root@ctrl-01:~/proxmox-automation/terraform# terraform apply
proxmox_virtual_environment_vm.test_vm: Modifying... [id=200]
proxmox_virtual_environment_vm.test_vm: Modifications complete after 12s

Apply complete! Resources: 0 added, 1 changed, 0 destroyed.

Bu akıştaki tek kritik nokta saha testinde ortaya çıktı ve baş ağrıtmadan önce bilinmesinde fayda var. API diskleri takılı olarak raporluyor, qm config serial'leri gösteriyor; ama serial hotplug edilebilen bir özellik değil: disk'ler VM zaten çalışırken eklendiğinde, saklanan konfigürasyon serial'leri taşıyor ama çalışan QEMU süreci taşımıyor, bu yüzden guest kernel'i boş serial'ler raporluyor. Düzeltme node üzerinden tam bir durdur-başlat: qm shutdown 200 && qm start 200. Guest içindeki bir reboot QEMU'yu yeniden başlatmıyor. Sonraki bölümdeki playbook'un assert'i tam bu durumu iki ihtimalli net bir teşhis mesajıyla yakalıyor; hata bu yüzden gizemli değil, gayet anlaşılır.

İki taraftan doğrulama

Bu seride her yerde olduğu gibi bir iddia, ancak arkasındaki kanıt ve somut çıktı kadar geçerlidir. Diskler artık hipervizör sınırının iki tarafında da var ve üç komut zincirin tamamını kapsıyor; hepsi de Ansible adımı bir şeye dokunmadan önce aynı dört serial'de hemfikir olmalı. İlk ikisi bir PVE node'unda çalışıp hipervizörün gördüğü durumu, hem saklanan konfigürasyonda hem gerçekten çalışan QEMU sürecinde gösteriyor; sonuncusu guest içinde çalışıp kernel'in gerçekten ne gördüğünü gösteriyor. Bu, saha hatasını dakikalar içinde izole eden komut seti.

# pve-a'da: saklanan konfigürasyon serial'leri taşıyor...
root@pve-a:~# qm config 200 | grep -E "scsi[1-4]:"
scsi1: nfs-shared:vm-200-disk-0,size=10,serial=var01,ssd=1,discard=on
scsi2: nfs-shared:vm-200-disk-1,size=10,serial=log01,ssd=1,discard=on
scsi3: nfs-shared:vm-200-disk-2,size=20,serial=data01,ssd=1,discard=on
scsi4: nfs-shared:vm-200-disk-3,size=15,serial=backup01,ssd=1,discard=on

# ...çalışan QEMU süreci de öyle:
root@pve-a:~# qm showcmd 200 --pretty | grep -o "serial=[a-z0-9]*"
serial=var01
serial=log01
serial=data01
serial=backup01

# guest içinde: kernel her serial'i kendi görüşünde raporluyor
ubuntu@vm-test-01:~$ lsblk -o NAME,SIZE,TYPE,SERIAL
NAME SIZE TYPE SERIAL
sda  10G  disk drive-scsi0   <- OS diski: QEMU'nun varsayılan kimliği, serial yok
sdb  15G  disk backup01
sdc  20G  disk data01
sdd  10G  disk log01
sde  10G  disk var01

Bu çıktıda üç ayrıntı dikkati hak ediyor. OS diski drive-scsi0 gösteriyor, QEMU'nun serial'siz yapılandırılmış bir disk için varsayılan tanımlayıcısı; zararsız çünkü bu tasarımda hiçbir şey OS diskini serial'le adreslemiyor. Disk dosyası numaralandırması kasıtlı biçimde tedirgin edici görünüyor: OS diski vm-200-disk-0.qcow2 iken dört ham veri diski vm-200-disk-0'dan vm-200-disk-3'e uzanıyor. Yani depolama tahsis mekanizması (storage allocator), farklı dosya uzantıları arasında indeksleri yeniden kullanmış; bir hata gibi görünüyor, aslında bir uygulama detayı, disk sayısı da boyutlar da serial'ler de doğru. Ve /dev/disk/by-id'nin lsblk çıktısını yansıtmasını beklemeyin: bu Ubuntu 26.04 guest'inde o dizin serial-adlı hiçbir girdi hiç oluşturmadı; playbook'un kernel görüşünü okumasının sebebi tam da bu.

Rebuild dolambacı: önce başarısız olan apply

Saha oturumu çalışan bir Faz 1 VM'inden başlamadı. Lab'ı sıfıra indirerek başladı: eski repo dizini silindi, eski VM'ler yok edildi, repo ctrl-01'de yeniden açıldı, terraform init boş bir state'ten başladı. Temizlikten bir nesne kaçtı: Faz 1'in golden template'i, VMID 9000, hâlâ pve-a'da duruyordu ve oturumun ilk apply'ı ona çarpıp başarısız oldu. Hata bir dönüştürme sorunu gibi görünüyor; asıl sorun iki adım önce, oluşturma anında yaşandı ve sıra dikkatle okunmaya değer, çünkü geride kalan her nesne senaryosunda benzer durum yaşanır.

root@ctrl-01:~/proxmox-automation/terraform# terraform apply
proxmox_virtual_environment_vm.ubuntu_template: Creating...
proxmox_virtual_environment_vm.ubuntu_template: Still creating...
╷
│ Error: VM convert to template failed
│ ... can't convert a template to a template ...
╵
# apply #1 burada durdu; template kaynağı state'te kaldı, tainted işaretlendi

Mekanizma, sonradan provider kaynağından doğrulandı: create çağrısı PVE'nin "VM 9000 already exists" hatasına çarptı; provider'ın retry yardımcısı bu spesifik hatayı zaten-tamamlanmış-başarı olarak ele alıyor (vms.go, ErrorContains("already exists") etrafındaki WithAlreadyDoneCheck). Oluşturma bu yüzden "başarılı" oldu, imaj içe aktarma ve disk boyutlandırma geride kalan template'e karşı çalıştı, uyuşmazlık ancak son dönüştürme adımında ortaya çıktı: PVE bir template'i template'e dönüştürmeyi reddetti. Durumu olduğundan daha vahim gösteren beklenmedik bir ayrıntı daha var: provider, VM oluşturulduktan hemen sonra kaynak ID'sini yazıyor, yani başarısız apply template kaynağını state'te mevcut ve tainted bırakıyor; bunu hiç kurtarırken görmemiş birine tamamen kurtarılamaz görünen bir durum.

root@ctrl-01:~/proxmox-automation/terraform# terraform apply
Note: Objects have changed outside of Terraform since the last
"terraform apply" ... the following changes ... has been deleted
- ...
proxmox_virtual_environment_vm.ubuntu_template: Creating...
proxmox_virtual_environment_vm.ubuntu_template: Creation complete after 10s
proxmox_virtual_environment_vm.test_vm: Creating...
proxmox_virtual_environment_vm.test_vm: Creation complete after 5s

Apply complete! Resources: 2 added ...
# template: ~10 sn; test_vm: ~5 sn; ikinci denemede ikisi de temiz kuruldu

Kurtarma hiçbir elle state ameliyatı istemedi ve asıl ders bu: apply'ı yeniden çalıştırmak geçerli bir ilk tepki. Refresh, state ile gerçeğin anlaşmadığını fark etti, Terraform dışında nesnelerin değiştiğine dair tanıdık notu bastı, geride kalan girdiyi temizledi, iki kaynağı da temiz yeniden kurdu: template'i on saniyede, VM'i beş saniyede. Bu hikâyeden iki alışkanlık çıkıyor: bir lab'ı söküyorsan template'i de yok et, bu temizliğin unuttuğu tek nesne o, node üzerinde qm destroy 9000 onu kaldırıyor. Ve bir apply geride kalmış bir şeye çarpıp düşerse, hatayı oku, sonra terraform state komutlarına uzanmadan önce tekrar apply et; provider'ın okuma yolu tam bu durumu yakınsatmak için inşa edilmiş.

Rebuild'in bir sonucu daha vardı, tam bir sonraki komutu karşılıyor: yeni VM taze host anahtarları üretti, ctrl-01'deki known_hosts hâlâ eski makineyi hatırlıyor ve SSH bağlantıyı yüksek sesle reddediyor. Bu her klonlanan VM'in her rebuild'inde beklenen bir şey, uyarı özelliğin ta kendisi, düzeltmesi tek komut:

root@ctrl-01:~# ssh ubuntu@192.168.122.50
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
...
root@ctrl-01:~# ssh-keygen -f ~/.ssh/known_hosts -R 192.168.122.50
# Host 192.168.122.50 found: line 2
192.168.122.50 Host key removed.
root@ctrl-01:~# ssh ubuntu@192.168.122.50  # yeni anahtarı kabul et

Faz 1'i yazarken bu sahneye "bunu sonradan öğrendim" diye not düşmüştüm; söz burada tutuldu.

Ansible storage playbook'u

Faz 1 tamamen builtin modüllerle çalışmıştı; Faz 2, pipeline'ın ilk gerçek bağımlılığını kazandığı yer. LVM ve mount yönetimi community collection'larında yaşıyor, repo artık bunları bir requirements dosyasında sabitliyor ki kontrol düğümü repodan tek başına yeniden üretilebilsin. Kurulum ctrl-01'de tek komut, bu fazın getirdiği tek yeni ön koşul da bu:

# ansible/requirements.yml
collections:
  - name: community.general
    source: https://galaxy.ansible.com
  - name: ansible.posix
    source: https://galaxy.ansible.com

root@ctrl-01:~/proxmox-automation/ansible# ansible-galaxy collection install -r requirements.yml

Playbook'un kendisi bir ekran değişken, bir ekran görev ve şekli üçüncü bölümdeki kimlik zincirini izliyor: önce çöz, sonra kur, sonra bağla. Değişkenler dört diskin tüm istenen durumunu tek yerde bildiriyor; lab'a ileride beşinci bir disk eklemek bu yüzden bir tfvars satırı, bir vm.tf bloğu ve bu listeye bir girdi kadar basit.

# playbooks/02_storage.yml (data_disks sözleşmesi)
vars:
  data_disks:
    - serial: var01 # scsi1, boyut: var_disk_size_gb
      vg: vg_var
      lv: lv_var
      mount: /srv/var
    - serial: log01 # scsi2, boyut: log_disk_size_gb
      vg: vg_log
      lv: lv_log
      mount: /srv/log
    - serial: data01 # scsi3, boyut: data_disk_size_gb
      vg: vg_data
      lv: lv_data
      mount: /srv/data
    - serial: backup01 # scsi4, boyut: backup_disk_size_gb
      vg: vg_backup
      lv: lv_backup
      mount: /srv/backup

Çözümleme önce geliyor, çünkü sonraki her görev bir diski kendi çözülmüş yolundan adresliyor ve saha testi bu çözümlemenin nereden okuyacağına karar verdi. İlk sürüm bir find görevi ile /dev/disk/by-id'yi dolaşıyordu; Ubuntu 26.04 guest'i serial symlink'lerini orada hiç oluşturmadı, bu yüzden v2 doğrudan kernel'e soruyor: tek bir lsblk -J çağrısı her blok aygıt için NAME, TYPE ve SERIAL'i yakalıyor, bir set_fact bu JSON'dan serial-den-diske haritayı kuruyor, bir debug görevi haritayı yazdırıyor ki çalıştırma log'u her serial'in hangi aygıta dönüştüğünü göstersin, ve bir assert bir serial tam olarak bir diskten başka bir şeye çözülürse açıkça hata fırlatıp işlemi durduruyor. Bu assert hem beşinci bölümdeki taze-QEMU durumuna hem klasik bir yazım hatasına karşı bir bekçi; hata mesajı ise karmaşık bir stack trace yerine iki ihtimalli net bir teşhis taşıyor.

- name: Read the kernel serial view of all disks
  ansible.builtin.command:
    cmd: lsblk -J -o NAME,TYPE,SERIAL
  register: lsblk_serials
  changed_when: false

- name: Map every serial to its disk(s) (kernel view)
  ansible.builtin.set_fact:
    serial_map: >-
      {{ serial_map | default({}) | combine({
        item: (lsblk_serials.stdout | from_json).blockdevices
          | selectattr('type', 'equalto', 'disk')
          | selectattr('serial', 'equalto', item)
          | map(attribute='name') | list
      }) }}
  loop: "{{ data_disks | map(attribute='serial') | list }}"

- name: Every serial must resolve to exactly one disk
  ansible.builtin.assert:
    that: serial_map[item.serial] | default([]) | length == 1
    fail_msg: >-
      Expected exactly one disk with serial {{ item.serial }}, found
      {{ serial_map[item.serial] | default([]) | length }}. Diagnose in
      the guest with lsblk -o NAME,SIZE,SERIAL. (a) Empty serials there
      mean the running QEMU predates the config: check qm config, then
      fully stop and start the VM; a guest reboot does NOT restart
      QEMU. (b) If lsblk shows the serial, compare against vm.tf.
  loop: "{{ data_disks }}"

Bu yeniden yazım teorik değildi: ilk sürüm sahada tam olarak by-id'nin boş olduğu yerde başarısız oldu ve o başarısızlığın şekli, onu izole eden komutlarla birlikte saklamaya değer, çünkü "playbook, hipervizörün orada olduğuna yemin ettiği şeyi göremiyor" durumunun genel reçetesi bu: saklanan konfigürasyonu kontrol et, çalışan süreci kontrol et, kernel'i kontrol et, ilk anlaşmayan görüş sorunu adlandırsın.

root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/02_storage.yml
TASK [Every serial must resolve to exactly one disk] **************
fatal: [vm-test-01]: FAILED! => (item=var01) => {
    "msg": "Expected exactly one disk with serial var01, found 0. ..."
}
... (log01, data01, backup01: aynı şekil, found 0)

# izolasyon, dakikalar sonra (VM'in tam durdur/başlat'ından sonra):
# pve-a'da: qm config 200 | grep serial -> dört serial de mevcut
# pve-a'da: qm showcmd 200 | grep serial -> çalışan QEMU'da da var
# guest'te: lsblk -o NAME,SIZE,SERIAL -> dört serial de mevcut
# guest'te: ls /dev/disk/by-id -> 10 girdi, hiçbiri serial-adlı değil

Eşleşme kurulduktan sonraki inşa zinciri dört görevden oluşuyor ve modül işleyişi varsayımlarla değil, doğrudan community.general kaynak kodundan incelenerek kurgulandı. fstype: lvm ile filesystem modülü oluşturmayı pvcreate'e, büyütmeyi pvresize'a eşliyor; lvg modülü gerekirse pvcreate'i kendisi çalıştırıp volume group'u kuruyor; size: 100%VG ile lvol modülü LV hedefini VG'nin tamamı olarak hesaplıyor, ilk çalıştırmada LV'yi kuruyor, VG her büyüdüğünde lvextend --resizefs çağırıyor; bu da XFS için online xfs_growfs'i tetikliyor. shrink bayrağı sadece-büyüme mantığıyla eşleşsin diye false.

- name: Create/resize physical volumes
  community.general.filesystem:
    fstype: lvm
    dev: "{{ disk_map[item.serial] }}"
    resizefs: true # ilk çalıştırmada pvcreate, her çalıştırmada pvresize

- name: Create volume groups (one per disk)
  community.general.lvg:
    vg: "{{ item.vg }}"
    pvs: "{{ disk_map[item.serial] }}"

- name: Create/extend logical volumes at 100 percent of their VG
  community.general.lvol:
    vg: "{{ item.vg }}"
    lv: "{{ item.lv }}"
    size: 100%VG # LV her zaman VG'sine eşit
    resizefs: true # lvextend --resizefs -> xfs_growfs
    shrink: false # sadece büyüme, tasarım gereği

- name: Create XFS filesystems
  community.general.filesystem:
    fstype: xfs
    dev: "/dev/{{ item.vg }}/{{ item.lv }}"

- name: Mount filesystems and persist in fstab
  ansible.posix.mount:
    path: "{{ item.mount }}"
    src: "/dev/{{ item.vg }}/{{ item.lv }}"
    fstype: xfs
    opts: defaults,noatime
    state: mounted # hem şimdi bağla HEM fstab'a yaz

Bu zincirde iki ayrıntı dikkati hak ediyor. Mount görevi state: mounted kullanıyor, bu hem hemen bağlıyor hem fstab girdisini yazıyor; playbook, düzen bir reboot'u atlatana kadar bitmiş sayılmıyor. Ve disk'in tamamı, partition tablosu olmadan LVM'e bir PV olarak veriliyor; bu modern disk-başına-tek-LV kalıbı ve resize zincirinden growpart adımını tamamen kaldırıyor. Genişletilecek bir partition yok, çünkü partition yok.

Son olarak, pre_tasks bloğu her şeyden önce lvm2 ve xfsprogs'u kuruyor, çünkü Ubuntu cloud imajları ikisiyle de gelmiyor. Bu, Faz 1'deki eksik guest agent'la aynı sınıftan bir ders: cloud imajları bilinçli olarak minimal, iş yükünün taban sistemin ötesinde ihtiyaç duyduğu her şey pipeline'ın işi oluyor. Bu adımı unutmak, filesystem modülünün pvcreate'i bulamadığı kafa karıştırıcı bir erken hatayla sonuçlanıyor; pre_task bağımlılığı açık ve idempotent hale getiriyor.

İlk çalıştırma ve doğrulama

Sıfırıncı adım: taze VM'de guest agent yok

Sıralama kuralları neyin önce çalışacağını belirliyor ve saha oturumu bunu bir başarısızlıktan değil bir uyarıdan öğrendi. Taze klonlanmış bir VM'de QEMU guest agent yok; Faz 1'in 01_first_contact.yml'i onu kuran adım. Agent bu fazda özellikle önemli, çünkü beşinci bölümdeki teşhis durdur-başlat'ı temiz bir kapanış istiyor ve PVE, agent'ı olan bir VM'i onun üzerinden kapatıyor. Aşağıdaki uyarı, aynı komutun agent yokken neye benzediği; zararsız ama sıralamayı adlandırıyor: önce ilk temas, sonra depolama.

root@pve-a:~# qm shutdown 200
warning: QEMU Guest Agent is not running
# kapatma yine de başarılı; agent olmadan guest-farkında değil, düz bir ACPI kapatma

root@pve-a:~# qm start 200

Rebuild edilmiş VM'de ilk temas playbook'unun tekrar çalıştırılması, Faz 1'in taze bir makine için belgelediği doğrulama çıktısının aynısıyla sonuçlandı, aynı sebeple: agent paketi kuruluyor (changed), postinst'i servisi zaten başlatmış oluyor (bu yüzden service görevi ok okuyor), yönetilen damga yazılıyor (changed). Aynı sayılar, yeni makine:

root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/01_first_contact.yml
TASK [Install QEMU guest agent] *********************************
changed: [vm-test-01]

TASK [Enable and start the guest agent] *************************
ok: [vm-test-01]

TASK [Mark the VM as managed by this pipeline] *******************
changed: [vm-test-01]

PLAY RECAP ******************************************************
vm-test-01 : ok=5 changed=2 unreachable=0 failed=0
# taze klon doğrulandı: Ubuntu 26.04, kernel 7.0.0-30-generic

İlk çalıştırma

Agent yerindeyken storage playbook'u ilk kez çalıştırılıyor ve değişiklik yapan tek çalıştırma bu: sonrasında playbook'taki her görev ya no-op, ya kozmetik bir kontrol ya da bir büyütme adımı. Saha testinde recap beş changed görev gösterdi; dört tam dosya sistemi yığınını çıplak disklerden inşa etmenin görünüşü bu. Araç pre_task'ı ok'a indi çünkü daha önce yarım kalmış bir deneme lvm2 ve xfsprogs'u zaten kurmuştu; bakir bir VM'de o görev de değişiyor.

root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/02_storage.yml
PLAY [Storage - LVM and XFS on serial-tagged data disks] **********

TASK [Show the serial to device mapping (the guessing game this replaces)] ***
ok: [vm-test-01] => (item=var01) => { "msg": "var01 (vg_var/lv_var -> /srv/var) = /dev/sde" }
ok: [vm-test-01] => (item=log01) => { "msg": "log01 (vg_log/lv_log -> /srv/log) = /dev/sdd" }
ok: [vm-test-01] => (item=data01) => { "msg": "data01 (vg_data/lv_data -> /srv/data) = /dev/sdc" }
ok: [vm-test-01] => (item=backup01) => { "msg": "backup01 (vg_backup/lv_backup -> /srv/backup) = /dev/sdb" }

TASK [Every serial must resolve to exactly one disk] **************
ok: [vm-test-01] => (item=var01) => { "msg": "All assertions passed" }
... (3 tane daha, hepsi geçti) ...

TASK [Create/resize physical volumes] ****************************
changed: [vm-test-01] => (item=var01) ... (3 tane daha)

TASK [Create volume groups (one per disk)] ***********************
changed: [vm-test-01] => (item=vg_var) ... (3 tane daha)

TASK [Create/extend logical volumes at 100 percent of their VG] ***
changed: [vm-test-01] => (item=vg_var/lv_var) ... (3 tane daha)

TASK [Create XFS filesystems] ************************************
changed: [vm-test-01] => (item=/dev/vg_var/lv_var) ... (3 tane daha)

TASK [Mount filesystems and persist in fstab] ********************
changed: [vm-test-01] => (item=/srv/var) ... (3 tane daha)

PLAY RECAP ******************************************************
vm-test-01 : ok=14 changed=5 unreachable=0 failed=0

Eşleştirme bloğunu her şeyden önce okuyun: o dört debug satırı, ikinci bölümdeki tahmin oyununun düz metinde çözülmesi. Her serial, kendi VG/LV çifti, bağlama noktası ve çözülmüş aygıtıyla tek satırda duruyor; bütün bu tasarımın bize kazandırdığı asıl değer bu satır. Bir serial çözülemeseydi, assert karmaşık bir stack trace yerine yönlendirici bir hata mesajıyla süreci tam orada durdururdu.

Playbook, çalıştırma log'unun bir iddia değil kanıtla bitmesi için iki doğrulama çıktısıyla kapanıyor:

TASK [Show block devices with serials and mounts] *************
NAME                   SIZE TYPE SERIAL      MOUNTPOINT
sda                    10G disk              / <- OS diski (serial gerekmiyor)
sdb                    15G disk backup01
└─vg_backup-lv_backup  15G lvm               /srv/backup
sdc                    20G disk data01
└─vg_data-lv_data      20G lvm               /srv/data
sdd                    10G disk log01
└─vg_log-lv_log        10G lvm               /srv/log
sde                    10G disk var01
└─vg_var-lv_var        10G lvm               /srv/var

TASK [Show filesystem usage] ************************************
Filesystem                        Size  Used Avail Use% Mounted on
/dev/mapper/vg_var-lv_var          10G  104M   10G   2% /srv/var
/dev/mapper/vg_log-lv_log          10G  104M   10G   2% /srv/log
/dev/mapper/vg_data-lv_data        20G  424M   20G   3% /srv/data
/dev/mapper/vg_backup-lv_backup    15G  145M   15G   1% /srv/backup

İdempotans: tekrar çalıştırma

Bu playbook'un sözleşmesi, hiçbir şey değişmediğinde ikinci çalıştırmanın olaysız (sıkıcı) geçmesiydi ve saha testi bu taahhüdü kesin sayılarla doğruladı. PV'ler zaten var, VG'ler zaten onları içeriyor, LV'ler zaten VG'lerine eşit, dosya sistemleri zaten var, bağlamalar zaten fstab'la eşleşiyor; bu yüzden her görev bir tanesi dışında ok'a iniyor: PV görevi saha testinde yine changed raporladı, çünkü resizefs: true ile community.general'in filesystem modülü her çağrıda pvresize'ı çalıştırıyor ve hiçbir boyut kımıldamasa bile görevi changed işaretliyor. Etki yine idempotent, hiçbir şey büyümüyor ya da yeniden yazılmıyor, ancak recap çıktısındaki gerçekçi beklenti sıfır değil, bir changed görev.

root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/02_storage.yml
TASK [Create/resize physical volumes] ****************************
changed: [vm-test-01] => (item=var01)
changed: [vm-test-01] => (item=log01)
changed: [vm-test-01] => (item=data01)
changed: [vm-test-01] => (item=backup01)   # pvresize geçişi
# diğer her görev: ok

PLAY RECAP ******************************************************
vm-test-01 : ok=14 changed=1 unreachable=0 failed=0

Tek hayatta kalan değişiklik pvresize geçişi: resizefs: true ile modül onu koşulsuz çalıştırıyor ve hiçbir disk büyümese bile changed raporluyor. Gürültü olarak görün; asıl sinyal hiçbir VG, LV, dosya sistemi ya da mount görevinin değişiklik raporlamaması.

Büyütme denemesi: tek düzenleme, sıfır kesinti

Senaryo: /srv/data, aşağıya inmemesi gereken bir sunucuda dolmaya yaklaşıyor. Eski dünyada bu bir bakım penceresi, doğru hipervizör diskini deneme-yanılmayla bulmak ve beş komutluk ritüel demekti. Burada tek bir değişken düzenlemesi, bir apply ve playbook'un bir kez daha çalıştırılması; VM hiçbir şey fark etmiyor.

# ctrl-01'de: data_disk_size_gb 20 -> 30, sonra apply
root@ctrl-01:~/proxmox-automation/terraform# terraform apply
~ resource "proxmox_virtual_environment_vm" "test_vm" {
    ~ disk {
        ~ size = 20 -> 30   # yalnızca scsi3 değişiyor
      }
  }

Plan: 0 to add, 2 to change, 0 to destroy.   # 2. değişiklik: template VM
...
proxmox_virtual_environment_vm.test_vm: Modifications complete after 1s

Apply complete! Resources: 0 added, 2 changed, 0 destroyed.

Apply, VM çalışırken diski API üzerinden büyüttü; guest'teki virtio-scsi katmanı yeni aygıt boyutunu anında aldı. Ama guest içinde henüz hiçbir şey değişmedi: PV hâlâ eski boyutu, LV ve dosya sistemi de onunla birlikte kayıtlı. Disk büyüdü; üstündeki yığın bilmiyor. Playbook'un tekrar çalıştırılması tam olarak bu yüzden gerekiyor.

Saha oturumunda bir denemede playbook apply'dan önce çalıştırıldı, df yine 20G raporladı: playbook yalnızca hipervizörün zaten büyüttüğü boyutu içeriye yansıtabiliyor. Sıra: düzenle, terraform apply, playbook, doğrulama.

root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/02_storage.yml
TASK [Create/resize physical volumes] ****************************
changed: [vm-test-01] => (item=data01)   # pvresize büyümeyi gördü
# (+ diğerlerinde her çalıştırmada olan rutin kontrol)

TASK [Create/extend logical volumes at 100 percent of their VG] ***
changed: [vm-test-01] => (item=vg_data/lv_data)   # lvextend --resizefs

PLAY RECAP ******************************************************
vm-test-01 : ok=14 changed=2 unreachable=0 failed=0

root@ctrl-01:~# ssh ubuntu@192.168.122.50 'df -h /srv/data'
Filesystem                     Size  Used Avail Use% Mounted on
/dev/mapper/vg_data-lv_data    30G  620M   30G   3% /srv/data

İki görev değişti, yalnızca biri büyüme anlamına geliyor: LV görevi tam olarak büyüyen tek disk için değişti: lvol, VG'yi LV'den büyük görünce lvextend'i --resizefs ile çağırdı, bu da dosya sistemi bağlıyken online xfs_growfs'i tetikledi. PV görevi dört diskin hepsinde her çalıştırmadaki alışılmış rutin tetiklemeyi işaretledi. Bu hassasiyet, disk-başına-bir-VG yerleşiminin ödülü: büyüme, serial üzerinden tam olarak doğru yığına yönlendiriliyor, komşusuna hiç dokunmadan. Uptime tüm dizi boyunca hiç değişmedi; disk, bağlı ve kullanımdaki bir XFS dosya sistemi altında 20G'den 30G'ye büyüdü.

Ters yönü denemek de öğretici, çünkü biri er ya da geç bir diski bu yolla küçültmeyi deneyecek. data_disk_size_gb'yi 20'ye geri çekip apply etmek, planı provider'ın kendi sözleriyle duvara çarptırıyor: Cannot shrink, it is not supported. Bu hata bir eksiklik değil, tasarımın kendi işini yapması. Daha küçük bir volume'e giden doğru ve sağlıklı yol; doğru boyutta yeni bir disk, bir veri taşıma ve eskisinin kaldırılmasıdır; yerinde yapılan bir göz boyama değil, kendi prosedürü olan planlı bir göç.

Hızlı başvuru: belirti, neden, çözüm

Belirti	Neden	Çözüm
Plan, VM'in yok edilip yeniden oluşturulacağını gösteriyor	Bir kimlik özniteliği değişmiş (VMID, klon kaynağı), disk boyutu değil	`yes` yazmadan dur, diff'i oku; kimlik özniteliğini geri al, bir boyut düzenlemesi için asla replace'i kabul etme
Apply `VM convert to template failed ... can't convert a template to a template` hatasıyla sonlanıyor	Geride kalmış bir nesne zaten VMID 9000'i tutuyor; provider "already exists" içeren bir create hatasını zaten-tamamlanmış sayıyor	`terraform apply`'ı tekrar çalıştır: refresh geride kalanı temizler ve temiz yeniden kurar; ya da önce node'da `qm destroy 9000` ile elle kaldır
SSH rebuild sonrası `REMOTE HOST IDENTIFICATION HAS CHANGED` uyarısı veriyor	Rebuild edilen VM taze host anahtarları üretti; ctrl-01 eskisini hatırlıyor	`ssh-keygen -f ~/.ssh/known_hosts -R <ip>`, yeniden bağlan, yeni anahtarı kabul et
Assert başarısız: serial 0 diske çözülüyor, lsblk boş serial gösteriyor	Çalışan QEMU konfigürasyondan eski: serial'ler çalışan bir sürece hotplug edilemiyor	`qm config` serial'leri gösteriyorsa, VM'i node'da tam durdur-başlat (`qm shutdown` sonra `qm start`); guest içi reboot QEMU'yu yeniden başlatmaz
Serial'ler lsblk'de görünüyor ama `/dev/disk/by-id`'de serial girdisi yok	Bu Ubuntu 26.04 virtio-scsi guest'i by-id symlink'lerini hiç oluşturmuyor	Düzeltilecek bir şey yok: playbook kernel görüşünü okuyor; by-id ilk sürümün bağımlılığıydı, artık yok
`qm shutdown`, `QEMU Guest Agent is not running` uyarısı veriyor	Klon taze, `01_first_contact.yml` henüz tekrar çalıştırılmadı, agent yok	Önce `01_first_contact.yml`'i çalıştır; kapatma agent olmadan da çalışır, düz bir ACPI kapatmaya düşer
Bir boyut parametresini düzenledikten sonra `df` hâlâ eski boyutu gösteriyor	Playbook, `terraform apply` diski büyütmeden önce çalıştı	Sıra önemli: düzenle, `terraform apply`, sonra playbook; yalnızca hipervizörün zaten büyüttüğü boyutu yansıtır
`lvol` ya da `lvg` modülü bulunamıyor	Collection'lar kontrol düğümüne kurulmamış	`ansible-galaxy collection install -r requirements.yml`
Filesystem modülü `pvcreate`'i arayıp bulamıyor	Cloud imajında lvm2 yok (pre_task atlanmış ya da kaldırılmış)	Playbook'u değiştirmeden tekrar çalıştır; pre_task önce lvm2 ve xfsprogs'u kuruyor
Apply, `Cannot shrink ... not supported` hatası veriyor	Bir boyut parametresi küçültülmüş	Tasarım gereği yalnızca büyümeye izin var; volume gerçekten küçülmeli ise yeni disk oluştur ve taşı

Sırada ne var?

Faz 2 kapanınca, taze sağlanmış bir VM işletim sistemiyle, kimliğiyle, ağıyla ve eksiksiz DB sınıfı bir depolama düzeniyle geliyor; hepsi tek bir apply ve tek bir playbook'tan. Hâlâ eksik olan, orijinal manuel sürecin depolama adımından sonra yavaşlatan her şey: ajanlar. Faz 3, eski template'in /install dizinini gerçek Ansible rollerine çeviriyor, ajan başına bir tane, her biri idempotent ve konfigürasyon güdümlü: sunucu adresi zabbix_agent2.conf'a template'lenmiş Zabbix Agent 2, kontrollü kaynaklardan kurulan Trend Micro ve ManageEngine, QRadar'a işaret eden rsyslog forward kuralları.

Faz 4 sonra son elle dokunma noktasını kaldırıyor: istek formu. Bu rehberde tanıtılan boyutlar zaten sade tfvars parametreleri, yani birer form alanı adayı; bir Semaphore UI pipeline'ı bir form gönderiminden bir workspace tfvars yazabilir, terraform apply'ı ve iki playbook'u çalıştırabilir, dakikalar içinde tamamen kurulmuş bir sunucu teslim edebilir. Faz 5 pipeline'ı ölçek için sertleştiriyor: IP adreslerinin elle atanmayı bırakması için IPAM, paralellik sınırları ve gerçekliğin bildirilen durumdan saptığını fark etmek için drift tespiti.

Kat edilen mesafe kendi paragrafını hak ediyor, çünkü tüm seriyi haklı çıkaran ölçüt bu. Bu serinin yerini aldığı süreç günde yirmi ila doksan kez işletiliyordu: konsol-güdümlü klonlama, elle IP konfigürasyonu, ajan başına bir SSH oturumu, elle düzenlenmiş konfigürasyonlar ve bitirmek için bir reboot; bir DB profili söz konusu olduğunda üstüne bir de depolama işi. İki fazdan sonra aynı sonuç, bir kontrol konteynerinden iki komut, her adımı loglanmış, her hata modu belgelenmiş ve her disk kernel'in onu nerede bulduğuyla değil ne olduğuyla adreslenmiş. Kalan fazlar kalıbın tekrarı, yeni bir fikir değil: durumu bildir, o duruma yakınsa (durumu eşitle), doğrulama çıktısıyla teyit et.

Companion repo, seri boyunca her fazda biraz daha büyüyor:

📌 Link: GitHub repo; fazlarla eşleşen dizin yapısı, playbook'lar ve Terraform dosyaları

Bu fazı kendi lab'ınızda denerseniz, by-id'nin sizin ortamınızda çalışıp çalışmadığını ve rebuild sonrası geride kalan nesneleri kontrol etmeye değer; ikisi de bu yazıdaki komutlarla dakikalar içinde çözülüyor. Deneyimleriniz ve kendi disk desenleriniz için yorumlarda bekliyorum.

Proxmox'da Sıfır Dokunuşla VM Sağlama: Terraform, cloud-init ve Ansible (Bölüm 1)

Hakan İSMAİL — Tue, 01 Sep 2026 06:00:52 +0000

Bir önceki seride Proxmox VE cluster ve Corosync'i kurmuştuk; üç node (pve-a, pve-b, pve-c), bir QDevice, quorum dersleri, split-brain denemesi ve NFS shared storage ile bitirmiştik.

O lab hâlâ ayakta ve bu yeni seri tam olarak o lab'ın üzerine kuruluyor. Cluster kısmı bitti; şimdi asıl konu, o cluster'dan verimli VM üretmek.

Başlangıç noktası hepimizin bildiği o manuel rutin: yeni bir sunucu lazım olur, konsolu açarsın, template'den klonlarsın, IP'yi, maskeyi, ağ geçidini elle yazarsın, her agent kurulumu için ayrı ayrı SSH girersin, bir dosyayı elinle düzenlersin, sonunda reboot atarsın. Günde yirmi kurulumda bu sıkıcı; doksan kurulumda yönetilemez. Bu serinin ilk fazı, o işin en can yakıcı katmanını kaldırıyor: işletim sistemi kurulumunun kendisi. Faz 1'in sonunda elimizde tek komutla çalışan bir pipeline olacak; altın kalıbı (golden template) Terraform kuracak, workload VM'i cloud-init ile klonlayacak ve makineyi Ansible'a devredecek.

Hedef: tek komut, üç kaynak

Faz 1'in tamamı aslında şu cümleye indirgenebilir: terraform apply yazdığımda Proxmox üç kaynak oluşturmalı ve Ansible kalanını halletmeli. Üç kaynak, sırayla şunlar:

Ubuntu 26.04 LTS cloud imajının NFS storage'a indirilmesi
Bu imajdan VMID 9000 numaralı, Terraform tarafından yönetilen altın kalıp
VMID 200 numaralı, statik IP'li, cloud-init'li tam klon (full clone)

Klon ayağa kalkıp ağa girdikten sonra sıra Ansible'a geçiyor; ilk temas (first contact) playbook'u qemu-guest-agent'ı kuruyor ve VM'e "buradan yönetiliyorsun" damgasını basıyor. Sonrası, ileriki fazların konusu: veri diskleri (Faz 2), monitoring ve güvenlik agent'ları (Faz 3), form tabanlı self-servis akış (Faz 4).

Kullanılan araçların doğrulanmış sürümleri şöyle; hepsi yazım anında (Ağustos 2026) upstream kaynaklardan kontrol edildi. Güncelliğini yitirmiş tutorial'lar, lab'da boşa geçen saatlerin bir numaralı sebebi:

Bileşen	Sürüm	Not
Proxmox VE	9.2	8.4 dalı 2026-08-31'te EOL; hard minimum 8.4 (Import içerik türü 8.4'le geldi)
Terraform	1.15.9	1.16 hâlâ release-candidate aşamasında
bpg/proxmox provider	0.111.1	Eski `proxmox_virtual_environment_download_file` adı deprecated
Ubuntu imajı	26.04 LTS (Resolute)	İki varyant: amd64 ve amd64v3 (x86-64-v3 CPU ister)
ansible-core	2.20.1	Ubuntu deposundan; Faz 1 için builtin modüller yeterli

Ön kontrol: dört kapı, on dakika

İlk apply'dan önce dört kapıyı geçmek gerekiyor: cluster sürümü, CPU komut seti, NFS storage ve ağ planı. Cluster serisindeki disiplin burada da geçerli: her iddia, komut çıktısıyla kanıtlanır.

root@pve-a:~# pveversion
pve-manager/9.2.2/b9984c6d90a4bd80 (running kernel: 7.0.2-6-pve)

root@pve-a:~# hostname -I
192.168.122.11

root@pve-a:~# pvesm status
Name        Type    Status  Total(KiB)   Used(KiB)  Available(KiB)  %
local       dir     active  17687844     4986852    11777140        28.19%
local-lvm   lvmthin active  10940416     0          10940416        0.00%
nfs-shared  nfs     active  486256640    197097472  286114816       40.53%

root@pve-a:~# ping -c2 192.168.122.1
PING 192.168.122.1 (192.168.122.1) 56(84) bytes of data.
64 bytes from 192.168.122.1: icmp_seq=1 ttl=64 time=0.312 ms
64 bytes from 192.168.122.1: icmp_seq=2 ttl=64 time=0.298 ms

--- 192.168.122.1 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

hostname -I çıktısındaki adres, https:// öneki ve :8006 portuyla birlikte sonradan pve_endpoint değişkeninin değerini oluşturacak. NFS tarafında 486 GB'lık paylaşımda yer bol; imaj, kalıp ve ilk VM için en az 25 GB gerekiyor. Paket kaybı sıfır olan ping de ağ tarafını kanıtlıyor.

Çoğu tutorial'ın atladığı bir kapı daha var: CPU komut seti. Ubuntu 26.04'ün iki cloud imajı var; baseline amd64 her x86-64 CPU'da çalışır, amd64v3 ise x86-64-v3 mikro mimari seviyesini (AVX2, BMI2, FMA, MOVBE) ister ve modern donanımda belirgin şekilde daha hızlıdır. v3 imajını bu özelliklerden yoksun bir CPU'da açarsanız boot'ta kernel panic alırsınız; fiziksel CPU yeni olsa bile Proxmox'un VM'e gösterdiği sanal CPU tipi eskiyse aynı sonuç çıkar. Benim lab'ım nested-virt olduğu için bu kontrolü fiziksel makinede, yani laptop üzerinde çalıştırdım:

# laptop üzerinde, scripts/check-cpu-v3.sh
OK: CPU exposes all x86-64-v3 features (avx2 bmi2 fma movbe).
You can use the amd64v3 cloud image.

Storage: content type'ların sessiz tuzağı

PVE node'larının yerel diskleri küçük olduğu için her şey NFS'te duruyor: indirilen cloud imajı, altın kalıp, VM diskleri. Proxmox storage'ları hangi içerik türlerini kabul ettiklerini bildirir; yeni oluşturulmuş bir NFS storage genelde sadece disk imajlarını kabul eder. Faz 1 için kritik olan tür Import; bu tür kapalıysa Terraform'un indirme kaynağı HTTP 500 ile ölüyor ve hata mesajı storage ayarına hiç değinmiyor. Snippets de şimdiden açılırsa Faz 4'te custom user-data dosyaları için bu ayara geri dönmek zorunda kalmayız.

Web arayüzünde Datacenter > Storage > nfs-shared > Edit yolunu izleyip Content listesindeki her kutuyu tiklemek yeterli.

CLI'deki karşılığı tek satır; lab günlüğüne yazdığım da bu:

root@pve-a:~# pvesm set nfs-shared -content images,rootdir,vztmpl,snippets,import

Import türü çoğu tutorial'dan yeni olduğu için bir cümlelik açıklamayı hak ediyor. Proxmox'un download-url adında bir API ucu var; bir node bu uç sayesinde dosyayı HTTPS üzerinden doğrudan storage'a çekiyor. bpg provider bu ucu proxmox_download_file kaynağıyla kullanıyor; bu yüzden kontrol düğümünde wget de, qm importdisk da yok. Uç, import içerik türünü bildirmeyen bir storage'a yazmayı reddediyor ve bu ret Terraform tarafına jenerik bir 500 olarak yansıyor.

Terraform için API token'ı

Provider'ın cluster'a erişmesi için üç yol var: kullanıcı adı ve şifre, auth ticket ya da API token'ı. Otomasyon için doğru cevap token: tek tek iptal edilebilir, kendi izin sınırını taşır ve bir insanın şifresini CI değişkenine gömmenize gerek kalmaz. Token'ı üç komutla, idempotent şekilde oluşturuyorum; kullanıcı ve izin nesneleri cluster genelindeki yapılandırma veritabanında tutulduğu için komutu tek bir node'da çalıştırmak yeterli, diğer node'lara kendiliğinden replike oluyor:

root@pve-a:~# pveum user add terraform@pve --comment "Terraform automation"
root@pve-a:~# pveum acl modify / --users terraform@pve --roles Administrator
root@pve-a:~# pveum user token add terraform@pve provider --privsep 0

┌────────────┬──────────────────────┬────────┬─────────┐
│ token-name │ value                │ expire │ privsep │
├────────────┼──────────────────────┼────────┼─────────┤
│ provider   │ 1a2b3c4d-...         │ never  │       1 │
└────────────┴──────────────────────┴────────┴─────────┘

Web arayüzünde Datacenter > Users > add yolunu izleyip yeni kullanıcı eklenebilir. Önemli olan kısım, Linux PAM standard authentication yerine Proxmox VE authentication server seçilmesi:

Ardından Web arayüzünde Datacenter > API Tokens > add yolunu izleyip yeni bir token eklenir:

Token değeri, tam token kimliği ile UUID'nin eşittirle birleşimi: terraform@pve!provider=1a2b3c4d-.... Kopyalarken dizgenin başına ya da sonuna karışan boşluklar, yeni üretilmiş bir token'ın reddedilmesinin en yaygın sebebi; o yüzden tamını tamına alın, ne eksiği ne fazlası. Açık konuşmak gerekirse: Administrator rolü ve privsep 0 bir lab kısayolu. Production'da custom bir role geçilip minimum yetkiyle yetinilmeli (indirme kaynağı için Sys.Audit, Sys.Modify, Datastore.AllocateTemplate; VM kurulumu için VM.Allocate, VM.Clone ve benzerleri) ve privsep 1 yapılmalı. Bu, serinin sonundaki hardening maddelerinden biri.

Kontrol düğümü: küçük bir LXC

Terraform ve Ansible'ın çalışacağı kontrol düğümü, NFS üzerinde küçük bir LXC konteyneri: ctrl-01. Konteyner olması bilinçli bir tercih; saniyeler içinde açılıyor, boştayken kabaca 100 MB RAM yiyor ve root filesystem'i zaten Faz 1'de açtığımız rootdir içerik türünün kapsamına giriyor. Faz 1'de kernel düzeyinde yetki gerektiren hiçbir şey yok, o yüzden unprivileged konteyner sorunsuz.

Önce Ubuntu LXC template'ini NFS'e indirip konteyneri oluşturuyorum:

root@pve-a:~# pveam available --section system | grep ubuntu
root@pve-a:~# pveam download nfs-shared ubuntu-26.04-standard_26.04-1_amd64.tar.zst
downloading ubuntu-26.04-standard_26.04-1_amd64.tar.zst from
download finished

root@pve-a:~# pct create 900 nfs-shared:vztmpl/ubuntu-26.04-standard_26.04-1_amd64.tar.zst \
  --hostname ctrl-01 --memory 2048 --cores 2 --rootfs nfs-shared:8 \
  --net0 name=eth0,bridge=vmbr0,ip=192.168.122.10/24,gw=192.168.122.1 \
  --unprivileged 1 --features nesting=1 --start 1

root@pve-a:~# pct list
VMID Status    Lock Name
900  running       ctrl-01

Template'in tam sürüm dizgesi zamanla değişir; önemli olan üç şey: template'in NFS'e indirilmesi (böylece migration sonrası her node konteyneri başlatabilir), konteynere gelecekteki VM'lerle aynı ağdan statik adres verilmesi ve ağ tarafının aynı vmbr0 köprüsüne takılması. 2 GB RAM, Terraform state işlemlerine rahat rahat yetiyor.

İlk giriş: konsolda şifre yok

Konteyner ayağa kalktı, noVNC konsolunu açtım, root yazdım ve şunu aldım:

Login incorrect

Ubuntu LXC template'inde root hesabı kilitli geliyor ve hiçbir varsayılan şifresi yok; template, yapılandırmanın konsoldan değil host'tan yapılacağını varsayıyor. Kapının kendisi pct enter; kimlik doğrulaması olmadan, kernel namespace'i üzerinden konteynerin içine root shell açıyor:

root@pve-a:~# pct enter 900
root@ctrl-01:~#

Konsoldan tty1'e doğrudan girmek isterseniz içeride passwd root çalıştırmak yeterli. Node tarafından tek satırlık, etkileşimsiz alternatif de var:

root@pve-a:~# pct exec 900 -- bash -c 'echo "root:changeme" | chpasswd'

Bu yazıda "ctrl-01 içinde" etiketli komutların tamamı bu kapıdan girilerek çalıştırıldı.

Aynı shell'e web arayüzünden de girilebilir:

Minimal konteynerde gpg yok

Terraform'u HashiCorp deposundan kurmak istedim; çünkü Ubuntu'nun kendi deposundaki sürüm geride kalıyor. Elinizdeki tutorial'ların hepsi şöyle bir blok gösterir: anahtarı indir, gpg --dearmor'dan geçir, keyring'e yaz. Ben de öyle yaptım ve şunu aldım:

sudo: 'gpg': command not found

Bu sadece ilk halka. Minimal Ubuntu LXC template'inde gnupg yok, o yüzden dearmor adımı keyring'e hiçbir şey yazmıyor ve apt-get update bir sonraki adımda HashiCorp deposunu imzasız reddediyor:

NO_PUBKEY AA16FCBCA621E701

çünkü signed-by referansı, hiç var olmamış bir .gpg dosyasına bakıyor. Çözüm, gpg'yi tamamen atlamak: HashiCorp'ın sunduğu anahtar ASCII-armored ve modern apt (2.4 ve üzeri; Ubuntu 26.04'te apt 3.x var) armored anahtarları .asc uzantısıyla doğrudan okuyor:

root@ctrl-01:~# wget -qO /usr/share/keyrings/hashicorp.asc \
  https://apt.releases.hashicorp.com/gpg
root@ctrl-01:~# echo "deb [signed-by=/usr/share/keyrings/hashicorp.asc] \
  https://apt.releases.hashicorp.com $(lsb_release -cs) main" \
  > /etc/apt/sources.list.d/hashicorp.list
root@ctrl-01:~# apt-get update && apt-get install -y terraform
root@ctrl-01:~# apt-get install -y ansible

Ayrıca doğruladım: Ubuntu 26.04'ün kod adı resolute ve HashiCorp mirror'ında kendi dağıtımı var; lsb_release -cs hiçbir özel işlem gerektirmiyor.

Üretilmemiş locale

Terraform kuruldu, sıra Ansible'da. ansible --version ise version banner'ı yerine bunu bastı:

ERROR: Ansible could not initialize the preferred locale: unsupported locale setting

Ubuntu template'i LANG=en_US.UTF-8 set ediyor ama o locale'i hiç üretmiyor; aynı eksiklik, paket kurulumları sırasında perl'den gelen uyarıların da sebebiydi. Ansible, perl kadar hoşgörülü değil; başlamayı tamamen reddediyor. Locale'i bir kez üretmek ikisini de tek hamlede çözüyor ve update-locale bu ayarı /etc/default/locale'a taşıdığı için reboot sonrası da kalıcı:

root@ctrl-01:~# apt-get install -y locales
root@ctrl-01:~# locale-gen en_US.UTF-8
root@ctrl-01:~# update-locale LANG=en_US.UTF-8

Araç kapıları da artık kanıtla kapandı; her iki banner'ı da gerçek çalıştırmadaki haliyle buraya bırakıyorum:

root@ctrl-01:~# terraform -version
Terraform v1.15.9
on linux_amd64

root@ctrl-01:~# ansible --version
ansible-core 2.20.1
  config file = /etc/ansible/ansible.cfg
  executable location = /usr/bin/ansible
  python version = 3.13.2 (/usr/bin/python3)
  jinja version = 3.1.6
  libyaml = True

Bir küçük sürüm gerçeğini de buraya not edeyim: araştırmam sırasında "Ansible core 2.21" yazmıştım ama Ubuntu deposu ansible-core 2.20.1 + ansible 13.1.0 meta paketini veriyor. Plan 2.21'di, saha 2.20.1'di; saha kazanır.

SSH anahtarı ve repo'nun üç aktarmalı yolculuğu

Kontrol düğümü, kurduğu her VM'e anahtar enjekte edecek; önce o anahtar çifti:

root@ctrl-01:~# ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519 -N ""
Generating public/private ed25519 key pair.
Your identification has been saved in /root/.ssh/id_ed25519
Your public key has been saved in /root/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:1Zc5k... root@ctrl-01

cat ~/.ssh/id_ed25519.pub ile okunan satır, Terraform tarafında her klonlanan VM'e cloud-init user_account bloğuyla enjekte edilecek olan dizgi. Aynı anahtar malzemesini üç yerde görmek (kontrol düğümü, hypervisor'da qm cloudinit çıktısı, guest içinde authorized_keys), Faz 1'in en hızlı uçtan uca sağlaması.

Repo zip'i laptop'ta duruyor. Konteynere taşımak üç aktarmada tamamlanıyor ve her aktarma, o ayağın elinde zaten olan yolu kullanıyor:

# laptop üzerinde: cluster'a (laptop aynı zamanda lab'ın NAT ağ geçidi, 192.168.122.1)
laptop$ scp ~/Downloads/proxmox-automation.zip root@192.168.122.11:/root/
proxmox-automation.zip  100%  452KB   9.1MB/s   00:00

# pve-a üzerinde: dosyayı konteynerin filesystem'ine doğrudan yaz; SSH'a gerek yok
root@pve-a:~# pct push 900 /root/proxmox-automation.zip /root/proxmox-automation.zip

# ctrl-01 içinde
root@ctrl-01:~# apt-get install -y unzip
root@ctrl-01:~# unzip ~/proxmox-automation.zip -d ~/
root@ctrl-01:~# ls ~/proxmox-automation
ansible  docs  README.md  scripts  terraform

Laptop'tan konteynere doğrudan scp neden çalışmaz? Çünkü yeni kurulmuş Ubuntu konteynerinde kilitli bir root var, şifre yok, authorized_keys yok; SSH'ın doğrulayacağı hiçbir şey yok. pct push bu engeli tasarım gereği bypass ediyor, dosyayı konteyner filesystem'ine node üzerinden yazıyor. Her aktarmanın başarı işareti farklı: scp ilerleme satırı basıp sessizce çıkıyor, pct push hiçbir şey basmıyor (Proxmox'un "başarı sessizdir" geleneği) ve ls nihai makbuz. Bu zincir, repo bir git remote'a taşındığı anda tek bir git clone'a indirgeniyor; o zaman bu bölümün tamamı tarih oluyor.

Terraform tarafı: kritik kararlar

Repo'daki Terraform konfigürasyonunun tamamına girmeyeceğim; sadece beklenmedik bir davranışla karşılaştığınızda açıklaması elinizin altında olsun diye kritik kararları ve iki dosyanın can alıcı kısımlarını buraya bırakıyorum.

İlki, imaj indirme ve altın kalıp:

resource "proxmox_download_file" "ubuntu_image" {
  content_type        = "import"     # PVE 8.4+ ve storage'da Import açık olmalı
  datastore_id        = var.storage_id
  node_name           = var.template_node
  url                 = var.cloud_image_url
  file_name           = "ubuntu-2604-cloudimg.qcow2"
  upload_timeout      = 3600         # provider varsayılanı 600 s, dar geliyor
  overwrite_unmanaged = true
}

resource "proxmox_virtual_environment_vm" "ubuntu_template" {
  name          = var.template_name
  node_name     = var.template_node
  vm_id         = var.template_vmid  # sabit 9000
  template      = true
  agent { enabled = true }
  cpu {
    cores = 2
    type  = var.cpu_type  # x86-64-v3, aşağıda hikayesi var
  }
  scsi_hardware = "virtio-scsi-pci"
  disk {
    datastore_id = var.storage_id
    import_from  = proxmox_download_file.ubuntu_image.id
    interface    = "scsi0"
    size         = var.template_disk_size_gb
  }
  serial_device {}
  vga { type = "serial0" }
  boot_order = ["scsi0"]
}

Buradaki en önemli satır import_from. file_id kullanırsanız provider sessizce PVE node'una SSH açıp qm disk import çalıştırıyor; API token'ıyla giden yolda ise SSH yok ve apply template adımında düşüyor. import_from ise PVE'nin yerel import-from= disk seçeneğini API üzerinden kullanıyor; kimse hiçbir node'a SSH yapmıyor. İkinci kritik karar: template'te initialization bloğu olmamalı; cloud-init ayarları klonun işidir, öyle ki tek kalıp, birbirinden tamamen farklı ağ kimlikleriyle workload'lara hizmet verebilsin. Kalıp bir kalıp, makine değil.

İkinci dosya, workload klonu:

resource "proxmox_virtual_environment_vm" "test_vm" {
  name      = var.vm_name
  node_name = var.vm_node
  vm_id     = var.workload_vmid  # sabit 200

  clone {
    vm_id   = proxmox_virtual_environment_vm.ubuntu_template.vm_id
    full    = true
    retries = 3
  }

  agent {
    enabled = true
    wait_for_ip { disabled = true }  # bu satırın 15 dakikalık hikayesi aşağıda
  }

  disk {  # klonun root diskini büyütür
    datastore_id = var.storage_id
    interface    = "scsi0"
    size         = var.vm_disk_size_gb
  }

  initialization {
    datastore_id = var.storage_id
    dns {
      domain   = var.search_domain
      servers  = var.dns_servers
    }
    ip_config {
      ipv4 {
        address = "${var.vm_ip_address}/${var.vm_ip_cidr}"
        gateway = var.vm_ip_gateway
      }
    }
    user_account {
      keys     = [trimspace(file(pathexpand(var.ssh_public_key_path)))]
      username = var.vm_username
    }
  }
}

Kararların gerekçeleri, kısaca:

Karar	Gerekçe
`proxmox_download_file` (yeni ad)	`proxmox_virtual_environment_download_file` deprecated; v1.0'da kalkacak
`scsi_hardware = virtio-scsi-pci`	Ubuntu cloud imajlarının istediği kontrolcü; online disk resize'ı yalnızca bu destekliyor, Faz 2 bunun üzerine kurulu
CPU tipi `x86-64-v3`	PVE varsayılanı `x86-64-v2-Auto` AVX2 taşımıyor; amd64v3 guest boot'ta kernel panic yiyor
Seri konsol (`serial_device` + `vga serial0`)	Cloud imaj konvansiyonu; standart VGA'da noVNC'de görülen boş ekran belirtisini önler
Full clone	NFS üzerinde bağımsız diskler; production DB sunucusu pratiğinin aynısı
Guest agent cloud-init yerine Ansible'dan	user-data sade kalıyor, paket yapılandırması yönetim altına giriyor; Faz 3'te drift tespiti de yanında geliyor

init, validate ve plan: iki schema hatası üst üste

Değişkenleri doldurup (pve_endpoint, token, storage_id = nfs-shared, VM adı ve IP'si) provider'ı çekiyorum:

root@ctrl-01:~# terraform init
Initializing the backend...
Initializing provider plugins...
- Finding bpg/proxmox versions matching "~> 0.111.1"...
- Installing bpg/proxmox v0.111.1...
- Installed bpg/proxmox v0.111.1 (signed, key ID F0582AD6AE97C188)

Terraform has been successfully initialized!

vlan_tag artık yok

İlk terraform plan tam da burada, schema hatasıyla düştü:

╷
│ Error: Unsupported argument
│
│   on template.tf line 65, in resource "proxmox_virtual_environment_vm" "ubuntu_template":
│   65:     vlan_tag = var.vlan_tag
│
│ An argument named "vlan_tag" is not expected here.
╵

Provider 0.111 hattında network_device.vlan_tag özniteliğini vlan_id olarak yeniden adlandırmış. Eski tutorial'lar vlan_tag kullanıyor. Düzeltme tek satır; değişken adını koruyup değeri vlan_id'ye bağlıyorum, böylece tfvars dosyası değişmiyor

Bu arada, VLAN-aware köprülerdeki trunk özelliği ayrı bir öznitelik (trunks = "10;20;30"); vlan_id ile karıştırmamak gerek.

hostname kalkmış, CPU tipinde -Auto yok

Plan bu kez başka iki hatayla düştü. İlki initialization.hostname özniteliği; provider 0.111'de kaldırılmış. cloud-init hostname'i artık VM'in adından geliyor, o yüzden VM adı geçerli bir DNS ismi olmalı:

│ Error: Unsupported argument
│
│   on vm.tf line 90, in resource "proxmox_virtual_environment_vm" "test_vm":
│   90:     hostname = var.vm_name
│
│ An argument named "hostname" is not expected here.
╵

İkincisi daha gizliydi: x86-64-v3-Auto diye bir CPU tipi provider validator'ının listesinde yok. PVE arayüzünde gördüğünüz -Auto varyantları, provider tarafında geçersiz:

│ Error: expected cpu.0.type to be one of [x86-64-v2 x86-64-v3 ... host ...],
│ got x86-64-v3-Auto

Çözüm: hostname satırını silmek ve cpu_type'ı düz x86-64-v3 yapmak. Buradan çıkan ders, terraform validate'ı alışkanlık haline getirmek oldu; init ile plan arasına sıkışan bu tek komut, tüm öznitelik ve blokları gerçek provider şemasına karşı, cluster'a tek istek atmadan kontrol ediyor. İki schema hatasının ikisini de, kimlik bilgilerine hiç dokunmadan, birer saniyenin altında yakalayabilirdi.

root@ctrl-01:~# terraform validate
Success! The configuration is valid.

Ve nihayet sağlıklı bir plan:

Plan: 3 to add, 0 to change, 0 to destroy.

Changes to Outputs:
  + ssh_command    = "ssh ubuntu@192.168.122.50"
  + template_vm_id = 9000
  + test_vm_id     = 200
  + test_vm_ip     = "192.168.122.50"
  + test_vm_name   = "vm-test-01"

İlk çalıştırmada üç ekleme, sıfır değişiklik, sıfır silme; olması gereken tablo bu. Outputs bloğu da anahtarların devrini gösteriyor.

İlk apply: 4 dakika 25 saniye, 11 saniye, 15 dakika 5 saniye

Konfigürasyon düzeltmeleri sonrası apply. Süreler ölçüldü; işte gerçek değerler:

proxmox_download_file.ubuntu_image: Creating...
proxmox_download_file.ubuntu_image: Still creating... [4m25s elapsed]
proxmox_download_file.ubuntu_image: Creation complete after 4m25s
proxmox_virtual_environment_vm.ubuntu_template: Creating...
proxmox_virtual_environment_vm.ubuntu_template: Creation complete after 11s
proxmox_virtual_environment_vm.test_vm: Creating...
proxmox_virtual_environment_vm.test_vm: Still creating... [15m00s elapsed]
proxmox_virtual_environment_vm.test_vm: Creation complete after 15m5s

Apply complete! Resources: 3 added, 0 changed, 0 destroyed.

Outputs:

ssh_command = "ssh ubuntu@192.168.122.50"
template_vm_id = 9000
test_vm_id = 200
test_vm_ip = "192.168.122.50"
test_vm_name = "vm-test-01"

Süreyi belirleyen indirme (4,5 dakika) ve saniyeler içinde ayaklanan kalıp (11 saniye) normal; VM'e bağlanan 15 dakikalık kısım ise asıl sorun işareti.

Hata olmayan on beş dakikalık uyarı

Apply'ın kuyruğunda şu uyarı vardı:

╷
│ Warning: error waiting for network interfaces from QEMU agent
│
│ with proxmox_virtual_environment_vm.test_vm,
│ on vm.tf line 7, in resource "proxmox_virtual_environment_vm" "test_vm":
│ 7: resource "proxmox_virtual_environment_vm" "test_vm" {
│
│ timeout while waiting for the QEMU agent on VM "200" to publish the
│ network interfaces
╵

15 dakika 5 saniyelik sürenin kendisi ipucu. Klon saniyeler içinde bitti, VM neredeyse anında açıldı; beklemin tamamı, provider'ın guest agent'ı yoklamasından ibaretti. Mekanizmayı sonradan provider'ın kaynak kodundan doğruladım: VM konfigürasyonunda agent açık olduğu sürece provider, VM'i başlattıktan sonra ve sonraki her plan/apply yenilemesinde agent'a ağ arayüzlerini soruyor ve "henüz IP yok" cevabını agent.timeout (varsayılan 15 dakika) bitene kadar tekrarlıyor. Ubuntu cloud imajları qemu-guest-agent ile gelmiyor; o yüzden her yoklama boşa çıkıyor, 15 dakika dolunca provider bir Warning ile pes ediyor. Warning, Error değil: VM çalışıyor, state temiz, tek kayıp state'te ipv4_addresses'ın boş kalması; statik IP tasarımında zaten ihtiyacım yok.

Üç makul tepki var; repoya işlenen, birincisi:

agent { wait_for_ip { disabled = true } } ile sorguyu tamamen atlamak; statik IP'li bu pipeline için doğru varsayılan.
agent.timeout'ı kısaltmak (örneğin 2m); bekleme küçülür ama kalkmaz. Agent tabanlı IP keşfini ileride isterseniz makul orta yol.
Hiçbir şey yapmamak; guest agent kurulunca yoklamalar saniyeler içinde başarıya döner ve uyarı kendiliğinden kaybolur.

Asla doğru olmayan dördüncü yol ise apply'ı Ctrl-C ile kesmek; oluşturulması yarıda kesilen kaynak tainted olur ve arkasında yarım kalmış bir temizlik bırakır. Ben kesmedim, bekledim; 15 dakikanın bedeli bu yazı oldu.

Düzeltmeyi uygulayıp tekrar plan çektiğimde fark tek bir bloğa iniyordu (agent), apply "0 to add, 2 changed" ile bir saniyede tamamlandı ve sonraki tüm yenilemeler saniye sürdü. Yani wait_for_ip satırı, bu yazıyı okuyan herkesin konfigürasyonuna eklemesi gereken tek satırlık sigorta.

Doğrulama: üç bağımsız katman hemfikir olana kadar

Terraform "tamam" dedikten sonra güven meselesi başlıyor. Hipervizör, guest ve ağ katmanlarının üçü de aynı şeyi söyleyene kadar hiçbir şeye inanmıyorum.

Hipervizör tarafı:

root@pve-a:~# qm list
VMID  Name             Status   MEM(MB)  BOOTDISK(GB)  PID
9000  ubuntu-2604-tpl  stopped  2048     10.00         0
200   vm-test-01       running  2048     10.00         318234

root@pve-a:~# qm config 200 | grep -E "scsi0|net0|agent|serial"
agent: enabled=1
net0: virtio=BC:24:11:2E:AA:F7,bridge=vmbr0
scsi0: nfs-shared:vm-200-disk-0,size=10G
serial0: socket
vga: serial0

root@ctrl-01:~# terraform state list
proxmox_download_file.ubuntu_image
proxmox_virtual_environment_vm.ubuntu_template
proxmox_virtual_environment_vm.test_vm

Kalıbın stopped ve PID 0 görünmesi tam olması gerektiği gibi; bir kalıbın çalışıyor görünmesi, birilerinin yanlışlıkla kalıbı başlattığı anlamına gelir ve asla olmamalıdır. qm config çıktısı ise altıncı bölümdeki dört donanım kararını tek bakışta doğruluyor: agent açık, virtio ağ, NFS'te root diski, seri konsol çifti.

Guest ve ağ tarafı:

root@ctrl-01:~# ssh ubuntu@192.168.122.50
The authenticity of host '192.168.122.50' can't be established.
ED25519 key fingerprint is SHA256:dG9w...DzKw.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Welcome to Ubuntu 26.04 LTS (Resolute) (GNU/Linux 6.17.0-25-generic...)

ubuntu@vm-test-01:~$ cloud-init status --wait
status: done

ubuntu@vm-test-01:~$ grep Datasource /var/log/cloud-init-output.log
Cloud-init v. 25.1 finished at ... Datasource DataSourceNoCloud
seeddev=/dev/sr0. Up 14.32 seconds

Prompt'taki vm-test-01, kaldırılan initialization.hostname özniteliğine rağmen hostname'in cloud-init tarafından VM adından alındığının kanıtı. status: done ve DataSourceNoCloud seeddev=/dev/sr0 ise tohum (seed) diskının bulunduğunun ve ilk boot'ta tamamen tüketildiğinin makbuzu. Bu ikisi olmadan, VM göründüğü gibi çalışsa bile cloud-init payload'ı hiç almamış olabilir; belirtisi de şu olur: statik adres yerine imajın DHCP kimliğiyle ağa çıkar. Bir not: VM'i destroy/apply döngüsüne sokarsanız yeni makine yeni host anahtarıyla gelir; yeniden bağlanmadan önce ssh-keygen -R 192.168.122.50 şart. Bunu sonradan, Faz 2 rebuild'i sırasında öğrendim.

Ansible ilk temas: pipeline'ın kapanışı

Terraform, açılmış ve ağa bağlanmış bir VM'e kadar götürüyor. İşletim sisteminin içindeki her şey artık Ansible'ın sahası ve Faz 3'te bu ilk playbook'un üzerine tüm agent yığını (Zabbix Agent 2, Trend Micro, ManageEngine, QRadar'a rsyslog forward'u) gelecek. Faz 1 playbook'u bilinçli olarak minik; görevi yönetim kanalını kanıtlamak ve hypervisor'ın tek umursadığı paketi, qemu-guest-agent'ı kurmak.

Envanter tek VM'lik:

all:
  children:
    provisioned:
      hosts:
        vm-test-01:
          ansible_host: 192.168.122.50
          ansible_user: ubuntu

root@ctrl-01:~/proxmox-automation/ansible# ansible provisioned -m ping
vm-test-01 | SUCCESS => {
    "ansible_facts": { "discovered_interpreter_python": "/usr/bin/python3" },
    "changed": false,
    "ping": "pong"
}

Playbook dört görevden ibaret: kimlik göster, agent'ı kur, servisi başlat, /etc/provisioned-by damgasını yaz. (Playbook'un tamamı repoda; burada çalıştırmanın çıktısı daha değerli.)

root@ctrl-01:~# ansible-playbook playbooks/01_first_contact.yml

PLAY [First contact - verify a freshly provisioned VM] ***********

TASK [Gathering Facts] ******************************************
ok: [vm-test-01]

TASK [Show system identity] *************************************
ok: [vm-test-01] => {
    "msg": "vm-test-01 is up, Ubuntu 26.04"
}

TASK [Install QEMU guest agent] *********************************
changed: [vm-test-01]

TASK [Enable and start the guest agent] *************************
ok: [vm-test-01]

TASK [Mark the VM as managed by this pipeline] ******************
changed: [vm-test-01]

PLAY RECAP *******************************************************
vm-test-01 : ok=5 changed=2 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

ok=5 changed=2 ilk bakışta yanlış görünür; aritmetiği şöyle: ok sayacı changed olan görevleri de içerir. Beş görevin beş sonucu var; üçü normalde changed raporlardı ama service görevi fresh VM'de ok rapor etti, çünkü paketin postinst'i, apt görevinin hemen ardından agent'ı zaten başlatıp enable etmişti. İki changed; paket kurulumu ve damga dosyası. Bir dakika sonra ikinci çalıştırma, idempotans makbuzu:

vm-test-01 : ok=5 changed=0 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

changed'in sıfıra düşmesi bu playbook'u tek seferlik kurulumdan güvenli, tekrar çalıştırılabilir bir operasyona çevirir; Faz 3'te aynı örüntü her provision edilmiş VM'e karşı çalışacak ve sıfırın üstündeki changed, rutin bir yan etki değil, incelenmeye değer bir drift sinyali olacak.

Facts enjeksiyonu 2.24'te kalkıyor

İlk çalıştırmada iki görevden şu uyarı düştü:

[DEPRECATION WARNING]: The INJECT_FACTS_AS_VARS setting is scheduled to be
removed in version 2.24. ...

Playbook, ansible_distribution tarzı çıplak fact değişkenleri kullanıyordu. ansible-core 2.20 otomatik fact enjeksiyonunu deprecate etmiş; 2.24'te tamamen kalkıyor. Düzeltme, parantez sözdizimine geçmek:

# eski:
msg: "{{ inventory_hostname }} is up, {{ ansible_distribution }} {{ ansible_distribution_version }}"
# yeni:
msg: "{{ inventory_hostname }} is up, {{ ansible_facts['distribution'] }} {{ ansible_facts['distribution_version'] }}"

2.24 çıktığında bu uyarı, kırılan playbook'ların başındaki hata mesajına dönüşecek; düzeltmesi de gösterildiği kadar küçük.

Agent kurulduktan sonra hypervisor tarafındaki son kapı da sessizce açılıyor:

root@pve-a:~# qm guest cmd 200 ping
root@pve-a:~# echo $?
0

qm guest cmd ping başarılı olunca hiçbir şey basmaz; sessizlik ve sıfır çıkış kodu, testin geçtiğinin işareti. Bu tek satır, 15 dakikalık uyarıyla başlayan döngüyü kapatıyor: agent artık var, yoklamalar saniyeler içinde cevap buluyor ve Proxmox arayüzü VM'in IP adresini kendisi gösteriyor.

Lab aniden dondu

Faz 1'i kapatırken bir de gizemli olay yaşadım; kaydetmemek olmaz. Oturum ortasında pve-a'ya açık SSH bağlantım aniden Connection reset by peer ile gitti. Yeniden girdiğimde CT 900 önce not running gösterdi, saniyeler sonra yeniden running oldu; VM 200 ise durmuştu ve sonraki plan started: false -> true değişikliği gösterdi. Ansible, guest'in uptime'ını 2.2 dakika raporladı; yani makine kısa süre önce yeniden başlamıştı. Üç belirti de aynı anda bir pve-a reboot'una işaret ediyordu ama hiçbir crash kanıtı yoktu.

Cevap, utanılacak kadar basitti: laptop öğle yemeğinde uykuya girmiş. Bu lab nested-virt; pve-a ve arkadaşları o laptop'un libvirt guest'leri. Host uykuya girince tüm lab bir anda askıya alınıyor; SSH kopuyor, konteyner duruyor, VM kapanıyor. Hiçbir şey çökmedi; onboot=1 ayarları her şeyi kendisi toparladı. Son ders donanımda değil, lab tasarımında: nested-virt lab'ın tek bir fiziksel host'u var ve onun güç yönetimi, cluster'ın beşinci düğümüdür. Lab saatlerinde host'un otomatik uykuya dalmasını kapatmak ve bunu uptime ile journalctl --list-boots üzerinden doğrulamak yeterli.

Hızlı başvuru: belirti, neden, çözüm

Yazı boyunca geçen belirti ve çözümler, hepsini baştan okumak istemeyenler için tek tabloda:

Belirti	Neden	Çözüm
Konsolda `Login incorrect`	Ubuntu LXC template'i şifresiz ve root kilitli	`pct enter 900`, gerekiyorsa `passwd`
`gpg: command not found` + `NO_PUBKEY`	Minimal template'te gnupg yok; keyring hiç yazılmadı	Anahtarı `.asc` olarak sakla; gpg'ye hiç ihtiyaç yok
`Ansible could not initialize the preferred locale`	`LANG` set edilmiş ama locale üretilmemiş	`locale-gen en_US.UTF-8` + `update-locale`
Plan: `vlan_tag is not expected here`	Provider 0.111 özniteliği `vlan_id` yaptı	`network_device` içinde `vlan_id = N`
Plan: `hostname` yok + `x86-64-v3-Auto` geçersiz	`initialization.hostname` kaldırıldı; `-Auto` CPU tipleri validatörde yok	hostname satırını sil (VM adı DNS ismi), `cpu_type = x86-64-v3`
VM 15 dk `Still creating` + Warning	Agent açık ama imajda qemu-guest-agent yok; `agent.timeout` 15m	`wait_for_ip { disabled = true }`; asla Ctrl-C değil
`INJECT_FACTS_AS_VARS` deprecation uyarısı	ansible-core 2.24'te çıplak fact değişkenleri kalkıyor	`ansible_facts['...']` parantez sözdizimi
SSH reset, CT durdu, VM kapandı; kanıt yok	Laptop uykusu; nested-virt lab'ın tamamı host'a bağlı	Lab saatlerinde host uykusunu kapat; `journalctl --list-boots`

Sırada ne var?

Faz 1 tek diskli bir VM üretiyor; web sunucusu ve jump host için yeterli, veritabanı sunucusu için değil. Faz 2'nin konusu çoklu disk örüntüsü: /var, /log, /data ve /backup için ayrı SCSI cihazlar, her diske Terraform serial özniteliğiyle kalıcı kimlik ve konuk içinde LVM + XFS zinciri. Buraya çekilen temeller tam olarak Faz 2'nin ihtiyacı olanlar; virtio-scsi-pci kontrolcüsü online disk resize'ı destekleyen tek kontrolcü ve serial etiketi, /dev/sdb harflerinin konuk içinde kayması problemine kökten çözüm. Müşteri bir terabayt ek data isterse cevap bir satırlık değişken düzenlemesi ve bir re-apply olacak.

Companion repo, seri boyunca her fazda biraz daha büyüyor:

📌 Link: GitHub repo; fazlarla eşleşen dizin yapısı, playbook'lar ve Terraform dosyaları

Bu fazı siz de kendi lab'ınızda denerseniz, 15 dakikalık uyarı sizin de karşınıza çıkacaktır; çözümü, yazının yukarısındaki o tek satırlık sigorta. Sorularınız, düzeltmeleriniz ve kendi karşılaştığınız tuzaklar için yorumlarda bekliyorum.

# Redundant Links, İzleme Araçları ve Bir Affinity Kilitlenmesi (Modül 5)

Hakan İSMAİL — Wed, 26 Aug 2026 06:32:30 +0000

Seri: Proxmox VE Cluster ve Corosync | Hafta 5

Serinin adı "Cluster ve Corosync"; ama dört modüldür ağırlık HA Manager, resource affinity ve CRS'teydi, Corosync'in kendisine (redundant link'ler, izleme araçları) hiç dönmemiştim. Bu modülde iki konuyu birleştirip derinlemesine işledim: birden fazla corosync link'i tanımlayıp gerçekten birini kesip diğerinin devralmasını kanıtlamak, ve günlük operasyonda kullanılacak izleme araçlarını tek tek denemek. İkisi de planladığımdan çok daha fazla soru açtı; biri yanlış bir config anahtarı yüzünden saatler süren bir araştırmaya dönüştü, diğeri ise hiç beklemediğim bir kilitlenme keşfiyle bitti.

Bölüm 1: Redundant Corosync Links

Kurulum: İkinci Link'i Eklemek

Şu ana kadar cluster'ımızda tek bir corosync link'i vardı (link1, izole corosync-net ağı). Management ağını (192.168.122.x) link0 olarak ekleyip gerçek bir yedeklilik kurdum; /etc/pve/corosync.conf'u kopyalayıp düzenleyip atomik olarak yerine taşıdım:

cp /etc/pve/corosync.conf /etc/pve/corosync.conf.new
# nodelist'teki her node'a ring0_addr ekledim, totem'e ikinci bir interface bloğu ekledim
mv /etc/pve/corosync.conf.new /etc/pve/corosync.conf

Doğrulama:

corosync-cfgtool -s

LINK ID 0 udp
    addr    = 192.168.122.11
    status: ... connected ... connected
LINK ID 1 udp
    addr    = 10.10.10.11
    status: ... connected ... connected

Teknik olarak başarılı; iki link de bağlı. Ama log'a dikkatlice bakınca, mimarimizin niyetini tersine çeviren bir şey oldu:

[KNET  ] rx: host: 3 link: 0 is up
[KNET  ] host: host: 3 (passive) best link: 0 (pri: 1)

link_mode: passive modunda, öncelik eşitken düşük numaralı link kazanıyor. link0'ı sonradan eklediğim için, o Corosync'in asıl trafiğini üstlenmiş; Modül 0'da özellikle izole ettiğimiz corosync-net (link1) sessizce yedek konuma düşmüştü.

Yanlış Anahtar, Saatler Süren Bir Araştırma

Bunu düzeltmek için link1'e daha yüksek öncelik vermeye çalıştım:

interface {
  linknumber: 0
  priority: 5
}
interface {
  linknumber: 1
  priority: 10
}

İşe yaramadı. corosync-cmapctl | grep priority sadece tek, indekslenmemiş bir satır gösterdi: totem.interface.priority (str) = 10. Diğer parametreler (knet_ping_interval, knet_ping_timeout) düzgün şekilde interface.0.* / interface.1.* diye ayrılmışken, priority öyle değildi. Log'da "best link" seçimi hâlâ (pri: 1) gösteriyordu; bizim verdiğimiz değer hiç okunmamıştı.

Tam bir servis restart'ının (systemctl restart corosync) sorunu çözebileceğini düşündüm; denedim, çözmedi. Restart, pve-a'yı ~13 saniyeliğine cluster'dan düşürdü (Nodes: 1, Quorate: No), ama priority yine tek, indekslenmemiş kaldı.

Sebep, resmi man sayfasında (corosync.conf(5)) çıktı: doğru anahtar priority değil, knet_link_priority. Bizim yazdığımız priority, geçerli bir knet parametresi olmadığı için corosync tarafından sessizce, gevşek bir yere yazılmış; hiçbir zaman gerçek link seçim mantığına girmemiş.

Doğru Syntax, Kesin Kanıt

interface {
  linknumber: 0
  knet_link_priority: 5
}
interface {
  linknumber: 1
  knet_link_priority: 10
}

corosync-cmapctl | grep -i "interface.*priority"

totem.interface.0.knet_link_priority (u8) = 5
totem.interface.1.knet_link_priority (u8) = 10

Bu sefer düzgün indekslenmiş. Log de anında değişti:

[KNET  ] host: host: 3 (passive) best link: 0 (pri: 5)
[KNET  ] host: host: 3 (passive) best link: 1 (pri: 10)

Corosync her iki linki de değerlendirip yüksek öncelikli olanı (link1, corosync-net) seçmiş.

Kesme ve Geri Getirme Testi

link1'i fiziksel host'tan kestim:

sudo virsh domif-setlink pve-a vnet0 down

[KNET  ] link: host: 3 link: 1 is down
[KNET  ] host: host: 3 (passive) best link: 0 (pri: 5)

Anında link0'a geçiş; pvecm status kesintisiz Quorate: Yes kaldı, hâlâ tam oy sayısıyla. Sonra geri açtım:

sudo virsh domif-setlink pve-a vnet0 up

[KNET  ] rx: host: 3 link: 1 is up
[KNET  ] host: host: 3 (passive) best link: 1 (pri: 10)

Saniyeler içinde link1'e geri dönüş. Bu, hem failover'ı hem failback'i (yüksek öncelikli link geri gelince otomatik ona dönme) doğru anahtarla kesin olarak kanıtladı. İlk yanlış denemede ("sticky" davranış sandığım şey) aslında sadece önceliğin hiç uygulanmamış olmasıydı; gerçek mekanizma tam beklendiği gibi çalışıyor.

Bölüm 2: İzleme Araçları

`corosync-quorumtool`: Daha Okunabilir Bir Alternatif

corosync-quorumtool -s
corosync-quorumtool -l

İçerik pvecm status ile aynı, ama membership tablosu hex ID (0x00000001) yerine düz ondalık ID + doğrudan hostname gösteriyor. Günlük kullanımda daha okunabilir.

Token/Consensus Formülünü Canlı Doğrulamak

corosync-cmapctl | grep -E 'totem.token|totem.consensus'

runtime.config.totem.token (u32) = 3125
runtime.config.totem.consensus (u32) = 3750
totem.token_coefficient (u32) = 125

Modül 0'da bulduğumuz formül: token = 3000 + (node_sayısı - 2) × token_coefficient. 3 node ile: 3000 + 1×125 = 3125. Tam uyuyor. consensus = 1.2 × token = 3750. O da uyuyor. Aylar önce bir dokümandan öğrendiğimiz bir formülü, kendi cluster'ımızın gerçek sayılarıyla doğrulamış olduk.

Beklenmedik Bulgu: İki Ayrı `corosync.conf`

pve-cluster (pmxcfs) loglarına bakınca, hiç bilmediğimiz bir mekanizma ortaya çıktı:

journalctl -u pve-cluster -n 20

[dcdb] notice: wrote new corosync config '/etc/corosync/corosync.conf' (version = 7)

Bir saniye sonra, corosync log'unda:

[CFG] Config reload requested by node 1

Şimdiye kadar hep /etc/pve/corosync.conf'u düzenledik; bu, pmxcfs üzerinden cluster geneline otomatik yayılan sanal bir dosya. Ama corosync daemon'ının kendisi aslında /etc/corosync/corosync.conf'u okuyor, farklı bir yol. pmxcfs bizim düzenlememizi algılayıp gerçek dosyayı arkada kendisi yazıyor, corosync de bunu saniyeler içinde fark edip reload istiyor. İki ayrı dosya, tek görünen arayüz.

Yan Etki: Corosync Restart'ı HA'ya da Yayılıyor

systemctl restart corosync denememizin ardından, pve-ha-crm/pve-ha-lrm logları da bir "Boot" işareti ve yeniden başlatma döngüsü gösterdi; VM'ler yeniden başlatılmış, lock'lar yeniden alınmış. "Sadece corosync'i restart ettim" sanısı, HA katmanına da dalga dalga yayılabiliyor.

Bölüm 3: Bir Node'u Gerçekten Çıkarmak

Prosedür

pve-c'yi resmi prosedürle çıkardım:

# pve-c'de
systemctl stop pve-cluster corosync

# pve-a'da
pvecm delnode pve-c

pvecm status

Nodes: 2
Expected votes: 3
Total votes: 3
Quorum: 2
    0x00000000    1    Qdevice

Beklenmedik detay: QDevice oyu 2'den 1'e düşmüş. lms algoritmasının formülü N-1 (node sayısı eksi bir); önceden 3-1=2'ydi, şimdi 2-1=1. pvecm delnode, node sayısını düşürse de QDevice algoritmasına (lms olarak kalmaya devam ediyor) hiç dokunmuyor; bunu elle yönetmek bize düşüyor.

Ortamın Kararsızlığı: Beklenmedik Bir HA Kilitlenmesi

pve-c çıkarma işleminden sonra, ha-manager status saatlerce şunu gösterdi:

fencing standby (CRM watchdog standby)
lrm pve-a (wait_for_agent_lock, ...)
lrm pve-b (wait_for_agent_lock, ...)

Corosync/quorum seviyesi tamamen sağlıklıyken (Quorate: Yes), HA CRM/LRM katmanı ayrı bir kilitte takılı kalmıştı. Loglardaki Boot işaretleri, host laptop'un bu süre zarfında birkaç kez uyku/uyanma döngüsünden geçtiğini gösteriyordu; nested VM'ler bu geçişlerde bazen kendini resetliyor. Bu, kontrollü bir test değildi, dürüstçe belirtmem gerekiyor. Ama şunu net gösterdi: corosync seviyesinde quorum sağlıklı olması, HA katmanının da sağlıklı olduğu anlamına gelmiyor; ikisi ayrı ayrı bozulabiliyor.

Bölüm 4: `lms`'ten `ffsplit`'e Geçiş

Artık gerçekten 2 node'dayız; Modül 2'de "resmi olarak desteklenmiyor" dediğimiz lms yerine, resmi olarak önerilen ffsplit'i test edebileceğimiz ilk an bu.

sed -i 's/algorithm: lms/algorithm: ffsplit/' corosync.conf.new

pvecm status

Total votes: 3
    0x00000000    1    Qdevice

QDevice oyu 1'de kaldı; ffsplit her zaman sabit 1 oy veriyor, lms'in değişken N-1 formülü değil. 2-node özelinde rakamsal sonuç aynı görünüyor (zaten N-1=1 burada), ama mekanizma temelden farklı; asıl fark bir node düştüğünde ortaya çıkacak.

Gerçek Bir 2-Node + QDevice Testi

pve-b'yi çökerttim:

sudo virsh destroy pve-b

pvecm status

Nodes: 1
Total votes: 2
Quorum: 2
Quorate: Yes
    0x00000001    1    pve-a
    0x00000000    1    Qdevice

pve-a (1 oy) + QDevice (ffsplit'in sabit 1 oyu) = 2, eşik de 2. Quorate: Yes. Bu, Modül 2'de simüle ettiğimiz senaryonun, artık gerçekten resmi olarak desteklenen 2-node yapılandırmasında, doğru algoritmayla çalıştığının kanıtı.

Bölüm 5: Beklenmedik Kapanış, Affinity Kilitlenmesi

Asıl beklemediğim şey burada oldu. VM 102 (o an pve-b'deydi) için ha-manager status, fence durumundan sonra sonsuza kadar recovery'de takılı kaldı. Loglara baktım:

journalctl -u pve-ha-crm -n 40 | grep -i "102"

08:16:50  recovering service 'vm:102' from fenced node 'pve-b' failed, no recovery node found
08:17:00  recovering service 'vm:102' from fenced node 'pve-b' failed, no recovery node found
08:17:10  recovering service 'vm:102' from fenced node 'pve-b' failed, no recovery node found
... (her 10 saniyede bir, kesintisiz tekrarlanıyor)

Sebep: Modül 4'te tanımladığımız negatif resource affinity kuralı (VM 100 ve 102 asla aynı node'da olamaz) hâlâ aktifti. Tek ayakta kalan node (pve-a) zaten VM 100'ü barındırıyordu; VM 102 için yasal hiçbir hedef yoktu. Sistem bu imkansız durumu, Modül 4'teki gerçek migration hatasından (exit code 255, birkaç denemeden sonra error state'ine düşme) tamamen farklı bir şekilde ele aldı: hiç error'a düşmedi, sadece sessizce, sabırla, her 10 saniyede bir yeniden denemeye devam etti.

pve-b'yi geri getirdim:

sudo virsh start pve-b

Birkaç dakika sonra:

ha-manager status

lrm pve-b (active, ...)
service vm:102 (pve-b, started)

pve-b geri gelir gelmez, VM 102 için nihayet yasal bir hedef oluştu (VM 100'den uzak), ve kilitlenme kendiliğinden çözüldü.

Bu, Modül 3'teki "yanlış çalışmaya devam etmektense hiç çalışmamak" fail-safe felsefesinin bir üst seviyesi: burada sistem "hiç çalışmamayı" bile seçmedi, "kuralı çiğnemektense sonsuza kadar beklemeyi" seçti. HA'nın kendi kurtarma mantığı, kendi affinity kurallarıyla çelişkiye düşebiliyor, ve sistem bunu görmezden gelmiyor; askıda bırakıyor.

Genel Değerlendirme

Bu modül, planladığımdan çok daha derin bir yere gitti, ve muhtemelen serinin en yoğun modülü oldu.

Birincisi, priority yerine knet_link_priority gerektiği yanlış anahtar hatası. Saatler süren bir araştırmaya (config reload mı restart mı, cmapctl'in tuhaf tek satırı, "sticky" yanlış hipotezi) yol açtı, ama sonunda man sayfasını okumanın (tahmin etmek yerine) değerini bir kez daha kanıtladı.

İkincisi, pmxcfs'in arkada iki ayrı corosync.conf dosyası yönetmesi. Beş modüldür /etc/pve/corosync.conf'u düzenliyorduk, corosync'in gerçekte /etc/corosync/corosync.conf'u okuduğunu hiç fark etmemiştik.

Üçüncüsü, ve en değerlisi: affinity kilitlenmesi. Bunu planlamamıştık; gerçek bir node çıkarma operasyonunun, gerçek bir node çökmesinin, ve Modül 4'te tanımladığımız bir kuralın kesişiminde kendiliğinden ortaya çıktı. HA'nın "kuralı çiğnemektense sonsuza kadar bekle" tercihi, sistemin ne kadar temkinli tasarlandığını gösteren en net kanıt oldu.

Bu seride Corosync'in temellerinden (Modül 1) quorum'a (Modül 2), HA Manager'a (Modül 3), resource affinity ve CRS'e (Modül 4), ve şimdi redundant link'lere ve izleme araçlarına kadar geniş bir yüzeyi gezdim. Her modülde en az bir varsayımım yanlış çıktı, ve neredeyse her seferinde yanlış çıkan varsayım, doğru olandan daha çok şey öğretti. Bu, sanırım bu serinin özeti: hazır bir HOL yokken, doğru cevabı bilmiyor olmak bir eksiklik değil, öğrenmenin kendisiydi.

Bu seri, resmi Proxmox VE dokümantasyonundan (pve.proxmox.com), corosync man sayfalarından, ve topluluk kaynaklarından 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.

# Resource Affinity, CRS ve Bir Gece Boyu Salınım (Modül 4)

Hakan İSMAİL — Fri, 21 Aug 2026 05:50:06 +0000

Seri: Proxmox VE Cluster ve Corosync

Modül 3'ün sonunda söz vermiştim: 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 edecektim. Planım basitti: birkaç kural ekle, birkaç migration dene, sonuçları yaz. Gerçekte olan şu oldu: bir gece boyu süren beklenmedik bir salınım, gerçek bir HA arızası, ve kendi verdiğim yanlış bir talimatın beni yanlış bir teşhise sürüklemesi. Hepsini olduğu gibi anlatıyorum.

Kavramlar: Resource Affinity ve CRS

Resource affinity, node-affinity'den farklı bir şey; node-affinity bir VM'i belirli node'lara bağlarken, resource affinity iki veya daha fazla VM'i birbirine göre konumlandırıyor. İki tipi var: pozitif (belirtilen kaynaklar hep aynı node'da olmalı) ve negatif (hep farklı node'larda olmalı). Resmi dokümantasyona göre negatif bir kuralda cluster'daki node sayısından fazla kaynak olamıyor (bizim 3 node'umuzda en fazla 3 kaynak), ve aynı VM çifti aynı anda hem pozitif hem negatif bir kuralda olamıyor.

CRS (Cluster Resource Scheduler), HA kaynaklarının hangi node'a yerleştirileceğine karar veren mekanizma. Üç mod var: basic (sadece guest sayısına bakar), static (yapılandırılmış CPU/RAM kotalarını da hesaba katar), dynamic (gerçek zamanlı kullanımı da hesaba katar). Dynamic mod, isteğe bağlı bir otomatik yeniden dengeleme (auto-rebalance) özelliği de sunuyor; cluster dengesizliği belirli bir eşiği aşarsa, otomatik migration'lar tetikliyor. Config, /etc/pve/datacenter.cfg içinde crs: ha=dynamic,ha-auto-rebalance=1,ha-auto-rebalance-threshold=<yüzde>,ha-auto-rebalance-hold-duration=<tur> şeklinde tutuluyor.

Uygulama 1: Test VM'lerini Hazırlamak

VM 100'ü iki kez klonladım:

qm clone 100 101 --name alpine-b --full
qm clone 100 102 --name alpine-c --full

İkisini de HA'ya ekledim:

ha-manager add vm:101 --state started
ha-manager add vm:102 --state started

İlk ha-manager status çıktısında üçü de pve-a'da görünüyordu. İlk bakışta "pozitif affinity zaten çalışıyor" diye düşünebilirdim, ama bu yanlış bir sonuç olurdu: qm clone'u pve-a'dan çalıştırdığım için, yeni VM'lerin config dosyaları zaten oraya oluşmuştu; hiçbir kural henüz devrede değildi. Tesadüfi yerleşimi kanıt sanmak, bu modülün ilk dersi oldu.

Uygulama 2: Pozitif Resource Affinity, Gerçek Bir Test

ha-manager rules add resource-affinity keep-together --affinity positive --resources vm:100,vm:101

Gerçek kanıt için, kuralı ihlal etmeye çalıştım:

qm migrate 101 pve-c --online

cannot migrate resource 'vm:101' to node 'pve-c':
- resource 'vm:101' not allowed on target node 'pve-c'

Reddedildi. Kural gerçekten çalışıyor; VM 100 pve-a'ya bağlı olduğu (Modül 3'ten kalma node-affinity kuralı) için, 101'in oradan ayrılmasına izin verilmiyor. Manuel bir taşımayı bile engellemesi, bunun tesadüfi değil aktif bir kısıtlama olduğunu kanıtlıyor.

Beklenmedik Bir İsimlendirme Gizemi

ha-manager rules list çalıştırdığımda, Modül 3'te prefer-pve-a adıyla oluşturduğum node-affinity kuralının artık ha-rule-ae59af1e-b08f gibi bir hash olarak göründüğünü fark ettim. Kendiliğinden değişmemişti; ben bir ara bu kuralı web arayüzünden silip yine web arayüzünden yeniden eklemiştim. Yeni eklediğim keep-together (CLI'dan) ise ismini koruyordu. /etc/pve/ha/rules.cfg'ye bakınca ikisi de doğrulandı. Sebebi araştırınca netleşti: GUI'nin "Add" formunda isim alanı yok; boş bırakılınca backend otomatik bir hash üretiyor. Bunu doğrulamak için CLI'dan ayrı bir isim testi yaptım:

ha-manager rules add node-affinity test-isim-korunuyor-mu --resources vm:102 --nodes pve-c

Bu isim korundu. Sonuç: CLI'dan eklenen kurallar verdiğin ismi koruyor, GUI'den eklenenler otomatik hash alıyor. Küçük ama gerçek bir GUI/CLI farkı; benim başıma gelme sebebi kuralı GUI üzerinden silip tekrar eklemem oldu, sistemin kendi kendine isim değiştirmesi değil.

Aynı ekleme işlemi web arayüzünden Datacenter → HA → Affinity Rules → HA Node Affinity Rules altında "Add" butonuyla da yapılabiliyor; iddiamı bu ekranı görünce doğruladım, gerçekten bir isim alanı yok:

Uygulama 3: Negatif Resource Affinity, Proaktiflik ve Geçişli Çıkarım

ha-manager rules add resource-affinity keep-separate --affinity negative --resources vm:100,vm:102

Hiçbir manuel migration yapmadan, ha-manager status'a tekrar baktığımda VM 102'nin kendiliğinden pve-c'ye taşınmış olduğunu gördüm; Modül 3'teki proaktif node-affinity bulgusunun resource-affinity için de geçerli olduğu kanıtlandı.

Sonra kuralı ihlal etmeye çalıştım: VM 102'yi (pve-c'de), VM 100'ün olduğu pve-a'ya geri çekmeye:

qm migrate 102 pve-a --online

cannot migrate resource 'vm:102' to node 'pve-a':
- resource 'vm:100' on target node 'pve-a' in negative affinity with resource 'vm:102'
- resource 'vm:101' on target node 'pve-a' in negative affinity with resource 'vm:102'

İkinci satır beni şaşırttı: vm:101 için hiç negatif kural tanımlamamıştım. Sistem bunu kendisi türetmiş: vm:101, vm:100'le pozitif kuralda (birlikte kalmalı); vm:100 da vm:102'yle negatif kuralda (asla birlikte olmamalı). Motor bu iki kuralı birleştirip, açıkça yazılmamış üçüncü bir kısıtlamayı geçişli olarak çıkarmış: vm:101 de vm:102'den uzak durmalı. Kural motoru sadece her kuralı tek tek kontrol etmiyor, aralarında mantıksal çıkarım yapıyor.

Uygulama 4: CRS'i Etkinleştirmek, Yanlış Bir İzin Peşinde

Dynamic CRS'i, testi hızlandırmak için agresif ayarlarla açtım: threshold %10, hold-duration 1.

ha-manager status

master pve-b (active, ...) - dynamic load CRS (load imbalance: 8.1%)

%8.1 < %10 olduğu için hiçbir şey taşınmadı; beklenen davranış. Eşiği %1'e düşürdüm, ama yine hiçbir taşıma olmadı, dengesizlik %9.3 göstermesine rağmen. Bunun sebebini GUI'den migration denemesiyle araştırdım:

pve-b hedefindeki hata daha az detaylıydı, ve gerçek sebep CRS ile hiç ilgili değildi: Uygulama 2'de test amaçlı eklediğim test-isim-korunuyor-mu kuralı (VM 102'yi pve-c'ye sabitleyen) hâlâ duruyordu, hiç silmemiştim. Kalıntıyı temizleyince:

ha-manager rules remove test-isim-korunuyor-mu
ha-manager migrate vm:102 pve-b

Bu sefer kabul edildi. Ders: kendi test kalıntılarını temizlemeden bir sonraki testi yorumlamaya çalışmak, yanlış sonuçlara götürebiliyor. "Kesin CRS'in suçu" diye düşünüp geçebilirdim; gerçek sebep çok daha sıradandı.

Uygulama 5: 12 Dakikalık Salınım

Temiz zeminde CRS'i test etmeye devam ettim. Saatler sonra loglara dönünce, journalctl -u pve-ha-crm çıktısında beklemediğim bir şey buldum: 21:38 ile 21:50 arası, tam 12 dakika boyunca, VM 102 her ~20 saniyede bir pve-b ile pve-c arasında ileri geri taşınmış:

21:38:27  auto rebalance - migrate vm:102 to pve-c (imbalance from 6.0% to 5.0%)
21:38:47  auto rebalance - migrate vm:102 to pve-b (imbalance from 12.0% to 9.8%)
21:39:07  auto rebalance - migrate vm:102 to pve-c (imbalance from 10.9% to 8.8%)
21:39:27  auto rebalance - migrate vm:102 to pve-b (imbalance from 9.4% to 7.2%)
...

(Bu desen, yaklaşık 20 saniyede bir tekrarlanarak devam ediyor.)

Her taşıma "dengesizliği azaltıyor" gibi görünüyor, ama taşıdıktan hemen sonra tekrar dengesiz hale geliyor, sistem tekrar taşıyor; klasik bir salınım. Sebebi büyük ihtimalle bizim test için verdiğimiz aşırı agresif ayarlar (threshold=1%, hold-duration=1). Gerçek bir ortamda bu ayarlarla çalışmak, sürekli gereksiz migration'a ve VM'ler için mikro kesintilere yol açardı. Bu, dynamic CRS'in varsayılan ayarlarının (yaklaşık %30 eşik, daha uzun hold-duration) neden öyle seçildiğini somut olarak gösterdi.

Uygulama 6: Gerçek Bir Arıza

Salınım 21:50'de durmuş, ama ondan 9 saat sonra, sabaha karşı, gerçek bir arıza oluşmuş:

07:46:58  service 'vm:102' - migration failed (exit code 255)
07:47:18  starting service vm:102 on node 'pve-b' failed, relocating service.
07:47:28  service 'vm:102' - migration failed (exit code 255)
07:47:48  recovery policy for service vm:102 failed, entering error state. Failed nodes: pve-b, pve-b

VM error state'ine düşmüştü. qm status 102, pve-b'de "stopped", pve-c'de "config dosyası yok" diyordu; disk ve NFS bağlantısı sağlıklıydı. Asıl ipucu /var/lock/qemu-server/lock-102.conf dosyasıydı; başarısız migration'ın arkasında bıraktığı bir kilit.

Proxmox'un resmi hata kurtarma prosedürünü uyguladım:

ha-manager set vm:102 --state disabled
qm unlock 102
qm start 102

Bu üçüncü komut başarılı oldu; VM gerçekten çalışmaya başladı (VM 102 started with PID 3490). Kilit, sorunun gerçek sebebiydi.

Kendi Verdiğim Yanlış Bir Talimat

Buradan sonra "temiz bir devir" için VM'i durdurup HA'ya tekrar devretmeyi önermiştim:

qm stop 102
ha-manager set vm:102 --state started

VM birkaç saniye sonra durmuş görününce bir an paniğe kapıldım: "neden durdu?" Log'a bakınca gerçek sebep ortaya çıktı: VM 07:57:42'de başarıyla başlamıştı, ama benim önerdiğim qm stop komutu tam 9 saniye sonra (07:57:51) onu durdurmuştu. Gizemli bir sistem davranışı değildi; benim gereksiz bir talimatımdı. Asıl düzeltme (qm unlock) tek başına yeterliydi.

Uygulama 7: İkinci Bir Salınım, Ve Kalıcı Çözüm

VM'i tekrar --state started yapınca, HA onu pve-b'de başlattı, ama 20 saniye sonra CRS onu tekrar pve-c'ye taşıdı, 30 saniye sonra pve-b'ye geri getirdi:

08:02:59  service 'vm:102': state changed to 'started' (node = pve-b)
08:03:19  auto rebalance - migrate vm:102 to pve-c (imbalance from 18.4% to 15.4%)
08:03:49  auto rebalance - migrate vm:102 to pve-b (imbalance from 7.0% to 6.3%)

Uygulama 5'teki salınım hâlâ aktifti; recovery'nin üstüne binmişti. ha-auto-rebalance'ı hiç kapatmamıştık. Kapattım:

sed -i 's/ha-auto-rebalance=1/ha-auto-rebalance=0/' /etc/pve/datacenter.cfg

sed ile metin üzerinde arama-değiştirme yapmak, teknik olarak çalışsa da bir risk taşıyor: yanlış bir eşleşme ya da beklenmedik bir format farkı, dosyayı sessizce bozabilir. Aynı değişikliği web arayüzünden yapmak daha güvenli; Datacenter → Options → Cluster Resource Scheduling ekranına dönüp "Automatic Rebalance" kutusunu kaldırmak yeterli:

Birkaç dakika sonra:

ha-manager status

master pve-c (active, ...) - dynamic load CRS
service vm:102 (pve-c, started)

VM artık sabit. Küçük bir bonus gözlem: master satırındaki (load imbalance: X%) yüzdesi de kaybolmuş; muhtemelen bu hesaplama sadece auto-rebalance aktifken yapılıp gösteriliyor.

Genel Değerlendirme

Bu modül, planladığımdan tamamen farklı bir yere gitti, ve sanırım bu yüzden serinin en zengin modüllerinden biri oldu.

Birincisi, resource affinity kurallarının geçişli çıkarım yapması. İki kuralı ayrı ayrı yazdım (100-101 pozitif, 100-102 negatif), ama sistem bunları birleştirip yazmadığım üçüncü bir kısıtlamayı (101-102 negatif) kendisi türetti. Bu, kural motorunun basit bir liste kontrolünden çok daha fazlası olduğunu gösterdi.

İkincisi, agresif CRS ayarlarının gerçek bir tehlikeyi somutlaştırması. 12 dakikalık salınımı görmeden önce "düşük eşik = daha duyarlı sistem" gibi soyut bir fikrim vardı. Gördükten sonra bunun "sürekli gereksiz migration" anlamına geldiğini anladım; varsayılan ayarların neden temkinli seçildiğini artık deneyimledim.

Üçüncüsü, ve belki en önemlisi: kendi verdiğim bir talimatın (gereksiz qm stop) beni yanlış bir teşhise sürüklemesi. Bir rehber, bir dokümantasyon, hatta bir AI asistanı bile, doğrulanmamış bir öneri verdiğinde yanlış ize sürükleyebiliyor. Log'a dönüp gerçek zaman damgalarını karşılaştırmak, "sistem tuhaf davranıyor" sanısını "ben tuhaf bir şey yaptım" gerçeğine çevirdi. Bu ders, teknik bir bulgudan çok, bir çalışma disiplini: iddia etmeden önce logu aç.

Bir sonraki modülde seriyi toparlayacağım: bu dört modülde öğrendiklerimi (Corosync temelleri, quorum, QDevice, HA Manager, resource affinity, CRS) bir araya getiren bir kapanış, ve muhtemelen bir sonraki öğrenme hedefine (Ceph ya da başka bir konu) işaret eden bir bakış.

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.

# 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.

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.

DEV Community: Hakan İSMAİL

Proxmox Otomasyonu Faz 2: Serial ile Kimliklendirilmiş Depolama, Kesintisiz LVM + XFS

Hedef: dört disk, kalıcı kimlik

Problem: disk tahmini ve elle büyütme

Tasarım: kimlik serial'da

Terraform: dört diski tanımlamak

Apply: disk, VM çalışırken beliriyor

İki taraftan doğrulama

Rebuild dolambacı: önce başarısız olan apply

Ansible storage playbook'u

İlk çalıştırma ve doğrulama

Sıfırıncı adım: taze VM'de guest agent yok

İlk çalıştırma

İdempotans: tekrar çalıştırma

Büyütme denemesi: tek düzenleme, sıfır kesinti

Hızlı başvuru: belirti, neden, çözüm

Sırada ne var?

Proxmox'da Sıfır Dokunuşla VM Sağlama: Terraform, cloud-init ve Ansible (Bölüm 1)

Hedef: tek komut, üç kaynak

Ön kontrol: dört kapı, on dakika

Storage: content type'ların sessiz tuzağı

Terraform için API token'ı

Kontrol düğümü: küçük bir LXC

İlk giriş: konsolda şifre yok

Minimal konteynerde gpg yok

Üretilmemiş locale

SSH anahtarı ve repo'nun üç aktarmalı yolculuğu

Terraform tarafı: kritik kararlar

init, validate ve plan: iki schema hatası üst üste

vlan_tag artık yok

hostname kalkmış, CPU tipinde -Auto yok

İlk apply: 4 dakika 25 saniye, 11 saniye, 15 dakika 5 saniye

Hata olmayan on beş dakikalık uyarı

Doğrulama: üç bağımsız katman hemfikir olana kadar

Ansible ilk temas: pipeline'ın kapanışı

Facts enjeksiyonu 2.24'te kalkıyor

Lab aniden dondu

Hızlı başvuru: belirti, neden, çözüm

Sırada ne var?

# Redundant Links, İzleme Araçları ve Bir Affinity Kilitlenmesi (Modül 5)

Bölüm 1: Redundant Corosync Links

Kurulum: İkinci Link'i Eklemek

Yanlış Anahtar, Saatler Süren Bir Araştırma

Doğru Syntax, Kesin Kanıt

Kesme ve Geri Getirme Testi

Bölüm 2: İzleme Araçları

corosync-quorumtool: Daha Okunabilir Bir Alternatif

Token/Consensus Formülünü Canlı Doğrulamak

Beklenmedik Bulgu: İki Ayrı corosync.conf

Yan Etki: Corosync Restart'ı HA'ya da Yayılıyor

Bölüm 3: Bir Node'u Gerçekten Çıkarmak

Prosedür

Ortamın Kararsızlığı: Beklenmedik Bir HA Kilitlenmesi

Bölüm 4: lms'ten ffsplit'e Geçiş

Gerçek Bir 2-Node + QDevice Testi

Bölüm 5: Beklenmedik Kapanış, Affinity Kilitlenmesi

Genel Değerlendirme

# Resource Affinity, CRS ve Bir Gece Boyu Salınım (Modül 4)

Kavramlar: Resource Affinity ve CRS

Uygulama 1: Test VM'lerini Hazırlamak

Uygulama 2: Pozitif Resource Affinity, Gerçek Bir Test

Beklenmedik Bir İsimlendirme Gizemi

Uygulama 3: Negatif Resource Affinity, Proaktiflik ve Geçişli Çıkarım

Uygulama 4: CRS'i Etkinleştirmek, Yanlış Bir İzin Peşinde

Uygulama 5: 12 Dakikalık Salınım

Uygulama 6: Gerçek Bir Arıza

Kendi Verdiğim Yanlış Bir Talimat

Uygulama 7: İkinci Bir Salınım, Ve Kalıcı Çözüm

Genel Değerlendirme

# 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?

`corosync-quorumtool`: Daha Okunabilir Bir Alternatif

Beklenmedik Bulgu: İki Ayrı `corosync.conf`

Bölüm 4: `lms`'ten `ffsplit`'e Geçiş

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

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

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