Understand the Configuration Process

Configuring JD Edwards disaster recovery by using OCI Full Stack Disaster Recovery is basically a three-step process: you need to create DR protection groups and then create the DR plan that includes those groups. Once these steps are complete, you then need fully implement the plan by completing a sequence of post-switchover activities. You can configure and implement a DR plan for both moving and non-moving instances, both described in this article, along with a description of the switchover process..

Implement a Disaster Recovery Protection Group and Disaster Recovery Plan for Moving Instances

Deploy moving instances, which are commonly used in cold DR topologies, in the primary region. During a disaster event, moving instances are moved from the primary region’s DR protection group to the standby region’s DR protection group. Moving instances are cost-efficient because resources in the standby region are not continuously running although, because you need to ensure they are provisioned and started in the standby region, they do require longer recovery times.

The following topics walk you through the process of configuring and implementing a DR protection group and plan for moving instances

Create Disaster Recovery Protection Group

First, create a DR protection group, associate the primary and secondary DR groups, and add members to the group. Use this procedure:

1. Log in to the OCI Console and select the primary region. From the Main Menu click Disaster Recovery then DR Protection Groups then Create DR Protection Group. Select the object storage bucket created in the Primary region as part of the prerequisites for logging purposes.
2. Switch to the standby region in the OCI Console. Create another DR protection group and associate it with the bucket created in standby, which you set up as a prerequisite.
3. Return to the primary region and select the DR protection group created there. Click Associate to establish the link with the DR group in standby region.
4. View the role assignments (primary/standby) for each DR group from the DR Protection Groups main page in the OCI Console.
5. Add members to the DR Group in primary region:
   1. Include the required volume group as a member of the DR protection group.
   2. Add compute resources and provide necessary input for the VNICs by selecting Add VNIC Mapping. VNIC settings should match the primary site as JDE stores hostnames on machine information. You can also specify valid IP addresses for the DR region to be used during compute instance spin-up.
   3. You should have created a load balancer in the standby region as part of the prerequisites. Once created, you can add as a member of the DR protection group. Associate backend sets between primary and standby regions to ensure that backends transition properly during diaster recovery.
   4. Add the database as a member to the Primary region then switch to the Secondary region and peer database as a member of DR protection.

Create Disaster Recovery Plan

A disaster recovery plan outlines the workflow from Primary region to Standby region of activities and tasks that would be carried out in the event of a switchover or failover. This section describes the process of creating a DR plan that is a member of the earlier-defined Protection group

When it runs, the DR plan results in transitioning resources (member of protection group) from the Primary region to the Standby region and vice-versa.

To create the DR plan, use this procedure:

1. Navigate to the relevant DR Protection Group. Under the Resources tab, select Create Plan.

   Note:

   • For a switchover scenario, create the plan in the Standby region.
   • For a rollback scenario, create the plan in the Primary region.
2. Once created, the DR plan includes several default steps. By default, termination steps are disabled. You can enable or disable specific steps based on your requirements.
   You can add custom actions to the plan by clicking Add Group. Use this to incorporate scripts that were created as part of your custom step execution.
3. Provide a Group Name. Choose the right sequence by selecting either Add Before or Add After, then select the group that your new step should precede or follow. Click Add Step to include the new action in the plan.
4. For each custom step, enter a Group Name and Step Name. Select the correct User-defined Step Type, depending on the location of your script. Provide any required script parameters, then click Add Step. You can add multiple steps under the same group if needed.

   Note:

   In this scenario, the region selected is Primary, as it is a movable FSDR scenario, and instances are not present in the Secondary region.
5. After validating the steps in the plan, click Execute Plan to initiate the switchover.
   If the pre-checks are successful, the DR plan will execute each step sequentially.
6. If any errors occur during the switchover process, execution will pause at the failed step. You can choose to skip the failed step and continue with the remaining steps in the plan.
7. for the rollback procedure, follow this same process; however, ensure that the plan is executed from the Primary region during rollback.

Implement a Disaster Recovery Protection Group and Disaster Recovery Plan for Non-moving Instances

Deploy non-moving instances, which are common in active-passive DR topologies, in both primary and standby regions. During DR operations, these instances are started or stopped as needed to transition service between regions. This method provides faster recovery due to pre-existing infrastructure in the standby region although it can be expensive because your infrastructure needs to be maintained in both regions.

The following topics walk you through the process of configuring and implementing a DR protection group and plans for non-moving instances.

Create Disaster Recovery Protection Group

As with moving instances, if you are working with non-moving instances, you need to create a DR protection group, rassociate the primary and secondary DR groups, and add members to the group. User this procedure:

1. Log in to the OCI Console and select the Mumbai region. From the Main Menu click Disaster Recovery then DR Protection Groups then Create DR Protection Group. Select the Object Storage bucket created in the Mumbai region as part of the prerequisites for logging purposes.
2. Add Members to the DR Group in Primary Region.
3. Switch to the Secondary region in the OCI Console. Create another DR Protection Group and associate it with the bucket created in Secondary location, which was set up as a prerequisite.
4. Add Members to the DR Group in Secondary Region. Since this is a non-moving type DR setup, all required JDE Deployment, Batch, and Web servers must already be provisioned in the secondary region.
5. Only block volumes will be replicated to the Secondary site. It is recommended to host application on block volumes.
6. To sync boot volumes on servers in Primary and Secondary location use rsync/robocopy to sync file folder between primary and secondary site if needed.
7. Return to the Primary region and select the DR protection group created there. Click Associate to establish the link with the DR group in Secondary.
8. You can view the role assignments (Primary/Secondary) for each DR group from the DR Protection Groups main page in the OCI Console.

