Oracle Estate, das Sie kontrollieren können

Ihr Oracle-System läuft auf drei „Uhren“, die Sie nicht kontrollieren: Die Erneuerung des Hypervisors kam mit höheren Kosten, für die niemand budgetiert war. Das Datenbank-Supportfenster hat ein Datum. Und irgendwo über Ihnen hat sich jemand für KI eingesetzt AI, die sich auf die kritischen Daten in diesen Datenbanken verlassen muss. Jede Zeitleiste gehört einem anderen Anbieter und wird verwendet, um eine Entscheidung im Zeitplan einer anderen Person zu erzwingen.

Die Arbeit, die Red Hat und Everpure gemeinsam geleistet haben, besteht darin, diese Verbindung zu unterbrechen. Jede Ebene des Systems – Hypervisor, Betriebssystem (OS), Storage und die Datenbank selbst – sollte nach eigenem Zeitplan modernisiert werden, den Sie steuern. In den letzten zwei Jahren haben wir die Validierung entwickelt und veröffentlicht, um dies speziell für Oracle-Workloads realisierbar zu machen. In diesem Beitrag geht es darum, was wir getestet haben, was die Ergebnisse waren und was sie für die Sequenzierung in den nächsten drei Jahren bedeuten.

Oracle-Workloads auf Red Hat OpenShift Virtualization und Everpure validieren

Das Entwicklungsteam von Red Hat veröffentlichte eine vollständige Referenzarchitektur für Oracle Database 19c auf Red Hat OpenShift Virtualization, die Einzelinstanzen und Oracle Real Application Clusters (RAC) abdeckte, mit den vollständigen Testartefakten, die auf GitHub verfügbar sind. Die Validierung lief mit Funktionalität, Performance, Skalierbarkeit und Live-Migrationstests. Der Storage unter diesen Tests umfasste Everpure™ FlashArray™, das über den Portworx® Enterprise-Operator bereitgestellt wurde.

Zwei Ergebnisse sind für jeden, der eine Migration plant, am wichtigsten:

1. Live-Migration einer virtuellen Maschine (VM), auf der eine Oracle-Datenbank mit einer einzigen Instanz ausgeführt wird, die im Durchschnitt in 1 bis 2 Minuten abgeschlossen ist, und das Ergebnis hielt fest, ob die Datenbank inaktiv war oder unter produktionsähnlicher Last stand, wobei virtuelle Benutzer anhaltende Mengen gleichzeitiger Transaktionen generierten. Live-Migration ist der Vorgang, der eine Virtualisierungsplattform lebenswert macht. Knotenwartung, Neugewichtung und Hardware-Aktualisierung hängen davon ab, und sie funktioniert für Oracle auf dieser Plattform so, wie Sie sie benötigen.
2. Die Stützhaltung ist dieselbe, in der Sie bereits arbeiten. Oracle zertifiziert für das OS innerhalb der VM und nicht für den darunter liegenden Hypervisor. Oracle Database auf Red Hat Enterprise Linux (RHEL) bleibt eine vollständig unterstützte OS, und Red Hat hat umfassende, validierte Referenzarchitekturen für die Ausführung dieser Workloads – einschließlich RAC – auf OpenShift Virtualization veröffentlicht. 

3 Haltungen, 1 Plattform

Kunden kommen aus verschiedenen Startpositionen zu dieser Arbeit. Die Plattform zwingt sie nicht auf den gleichen Weg.

