It’s time to bring containers to Oracle!

In my prior two blog posts I discussed the problem of underutilized hardware in today’s data centers and why containers can be used to consolidate data applications and address this problem. Today we will review the consolidation needs for Oracle databases.

Oracle for Enterprise Production Applications

The NoSQL database movement has definitely grabbed headlines in the last few years, but when it comes to enterprise-grade production applications for transaction processing Oracle remains numero uno. Even in the Oracle database space, the need to consolidate has increased rapidly as users want to reduce licenses, reduce server floor space and reduce power consumption in their data centers. Responding to changing SLA needs, along with the peaks and troughs of the application workload, demands in-built platform agility.

What do customers want?

  • Reduce Licenses
  • Reduce floor space
  • Reduce power consumption

Current Consolidation Methods & Associated Issues

To address these needs, enterprise IT teams have looked at various methods of consolidating databases, including schema-based (applications running in separate schemas in the same database), separate databases on the same bare-metal server sharing the Oracle database binaries (Oracle home), and of course virtualization. Among these choices, given the flexibility of management and isolation of data, virtualization has become the go-to solution for consolidation in most cases. However, due to the hypervisor layer and the overhead (both operational and performance) of running a guest OS for every database, adoption of virtualization has been limited to some extent in the development and test databases environments. So, due to the fear of not meeting performance SLAs, mission-critical production databases are still running on bare-metal within silos. This has led to running the dev/test and production in almost two separate setups often leading to issues (read product bugs) that occur only in one environment but are not reproducible in others. Physically separated test/dev “islands” separated from the bare-metal production siloes create delays, inflate costs and also complicate operations.

LXC Containers to the Rescue

This divide can be addressed with containers. With containers, the in-between hypervisor layer is eliminated and hence there is no performance overhead.

LXC System Containers are also similar to VMs with extreme agility, dedicated IP address, file systems and separate user space. This allows IT to run any data apps completely isolated as if running on a separate host but with higher consolidation density.

Like VMs, system Containers provide

  • dedicated IP address
  • dedicated file systems
  • separate user space

Oracle Multitenant

Containers also provide better hardware consolidation and eliminate OS and application software sprawl. Finally, unlike traditional VMs, containers can be launched in just seconds, providing agility. Thus containers open up a new frontier for consolidation of Oracle databases.

Let us now look at what Oracle has been doing as a company to address this issue. Oracle, with its recent 12c release, introduced Oracle Multitenant, a new option aimed at resolving some of these problems. While a full analysis of the Multitenant option is not possible in this context, we can say it is a viable option for users that are looking to consolidate all their databases into Oracle. Multitenant, in my opinion, is also great for a hosted SaaS application where a given customer is not worried about the database version or the platform on which the application is running. But for consolidation of disparate applications, the need to maintain a single (same) version of Oracle binaries for all applications does sound a bit restrictive.

Consolidation and DBaaS

In addition to what I discussed in part 1 of this blog, we also need to take account of the fact that the database landscape is changing rapidly. Increasingly, there is a need for greater elasticity and agility in provisioning and other lifecycle management tasks of databases. This need has led customers to think about a DBaaS (Database-as-a-Service) platform for the end users.

Enterprise customers no longer run all their databases from a single vendor. In a recent paper by 451 research, we found that most enterprise IT departments today have databases from at least three different vendors. The following chart, in the same paper, illustrates the different metrics that customers will use to measure the success of DBaaS.

 

The Need: Management Platform

Clearly, we need a platform that not only reduces CAPEX and OPEX but also improves developer productivity. At the same time, there is a need to create a platform that will provide support for a variety of databases. Instead of creating a point tool to manage an Oracle database, we now need a platform that manages an Oracle or a Cassandra or a MongoDB database exactly the same way. A platform that allows operations, such as provisioning, cloning or a bulk upgrade, in the exact same way.

In a recent blog, my longtime colleague Adeesh Fulay provided a checklist for containerizing databases. While I encourage you to read his piece, one thing I wish to point out in the context of consolidating Oracle databases is the need for quality service.

Predictable performance in the I/O layer is a key for any consolidation, but right now the only solution available to Oracle customers is a very expensive one tied to specific hardware. This has to change; we need a platform that provides IOPS control in a completely database/vendor-agnostic way. Robin’s IOPS control feature augments containers and ensures mission-critical databases adhere to their performance SLAs, and also caps IOPS to prevent the noisy neighbor problem. A quick video demo of this capability is available here.

The Robin Advantage

Robin is leading the data center evolution with containers. Robin’s container-based, end-to-end compute, storage, and data management software makes the boundaries among servers, virtual machines, and storage invisible to the applications. This maximizes hardware utilization without compromising on bare metal performance, eliminates virtual machine and data sprawl, and enables application mobility across machines and clouds. Robin is the first company to extend containerization benefits to all classes of enterprise applications, including databases and Big Data clusters.

Here is a comparison of the different methods of consolidation in the Oracle database space.

Container
Criteria
Virtual Machine Oracle 12c Multitenant Containers on Robin
Performance overhead

 Significant

Hypervisor layer, Guest OS

 Significant

Shared Redo logs, Noisy neighbors not addressed

Negligible

Completely independent, no hypervisor

Availability

High

One VM doesn’t impact another one

Medium

CDB takes down all PDBs with it

High

Just like VMs

Isolation

 Excellent

 Good

Shared buffer cache

Excellent

Performance Predictability

Poor

No way to cap IOPS at the hypervisor layer

Good

IOPS control only available on Exadata

Excellent

Built into the platform

Agility

 Good

 Excellent

Excellent

Manageability

High

(OS sprawl)

High

Challenges in getting patching window

Low

(no OS sprawl)

Learn more about Robin Containerization Platform.

mm

Author Deba Chatterjee, Director Products

More posts by Deba Chatterjee, Director Products

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.