AWS Cloud-Migration für Oracle: Diese Wege gibt es

AWS Cloud-Migration für Oracle: Diese Wege gibt es

Fast alle IT-Entscheider sehen sich heute mit der Aufgabe konfrontiert, Workloads und damit auch Datenbanken in die Cloud zu migrieren, um ihre IT effizienter und kostengünstiger aufzustellen und ihre Transformation voranzutreiben. Zur Migrationsplanung gehört aber stets auch die Entscheidung, was genau dabei mit konkreten Workloads geschehen soll: Einfach in die Cloud schieben? Modernisieren? Oder vielleicht doch gleich ersetzen? 

Immer mehr CIOs erwägen die Nutzung von Open-Source-Software, um hohe Lizenzgebühren, finanzielle Risiken durch Audits oder Vendor-Lock-in zu vermeiden. Nicht selten betrifft das auch Anwender von Oracle Database. Oft ist für diese ihre Cloud-Journey auch ein Anlass, nach Open-Source-Alternativen zu Oracle Ausschau zu halten. In diesem Beitrag sprechen wir darüber, welche verschiedenen Wege Oracle-Anwendern bei einer Cloud-Migration offenstehen, und fragen dabei auch nach Optionen jenseits von Oracle – zum Beispiel PostgreSQL. 

Cloud-Migrationsstrategien für Oracle: die 7 Rs: 

Wenn Sie als Oracle Anwender Ihre Datenbank in die Cloud umziehen wollen, steht Ihnen eine Reihe von Optionen offen. Wie bei jeder Cloud-Migration gibt es grundsätzlich die bekannten Migrationsstrategien der „7 Rs“ (siehe Abbildung). Wir erläutern diese Strategien am Beispiel von AWS, dem Marktführer bei Public-Cloud-Services: 

 

Rehost (Lift and Shift): Verschieben Sie Ihre lokale Oracle-Datenbank ohne Änderungen auf eine virtuelle Maschine (VM) in der Cloud, zum Beispiel eine EC2-Instanz (Amazon Elastic Compute Cloud). 

 

Relocate (Lift and Shift auf Hypervisor-Ebene): Setzen Sie eine mit VMware virtualisierte Oracle Datenbank ein, können Sie sie nach VMware Cloud on AWS verschieben. 

 

Replatform (Lift and Reshape): Wollen Sie Ihre lokale Oracle-Datenbank ohne größere Änderungen in die AWS-Cloud verschieben und trotzdem bereits von Cloud-Vorteilen profitieren? Dafür können Sie Amazon Relational Database Service (RDS) for Oracle nutzen (Platform as a Service, PaaS). 

 

Repurchase (Drop and Shop): Nicht selten ist es sinnvoll, eine neue Lösung anzuschaffen, die Vorteile gegenüber Oracle hat und womöglich auch schon in der Cloud läuft (Software-as-a-Service, SaaS), und nur die vorhandenen Daten aus Oracle in die neue Datenbank zu migrieren. 

 

Refactor/Rearchitect (neue Architektur): Diese Strategie meint meist eine Neuentwicklung oder Überarbeitung mit substanziellen Änderungen an Architektur und Code. Im Falle von Oracle liegt allerdings der Umstieg auf eine andere Architektur näher, um die Vorteile Cloud-nativer Funktionen zu nutzen, z. B. mit Amazon Aurora.  

 

Zu diesen fünf Strategien kommen noch zwei, die wir der Vollständigkeit halber aufführen, die aber eigentlich keine Migration darstellen: 

 

Retain (Beibehalten): Es besteht natürlich immer die Möglichkeit, für ausgewählte Workloads die bewährte On-premises-Umgebung weiter zu nutzen (etwa um aufwendige Optimierungen auf einen späteren Zeitpunkt zu verschieben).  

 

Retire (Ausmustern): Wird eine Anwendung oder ein Service nicht mehr unbedingt benötigt, muss sie auch nicht migriert werden – Sie können sie einfach stilllegen. 

 

