OnPrem und Cloud: einmal addieren, einmal nicht. Oder: Konsistenz wäre schön!

Was will ich nun mit dieser kryptischen Überschrift sagen…

Es geht um die Ermittlung der Anzahl der benötigten Prozessoren und um den Umgang mit Rundungsnotwendigkeiten.

Gucken wir uns erstmal OnPrem an:
Nicht immer ist das Zählen so einfach wie Oracle es in den wenigen Beispielen in den veröffentlichten Dokumenten vorsieht. Zum Einen gibt es Betriebssysteme, bei denen man ganz offiziell Bruchteile von Prozessoren zuweisen kann (z.B. IBM capped LPAR), und dann stellt sich noch die Frage, wann mit dem jeweiligen Core-Faktor mutipliziert wird, und dadurch können Ergebnisse mit Bruchteilen entstehen, und es stellt sich die Frage, wann dann auf die jeweils nächst-höhere ganze Zahl gerundet werden muss, denn Oracle verkauft nur ganzzahlige Prozessorlizenzen.
Nehmen wir mal an, wir haben folgende Umgebung, auf der die Oracle DB Enterprise Edition läuft:
1 IBM Server (Power8-Prozessoren (Core-Faktor=1,0)), auf dem 3 capped LPARs mit der DB-EE laufen
– 1 LPAR hat Entitled Capacity = 0,6
– 1 LPAR hat Entitled Capacity = 0,9
– 1 LPAR hat Entitled Capacity = 1,2
1 Oracle/Sun-Server (SPARC T5 (Core-Faktor=0,5)) mit 1 capped Zone mit 3 Cores
1 Oracle VM mit 3 zugeordneten Cores Intel Xeon E7-48xx (Core-Faktor=0,5)
Man sieht, alle Server sind Hard-Partitioniert.
Um bei solchen komplexeren Umgebungen die Anzahl der zu lizenzierenden Prozessoren zu ermitteln, gibt bei On-Prem gibt es nun folgendes Regelwerk:
Erst die Server gleichen Prozessortyps addieren, die jeweilige Summe mit dem Core-Faktor multiplizieren, dann addieren und erst dann ggf. runden. D.h.:
LPAR: (0,6+0,9+1,2)*1,0 = 2,7*1,0 = 2,7
Oracle/Sun: 3*0,5 = 1,5
Oracle VM: 3*0,5 = 1,5
Summe: 2,7+1,5+1,5 = 5,7   also aufrunden auf 6 Prozessorlizenzen

 

Kommen wir jetzt zur Cloud:
In dem Whitepaper zu Licensing Oracle in Cloud Computing Environments (Azure, AWS) steht folgendes zur Lizenzierung der DB SE1/SE/SE2:

When licensing Oracle programs with Standard Edition One, Standard Edition 2, or Standard Edition in the product name, the pricing is based on the size of the instance. Authorized Cloud Environment instances with four or fewer Amazon vCPUs, or four or fewer Azure vCPUs, are counted as 1 socket, which is considered equivalent to an Oracle processor license. For Authorized Cloud Environment instances with more than four Amazon vCPUs, or more than four Azure vCPUs, every four Amazon vCPUs used (rounded up to the nearest multiple of four), and every four Azure vCPUs used (rounded up to the nearest multiple of four) equate to a licensing requirement of one socket.

Gleiches gilt auch für die OCPUs in der Oracle Cloud.
Stellt sich nun die Frage, wie hier addiert und gerundet wird. Nehmen wir mal an, die DB-EE läuft in der AWS-Cloud in zwei Cloud-Instanzen (=VMs) mit je 2 vCPUs.
Im Unterschied zu OnPrem wird in der Cloud  jede Cloud-Instanz separat betrachtet.
Man darf also hier nicht erst addieren und dann ggf. runden (2 vCPU + 2 vCPU = 4 vCPU = 1 Prozessorlizenz DB SE1/SE/SE2 wäre hierfür das falsche Ergebnis), sondern es muss jeweils pro Instanz gerundet und dann addiert werden: 2 vCPU -> 1 Prozessorliz. + 2 vCPU -> 1 Prozessorliz = 2 Prozessorlizenzen.

