Audyt infrastruktury u jednego z naszych klientów – średniej wielkości firmy produkcyjnej z Wielkopolski. 50 maszyn wirtualnych rozmieszczonych na czterech hostach. Wszystko "działa". Serwery są włączone, aplikacje odpowiadają, użytkownicy logują się codziennie. Ale od miesięcy słyszymy te same skargi: "System jest wolny", "Raport generuje się wieczność", "CRM się wiesza".

Kierownik IT był przekonany, że potrzebują nowego sprzętu. Przygotował już ofertę na dodatkowe serwery za 120,000 PLN. Zanim jednak firma podjęła decyzję o tej znaczącej inwestycji, poprosili nas o drugą opinię.

To, co znaleźliśmy, było szokujące – ale niestety typowe dla wielu firm.

Wirtualizacja: Technologia, która obiecywała oszczędności

Zanim przejdziemy do konkretów, warto przypomnieć, dlaczego wirtualizacja stała się standardem w nowoczesnych centrach danych. Obietnica była kusząca: zamiast dziesiątek fizycznych serwerów, z których każdy wykorzystuje 10-20% swoich możliwości, możemy mieć kilka potężnych hostów, na których uruchamiamy dziesiątki maszyn wirtualnych. Lepsze wykorzystanie zasobów, niższe koszty energii, łatwiejsze zarządzanie, szybsze wdrażanie nowych systemów.

I to wszystko prawda. Wirtualizacja rzeczywiście rewolucjonizuje sposób, w jaki budujemy infrastrukturę IT. Ale – i to duże "ale" – tylko wtedy, gdy jest właściwie skonfigurowana.

Problem polega na tym, że tworzenie maszyny wirtualnej jest dzisiaj tak proste, że stało się niebezpiecznie łatwe. Kilka kliknięć w interfejsie VMware, Hyper-V czy Proxmox i gotowe – nowa maszyna działa. Ale czy działa optymalnie? To zupełnie inna sprawa.

Co znaleźliśmy podczas audytu?

Wracając do naszego klienta z 50 maszynami wirtualnymi – oto lista problemów, które odkryliśmy w ciągu pierwszych dwóch godzin analizy:

Problem 1: Anarchia w alokacji CPU

Pierwsza maszyna, którą sprawdziliśmy, to serwer aplikacyjny obsługujący system ERP. Miał przypisane 8 vCPU. Brzmi rozsądnie, prawda? Problem w tym, że średnie wykorzystanie CPU wynosiło... 5%. Przez 95% czasu siedem z ośmiu wirtualnych procesorów stało bezczynnie.

"No i dobrze" – pomyślisz – "lepiej mieć zapas". Ale w wirtualizacji to nie działa tak jak w świecie fizycznym. Każdy vCPU musi być schedulowany przez hypervisor. Maszyna z 8 vCPU musi czekać, aż wszystkie osiem wirtualnych rdzeni będzie mogło być jednocześnie zmapowanych na fizyczne rdzenie. Im więcej vCPU, tym dłuższe kolejki, tym więcej context switching, tym większy overhead.

Znaleźliśmy 15 maszyn z podobnym problemem. Łącznie zmarnowane: 60 vCPU, które mogły obsługiwać inne workloady.

Problem 2: Overcommitment pamięci na sterydach

Host numer dwa miał 256 GB RAM. Maszyny wirtualne na nim uruchomione miały łącznie... 768 GB przypisanej pamięci. Współczynnik overcommitment 3:1.

Samo w sobie overcommitment nie jest złem. Hypervisory mają zaawansowane mechanizmy zarządzania pamięcią – memory ballooning, transparent page sharing, kompresję. Ale przy współczynniku 3:1 te mechanizmy pracują na pełnych obrotach non-stop.

Efekt? Memory ballooning był aktywny przez 80% czasu. Oznacza to, że hypervisor musiał "odbierać" pamięć maszynom wirtualnym, które teoretycznie ją miały przypisaną. Aplikacje zaczynały swapować. Serwer baz danych, który powinien trzymać wszystko w RAM, musiał sięgać do dysku. Każde zapytanie trwało dwa razy dłużej niż powinno.

