Configure Rackware for Virtual Machine Disaster Recovery

Rackware Migration Manager (RMM) is deployed in the production site to replicate virtual machines to or from OCI andCompute Cloud@Customer.

The following Rackware architecture shows disaster recovery between OCI and Compute Cloud@Customer.

Description of rackware-dr-oracle-compute-cloud-customer-oci.png follows

Description of the illustration rackware-dr-oracle-compute-cloud-customer-oci.png

In this architecture, RMM is deployed in the production site to replicate virtual machines to or from OCI and Compute Cloud@Customer. The RMM server is deployed on OCI. The Rackware DR plan is configured on the RMM server to protect the Web and App VMs along with their attached block storage. Web and App VMs along with their block storage are replicated from OCI to Compute Cloud@Customer by Rackware.

About Configuring a Backup and Restore Architecture for OCI

The following are the configuration recommendations for configuring the backup and restore architecture for OCI :

Configure OCI as the production or primary site, and Compute Cloud@Customer as the secondary or standby site.
Configure the Rackware disaster recovery policy as Dynamically Provisioned Targets. Rackware protects your workload by maintaining a copy of the origin server's image on RMM. You can use the image to deploy an instance on the target infrastructure on demand in case of an event to significantly reduce costs and lower the RPO at the expense of higher RTO.
Rackware stops and replicates virtual machines from OCI to Compute Cloud@Customer.
Configure any production databases running OCI to replicate to standby databases on Compute Cloud@Customer. If failover is required, you can use Data Guard to promote the standby Oracle Database as well as failing back to return the Oracle Database in OCI to primary after disaster recovery efforts are complete.
Deploy OCI Storage Gateway in OCI with Cloud Sync replication properly configured and scheduled to replicate OCI Object Storage from OCI to Compute Cloud@Customer.
Use Rackware to orchestrate the disaster recovery of virtual machines between Compute Cloud@Customer and OCI during disaster recovery operations.

About Configuring a Pilot Light Architecture for OCI

The pilot light architecture is the same as the disaster recover for Compute Cloud@Customer with OCI.

The following are the configuration recommendations:

Similar to backup and restore use case, deploy RMM in the production site to replicate virtual machines to and from OCI and Compute Cloud@Customer. In this case, configure OCI as the production or primary site, and Compute Cloud@Customer as the secondary or standby site.
Configure the Rackware disaster recovery policy as Pre-Provisioned Targets. With this configuration, you can choose to protect your workloads by maintaining an active server instance on the target infrastructure in addition to the origin server's image on RMM. Configure synchronization jobs to update the image as well as the target server at user specified intervals. This approach achieves the lowest RTO but is more expensive because you have to always maintain an active disaster recovery site.
Rackware replicates the virtual machines from OCI to Compute Cloud@Customer running at a minimal scale in Compute Cloud@Customer.
Configure any production databases running OCI to replicate to standby databases on Compute Cloud@Customer. If failover is required, you can use Data Guard to promote the standby Oracle Database as well as failing back to return the Oracle Database in OCI to primary after disaster recovery efforts are complete.
Deploy OCI Storage Gateway in OCI with active Cloud Sync replication properly configured to replicate OCI Object Storage from OCI to Compute Cloud@Customer.

About Configuring a Warm Standby Architecture for OCI

The Warm Standby architecture is the same as the disaster recover for Compute Cloud@Customer with OCI.

The following are the configuration recommendations:

Deploy RMM in the production site to replicate virtual machines to or from OCI and Compute Cloud@Customer. In this case, configure OCI as the production or primary site, and Compute Cloud@Customer as the secondary or standby site.
Configure the Rackware disaster recovery policy as Pre-Provisioned Targets. With this configuration, you can choose to protect your workloads by maintaining an active server instance on the target infrastructure in addition to the origin server's image on RMM. Configure synchronization jobs to update the image as well as the target server at user specified intervals (with different periodicity). This approach achieves the lowest RTO but is more expensive because you have to always maintain an active disaster recovery site.
Rackware constantly replicates virtual machines are constantly from OCI to Compute Cloud@Customer running the same version of the OCI production environment operating in Compute Cloud@Customer.
Configure any production databases running OCI to replicate to standby databases on Compute Cloud@Customer. If failover is required, you can use Data Guard to promote the standby Oracle Database as well as failing back to return the Oracle Database in OCI to primary after disaster recovery efforts are complete.
Deploy OCI Storage Gateway in OCI with active and continuum Cloud Sync replication properly configured to replicate OCI Object Storage from OCI to Compute Cloud@Customer.

