Oracle en VMWare, afscheid nemen van Oracle?

[johntyrrell]

Beste Tweakers,

Afgelopen maand hebben we een nieuwe VMWare Infrastructure 3 omgeving neergezet.
Hierop willen we uiteraard alle servers zetten die hardwarematig uit of bijna uit de garantie zijn gelopen.

Nu werd ik door een externe leverancier gewezen op het feit dat Oracle een aparte manier van licenties hanteerd bij virtuele servers.
Op dit moment hebben we 2x een 1 CPU licentie van Oracle. Voor ons volop voldoende om vooruit te kunnen.
Als we deze op onze VI3 omgeving willen plaatsen, dan moeten we 50% van de cores licenseren. We hebben 40 cores, dat betekend dus 20 licenties... kort gezegd kost ons dit 10X zoveel

Nu hebben we hier contact over gehad met Oracle en die bevestigen deze berekening...
Hoe kunnen ze dit nou in hemelsnaam blijven volhouden??
Wij gaan de komende tijd hard denken om Oracle er helemaal uit te gooien en over te gaan op een alternatief.
Zijn wij nou de enige die dit absoluut absurd vinden? Wat zouden jullie doen?

Groeten,
John

[MAX3400]

Licentie is licentie... En als Oracle (desnoods via een zwart-op-wit brief) jullie inderdaad verzekerd dat je 20 licenties moet gaan aanschaffen, so be it.

Tja, je kan natuurlijk ook bedenken; screw it maar en we kopen minder licenties en zien wel hoe we het draaiend houden; betekent wel dat enige vorm van support natuurlijk verdwijnt, gok ik zo.

/edit
Hoe kan het nou dat je voorheen 2 CPU-licenties had (2 fysieke servers??) en nu ineens 20 CPU-licenties moet kopen?

[ Voor 15% gewijzigd door MAX3400 op 06-02-2009 17:08 ]

[Flappie]

Ik snap het niet helemaal. Als je je Oracle server in een aparte virtuele machine laat draaien met 1 of 2 cores heb je toch maar 1 of 2 licenties nodig?

[MAX3400]

Ah, ik ben erachter... Omdat Oracle vindt dat een fysieke CPU (van een ESX-node) niet dedicated aan een VM gehangen kan worden, is het dus onduidelijk welke fysieke CPU zorgt voor de aansturing van een virtuele CPU.

Je moet dus elke fysieke CPU in je ESX-omgeving licenseren voor Oracle.

/edit
Hier een PDF van Oracle; hopelijk kan je hiermee iets op je ESX-nodes om het aantal fysieke CPU's voor je VM's te beperken en dus ook je licenties binnen de perken te houden.

[ Voor 31% gewijzigd door MAX3400 op 06-02-2009 17:13 ]

[johntyrrell]

Onze virtuele omgeving bestaat uit 5 servers met ieder 2 quadcore processors. Met high availability aan betekend het dat de Oracle server die op de virtuele omgeving draait op iedere core zou kunnen draaien en Oracle vind dat dan 50% van de cores gelicenceerd moeten zijn...

Nu kunnen we uiteraard een aparte virtuele server in gaan richten met 2 cores en daar Oracle op draaien, maar dat is wederom een uitzondering. Als we genoeg processor kracht en geheugen in onze VI3 omgeving hebben, waarom zou ik dan weer een aparte server er naast willen hebben.

Natuurlijk gaan we niet illegaal draaien, dat is niet te verantwoorden. Maar ik kan me zo voorstellen dat Oracle op deze manier HEEL veel klaten gaat verliezen...niet??

[MAX3400]

johntyrrell schreef op vrijdag 06 februari 2009 @ 17:16:...Als we genoeg processor kracht en geheugen in onze VI3 omgeving hebben, waarom zou ik dan weer een aparte server er naast willen hebben...

Ik snap je gedachtengang heel goed, maar eigenlijk zeg je in deze zin dat je je VM's enigszins unmanaged op je VM-nodes neerzet omdat je je sizing niet af hebt (als in, je hebt het over genoeg CPU-power ipv "2 fysieke CPU's kunnen onze Oracle-VM's draaiend houden"). Dat is natuurlijk de schaalbaarheid van VMWare maar meteen het nadeel voor je Oracle-licenties

Natuurlijk gaan we niet illegaal draaien, dat is niet te verantwoorden. Maar ik kan me zo voorstellen dat Oracle op deze manier HEEL veel klaten gaat verliezen...niet??

Nope, ze zijn zelf aan het virtualiseren en willen dus nog meer afhankelijkheid verkopen.

[ Voor 5% gewijzigd door MAX3400 op 06-02-2009 17:20 ]

