BYOL-Fallen vermeiden So lizenzieren Sie Oracle in der Cloud richtig

Quelle: Pressemitteilung 2 min Lesedauer

Anbieter zum Thema

Oracle-Datenbanken in die Public Cloud zu migrieren, klingt nach einem einfachen Wechsel des Betriebsmodells – doch beim Bring Your Own License können sich die Lizenzkosten deutlich erhöhen. Wer aber BYOL falsch aufsetzt, zahlt doppelt. Prolicense erklärt, wie sich die Lizenzrechnung belastbar aufsetzen lässt.

Bei BYOL in der Cloud können Lizenzfallen im Hintergrund lauern. Die Unterschiede zwischen den Cloud-Modellen, die aktuelle Cloud-Policy und mögliche Doppel- oder Fehllizenzierungen sollten daher bereits vor der Migration geprüft werden, um hohe Nachzahlungen und unnötige Kosten zu vermeiden. (Bild: ©  brillianata - stock.adobe.com)
Bei BYOL in der Cloud können Lizenzfallen im Hintergrund lauern. Die Unterschiede zwischen den Cloud-Modellen, die aktuelle Cloud-Policy und mögliche Doppel- oder Fehllizenzierungen sollten daher bereits vor der Migration geprüft werden, um hohe Nachzahlungen und unnötige Kosten zu vermeiden.
(Bild: © brillianata - stock.adobe.com)

Oracle-Datenbanken wandern in die Public Cloud, meist per Bring Your Own License (BYOL). Der Gedanke ist einfach: vorhandene Lizenzen mitnehmen und nur noch Rechenzeit zahlen. In der Praxis lauern hier eigene Fallen, denn Oracle bewertet die Cloud-Lizenzierung anders als das eigene Rechenzentrum.

Wie Oracle Cloud-Cores zählt

AWS, Azure und Google Cloud gelten als Authorized Cloud Environments. Dort wendet Oracle nicht die vertraute Prozessor-Kernfaktor-Tabelle an, sondern zählt nach virtuellen CPUs. Bei aktivem Hyperthreading werden zwei vCPUs als eine Prozessorlizenz gewertet, ohne Hyperthreading zählt eine vCPU als eine Lizenz. Weil der Core-Faktor von 0,5 für x86 in der Cloud wegfällt, verdoppelt sich der Lizenzbedarf für dieselbe Hardware schnell gegenüber dem eigenen Rechenzentrum. Wichtig zu wissen: Zu lizenzieren ist die maximale vCPU-Zahl der Instanz, das Abschalten einzelner vCPUs senkt den Bedarf nicht.

OCI behandelt Oracle günstiger

Oracles eigene Cloud, OCI, fällt nicht unter diese Policy, sondern ist vertraglich über die Servicebeschreibung geregelt. Und sie ist bewusst günstiger gestellt. In OCI deckt eine Lizenz zwei OCPUs ab, was rund vier vCPUs an Rechenleistung entspricht. Dieselbe Last braucht damit in OCI etwa halb so viele Lizenzen wie in AWS oder Azure. Dazu kommen Support Rewards, also Gutschriften auf die Supportkosten. Das ist kein Zufall, sondern Oracles Anreiz, Kunden in die eigene Cloud zu ziehen. Wer bei AWS oder Azure bleibt, muss diesen Unterschied in der Rechnung berücksichtigen.

„In der Cloud verschwindet der Core-Faktor, und plötzlich braucht dieselbe Datenbank doppelt so viele Lizenzen wie im eigenen Haus. In OCI sieht die Rechnung ganz anders aus. Das ist Oracles Anreiz, und man muss ihn kennen, bevor man migriert, nicht danach“, sagt Markus Oberg, Partner der Prolicense.

Policy ist nicht gleichbedeutend mit Vertrag

In AWS und Azure entfällt der Core-Faktor, der Bedarf steigt, und OCI ist bewusst günstiger gestellt.(Bild:  Prolicense GmbH)
In AWS und Azure entfällt der Core-Faktor, der Bedarf steigt, und OCI ist bewusst günstiger gestellt.
(Bild: Prolicense GmbH)

Wie bei der Virtualisierung im eigenen Haus gilt auch in der Cloud: Die Zählregeln stehen in Oracles Cloud-Policy, einem Positionspapier, das Oracle jederzeit ändern kann. Vertraglich bindend sind nur der Rahmenvertrag und das Bestelldokument. Deshalb sollte die zum Zeitpunkt der Migration geltende Fassung der Policy festgehalten und jede Instanz dagegen dokumentiert werden. Wer die Oracle-Lizenzierung in der Cloud sauber gegen den Vertrag hält, hat im Streitfall die besseren Argumente.

Die häufigsten BYOL-Fallen

„Die Cloud-Policy ist kein Gesetz und kein Vertrag, sie ist Oracles Position. Wer sie kennt und die geltende Fassung dokumentiert, kann überzogene Nachforderungen abwehren. Der teuerste Fehler ist, ohne Lizenzrechnung in die Cloud zu gehen“, betont Sören Reimers, Rechtsanwalt und Geschäftsführer der Prolicense.

Die Erfahrung zeig: Immer wieder sind es dieselben Fehler. Die Doppellizenzierung, wenn Support im eigenen Haus und in der Cloud parallel läuft. Die falsche Anrechnung, wenn Hyperthreading und die maximale vCPU-Zahl nicht sauber berücksichtigt werden. Optionen und Packs, die in der Cloud unbemerkt mitgezählt werden. Die unklare Trennung von Nicht-Produktion, die eigentlich anders zu behandeln wäre. Und die Annahme, die Cloud-Policy sei bindend, obwohl sie es nicht ist. Jeder dieser Punkte kann im Audit teuer werden.

(ID:50964084)

Jetzt Newsletter abonnieren

Täglich die wichtigsten Infos zu Cloud Computing

Mit Klick auf „Newsletter abonnieren“ erkläre ich mich mit der Verarbeitung und Nutzung meiner Daten gemäß Einwilligungserklärung (bitte aufklappen für Details) einverstanden und akzeptiere die Nutzungsbedingungen. Weitere Informationen finde ich in unserer Datenschutzerklärung. Die Einwilligungserklärung bezieht sich u. a. auf die Zusendung von redaktionellen Newslettern per E-Mail und auf den Datenabgleich zu Marketingzwecken mit ausgewählten Werbepartnern (z. B. LinkedIn, Google, Meta).

Aufklappen für Details zu Ihrer Einwilligung