By Klaus Muehlbradt, HP Software Database and Middleware R&D
Most discussions I’ve had about Database as a Service (DBaaS) seem to assume a pretty simple database setup: a standalone database server. But brick-and-mortar databases that are used in production environments are typically deployed as database clusters (e.g. Oracle GRID) and often have a data replication component (e.g. Oracle Dataguard) to guard against the loss of a site.
So why is DBaaS in the cloud any different? Is high availability assumed to be provided by the underlying infrastructure? Or has nobody actually provisioned complex production databases in the cloud yet?
Ensuring high availability
Moving production databases into the cloud has the same advantages as moving other databases to the cloud—efficiency gains through resource leveraging, increased agility through self service and standardization, just to name a few.
But DBaaS should satisfy the same requirements as traditional databases.
Assuming that the infrastructure provides high availability for the database is obviously dead wrong. Virtual servers are just that, servers, with no additional database-relevant high availability services have been built in. The Infrastructure-as-a-Service (IaaS) layer cannot provide all the necessary HA/DR database provisioning automation.
Sure, a virtual server could be moved to another host or restarted on another host—a “lift and shift”—but what would this do to the database running on that server? What would happen to transactions, or to an application connected to the database? Databases like Oracle come with sophisticated high-availability clusters and replication components for a reason.
Automating complex provisioning
HP R&D has been working to solve these challenges. In our mind, the initial problem with moving production databases to the cloud is the automation of fairly complex database installations. The problem is twofold: Setting up a high-availability database (e.g. Oracle GRID with Dataguard) is inherently complex to begin with. But in many cases, the traditional approach of setting up a database that is highly tuned for a specific application only adds to the complexity. Combining an inherently difficult task with a high degree of proactive tuning results in a job that is highly complex and costly to automate.
Divide and conquer
The HP Database and Middleware Automation (DMA) group has tackled provisioning of high availability databases with a divide-and-conquer approach to different kinds of installations:
Inherently complex installations—DMA comes with a set of mature, out-of-the-box workflows to implement clusters and database replication for Oracle databases and MS SQL Server databases.
Standard installations—DMA allows the definition of standard database scenarios including pre-setting relevant configuration parameters. DMA even ships with some examples.
Last-mile configurations—DMA workflows can easily be extended to address the need to tune a database for a specific application.
Share your thoughts
Are you moving production databases to your internal cloud? Would you, if you could with minimum risk? We are interested in your input, so please post a comment below about how you envision provisioning production database systems as you move to DBaaS’s self-service models.
● Watch a 4-minute demo of how to provision databases in multivendor environments, using HP DMA to enforce standards
● Watch a 2-minute overview of how HP Database and Middleware Automation automates patching, provisioning, code release and compliance audit