Konfigurator serwera do wirtualizacji firmowej – jak dobrać moc pod VM-ki?

Wirtualizacja kusi prostotą - „wrzuć VM-ki na host i działa”. W praktyce to działa tylko wtedy, gdy rdzenie, RAM i storage zostały policzone zanim kliknąłeś instalację VMware. Serwer pod środowisko wielomaszynowe to nie jest „większy komputer”. To platforma, która ma unieść kilkanaście, czasem kilkadziesiąt systemów jednocześnie - z różnym profilem obciążenia, różnym apetytem na pamięć i I/O. Jeśli planujesz wdrożyć VMware, Proxmox albo Hyper-V w firmie - zacznij od mocy.

Ile łącznie vCPU naprawdę potrzebujesz, by skonfigurować serwer pod wirtualizację? Zanim klikniesz „dodaj drugi procesor”, policz to dobrze

Najpierw policz sumę vCPU wszystkich planowanych maszyn, a dopiero potem dobieraj fizyczne rdzenie - odwrotna kolejność kończy się przewymiarowaniem albo przeciążeniem hosta.

• Konserwatywny start dla produkcji: overcommit CPU 1:1 do 1:2 (vCPU : logiczny wątek).
• Fizyczny procesor serwerowy 16c/32t daje 32 logiczne wątki, które hypervisor rozdziela między VM.
• Za wysoki overcommit = rosnące CPU Ready i czekanie VM na dostęp do rdzenia.
• Nowe VM-ki zaczynają od 1-2 vCPU, zwiększasz dopiero po analizie obciążenia.

Brzmi prosto, ale tu najczęściej popełniany jest błąd. Widać to regularnie: firma planuje 15 VM-ek, każda „na zapas” dostaje 4 vCPU, bo „lepiej mieć więcej”. Nagle robi się 60 vCPU na hoście z 16 rdzeniami. Scheduler hypervisora zaczyna żonglować wątkami, pojawia się CPU Ready, aplikacje reagują wolniej, a w vCenter wszystko „niby” wygląda dobrze. Wirtualizacja nie lubi nadmiaru przydziałów.

Dobrą praktyką jest start small and scale up - czyli minimalny przydział, monitoring i dopiero potem korekta. W wielu środowiskach MŚP 1 mocny CPU z 12-16 rdzeniami o sensownym taktowaniu spokojnie wystarcza do kilkunastu lekkich VM-ek. Drugi procesor ma sens, gdy liczba maszyn rośnie dynamicznie albo pojawiają się obciążenia typu SQL, VDI czy systemy analityczne. Najpierw policz. Potem rozbudowuj.

Rdzenie vs taktowanie - dlaczego „więcej” nie zawsze oznacza „lepiej” w środowisku VMware?

W wirtualizacji liczy się równowaga między liczbą rdzeni a wydajnością pojedynczego rdzenia - sama gęstość rdzeni nie gwarantuje lepszej pracy VM-ek.

• Hyper-Threading / SMT powoduje, że 1 rdzeń = 2 logiczne wątki, ale to nie podwaja mocy.
• Zbyt wiele wolnych rdzeni o niskim taktowaniu zwiększa pracę schedulera.
• Jedna VM z 16-32 vCPU może działać wolniej niż ta sama z 4-8 vCPU.
• Topologia „Sockets × Cores” ma znaczenie przy NUMA i sposobie widzenia CPU przez system gościa.

To jest moment, w którym specyfikacja przestaje być oczywista. Procesor z ogromną liczbą rdzeni wygląda imponująco, ale jeśli większość Twoich VM-ek to serwery aplikacyjne, AD, pliki, monitoring - często ważniejsze jest stabilne, wyższe taktowanie pojedynczego rdzenia. Wirtualizacja rozkłada obciążenie. Jeśli jedna maszyna potrzebuje synchronizacji wielu wątków naraz, zbyt duży przydział vCPU może ją… spowolnić, bo scheduler czeka aż wszystkie logiczne wątki będą wolne jednocześnie.

Dlatego przy planowaniu mocy pod VMware nie chodzi o „maksymalną liczbę rdzeni”. Chodzi o dopasowanie rdzeni do realnego profilu obciążeń. Inaczej budżet idzie w CPU, a realnym ograniczeniem i tak okazuje się RAM albo storage. A to już zupełnie inna rozmowa.

