DEV Community

Hakan İSMAİL
Hakan İSMAİL

Posted on

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

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

pmxcfs log satırı - node adının management IP'sine çözümlenmesi

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/
Enter fullscreen mode Exit fullscreen mode

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

/etc/pve/nodes/ dizini - cluster öncesi, sadece pve-a

Uygulama 2: Cluster'ı Kurmak

Cluster'ı GUI'den Oluşturmak

Create Cluster ekranı - cluster ismi ve Link seçimi

Create Cluster - Link 1 için corosync-net arayüzü (10.10.10.11) seçili

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ı.

Datacenter → Cluster - lab-cluster oluşturuldu, tek node (pve-a)

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
Enter fullscreen mode Exit fullscreen mode 
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)
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
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.
Enter fullscreen mode Exit fullscreen mode

Ç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.

Join Information ekranı - pve-a, encode edilmiş bilgi bloğu

Join Information - kopyala butonu

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.

Cluster Join ekranı - pve-c, Link 1 otomatik önerisi (10.10.10.13)

Cluster Join ekranı - Peer Address ve Fingerprint otomatik dolu

"Join 'lab-cluster'" dedim.

Task viewer - Join Cluster,

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
Enter fullscreen mode Exit fullscreen mode

pve-c katıldıktan sonra:

Nodes:            3
Quorate:          Yes
Expected votes:   3
Total votes:      3
Quorum:           2
Enter fullscreen mode Exit fullscreen mode

pvecm nodes:

    Nodeid      Votes Name
         1          1 pve-a (local)
         2          1 pve-b
         3          1 pve-c
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

cat /etc/pve/test-sync.txt
Enter fullscreen mode Exit fullscreen mode 
cluster calisiyor
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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/
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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.

Alpine Linux Sanal Makine Detayları

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

qm migrate 100 pve-b --online --with-local-disks
Enter fullscreen mode Exit fullscreen mode 
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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

qm status 100
Enter fullscreen mode Exit fullscreen mode 
status: running
Enter fullscreen mode Exit fullscreen mode

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

pvesh get /cluster/resources --type vm
Enter fullscreen mode Exit fullscreen mode 
│ id       │ type │ ... │ name   │
│ qemu/100 │ qemu │ ... │ alpine │
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
Domain 'pve-b' destroyed
Enter fullscreen mode Exit fullscreen mode

pve-a'dan cluster durumuna baktım:

pvecm status
Enter fullscreen mode Exit fullscreen mode 
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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode 
Configuration file 'nodes/pve-a/qemu-server/100.conf' does not exist
Enter fullscreen mode Exit fullscreen mode

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
Enter fullscreen mode Exit fullscreen mode

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

pvecm status
Enter fullscreen mode Exit fullscreen mode 
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
Enter fullscreen mode Exit fullscreen mode

Üç 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.

Top comments (0)