Serwer w małej lub średniej firmie kupuje się raz na 5-7 lat - przez cały ten okres będzie pracował dla księgowości, magazynu, produkcji albo recepcji. W obsłudze IT klientów MŚP regularnie spotykamy ten sam mechanizm zakupowy: właściciel dostaje jedną ofertę od dostawcy, w tabelce widzi "1U rack, 32 GB RAM, 2x SSD", uznaje że "wygląda OK" i podpisuje. Po dwóch latach okazuje się, że dyski wstawione do macierzy to konsumenckie SSD bez PLP, że jest tylko jeden zasilacz, że "zdalne zarządzanie" sprowadza się do TeamViewera na zalogowanej maszynie, a wystawienie sześćdziesiątej faktury dziennie w enovie zaczyna zajmować kilka sekund zamiast ułamka. Tym razem coś trzeba z tym zrobić - i wtedy przychodzi telefon do nas albo do innego dostawcy outsourcingu IT.

Ten artykuł jest o tym, jak nie wpaść w ten schemat. Idziemy po kolei przez parametry, które realnie decydują o tym, czy serwer dowiezie zadania na pięć lat do przodu: liczbę socketów i częstotliwość CPU, rodzaj i pojemność RAM, dyski (SSD, HDD, SATA, SAS, NVMe), kontroler RAID, redundancję zasilaczy, kartę sieciową, zdalne zarządzanie iLO/iDRAC i gwarancję producenta. Na końcu pokazujemy, dla jakich firm sensownym wyborem jest HPE MicroServer, a kiedy lepiej sięgnąć po HPE ProLiant DL20 - dwa modele, które kupujemy klientom najczęściej, gdy oddział lub mała firma nie potrzebuje pełnego rackowego serwera klasy DL360.

Skupiamy się na hardware. Pisaliśmy już o tym, jak ułożyć infrastrukturę pod enova365 - SQL Server, RDS i backupy oraz co trzeba wiedzieć o utrzymaniu Comarch Optimy - tamte teksty pokazują, jak warstwa systemowa i bazodanowa wpływa na wybór maszyny. Tu schodzimy poziom niżej, do metalu.

Jakie są realne zastosowania serwera w MŚP

Zanim wybierzesz CPU i dyski, ustal, co maszyna ma robić. To brzmi banalnie, ale 80% błędów w doborze serwerów dla MŚP bierze się z pominięcia tego kroku. Pełna inwentaryzacja obciążeń bywa dobrym punktem startu rozmowy o wsparciu IT.

W praktyce MŚP rozkłada się dla nas na trzy profile, które różnią się obciążeniem serwera:

• Mikrofirma i małe biuro (5-15 osób) - najczęściej oddział, biuro rachunkowe albo kancelaria. Serwer plików, AD, lokalny backup, czasem program księgowy z lokalną bazą.

• Mała firma (15-50 osób) - tu dochodzi ERP z SQL Serverem, RDS dla części załogi, integracje, pierwsze poważne wymagania backupowe (RPO/RTO liczone w godzinach, nie w dniach).

• Średnia firma (50-150 osób) - kilka VM-ek, ERP z bazą rosnącą szybciej, niż byśmy chcieli, WMS, czasem MES, RDS dla 20+ osób, osobny host backupu.

Te zakresy są punktem orientacyjnym, nie sztywnym podziałem. W rzeczywistości znamy 12-osobowe biura projektowe z pakietami CAD, które potrzebują infrastruktury bliższej średniej firmie, i 80-osobowe firmy handlowe, którym wystarczy konfiguracja na poziomie małej firmy, bo realne obciążenie serwera robi sześciu pracowników z księgowości. Liczba osób w firmie to przybliżenie - prawdziwą informacją jest profil obciążenia.

Poniżej mapa typowych usług. W kolejnych sekcjach pokazujemy, jak każda z nich wpływa na dobór parametrów.

Serwer plików. Podstawa większości firm. Dziesiątki gigabajtów dokumentów księgowych, projektów CAD, archiwum kontraktów, skany. Wymaga miejsca i przyzwoitej przepustowości sieciowej, ale rzadko wąskim gardłem jest CPU.

Active Directory, RADIUS, kontroler Wi-Fi. Usługi infrastrukturalne - logowanie do domeny, uwierzytelnianie 802.1X, zarządzanie punktami dostępowymi Aruba czy Ubiquiti. Pojedynczo zużywają ułamek zasobów, ale są krytyczne - jeżeli kontroler domeny przestanie działać, użytkownicy nie zalogują się do swoich stacji. Zwykle te usługi działają jako maszyny wirtualne na tym samym hoście, co inne komponenty.

ERP - enova365, Comarch Optima, Symfonia, Subiekt. Tu kończy się "lekka" infrastruktura, a zaczyna realne obciążenie - Microsoft SQL Server pod bazą produkcyjną, klient terminalowy (RDS) dla pracowników zdalnych, baza, która rośnie po 1-2 GB miesięcznie. Pisaliśmy o tym szerzej w artykule o enova365 - tam jest cała mechanika RDS-a i SQL Express vs Standard.

