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.
Top comments (0)