1

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

Ende der Fix-Term-Lizenzen … fast !!!

Oracle hat heute informiert, dass ab 01.09.2020 die zeitlich befristeten Lizenzen (Fix-Term-Lizenzen (FTL), die für 1, 2, 3, 4 oder 5 Jahre angeboten wurden), nicht mehr angeboten werden. Auch hierdurch sollen die Kunden in die Cloud motoviert werden. Bestehende Kunden, die Support für ihre befristeten Lizenzen zahlen, werden bis zum Ende ihrer Laufzeit weiterhin unterstützt.

Es gibt allerdings eine Ausnahme: 1-Jahres-Lizenzen sind auch nach dem 01.09.2020 noch für bestimmte Oracle-Produkte kaufbar. Aktuell sind diese Produkte auch nach dem 01.09.2020 als 1-Jahres-Lizenz lizenzierbar:

Datenbank:
Oracle Database Standard Edition 2
Oracle Database Enterprise Edition

Optionen der Datenbank:
Oracle Active Data Guard
Oracle Advanced Compression
Oracle Advanced Security
Oracle Database In-Memory
Oracle Database Vault
Oracle Multitenant
Oracle OLAP
Oracle Partitioning
Oracle Real Application Clusters
Oracle Real Application Clusters One Node
Oracle Real Application Testing

Management Packs der Datenbank:
Oracle Diagnostics Pack
Oracle Tuning Pack

Middleware:
Oracle Forms and Reports
Oracle Internet Application Server Enterprise Edition
Oracle WebLogic Server Standard Edition
Oracle WebLogic Server Enterprise Edition
Oracle WebLogic Suite
Oracle SOA Suite for Oracle Middleware

Sonstiges:
Oracle GoldenGate
Exadata Storage Server Software

 

 

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

Update in Beitrag „Failover und die 10-Tage Regel – äh … 10×24-Stunden Regel“

Gestern habe ich von der Änderung der „10-Tage-Regel“ beim Failover berichtet, die ja noch einige offene Fragen zurückgelassen hat. Die Fragen bzgl. der Berechnung der 24-Stunden-Perioden konnten schnell geklärt werden:
Jede 24-Stunden-Periode beginnt mit dem Ausfall des Primär-Servers und dem Umschalten auf den Sekundär-Server. Ich habe die im verlinkten Beitrag aufgezählten Varianten bzgl. der neuen Regelung entsprechend aktualisiert.

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

Failover und die 10-Tage Regel – äh … 10×24-Stunden Regel

Gerade durch einen Newsletter von Redress Compliance drüber gestolpert:

 

 

 

 

 

Aber auch hier … es wäre nicht Oracle, würde das nicht wieder mehr Fragen aufwerfen als es beantwortet:

  • im aktuell auf den Oracle-Seiten verfügbare LDR vom 11.06.2020, und nur der ist vertraglich bindend, steht da noch nichts von drin, sondern der alte Text von den
    10 Tagen.

    • wann kommt ein entsprechend angepasster LDR ?
  • Strenggenommen gilt das dann doch nur für neu gekaufte Lizenzen, denn von einer rückwirkend geltenden Änderung steht da nichts.
  • Im am 28.07.2020 geänderten Dokument „Licensing Data Recovery Environments“ steht folgendes:

    Das ist soweit klar, weil in dem Beispiel im Text der Primärserver einmal am Dienstag und einmal am Freitag ausfällt, und das kann man ja nicht in eine 24-Stunden-Periode packen. Es wird aber nicht deutlich, wie zu rechnen ist, wenn die Maschine am Donnerstag 2 Stunden und am Freitag 3 Stunden ausfällt, denn hier gibt es drei Möglichkeiten:
    ◊ Maschine fällt aus von Donnerstag 22 Uhr bis Freitag 03 Uhr
    → Alte Regelung: 2 Tage von 10 Tagen sind weg
    → Neue Regelung: Eine 24-Stunden-Periode ist weg
    ◊ Maschine fällt aus Donnerstag von 09 bis 11 Uhr und Freitag von 03 bis 06 Uhr
    → Alte Regelung: 2 Tage von 10 Tagen sind weg
    → Neue Regelung: Zwei 24-Stunden-Perioden sind weg
    ◊ Maschine fällt aus Donnerstag von 09 bis 11 Uhr und Freitag von 14 bis 17 Uhr
    → Alte Regelung: 2 Tage von 10 Tagen sind weg
    → Neue Regelung: Zwei 24-Stunden-Perioden sind weg

