Proxmox HA (Yüksek Erişilebilirlik) Kurulumu

Bir hipervizörün anakartı gece yarısı öldü. Üzerindeki on iki sanal makine de onunla birlikte gitti ve sabah birisi fark edene kadar hizmet vermediler. Proxmox HA kurulumu tam olarak bu senaryoyu ortadan kaldırmak için vardır: küme bir düğümün öldüğünü kendisi anlar, o düğümün sanal makinelerini hayatta kalan düğümlerde otomatik olarak başlatır ve bunu insan müdahalesi olmadan birkaç dakika içinde yapar.

Ancak HA, üstüne "aç" düğmesine basılan bir özellik değildir; altında paylaşımlı depolama, sağlıklı bir corosync ağı ve doğru çalışan bir fencing mekanizması olmadan kurulu olmaması daha güvenlidir. Yanlış yapılandırılmış bir HA, ağ hıçkırığında sağlıklı sunucuları kendiliğinden yeniden başlatarak var olmayan bir arızayı gerçek bir kesintiye çevirir. Bu rehberde HA'nın nasıl çalıştığını, ön koşulları, ha-manager ile kaynak ve grup tanımlamayı, fencing/watchdog mantığını, doğru test yöntemini ve tuzakları anlatacağım. Kümeniz yoksa önce Proxmox cluster kurulumu yazısıyla başlayın.

HA Mimarisi: CRM, LRM ve Durum Makinesi#

Proxmox'un HA yığını iki bileşenden oluşur ve ikisinin iş bölümünü bilmek, log okurken çok işe yarar.

CRM (Cluster Resource Manager) kümede tek bir düğümde aktif çalışır; buna "master" denir. Kümenin genel durumuna bakar, hangi kaynağın hangi düğümde olması gerektiğine karar verir ve bu kararları paylaşılan durum dosyasına yazar. Master düğüm kaybolursa kalan düğümler aralarında yeni bir master seçer.

LRM (Local Resource Manager) ise her düğümde çalışır. CRM'in verdiği kararları kendi düğümünde uygular: sanal makineyi başlatır, durdurur ya da göç ettirir. LRM ayrıca düğümün kendisinin sağlıklı olup olmadığını izler.

İkisi arasındaki iletişim /etc/pve üzerinden, yani corosync'in senkronize ettiği dosya sistemi üzerinden yürür. Bu nedenle corosync sağlığı doğrudan HA sağlığıdır: quorum kaybolduğunda /etc/pve salt okunur olur, LRM kararları yazamaz ve düğüm kendini güvenli tarafa çeker.

Bir kaynak (VM ya da konteyner) HA'ya alındığında bir durum makinesine girer:

error durumu özellikle önemlidir: HA sonsuza kadar denemez. max_restart ve max_relocate sayaçları tükendiğinde kaynak error durumuna alınır ve orada bekler. Bu kasıtlıdır — bozuk bir sanal makineyi sonsuz döngüde başlatmaya çalışmak, kümenin tamamını meşgul etmekten başka işe yaramaz.

Ön Koşullar — Atlanamayacak Üç Madde#

HA kurmadan önce üç şeyin sağlandığından emin olun. Bunlar öneri değil, işleyişin matematiksel gereğidir.

1. En az üç düğüm (ya da iki düğüm + QDevice). HA kararları quorum gerektirir. İki düğümlü bir kümede bir düğüm çöktüğünde kalan düğüm quorum sağlayamaz, dolayısıyla hiçbir karar alamaz ve HA çalışmaz. Üç düğüm, bir düğüm kaybında quorum'u korur. İki düğümünüz varsa mutlaka bir QDevice ekleyin:

# Tanık makinede
apt install -y corosync-qnetd && systemctl enable --now corosync-qnetd

# Proxmox düğümlerinde
apt install -y corosync-qdevice

# Bir düğümde kurulum
pvecm qdevice setup 10.10.10.20
pvecm status | grep -A4 Qdevice

