Using OpenStack Trove for On-Premise DBaaS
August 7, 2015 § Leave a comment
One of the basic elements of cloud computing is flexibility in deploying resources as needed within hours if not minutes. With database as a service (DBaaS), the concept of flexible deployment extended to non-infrastructure elements of the stack including software. While there are already numerous DBaaS providers which host multiple types of databases off premises, the question of on premises database deployment for cloud infrastructure has been answered more so by patterns or images which require a decent amount of configuration before a working database image is available for end users. In addition to the pre-deployment work, on-going database monitoring requires some understanding of the underlying VM (i.e. how to scale or network with other VMs for clustering) which may defeat the purpose of a DBaaS for users who didn’t want to worry about the infrastructure to begin with.
This is where the OpenStack Trove project comes in (see architecture above, original image can be found here and a detailed description of the components can be found here). Originally released as a part of the Icehouse release, Trove aims to automate much of this process by using existing OpenStack components to manage tasks like infrastructure deployment, storage allocation, monitoring, and replication. The key to this process is the Task Manager which “does the heavy lifting as far as provisioning instances, managing the lifecycle of instances, and performing operations on the instance. A few complex tasks, for example, are resize database flavor and create instance.” Basically, the Task Manager works with Trove API and components such as Nova and Cinder to provision initial compute and storage resources. This is all managed through the Horizon dashboard which remains database specific (rather than showing irrelevant VM details).
The configuration at a software level is just as important. This is done by using the assigned Guest Agent which is provisioned into the compute instance with the actual database. This agent is “in charge of bringing a datastore online,” and its behaviors will vary based on the type of database being implemented which can be SQL or NoSQL. As noted on the Trove wiki, Heat templates will be the primary provisioning and instrumentation for this functionality.
As greater support is gained for this project and guest agents are created for various databases, organizations should be able to “out-source” much of the configuration work which is required with current database patterns and images (the robustness of OpenStack community will greatly aid the development of this ecosystem). In addition, by leveraging the existing OpenStack components, it is clear that Trove will be able to simplify the infrastructure aspect of database deployment. Taken together, I believe this project eliminates many of the hurdles organizations face with either manually developing processes or coordinating multiple tool sets to orchestrate database deployments on premises.
Thanks for reading, feel free to add comments and questions below.