Alles neu macht der Ma … Januar’23, Teil 2: Oracle Java

Update1, 26.01.2023 – siehe ganz unten
Update2, 30.01.2023 – siehe noch weiter unten ;o)

So, und nun zu etwas für die meisten Oracle Java Kunden vermutlich sehr Hässlichem: Die Änderungen der Oracle Java Subsktiptionierung.

Hierzu einige wichtige Vorbemerkungen:
Der Konsum einer größeren Tasse Baldriantees oder eines anderen Beruhigungsmittels vor dem Lesen dieses Artikels ist angeraten.
Und wie immer gilt: Don’t shoot the Messenger. Ich kann nix dafür. Ich möchte nur informieren!

Aaaaaalso, nachdem ich Oracle im vorherigen Beitrag fast schon ein wenig gelobt habe, weil Änderungen bekannt gegeben wurden, die zum Vorteil des Kunden waren, dürften diese Änderungen für die meisten betroffenen Kunden zu deutlichen Verteuerungen der Oracle-Java Nutzung führen.

Wir erinnern uns, dass ab 2018 bestimmte Oracle Java Versionen nur noch kostenfrei waren für die
– persönliche (private) Nutzung,
– Entwicklung, Test und Demo,
– die Nutzung im Zusammmenhang mit einem Oracle-Produkt
– oder die Nutzung für die OCI-Cloud.
Andere Nutzungen, vor Allem produktive Nutzung in Unternehmen, benötigen die Oracle Java SE Subscription, die per „Named User Plus“ für die Desktop- und per „Prozessor“ für die Server-Nutzung erhältlich war.
Wen’s interessiert: hier die damaligen Infos in meinem Blog:
https://mpaege.wordpress.com/2019/04/16/oraclejdk-8-updates-bei-kosten-und-damit-supportfreien-oracle-produkten/
https://mpaege.wordpress.com/2019/04/30/java-was-aendert-sich/
https://mpaege.wordpress.com/2019/06/28/aktuelle-situation-zu-oracle-java-se/
Beide Metriken waren bei Kunden nicht sonderlich beliebt, da vor allem die NUP-Metrik nicht die installiertenm Geräte abbildet, sondern alle berechtigten Personen gezählt werden müssen, was aufwändig ist, insbesondere bei Geräten, die von mehreren Personen genutzt werden. Bei der Prozessormetrik musste entsprechend der Regeln der Lizenzierung der Oracle DB EE gezählt werden – inkl. der Probleme der Lizenzierung beim Einsatz von Virtualisierungssoftware.

Im September 2021 hatte Oracle dann verkündet, dass die Version 17 des Oracle JDK nun unter einer No-Fee-License veröffentlicht wird. Also generell kostenfreie Nutzung dieser Version und aller Patches die in den 2 Jahren bis zur Veröffenbtlichung der nächsten LongTermSupport-Version (das wäre dann Oracle Java Version 21, ab Oktober 2023) rauskommen plus weitere 12 Monate. Patches, die nach Oktober 2024 für Oracle Java Version 17 erscheinen, benötigen dann wieder eine Subscription. Allerdings könnte man auch auf das dannkostenfreie Oracle Java 21 gewechselt haben.

Klingt doch gut. Warum dann den Baldrian-Tee?

Erstens: die Behäbigkeit des Marktes. Viele Kunden können und/oder wollen nicht auf diese neue kostenfreie Version migrieren. Andere Projekte waren wichtiger, es gab Corona, Ukraine-Krieg etcpp. Man nutzt also immer noch irgendwelche alten Versionen, aus Sicherheitsgründen dann aber immerhin mit aktuellen Patches (ergo, kostenpflichtig, wenn Oracle-Java). Weil man nicht alles auf ein kostenfreies Java anderer Distributoren migrieren konnte, werden die verbliebenen wenigen kostenpflichtigen Oracle Java Versionen dann subskriptioniert. Und hier kommt jetzt die Änderung von Oracle – zur Vereinfachung der Oracle Java SE Subskriptionierung:

Für die Oracle „Java SE Universal Subscription“ (so lautet der neue Name der Subscription) wurden die Metriken „Named User Plus“ und „Prozessor“ durch die Metrik „Employee“ ersetzt!

Ist doch super, weil einfach.

Naja, einfach ist das tatsächlich. Wobei dann auch nicht ganz so einfach, wie man meint, denn als Employee nach der Oracle-Definition für die Oracle Java SE gelten:
– alle Vollzeit-, Teilzeit- und Zeitarbeitskräfte, und zwar unabhängig davon, ob diese Oracle Java nutzen
– alle Vollzeit-, Teilzeit- und Zeitarbeitskräfte Ihre Vertreter, Auftragnehmer, Outsourcer, Berater und Leiharbeiter, die Ihre internen Geschäftsabläufe unterstützen
Um das Prozessorzählen kommt man aber trotzdem nicht ganz rum, denn wenn das kostenpflichtige Oracle Java dann noch auf mehr als 50.000 Prozessoren (Servern, Desktops, Laptops, VDI, …) läuft, braucht man noch eine zusätzliche Lizenz. Welche konkret, ist noch unklar.

