Yüksek Erişilebilirlik: Proxmox HA Kümesi Kurulumu ve Yönetimi

Proxmox ortamında yüksek erişilebilirlik kuruyorsanız, işler göründüğü kadar basit değil. Tek bir node’un çökmesi tüm sanal makinelerinizi götürebilir, ve bu da ya müşteri kaybı ya da gece 3’te panikle uyanmak demek. HA kümesi kurarak bu riski minimize edebilirsiniz ama doğru yapılandırılmamış bir HA kümesi, bazen hiç HA yoktan daha kötü sonuçlar verebilir. Bu yazıda gerçek dünyada işe yarayan, üretim ortamında test edilmiş bir Proxmox HA kurulumunu adım adım ele alacağız.

Proxmox HA’ya Giriş: Ne Zaman Gerekli?

Proxmox HA (High Availability), bir veya birden fazla node’un çökmesi durumunda sanal makineleri ve konteynerleri ayakta tutmak için tasarlanmış bir mekanizmadır. Ama her ortam için HA şart değil. Önce şunu sorun kendinize: “Bu sistem çökerse ne olur?”

Eğer cevabınız “müşteriler etkilenir”, “ödeme sistemi durur” veya “SLA ihlali yaşarız” ise, HA bir lüks değil zorunluluktur. Küçük geliştirme ortamları veya test sunucuları için bu kadar karmaşıklığa girmenize gerek yok.

HA kümesi için minimum gereksinimler şunlardır:

• 3 node: Bu bir tavsiye değil, zorunluluk. 2 node ile quorum çalışmaz. 1 node çökünce kalan 1 node quorum sağlayamaz ve HA aktif olamaz.
• Shared storage: Tüm node’ların erişebildiği ortak depolama alanı. NFS, iSCSI, Ceph veya ZFS over iSCSI olabilir.
• Ayrı ağ bağlantıları: Management, VM trafiği ve storage trafiği için ayrı interface’ler şiddetle tavsiye edilir.
• Corosync için güvenilir ağ: Yüksek latency veya paket kaybı olan bir ağda HA kümesi felakete davet çıkarır.

Lab Ortamının Hazırlanması

Bu yazıda 3 node’lu bir küme kuracağız. Node’larımızın IP adresleri şöyle olsun:

• pve-node1: 192.168.10.11
• pve-node2: 192.168.10.12
• pve-node3: 192.168.10.13
• Shared storage (NFS): 192.168.10.50

Her node’da Proxmox VE 8.x kurulu olduğunu varsayıyoruz. İlk adım olarak her node’un birbirini hostname üzerinden çözümleyebildiğinden emin olun.

# Her node'da /etc/hosts dosyasını düzenle
cat >> /etc/hosts << 'EOF'
192.168.10.11 pve-node1
192.168.10.12 pve-node2
192.168.10.13 pve-node3
EOF

Şimdi node’lar arasında SSH key authentication ayarlayalım. Bu hem küme kurulumu hem de yönetim için hayat kurtarır:

# pve-node1'de SSH key oluştur ve diğer node'lara kopyala
ssh-keygen -t ed25519 -f /root/.ssh/id_ed25519 -N ""
ssh-copy-id root@pve-node2
ssh-copy-id root@pve-node3

# Bağlantıyı test et
ssh pve-node2 "hostname && date"
ssh pve-node3 "hostname && date"

Proxmox Kümesinin Oluşturulması

Küme oluşturma işlemini her zaman pve-node1 üzerinde başlatın. Web arayüzünü kullanabilirsiniz ama komut satırı daha hızlı ve script edilebilir.

# pve-node1'de kümeyi oluştur
pvecm create production-cluster --link0 192.168.10.11

# Küme durumunu kontrol et
pvecm status

Küme oluştuktan sonra diğer node’ları ekleyin. Bu işlemi pve-node2 ve pve-node3 üzerinde yapın:

# pve-node2'de çalıştır
pvecm add 192.168.10.11 --link0 192.168.10.12

# pve-node3'te çalıştır
pvecm add 192.168.10.11 --link0 192.168.10.13

Node eklendikten sonra pve-node1’den küme durumunu kontrol edin:

pvecm status
# Çıktıda "Quorum information" ve "Membership information" bölümlerini kontrol edin
# Her üç node da "M" (member) olarak görünmeli

pvecm nodes
# Tüm node'ların listesini ve durumlarını gösterir

Shared Storage Yapılandırması

HA’nın çalışması için VM disk görüntülerinin tüm node’lardan erişilebilir olması şart. NFS ile basit bir shared storage kurulumu yapalım.

