Eucalyptus is a management framework for implementing an on-premise (or private) Cloud, i.e., a Cloud that lives within the boundaries of your enterprise data center. In the world of cloud frameworks, Eucalyptus has proved to be the most effective, with a simple modular architecture. There are many Linux distros that provide Eucalyptus out of the box; Ubuntu is one of them. Ubuntu has in fact white labeled Eucalyptus as Ubuntu Enterprise Cloud.
Eucalyptus APIs are AWS EC2/S3 compatible, which means any client tool that works with AWS works with minimum-or-no-changes with Eucalyptus, and hence anyone familiar with AWS can take to Eucalyptus, like fish to water.
That being said, Eucalyptus only provides a subset of the APIs that AWS provides. One of the missing APIs is the CloudWatch API. Amazon CloudWatch is a web service that provides monitoring for AWS cloud resources, starting with Amazon EC2. It provides customers with visibility into resource utilization, operational performance, and overall demand patterns, including metrics such as CPU utilization, disk reads and writes, and network traffic. We dub this CloudWatch for Eucalyptus as "EucaWatch".
Eucalyptus is heavily dependent on a virtualization toolkit called libvirt. Libvirt is a collection of software that provides a convenient way of managing virtual machines and other virtualization functionalities, such as storage and network interface management. These software pieces include an API library, a daemon (libvirtd), and a command line utility (virsh). Also, a primary goal of libvirt is to provide a single way to manage multiple virtualization providers/hypervisors.
The APIs provided by libvirt through its API library is extensive. Also, there are many languages binding for all these APIs. The APIs of interest in this document are those that expose the utilization of physical resources by the instances that run on the underlying virtualization layer. Virt-top is one such tool that uses libvirt to get the physical resource utilization by the virtual instances.
Using these libvirt APIs, it is possible to get equivalent metrics offered by CloudWatch on CPU Utilization, Disk IO, and Network IO. These APIs have been used as the building blocks for EucaWatch.
Eucalyptus uses network isolation of NC's (Node Controller) as a mechanism to secure instances that run on them. On a typical Eucalyptus setup, the NC is reachable only through the CC (Cloud Controller). This is one of the challenges, as there is no way to query the NC directly, but through the CC.
Eucalyptus does not expose virtual resource (instances in our case) information - there is no way to know which NC is hosting a particular instance. At any given time, there may be several instances running on a Eucalyptus Cloud, and many of these instances need to be watched. Thus, there is a need to store this time series data in an easy manner, and retrieve it in an effective way.
To address these challenges, EucaWatch consists of several small, effective, and simple components. Since EucaWatch is the Eucalyptus dubbed version of CloudWatch, it needs to implement an interface that talks the same lingo as CloudWatch.
EucaWatch Web Services (WS) is an interface through which the user will communicate with the EucaWatch. These web services will emulate all the functionality exposed by CloudWatch. This layer will have two interfaces at the backend:
As mentioned above, the only way to reach NC with a request to watch a particular instance running on it, is through the CC. The CC-Daemon will be a threaded TCP socket server listening for requests from the web service layer whose instance is (un)watched. The CC-Daemon functions as a mere router of the requests to the NC(s).
Since there is no book-keeping exposed by Eucalyptus on where an instance is launched, CC posts the requests to all NC(s) running under it.
The NC-daemon is a threaded socket server listening to incoming requests from the CC-daemon that needs to be watched or unwatched. The request processing thread will be spawned on receiving a request. This thread will query the libvirt interface for the instance existence. If the instance exists, the watch or unwatch will be processed on that instance, otherwise the request is dropped and logged.
NC-Daemon includes small light-weight modules to watch each of the metrics on a given virtual instance by querying the appropriate libvirt API for information. These modules are clubbed together, and are called watchers. The data collected by the watchers is sent back to the Data Store by NC-Daemon. Since the data is sent at specific intervals, defined by the EucaWatch system, the data will be a time series, and will be stored in the fixed-size RRD type Data Store.
This will be a fixed-size database, similar in design to RRD (round-robin-database), which provides fast, reliable storage of numeric time series data. This will also include a daemon that the NC Daemon will connect to, in order to send watch data on a particular instance. An API is provided on top of the Data Store, for easy retrieval of data.
The primary goal of EucaWatch is to emulate, or do what CloudWatch does for EC2; to give data back regarding resources consumed by the EC2 instance. To this end, the web services of EucaWatch will be similar to those provided by CloudWatch.
Once the EucaWatch Web Service receives a request to watch a particular instance running on the Eucalyptus infrastructure, the request processing engine (part of the Web Services Layer) will take over. The request processing engine, validates the request, and makes a socket connection to the CC Daemon (EW-CCD) on each of the CC's, and pushes the ID of the instance to be watched by it.
The EW-CCD receives the InstanceID. Since the CC does not by itself keep any data on which NC under it is running a particular instance, and neither does it expose any API for getting that information, the EW-CCD gets a list of NC's under it, and makes a socket connection to each NC Daemon(EW-NCD) running on of the NC's. This connection is used to push the InstanceID to NC's.
The EW-NCD on each of the NC's will receive the InstanceID. The EW-NCD will start by checking the existence of the Instance against the InstanceID. If there is no match for the instanceID, the request is just dropped and logged. Else it will start watching the Instance for the following metrics:
This data will be sent back to a data store service at regular intervals. And the data will be stored in fixed size RRD type of format, which is the most effective way of storing time series data of this kind.
The time series data pertaining to an InstanceID could be retrieved by making web services request as done in CloudWatch to the EucaWatch. The request processing engine of the EucaWatch Web Service layer will validate the request, and connect to the data store service to retrieve the data.
To know more about this tool please mail us at: cssinnovations@csscorp.com
Simply enter your first name and email id into the
box below, then click the button and We'll send your
free newsletter every month via email.
We respect electronic privacy and will NOT give out your name and address under any circumstances.
