Tag Archives: Cassandra

Enabling, Configuring and Viewing Metrics in vCloud Director 9.0

Last week I released a post on configuring Cassandra for vCloud Director 9.0 metrics. As a refresher, one of the cool features released in vCloud Director SP 5.6.x was the ability to expose VM metrics that service providers could expose to their clients via a set of API calls. With the release of vCloud Director 9.0, the metrics can now be viewed from the new HTML5 tenant UI, meaning that all service providers should be able to offer this to their customers.

With the Cassandra configuration out of the way, the next step is to use the Cell Management Tool to tell the vCD cells to push the VM Metric data. Before this, if you log into the HTML5 UI you will notice no menu for Monitoring…this only gets enabled once the metrics have have been enabled by the tool.

The command has changed from previous versions in line with removing the dependancy on the KairosDB and we are now calling a cassandra argument that has the following options:

Those familiar with the previous command to configure the metrics will see a lot more options that specify the Cassandra nodes, the original command to configure the schema, the username and password to connect to the Cassandra database with and the ttl for the data, meaning that if you wanted you could keep more than two weeks of data.

If you tail the Cassandra system.log while the process is happening you will see a bunch of tables being created and populated with the initial data.

With the done, if you go into the new HTML5 Tenant UI and go to the Virtual Machine view you should now see a Monitoring Chart drop down in the menu in the main window. From here you can choose any of the available metrics across a half hour, hour, day and week timescale.

API Calls to Retrieve Current and Historical Metrics:

If you still want to go old school the following API Calls are used to gather current and historical VM metrics for vCD VMs. The Machine ID required used the VM GUID as seen in vCenter. The ID can be sourced from the VM Name. The vCD Machine ID shown below in the brackets is what you are after.



Configuring Cassandra for vCloud Director 9.0 Metrics

One of the cool features released in vCloud Director SP 5.6.x was the ability to expose VM metrics that service providers could expose to their clients via a set of API calls. Some service providers took advantage of this and where able to offer basic VM metrics to their tenants through customer written portals. Zettagrid was one of those service providers and while I was at Zettagrid, I worked with the developers to get VM metrics out to our customers.

Part of the backend configuration to enable the vCloud Director cells to export the metric data was to stand up a Cassandra/KairosDB cluster. This wasn’t a straight forward exercise but after a bit of tinkering due to a lack of documentation, most service providers where able to have the backend in place to support the metrics.

With the release of vCloud Director 9.0, the requirement to have KairosDB managed by Apache has been removed and metrics can now be accessed natively in Cassandra using the cell management tool. Even cooler is that the metrics can now be viewed from the new HTML5 tenant UI, meaning that all service providers should be able to offer this to their customers.

Cassandra is an open source database that you can use to provide the backing store for a scalable, high-performance solution for collecting time series data like virtual machine metrics. If you want vCloud Director to support retrieval of historic metrics from virtual machines, you must install and configure a Cassandra cluster and use the cell-management-tool to connect the cluster to vCloud Director. Retrieval of current metrics does not require optional database software.

The vCloud Director online docs have a small install guide but it’s not very detailed. It basically says to install and configure the Cassandra cluster with four nodes, two of which are seed nodes, enabling encryption and user authentication with Java Native Access installed. Not overly descriptive. I’ve created an script below that installs and configures a basic single node Cassandra cluster that will suffice for most labs/testing environments.

Setting up Cassandra on Ubuntu 16.04 LTS:

I’ve forked an existing bash script on Github and added modifications that goes through the installation and configuration of Cassandra 2.2.6 (as per the vCD 9.0 release notes) on a single node, enabling authentication while disabling encryption in order to keep things simple.

This will obviously work on any distro that supports apt-get. Once configured you can view the Cassandra status by using the nodetool status command as shown below.

The manual steps for the Cassandra installation are below…note that they don’t include the configuration file changes required to enable authentication and set the seeds.

From here you are ready to configure vCD to push the metrics to the Cassandra database. I’ll cover that in a seperate post.

References:

