DEV Community: Hakan İSMAİL

# VCF 9.1: Memory Tiering, vSAN Global Deduplication ve Oracle RAC / WSFC için Hot Extend (Modül 3)

Hakan İSMAİL — Thu, 15 Oct 2026 05:23:15 +0000

HOL-2701-01 serisinin son yazısı. İlk modülde arayüz ve VCF Operations'ı, ikinci modülde VCF Automation'ı gezdim. Bu yazıda vSphere tarafında Memory Tiering, vSAN tarafında Auto RAID, Global Deduplication ve clustered uygulamalar için Hot Extend'i ele alıyoruz.

Her zamanki gibi bunları sahadan değil, HOL ortamından yazıyorum. Production'da Memory Tiering ya da vSAN ESA işletmedim. Lab'ı "bunu gerçek bir ortamda açmadan önce ne sorardım" gözüyle okumaya çalıştım. Yanlış anladığım yer olursa yorumlarda düzeltirseniz sevinirim.

Memory Tiering

Kılavuzun anlattığı problem

Kılavuzun bu bölümü, bir okuma kısmıyla başlıyor ve çıkış noktası şu: pratikte bellek kullanımı genelde CPU kullanımından yüksek oluyor. Bellek neredeyse dolarken CPU düşük kalıyor ve o CPU'yu kullanamıyorsunuz, çünkü ona bağlı bellek yok. Host ya da koca bir küme memory-bound hale geliyor. Kılavuza göre bunun sonucu verimsiz kaynak kullanımı, güç ve soğutma israfı ve bellek maliyetinin TCO içindeki büyük payı yüzünden artan maliyet.

Çözüm olarak ESX host'una takılı yerel NVMe cihazlarını "tiered memory" olarak kullanıp belleği iki katmana ayırıyorlar:

Tier 0: DRAM.
Tier 1: NVMe. Yalnızca host üzerinde çalışan VM'ler için kullanılıyor.

Mantık sayfaların ne kadar kullanıldığına göre sınıflandırılması:

Hot: Zamanın %50'sinden fazlasında aktif.
Warm: Zamanın %50'sinden azında kullanılıyor.
Cold: Zamanın %20'sinden azında kullanılıyor.
Very cold: Neredeyse hiç kullanılmayan sayfalar. Kılavuz bunu aşırı provisioning'e bağlıyor.

Cold ve very cold sayfalar NVMe'ye iniyor, DRAM boşalıyor. Böylece aynı CPU kapasitesiyle daha fazla VM çalıştırabiliyorsunuz.

Kılavuzun listelediği hedefler arasında şunlar var: uygulamalara şeffaf, DRAM ve NVMe üzerinde tek bir tüketim modeli, ortak bir yönetim modeli ve VM bazında Memory Tiering'i kapatabilme. HA, DRS, vMotion, Fast Suspend/Resume ve RAID desteği de kılavuzda açıkça sayılmış.

VCF Operations'ta "ya eklesem" simülasyonu

Bu bölümün en pratik cümlesi bence şu: VCF Operations, NVMe eklemeden önce bunu simüle etmenizi sağlıyor. Mevcut CPU ve bellek kullanım örüntülerine bakarak potansiyel maliyet tasarrufunu, olası VM sayısı artışını, projeksiyonla bellek durumunu ve CPU kullanımındaki beklenen iyileşmeyi gösteriyor. Maliyet tahminleri VCF Operations'taki cost driver'lara dayanıyor ve güncel piyasa fiyatlarına göre güncellenebiliyor. Aktif bellek kullanımı %50'nin altında ve boş CPU kapasitesi %50'nin üstünde olan kümeler güçlü aday olarak işaretleniyor.

Donanım satın almadan önce "bu bana ne kazandırır" sorusuna veri ile cevap verebilmek hoşuma gitti. Bir bütçe konuşmasında bu tür bir çıktı iş görür. Ama bu simülasyonun ekranını lab'da görmedik, sadece okuma kısmında anlatılıyor. Tahminin ne kadar doğru çıktığı, ya da hangi metriklerle ne kadar süreyle toplanan veriye dayandığı da bilgi olarak verilmiyor.

Lab'da gördüğüm: ayarlar

Lab'da Memory Tiering açılmıyor, sadece ayarlar inceleniyor. Kılavuz, ayrıntılı kurulum için HOL-2703-01-VCF-L adlı ayrı lab'ı öneriyor. Orada tiering'in gerçekten yapılandırıldığı ve vCenter ile VCF Operations'taki yeni gözlemlenebilirlik raporlarının ve dashboard'ların gezildiği anlatılıyor.

Yol şöyle:

vCenter'da (vc-wld01-a) Hosts and Clusters > cluster-wld01-01a > Configure.
Soldaki menüde Desired State > Configuration.
Önceden bir draft varsa Discard Draft, sonra Draft sekmesinde CREATE DRAFT.
esx kategorisi altında memtier > nvme ayarı > CONFIGURE SETTINGS.

Memory Tiering ayarı küme genelinde Desired State yapılandırmasının bir parçası. Yani ayarı tek tek host'larda yapmıyorsunuz, draft üzerinden küme için tanımlıyorsunuz.

Configure > Desired State > Configuration, Draft sekmesi" width="800" height="433">

nvme ayarı" width="800" height="433">

Ayar ekranında şunlar var:

Enabled: TRUE yapınca Memory Tiering açılıyor. Varsayılan olarak kapalı.
device: Her host için birincil NVMe cihazı.
mirror_device: İkincil ya da mirror NVMe cihazı. Birincil NVMe'de sorun olursa yedeklilik için.
encryption: NVMe'de tutulan bellek sayfalarının şifrelenmesi.
Yüzde değeri: Memory Tiering için kullanılacak NVMe miktarı, fiziksel belleğin yüzdesi olarak. Varsayılan 100, yani fiziksel belleğin %100'ü.

Sonra CANCEL diyorsunuz, hiçbir şey kaydedilmiyor.

Gerçek ortamda soracağım sorular

Kılavuzun anlattığı faydalar (daha fazla VM yoğunluğu, daha iyi CPU kullanımı, düşen TCO) mantıklı geliyor. Ama lab hiçbirini ölçmüyor. Bende kalan sorular şunlar:

Cold sayfaya erişim gerekirse ne olur? NVMe, DRAM'den yavaş. Kılavuz "şeffaf" diyor, ama gecikmeye duyarlı iş yüklerinde bunun etkisini bilmek isterim. VM bazında kapatabilmek tam bu yüzden değerli bir seçenek olabilir.
Hangi NVMe cihazları destekleniyor? Dayanıklılık (yazma ömrü) ve performans gereksinimleri nelerdir, kılavuz değinmiyor.
Mirror cihaz zorunlu mu, tavsiye mi? Birincil cihaz arızalanırsa o host'taki VM'lere ne olacağını lab'da denemedik.
%100 varsayılanı ne anlama geliyor? Fiziksel belleğin yüzde yüzü kadar NVMe kullanmak, toplam belleği iki katına çıkarmak gibi okunabilir, ama kılavuz bunu açıkça yazmıyor. Kendi yorumum, o yüzden emin değilim.

vSAN

Bu modül üç özellik üzerine kurulu: Auto RAID, Global Deduplication ve clustered uygulamalar için Hot Extend.

Auto RAID

vSAN ESA'da Auto-RAID storage policy'si, site disaster tolerance ve failures to tolerate değerlerini küme yapılandırmasına göre kendisi belirliyor. Yeni storage policy oluştururken bu varsayılan ayar. Kılavuza göre:

3-5 host'luk kümelerde: RAID-5 erasure coding, 1,5x RAID overhead.
6 ve üzeri host'ta: RAID-6 erasure coding, aynı 1,5x overhead.

Küme yapılandırması değişirse (örneğin host eklerseniz) nesneler otomatik olarak yeni optimal ayara göre yeniden yapılandırılıyor. Kılavuz bunun performansı etkilemeden daha iyi veri koruması sağladığını söylüyor.

Bu bölüm tamamen okuma. Lab'da Auto-RAID policy'si oluşturmuyoruz. İşletme gözüyle sorum şu: host sayısı 5'ten 6'ya çıkınca RAID-5'ten RAID-6'ya geçiş sırasında yeniden yapılandırma (resync) trafiği ne kadar olur, bunu bakım penceresine nasıl yerleştiririm? Lab bunu göstermiyor. Auto-RAID ayrıca bir sonraki bölümdeki effective capacity görünümünü de açıyor.

Global Deduplication ve Effective Capacity Reporting

vSAN ESA artık küme seviyesinde global deduplication yapabiliyor. Kılavuza göre sıkıştırma 9.1'de varsayılan olarak açık. Global dedup ise ESA kümesini yapılandırdıktan sonra açılabiliyor ve vSAN nesne seviyesinde uygulanıyor. Çalışma biçimi: kümedeki tekrarlanan veri bloklarını kaldırıp yerine tek bir örneğe işaret eden pointer'lar koyuyor. Modül girişinde bunun küme geneli ve post-processing bir ayar olduğu, şifreleme desteğiyle geldiği ve dedup etkinliğini düşürmeden data-at-rest güvenliği sağladığı belirtiliyor.

vSAN serisinde (Modül 3) şifrelemeye bakmıştık. Dedup ile şifrelemenin birlikte çalışması bu yüzden dikkatimi çekti, çünkü bunlar genelde birbirini köreltir. Kılavuz bunun mekanizmasını anlatmıyor, sadece "etkinliği düşürmeden" diyor.

Dedup'un getirdiği kısıtlar

Kılavuz bunları açıkça sayıyor ve bence bu bölümün en değerli kısmı bu:

Thick-provisioned VM'ler dedup edilmiyor. Global dedup açıldıktan sonra kümedeki thick VM'ler dedup dışı kalıyor. Thin'den thick'e çevrilen bir VM için de dedup duruyor.
Stretched cluster'a dönüşüm yok. Standart bir vSAN kümesinde global dedup açıldıysa, o küme sonradan stretched cluster'a çevrilemiyor.

İkincisini tasarım aşamasında bilmezseniz ileride pahalıya patlayabilir: "şimdilik standart kuralım, sonra stretched'a geçeriz" planı varsa dedup'u açmadan önce iki kere düşünmek gerekir.

Lab'da gördüğüm

vCenter'da cluster-wld01-01a > Configure > vSAN > Services. Lab'da deduplication zaten açık görünüyor. Kapalı olsaydı EDIT ile açabilirdik, ama gerek yok.

vSAN > Services, Deduplication açık" width="800" height="409">

Aynı kümede Monitor > vSAN > Capacity. Space Efficiency bölümünde kullanılan kapasite 83,82 GB, data reduction tasarrufu 57,55 GB görünüyor. Kılavuz sizin ortamınızda rakamların biraz farklı çıkabileceğini söylüyor.
Data reduction ratio altında SHOW DETAILS diyince dedup oranı ve sıkıştırma oranı ayrı ayrı görünüyor. 9.1'de sıkıştırma varsayılan açık olduğu için ikisini birbirinden ayırabilmek güzel.

vSAN > Capacity, Space Efficiency bölümü" width="800" height="409">

Burada dürüst olmam gereken şey şu: lab'ın küçük bir veri setiyle çalıştığını rakamlardan görüyorsunuz (83 GB civarı). Bu oranlar production'daki gerçek veri için bir fikir vermez. Dedup'un gerçek faydası iş yükünün tipine (çok sayıda aynı OS imajı mı, veritabanı mı) bağlı ve bunu lab'da test etme şansımız yok. Ayrıca post-processing olduğunu düşününce, dedup'un ne zaman ve ne kadar sürede etki edeceğini, arka planda ne kadar kaynak tükettiğini de bilmek isterim.

Clustered uygulamalar için Hot Extend: Oracle RAC ve WSFC

VCF 9.1, clustered uygulamaların disklerini, o uygulamayı barındıran VM'leri kapatmadan genişletmenize izin veriyor. Kılavuza göre hem Oracle RAC multi-writer hem de Windows Server Failover Cluster (WSFC)'taki shared VMDK destekleniyor. Multi-writer attribute'unu kaldırmanız da gerekmiyor.

Lab'da bunun demosu, Oracle RAC yerine OCFS2 (Oracle Cluster File System v2) kullanan üç VM üzerinden yapılıyor. Yani Oracle RAC'in kendisini değil, aynı multi-writer VMDK'yı paylaşan bir OCFS2 kümesini görüyoruz. WSFC tarafı lab'da hiç gösterilmiyor, sadece kılavuz "destekleniyor" diyor.

Adımlar:

1. Multi-writer VMDK'yı görmek. ub1 VM'ine sağ tık > Edit Settings, Hard disk 2'yi genişlet, Sharing altında Multi-writer seçili görünüyor. ub2 ve ub3 için de aynı VMDK'ya bağlı olduğunu (Disk File yolu aynı) doğrulayabiliyorsunuz.

2. OCFS2 kümesine bakmak. ub1'in web console'unda sırasıyla:

sudo o2cb list-clusters
sudo o2cb cluster-status ocfs2
sudo o2cb list-nodes ocfs2

Birincisi ocfs2 adında tek bir küme olduğunu, ikincisi kümenin online olduğunu, üçüncüsü de üç node'u (ub1, ub2, ub3) gösteriyor.

3. Volume'u görmek.

sudo df -h /dev/sdb
ls /mnt/ocfs2
cat /mnt/ocfs2/test_file.txt

/dev/sdb cihazı /mnt/ocfs2 altına mount edilmiş ve boyutu 25 GB. Klasörde test_file.txt var ve içinde dosyanın ub1 üzerinde oluşturulduğu yazıyor.

4. VMDK'yı büyütmek. vCenter'da ub1'in Edit Settings'inde Hard disk 2'yi 25 GB'dan 30 GB'a çıkarıp OK diyorsunuz. VM'ler açık, multi-writer attribute'u olduğu gibi duruyor.

5. Volume'u genişletmek. ub2'nin console'unda lab'ın hazırladığı bir script var:

./expand_volume.sh

Kılavuz bu script'in tunefs.ocfs2 komutuyla /dev/sdb volume'unu genişlettiğini söylüyor. Çıktıda volume'un önce 25 GB, script'ten sonra 30 GB olduğu görünüyor.

6. Doğrulamak. ub2'de test_file.txt aynı dosya olarak açılıyor. Sonra ub1'in console'unda sudo df -h /dev/sdb çalıştırınca yeni boyutun (30 GB) orada da göründüğünü teyit ediyorsunuz. ub3 için de aynısı yapılabilir. Ben ikinci kez çalıştırdığım için Confirming Current Volume Size da 30GB görünüyor.

Bu, sistem tarafı için en somut kazanım gibi duruyor. Kılavuz bunu 9.1'in yeni bir yeteneği olarak sunuyor, yani öncesinde bu işi kesintisiz yapmak mümkün değildi ya da desteklenmiyordu, ama önceki sürümlerde tam olarak ne olduğunu kılavuz anlatmıyor. Burada üç VM çalışırken disk büyüyor. Ama burada iki şeye dikkat edilmeli. Birincisi, volume genişletme adımını bir script yapıyor ve kılavuz script'in içini göstermiyor. Yani tunefs.ocfs2 ile ne yapıldığını ve gerçek bir Oracle RAC kurulumunda (ASM gibi) bu adımların nasıl olacağını lab'dan çıkaramıyorum. İkincisi, VMDK'yı vSphere tarafında büyütmek bu özelliğin kolay kısmı, asıl iş guest OS tarafında yürüyor.

Genel olarak neler dikkatimi çekti

Birkaç şey kafamda kaldı.

İlk olarak, bu modüllerin ikisi de "donanım ya da yazılım maliyetini düşür" mesajı veriyor. Memory Tiering DRAM maliyetini, global dedup disk kapasitesini hedefliyor. Mantıklı. Ama ikisinin de "faydası" iş yükünüze bağlı ve lab'ın küçük, temiz ortamında bu faydayı ölçemiyoruz.

İkincisi, kısıtlar kılavuzda açıkça yazılıyor ve asıl okunması gereken yer orası. Thick VM'lerin dedup dışı kalması, global dedup sonrası stretched cluster'a geçilememesi, Memory Tiering'in varsayılan kapalı olması. Bunları okumadan "9.1'e geçince hepsini açarım" demek yanlış olur.

Üçüncüsü, bu iki modül de aslında tanıtım. Memory Tiering'i açmadık, Auto-RAID policy'si oluşturmadık, dedup'u kendimiz açmadık (zaten açık geldi). Gerçekten uygulamalı olan tek kısım Hot Extend'di. Kılavuz Memory Tiering için ayrı bir lab'a (HOL-2703-01-VCF-L) yönlendiriyor, bu da konunun bir tur kadarıyla anlaşılmayacağını kabul ediyor gibi.

Son olarak, her zamanki gibi: bu yazıdaki her şey lab ortamında, küçük ve temiz bir kurulumda gördüklerime dayanıyor. Production'da ölçek, iş yükü ve alışkanlıklar işi değiştirir. Memory Tiering, vSAN ESA ya da clustered uygulama işletenler "şu aslında böyle olmuyor" derse öğrenmek isterim.

Seri hakkında

HOL-2701-01 ile üç yazıda HOL'ın ilk laboratuvarını bitirmiş oldum: arayüz ve VCF Operations, VCF Automation, sonra Memory Tiering ve vSAN. Genel izlenimim, 9.1'in "her şeyi tek platformdan yönet" fikrini sertleştirdiği yönünde. Log, güvenlik, sertifika, namespace, policy, hepsi VCF Operations ve Automation etrafında toplanıyor. Bir sistemci olarak bunun getireceği kolaylığı da, getireceği bağımlılığı da görebiliyorum.

Katalogda daha ayrıntılı lab'lar var, kılavuzun kendisi bile Memory Tiering için başka bir lab öneriyor. Onlara bakarsam yine buradan yazarım.

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

VCF 9.1 Automation: Namespace Self-Service, Namespace Capture ve Infrastructure Policies (Modül 2)

Hakan İSMAİL — Fri, 09 Oct 2026 05:46:25 +0000

Önceki modülde HOL-2701-01 serisine VCF 9.1'in yeni menüleri ve VCF Operations tarafıyla başlamıştım. Operations modülünde çoğunlukla ekran gezdik, burada gerçekten bir şeyler oluşturuyoruz: namespace açıyoruz, bir namespace'i blueprint'e çeviriyoruz, tag ve policy zinciri kurup VM'in başka bir host'a kendiliğinden taşınmasını izliyoruz.

Her zamanki not: bunları sahadan değil, HOL ortamından yazıyorum. Production'da VCF Automation işletmedim. Lab'da gördüklerimi, "bunu gerçek bir ortamda kullanacak olsam ne sorardım" gözüyle okumaya çalıştım. Yanlış yorumladığım yer olursa yorumlarda düzeltirseniz sevinirim.

Kılavuz dört bölümden oluşuyor: Namespace Self-Service, Namespace Capture, Infrastructure Policies ve Service Framework. Sırayla gidiyorum.

Önce roller: bu modülde üç farklı kişi var