Konfiguracja serwera do wirtaulizacji: 128, 256 czy 512 GB RAM? Zobacz, ile pamięci realnie „zjada” kilkanaście VM-ek

W praktyce to RAM, a nie CPU, najczęściej ogranicza liczbę maszyn wirtualnych na hoście.

• AD, DNS, drobne usługi - 4-8 GB RAM.
• File server, aplikacje biznesowe - 8-16 GB RAM.
• Mały SQL / ERP - 16-32 GB RAM (więcej przy większych bazach).
• Hypervisor potrzebuje zwykle 10-20% RAM dla siebie.
• Produkcyjne środowiska celują w 1,0-1,3× vRAM względem fizycznej pamięci.

Host z 128 GB RAM spokojnie uniesie kilkanaście lekkich VM-ek bez agresywnego overcommit. Przy 256 GB zaczyna się komfort - 20-40 maszyn o mieszanym profilu, z zachowaniem marginesu bezpieczeństwa. 512 GB i więcej to już środowiska gęste: VDI, kilka baz danych, systemy raportowe.

Overcommit pamięci jest technicznie wspierany, ale jeśli przesadzisz, pojawi się ballooning, kompresja i swapping. A swapping w środowisku produkcyjnym oznacza jedno - skoki latencji usług. Dlatego doświadczeni administratorzy zwykle trzymają się blisko fizycznej pamięci przy krytycznych systemach, a overcommit traktują jako bufor, nie fundament.

W skrócie: jeśli zastanawiasz się, czy 128 GB wystarczy, odpowiedz sobie na jedno pytanie - ile RAM zużyją Twoje VM-ki w godzinach szczytu, a nie w nocy. To ta wartość powinna determinować konfigurację hosta. CPU możesz jeszcze „rozciągnąć”. RAM-u nie.

NVMe pod datastore - kiedy storage staje się wąskim gardłem całego klastra?

Jeśli VM-ki zaczynają reagować wolniej mimo zapasu CPU i RAM, wąskim gardłem niemal zawsze okazuje się storage - a przy wielu maszynach wirtualnych zabija go losowe I/O.

• NVMe PCIe 4.0/5.0 - nawet 1 mln+ IOPS, latencje rzędu kilkunastu-kilkudziesięciu µs
• SSD SATA/SAS - zwykle 100-200 tys. IOPS, latencja liczona w setkach µs
• HDD 10K/15K - kilka ms latencji i dramat przy wielu jednoczesnych operacjach
• 4-8 dysków NVMe w RAID 10 jako lokalny datastore to dziś rozsądne minimum pod produkcję
• SDS (vSAN, Ceph) pozwala połączyć lokalne NVMe w wydajny i redundantny klaster

W środowisku wielomaszynowym każda VM generuje swoje małe, rozproszone operacje - logi, indeksy, pliki systemowe, snapshoty, backupy. To nie jest sekwencyjne kopiowanie dużych plików. To ciągły, losowy ruch. I właśnie dlatego talerzowe dyski, a nawet część starszych SSD, zaczynają się „dławić”.

W praktyce zestaw 4-8 NVMe w RAID 10 daje nie tylko ogromną przepustowość, ale też stabilność przy pikach - aktualizacjach systemów, snapshotach, backupach czy masowym starcie VM po restarcie hosta. Przy małych klastrach 2-3 węzłowych bardzo dobrze sprawdza się model lokalne NVMe + Software-Defined Storage (vSAN / Ceph) - dostajesz zarówno wydajność lokalnego dysku, jak i redundancję między hostami.

EPYC czy Xeon Gold? Gęstość VM-ek kontra single-core i kompatybilność - wybierz świadomie

Wybór platformy procesorowej decyduje o tym, ile VM-ek realnie zmieścisz na jednym hoście i jak będzie wyglądał koszt przeliczeniowy na rdzeń lub wątek.

• Dell PowerEdge R7615 (1× AMD EPYC) - do 128 rdzeni na socket, DDR5 4800 MT/s, PCIe 5.0
• Dell PowerEdge R7625 (2× AMD EPYC) - jeszcze większa gęstość, nawet kilka TB RAM, cel pod VDI i duże klastry
• Xeon Gold - mocne single-core performance, bardzo dojrzały ekosystem i kompatybilność
• EPYC - więcej kanałów pamięci i linii PCIe = większa przepustowość RAM i storage