Screenshot der Definition“Employee for Java SE Universal Subscription“ aus dem Dokument „Oracle License Definitions and Rules Booklet“ vom 11.12.2022:

Tja, und das bedeutet ab jetzt vor allem für Unternehmen mit höherer Mitarbeiterzahl hohe Subskriptionskosten für Oracle Java SE. Denn es hilft nun auch nicht, das Allermeiste auf ein Open-Java migriert zu haben und nur in unbedingt notwendigen Fällen kostenpflichtiges Oracle Java zu nutzen, denn selbst bei nur einer produktiv genutzten kostenpflichtigen Oracle Java Installation wären für alle Mitarbeiter des Unternehmens und Externe, die für das Unternehmen arbeiten, eine Subskription abzuschließen.

Wie bisher schon, gibt es auch hier wieder Staffelpreise, die von 180 Dollar pro Jahr und Employee (bei 1 – 999 Employees) bis zu 60 Dollar pro Jahr und Employee (bei 40.000 – 49.999 Employees) liegen. Achtung: in der Preisliste sind – ebenfalls wie bisher – Monatspreise angegeben, obwohl man nur 12-Monats-Subskriptions abschließen kann.

Ein Unternehmen mit 45.000 Mitarbeitern müsste also 45.000*63$ = 2.835.000,–$ pro Jahr für die kokstenpflichtigen Oracle Java Installationen bezahlen. Selbst wenn es nur 1, 10 oder 100 wären.
Und Rabatte werden bei Java nur in sehr begrenztem Maße gegeben, denn es gibt ja die Staffelpreise.

Achja, was mir dazu noch einfällt: Seit ca. Sommer 2022 auditiert Oracle die Kunden in Deutschland auch bzgl. des Einsatzes der kostenpflichtigen Oracle Java Versionen.

So, und jetzt noch weiteren nen Baldriantee. Oder? ;o)

Aber um das Ganze nicht so traurig enden zu lassen: Wie man sich leicht vorstellen kann, ist spätestens jetzt unter Beachtung der Tatsache, dass Audits stattfinden UND es im Zweifelsfalle seeeehr teuer werden kann, die Detection kostenpflichtiger Oracle Java Versionen von entscheidender Bedeutung. Hier können wir (OPITZ CONSULTING, meine Kollegen und ich) Sie toolgestützt bei der Entdeckung von kostenpflichtigem Java unterstützen. Und natürlich auch bei den Überlegungen und Maßnahmen danach.

Update 1, 26.01.2023:
Heute habe ich von Oracle hierzu folgende Informationen erhalten:
1. Renewals mit den bestehenden Metriken seien möglich: „Existing customers with ACCURATE NUPs and Procs Java SE Subscription(s) can continue to renew under existing metrics OR move to Employee Metric Model„. Die bisherigen Produkte und Metriken „Java SE Desktop Subscription“ mit „Named User Plus“ sowie „Java SE Sebscription“ mit „Prozessor“ können bei Bedarf mit entsprechendem Approval noch verwendet werden.

Update 2, 30.01.2023:
Mittlerweile hat Oracle eine FAQ-Liste zu dem Thema „Java SE Universal Subscription veröffentlicht.

Werbung
Veröffentlicht unter OPITZ CONSULTING, Oracle-Lizenzierung | Verschlagwortet mit , , , , | Kommentar hinterlassen

Alles neu macht der Ma … Januar’23, Teil 1: Oracle Linux

Gestern, am 23.01.2023, hat Oracle seine Lizenzierungsmetrik für die Linux Subscriptions geändert. Und es wurde bei den Linux-Produkten aufgeräumt:

Oracle Linux Network stand ja schon länger auf „controlled availability“ und wurde jetzt von der Preisliste entfernt.
Oracle Linux Basic Limited wurde entfernt.
Oracle Linux Premier Limited wurde entfernt.
Es verbleiben als „nur“ noch Oracle Linux Basic und Oracle Linux Premier, allerdings mit den Preisen der ehemaligen Limited-Subscriptionen.

Dafür wurde die Metrik für die Subscriptions von „System“, also pro ‚Blech-Server‘ auf „CPU Pair“ geändert. Es werden jetzt also CPU Pairs gezählt und subskriptioniert.Wobei ein CPU Pair immer im selben ‚Blech-Server‘ existieren muss.

