Oracle Database Management Challenges
For enterprise-grade production applications, Oracle databases are a natural choice. Like all mission-critical applications, Oracle database-driven applications are performance sensitive and tend to rely on consistent performance from the underlying hardware.
The need for such predictable performance has forced IT admins to run most Oracle databases on bare metal silos which in turn has resulted in hardware and operating system sprawl. Today large enterprises with hundreds of Oracle databases are feeling the pain of this sprawl and are looking to consolidate databases to reduce software licenses, reduce server floor space and reduce power consumption in their data centers.
Robin’s container-powered virtualization platform helps enterprises consolidate their mission-critical Oracle databases while ensuring bare-metal performance.
Running Databases in Containers
Containers share the same operating system kernel as the host OS and are lightweight requiring far fewer resources than virtual machines. System containers (such as LXC) are extremely agile but they are in many ways similar to virtual machines. Like VMs containers have dedicated IP address, file systems and separate user space. With a much smaller footprint and resource requirements, containers are great for consolidation. Unlike virtualization technology where support is limited, containers (both LXC and Docker) are fully supported and certified to run Oracle databases.
It is possible to consolidate disparate Oracle databases, on different patch levels, to run on the same hardware without any performance penalty. Database processes, memory allocation and data from each database are completely isolated from each other and run on separate namespaces.
The increased consolidation density not only results in up to 50 percent reduction in hardware footprint but also significantly improves hardware utilization. Tests reveal that containers show 40 percent gain in performance over virtual machines.
Why Robin for consolidating Oracle databases?
Here are the options for various criteria:
|Criteria||Virtual Machine||Oracle 12c Multitenant||Containers on Robin|
Hypervisor layer, Guest OS
Shared Redo logs, Noisy neighbors not addressed
Completely independent, no hypervisor
One VM doesn’t impact another one
CDB shutdown takes down all PDBs with it
Just like VMs
Shared buffer cache
No way to cap IOPS at the hypervisor layer
IOPS control only available on Exadata
Built into the platform
(OS, OH sprawl)
Challenges in getting patching window.
(no OS sprawl)
Guaranteed App-to-Spindle Performance
Controlling IOPS in an Oracle Database
Robin’s unique App-to-Spindle Quality-of-Service Guarantee® ensures multi-tenant harmony and complete performance isolation for each application. Simple IOPS control built into the UI provides Exadata-like IORM capability on top of commodity hardware. Robin can also identify IO requests from a cloned application and can prioritize the production IO over the IO from a cloned system.
Robin also allows both CPU reservation and over-provisioning to meet the needs of the application being run.
Robin’s built in monitoring also allows seamless failover of the database instance and protects against any data loss.
Provisioning an Oracle database on ASM
Robin’s extensible orchestration framework makes provisioning of applications really easy. Unlike traditional deployment where each component of the application is provisioned separately and then wired to work together, Robin Cluster Manager allows you to define the structure of the entire application in a single manifest file with all configuration details. Thus, the whole application is deployed in one shot with a click of a button. The ease of provisioning applications makes deployment of Oracle databases really simple. Whether it is a single-node configuration running on an ext4 filesystem or a complex multi-node RAC setup running on ASM, it can be deployed on Robin with a single click of a button.
Traditionally cloning has been a big pain point for Oracle enterprise applications where the database is often cloned separately and then rewired with a copy of the application server. Cloning also requires the source data to be in a consistent state which is ensured by taking an application outage every month or at quarter end. This means developers and QA engineers are almost always working on stale data that is months old.
Robin liberates IT from these downtimes and enables Live Clone of the entire application with a click of a button. Robin provides the ability to take unlimited snapshots of the entire running application at any time the admin wishes. Snapshots are a point-in-time consistent images of an entire application and are used to create thin clones of the application in minutes.
Time Travel for Entire Application
Robin provides out-of-the-box support for application time travel. Application snapshots at certain intervals can be really useful to restore back the entire application if anything goes wrong. Robin recommends taking snapshots before making any major application changes. If you are applying a database patch or making a configuration change make sure to have a snapshot first. If anything goes wrong the application can be restored to the last known snapshot in a matter of minutes.