IntelliP: Effective Mechanism for Resource Monitoring

IntelliP: Effective Mechanism for Resource Monitoring in Private Cloud

• Vivekanand Adam

Abstract—Cloud computing paradigm makes huge virtualized compute resources available to users as pay-as-you-go style. Resource monitoring is the premise of many major operations such as network analysis, management, job scheduling, load balancing, billing, event predicting, fault detecting, and fault recovery in Cloud computing. Cloud computing is more complicated than ordinary network owing to its heterogeneous and dynamic characteristics. Hence, it is a vital part of the Cloud computing system to monitor the existence and characteristics of resources, services, computations, and other entities. Monitoring data between hosts and servers should be consistent, and data transfer from hosts to servers should be efficient. In this paper, I will use an effective mechanism for resource monitoring called IntelliP which is based on a modified push model. It reduces useless monitoring data coherency between hosts and servers in CloudStack.

Keywords—Cloud computing, Monitoring, self-adaptive, coherency, CloudStack, IntelliP.

I. Introduction

Cloud computing has rapidly emerged as a method for service delivery over TCP/IP networks such as the Internet. It disrupts the traditional IT computing environment by providing organizations with an option to outsource the hosting and operations of their mission-critical business applications.

Cloud computing paradigm makes huge virtualized compute resources available to users as pay-as-you-go style. Resource monitoring is the premise of many major operations such as network analysis, management, job scheduling, load balancing, billing, event predicting, fault detecting, and fault recovery in Cloud computing. Cloud computing is more complicated than ordinary network owing to its heterogeneous and dynamic characteristics. Hence, it is a vital part of the Cloud computing system to monitor the existence and characteristics of resources, services, computations, and other entities.

Apache CloudStack [1] is one of the most popular open source IaaS solutions. CloudStack is the best choice of all open source clouds to migrate the services and integrated the maximum security level in its architecture [2].

In IaaS Cloud environments, two aspects should be considered:

1. IaaS hardware and software: In Cloud environment, there are various kinds of hardware and software, including physical hosts, network devices, storage devices and databases. Monitoring system should obtain the performance data of these hardware and software, and report the real-time running status.

2. The Cloud user’s resources: Everything the user has in the Cloud. These are instances, disk volumes, guest networks, templates, ISOs, etc. For all these components, the Cloud user needs clear and reliable knowledge of their status.

My goal is to develop an effective monitoring system for CloudStack which will use an effective mechanism for resource monitoring called IntelliP which is based on a modified push model and it reduces useless monitoring data coherency between hosts and servers. The monitoring system can collect utilization information from both physical and virtual resources. The monitoring metrics should be accurate, i.e. they are as close as possible to the real value to be measured. This can help the administrators know the status of Cloud system, and give end users a clear view of their resources in Cloud.

II. Background

This existing monitoring system named SCM is proposed to monitoring the Apache CloudStack platform [3].

SCM is a flexible monitoring system supporting for cloud environments, which can monitor both physical and virtual resources. SCM users can choose their interested metrics and set a custom interval. In order to meet these requirements, SCM needs a well-designed user interface, and flexible, dynamic data sources. In Clouds, monitoring metrics are also important to the billing systems, job scheduling and other Cloud components. Because of the characteristics of Cloud environment, the monitoring metrics will be dynamically changed and the volume of data may become very large, a scalable and high performance storage system is needed. The SCM monitoring system has four main functionalities, which are metric collection, information processing and storage, metric display, alert.

The architecture of the SCM monitoring system is shown figure 1.

1. Collectors

In Apache CloudStack environment, the hosts have different meanings [1]. These hosts may be physical or virtual, customer instances or system virtual machines, so the metrics need to be collected vary with the host’s type. In the SCM monitoring system, they use collectors as the data sources which are deployed on each host. These collectors can easily be configured to collect different metrics. In fact, the collector

Figure1. The architecture of the SCM monitoring

offers a framework, in which users can develop their own programs to collect metrics they interested in.

The collector periodically retrieves performance metric values from the host, e.g. cpu usage, memory usage, disk I/O. When the host becomes management server or storage server, the performance metrics of MySQL, tomcat, NFS and other CloudStack components are also collected. As mentioned above, CloudStack has different network traffics on a host, some of traffics do not to need be monitored. The collector monitors the public and storage traffics. The collector also monitors the network devices through SNMP. These metric values are then pushed to SCM Server.