Bu modülü takip ederken en çok işime yarayan şey, kimin hangi portalda ne yaptığını baştan netleştirmek oldu. Çünkü lab sürekli portal değiştiriyor ve ne zaman hangi hesapla girdiğinizi karıştırmak kolay.

Provider admin: VCF Automation Provider portalında çalışıyor. Infrastructure Policy'leri burada tanımlıyor, Organization'lara Region Quota üzerinden atıyor, servisleri (Service Management) yönetiyor.
Organization admin: Organization portalında (lab'da ACME). Ağları, namespace class'larını, namespace servislerini sahipleniyor ve project'lere self-service'i açıyor.
Project admin: Kendi project'i sınırları içinde, org admin'in izin verdiği kaynaklarla namespace oluşturuyor, blueprint yayınlıyor.

Bu ayrım bana vCenter'daki "herkes admin" alışkanlığından farklı geldi. Self-service'in mantığı bu: org admin çerçeveyi çiziyor, project admin o çerçevenin içinde istediği gibi hareket ediyor.

Namespace Self-Service

Kılavuzdaki girişte iş akışı şöyle anlatılıyor: ağlar, namespace class'ları ve namespace servisleri org admin tarafından sağlanıyor. Project admin'ler bunları kendi project'leri sınırları içinde kullanıyor. Namespace oluşturabilmeleri için önce org admin'in o project için self-service'i yapılandırması gerekiyor. Bu ayarlar, hangi paylaşılan kaynakların ve hangi şablonların kullanılabileceğini belirliyor.

Lab'da bu kurulum zaten yapılmış halde geliyor. Yani org admin'in self-service'i nasıl açtığını görmüyoruz, sadece yapılmış ayarlara bakıyoruz. Bunu not düşmek istiyorum, çünkü gerçek ortamda en çok emek harcanacak yer bence orası.

Ayarlara şuradan ulaşıyorsunuz: Manage & Govern > default-project > Namespace Self-Service sekmesi.

Sekmede şu bölümler var:

Associated Regions: Namespace'lerin hangi region'larda oluşturulabileceği.
Associated Namespace Classes: Önceden tanımlanmış boyutlar. Project admin bunları değiştiremiyor.
Associated VPCs: Namespace oluştururken seçilebilecek paylaşılan VPC'ler.
Associated Connectivity Profiles: Bu profil seçilirse namespace için ayrı (dedicated) bir VPC oluşturuluyor.
Associated Subnets: Namespace oluştururken seçilebilecek önceden tanımlı subnet'ler.
Infrastructure Policies: Varsa project'e buradan bağlanıyor. Bu konuya modülün ortasında geri döneceğiz.
Associated Service Engine Groups: Avi Load Balancer'dan Service Engine Group tüketmek için.

Yeni namespace oluşturmak

Sonra kılavuz bir namespace açtırıyor: Namespaces > New Namespace. Sihirbazdaki alanlar şöyle:

İsim: sales (isim kurallarına dikkat edin diyor).
Namespace class: small. Sağ tarafta seçilen class'a göre kaynak sınırları değişiyor.
Region: us-west.
Zone: z-wld-a. Namespace'e ayrılan kaynaklar seçilen region'daki bir ya da birden fazla zone'dan geliyor.
Networking: Shared VPC (diğer seçenek Dedicated VPC) ve VPC olarak default-us-west.
Shared subnet: lab'daki hazır subnet.

Namespace hazır olunca sağ taraftaki detay panelini açıyorsunuz. Burada VM class'larını (ekleyip çıkarabiliyorsunuz), storage class'ı ve storage limitini (EDIT ile), infrastructure policy ayarını ve kullanılabilir servisleri görüyorsunuz.

Burada aklıma gelen sorular şunlar: Namespace class'larının sınırları ne kadar katı? Bir project admin kaç namespace açabilir, toplam limit nerede uygulanıyor? Lab bunları göstermiyor, sadece "oluşturdum, hazır" noktasına kadar götürüyor. Bir de dedicated VPC seçeneğini denemedik, sadece shared VPC kullandık.

Kılavuzun bu bölümün sonunda söylediği şey şu: bu özellik, namespace'i VM ya da ağ gibi bir kaynak olarak istemeyi mümkün kılıyor ve bir sonraki özelliğin (Namespace Capture) temeli.

Namespace Capture

Bence modülün en ilginç kısmı bu. Kılavuzun tanımı şöyle: çalışan bir namespace'i (VPC, VM'ler, diskler, subnet'ler, load balancer'lar ve ayarları dahil) alıp standart bir VCF Automation blueprint'ine, yani YAML'a çeviriyor. Bu blueprint versiyonlanıp catalog item olarak yayınlanabiliyor ve yetkili project kullanıcıları orijinalin birebir, bağımsız bir kopyasını isteyebiliyor.

Kılavuz bir de şunu söylüyor: 9.1 öncesinde blueprint'leri elle YAML olarak yazmanız gerekiyordu, bilinen bir namespace'i "kaydedip" dağıtılabilir bir şeye çevirmenin yolu yoktu. Şimdi project admin iş yükünü gerçek bir namespace'te kuruyor, doğruluyor ve blueprint'i VCF Automation üretiyor. Test/dev/lab ortamlarını "golden" bir şablondan tekrar tekrar basmak için düşünülmüş.

Proxmox otomasyon serisinde Terraform ve Ansible ile zero-touch VM provisioning yazmıştım. Orada her şeyi elle tanımlamanız gerekiyor ve bu işin asıl emeği. Burada ise tersini yapıyor: önce çalışan bir ortam kuruyorsunuz, sonra ondan tanım çıkarıyorsunuz. Hangi yaklaşımın daha iyi olduğunu söylemek için erken. Ama bu üretilen YAML'ın Git gibi bir akışa nasıl oturduğunu merak ediyorum, lab bunu göstermiyor. Blueprint ve versiyonlar VCF Automation'ın içinde tutuluyor.

Capture öncesi gerekenler

Kılavuz ön koşulları açıkça sayıyor, ben de aynen aktarayım çünkü gerçek hayatta bunlar işi belirler:

Org admin'in o project için Namespace self-service'i açmış olması.
Namespace ile ilişkili en az bir project content library olması. Yakalanan VM image'ları buraya kaydediliyor. Project content library OVA/OVF destekliyor, ISO ve çoklu VM içeren OVA desteklenmiyor.
Namespace içinde tam olarak bir VM Group olması ve namespace'teki her VM'in bu gruba ait olması.
Tüm VM'lerin başlatılmış (initialized) ve capture anında kapalı olması, veri tutarlılığı için.

İki kısıt da var: VKS cluster içeren namespace'ler capture edilemiyor. vSphere pod içeren namespace'ler capture edilebiliyor ama pod'lar blueprint'e dahil olmuyor.

Bu kısıtlar bana şunu düşündürdü: çalışan bir uygulama ortamını "yakalamak" için VM'leri kapatmanız gerekiyor. Golden bir lab ortamı için sorun değil, ama canlı bir ortamı kopyalamak için değil. VKS'in capture dışında kalması da, Kubernetes ağırlıklı bir kurulumda bu özelliğin kapsamını ciddi biçimde daraltabilir.

İki capture türü

