Ile serwerów potrzebuje firma – jeden mocny czy kilka mniejszych?

Liczba serwerów zależy od trzech rzeczy: dopuszczalnego czasu przestoju, charakteru obciążenia i wymogów prawnych. W skrócie: jeden mocny serwer wystarczy firmie do ~25 użytkowników z przewidywalnym obciążeniem i akceptowalnym przestojem liczonym w godzinach; trzy węzły dają realną odporność na awarię; dwa to najgorszy wybór – niosą koszt klastra bez jego korzyści, o ile nie dołożysz trzeciego głosu. Poniżej pokazujemy progi liczbowe, ukryte koszty licencji i uczciwe wady każdej opcji.

Zanim przejdziemy dalej, jedno rozróżnienie, które porządkuje cały temat. Mieszają się tu trzy różne pytania: ile serwerów fizycznych, ile maszyn wirtualnych i ile węzłów klastra HA. To nie to samo – jeden serwer fizyczny obsłuży kilkanaście maszyn wirtualnych, ale nie zapewni wysokiej dostępności, do której trzeba minimum trzech węzłów.

Scale-up i scale-out – czym się różnią?

To rozróżnienie decyduje, czy w ogóle warto stawiać na jedną dużą maszynę. Scale-up (skalowanie w górę) to procesory połączone magistralami spójności pamięci podręcznej (SMP), pracujące pod jednym systemem operacyjnym – jedna duża maszyna widziana jako całość.

Scale-out (skalowanie wszerz) to wiele niezależnych serwerów, każdy z własnym systemem operacyjnym, bez łączy spójnościowych. Uwaga na częsty błąd: scale-up to nie to samo co dołożenie RAM – to konstrukcyjnie trudniejsza architektura wieloprocesorowa, nie zwykła rozbudowa. Dla części zadań (obciążenia typu scale-out) duża maszyna bywa wręcz przewymiarowana, bo marnuje hierarchię pamięci, której te obciążenia nie wykorzystują.

Warto też oddzielić dwa pojęcia mylone nagminnie: redundancja to zdolność do pracy po awarii komponentu, a backup to możliwość odtworzenia danych. Jedno nie zastępuje drugiego – RAID czy drugi węzeł nie cofną skasowanego pliku, a kopia zapasowa nie utrzyma firmy w ruchu w chwili awarii.

Kiedy wystarczy jeden serwer?

Jeden serwer to rozsądny wybór, gdy spełnione są trzy warunki naraz: firma liczy do ~25 użytkowników, obciążenie jest przewidywalne, a kilka godzin przestoju nie zatrzymuje biznesu. Licencyjnie odpowiada temu Windows Server Essentials – pokrywa do 10 rdzeni i jedną maszynę wirtualną, wyłącznie na serwerze jednoprocesorowym, dla firm do 25 użytkowników i 50 urządzeń.

Przemawia za tym również energetyka, i to mocno. Serwer bezczynny pobiera ponad 70% mocy szczytowej, bo tylko procesor ma skuteczne tryby oszczędzania – pamięć, dyski i sieć niemal nie schodzą z poboru. W nowszym ujęciu Google Cloud (2024) sama moc bezczynności odpowiada za około 60% średniego zużycia energii serwera.

Większość energii serwera pochłania sama gotowość do pracy, nie obliczenia. Dane: metodologia Google Cloud, 2024.

Z tego wynika najważniejszy wniosek energetyczny: trzy serwery obciążone po 20% zużywają wyraźnie więcej prądu niż jeden obciążony w 60%, wykonując tę samą pracę. Serwery pracujące na 10% mocy lub mniej i tak pobierają 30–60% maksimum. Dlatego rozdrabnianie na kilka słabo obciążonych maszyn to najczęstszy sposób na przepalanie budżetu energetycznego.

Kiedy potrzebujesz co najmniej dwóch – i dlaczego dwa to najgorsza liczba?

