Masz pytania? tel. (32) 209-80-39 e-mail: oracle@polsoft.pl

Bezpłatna konsultacja

Artykuł

Oracle na VMware, Proxmoksie i w chmurze: ile licencji naprawdę potrzeba

Trzy serwery połączone w klaster wirtualizacji.

Maszyna wirtualna z bazą Oracle i czterema vCPU nie oznacza czterech rdzeni do licencjonowania. Oracle Partitioning Policy wymienia VMware wśród technologii soft partitioning i stwierdza, że nie służą one do ustalania ani ograniczania liczby licencji dla serwera lub klastra serwerów. Licencjonuje się fizyczne procesory, na których program jest zainstalowany lub uruchomiony. Wyjątków jest kilka: Oracle Linux KVM z przypiętymi rdzeniami, kilka technologii sprzętowych, systemy Engineered Systems i chmury, dla których Oracle ma osobne przeliczniki.

Informacje ogólne według stanu na 14 października 2026 r. Wiążące są umowa licencyjna i aktualne dokumenty Oracle, więc przed wdrożeniem sprawdź je w Oracle albo u partnera licencyjnego.

Soft i hard partitioning

Polityka partycjonowania Oracle dzieli technologie na dwie grupy.

Soft partitioning to podział zasobów przez system operacyjny albo hiperwizor. Dokument podaje przykłady: Solaris 9 Resource Containers, AIX Workload Manager, HP Process Resource Manager, Affinity Management, Oracle VM i VMware. Takie rozwiązania, łącznie z ich funkcjami, nie ograniczają liczby licencji.

Hard partitioning fizycznie dzieli serwer na mniejsze, niezależne systemy. Polityka wymienia zamkniętą listę: Physical Domains (Dynamic Domains), Solaris Zones (tylko z limitem), IBM LPAR, IBM Micro-Partitions (tylko z limitem), vPar, nPar, Integrity Virtual Machine, Secure Resource Partitions (tylko z limitem) i Fujitsu PPAR. Do tego Oracle Linux KVM, Oracle VM Server for x86 i Oracle VM Server for SPARC, wyłącznie przy przydzieleniu konkretnych rdzeni według osobnych dokumentów Oracle. Polityka zaznacza, że żadna inna technologia ani konfiguracja się nie kwalifikuje.

Dokument Oracle Software Licensing Basics (aktualizacja z lipca 2024 r.) podsumowuje to tak: dla instalacji lokalnych Oracle nie ma osobnej polityki licencjonowania wirtualizacji, środowiska zwirtualizowane licencjonuje się według definicji metryki.

VMware i Hyper-V

Na VMware liczba vCPU maszyny z bazą nie ma znaczenia dla licencji. Liczą się procesory fizycznych hostów, na których baza jest zainstalowana lub uruchomiona, przeliczone według tabeli core factor (jak to policzyć).

Trudniejsze pytanie brzmi: które hosty? Jeśli maszyna z bazą może migrować po klastrze (vMotion, DRS), może zostać uruchomiona na każdym hoście, do którego da się ją przenieść. Dokumenty Oracle nie wyznaczają tej granicy wprost (klaster, centrum danych, cały vCenter), a polityka mówi tylko, że soft partitioning nie ogranicza licencji „serwera lub klastra serwerów”. Ten punkt warto uzgodnić przed wdrożeniem, a nie dopiero przy audycie. Bezpieczne podejście to postawić bazę na osobnych hostach albo w osobnym klastrze, z którego maszyna nie może wyjść, i licencjonować wszystkie rdzenie tych hostów.

Hyper-V nie ma na liście hard partitioning, więc obowiązuje ta sama zasada co przy VMware.

Proxmox VE

Proxmox działa na KVM, ale to nie jest Oracle Linux KVM. Polityka dopuszcza jako hard partitioning tylko Oracle Linux KVM, a dokument Hard Partitioning with Oracle Linux KVM (lipiec 2024 r.) opisuje przypinanie procesorów w Oracle Linux KVM razem z Oracle Linux Virtualization Manager. Przypięcie vCPU do rdzeni w Proxmoksie nie jest na tej liście, więc licencji nie zmniejsza.

Praktyczny wniosek dla klastra Proxmox: baza na wydzielonym węźle albo w małym osobnym klastrze, licencjonowanym w całości, a reszta maszyn na pozostałych węzłach. Licencji wymagają węzły, na których baza jest zainstalowana lub uruchomiona; jeśli maszyna z bazą może trafić na każdy węzeł (HA, migracja), w praktyce licencjonujesz cały klaster. Jak w Proxmoksie rozplanować węzły i klastry, opisuje wpis o architekturze Proxmox VE w MŚP, a o przenoszeniu maszyn z VMware tekst o pułapkach migracji VMware → Proxmox.

Oracle Linux KVM: kiedy przypięte rdzenie wystarczą

