JD Edwards Disaster Recovery mit OCI Full Stack Disaster Recovery konfigurieren

JD Edwards-Architektur

In dieser Abbildung wird die Deployment-Architektur der JD Edwards-Anwendung dargestellt, die sowohl primäre als auch sekundäre Regionen umfasst.

Beschreibung der Abbildung jdr-dr-fsdr.png

jde-dr-fsdr-oracle.zip

Primärbereich

In der primären Region wird die JDE-Umgebung in einem virtuellen Cloud-Netzwerk (Virtual Cloud Network, VCN) bereitgestellt, das in drei dedizierte Subnetze unterteilt ist, die nach Anwendungsressourcenfunktionalität getrennt sind, wie unten beschrieben.

Load Balancer-Tier
Die Load-Balancer-Ebene hostet den OCI-Load-Balancer, der Endbenutzern Zugriff auf JDE-Webservices bietet.
Application Tier
Die Application Tier enthält die Kernanwendungskomponenten, einschließlich Enterprise Server, Webserver und Application Interface Services-(AIS-)Server
Managementebene
Die Management-Tier umfasst Tools und Services für die JDE-Verwaltung und -Administration, wie den Deployment-Server und den Server der Server Manager Console
Datenbankebene
In der Datenbankebene wird die JDE-Datenbank auf Autonomous Transaction Processing – Shared (ATP-S) bereitgestellt. Anwendungsserver melden sich mit Endpunkten bei der Datenbank an. Oracle Autonomous Data Guard ist aktiviert, erstellt eine Standbydatenbank in der sekundären Region und stellt die Echtzeitdatenreplikation für High Availability und Disaster Recovery sicher.
Speicherung und Datenschutz
Die von Compute-Instanzen verwendeten Block-Volume-Gruppen werden durch regionsübergreifende Volume-Gruppenreplikation geschützt, wobei die sekundäre Region als Replikationsziel konfiguriert ist.

Sekundäre Region

Die sekundäre Region dient als Disaster-Recovery-Site und spiegelt kritische Komponenten aus der primären region.It wider. Sie enthält:

Eine replizierte VCN-Struktur, die mit dem Netzwerklayout der primären Region übereinstimmt.
Ein Replikat-Load Balancer, um die Kontinuität des Zugriffs während des Failovers sicherzustellen.
Eine Standby-ATP-S-Datenbank, die mit Autonomous Data Guard mit der Primärdatenbank synchronisiert wird.
Replikate von Volume-Gruppen, die bei einem Ausfall der primären Region die Datenverfügbarkeit sicherstellen.

Konfigurationsbezogene JD Edwards-Dateien verstehen

JDE verlässt sich auf mehrere Konfigurationsdateien, um die Konnektivität zwischen seinen Komponenten und anderen beteiligten Ebenen, wie Datenbanken und Authentifizierungsservices, zu verwalten. Diese Dateien spielen eine entscheidende Rolle bei der Definition von Verbindungsparametern, Laufzeiteinstellungen und Integrationsverhalten. Ein angemessenes Verständnis dieser Dateien und ihrer Inhalte ist bei der Konfiguration des Disaster Recovery-(DR-)Szenarios unerlässlich, um eine nahtlose Anwendungsfunktionalität sicherzustellen.

Im Folgenden finden Sie eine Übersicht der Schlüsselkonfigurationsdateien:

sqlnet.ora

Zweck: Speichert die Oracle Wallet-Konfiguration, mit der die Anwendung eine sichere Verbindung zur Datenbank herstellt.

Speicherort: JDE Enterprise/Batch-Server. Soll

Hinweis: Stellen Sie sicher, dass der Wallet-Pfad auf den gültigen Wallet-Speicherort der DR-Datenbank verweist.

Dateipfad: Oracle_ClientHome/network/admin

tnsnames.ora

Zweck: Speichert Net Service Names, die als Aliasnamen für Datenbanknetzwerkadressen fungieren.

Speicherort: JDE Enterprise-, Batch- und Webserver.

DR-Überlegung: Aktualisieren Sie mit der richtigen Netzwerkadresse (FQDN/IP) der DR-Datenbank.

Dateipfad auf Enterprise-/Batch-Servern: Oracle_ClientHome/network/admin

Dateipfad auf Webservern: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jde.ini

Zweck: Speichert die Laufzeitkonfiguration für die JDE-Anwendung, einschließlich Datenbankverbindungsdetails und Sicherheitseinstellungen.

Speicherort: JDE Enterprise- und Batch-Server.

DR-Überlegung: Aktualisieren Sie den Abschnitt DB SYSTEM SETTINGS mit dem richtigen Servernamen für die DR-Umgebung.

Dateipfad: JDE_HOME/e920/ini