Gdy przestój kosztuje realne pieniądze, jeden serwer przestaje wystarczać – ale przeskok „na dwa” to pułapka. Klaster wysokiej dostępności działa na zasadzie kworum: potrzebuje większości głosów. Jeśli po awarii żadna część klastra nie ma większości, węzły, które przetrwały, wyłączają się, żeby chronić spójność danych.

Przy dwóch węzłach każdy ma jeden głos. Awaria jednego oznacza remis 1:1 – żadna strona nie ma większości, więc mechanizm ochronny potrafi zatrzymać całość. Dlatego:

• trzy węzły to minimum, by mechanizm diskless SBD samodzielnie obsłużył scenariusz split-brain,
• klaster dwuwęzłowy wymaga dodatkowego głosu (QDevice/QNetd) jako rozjemcy,
• minimalna konfiguracja klastra rozciągniętego vSAN to trzy hosty na lokalizację plus węzeł świadka (układ 3+3+1).

Do tego dochodzi rezerwa mocy, o której łatwo zapomnieć. VMware zaleca ustawienie vSphere HA Admission Control na 50% CPU i pamięci – czyli połowę kupionej mocy trzymasz jako zapas na przejęcie obciążenia po awarii. Prawdziwa odpowiedź na pytanie z tytułu brzmi więc: dwa to najgorsza liczba. Jeden jest tani i prosty, trzy dają realną odporność, a dwa łączą koszt klastra z jego zawodnością – chyba że dołożysz świadka.

Ile to naprawdę kosztuje – licencje, prąd, okno serwisowe

Najczęściej pomijany, a często decydujący składnik rachunku to licencje. Windows Server 2025 licencjonuje wszystkie rdzenie fizyczne, z minimum 8 licencji na procesor i minimum 16 licencji rdzeniowych na każdy serwer – także jednoprocesorowy. Konsekwencja dla strategii „kilka mniejszych” jest bolesna:

Trzy serwery po 8 rdzeni wymagają 48 licencji zamiast 16 – ta sama moc, potrójny koszt. Dane: Windows Server 2025 Licensing Guide.

Trzy serwery po 8 rdzeni to 48 licencji rdzeniowych (3 × 16 minimum), podczas gdy jeden serwer 16-rdzeniowy to 16 licencji – ta sama moc obliczeniowa, trzykrotny koszt licencji. Do tego edycja Standard daje prawo tylko do dwóch środowisk (OSE); każde kolejne dwa wymagają ponownego zalicencjonowania wszystkich rdzeni maszyny. Aktualne ceny i warunki licencyjne warto zweryfikować przed zakupem.

Drugi ukryty koszt to okno serwisowe. 72% organizacji przeznacza od 2 do 8 godzin miesięcznie na planowany przestój – patchowanie, testy, aktualizacje. Przy jednym serwerze te godziny to twardy przestój całej firmy. Przy klastrze to migracja maszyn na żywo, bez zatrzymania pracy. Trzeci koszt to prąd – opisany wyżej mechanizm mocy bezczynności sprawia, że rozdrobnienie podnosi rachunek za energię.

Wady konsolidacji, o których nie mówią producenci

Uczciwość wymaga pokazania drugiej strony. Konsolidacja na jednej maszynie ma realne wady:

• jeden serwer to jeden punkt awarii i jedno okno serwisowe dla całej firmy,
• wyższe obciążenie skonsolidowanej maszyny koreluje z wyższą awaryjnością, zwłaszcza dysków i pamięci (badanie czteroletnie, DSN 2017),
• maksymalny pobór mocy pojedynczego serwera rośnie z każdą generacją – gęsta maszyna może przekroczyć możliwości istniejącego zasilania i chłodzenia w serwerowni (analiza 16 lat SPEC Power, 2024).

Awaria komponentu nie jest przy tym wyjątkiem, lecz zdarzeniem oczekiwanym. W skali roku około 9,62% serwerów doświadcza korygowalnych błędów pamięci (Facebook / CMU, 2015), a rzeczywisty wskaźnik awaryjności dysków SSD bywa nawet o 70% wyższy niż deklarowany w specyfikacji (Microsoft Research, 2016). To argument nie przeciw konsolidacji, lecz za redundancją – niezależnie od tego, na ilu maszynach ją budujesz.

