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