Capture as an identical copy: Namespace'i birebir yeniden üretiyor: namespace class ve region, VPC connectivity profile ve private CIDR'lar, VM donanımı (VM class, sanal BIOS, NIC IP/MAC), ağ ve storage ayarları. Bootstrap alanları temizleniyor ki guest customization tekrar çalışmasın. Referans verilen secret'lar yeniden oluşturulmuyor. "Bana bundan bir tane daha ver, aynısı olsun" durumu için.
Capture with customizations: Aynısını yapıyor ama catalog'dan isteyen kişiye VM başına guest OS ayarları açıyor: hostname, parola (kullanıcının girdiği ya da otomatik üretilen, isterseniz ilk girişte değiştirmeye zorlayan), pre/post script'ler (Windows'ta Sysprep GuiRunOnce ya da PowerShell, Linux'ta LinuxPrep shell script'leri) ve Windows Active Directory domain join. Her dağıtımın benzersiz olması ya da domain'e katılması gerektiğinde.

Domain join seçeneğini görünce bir sistemci olarak rahatladım. Çünkü "aynı VM'den on tane" fikrinin ilk takıldığı yer hep hostname, SID ve domain oluyor.

Lab'da yaptıklarım

1. VM Group oluşturmak. Build & Deploy > Virtual Machine > VM Groups > +NEW VM GROUP. Sihirbazda Power State'i Powered Off yapıyorsunuz, listeden VM'i seçiyorsunuz, start order adımını geçiyorsunuz ve bitiriyorsunuz. VM açıksa grup oluşturulurken kapatılıyor.

Ekran görüntüsündeki [object Object] ifadesi web arayüzündeki bir görüntüleme hatası: arayüz bir metin beklerken nesne almış. İşleyişi etkilemiyor, sihirbaz normal şekilde devam ediyor.

2. Capture'ı başlatmak. Namespace Overview > CAPTURE AS A BLUEPRINT. Önce bir dizi precheck çalışıyor. Başarısız olan olursa burada raporlanıyor, hepsi geçerse Capture Wizard'a devam ediyorsunuz.

3. Blueprint detayları. İsim olarak HOL Namespace Capture, content library olarak ACME Default Project Library seçiyorsunuz, türü Capture with customizations yapıyorsunuz ve guest customization'ı açıyorsunuz. Sonra VM kaynağını seçip CONFIGURE diyorsunuz. Lab'da parola seçeneği olarak User specified password seçiliyor. Sonra Next ve CAPTURE.

4. İzlemek. Recent Captures sekmesinde durumu görüyorsunuz.

Blueprint ile catalog item farkı

Kılavuzun burada anlattığı ayrım önemli: capture bir blueprint üretiyor, yani versiyonlanabilen ve düzenlenebilen bir YAML tasarım dosyası. Bunu yayınlamak ayrı bir adım. Blueprint'i açıp Version diyorsunuz, bir versiyon numarası ve açıklama giriyorsunuz, "Publish this version to the catalog" seçeneğini açıp Create diyorsunuz. Bir blueprint'in çok versiyonu olabilir ama catalog'da sadece yayınladıklarınız görünüyor.

Bunun mantığı şu: tasarımı (YAML'ı düzenleyip tekrar capture edip versiyonu artırarak) mevcut kullanıcıları bozmadan geliştirebiliyorsunuz, hangi versiyonun dağıtımda olduğunu kontrol ediyorsunuz, belirli versiyonları organization'ınızdaki başka project'lerle ya da başka VCF Automation organization'larıyla paylaşabiliyorsunuz. Catalog item olmadan blueprint'e sadece org admin'ler ve project admin'ler ulaşıyor, project kullanıcıları isteyemiyor.

Lab'da: Blueprint Design > HOL Namespace Capture diyerek blueprint'i açıyoruz. Topology diyagramını ve YAML'ı inceliyoruz. Kılavuzun vurguladığı şey, capture'ın standart VCF Automation YAML'ı üretmesi. Sonra VERSION > versiyon 1, açıklama Initial Capture Catalog Item, Publish this version to the catalog açık > CREATE.

Catalog'dan dağıtmak

Catalog sayfasında HOL Namespace Capture item'ında REQUEST diyorsunuz, dağıtım adı (HOL Deployment 1) ve VM parolası giriyorsunuz, SUBMIT. Dağıtım birkaç dakika sürüyor.

Bittiğinde dağıtımın özetini görüyorsunuz: Power State, IP adresi, VM Class. Kılavuzun bu noktada dikkat çektiği bir şey var: gördüğünüz IP, VM'in namespace'in özel ağındaki IP'si ve routable değil. VM'e ulaşmak için VM Load Balancer'a bakmanız gerekiyor. Topology sekmesinde vmService_vm_lb_... öğesine tıklayıp Load Balancer Ingress IP'yi alıyorsunuz, sonra terminalden SSH ile bağlanıyorsunuz.

Burada gözüme batan şey şu: yeni dağıtılan VM'e ulaşmak için ilk bakacağınız yer olan IP, erişilemeyen IP. Bunu bilmeyen biri bir süre uğraşabilir. Ayrıca ben bu bölümde sadece tek VM'li bir namespace capture ettim. Birden fazla VM, birden fazla disk ya da gerçek bir uygulama yığını yok. "Golden dev/test ortamını basma" iddiası kâğıt üzerinde güçlü, ama lab bunu tek VM ile gösteriyor.

Infrastructure Policies

Bu bölüm en uzun kısım (yaklaşık 50 sayfa) ve zincirleme çok adımı olduğu için ayrıca anlatmaya değer.

Kılavuzun tanımı: Infrastructure Policy'ler, cloud admin'in hizmet seçeneklerini ayırması (CPU yoğun ya da yüksek bellekli profiller gibi) ve lisans uyumluluğu için host yerleşimini yönetmesi için bir mekanizma. Bir Infrastructure Policy, bir VM'in hangi host'a ya da host grubuna yerleşeceğini tanımlıyor. VM-host affinity kurallarını uygulamak için. Policy'ler VCF Automation'da oluşturuluyor ve Region Quota üzerinden Organization'lara atanıyor.

İki uygulama biçimi var:

Mandatory: Organization'a zorunlu atanırsa, o organization'da oluşturulan her namespace'e otomatik uygulanıyor.
Optional: Org admin ya da project admin namespace oluştururken/güncellerken opsiyonel policy listesinden seçiyor, kullanıcılar da iş yükü dağıtırken bunlardan seçiyor.

Lab sadece optional policy'leri gösteriyor. Mandatory olanlar ve bunları otomatik uygulayan criteria builder için kılavuz "gelecekteki bir modül" diyor. Bunu açıkça yazıyorum, çünkü zorunlu uygulama production'da asıl merak edilen kısım ve burada görmüyoruz.

Policy'ler arkada vCenter Compute Policy'lerini kullanıyor. Kılavuzdaki dört adımlı akış şöyle:

Tag oluşturma: VCF Operations'ın tag özelliğiyle.
Compute Policy: Bu tag'leri vCenter'da bir Compute Policy'ye bağlamak.
Infrastructure Policy tanımı: VCF Automation Provider portalında.
Uygulama: Organization'ların Region Quota'sına eklemek.

Yani tek bir özellik için dört farklı yerde çalışıyorsunuz. Bu bana zincirin her halkasının sahibinin kim olduğu sorusunu getirdi: tag'ler platform ekibinde mi, vCenter policy'leri sanallaştırma ekibinde mi, Automation tarafı başka bir ekipte mi? Lab bunu tek kişinin yaptığı bir egzersiz olarak gösteriyor.

1. Tag'ler (VCF Operations)

Manage > Tags > Tag Definitions > + CREATE. Category adı infrastructure, altına üç tag: backup, disaster-recovery, production.

Sonra bu kategorileri vCenter'lara gönderiyorsunuz: PUSH CATEGORIES > ilgili vCenter'ı seç (lab'da wld01-a) > PUSH. Kılavuz, tag kategorilerini tek seferde birden fazla vCenter'a push edebildiğinizi özellikle vurguluyor. Çok vCenter'lı ortamlarda tek tek tag kategorisi oluşturmak zorunda kalmamak güzel.

Ardından Tag Assignments sekmesinde filtre uyguluyorsunuz: VCF Components altında wld01-a, Object Types altında Host. Atamalar şöyle:

Listelenen tüm host'lara infrastructure:backup.
esx-05a host'una infrastructure:disaster-recovery.
esx-06a ve esx-07a host'larına infrastructure:production.

Her atamada Assign Tags penceresinde seçilen nesneleri kontrol edebiliyorsunuz. Bu tasarım bana mantıklı geldi: backup tag'i tüm host'larda olduğu için, backup ve disaster-recovery policy'lerini birlikte seçen bir VM'in esx-05a'ya düşmesi beklenir. Bunu kılavuz açıkça yazmıyor, benim yorumum.

2. Compute Policy'ler (vCenter)

vCenter'a (workload domain'in vc-wld01-a'sı) geçiyorsunuz. Önce bir lab ayarı: kümenin vSphere DRS Automation Level'ı lab'daki kaynak kısıtları yüzünden Partially Automated gelmiş. Policy'nin otomatik yerleşimi gösterebilmesi için Fully Automated yapıyorsunuz (Hosts and Clusters > cluster-wld01-01a > Configure > vSphere DRS > Edit).

Sonra Policies and Profiles > Compute Policies > ADD. Üç tane VM-Host affinity policy oluşturuyorsunuz:

backup-vm-host-affinity: VM tag'i infrastructure:backup, host tag'i infrastructure:backup.
disaster-recovery-vm-host-affinity: VM ve host tag'i infrastructure:disaster-recovery.
production-vm-host-affinity: VM ve host tag'i infrastructure:production.

Mantık: bu tag'e sahip VM'ler, aynı tag'e sahip host'lara yerleşecek.

Kılavuz bu policy'lerin "must" mu "should" mu olduğunu belirtmiyor. Bu fark production'da önemli: host arızasında HA'nın bu kuralı çiğneyip çiğneyemeyeceği buna bağlı. Lab'da bunu görmedik.

3. Infrastructure Policy'ler (VCF Automation Provider portal)

Provider portalında Infrastructure Policies > vCenter Compute Policies sekmesinde üç compute policy'yi görüyorsunuz. Kılavuz bu policy'lerin VCF Automation'da görünmesinin birkaç dakika alabileceğini söylüyor. Sonra Infrastructure Policies sekmesinde CREATE INFRASTRUCTURE POLICY ile backup, disaster-recovery ve production adında üç policy tanımlıyorsunuz, her biri ilgili compute policy'ye bağlı.

4. Organization'a atamak

Organizations > Acme > Region Quota > us-west (>>) > Infrastructure Policies > EDIT, hepsini seçip SAVE. Sonra LAUNCH ORGANIZATION PORTAL ile org portalına geçiyorsunuz.

Test: namespace ve VM

Org portalında yeni bir namespace açıyorsunuz: production-all-apps, project default-project, class small, region us-west, zone z-wld-a, Infrastructure Policies alanında hepsini seçili, VPC default-us-west. Namespace Active olunca açıp Infrastructure Policies'in atandığını görüyorsunuz.

Sonra Services altında Virtual Machine servisinden + CREATE VM: Deploy from OVF, VM adı web-vm, Infrastructure Policy alanında backup ve disaster-recovery, image hol-ubuntu24, VM class best-effort-xsmall, DEPLOY VM.

VM Ready olunca nesne detayında iki policy'nin atandığını görüyorsunuz. vCenter'da web-vm'i aratıp açınca, Tags widget'ında vSphere tag'lerini ve Related Objects widget'ında dağıtım konumunu doğruluyorsunuz.

Policy değişince VM ne yapıyor?

Lab'ın en iyi gösterdiği şey bu. VM oluştuktan sonra Infrastructure Policy'yi düzenliyorsunuz: disaster-recovery'yi kaldırıp production'ı seçiyorsunuz, Save. vCenter'ı yenileyince disaster-recovery tag'inin yerini production tag'inin aldığını görüyorsunuz. Tag değiştiği için DRS, VM'i uygun bir host'a taşıyor. Monitor > Tasks altında Migrate virtual machine ve Reconfigure virtual machine görevlerini inceleyebiliyorsunuz.

Bunu görmek gerçekten iyiydi: policy değişikliği tag'e dönüşüyor, tag DRS'i tetikliyor, VM kendiliğinden taşınıyor. Ama aynı zamanda bir uyarı da: production'da bir policy düzenlemek, o policy'ye bağlı tüm VM'leri taşıyabilir. Kaç VM etkilenir, bunu düzenlemeden önce nasıl görürüm, taşıma sırasında ne olur, lab bunları cevaplamıyor. Üstelik lab'da DRS'i Fully Automated'a çekmemiz gerekti. Partially Automated olan bir ortamda bu akış aynı çalışmaz.

Service Framework

Son bölüm kısa. Provider portalındaki Service Management arayüzüyle, VCF Automation'ı Broadcom'un ve üçüncü tarafların sunduğu servislerle genişletebiliyorsunuz. Bir servis UI plugin'leri, service account'lar, Supervisor Service'ler, roller, rights bundle'lar, runtime defined entity'ler gibi birçok öğe içerebiliyor. İki tür servis var: VCF services (Broadcom'dan, örneğin VMware Data Services Manager ve Secret Store) ve partner services (dış üreticilerden).

Lab'da Service Management altında Secret Store Service'i buluyorsunuz ve Install diyorsunuz. Sertifikaları kabul ediyorsunuz, tüm region'lara ya da belirli region'lara dağıtmayı seçebiliyorsunuz (lab'da us-west), servis özelliklerini gözden geçiriyorsunuz (gerekirse elle değiştirilebiliyor) ve son adımda kurulumu tamamlamadan Cancel diyorsunuz.

Kılavuzun Secret Store tanımı: vSphere Supervisor ortamlarında secret yönetimi için merkezi bir servis. Supervisor ve VKS cluster'larla entegre, yöneticiler, DevOps mühendisleri ve uygulama kiracıları için rol tabanlı erişim sağlıyor, Kubernetes-native API'leri destekliyor.

Bu bölüm bir ekran turundan ibaret. Kurulumu tamamlamadığımız için servisin nasıl çalıştığını, yükseltmelerin nasıl yapıldığını, partner servislerin destek sınırlarını ve bir servis bozulduğunda ne olacağını göremiyoruz. Soru işaretlerim burada en fazla.

Genel olarak neler dikkatimi çekti

İlk olarak, bu modülün ana fikri self-service'i yönetilebilir hale getirmek. Namespace Self-Service, Capture ve Infrastructure Policies'in üçü de aynı yöne bakıyor: platform ekibi çerçeveyi çiziyor, kullanıcı o çerçevenin içinde kendi başına iş görüyor. Mantığını anlıyorum. Ama bu çerçevenin kurulumu lab'da hazır geliyor, yani asıl emeği göremiyoruz.

İkincisi, ön koşullar ve kısıtlar çok belirleyici. Capture için VM'lerin kapalı olması, tek VM Group, VKS'in dışarıda kalması, ISO ve çoklu VM OVA'nın desteklenmemesi. Bunları okumadan "ortamımı yakalayıp çoğaltırım" demek yanlış olur.

Üçüncüsü, Infrastructure Policy'lerde zincirin uzunluğu. Tag, compute policy, infrastructure policy, region quota. Her halka ayrı bir yerde ve muhtemelen ayrı bir ekibin elinde. Sorun çıktığında hangi halkada baktığınızı bilmek gerekecek.

Dördüncüsü, lab'ın göstermedikleri: mandatory policy'ler, DRS'in Fully Automated olmadığı durum, çoklu VM'li capture, Service Framework'ün işletme tarafı. Kılavuz bazılarını kendisi de "gelecek modül" diye erteliyor.

Son olarak, her zamanki gibi: bu yazıdaki her şey lab ortamında, küçük ve temiz bir kurulumda gördüklerime dayanıyor. Production'da ölçek ve alışkanlıklar işi değiştirir. Orada VCF Automation işletenler "şu aslında böyle olmuyor" derse öğrenmek isterim.

Gelecek hafta serinin son yazısı: kılavuzun 4. ve 5. modülleri. vSphere'de Memory Tiering, vSAN'da Global Deduplication, Effective Capacity Reporting ve Oracle RAC ile WSFC için Hot Extend.

VCF 9.1'de Neler Değişti? Yeni Menü, Health, Log Management ve Fleet Yönetimi (Modül 1)

Hakan İSMAİL — Mon, 05 Oct 2026 05:11:57 +0000

Bir süredir VMware tarafına bakmıyordum. vSAN HOL serisini bitirdikten sonra Proxmox'a geçtim, önce cluster ve Corosync, ardından Terraform ve Ansible ile otomasyon üzerine çalışıp bazı yazılar yazdım. Şimdi VMware HOL'a geri dönüyorum, çünkü katalog değişti.

VMware, HOL kataloğunu VCF 9.0'dan 9.1'e taşıdı ve 9.0 lab'larının (HOL-26xx) çoğunu kaldırdı. O yüzden yeni katalogdaki ilk lab olan HOL-2701-01-VCF-L (What's New in VCF 9.1: Highlights) ile baştan başlıyorum. Kılavuzda 5 modül var. Bu hafta ilk ikisini, yani arayüz değişikliklerini ve VCF Operations tarafını inceleyeceğim ve gördüklerimi aktaracağım. İlk 104 sayfa bu ikisine denk geliyor. Yazılarda "Modül" dediğim yer serinin haftalarını, "kılavuzun 2. modülü" dediğim yer ise PDF'in kendi bölümlerini anlatıyor, karışmasın diye ayırıyorum.

Her zamanki not: bu yazıyı sahadan değil, HOL ortamından yazıyorum. Production'da bir VCF fleet'i yönetmedim, yöneten birinin gözüyle bakamam. Ama lab'i bir sistemci gibi okumaya çalıştım. Yani "bu özellik harika" demek yerine "bunu gerçek bir ortamda açmadan önce ne sorardım" diye düşündüm. Yanlış anladığım yer olursa yorumlarda düzeltirseniz sevinirim.

Önce arayüz: dört ana başlık

VCF Operations'ın ana menüsü artık dört başlığa ayrılmış: Operate, Manage, Protect, Build. Lab'ın ilk modülü bu menülerin içinde dolaşmaktan ibaret. Uygulamalı bir iş yok, tur atıyorsunuz. Ama 9.0'dan geliyorsanız menülerin yerinin değişmesi ilk gün sizi en çok yoracak şey olabilir, o yüzden buraya vakit ayırmaya değer.

Operate günlük izleme ve sorun giderme tarafı. Overview altında Compute, Storage ve Network sayfaları var. Lab'a göre Compute yeni bir görünüm, Storage ve Network ise eski "Storage Operations" ve "Network Operations" sayfalarının yeniden adlandırılmış hali. Bunun dışında Inventory, Alerts, Dashboards ve Automation Central duruyor. Workbench'in yanına üç yeni parça eklenmiş: Metrics (özel sorgularla metrik analizi), Logs (entegre log ekranı) ve Flows (ağ akışı analizi). Findings, VCF Health ve Organizations da 9.1 arayüzünde yeni geçiyor. Business Applications ve Green Score da bu menüde.

Administration altında Configurations, Integrations, Cloud Proxies, SDDC Manager, Control Plane ve Global Settings var. Bu kısmı not alın, çünkü kılavuzun 2. modülündeki birçok ayar (log yönetimi, realtime metrik politikaları, access control) buraya düşüyor.

Manage fleet yönetimi: sertifikalar, şifreler, kimlik ve erişim, tag'ler, konfigürasyon yönetimi ve fleet ayarları (şifre politikası, DNS, NTP). Bunun yanında Capacity (Assess, Optimize, Plan), Cost (Showback, Chargeback, Bills) ve Licensing de burada. Lab bu üçüne sadece isim ve tek cümlelik açıklama düzeyinde değiniyor, içine girmiyor.

Protect altında Security Operations, Audit Records, Security Posture Management, Compliance ve Protection and Recovery var. İki küçük ayrıntı önemli: "Audit Events" artık Audit Records adını taşıyor, işlev aynı. "Compliance" bölümü ise 9.1'de kullanımdan kaldırılıyor ve Security Posture Management altına taşınıyor. Eski bir ortamda compliance ile uğraştıysanız ya da ona dayanan bir runbook yazdıysanız, bu değişiklik sizi doğrudan ilgilendirir.

Build altında Software Depot, Lifecycle ve Tasks var. Developer Center'da API & SDK'lar ile no-code çalışan Management Pack Builder bulunuyor. Sonradan göreceğiniz gibi realtime metriklerin altyapı bileşenleri de Build > Lifecycle altından açılıyor, yani "Build" sadece geliştirici menüsü değil, platformun kendi bileşenlerinin yönetildiği yer de.

Bu bölümdeki en büyük beklentim, 9.0'dan gelen biri için yerleri bulmayı kolaylaştıran bir eşleşme tablosu olurdu. Lab bunu vermiyor, sadece "şu yeni, şu yeniden adlandı" diyor. Yine de menü haritasını bilmek, kılavuzun 2. modülünü takip etmek için yeterli.

Health ve Diagnostics: artık sadece "host düştü mü" demiyor

Kılavuzun 2. modülünün ilk konusu bu. 9.0'da Diagnostic Findings ve VCF Health, "Infrastructure Operations" altındaydı. 9.1'de Operate sayfasının sol menüsüne doğrudan link olarak çıkmış. "Diagnostic Findings" sayfası da sadece Findings adını almış.

Findings Catalog sekmesinde sistemin tarattığı tüm kural imzaları listeleniyor. Lab yazıldığı sırada bu sayı 890'dı (lab, 9.0'a göre birkaç yüz fazla olduğunu söylüyor). Bunlar özellik ve log bazlı kurallar, Diagnostics Content Management Pack ile de yenileri ekleniyor. Filtreyle bileşene ve önem derecesine göre daraltabiliyorsunuz. Sayı kulağa etkileyici geliyor ama pratikte kritik olan kuralların ne kadar güvenilir ve ne kadar gürültülü çıktığı. Lab bunu ölçmüyor, çünkü ortam küçük ve kontrollü.

VCF Health tarafında iki görünüm var: VCF View ve Component View. VCF View, instance'tan başlayıp management domain, workload domain, vCenter, NSX, vSAN ve ESX host'a kadar inen hiyerarşiyi gösteriyor. Component View ise sertifika, NTP, DNS, vCenter, ESX, vSAN, NSX ve VCF Management Services için tile'lar sunuyor.

9.1'de gözüme en çok çarpan şey ESX Health tile'ı. 9.0'da yalnızca cevap vermeyen host'ları görüyordunuz. Şimdi bağlantı sorunları, servis sorunları, donanım sorunları, PSOD ve kullanım ayrı ayrı sayılıyor. Lab örneğinde 7 donanım sorunu ve 4 PSOD görünüyordu. Detaya girince host tablosunda "Hardware Status Check", "PSOD" ve "Tunnels" gibi sütunlarla hangi host'ta ne olduğunu görüyorsunuz. Sabah ilk baktığım yer bu olurdu.

İkinci yenilik vSAN Diagnostics. Sağlık sorunlarını Availability, Performance, Capacity ve Compliance başlıklarında topluyor. Lab'ın vSAN ortamında sorun yoktu, o yüzden bu ekranlar boş çıktı ve ne gösterdikleri sadece ekranın yapısından anlaşılıyor. Performance Insights sekmesinde ise gerçekten bir şey çalıştırdık: "Run New Diagnostics" ile hedefi (production kümede sorun giderme veya yeni kümede benchmark) seçiyorsunuz, kümeyi seçiyorsunuz (labda cluster-wld01-01a), zaman aralığını seçiyorsunuz (son bir saat) ve çalıştırıyorsunuz. Sorun çıkarsa vCenter'daki performans görünümüne ya da Operations içindeki cluster dashboard'una geçiş linki var. Sonucu ben de lab'da sadece gözle inceledim, anlamlı bir bulgu çıkmadı.

Bu da vSAN serisindeki Modül 2'yi hatırlattı, orada sağlık ve performansa vSphere Client'tan bakmıştık. Burada aynı soruları VCF Operations'tan soruyoruz.

Üçüncüsü NSX Instances tile'ı. Yönetim kümesi durumu, NSX Manager sağlık sorunları, kapasite sorunları, kullanım, Edge ve ESXi host ağ sorunları ayrı ayrı izleniyor. Lab'da iki NSX instance vardı. Büyük bir ortamda filtre kutusunun işe yarayacağını kılavuz da söylüyor. Son olarak VCF Management Services tile'ı var, lab'da 10 servis izleniyordu ve sorun yoktu.

Burada kılavuzda geçen bir cümleyi özellikle işaretlemek istiyorum: VCF Health, sadece VCF Installer ile kurulmuş ortamlarda çalışıyor. Sertifika ve konfigürasyon gibi merkezi veriyi bu yolla topluyor, bileşenleri elle eklenmiş ortamlarda bu veri yok. Sahada bir ortama sonradan eklenmiş ya da elle kurulmuş bileşenler olması çok normal. Bu kısıt, "VCF Health herkese yarar" beklentisini daraltıyor ve 9.1'e geçiş planı yaparken ilk kontrol edeceğim şey bu olurdu.

Realtime Metrics: 20 saniye ve 2 saniye

Realtime Metrics, belirli metrikler için 20 saniyelik, bazıları için 2 saniyelik veri noktaları getiriyor. Performans tepe noktalarını ve çukurlarını görmek için Workbench > Real Time Analysis altında bakılıyor. Kılavuza göre bu, yeni VCF management services'in bir parçası ve varsayılan olarak açık.

Lab'da zaten açıktı ama nasıl açıldığını da gösteriyor: Build > Lifecycle > VCF Management > Add Component ile OPS_DATA_PLATFORM ve VCFMS_METRICS_STORE bileşenleri ekleniyor. Yani bu özellik Operations'ın içinde bir anahtar değil, altında ek bileşenler çalıştırıyor.

Lifecycle > VCF Management, Add Component penceresi" width="800" height="352">

Kullanımı basit. Workbench'te bir nesne arıyorsunuz (lab'da ub3 adlı VM), Real Time Analysis'e giriyorsunuz ve üç sekme çıkıyor:

Overview: Seçtiğiniz metrik kategorisini (örneğin CPU) grafik olarak gösteriyor. Grafiği PDF olarak kaydedebiliyor, panoya kopyalayabiliyor veya Notes'a ekleyebiliyorsunuz.
Top N: Bir metrik seçip (lab'da VM Memory Consumed) çalıştırıyorsunuz, en yüksek nesneler listeleniyor.
Custom Query: Elle sorgu yazabiliyorsunuz ya da Quick Query Builder'ı kullanıyorsunuz. Sample Queries sekmesinde hazır örnekler var, mesela cpu.capacity.usage.HOST. Kılavuz her örneğin her nesneye uymayacağını da hatırlatıyor.

Varsayılan açılan paket Essential ve 856 realtime metrik içeriyor. Daha fazlası için Standard seti var. Bunu Operate > Administration > Configurations > Policy Definition altından politika üzerinden açıyorsunuz: Real Time Metrics'i düzenleyip vCenter için State'i "Activated" yapıyorsunuz. Host System için aynısını yaptığınızda ESX Top tarzı 2 saniyelik ESXi host metrikleri geliyor. Ayrıca Operate > Dashboards altında bir Real-time metrics Health dashboard'u var.

Gerçek ortamda bu bölümle ilgili sorularım şunlar: Saklama süresi ne kadar? Depolama ve kaynak maliyeti nedir? Tüm host'lar için 2 saniyelik veri açmak mantıklı mı, yoksa sadece sorun yaşayan küme için geçici mi açılmalı? Lab bunların hiçbirini cevaplamıyor ve ben de uydurmak istemiyorum. Bu sayıları sizlerden duymak isterim.

Security Posture Management

Protect > Security Posture Management, VCF bileşenlerini güvenlik benchmark'larına göre değerlendiren merkezi bir yer. Lab'daki hazır benchmark VCF 9 General Controls v1.0 ve 140 kural içeriyor. "View More" ile hangi bileşenden kaç kural geldiğini görüyorsunuz. "Browse More Benchmarks" ile ek benchmark'ları indirip kurabiliyorsunuz.

Benchmark'ın içine girince kuralları isme göre filtreleyebiliyorsunuz (lab'da "session timeout" yazdık), CSV'ye aktarabiliyorsunuz, açık değilse Enable Benchmark ile açıyor ve Run Assessment ile istediğiniz an çalıştırıyorsunuz. View Results'ta genel uyumluluk skoru, bileşen bazlı sonuç ve önem derecesine göre uyumsuz kural sayıları çıkıyor. Seçtiğiniz kurallar için Remediate, Export as CSV ve Generate Report aksiyonları var.

Lab'da hiçbir kuralı remediate etmedik, kılavuz da bunu açıkça yazıyor. "Tek tıkla düzeltme" kulağa hoş geliyor ama bir kurala tıklayınca ortamda tam olarak neyin değişeceğini, geri alınıp alınamayacağını ve bakım penceresi gerektirip gerektirmediğini görmeden production'da çalıştırmazdım. Lab bunu göstermediği için sadece "var" diyebiliyorum.

Bence bu bölümün en gerçekçi kısmı benchmark'ı klonlayıp düzenlemek. "VCF 9 General Controls v1.0"ı klonlayıp HOL VCF 9 General Controls v1.0 adıyla kaydettik. Sonra "login" araması yapıp "The vCenter server should meet max failed login attempts" kuralını Edit Rule ile açtık ve kural değerini değiştirebildiğimizi gördük. Kendi kurumunuzun politikası hazır benchmark'tan farklıysa (ki neredeyse hep farklıdır) hazır kuralı olduğu gibi kullanmanıza gerek yok. Kaydetmeden iptal ettik, o yüzden değiştirdiğimiz bir şey yok.

Log Management: Aria Operations for Logs'a veda

Bu bölüm 9.1'in en büyük mimari değişikliği gibi duruyor. Log Management artık VCF Operations'ın içinde. Aria Operations for Logs'un yerini alıyor, ayrı bir arayüz ve ayrı bir sanal appliance yok. Altında OpenSearch çalışıyor ve kılavuza göre daha ölçeklenebilir, hata durumlarına karşı daha dayanıklı. Content pack'ler kaldırılmış, içerik management pack'lerin içine alınmış. Deployment, patch, upgrade ve persistent volume boyutlandırma gibi yaşam döngüsü işleri de VCF management services akışına bağlanmış.

Mimaride üç parça var: Gateway Pod (Envoy, log kaynaklarından gelen trafiği karşılıyor), Log Processor (alma, sorgulama, maskeleme, yönlendirme, filtreleme ve partition işlerini yapıyor) ve Log Store (OpenSearch, indeksleme ve saklama). Hepsi VCF management services kümesi içinde çalışıyor.

