Klaster Proxmox VE — konfiguracja krok po kroku

Czym jest klaster Proxmox VE

Klaster Proxmox to grupa serwerów z zainstalowanym Proxmox VE, które wspólnie zarządzają maszynami wirtualnymi. Zapewnia wysoką dostępność (HA), live migration, centralne zarządzanie i replikację konfiguracji. Klaster używa Corosync do synchronizacji stanu i pmxcfs (rozproszonego systemu plików) do replikacji konfiguracji w czasie rzeczywistym.

W praktyce klaster pozwala na:

• Migrację VM między fizycznymi serwerami bez wyłączania (live migration)
• Automatyczny restart VM na innym węźle po awarii sprzętu (HA)
• Centralne zarządzanie z dowolnego node-a (panel zarządzania pokazuje wszystkie VM)
• Replikację storage (z Ceph) lub współdzielenie (z NFS/iSCSI)
• Skalowanie horyzontalne — dodawanie kolejnych serwerów bez przerw w pracy

Wymagania klastra

Minimum sprzętowe

Wymagania sieciowe

Sieć jest często niedoceniana — to ona decyduje o stabilności klastra. Krytyczne parametry:

• Latency corosync < 5 ms (idealnie < 2 ms) — przekroczenie powoduje fencing węzła
• Jitter < 2 ms — niestabilność powoduje fałszywe wykrywanie awarii
• Brak utraty pakietów w sieci corosync — utrata 2 kolejnych = wyrzucenie z klastra
• Multicast lub unicast — w nowoczesnych deploymentach unicast (znacznie prostszy)
• Redundancja — link0 + link1 na różnych switchach (high availability sieci)

Konfiguracja klastra — krok po kroku

1. Zainstaluj Proxmox VE na każdym węźle

   Pobierz ISO z proxmox.com/downloads, zbootuj na każdym serwerze. Wybierz ZFS (rpool) jako storage system — daje lokalną replikację i snapshoty. Po instalacji zaktualizuj system: apt update && apt full-upgrade.

2. Skonfiguruj sieć dedykowaną corosync

   Dodaj drugi interfejs (np. eno2) w trybie bridge (vmbr1) na osobnym VLAN. Przykład w /etc/network/interfaces:

   auto vmbr1
   iface vmbr1 inet static
       address 10.10.10.11/24
       bridge-ports eno2
       bridge-stp off
       bridge-fd 0
       mtu 9000  # jumbo frames jeśli switch obsługuje

   Powtórz na każdym węźle z odpowiednim IP (10.10.10.11/12/13).

3. Utwórz klaster na pierwszym węźle

   # Na node1
   pvecm create produkcja01 -link0 10.10.10.11
   
   # Weryfikacja
   pvecm status

   Wynik: Quorate: Yes, Total votes: 1 (na razie sam).

4. Dołącz pozostałe węzły

   # Na node2 (i node3)
   pvecm add 10.10.10.11 -link0 10.10.10.12  # node2
   pvecm add 10.10.10.11 -link0 10.10.10.13  # node3
   
   # Po każdym add:
   pvecm status  # Total votes powinno rosnąć

   Po dodaniu 3. węzła Total votes: 3, Quorate: Yes — klaster działa.

5. Skonfiguruj HA Manager (dla automatycznego restartu VM po awarii)

   W panelu webowym: Datacenter → HA → Groups → Create. Wybierz węzły dla danej grupy. Następnie Datacenter → HA → Resources → Add → wybierz VM/CT. Stan: ha-manager status.

6. Dodaj shared storage (NFS, iSCSI lub Ceph)

   Dla małych klastrów: NFS share z 4. serwera lub NAS. Dla średnich/dużych: Ceph hyperconverged (na tych samych węzłach). Konfiguracja Ceph: pveceph install, pveceph init --network 10.10.20.0/24, pveceph mon create na 3 węzłach, pveceph osd create /dev/sdX dla każdego dysku Ceph.

7. Test failover — symulacja awarii

   # Na node1 z HA-managed VM
   qm set 100 --ha 1  # włącz HA dla VM 100
   shutdown -h now    # symuluj awarię node1
   
   # Z node2 obserwuj (po ~2 min)
   ha-manager status  # VM 100 powinno zmienić node na node2/node3

   VM zostanie automatycznie zrestartowana na innym węźle. To dowód że HA działa.

Klaster vs HA vs Ceph — co to jest co

Najczęstsze błędy przy wdrożeniu

1. Brak dedykowanej sieci corosync — fragmentacja klastra pod obciążeniem. Zawsze osobny VLAN.
2. Tylko 2 węzły bez QDevice — split-brain przy partition. Dodaj 3. węzeł lub QDevice.
3. HA bez shared storage — HA wymaga aby VM dane były dostępne na każdym węźle. Bez tego HA nie działa.
4. Mieszanie hardware bez ujednolicenia CPU — live migration zawodzi. Ustaw cpu: kvm64 lub jednolite typy.
5. Pominięcie testu failover — pierwsza prawdziwa awaria pokazuje że HA nie było prawidłowo skonfigurowane. Testuj!
6. Brak monitoringu kworum — strata kworum = read-only mode. Dodaj alert Zabbix na pvecm status.
7. Network bonding źle skonfigurowany — LACP wymaga konfiguracji po stronie switcha. Częsta przyczyna fencingu.

Kiedy warto, kiedy nie warto

Warto wdrożyć klaster gdy:

• Masz 3+ serwery i potrzebujesz HA dla krytycznych aplikacji (ERP, e-commerce, bazy danych)
• Wymagana ciągłość pracy 24/7 (SLA 99.9%+)
• Chcesz live migration dla planowanych przerw konserwacyjnych
• Skalujesz infrastrukturę i chcesz dodawać serwery bez przerw
• Masz wymagania compliance (ISO 27001, NIS2) co do redundancji

Nie warto klastra gdy:

• Masz tylko 1-2 serwery — prościej i taniej zrobić replikację offline + ręczny failover
• Brak budżetu na 3 serwery + dedykowaną sieć — koszt sprzętu i konfiguracji nieadekwatny do skali
• Aplikacje są stateless (cloud-native) — kontenery Kubernetes mogą być lepszą opcją
• Wymagania SLA są niskie (RPO/RTO > 4 godzin) — backup + restore wystarczy

Cennik wdrożenia

Pełna usługa wdrożenia klastra Proxmox dla firm (audyt sprzętu → konfiguracja → dokumentacja → szkolenie):

Ceny obejmują: wstępny audyt sprzętu, konfigurację, dokumentację techniczną, 30 dni wsparcia powdrożeniowego, szkolenie 1-dniowe dla administratorów. Sprzęt po stronie klienta lub dostarczamy w wycenie indywidualnej.

Często zadawane pytania (FAQ)

Powiązane materiały

• ZFS vs Ceph — który storage do klastra?
• Proxmox VE vs VMware vSphere 2026
• Proxmox Backup Server — przewodnik
• Cennik subskrypcji Proxmox
• Migracja VMware → Proxmox