by Joe Grant (@dba_jedi), Principal Architect

In recent years, modern converged infrastructure systems have increased in popularity and for good reason. They run required workloads well, but also simplify management, improve component integration, and scale easily. They offer several benefits including faster deployments, very few issues with incompatible hardware, and the flexibility of having workload-oriented, buy-as-you-grow models. While this is all great, there is a downside—modern converged infrastructure systems (specifically hyperconverged systems) require you buy storage with every new compute node.

Open Convergence Enters the Picture

With the new Open Converged Infrastructure platform, you can grow compute and storage separately. This allows you to purchase only what you need without having to over provision what you don’t.

It used to be that any converged platform came with scary and intimidating software support and licensing terms. This is especially true for Oracle RAC on virtualized platforms. So it’s easy to see why DBAs want to maintain physical systems. No DBA wants to lose their job because something bad happens, and suddenly support becomes an issue at a very inconvenient time.

Oracle has supported RAC on VMware for years, and it works well. Licensing, on the other hand, is a completely different beast. Oracle Sales and LMS organizations are notoriously unfriendly to VMware environments. However, it is important to note that virtualization technology does not inherently increase license liability.

Oracle RAC on Open Converged (DVX) Infrastructure

If you decide to virtualize Oracle RAC on an Open Converged Infrastructure system (like Datrium’s DVX System), you’ll need to decide how to handle the required shared storage.

On a virtualized platform using VMware’s vSphere, the best method is to utilize VMDKs with the multi-writer flag set. This configuration will meet and exceed the requirements for most of the RAC systems out there. In short, it will work, and work well.  One caveat though, the use of the multi-writer flag does prevent Storage vMotion of the shared VMDKs. However, dealing with this limitation is a minor issue.

The next question to ask is what happens in case of the various, expected failures that can occur with any hardware platform? I recently had the opportunity to test these failures on a DVX system.

The physical hardware consisted of two physical nodes running four VMs configured into a 4-node RAC cluster. Once the cluster was running, a database was created for Swingbench testing. While Swingbench is typically used for benchmarking activities, in this scenario it was a good fit for failure testing. While Swingbench was running, we validated behavior by noting the transactions per second (TPS).

At this point various failure scenarios were performed. These tests included:

• Performing a standard vMotion of a VM from one physical node to another. While this is not technically a failure, it is always good to test how well this works. The results were as expected, with a minor dip in TPS for a very brief moment and a migrated VM. No cluster or database events occurred.
• Simulated the disconnection of public networking by editing the VM settings and disconnecting the public NIC. The results were as expected, the “failed” node VIP was restarted on one of the “surviving” nodes. The database remained available and was able to accept new connections.
• Simulated the disconnection of private networking by editing the VM settings and disconnecting the public NIC. The results were as expected, and the “failed” node VIP was restarted on one of the “surviving” nodes. The database remained available and was able to accept new connections.
• Physically pulled the power cable to one of the STORAGE or COMPUTE nodes. The results were as expected. However, this did cause two of the VMs to power off, and since VMware HA was not configured, they did not restart. The networking components for the VIP and SCAN listeners on the failed nodes properly restarted on the remaining nodes. There was a brief pause on TPS while the cluster dealt with the loss of the two nodes. The database remained available and accepted connections on the “surviving” nodes.

In short, everything worked as we anticipated and the RAC database remained available throughout. The Open Converged Infrastructure (DVX system) platform took nothing away from the Oracle HA solution.

While nothing was taken away, some good features were added. Simply stated, the DVX system does not hinder the RAC features and functionality that Oracle provides. However, it can make life easier for system and database admins by integrating additional features including Blanket Encryption (storage-level encryption), integrated backup technology, and storage level snapshots.

Blanket Encryption has the potential of eliminating the need for additional Oracle Database options. For example, encryption is a part the Advanced Security Option. As long as none of the other ASO features are required, Blanket Encryption could easily eliminate the need for ASO. Since, Oracle’s list price for ASO is $15,000 per processor, this option could offer nice savings.

The integrated backup technology can help system admins with VM and data protection, which could eliminate the cost and time needed for third party backup products.

Then there’s DVX systems’ storage level snapshots. By taking snapshots at the storage layer, you could significantly reduce the amount of time it takes to create database clones for non-production environments. Additionally, these snapshots could also be utilized for backups and data protection, which could open several additional options for any necessary recovery.

These features demonstrate how an Open Converged Infrastructure platform can eliminate the need for additional software products and make life a lot easier for system and database administrators.

In our tests, Datrium’s Open Converged platform (DVX) worked as expected with Oracle RAC. Simply put, DVX with Oracle RAC deserves serious consideration by anyone looking to do a hardware refresh for virtualized platforms.

As with any new technology under consideration, always make sure to compare your specific requirements to the feature set of the new option you are evaluating.

Please note: this article was originally posted on Datrium’s blog at www.datrium.com/datrium-and-oracle-partner/.