Oracle Linux KVM z Oracle Linux Virtualization Manager pozwala licencjonować tylko rdzenie przypięte do maszyny z bazą, pod warunkami z dokumentu Oracle:

  • vCPU maszyny są przypięte do konkretnych rdzeni albo wątków fizycznych (CPU pinning);
  • przypiętej maszyny z oprogramowaniem Oracle nie wolno migrować na żywo na inny węzeł, a klaster nie może mieć włączonych polityk szeregowania.

Jeśli migracja na żywo przypiętych maszyn jest jednak używana, licencjonowanie według przypiętych rdzeni nie obowiązuje. Licencjonujesz wtedy tyle fizycznych serwerów, ile jest maszyn z oprogramowaniem Oracle, zaczynając od największych, ale nie więcej niż wszystkie serwery klastra. Przykład z dokumentu: klaster 32 serwerów z 20 takimi maszynami wymaga licencji na 20 największych serwerów, a przy 50 maszynach wystarczą licencje na 32 serwery.

Engineered Systems i Trusted Partitions

Na systemach Exadata Database Machine, Private Cloud Appliance, Exalogic i Exalytics Oracle dopuszcza Trusted Partitions. Dwa vCPU liczą się jak jeden rdzeń fizyczny, licencje kupuje się w krokach po dwa rdzenie, a licencjonuje najwyższą liczbę vCPU działających jednocześnie, nie więcej niż wszystkie rdzenie maszyny. Wymagany jest Oracle Enterprise Manager (poza Private Cloud Appliance X9-2 i nowszymi) i włączony Hyper-Threading. Na pozostałych systemach z tej listy minimum to dwa rdzenie, a dla Exadata zasady opisuje osobny podręcznik.

Kontenery i Kubernetes

Według polityki partycjonowania host albo węzeł Kubernetes trzeba licencjonować na wszystkie jego procesory od chwili, gdy pobrano na niego obraz kontenera z programem Oracle. Jeśli węzeł jest maszyną wirtualną, liczbę procesorów ustala się według tej samej polityki, czyli jak przy wirtualizacji powyżej.

Chmura: AWS, Azure, Google Cloud i Oracle Cloud

W chmurach uznanych przez Oracle zasady są prostsze, bo opiera się je na vCPU. Dokument Licensing Oracle Software in the Cloud Computing Environment (stan polityki na 4 września 2026 r.) obejmuje Amazon EC2 i RDS, Microsoft Azure i Google Cloud Platform:

  • dwa vCPU to jedna licencja Processor, jeśli wielowątkowość rdzeni jest włączona, a jeden vCPU to jedna licencja, jeśli wyłączona;
  • tabeli core factor się nie stosuje; liczy się maksymalna liczba vCPU typu instancji;
  • programy ze Standard Edition 2 w nazwie liczy się w gniazdach: instancja do czterech vCPU to jedno gniazdo, większa to jedno gniazdo na każde rozpoczęte cztery vCPU;
  • SE2 wolno licencjonować tylko na instancjach do ośmiu vCPU, a przy NUP minimum to 10 licencji na każde osiem vCPU.

Przykład Oracle: Enterprise Edition na instancji z czterema vCPU w Amazon EC2, z włączoną wielowątkowością, wymaga dwóch licencji Processor.

W Oracle Cloud obowiązuje przelicznik z tabeli core factor: jedna licencja Processor obejmuje dwa OCPU na platformie x86 albo cztery OCPU na Ampere, a dla programów ze Standard Edition w nazwie cztery OCPU.

W chmurze jeden rdzeń z wielowątkowością (dwa vCPU) to cała licencja Processor, a na własnym serwerze Intel albo AMD pół licencji. Chmura wychodzi więc taniej tylko wtedy, gdy instancja jest dużo mniejsza od serwera albo klastra, który trzeba by licencjonować w całości. SE2 jest tam przy tym ograniczona do ośmiu vCPU. Ile kosztuje każda licencja i wsparcie, pokazuje artykuł Ile kosztuje Oracle Database.

Co sprawdzić przed postawieniem bazy w maszynie wirtualnej

  1. Na jakich fizycznych hostach maszyna z bazą może zostać uruchomiona (HA, migracja, DRS) i ile mają rdzeni.
  2. Czy hiperwizor jest na liście hard partitioning Oracle. VMware, Hyper-V i Proxmox nie są.
  3. Czy da się wydzielić bazę na osobne hosty albo osobny klaster, żeby nie licencjonować całej infrastruktury.
  4. Czy taniej nie wyjdzie osobny serwer fizyczny dobrany pod licencję albo instancja w chmurze.
  5. Czy przy mniejszej liczbie licencji Processor nie opłaca się metryka NUP (próg opłacalności).

Przy wirtualizacji pomyłka obejmuje wszystkie rdzenie hostów, a nie kilka vCPU, więc przed zmianą architektury warto ją przeliczyć. Pomoże w tym rozmowa na stronie konsultacji licencji Oracle.

Źródła

Wszystkie dokumenty odczytano 14 października 2026 r.

Tekst opisuje zasady zapisane w dokumentach Oracle. Nie jest poradą prawną ani gwarancją zgodności z umową licencyjną, a Oracle zastrzega zmiany swoich dokumentów bez uprzedzenia.