Problem 3: Storage provisioning bez strategii

Sprawdziliśmy wykorzystanie przestrzeni dyskowej. Z 8 TB dostępnego miejsca wykorzystane było... 3.2 TB. Gdzie reszta?

Okazało się, że wszystkie dyski były skonfigurowane jako thick provisioned eager zeroed. To najwolniejszy, ale najbezpieczniejszy sposób alokacji miejsca – cała przestrzeń jest rezerwowana i zerowana z góry. Świetne dla krytycznych baz danych. Kompletnie bez sensu dla serwera testowego, który zajmuje 50 GB z przydzielonych 500 GB.

Zmarnowane: prawie 5 TB przestrzeni, która mogła być wykorzystana produktywnie.

Problem 4: NUMA – niewidzialny zabójca wydajności

To był najpoważniejszy problem, choć najmniej oczywisty.

Nowoczesne procesory serwerowe mają architekturę NUMA (Non-Uniform Memory Access). W uproszczeniu: każdy procesor ma "swoją" pamięć RAM, do której ma szybki dostęp. Dostęp do pamięci "drugiego" procesora jest wolniejszy.

Maszyny wirtualne powinny być konfigurowane z uwzględnieniem NUMA topology – tak, żeby vCPU i pamięć były przypisane do tego samego węzła NUMA. Jeśli tego nie zrobisz, procesor musi ciągle sięgać przez interconnect do pamięci na drugim sockecie.

Żadna z 50 maszyn nie miała włączonej NUMA awareness. Żadna.

Strata wydajności? W przypadku aplikacji intensywnie korzystających z pamięci – nawet 20-25%.

Problem 5: Brak limitów i rezerwacji

Znaleźliśmy maszynę wirtualną z priorytetem "High" i unlimited shares dla CPU i pamięci. Była to... maszyna testowa, która nie była używana od trzech miesięcy.

Jednocześnie produkcyjny serwer baz danych miał domyślne ustawienia – "Normal" priority i brak rezerwacji. W momencie, gdy kilka maszyn zaczynało konkurować o zasoby, testowa maszyna (teoretycznie) mogła "ukraść" CPU produkcyjnemu serwerowi.

Na szczęście nie doszło do tego scenariusza, ale samo ryzyko było nieakceptowalne.

Proces optymalizacji: Co zmieniliśmy?

Po zidentyfikowaniu problemów przeszliśmy do działania. Cały proces optymalizacji zająć trzy dni – w tym czas na testy i weryfikację.

Krok 1: Right-sizing maszyn wirtualnych

Przeanalizowaliśmy rzeczywiste wykorzystanie zasobów przez ostatnie 90 dni. Dla każdej maszyny wirtualnej stworzyliśmy profil: średnie wykorzystanie CPU, peak usage, wzorce obciążenia, wykorzystanie pamięci.

Na tej podstawie:

• 23 maszyny zmniejszyliśmy z 8 vCPU do 4 vCPU
• 12 maszyn zmniejszyliśmy z 4 vCPU do 2 vCPU
• 8 maszyn zmniejszyliśmy alokację RAM o 30-50%
• 3 krytyczne maszyny (serwery baz danych) zwiększyliśmy alokację RAM o 20%

Każdą zmianę testowaliśmy pod obciążeniem. Ani jedna maszyna nie straciła na wydajności – większość zyskała.

Krok 2: Optymalizacja pamięci i eliminacja overcommitment

Zmniejszenie alokacji RAM dla maszyn, które jej nie potrzebowały, pozwoliło nam zredukować overcommitment z 3:1 do 1.3:1. To bezpieczny poziom, który pozwala hypervisorowi na elastyczność bez konieczności agresywnego ballooningu.

Dla krytycznych maszyn ustawiliśmy memory reservation – gwarancję, że przypisana pamięć będzie zawsze dostępna, bez względu na obciążenie innych VM.

Krok 3: Storage tiering i thin provisioning

Podzieliliśmy maszyny na trzy kategorie:

• Tier 1 (krytyczne bazy danych): thick provisioned eager zeroed – maksymalna wydajność i bezpieczeństwo
• Tier 2 (produkcyjne aplikacje): thick provisioned lazy zeroed – dobra wydajność, szybsze tworzenie
• Tier 3 (dev/test, niekrytyczne): thin provisioned – maksymalna efektywność miejsca

Odzyskaliśmy 4.2 TB przestrzeni, którą mogliśmy przeznaczyć na nowe projekty.

Krok 4: Konfiguracja NUMA

To była najbardziej techniczna część. Dla każdej maszyny z więcej niż 4 vCPU:

• Włączyliśmy NUMA awareness w ustawieniach VM
• Skonfigurowaliśmy vNUMA topology odpowiadającą fizycznej architekturze
• Dla największych maszyn (8+ vCPU) użyliśmy CPU affinity, żeby przypiąć je do konkretnych węzłów NUMA

Efekt był natychmiastowy i mierzalny.

Krok 5: Resource pools i priorytety

Stworzyliśmy strukturę resource pools:

• Production-Critical: 60% shares, wysokie rezerwacje
• Production-Standard: 30% shares, umiarkowane rezerwacje
• Development: 10% shares, brak rezerwacji

Każdą maszynę przypisaliśmy do odpowiedniego poola. Teraz system wie, które workloady są priorytetowe.

Rezultaty: Liczby mówią same za siebie

Po tygodniu od zakończenia optymalizacji zebraliśmy metryki:

Wydajność aplikacji:

• Serwer ERP: średni czas odpowiedzi zmniejszył się o 28%
• Baza danych: zapytania wykonują się średnio 23% szybciej
• CRM: czas ładowania dashboardów spadł z 8 sekund do 5 sekund
• Serwer plików: przepustowość wzrosła o 19%

Wykorzystanie zasobów:

• CPU ready time spadł z średnio 8% do 1.2%
• Memory ballooning praktycznie wyeliminowany (z 80% czasu do <5%)
• Storage latency zmniejszone o 15%
• Odzyskane 4.2 TB przestrzeni dyskowej

Możliwości rozwoju:

• Uwolnione zasoby pozwalają na uruchomienie 12-15 dodatkowych maszyn wirtualnych
• Bez konieczności zakupu nowego sprzętu

Oszczędności finansowe:

• Uniknięta inwestycja w nowy sprzęt: 120,000 PLN
• Koszt optymalizacji: 8,500 PLN (nasz czas pracy)
• ROI: 1,312%

Dlaczego to się dzieje? Anatomia problemu

Po setkach podobnych audytów widzimy powtarzające się wzorce. Dlaczego tak wiele firm ma źle skonfigurowane maszyny wirtualne?

1. Wirtualizacja jest "za łatwa"

Paradoksalnie, prostota tworzenia VM jest problemem. W czasach fizycznych serwerów każda nowa maszyna wymagała zakupu sprzętu, instalacji, konfiguracji. Był czas na przemyślenie wymagań.

Dziś? Kilka kliknięć i masz nową maszynę. Często z domyślnymi ustawieniami, które "powinny działać". I działają – ale nie optymalnie.

2. Brak ciągłego monitoringu i optymalizacji

Maszyna wirtualna jest tworzona z pewnymi założeniami: "aplikacja będzie potrzebować 8 GB RAM i 4 vCPU". Po roku okazuje się, że używa 3 GB i 15% jednego CPU. Ale nikt tego nie sprawdza.

Infrastruktura IT to żywy organizm. Wymagania się zmieniają, obciążenia rosną i maleją. Konfiguracja sprzed roku może być nieoptymalna dziś.

3. Kopiowanie "sprawdzonych" szablonów

"Ostatni serwer aplikacyjny miał 8 vCPU, więc ten też dajmy 8". Logiczne, prawda? Ale może tamten też był źle skonfigurowany?

Widzimy firmy, gdzie wszystkie maszyny mają identyczną konfigurację – 4 vCPU, 16 GB RAM – niezależnie od tego, czy to serwer baz danych obsługujący 500 użytkowników, czy testowa maszyna używana raz w miesiącu.

4. Brak wiedzy o zaawansowanych funkcjach