SQL pod Płatnika. Płatnik to typowo narzędzie działu księgowości albo biura rachunkowego, które korzysta z lokalnego SQL Express jako uzupełnienie programu kadrowo-płacowego. W mikrofirmie stoi obok księgowej, na jej stacji albo na małym serwerze plików. W większej organizacji bywa instalowany na wydzielonej instancji SQL i wtedy dzieli zasoby z innymi bazami.

Programy magazynowe i WMS. Subiekt z WMS, osobny WMS na bazie SQL, integracje z ERP, czytniki kodów. Tu pojawia się wymóg niskich opóźnień - skanowanie palety nie może czekać 4 sekundy, bo magazynier rzuci czytnikiem.

Aplikacje wspierające produkcję. MES, harmonogramowanie, ewidencja czasu pracy maszyn, integracje z PLC. Często z bazą SQL, czasem z usługami nasłuchującymi 24/7. Awaria takiego serwera oznacza zatrzymanie linii.

Backup, monitoring, antywirus. Veeam, Acronis, ESET, Wazuh - usługi, które wszyscy traktują jako "drugorzędne", dopóki nie trzeba odtwarzać bazy o 23:00 w piątek.

Ten zestaw jest typowy dla firmy 30-150 osobowej. W mikrofirmie odpada produkcja i WMS, w większej dochodzi BI, hurtownia danych, osobne środowiska deweloperskie. Twoja lista decyduje o tym, jakiego serwera potrzebujesz - i czy w ogóle wystarczy ci jeden.

CPU - 1 czy 2 sockety, częstotliwość, wlutowany procesor

Większość MŚP, z którymi pracujemy, nie potrzebuje serwera dwusocketowego. Jedna nowoczesna jednostka Intel Xeon Scalable 4. lub 5. generacji albo Xeon E-2400 wyciąga zadania, na które 10 lat temu trzeba było dwóch procesorów. Drugi socket dokłada koszt platformy, koszt licencji (Windows Server, SQL Server liczone na rdzeń) i pobór mocy, zwykle bez proporcjonalnej korzyści wydajnościowej dla obciążeń typowych w MŚP.

Kiedy ma sens konfiguracja dwusocketowa: wirtualizacja gęsta (kilkanaście-kilkadziesiąt VM), bazy SQL z bardzo dużą liczbą równoległych zapytań, środowiska terminalowe dla 50+ pracowników. Jeżeli twoja firma nie spełnia tych warunków - wybierz jeden socket.

Częstotliwość bazowa kontra liczba rdzeni

Wyobraź sobie dwie oferty: po lewej Xeon Silver 4416+ z 20 rdzeniami i bazą 2,0 GHz, po prawej Xeon E-2486 z 6 rdzeniami i bazą 3,5 GHz. Cena podobna, "Silver" brzmi lepiej, w specyfikacji więcej rdzeni. W większości MŚP to wybór pułapkowy - dla obciążeń, które tam się realnie kręcą, druga oferta zrobi więcej, mimo że ma trzykrotnie mniej rdzeni.

Systemy takie jak Comarch Optima, enova365, Symfonia czy Płatnik "żyją" z wysokiego taktowania pojedynczego rdzenia, nie z ich liczby. Pojedyncze zapytanie SQL nie zostanie podzielone na 16 rdzeni. Wykona się w całości na jednym - i prędkość zwrotu wyniku zależy od tego, jak szybko ten jeden rdzeń go policzy. Kupując 6-rdzeniowy procesor z zegarem 3,5 GHz dostajesz szybszą odpowiedź dla użytkownika księgowości otwierającego raport, a nie po prostu "więcej rdzeni do wirtualizacji, której u ciebie nie ma".

Druga sprawa, której sprzedawca już nie pokaże w tabelce: licencje. Microsoft SQL Server Standard w modelu Per Core rozliczany jest na rdzeń, minimum 4 rdzenie, kupujesz w blokach 2-rdzeniowych. Te 16 rdzeni z Xeona Silver to 16 licencji, niezależnie od tego, że SQL realnie używa dwóch. Procesor 6-rdzeniowy z wysokim clockiem - 6 licencji, ten sam wynik dla użytkownika, koszt licencji wyraźnie niższy.

Zastrzeżenie z praktyki: licencjonowanie SQL Server bywa bardziej skomplikowane niż "ile rdzeni masz w CPU". Można licencjonować w modelu Server + CAL (sensowny dla małych firm z ograniczoną liczbą użytkowników), w środowisku zwirtualizowanym dochodzą reguły dla VM-ów i Software Assurance, dla wirtualizacji licencjonowanej "na hosta" liczą się też rdzenie nieaktywne. Przed zakupem lepiej zestawić dobór CPU z konkretnym modelem licencjonowania, najlepiej z partnerem Microsoftu - bo zdarzają się przypadki, w których dla mikrofirmy z 10 użytkownikami SQL Server Standard w modelu Server+CAL wychodzi taniej niż wszystko inne, a różnica między dwoma a sześcioma rdzeniami w CPU jest drugorzędna.