Update 25.08.2020: Inzwischen ist bzgl. der Zeiträume Klarheit geschaffen worden: Jede 24-Stunden-Periode beginnt mit dem Ausfall des Primär-Servers und dem Umschalten auf den Sekundärserver. Ich habe die oben aufgezählten Varianten bzgl. der neuen Regelung entsprechend aktualisiert.

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

Neues zum kostenpflichtigen Oracle-Java

Java Logo Klassisch" von kleversonk | Redbubble Gute und nicht ganz so gute Nachrichten zum kostenpflichtigen Oracle JDK gibt es heute zu vermelden.

Fangen wir mit den nicht ganz so guten Nachrichten an, die sich aus der Frage ergeben, welche Versionen und Patch-Stände des Oracle-JDK überhaupt kostenpflichtig sind:
Hier wurde immer nur von Oracle JDK8 ab inklusive Patchlevel 211 sowie Oracle JDK11, 12, ff berichtet. Das ist auch grundsätzlich richtig, man vergisst dabei aber die späten Patchlevel von Oracle JDK6 und Oracle JDK7. Letzte frei verfügbare Patchlevel für diese Versionen waren Oracle JDK6u45 (April 2013) und Oracle JDK7u80 (April 2015). Alle Patchlevel von OracleJDK6 höher Level45 und Oracle JDK7 höher Level80 sind kostenpflichtig. Und diese Versionen sind durchaus häufig noch im Einsatz.

Übersicht:
OracleJDK 6
frei bis einschließlich Patchlevel 45 (April 2013)
Premier Support bis Dezember 2015
Extended Support bis Dezember 2018

OracleJDK 7
frei bis einschließlich Patchlevel 80 (April 2015)
Premier Support bis Juli 2019
Extended Support bis Juli 2022

OracleJDK8
frei bis einschließlich Patchlevel 202 (Januar 2019)
Premier Support bis März 2022
Extended Support bis Dezember 2030

 

Kommen wir nun zu den guten Nachrichten:
Wer das oben Stehende genau gelesen hat, dem ist aufgefallen, dass Oracle den Zeitraum für den Extended Support für Oracle JDK 8 verlängert hat. Und zwar bis zum Dezember 2030. Kunden, die die kostenpflichtigen Patches des Oracle JDK 8 einsetzen wollen, haben nun sehr viel mehr Zeit, die mit Java 8 letztmalig unterstützten Features (z.B. Applets, Java Webstart, …) weiterhin nutzen zu können. Und das in einer bzgl. Security-Patches aktuellen Umgebung.
Die zweite gute Nachricht ist, dass – lt. Oracle und nach heutigem Kenntnisstand – der Extended Support für Java keine Zusatzkosten mit sich bringt. Hoffen wir, dass das bis 2030 so bleibt.

 

 

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

Oracle Multitenant: wie viele PDBs sind möglich ohne Multitenant Option?

Weil ich selbst es gerne vergesse, hier die Übersicht, wie viele PDBs pro CDB „erlaubt“ sind ohne die Multitenant Option lizenzieren zu müssen. Denn dies ist abhängig von der verwendeten Version der Oracle-Database:

11.1 und 11.2:
Diese Versionen beinhalteten noch nicht die Multitenant-Technologie

12.1:
SE1/SE/SE2: 1 CDB + 1 PDB frei
EE: 1 CDB + 1 PDB frei, darüber Multitenant Option