• Das Anwesen vor Ort halten und die alte Virtualisierungsplattform verlassen. Dies ist die Haltung, die der Verlängerungsbrief schafft. Anstatt an eine unerschwingliche Hypervisor-Verlängerung gebunden zu sein, verlagert das Migrations-Toolkit für Virtualisierung von Red Hat Oracle VMs von VMware vSphere auf OpenShift Virtualization, ohne dass der Administrator den Gast ändern muss. Die Umgebung des Datenbankadministrators am Montag sieht aus wie am Freitag. FlashArray befindet sich sowohl unter der alten als auch unter der neuen Plattform, und ActiveCluster™ kann den Storage zwischen Arrays verschieben, ohne die Datenbank herunterzufahren, was bedeutet, dass die Storage-Ebene das Migrationsfenster nie blockiert. Die Datenbank wurde nicht verschoben. Die Plattform um sie herum hat es geschafft.
• Modernisierung auf der Datenbank-eigenen Uhr. Der Upgrade-Zyklus von Oracle ist eine eigene Zwangsfunktion, und ein schlecht getestetes Upgrade ist die teuerste Art von Ausfall. Array-Snapshots liefern Ihnen sofortige, platzsparende Produktionsklone für Entwicklungs-, Test- und Performance-Umgebungen, sodass die Probe ohne eine zweite Kopie der Storage-Rechnung mit echten Daten abläuft. FlashBlade® stellt bis zu 65TB pro Stunde wieder her, sodass der Rollback-Pfad in Minuten statt am Wochenende gemessen wird. Die Plattformmigration und das Datenbank-Upgrade brechen den Wettbewerb um dasselbe Änderungsfenster ab, da keines davon abhängig ist.
• Aufbauen auf der Datenbank. Neue Services landen jetzt als Container. Die Frage ist, ob sie auf der gleichen Plattform wie das Gut oder auf einer zweiten mit eigenem Storage, Backup und Bereitschaftsrotation landen. Everpure bedient sowohl VMs als auch Container von einer Ebene aus auf denselben Arrays mit persistentem Storage. Das Team, das den VM-Bestand betreibt, und das Team, das containerisierte Services versendet, stellen die Wartung einer parallelen Infrastruktur ein. Und die letztendlichen AI-Workloads – einschließlich der Vektor- und Abruffunktionen, die in der aktuellen Generation der Oracle-Datenbank ankommen – erben dasselbe Substrat, anstatt ein neues zu verlangen.

Wert der Storage-Ebene

Eine Plattformmigration ist eine Abfolge von Momenten, in denen Daten an zwei Orten liegen, ohne Unterbrechung verschoben werden oder schneller wiederhergestellt werden müssen als die Geschäftshinweise. Dies sind Storage-Eigenschaften. Die Ergebnisse der Red Hat-Validierung zu RAC haben empirisch folgende Punkte formuliert: Externer Enterprise-Array-Storage übertraf hyperkonvergente Alternativen für die anspruchsvollsten Konfigurationen. Die Nähte bei einer Modernisierung – zwischen Hypervisoren, zwischen Datenbankversionen und zwischen VM und Container – sind genau dort, wo die Storage-Plattform entweder die Uhren entkoppelt oder sie wieder zusammenfasst.

Die Everpure Evergreen®-Architektur erweitert die gleiche Logik auf den Storage selbst. Das Array unter Ihrem Oracle-System wird unterbrechungsfrei über Controller-Generationen hinweg aufgerüstet, wodurch die Ein-Uhr-Infrastrukturteams entfernt werden, die traditionell allen anderen auferlegt werden: die Komplettaustausch-Aktualisierung.

Was ist damit zu tun?

Beginnen Sie mit der Naht, die mit einem Datum versehen ist. Wenn es sich bei diesem Datum um eine Hypervisor-Verlängerung handelt, führen Sie das Migrations-Toolkit von Red Hat für die Virtualisierung mit einer Oracle VM aus, die nicht in der Produktion ist, und messen Sie das Ergebnis mit der veröffentlichten Referenzarchitektur. Wenn es sich bei diesem Datum um ein Datenbank-Supportfenster handelt, erstellen Sie in diesem Quartal die Probenumgebung aus Snapshots und stellen Sie Ihren Wiederherstellungspfad ein. Beide Übungen kosten Tage und wandeln eine externe Frist in einen gemessenen Plan um.

Das Anwesen, das Sie 2029 betreiben, wird nicht wie das aussehen, das Sie heute betreiben. Die obige Arbeit bedeutet, dass Sie entscheiden können, in welcher Reihenfolge sie sich ändert.

Weitere Informationen finden Sie in diesen Ressourcen:

• Oracle-Datenbank-Workloads auf OpenShift-Virtualisierungsreferenzarchitektur
• Moderne Virtualisierungsinfrastruktur mit Red Hat und Portworx
• Partnerschaft zwischen Oracle und Everpure
• Oracle-Datenbanklösungen: Nutzen Sie mit Everpure den wahren Mehrwert Ihrer Oracle-Daten