Serwer do Proxmox VE – jak dobrać RAM, dyski i sieć do węzła i klastra

Serwer do Proxmoksa dobiera się od pamięci masowej, a nie od procesora. Wybór między ZFS a Ceph przesądza, ile RAM-u kupić, jaki kontroler dysków zamówić i czy potrzebna będzie osobna sieć 10 Gbps. O liczbie rdzeni dokumentacja mówi najmniej. Poniżej rachunek oparty na dokumentacji Proxmox VE 9.2 (odczyt: 10 października 2026 r.) i przykład z podanymi założeniami.

Wartości minimalne z dokumentacji, czyli 1 GB RAM, jeden dysk i jedna karta sieciowa, producent opisuje jako wystarczające do oceny produktu, ale nie na produkcję. Dalej mowa o zaleceniach dla produkcji.

Najpierw liczba węzłów i rodzaj storage

Od tego zależy reszta listy zakupowej.

• Jeden węzeł z ZFS to najprostszy wariant. Gdy sprzęt się zepsuje, maszyny stoją do czasu naprawy.
• Dwa węzły wymagają QDevice. Dokumentacja przewiduje go jako trzeci głos w małych klastrach dwuwęzłowych.
• Trzy węzły i więcej to punkt wyjścia dla wysokiej dostępności, bo kworum jest wtedy wiarygodne. Ceph w układzie hiperkonwergentnym też wymaga co najmniej trzech serwerów, najlepiej identycznych.

Jak te warianty wyglądają w małej firmie, opisuje wpis o architekturze Proxmox VE w MŚP. Różnice między ZFS, LVM-thin i Ceph porównuje tekst ZFS vs LVM-thin vs Ceph. Poniżej wybór storage jest już dokonany i liczony jest sprzęt.

Ile RAM-u: host, ZFS albo Ceph, a dopiero potem maszyny

System i usługi Proxmoksa potrzebują minimum 2 GB. Do tego dochodzi pamięć dla maszyn i, zależnie od storage, pamięć dla ZFS albo Ceph.

Przy ZFS dokumentacja radzi mieć co najmniej 8 GB, żeby w ogóle zacząć. Domyślnie cache ARC dostaje 10 % pamięci hosta, ale nie więcej niż 16 GiB. Jako regułę kciuka dokumentacja podaje 2 GiB bazy plus 1 GiB na każdy TiB pamięci masowej. Jej przykład: pula 8 TiB oznacza 10 GiB dla ARC. Zaleca też pamięć ECC dobrej jakości.

Przy Ceph producent zaleca co najmniej 8 GiB pamięci na każdy demon OSD (domyślnie demon bierze 4 GiB). Całkowite zużycie wynika głównie z liczby OSD, a podczas odbudowy i rebalansowania rośnie. Dlatego dokumentacja każe nie dobijać do limitu pamięci już w normalnej pracy.

Procesor: rdzenie, producent i gniazda

Do wirtualizacji potrzebny jest procesor Intel 64 lub AMD64 z flagą Intel VT lub AMD-V. Rdzeni nie da się podać jedną liczbą, bo zależą od maszyn. Jedyną regułą wprost jest Ceph: przynajmniej jeden rdzeń lub wątek na każdą usługę Ceph. Węzeł z jednym monitorem, jednym managerem i sześcioma OSD potrzebuje więc ośmiu rdzeni tylko dla Ceph. Przy dyskach NVMe o bardzo wysokiej wydajności jeden OSD może zająć cztery do sześciu wątków.

Dwie rzeczy łatwo przeoczyć przy dokupowaniu węzła do istniejącego klastra:

• Migracja maszyn na żywo jest wspierana tylko między węzłami z procesorami tego samego producenta. Między Intelem a AMD nie ma gwarancji, że zadziała.
• Domyślny typ procesora nowej maszyny to x86-64-v2-AES, który wymaga procesora od generacji Westmere (Intel) albo co najmniej czwartej generacji Opteron (AMD). Jeśli klaster ma mieszane generacje, dokumentacja radzi wybrać model odpowiadający najstarszemu węzłowi.

Procesor wpływa też na koszt subskrypcji. Według strony producenta subskrypcja Proxmox VE jest wymagana dla każdego zajętego fizycznego gniazda procesora, a liczba rdzeni nie wpływa na cenę. Wszystkie węzły klastra muszą mieć ten sam poziom subskrypcji. Serwer dwugniazdowy to więc dwie subskrypcje, jednogniazdowy – jedna. Aktualną cenę w złotych policzy kalkulator subskrypcji, a plany opisuje cennik.

