To RAC or Not to RAC? Veritas Cluster File System Responds "No RAC Needed"

| | Leave a comment
In a previous blog entry, I took a look at how Veritas Cluster Server (VCS) combined with Veritas Cluster File System (CFS) - Veritas CFS High Availability - enables organizations to achieve faster failover without the associated complexity and costs. Despite these advantages, organizations that are already using an HA solution such as Oracle RAC still may be reticent to switch as they need more concrete business and technical reasons to justify such a switch to Veritas CFS. But here's the good news: There is an unequivocal answer to the "To RAC or Not to RAC" question.

The main reasons that organizations may favor Oracle RAC is that it provides 5 - 10 second failover times and may already be working in their environment. However a careful examination of the facts illustrates that Veritas CFS HA provides performance that is comparable to Oracle RAC without RAC's added cost and complexity.
 
Let's look at a specific example. If an organization has 10 Oracle databases, it will need at least 20 physical servers to deliver HA for each of those Oracle databases, assuming a minimum of two servers are configured to provide support for each database.

In addition to the Oracle RAC software licenses for each production host, one must also take into account the costs for additional physical servers that are part of the failover configuration. Toss in Oracle RAC's annual maintenance costs (28% of the list price) plus the ongoing managements costs associated with supporting Oracle RAC and the cost of this configuration can easily run in the millions.

Now let's consider Veritas Cluster File System HA in this same situation. The Symantec solution costs less than Oracle RAC to implement and provides, on average, sub-minute recovery times. Further, the licensing cost per CPU for Veritas CFS HA is 2% the cost of the dual quad-core Linux server with Oracle RAC while the annual software maintenance costs for Veritas CFS HA are about 1.5% of what Oracle RAC's licensing costs run.
 
In looking at the hardware costs, server costs have dropped in recent years and many companies have negotiated aggressive discounts with server providers, such that a server with dual quad-core runs around $10,000. However by using Veritas CFS HA instead of Oracle RAC in an environment with 10 Oracle database, the number of standby physical servers needed for failover may drop from 10 to 1 or 2 that results in another $80 - 90,000 in savings.

So when one totals up all of the costs associated with implementing an HA solution using Oracle RAC versus using Veritas CFS HA for a 3 year period for 10 Oracle databases, organizations can deliver an HA environment for their Oracle environment using Veritas CFS HA for approximately 1/3rd the cost of Oracle RAC.

Then the question becomes: why would anyone use Oracle RAC in lieu of Veritas CFS HA at all? 

There is one primary use case that still favors Oracle RAC. To fail over an Oracle database using Veritas CFS HA can take up to two minutes to complete though the average failover time is 40 - 45 seconds. However if an organization has Oracle database applications that can only tolerate a an application processing interruption of seconds, then Oracle RAC is still the right answer.

Adopting a new HA solution is never one that users take lightly but the financial and technical reasons to use Veritas CFS in lieu of Oracle RAC have become so compelling that organizations can no longer ignore them. It is only those organizations that need Oracle application failovers to occur within a few seconds have a legitimate claim to remaining with Oracle RAC. Otherwise the answer to the question of  "To RAC or not to RAC?" is becoming an unequivocal "No" when Veritas CFS High Availability is available as an alternative solution.

5 Comments

Francisco Guadarrama Barraza said:

I do not understand.

Oracle RAC is able to work in parallel with the instance. Oracle RAC has failover and balancing load.
I believed that companies are using main Oracle RAC for this both characteristics.

So let me know if a loss something.

TANKS

igorus said:

"If an organization has 10 Oracle databases, it will need at least 20 physical servers to deliver HA for each of those Oracle databases..."

That is not always correct assumption, rather not correct at all - two proper servers could support few databases simultaneously.

If you could accept few minutes downtime for your production database, maybe Data Guard (standby) will be more suitable solution.

Gavin said:

Not very convincing. What happens when we need to patch the Oracle Databases and/or patch the o/s, do we have to ask for a downtime to the business?
Sorry, but I will stick with RAC.... Good try Veritas

David Shockey said:

"If an organization has 10 Oracle databases, it will need at least 20 physical servers to deliver HA for each of those Oracle databases"

Not so. Two SUN servers with 10 zones or domains can support 10 databases. Similar partitioning technologies exist from IBM, HP, and other server vendors.

You can run RAC with SUN clusters in active-active mode and have zero downtime/interruption if one node fails. So if zero downtime is required RAC is the path to take.

Chris said:

Please, anything but RAC. I use it and I have never seen anythign more unreliable then RAC. We had ORacle ACS set it up and it goes down 3-5 times per week. Think we could try Oracle Support, we have dozens of tickets open and they either can't fix it or it is a bug that will be fixed at a later time.

Leave a comment

Optional: Sign in with   |  

Entry Sponsorship

This entry is sponsored by Symantec Corp.

About Symantec Corp.

    Symantec is a global leader in infrastructure software, enabling businesses and consumers to have confidence in a connected world. The company helps customers protect their infrastructure, information and interactions by delivering software and services that address risks to security, availability, compliance and performance. Headquartered in Cupertino, Calif., Symantec has operations in more than 40 countries. More information is available at www.symantec.com.

    DCIG is paid a fee by Symantec Corp. in connection with this blog. Symantec undertakes no obligation to update, correct or modify any statements contained in this blog; these statements represent the views and opinions of DCIG only.