12.2.:
SE2: 1 CDB + 1 PDB frei
EE: 1 CDB + 1 PDB frei, darüber Multitenant Option
jeweils +1 Application Root und +1 Proxy PDB

18c:
SE2: 1 CDB + 1 PDB frei
EE: 1 CDB + 1 PDB frei, darüber Multitenant Option
jeweils +1 Application Root und +1 Proxy PDB

19c:
SE2: 1 CDB + 3 PDB frei
EE: 1 CDB + 3 PDB frei, darüber Multitenant Option

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

Geändertes, kundenfreundlicheres(!), Bewertungsverfahren bei Nutzung von LPARs mit LPM

Ich habe kürzlich erfahren, dass Oracle das Bewertungsverfahren für die Ermittlung der benötigten Lizenzen bei der Nutzung von IBM LPARs mit Live Partition Mobility (LPM) geändert hat.

LPARs sind ja quasi der Archetypus des Hardpartitionings, allerdings zerstört lt. Partitioning-Dokument die Nutzung von LPM diese Einstufung als Hartpartitioning.
Wie in einem solchen Fall der Lizenzbedarf ermittelt wird, hat Oracle neu definiert.

In der Vergangenheit mussten, wenn LPM für eine LPAR mit Oracle konfiguriert war und somit auch eine Schatten-LPAR auf einem zweiten phys. Server dazu definiert war, beide Server voll lizenziert werden.

Heute prüft Oracle, ob diese LPAR tatsächlich schonmal verschoben wurde. Ist dies der Fall müssen beide Server bzgl. Oracle voll lizenziert sein, anderenfalls reicht es, nur die LPAR bzgl. Oracle zu lizenzieren. Hier hat Oracle auf eine kundenfreundlichere Bewertungsmethode gewechselt, die allerdings mehr Aufwand für Logging und Log-Archivierung verursacht.

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

OVM bekommt nun doch 3 Jahre Extended Support

Nachdem Oracle das Produkt- und Supportende von Oracle VM für März 2021 angekündigt hat,  kam gestern eine Info von unserem Oracle-Linux und OVM Ansprechpartner, dass für OVM entgegen bisher anders lautender Infos nun doch noch drei Jahre Extended Support gegen Mehrkosten (+10% im ersten Jahr, +20% im zweiten und dritten Jahr des Extended Supports) angeboten wird.

Der Extended Support für Oracle Linux 5 wurde von Juni 2020 auf November 2020 verlängert.

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

Oracle änderte die Audit-Formulierung in den AGBs

Mit den immerhin schon im Frühjar 2019 herausgekommenen als AGB fungierenden OMA und TOMA v040119 hat Oracle die Audit-Klauseln geändert bzw. erweitert.

Folgende Absätze sind hinzugekommen:

Sie verpflichten sich, bei einer solchen Prüfung durch Oracle zu kooperieren sowie, soweit von Oracle in zumutbarem Umfang angefordert, angemessene Unterstützung und Zugriff auf Informationen zu gewähren. Eine solche Unterstützung umfasst unter anderem das Ablaufenlassen von Oracle-Datenmesswerkzeugen auf Ihren Servern und die Bereitstellung der daraus resultierenden Daten an Oracle.

Die Durchführung der Prüfung sowie dabei gewonnene, nichtöffentliche Informationen und Daten (einschließlich aus der Prüfung resultierender Feststellungen oder Berichte) unterliegen den Bestimmungen in Abschnitt 8 (Geheimhaltung) der Allgemeinen Vertragsbedingungen.

Quelle: TOMA v040119_DEU

 