jdbj.ini

Zweck: Enthält JDBj-Treibereinstellungen und Datenbankverbindungsparameter für JDE-Anwendungen.

Speicherort: JDE Web- und AIS-Server.

DR Überlegung: Stellen Sie sicher, dass der korrekte Servername im Abschnitt JDBj-BOOTSTRAP DATA SOURCE angegeben ist.

Dateipfad: SM_Agent_Home/SCFHA/Target/Managed Instance/config

jas.ini

Zweck: Speichert die Konfiguration für die HTML-Serverkomponente von EnterpriseOne-Webclients.

Speicherort: JDE-Webserver.

DR-Überlegung: Aktualisieren Sie Folgendes:

FORMSERVICE-Abschnitt mit dem richtigen AIS-Host und -Port.
Abschnitt Security mit der entsprechenden OracleAccessSSOSignOffURL, wenn SSO aktiviert ist.

Dateipfad: SM_Agent_Home/SCFHA/Target/Managed Instance/config

rest.ini

Zweck: Speichert die Konfiguration für den AIS-Server, einschließlich REST-API-Pfaden, Authentifizierungseinstellungen und JAS-Serverlinks.

Speicherort: JDE AIS-Server.

DR-Überlegung: Aktualisieren Sie Folgendes:

Abschnitt BASIC CONFIG mit dem richtigen JAS-Host und -Port.
Security-Abschnitt mit dem aktualisierten IDCSSSOSignOffURL, wenn SSO aktiviert ist.

Dateipfad: SM_Agent_Home/SCFHA/Target/Managed Instance/config

Verwaltung-console.xml

Zweck: Diese XML-Datei enthält Informationen über die verschiedenen Server, ihre Konfigurationen und Benutzerzugriffsberechtigungen.

Speicherort: Server Manager-Server

DR-Überlegung: Stellen Sie sicher, dass der korrekte Hostname in der management-console.xml angegeben ist

Dateipfad: SM_Console_Home/SCFMC/targets/home

Agent. Eigenschaften

Zweck: Konfigurationsdatei mit Einstellungen für den Management Agent, eine Komponente, die mit der Managementkonsole interagiert und EnterpriseOne-Server verwaltet

Speicherort: Server Manager-Server

DR Überlegung: Stellen Sie sicher, dass der richtige Servername im Abschnitt agent.properties angegeben ist.

Dateipfad: SM_Console_Home/ SCFMC/config

Zusätzliche Updates auf Systemebene

Zusätzlich zu den Anwendungskonfigurationsdateien sollten die folgenden Systemdateien während einer DR-Implementierung geprüft und aktualisiert werden:

Linux-Hosts und fstab-Dateien: Stellen Sie sicher, dass gültige IP-Adressen und FQDNs definiert sind.
Windows-Hostdatei: Aktualisieren Sie die Datei nach Bedarf mit aktuellen IP- und FQDN-Zuordnungen.
WebLogic-Wallet-Dateien: Sie müssen aktualisiert werden, um das DR-spezifische Datenbank-Wallet wiederzugeben und die Konnektivität sicherzustellen, wenn die Datenbank autonom ist.

Die ordnungsgemäße Verwaltung und Aktualisierung dieser Konfigurationsdateien stellt sicher, dass JDE in einer Disaster-Recovery-Umgebung weiterhin ordnungsgemäß funktioniert, wodurch Ausfallzeiten minimiert und eine sichere, konsistente Anwendungskonnektivität aufrechterhalten wird.

Full Stack Disaster Recovery - Konzepte

Bei der Konfiguration und Implementierung von FSDR müssen Sie die folgenden Konzepte und Terminologien verstehen.

