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.
mpaege 