Lift and Shift und Replatform sind zumindest in unseren Kundenprojekten die meistgenutzte Option, gefolgt von Retire und dem Umstieg auf SaaS (Repurchase). Bei etwa zehn Prozent der migrierten Workloads setzen Anwender auf Modernisierung im engeren Sinne (Refactor/Rearchitect) – nämlich dort, wo Aufwand und Nutzen im günstigsten Verhältnis stehen. Auch für viele Oracle Anwender ist eine heterogene Datenbankmigration, also der Wechsel zu einem anderen Datenbank-Managementsystem (DBMS), eine attraktive Option.

Warum migrieren Oracle Anwender auf eine andere Datenbank?

 

Datenbanken sind unternehmenskritische Systeme; eine Migration will gut überlegt sein. Aber es gibt doch einige Gründe, warum viele Oracle Database-Anwender auf ein anderes DBMS umsteigen möchten. Einer der wichtigsten: die Kosten. Zu den hohen Lizenzkosten, bei denen zudem viele Optionen nur gegen Aufpreis erhältlich sind, kommen noch obligatorische Supportkosten hinzu (die sogar für ungenutzte Lizenzen fällig werden). Außerdem ändert Oracle immer wieder seine Lizenzbedingungen, meist zu Ungunsten des Kunden. 

 

Damit sind auch finanzielle und rechtliche Risiken verbunden. Oracle behält sich das Recht für Lizenzaudits vor und überprüft regelmäßig, ob Anwender alle Workloads vertragsgemäß lizenziert haben. Fast immer sind Mehrkosten die Folge – die wenigsten der Geprüften sind vollständig compliant. Oracle verwendet erhebliche Ressourcen und Kreativität darauf, Lizenzverstöße festzustellen, und ist auch nicht zimperlich, wenn es um die rechtliche Durchsetzung vermeintlicher Ansprüche geht. Die auf geistiges Eigentum und Lizenzrecht spezialisierte Anwaltskanzlei Tactical Law Group betreibt einen eigenen Blog zum Thema Oracle-Audits und beschäftigt sich mit zahlreichen Klagen des Softwareherstellers, darunter 11 Verfahren allein in 2021. 

 

Mangelnde Flexibilität und Vendor Lock-in 

 

Auch die Flexibilität leidet unter der Preispolitik des Anbieters, der die Kunst des „Vendor Lock-in“ perfektioniert hat. Zum Beispiel soll, wer keine „Named-User-Plus“-Lizenz nutzt, Lizenzkosten für alle Prozessoren zahlen, die er theoretisch für Oracle Workloads nutzen könnte (Soft Partitioning). Bei der Virtualisierungstechnologie von VMware kann das (ab vCenter Server 6.0) im Zweifel die komplette IT-Infrastruktur betreffen, weil Ressourcen dort per „Live Migration“ instanzenübergreifend genutzt werden können, egal ob auf dem gerade genutzten Knoten Oracle überhaupt installiert ist. Anwender, die Oracle Virtualisierung nutzen, haben dieses Problem nicht. 

 

Wer mit seiner Oracle Datenbank in die Public Cloud umziehen möchte, bekommt die Einschränkungen besonders zu spüren. Denn Oracle möchte Kunden in der eigenen Oracle Cloud Infrastructure halten und gestaltet seine Lizenzbedingungen entsprechend ungünstig für Drittanbieter (mehr Informationen). Zudem drohen unerwartete Zusatzkosten, weil es Anwendern in der Public Cloud, gerade auch in Amazon Web Services (AWS), sehr einfach gemacht wird, zusätzliche Datenbankfunktionen zu aktivieren. 

Repurchase oder Refactor? Die Optionen am Beispiel von PostgreSQL 

 

Wer die Gelegenheit der Cloud-Migration zu AWS nutzen möchte, auf eine neue Datenbank in der AWS Cloud umzusteigen, also eine heterogene Datenbankmigration anstrebt, hat insbesondere die Wahl zwischen den Migrationsstrategien Repurchase und Refactor: 

 

Repurchase meint hier in der Regel den Umstieg von Oracle auf eine andere relationale Datenbank, meist eine Open-Source-Datenbank (z. B. PostgreSQL, MySQL, MariaDB). 

 

Refactor/Rearchitect läuft auf den Umstieg auf einen cloud-nativen AWS Datenbank-Service hinaus: als relationale Datenbank (z. B. Amazon Aurora), als NoSQL-Datenbank (Amazon DynamoDB) oder als Data Warehouse (Amazon Redshift). 

 