Beispiele:
1 Server mit 1 CPU: 1 CPU Pair
1 Server mit 2 CPU: 1 CPU Pair
1 Server mit 3 CPU: 2 CPU Pairs
1 Server mit 4 CPU: 2 CPU Pairs
2 Server mit je 1 CPU: 2 CPU Pairs
2 Server mit je 2 CPU: 2 CPU Pairs
3 Server mit je 3 CPU: 6 CPU Pairs
1 Server mit 2 CPUs und 2 Server mit je 1 CPUs: 3 CPU Pairs

Ferner hat Oracle die Subscriptionierung der Containerplattform Oracle Verrazano ebenfalls auf CPU Pair angepasst.

Lt. Ankündigung von Oracle haben sich wohl auch die AGBs geändert, aufgrund derer man nun Oracle Linux vestellen kann. Hier warte ich noch auf Detailinformationen, die ich dann in einem Update hier einbauen werde, sobald ich sie habe,

Bewertung:
Man müsste mal diverse Beispiele aus den Kundensituationen durchrechnen um ein allgemeineres Bild zu bekommen, aber zumindest der erste Kunde, der jetzt nach den neuen Regeln bestellt, spart etwa 10% der Subskriptionsgebühren pro Jahr. Mir scheint, dass das bei etlichen Kunden zutreffen wird. Also mal eine Änderung von Oracle, bei der nicht automatisch alles teurer wird. Ist doch auch mal schön.

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , , | 1 Kommentar

GoldenGate Free – kostenlose Version von GoldenGate

Auf der gerade zuende gegangenen Oracle Cloud World hat Oracle eine kostenlose Verison von der – simpel ausgedrückt – Datenübertragungssoftware GoldenGate vorgestellt: GoldenGate Free.

Erste Infos:

  • GoldenGate Free ist auf die Verwendung mit Datenbanken bis zu einer Größe von 20 GB beschränkt,
  • Support gibt es – wie bei der Database Express Edition (DB XE) über Community-Foren und nicht über den Oracle-Support,
  • GoldenGate Free kann nicht mit vollwertigen, lizenzierten GoldenGate-Produkten interagieren

Für weitere Infos bzgl. der Einschränkungen der kostenfreien Version müssen wir uns noch bis zum Erscheinen des entsprechenden Licensing Guide gedulden. Die Software selbst ist auch noch nicht runterladbar.

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , | Kommentar hinterlassen

Oracle Database Appliance ODA X9-2 bestellbar

Seit dem 07.06.2022 ist die neue Version der Oracle Database Appliance (ODA) bestellbar: ODA X9-2.

Auf der Oracle Webiste steht noch nichts darüber, aber wir haben schon alle Preise und Infos.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Wieder kostenfreies Oracle JDK !!!

Logo

Oracle überrascht zum Start der neuen LTS-Version 17 des Oracle JDK mit interessanten Neuigketen (LTS=Long Term Support):

kostenfrei, sogar für kommerzielle, produktive Nutzung: lädt man Oracle Oracle Java 17 LTS herunter (Link), bekommt man kostenfreie Updates bis September 2024 und erhält Oracle Java 17 LTS unter einer „No-Fee License
für Entwicklung, Test, Prototyping UND für die eigene kommerzielle produktive Nutzung. Entsprechend der Presseveröffentlichung von Oracle vom 14.09.2021 wird diese „No-Fee“- oder „Free to use“-Lizenz bis ein Jahr nach Erscheinen der nächsten LTS-Version (siehe unten) gültig sein.
Achtung: dies gilt nur ab Oracle Java 17 und nicht rückwirkend für die älteren LTS-Versionen.
Achtung2: dies gilt nur für den Java-Standard. Spezielle kommerzielle Oracle Features, wie bespw. der auf den Java User Tracker (kommerziell) aufbauende Java Management Service (JMS (ja, ich weiß, Java Message Service hieß auch schonmal so, aber ich kann nichts für Oracles Naming-Entscheidungen)) bleiben kostenpflichtig, so dass man für deren Nutzung die Subscription beziehen muss.

neue LTS-Release-Kadenz: nachdem ursprünglich geplant war, alle drei Jahre eine neue LTS-Version herauszubringen, hat Oracle nun für seine Java-Distribution entschieden, diesen Zeitraum auf zwei Jahre zu verkürzen. Siehe: hier.