2. Paylaşımlı depolama. Bu maddenin pazarlığı yoktur. Bir düğüm çöktüğünde diğer düğümlerin o makinenin diskine erişebilmesi gerekir; yerel ZFS ya da yerel LVM üzerindeki bir disk, düğümle birlikte erişilemez hâle gelir. Ceph, NFS ya da iSCSI kullanın. Ceph kurulumunu Proxmox'ta Ceph ile dağıtık depolama yazısında ele aldım.

3. Sağlıklı ve ayrılmış corosync ağı. HA, corosync'in "bu düğüm cevap vermiyor" demesine güvenerek sunucu yeniden başlatır. Corosync trafiği yedekleme ya da göç trafiğiyle aynı hattaysa, hattın dolduğu her an sahte bir arıza sinyaline dönüşür. Sonuç: sağlıklı sunucular gece yarısı kendiliğinden yeniden başlar. Ağ ayrımını Proxmox ağ yapılandırması: bridge ve VLAN yazısında anlattım.

Kontrol listesini komutlarla doğrulayın:

# Quorum var mı, kaç oy
pvecm status | grep -E 'Quorate|Expected votes|Total votes'

# Corosync halkaları sağlıklı mı
corosync-cfgtool -s

# Depolama paylaşımlı mı (shared 1 olmalı)
grep -A5 -E '^(rbd|nfs|iscsi)' /etc/pve/storage.cfg

# HA servisleri çalışıyor mu
systemctl status pve-ha-crm pve-ha-lrm --no-pager | grep Active

Fencing ve Watchdog Nasıl Çalışır#

Fencing, dağıtık sistemlerin en kritik ve en yanlış anlaşılan kavramıdır. Problem şudur: bir düğüm ağdan kayboldu. Bu düğüm gerçekten öldü mü, yoksa yalnızca ağ kablosu mu çıktı? İkinci durumda düğüm hâlâ çalışıyor, hâlâ diske yazıyor olabilir. O sanal makineyi başka bir düğümde de başlatırsanız, aynı diske iki makine birden yazar ve dosya sistemi geri dönüşsüz biçimde bozulur. Buna "split-brain" denir ve HA'nın var olma sebebi kadar korkulan bir şeydir.

Fencing bu belirsizliği ortadan kaldırır: kaybolan düğümün kesinlikle çalışmadığından emin olunur, ancak ondan sonra makineleri başka yerde başlatmaya izin verilir.

Proxmox bunu watchdog mekanizmasıyla çözer ve çözüm zarif biçimde tersinedir. Her düğümdeki LRM, düzenli aralıklarla bir donanım ya da yazılım zamanlayıcısını sıfırlar ("besler"). Düğüm quorum kaybederse LRM zamanlayıcıyı beslemeyi bırakır; zamanlayıcı dolduğunda düğüm kendini yeniden başlatır. Yani düğüm dışarıdan kapatılmaz, kendini kapatır. Kalan düğümler ise "bu süre kadar bekledim, o düğüm mutlaka yeniden başlamıştır" diyerek makineleri güvenle devralır.

Varsayılan olarak softdog yazılım zamanlayıcısı kullanılır ve çoğu kurulum için yeterlidir. Sunucunuzda IPMI/BMC varsa donanım watchdog'u daha güvenilirdir, çünkü çekirdek tamamen kilitlense bile çalışır:

# Hangi watchdog modülü yüklü
lsmod | grep -E 'wdt|softdog'
cat /sys/class/watchdog/watchdog0/identity

# Donanım watchdog'u kullanmak için (sunucu modeline göre modül adı değişir)
# /etc/default/pve-ha-manager
WATCHDOG_MODULE=ipmi_watchdog

# Softdog'un devre dışı kalması için modülü kara listeye al
echo "blacklist softdog" > /etc/modprobe.d/blacklist-softdog.conf
update-initramfs -u && reboot