Häufig entscheiden sich Organisationen, von Oracle auf PostgreSQL zu wechseln – aufgrund der relativen technischen Nähe beider Datenbanktechnologien eine sinnvolle Wahl. PostgreSQL, kurz Postgres, ist ein schlankes, modulares und leistungsfähiges Datenbankmanagementsystem, das seit den 1980er Jahren entwickelt wird, seit 1996 als Open Source. Wie Oracle unterstützt es objektrelationale Daten, Trigger sowie Prozeduren und kommt bereits in Tausenden businesskritischen Anwendungen zum Einsatz.  

 

Auf AWS ist PostgreSQL mit beiden genannten R-Optionen möglich: Sie können PostgreSQL auf einer EC2-Instanz installieren (Repurchase) oder die komplett gemanagten Datenbankservices von AWS nutzen (Refactor/Rearchitect): entweder PostgreSQL auf Amazon RDS oder Amazon Aurora PostgreSQL für höhere Ansprüche an Performance, Skalierbarkeit und Verfügbarkeit.  

 

Die Installation von PostgreSQL auf Amazon EC2 ist die preiswerteste Option. Sie installieren und verwalten Ihre Datenbank auf einer VM in Amazon EC2, haben Zugriff auf sämtliche Konfigurationsmöglichkeiten inkl. Server-Betriebssystem, müssen sich aber selbst um Updates und Funktionen wie Hochverfügbarkeit, Backups oder Streaming Replication für bessere Skalierbarkeit kümmern.  

 

PostgreSQL auf Amazon RDS: Amazon RDS erleichtert das Einrichten, Betreiben und Skalieren relationaler Datenbanken in der AWS-Cloud (EC2) und nimmt Anwendern die meisten Admin-Aufgaben ab. Mit Funktionen wie automatisierten Backups, Replikation zur Skalierung sowie Multi-AZ-Bereitstellung (synchron über verschiedene Availability Zones) und automatischem Failover für Hochverfügbarkeit und Disaster Recovery ist er für wartungsarme Produktivumgebungen bestens geeignet. 

 

Amazon Aurora PostgreSQL: Amazon Aurora PostgreSQL nutzt ein performanteres Speichersystem: Statt EBS-Volumes (Amazon Elastic Block Storage) für jede Datenbank-Instanz nutzt es dynamischen Speicher, der Replikationen, Failover, Recovery sowie Workloads mit hohem Parallel-Durchsatz erheblich beschleunigt. Es bietet einige zusätzliche Funktionen (u. a. Datenbank-Klonen, Serverless, regionenübergreifende Datenbanken), aber weniger kleine Instanzen. Für Umsteiger von kommerziellen Datenbank-Engines wie Oracle bietet Aurora PostgreSQL lt. AWS die gleiche Leistung zu einem niedrigeren Preis. Hinweise zur Auswahl der für Sie geeigneten Service-Option finden Sie in diesem AWS Beitrag: Ist Amazon RDS for PostgreSQL oder Amazon Aurora PostgreSQL die bessere Wahl für mich?

 

Für die Migration Ihrer Oracle-Daten zu PostgreSQL steht eine Reihe von Werkzeugen zur Verfügung, zum Beispiel der AWS Database Migration Service (AWS DMS). AWS DMS ist ein verwalteter Migrations- und Replikationsservice von AWS, mit dem Sie AWS zufolge Datenbank- und Analyse-Workloads schnell, mit minimalen Ausfallzeiten und ohne Datenverlust zu AWS verlagern können.

Sie möchten mehr erfahren?

 

Unser Whitepaper „Datenbank-Migration und Modernisierung: So migrieren Sie Ihre Oracle-Datenbank nach PostgreSQL auf AWS“ zeigt Alternativen für migrationswillige Oracle Kunden auf, beschreibt das Vorgehen bei der Cloud-Migration nach PostgreSQL auf AWS, benennt kritische Erfolgsfaktoren und erklärt, wie Sie Ihre Datenbankmigration in die Cloud beschleunigen, Risiken reduzieren und Unterstützung erhalten können.