Enterprise OpenStack and DBaaS

OpenStack Trove Logo

As OpenStack matures, and as the community provides new features demanded by customers and the enterprise, one critical services required to benefit from IaaS managed by OpenStack is Database as a Service (dBaaS) on which the OpenStack Project is called Trove is focused. Most conversations about Trove center around the open source MySQL database, but other enterprise-level databases such as Oracle dB 12c can also be managed by Trove.  In fact, Oracle 12c includes features, such as multi-tenancy, that Enterprises want, and that Trove should support.  

Database as a Service (DBaaS)

The database is one of the most critical services in the enterprise. The database’s function is to store data, enable the ability to search for specific data, analyze data, abstract data for applications. Customers want to have the ability to scale both relational and non-relational  cloud database engines. The Trove project is focused on enabling OpenStack users to effortlessly and rapidly manage a database without the complexities of administrative jobs on the database itself.

Currently the Trove model looks something like this:

Current Trove Model   

Another major goal of Trove, however, is to isolate resources and automate complex operations usually done by a dBA Engineer, such as deployment of databases, patching a database, backing up a database, restoring a database, monitoring a running database, and configuring a new database.

Trove today

The ‘current’ process in creating a dB instance with the current build of Trove looks something like this:

Current Trove Workflow

This corresponds to the following steps:

Step 1: A request to create a virtual database is made
Step 2: A authentication request is made with Keystone
Step 3: Provision a Trove Instance (which also leads to the creation of a new VM on which to run the database)
Step 4: Trove returns a response that incorporates the description of the instance, including:

  1. The Instance ID
  2. The DataStore Type or Version
  3. The Volume Size
  4. The IP Address of the instance
  5. Other variables that might be requested or required

A current limitation of OpenStack’s ‘Database as a Service’ tool is that Trove currently only supports single-tenant instances. One new feature in Oracle dB 12c is multi-tenancy, which is a critical feature currently being deployed at  accounts such as Thomson Reuters and other enterprises in the financial industry. With their growing interest in OpenStack, having this feature on the roadmap is critical to gain access to financial industry accounts.  

Multi-tenancy and Trove

John Deveraux will be presenting on OpenStack Trove Day, on August 19th in Cambridge, MA.

Multi-tenancy is an architecture in which a single instance of a software application serves multiple customers. Each customer is called a tenant. Tenants may be given the ability to customize some parts of the application, such as color of the user interface, but they cannot customize the application’s code.

Multi-tenancy can be economical because software development and maintenance costs are shared. It can be contrasted with single-tenancy, an architecture in which each customer has their own software instance and may be given access to code. With a multi-tenancy architecture, the provider only has to make updates once. With a single-tenancy architecture, the provider has to touch multiple instances of the software in order to make updates.

Oracle’s current plan for OpenStack Trove is:

1. Each Tenant Gets a dedicated Database Instance

  1. Based on a preconfigured VM Image
  2. Tenant runs on a Compute and Storage Node(s)

2. Customer has complete control of services
3. Any Database Application, any Database Query Language, and Connection Methods are to be supported
4. For the first time, Oracle will change its per CPU/core licensing model and introduce monthly subscription pricing

To accommodate these changes, Trove will need a slightly modified architecture:

Proposed Trove Workflow

In this case, the workflow looks like this:

  1. A user requests a database.  (In this case, it’s a portable database (PDB).
  2. Keystone receives an authorization request
  3. The Database container gets provisioned
    1. The Guest agent asks Oracle to create the PDB
    2. Oracle creates the PDB
    3. Oracle responds to the guest with connection attributes
  4. The response, containing connection credentials, is returned to the requesting user.

To make this work, the Trove project needs the following components:

  1. API Server – The API Server receives requests and talks directly to guest agents to address quick tasks such as obtaining a list of dB Users, but asks the Task Manager to handle tortuous, serial tasks.
  2. Message Bus – A Messaging Queue Broker between API points such as the Task Manager and the Guest Agent via HTTP requests.
  3. Task Manager – This is the workhorse of the system, responsible for provisioning instances, controlling the life cycle of all instances, and performing operations on any instance. It works with the API Server by collecting and responding to messages. Remember that both the Task Manager and the API Server require HTTP calls to the OpenStack services.
  4. Guest Agent – This is a service that runs within a guest instance running a database, which also manages and performs operations on the datastore. It brings the datastore online and also transmits a heartbeat signal to the API via the conductor.
  5. Conductor – This is a service running on the host which handles accepting messages from guest instances to update information on the host. If you are running a database backup – the conductor, using the RPC Messages via the bus, performs the relevant operation as follows:
    1. trove-conductor is the entry point
    2. RpcService, configured by /etc/trove/trove-conductor.conf, specifies the conductor manager
    3. Requests are pushed to the Message Queue
    4. The heartbeat updates the status of any instance. There are three basic choices: NEW, BUILDING, and ACTIVE, though others can be added

Trove isn’t quite ready for this new structure, however.

Moving forward

The Community Roadmap for Icehouse includes:

  • Generalization of core in order to improve extensibility
  • Database multi-engine type using versiontype
  • Adding support of cluster provisioning and management
  • Extensibility forming complete architectures (using Conductor and Scheduler)
  • Amazon “parameters-group” like features
  • Automated scheduled tasks
  • Designate / Ceilometer Support
  • Automated failover
  • Tempest Test Coverage

As of now, multi-tenancy isn’t on that list, but it should be. Using services such as Murano, which enables your users to select which database service to deploy and with the proper flavor settings to determine how much resources will be allocated for that tenant is very enticing for enterprise customers who want to leverage an Orchestration Tool to combine the management and operations of their hardware and software components. Murano, for example, enforces permissions with Keystone to ensure only the predetermined users have access, and lets Trove communicate with the Guest Agents, allowing a quick creation of a database.

These are all attractive features for Enterprise users, and for many, they are enough. But for those customers who need that extra level of Enterprise functionality, the Trove roadmap should include a move in that direction.

Leave a Reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>