Buradaki en önemli davranışsal sonucu tekrar vurgulayayım: HA etkin bir kümede quorum kaybeden düğüm kendini yeniden başlatır. Bu, corosync ağınızdaki her sorunun potansiyel bir sunucu yeniden başlatması demek olduğu anlamına gelir. HA açmadan önce corosync ağınızın gerçekten sağlam olduğundan emin olun; bu, rehberdeki en önemli cümle olabilir.

Kaynak ve Grup Tanımlama#

Ön koşullar sağlandıysa asıl yapılandırma oldukça kısadır. Bir sanal makineyi HA yönetimine almak tek komuttur:

# VM'i HA'ya al
ha-manager add vm:101 --state started --max_restart 3 --max_relocate 2

# LXC konteyneri için
ha-manager add ct:200 --state started

# Durumu gör
ha-manager status
# Örnek çıktı:
# quorum OK
# master pve1 (active, Mon Aug 24 03:11:02 2026)
# lrm pve1 (active, Mon Aug 24 03:11:05 2026)
# lrm pve2 (active, Mon Aug 24 03:11:03 2026)
# service vm:101 (pve1, started)

# Ayarı sonradan değiştir
ha-manager set vm:101 --max_restart 5

# Elle başka düğüme taşı
ha-manager migrate vm:101 pve2

# HA yönetiminden çıkar
ha-manager remove vm:101

max_restart aynı düğümde kaç kez yeniden başlatılacağını, max_relocate ise başka bir düğümde kaç kez denenceğini belirtir. İkisi de tükendiğinde kaynak error durumuna girer ve sizin müdahalenizi bekler.

HA grupları, hangi kaynağın hangi düğümlerde çalışabileceğini ve tercih sırasını belirler. Lisans kısıtı olan bir yazılımı yalnızca belirli düğümlerde çalıştırmak ya da bir makineyi normalde en güçlü düğümde tutmak için kullanılır:

# /etc/pve/ha/groups.cfg
group: uretim
	nodes pve1:2,pve2:1,pve3:1
	restricted 1
	nofailback 0

group: sadece-guclu
	nodes pve1:1,pve2:1
	restricted 1
	nofailback 1

Sözdizimini açalım. pve1:2 ifadesindeki sayı önceliktir; yüksek olan tercih edilir. restricted 1, kaynağın yalnızca listedeki düğümlerde çalışmasına izin verir; 0 ise liste dışındaki düğümleri son çare olarak kabul eder. nofailback 1 ise tercih edilen düğüm geri geldiğinde kaynağın otomatik olarak geri dönmemesini sağlar — bu, gereksiz ikinci bir kesintiyi önlediği için üretimde genellikle tercih edilir.

# Kaynağı bir gruba bağla
ha-manager set vm:101 --group uretim

# Grupları listele
cat /etc/pve/ha/groups.cfg

HA'yı Test Etmek ve Bakım Modu#

Test edilmemiş bir HA yapılandırması, olmayan bir HA'dan daha tehlikelidir; çünkü size sahte bir güven verir. Testi üretime çıkmadan önce, planlı olarak yapın.

Test için yeni bir sanal makine oluşturun (üretim makinesiyle test yapmayın), HA'ya alın ve şu senaryoları sırayla deneyin:

1. Yumuşak test — elle taşıma. ha-manager migrate vm:999 pve2 çalıştırın ve makinenin sorunsuz taşındığını doğrulayın. Bu, temel yapılandırmanın çalıştığını gösterir.
2. Servis testi. Hedef düğümde makineyi elle kapatın (qm stop 999) ve HA'nın onu tekrar başlattığını izleyin. max_restart mekanizması burada devreye girer.
3. Sert test — düğüm kaybı. Bir düğümün ağ kablosunu çekin ya da güç kaynağını kesin. Kalan düğümler quorum'u korumalı, kaybolan düğüm kendini yeniden başlatmalı ve makineleri birkaç dakika içinde devralmalıdır.
4. Süreyi ölçün. Makinenin ne kadar sürede hizmet vermeye başladığını not edin; bu sizin gerçek kurtarma sürenizdir ve genellikle beklenenden uzundur.
5. Log okuyun. Testten sonra süreçte ne olduğunu anlayın; gerçek bir arızada log okumayı ilk kez denemek istemezsiniz.

