As the great philosopher, Yogi Berra, once said, “This is like déjà vu all over again”.
Back in the early days of Oracle, everything sat on one “big” server – the applications and the databases. Apparently this was bad. We needed to move to Symmetric Multi-Processing Servers to spread the CPU load. It turns out this too was bad. Our business was now vulnerable to a complete shutdown if this single server failed – we needed to distribute to many smaller servers. Suddenly our applications went one way, our databases split up and went other ways, our server rooms got larger, our IT support staff got larger, our license costs grew larger, and when the server hosting our Sales database crashed our business shutdown anyways.
What’s the answer? Consolidation! That’s right… let’s take all those smaller, cheaper servers, create virtualized versions of them, and put them together on a large server. “This is like déjà vu all over again!”
But Seriously Folks…
You have to love the humor in it. To be clear though, in many cases this is an excellent idea. You’ll still have to incur the costs of new servers, virtualization software, staff training, and transition effort costs; however, your long term savings in terms of support costs, energy use, and IT staff costs may result in significant savings over the long-term.
In many cases, the decision to consolidate through virtualization is not terribly difficult. Where it can really get tricky is when you are dealing with your Oracle databases. You should determine the impact on your license agreement with Oracle and investigate the costs/benefits of consolidating your Oracle databases utilizing Oracle Real Application Clusters.
Beware The License Trap
The easy consolidation path is to virtualize each of your database servers and move these virtual machines to the new server. Be very careful though… depending on the type of server you are moving to, you may find yourself out of compliance with Oracle. You need expert advice from an Oracle Reseller with deep experience in the latest licensing metrics.
The High Availability/Scalability Muddle
If high-availability and/or scalability are important issues for your organization, then this is where your Database Administrators need to do some serious investigation.
You will get the pitch on VMware High Availability (HA) Cluster. This is an excellent feature of VMware but make sure you really know what you’re getting and that you investigate all of your options.
With VMware HA, if a physical server crashes, VMware HA takes over and boots another copy on another server. This does require an O/S boot, a database boot, and will require users to reestablish their sessions.
Oracle’s High-Availability solution is Real Application Clusters (RAC). Oracle RAC is fully fault-tolerant. If one or more physical servers in the cluster crashes, RAC will continue to run using the remaining servers. Utilizing connection pools, users will transparently failover to a remaining node and, at worst, be prompted to retry their operation. Most users will never be aware that a failure took place.
Realize as well that VMware will only detect a total crash of the VM environment. Unlike Oracle RAC, it cannot detect and resolve infrastructure process issues such as Listener failure.
In terms of scalability, VMware’s ability to scale will be limited by the number of virtual machines that can be supported by the physical server (and the configuration of each of these virtual machines). As the database grows, you may also find yourself limited by the size of the VM. One proposed option will be to spread the data across multiple instances (data partitioning) but this is a very big job with many performance, management and application implications.
With Oracle RAC, you simply add another node to the cluster and the database/application environment immediately and transparently begins to scale up. Oracle RAC has a shared cache architecture that does not require data partitioning to scale. New nodes, storage devices, memory, CPU’s can all be added to the RAC environment while the system stays online and available.
In truth, many organizations may not need the fault-tolerance and scalability that Oracle RAC provides. It may very well be overkill. The point is to make a decision on consolidation with all the facts available and decide on the best approach that meets the needs of your business users.
What About Savings in Manageability?
As one of the reasons for consolidation is to reduce costs through improved manageability and effort, it is important to consider the following.
With Oracle RAC, you have one single database software image across multiple servers. A single database software image is easier to patch, manage, backup, recover, tune, etc. Taking 100 physical servers and converting them into 100 virtual machines will still leave 100 database environments that need to be patched and managed separately.
Final Thought
So, what is the best approach to database consolidation? It depends. Virtualizing all your physical servers might be the answer. Consolidating databases within an Oracle RAC infrastructure might be the answer. You might even find that a hybrid solution is the best approach for your organization.
What you need to do is dig deeper than each vendor’s marketing pitch and involve your technical team in the decision making process. The easy answer might not be right, but then again, the right answer may not be easy.
To quote Yogi Berra one more time, “You’ve got to be very careful if you don’t know where you’re going, because you might not get there.”
For more information regarding DesTech’s database consulting and software licensing services, please contact us at 416-368-8455 / 1-866-368-8455. or info@destech.com.