NFS sunucunuzda (192.168.10.50) şu yapılandırmayı yapın:

# NFS sunucuda
apt install nfs-kernel-server -y

mkdir -p /export/proxmox-storage
chown nobody:nogroup /export/proxmox-storage
chmod 777 /export/proxmox-storage

# /etc/exports dosyasına ekle
echo "/export/proxmox-storage 192.168.10.0/24(rw,sync,no_subtree_check,no_root_squash)" >> /etc/exports

exportfs -ra
systemctl restart nfs-kernel-server

Proxmox tarafında tüm node’lara NFS storage ekleyin. Bunu web arayüzünden “Datacenter > Storage > Add > NFS” ile yapabilirsiniz ya da komut satırından:

# pve-node1'de çalıştır, cluster geneline yayılır
pvesm add nfs ha-storage --server 192.168.10.50 --export /export/proxmox-storage --content images,rootdir --options vers=4

# Storage'ın tüm node'lardan erişilebilir olduğunu kontrol et
pvesm status

Gerçek üretim ortamında NFS yerine Ceph kullanmanızı tavsiye ederim. Ceph hem daha güvenilir hem de Proxmox ile çok daha iyi entegre çalışıyor. Ama Ceph kurulumu ayrı bir yazı konusu, şimdilik NFS ile devam ediyoruz.

HA Kaynaklarının Yapılandırılması

Küme ve storage hazır, şimdi asıl işe gelebiliriz. Bir sanal makine oluşturun ve bunu HA kaynağı olarak ekleyin.

Önce HA Manager’ın durumunu kontrol edelim:

# HA servislerinin durumu
systemctl status pve-ha-lrm
systemctl status pve-ha-crm

# HA Manager'ın genel durumu
ha-manager status

Şimdi VM’i HA grubuna ekleyelim. Web arayüzünden “Datacenter > HA > Add” yapabilirsiniz ya da:

# VM 100'ü HA kaynağı olarak ekle
ha-manager add vm:100

# Daha detaylı yapılandırmayla ekle
ha-manager add vm:100 --state started --max_restart 3 --max_relocate 2

# HA kaynaklarını listele
ha-manager status

Bu parametreler önemli:

• –state started: VM her zaman çalışır durumda olmalı
• –max_restart: Aynı node’da kaç kez yeniden başlatma denenecek
• –max_relocate: Başka node’lara kaç kez taşınacak

HA Gruplarının Oluşturulması

HA grupları, VM’lerin hangi node’larda çalışabileceğini ve hangi node’ların öncelikli olduğunu belirlemenizi sağlar. Örneğin güçlü donanımlı node’ları veritabanı sunucuları için önceliklendirebilirsiniz.

# "database-servers" adında bir HA grubu oluştur
ha-manager groupadd database-servers --nodes pve-node1:2,pve-node2:1,pve-node3:1 --restricted 1

# "web-servers" grubu - tüm node'larda eşit öncelik
ha-manager groupadd web-servers --nodes pve-node1,pve-node2,pve-node3

# Grupları listele
ha-manager groupconfig database-servers

Grup parametreleri:

• –nodes: Node listesi ve öncelik değerleri (yüksek sayı = yüksek öncelik)
• –restricted 1: VM sadece bu gruptaki node’larda çalışabilir
• –nofailback 0: Orijinal node geri gelince VM otomatik taşınsın

Bir VM’i gruba atayın:

# VM 101'i database-servers grubuna ekle
ha-manager add vm:101 --state started --group database-servers --max_restart 2 --max_relocate 1

Fencing Mekanizmasının Yapılandırılması

Bu kısım çoğu zaman atlanan ama en kritik bölüm. Fencing (çitleme), bir node yanıt vermediğinde o node’u zorla kapatma işlemidir. Fencing olmadan “split-brain” senaryosu yaşanabilir: İki node da aynı VM’i çalıştırdığını düşünür ve disk corruption meydana gelir.

Proxmox fencing için birkaç seçenek sunar: IPMI/iDRAC, hardware watchdog veya external scripts. IPMI ile yapılandıralım:

# pve-node1'de IPMI fencing yapılandırması
# /etc/pve/corosync.conf dosyasına watchdog ekle

# Önce watchdog modülünü yükle
modprobe softdog
echo "softdog" >> /etc/modules

# Her node'da watchdog'u aktif et
systemctl enable --now watchdog-mux

# Watchdog'un çalıştığını doğrula
ls -la /dev/watchdog*

IPMI tabanlı fencing için IPMI araçlarını kurun:

apt install freeipmi-tools ipmitool -y