Wniosek: dla typowego serwera ERP/plikowego/AD w MŚP wybieraj wysoką częstotliwość bazową kosztem liczby rdzeni. 6-8 rdzeni z bazą 3,2-3,7 GHz robi w realnej pracy więcej niż 16 rdzeni z bazą 2,1 GHz - i kosztuje cię mniej w licencjach.

Wyjątek, który czasem widzimy: gęsty serwer terminalowy dla 30-50 użytkowników. Tu liczba rdzeni zaczyna mieć znaczenie, bo każdy aktywny użytkownik to osobne procesy, scheduler systemu lubi mieć rdzenie do rozprowadzenia. Granica nie jest ostra - dla 10 użytkowników RDS dalej wolimy clock, dla 40 zaczynamy ważyć kompromis. To jest moment, w którym lepiej zmierzyć rzeczywiste obciążenie z istniejącego środowiska, zamiast pozostawiać dobór ogólnym zasadom.

Procesor wlutowany w płytę

Niektóre platformy oszczędnościowe (mini-towery, NAS-y konfigurowane jako serwery) mają CPU wlutowany w płytę. Wygląda atrakcyjnie cenowo, ale niesie konsekwencje:

• Brak ścieżki upgrade'u. Po dwóch latach, gdy potrzebujesz mocniejszego CPU, kupujesz nową maszynę.

• Awaria CPU = wymiana całej płyty, czyli w praktyce wymiana serwera.

• Często ograniczone wsparcie ECC RAM albo gorsza obsługa pamięci.

W serwerach klasy enterprise (HPE ProLiant, Dell PowerEdge, Lenovo ThinkSystem) CPU jest w gnieździe LGA - wymienne. To nie jest funkcja "premium", to standard - i nie zgadzaj się na rezygnację z niego. Wlutowany procesor akceptujemy w jednym przypadku - małe maszyny do oddziałów, gdzie ścieżka upgrade'u i tak nie ma sensu (HPE MicroServer - tam CPU jest w gnieździe, ale niektóre konkurencyjne mikroserwery mają już wlutowany).

Pamięć RAM - ECC, pojemność, kanały

RAM serwerowy ma być pamięcią ECC (Error-Correcting Code). To podstawa. Pamięć ECC wykrywa i koryguje pojedyncze błędy bitowe - w serwerze, który chodzi 24/7, to nie jest "miły dodatek", tylko warunek bezawaryjnej pracy bazy SQL i hyperwizora.

Każdy szanujący się serwer (HPE ProLiant DL20, DL360, MicroServer; Dell PowerEdge R250, R350, R450; Lenovo ThinkSystem ST50/ST250) wymaga modułów ECC UDIMM albo RDIMM. Nigdy nie godź się na "uda się uruchomić Windows Server na pamięci desktopowej" - uda się, ale nie wlicza się to w gwarancję, a pierwszy nieskorygowany błąd bitowy w bazie SQL może kosztować twojego informatyka tydzień analizy, dlaczego dane w jednej tabeli nie zgadzają się z resztą.

Ile RAM-u

Reguły orientacyjne dla typowego serwera w MŚP:

• Mikrofirma 5-15 osób, file server + AD + Płatnik: 32 GB RAM jest absolutnym minimum. 64 GB daje rezerwę na drugą maszynę wirtualną i Veeama.

• Firma 20-60 osób, ERP (enova365, Optima, Symfonia) z bazą SQL, RDS dla 5-10 osób, file server, AD: 64-128 GB. SQL Server bez ograniczenia w Standardzie weźmie tyle, ile mu dasz, więc planuj z zapasem.

• Firma 60-150 osób, kilka VM, ERP + WMS + RDS dla 20+ osób, osobny serwer backupu i monitoringu: 128-256 GB, często z dwoma serwerami w klastrze (Hyper-V, VMware).

Z naszej praktyki przy wdrożeniach: SQL Server domyślnie zajmie tyle RAM-u, ile mu się pozwoli. Cache bufora, plan cache, tempdb - wszystko siedzi w pamięci, bo dostęp do pamięci jest tysiące razy szybszy niż do dysku. Jeśli dasz bazie za mało albo nie ustawisz parametru max server memory, SQL potrafi zająć cały RAM hosta, wypchnąć system operacyjny do swap i wywołać efekt odwrotny od zamierzonego.

W praktycznej konfiguracji: ustawiamy max server memory na poziomie ok. 80% pamięci hosta dla maszyny przeznaczonej tylko pod SQL Server, mniej w środowisku współdzielonym z innymi rolami (file server, Veeam, drugi RDS). Jeśli RAM-u jest za mało nawet po prawidłowej konfiguracji, SQL zaczyna nieustannie odwoływać się do dysków. Wtedy nawet najszybsze NVMe nie uratują wydajności aplikacji, bo zamiast losowych odczytów rzędu mikrosekund masz cykliczne strumienie z dysku rzędu milisekund. Użytkownicy raportują, że "system zwolnił", administrator widzi 100% kolejki I/O, a tymczasem rzeczywistym problemem jest brak pamięci dla bazy.