NUMA topology, CPU affinity, memory reservation, storage tiering – to nie są egzotyczne funkcje. To podstawowe narzędzia optymalizacji. Ale wymagają wiedzy i doświadczenia.

Większość administratorów IT zna podstawy wirtualizacji. Ale różnica między "działającą" a "optymalną" infrastrukturą leży właśnie w tych zaawansowanych konfiguracjach.

5. Presja czasu i priorytetów

"Potrzebujemy nowego serwera na jutro" – słyszymy to często. W pośpiechu administrator tworzy maszynę z domyślnymi ustawieniami, obiecując sobie, że "później to zoptymalizuje".

Później nigdy nie nadchodzi. Maszyna działa, więc nikt do niej nie wraca. Aż do momentu, gdy problemy z wydajnością stają się nie do zniesienia.

Najczęstsze błędy konfiguracyjne – kompletna lista

Na podstawie setek audytów stworzyliśmy listę najczęstszych błędów. Jeśli którykolwiek z nich występuje w Twojej infrastrukturze, tracisz wydajność:

CPU:

• ❌ Za dużo vCPU w stosunku do rzeczywistych potrzeb
• ❌ Brak CPU reservation dla krytycznych workloadów
• ❌ Ignorowanie CPU ready time w monitoringu
• ❌ Overcommitment CPU powyżej 4:1
• ❌ Brak CPU affinity dla dużych maszyn (8+ vCPU)
• ❌ Wyłączona NUMA awareness
• ❌ Nieprawidłowe ustawienie CPU shares/limits

Pamięć:

• ❌ Memory overcommitment powyżej 1.5:1 bez monitoringu
• ❌ Brak memory reservation dla baz danych
• ❌ Aktywny memory ballooning przez większość czasu
• ❌ Transparent page sharing jako główna strategia oszczędzania RAM
• ❌ Zbyt mała pamięć dla aplikacji intensywnie z niej korzystających
• ❌ Zbyt duża pamięć dla małych workloadów
• ❌ Brak limitów pamięci dla maszyn testowych

Storage:

• ❌ Thick provisioning dla wszystkich maszyn (marnotrawstwo miejsca)
• ❌ Thin provisioning dla wszystkich maszyn (ryzyko przepełnienia)
• ❌ Brak storage tiering (wszystko na tym samym tier)
• ❌ Ignorowanie storage latency w monitoringu
• ❌ Zbyt wiele VM na jednym datastorze
• ❌ Brak separacji dla intensywnych operacji I/O
• ❌ Snapshoty starsze niż 24-48 godzin

Sieć:

• ❌ Pojedyncza karta sieciowa (brak redundancji)
• ❌ Brak separacji ruchu (management, vMotion, storage, produkcja na jednej sieci)
• ❌ Niewykorzystanie SR-IOV dla wymagających aplikacji
• ❌ Brak QoS i traffic shapingu
• ❌ Zbyt małe MTU dla ruchu storage (brak jumbo frames)

Ogólne:

• ❌ Wszystkie maszyny z tym samym priorytetem
• ❌ Brak resource pools
• ❌ Brak regularnych audytów wydajności
• ❌ Kopiowanie konfiguracji bez analizy potrzeb
• ❌ Ignorowanie alertów i ostrzeżeń hypervisora

Jak samodzielnie zdiagnozować problemy?

Nie musisz od razu wzywać zewnętrznych konsultantów. Oto kilka prostych kroków, które możesz wykonać samodzielnie:

1. Sprawdź CPU Ready Time

W VMware vCenter lub Hyper-V Manager sprawdź metrykę "CPU Ready Time" dla każdej maszyny. Jeśli wartość przekracza 5% (lub 1000ms na 20 sekund), masz problem.

Co to oznacza? Maszyna wirtualna czeka na dostęp do fizycznych rdzeni CPU. Im wyższa wartość, tym więcej czasu marnuje na czekanie zamiast na pracę.

Jak naprawić? Zmniejsz liczbę vCPU lub zwiększ CPU reservation dla tej maszyny.

2. Monitoruj Memory Ballooning

Sprawdź, jak często i jak intensywnie działa memory ballooning. Okazjonalne użycie (kilka procent czasu) jest OK. Ciągłe ballooning to czerwona flaga.