Proxmox otomasyon serisinde rsyslog ile QRadar'a log göndermeyi, disk destekli kuyruğuyla birlikte kendim kurmuştum. Orada toplama, iletme ve kuyruk dayanıklılığı tamamen sizin işiniz. Burada bunların hepsi platformun içinde hazır geliyor. Bu rahatlık güzel, ama aynı zamanda o katmanı ne kadar ayarlayabildiğiniz ve QRadar gibi harici bir SIEM'e log yönlendirmenin nasıl olduğu sorusunu açıyor. Lab bunu göstermiyor.

Bir de log standardizasyonu var. Eskiden vCenter, ESX gibi ürünler kendi log formatlarını kullanıyordu (çoğu RFC 5424 syslog tabanlıydı). 9.1'de OpenTelemetry prensipleriyle uyumlu ortak bir format geliyor. Log'larla uğraşan biri için bu, ürünler arası arama ve parse etme işini ciddi biçimde kolaylaştırabilir. Ama mevcut Aria Operations for Logs'a yazdığınız sorgular, alarmlar ve dashboard'lar yeni yapıya nasıl taşınıyor, lab'da bunu göremedim.

Logs, Analyze Logs ekranı" width="800" height="352">

Lab'da gezdiğimiz yerler:

Log Collection: Administration > Configurations > Log Management altında. Log kaynaklarını, agent'ları, agent gruplarını ve entegre load balancer ayarlarını görüyorsunuz. Lab'da yalnızca VCF Operations için log toplama açıktı. Edit ile açınca log seviyesini (info, debug, warning, error) ve hangi log dosyalarının toplanacağını grup bazında ayarlayabiliyorsunuz. Agent sekmesinde tüm VCF bileşenlerinde agent'ın varsayılan olarak kurulu olduğunu ve otomatik agent yükseltmesini açıp kapatabildiğinizi görüyorsunuz. Agent'lar Linux'ta syslog ve cfapi protokolüyle çalışıyor, ayarları web arayüzünden ya da liagent.ini dosyasından yönetebiliyorsunuz.

Fields Library: Alanları indeksli ya da indekssiz yapabiliyorsunuz. İndeksli alanlar aramayı hızlandırıyor ama kılavuz, yeniden indekslemenin sistem performansını ve depolamayı geçici olarak etkileyebileceğini açıkça söylüyor. Lab'da bir alanı "Index Field" ile indeksledik. Kendi ortamımda hangi alanları indeksleyeceğime karar vermek için log hacmini bilmem gerekirdi, lab'da bunu test edemedik.

Arşivlenmiş log import: 9.1'de arşivlenmiş logları geri yükleyebiliyorsunuz, hem yeni Log Management arşivlerinden hem de eski Aria Operations for Logs arşiv konumlarından. Kılavuz iki önemli not düşüyor: Import küçük zaman aralıklarıyla yapılmalı, çünkü depolama %80'in üstüne çıkarsa görev başarısız oluyor. Ayrıca olay sonrası inceleme ve denetim için bu özellik değerli. Lab'da NFS ya da S3 deposu olmadığı için import'u gerçekten yapamadık, sadece formu açıp alanlara baktık (arşive isim, hedef harici depolama, arşiv yolu, zaman aralığı). Compare Logs ekranında import edilen arşivin nasıl görüneceğini de sadece anlatıyorlar.

Log Partition > Initiate New Log Import formu" width="800" height="352">

Access Control: Log verisi kümesine göre kapsam (scope) tanımlayabiliyorsunuz. Mesela bir kullanıcının sadece NSX loglarını görmesini sağlamak için. Lab'da Logs only errors adında bir scope oluşturup "Text – Contains – error" filtresi verdik. Gerçek bir senaryoda bu scope'u bir kullanıcıya atamanız gerekiyor, lab o adımı yapmıyor. Roller de log yetkilerini kapsayacak şekilde genişletilmiş. Rol düzenleme ekranı menü yapısını (Operate, Manage, Protect, Build) birebir yansıtıyor, hangi alt başlığa kimin erişeceğini seçiyorsunuz.

Scopes, " width="800" height="352">

sd_comp_id: Yeni formatla gelen bu alan, logları bileşene göre filtrelemeye yarıyor (ops, logs, vidb gibi). Lab'da vmsp, ops, logs ve vidb bileşenlerinden log geldiğini gördük.

Fleet Management

Son konu, Manage altındaki fleet yönetimi. Dört başlık var.

Kimlik ve erişim (IAM/SSO). Çok düğümlü bir Identity Broker, harici bir kimlik sağlayıcıyla (AD ya da LDAP) çalışıyor ve vCenter ile NSX gibi bileşenlerde SSO sağlıyor. Manage > Identity & Access > VCF SSO Overview altında akışı ve ön koşulları görüyorsunuz. Asıl yenilik VCF Roles: Tek tek vCenter, NSX, VCF Automation ve VCF Operations'a girip yetki tanımlamak yerine, yetkiyi VCF Operations'tan fleet geneline veriyorsunuz. Arkada bu roller her bileşendeki gerçek rollerle eşleşiyor. Hazır roller var, özel rol de oluşturabiliyorsunuz. Lab'da HOL-VCF-Default adında bir rol yarattık: vCenter için Administrator, VCF Operations için PowerUser seçtik. İki önemli ayrıntı var: VCF Roles kullanmak zorunlu değil, bileşen bazlı yetkilendirmeye devam edebilirsiniz. Ayrıca sadece 9.1 ve üstü sürümdeki bileşenler VCF rolü atamasını destekliyor.

Sertifikalar. Burada 9.1'in "toplu işlem" yeniliği var: Birden fazla sertifika için aynı anda CSR üretme, yenileme, import ve değiştirme. CA tarafında harici Microsoft CA ya da SDDC Manager üzerinde yapılandırılan OpenSSL seçilebiliyor. Kapsam geniş: VCF yönetim bileşenleri, VCF instance'ları (5.2 ve üstü) ve bağımsız vCenter ile ESXi host'ları (8.0 Update 3 ve üstü). Otomatik yenilemeyi açıp kapatabiliyorsunuz. Sertifika yenileme gerçek ortamda zaman kaybettiren, hata yapıldığında servis aksatan bir iş. Toplu yapabilmek burada gerçekten değer katar, ama lab'da bir yenileme çalıştırmadık, sadece ekranları ve seçenekleri gördük.

Şifre politikaları. Uzunluk, karmaşıklık, süre sonu, hesap kilitleme, değiştirme aralığı ve şifre geçmişi için merkezi politika tanımlıyorsunuz. Lab'da MaxExpiration adında hazır bir politika vardı ve Non Compliant görünüyordu. VCF Operations Component'ine tıklayınca beklenen değer ile mevcut değerin JSON olarak karşılaştırmasını görüyorsunuz. Kılavuz, VCF Operations'ın hazır, düzenlenebilir bir şifre politikasıyla gelmediğini, lab'daki politikanın örnek olarak eklendiğini özellikle belirtiyor. Create Policy ekranına bakıp iptal ettik.

Konfigürasyon yönetimi. vCenter instance'larının ve vSphere cluster'larının konfigürasyonunu bir şablonla karşılaştırıp drift (sapma) tespit ediyor. Lab'da HOL-vCenter-Template-1 adlı örnek bir şablon vardı. Şablonu açınca konfigürasyon öğelerini gezip JSON'da ilgili yere atlayabiliyor, indirip kopyalayıp düzenleyebiliyorsunuz. Drifts sekmesinde hangi vCenter'a kaç şablon atandığı (VCF Operations politikalarıyla) ve drift durumu görünüyor. Detect Drift ve Download Drifts Status Report aksiyonları var. Şifre politikasında olduğu gibi burada da kılavuz, şablonların hazır gelmediğini, lab için eklendiğini söylüyor. Yani bu özelliği kullanmak için önce kendi "doğru" konfigürasyonunuzu tanımlamanız gerekiyor ve işin asıl emeği orada.

Genel olarak neler dikkatimi çekti

Birkaç şey kafamda kaldı.

İlk olarak, 9.1'in ana fikri "her şey VCF Operations'ta" gibi görünüyor. Log, güvenlik, sertifika, şifre, kimlik, konfigürasyon, hepsi aynı arayüzde. Operasyon tarafında farklı araçlar arasında gezmek zaten yorucu bir iştir, bunu azaltma fikri çok mantıklı. Öte yandan her şeyin tek yerde toplanması, o tek yerin sağlıklı çalışmasına çok bağımlı olmak anlamına geliyor. Realtime metrikler, log yönetimi ve diğerleri VCF management services üzerinde koşuyor. Lab bu altyapının kaynak ihtiyacını, yedeğini ve bakımını anlatmıyor.

İkincisi, lab'ın "ilk açılışta hiçbir şey yok" durumunu göstermemesi. Şifre politikası, konfigürasyon şablonu ve çoğu benchmark hazır geliyor. Gerçek ortamda önce bunları kurmak, kendi standardınızı belirlemek gerekiyor ve işin büyük kısmı da bu.

Üçüncüsü, bazı özelliklerin ön koşulları var: VCF Health için VCF Installer kurulumu, VCF Roles için 9.1 ve üstü bileşenler, sertifika yönetimi için belirli sürüm aralıkları. Bunları okumadan "9.1'e geçince hepsi çalışır" diye düşünmek yanlış olur.

Son olarak, bu yazıdaki her şey lab ortamında, küçük ve temiz bir kurulumda gördüklerime dayanıyor. Production'da ölçek, gürültü ve alışkanlıklar işi değiştirir. Orada deneyimi olan biri "şu aslında böyle olmuyor" derse öğrenmek isterim.

Gelecek hafta serinin Modül 2'sinde, yani kılavuzun 3. modülünde VCF Automation'a geçiyorum: namespace self-service, infrastructure policy'ler ve service framework.

Bir Hafta Sonu Projesi: AWS EC2 Üzerinde V2Ray (3X-UI) ve Cloudflare WARP ile Datacenter IP Engellerini Aşmak

Hakan İSMAİL — Mon, 14 Sep 2026 06:30:46 +0000

Bu hafta sonu, elimde AWS Free Tier'ın verdiği 6 aylık (181 gün), 200 dolara kadar kredi ve basit bir sorunla oturdum: kendi proxy sunucumu kurmak istiyordum ama datacenter IP'lerin ChatGPT veya Netflix gibi servislerde nasıl engellendiğini de biliyordum. Bu yazı, o sorunu çözene kadar attığım adımları, karşılaştığım gerçek hataları ve onları nasıl çözdüğümü anlatıyor. Her komut, kendi terminalimden aldığım gerçek çıktılarla birlikte.

Kurulum, CachyOS (Arch Linux tabanlı) bir istemci üzerinden AWS EC2'ye SSH ile bağlanılarak gerçekleştirildi.

Adım 1: AWS EC2 ve SSH Kurulumu

İlk adım AWS konsolundan uygun bir sunucu ayağa kaldırmaktı. AWS konsoluna girip EC2 (Elastic Compute Cloud) altında launch instance dedim.

Burada direkt olarak bana "getting started walkthroughs" önerdi. Fakat ne yaptığımı bildiğim için "Launch without a walkthrough" seçeneğini seçtim.

Evet, burada bizi AWS'nin "Launch an instance" konfigürasyon arayüzü karşıladı. Ben burada bütçe dostu bir çözüm aradığım için, kredi havuzumu az tüketen t3.micro instance tipini seçili bıraktım. İşletim sistemi olarak da Ubuntu 26.04 LTS'i seçtim. İkisi de Free Tier eligible olarak işaretliydi.

Daha sonrasında ise login için Key Pair istedi. Burada "yeni bir key pair oluştur" dedim:

Burada anahtarımın .pem uzantılı olduğuna dikkat ettim, çünkü SSH bağlantısında bu formatı kullanacaktım. Sonrasında anahtarı bilgisayarıma indirdi.

Daha sonrasında ise AWS Network ayarlarında şu Firewall (security groups) kurallarını tanımladım:

SSH (Port 22) - My IP
HTTP (Port 80) - Anywhere (panel erişimi için, sonradan kapatılacak)
HTTPS (Port 443) - Anywhere (V2Ray bağlantısı için)

Kısaca konfigürasyonum bu şekildeydi; advanced ayarlara falan gerek yoktu. Sadece AWS'de çalışan, internete açık bir IP'si olan (CGNAT arkasında değil) ve fazla kaynak gerektirmeyen basit bir makine yeterliydi. Bu arada "Launch instance"a basmadan önce gözüme takılan çok güzel bir özellik vardı: Preview Code.

Burada, instance hazırlanırken hangi komutların CLI üzerinden çalıştırılacağını gösteriyor. Daha da güzeli, formatı değiştirerek diğer dillerde nasıl kullanılacağını da gösteriyor, örneğin Python SDK için:

Otomasyon script'leri yazarken cidden işe yarayacak bir özellik.

Şimdi ise launch instance diyelim ve makinemizi AWS tarafından oluşturmaya bırakalım (kısa bir süre):

5 sn falan sürdü.

İlk dashboard izlenimi:

Benim aşırı fazla bir AWS kullanmışlığım veya bununla ilgili detaylı çalışmalarım yok ama aradığım şeylerin (örneğin IPv4 ve instance state) ve diğer monitoring, security gibi sekmelerin direkt olarak beni karşılaması işimi kolaylaştırdı.

İstemciden sunucuya ilk bağlantı denemesi:

İndirdiğim anahtarla (Downloads klasöründen) giriş yaptım:

ssh -i ~/Downloads/aws-key.pem ubuntu@54.93.233.182

İlk bağlantıda bilinen hostlar listesine ekleme onayı istendi, giriş sorunsuz sağlandı:

The authenticity of host '54.93.233.182 (54.93.233.182)' can't be established.
ED25519 key fingerprint is: SHA256:xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Welcome to Ubuntu 26.04 LTS (GNU/Linux 7.0.0-1006-aws x86_64)

Evet. Uzak EC2 makinemizin içindeyiz. Artık kuruluma geçebiliriz.

Adım 2: 3X-UI Panel Kurulumu ve İlk Engeller

Sunucuya girdikten sonra root yetkisi aldım ve 3X-UI (V2Ray/Xray yönetim paneli) kurulum script'ini çalıştırdım:

sudo su -
bash <(curl -Ls https://raw.githubusercontent.com/mhsanaei/3x-ui/master/install.sh)

Kurulum sırasında veritabanı olarak SQLite'ı seçtim. Büyük bir veritabanı yöneticisine ihtiyacım yoktu.

═══════════════════════════════════════════
     Database Selection
═══════════════════════════════════════════
  1) SQLite     (default — recommended for < 500 clients)
  2) PostgreSQL (recommended for high client counts / many nodes)
Choose [1]: 1

Panel portu özelleştirme sorusuna y yanıtı verip port 80 olarak ayarladım.

Would you like to customize the Panel Port settings? (If not, a random port will be applied) [y/n]: y
Please set up the panel port: 80
Your Panel Port is: 80
Port set successfully: 80
Username and password updated successfully
Base URI path set successfully

Kurulumun son aşamasında SSL kurulumu soruldu:

═══════════════════════════════════════════
     SSL Certificate Setup (RECOMMENDED)
═══════════════════════════════════════════
SSL is strongly recommended. Skip only if a reverse proxy
or SSH tunnel handles TLS for you.
Let's Encrypt now supports both domains and IP addresses!

Choose SSL certificate setup method:
1. Let's Encrypt for Domain (90-day validity, auto-renews)
2. Let's Encrypt for IP Address (6-day validity, auto-renews)
3. Custom SSL Certificate (Path to existing files)
4. Skip SSL (advanced — behind reverse proxy / SSH tunnel only)
Note: Options 1 & 2 require port 80 open. Option 3 requires manual paths.
Note: Option 4 serves the panel over plain HTTP — only safe behind nginx/Caddy or an SSH tunnel.
Choose an option (default 2 for IP): 4

⚠ Panel will be installed WITHOUT SSL/TLS.
Login credentials and cookies will travel as plain HTTP.
Only safe when:
  • A reverse proxy (nginx, Caddy, Traefik) terminates TLS for you, or
  • You access the panel exclusively via SSH tunnel

SSL'i atladım (4). Ama script, panelin 127.0.0.1'e mi bağlanacağını da sordu:

Bind the panel to 127.0.0.1 only? (recommended — forces SSH tunnel / reverse-proxy access) [y/N]: N

Burada N seçtim. Nedeni, ilk aşamada paneli tarayıcıdan test etmek istememdi; y deseydim panele sadece SSH tüneli ile erişilebilecekti, bu da ilk hatayı tespit etmeyi zorlaştıracaktı.

Karşılaşılan Hata: 404 Not Found

Tarayıcıdan http://54.93.233.182 adresine gittiğimde karşılama ekranı yerine 404 Not Found hatası aldım.

Gözlem ve Tespit: 3X-UI'nin son sürümleri, güvenlik gereği paneli ana dizine (/) değil, rastgele oluşturulmuş gizli bir yola (webBasePath) kuruyor. Ana IP'ye girince 404 vermesi bir hata değil, bir güvenlik özelliği.

Gizli yolu bulmak için terminalden panel ayarlarını sorguladım:

x-ui settings

Çıktı şu şekilde geldi:

[INF] current panel settings as follows:
port: 80
webBasePath: /mubjbN3SXSEBOdEhtd/

Tarayıcı adresini http://54.93.233.182/mubjbN3SXSEBOdEhtd/ olarak güncelledim ve panele başarıyla girdim.

Ama giriş ekranı geldikten sonra bir sorun vardı. Kurulum yaparken bana kullanıcı adı ve şifre için sorular sormamıştı!

Bunun için panel ayarlarını açtım:

root@ip-172-31-38-106:~# x-ui
The OS release is: ubuntu

╔────────────────────────────────────────────────╗
│  3X-UI Panel Management Script                │
│  0. Exit Script                               │
│────────────────────────────────────────────────│
│  1. Install                                   │
│  2. Update                                    │
│  3. Update to Dev Channel (latest commit)     │
│  4. Update Menu                               │
│  5. Legacy Version                            │
│  6. Uninstall                                 │
│────────────────────────────────────────────────│
│  7. Reset Username & Password                 │
│  8. Reset Web Base Path                       │
│  9. Reset Settings                            │
│  10. Change Port                              │
│  11. View Current Settings                    │
│────────────────────────────────────────────────│
│  12. Start                                    │
│  13. Stop                                     │
│  14. Restart                                  │
|  15. Restart Xray                             │
│  16. Check Status                             │
│  17. Logs Management                          │
│────────────────────────────────────────────────│
│  18. Enable Autostart                         │
│  19. Disable Autostart                        │
│────────────────────────────────────────────────│
│  20. SSL Certificate Management               │
│  21. Cloudflare SSL Certificate               │
│  22. IP Limit Management                      │
│  23. Firewall Management                      │
│  24. SSH Port Forwarding Management           │
│  25. PostgreSQL Management                    │
│────────────────────────────────────────────────│
│  26. Enable BBR                               │
│  27. Update Geo Files                         │
│  28. Speedtest by Ookla                       │
╚────────────────────────────────────────────────╝