Kiedy w modelu obsługi informatycznej dostajemy zgłoszenie "serwer mocno przyciął", w pierwszej kolejności sprawdzamy dwie rzeczy: czy macierz nie jest w trybie zdegradowanym i ile RAM-u zostało dla bazy. W praktyce drugi punkt wyjaśnia większość przypadków - albo serwer ma za mało pamięci, albo SQL ma źle skonfigurowane max server memory (za niskie i nie wykorzystuje dostępnej pamięci, albo nieustawione i bierze wszystko, dusząc system). Dyski, sieć, antywirus to dalsi podejrzani, ale rzadziej okazują się winowajcami w tym typie scenariusza.

Kanały i rozkład modułów

Współczesne CPU serwerowe mają 4, 6 lub 8 kanałów pamięci. Wydajność RAM-u zależy od tego, czy używasz wszystkich kanałów. Dwa moduły 32 GB w 8-kanałowym CPU oznaczają, że pracujesz na 2 kanałach z 8 - przepustowość pamięci spada do 25% nominalnej.

Dlatego planując konfigurację: kupuj moduły w komplecie po liczbie kanałów CPU, jeżeli budżet pozwala. 8x 16 GB jest szybsze niż 2x 64 GB, mimo że daje tę samą pojemność. Dla MŚP w praktyce kompromis: kupujemy 4 moduły, jeśli płyta ma 4 banki (DL20, MicroServer), 8 modułów, jeśli płyta ma 8 banków (DL360, R450).

Dyski - SSD, HDD, SAS, SATA, NVMe

Dyski w serwerze MŚP odpowiadają za dwa parametry, które użytkownicy odczuwają najmocniej: szybkość otwierania okien w aplikacji i czas backupu nocnego. Rzadko ktoś pyta o dyski przed zakupem - zwykle pojawiają się w specyfikacji jako "2x SSD 480 GB" i tyle. A zakres możliwych konfiguracji jest dużo szerszy.

Rodzaje interfejsów

SATA - tani, powszechny, do 6 Gb/s. SATA SSD i SATA HDD trafiają do większości serwerów MŚP. Dobre dla file servera, archiwum, backupów. Słabe dla baz SQL z dużą liczbą równoległych zapisów - SATA ma jedną kolejkę poleceń (NCQ do 32), co dla serwera bazodanowego bywa wąskim gardłem.

SAS - 12 Gb/s w nowych modelach, w wybranych dyskach z opcją Dual Port (dwie ścieżki dostępu dla redundancji), lepsza obsługa wielu równoległych operacji niż SATA. Dyski SAS Enterprise są budowane do 24/7, mają wyższe MTBF, lepszą obsługę błędów. Dla baz SQL i wirtualizacji w MŚP - dobry standard.

NVMe - dyski podłączone bezpośrednio przez PCIe, omijające kontroler SAS. Realne 3-7 GB/s odczytu sekwencyjnego, kilkaset tysięcy IOPS. Dla bazy SQL pod ERP dla 50 osób w trybie standardowych operacji - przesada. Dla bazy WMS z kilkudziesięcioma stanowiskami skanującymi równolegle, dla tempdb pod ciężkimi raportami albo dla logu transakcyjnego SQL przy intensywnych zapisach - już realny zysk. U jednego z naszych klientów produkcyjnych, gdzie weekend zamykał się raportami magazynowymi liczonymi godzinami, dołożenie pary NVMe pod tempdb skróciło ten czas mniej więcej o połowę. To nie była różnica między "działa" a "nie działa", tylko między "raporty kończą się o 3 nad ranem" a "raporty kończą się przed północą". W innym wdrożeniu, gdzie obciążenie SQL było typowo czytające z małym wolumenem zapisu, dołożenie NVMe nie dało praktycznej zauważalnej różnicy. Trzeba mierzyć, nie zgadywać. NVMe Enterprise (z PLP) jest tym, czego chcesz w serwerze. Konsumenckie NVMe (Samsung 980, WD Black) - nie.

SSD vs HDD - klasyczny wybór. SSD dla wszystkiego, gdzie liczy się czas dostępu (system, bazy, RDS, file server, w którym ludzie pracują na dużych projektach CAD). HDD dla archiwum, długoterminowego backupu, repozytoriów video. W typowym MŚP wszystkie dyski produkcyjne to dziś SSD - HDD trafia tylko do dużych woluminów backupowych.

Konfiguracje, które polecamy

• File server / AD / mała firma (HPE MicroServer z 4 zatokami LFF, HPE DL20 Gen11 w wariancie 4-6 SFF, Dell R260 lub Lenovo SR250 V3): 2x SSD SATA Enterprise w RAID 1 na system + 2-4x SSD SATA lub SAS w RAID 10 na dane. Pojemnościowo 480 GB - 4 TB.

• Serwer ERP w małej i średniej firmie (HPE DL360 Gen11 do 8 SFF, Dell PowerEdge R450/R650 do 8 SFF): 2x SSD SAS w RAID 1 na system + 6x SSD SAS w RAID 10 na bazy + ewentualnie 2x NVMe na tempdb SQL Server, jeśli baza jest aktywnie obciążona.

• Serwer plików / archiwum dla średniej firmy (HPE DL380 Gen11 do 12 LFF, Dell R750 do 12 LFF): 2x SSD na system w RAID 1 + RAID 6 z 8-10 HDD SAS Enterprise, ewentualnie cache SSD na kontrolerze RAID.

