Oracle Standard Lizenzierung - Trennung von der VMWare Farm
Hallo zusammen,
die Thematik ist einwenig komplex. Wir haben einen Server worauf eine Oracle Datenbank läuft. Dieser Server ist virtualisiert in unsere VMWare Umgebung. Die Lizenz für Oracle umfasst 2 Sockel und jeweils 1 Core. In der VM Ware Umgebung gibt es jedoch weitaus mehr Sockel und Cores.
Wir müssen jetzt diesen einen Server von dieser Umgebung so kappen dass es rechtlich in Ordnung ist und er nur auf 2 Sockel zugreift.
Müssen wir ne seperate Farm erstellen oder gibt eine Art "Zonen"? Gibt es andere Lösungen? Phyisikalische Lösung kommt für uns nicht in Frage.
Danke schonmal. Ich hoffe ich bin hier im richtigen Themenbereich.
die Thematik ist einwenig komplex. Wir haben einen Server worauf eine Oracle Datenbank läuft. Dieser Server ist virtualisiert in unsere VMWare Umgebung. Die Lizenz für Oracle umfasst 2 Sockel und jeweils 1 Core. In der VM Ware Umgebung gibt es jedoch weitaus mehr Sockel und Cores.
Wir müssen jetzt diesen einen Server von dieser Umgebung so kappen dass es rechtlich in Ordnung ist und er nur auf 2 Sockel zugreift.
Müssen wir ne seperate Farm erstellen oder gibt eine Art "Zonen"? Gibt es andere Lösungen? Phyisikalische Lösung kommt für uns nicht in Frage.
Danke schonmal. Ich hoffe ich bin hier im richtigen Themenbereich.
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 574427
Url: https://administrator.de/contentid/574427
Ausgedruckt am: 26.11.2024 um 03:11 Uhr
18 Kommentare
Neuester Kommentar
Doppelpost
Jetzt ja, hier wars noch doppelt
Genau genommen nicht, du warst nur zu langsam, er hat bereits 2 Minuten vor deiner Antwort den dritten Thread eröffnet :-P
Aber zum Zeitpunkt der Threaderstellung des TOs war es eben nur doppelt . Kann man aus 20 Richtungen sehen, Scheet sind solche Überachwemmungen sowieso egal wie oft.
Eigentlich hat er ja nur eine Lizenz für zwei Sockel, da ist der dritte Post schon illegal , duck und wech.
Servus und hallo,
auch wenn es drei mal gepostet wurde...ist jetzt egal. Hier mal ein Ansatz für dich:
Oracle auf VMW Stand 2017
Ich hoffe, du kannst damit was anfangen...
Grüße
Uwe
auch wenn es drei mal gepostet wurde...ist jetzt egal. Hier mal ein Ansatz für dich:
Oracle auf VMW Stand 2017
Ich hoffe, du kannst damit was anfangen...
Grüße
Uwe
moin...
also bei dir, 2 Sockel und jeweils 1 Core! der rest wird nicht genutzt! da muss nix eingestellt werden!
was nutzt ihr den? Medistar...?
Wir müssen jetzt diesen einen Server von dieser Umgebung so kappen dass es rechtlich in Ordnung ist und er nur auf 2 Sockel zugreift.
kannst du doch so einstellen... wo ist das Problem?
Müssen wir ne seperate Farm erstellen oder gibt eine Art "Zonen"? Gibt es andere Lösungen? Phyisikalische Lösung kommt für uns nicht in Frage.
brauchst du nicht....
Danke schonmal. Ich hoffe ich bin hier im richtigen Themenbereich.
gerne
Frank
Zitat von @inspiratio:
Hallo zusammen,
die Thematik ist einwenig komplex. Wir haben einen Server worauf eine Oracle Datenbank läuft. Dieser Server ist virtualisiert in unsere VMWare Umgebung. Die Lizenz für Oracle umfasst 2 Sockel und jeweils 1 Core. In der VM Ware Umgebung gibt es jedoch weitaus mehr Sockel und Cores.
ja... also soweit ich das kenne, ist es so, das oracle je nach lizensierung sowiso nur das nutzt was lizensiert ist!Hallo zusammen,
die Thematik ist einwenig komplex. Wir haben einen Server worauf eine Oracle Datenbank läuft. Dieser Server ist virtualisiert in unsere VMWare Umgebung. Die Lizenz für Oracle umfasst 2 Sockel und jeweils 1 Core. In der VM Ware Umgebung gibt es jedoch weitaus mehr Sockel und Cores.
also bei dir, 2 Sockel und jeweils 1 Core! der rest wird nicht genutzt! da muss nix eingestellt werden!
was nutzt ihr den? Medistar...?
Wir müssen jetzt diesen einen Server von dieser Umgebung so kappen dass es rechtlich in Ordnung ist und er nur auf 2 Sockel zugreift.
Müssen wir ne seperate Farm erstellen oder gibt eine Art "Zonen"? Gibt es andere Lösungen? Phyisikalische Lösung kommt für uns nicht in Frage.
Danke schonmal. Ich hoffe ich bin hier im richtigen Themenbereich.
gerne
Frank
Moin,
der Ursprung der Problematik ist eigentlich der Weiterentwicklung von VMware vSphere zu verdanken. Genauer gesagt der Verschiebung von VMs über einen Cluster hinweg. Grundsätzlich musst du bei der Lizenzierung von Oracle alle ESXi Hosts betrachten.
Nicht um sonst sind viele (auch große) Unternehmen wieder zurück auf physkalische Server gegangen. Da hier klar definiert ist, was zu lizenzieren ist. Die Vor- und Nachteile liegen unabhängig von Oracle klar auf der Hand.
Hast du von Oracle die Dokumente zu Hard- und Soft Partitioning durchgelesen? Damit lässt sich recht gut definieren, wie grau dein Vorhaben im Moment ist. Gerade Techniken wie L-/V-PAR fallen unter Hard Partitioning, werden aber kaum eingesetzt. Im Gegenzug fällt Virtualisierung wie VMware, Hyper-V, etc... unter Soft Partitioning. Soft Partitioning wir nach wie vor offziell von Oracle nicht akzeptiert. Das Ganze nimmt recht komplexe Züge an...
Nachdem physikalische Server keine Option sind bleibt eigentlich nur eine separate VMware Plattform für Oracle - eigene ESXi-Server, eigene VCSA, eigenes Storage (=kein Shared). Die Planungen anschließend Oracle vorlegen und genehmigen lassen. Ob der Preis/Leistungsaufwand noch im Verhältnis steht, muss jeder selbst beantworten.
Gruß,
Dani
der Ursprung der Problematik ist eigentlich der Weiterentwicklung von VMware vSphere zu verdanken. Genauer gesagt der Verschiebung von VMs über einen Cluster hinweg. Grundsätzlich musst du bei der Lizenzierung von Oracle alle ESXi Hosts betrachten.
Nicht um sonst sind viele (auch große) Unternehmen wieder zurück auf physkalische Server gegangen. Da hier klar definiert ist, was zu lizenzieren ist. Die Vor- und Nachteile liegen unabhängig von Oracle klar auf der Hand.
Hast du von Oracle die Dokumente zu Hard- und Soft Partitioning durchgelesen? Damit lässt sich recht gut definieren, wie grau dein Vorhaben im Moment ist. Gerade Techniken wie L-/V-PAR fallen unter Hard Partitioning, werden aber kaum eingesetzt. Im Gegenzug fällt Virtualisierung wie VMware, Hyper-V, etc... unter Soft Partitioning. Soft Partitioning wir nach wie vor offziell von Oracle nicht akzeptiert. Das Ganze nimmt recht komplexe Züge an...
Nachdem physikalische Server keine Option sind bleibt eigentlich nur eine separate VMware Plattform für Oracle - eigene ESXi-Server, eigene VCSA, eigenes Storage (=kein Shared). Die Planungen anschließend Oracle vorlegen und genehmigen lassen. Ob der Preis/Leistungsaufwand noch im Verhältnis steht, muss jeder selbst beantworten.
Gruß,
Dani
auf Intel-CPUs mit aktivem Hyperthreading entsprechen 2 Threads einem Core. Und das muß man im ESX auch so einstellen, bei aktivem HT jeweils 2 vCPU einem Socket zuweisen... gibt nur böse Performanceeinbußen weil die vCPUs immer mal wieder auf nicht NUMA-lokalen Arbeitsspeicher zugreifen müssen. Davon rät VMware ausdrücklich ab, hatte ich mal in einem Whitepaper gelesen.
Eine Lizenz mit 2 Sockets und jeweils einem Core ist in der heutigen Zeit deshalb totaler Unsinn, und das wird auch ziemliches Kopfzerbrechen bringen, sowas noch auf einem physischen System einzureichten. Sollte man mal zu 2 Cores in einem Socket komvertieren lassen, was einem eine bessere Leistung bei speicherintensiven Operationen bringt.
Bezüglich Host-Affinity muß man definitiv bei Oracle nachfragen, denn einige Lizenzen werden ausdrücklich mit Host-Bindung verkauft, und (wenn auch nicht von Oracle, aber bei anderen Produkten) an Parameter gebunden, die für jeden Host eindeutig sind (z.B. eine CPU ID)
Eine Lizenz mit 2 Sockets und jeweils einem Core ist in der heutigen Zeit deshalb totaler Unsinn, und das wird auch ziemliches Kopfzerbrechen bringen, sowas noch auf einem physischen System einzureichten. Sollte man mal zu 2 Cores in einem Socket komvertieren lassen, was einem eine bessere Leistung bei speicherintensiven Operationen bringt.
Bezüglich Host-Affinity muß man definitiv bei Oracle nachfragen, denn einige Lizenzen werden ausdrücklich mit Host-Bindung verkauft, und (wenn auch nicht von Oracle, aber bei anderen Produkten) an Parameter gebunden, die für jeden Host eindeutig sind (z.B. eine CPU ID)