Klasa sprzętu waży więcej niż liczba maszyn

Zanim rozdrobnisz infrastrukturę „dla bezpieczeństwa”, spójrz na twarde dane o awaryjności. Redundancja z kilku tanich maszyn nie pomoże, jeśli każdy węzeł jest zawodny. Różnice między klasami sprzętu są dramatyczne:

Roczny nieplanowany przestój na serwer wg klasy sprzętu, skala logarytmiczna. Dane: ITIC 2024.

Serwery bezmarkowe (white box) notują 60 minut przestoju rocznie, a 42% z nich przekracza 4 godziny. Dla platform enterprise jak Dell PowerEdge to 20 minut i 8% maszyn powyżej 4 godzin, a dla klasy mission-critical – od 0% do 1,5%. Dochodzi cykl życia: 78% serwerów starszych niż 4 lata z podniesionym obciążeniem traci niezawodność, a odświeżanie sprzętu co trzy lata ograniczyło przestój u 95% organizacji. Dobór liczby serwerów to więc także decyzja o cyklu wymiany, nie jednorazowy zakup. Jak dobrać klasę i model, rozkładamy w przewodniku „Jaki serwer wybrać?”, a wybór między nowym a odnowionym – w tekście nowy serwer czy recertyfikowany.

Jak sprawdzić, ile mocy naprawdę zużywasz?

Zanim dokupisz sprzęt, zmierz wykorzystanie tego, co masz. Progi audytowe są proste.

• Poniżej 50% wykorzystania CPU. Niedowykorzystanie – masz zapas albo za dużo maszyn.
• 51–85% wykorzystania. Zakres prawidłowy – sprzęt pracuje efektywnie.
• 86% i więcej. Przeciążenie – czas na rozbudowę lub kolejny węzeł.

Punktem odniesienia jest fakt, że średnie wykorzystanie CPU w badaniach bywa niskie – rzędu 36% (pomiar z 2010 r., mechanizm aktualny), a 80% maszyn wirtualnych w jednej analizie nie przekraczało 60% przydzielonych zasobów. Zanim kupisz kolejny serwer, sprawdź, czy obecny nie stoi bezczynnie. Konsolidacja działa właśnie dlatego, że obciążenia szczytują w różnych momentach – ponad połowa serwerów w obciążeniu bankowym ma charakter „grubego ogona”, więc jedna maszyna absorbuje szczyty, które nigdy nie występują jednocześnie.

Co mówią przepisy – NIS2 i redundancja

Dla części firm redundancja przestała być wyborem ekonomicznym. Rozporządzenie wykonawcze (UE) 2024/2690 do dyrektywy NIS2 wymaga od podmiotów objętych regulacją utrzymywania planu ciągłości działania i odtwarzania po awarii, kopii zapasowych oraz zapewnienia odpowiedniego poziomu redundancji zasobów – obiektów, systemów i personelu. Jeśli firma podlega NIS2, pojedynczy serwer bez planu ciągłości może być niezgodny z prawem, niezależnie od rachunku ekonomicznego.

Warto dodać, że wirtualizację i konsolidację jako najlepszą praktykę wskazują też unijne wytyczne EU Code of Conduct on Data Centre Energy Efficiency (JRC, 2025). Zakres podmiotowy NIS2 warto potwierdzić – nie każda firma jest objęta regulacją, ale dla objętych redundancja to obowiązek. Szerzej piszemy o tym w tekście o cyberbezpieczeństwie w myśl NIS2. Kontekst rynkowy dopełnia jedno: mimo popularności chmury (w 2025 r. usługi chmurowe kupiło 55,3% firm w Polsce) tylko około 28% firm w UE kupuje moc obliczeniową do uruchamiania własnego oprogramowania – pytanie o własne serwery pozostaje otwarte.

Od czego zacząć?