Panel state: Running
Start automatically: Yes
xray state: Running

Please enter your selection [0-28]: 7

Are you sure to reset the username and password of the panel? [Default n]: y
Please set the login username [default is a random username]: ********
Please set the login password [default is a random password]: ********
Do you want to disable currently configured two-factor authentication? (y/n): n
Panel login username has been reset to:  ******** 
Panel login password has been reset to:  ******** 
 Please use the new login username and password to access the X-UI panel. Also remember them! 

Restart the panel, Attention: Restarting the panel will also restart xray [Default y]: 
[INF] x-ui and xray Restarted successfully 

Press enter to return to the main menu: 

╔────────────────────────────────────────────────╗
│  3X-UI Panel Management Script                │
│  0. Exit Script                               │
│────────────────────────────────────────────────│
│  1. Install                                   │
│  2. Update                                    │
│  3. Update to Dev Channel (latest commit)     │
│  4. Update Menu                               │
│  5. Legacy Version                            │
│  6. Uninstall                                 │
│────────────────────────────────────────────────│
│  7. Reset Username & Password                 │
│  8. Reset Web Base Path                       │
│  9. Reset Settings                            │
│  10. Change Port                              │
│  11. View Current Settings                    │
│────────────────────────────────────────────────│
│  12. Start                                    │
│  13. Stop                                     │
│  14. Restart                                  │
|  15. Restart Xray                             │
│  16. Check Status                             │
│  17. Logs Management                          │
│────────────────────────────────────────────────│
│  18. Enable Autostart                         │
│  19. Disable Autostart                        │
│────────────────────────────────────────────────│
│  20. SSL Certificate Management               │
│  21. Cloudflare SSL Certificate               │
│  22. IP Limit Management                      │
│  23. Firewall Management                      │
│  24. SSH Port Forwarding Management           │
│  25. PostgreSQL Management                    │
│────────────────────────────────────────────────│
│  26. Enable BBR                               │
│  27. Update Geo Files                         │
│  28. Speedtest by Ookla                       │
╚────────────────────────────────────────────────╝

Panel state: Running
Start automatically: Yes
xray state: Running

Please enter your selection [0-28]: 0
root@ip-172-31-38-106:~#

Ve evet, kullanıcı adı ve parolayı sıfırlayarak kendim yeni kullanıcı adı ve parola tanımladım! Ve web arayüzüne giriş yaptığımda beni çok güzel bir arayüz karşıladı:

Ve artık VLESS + WebSocket Inbound kurulumuna geçebiliriz!

Adım 3: VLESS + WebSocket Inbound Oluşturma

Panele girdikten sonra bağlantıları karşılayacak Inbound kuralını oluşturmamız gerekti. GUI'deki sol menüden Inbounds'u açtım:

"Add Inbound" ekranında "Stream" sekmesine geçtiğimde "Transmission" kısmı varsayılan olarak RAW (TCP) geliyordu. Arayüzden bunu ws (WebSocket) yapmak ve Host eklemek bazen karmaşık olabiliyor.

Gerçek Hata ve Çözüm: GUI üzerinden ayarları değiştirmeye çalıştığımda arayüz bazen değişiklikleri tam yansıtmadı. En kesin ve hatasız yöntemin "Advanced" sekmesinden JSON config'i doğrudan düzenlemek olduğuna karar verdim.

Advanced (JSON) Config:

{
  "listen": "",
  "port": 443,
  "protocol": "vless",
  "tag": "in-443-ws",
  "settings": {
    "clients": [],
    "decryption": "none",
    "encryption": "none"
  },
  "sniffing": {
    "enabled": true,
    "destOverride": [
      "http",
      "tls"
    ]
  },
  "streamSettings": {
    "network": "ws",
    "security": "none",
    "wsSettings": {
      "path": "/",
      "headers": {
        "Host": "hakanismail.info"
      }
    }
  }
}

Not: security: none seçmemin sebebi, sunucuda henüz SSL sertifikası olmaması. Trafik şifrelenmiş (TLS) bir port üzerinden değil, ham WebSocket (HTTP upgrade) üzerinden taşınacak.

Inbound'u kaydettikten sonra "Clients" kısmından bir kullanıcı oluşturdum ve sağlanan bağlantı QR'ı ile Arch Linux üzerindeki v2rayN istemcisinden bağlantı sağladım. vless:// linki ile bağlantı sağlanabilir fakat QR kod daha kolay oldu.

QR kodda önemli bir detay var: iki tane QR kodu var. "Subscription Info" QR'ı bağlantı için kullanılmaz. Bağlantı için kullanmamız gereken, "Vless WS (Arch-Linux:443)" etiketli QR.

Bağlantıyı ekledikten sonra alttaki anahtarı "Clear system proxy" konumundan "Set system proxy" konumuna çekiyoruz ve bağlantı sağlanıyor.

whatismyip.com üzerinden IP'nin Almanya (AWS) olduğunu teyit ettim.

Adım 4: Güvenlik (Panelin Dış Dünyaya Kapatılması)

Sistem çalışır durumdaydı ama 3X-UI paneli (80 portu) tüm dünyaya açıktı. İnternetteki botlar IP'yi tarayıp paneli kötüye kullanmaya çalışabilir. Çözüm, AWS güvenlik duvarından 80 portunu kapatmak ve panele sadece SSH tüneli ile girmekti.

1. AWS Security Group Kuralını Sildim

AWS konsolundan EC2 → seçili sanal makine → Security sekmesi → Security Groups altındaki tek security grup → Inbound rules kısmına gittim. HTTP (Port 80) kuralını listeden sildim. Artık http://54.93.233.182 adresine dışarıdan kimse erişemiyor.

2. SSH Tüneli (Local Port Forwarding) Kurdum

Arch Linux terminalinden şu komutu çalıştırdım:

ssh -i aws-key.pem -L 8080:127.0.0.1:80 ubuntu@54.93.233.182

Bu komut, yerel makinenin 8080 portunu, SSH bağlantısı üzerinden sunucunun iç ağındaki 127.0.0.1:80 adresine gizlice yönlendirdi.

3. Test

SSH tüneli açıkken tarayıcıya şu adresi girdim: http://127.0.0.1:8080/mubjbN3SXSEBOdEhtd/panel/. Panel sorunsuz açıldı.

Dış IP üzerinden denediğimde ise bağlantı zaman aşımına uğradı (Timeout). Sunucu güvenliği sağlandı.

Adım 5: Cloudflare WARP Entegrasyonu

Şu anda IP'm 54.93.233.182 (Amazon). ChatGPT veya Netflix gibi servisler, trafiğin bir veri merkezinden geldiğini anlayıp erişimi reddedebilir. Bu, film izlerken veya agentik iş yaparken can sıkıcı olabiliyor. Bunu aşmak için AWS sunucusunun içine Cloudflare WARP kurdum. WARP, trafiği Cloudflare'in residential IP havuzundan, yani son kullanıcı IP'lerinden çıkarıyor.

1. WARP Kurulumu

AWS sunucusuna SSH ile bağlanıp root oldum. Cloudflare deposunu ekledim ve paketi kurdum:

curl -fsSL https://pkg.cloudflareclient.com/pubkey.gpg | sudo gpg --yes --dearmor --output /usr/share/keyrings/cloudflare-warp-archive-keyring.gpg
echo "deb [signed-by=/usr/share/keyrings/cloudflare-warp-archive-keyring.gpg] https://pkg.cloudflareclient.com/ $(lsb_release -cs) main" | sudo tee /etc/apt/sources.list.d/cloudflare-client.list
apt update && apt install cloudflare-warp -y

2. Kayıt ve Proxy Modu

WARP'ı tüm sunucu trafiğini kesmeyecek, sadece yerel bir SOCKS5 proxy (port 40000) olarak çalışacak şekilde ayarladım:

warp-cli registration new
# (Kullanım şartları kabul edildi: y)

warp-cli mode proxy
# Success

warp-cli connect
# Success

3. Test ve Karşılaşılan Garip Çıktı

WARP'ın çalışıp çalışmadığını test etmek için standart trace komutunu kullandım:

curl https://www.cloudflare.com/cdn-cgi/trace/

İlginç bir şekilde ekrana HTML olarak 404 Not Found düştü. Bu adresin kendisi bozuk değildi; muhtemelen cloudflare.com'un kendi sitesine özgü bir bot koruması ya da redirect davranışıydı, WARP veya AWS IP'siyle doğrudan ilgisi yoktu.

Bunun yerine Cloudflare'in tam olarak bu iş için var olan tanılama adresini denedim:

curl https://1.1.1.1/cdn-cgi/trace

fl=928f31
h=1.1.1.1
ip=54.93.233.182
ts=1788933479.000
visit_scheme=https
uag=curl/8.18.0
colo=FRA
sliver=050-tier1
http=http/2
loc=DE
tls=TLSv1.3
sni=off
warp=off
gateway=off
rbi=off
kex=X25519MLKEM768

warp=off görünce şüphelendim, çünkü WARP zaten bağlıydı. Emin olmak için bağlantıyı kesip tekrar bağladım ve her seferinde aynı komutu tekrarladım:

root@ip-172-31-38-106:~# warp-cli disconnect
Success
root@ip-172-31-38-106:~# curl https://1.1.1.1/cdn-cgi/trace
...
warp=off

root@ip-172-31-38-106:~# warp-cli connect
Success
root@ip-172-31-38-106:~# warp-cli status
Status update: Connected
Network: healthy
root@ip-172-31-38-106:~# curl https://1.1.1.1/cdn-cgi/trace
...
warp=off

warp-cli status "Connected" ve "healthy" dese bile çıktı hep warp=off kaldı.

Gerçek Durum: WARP'ı proxy moduna aldığım için varsayılan ağ yönlendirmesine hiç müdahale etmiyor. curl gibi düz bir istek WARP'a hiç girmeden direkt AWS ağından çıkıyor; WARP yalnızca açıkça kendisine yönlendirilen (SOCKS5 üzerinden gelen) trafiği görüyor. Bu artık hipotez değil, connect/disconnect döngüsüyle doğrulanmış bir gözlem.

Bunu kanıtlamak için, az önceki testle birebir aynı komutu bu kez WARP'ın SOCKS5 portu üzerinden çalıştırdım:

curl -x socks5h://127.0.0.1:40000 https://1.1.1.1/cdn-cgi/trace

Not: socks5h kullanmak önemli (düz socks5 değil), çünkü h DNS çözümlemesini de proxy üzerinden yaptırıyor.

fl=470f261
h=1.1.1.1
ip=104.28.197.9
ts=1788933795.000
visit_scheme=https
uag=curl/8.18.0
colo=FRA
sliver=010-tier1
http=http/2
loc=DE
tls=TLSv1.3
sni=off
warp=on
gateway=off
rbi=off
kex=X25519MLKEM768

Fark net: ip artık AWS'e ait 54.93.233.182 değil, Cloudflare'e ait 104.28.197.9; warp alanı da off'tan on'a döndü. WARP'ın çalıştığı, sadece varsayılan yönlendirmeye dahil olmadığı bu şekilde kanıtlandı.

4. 3X-UI Panelinden Yönlendirme (Routing)

WARP kuruldu ama V2Ray trafiği hâlâ AWS'in normal internetinden çıkıyordu. 3X-UI panelinden (SSH tüneli ile girdim), Panel Settings → Xray Configuration kısmındaki JSON config'i güncelledim.

outbounds dizisine WARP için bir SOCKS çıkışı ekledim:

{
  "tag": "warp",
  "protocol": "socks",
  "settings": {
    "servers": [
      {
        "address": "127.0.0.1",
        "port": 40000
      }
    ]
  }
}

routing → rules kısmına ise tüm trafiği bu WARP'a yönlendirecek kuralı yazdım:

{
  "type": "field",
  "outboundTag": "warp",
  "network": "tcp,udp"
}

Ayarları kaydedip Xray'i yeniden başlattım.

5. Final Testi

v2rayN istemcisinden bağlantıyı kesip tekrar bağlandım. whatismyip.com adresine girdim:

Yeni IPv4: 104.28.197.14 (Cloudflare)
Yeni IPv6: 2a09:bac1:1e20:8::3a2:d (WARP)

Merakımdan, WARP'ı devre dışı bırakıp chat.openai.com adresine direkt AWS IP'si üzerinden de gittim. Beklediğimin aksine herhangi bir hata almadan, sorunsuz açıldı; yani ChatGPT bu spesifik AWS IP'sini o an engellemiyordu. Bu da datacenter IP engellerinin ne kadar tutarsız olduğunu gösteriyor: hangi IP'nin hangi serviste ne zaman engelleneceği önceden kestirilemiyor (Netflix gibi bölge kilidine çok daha sıkı yaklaşan servislerde durum farklı olabilir, ama bunu ayrıca test etmedim). WARP'ın buradaki asıl faydası "aktif bir engeli aşmak" değil, IP'nin görünümünü baştan residential seviyeye çekip bu riski azaltmaktı.

Kapanış ve Gözlem

Bir hafta sonuna sığan bu lab çalışmasında, standart bir VPS'in nasıl güvenli bir proxy sunucusuna dönüştürüleceğini test ettim. Çıkardığım en önemli dersler:

GUI bazen istenen network ayarlarını tam yansıtmayabilir; JSON config'i doğrudan düzenlemek çok daha güven verici.
Bir servisi (WARP gibi) sistem geneline yaymak yerine local proxy modunda çalıştırıp ana proxy yazılımının (Xray) routing kurallarıyla yönetmek, hata ayıklamayı inanılmaz kolaylaştırıyor.
Yönetim panellerini (3X-UI gibi) dış dünyaya açmamak, SSH local forwarding ile erişmek en sağlam sunucu güvenliği yöntemi.
Datacenter IP engelleri servise göre çok değişken ve garantili değil; bu testte ChatGPT AWS IP'mi hiç engellemedi. WARP'ın buradaki kazancı "aktif bir engeli aşmak" değil, IP'nin görünümünü residential seviyeye çekip bu riski önceden azaltmaktı.

Proxmox Otomasyon Serisi Faz 3: Zabbix Agent 2 (7.0 LTS), Rsyslog (QRadar TCP ve Disk Destekli Kuyruk) ve Güvenlik Ajanları

Hakan İSMAİL — Thu, 10 Sep 2026 12:08:11 +0000

Bu rehber, Proxmox Otomasyon Serisi'nin dördüncü modülüdür ve tamamlanmış bir altyapı fazının üzerine inşa edilen ilk katmandır. Faz 2; seri numaralarıyla etiketlenmiş disklerin LVM ve XFS katmanlarından geçirilip bağlanması, çalışan makinede kesintisiz disk genişletme, VM açılışında kalıcılığını kanıtlayan reboot testleri ve aygıt harfleri (sdb, sde...) tamamen yer değiştirdiğinde dahi sistemin ayakta kaldığını gösteren saha oturumlarıyla kapatılmıştı.

Makineler mevcut, veriyi tutuyor ve reboot sonrasında sorunsuz ayağa kalkıyor. Bu noktada ana soru değişir: Artık soru "makine ayakta mı?" değil, "makinenin içinde neler oluyor?" sorusudur. Bu sorunun yanıtı konuk (guest) makinenin dışından verilir; bu yanıtın makine içindeki ayağı ise her zaman bir ajandır (agent).

Faz 3, provizyon edilen her sanal makineye üç temel ajan rolü kazandırır:

İzleme Ajanı (Monitoring): Merkezi bir sunucunun makineyi kontrol edebilmesi için resmi 7.0 LTS deposuna sabitlenmiş Zabbix Agent 2.
Log Yönlendirme (Logging): Makinenin tüm sistem loglarını kurumsal QRadar mimarisine uygun şekilde TCP üzerinden ve disk destekli bir kuyruk mekanizmasıyla dışarı aktaran rsyslog yapılandırması.
Güvenlik Ajanları (Security): Homelab ortamında lisanslanması mümkün olmayan kurumsal güvenlik yazılımlarını (Trend Micro Deep Security ve ManageEngine) simüle eden, bir belirteç sözleşmesi (marker contract) arkasında çalışan stub yükleyiciler.

Her üç bileşen de serinin felsefesine sadık kalınarak; numaralandırılmış, bağımsız, idempotent, tek bir değişken dosyasından beslenen ve yeşil recap çıktısı vermeden önce kendi yaptıklarını bizzat doğrulayan Ansible playbook'ları olarak dağıtılır.

Faz 3'de ne var?

Planlama aşamasında community rolleri, bir Graylog konteyneri ve basit echo komutlarıyla çalışan sahte betikler düşünülmüştü. Canlıya alınan mimarideki sapmalar birer taviz değil; saha testlerinin getirdiği teknik zorunluluklardır:

İlk Planlanan	Canlıya Alınan	Teknik Gerekçe
`community.zabbix.zabbix_agent` rolü	Özel `04_zabbix_agent.yml` playbook'u	Ubuntu 26.04 için resmi 7.0 LTS deposu zorunluluğu; kontrol düğümüne koleksiyon kurmadan `ansible.builtin` içinde kalma hedefi.
Ayrı Zabbix sunucusu VM'i (Docker, 4 GB)	`ctrl-01` üzerinden `zabbix-get` doğrulaması	Bu fazın teslimatı sunucu değil ajandır. Soket sorgusu tüm yolu kanıtlar; sunucu isteğe bağlı hafif LXC'ye bırakıldı.
Graylog konteyneri / tam rsyslog sunucusu	`ctrl-01` üzerinde tek satırlık `socat` dinleyicisi	QRadar TCP desenini test eden en hafif uç nokta. Altyapıyı şişirmeden kuyruk akışını tam doğrular.
`. @@receiver:514` (tek satır yönlendirme)	Disk destekli kuyruğa sahip `omfwd` aksiyonu	Tek satırlık kural hedef kapandığında log düşürür. Kuyruk mekanizması hedef gelene kadar logları diske depolar.
Basit kabuk betikleri (`touch /opt/...`)	Sürüm sapma alarmlı marker sözleşmesi	Yükleyici iskeleti prodüksiyon standardındadır; yarın lisans geldiğinde yalnızca yükleme gövdesi güncellenir.

Dizin Ağacı ve Dosya Rolleri

ansible/
├── inventory/group_vars/
│   └── provisioned.yml             # Ajan değişkenleri ayrıştırıldı, sadece depolama şeması kaldı
├── playbooks/
│   ├── vars/
│   │   └── agent-layer.yml         # Ajan katmanının tek gerçek kaynağı (Single Source of Truth)
│   ├── tasks/
│   │   └── wait_for_apt.yml        # İlk açılış dpkg/apt kilit yarışını çözen geçit görevi
│   ├── templates/
│   │   ├── zabbix_agent2.conf.j2   # Dinamik ajan yapılandırma şablonu
│   │   ├── 50-qradar-forward.conf.j2 # Disk kuyruklu rsyslog yönlendirme şablonu
│   │   └── install.sh.j2           # Marker sözleşmesine bağlı stub yükleyici
│   ├── 04_zabbix_agent.yml         # Zabbix kurulum ve 5 adımlı doğrulama playbook'u
│   ├── 05_rsyslog_forward.yml      # Log yönlendirme ve sözdizimi doğrulama playbook'u
│   └── 06_security_agents.yml      # Güvenlik ajanları stub dağıtımı ve drift denetimi

