Configuring Disaster Recovery

This document provides an architectural view of an Active-Passive configuration with two Visual Builder (VB) instances, or two OIC instances that include VB, for a High Availability (HA) Disaster Recovery (DR) solution.

It also provides a procedure for setting up the system. In this document, the "active" instance is sometimes referred to as the "primary" instance, and the "passive" instance is usually referred to as the "standby" instance for the failover scenario.

Supported Scenario

If you have a live VB application that is deployed on an active instance, and a failover necessitates switching to the standby instance, your application will continue to execute with the understanding that both Identity Cloud Service (IDCS) and the Bring Your Own Database (BYODB) Autonomous Transaction Processing (ATP) instances are functional after the failover.

High Availability Disaster Recovery Architecture Using ATP

You can configure a high-availability DR architecture solution that consists of two VB instances, active and standby, to use the BYODB configuration to the same ATP service. This diagram shows the DR architecture when you have two OIC instances that include Visual Builder:


Description of disaster-recovery.png follows
Description of the illustration disaster-recovery.png

This solution utilizes Visual Builder’s BYODB feature for the database configuration to simplify sharing your application data between the primary and standby instances and using a vanity or custom domain name for both the instances to support DNS switching in a failover scenario.

You need to create and manage your own ATP database instance. You’re also responsible for managing any additional database-specific DR setup with the ATP service. See Using a Standby Database with Autonomous Database. The primary and standby service instances both need to be updated to use the ATP database in a BYODB configuration. Once that is done, VB DevOps must make the standby instance setup point to the same schema setup in the BYODB configuration for the primary instance.

Both the primary and standby instances are configured to use the same vanity or "custom" host name for the VB service. Sharing the same host name provides a mechanism to make a DNS change to the registered CNAME for the vanity host in a failover scenario, routing traffic to the standby instance without you having to perform additional steps related to life cycle management of your published apps. That means there is no need for you to version, re-stage, and re-publish.

About the Solution: How It Works and Any Limitations

You can configure Visual Builder DR solutions for:

  • Oracle Visual Builder, Gen 2 instances
  • Visual Builder in Oracle Integration Generation 2 instances

This section provides specific details about how the DR solution works and explains its limitations.

What Makes the Solution Work?

  • In this configuration, the DNS CNAME registration for the vanity host name is used to route requests to the VB or OIC service instance front-end load balancers.
  • Two Visual Builder load balancers are configured with additional listeners (and SSL certificate) for the vanity host name.
  • In this Active-Passive failover configuration, only one of the service instances processes requests.
  • The VB Design Time and apps in the primary instance are accessed using the vanity host name.
  • The standby instance doesn’t get traffic related to the vanity host name.
  • When a switchover operation is required, you need to update your DNS CNAME registration to point to the standby instance’s front-end load balancer.
  • The data tier is set up so both instances are configured to use the BYODB feature and both point to the same schemas in the ATP database.
  • The ATP database must be configured to use the ATP service DR solution, which is a solution that is separate from the VB DR solution. See Using a Standby Database with Autonomous Database.

What Are Its Limitations?

  • Setup of ATP DR standby can have two options:
    • In the same region as the primary ATP, although likely a different Autonomous Database. This setup supports automatic failover.
    • Cross-region standby with Data Guard. This setup does not support automatic failover. You'll need to manually switch over to the cross-region standby.
  • In identity domains with built-in cross-region DR (in regions with cross-region DR enabled):
    • Identity domains replicated to other regions might not be in sync with the DR region.
    • In some cases you might not have access to the OCI Console during failover.

Set Up the Disaster Recovery Solution for Oracle Visual Builder

Follow these one-time tasks to set up the disaster recovery solution for Oracle Visual Builder:

  1. Set up your service instances:
  2. Provision an ATP database with Allow secure access from anywhere enabled. Then complete the following:
    1. If you plan to restrict access to your ATP DB instance, add security rules to allow access from both service instances.

      File a service request to get the VCN OCIDs and NAT gateway IP addresses that are required for access (ingress) rules to your ATP database. The OCIDs aren’t public and depend on your instance’s region. When you receive the VCN OCIDs and NAT gateway IP addresses, add the new rules to your ATP database’s access control settings to allow access from VB.

    2. Ensure that ATP database is configured for ATP disaster recovery. See Using a Standby Database with Autonomous Database and follow ATP best practices for setting up DR.
  3. Configure the BYODB feature in both of your service instances to use their ATP database.

    Note:

    If your configuration uses BYODB ATP with cross-region standby with Data Guard:
    1. Configure the Primary VB instance with Primary BYODB ATP.
    2. Switch over the BYODB ATP to standby. The Primary VB will not connect after this.
    3. Configure the Secondary VB instance with Secondary BYODB ATP. Use the same ATP ADMIN credentials, but a different ATP Wallet.
    4. Switch over the BYODB ATP to the primary region. The Secondary VB will not connect after this.
  4. Finally, file a service request (SR) and request VB DevOps to complete the remaining Oracle service-side-related HA-DR set up.

Post-Configuration Tasks

Once you and Visual Builder DevOps team have completed the HA DR configuration, you must also:

  • Configure the IDCS Service Applications of both service instances to have exactly the same assigned access based on groups rather than individual users.
  • Use the custom domain URL to access all Visual Builder design-time applications (creating, editing, and publishing) and for providing runtime access for your applications.

Note:

For Visual Builder on OIC instances, on the Tenant Settings page, you'll also need to update the default values for the Integration and Process server URLs to use the custom domain host name.

Documentation Accessibility

For information about Oracle's commitment to accessibility, visit the Oracle Accessibility Program website at http://www.oracle.com/pls/topic/lookup?ctx=acc&id=docacc.

Access to Oracle Support

Oracle customers that have purchased support have access to electronic support through My Oracle Support. For information, visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=info or visit http://www.oracle.com/pls/topic/lookup?ctx=acc&id=trs if you are hearing impaired.