‘Enorme licentiekosten bij Oracle op VMware?’

‘Oracle telt alle servers bij toepassing van VMware vSphere vanaf versie 5.1’

Diverse bronnen op het internet melden dat Oracle bij audits van licentiegebruik het volgende aangeeft:
bij toepassing van VMware VSphere vanaf versie 5.1 moeten alle CPU’s in alle ESXi hosts in alle clusters – die beheerd worden door dezelfde vCenter Server en/of gebruik maken van dezelfde fysieke storage – worden gelicentiëerd voor Oracle.

Bijvoorbeeld op de Duitse Oracle User Group verscheen een dergelijk bericht. Zie: http://www.doag.org/home/aktuelle-news/article/oracle-aendert-lizenzierung-von-oracle-produkten-unter-vmware-vsphere-ab-version-51.html En ook op de volgende community: https://community.oracle.com/thread/3768425?start=0&tstart=0

Een heldere samenvatting van de situatie kan worden gevonden op de volgende locatie: http://blog.dbi-services.com/all-you-need-to-know-about-oracle-database-licensing-with-vmware/

Het contract

De met u overeengekomen voorwaarden voor het gebruik van aangekochte Oracle licenties zijn over het algemeen vastgelegd in de zogenaamde OLSA (‘Oracle License and Service Agreement’) of OMA (‘Oracle Master Agreement’).
Toepassing van Oracle licenties wordt vaak gemeten aan de hand van het aantal gebruikte processoren voor de Oracle software. In het contract staat gedefinieerd welke processoren dan voor Oracle gelicentiëerd dienen te worden:

‘Processor: shall be defined as all processors where the Oracle Programs are installed and/or running.’

Oftewel alle processoren waar de Oracle software op geïnstalleerd is en/of draait dienen gelicentiëerd te worden.

Helaas laat deze definitie de nodige ruimte voor verschillende interpretaties.

Interpretatie van ‘Processor’ bij toepassing van VMware vSphere

Veel Oracle gebruikers hebben een afzonderlijk cluster gedefinieerd voor de Oracle software. Het doel hiervan is onder andere beperking van de Oracle licentiekosten. Wij als Oracle partner hebben in het verleden een dergelijke architectuur ook geadviseerd. Bij Oracle audits werden de regels ook zodanig uitgelegd dat uitsluitend de processoren van het Oracle cluster gelicentiëerd dienen te worden.

Volgens de eerder genoemde bronnen interpreteert Oracle de regels vanaf VMware vSphere 5.1 anders. Oracle heeft het – voor zover ons bekend – niet aangekondigd (wij hebben in ieder geval geen aankondiging ontvangen, voor zover ons bekend zijn er ook geen klanten van ons of andere Oracle gebruikers of partners die het ontvangen hebben, en wij hebben geen enkele online publicatie van Oracle hierover kunnen vinden).

Als gevolg hiervan adviseren wij al onze klanten om door Oracle te laten bevestigen welke (virtuele en fysieke) servers in hun specifieke situatie en architectuur gelicentieerd dienen te worden nog voordat een nieuwe omgeving wordt gebouwd. Idealiter zou een dergelijke bevestiging zo vroeg mogelijk in de ontwerpfase van nieuw geplande configuraties plaatsvinden; nog voordat daadwerkelijk licenties worden aangeschaft. Maar ook in een later stadium kan het nuttig zijn een uitspraak van Oracle betreffende verschuldigde licenties te krijgen. Dit zou een eventueel ontwerp kunnen bijstellen en goedkoper kunnen maken.

Hier volgt een voorbeeld van hoe wij menen dat Oracle nu licenties interpreteert. De hier weergegeven architectuur wordt veel gebruikt bij toepassing van VMware in combinatie met Oracle. (indien u op het voorbeeld klikt zal deze groot worden weergegeven)

Het rode cluster bestaat uit twee fysieke servers waarop Oracle software draait.

De interpretatie van Oracle in dit voorbeeld is dat de Oracle software is geïnstalleerd op alle processoren van alle in het plaatje weergegeven fysieke servers.
Dus ook op de processoren van het (blauwe) non-Oracle cluster. Alles binnen de rode stippellijnen valt volgens deze interpretatie binnen hetgeen dat voor Oracle gelicentiëerd dient te worden.

Achterliggende gedachte van deze nieuwe interpretatie van Oracle is wellicht dat vSphere versie 5.1 de mogelijkheid biedt om VM’s te verhuizen tussen clusters.

De interpretatie van Oracle is dus dat de Oracle software in dit voorbeeld ook geïnstalleerd is en/of draait op de VM’s van het blauwe cluster.

In veel publicaties op internet worden vraagtekens gezet bij deze interpretatie. Voor zo ver ons bekend is er geen formeel/juridisch uitsluitsel hierover.

Wat kunt u doen?

Heeft u momenteel een VMware vSphere omgeving met een versie vanaf 5.1 en slechts een deel van de processoren gelicentiëerd voor Oracle, dan loopt u het risico in de toekomst door Oracle hierop aangesproken te worden.

Afhankelijk van uw specifieke situatie zijn er diverse mogelijkheden om dit risico te ontlopen.

Een voor de hand liggende mogelijkheid is bijvoorbeeld om de Oracle omgeving niet te vitualiseren, maar bijvoorbeeld een ODA (Oracle Database Appliance) toe te passen.

Een andere mogelijkheid is toepassing van Oracle VM (Oracle Virtual Machine) in plaats van VMware. En bijvoorbeeld om een architectuur zoals hieronder te realiseren. Of als variant hierop kunt u ook niet van alle virtuele machines, maar uitsluitend voor de virtuele machines waarop de Oracle software is geïnstalleerd VMware vervangen door OVM.

Nog een andere mogelijkheid is bijvoorbeeld om een afzonderlijk vCenter in te richten voor de Oracle omgeving, en ook afzonderlijke fysieke storage toe te passen (bijvoorbeeld de lokale opslag van de betreffende server(‘s)). Een dergelijke (strikt gescheiden) architectuur is hieronder weergegeven. Voor zo ver bekend accepteert Oracle namelijk in principe niet dat storage wordt gescheiden door middel van dedicated LUN’s of Vplex-technieken. Het zou dus niet voldoende zijn om een aparte vCenter-configuratie op te zetten waarbij disks uit hetzelfde SAN komen als dat van niet-gelicentieerde servers. Dit is echter in veel situaties nogal een dure en ingrijpende operatie.

Indien u Oracle in combinatie met VMWare wilt (blijven) toepassen adviseren wij u om de specifieke gewenste configuratie door Oracle te laten goedkeuren. U hanteert dan uit het oogpunt van beheersbaarheid en de kosten geen strikt gescheiden omgeving, en legt de architectuur – bij voorkeur vooraf – aan Oracle voor. Zo hebben enkele van onze klanten met succes bij Oracle expliciete toestemming aangevraagd voor licentiëring van alleen de Oracle servers bij storage scheiding door middel van dedicated LUN’s.

Graag zijn wij u van dienst om een op uw specifieke situatie afgestemd advies te geven.
Via onze contactpagina kunt u onze accountmanagers en licentie experts bereiken.