Der erste Absatz definiert, dass Oracle die Nutzung auf den Servern messen möchte. In der Vergangenheit war nur das prinzipielle Audit-Recht Bestandteil der entsprechenden Verträge, so dass Kunden die Vermessungen ggf abgelehnt haben. Diesem Vorgehen will Oracle nun einen Riegel vorschieben. Was genau mit „Oracle-Datenmesswerkzeugen“ gemeint ist, ist nicht näher definiert. In der Praxis erwarte ich aber keine Änderung im Unterschied zum bisherigen Vorgehen beim Audit: Man nutzt das LMS Collection Tool von Oracle. Wenn der Kunde hierzu den Oracle Enterprise Manager oder ein verifiziertes Tool (z.B. Flexera, Nova Ratio, Aspera SmartCollect, … (siehe https://www.oracle.com/corporate/license-management-services/tooling.html) einsetzt, werden dessen Ergebnisse akzeptiert. Und man kann mit entsprechendem Aufwand auch mit Oracle sein nicht-verifiziertes Tool (In-House entwickelt, Snow, …) nutzen, wenn man vorher mit Oracle gemeinsam beweist, dass dieses die selben Ergebnisse erzeugt wie das LMS Collection Tool.

Der zweite Abschnitt erinnert an die Vertraulichkeit der Audit-Ergebnisse, was eigentlich bereits in Abschnitt 8 geregelt wird. Ob dieser Passus generell haltbar ist, wird unter Juristen diskutiert, denn es gibt ja auch die berechtigte Forderung, dass ein Kunde sich fachlich versierte Unterstützung z.B. durch einen Anwalt und/oder Lizenzberater holen können muss.

 

Die Änderung des Audit-Abschnitts ist in D, A und CH leicht unterschiedlich ausgefallen, woraus ein Lizenzberater im Herbst des vergangenen Jahres ein größeres Thema gemacht hat. Die DOAG hat durch die Anwälte des DOAG Legal Council (ebenfalls, aus D, A und CH) die Unterschiede prüfen lassen. Die Anwälte sind zu dem Schluss gekommen, dass es zwar Übersetzungsuntreschiede gibt, weil eben 3 unterschieliche Menschen/Muttersprachler übersetzt haben, dass das aber keinerlei rechtliche Auswirkungen/Unterschiede hat.

 

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

VMware hat nun auch die Multicore-Prozessoren entdeckt

Mal nicht direkt was zu Oracle-Lizenzierung, sondern zu VMware.

Lt diesem Artikel vom ITAM Review (itassetmanagement.net) ändert VMware aktuell die Prozessor-Lizenzierung.

Nach der bislang geltenden Regelung, war ein Prozessor ein Prozessor (das ist nicht überraschend), unabhängig davon, wieviele Cores sich auf ihm befinden. Ab 02.04.2020 (warum nur nicht ab 01.04. ? ;o)  ) darf ein solcher Prozessor nur noch maximal 32 physikalische Cores haben. Hat eine CPU nun aber bspw. 40 Cores, so sind dafür bei VMware zwei Prozessoren zu lizenzieren.

Die 32 Core-Grenze klingt zwar erstmal hoch angesetzt, aber aktuell sind wir schon bei 56 bzw 64 Cores pro CPU bei Intel und AMD angekommen. Und wie wir die Hersteller kennen: Tendenz steigend.

Die vertragliche Situation, und warum es über kurz oder lang jeden Kunden treffen wird,  ist im oben verlinkten Artikel sehr gut beschrieben. In Kurzform: Vmware hat hier nicht einseitig die Verträge geändert, aber durch den Bezug von jeweilig eingesetzter Version und dem jewieligen Product Guide, der die Prozessorbestimmung enthält, lässt man sich bspw beim upgrade auf eine neue Version auch auf die geänderten Lizenzbedingungen ein.

 

Ich stelle gerade fest, so ganz ohne Oracle geht’s auch hier nicht: diese galoppierende Core-Anzahl pro CPU ist natürlich auch für Oracle-Kunden (oder Oracle ?) zunehmend ein Problem, zumal bisher im x86-Umfeld nur Oracle VM und demnächst der Nachfolger Oracle Linux VM (OLVM) als Hardpartitioning anerkannt wird, bei dem man nur die zugewiesenen Cores lizenzieren muss.

 

 

Veröffentlicht unter DOAG Deutsche Oracle Anwendergruppe, OPITZ CONSULTING, Uncategorized | Verschlagwortet mit | Kommentar hinterlassen