Recently, VLSS took on an engagement with an organization that had no disaster recovery (DR) solution in place. The initial phase was to develop a DR Proof of Concept (POC) within a two-week timeframe.

This organization has an on-premise data warehouse and a stack consisting of an Oracle® database, an Oracle Business Intelligence Enterprise (OBIEE) server, and Informatica®. The database is backed up locally with Recovery Manager (RMAN). All components are running in VMware®. The POC’s objective was to take the company’s on-premise environment and replicate it that to the Oracle Cloud to achieve a 48-hour Recovery Point Objective (RPO) and a 24-hour Recovery Time Objective (RTO).

Oracle Database Backup Cloud Service

The first task for the VLSS team was to back up the client’s four on-premise databases using Oracle Database Cloud Backup Service (ODBS), a secure, scalable, on-demand storage solution for backing up Oracle databases to the public cloud. Administrators can use the RMAN (Oracle Recovery Manager) interface to perform backup and restore operations. Whenever a restore is required, cloud backups are immediately available.

During the POC, the ODBS backup module was downloaded and installed on the servers running the Oracle databases. Because the POC was just a one-time event, RMAN was used to do a single full backup of each database into the cloud.  However, it would be very easy to add the Oracle Cloud as a backup destination for scheduled backups, either in conjunction with on-premise backups or by itself.

Oracle Database Cloud Service

VLSS then used Oracle Database Cloud Service (DBaaS) so that the client’s on-premise databases could fail over to the Oracle Cloud. The service offers an easy-to-use web console to restore from the Backup Service with just a few clicks or REST APIs to provision and administer Oracle Databases. With DBaaS, an Oracle database, listener, and backups are configured automatically according to user specifications; a full Oracle database restore is done from backups in the Backup Service. Given the time constraints of the POC, as well as the added functionality provided, VLSS chose to use the DBaaS option for the databases.

For three of the databases, there was no problem using the DBaaS service to get the databases up and running. VLSS selected the closest approximation of hardware and software from the Web Console and let the DBaaS provisioning complete. The databases were automatically restored from the RMAN backups.

The fourth database was larger than the automated DBaaS restore service could handle (currently 2TB), so VLSS had to take a different approach. They created the largest DBaaS instance they could, and then added storage. The database was then restored and recovered with no problems using traditional RMAN procedures.

Oracle Compute Cloud Service

VLSS utilized Oracle Compute, a multi-tenant virtual compute environment that runs Oracle and third-party applications in the Oracle Cloud. To reduce RTOs, VLSS installed the applications and routinely synchronized the latest configuration files so the applications would be up to date. For the application portion of the POC, VLSS created Oracle Compute instances that replicated the on-premise VMs and then installed and configured the applications.

One of the POC requirements was to create a Windows® desktop in the cloud, which would serve as a jumpbox for access into the cloud environment and a testing and validation environment with access to the various application interfaces. To this end, VLSS developed a Windows desktop that connected to the Oracle databases, Informatica administration console, Informatica client tools, and OBI reporting and administration portals.

VLSS provisioned an Oracle Enterprise Linux 6 instance for the Informatica application and a second Oracle Enterprise Linux 6 instance for the OBI application. After changing some settings to account for the higher Oracle Cloud security requirements and creating new schemas, the installation was completed.

Benefits of the POC

The POC proved that this client could have an inexpensive, warm DR solution in the Oracle Cloud that supported all their databases and applications.  During testing of the DR solution, the databases and application servers were configured to mimic the size and capacity of the on-premise environment.  The testing proved that the environment performed as well as the on-premise systems.

However, once testing was comple, VLSS was able to down-scale the environment for significant cost savings.  The application virtual machines in the Oracle Compute Cloud were “shrunk” to the smallest instances available, but they were still configured to received application synchronization updates from the on-premise environment.  Those changes probably could have been consolidated into just one virtual machine for even more cost savings; however, that would have complicated the recovery process in the case of a DR event. 

The DBaaS instance were shutdown and terminated completely.  Since the backups exist independently in the ODBS, there is no need to keep the databases up and running.  All of the changes will be captured by regular backups from the on-premise environments, and the automated restores, or RMAN restore process for the large database, can build new databases.  If a disaster happens, the client only needs to spin up their databases and upscale the VMs at that time to run their day-to-day operations from the Oracle Cloud. This provides a flexible and inexpensive solution.

In addition, VLSS exceeded the RPO and RTOs thresholds. The client runs their backups every night, so their RPO will be at most 24 hours. The databases had a combined RTO of eight hours with the applications just under one hour, providing a nine-hour RTO.

 

Comment