# HA olaylarını canlı izle
journalctl -u pve-ha-crm -u pve-ha-lrm -f

# Geçmişe bak
journalctl -u pve-ha-crm --since "2 hours ago" | grep -iE 'fence|error|migrate'

# Kaynak durumları
ha-manager status --verbose

Planlı bakım yaparken düğümü bakım moduna almalısınız. Bunu yapmadan bir düğümü kapatırsanız HA onu arıza sanar ve fencing süreci başlar; oysa yalnızca yeniden başlatmak istiyordunuz:

# Bakım modu: makineler düzgünce boşaltılır, HA arıza saymaz
ha-manager crm-command node-maintenance enable pve1

# Boşaldığını doğrula
qm list; pct list

# Bakım bitince
ha-manager crm-command node-maintenance disable pve1

Bir kaynak error durumuna düştüyse, sorunu giderdikten sonra durumu elle sıfırlamanız gerekir:

# Önce sorunun kaynağını bul, sonra
ha-manager set vm:101 --state disabled
ha-manager set vm:101 --state started

Sık Yapılan Hatalar#

Yerel depolama ile HA kurmak. Düğüm çöktüğünde diskine erişilemez, dolayısıyla makine başka düğümde açılamaz. HA "started" demeye çalışır, başarısız olur ve error durumuna düşer. Paylaşımlı depolama olmadan HA açmayın.

Corosync'i paylaşımlı hatta bırakıp HA açmak. Bu kombinasyon, ağın doyduğu her an sunucuların kendiliğinden yeniden başlaması demektir. Bir yedekleme işi kümenin yarısını yeniden başlatabilir. Ağ ayrımı HA'nın ön koşuludur, ince ayarı değil.

İki düğümde QDevice'sız HA denemek. Bir düğüm çöktüğünde kalan düğüm quorum sağlayamaz ve hiçbir şey yapamaz. HA görünürde kuruludur ama gerçek arızada işe yaramaz.

Test etmeden üretime almak. Fencing'in çalıştığını, watchdog modülünün yüklendiğini ve devralma süresinin kabul edilebilir olduğunu ancak test ederek bilirsiniz.

HA'yı yedeklemenin yerine koymak. HA donanım arızasına karşı korur; silinen veriyi, bozulan veritabanını ya da fidye yazılımını geri getirmez — bu değişiklikler paylaşımlı depolamaya anında yazılır. Yedekleme kurgusu ayrıca gereklidir; Proxmox yedekleme ve geri yükleme ve Proxmox Backup Server kurulumu yazıları bu tarafı anlatıyor.

Her makineyi HA'ya almak. HA devralma sırasında makine yeniden başlar; yani kesintisiz değildir, "kısa kesinti sonrası otomatik kurtarma"dır. Durumsuz test makineleri için bu maliyet gereksizdir. Gerçekten kritik olanları seçin.

Sıkça Sorulan Sorular#

Proxmox HA için en az kaç sunucu gerekir#

Üç düğüm önerilir, çünkü HA kararları quorum gerektirir ve üç düğüm bir düğüm kaybında quorum'u korur. İki düğümle çalışmak istiyorsanız mutlaka bir QDevice ekleyin; küçük bir Debian makinesi yalnızca oy vermek için kümeye katılır ve iki düğümlü kurulumu HA'ya uygun hâle getirir. QDevice'sız iki düğümde HA gerçek bir arızada işe yaramaz.

HA kesintisiz hizmet sağlar mı#