Zacznij od trzech pytań, nie od liczby maszyn: ile przestoju wytrzyma firma, jak zmienne jest obciążenie i czy podlegasz NIS2. Z odpowiedzi wynika reszta – jeden serwer dla małej firmy z akceptowalnym przestojem, trzy węzły tam, gdzie liczy się ciągłość, i świadomość, że dwa węzły bez świadka to najgorszy kompromis. Napisz nam, ilu masz użytkowników, co ma działać na serwerze i jaki przestój jest dopuszczalny, a dobierzemy konfigurację – od pojedynczej maszyny po klaster HA – przetestowaną, gotową do wdrożenia i objętą gwarancją. Pełną ofertę znajdziesz w kategorii serwerów – w formatach Tower, Rack i Blade.

FAQ

Ile serwerów potrzebuje firma zatrudniająca 50 osób?

Zwykle jeden wydajny serwer z wirtualizacją obsłuży 50 osób, o ile obciążenie jest przewidywalne, a przestój liczony w godzinach jest akceptowalny. Jeśli działają na nim systemy krytyczne (ERP, SQL), warto rozważyć klaster trzywęzłowy dla wysokiej dostępności.

Czy jeden serwer wystarczy dla małej firmy?

Tak, do około 25 użytkowników z przewidywalnym obciążeniem. Windows Server Essentials pokrywa firmy do 25 użytkowników i 50 urządzeń na serwerze jednoprocesorowym. Ograniczeniem jest to, że jeden serwer to pojedynczy punkt awarii.

Dlaczego klaster dwuwęzłowy wymaga trzeciego głosu?

Klaster działa na zasadzie większości głosów (kworum). Przy dwóch węzłach awaria jednego daje remis 1:1 – żadna strona nie ma większości, więc mechanizm ochronny może zatrzymać całość. Trzeci głos (węzeł lub świadek QDevice) rozstrzyga, który węzeł ma kontynuować.

Ile maszyn wirtualnych zmieści się na jednym serwerze fizycznym?

To zależy od zasobów i obciążenia VM, nie od sztywnego limitu. Konsolidacja działa, bo obciążenia szczytują w różnych momentach. Kluczowe jest trzymanie zapasu – jeśli planujesz HA, VMware zaleca rezerwę 50% CPU i pamięci na przejęcie obciążenia po awarii.

Czy kilka mniejszych serwerów jest tańsze od jednego dużego?

Zwykle nie. Trzy serwery po 8 rdzeni wymagają 48 licencji rdzeniowych Windows Server zamiast 16 dla jednej maszyny 16-rdzeniowej. Do tego dochodzi wyższe zużycie energii, bo każdy bezczynny serwer i tak pobiera ponad 70% mocy szczytowej.

Co się stanie, gdy padnie jedyny serwer w firmie?

Zatrzymują się wszystkie usługi na nim działające – poczta, pliki, ERP, bazy. Backup pozwoli odtworzyć dane, ale nie utrzyma firmy w ruchu w czasie awarii. Ciągłość pracy zapewnia dopiero redundancja, czyli co najmniej trzy węzły w klastrze HA.

Czy NIS2 wymaga posiadania więcej niż jednego serwera?

NIS2 nie narzuca liczby serwerów wprost, ale wymaga od objętych podmiotów planu ciągłości działania i odpowiedniego poziomu redundancji. W praktyce dla wielu firm oznacza to konieczność zapewnienia odporności, której pojedynczy serwer nie daje. Zakres podmiotowy warto potwierdzić.

Bibliografia