[SpamLame]

johntyrrell schreef op vrijdag 06 februari 2009 @ 17:16:


Natuurlijk gaan we niet illegaal draaien, dat is niet te verantwoorden. Maar ik kan me zo voorstellen dat Oracle op deze manier HEEL veel klaten gaat verliezen...niet??

Overstappen naar een ander kan niet altijd en waar het wel kan zit je met opleidingen (van beheerders en ontwikkelaars), migratie trajecten, pakket keuze traject etc etc.
Voordat je dan helemaal om bent heb je ook al de nodige (extra) kosten gemaakt.

In een kosten/baten analyse (of business case) zou je als resultaat kunnen krijgen,

1. virtualiseren op je favo platform,
2. dedicated hardware gebruiken,
3. overgaan op ander pakket.

[johntyrrell]

Als we Oracle gaan beperken op 2 CPU's, dan betekend het dat als die server uitvalt dat de Oracle server niet op een andere server opgestart kan worden, omdat deze niet gelicenceerd zijn. Dus weg high availability! We zouden dan onze VI3 omgeving moeten verkleinen om Oracle te kunnen draaien op een VMWare node die niet mee "mag" doen in de cluster.

Dit is toch van de zotte! Ik snap niet dat er niet veel meer mensen een klacht hierover neerleggen bij Oracle...toch?

[johntyrrell]

SpamLame schreef op vrijdag 06 februari 2009 @ 17:25:
[...]
Overstappen naar een ander kan niet altijd en waar het wel kan zit je met opleidingen (van beheerders en ontwikkelaars), migratie trajecten, pakket keuze traject etc etc.
Voordat je dan helemaal om bent heb je ook al de nodige (extra) kosten gemaakt.

Maar het wordt wel meer en meer een principe kwestie... Van mij mag Oracle elke maand langs komen om te controleren of onze Oracle servers niet op meer dan 2 vCPU's draaien hoor.

[pven]

Voor zover ik heb begrepen, licenseer je bij Oracle alleen de CPU's die daadwerkelijk door je virtual machines worden gebruikt (dit kan je afdwingen op je global zone).

Ik weet niet of je op metalink kunt, maar als je in docid 317257.1 (Running Oracle Database in Solaris 10 Containers - Best Practices) kijkt dan vindt je het onderstaande:

Oracle now recognizes capped Solaris 10 Containers as licensable entities, known as hard partitions. Oracle licensing policy defines hard partitioning as �a physical subset of a server that acts like a self-contained server". Oracle customers running Oracle in a Solaris 10 environment can now license only the CPUs or cores that are in a capped Solaris Container as discussed below.

To create a Solaris 10 Container that fits the licensing requirements set by Oracle, the Solaris system administrator needs to create a Resource Pool with the desired number of CPUs or cores and bind a Solaris Zone to this Resource Pool. The license is driven by the number of CPUs or cores in this Pool.

[johntyrrell]

pven schreef op vrijdag 06 februari 2009 @ 17:33:
Voor zover ik heb begrepen, licenseer je bij Oracle alleen de CPU's die daadwerkelijk door je virtual machines worden gebruikt (dit kan je afdwingen op je global zone).

Ik weet niet of je op metalink kunt, maar als je in docid 317257.1 (Running Oracle Database in Solaris 10 Containers - Best Practices) kijkt dan vindt je het onderstaande:

[...]

Helaas heeft Oracle ervoor gekozen om Solaris als hard partitioning te zien en VMWare als soft partitioning. Komt ze wel zo goed uit qua inkomsten..

[MAX3400]

johntyrrell schreef op vrijdag 06 februari 2009 @ 17:40:
[...]


Helaas heeft Oracle ervoor gekozen om Solaris als hard partitioning te zien en VMWare als soft partitioning. Komt ze wel zo goed uit qua inkomsten..

Stemmingmakerij? Misschien dat er in VMWare net een vinkje anders staat (al dan niet ergens hardcoded of hoe je het ook noemen wil) waardoor ze het beschouwen als soft-partitioning. Trouwens, hetzelfde zou dan gelden voor Microsoft Hyper-V waar ook bepaalde/andere licenties nodig zijn voor je VM's afhankelijk van je host-OS. Oracle doet dus niks vreemd in de markt...

[johntyrrell]

Hyper-V is geen vergelijking. Hyper-V heeft geen VMotion alternatief. Je zou dan dus alleen licenties kopen voor de server waarop Oracle draait en niet alle 5 de fysieke machines.

Stemmingmakerij... ik vind het gewoon asociaal van Oracle om dit te blijven hanteren in deze virtualisatie tijd. Daar moet toch iets tegen te doen zijn?

[MAX3400]