2. The SCM server

The SCM server is the core of the SCM monitoring system. There are five main modules of the SCM server. Host aggregator is used to aggregate the metric values from the collectors. A host aggregator may receive metric values from a lot of collectors. Apache CloudStack provides an API that gives programmatic access to all the management features. They designed the platform aggregator to communicate with ACS management servers and call the ACS API through HTTP to get the CloudStack related information, such as the version of CloudStack and how many zones, pods, clusters and hosts in the current environment, etc. After a pre-set time, the aggregators send the metrics to the storage module. The storage module is used to communicate with the storage system, putting the metric values into the storage system or getting values from it. The storage module receives the metrics from the aggregators and stores all these data locally, when the metrics file is large enough, it puts the metrics into the storage system. This can reduce the I/O operations on the storage system. The statistics module is a data processing module. It analyses the metric values from the storage module and provides the average, minimal, maximum, performance outliers, etc. To improve the availability of the ACS, abnormal running information should be reported to the Cloud users immediately. The alert module obtains exceptions from statistics and records the information, and then notifies the Cloud user. If the ACS scale is large, there are hundreds or thousands of hosts, multiple SCM Servers may be needed for load balance.

3. The SCM Client

The metric values are organized as a tuple (metric name, timestamp, value, tags), these tuple are not friendly to the Cloud users. So just collecting various resource utilizations information is not enough to explain the observed performance of hosts or applications. In order to let the Cloud users easily to understand the meaning of these metric values, it is very important to display information in a simple and flexible way.

The SCM Client gives an overview of the whole system, and displays the metric values in time series graphs with several filters, which is used to help the Cloud users quickly find the minimal or maximal of the current metric value or calculate the average performance in a period of time. Also the Cloud users can customize the graphs by selecting the metric names and tags in tuples. Then only the interested metric values will be displayed in the user interface.

4. Storage system

The metric values need to be stored persistently for analysis as well as displayed on the fly. Resources in the Cloud change dynamically and the deployment of the Cloud is large. Monitoring such distributed system may produce a large amount of metric values. So the storage system should be scalable and flexible, with the ability to collect many thousands of metrics from thousands of hosts and applications at a high rate.

Above system uses pure push model for data collection [3], hosts initiatively send running status (CPU, memory, I/O, etc.) to a monitoring server.

This model has better real-time, and makes the monitoring data between hosts and servers higher in coherency, but lower in efficiency. Usually, the push model is triggered by a time interval or exceeding a threshold. The value of time interval and threshold is important to this model. If the value is too small, even a little change on hosts may make the status information deliver to monitoring servers over a network. This may cause network congestion. If the value is too big, a lot of useful information may be ignored. It consist useless monitoring data coherency between hosts and servers.

A pure Push or Pull model is not suited for many different kinds of virtualized resources

III. Related work

In Clouds, resource monitoring is the premise of job scheduling, load balancing, billing and many other major operations. Therefore, data coherency and real-time are important indicators for a monitoring system of Clouds. Elastic compute is one of the main characters of Clouds, resources in Clouds change dynamically. So the monitoring system should adapt to this kind of situation.

To solve the above problem He Huang and Liqiang Wang proposed a combined push and pull model called P&P model for resource monitoring in Cloud computing environment [4]. The P&P model inherits the advantages of Push and Pull models. It can intelligently switch between Push and Pull models depending on the resource status and external customer request. But the combination of the push model and pull model is more complex to the pure push model and pull model. When there are a large number of requests, event driven method will increase the load on the monitoring servers, and the servers will become the bottleneck. The switch between push and pull has some extra costs [4] and it consist useless monitoring data coherency between hosts and servers.

In an attempt to minimize unnecessary and useless updating massages, and maximize the consistency between the producer and consumer. Wu-Chun Chung and Ruay-Shiung Chang [5] have proposed GRIR (Grid Resource Information Retrieval), which is considered a new algorithm for resource monitoring in grid computing to improve Push model. They examined a set of data delivery protocols for resource monitoring in the push-based model, such as the OSM (OffsetSensitive Mechanism) protocol, the TSM (Time-Sensitive Mechanism) protocol, and the hybrid ACTC (Announcing with Change and Time Consideration) protocol. This hybrid protocol is based on a dynamically adjusted update time interval and the consideration for early update when the change is larger than a dynamic threshold.