Dyski Enterprise vs Desktop

Wkładanie dysków Samsung 870 Evo czy WD Blue do serwera produkcyjnego to proszenie się o kłopoty. Te dyski są świetne do laptopa i stacji roboczej. W serwerze nie mają racji bytu z trzech konkretnych powodów.

Po pierwsze, brak PLP (Power Loss Protection - kondensatorów na samym dysku, które dokończą rozpoczęty zapis przy nagłej utracie zasilania). Pierwszy lepszy zanik napięcia w trakcie zapisu i twoja baza danych może po prostu wyparować w częściowo zapisanym stanie. Dyski enterprise mają PLP wbudowane.

Po drugie, niskie DWPD (Drive Writes Per Day - ile razy dziennie można zapisać całą pojemność dysku przez 5 lat gwarancji). Konsumenckie SSD mają zwykle 0,3 DWPD. Dyski enterprise read-intensive - 1 DWPD, mixed-use - 3 DWPD, write-intensive - 10+ DWPD. Baza ERP w średniej firmie potrafi w tygodniu wymazać roczny budżet zapisów dysku konsumenckiego.

Po trzecie, gwarancja producenta nie obejmuje pracy ciągłej 24/7. Po awarii dysku, którego nie powinno być w serwerze, nie tylko nie dostaniesz wymiany na gwarancji - sam też masz problem, bo to przeczy ogólnym warunkom serwisowania platformy.

Dyski enterprise od producentów serwera (HPE, Dell, Lenovo - tzw. dyski branded, certyfikowane do danej platformy) albo z linii enterprise innych dostawców (Kingston DC, Micron 5400 PRO/MAX, Samsung PM983/PM1733) kosztują 2-3x więcej. Oszczędność 500-1000 zł na dysku enterprise to najdroższa droga na skróty, jaką można sobie zafundować w serwerowni.

Kontroler RAID i poziomy

Kontroler RAID dzieli serwery na dwie klasy. Pierwsza ma kontroler programowy zintegrowany z chipsetem płyty (np. Intel VROC, popularne rozwiązanie w mikroserwerach) - tańszy, ale obciąża CPU i nie ma write-back cache. Dla serwera plików w mikrofirmie wystarczy. Dla bazy SQL - problem.

Druga klasa to kontroler sprzętowy z dedykowaną pamięcią cache 2-8 GB i akumulatorem albo kondensatorem podtrzymującym cache na wypadek utraty zasilania (BBU lub Flash Cache Module - typowe modele to HPE Smart Array P408i/P416ie, Broadcom MegaRAID 9560). Write-back cache realnie przyspiesza bazy SQL i wirtualizację - różnica wydajnościowa między tymi klasami dla obciążeń bazodanowych jest dramatyczna.

Poziomy RAID dla MŚP

W MŚP najczęściej stosujemy układ 2x RAID 1 na system (ewentualnie z BOSS/M.2) plus RAID 10 na dane aplikacji i baz. Prosty, wydajny, przewidywalny w odbudowie. 90% serwerów, które konfigurujemy z kontrolerem sprzętowym, kończy w tym układzie.

Dlaczego rzadko sięgamy po RAID 5? Bo przy dzisiejszych pojemnościach dysków - 4 TB, 8 TB, 16 TB - czas odbudowy macierzy "piątki" po awarii potrafi się liczyć w dniach. Przez te dni macierz pracuje w trybie zdegradowanym, każdy odczyt obciąża pozostałe dyski, ryzyko padnięcia drugiego dysku w trakcie rebuildu staje się realnym zagrożeniem dla wszystkich danych. Dla 4-8 TB SAS-ów rebuildy potrafią trwać 24-72 godziny - to są godziny, w trakcie których cała kondycja macierzy wisi na dyskach, które mają już za sobą lata pracy w tym samym kurzu i temperaturze co ten, który właśnie padł.

Kiedy RAID 5 ma sens? Dla małych macierzy SSD (3-4 dyski) jako wolumen mniej krytyczny - rebuildy SSD są dużo szybsze niż HDD (mniej godzin, mniej obciążenia mechanicznego), a strata pojemności (jednego dysku z N) bywa istotna ekonomicznie. Stosujemy też RAID 5 świadomie tam, gdzie liczy się każdy gigabajt pojemności i mamy aktualny, sprawdzony backup poza maszyną. Dla baz produkcyjnych SQL i wirtualizacji w MŚP - dalej trzymamy się RAID 10.

RAID 6 (dwa dyski parzystości) ma sens dla większych macierzy archiwalnych z HDD - 8-12 dysków, znosi awarię dwóch dysków jednocześnie. Dla baz SQL i wirtualizacji - słaby wybór wydajnościowy, bo zapis wymaga obliczania dwóch parzystości na każdy blok.

RAID 1 (mirror, 2 dyski) zostaje dla systemu i małych woluminów - prosty, szybki, odbudowuje się w godzinę. RAID 10 (mirror + stripe, 4+ dysków) - najlepszy kompromis wydajność/odporność dla baz SQL i wirtualizacji, ale tracisz 50% pojemności. To jest cena, którą się płaci za nie martwienie się rebuildami.