Co to oznacza? Hypervisor musi agresywnie "odbierać" pamięć maszynom, bo jest jej za mało.

Jak naprawić? Zmniejsz memory overcommitment lub dodaj fizycznej pamięci RAM do hosta.

3. Przeanalizuj rzeczywiste wykorzystanie zasobów

Dla każdej maszyny sprawdź:

• Średnie wykorzystanie CPU za ostatnie 30/60/90 dni
• Peak usage CPU
• Średnie wykorzystanie RAM
• Peak usage RAM

Jeśli maszyna ma 8 vCPU, ale średnio używa 10% z jednego rdzenia, masz problem z over-provisioningiem.

4. Sprawdź Storage Latency

Latencja dysku powinna być:

• <10ms dla standardowych aplikacji
• <5ms dla baz danych
• <2ms dla krytycznych workloadów

Jeśli widzisz wartości powyżej 20ms, masz poważny problem z storage.

5. Zweryfikuj NUMA Configuration

W VMware: sprawdź Advanced Settings każdej maszyny. Szukaj parametru numa.autosize. Jeśli jest ustawiony na FALSE lub nie istnieje, NUMA awareness jest wyłączona.

Kiedy warto wezwać specjalistów?

Niektóre optymalizacje możesz wykonać samodzielnie. Ale są sytuacje, gdy warto skonsultować się z ekspertami:

1. Planowanie nowej infrastruktury

Jeśli budujesz nowe środowisko wirtualizacyjne od zera, warto od razu zrobić to dobrze. Poprawianie błędów później jest droższe i bardziej ryzykowne.

2. Migracja do chmury lub nowego hypervisora

Migracja z VMware do Hyper-V, z on-premise do Azure, z fizycznych serwerów do wirtualnych – to moment, żeby przemyśleć całą architekturę na nowo.

3. Problemy z wydajnością, których nie możesz zdiagnozować

Jeśli użytkownicy narzekają na wolne systemy, a Ty nie widzisz oczywistych problemów w metrykach, potrzebujesz głębszej analizy.

4. Przed dużą inwestycją w sprzęt

Jeśli planujesz wydać 100,000+ PLN na nowe serwery, warto najpierw sprawdzić, czy na pewno ich potrzebujesz. Może wystarczy optymalizacja?

5. Regularne audyty (raz na 12-18 miesięcy)

Infrastruktura zmienia się w czasie. Regularne audyty pozwalają wychwycić problemy, zanim staną się krytyczne.

Narzędzia do monitoringu i optymalizacji

Nie musisz polegać tylko na wbudowanych narzędziach hypervisora. Oto kilka rozwiązań, które pomogą Ci utrzymać infrastrukturę w optymalnym stanie:

Darmowe/wbudowane:

• VMware vRealize Operations (wersja trial/podstawowa)
• Microsoft System Center Virtual Machine Manager
• Veeam ONE (wersja darmowa)
• PowerCLI scripts (dla VMware)

Komercyjne:

• Turbonomic (teraz IBM) – automatyczna optymalizacja
• vRealize Operations (pełna wersja) – zaawansowana analityka
• SolarWinds Virtualization Manager
• PRTG Network Monitor (z sensorami dla wirtualizacji)

Open Source:

• Prometheus + Grafana – monitoring metryk
• Zabbix – kompleksowy monitoring
• Netdata – real-time performance monitoring

Najlepsze praktyki: Jak utrzymać optymalną konfigurację?

Optymalizacja to nie jednorazowa akcja. To ciągły proces. Oto sprawdzone praktyki:

1. Twórz maszyny "na miarę", nie "na zapas"

Zamiast domyślnie dawać 8 vCPU i 16 GB RAM, zacznij od minimum i zwiększaj w razie potrzeby. Łatwiej dodać zasoby niż je odebrać.

2. Monitoruj przez 2-4 tygodnie przed optymalizacją

Nie podejmuj decyzji na podstawie jednego dnia. Zbierz dane przez pełny cykl biznesowy, żeby zobaczyć rzeczywiste wzorce obciążenia.

3. Dokumentuj zmiany i ich powody