# IPMI erişimini test et (kendi node'unuzun IPMI IP'si ile)
ipmitool -I lanplus -H 192.168.10.101 -U admin -P password chassis power status

Fencing’in gerçek hayatta düzgün çalışmaması çok ciddi sorunlara yol açar. Bu yüzden her kurulumdan sonra mutlaka test edin.

HA Testleri: Gerçek Arıza Simülasyonu

Teoride her şey güzel görünebilir ama HA’yı test etmeden canlıya almak büyük risk. Şu test senaryolarını mutlaka uygulayın.

Test 1: Node’un Graceful Kapatılması

# pve-node2'yi maintenance moduna al
ha-manager crm-command node-maintenance enable pve-node2

# Node durumunu izle
watch -n 2 'ha-manager status'

# VM'lerin diğer node'lara migrate edildiğini gözlemle
# Tüm migration tamamlandıktan sonra node'u kapat
shutdown -h now  # pve-node2'de

Test 2: Node’un Zorla Kapatılması (Gerçek Arıza Simülasyonu)

# Bu testi SADECE test ortamında yapın!
# pve-node3'te ani power-off simülasyonu
# echo c > /proc/sysrq-trigger  # Kernel panic

# pve-node1'den izleme yap
watch -n 3 'pvecm status && echo "---" && ha-manager status'

# HA manager'ın fencing başlatıp başlatmadığını kontrol et
journalctl -u pve-ha-crm -f

Test 3: Network Split Testi

# pve-node2'de ağı geçici olarak kes (dikkatli olun!)
ip link set eth0 down

# 30-60 saniye bekle ve pve-node1'den izle
# HA manager'ın node'u fence edip etmediğini gözlemle
journalctl -u pve-ha-crm --since "5 minutes ago"

# Ağı geri getir
ip link set eth0 up

Test sonuçlarını bir yere kaydedin. “Kaç saniyede failover oldu?”, “Hangi mesajlar loglandı?” gibi bilgiler ileride sorun giderirken çok işe yarar.

Corosync İnce Ayarları

Varsayılan Corosync ayarları her ortam için optimal değil. Özellikle yüksek latency’li veya kablosuz ağlarda timeout değerlerini ayarlamanız gerekebilir.

# /etc/pve/corosync.conf dosyasını düzenle
# Önce yedeğini al
cp /etc/pve/corosync.conf /root/corosync.conf.backup

cat /etc/pve/corosync.conf

Corosync’te önemli parametreler:

• token: Token timeout değeri (ms cinsinden). Default 3000ms. Yüksek latency ortamlar için artırın.
• token_retransmits_before_loss_const: Kaç token kaybından sonra node ayrılmış sayılır.
• join: Node’un kümeye katılma timeout’u.
• consensus: Quorum için gereken onay süresi.

# Corosync istatistiklerini izle
corosync-cfgtool -s

# Ring durumunu kontrol et
corosync-cfgtool -r

# Corosync üyelerini listele
corosync-cmapctl | grep members

# Corosync log'larını izle
journalctl -u corosync -f

Eğer “TOTEM: A processor failed” gibi mesajlar görüyorsanız ve network’te bir sorun yoksa, token timeout değerini artırmayı deneyin.

Günlük Yönetim ve İzleme

Küme kurulduktan sonra asıl iş başlıyor: düzenli izleme ve bakım. Birkaç pratik script paylaşayım.

#!/bin/bash
# ha-health-check.sh - Günlük HA sağlık kontrolü

echo "=== Proxmox HA Health Check ==="
echo "Tarih: $(date)"
echo ""

echo "--- Küme Durumu ---"
pvecm status

echo ""
echo "--- Node'lar ---"
pvecm nodes

echo ""
echo "--- HA Kaynakları ---"
ha-manager status

echo ""
echo "--- Storage Durumu ---"
pvesm status

echo ""
echo "--- Son 1 Saatin Kritik Log'ları ---"
journalctl -u pve-ha-crm --since "1 hour ago" -p err

echo ""
echo "--- Quorum Durumu ---"
corosync-quorumtool -s

Bu script’i cron’a ekleyip günlük mail atmasını sağlayabilirsiniz:

chmod +x /usr/local/bin/ha-health-check.sh

# Her sabah 07:00'de çalıştır ve mail gönder
echo "0 7 * * * root /usr/local/bin/ha-health-check.sh | mail -s 'HA Health Report' [email protected]" >> /etc/crontab

Sık Karşılaşılan Sorunlar ve Çözümleri

Quorum kaybolması: En sık yaşanan sorun. Node sayısı azaldığında veya network bölündüğünde quorum kaybolabilir.