A co z ZFS i rozwiązaniami software'owymi

Sprzętowy kontroler RAID nie jest jedyną sensowną drogą. W części wdrożeń stosujemy ZFS - system plików z wbudowaną ochroną integralności danych (sumy kontrolne dla każdego bloku, automatyczne wykrywanie i naprawa cichego uszkodzenia danych - tzw. bit rot), własnymi mechanizmami RAID-Z, snapshotami i replikacją. Dla serwerów plików, hostów backupowych i części wdrożeń wirtualizacji opartej o Linuksa albo TrueNAS to często lepszy wybór niż klasyczny kontroler sprzętowy. Pisaliśmy o tym osobno w artykule ZFS - system plików, który pilnuje twoich danych lepiej niż cokolwiek innego.

Decyzja "sprzętowy RAID czy ZFS" zależy od systemu operacyjnego (Windows Server praktycznie zawsze idzie ze sprzętowym RAID, Linux/TrueNAS/Proxmox - ZFS), wymagań aplikacji (SQL Server na Windows preferuje sprzętowy kontroler z BBU) i kompetencji zespołu utrzymaniowego.

Zasilacze - redundancja N+1

Zasilacze padają rzadko. Ale kiedy już padną, a ty masz tylko jeden, firma stoi. Dlatego dwa zasilacze to dla nas standard, nie opcja dodatkowa - choćby dlatego, że awaria pojedynczego PSU w środku dnia roboczego oznacza nie tylko nieplanowany przestój, ale też niezaplanowane tłumaczenie się szefowi działu produkcji albo zarządowi, dlaczego serwer leży.

Redundancja N+1 to dwa zasilacze hot-plug, każdy zdolny zasilić cały serwer samodzielnie. Padnie jeden, drugi przejmuje obciążenie. Technik wymienia uszkodzony bez wyłączania maszyny. Użytkownicy nawet nie wiedzą, że coś się stało.

Drugi argument za redundancją: wpinasz dwa zasilacze do dwóch różnych listew (a najlepiej do dwóch różnych obwodów - jeden zasilany z UPS-a, drugi z sieci albo z drugiego UPS-a). Gdy padnie listwa, gdy ktoś przypadkiem wyciągnie wtyczkę, gdy pracownik konserwacji wymienia gniazdko - serwer dalej pracuje.

HPE MicroServer ma jeden zewnętrzny zasilacz 180W i nie wspiera redundancji - to jego ograniczenie. Jeżeli kupujesz MicroServera, zaplanuj UPS i akceptuj fakt, że awaria zasilacza oznacza kilka godzin niedostępności do czasu wymiany. Dla oddziału - akceptowalne. Dla głównej maszyny w siedzibie - nie.

HPE ProLiant DL20 Gen11 oferuje opcję redundantnych zasilaczy 290W albo 500W (Hot Plug Redundant Power Supply). To opcja, która zwykle dokłada 300-500 zł do ceny serwera, ale realnie podnosi dostępność - wybieraj ją zawsze, kiedy serwer jest krytyczny dla pracy firmy.

Karta sieciowa - 1 GbE wystarczy?

Standardem w serwerach MŚP są dwa porty 1 GbE wbudowane w płytę (Embedded LOM albo OCP). Dla serwera pełniącego rolę serwera plików, Active Directory albo kontrolera Wi-Fi w mikrofirmie - wystarczy. Dla maszyny, która ma obsłużyć backup wieczorny 500 GB w oknie 4-godzinnym albo synchronizację repliki SQL między dwoma serwerami - 1 GbE jest już wąskim gardłem (realnie 100-110 MB/s).

Kiedy 10 GbE

Kupuj kartę 10 GbE, gdy:

• Backup nocny przekracza 200 GB i zaczyna się o 22:00, a pierwsi pracownicy logują się o 6:00 - musi się zmieścić.

• Masz drugi serwer (zapasowy, replica, klaster), który komunikuje się z pierwszym - replikacja SQL Server, backup Veeam Direct SAN, replikacja Hyper-V.

• File server obsługuje pracownie graficzne, CAD, video - pojedyncze pliki rzędu gigabajtów, kilkanaście stanowisk równolegle.

10 GbE wymaga też switcha 10 GbE i kabli SFP+ albo Cat 6A. To dodatkowy koszt po stronie sieci, więc patrz na to jako na inwestycję w warstwę, nie tylko w serwer.

LACP i teaming

Dwa porty 1 GbE z LACP (Link Aggregation) dają teoretycznie 2 Gb/s, w praktyce nie tyle, ile się wszystkim wydaje - LACP rozdziela ruch po haszu adresów MAC/IP, więc pojedynczy strumień (jedna sesja kopiowania) idzie po jednym porcie. Teaming jest sensowny dla redundancji (padnie jeden port, drugi przejmuje), ale nie traktuj go jako zamiennika 10 GbE.

Zdalne zarządzanie - iLO, iDRAC, XClarity

To jeden z parametrów, na którym najlepiej widać, czy ktoś dobiera serwer "za drogo" czy "tanio i zacznie boleć potem".

