TL;DR dla CIO/CTO: Jeżeli systemy SAP w Państwa organizacji pracują na SUSE Linux Enterprise Server for SAP Applications - a w Polsce dotyczy to większości środowisk - to KVM (Kernel-based Virtual Machine) jest już wliczony w Państwa subskrypcję. Jest natywnie certyfikowany przez SAP dla S/4HANA i HANA (SAP Note 1122387). Po zmianach licencyjnych Broadcom w VMware decyzja “płacić dwa razy” przestała być neutralna - przeszła w kategorię pytania, na które zarząd ma prawo poznać odpowiedź.
Punkt wyjścia: co się zmieniło w 2024-2026
Przejęcie VMware przez Broadcom (listopad 2023) zmieniło model licencyjny w sposób, który dla większości organizacji SAP w Polsce oznacza dwucyfrowy wzrost rachunku rocznego. W praktyce:
- Koniec produktów standalone - vSphere Standard, vSphere Enterprise Plus, vSAN, NSX jako osobne SKU zostały wycofane. Klient kupuje pakiet (VMware Cloud Foundation lub VMware vSphere Foundation), a nie pojedyncze komponenty.
- Subskrypcja per-core, nie per-CPU - minimum 16 rdzeni na CPU jako jednostka rozliczeniowa, niezależnie od fizycznej konfiguracji serwera.
- Likwidacja licencji wieczystych - klienci, którzy przez lata płacili wyłącznie za support, dziś stają przed wyborem: subskrypcja w nowym modelu albo brak aktualizacji bezpieczeństwa.
- Wzrost cen - zależnie od konfiguracji, sygnały rynkowe wskazują na trzy- do dziesięciokrotny wzrost rocznego kosztu utrzymania tej samej platformy.
Dla środowiska SAP, w którym jeden klaster może liczyć kilkadziesiąt rdzeni produkcyjnych plus QA, dev i sandboxy, oznacza to wzrost pozycji budżetowej, której nikt sześć miesięcy temu nie planował.
Druga strona równania, którą warto zobaczyć
W tej samej organizacji, w której rachunek VMware właśnie wzrósł, najprawdopodobniej obecny jest system operacyjny, za który Państwo płacą od lat - SUSE Linux Enterprise Server for SAP Applications. To dziś dominujący Linux pod SAP w Polsce, częściowo z powodu długiej historii partnerstwa SAP-SUSE, częściowo dlatego, że SAP rekomenduje go w typowych scenariuszach HANA.
Mniej znany fakt: subskrypcja SLES for SAP zawiera prawo do uruchamiania KVM jako hypervisora produkcyjnego, włącznie z wirtualizacją systemów krytycznych. Bez dopłaty. Bez osobnej licencji. To nie jest “darmowy Linux” - to element pakietu, który Państwo już kupili.
Kluczowy element, którego brakuje w większości dyskusji o “alternatywach VMware”:
SAP Note 1122387 - Linux: SAP Support in virtualized environments jednoznacznie wymienia KVM jako certyfikowany hypervisor dla obciążeń SAP, w tym S/4HANA i SAP HANA, na SLES for SAP.
To nie jest eksperyment, hobby projekt, ani decyzja “na własne ryzyko”. To certyfikowana ścieżka, którą SAP wspiera w ramach standardowego SLA.
”Ale czy KVM ma to, co miało VMware?”
To jest właściwe pytanie. Pozwolimy sobie odpowiedzieć rzeczowo, funkcja po funkcji:
| Funkcja produkcyjna | VMware vSphere | KVM na SLES for SAP |
|---|---|---|
| Live migration maszyn wirtualnych | vMotion | libvirt + virsh migrate / live block migration |
| Wysoka dostępność (HA) | vSphere HA | Pacemaker + Corosync (część SLES HA Extension) |
| Snapshoty i kopie zapasowe | VMware Snapshots | qcow2 snapshots, integracja z backupem (Veeam, Bareos, SEP) |
| Zarządzanie centralne | vCenter | SUSE Manager / Cockpit / SUSE Virtualization (oparta na Harvester) |
| Storage replication | vSAN, SRM | DRBD, Ceph, replikacja na poziomie macierzy |
| Monitoring i wydajność | vRealize | Prometheus + Grafana, SAP Host Agent, SUSE Manager |
| Wsparcie producenta | Broadcom | SUSE (24/7, polski support pierwszej linii dostępny przez partnerów) |
Lista nie jest wyczerpująca. Pomijamy też uczciwie miejsca, w których VMware nadal ma przewagę narzędziową - na przykład dojrzałość interfejsu vCenter dla administratora, który spędził z nim piętnaście lat. To realna wartość, której nie należy bagatelizować.
Ale w warstwie funkcjonalnej, w której pracuje SAP - uruchom maszynę, daj jej zasoby, przenieś ją na żywo na inny host, zrób snapshot, odtwórz po awarii - KVM od kilku lat domyka tę lukę.
Skąd nasza pewność: krótka historia operacyjna
Pierwsze wdrożenia produkcyjne SAP na KVM w Polsce sięgają roku 2018. Red Hat i SUSE wspólnie utrzymywały certyfikację KVM dla SAP od momentu, w którym SAP zaczął traktować Linux jako platformę pierwszego wyboru dla HANA (2014-2015). Sześć lat później KVM stoi pod znacznymi obciążeniami produkcyjnymi - od finansów, przez retail, po administrację publiczną w UE.
W zespole SAP Basis SNOK obserwujemy te wdrożenia od strony technicznej. Pojedyncze, dobrze zaprojektowane środowisko KVM pod S/4HANA potrafi obsłużyć kilkanaście instancji aplikacyjnych i bazodanowych z parametrami SLA porównywalnymi do równoległego środowiska VMware - przy zerowym koszcie licencji hypervisora.
“Pytanie, które dziś dostajemy od dyrektorów IT, nie brzmi już ‘czy KVM się nada’. Brzmi ‘co konkretnie zmieni się w naszym dniu operacyjnym po migracji’. To zdrowa zmiana - rozmowa o ryzyku operacyjnym, a nie o ideologii.” - Jarosław Zdanowski, Partner odpowiedzialny za SAP Basis i Cybersecurity w SNOK
Trzy warstwy decyzji, które warto rozłożyć
Większość organizacji, z którymi rozmawiamy, podejmuje tę decyzję jednowymiarowo - “jest drogo, szukamy taniej”. To zbyt wąska perspektywa. Sensowna analiza obejmuje trzy warstwy:
Warstwa 1. Finansowa
Konkretne porównanie TCO w horyzoncie pięciu lat: subskrypcja VMware w nowym modelu (z prognozowanym wzrostem) versus jednorazowy koszt migracji do KVM plus zerowy koszt hypervisora w kolejnych latach. Dla średniej wielkości środowiska SAP w Polsce różnica liczona w pięciu latach mieści się zwykle w przedziale od jednego do kilku milionów złotych.
Warstwa 2. Ryzyka strategicznego
Pytanie, które dziś zadają sobie zarządy: na ile uzależnienie krytycznych systemów od jednego dostawcy, który właśnie przeprowadził najgłębszą zmianę modelu biznesowego w swojej historii, jest akceptowalne w perspektywie kolejnej dekady? To nie jest pytanie ideologiczne. To pytanie o dywersyfikację ryzyka technologicznego - to samo, które rozsądny CFO zadaje o dostawców finansowych.
Warstwa 3. Operacyjna
Najmniej widoczna, najważniejsza w praktyce. Migracja oznacza, że zespół, który dziesięć lat operował VMware, będzie operował KVM. Wymaga to: planu szkoleń, zmiany w runbookach, weryfikacji integracji z systemami backupu, monitoringu, automatyzacji. To jest rzeczywista praca i nie należy jej minimalizować w prezentacji dla zarządu.
Jak my podchodzimy do takich migracji
Dla zachowania transparentności - to nie jest punkt sprzedażowy, to opis metody:
- Discovery (1-2 tygodnie) - mapa obecnego środowiska VMware, inwentarz maszyn pod SAP, profil obciążeń, audyt licencji SUSE pod kątem uprawnień do KVM.
- Analiza wykonalności i TCO (1-2 tygodnie) - porównanie finansowe i operacyjne dwóch scenariuszy: pozostanie na VMware versus migracja do KVM. Bez automatycznej rekomendacji - decyzja należy do Państwa.
- PoC na środowisku nieprodukcyjnym (2-4 tygodnie) - jedna lub dwie instancje SAP przeniesione do KVM, weryfikacja procesów backupu, HA, monitoringu, integracji z istniejącym Solution Manager / Cloud ALM.
- Plan migracji produkcji (faza wdrożeniowa) - tylko jeżeli decyzja na “tak”. Sekwencja okien serwisowych, plan rollback, transfer wiedzy do Państwa zespołu.
W większości przypadków całość mieści się w jednej linii budżetowej projektowej, nie w stałym koszcie operacyjnym. To jest właśnie ten model, który zmienia matematykę: jednorazowa inwestycja zamiast rosnącej corocznie subskrypcji.
Kiedy KVM nie będzie dobrą rekomendacją
Aby tekst pozostał uczciwy - są scenariusze, w których pozostanie przy VMware jest właściwą decyzją:
- Państwa organizacja używa intensywnie zaawansowanych funkcji vSAN, NSX, SRM i nie ma planów ich zastąpienia rozwiązaniami natywnymi.
- Środowisko SAP jest w trakcie aktywnej transformacji (konwersja do S/4HANA, migracja do chmury) - dokładanie kolejnej zmiany platformy w tym samym oknie czasowym zwiększa ryzyko ponad próg akceptowalny.
- Wewnętrzny zespół IT nie ma kompetencji linuksowych i organizacja nie chce ich budować ani outsourcować w stałym modelu.
W każdym z tych przypadków właściwą decyzją jest renegocjacja warunków z Broadcom (możliwa, choć trudna) lub zaplanowanie migracji w późniejszym oknie - nie wymuszanie zmiany dla samej zmiany.
Co warto zrobić w tym kwartale
Jeden krok, który nic nie kosztuje, a daje pełną podstawę do dyskusji w zarządzie:
Sprawdzić w umowie SUSE Linux Enterprise Server for SAP Applications zakres uprawnień do KVM jako hypervisora produkcyjnego. W większości przypadków zobaczą tam Państwo, że to prawo już Państwu przysługuje. To jeden telefon do account managera SUSE lub partnera, który Państwa subskrypcję obsługuje.
Drugi krok, jeżeli pierwszy potwierdzi uprawnienia: zlecić niezależną analizę TCO i wykonalności. Niezależną - to znaczy nie u dostawcy VMware ani nie u jednego z większych integratorów, dla którego utrzymanie status quo jest bardziej rentowne niż jego zmiana.
W SNOK takie analizy prowadzimy regularnie. Format jest stały: dwa-trzy tygodnie pracy, prezentacja dla zarządu z trzema scenariuszami (pozostanie, migracja częściowa, migracja pełna), liczby oparte na Państwa rzeczywistym środowisku, a nie na benchmarkach z prezentacji producentów.
Decyzja zawsze pozostaje po Państwa stronie. Ale warto, żeby była podjęta na podstawie własnych danych, a nie cudzych założeń.
Powiązane materiały
- SAP Basis i bezpieczeństwo SAP - usługi SNOK
- SUSE - partner technologiczny SNOK (Gold)
- SecurityBridge w architekturze obronnej SAP
Porozmawiajmy
Jeżeli temat dotyczy Państwa organizacji - jesteśmy do dyspozycji w ciągu 48 godzin. Dwie godziny niezobowiązującej rozmowy z naszym inżynierem SAP Basis. Bez prezentacji handlowej, bez slajdów. Pytania, odpowiedzi, mapa decyzji.