# Quorum durumunu kontrol et
corosync-quorumtool -l

# DIKKAT: Sadece 2 node kaldıysa ve kesinlikle emin iseniz
# Expected votes değerini geçici olarak düşürebilirsiniz
# Bu komutu yanlış kullanmak veri kaybına neden olabilir!
pvecm expected 1  # sadece acil durumlar için

VM’in HA durumunda stuck kalması:

# Stuck durumu temizle
ha-manager set vm:100 --state stopped
ha-manager remove vm:100

# VM'i yeniden başlat ve tekrar HA'ya ekle
qm start 100
ha-manager add vm:100 --state started

Corosync ring hatası:

# Ring durumunu kontrol et
corosync-cfgtool -r

# Hatalı ring'i sıfırla
corosync-cfgtool -R

# Servis durumunu kontrol et
systemctl status corosync
journalctl -u corosync --since "30 minutes ago"

Node rejoin işlemi: Bir node uzun süre offline kaldıktan sonra kümeye katılmak istediğinde sorunlar yaşanabilir.

# Offline node'da cluster state temizle (DIKKAT!)
systemctl stop pve-ha-lrm pve-ha-crm
systemctl stop corosync pve-cluster

# /etc/corosync/corosync.conf ve /var/lib/corosync altındaki dosyaları temizle
# Sonra yeniden kümeye ekle
pvecm add 192.168.10.11 --link0 192.168.10.13

Performans İpuçları

HA migrasyonları yavaş çalışıyorsa, live migration bandwidth’ini ayarlayın:

# Tüm küme için migration bandwidth limiti ayarla (MB/s)
# /etc/pve/datacenter.cfg dosyasını düzenle
echo "migration: secure,bandwidth=500" >> /etc/pve/datacenter.cfg

# Tek bir VM için migration ayarı
qm set 100 --migrate_speed 500 --migrate_downtime 0.5

Storage’ın performansını izleyin. HA migrasyonları shared storage’ı yoğun kullanır:

# Storage I/O istatistikleri
iostat -x 2 10

# NFS özelinde istatistikler
nfsstat -c
nfsstat -s

# Hangi VM'lerin en çok I/O yaptığını gör
qm list | awk '{print $1}' | grep -E '^[0-9]+$' | while read vmid; do
  echo "VM $vmid I/O:"
  cat /proc/$(qm pid $vmid 2>/dev/null)/io 2>/dev/null | head -4
done

Yedekleme Stratejisi HA Ortamında

HA kümesinde yedekleme yaparken dikkat edilmesi gereken önemli bir nokta var: yedekleme sırasında VM migration tetiklenebilir ve bu yedekleme görevini bozabilir.

# Yedekleme sırasında HA'yı geçici olarak pasifleştirme (tavsiye edilmez)
# Bunun yerine, yedekleme saatlerinde migration'ı kısıtlayan HA grupları kullanın

# Yedekleme için özel bir HA grubu oluştur
ha-manager groupadd backup-window --nodes pve-node1:1,pve-node2:1,pve-node3:1 --nofailback 1

# Scheduled backup oluştur (tüm HA VM'leri için)
pvesh create /nodes/pve-node1/vzdump --all 1 --storage backup-storage --compress zstd --mode snapshot --mailnotification always

HA ortamında snapshot tabanlı yedekleme her zaman live yedeklemeye tercih edilmeli. Bu sayede VM’i durdurmadan tutarlı yedek alabilirsiniz.

Sonuç

Proxmox HA kümesi, doğru kurulduğunda ve düzenli test edildiğinde gerçekten hayat kurtaran bir yapı. Ama “kurdum, bitti” diye düşünmek tehlikeli. Şu noktaları unutmayın:

Fencing’i mutlaka yapılandırın ve test edin. Fencing olmayan HA, yarım kalmış bir sigorta gibidir. Quorum matematik basit: 3 node varsa, en az 2’si ayakta olmalı. Bu yüzden 3 node minimumunu hiçbir zaman esnetmeyin.

Shared storage güvenilirliği HA’nın temelidir. NFS iyi bir başlangıç noktası ama üretim ortamı için Ceph veya kaliteli bir iSCSI çözümüne geçmeyi düşünün. Aylık test rutini oluşturun. Test etmediğiniz HA, çalışmayan HA demektir.

Log’ları düzenli izleyin. Corosync ve HA manager logları size gerçek bir arıza olmadan önce ipuçları verir. Ve son olarak: HA tek başına yeterli değil. HA + düzenli yedekleme + monitoring üçlüsü olmadan eksiksiz bir yüksek erişilebilirlik stratejisi kurulamaz.