Create Disaster Recovery Plan

Similar to a DR plan for moving instances, a DR plan for non-moving instances plan outlines the workflow of activities and tasks that would be carried out in the event of a switchover or failover from primary region to standby region. To create a DR plan for non-moving instances that is a member of the Protection group you defined in the preceding step, use this procedure.

1. Navigate to the relevant DR Protection Group. Under the Resources tab, select Create Plan.

   Note:

   • For a switchover scenario, create the plan in the Secondary region.
   • For a rollback scenario, create the plan in the Primary region .
2. You can add custom actions to the plan by clicking Add Group. Use this to incorporate scripts that were created as part of your custom step execution.
3. Create Custom scripts to start E1services in Secondary region.
4. After validating the steps in the plan, click Execute Plan to initiate the switchover.
5. If the pre-checks are successful, the DR plan will execute each step sequentially.
6. If any errors occur during the switchover process, execution will pause at the failed step. You can choose to skip the failed step and continue with the remaining steps in the plan.
7. For a rollback, use the same process; however, you need to run the plan from the Primary region during rollback.

Understand Disaster Recovery Plan Groups

JD Edwards FDSR relies on two DR plan groups:

• Pre-populated groups, which are sequential groups that vary based on the members and type of plan.
• Custom groups, which perform configuration changes to the JDE application by using custom scripts after the switchover of instances from the primary region to the secondary region.

The following topics describe how to use these groups.

Understand Pre-Populated Groups for DR Plans

The Pre-population of sequential groups vary based on the members that has been added to the DR Protection Group and type of plan. Here will discuss the steps that are populated as per Switchover Plan.

• Prechecks - Built In

  These prechecks ensure that all required resources, configurations, and permissions are in place to help prevent errors during the actual failover, failback, or test.

• Load Balancers - Update Source Backend Sets

  Removes backend servers from the backend sets that are no longer needed after the failover.

• Compute Instances – Stop

  Stops all the Instance resources that are part of DR protection group in Primary region.

• Volume Groups – Switchover

  Initiates a switchover operation for volume groups from the Primary region to the Secondary region, making the volumes on Secondary region are writable and active.

• Autonomous Databases – Switchover

  Performs a switchover of Autonomous Databases to the standby instance in the Secondary region.

• Compute Instances – Launch

  Launches compute instances in the Secondary region using pre-defined configurations.

• Load Balancers - Update Destination Backend Sets

  Updates the load balancer backend sets with backends that are launched in Secondary region.

• Volume Groups - Reverse Replication

  Reverses the direction of volume group replication so that the Secondary region now replicates data back to the Primary region to ensure continuity after failover.

• Compute Instances – Terminate

  Terminates the compute instances that are no longer needed in the Primary Region. This is optional step, which needs to manual enablement.

• Compute Instances - Remove from DR Protection Group

  Removes compute instances from the DR Protection Group to keep the group updated.

• Volume Groups – Terminate

  Deletes volume groups in the Primary region after successful switchover. This is optional step, which needs to manual enablement

• Volume Groups - Remove from DR Protection Group

  Removes volume groups from the DR Protection Group to keep the group updated.

Understand Custom Groups for the DR Plan

You can add these custom groups to perform configuration changes to the JDE application by using custom scripts after the switchover of instances from the primary region to the secondary region. This approach helps to minimize operational effort and reduce downtime.

The following groups have been included based on the architectural requirements.

• Update Enterprise Server; add this group after Compute Instance – Launch.
• Update Web Server; add this group after Update Enterprise Server.
• Update Ais Server; add this group after Update Web Server.

Follow steps 2, 3, and 4 in "Create Disaster Recovery Plan", above, to run multiple custom scripts to update JDE configuration files for the secondary region.

Complete the Post Switchover Activities

After successfully switching over to the Secondary site, perform the following activities to ensure that all services are restored and operational:

1. Log in to the DR region's virtual machines by using the private key.
2. Edit the /etc/hosts file to include the IP addresses of the DR Web, Enterprise/batch and AIS servers.
3. Log in to the Enterprise/Batch server and use tnsping to test connectivity to the database. If successful, start JD Edwards (E1) services. Perform a port test after application startup.
4. On Web and AIS servers, stop and start Weblogic service.
5. Log in to the WebLogic console. and start all associated managed servers.
6. On Secondary region load balancer, verify that the mapped backends are in an active state.
7. Perform surface-level testing of JDE web links. Once verified, release the environment to users.
8. Update softcoding for JD Edwards in AIS Connection:
   1. Log in to JDE and open P954000 application.
   2. Check for the <J**920> environment and update to the DR link: http://lb_address:port