Każda zmiana konfiguracji powinna być udokumentowana: co, kiedy, dlaczego, jaki był efekt. Za rok przyda Ci się ta wiedza.

4. Testuj zmiany w środowisku testowym

Jeśli to możliwe, najpierw przetestuj optymalizacje na maszynach niekrytycznych lub w środowisku dev/test.

5. Wdrażaj zmiany stopniowo

Nie optymalizuj 50 maszyn jednocześnie. Zacznij od 5-10, sprawdź efekty, wyciągnij wnioski, dopiero potem przejdź do kolejnych.

6. Regularnie przeglądaj "zombie VMs"

Co kwartał sprawdzaj, które maszyny nie są używane. Wyłącz je lub usuń. Każda niepotrzebna maszyna to zmarnowane zasoby.

7. Automatyzuj, co się da

Używaj skryptów do regularnego zbierania metryk, generowania raportów, identyfikowania anomalii. Nie polegaj tylko na ręcznych sprawdzeniach.

Koszt ignorowania problemu

Wróćmy do naszego klienta z początku artykułu. Co by się stało, gdyby nie zdecydowali się na audyt?

Scenariusz bez optymalizacji:

• Inwestycja w nowy sprzęt: 120,000 PLN
• Dodatkowe koszty energii: ~8,000 PLN rocznie
• Dodatkowe koszty licencji (więcej hostów): ~15,000 PLN rocznie
• Ciągłe problemy z wydajnością i niezadowoleni użytkownicy
• Łączny koszt w 3 lata: ~189,000 PLN

Scenariusz z optymalizacją:

• Koszt audytu i optymalizacji: 8,500 PLN
• Brak dodatkowych kosztów sprzętu i energii
• Lepsza wydajność i zadowoleni użytkownicy
• Oszczędność: 180,500 PLN w 3 lata

A to tylko bezpośrednie koszty. Nie uwzględniamy:

• Czasu straconego przez pracowników na czekanie na wolne systemy
• Utraconej produktywności
• Frustracji użytkowników
• Ryzyka awarii z powodu przeciążenia

Podsumowanie: Wydajność to nie przypadek

Wirtualizacja to potężne narzędzie, które może znacząco obniżyć koszty IT i zwiększyć elastyczność infrastruktury. Ale tylko wtedy, gdy jest właściwie skonfigurowana i zarządzana.

Kluczowe wnioski z tego artykułu:

✅ Źle skonfigurowane maszyny wirtualne mogą tracić nawet 20% wydajności – to jak płacić za 10 serwerów, a mieć moc 8.

✅ Najczęstsze problemy to over-provisioning CPU, memory overcommitment i ignorowanie NUMA – wszystkie łatwe do naprawienia, jeśli wiesz, czego szukać.

✅ Optymalizacja często kosztuje mniej niż zakup nowego sprzętu – i daje lepsze rezultaty.

✅ Monitoring i regularne audyty to klucz do utrzymania optymalnej wydajności – infrastruktura zmienia się w czasie.

✅ Nie musisz być ekspertem od wirtualizacji – ale musisz wiedzieć, kiedy poprosić o pomoc.

Jak Interactive Workspace może pomóc?

Specjalizujemy się w audytach i optymalizacji infrastruktury wirtualnej. Nasz proces obejmuje:

🔍 Kompleksowy audyt – analiza konfiguracji, metryk wydajności, identyfikacja problemów

📊 Szczegółowy raport – konkretne zalecenia z uzasadnieniem i przewidywanymi efektami

⚙️ Wdrożenie optymalizacji – bezpieczne wprowadzenie zmian z pełnym testowaniem

📈 Weryfikacja rezultatów – pomiar efektów i dostrajanie konfiguracji

📚 Transfer wiedzy – szkolenie Twojego zespołu, żeby mogli utrzymać optymalną konfigurację

Niezależnie od tego, czy używasz VMware, Hyper-V, Proxmox czy mieszanej infrastruktury – pomożemy Ci wyciągnąć maksimum z posiadanych zasobów.

Zanim zainwestujesz w nowy sprzęt, sprawdź, czy wykorzystujesz to, co już masz.