Oracle ist kein grundsätzlicher Hinderungsgrund für den Wechsel zu Proxmox VE. Die Datenbank läuft im Gastbetriebssystem; die Zielplattform stellt CPU, Arbeitsspeicher, Netzwerk und Storage bereit. Für den produktiven Einsatz bringen Sie drei Dinge zusammen: eine passende technische Auslegung, geklärte Lizenzen und einen belastbaren Supportweg. Bei RAC planen Sie zusätzlich die gemeinsame Datenhaltung und das Verhalten bei Ausfällen. Technische Machbarkeit ist dabei von einer Herstellerfreigabe zu unterscheiden.
Lizenzumfang
Welche Systeme und Nutzungen sind abgedeckt?
Supportweg
Wer hilft bei genau dieser Konfiguration?
Betriebsnachweis
Funktioniert die Anwendung auch nach einem Ausfall?
Oracle in die neue Plattform einplanen
Der Wechsel bietet die Gelegenheit, die Datenbankumgebung passend zum tatsächlichen Bedarf auszulegen. Sie können Oracle in die Proxmox-Betriebsabläufe für Überwachung, Wartung und Kapazitätsplanung aufnehmen. Ob gemeinsame Hosts oder eine dedizierte Umgebung besser passen, ergibt sich aus Last, Verfügbarkeit und Lizenzumfang. Das Ziel ist ein System, das Ihr Infrastrukturteam und der DBA gemeinsam gut betreiben können.
- Mit einer repräsentativen Anwendung beginnen und die Zielumgebung unter realer Last erproben.
- Für die Migration Datenbankverfahren und VM-Übernahme vergleichen. Datenmenge, Versionswechsel und erlaubte Unterbrechung bestimmen den geeigneten Weg.
- Bestehende Oracle-Lizenzen und Supportvereinbarungen in die Planung einbeziehen. Der Hypervisorwechsel allein reduziert den Oracle-Lizenzbedarf nicht.
Zuerst den Oracle-Bestand aufnehmen
Eine VM-Liste reicht nicht. Erstellen Sie mit dem DBA und dem Lizenzverantwortlichen ein kurzes Bestandsblatt. Erst damit lässt sich entscheiden, ob Oracle mit dem übrigen Bestand umzieht oder eine eigene Zielumgebung braucht.
- Datenbankedition, Version, Release Update, Grid Infrastructure und Gastbetriebssystem festhalten.
- Vertragsunterlagen, Lizenzmetrik und tatsächlich genutzte Optionen erfassen. Auch Test, Entwicklung, Ersatzbetrieb und Migrationsparallelbetrieb berücksichtigen.
- Physische Hosts mit CPU-Modell und Core-Anzahl aufnehmen. Mögliche Ziele für Wartung, HA und manuelle Migration sichtbar machen.
- Datenvolumen, Spitzenlast, tolerierbare Unterbrechung und Wiederanlaufziel mit dem Anwendungsverantwortlichen vereinbaren.
CPU-Pinning ist keine Lizenzfreigabe
Die hier verlinkte Oracle Partitioning Policy ordnet nicht ausdrücklich anerkannte Verfahren dem Soft Partitioning zu. Proxmox ist darin nicht als Hard Partitioning aufgeführt. CPU-Pinning oder HA-Regeln sollten Sie deshalb nicht als von Oracle anerkannte Begrenzung des Lizenzumfangs behandeln. Die Policy bezeichnet sich selbst als nicht vertragliches Informationsdokument. Was Ihr Unternehmen tatsächlich schuldet, muss anhand Ihrer Verträge und Nutzung qualifiziert geprüft werden.
- Ein großes gemischtes Cluster vergrößert den zu prüfenden Einsatzbereich. Die Aussage „immer das ganze Cluster lizenzieren“ ersetzt aber keine Vertragsprüfung.
- Eine dedizierte Umgebung kann den Einsatz nachvollziehbarer begrenzen. Sie ist für sich genommen keine verbindliche Lizenzzusage.
Mit physischen Cores rechnen, nicht nur mit vCPUs
Für eine Processor-basierte Kalkulation müssen Lizenzumfang und CPU-Modell feststehen. Die Oracle-Tabelle nennt für viele Xeon- und EPYC-Modelle den Faktor 0,5, aber nicht pauschal für jeden Intel- oder AMD-Prozessor. Das folgende Beispiel zeigt nur den Einfluss der Host-Anzahl. Es bestimmt nicht, welche Hosts in Ihrem Vertrag zählen.
Zwei Hosts im geprüften Umfang
2 Hosts × 32 physische Cores × 0,5
32Processor-Lizenzen
im Rechenbeispiel
Sechs Hosts im geprüften Umfang
6 Hosts × 32 physische Cores × 0,5
96Processor-Lizenzen
im Rechenbeispiel
- Edition, Metrik, Optionen und Mindestmengen separat prüfen. Das Beispiel ist keine Berechnung für Standard Edition 2 oder Named User Plus.
- Hard Partitioning ist nicht ausschließlich auf Oracle-Hardware beschränkt. Die Policy nennt beispielsweise auch bestimmte IBM-Verfahren.
- Die Anleitung für Oracle Linux KVM mit OLVM ist keine Freigabe für beliebige KVM-Plattformen. Sie verlangt eine konkrete CPU-Zuordnung und schließt Live-Migration der so begrenzten VMs aus. „Zwei vCPUs sind ein Core“ ist keine allgemeine Regel für Proxmox.
Den Support vor der Migration schriftlich klären
Die öffentlich zugängliche Oracle-Matrix führt KVM mit bestimmten Oracle-Linux-Konfigurationen auf, Proxmox VE jedoch nicht als eigene Plattform. Daraus lässt sich weder eine pauschale Proxmox-Freigabe noch eine vollständige Supportablehnung ableiten. Die dort verlinkte MOS Note 249212.1 betrifft VMware. Sie ist keine belastbare Grundlage für eine Proxmox-Zusage.
- Oracle die genaue Kombination aus Datenbank, Grid Infrastructure, Gast-OS, Kernel, Proxmox-Version und Storage-Anbindung vorlegen.
- Supportumfang und mögliche Anforderungen zur Fehlernachstellung klären. Falls eine andere Plattform nötig ist: Kapazität, Lizenzen, Datenübernahme und Zeitbedarf einplanen.
- Auch die Freigabe des ERP- oder Fachanwendungsherstellers einholen. Eine funktionierende Datenbank allein genügt nicht.
Single Instance, Proxmox HA und RAC unterscheiden
Proxmox HA kann eine VM nach einem Host-Ausfall neu starten. Die Datenbank muss danach wieder verfügbar werden. RAC betreibt mehrere Datenbankinstanzen auf gemeinsamen Daten. Das sind unterschiedliche Verfahren mit unterschiedlichen Anforderungen. Übernehmen Sie RAC nicht ungeprüft aus der bisherigen Architektur, sondern gleichen Sie es mit dem Wiederanlaufziel der Anwendung ab.
- RAC ersetzt weder eine unabhängige Sicherung noch einen geprüften Wiederherstellungsweg. Auch ein gemeinsames Storage-System bleibt als Abhängigkeit zu betrachten.
Bei RAC die Datenpfade und Fehlerfälle zuerst planen
Alle RAC-Knoten benötigen einen geeigneten gemeinsamen Zugriff auf die Datenbankdateien. FC oder iSCSI können Teil der Lösung sein, sind aber nicht die einzig denkbaren Wege. Entscheidend ist die für Ihre Konfiguration unterstützte Speicheranbindung. Gemeinsamer Speicher für Proxmox-Hosts bedeutet nicht automatisch, dass mehrere Gastmaschinen sicher gleichzeitig dieselben Datenbankdisks beschreiben können.
Verbindungen und Wiederanlauf mitprüfen
Privater Interconnect
Latenz · Redundanz · Fehlerverhalten
Beide Instanzen greifen auf dieselbe Datenbank zu.
Storage-Pfade und gemeinsamen Ausfall prüfen.Unabhängige Sicherung und getesteter Wiederherstellungsweg
- Storage: Gerätekennungen, gleichzeitigen Zugriff, Schreibverhalten, Pfadausfälle und Wiederkehr der Pfade mit dem DBA prüfen. Nicht einfach dieselbe virtuelle Disk doppelt einhängen.
- Interconnect: getrennte Kommunikationswege und Redundanz planen. Latenz und Paketverluste auch unter Last und beim Ausfall eines Pfades messen.
- Platzierung: RAC-VMs auf getrennte physische Hosts verteilen. Verhalten der Affinity-Regeln bei Wartung und fehlender Restkapazität für Ihre Proxmox-Version testen.
- Fencing: Oracle Clusterware und Proxmox HA gemeinsam betrachten. Bei einem Fehler muss eindeutig sein, welche Instanz ausgeschlossen wird und wann eine VM wieder starten darf. Timeouts nicht ungeprüft aus anderen Umgebungen übernehmen.
Die Abnahme an der Anwendung festmachen
Ein erfolgreicher VM-Start ist noch keine gelungene Migration. Vereinbaren Sie mit DBA, Infrastrukturteam und Fachbereich wenige konkrete Abnahmetests. Führen Sie Fehlerproben nur in einer dafür freigegebenen Umgebung mit Sicherung, Abbruchkriterien und klarer Zuständigkeit durch.
- Normallast und Lastspitze: wichtige Geschäftsvorgänge, Batch-Laufzeiten und Antwortzeiten mit dem Ausgangssystem vergleichen. Auch die Last bei Ausfall eines Hosts berücksichtigen.
- Host-Ausfall: Datenbankverfügbarkeit, Wiederverbindung der Anwendung und tatsächliche Unterbrechung messen.
- RAC zusätzlich: Interconnect- und Storage-Pfadfehler kontrolliert testen. Clusterware-Ereignisse und Zugriffe der verbleibenden Instanz protokollieren.
- Wiederherstellung: eine geeignete Datenbanksicherung in einer getrennten Umgebung zurückspielen und fachlich prüfen. Ein Hypervisor-Snapshot allein ist kein Nachweis.
- Rückwechsel: festlegen, wie nach dem Start auf dem Ziel neu entstandene Daten erhalten bleiben. Die alte VM einfach wieder einzuschalten kann Daten verlieren.
Oracle muss nicht den gesamten VMware-Exit aufhalten
Wenn Lizenzierung oder Support noch offen sind, behandeln Sie Oracle als gesonderten Migrationsstrang. Andere Systeme können gegebenenfalls früher wechseln. Halten Sie die verbleibenden Abhängigkeiten und Kosten des Parallelbetriebs fest. Für Oracle selbst vergleichen Sie erst dann den Plattformwechsel, eine dedizierte Umgebung oder den vorläufigen Weiterbetrieb.
- Das konkrete Ergebnis der Vorbereitung: Bestandsblatt, geprüfter Lizenzumfang, dokumentierter Supportweg, Zielarchitektur und ein abgestimmter Abnahmeplan. Erst danach das Umschaltfenster verbindlich festlegen.
Diese Fragen sollten geklärt sein
- Sind Lizenzumfang und Support für die konkrete Zielkonfiguration geklärt?
- Welche Hosts dürfen die Oracle-VMs im Alltag, bei Wartung und bei Ausfällen aufnehmen?
- Sind Datenpfade, Platzierung und verbleibende Kapazität praktisch geprüft?
- Wer bestätigt, dass die Anwendung nach Umschaltung und Wiederanlauf nutzbar ist?
- Wie werden neue Daten bei einem nötigen Rückwechsel erhalten?