Kapsam Sınırları

Kapsam İçi: Zabbix Agent 2'nin resmi 7.0 LTS reposundan pini, disk destekli TCP rsyslog kuyruğu, lisanslı ajanlar için marker sözleşmeli stub altyapısı, ctrl-01 üzerinde oturum bağımsız dinleyici ve saha doğrulamaları.
Kapsam Dışı: Prodüksiyon QRadar / Zabbix sunucu kurulumları, TLS sertifika yönetimi, log ayrıştırma kuralları ve alarm dashboard'ları (bu katmanın tek amacı misafir makinedeki ajan omurgasını ayağa kaldırmaktır).

Zabbix Agent 2: Sürüm Sabitleme ve Doğrulama

İzleme tarafında klasik Zabbix ajanı yerine Go ile yeniden yazılan Zabbix Agent 2 tercih edildi. Klasik ajan her metrik için yeni bir alt süreç (fork) açarak kaynak tüketirken, Agent 2 eklenti mimarisi ve kalıcı tek bir TCP bağlantısı üzerinden aktif kontrolleri yürütür.

Neden Community Değil?

Resmi Depo Sabitlemesi: Ubuntu 26.04 (resolute) için kararlı paket sağlayan güncel ana dal 7.0 LTS serisidir. Üçüncü taraf bir rolün varsayılan değişkenlerine güvenmek yerine bu bağımlılık doğrudan kod içinde sabitlendi.
Sıfır Dış Bağımlılık: Kontrol düğümüne harici Ansible Galaxy koleksiyonları eklenmedi, tüm akış ansible.builtin modülleriyle çözüldü.
Operasyonel Şeffaflık: Arka planda onlarca task çalıştıran soyut roller yerine, her komutun ve doğrulamayı yapan assertion'ların net izlenebildiği yalın bir yapı kuruldu.

Canlı Depo Kontrolü ve Apt Seçimi (Election)

Resmi repo doğrudan sorgulandığında 7.0 LTS paketinin erişilebilir olduğu, 8.0 paketinin ise henüz Ubuntu 26.04 için derlenmediği teyit edildi:

$ curl -sI https://repo.zabbix.com/zabbix/7.0/ubuntu/dists/resolute/Release | head -1
HTTP/2 200 # 7.0 LTS paketi yayında

$ curl -sI https://repo.zabbix.com/zabbix/8.0/ubuntu/dists/resolute/Release | head -1
HTTP/2 404 # 8.0 ana sürümü henüz bu dağıtım için yok

Ubuntu Universe deposunda 7.0.22 sürümü yer alırken, resmi repo.zabbix.com üzerinde güncel 7.0.30 paketi bulunur. Paket yöneticisi (apt) yüksek sürüm numarasına sahip resmi depoyu seçer; ancak playbook bu varsayımla yetinmeyip apt-cache policy zabbix-agent2 çıktısını kontrol ederek paketin resmi repodan geldiğini ve 7.0 ailesinde kaldığını doğrular.

Kurulum Görevleri ve `lock_timeout` Ayrımı

İşlem sırası kritiktir: GPG anahtarı repo tanımından önce diske yazılmalıdır; aksi halde apt_repository anında tetiklediği güncellemede imzasız repo hatasıyla süreci kırar.

- name: Create the apt keyrings directory
  ansible.builtin.file:
    path: /etc/apt/keyrings
    state: directory
    mode: "0755"

- name: Install the Zabbix official repo signing key
  ansible.builtin.get_url:
    url: https://repo.zabbix.com/zabbix-official-repo.key
    dest: /etc/apt/keyrings/zabbix-official-repo.asc
    mode: "0644"

- name: Wait out the first-boot apt race before touching packages
  ansible.builtin.include_tasks: tasks/wait_for_apt.yml

- name: Add the pinned Zabbix apt repository
  ansible.builtin.apt_repository:
    repo: >-
      deb [signed-by=/etc/apt/keyrings/zabbix-official-repo.asc]
      https://repo.zabbix.com/zabbix/{{ zabbix_agent_version }}/ubuntu
      {{ ansible_facts['distribution_release'] }} main
    filename: zabbix-official-repo
    state: present

- name: Install Zabbix Agent 2
  ansible.builtin.apt:
    name: zabbix-agent2
    state: present
    lock_timeout: 1800