johntyrrell schreef op vrijdag 06 februari 2009 @ 17:48:
Hyper-V is geen vergelijking. Hyper-V heeft geen VMotion alternatief. Je zou dan dus alleen licenties kopen voor de server waarop Oracle draait en niet alle 5 de fysieke machines.

Je leest blijkbaar alleen wat je wil lezen. Niet erg maar reageer dan op je eigen interpretatie. Je hebt gelijk dat Hyper-V nog geen Live Migration heeft maar dat houdt niet in dat ik een VM kan "migreren" naar een host met meer CPU's en/of RAM.

Stemmingmakerij... ik vind het gewoon asociaal van Oracle om dit te blijven hanteren in deze virtualisatie tijd. Daar moet toch iets tegen te doen zijn?

Zolang jij bijna elke post met een vraagteken eindigt, is het stemmingmakerij want je zoekt medestanders. Het heeft meer zin om jouw hoogste baas met iemand van Oracle te laten bellen dan dat je hier op GoT iets gaat posten want daardoor verandert de situatie de komende 50 jaar toch niet.

[leuk_he]

De licentie van oracle past dus niet op virtualisatie van vm.

Dan ga je oracle toch gewoon lekker niet virtualiseren. Met het uitsparen van van de oracle licentie voor 40 licenties kun je best een server bijkopen.

Virtualisatie is een middel om kosten te besparen. Als je dat niet bereikt moet je niet vergeten dat virtualisatie een middel is en geen doel.

Verder vermoed ik dat oracle liever zijn eigen HA (oracle RAC, ook prijzig) producten verkoopt dan op anderen vertrouwd om op lager nivo HA te bereiken.

[seq_uence]

leuk_he schreef op vrijdag 06 februari 2009 @ 18:06:
De licentie van oracle past dus niet op virtualisatie van vm.

Dan ga je oracle toch gewoon lekker niet virtualiseren. Met het uitsparen van van de oracle licentie voor 40 licenties kun je best een server bijkopen.

Virtualisatie is een middel om kosten te besparen. Als je dat niet bereikt moet je niet vergeten dat virtualisatie een middel is en geen doel.

Verder vermoed ik dat oracle liever zijn eigen HA (oracle RAC, ook prijzig) producten verkoopt dan op anderen vertrouwd om op lager nivo HA te bereiken.

Virtualisatie is ook een middel om een beter schaalbare omgeving in te richten en eenvoudiger uit te kunnen wijken in geval van een calamiteit. Overigens heb ik dezelfde discussie met Oracle gehad, het licentiemodel lijkt gewoon nergens op. En zeker het MKB gaat nu een andere keuze maken.
Dat Oracle de marketing zo opzet dat de eigen virtualisatie oplossing aantrekkelijk is lijkt me logisch.

Het huidige licentiebeleid zorgt er echter voor dat kleine bedrijven (die toch al snel een Vmware omgeving van een aantal nodes hebben draaien) hoge kosten moeten maken.

[MAX3400]

seq_uence schreef op vrijdag 06 februari 2009 @ 21:00:
[...]
Virtualisatie is ook een middel om een beter schaalbare omgeving in te richten en eenvoudiger uit te kunnen wijken in geval van een calamiteit.

Virtualisatie is niet per definitie een excuus om beter schaalbaar te zijn. Een omgeving zoals een x aantal Oracle-servers is redelijk statisch en voorspelbaar (qua grootte en performance). Linksom of rechtsom moet je toch je hosts sizen op maximale belasting van een Oracle-bak en als je die sizing inzichtelijk hebt, kan je 1+1 bij elkaar optellen om te bedenken of virtualisatie (en dus x CPU-licenties) goedkoper is dan fysieke machines.

Ook uitwijk vind ik geen reden voor virtualisatie. Ja, leuk, door VMotion kan je je VM's elders snel opstarten mits de shared storage van de ESX-nodes ook kan worden gerepliceerd naar je uitwijk-centrum. Betekent dus dat je een relatief mooi dik lijntje moet hebben liggen; maak er dan een active-active ESX-cluster van met aan beide zijden minder shared storage en maak een goede analyse over kosten vs. performance.

Maar ja, allemaal langs de lijn gelul; topicstarter is blijkbaar niet bij machte om voldoende financien of politieke druk te verzamelen om daadwerkelijk Oracle eens aan te vliegen en te sturen naar een voordeliger model; ik snap het topic dan ook niet zo goed omdat het licentie-model al ongeveer anderhalf jaar zo in elkaar steekt. Dat had je dus aan moeten kunnen zien komen op het moment dat je (vorige maand) een VMI3-omgeving neerzet in je bedrijf.

[F_J_K]