Jeśli Twoim celem jest maksymalna liczba VM-ek na jednym hoście i dobre TCO per wątek, EPYC w modelach R7615 / R7625 daje dziś ogromną elastyczność. Wysoka liczba rdzeni, dużo kanałów pamięci i nowoczesne PCIe 5.0 sprawiają, że możesz gęsto upakować środowisko bez wąskich gardeł I/O.

Z drugiej strony Xeon Gold wciąż jest bardzo mocną opcją tam, gdzie liczy się wydajność pojedynczego rdzenia i szeroka kompatybilność z określonymi rozwiązaniami storage czy HCI. W części środowisk aplikacyjnych wyższe taktowanie single-core daje lepsze rezultaty niż sama liczba rdzeni.

To nie jest wybór „lepsze-gorsze”. To wybór: czy budujesz host pod maksymalną gęstość VM-ek, czy pod bardziej klasyczne, zrównoważone obciążenia. Dlatego właśnie temat CPU dobrze osadzić w konfiguratorze - zobaczyć różnicę w liczbie rdzeni, RAM i NVMe przy konkretnym budżecie.

Jeden host czy klaster 2-3 węzłowy? Jeśli myślisz o HA, zacznij od tej decyzji

Wirtualizacja bez wysokiej dostępności działa - do pierwszej poważnej awarii hosta.

• Klaster 2-węzłowy + witness - minimum sensownego HA
• Klaster 3-węzłowy - pełniejsza redundancja i komfort serwisowy
• Automatyczne przenoszenie VM (HA / failover) po utracie hosta
• vSAN / Ceph / Storage Spaces Direct - replikacja danych między węzłami
• Możliwość planowanych prac bez przestojów

Pojedynczy host jest tańszy i prostszy. Jeśli jednak na tych VM-kach działa księgowość, ERP, CRM czy system produkcyjny, jeden punkt awarii to realne ryzyko przestoju. Klaster 2-węzłowy z dodatkowym witness pozwala już zbudować podstawowe HA - przy awarii jednego hosta VM-ki startują na drugim.

Klaster 3-węzłowy daje więcej elastyczności. Możesz wyłączyć jeden węzeł do serwisu i nadal zachować redundancję. Przy lokalnych NVMe i SDS dostajesz wydajność oraz odporność na awarie bez konieczności budowania rozbudowanej infrastruktury SAN.

Jeśli więc planujesz wirtualizację „na poważnie”, pytanie nie brzmi czy HA jest potrzebne. Pytanie brzmi: jaki poziom przestoju możesz zaakceptować? Od tej odpowiedzi zaczyna się architektura.

Sprawdź swoją konfigurację w praktyce!

Zamiast zgadywać, ile rdzeni i ile NVMe potrzebujesz, przetestuj różne warianty w naszym konfiguratorze serwera.

Dobierz:

• platformę,
• liczbę rdzeni i wątków,
• 128-512 GB RAM i więcej,
• konfigurację NVMe pod datastore,
• wariant pojedynczego hosta lub klastra 2-3 węzłowego.

W kilka minut zobaczysz, jak zmienia się koszt i skalowalność przy różnych scenariuszach. Jeśli nie masz pewności - lepiej zweryfikować projekt przed wdrożeniem niż po pierwszym przeciążeniu hosta.

FAQ

Czy jeden host wystarczy dla małej firmy?

Tak, jeśli akceptujesz brak HA. Przy krytycznych systemach produkcyjnych rekomendowany jest co najmniej klaster 2-węzłowy.

Czy można mocno overcommitować CPU?

Technicznie tak, ale dla produkcji warto trzymać się 1:1-1:2 i zwiększać współczynnik dopiero po monitoringu.

Czy RAM czy CPU ogranicza host szybciej?

W większości środowisk MŚP to RAM jest pierwszym limitem, nie CPU.

Czy NVMe jest konieczne pod VMware?

Przy kilkunastu i więcej VM-kach - praktycznie tak. Losowe I/O szybko obnaża ograniczenia HDD i starszych SSD.

EPYC czy Xeon Gold - co wybrać?

Jeśli liczysz maksymalną gęstość VM-ek - EPYC. Jeśli ważniejsza jest kompatybilność i single-core - Xeon Gold. Decyzja zależy od profilu obciążeń.