Saha Dersi (Bulgu #19): İlk pipeline denemesinde apt_repository adımına eklenen lock_timeout: 1800 parametresi görevi çökertti (Unsupported parameters for apt_repository module). Bu parametre yalnızca apt modülüne aittir. Kilit koruması wait_for_apt.yml geçidiyle çözüldüğü için parametre repo görevinden kaldırıldı, sadece paket kurulum adımında bırakıldı.

Yapılandırma ve Değişken Sözleşmesi

Yapılandırma Jinja2 şablonu üzerinden basılır:

# {{ ansible_managed }}
PidFile=/run/zabbix/zabbix_agent2.pid
LogFile=/var/log/zabbix/zabbix_agent2.log
Server={{ zabbix_agent_server }}
ListenPort={{ zabbix_agent_listenport }}
ServerActive={{ zabbix_agent_serveractive }}
Hostname={{ zabbix_agent_hostname }}
Include=/etc/zabbix/zabbix_agent2.d/plugins.d/*.conf

Bu şablonu besleyen vars/agent-layer.yml dosyası:

# Zabbix Agent 2 Parametreleri
zabbix_agent_version: "7.0"                # Resmi LTS deposu sürüm sabitlemesi
zabbix_agent_server: "192.168.122.10"      # Pasif kontrolleri sorgulayacak uç (ctrl-01)
zabbix_agent_serveractive: "192.168.122.10"# Aktif kontrollerin iletileceği uç
zabbix_agent_listenport: 10050             # Standart ajan dinleme portu
zabbix_agent_hostname: "{{ inventory_hostname }}" # Zabbix üzerindeki konak kimliği

Şablon güncellendiğinde Restart Zabbix Agent 2 handler'ı devreye girer. Playbook içindeki ansible.builtin.flush_handlers çağrısı, doğrulama testlerine geçmeden önce servisin yeniden başlatılmasını zorunlu kılar.

Beş Basamaklı Doğrulama ve `zabbix-get`

04_zabbix_agent.yml, sunucuya ihtiyaç duymadan ajanı 5 aşamalı bir test zincirinden geçirir:

Apt Seçim Sağlaması: apt policy çıktısından paketin repo.zabbix.com adresinden ve 7.0 ana sürümünden geldiği denetlenir.
Servis Durumu: service_facts ile ajanın running durumunda olduğu doğrulanır.
Soket Kontrolü: wait_for ile 127.0.0.1:10050 portunun açık olduğu görülür.
Yerel Metrik Testi: zabbix_agent2 -t agent.version komutu çalıştırılarak eklentilerin yüklendiği ve ajanın dahili metrik üretebildiği teyit edilir (rc=0).
Konfigürasyon Denetimi: Dağıtılan dosya slurp ile okunarak IP ve konak adı tanımları doğrulanır.

Uçtan uca son test kontrol makinesinden (ctrl-01) misafir ajana doğru tetiklenir:

# ctrl-01 üzerinden misafir ajanı sorgula:
zabbix_get -s 192.168.122.50 -k agent.version
# Çıktı: 7.0.30

Rsyslog Yönlendirme: QRadar Deseni

Sistem loglarının yalnızca yerel diskte tutulması felaket anında adli kanıtların yok olmasına neden olur. Ancak yaygın kullanılan *.* @@192.168.122.10:5514 gibi tek satırlık yönlendirme kuralları alıcı çöktüğü veya ağ kesildiği anda ya log akışını kilitler ya da veriyi sessizce düşürür.

Bu riski bertaraf etmek için disk destekli bir omfwd kuyruğu kurulmuştur:

action(type="omfwd"
  target="192.168.122.10"
  port="5514"
  protocol="tcp"
  queue.type="LinkedList"
  queue.filename="qradar_fwd"
  queue.maxDiskSpace="100m"
  queue.saveOnShutdown="on"
  action.resumeRetryCount="-1")

Bu yapılandırmanın getirdiği davranış modeli:

Loglar normal koşullarda bellekte (LinkedList) işlenir.
Hedefe ulaşılamazsa bellek taşmasını engellemek için /var/spool/rsyslog altına geçici disk kuyruğu açılır.
saveOnShutdown="on" sayesinde makine yeniden başlasa dahi iletilmemiş kuyruk silinmez.
resumeRetryCount="-1" alıcı ayağa kalkana kadar iletim denemelerinin sonsuza dek sürmesini sağlar.

Parametreler yine vars/agent-layer.yml üzerinden yönetilir:

# Rsyslog Yönlendirme Parametreleri
rsyslog_receiver_host: "192.168.122.10" # SIEM / Alıcı IP (Laboratuvarda ctrl-01)
rsyslog_receiver_port: 5514             # Root yetkisi istemeyen socat test portu (Prodüksiyonda 514)
rsyslog_forward_protocol: "tcp"         # Paket kaybını önleyen TCP aktarımı
rsyslog_queue_maxdisk: "100m"           # Kuyruk diske taştığında ayrılacak üst sınır
rsyslog_test_tag: "phase3-test"         # Doğrulama aşamasında basılacak test log etiketi

12 Dakikalık Saha Kesinti Testi

ctrl-01 üzerindeki socat dinleyicisi SSH oturumu kapandığı için devre dışı kaldı. Bu esnada 05_rsyslog_forward.yml çalıştırıldı, ardından alıcı kapalıyken test logu üretildi:

# 1. Alıcı kapalı, port dinlenmiyor:
$ ss -tlnp | grep 5514
# (çıktı yok)

# 2. Misafir makinede log üretildi ve rsyslog servisi restart edilerek saveOnShutdown test edildi:
$ ssh ubuntu@192.168.122.50 'sudo systemctl restart rsyslog && ls -la /var/spool/rsyslog/'
-rw------- 1 syslog syslog 193147 Aug 28 09:45 qradar_fwd.00000001
-rw------- 1 syslog syslog    567 Aug 28 09:45 qradar_fwd.qi

# 3. Alıcı 12 dakika sonra arka planda ayağa kaldırıldı:
$ nohup socat -u TCP-LISTEN:5514,reuseaddr,fork OPEN:/tmp/qradar-stub.log,creat,append >/dev/null 2>&1 &

# 4. Yaklaşık 30 saniye sonra biriken tüm kuyruk hedefe ulaştı:
$ wc -l /tmp/qradar-stub.log
942 /tmp/qradar-stub.log

$ grep kuyruk /tmp/qradar-stub.log
<13>Aug 28 09:34:21 vm-test-01 phase3-test: kuyruk testi: alici kapaliyken gonderildi

Log satırındaki 09:34:21 zaman damgası mimarinin başarısını kanıtlar: Mesaj alıcı kapalıyken üretilmiş, iletim 12 dakika sonra gerçekleştiği halde satır orijinal üretim zamanıyla hedefe ulaşmıştır.

Stub Yükleyici Deseni ve Marker Sözleşmesi

Homelab ortamında Trend Micro Deep Security veya ManageEngine gibi lisanslı yazılımların ikili paketleri bulunmaz; ancak bu ajanları kuracak dağıtım hattının kendisi gerçektir. Bu ayrımı yönetmek için Marker Sözleşmesi (Marker Contract) kurgulanmıştır.

Ansible doğrudan ikili dosyanın içeriğiyle değil, kurulum tamamlandığında dosya sistemine bırakılan .installed belirteciyle el sıkışır:

#!/bin/sh
set -eu
INSTALL_DIR="{{ item.install_dir }}"
MARKER="{{ item.install_dir }}/.installed"

echo "[{{ item.name }}] yukleyici basliyor: surum {{ item.version }}..."

# -------------------------------------------------------------
# YUKLEME BLOKU (STUB)
# Lisans geldiginde YALNIZCA bu blok degistirilecek
echo "[{{ item.name }}] stub modu: ikili dosya yok, lisans kullanilmadi."
# -------------------------------------------------------------

mkdir -p "$INSTALL_DIR"
{
  echo "agent={{ item.name }}"
  echo "version={{ item.version }}"
  echo "mode={{ item.mode }}"
  echo "installed_at=$(date -Is)"
  echo "host=$(hostname -s)"
} > "$MARKER"

echo "[{{ item.name }}] marker yazildi: $MARKER"

Belirteç dosyası içindeki her alan belirli bir amaca hizmet eder:

agent ve version: vars/agent-layer.yml içindeki tanımla eşleşmek zorundadır. Uyuşmazlık durumunda Ansible drift alarmı üretir.
mode: Şu an stub değerine kilitlidir; prodüksiyona geçildiğinde real moduna çevrilir.
installed_at: Adli bilişim açısından kurulum zamanını kanıtlar.
host: Belirtecin başka bir sanal makineden kopyalanmadığını belgeler.

Drift Alarmı ve Lisans Geçişi

Kurulum adımı creates: "{{ item.install_dir }}/.installed" korumasıyla çalışır. Bu sayede belirteç mevcutsa görev işletilmez ve temiz ikinci çalıştırmada özet changed=0 döner.

Eğer değişken dosyasında sürüm 1.0.0-stub iken 1.1.0-stub yapılırsa:

Yükleyici betik şablonu yeni sürümle güncellenir.
creates koruması nedeniyle betik tekrar çalıştırılmaz, diskteki marker eski kalır.
Sonraki adımda marker içeriği okunup assertion çalıştırıldığında playbook hata verir ve süreci durdurur.

Bu yapı kontrolsüz güncellemeyi engelleyen bir güvenlik kilididir. Yeniden kurulum için marker'ın bilinçli olarak silinmesi gerekir:

ansible provisioned -m file -a "path=/opt/TrendMicro/.installed state=absent" -b
ansible-playbook playbooks/06_security_agents.yml

Lisanslar temin edildiğinde install.sh.j2 dosyasındaki indirme/kurulum bloğu güncellenecek, vars/agent-layer.yml içinde mode: real değerine geçilecek ve dağıtım hattı mimarisi bozulmadan gerçek ajanlar devreye alınacaktır.

Saha Doğrulama Adımları ve Terminal Sonuçları

Ajan katmanı sahada önce bağımsız adımlarla, ardından Semaphore UI dağıtım hattı üzerinden iki aşamada doğrulandı.

1. Zabbix Agent 2 Kurulumu (`04_zabbix_agent.yml`)

Ubuntu 26.04 cloud imajı /etc/apt/keyrings diziniyle geldiği ve apt install sonrası servis paket tetikleyicisi tarafından otomatik başlatıldığı için ilk çalıştırmada 5 değişiklik gerçekleşti:

$ ansible-playbook playbooks/04_zabbix_agent.yml
# ...
TASK [Receipt - agent on duty] ***************************************
ok: [vm-test-01] => {
  "msg": "zabbix-agent2 (repo 7.0) listening on port 10050; passive checks accepted from 192.168.122.10, active checks sent to 192.168.122.10 as host \"vm-test-01\". Self-test: agent.version [s|7.0.30]"
}

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

Aynı komut tekrar çalıştırıldığında handler tetiklenmedi ve idempotency kanıtlandı: ok=18 changed=0.

2. Rsyslog İletimi (`05_rsyslog_forward.yml`)

Paket sistemde kurulu geldiği için paket adımı ok döndü; spool dizin izin düzeltmesi, şablon kopyalama ve servis restart adımları değişimi oluşturdu:

$ ansible-playbook playbooks/05_rsyslog_forward.yml
# ...
PLAY RECAP ***********************************************************
vm-test-01 : ok=13 changed=3 unreachable=0 failed=0

İkinci çalıştırmada sistem tam kararlılığa ulaştı: ok=12 changed=0.

3. Güvenlik Ajanları Dağıtımı (`06_security_agents.yml`)

İki stub ajan sisteme dağıtıldı, marker dosyaları oluşturuldu ve doğrulandı:

$ ansible-playbook playbooks/06_security_agents.yml
# ...
PLAY RECAP ***********************************************************
vm-test-01 : ok=8 changed=3 unreachable=0 failed=0

# Sanal makinedeki marker çıktısı:
$ ssh ubuntu@192.168.122.50 'cat /opt/TrendMicro/.installed /opt/ManageEngine/.installed'
agent=trendmicro
version=1.0.0-stub
mode=stub
installed_at=2026-08-28T09:12:01+00:00
host=vm-test-01
agent=manageengine
version=1.0.0-stub
mode=stub
installed_at=2026-08-28T09:12:02+00:00
host=vm-test-01

Tekrarlanan çalıştırmada creates muhafazası devreye girdi: ok=8 changed=0.

Dağıtım Hattı Entegrasyonu (Pipeline)

Faz 4 kapsamında Semaphore UI üzerinden provizyon edilen vm-faz4-01 makinesinde tüm süreç otomatik tetiklendi. Süreç sırasında iki temel entegrasyon bulgusu çözüldü:

Bulgu #18 (Run #31): Semaphore dinamik envanter kullandığından reponun group_vars tanımlarını doğrudan görmedi ve değişkenler tanımsız kaldı. Çözüm olarak tüm ajan yapılandırması vars/agent-layer.yml dosyasına toplandı ve playbook'lara vars_files ile bağlandı.
Bulgu #19 (Run #36): apt_repository adımına verilen lock_timeout parametresi görevi çökertti. Hatalı parametre kaldırılarak dpkg kilitleri tasks/wait_for_apt.yml geçidine devredildi.
Tam Başarı (Run #37): Hataların ardından pipeline baştan sona eksiksiz çalıştı:

# Run #37 pipeline özeti (vm-faz4-01)
PLAY RECAP *********************************************************************
localhost  : ok=16 changed=2 unreachable=0 failed=0 skipped=2 rescued=0 ignored=0
vm-faz4-01 : ok=88 changed=11 unreachable=0 failed=0 skipped=0 rescued=0 ignored=0

Makine üzerindeki changed=11 değeri, bağımsız çalıştırmalardaki değişimlerin toplamıdır ($5 + 3 + 3$). Otomasyonun terminalden manuel işletilmesi ile pipeline üzerinden tetiklenmesi arasında hiçbir davranış sapması yaşanmamıştır.

İlk Açılış Apt Kilitlenmesinin Çözümü (`tasks/wait_for_apt.yml`)

Yeni klonlanan bir sanal makine ilk açıldığında cloud-init paket güncellemelerini çalıştırırken unattended-upgrades de devreye girer. Bu aralıkta tetiklenen apt görevleri dpkg lock hatasıyla çöker.

Süreç adlarını (pgrep unattended-upgr) izlemek kalıcı servisler nedeniyle sonsuz döngüye yol açtığından, nihai çözüm doğrudan kilit dosyalarını izlemek oldu:

cloud-init status --wait komutuyla bulut başlatması beklenir.
/var/lib/dpkg/lock-frontend ve /var/lib/apt/lists/lock kilit dosyalarının boşa çıkması dinlenir.
Paket görevlerinde lock_timeout: 1800 kullanılarak yarış koşulu tamamen engellenir.

Faz 3 Kapanışı ve Sıradaki Adım

Ajan katmanı; harici koleksiyon bağımlılığı olmadan kurulan Zabbix Agent 2 omurgası, kesintiye dayanıklı disk destekli rsyslog kuyruğu ve lisans geçişine hazır drift korumalı marker mimarisiyle tamamlandı.

Süreç geride iki aktif mekanizma bıraktı:

Makine içindeki logları merkezi kuyrukla toplayan oturum bağımsız dinleyici,
Hem yerel hem de uzaktan tetiklenebilen 5 basamaklı servis sağlık denetimi.

Faz 3 tamamen kapanmıştır. Sıradaki çalışma Faz 4: Semaphore UI ile Uçtan Uca Otomatik Dağıtım:

Form üzerinden parametrik VM provizyonu,
Disklerin, LVM katmanının ve ajanların tek tıkla canlıya alınması,
Dağıtım kapısı (Delivery Gate) ile provizyon doğrulama testleri.

GitHub Deposu

Proxmox Otomasyonu Faz 2.5: Depolamayı Güçlendirme, Doğrulama, fstab Kalıcılığı ve 5. Disk

Hakan İSMAİL — Mon, 07 Sep 2026 12:26:44 +0000

Bu rehber, Proxmox Otomasyon Serisi'nin üçüncü modülüdür. Faz 2 saha oturumu, depolama mimarisinin canlı ortamda kanıtlanmasıyla noktalanmıştı: Terraform üzerinde seri numaralarıyla (serial) tanımlanan dört disk, idempotent bir Ansible playbook aracılığıyla LVM ve XFS katmanlarından geçirilip /srv/* altına bağlanmış, çalışan sanal makinede (VM) disk boyutu 20 GB'den 30 GB'ye kesintisiz büyütülmüş ve her iddianın arkasına somut terminal çıktıları konmuştu.

Bu sağlam bir zemin olsa da Faz 2 tamamlandığında arkasında henüz test edilmemiş iki büyük varsayım ve bir mimari açık bırakmıştı:

Reboot Kalıcılık Testi: Dosya sistemlerinin reboot sonrasında geri geleceği varsayılıyordu. fstab satırları yazılmış ve LVM'in açılışta volume group'ları otomatik etkinleştirmesi bekleniyordu; fakat birisi makineyi gerçekten yeniden başlatıp kontrol edene kadar bu bir kanıt değil, bir temenniden ibarettir. Üretim ortamlarındaki veritabanı sunucularında "makine reboot oldu ve veri diskleri geri gelmedi" durumu klasik bir kriz senaryosudur ve neredeyse her zaman tek satırlık bir hatadan kaynaklanır: fstab'da bir yazım yanlışı, aktivasyon kapsamı dışında kalan bir VG veya açılış sürecinin bağlamayı reddettiği bir dosya sistemi.
Yeni Disk İhtiyacı: Faz 2'deki büyüme senaryosu mevcut bir diski büyütmeyi kapsıyordu. Oysa sahada depolama büyümesi sıklıkla ortama yeni bir diskin eklenmesi şeklinde gelir: yeni bir iş yükü için depolama ekibinden gelen taze bir LUN.
Yapılandırma Kayması Riski (Configuration Drift): Depolama düzeni 02_storage.yml playbook'unun içindeki vars: bloğunda tanımlanmıştı. Tek bir playbook varken bu durum sorunsuzdu; ancak aynı listeyi doğrulayacak ikinci bir playbook geldiği anda iki dosya arasında kopyala-yapıştır yapmak kaçınılmaz bir drift riskine davetiye çıkaracaktı.

Bu sağlamlaştırma adımı, çalışan parçaları bozmadan bu üç açığı kapatıyor:

Disk düzeni tek gerçek kaynak (Single Source of Truth) olarak group_vars/provisioned.yml dosyasına taşınıyor.
Yeni yazılan 03_storage_verify.yml playbook'u makineyi yeniden başlatarak reboot sonrası kalıcılığını doğrulama token'ları, güncel fact'ler ve assertion'lar ile kanıtlıyor.
Opsiyonel bir beşinci disk ise uçtan uca yeni disk ekleme iş akışını sınıyor.

Dosya	Değişiklik	Amaç
`ansible/inventory/group_vars/provisioned.yml`	Yeni	Depolama düzenini tek bir liste olarak tanımlar: `serial`, `vg`, `lv`, `mount`. Hem kurulum hem doğrulama playbook'ları buradan okur.
`ansible/playbooks/02_storage.yml`	Güncellendi (v3)	`data_disks` listesi `group_vars`'a taşındı; dosya eksikse açık bir mesajla süreci durduran koruyucu `assert` eklendi. Görevler v2 ile aynı kaldı.
`ansible/playbooks/03_storage_verify.yml`	Yeni (v1.1)	Reboot sonrası kalıcılık doğrulaması: doğrulama token'ları, reboot, taze fact'ler, assertion'lar ve doğrulama logları. İlk saha testinde tespit edilen `follow: true` düzeltmesini içerir.
`terraform/variables.tf`	Güncellendi	Yeni değişken: `scratch_disk_size_gb` (varsayılan: `0` = 5. disk kapalı).
`terraform/vm.tf`	Güncellendi	Değişken sıfırdan büyük olduğunda `scsi5` arayüzünde `scratch01` serial'li diski üreten dinamik blok (`dynamic "disk"`).
`terraform/terraform.tfvars.example`	Güncellendi	5. diskin büyüme iş akışıyla birlikte belgelenen yeni parametresi.

Kapsam sınırları yine bilinçli olarak dar tutuldu:

Kapsam Dahilinde	Kapsam Dışında
Kurulum ve doğrulama playbook'larının paylaştığı tek `group_vars` listesi	Terraform state'ten beslenen dinamik envanter (Faz 4)
Senaryolaştırılmış reboot ile boot kalıcılığının kanıtlanması	Dosya sistemi kullanımının sürekli izlenmesi (Zabbix Faz 3'te geliyor)
`tfvars` parametresiyle kontrol edilen opsiyonel beşinci disk	Disk silme veya küçültme
02, 03 ve büyüme çalıştırmalarının gerçek saha logları (`ok=15 changed=1`, `ok=28 changed=2 failed=0`, büyümede `ok=15 changed=5`)	Rebootsuz hızlı test modunun logları (`verify_reboot=false` belgelendi, henüz sahada loglanmadı)

Depolama Düzeni İçin Tek Gerçek Kaynak

Faz 2 playbook'u disk listesini play başındaki bir vars: bloğunda tanımlamıştı. İkinci bir playbook aynı bilgiye ihtiyaç duyduğu anda sorun başlar: doğrulama playbook'unun da aynı serial'lere, aynı VG/LV adlarına ve aynı bağlama noktalarına ihtiyacı vardır; çünkü altyapıyı kanıtlamak, kurulum playbook'unun kurduğunu iddia ettiği şeyi birebir denetlemek demektir. İki dosyada tek bir listenin kopyasını tutmak drift'in doğduğu yerdir: beşinci bir disk eklersiniz, bir playbook'u günceller, diğerini unutursunuz ve doğrulama adımı fark ettirmeden o diski denetlemeyi bırakır.

Çözüm standart Ansible yöntemidir: grup değişkenleri (group_vars). Envanter zaten provisioned adında bir grup tanımlıyor; bu nedenle inventory/group_vars/provisioned.yml konumundaki bir dosya, hiçbir playbook kodu çalışmadan önce o gruptaki her host için otomatik olarak yüklenir. İki playbook da artık doğrudan data_disks değişkenini okur ve mimari bir garanti elde edilir: depoda tek bir liste vardır.

# ansible/inventory/group_vars/provisioned.yml
# Faz 2 depolama düzeni için tek gerçek kaynak (Single Source of Truth).
# playbooks/02_storage.yml (kurulum) ve
# playbooks/03_storage_verify.yml (reboot kalıcılığı kanıtı) tarafından okunur.

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

# 03_storage_verify.yml varsayılan olarak makineyi reboot eder.
# Kesintisiz hızlı kontrol (smoke test):
# ansible-playbook playbooks/03_storage_verify.yml -e verify_reboot=false
verify_reboot: true

Bu dosyadaki yorum satırları SCSI arayüzünü ve tfvars değişkenini her serial'in yanında tutar; çünkü bu dosya Terraform tarafı ile Ansible tarafı arasındaki bir sözleşmedir. verify_reboot değişkeni de playbook'un derinliklerine gömülmek yerine buraya kondu; böylece operatör ayarları aradığı yerde bulur.

Listeyi playbook dışına taşımak dosya bulunamadığında ne olacağını değiştirir; bu yüzden her iki playbook da en başta bir koruyucu assert ile açılır. Yanlış dizinden ya da bu grubu içermeyen bir envanterle çalıştırma durumunda süreç ortalarda tanımsız değişken hatasıyla patlamak yerine, henüz hiçbir şeye dokunmadan neden durduğunu açıkça bildirir:

- name: Require the storage layout (group_vars/provisioned.yml)
  ansible.builtin.assert:
    that: data_disks is defined and data_disks | length > 0
    fail_msg: >-
      data_disks tanımlanmamış. Depolama düzeni
      ansible/inventory/group_vars/provisioned.yml dosyasında yaşar;
      bu dosyanın var olduğunu ve playbook'un reponun kendi ansible.cfg'siyle,
      provisioned grubuna karşı çalıştırıldığını kontrol edin.

Ansible öncelik sıralaması (precedence) burada kritik bir tasarım kararı içerir:

Öncelik (Düşükten Yükseğe)	Bu Tasarımdaki Anlamı
`group_vars/provisioned.yml`	Tek gerçek kaynak; her iki playbook da olduğu gibi okur.
Playbook içindeki `vars:`	`group_vars`'ı override eder; `02_storage.yml` içinden özellikle kaldırıldı ki dosyadaki listeyle yarışamasın.
Komut satırındaki `--extra-vars`	Her şeyi override eder; tek seferlik geçici denemeler için belgelenmiş kaçış kapısı (`-e verify_reboot=false`).

Reboot Testi: `03_storage_verify.yml`

Faz 2 saha oturumu depolama katmanını bırakıldığı anki haliyle doğrulamıştı: bağlı, boyutlandırılmış ve df üzerinden okunabilir durumda. Ancak makinenin bir reboot sonrasında ayağa kalkıp kalkmayacağı test edilmemişti.

fstab girdileri yalnızca açılışta okunur. Açılıştaki LVM aktivasyonu, kurulum playbook'unun tetiklediği açık çalıştırmadan tamamen farklı bir mekanizmadır. Elle mount komutu çalıştırıldığı için ayakta duran bir dosya sistemi ile kalıcı olan bir dosya sistemi, ilk yeniden başlatmaya kadar birbirinden ayırt edilemez.

Doğrulama playbook'u, dikkatli bir sistem mühendisinin elle yapacağı adımları tekrarlanabilir çıktılara döker.

Reboot Öncesi Belirteçler (Token & Marker)

Kalıcılığı dizin adıyla değil içerikle denetlemek gerekir; çünkü yeni formatlanmış boş bir disk de aynı mount point'e bağlanabilir ama içindeki veriyi kaybetmiştir. Playbook, reboot öncesinde her dosya sistemine benzersiz bir token yazar:

- name: Mint a one-run verification token
  ansible.builtin.set_fact:
    verify_token: "phase2-{{ ansible_facts.date_time.epoch }}-{{ 100000 | random }}"

- name: Write a marker file into every data filesystem
  ansible.builtin.copy:
    content: "{{ item.mount }} {{ verify_token }}"
    dest: "{{ item.mount }}/phase2-verify.txt"
    mode: "0644"
  loop: "{{ data_disks }}"

Token, her çalıştırmanın yalnızca kendi yazdığını doğrulaması için üretilir. Sabit bir string'e karşı kontrol yapmak önceki çalıştırmadan kalan bayat bir dosyada bile geçer; oysa reboot'tan saniyeler önce üretilen bir token'ı aramak, okunan verinin tam o oturumda diske yazıldığını garantiler. Dosya içeriği mount yolu ile token'ın birleşimidir; yani yanlışlıkla başka diske yazılan bir belirteç de doğrulamadan geçemez.

Reboot ve Fact Yenileme Mantığı

- name: Reboot the VM (the moment of truth for fstab and LVM)
  ansible.builtin.reboot:
    msg: "Phase 2 verification reboot: proving fstab + LVM boot persistence"
    pre_reboot_delay: 5
    post_reboot_delay: 10
    reboot_timeout: 600
    test_command: "uptime"
  when: verify_reboot | default(true) | bool

- name: Refresh facts after the reboot (pre-reboot facts are stale)
  ansible.builtin.setup:
    when: verify_reboot | default(true) | bool

Bu iki görevde iki hayati teknik detay bulunur:

ansible.builtin.setup görevi gereksiz görünür ama zorunludur. gather_facts play'in en başında tek bir kez çalışır; dolayısıyla reboot sonrasında ansible_facts.mounts listesi hâlâ makinenin açılış öncesi dünyasını tarif eder. Reboot sonrası setup modülünü çağırmak, mount kontrollerinin güncel gerçeği okumasını sağlar.
Koşulda yer alan | bool filtresi zorunludur. Komut satırından --extra-vars ile geçilen değerler Ansible'a string olarak ulaşır. Jinja motorunda "false" string'i truthy (doğru kabul edilen) bir değerdir; bu filtre konmazsa -e verify_reboot=false parametresi verildiğinde playbook tam da reboot etmemesini istediğiniz anda makineyi yeniden başlatır.

LVM Kontrolü: Neden `lv_attr` Karakterleri Değil?

LVM, volüm durumunu lv_attr öznitelik dizgisinin 5. karakterinde kodlar (a = active). Ancak pozisyona dayalı karakter okumak, araçlar raporlama düzenini değiştirdiğinde sessizce patlayan kırılgan bir yöntemdir.

Playbook bunun yerine lvs komutundan JSON raporu alarak volüm sayısını doğrular, ardından sistemin doğrudan kendisine sorar: aktif bir mantıksal volüm aygıt düğümünü /dev/vg/lv altında sunar, aktif olmayan bir volümün düğümü oluşmaz. Bu yüzden her volüm için stat çalıştırmak hem daha sade hem daha güvenilir bir testtir.

- name: Read the LVM logical volume report (JSON)
  ansible.builtin.command:
    cmd: lvs --reportformat json --noheadings -o vg_name,lv_name,lv_attr
  register: lvs_state
  changed_when: false

- name: Parse the LVM report
  ansible.builtin.set_fact:
    lv_rows: "{{ (lvs_state.stdout | from_json).report[0].lv }}"

- name: Exactly the expected logical volumes must exist
  ansible.builtin.assert:
    that: lv_rows | length == data_disks | length

- name: Check every logical volume's device node
  ansible.builtin.stat:
    path: "/dev/{{ item.vg }}/{{ item.lv }}"
    follow: true # /dev/vg/lv -> /dev/dm-X symlink'ini takip etmek şart
  loop: "{{ data_disks }}"
  register: lv_nodes

- name: Every logical volume must be active after the reboot
  ansible.builtin.assert:
    that:
      - lv_nodes.results[idx].stat.exists
      - lv_nodes.results[idx].stat.isblk
    fail_msg: >-
      The volume group {{ item.vg }} was not activated after the reboot.
      Diagnose inside the VM with: systemctl status lvm2-activation.service,
      then check vgchange -ay.
    loop: "{{ data_disks }}"
    loop_control: { index_var: idx }

İlk saha oturumunun öğrettiği follow: true dersi tam buraya aittir. /dev/vg/lv bir blok aygıtı değil, udev tarafından yönetilen bir sembolik bağdır (symlink). stat modülüne symlink'i takip etmesi söylenmediğinde bağın kendisini inceler; sonuç olarak islnk: true dönerken isblk: false kalır ve çalışan sistemde sahte bir alarm (false positive) üretir.

fstab kontrolü ise mount modülünün yazdığı satırı doğrudan denetler: /dev/mapper alias'ı yerine verilen tam aygıt yolu (/dev/vg_data/lv_data) ve bağlama noktası. Hem aygıtı hem hedefi aramak iki arıza modunu birden yakalar: satırın hiç olmaması veya olup yanlış yere işaret etmesi.

Kesintisiz Hızlı Kontrol Modu (`verify_reboot=false`)

Reboot istenmeyen anlarda playbook -e verify_reboot=false ile çalıştırılarak kesintisiz bir denetim aracına (smoke test) dönüşür. Bu modda hangi kontrolün neyi kanıtladığı net biçimde bilinmelidir:

Denetim	Reboot İle (Varsayılan)	`verify_reboot=false` İle (Smoke Test)
Belirteç dosyaları (byte-to-byte)	Veri açılışı atlattı	Yalnızca oturum içi doğrulama
Mount durumu (`fstype: xfs`)	`fstab` açılış aktivasyonu çalıştı	Mevcut bağlı durum doğru
LV aygıt düğümleri mevcut	Açılış zamanı LVM aktivasyonu çalıştı	LV'ler şu anda aktif
`fstab` satırları mevcut	Kalıcılık beyan edilmiş, sadece canlıda kalmamış	Aynı
Serial'ler tek diske çözülüyor	Kimlik şeması açılışı atlattı	Kimlik şeması şu an geçerli

Dört Diskten Fazlası: `scratch01` Genişletme İş Akışı

Faz 2'deki büyütme senaryosu en yaygın talebi yanıtlamıştı: aynı diski büyütmek. İkinci yaygın talep ise yeni bir iş yükü için yeni bir disk eklemektir.

Manuel dünyada bu işlem hipervizörde ayrı, guest içinde ayrı konsol adımları demektir ve aygıt harfi tahmin oyununun en çok can sıktığı yerdir; çünkü yeni bir disk kendisinden sonraki disklerin sıralamasını kaydırabilir.

Terraform tarafı bunu dinamik bir blokla çözer. HCL blok seviyesinde doğrudan if anahtarı sunmaz; bu yüzden parametre verildiğinde tek elemanlı, verilmediğinde boş liste dönen bir dynamic "disk" bloğu kullanılır. Varsayılan sıfırken plan içinde scsi5 diski hiç yer almaz:

# terraform/vm.tf (Opsiyonel 5. veri diski)
variable "scratch_disk_size_gb" {
  description = "Opsiyonel 5. veri diski (serial: scratch01), GB. 0 = kapali."
  type        = number
  default     = 0
}

# proxmox_virtual_environment_vm.test_vm kaynagi icinde:
dynamic "disk" {
  for_each = var.scratch_disk_size_gb > 0 ? [var.scratch_disk_size_gb] : []
  content {
    datastore_id = var.storage_id
    interface    = "scsi5"
    size         = disk.value
    serial       = "scratch01"
    ssd          = true
    discard      = "on"
  }
}

Ansible tarafında yeni kod yazılmaz, sadece sözleşmeye yeni bir satır eklenir. Sorumluluk dağılımı bellidir:

Taraf	Sorumluluk Alanı	Tanımlandığı Yer
Terraform	Hangi disklerin var olduğu, arayüzler, boyutlar, serial'ler	`terraform/vm.tf` + `tfvars` ayarları
Ansible	Her serial'in guest içinde neye dönüştüğü: `vg`, `lv`, mount noktası	`inventory/group_vars/provisioned.yml`
Kernel	Her serial'in o anda hangi disk harfi olduğu	Her çalıştırmada sıfırdan çözülür, asla kalıcı yazılmaz

Büyütme (Resize) ile Yeni Disk Ekleme (Attach) Arasındaki Asimetri

Saha oturumu bu iki eylem arasındaki farkı netleştirdi:

Operasyon	VM Durumu	Serial Guest'te Görünür mü?	Görünmezse Yapılacak Eylem
Mevcut diski büyütmek (`data` 20 -> 30 GB)	Çalışıyor (Online)	Anında (Kernel görünümü anında yenilenir)	Gerek yok; sahada kanıtlanmış online işlem
Yeni disk takmak (`scsi5` `scratch01`)	Çalışıyor (Online)	Tam bir VM başlatması gerektirebilir (saha oturumunda: anında görüldü)	PVE host üzerinde: `qm shutdown 200 && qm start 200`, sonra 02'yi tekrar çalıştır
Tam bir VM başlatmasından sonraki durum	Taze başladı	Her zaman (konfigürasyon ve QEMU hemfikir)	Teşhis: `qm config 200

Büyütme online, yeni takma da (genellikle) online:
Mevcut diski büyütmek tamamen kesintisiz kalır. Yeni disk takmak da saha oturumunda makine çalışırken online tamamlandı; ancak serial'in konfigürasyonun gerisinde kaldığı durumlar için belgelenmiş tam kapat-aç adımı el altında beklemelidir.

Uçtan uca büyüme iş akışı:
{% raw %}

# 1. ctrl-01'de: diski aktif et (terraform/terraform.tfvars)
scratch_disk_size_gb = 5

# 2. apply: disk makine calisirken takilir
cd ~/proxmox-automation/terraform && terraform apply

# 3. duzen girdisini group_vars/provisioned.yml dosyasina ekle
# - serial: scratch01
#   vg: vg_scratch
#   lv: lv_scratch
#   mount: /srv/scratch

# 4. baglamayi insa et (ayni playbook, fazladan bir dongu iterasyonu)
cd ../ansible && ansible-playbook playbooks/02_storage.yml

# 5. Eger 4. adim scratch01 NOT FOUND derse: PVE node'unda tam durdur/baslat
# qm shutdown 200 && qm start 200
# ardindan 4. adimi tekrar calistir

# 6. reboot dahil kanitla
ansible-playbook playbooks/03_storage_verify.yml
ssh ubuntu@192.168.122.50 'df -h /srv/scratch'

Upstream İmaj Yenilenmesi Durumu

Beşinci diski takarken çalıştırılan apply, plan çıktısında beklenmedik bir satır getirdi: Plan: 1 to add, 2 to change, 1 to destroy.

Yok edilen nesne VM değildi; proxmox_download_file.ubuntu_image kaynağıydı. Canonical, Ubuntu cloud imajını upstream depoda güncellemiş, dosya boyutu 861.837.824 bayttan 864.818.688 bayta çıkmıştı. Provider boyut uyuşmazlığını görünce eski dosyayı silip yenisini indirdi. Apply süresi bu indirme nedeniyle 5 dakika sürdü; fakat VM yerinde güncellendi, kesinti yaşanmadı. Bu tazelik yerine tam tekrarlanabilirlik isteyenler template.tf içinde overwrite = false parametresini kullanabilir.

Saha Oturumu ve Terminal Çıktıları

Aşağıdaki runbook tablosu Faz 2 Addendum'un sahadaki tam icra sırasıdır:

Makine	Komut	Geri Alınan Çıktı	Durum
`ctrl-01`	`cd ~/proxmox-automation && unzip -o proxmox-automation.zip`	Dosyalar güncellendi	Tamamlandı
`ctrl-01`	`cd ansible && ansible-playbook playbooks/02_storage.yml`	PLAY RECAP	Saha: `ok=15 changed=1`
`ctrl-01`	`ansible-playbook playbooks/03_storage_verify.yml`	Debug satırları, assert satırları, PLAY RECAP	Saha: `ok=28 changed=2 failed=0`
`ctrl-01`	`ansible-playbook playbooks/03_storage_verify.yml -e verify_reboot=false`	Rebootsuz mod recap çıktısı	Opsiyonel, henüz çalıştırılmadı
`ctrl-01`	tfvars düzenle: `scratch_disk_size_gb = 5`, sonra `terraform apply`	Apply çıktısı (imaj tazeleme + scsi5, VM yerinde)	Saha: tamamlandı (5 dk: imaj indirme)
`ctrl-01`	`scratch01`'i group_vars'a ekle, `02_storage.yml` tekrar çalıştır	`scratch01` mapping satırı, PLAY RECAP	Saha: `ok=15 changed=5`

`ok=14`'ten `ok=15`'e Geçişin Mantığı

Faz 2 rehberinde 02_storage.yml için recap ok=14 changed=1 olarak kaydedilmişti. v3 refactor'ünde liste group_vars'a taşındı ve play başına koruyucu assert görevi eklendi. Geçen bir assertion recap'te fazladan bir ok demektir: 14 görev artı koruyucu assert eşittir 15. Depolama işinin kendisinde hiçbir şey değişmedi; recap'ler arasındaki bir görevlik fark, group_vars hamlesinin sisteme gizli bir yük bindirmediğinin somut kanıtıdır.

root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/02_storage.yml
# ... eslestirme ve kontroller gecti ...
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 gecisi

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

İlk Doğrulama Denemesi ve Düzeltme Adımı

İlk doğrulama denemesi reboot'a kadar yeşil aktı: token'lar yazıldı, eşleşme alındı, makine yeniden başladı, token'lar byte'ı byte'ına geri okundu. Ancak mantıksal volüm kontrolünde sistem sahte bir alarmla (false positive) durdu:

root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/03_storage_verify.yml
TASK [Every logical volume must be active after the reboot] ********************
fatal: [vm-test-01]: FAILED! => (item=vg_var/lv_var) => {
    "assertion": "lv_nodes.results[0].stat.isblk",
    "evaluated_to": false,
    "msg": "The volume group vg_var was not activated after the reboot ..."
}
# ... (vg_log, vg_data, vg_backup: dördü birden ayni anda basarisiz)

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

follow: true eklenip düzeltme doğrulandıktan sonra ikinci deneme başarıyla sonuçlandı:

root@ctrl-01:~/proxmox-automation/ansible# grep "follow:" playbooks/03_storage_verify.yml
    follow: true

root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/03_storage_verify.yml
TASK [Show the mapping before the reboot] **************************************
ok: [vm-test-01] => (item=var01) => { "msg": "var01 = /dev/sde" }
# ... (log01 = /dev/sdd, data01 = /dev/sdc, backup01 = /dev/sdb)

TASK [Reboot the VM (the moment of truth ...)] *********************************
changed: [vm-test-01]

TASK [Every logical volume must be active after the reboot] ********************
ok: [vm-test-01] => (item=vg_var/lv_var) => { "msg": "All assertions passed" }
# ... (vg_log/lv_log, vg_data/lv_data, vg_backup/lv_backup)

TASK [Show the mapping before vs after ...] ************************************
ok: [vm-test-01] => (item=var01) => { "msg": "var01: /dev/sde before -> /dev/sde after (vg_var/lv_var on /srv/var)" }
ok: [vm-test-01] => (item=backup01) => { "msg": "backup01: /dev/sdb before -> /dev/sdb after (vg_backup/lv_backup on /srv/backup)" }
# ... (log01, data01)

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

Buradaki sayılar net bir hesaba dayanır:

changed=2: Doğrulama çalıştırması için beklenen minimumdur; token dosyaları her çalıştırmada taze yazılır ve reboot modülü gerçek bir eylemdir.
ok=28: İlk denemedeki ok=18'in üzerine 10 yeni kontrol eklenmedi; ilk deneme assert'te durduğu için çalışamayan boot sonrası eşleşme, fstab çıktıları, findmnt, lsblk ve df görevleri nihayet çalışabildi.

Bu ikinci denemede harfler de değişmedi (var01 hem öncesinde hem sonrasında sde); ama bu bir garanti değil, o boot'a özgü bir şans. Şema harflerin sabit kalmasına değil, sadece serial'lerin sabit kalmasına güveniyor; birkaç bölüm sonraki büyüme çalıştırması, harfler gerçekten döndüğünde de aynı yeşil sonucu veriyor.

Genişletme Çalıştırması: Aygıt Harflerinin Kayması Testi

scratch_disk_size_gb = 5 ile disk eklendikten sonra 02_storage.yml çalıştırıldı:

root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/02_storage.yml
TASK [Show the serial to device mapping ...] ***********************************
ok: [vm-test-01] => (item=scratch01) => { "msg": "scratch01 (vg_scratch/lv_scratch -> /srv/scratch) = /dev/sdf" }

TASK [Create volume groups (one per disk)] *************************************
changed: [vm-test-01] => (item=vg_scratch)
# (vg_var, vg_log, vg_data, vg_backup: ok, dokunulmadi)

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

changed=5 tam olarak yeni bir diskin ilk çalıştırma işini yapan beş görevdir: PV görevi (pvresize geçişi), VG, LV, XFS ve mount. Mevcut dört disk hiçbir değişiklik bildirmedi; VG, LV, XFS ve mount maddeleri ok olarak döndü.

Ardından çalıştırılan doğrulama playbook'u, bu tasarımın en büyük sınavını verdi. Beşinci disk takıldıktan sonra yapılan reboot sırasında kernel aygıt harflerini tamamen döndürdü:

root@ctrl-01:~/proxmox-automation/ansible# ansible-playbook playbooks/03_storage_verify.yml
TASK [Show the mapping before vs after ...] ************************************
ok: [vm-test-01] => (item=var01) => { "msg": "var01: /dev/sde before -> /dev/sdf after (vg_var/lv_var on /srv/var)" }
ok: [vm-test-01] => (item=scratch01) => { "msg": "scratch01: /dev/sdf before -> /dev/sdb after (vg_scratch/lv_scratch on /srv/scratch)" }
# (log01: sdd -> sde, data01: sdc -> sdd, backup01: sdb -> sdc)

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

Açılışta var01 diski sde'den sdf'ye kaydı; yeni eklenen scratch01 ise sdf iken açılışta sdb oldu. Diğer tüm komşular birer koltuk ötelendi.

Buna rağmen çalıştırma tamamen yeşil kaldı; çünkü yığındaki hiçbir şey bir harfi adreslemiyor: fstab /dev/vg/lv yollarını arıyor, LVM disklerin üzerindeki meta veriyi okuyor ve playbook'lar her çalıştırmada haritalamayı kernel görüşünden taze kuruyor. Recap yine ok=28 changed=2 kaldı; çünkü listeye beşinci bir girdi eklemek görev sayısını değil, döngü iterasyonlarını artırır: playbook makineyle birlikte büyüyor, hareketli parça sayısı ise hiç artmıyor.

Operasyonel Not: Kontrol düğümünde df -h /srv/scratch çalıştırmak "No such file or directory" der; çünkü mount kontrol düğümünde değil, misafir makinededir. Doğrulama çıktısı SSH üzerinden misafirden okunmalıdır:

root@ctrl-01:~# ssh ubuntu@192.168.122.50 'df -h /srv/scratch'
Filesystem                         Size  Used Avail Use% Mounted on
/dev/mapper/vg_scratch-lv_scratch  5.0G  130M  4.9G   3% /srv/scratch

Depolama Katmanı Kapandı: Sırada Ne Var?

Depolama katmanı serinin taahhüt ettiği her iki boyutta da tamamlandı: golden template ve dört serial ile deklaratif olarak inşa edildi, tek bir tfvars düzenlemesiyle online büyütüldü ve bu addendum ile birlikte tek bir komutla reboot sınavından geçirildi.

Tek gerçek kaynaklı group_vars mimarisi, doğrulama playbook'u ve büyüme iş akışı sahada bizzat çalıştı. Alınan dersler; stat'ın sembolik bağları yalnızca açıkça istendiğinde takip ettiği, serial hotplug'ın şanslı bir günde online tamamlandığı ve upstream bir imajın pipeline ortasında kendini yenileyebileceği, gelecekteki çalıştırmaların bulacağı yerlere not edildi.

Her depolama değişikliğinden (büyütme ya da yeni disk ekleme) sonra operasyonel alışkanlık aynıdır:

Önce kurulum playbook'unu çalıştır (02_storage.yml),
Ardından doğrulama playbook'unu çalıştır (03_storage_verify.yml).

İlki durumu yakınsar; ikincisi makinenin gece saat 3'te tek başına ayağa kalkabileceğini somut terminal çıktılarıyla kanıtlar.

Faz 2 tamamen kapandı. Sıradaki durak Faz 3:

Template içindeki eski /install dizinini gerçek Ansible rollerine dönüştürmek,
Mount noktalarına anlık denetim yerine kalıcı bir gözlemci atayacak Zabbix Agent 2,
Merkezi güvenlik ajanları ve log diskini salt bir depolama alanından pipeline parçasına dönüştürecek QRadar rsyslog yönlendirme kuralları.

GitHub Deposu

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.

DEV Community: Hakan İSMAİL

# VCF 9.1: Memory Tiering, vSAN Global Deduplication ve Oracle RAC / WSFC için Hot Extend (Modül 3)

Memory Tiering

Kılavuzun anlattığı problem

VCF Operations'ta "ya eklesem" simülasyonu

Lab'da gördüğüm: ayarlar

Gerçek ortamda soracağım sorular

vSAN

Auto RAID

Global Deduplication ve Effective Capacity Reporting

Dedup'un getirdiği kısıtlar

Lab'da gördüğüm

Clustered uygulamalar için Hot Extend: Oracle RAC ve WSFC

Genel olarak neler dikkatimi çekti

Seri hakkında

VCF 9.1 Automation: Namespace Self-Service, Namespace Capture ve Infrastructure Policies (Modül 2)

Önce roller: bu modülde üç farklı kişi var

Namespace Self-Service

Yeni namespace oluşturmak

Namespace Capture

Capture öncesi gerekenler

İki capture türü

Lab'da yaptıklarım

Blueprint ile catalog item farkı

Catalog'dan dağıtmak

Infrastructure Policies

1. Tag'ler (VCF Operations)

2. Compute Policy'ler (vCenter)

3. Infrastructure Policy'ler (VCF Automation Provider portal)

4. Organization'a atamak

Test: namespace ve VM

Policy değişince VM ne yapıyor?

Service Framework

Genel olarak neler dikkatimi çekti

VCF 9.1'de Neler Değişti? Yeni Menü, Health, Log Management ve Fleet Yönetimi (Modül 1)

Önce arayüz: dört ana başlık

Health ve Diagnostics: artık sadece "host düştü mü" demiyor

Realtime Metrics: 20 saniye ve 2 saniye

Security Posture Management

Log Management: Aria Operations for Logs'a veda

Fleet Management

Genel olarak neler dikkatimi çekti

Bir Hafta Sonu Projesi: AWS EC2 Üzerinde V2Ray (3X-UI) ve Cloudflare WARP ile Datacenter IP Engellerini Aşmak

Adım 1: AWS EC2 ve SSH Kurulumu

Adım 2: 3X-UI Panel Kurulumu ve İlk Engeller

Karşılaşılan Hata: 404 Not Found

Adım 3: VLESS + WebSocket Inbound Oluşturma

Adım 4: Güvenlik (Panelin Dış Dünyaya Kapatılması)

Adım 5: Cloudflare WARP Entegrasyonu

Kapanış ve Gözlem

Proxmox Otomasyon Serisi Faz 3: Zabbix Agent 2 (7.0 LTS), Rsyslog (QRadar TCP ve Disk Destekli Kuyruk) ve Güvenlik Ajanları

Faz 3'de ne var?

Dizin Ağacı ve Dosya Rolleri

Kapsam Sınırları

Zabbix Agent 2: Sürüm Sabitleme ve Doğrulama

Neden Community Değil?

Canlı Depo Kontrolü ve Apt Seçimi (Election)

Kurulum Görevleri ve lock_timeout Ayrımı

Yapılandırma ve Değişken Sözleşmesi

Beş Basamaklı Doğrulama ve zabbix-get

Rsyslog Yönlendirme: QRadar Deseni

12 Dakikalık Saha Kesinti Testi

Stub Yükleyici Deseni ve Marker Sözleşmesi

Drift Alarmı ve Lisans Geçişi

Saha Doğrulama Adımları ve Terminal Sonuçları

1. Zabbix Agent 2 Kurulumu (04_zabbix_agent.yml)

2. Rsyslog İletimi (05_rsyslog_forward.yml)

3. Güvenlik Ajanları Dağıtımı (06_security_agents.yml)

Dağıtım Hattı Entegrasyonu (Pipeline)

İlk Açılış Apt Kilitlenmesinin Çözümü (tasks/wait_for_apt.yml)

Faz 3 Kapanışı ve Sıradaki Adım

Proxmox Otomasyonu Faz 2.5: Depolamayı Güçlendirme, Doğrulama, fstab Kalıcılığı ve 5. Disk

Depolama Düzeni İçin Tek Gerçek Kaynak

Reboot Testi: 03_storage_verify.yml

Reboot Öncesi Belirteçler (Token & Marker)

Reboot ve Fact Yenileme Mantığı

LVM Kontrolü: Neden lv_attr Karakterleri Değil?

Kesintisiz Hızlı Kontrol Modu (verify_reboot=false)

Dört Diskten Fazlası: scratch01 Genişletme İş Akışı

Büyütme (Resize) ile Yeni Disk Ekleme (Attach) Arasındaki Asimetri

Kurulum Görevleri ve `lock_timeout` Ayrımı

Beş Basamaklı Doğrulama ve `zabbix-get`

1. Zabbix Agent 2 Kurulumu (`04_zabbix_agent.yml`)

2. Rsyslog İletimi (`05_rsyslog_forward.yml`)

3. Güvenlik Ajanları Dağıtımı (`06_security_agents.yml`)

İlk Açılış Apt Kilitlenmesinin Çözümü (`tasks/wait_for_apt.yml`)

Reboot Testi: `03_storage_verify.yml`

LVM Kontrolü: Neden `lv_attr` Karakterleri Değil?

Kesintisiz Hızlı Kontrol Modu (`verify_reboot=false`)

Dört Diskten Fazlası: `scratch01` Genişletme İş Akışı

`ok=14`'ten `ok=15`'e Geçişin Mantığı

`corosync-quorumtool`: Daha Okunabilir Bir Alternatif

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

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