Każdy serwer enterprise ma kartę zdalnego zarządzania - HPE Integrated Lights-Out (iLO), Dell iDRAC, Lenovo XClarity Controller. Karta ma własny chip, własny adres IP, własny interfejs sieciowy i działa, nawet gdy serwer jest wyłączony. Pozwala:

• Włączyć i wyłączyć serwer zdalnie.

• Zobaczyć ekran POST i konsolę systemu (Virtual Console - jakbyś siedział przy maszynie z monitorem KVM).

• Zamontować zdalnie obraz ISO i zainstalować z niego system (Virtual Media).

• Czytać logi sprzętowe, temperatury, błędy ECC, status dysków.

• Powiadomić mailem albo SNMP, że coś się dzieje.

Dla firmy korzystającej z outsourcingu IT to jest podstawowe narzędzie zdalnej diagnostyki. Bez iLO/iDRAC każda awaria w nocy = ktoś jedzie na miejsce. Z iLO/iDRAC = administrator loguje się z domu, restartuje maszynę, sprawdza co się stało, raportuje rano. Różnica w czasie naprawy: kilkanaście minut zamiast kilku godzin.

Krótka dygresja, bo to istotne dla zrozumienia, dlaczego upieramy się przy iLO Advanced przy zakupie. Kto pamięta serwisowanie serwerów sprzed kilkunastu lat, ten doceni. Standardem była jazda do serwerowni o trzeciej w nocy, z monitorem, klawiaturą, pendrivem z bootowalnym Linuksem na wszelki wypadek - i kawą z automatu na stacji benzynowej, bo pomieszczenie z serwerem nigdy nie było w wygodnym miejscu. Pełne iLO/iDRAC zmieniło tę pracę nie do poznania. Dziś tę samą diagnostykę robisz z domu, w piętnaście minut, bez wkładania spodni. To wygląda jak drobny dodatek w specyfikacji, a w praktyce decyduje o tym, ile firma realnie traci na awariach po godzinach pracy. Tyle dygresji, wracamy do parametrów.

iLO Standard vs Advanced

HPE udostępnia iLO w dwóch wariantach. iLO Standard (bezpłatna licencja, wliczona w serwer) daje monitoring, zarządzanie zasilaniem, dostęp do logów. iLO Advanced (płatna licencja, dochodzi przy zakupie albo dokupowana osobno) dodaje pełną Virtual Console i Virtual Media - czyli to, czego naprawdę potrzebujesz w pracy zdalnej.

Naszą rekomendacją jest zawsze brać iLO Advanced przy zakupie serwera. Licencja przy nowym serwerze kosztuje ułamek ceny, dokupowana po fakcie - 2-3x więcej. Dell iDRAC ma analogiczny podział na Basic, Express i Enterprise - tu też wybieraj wariant Enterprise.

W HPE MicroServer jest okrojona wersja iLO 5 - nie pełne iLO Advanced, tylko podstawowy zdalny dostęp. To akceptowalne dla maszyny oddziałowej, ale dobrze o tym wiedzieć przed zakupem.

Gwarancja i wsparcie producenta

Serwer to sprzęt, który ma pracować 5-7 lat. Standardowa gwarancja HPE na ProLianty to 3 lata, NBD (Next Business Day) - jeżeli serwer padnie w poniedziałek o 14:00, części przyjeżdżają we wtorek. Dla mikrofirmy to często wystarczy - dla firmy, w której serwer zatrzymanie produkcji oznacza realne pieniądze, NBD bywa za wolne.

Pakiety, na które patrzeć

• HPE Tech Care Basic / Essential / Critical - rozszerzenia gwarancji na 4-5 lat z czasem reakcji odpowiednio NBD / 4h / 24x7. Critical bywa nadmiarowy dla MŚP, Essential (4h on-site, 24x7) jest sensownym wyborem dla maszyny krytycznej.

• Dell ProSupport / ProSupport Plus - analogiczne wsparcie po stronie Della, z opcją 4h Mission Critical.

• Defective Media Retention (DMR) - opcja "uszkodzony dysk zostaje u ciebie". Standardowo dyski wymieniane na gwarancji wracają do producenta. DMR jest opcją, którą rozważ, jeżeli przetwarzasz dane wrażliwe (dane osobowe, dokumentacja medyczna, dane finansowe) i nie chcesz wypuszczać dysku poza firmę nawet w postaci uszkodzonej.

Co nie jest gwarancją

Gwarancja producenta to nie jest umowa serwisowa twojego dostawcy IT. Producent przyjedzie z częścią - ktoś musi tę część wpiąć, zaktualizować firmware, sprawdzić macierz, przywrócić serwer do pracy. Robi to twój zespół IT albo zewnętrzny partner. W modelu obsługi IT, w którym pracujemy z klientami, te czynności są wliczone w abonament - w Helpwise IT baterie są w zestawie i wizyta technika po awarii sprzętu nie jest osobną fakturą.

HPE MicroServer i HPE DL20 (oraz odpowiedniki Della i Lenovo) - dla mniejszych firm i oddziałów