DR-Schutzgruppe
- Definition: Eine DR-Schutzgruppe umfasst alle erforderlichen OCI-Ressourcen, wie Compute-Instanzen, Volume-Gruppen, Load Balancer und Datenbanken, die zusammen einen vollständigen Anwendungsstack bilden.
- Vorteil: Eine DR-Schutzgruppe wird als eine Einheit für Failover, Failback und Testszenarien behandelt. Es stellt sicher, dass alle Ressourcen zusammen wiederhergestellt werden, was Ausfallzeiten und Datenverlust minimiert.
DR-Plan
Ein DR-Plan ist ein automatisiertes Runbook, das von FSDR erstellt wurde, um ein Disast Recovery für alle Ressourcen in der primären DR-Schutzgruppe auszuführen. Sie besteht aus Schritten, die definieren, wie alle Ressourcen in einer primären DR-Schutzgruppenregion in die sekundäre DR-Schutzgruppenregion des Peers überführt werden. Es gibt folgende Arten von DR-Plänen:
- Failover (ungeplant): Verwenden Sie einen Failover-Plan, wenn Sie einen sofortigen Übergang ausführen möchten, indem Sie den Anwendungsstack in der Standbyregion hochfahren, ohne zu versuchen, den Service in der primären Region herunterzufahren. Failover-Pläne werden im Allgemeinen zur Ausführung von DR-Übergängen verwendet, wenn ein Ausfall oder ein Notfall in der primären Region auftritt.
- Switchover (geplant): Verwenden Sie einen Switchover-Plan, wenn Sie einen ordnungsgemäßen Übergang ausführen möchten, indem der Anwendungsstack in der primären Region heruntergefahren und dann in der Standbyregion hochgefahren wird. Switchover-Pläne werden in der Regel für geplante Sitewartung, Software-Patching, DR-Tests und zur Validierung verwendet.
- Startdrill: Ein Startdrill generiert einen Plan zur Ausführung des DR-Drillings, ohne die primären DR-Schutzgruppenressourcen zu unterbrechen. Es erstellt ein Replikat von Ressourcen in der Standby-DR-Schutzgruppe.
- Drilldown stoppen: Dieser DR-Plan stoppt den DR-Drill, indem das Replikat der Ressourcen entfernt wird, die durch den Startdrill erstellt wurden.
Zu verschiebende Instanz
- Definition: Instanzen, die nur in der primären Region bereitgestellt werden.
- Use Case: Common in cold DR topologies, wherein very few or none of the components of an application or service need to be pre-deployed in the standby region in preparation for a future DR transition.
- Verhalten: Während eines Disaster-Ereignisses werden das Verschieben von Instanzen von der DR-Schutzgruppe der Primärregion in die DR-Schutzgruppe der Standbyregion verschoben.
- Vorteil: Kosteneffizienz, da Ressourcen in der Standbyregion nicht kontinuierlich ausgeführt werden.
- Hinweis: Für diese Methode sind längere Recovery-Zeiten erforderlich, da Instanzen in der Standbyregion bereitgestellt und gestartet werden müssen.
Nicht zu verschiebende Instanz
- Definition: Instanzen, die in Primär- und Standbyregionen vorab bereitgestellt werden.
- Anwendungsfall: Allgemein in active-passive DR-Topologien, bei denen einige oder alle Komponenten einer Anwendung oder eines Service in der Standbyregion vorab bereitgestellt werden, um einen zukünftigen DR-Übergang vorzubereiten.
- Verhalten: Während DR-Vorgängen werden diese Instanzen nach Bedarf gestartet oder gestoppt, um den Service zwischen Regionen zu wechseln.
- Vorteil: Diese Methode ermöglicht ein schnelleres Recovery aufgrund einer bereits vorhandenen Infrastruktur in der Standbyregion.
- Hinweise: Dies kann zu höheren Kosten führen, da die Infrastruktur in beiden Regionen gewartet werden muss.

Full Stack Disaster Recovery – Voraussetzungen

Bevor Sie mit dem FSDR-Prozess fortfahren können, müssen Sie die folgenden Voraussetzungen erfüllen:

Stellen Sie ein VCN, Subnetze, Routentabellen, Sicherheitslisten und Netzwerkgateways in der DR-Region bereit. Um Failover-Funktionalität und -Konnektivität zu unterstützen, stellen Sie sicher, dass die Netzwerkkonfigurationen die in der primären Region widerspiegeln.
Definieren Sie eine dynamische Gruppe, um Policys zuzulassen, die Instanzen, die als Teil der DR-Umgebung erstellt wurden, Administratorberechtigungen erteilen.
Sie benötigen Administratorrechte, um Skripte auf Compute-Instanzen auszuführen. Das Plug-in "Befehl ausführen" verwendet den Benutzer ocarun, um diese Skripte auszuführen. Stellen Sie sicher, dass dieser Benutzer über die entsprechenden Berechtigungen verfügt.
1. Öffnen Sie oracle-cloud-agent-run-command zur Bearbeitung:
```
 vi ./101-oracle-cloud-agent-run-command
```
2. Fügen Sie die folgenden Zeilen in der Konfigurationsdatei hinzu:
```
ocarun ALL=(ALL) 
NOPASSWD:ALL
```
3. Führen Sie anschließend Folgendes aus:
```
vi sudo -cf ./101-oracle-cloud-agent-run-command
```
4. Fügen Sie die Konfigurationsdatei zu /etc/sudoers.d hinzu:
```
sudo cp ./101-oracle-cloud-agent-run-command /etc/sudoers.d/
```
Regionsübergreifende Backupfunktion für Volume-Gruppen aktivieren.
Stellen Sie einen Load Balancer in der sekundären Region bereit. Im Rahmen der FSDR-Konfiguration wird nur das Backend-Set (Instanzen) von der Primär- in die Standbyregion verschoben. Der Load Balancer selbst muss zuvor manuell in der Standbyregion erstellt werden.
Richten Sie eine entsprechende (Peer-)Datenbankinstanz in der DR-Region ein, um das Anwendungs-Failover zu unterstützen.
Erstellen Sie einen Objektspeicher-Bucket für Logs in der primären Region. In diesem Bucket werden DR-Logs und Artefakte für die Umgebung gespeichert.
Erstellen Sie einen zusätzlichen Objektspeicher-Bucket in der Standbyregion. Dieser Bucket wird zu Replikations- oder Loggingzwecken verwendet, um die DR-Bereitschaft in der Standbyregion sicherzustellen.
Platzieren Sie die folgenden benutzerdefinierten Skripte an der richtigen Stelle.

