Informationen zur Migration einer Oracle EBS-Umgebung nach Standby-Methode mit EBS Cloud Manager
In diesem Playbook verwenden Sie Cloud Manager, um eine Standbyversion Ihrer On-Premise-Umgebung in Oracle Cloud Infrastructure (OCI) einzurichten und diese Standbydatenbank dann in die Produktion hochzustufen, um den Lift-and-Shift abzuschließen. Dieses Feature ist für EBS 12.2 und Oracle Database 19c verfügbar und verwendet die Zero Downtime Migration (ZDM) von Oracle, um den Prozess reibungsloser zu gestalten.
Architektur
Diese Lösung implementiert die folgende Architektur:
Die Architektur besteht aus folgenden Komponenten:
- Oracle E-Business Suite-Cloud-Manager
Oracle E-Business Suite Cloud Manager ist eine webbasierte Anwendung, mit der die wichtigsten Automatisierungsabläufe für Oracle E-Business Suite auf OCI gesteuert werden, einschließlich der Migration Linux-basierter Umgebungen von On-Premises, der Bereitstellung neuer Umgebungen und der Durchführung von Lebenszyklusmanagementaktivitäten.
- Anwendungsebene
Die Oracle E-Business Suite-Anwendungsebene hostet die verschiedenen Server und Servicegruppen, einschließlich Webservices, Forms-Services und dem Concurrent Processing-Server, die Geschäftslogik verarbeiten und die Kommunikation zwischen der Desktop-Ebene und der Datenbankebene verwalten.
- Oracle Database
Diese Architektur ist für Zielumgebungen gültig, die Oracle Base Database Service 19c oder Oracle Exadata Database Service 19c enthalten.
- OCI Object Storage
OCI Object Storage bietet Zugriff auf große Mengen an strukturierten und unstrukturierten Daten eines beliebigen Inhaltstyps, darunter Datenbankbackups, Analysedaten und umfangreiche Inhalte, wie Bilder und Videos. Sie können Daten sicher und sicher direkt aus Anwendungen oder aus der Cloud-Plattform speichern. Sie können den Storage skalieren, ohne dass die Performance oder Servicezuverlässigkeit beeinträchtigt wird.
Verwenden Sie den Standardspeicher für "Hot Storage", auf die Sie schnell, sofort und häufig zugreifen müssen. Verwenden Sie Archivspeicherung für "Cold Storage", die Sie über lange Zeiträume beibehalten und nur selten darauf zugreifen.
- Oracle Data Guard
Oracle Data Guard und Active Data Guard bieten ein umfassendes Set an Services, mit denen eine oder mehrere Standbydatenbanken erstellt, gewartet, verwaltet und überwacht werden können und die es Oracle-Produktionsdatenbanken ermöglichen, ohne Unterbrechung verfügbar zu bleiben. Oracle Data Guard verwaltet diese Standbydatenbanken mit In-Memory-Replikation als Kopien der Produktionsdatenbank. Wenn die Produktionsdatenbank aufgrund eines geplanten oder ungeplanten Ausfalls nicht verfügbar ist, kann Oracle Data Guard jede Standbydatenbank auf die Produktionsrolle umstellen und so die Ausfallzeit minimieren, die mit dem Ausfall verbunden ist. Oracle Active Data Guard bietet die zusätzliche Möglichkeit, Workloads mit Lesezugriffen in Standbydatenbanken auszulagern, und bietet außerdem erweiterte Datenschutzfunktionen.
Voraussetzungen erfüllen
Bevor Sie mit dieser Lösung verfahren, müssen Sie die folgenden Voraussetzungen erfüllen:
- Verbinden Sie Cloud Manager mit der Quellanwendung und Datenbankebene über SSH, entweder direkt oder über einen Bastion-Server.
- Verbinden Sie die Zielanwendungsebene mit der Quellanwendungsebene über SSH, entweder direkt oder über einen Bastion-Server.
- Prüfen Sie die Konnektivität zwischen Quell- und Zieldatenbank-Tiers, indem Sie TNSPing in beide Richtungen verwenden.
- Öffnen Sie Firewallports für die Quellanwendung und die Datenbankknoten.
- Ensure source and target hostnames and scan names are DNS resolvable from both the source and target database tiers.
- Aktivieren Sie Transparent Data Encryption (TDE) für die Quellumgebung, und verschlüsseln Sie alle Tablespaces (mit Ausnahme von TEMP) sowohl in der CDB als auch in der PDB. Nehmen Sie oratab-Einträge, Listener-Einträge auf, und verwenden Sie Oracle Managed Files (OMF) für Redo Log-Dateien. Legen Sie den Parameter dg_broker_config_file fest. Weitere Informationen zu TDE finden Sie im Oracle Advanced Security Guide 19c, auf den Sie von Explore More an anderer Stelle in diesem Playbook zugreifen können.
- Heben Sie die Festlegung des Parameters LOG_ARCHIVE_DEST auf der Quelle auf. Verwenden Sie stattdessen LOG_ARCHIVE_DEST_1.
- Behalten Sie die Datenbank unter 19c Release Update (RU) 19.21 oder höher bei. Befolgen Sie dabei die neuesten vierteljährlichen Updateanforderungen für Oracle E-Business Suite Cloud Manager. Weitere Informationen finden Sie unter "Cloud Automation Support for Database Quarterly Updates" im My Oracle Support Knowledge Document 2517025.1 "Erste Schritte mit Oracle E-Business Suite auf Oracle Cloud Infrastructure", auf das Sie von "Weitere Informationen" an anderer Stelle in diesem Playbook zugreifen können.
- Erstellen Sie einen Staging-Ordner in der Quellumgebung mit den richtigen Berechtigungen: Verwenden Sie chmod 777 für
/u01/STAGEund chmod 755 für/u01. - Ordnen Sie Betriebssysteme zwischen Quelle und Ziel ab. Wenn das Ziel Oracle Database@Azure verwendet, führen Sie die Quelldatenbank auf OL8 aus.
- Stellen Sie mindestens 2 GB temporären Speicherplatz in der Quelldatenbankebene für CDB und PDB bereit.
- Stellen Sie sicher, dass keine Adoptions-Sessions aktiv sind oder ausgeführt werden. Starten Sie keine Sessions, nachdem die Standbydatenbank erstellt wurde, da dadurch die Hochstufung nicht erfolgreich verläuft.
- Stellen Sie sicher, dass /tmp über ausreichend Speicherplatz verfügt und der sudo-Benutzer lesen und schreiben kann, da ZDM dieses Verzeichnis verwendet.
- Legen Sie Kennwörter für die APPS-, WebLogic Server-, SYS- und TDE-Verschlüsselung fest, um die Sicherheitsstandards von Oracle E-Business Suite Cloud Manager zu erfüllen.
- Ändern Sie das TDE-Wallet-Kennwort weder auf der Quelle noch auf dem Ziel, da dies bei der Hochstufung der Standbyinstanz zu Problemen führen kann.