DEV Community: Hakan İSMAİL

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.

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

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

Seri: Proxmox VE Cluster ve Corosync

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

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

Neden Cluster?

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

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

Üç Parça: pvecm, Corosync, pmxcfs

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

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

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

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

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

systemctl status pve-cluster

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

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

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

ls -la /etc/pve/nodes/

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

Uygulama 2: Cluster'ı Kurmak

Cluster'ı GUI'den Oluşturmak

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

Hata: TLS Sertifika Doğrulaması

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

pvecm add 10.10.10.11 --link1 10.10.10.12

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

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

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

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

pvecm add 192.168.122.11 --link1 10.10.10.12

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

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

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

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

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

"Join 'lab-cluster'" dedim.

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

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

Bunu terminalden doğruladım.

Sonucu Doğrulamak

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

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

pve-c katıldıktan sonra:

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

pvecm nodes:

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

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

pmxcfs'in Canlı Senkronizasyonu

pve-a'da bir dosya oluşturdum:

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

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

cat /etc/pve/test-sync.txt

cluster calisiyor

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

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

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

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

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

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

ls -la /etc/pve/nodes/

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

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

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

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

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

Küçük Bir VM ile Migration Testi

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

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

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

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

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

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

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

qm status 100

status: running

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

pvesh get /cluster/resources --type vm

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

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

Node'u Çökertmek

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

ping 192.168.122.251

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

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

sudo virsh destroy pve-b

Domain 'pve-b' destroyed

pve-a'dan cluster durumuna baktım:

pvecm status

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

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

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

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

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

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

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

qm start 100

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

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

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

Toparlamak ve Doğrulamak

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

sudo virsh start pve-b

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

pvecm status

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

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

Genel Değerlendirme

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

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

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

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

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

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

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

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

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

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

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

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

Ortam Hakkında Bir Not

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

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

Lab Mimarisi: Neden Nested Virtualization, Neden libvirt

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

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

Nested Virtualization Kontrolü

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

cat /sys/module/kvm_intel/parameters/nested

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

Kaynak Planlaması

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

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

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

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

ISO'ları İndirmek ve Doğrulamak

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Kurulumu Tamamlamak: Proxmox VE ve Debian

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

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

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

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

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

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

PermitRootLogin yes

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

systemctl restart sshd.service

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

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

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

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

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

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

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

Bağlantıyı Doğrulamak

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

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

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

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

Genel Değerlendirme

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

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

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

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

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

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

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

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

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

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

vSAN Data Protection Nedir?

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

Mimari olarak birkaç önemli nokta var:

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

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

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

vSAN ESA Snapshot'ları: Temel Mekanik

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

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

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

Data Protection Arayüzüne Giriş

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

Genel Bakış (Overview)

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

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

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

Protection Groups

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

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

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

Existing VMs, Removed VMs, Incoming VMs

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

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

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

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

Replication Pairs

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

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

Yeni Bir Protection Group Oluşturmak

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

Genel Ayarlar

Protection Groups > Create Protection Group

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

Bu HOL'da Local protection seçiliyor.

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

VM İsim Deseni Eklemek

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

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

Snapshot Zamanlaması

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

Bu HOL'da:

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

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

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

Review ve Oluşturma

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

Manuel Snapshot Almak

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

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

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

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

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

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

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

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

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

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

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

VM'leri Geri Yüklemek

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

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

VMs > core-a seçili > Restore VM

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

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

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

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

Silinmiş Bir VM'i Geri Getirmek

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

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

Sihirbaz adımları:

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

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

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

VM Klonlamak

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

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

Klonlama Adımları

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

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

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

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

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

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

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

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

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

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

Immutable Protection Group Oluşturmak

Protection Groups > Create Protection Group

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

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

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

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

Immutability'nin Etkisini Doğrulamak

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

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

Genel Değerlendirme

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

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

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

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

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

Seri Üzerine Kapanış Notu

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

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

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

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

DEV Community: Hakan İSMAİL

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

Upstream İmaj Yenilenmesi Durumu

Saha Oturumu ve Terminal Çıktıları

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

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

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

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

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

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

Problem: disk tahmini ve elle büyütme

Tasarım: kimlik serial'da

Terraform: dört diski tanımlamak

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

İki taraftan doğrulama

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

Ansible storage playbook'u

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

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

İlk çalıştırma

İdempotans: tekrar çalıştırma

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

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

Sırada ne var?

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

Hedef: tek komut, üç kaynak

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

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

Terraform için API token'ı

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

İlk giriş: konsolda şifre yok

Minimal konteynerde gpg yok

Üretilmemiş locale

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

Terraform tarafı: kritik kararlar

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

vlan_tag artık yok

hostname kalkmış, CPU tipinde -Auto yok

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

Hata olmayan on beş dakikalık uyarı

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

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

Facts enjeksiyonu 2.24'te kalkıyor

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ş

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

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