Dyski i kontroler: HBA zamiast RAID dla ZFS i Ceph

Producent zaleca szybką, redundantną pamięć masową, najlepiej na SSD. Dla dysków maszyn rekomenduje SSD z zabezpieczeniem przed utratą zasilania (PLP) i odradza dyski konsumenckie.

Kontroler zależy od storage:

• Dysk systemowy ma stać na sprzętowym RAID-zie z podtrzymaniem bateryjnym pamięci zapisu (BBU) albo na ZFS bez RAID-u sprzętowego.
• ZFS nie powinien pracować na kontrolerze RAID z własną pamięcią podręczną. Dokumentacja zaleca HBA albo kontroler w trybie IT.
• Ceph też ma dostać dyski bez warstwy pośredniej, bo dokumentacja mówi wprost: unikaj kontrolerów RAID, użyj HBA. Zalecany jest jeden OSD na fizyczny dysk, w miarę podobne rozmiary dysków w każdym węźle i, dla klastra trzywęzłowego, co najmniej 12 OSD rozłożonych równo. W małych klastrach lepsze są SSD, bo skracają czas odbudowy po awarii.

Sieć: osobny tor dla corosync i dla Ceph

Podstawą są redundantne karty wielogigabitowe, a ich liczba zależy od storage i klastra.

Komunikacja klastra (corosync) jest czuła na opóźnienia, a przepustowości prawie nie zużywa. Dokumentacja wymaga opóźnień poniżej 5 ms między węzłami i uznaje osobną kartę 1 Gbit za wystarczającą. Sieci corosync nie należy dzielić ze storage. Drugi link powinien iść inną fizyczną siecią, bo pojedynczy link oparty na bondzie sprawia kłopot przy części awarii.

Ceph potrzebuje co najmniej 10 Gbps wyłącznie dla swojego ruchu. W klastrach trzy- do pięciowęzłowych dopuszczalna jest sieć mesh, gdy brakuje przełączników 10 Gbps. Pojedynczy dysk NVMe potrafi sam wysycić 10 Gbps, a dla takich konfiguracji zalecane jest 25 Gbps lub więcej.

Przykład rachunku (założenia przykładowe, nie pomiary)

Załóżmy trzy węzły z wysoką dostępnością, na każdym 15 maszyn po 8 GiB, czyli 120 GiB dla gości. Zakładam, że po awarii jednego węzła dwa pozostałe mają przejąć jego maszyny, więc każdy musi unieść 180 GiB gości (120 GiB własnych plus połowa z padniętego węzła, czyli 60 GiB).

• ZFS i pula 8 TiB użytecznych: host 2 GiB, ARC 10 GiB (przykład z dokumentacji), goście 180 GiB, razem 192 GiB na węzeł.
• Ceph i cztery OSD na węzeł (razem 12): host 2 GiB, OSD 4 × 8 GiB = 32 GiB, goście 180 GiB, razem 214 GiB, a do tego pamięć usług MON i MGR oraz zapas na odbudowę. Rdzenie tylko dla Ceph: monitor, manager i cztery OSD to sześć.

Liczby gości są przykładem. Twoje maszyny mogą być lżejsze albo cięższe, ale kolejność rachunku zostaje ta sama: host, storage, goście, rezerwa na awarię węzła.

Przed zamówieniem sprzętu

• Ustal storage i liczbę węzłów.
• Zsumuj pamięć: host, ARC albo OSD, goście oraz rezerwa na przejęcie maszyn po awarii.
• W istniejącym klastrze sprawdź producenta i generację procesora.
• Wybierz HBA do ZFS i Ceph oraz dyski z PLP.
• Zaplanuj osobną kartę pod corosync i, przy Ceph, sieć 10 Gbps wyłącznie dla niego.
• Policz liczbę gniazd, bo od niej zależy liczba subskrypcji.

W usługach Proxmox Polsoft wymienia konfigurację sieci, projektowanie storage i dobór komponentów sprzętowych. Jeśli chcesz sprawdzić własny rachunek przed zamówieniem, możesz umówić bezpłatną konsultację. Kopie zapasowe powinny stać na osobnym serwerze, nie na tych samych węzłach. Jak go dobrać, opisujemy w tekście o serwerze pod Proxmox Backup Server.

Źródła (odczyt 10.10.2026)

• Proxmox VE: wymagania systemowe
• Proxmox VE: ZFS, pamięć i ARC
• Proxmox VE: klaster, kworum i sieć corosync
• Proxmox VE: Ceph, zalecenia sprzętowe
• Proxmox VE: typy procesora maszyny wirtualnej
• Proxmox VE: subskrypcje