Und was sagt uns das nun?
Euphemistisch: Oracle hört auf seine Kunden und geht auf deren Bedürfnisse ein.
Man kann aber auch vermuten, dass Oracle gemerkt hat, dass Kunden nicht daran denken, für Oracle-Java Subscriptions zu kaufen sondern in großer Zahl Oracle-Java durch OpenJDK-Distributionen ersetzen. Dass zunächst AWS und nun auch noch Microsoft mit eigenen kostenfreien LTS-Versionen die Auswahl im OpenJDK-Bereich vergrößern war möglicherweise noch ein zusätzliches Argument für den plötzlichen Sinneswandel bzgl. der Kostenfreiheit bei Oracle-Java.
Nun ist dabei – wie ich finde – ein sinnvoller Kompromiss entstanden:
Kunden brauchen weiterhin nicht auf Oracle-Java zu verzichten, das ab Version 17 für drei Jahre auch bei kommerzieller/produktiver Nutzung kostenfrei bleibt. Wer nach den drei Jahren dann Updates/Patches braucht, wird dann eine Subscription beziehen müssen, sofern es nicht auf die dann aktuelle neue LTS-Version upgraden möchte oder kann.

Veröffentlicht unter DOAG Deutsche Oracle Anwendergruppe, OPITZ CONSULTING, Oracle-Lizenzierung | Verschlagwortet mit | 1 Kommentar

Oracle-Lizenzmigrationen: „langweilige“ Migrationen entfallen

Oracle hat heute die Oracle-Partner informiert, dass seit 02.07.2021 einige „langweilige“ Migrationen entfallen können.

Inbesondere betrifft dies auch die Migration von der DB Standard Edition One und DB Standard Edition auf die DB Standard Edition Two, di enotwendig war, wenn man eine Datenbank Standard Edition Version 12.1.0.2 oder höher einsetzen wollte und man bisher die „alten“ Lizenzen der DB SE1 oder DB SE hatte.
In einem aktuell nur für Oracle-Partner im Oracle Partner Network zugänglichen Dokument wird beschrieben, dass Kunden für die nun impliziert durchgeführte Migration in der Oracle Software Delivery Cloud die gewünschte neue Version herunterladen sollen, wobei dann die Lizenzbedingungen der DB SE2 durch Anklicken einer entsprechenden Checkbox akzeptiert werden müssen. Das bedeutet implizit auch, dass die bisher druchgeführte Verteuerung des Supports der DB SE2 um 20%, wenn man von der DB SE1 migriert hat, entfällt. Ein offizielle Aussage hierzu war aber noch nicht zu lesen.

Kunden, die trotzdem noch die offizielle Lizenzmigration durchführen möchten, können dies auch weiterhin tun. Wir als Oracle-Partner stehen dafür gerne weiterhin zur Verfügung.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Keine Zwischen-/Innovation-Releases der Oracle DB mehr für IBM-Kunden

Mit Neuordnung der DB-Releases und Nummerierung deselben hat Oracle vor ein paar Jahren eingeführt, dass es sogenannte „Innovation Releases“ (Zwischenreleases) mit relativ kurzer Supportlaufzeit gibt, und sogenannte LongTerm-Releases mit der üblichen Supportlaufzeit von 5 Jahren plus 3 Jahren Extended Support-Möglichkeit.

Innovation Releases der DB sind die 18c, die 21c, die 22c, 24c (oder welcher Buchstabe dann modern ist), 25, ….
LongTerm-Releases sind bspw. die 19c und 23c.

Mit der MyOracleSupport Note … hat Oracle nun angekündigt, dass Nutzer der IBM Power Systems mit AIX und Kunden mit IBM Z Systemen keine Innovation Releases mehr bekommen werden, sondern nur noch die LogTerm-Releases.

Siehe MyOracleSupport Doc ID 2766930.1 (Account für MyOracleSupport erforderlich)

Vielen Dank an meinen Kollegen Christian Ballweg für den Hinweis!

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , , | Kommentar hinterlassen

Preissenkung bei Oracle (Tech-Produkte)

Soeben habe ich die neue ab 01.06.2021 gültige Tech-Preisliste von Oracle erhalten.

Aufgrund von Wechselkursanpassungen wurden die Preise aller Produkte um ca. 5% gesenkt!

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Oracle Segregation-Approval / VLAN-Approval – aktuelle FAQ

Nachdem immer wieder irritierende Aussagen von Kunden, DOAG-Mitgliedern und auch Oracle-Mitarbeitern mich erreichen, möchte ich den aktuellen Kenntnisstand zum Oracle VLAN-Approval (auch Segregation Approval oder Reconfiguration-Approval genannt) in einem FAQ-Dokument zusammenfassen:

F: Was ist das Segregration-Approval ?

