Home > Blogs > VMware vFabric Blog


Run DBaaS Metering & Chargebacks w/Data Director, then add Hyperic

Ever heard or thought this?

“We have so many databases—the cost is so significant and hard to track. If we could just measure and charge groups based on usage, we could better manage this and cut down on license costs.”

Many companies are realizing that they must run all services like a utility. There are “table stakes” for playing in the model. It means IT must manage all data-related services with metering and chargebacks. You just can’t be a true software service if you don’t know your real costs. Not to mention, other executives look at you with big eyes when you say, “I am not sure how much all our databases cost us.”

If you are unaware of what vFabric Data Director does, here is a short overview explaining how it can help consolidate databases by 13 to 1.

Through database-aware virtualization and self-service lifecycle management, vFabric Data Director (vFDD) enables organizations to offer DBaaS for reduced TCO, increased agility, accelerated application development, and more. Like all other XaaS offerings, vFDD 2.5 is implemented based on a  cloud architecture—resource pooling and elasticity through resource pools/resource bundles, multi-tenancy through the organization/database group/database structure, self-service through automated database lifecycle management workflows, and additional security.

However, some suspect there is one important, business-centric cloud component missing in vFDD—the service metering capability, a.k.a. chargeback. Many have wondered if vCenter Chargeback Manager (vCBM) can be utilized together with vFDD to fill the gap. Can it? In short, the answer is yes.

Metering and Chargeback Architecture for DBaaS

vFDD is built on top of vSphere, it relies on vSphere resources to create and run Database Virtual Machines (DBVMs). The DBVMs have a vFDD agent running inside and are managed by vFDD at the application layer. Like any other regular VMs, these DBVMs are also objects of the underlying vSphere environment. As such, they are ultimately managed and tracked by vSphere at the infrastructure layer. Information about the key DBVM computing resources—CPU, memory, network and storage—is captured in the vCenter database. This data provides the basis for allocation-based, reservation-based, and/or usage-based costing in vCBM. Additionally, vCBM allows you to customize a pricing model to include other costs such as a fixed cost for high availability protection (which is enabled by default in vFDD) or a one-time charge for a specific database installation (for instance, sharing of an Oracle license cost).

Moreover, using vCBM’s VM Instance Cost, you can easily create VM instance matrix definitions that match the definitions of resource templates in vFDD (e.g., large/medium/small, or gold/silver/bronze). In other words, you can have different types of instances be associated to different cost models.

There is nothing special that needs to be done in vFDD nor vCBM for the solution to work. All you need to do is to point vCBM to the vCenter where the vFDD instance is deployed, create a chargeback hierarchy, and drop in vFDD objects for the reporting granularity that is needed. Then, you create a pricing model that satisfies the business requirements. Very conveniently, vFDD’s structure of organization/database group/database is organized around the underlying resource pools in vSphere. It is very easy and straightforward to create a chargeback hierarchy via s drag-and-drop user interface from vCenter to reflect the true cloud organizational structure for chargeback, as shown in the screenshots below. An argument can be made here that there is actually no need to build separate metering capabilities within vFDD. vCBM complements vFDD DBaaS seamlessly.


Figure 1. vFDD organizational structure and resource allocation


Figure 2. vFDD organizational structure and resource allocation in vSphere

Make no mistake though, this solution won’t work if you want to report and charge based on some DB specific metrics such as transactions per second or # of DB connections. vSphere and vCBM have no insights at this type of application layer. However, it is rare that we have customers request this level of metering and chargeback. Most customers seem to be fine with VM level chargeback whether the VMs are running DBs or other applications.

From Metering to Operations Management

Now that metering is taken care of, it’s worth mentioning another aspect of cloud services—operations management and monitoring. Applications must be constantly monitored to find, fix, and prevent performance problems, reduce downtime, and meet SLAs. A well, databases can often require more care and feeding than application services. vFDD builds some basic monitoring capabilities in the product. With these, you can get a limited set of stats about a DBVM and the database running on it. Not surprisingly, customers want a lot more information—often a full-blown monitoring solution is needed.

Well, it makes no sense to reinvent the wheel and turn vFDD into something else. Enter vFabric Hyperic, the monitoring component of VMware cloud offerings. It automatically discovers, inventories, and monitors a broad range of over 120 products and collects a vast range of performance data. All the database types supported by vFDD (i.e. Oracle, SQL Server, vFabric Postgres, and Hadoop), along with the virtual infrastructure, can be monitored by vFabric Hyperic.

How vFabric Hyperic works with Data Director

The vFDD and vFabric Hyperic integration solution is straightforward:

  • Install the Hyperic agent into a vFDD base DBVM.
  • After the agent is configured with the Hyperic server information in the agent configuration file, the base DBVM is converted into a database template.
  • Every DBVM provisioned from this template will already have the agent installed and properly configured.
  • When the DBVM boots, the agent will start automatically as a service and establish communication with the Hyperic server to start monitoring.

Of course, this solution assumes that a Hyperic server instance is separately installed in the environment and is connected to the vFDD database access network.

There are about 37 videos on Youtube if you search “vFabric Data Director”—these videos include installation, testimonials, creating Oracle database templates, using Data Director with Cloud Foundry, and more. Here is a 6 minute product overview:

To learn more about vFabric Data Director:

Also:

About the Author: Weiguo He is a Senior Solutions Architect on the vFabric Data Director team. He is responsible for helping customers envision, plan, and implement solutions in the DBaaS, big data, and database virtualization areas. As a veteran of the industry, Weiguo also spent over 10 years at EMC in various roles.

2 thoughts on “Run DBaaS Metering & Chargebacks w/Data Director, then add Hyperic

  1. Sanjeev Kumar

    Weiguo, this is amazing article. Thanks for the great work. Can i some ideas to integrate this service in AppDirector or vCAC as part of blue print.

    Reply

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>