Vanaf 2002 verspreidt Oracle een document met de benaming ‘Oracle Partitioning Policy’. Het document is de afgelopen jaren in diverse versies verschenen. De eerste zin in het document maakt reeds duidelijk dat partitionering met een enkele fysieke server te maken heeft. Oracle maakt hierbij onderscheid tussen hardwarematige partitionering en softwarematige partitionering.
Softwarematige partionering
In het document wordt vervolgens gesteld dat VMware (vSphere) als softwarematige partitionering wordt beschouwd. Vervolgens concludeert Oracle dat VMware niet kan worden gebruikt om het aantal ‘cores’, waarvoor licenties moeten worden aangekocht, te beperken.
Dit betekent dat Oracle softwarematige partitionering niet erkent als middel om het aantal softwarelicenties op een server of een cluster van servers te beperken. Een voor de hand liggende uitzondering hierop vormt echter het eigen product van Oracle: Oracle VM Server (OVM).
Geen contractuele status
Wat opvalt is dat het Oracle Partitioning Policy document geen contractuele status heeft. Er wordt in de Oracle License and Services Agreement (OLSA) niet naar dit document verwezen. Er wordt echter wel degelijk aangegeven dat verwijzingen naar ‘policies’ tot de contractuele voorwaarden behoren.
Sterker nog, in de voetnoot van het document ‘Oracle Partitioning Policies’ staat vermeld:
‘This document is for educational purposes only and provides guidelines regarding Oracle’s policies in effect as of <datum>. It may not be incorporated into any contract and does not constitue a contract or a commitment to any specific terms.’
Is ‘het’ dan zo makkelijk? Nee, het is onzeker hoe zorgvuldig vSphere de scheiding tussen ‘cores’ respecteert tijdens normaal gebruik.
Een voorbeeld: test van House of Brick
Als een twee vCPU werklast is toegewezen aan de cores 2 en 3 op bijvoorbeeld een 16-core server, dan is tijdens het opstarten van VM niet duidelijk of de applicatie tijdelijk op een andere core dan 2 of 3 draait. Zo heeft het bekende Amerikaanse adviesbureau House of Brick een simpel testje uitgevoerd.
Zij probeerden een scheiding tussen cores te configureren zodat er een niet bestaande core 3 werd opgevoerd op een server met twee CPU’s. De user interface weigerde dit omdat core 3 niet bestond. Om die reden werd een .vmx bestand aangepast om zodoende de VM aan core 3 toe te wijzen.
De bedoeling was uiteraard om een situatie te simuleren waarbij een VM aan een niet toegestane of niet bestaande core werd toegewezen, of om een situatie te simuleren waarbij vMotion (een oplossing die het mogelijk maakt virtuele machines ‘live’ te migreren van de ene fysieke server naar de andere, zonder down time) op een server wordt toegepast die niet dezelfde core beschikbaar heeft als op de ‘bron’ server.
Bij het opstarten van de VM startte deze zonder belemmeringen in relatie tot de core scheiding. De log files lieten zien dat de VM opkwam op CPU 0, zonder enige waarschuwing of andere boodschap.
Heeft Oracle dan een punt?
In een zaak die repenfabrikant Mars in de VS tegen Oracle aanspande, dreigde Oracle de licentieovereenkomst met Mars te beëindigen. Volgens Oracle hield Mars zich niet aan de licentievoorwaarden door niet voor alle CPU’s in de VMware-omgeving te betalen. Hieraan voorafgaand had Oracle Mars verzocht uit te leggen op welke wijze zij Oracle in een VMware-omgeving inzette.
In de zaak die Mars vervolgens tegen Oracle aanspande ter voorkoming van de contractbeëindiging, claimde Mars dat zij Oracle alle benodigde informatie had gegeven om het gebruik van Oracle in hun VMware omgeving te bepalen. Oracle verlangde echter detailinformatie over alle clusters in de complete VMware omgeving waaruit zou blijken welke clusters aan Oracle zouden zijn toegewezen.
Mars maakte hier bezwaar tegen door aan te tonen dat zij uitgebreide technische controlemiddelen en beperkingen in de VMware-omgeving heeft aangebracht. Hiermee zou de migratie van VM’s met Oracle uit hun cluster worden voorkomen zodat deze niet in andere delen van de VMware-omgeving kan uitvloeien.
De zaak tussen Mars en Oracle is uiteindelijk geschikt.
Wat betekent dit?
Het is zaak dat een gebruiker van VMware aantoonbaar maakt dat hij afdoende technische en organisatorische maatregelen heeft getroffen ter voorkoming van ongewenste migratie van VM’s met Oracle naar andere clusters in de VMware-omgeving.
In feite toont een gebruiker daarmee aan dat het gebruik zich daadwerkelijk beperkt tot de ‘geregistreerde’ clusters. Dit weegt zwaarder dan het ‘testje’ dat hierboven is beschreven. Het testje maakt namelijk duidelijk dat het om zeer tijdelijk en onbedoeld gebruik gaat (waarmee geen ‘exploitatierecht’ van een rechthebbende wordt geschonden).
In geval van outsourcing
De geschetste problematiek doet zich evenzeer voor in de gevallen waarin organisaties tot outsourcing overgaan. Deze opdrachtgevers worden achteraf nogal eens geconfronteerd met onvoorziene kosten omdat leveranciers van datacenter-functionaliteit tegen dezelfde (onvoorziene) problemen aanlopen.
Het probleem is echter dat bij datacenters de schaalgrootte nogal afwijkt ten opzichte van de organisaties die tot uitbesteding overgaan. Zo kan het gebeuren dat kleinere gemeenten ineens worden geconfronteerd met grootschalige kosten. Hierbij realiseert het datacenter zich pas achteraf dat deze extra kosten eigenlijk al hadden moeten worden mee-begroot bij het offreren van de dienst.
Datacenters zijn enerzijds onvoldoende op de hoogte van hun rechten in relatie tot Oracle maar anderzijds is het zeer onredelijk, zo niet ongepast, om opdrachtgevers pas achteraf met deze extra kosten te confronteren.
Meer weten?
Bent u op zoek naar advies over softwarematige partitionering? Imtio helpt je graag verder. neem contact op via het contactformulier of mail naar info@emtio.nl.