IV. Proposed solution

We can use a self-adaptive mechanism for resource monitoring in Cloud computing environment based on push model. As mentioned earlier, push model has better coherency, but lower efficiency in small threshold situation. We can set up a transportation window to store metrics before they are delivered to the monitoring server. We can design an algorithm to control data delivery.

The design of the Self adaptive Push Model

Monitoring data between hosts and servers should be consistent, and data transfer from hosts to servers should be efficient. In this section, I introduce a self-adaptive push model called IntelliP, which is based on a modified push model. It reduces useless monitoring data coherency between hosts and servers. IntelliP has a transportation window, as shown in following figure 2.

Figure 2: A push model with transportation window.

When collectors get metrics from adapters on hosts, instead of delivering these data to servers immediately, they put these metrics into the transportation window. The window accepts a new metric and then compares it with the average value of the former metrics.

(1)

If diff is smaller than the current threshold, collectors put the metric into the window and keep accepting new data, otherwise, deliver the metric to monitoring server and empty the window. When the window is full deliver the average value of the metrics in the window to monitoring servers. The size of transportation window is not fixed, in order to adapt to the dynamically changing situation of Clouds the window size changes too. Small size means that resources change frequently, and large size hosts are running in a stable status. When the window is full, that means in the past periods of time, hosts were running in a stable status, and the next few periods may still in this status, so the size of window adds one. If diff is bigger than the threshold, it shows that CPU usage, Memory, I/O throughput or other resources of a host changed suddenly. This may indicate that the host becomes active.

An IntelliP data delivery control algorithm

At this moment, the window size reduces to half of the original size, so more metrics will be delivered to monitoring servers. In push model, the value of threshold is very important. IntelliP decides the size of threshold according to two parameters α and µ. Α α has a close relationship with the current network condition. If current network condition is good, α is small, more metrics would be delivered. While current network condition is poor, the value of α increased, less metrics would be on the network. When the network condition is in an ideal status, the value of α is 1. Another parameter is a constant value set by users. Users can customize the size of µ according to their requirement. We use m_average as the average value of metrics in window, and define threshold as;

threshold= α × µ × m (2)

One problem is that if the host was running smoothly for a long time and resources usage on this host did not change a lot, then the size of window will be very large. This will lost a lot of metrics. We set an upper limit of window size to solve this problem, when the window size increases to the maximum limit, then the size would not increase any more.

.

V. conclusion and future work

In Clouds, resource monitoring is the premise of job scheduling, load balancing, billing and many other major operations. Therefore, data coherency and real-time are important indicators for a monitoring system of Clouds. Elastic compute is one of the main characters of Clouds, resources in Clouds change dynamically. Using a self-adaptive push model called IntelliP, which is based on a modified push model we can build an effective cloud monitoring system which will reduces network congestion and also reduces useless monitoring data coherency between hosts and servers in CloudStack.

In future I will try to improve data delivery control algorithm for increasing effectiveness and adaptive nature of monitoring system, which will be available for all.

References

1. Apache Project, Apache CloudStack, 2013 [online] http://cloudstack.apache.org
2. Sasko Ristov and Marjan Gusev, “Security Evaluation of Open Source Clouds” EuroCon 2013, 1-4 July 2013, Zagreb, Croatia.
3. Lin Kai; Tong Weiqin; Zhang Liping; Hu Chao, “SCM: A Design and Implementation of Monitoring System for CloudStack,” Cloud and Service Computing (CSC), 2013 International Conference on , vol., no., pp.146,151, 4-6 Nov. 2013.
4. He Huang and Liqiang Wang, “P&P: a Combined Push-Pull Model for Resource Monitoring in Cloud Computing Environment” 2010 IEEE 3rd International Conference on Cloud Computing.
5. W. Chung, R. Chang (2009), “A New Mechanism For Resource Monitoring in Grid Computing,” Future Generation Computer Systems – FGCS 25, PP 1-7.