• ITIC – 2024 Global Server Hardware, Server OS Reliability Report – https://www.lenovo.com/content/dam/lenovo/dcg/global/en/products/servers/itic-2024-global-server-hardware-server-os-reliability-report.pdf
• Beloglazov, Buyya i in. – A Taxonomy and Survey of Energy-Efficient Data Centers and Cloud Computing Systems (2010) – https://arxiv.org/pdf/1007.0066
• A Framework for Auditing Data Center Energy Usage and Mitigating Environmental Footprint (2021) – https://arxiv.org/pdf/2102.04446
• Carbon accounting in the Cloud: a methodology for allocating emissions across data center users (Google Cloud, 2024) – https://arxiv.org/pdf/2406.09645
• Uptime Institute – Global Data Center Survey 2024 – https://datacenter.uptimeinstitute.com/rs/711-RIA-145/images/2024.GlobalDataCenterSurvey.Report.pdf
• Natural Resources Defense Council – Data Center Efficiency Assessment (IP:14-08-a, 2014) – https://www.nrdc.org/sites/default/files/data-center-efficiency-assessment-IP.pdf
• Revisiting Memory Errors in Large-Scale Production Data Centers (Facebook / CMU, DSN 2015) – https://users.ece.cmu.edu/~omutlu/pub/memory-errors-at-facebook_dsn15.pdf
• SSD Failures in Datacenters: What? When? and Why? (Microsoft Research, 2016) – https://www.microsoft.com/en-us/research/wp-content/uploads/2016/08/a7-narayanan.pdf
• What Can We Learn from Four Years of Data Center Hardware Failures? (DSN 2017) – https://people.iiis.tsinghua.edu.cn/~weixu/Krvdro9c/dsn17-wang.pdf
• SUSE Linux Enterprise High Availability 16.0 – Installing a Basic Three-Node HA Cluster (2026) – https://documentation.suse.com/sle-ha/16.0/pdf/HA-installing-three-node-cluster_en.pdf
• VMware vSAN Stretched Cluster Guide (2024) – https://www.vmware.com/docs/vsan-stretched-cluster-guide
• High-Availability Clusters: A Taxonomy, Survey, and Future Directions (2021) – https://arxiv.org/pdf/2109.15139
• Windows Server 2025 Licensing Guide (Microsoft, 2025) – https://www.licensingschool.co.uk/wp-content/uploads/2025/02/Licensing_guide_PLT_Windows_Server_2025-February-2025.pdf
• TCO benefits of server virtualization for the SMB (Principled Technologies dla Dell, 2012) – https://i.dell.com/sites/csdocuments/Business_smb_sb360_Documents/en/us/wp-virtualization-tco.pdf
• Clearing the Clouds: A Study of Emerging Scale-out Workloads on Modern Hardware (ASPLOS 2012) – https://www.comp.nus.edu.sg/~hebs/course/cs6284/papers/Ferdman-ASPLOS12.pdf
• Virtual Machine Consolidation in the Wild (IBM Research India, Middleware 2014) – https://dl.acm.org/doi/pdf/10.1145/2663165.2663316
• 16 Years of SPEC Power: An Analysis of x86 Energy Efficiency Trends (2024) – https://arxiv.org/pdf/2411.07062
• GUS – Społeczeństwo informacyjne w Polsce w 2025 r. – https://stat.gov.pl/files/gfx/portalinformacyjny/pl/defaultaktualnosci/5497/2/15/1/spoleczenstwo_informacyjne_w_polsce_w_2025_r..pdf
• Eurostat – Cloud computing: statistics on the use by enterprises (2026) – https://ec.europa.eu/eurostat/statistics-explained/SEPDF/cache/37043.pdf
• ENISA – Technical Implementation Guidance on Cybersecurity Risk Management Measures, v1.0 (2025) – https://www.enisa.europa.eu/sites/default/files/2025-06/ENISA_Technical_implementation_guidance_on_cybersecurity_risk_management_measures_version_1.0.pdf
• Joint Research Centre (KE) – 2025 Best Practice Guidelines for the EU Code of Conduct on Data Centre Energy Efficiency – https://publications.jrc.ec.europa.eu/repository/handle/JRC141521
• Lawrence Berkeley National Laboratory – United States Data Center Energy Usage Report (aktualizacja 2025) – https://eta-publications.lbl.gov/sites/default/files/2024-12/lbnl-2024-united-states-data-center-energy-usage-report.pdf
• Congressional Research Service – Data Centers and Their Energy Consumption: FAQ (R48646, 2025) – https://www.congress.gov/crs_external_products/R/PDF/R48646/R48646.1.pdf