Niet iedereen verwacht op-kortetermijnwinstmaximalisatie-gerichte licentiemodellen en de TS heeft blijkbaar meer draaien dan Oracle dozen

Bij genoeg geld kan er meestal wel gepraat worden, maar dat is voor 2 CPU-licenties niet echt aan de orde waarschijnlijk. Als klein klantje heb je maar te slikken wat de grote leverancier aanbiedt. (Wat soms overigens helemaal terecht is, imho). Maar ik heb me ook wel eens aan een dergelijk model model lopen te storen en dat zullen wel meer mensen/klanten hebben.

Als je als klant niet van je leverancier kan krijgen wat je wilt en naar een ander stappen is een optie, is het tijd om een nieuwe leverancier te overwegen (en afhankelijk van prijs, kwaliteit, etc indien nodig over te stappen).

Oracle verkoopt meer dan DB's, maar ik neem aan dat het om de DB gaat? Dan: zitten de applicatie(s) overdreven (bijv door gebruik van plsql) vast aan de DB? Zo ja heeft naar een alternatief kijken weinig zin zonder nieuwe applicaties te kopen. Uiteindelijk gaat het er inderdaad om hoeveel het kost & wat het doet. De hardware is blijkbaar al afgeschreven; hoelang moet de software nog mee, is het de moeite nog wel waard en kan je de Oracle dozen niet af laten sterven?

[leuk_he]

seq_uence schreef op vrijdag 06 februari 2009 @ 21:00:
Virtualisatie is ook een middel om een beter schaalbare omgeving in te richten en eenvoudiger uit te kunnen wijken in geval van een calamiteit. Overigens heb ik dezelfde discussie met Oracle gehad, het licentiemodel lijkt gewoon nergens op. En zeker het MKB gaat nu een andere keuze maken.

Als je maximale performance wil met oracle dan ga je niet de machines virtualiseren. Je hebt zelf al vastgesteld dat nodes/cpu bijschalen bij oracle je veel oracle licenties kost.

verder sluit ik me aan bij max3400 over uitwijk. Overigens kun je dan met de oracle HA cluster opties een del van je db op de remote locatie draaien. Draai je voor het zelfde geld 2 draaiende nodes ipv een hotstandby die enkel aan het repliceren is.

/* leukhe wil graag eens een migratie van oracle naar een andere echte open source db proberen, maar heeft nog geen klant gevonden die zijn uurtarief daarvoor de de moeite waard vind. */

[seq_uence]

leuk_he schreef op zaterdag 07 februari 2009 @ 00:00:
[...]


Als je maximale performance wil met oracle dan ga je niet de machines virtualiseren. Je hebt zelf al vastgesteld dat nodes/cpu bijschalen bij oracle je veel oracle licenties kost.

verder sluit ik me aan bij max3400 over uitwijk. Overigens kun je dan met de oracle HA cluster opties een del van je db op de remote locatie draaien. Draai je voor het zelfde geld 2 draaiende nodes ipv een hotstandby die enkel aan het repliceren is.

/* leukhe wil graag eens een migratie van oracle naar een andere echte open source db proberen, maar heeft nog geen klant gevonden die zijn uurtarief daarvoor de de moeite waard vind. */

Wanneer je gaat virtualiseren probeer je alle fysieke servers te consolideren, dus ook een Oracle server. Je wil immers dit platform zoveel mogelijk benutten. Afhankelijk van de load op die db kan dit goed gevirtualiseerd worden.

Een uitwijk van je totale omgeving omvat meer dan alleen Oracle, de discussie gaat echter steeds over Oracle alsof er niet nog een heel serverpark staat.

Een migratie proberen zeg je ? Ik kan me voorstellen dat een klant best iets wil proberen maar om daar dan ook gelijk voor de betalen. Laat een leverancier eens over de brug komen als deze zo nodig een open source oplossing wil implementeren.

[leuk_he]

seq_uence schreef op zaterdag 07 februari 2009 @ 19:29:
[...]
Wanneer je gaat virtualiseren probeer je alle fysieke servers te consolideren, dus ook een Oracle server. Je wil immers dit platform zoveel mogelijk benutten. Afhankelijk van de load op die db kan dit goed gevirtualiseerd worden.

Je haalt doel en middelen hier door elkaar. Meer kan ik hier niet over zeggen zonder je woorden in de mond te leggen.

Een migratie proberen zeg je ? Ik kan me voorstellen dat een klant best iets wil proberen maar om daar dan ook gelijk voor de betalen. Laat een leverancier eens over de brug komen als deze zo nodig een open source oplossing wil implementeren.

Je slaat de spijker precies op zijn kop. Wie gaat dat betalen. (soete lieve gerritje)