Benutzerdefinierte Skripts anwenden

Diese benutzerdefinierten Skripte werden während des FSDR-Prozesses ausgeführt.

update_rest

Anwendbarer Server: AIS

#Define the old and new file names
old_file1="rest_dr.ini"
new_file1="rest.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"
 # Copy the new second file back to the original name, preserving attributes
 cp -p "$new_file1" "$old_file1"
 echo "Copied $new_file1 back to $old_file1 (preserving attributes)"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_tnsnames_jdbj

Anwendbare Server: JAS, AIS

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="jdbj_dr.ini"
old_file3="jas_dr.ini"
new_file1="tnsnames.ora"
new_file2="jdbj.ini"
new_file3="jas.ini"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"

 # Rename the third file
 mv "$old_file3" "$new_file3"
 echo "Renamed $old_file3 to $new_file3"

else
 echo "One or both of the old files do not exist in the folder."
fi

update_wallet

Anwendbare Server: Alle JDE-Server (Enterprise, AIS, JAS, Fatclient, Integrationen usw.)

# Define old and new wallet folder names
old_wallet="Wallet_jdeorcl_hyderabad"
new_wallet="Wallet_jdeorcl"

# Check if the old wallet directory exists
if [ -d "$old_wallet" ]; then
  # Remove any existing new_wallet directory to avoid conflict
  if [ -d "$new_wallet" ]; then
    echo "Removing existing $new_wallet directory..."
    rm -rf "$new_wallet"
  fi

  # Rename the old wallet to the new name
  mv "$old_wallet" "$new_wallet"
  echo "Renamed $old_wallet to $new_wallet"

  # Copy the new wallet back to the old wallet directory for reuse
  cp -r "$new_wallet" "$old_wallet"
  echo "Copied $new_wallet back to $old_wallet for reuse"

else
  echo "Directory $old_wallet does not exist. Aborting operation."
fi

update_ini

Anwendbarer Server: Enterprise

# Define the old and new file names
old_file2="JDE_DR.INI"
old_file3="jdbj_dr.ini"
new_file2="JDE.INI"
new_file3="jdbj.ini"

# Check if the old files exist in the folder
if [ -e "$old_file2" ] && [ -e "$old_file3" ] ; then
    # Rename the second file
    mv "$old_file2" "$new_file2"
    echo "Renamed $old_file2 to $new_file2"

    # Rename the third file
    mv "$old_file3" "$new_file3"
    echo "Renamed $old_file3 to $new_file3"
else
    echo "Old files do not exist in the folder."
fi

update_tnsnames_sqlnet

Anwendbare Server: Enterprise, Deployment, Fatclients

#Define the old and new file names
old_file1="tnsnames_dr.ora"
old_file2="sqlnet_dr.ora"
new_file1="tnsnames.ora"
new_file2="sqlnet.ora"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
 # Rename the first file
 mv "$old_file1" "$new_file1"
 echo "Renamed $old_file1 to $new_file1"

 # Rename the second file
 mv "$old_file2" "$new_file2"
 echo "Renamed $old_file2 to $new_file2"
else
 echo "One or both of the old files do not exist in the folder."
fi

update_agent_properties

Anwendbare Server: Alle von Server Manager verwalteten Server

# Define the old and new file names
old_file1="agent.properties"
new_file1="agent_dr.properties"

# Check if the old files exist in the folder
if [ -e "$old_file1" ] && [ -e "$old_file2" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi

update_management_console

Anwendbarer Server: Sever Manager

# Define the old and new file names
old_file1="management-console_dr.xml"
new_file1="management-console.xml"

# Check if the old files exist in the folder
if [ -e "$old_file1" ]; then
# Rename the first file
mv "$old_file1" "$new_file1"
echo "Renamed $old_file1 to $new_file1"
else
echo "One or both of the old files do not exist in the folder."
fi