Hayır, HA kesintisizlik değil otomatik kurtarma sağlar. Bir düğüm çöktüğünde üzerindeki sanal makineler başka bir düğümde yeniden başlatılır; yani makine sıfırdan açılır, işletim sistemi yeniden yüklenir ve uygulamalar yeniden başlar. Tipik kurtarma süresi birkaç dakikadır. Gerçekten kesintisiz çalışma istiyorsanız uygulama katmanında kümeleme yapmanız gerekir.

Fencing nedir ve neden gerekli#

Fencing, ağdan kaybolan bir düğümün gerçekten çalışmadığından emin olma sürecidir. Bu güvence olmadan sanal makineyi başka düğümde başlatırsanız, iki makine aynı diske yazabilir ve dosya sistemi geri dönüşsüz bozulur. Proxmox bunu watchdog ile çözer: quorum kaybeden düğüm kendini yeniden başlatır, kalan düğümler bu süre kadar bekleyip makineleri güvenle devralır.

HA açtıktan sonra sunucularım kendiliğinden yeniden başlıyor#

Bu neredeyse her zaman corosync ağı sorunudur. Quorum kaybeden bir düğüm, HA etkinken watchdog süresi dolduğunda kendini yeniden başlatır. Corosync trafiğinin yedekleme, göç ya da depolama trafiğiyle aynı hattı paylaşıp paylaşmadığını kontrol edin ve journalctl -u corosync çıktısında yeniden iletim (retransmit) mesajlarına bakın. Çözüm, corosync'e ayrı ve düşük gecikmeli bir hat vermektir.

Hangi sanal makineleri HA'ya almalıyım#

Kesintisi gerçekten maliyetli olanları seçin: veritabanı sunucuları, ana uygulama sunucuları, e-posta ve kimlik doğrulama servisleri. Test makineleri, geliştirme ortamları ve durumsuz yardımcı servisler için HA'nın getirdiği karmaşıklık genellikle gereksizdir. Her makineyi HA'ya almak, gerçek arızada devralma sırasını gereksiz yere uzatır.

HA yedekleme yerine geçer mi#

Kesinlikle hayır. HA donanım arızasına karşı korur; yanlışlıkla silinen bir dosyayı, bozulan bir veritabanını ya da fidye yazılımının şifrelediği verileri geri getirmez, çünkü bu değişiklikler paylaşımlı depolamaya anında yazılır ve tüm düğümlerden aynı şekilde görünür. HA'yı erişilebilirlik, yedeklemeyi ise zaman içinde geri dönüş mekanizması olarak düşünün; ikisi birbirinin yerine geçmez.

Kapanış#

Proxmox HA, doğru zemin üzerine kurulduğunda gece yarısı ölen bir anakartın sabaha kadar süren bir kesintiye dönüşmesini engeller. Ama bu "doğru zemin" ifadesi somut üç şeyi kapsar ve hiçbiri isteğe bağlı değildir: quorum'u koruyabilen bir düğüm sayısı, paylaşımlı depolama ve corosync'e ayrılmış sağlıklı bir ağ. Bunlara ek olarak akılda tutulması gereken dört alışkanlık şudur: HA'yı üretime almadan önce sert testini yapın, planlı bakımda mutlaka bakım modunu kullanın, yalnızca gerçekten kritik makineleri HA'ya alın ve HA'yı asla yedeklemenin yerine koymayın.

HA'nın altındaki katmanları henüz kurmadıysanız Proxmox'ta Ceph ile dağıtık depolama ile paylaşımlı depolamayı, Proxmox'ta canlı göç ile de planlı bakım yeteneğini tamamlamanız gerekir. Yüksek erişilebilir bir küme kuracağınız donanım arıyorsanız dedicated sunucu ve colocation seçeneklerimiz uygun bir zemin sunar; bu karmaşıklığı hiç üstlenmeden yedekli bir altyapıda çalışmak isterseniz bulut sunucu paketlerimiz zaten böyle bir yapı üzerinde durur. Küme işletimini devretmek isterseniz sunucu yönetimi hizmetimiz devreye girer.