https://docs.vmware.com/en/vCloud-Director/9.0/com.vmware.vcloud.install.doc/GUID-E5B8EE30-5C99-4609-B92A-B7FAEC1035CE.html

https://www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/vcloud/vmware-vcloud-director-whats-new-9-0-white-paper.pdf

Installing and Configuring Cassandra and KairosDB on Ubuntu 14.04 LTS

Earlier this year I put together a post on installing and configuring a Cassandra Cluster in order to meet the requirements for vCloud SP 5.6.x Metric Reporting. In that post I went through the deployment of a Cassandra Cluster and promised a follow up on installing KairosDB. In my labs we are currently working with the vCD Metric APIs and I needed a quick way to stand up the Cassandra/KairosDB environment the vCD Metrics requires. Given the availability and sizing requirements in the lab are not representative of Production I decided to create a Single Node instance.

I also streamlined the Cassandra install by adding the Debian repositories for easier install and management. Watch the video below (suggest 2x speed) and check out the key commands listed after the video.

One of the Key settings to configure thats not shown above is changing the KairosDB datastore location from the default In Memory H2 Module to the local Cassandra location. After KairosDB has been started you are ready to point vCloud Director at the endpoint to start exporting VM Metrics to…the post showing that is still to come.

vCloud Director SP: VM Metrics Database Configuration Part 1

vCloud Director SP 5.6.3 was initially released in October 2014 was the first of the SP Editions that had been forked from the Enterprise 5.x builds that came before it. VMware delivered on their promise to release vCloud Air Features to Network Partners. One of those features was VM Metrics.

  • Virtual machine monitoring: Expose current and historical VM performance metrics to tenants through this tenant visible, multi-tenant safe API. Using the API, tenants can troubleshoot application performance problems, auto-scale their applications, and perform capacity planning.

To facilitate the storing of those VM Metrics a separate database needs to be deployed and and then have vCloud configured to use the new database instance.

No worries right?

The catch here is that VMware have decided to use a linearly scalable and fault tolerant database called KairosDB backed by a Cassandra cluster. To satisfy the requirements as set by the vCloud Director team you need to deploy a three node Cassandra Cluster.

While initially a little annoyed that we would have to deploy and manage another group of servers and services I do understand the decision for the vCloud Dev Team to go with a highly scalable database platform…after all development is done for the vCloud Air Service and then handed down to SPs after. At scale it makes sense to use something like this, however it would have been nice to have the option to use a “light” database option like MSSQL or similar…that would have made sense but lets move on!

There isn’t a lot of sizing around the VM Requirements for this Cassandra cluster so I went with three VMs with 1vCPU and 4GB of vRAM with 100GB of storage to start with. The is no guidance on the growth projections so at this point it’s a case of wait and see. Would be good to have someone from the team give estimates on the size of the cluster relative to the number of VMs in an environment.

In the lab I’m using Ubuntu 14.10 but this would apply to the current 14.04.1 LTS release as well. I’ve linked to the Debian install and config at the end of this post…Below are the quick and nasty steps to download the Cassandra tarball and the required packages to build and run a single server Cassandra instance. In production I would spend a bit more time tweaking the config however it gives you an instance to wrap your head around.

The Video below shows the whole process end to end.

To satisfy the three node Cassandra Requirement we need to repeat the steps on the next two VMs and configure for HA.

Go to the extracted location and the to /conf/cassandra.yaml and edit the config file entries listed below. For the seeds, there is no need to enter in the master IP. For an explanation on the config options the config file is well commented.

Once that’s been configured on every node in the cluster, restart the Cassandra Services. To validate the cluster status use the nodetool command under the bin folder and you should see the following:

In the next post I’ll work through the KairosDB install and configuration as well as tying it all together with vCloud Director and I’ll even attempt to pull some VM stats via the API.

Cassandra Debian Install Guide: http://www.datastax.com/documentation/cassandra/2.0/cassandra/install/installDeb_t.html

VMware vCD SP 5.6.3 Document Link: http://pubs.vmware.com/vcd-56/index.jsp#com.vmware.vcloud.install.doc_56/GUID-E5B8EE30-5C99-4609-B92A-B7FAEC1035CE.html