Dwa modele HPE, które kupujemy klientom najczęściej w sytuacjach, gdy pełnowymiarowy serwer 1U/2U jest za duży, a zwykły komputer biurowy nie spełnia wymagań serwerowych. W ofercie konkurentów odpowiadają im Dell PowerEdge R260 / R360 (1U, jeden socket Xeon E - bezpośredni odpowiednik DL20) oraz Lenovo ThinkSystem SR250 V3 / ST250 V3 (1U rack lub tower, też jeden socket Xeon E). Pod względem klasy maszyny i parametrów te trzy linie grają w tej samej lidze - wybór sprowadza się do polityki cenowej dystrybutora, dojrzałości narzędzi zarządzania (iLO vs iDRAC vs XClarity) i dostępności części w Polsce.

HPE ProLiant MicroServer

Mała maszyna, formfaktor mini-tower, typowo 1-procesorowa (Intel Xeon E-2300 albo Pentium Gold), 4 banki ECC UDIMM do 64 GB, 4 zatoki LFF na dyski (non-hot-plug), zewnętrzny zasilacz 180W, jeden port 1 GbE i opcjonalnie kart NIC PCIe.

Do czego sensowny:

• Oddział firmy - jedna maszyna dla 5-15 osób, file server + AD + kontroler Wi-Fi + lokalny backup. Cicha, niska, łatwo zmieścić w szafie biurowej.

• Mikrofirma - jako jedyny serwer dla firmy 5-10 osobowej z lekkim ERP (Optima, Symfonia) i Płatnikiem.

• Maszyna do specjalnych zastosowań - host monitoringu, backup target, serwer do testowania.

Czego nie oczekuj: redundancji zasilacza, hot-plug dysków, pełnego iLO Advanced, dwóch socketów, dużych pojemności RAM (limit 64 GB). Akceptujesz te ograniczenia w zamian za cenę i rozmiar.

HPE ProLiant DL20 Gen11

1U rack, jeden socket (Intel Xeon E-2400 series albo Pentium dla wariantów ekonomicznych), 4 banki DDR5 ECC UDIMM do 128 GB, 2-6 dysków SFF SSD/HDD, opcjonalny redundantny zasilacz 290W lub 500W, iLO 6 standardowo (z opcją Advanced).

Do czego sensowny:

• Główny serwer w małej firmie 15-40 osób z ERP, RDS dla 5-10 osób, AD, file server. Z 64-128 GB RAM, 4-6 SSD w RAID 10 i redundantnym zasilaczem - solidna baza.

• Drugi serwer w większej firmie - zapasowy DC, host backupu, host środowiska deweloperskiego.

• Oddział z większymi wymaganiami niż MicroServer - tam, gdzie ważna jest redundancja PSU i obecność w racku.

DL20 Gen11 vs MicroServer - DL20 ma pełny iLO 6 z opcją Advanced (kupujesz licencję), redundantne zasilacze (opcja, ale dostępna), obudowę rack. MicroServer ma niższy próg wejścia w kontekście ceny, mniejszą obudowę i tyle. Dla oddziału z małym budżetem MicroServer, dla głównej maszyny małej firmy - DL20.

Tabela: nasza ściągawka, od której zaczynamy rozmowy z klientami

Poniższa tabela to skrót, którego sami używamy jako punkt wyjścia w rozmowach. W realnym projekcie zawsze konfigurujemy szczegóły z klientem - inaczej wygląda firma księgowa, inaczej zakład produkcyjny - ale od czegoś trzeba zacząć:

Tabela jest punktem startowym, nie konfiguracją końcową. Realny dobór wymaga rozmowy o konkretnych obciążeniach, planowanym wzroście, polityce backupu i okienku serwisowym.

Najczęstsze pytania o dobór serwera dla małej i średniej firmy

Kiedy przegadać dobór serwera z kimś z zewnątrz

Dobór serwera na 5 lat to nie jest decyzja, którą się załatwia w godzinę przy mailowej ofercie od jednego dostawcy. Jeżeli rozpoznajesz u siebie któryś z tych symptomów:

• Obecny serwer przekroczył 5 lat i pakiety gwarancji kończą się w tym roku.

• ERP zaczyna działać wolno, sesje RDS przerywają się popołudniami, użytkownicy zgłaszają, że "system jest powolny".

• Kupujesz pierwszy serwer i nie chcesz powielić błędów z konfiguracji "pierwszego, jaki ci ktoś polecił".

• Otwierasz oddział i potrzebujesz lokalnej maszyny dla 5-15 osób.

• Backup nocny realizowany przez 1 GbE zaczyna nie mieścić się w oknie serwisowym.

To są te momenty, w których warto zatrzymać się i zastanowić: co serwer ma robić, jak długo, z jakim wzrostem obciążenia, w jakim modelu wsparcia. W Helpwise IT robimy to z klientami od 2000 roku - z perspektywy outsourcingu IT widzimy, jak konfiguracja kupiona dziś sprawdza się za 4 lata, gdy firma urośnie o 30%, a baza ERP - dwukrotnie. Jeżeli chcesz przegadać konkretny dobór dla swojej firmy, napisz do nas - rozmawiamy o realnych obciążeniach, nie o specyfikacjach z karty katalogowej.