Simon Haslam's Oracle Fusion Middleware blog

Should I use Oracle RAC for High Availability?

Almost all of my work involves high availability at one or more tiers, so options for Oracle Database resilience comes up regularly. Therefore I thought it would be worth writing down some of the considerations. 

Let's rewind for a moment: Real Application Clusters (RAC) was introduced in Oracle 9i to allow you to build powerful clustered database systems from of commodity hardware (typically x86 Linux servers running one or two dual core processors). RAC databases were designed to compete with the large single-instance databases running on SMP Unix servers made by IBM, HP and Sun - essentially shift spending from hardware to Oracle software (this was a long time before Oracle's acquisition of Sun Microsystems). In other words, RAC was primarily designed for scalability; high availability was a side effect.

Options & Prices

If you are looking at high availability options to protect Oracle databases here are your choices: 

  • Real Application Clusters (RAC) is the most sophisticated version of the Oracle Database and allows multiple instances to run concurrently on the same data on different nodes.
  • RAC One Node (RON) is a variant of RAC - the RAC cluster is still provisioned but a database is only allowed to be running one instance at any given time (except during switch-over during maintenance periods).
  • Enterprise Edition is the traditional single-instance Oracle Database which may or may not (typically not) be run on ASM.

As per the title of this blog post I'm focussing on whether you should use RAC or not to support your availability needs. I have ignored virtualisation based options (most notably VMware), though traditional active/passive clusters (such as Veritas, Service Guard, HACMP etc), when configured in a manner that complies with 10 day fail-over rule, can be treated in the same way as the Enterprise Edition only option.

You could also consider Oracle Database Standard Edition, which is licensed by socket rather than processor core. "Standard Edition" includes RAC and supports up to 4 Oracle Processor licenses in a cluster (i.e. 8 x86_64 cores, e.g. 2 x 4 cores), or "Standard Edition One" is allowed on servers with up to 2 sockets but doesn't have RAC. There are significant functional differences between Standard Edition and Enterprise Edition so that's not a discussion I am including here - this post is purely about availability options for Enterprise Edition.

Let's now look at how the Oracle licence prices compare. There are some assumptions I have made for these calculations:

  • The same discount would be available on all editions (whereas in practice a larger licence spend should attract a higher discount).
  • The capacity must still meet the minimum required when the system in a degraded state following one component failure (N+1 redundancy, e.g. loss of one node in a 4 node RAC cluster).
  • That a single node can have sufficient processing, memory and I/O bandwidth for your database(s) (e.g. that's 36 cores and up to 768GB memory on the Oracle Database Appliance X5-2).
  • Active/passive configurations can use Oracle's 10 day fail-over rule to save having to license the second server (see the Software Investment Guide for conditions).
  • Takes no account for overhead of running RAC compared to single-instance (e.g. 2 x 4 core servers running RAC is assumed to have the same performance as 1 server with 8 cores running single-instance).
  • Cost of server hardware is relatively insignificant compared to the cost of the Oracle licences.
  • Pricing is from the 9 April 2015 price-list, though the database prices haven't changed for quite some time.

Here are the relative list prices when you for different cluster sizes:

 Option vs No. of nodes23456
RAC 2.972.20 1.98 1.86 1.78 
RAC One Node1.21
Enterprise Edition only1.00

 Or, graphically:

 RAC vs RON vs EE relative Oracle Licence prices

Just for clarification: for sizing I am assuming that one node of an active/passive configuration has the same number of cores as the RAC cluster in degraded state.

E.g. a 3 node RAC cluster made up of 4 core nodes (needing a licence for 12 cores, or 6 Oracle Processors, in total), bit with one lost node would be 2x4 cores - two 8 core servers would be needed in an active/passive configuration, but if licensed under the 10 day fail-over rule that's an 8 core (4 Oracle Processor) licence: 6*70500 / 4*47500 = 2.23. Therefore, in this example, RAC costs 2.23x the price of EE or adds a 123% uplift.

As you can see RAC on 2 nodes, at nearly 3x the price of EE, and 1/3 more expensive than a 3 node RAC cluster, is significantly more expensive than all of other options. Note that other database options, such as Partitioning or EM Diagnostics, have to be purchased equally for all nodes so would scale in the same manner.

Conclusions 

Where RAC comes into its own is running a large scale database service platform (e.g. Database as a Service) where you can consolidate resources and benefit from additional operational flexibility.

If you are considering RAC to provide high availability for a small number of databases then a 2 node RAC cluster will cost you nearly 3 times the price of a single Enterprise Edition licence when sized to handle the same workload under degraded state. This is the least attractive RAC configuration - RAC becomes relatively less expensive for larger cluster sizes.

RAC's biggest strength from an availability perspective is that it is the only solution considered here that will protect against both planned and unplanned outages - when coupled with Application Continuity and Transaction Guard a 12c RAC database can provide very high levels of availability. Whilst a RAC cluster will suffer a temporarily degraded service following a node failure this is likely to be shorter than most alternatives and in many situations may be undetectable by the user applications and services.

On the other hand, if you can tolerate short outages, given the typically high levels of reliability of modern server hardware, then RAC One Node with a price premium of only 20% allows uninterrupted planned outages (e.g. during the day for maintenance). It also offers a very simple, online upgrade path to full RAC later.

Finally, single-instance Enterprise Edition, with shared storage and a carefully scripted fail-over, could provide a surprisingly high level of availability in the real world. The complexity here is that you need to run some kind of shared storage, for example Grid Infrastructure and ASM, as well as develop some robust automation scripts - if you rely on manual methods of fail-over then it will be very difficult to achieve availability figures anywhere near RAC's levels.

Aside

A lot has changed since RAC was first released and I would like to see Oracle offer a cheaper option that exploits RAC technology for online fail-over (e.g. a database running on both nodes but only one accepting connections to one instance) - perhaps as an enhancement to RAC One Node (with a small price uplift)?

Comments:

Philippe Fierens (@pfierens) just made a good point about the 10 day rule: "1 sec on a day means a day…so it would better be 10 times rules".

I think I gave a better description on http://o-box.com/2015/05/should-you-use-rac-ron-or-ee-for-your-soa-repo/
"Oracle’s “10 day fail-over rule” which in essences says that you can install Oracle software, without requiring a licence, on a second node attached to the same storage to act as a standby. This second node can only be activated on 10 separate occasions or up to a total of 10 days per year, and obviously if the node is used for anything else the software must be licensed."

Posted by Simon Haslam on May 05, 2015 at 10:25 AM BST #

Post a Comment:
Comments are closed for this entry.

Search this blog

About me
Oracle ACE Director (Middleware and SOA)
Presentation downloads



I'm speaking at Oracle OpenWorld


UKOUG Ambassador Partner
Oracle WebLogic Server 12c Certified Specialist
Oracle WebLogic Server 12c Certified Specialist

Links

Feeds