Configure Rackware for Disaster Recovery from OCI to Oracle Compute Cloud@Customer

The following are the steps-by-steps to configure RackWare to perform a disaster recovery from OCI to Oracle Compute Cloud@Customer for Linux:

For Linux platform the following configuration is recommended

Access Credentials: root user or user with sudo privileges
Storage
- Origins volume groups must have at least 15 percent of used space available as free extents.
- /var/tmp should have at least 20 MB of free space.
no-exec: /tmp and /var/tmp filesystems should not be configured with no-exec properties in fstab.
Grub: Origin servers should have /etc/default/grub file
Antivirus: If any antivirus program is running on Origin, it should add /mnt/rackware/ directory to the allowlist.

For Windows platform the following configuration is recommended:

Access Credentials: SYSTEM user or local user with administrative privileges.
Storage: Each volume should have sufficient free space (at least/approximately 20 percent) for VSS snapshots.
Antivirus: Origin should add rsync.exe, rwattr.exe, rwchangesvc.exe, and rw_tngsync_util.exe to the allowlist for any antivirus program or Windows Defender.
Language: For any language other than English for SYSTEM locale, contact Rackware support.

Follow these steps:

Assuming you already have Rackware RMM properly installed in OCI, go to the Rackware RMM management console and log in using the credentials configured during installation. Wave options can be the following:
Create a Wave: To create a wave, navigate to Replication, Waves and click on the plus (+) icon to open the wave create wizard. Provide a name and click create.
- Parallel Count: Allows user to set the number of parallel transfers within the wave.
- Auto Provision: Users can configure the RMM to provision targets via API calls to the target cloud.
- DR Policy: User can configure a policy to periodically synchronize all the hosts in the wave.
- Passthrough: When enabled, data flows via RMM. (Origin, RMM, Destination)
Configure Disaster Recovery Policy: A Disaster Recovery Policy allows you to synchronize deltas from source to its image captured on the RackWare RMM and target instance (in case of pre-provisioned scheme) at user specified intervals. Users can create as many Disaster Recovery policies as required with different periodicity. This allows greater flexibility to synchronize different waves at varied intervals based on the user's DR strategy. To create a new Disaster Recovery policy, navigate to DR, Policies and click on the plus (+) icon to open the DR create wizard. Provide a DR name, Periodicity, start time, and notification email.
Apply the Disaster recovery Policy: To apply a Disaster recovery policy, navigate to Replication tab, click on Waves, click on OCI to C3 wave details, and click on "No Policy". A Configuration dialog box will open. Select the correct Disaster Recovery Policy and click on assign policy. The screenshot listed below shows the assignment of DRPolicy_01 policy previously configured to the OCI to Oracle Compute Cloud@Customer Wave. Assigning a policy to a wave will move the said wave from Replication, Waves to DR, Waves as it's now configured for Disaster Recovery.
To initialize replication and disaster recovery of Windows or Linux virtual machines con the Wave Detail screen, click Start Replication.

Rackware also provides the following features that you can use to fine tune your Disaster Recovery architecture:

Right Sizing with Auto Provisioning: Users can choose on reducing or increasing the compute and storage specification for the target instances. This feature will allow users to add the granularity of re-sizing the filesystems.
Dynamic Provisioning during Disaster Recovery: Users can leverage Rackware's ability to locally maintain a replica image of the source instance and use this image to deploy a failover instance in a Disaster Recovery event.
Backup, Single File Restore and Protected Snapshots: Rackware's Backup offering comes with rich feature-sets like snapshot retention up to 3 years, selective file restores, and unlimited protected snapshots for point-in-time recovery.
BIOS to UEFI: Users can seamlessly migrate to UEFI enabled instances without any additional configuration changes to the original instance.
Throttled-Migrations: Users have a greater control over every single migration by being able to throttle the bandwidth individually.
Completely Automated Failover and Fallback: Failover is completely automated as is falling back to the Origin environment.
Rackware Migration Manager: Provides many more features like selective filesystem syncs, file and folder exclusions, enabling cloud-init, and custom post-scripts.