Oracle Real Application Clusters (RAC) is Oracle’s database level clustering technology that allegedly provides high availability. The intent is to make the RAC databases always available even in case of hardware failure, OS issues, or routine maintenance. How well this actually lives up to the Oracle promises is a discussion for another day.

Over the years the Oracle Sales team has been quite successful in convincing their customers that they have to have RAC. Thus, the customers have implemented RAC in both physical and virtual environments. Now that cloud migrations are in full swing these customers have a perceived dependence on RAC are trying to figure out how to migrate their Oracle databases to AWS. When doing this there are two issues that together make a compelling argument for transitioning Oracle workloads from RAC to single instance during a cloud migration.

Issues with RAC in AWS

The first issue is a licensing issue. The Oracle document Licensing Oracle Software in the Cloud Computing Environment (aka Cloud Policy) describes the conditions for licensing Oracle software in AWS. The problem here is that RAC is not on the list of software products that can use the Cloud Policy. This means you cannot license RAC using the Cloud Policy. The second issue concerns support. In the My Oracle Support (MOS) note 2688277.1 Oracle very explicitly states that they will not support RAC in any non-Oracle public cloud.

Neither of these issues are technical ones that would prevent Oracle RAC from running in a AWS environment. I know from experience that it is possible to run RAC in an AWS environment. That unfortunately is not the issue. The licensing issues and the support issues are enough to convince those looking to migrate to AWS that Oracle RAC is a not an ideal option. However, this is not enough of a reason to say that Oracle RAC workloads cannot be migrated. Migrating from RAC to single instance databases during an AWS migration is absolutely an option, and a very attractive one.

Oracle RAC to SI

Typically, Oracle RAC is implemented for high availability (HA), scalability, and/or workload isolation purposes. There are several strategies that can be utilized when migrating form Oracle RAC to single instance databases to keep those features without utilizing Oracle RAC.

High Availability

With Oracle RAC multiple instances on multiple servers (or VMs) are utilized to maintain continuous availability of the database. However, the application still needs to have retry/reconnect logic if an instance fails in order to take advantage of the HA that Oracle RAC provides. This functionality can also be utilized to minimize downtime during routine patching. However, it is very rare to find an application that actually takes advantage of this RAC feature by leveraging the feature Oracle calls Transparent Application Failover. Frequently instance disruptions to just one node cause the application as a whole to become unavailable, and patching requires the application to be down as well. Even when all works as it should there frequently is an application disruption for up to a few minutes.

In an AWS environment the Nitro hypervisor has similar functionality to VMware High Availability where compute resources will be restarted on a different physical host in case of hardware failure for the original host. Typically, the compute resources will be restarted and functional within 5 minutes. This is more than sufficient for most applications, and honestly service disruptions due to hardware failure in AWS are rare.

If a 5-minute recovery from failure is not fast enough for a particular platforms HA needs, another strategy would be to use Oracle Data Guard to maintain a standby database in the same AWS region, but a different availability zone. Optionally, the standby could be in a different AWS region, and thus could provide both HA and disaster recovery (DR). Operational procedures would need to be established to manage, or ideally automate, failover to the standby at the database and application levels. A “short leash” on failovers will help ensure the maximum availability in this configuration.

The other source of downtime that Oracle database administrators often cite as reason to require RAC is patching downtime. There are ways to handle this without Oracle RAC. To reduce the downtime associated with patching activity a secondary Oracle software home can be utilized. A second home can be installed and patched to the desired level on the EC2 instance prior to any scheduled downtime. Once the maintenance window starts the database can be shutdown, the oratab file updated to point the database to the new home, start the database, and finally perform any post patch procedures. This will apply patches with little more than a database restart.

Scalability

The multiple instances of an Oracle RAC database allow additional compute and memory resources to service the application workload. When migrating from an Oracle RAC configuration to a single instance the compute and memory resources of all nodes of the Oracle RAC cluster need to be taken into consideration.

For dealing with scalability issues, we simply “throw hardware” at it. Typically, a single instance database can perform as well as a RAC configuration with equal CPU and memory resources. Single instance databases are simply more efficient as there is no interconnect communication to have to coordinate. In an AWS environment there are so many instance types and instance sizes to choose from there will be no issue finding an appropriate instance to use.

Workload Isolation

With Oracle RAC it is possible to direct certain application activity to a specific node in the cluster to help reduce the possibility of contention within the database. For example, OLTP workloads can be directed to node 1 of a cluster while batch and/or reporting workloads are directed to node 2. There are several strategies for achieving the same performance isolation when migrating isolated Oracle RAC configurations to a single instance. These include:

• Increase the compute and memory resources allocated to the database to ensure the needed performance and response times.
• Utilize Oracle Resource Manager to manage the workloads.
• Create a read only copy of the database utilizing Active Data Guard, then direct as much of the application read activity as possible to the read only database.
  • This will likely require some application changes.
• Use Oracle Golden Gate replication to maintain multiple copies of the database.
  • Not all databases are suited to bi-directional replication.
• Separate and migrate application functionality to a different database.
  • This also may require some application refactoring.
• Separate schemas, and/or separate PDBs.

Other considerations

Changing from an Oracle RAC to a single instance configuration will be a significant change. All aspects of this change will need to be discussed within the relevant DBA and application support team, thoroughly tested, and new procedures developed/documented. Based on my experience, the following tasks will need to be completed as workloads are migrated from RAC to a single-instance AWS database.

• Through performance testing
  • Validate instance sizing
  • Performance testing of integrated workloads that have previously used workload isolation configurations
• Develop new maintenance procedures
  • Determine how patching will be performed (OS and DB)
• Work through failure scenario testing
  • Determine how the applications behave and to develop procedures on corrective actions
  • determine, via testing, the potential outage times in case of failure
• Validate DR configuration
  • Develop activation procedures
  • Determine activation timing
• Thoroughly test backup and recovery tasks

The information from the above tasks can then be used to inform the business units of the expected performance and application behavior in an AWS environment.

Summary

When migrating to AWS it is not always possible, or desirable, to perform a lift and shift migration. The simple fact is that there are differences between a cloud environment and an on-premises environment. However, these differences should never keep you from moving to a cloud environment. If that means moving from Oracle RAC to single instance then it can be accomplished without loss of functionality. Hopefully the strategies noted will help you with your migration. As always if you have any additional questions or if we can help with your migration to AWS, contact us here. We would love to see how House of Brick can help you.