A: Oracle beurteilt VMware-Virtualisierung als Softpartitioning (siehe Oracle Partitioning Policy (https://www.oracle.com/assets/partitioning-070609.pdf)). Ferner ist nach der Oracle-Bewertungslogik die gesamte Hardware einer VMware-Umgebung zu lizenzieren, auf die eine VM mit Oracle-Produkt zur Laufzeit hin verschoben werden kann. Da mit VMware 6.0 und höher eine VM sogar über vCenter-Grenzen hinweg verschoben werden könnte, wären theoretisch alle ESX-Hosts aller VMware-Umgebungen des Kunden mit Version 6.0 und höher zu lizenzieren. Ferner hat Oracle zu dem Zeitpunkt der Bekanntgabe, dass nicht mehr nur das VMware-Cluster lizenziert werden muss, die Sichtweise auch auf Shared Storages erweitert und festgelegt, dass alle VMware-Umgebungen lizenziert werden müssen, die an einem SAN hängen, wenn auf einer dieser Umgebungen sich Oracle-Produkte befinden. Da diese beiden Ankündigungen verständlicherweise nicht auf Akzeptanz bei Kunden gestoßen ist, hat Oracle das VLAN-Approval eingeführt, das dann zum Segregation Approval erweitert wurde.

F: Aber ich kann doch in VMware DRS Host Affinity Rules definieren um das Verschieben auf bestimmte Server zu begrenzen oder auch vSphere CPU Affinity konfigurieren um nur eine begrenzte Anzahl von Cores in einem Server für eine VM zu nutzen.

A: Das ist zwar technisch möglich, ABER es wird von Oracle lizenztechnisch nicht anerkannt. Was immer wieder die Diskussionen erschwert, ist die Tatsache, dass VMware genau dies in ihrem Whitepaper (https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/whitepaper/solutions/oracle/understanding_oracle_certification_support_licensing_vmware_environments-white-paper.pdf) seit 2015 behauptet. Allerdings ist dies die Ansicht von VMware, die von Oracle LMS (neuer Name GLAS (Global Licensing and Advisory Services)) nicht bestätigt wird.

F: Die Oracle Allgemeinen Vertragsbedingungen (OLSA, OMA, TOMA), enthalten oder verlinken auf die Definitionen, und dort ist der Prozessor definiert als „Prozessor bezeichnet alle Prozessoren, auf denen die Oracle Programme installiert sind und/oder ablaufen.“ Da steht nichts von „könnte ablaufen“ oder „könnte dahin verschoben werden“. OMA bzw. TOMA und früher OLSA ist doch neben der Rechnung die einzige vertragliche Basis, die zwischen Oracle und dem Kunden besteht. Wie kommt Oracle also dazu, hierzu erweiterte Regeln einzuführen?

A: Das kann leider nicht eindeutig beantwortet werden. Zu Beginn der Nutzung von Virtualisierung (vor allem VMware) unterhalb von Oracle-Produkten hat Oracle die oben beschriebene Sichtweise festgelegt, dann 2014 anhand der erweiterten Verschiebe-Möglichkeiten von VMware ebenfalls erweitert und beharrt seitdem darauf. Demgegenüber kommen auch die beiden Gutachten, die die Deutsche Oracle Anwendergruppe (DOAG) hierzu hat erstellen lassen, zu dem Schluss, dass Oracle Sichtweise der Lizenzierung nicht mit der vertraglichen Grundlage zusammenpasst. Gleiches gilt für das von der Österreichischen Oracle User Group (AOUG) erstellte Gutachten. Da es hierzu aber weltweit noch kein Gerichtsurteil gibt, das dieses abschließend geklärt hat, gibt es daher noch keine endgültige Rechtsprechung, so dass die Sichtweise von Oracle der der Kunden entgegensteht.

F: Was kann ich als Kunde denn nun tun?

A: Grundsätzlich gibt es zwei Wege: den konfrontativen und den kooperativen Weg. Der konfrontative Weg bedeutet, dass man sich auf den Standpunkt stellt, man lizenziert nur die genutzten Prozessoren, und Oracle soll doch versuchen, seine vermeintlichen Ansprüche durchzusetzen. Dies wird im englischsprachigen Raum und auch von niederländischen Lizenzberater Daniel Hesselink stark propagiert. Man muss sich dabei aber im Klaren sein, dass man sich – salopp ausgedrückt – dann mit Oracle in einem kriegsähnlichen Zustand befindet, dieses aushalten wollen und können, das Unternehmen intern entsprechen instruieren (z.B. Single Point of Contact, etc.) und genauestens loggen, wann Oracle wo genau in Betrieb war. In Deutschland wird daher eher der kooperative Weg eingeschlagen, und der wiederum bedeutet die Nutzung des Segregataion-Approvals, womit wir wieder beim eigentlichen Thema dieses FAQ wären.

F: Na endlich. Was ist denn nun das VLAN-Approval ?

A: Immer mit der Ruhe. Es muss ja auch der Hintergrund erläutert werden, damit das Problem verstanden wird. Im Gespräch mit Andrew Mendelsohn, Executive Vice President for Database Server Technologies bei Oracle, während der DOAG Konferenz 2015 wurde von ihm als Ausweg aus dem VMware-Lizenzierungsdilemma das VLAN-Approval erstmal hier in Deutschland erwähnt. Es bedeutet, dass man auf Netzwerkebene (!!!) VLANs definiert, diese von der VMware-Umgebung aus nutzt und somit ein Verschieben der VMs mit Oracle-Produkten außerhalb des per VLAN „eingezäunten“ Bereichs verhindert. Als Ergebnis braucht man dann nur die Prozessoren der ESX-Hosts zu lizenzieren, die sich in dem „einzäunenden“ VLAN befinden. Als Grenze wird meist das VMware-Cluster per VLAN abgetrennt. Zusätzlich betrachtet man dann auch das Storage. Hier muss man mit geeigneter Trennung (z.B. LUN-Zoning, NTFS-Mounts, etc.) dafür sorgen, dass der von/für Oracle genutzte Bereich des Storage nur von dem Oracle-Cluster gesehen werden kann und nicht von anderen VMware-Clustern. Dies beides (Netzwerk UND Storage) muss man entsprechend konfigurieren und zusammen mit einer Architekturskizze, erläuterndem Text und entsprechend beweisenden Screenshots in einem englischsprachigen Dokument dokumentieren. Dieses Dokument muss man dann beim Oracle-Vertrieb einreichen um das VLAN-Approval zu erlangen.

F: Und was ist dann das Segregation Approval ?

A: Nach einigen Monaten hat Oracle die Anzahl der möglichen Trennungstechnologien erweitert. Anstatt VLANs zu nutzen, kann man bspw. auch eine Firewall entsprechend platzieren und konfigurieren, die das Verschieben von VMs mit Oracle aus dem definierten Bereich verhindert, das Migration Netzwerk weglassen o.Ä.. Die Art der Trennung muss aber immer auf Netzwerkebene erfolgen, nicht nur in der VMware-Konfiguration. Da nun auch andere Trennungsarten als VLAN genehmigt werden können, wurde der Name von VLAN-Approval zu Segregation-Approval (manchmal auch Reconfiguration-Approval) geändert. Umgangssprachlich und auch hier in diesem FAQ werden Segregation-, Reconfiguration- und VLAN-Approval synonym benutzt.

F: OK, also hat man eine Vorgabe, was man tun muss um dann compliant zu sein (vorausgesetzt man hat ausreichend Lizenzen) ?

A: Leider nein. Es ist jedes mal eine Einzelgenehmigung, die zwischen dem Endkunden und Oracle getroffen wird. Daher wird das Segregation-Approval von vielen Beratern bedingt kritisch gesehen, weil man damit implizit dem Ansinnen von Oracle, abweichend von der vertraglichen Regelung zu lizenzieren, implizit zustimmt. Und auch aus Sicht der DOAG ist das leider nur ein Workaraound. Den aber seither viele Kunden in Anspruch genommen haben, weil sie damit bei den Vorteilen der VMware-Nutzung bleiben können und das Lizenzierungsthema damit einigermaßen im Griff ist.

F: Was wären denn Alternativen ?

A: Wenn man nicht den oben beschriebenen konfrontativen Weg gehen möchte, bleiben als Alternativen zum VLAN-Approval nur der Wechsel auf Blech, der Wechsel auf einen anderen Hypervisor für entweder den Oracle-Workload oder den Nicht-Oracle-Workload (was zumindest so lange funktioniert wie ein Verschieben von bspw. VMware zu HyperV zur Laufzeit nicht möglich ist), der Wechsel in die Cloud oder die Lizenzierung der Nicht-Oracle-Umgebungen mit sogenannten „passiven“ Lizenzen. Diese passiven Lizenzen sind extrem hoch rabattierte Oracle-Lizenzen, auf denen dann auch kein Oracle laufen darf, sondern die nur die Nicht-Oracle-VMware-Umgebungen legalisieren. Man kann aus dem Geschriebenen schon die Widersinnigkeit erkennen, und so rate ich von dieser Lösung „passive Lizenzen“ ab, denn hier muss man bei jeglicher Änderung im Nicht-Oracle-VMware-Bereich die Lizenzierung bzgl. der passiven Lizenzen beachten und ggf. nachkaufen.

F: Was kostet denn das Segregation- bzw. VLAN-Approval ?

F: Eigentlich nichts. Oracle (namentlich Andy Mendelsohn und auch Paul Wehner (Leiter der Systemberatung in Deutschland)) betont immer wieder, dass es keine Vorschrift bei Oracle gebe, dass das VLAN-Approval was kosten muss. Allerdings haben in der Vergangenheit die Oracle-Vertriebler die Erteilung des VLAN-Approvals an einen Cloud- oder Lizenzkauf gebunden um die dafür verwendete Arbeitszeit über den Umweg vergütet zu bekommen. Da es hierfür keinen einheitlichen Preis gab, sondern dieser vom jeweiligen Vertriebler anhand seiner persönlichen Einschätzung festgelegt wurde, wirkte dies doch sehr nach „Gutsherrenart“ und führte in der Praxis zu einer Bandbreite von „das bekommt der Kunde ‚für umme‘, weil der hat noch einen gut bei mir“ bis hin zu „das bekommt der Kunde gar nicht weil…“. Oder man konnte sich schlicht nicht einigen, weil der Kunde nichts brauchte und daher nichts kaufen wollte, der Oracle-Vertrieb aber trotzdem auf kompensierenden Umsatz bestanden hatte. Insgesamt also eine sehr unglückliche Situation, die sich aber inzwischen bessert.

F: Wie ? Das Segregation-Approval kostet nichts mehr?

A: Jein…. Hier muss man unterscheiden: der direkte Oracle Vertrieb ist ja grob in zwei Bereiche unterteilt: größere Kunden werden vom sogenannten „Feld“-Vertrieb betreut, die anderen Kunden werden von „Oracle Direct“ aus Amsterdam betreut. Zumindest aus dem Feld-Vertrieb hört man, dass seit Sommer 2020 die Bearbeitung des VLAN-Approvals nicht mehr mit einem kompensierenden Geschäft verbunden sein muss. Und auch aus Amsterdam sind erste Tendenzen in diese Richtung wahrzunehmen.

F: OK. Nehmen wir nun an, wir haben unser VMware-Cluster entsprechend abgetrennt, beim Storage die entsprechende Trennung konfiguriert und das Ganze dokumentiert und bei Oracle eingereicht. Was ist denn das Approval ?

A: Das Approval meint eigentlich den internen Genehmigungsprozess bei Oracle. Ein Oracle-intern genehmigtes Approval nützt dem Kunden erstmal noch gar nichts. Er braucht eine vertragliche Regelung um sich dann darauf berufen zu können. Hier empfehle ich dringend, dass darauf geachtet wird, dass in der vertraglichen Regelung die Genehmigungen sich auf alle vorhandenen Lizenzen beziehen und dass das idealerweise auch für zukünftig zu beschaffende Lizenzen geht. Aus meiner Sicht ist am besten, wenn zwischen Oracle und dem Kunden ein Oracle Master Agreement (OMA) unterzeichnet wird, an den dann per Amendment die vertragliche Regelung des Segregation Approvals (manchmal auch Segregation Clause genannt) gehängt wird. Da der OMA nach Abschluss 5 Jahre gültig ist (auf 10 Jahre verlängerbar), können zukünftige Lizenzkäufe auf Basis des OMA erfolgen, so dass diese zukünftig beschafften Lizenzen dann auch der Segregation Clause unterliegen.

F: Und wie lange ist das gültig ?

A: Für die in der vertraglichen Genehmigung (evtl. per Nennung der CSI-Nummern) genannten Lizenzen bzw. für die Lizenzen, die auf Basis eines OMA mit Segregation-Clause Amendment beschafft werden, gilt das Approval theoretisch unbefristet bzw. bis zu einer zwischen Oracle und dem Kunden abgeschlossenen neuen vertraglichen Basis.

F: Wann benötigt man denn ein Re-Approval?

A: Hier wurde zumindest in der Vergangenheit viel Unfug erzählt um Kunden vom Segregation-Approval abzuschrecken und lieber stattdessen eine ULA (Unilimited License Agreement) zu verkaufen. So wurde gerne behauptet, dass bei jeglicher Änderung (Server hinzu, Versionswechsel vSphere, neue Netzwerk-Switche, …) ein Re-Approval nötig sei. Das ist Unfug! Der reine Approval-Text ist so abstrakt, dass dort bei einem Approval auf VLAN-Trennung sinngemäß nur drinsteht, dass der Kunden eine Separierung auf Netzwerkebene mittels VLANs vornimmt, die die VMs, auf denen Oracle-Programme ablaufen, auf einen bestimmten Bereich isoliert, und dass die Migration von VMs nur auf die Server beschränkt ist, aus denen das VLAN besteht. Bzgl. Storage ist nur formuliert, dass durch Storage Segregation Technologie der Speicherbereich mit Oracle-Programmen von anderen Servern außer denen im VLAN nicht zugreifbar ist. Daraus ergibt sich, dass ein Re-Approval nur notwendig ist, wenn die Art der Trennung grundlegend geändert wird. Also wenn man bspw. von der VLAN-Trennung zur Trennung mittels Firewall wechselt. Analog beim Storage: wenn man bspw. LUN-Zoning im VLAN-Approval genehmigt bekommen hat, und man auf NTFS-Mounts umstellt, benötigt man ein Re-Approval. Aber nicht wenn man die NetApp gegen eine EMC austauscht, grundsätzlich aber beim LUN-Zoning bleibt.

F: Also braucht man kein Re-Approval, wenn man Server austauscht, Server hinzufügt, Betriebssystem-Versionen oder VMware-Versionen ändert, die Switche austauscht etc.?

A: nein. Man muss natürlich eine analoge VLAN-Konfiguration auf dem neuen Switch vornehmen. Und natürlich müssen entsprechende Lizenzen vorhanden sein, wenn man das abgetrennte Oracle.-Cluster vergrößert indem Server hinzugefügt oder gegen Server mit mehr Prozessoren/Cores getauscht werden.

F: Wie gesichert ist diese Aussage ?

A: Wie leider üblich, findet man solche Detailinformationen nicht bei Oracle, da Oracle sowas nicht veröffentlicht. Aber die Aussagen bzgl. des Re-Approvals wurden in meinem Beisein von einem LMS/GLAS-Mitarbeiter Kunden gegenüber getätigt.

F: Betrifft das eigentlich nur VMware ?

A: Nein. Da VMware generell sowie auch bei den Oracle-Nutzern die größte Verbreitung hat, werden alle Regeln immer auf VMware bezogen. Sie gelten aber gleichermaßen auch für andere Hypervisor, wenn sie die selben Features haben wie VMware.

F: Wie sieht’s denn bzgl. der neuen Technologien wie Hyperconverged Systems und Containerisierung aus ?

A: Ebenfalls analog zur Virtualisierung. Bzgl. Containers and Kubernetes Clusters hat Oracle das – nicht Vertragsbestandteil seiende – Partitioning-Policy Dokument (https://www.oracle.com/assets/partitioning-070609.pdf) im Oktober 2020 angepasst und die Regel hinzugefügt, dass ein Server bzgl. Oracle lizenziert werden muss, sobald ein Container mit dem Oracle-Programm dorthin deployed wurde. Wenn dieser Server kein physikalischer Server sondern eine VM ist, gelten die o.g. Regeln. Auch bei Hyperconverged Systems gelten lt. Oracle die hier beschriebenen Regeln. Da mittlerweile bspw. der Akropolis Hypervisor von Nutanix ebenfalls clusterübergreifendes Verschieben ermöglicht, muss also auch hier entsprechende Netzwerk-Trennung erfolgen.

F: Wie ist das Fazit zum Segregation Approval ?

A: Ich habe – zusammen mit meinen Kollegen, die bzgl. Netzwerk-, Storage und VMware-Konfiguration und Beurteilung der Dokumentation unterstützen – seit Anfang 2016 mehr als 40 Segregation-Approvals erfolgreich bearbeitet, so dass die Kunden mit unserer Unterstützung bei Konzeption und Dokumentation das Segregation Approval erlangt haben. Wir hatten darüber hinaus einen Kunden, der aus gesetzlichen Gründen bereits eine solch komplizierte Netzwerk-Architektur benötigt, dass eine zusätzliche VLAN-Einführung nicht denkbar war, dann hatten wir einen Kunden, bei dem keine Einigung über den damals noch seitens des Oracle-Vertriebs gewünschten kompensatorischen Kauf zwischen Oracle und dem Kunden erzielt werden konnte und einen Kunden, bei dem Oracle das Approval nicht bearbeiten wollte, weil der Kunde hosten lässt und man befürchtete, dass dann alle Kunden des Hosters das Approval haben wollen. Wenn man von solchen negativen Ausnahmen mal absieht, die zudem auch mittlerweile der Vergangenheit angehören sollten, ist das Segregation Approval die sinnvolle Möglichkeit, Oracle weiter compliant auf virtualisierten Umgebungen zu betreiben. Man erhält die HA-Vorteile und das gewohnte Management von VMware, ist aber mit dem VLAN-Approval und entsprechender Lizenzierung aber compliant. Allerdings ist ärgerlich, dass jeder Kunde dieses Approval einzelvertraglich beantragen und erhalten muss. Daher ist es aus meiner Sicht weiterhin nicht als „gute Lösung“, sondern nur als „Workaround“ zu bewerten. Der aber für viele Kunden eine sinnvollen Weg darstellen kann, wenn die Kunden nicht den konfrontativen Weg gehen wollen.

Veröffentlicht unter Uncategorized | Verschlagwortet mit , | Kommentar hinterlassen

Neues bei kostenfreien Java-Distributionen

Mit dem 06.03.2021 ist AdoptOpenJDK nun zur Eclipse Foundation gewandert und heißt nun neuerdings: „Ecliopse Adoptium“. Es bleibt bei: kostenfrei und LongTermSupport (LTS)

Dafür gibt es nun einen weiteren Anbieter für kostenfreies Java und kostenfreien LongTermSupport:

Nähere Informationen und Downloads gibt es hier: https://www.microsoft.com/openjdk

Vielen Dank an meinen Kollegen Klaus Kramer für den HInweis.

Veröffentlicht unter Uncategorized | Verschlagwortet mit , , | Kommentar hinterlassen