Monitoring as a Service for Cloud Environments

Transcription

1 Monitoring as a Service for Cloud Environments Julius Muelleri, David Palma2, Giada Lande, Joao Soares4, Bruno Parreira4, Thijs Metsch5, Peter Gra/, Alexander Georgiev6, Yahya AI-Hazmil, Thomas Magedanzl, Paulo Simoes7 ITechnical University, Berlin, julius.mueller@tu-berlin.de, yahya.al-hazmi@tu-berlin.de, thomas.magedanz@tu-berlin.de 20neSource, Coimbra, Portugal, palma@onesource.pt 3Nextworks, Pisa, Italy, g.landi@nextworks.it 4Portugal Telecom Inova<;ao, joao-m-soares@ptinovacao.pt, bruno-m-parreira@ext.ptinovacao.pt 51ntel GmbH, Dublin, Ireland, thijs.metsch@intel.com 6CloudSigma, Zurich, Switzerland peter.gray@cloudsigma.com, alexander.georgiev@cloudsigma.com 7Paulo Simoes, DEI-CISUC - University of Coimbra, psimoes@dei.uc.pt Abstract: Precise and dynamic measurements of physical and virtualized telecommunication environments are critical for ensuring optimized resource management and control. The flexible service instantiation and disposal of Virtual Network Functions (VNF), within geographically distributed cloud service environments, requires automated adjustments of monitoring systems. Moreover, the overall goal of reducing operational and capital expenditures, for supporting and managing a distributed monitoring system, requires such a system to be elastic and on-demand. Currently, monitoring systems are not able to fulfil these requirements. This paper introduces a novel design and specification of an on-demand monitoring as a service system for fixed and mobile cloud environments, from the low-level resources to the high-level services, across the four different domains: radio access network, mobile core network, data centre and network support systems. Keywords-Monitoring; Cloud; Service; Mobile I. INTRODUCTION The trend in Information Communication Technology (lct) systems moves away from static services and platforms towards virtualized cloud based solutions supporting Software Defined Networking (SDN)/OpenFlow [2] and Network Function Virtualization (NFV) [3]. Virtualization in ICT enables on-demand resource scaling, towards a better resource utilization through aligning the resources demanded by a service in real-time on the actual service capacity. In order to support this level of flexibility, an accurate and precise monitoring solution is required, exposing real-time monitoring data out of the cloud environment towards the service management and orchestration plane. Such a smart monitoring solution would be able to support other cloud services on flexible scaling up and down service components, changing the geographical location through service migration or multiplying a service instance in peak-times dynamically. Today's existing monitoring solutions are design-static and do not support a full service life-cycle. Existing monitoring solutions are missing features such as dynamic adaptations for efficient extraction, pre-processing, distribution, storage, analysis and notification of metrics such that higher-level services can utilise these facilities on demand to actually enable adaptive platform services. A specific challenge is the additional signalling load of a monitoring system in fixed and mobile cloud environments, which has to be limited as one of the cost factors. On-demand monitoring solutions are expected to integrate new service instances transparently in the monitoring system and thus enable the flexible inclusion or exclusion of complete services or individual service instance parameter. This paper presents a new concept for Monitoring as a Service (MaaS), which supports the life-cycle of fixed and mobile cloud-based environments through service management, control and orchestration optimally. The MaaS system extracts different monitoring data out of several domains of a cloud environment. Four different classification domains have been identified in total: Domain A - Represents all the elements within the Radio Access Network (RAN), also known as the Access Network Infrastructure including base stations. Domain B - Includes the various virtual and physical services or elements that are part of the Mobile Core Network including IP Multimedia Subsystem (IMS) and Evolved Packet Core (EPC). Domain C Constitutes the Cloud datacentre Infrastructure and the Network Infrastructure. The virtual network infrastructure that may be spanned through various datacentres is included in this domain. The network infrastructure represents the services deployed in network operator infrastructures enabling Connectivity-as-a-Service. Domain D - This category comprehends all the remaining services that are related to the cloud based (mobile) network, operation Support Service (OSS) and Business Support Service (BSS). The main objectives of the MaaS are firstly to provide monitoring metrics for assuring the health and the performance of the mobile cloud infrastructure. Secondly, monitoring should support the creation of metric and context-based information (notifications/events) to be used to support adaptive service life-cycle functionality. Thirdly, the MaaS system is able to extract monitoring data from different sources/domains and exposes them over a unified interface towards external services or components. This paper begins by outlining a number of existing monitoring solutions in Section 2. New challenges in cloud environments and limitations of today's monitoring systems are compared against MaaS's system requirements in Section 3. Building on the previous sections, a reference monitoring /14/$ IEEE 174

2 system architecture is presented in Section 4, before specifying the Monitoring as a Service Architecture Model in Section 5. Sequence diagrams of a dynamic instantiation of MaaS in a cloud environment are outlined Section 6 followed by a conclusion summarizes the main paper's contribution and highlights the outlook and future work. II. RELATED WORK The monitoring of computer systems has long been an important task to consider and include in any service of infrastructure with critical goals [7]. In fact, different aspects are likely to be monitored, serving different purposes from charging and billing (confirming the specified Service Layer Agreements, SLAs) up to real-time service optimisation, triggering or stopping processes in order to meet the measured metrics. The number and nature of existing metrics that are actually considered in the literature is vast, being dependent on the purpose to which monitoring is being considered. Moreover, when significant paradigm shifts in computing occur, different techniques for monitoring tools and architectures often arise. With the current trend for Cloud Computing, alternative mechanisms to traditional monitoring can be recognized in the market. A large number of commercial and open source products can be found today. Nonetheless, these approaches are still insufficient in terms of flexibility and integration between different clouds or federated clouds. At this point, existing and widely deployed monitoring solutions, such as Zabbix, can help with the integration of multi-tenant monitoring data. A. Zabbix Zabbix [5] provides agents for a wide range of operating systems, each supporting active as well as passive modes to monitor data. It provides standard monitoring metrics out of the box and has the possibility to set up individual customized user-defmed configuration, registration templates for complete host-groups. Furthermore, it supports Create-Read-Update Delete (CRUD) operations via a JavaScript Object Notation Remote Procedure Calls (JSON-RPC) based Application Programming Interface (API) for all relevant objects. Additionally, Zabbix comes with an intuitive web-interface. Data can be collected through the Simple Network Management Protocol (SNMP), using specific data objects that can be polled from the network hardware. An Object can be, for example, a port status or a port uplink throughput value. Each Object in SNMP has an Object Identifier (ID), known as OlD. The return values of OlD polls, known as "Items" in Zabbix, can then be pooled together to form aggregate Items using mathematical equations. Zabbix can assign Triggers to Items, which can take action once the trigger threshold has been breached. Examples include sending an , or resorting to a Short Message Service (SMS), running a shell script or any other user-defined action when a router port is transmitting a higher than user-specified level of traffic. This can then be used to track down the failure of a routing path for example. All routers based on the Linux kernel have Zabbix agents deployed on them to report metrics to their respective Zabbix servers. Network devices that do not support Zabbix agent deployment are either polled periodically via SNMP by the Zabbix server, or are configured to fue off Traps when a predefined state is reached, providing they support such functionality. The database for each Zabbix server can be MySQL [8], PostgreSQL [9], MS SQL Server [10], IBM DB2 [11], amongst others and can be hosted on the same machine or externally. It is recommended to host the database externally where heavy-load is to be expected from a large number of Zabbix clients. B. Ceilometer Ceilometer [6] aims to become the reference framework to collect measurements within OpenStack [4], across all the different system components. Its primary uses include monitoring and metering functionalities, performing actions in a flexible and extendible way, so that it can be easily enhanced for other objectives. The main scope of the Ceilometer project is to provide an efficient collection of metering data in terms of physical or virtual resources utilisation and in terms of network costs. To fulfil this requirement, the data can be collected by monitoring notifications sent from existing services or by polling the infrastructure. The security of the information exchanged between the various actors of the system is guaranteed using signed and non-reputable metering messages. Ceilometer aims to respect the easy-to-use constraints. Users or the upper layer software components will be able to retrieve metering counters through a Representational State Transfer (REST) interface and to easily configure the type of data to be collected. Generally all the Ceilometer modules, apart from the Compute Agents (i.e. the Central Agent, the Collector, the Data Store, and the API Server), are installed in the centralised Cloud Management Server and are configured so that the metering data are stored into the collector database (e.g. Mongo DB [12] or other databases). Similarly to Zabbix, Ceilometer allows data collection from different and varied devices; managing it and issuing appropriate actions or triggering different operations, according to the specified options. However, Ceilometer was foreseen within OpenStack and its architecture is closely coupled with this IaaS, making its integration more difficult in heterogeneous cloud environments. III. CHALLENGES AND REQUIREMENTS Monitoring is a crucial component of any cloud so that physical hardware can be optimally utilized and hardware procured as projected utilization saturates it. Monitoring Virtual Machines (VMs) is crucial for automatic and effective scaling to occur, matching the load placed on the VMs representing the service they provide. Load balancing cannot occur unless accurate load and performance data is provided 175

3 by the monitoring system employed. Significant costs and signalling reductions can be achieved through specifying precisely the required metrics to be monitored. The basic cloud principles apply for mobile cloud networking (MCN), as infrastructure is able to dynamically scale back during lower demand periods and increase capacity during peak times. To meet such a requirement, we must rely on thorough system and application level monitoring. Monitoring as a Service must first meet the basic cloud principals and reflect a model of on-demand, self-service, elastic, multi-tenant and pay-as-you-go computing. On-demand - The various components that make up the monitoring system are provisioned and deployed on-demand. If required, the monitoring agents and adapters related to the specific service are also provided on demand, usually running inside the VMs related to the service instance itself. Self-service - The monitoring system must provide essential functionality to the core components constituting the mobile cloud services, as well as to provide the foundation for other supporting services, such as Rating Charging and Billing as a Service (RCBaaS), Load Balancing as a Service (LBaaS) and Analytics as a Service (AaaS). When requesting a service, the user must be able to specify the various monitoring options, including the type of information to be monitored, the granularity and frequency of the measurements, as well as the time period for reporting historical data. In addition, the user should be able to make modifications to the monitoring system dynamically. Depending on the user's choices, the core monitoring system and the required monitoring agents and adapters will be automatically provisioned with the requested capabilities. Elasticity - The system must be able to scale automatically and needs to include the dynamic creation and deletion on monitoring agents and/or adapters. Multi-tenancy - The monitoring system can be provided in two different ways. Firstly, a dedicated monitoring system can be instantiated on a per-tenant basis without being required to share system components. Alternatively, multiple tenants can share a single monitoring core system. In this case the monitoring agents are still provided per-tenant but the core components are shared. Pay-as-you-go - The cost of the monitoring service should be determined by the level of monitoring provided and the amount of parameters requested by the user. The cost model should be incorporated to include the overall cost of the core mobile cloud service as well as MaaS as a supporting service. Monitoring requirements have been identified as a set of common metrics serving an end-to-end MCN service. Firstly, as MaaS is considered a supporting service and as such it is important, as any monitoring solution, be as lightweight as possible to reduce the overhead of the underlying system itself. MaaS collects monitoring data and exposes that data to the functional components of the end-to-end Service, as well as the other supporting services that rely upon it. This data supports the ass by allowing administrators to manage operations, with particular regard to server and network performance, resource management, mobility prediction and provisioning, as well as providing insight into QoS (Quality of Service). BSS is also supported by this data and reflects upon such business related features such as SLA validation, rating, charging and billing, as well as managing customer databases. Two main categories of monitoring requirements have been identified, which need to be covered by the solution: Cross-Service requirements - These are related to generic monitoring functionalities, features and interfaces to be supported independently on the specific MCN Service. Per-Service requirements - These are related to a specific MCN Service and are mainly focused on the metrics and parameters to be monitored and provided to the other service components. The challenge is for service developers to provide a standardized set of hooks in their developed software that will be capable of providing service performance metrics to MaaS. An agent capable of requesting and collecting this service level data, needs to be developed and integrated. This challenge can be broken down in the following ways: a. Developing and standardizing a common interface for all (disparate) Services, enabling them to provide common metrics to all MaaS consumers b. Developing and standardizing domain specific metrics, enabling the commoditization of Services. Performance data specific to a given domain will be made available via domain specific MaaS parameters. This will lead to the commoditization of Services in the context of MaaS in order to provide common and domain specific metrics. c. Identifying existing frameworks or developing custom agents to provide this Service monitoring functionality, which is then forwarded to global centralized monitoring system - namely Common Monitoring and Management System (CMMS). d. Abstracting away the underlying agents, which harvest performance data from Services and infrastructure, thus providing access to performance metrics using a common front-end interface. e. Developing the CMMS in such a way as to enable different performance monitoring agents to be used interchangeably depending on the underlying infrastructure and Service frameworks and languages, all the while doing so without impacting the front-end interface interaction protocol and the resulting monitoring data supplied by the CMMS. The high level, functional and non-functional requirements defined by the monitoring consumers serve all other MCN Services by enhancing their visibility and functionality. The CMMS is required to provide highly adaptable mechanisms for the simultaneous delivery of monitoring information to a set of monitoring consumers such as SLAaaS and RCBaaS. Monitoring consumers use the Front-end interface to programmatically retrieve the metrics provided by the CMMS. For example, SLAaaS depends on MaaS in order to check monitoring data against QoS metrics negotiated between consumer and provider. RCBaaS depends on MaaS for the data related to the tenant's service instance usage, leading to the generation of revenue. 176

4 None of the available solutions including Zabbix and Ceilometer cover all relevant requirements out of this section. IV. REFERENCE MONITORING SYSTEM ARCHITECTURE The Monitoring as a Service has a twofold objective. Firstly, providing metrics for assuring the health and the performance of the mobile cloud infrastructure, and secondly supporting the creation of metric and context-based information (notifications/events) to be used to support adaptive life-cycle functionality. MaaS will follow an approach of extract, pre-process, distribute, store, analyse and notify based on resource specific metrics as depicted in Figure 1. Monitoring Consumer - SubSCribes for specific metric - Exposes subscribed data Monitoring System - Validates monitoring requests - Queries resources or elements in the MCN architecture - Retrieves and exposes monitoring information Resource I Element I MCN SIC - Exposes ability to monitor data or events and supports Real-time monitoring Synchron monitoring, Asynchron monitoring or Event based monitoring Figure 1: General Concept of Monitoring and Relations Monitoring is used in parallel with other MCN Services or MCN Service Instanced Component (MCN SIC) in order to measure specific system parameters (metrics). Therefore monitoring is characterized as a supporting service next to atomic and MCN services. The Monitoring system should be capable of collecting metrics from different systems and on different levels. The main idea is to be able to collect data from the "access" level all the way up to the "application" level. In doing so the monitoring system will allow other services (through monitoring consumption) to get a complete overview. the SI management interfaces. A similar approach can be found in Amazon EC2 [13] which offers an interface for creating VMs and when the VM is created, it can be managed through the Amazon interface or other management interfaces (e.g. Secure Shell (SSH) can be accessed through the Amazon Interface). The most important point in this architecture is that the orchestration of the service instances (by the SO) is hidden from the end-user. The key MCN architectural entities have been drawn in relationship to the previously defined general service and service related entities in the following diagram, Figure 2. B. Common Monitoring Management System Architecture The core of the MaaS architecture is composed of three components: the Frontend, the Metric Storage and the Aggregator component. Furthermore, distributed monitoring agents are connected to the overall MaaS architecture over well-defined interfaces. Figure 3 shows the MaaS architecture (core and monitoring agents) and the entities that interact with it. These latter entities are SM, SO and CC as well as Monitoring Consumers and the Monitoring Agents. The Frontend provides interfaces to the administrating instances (SM, SO and CC) and to the Monitoring Consumer. The administrating instances use the Frontend for configuration purposes while the Monitoring Consumer uses it to retrieve monitoring data. As for the Metric Storage, it is the component responsible for storing the collected metrics, while the Aggregator is the entry point for the monitoring data provided by the Monitoring Agents. <<USeS» " I Servtce I -:n! _ ",," 1 Orcheslr8tor r L' '-1 r- ----'l.:,,.' : <<ltlanages» : 1 <<\Instance», Service V. MONITORING AS A SERVICE ARCHITECTURE MODEL Herein is presented the MaaS architecture model. First, the MCN reference architecture is presented. Then, the Common Monitoring Management System architecture and its framing with the MCN reference architecture are detailed. A. Mobile Cloud Networking Reference Architecture As already stated in the MCN architecture deliverable 2.2 [14], a Service Provider is expected to be able to instantiate service specific instances in particular considering a serviceoriented world. Considering the MCN perspective, this functionality should be exposed by an interface provided by the Service Manager (SM). The expected Service Instances (SI) should be created, configured, orchestrated and managed by a Service Orchestrator (SO). The SO communicates its needs and requirements to the Cloud Controller (CC) in order to create the desired SIs. Once a SI is up and running, an interface is provided to the service consumer. By using this interface, the service consumer is then capable of accessing Figure 2: Relationship Between MCN architectural Entities, General Service and Service Related Entities Bellow the common functional elements are described with reference to the MaaS: Service Manager - The SM interfaces the SO and Cc. The CC instantiates the MaaS SO initially once required. Cloud Controller - The CC manages the physical resources and instantiates the MaaS on behalf of the SO and returns its endpoint (IP and Port) towards the SO. When the CC is deploying an MCN service with monitoring capabilities, we assume that MCN Service has Monitoring Agent functionalities embedded; otherwise the CC will be in charge of deploying the Monitoring Agents within the service components. Service Orchestrator - The SO manages and configures the MaaS. The SO knows the service dependencies and 177

5 requirements. It uses the Frontend interface of the MaaS to configure it for the specific service it is orchestrating. It will also interact with the Frontend to acquire the necessary information for the configuration of the Monitoring Agents. During the MaaS runtime the SO might need to adjust the monitoring system to changes in the service. Monitoring Consumers - The Monitoring Consumers are the entities that use the Frontend interface to retrieve the metrics provided by the MaaS. An example of a monitoring consumer is the SLA service, which needs to collect monitoring information about SIs in order to validate the SLAs associated to the service and verify that its performances are compliant with the QoS metrics negotiated between customer and provider. In order to allow the gathering of monitoring data, dedicated SLA Agents are deployed and provisioned ondemand for each service instance and used during the service runtime to continuously collect the required monitoring data from the monitoring service. Such data are then aggregated in case of composite services and further elaborated within the SLA management system according to specific SLA rules. This approach allows for the evaluation of the QoS delivered for the entire end-to-end service and produce suitable notifications in case of SLA violations. Service lostl'lnoe ::omponen! I Service In.stllnoe Component Monitoring Consumer consumer to configure and manage his monitoring service. Using the Frontend, it is possible to configure the metrics available, which are dependent of the monitoring agents, and its granularity. Although all possible configurations and actions are available in the Frontend, some level of abstraction will be provided regarding the actual provisioning of the service. Besides the configuration, the Frontend is also in charge of delivering monitoring data. The delivery can be made using one or more of the following methods: Polling - the monitoring consumer will query the MaaS through a unique endpoint assigned for this service. The query can either be synchronous or asynchronous. Delivery - the SO informs the MaaS of the endpoint where he wants the monitoring data delivered. The Frontend will use this endpoint to deliver the data, which can be in real-time or synchronous. Trigger - for specific systems, the SO may require a service which is alarm based. He can use the Frontend to configure the conditions that will trigger these alarms. Metric Storage - The Metric Storage is the entity that ensures that all the monitoring data is made persistent, e.g. within a Database. Due to the heterogeneity of the monitoring sources and agents some type of normalization must be made before storing it. The database that composes the Metric Storage component may be provided by a supporting service, Database as a Service (DBaaS). Aggregator - The Aggregator collects all the monitoring data generated by the Monitoring Sources that will be stored in the Metric Storage using the Aggregator component. Although the complete analysis of the data will be performed by the monitoring consumer, the Aggregator will process the raw data before being store in the Metric Storage. The role of the ; analysis at this level is more focused on common and generalized algorithms to summarize and consolidate information from multiple sources. This component can be seen as an interface that enables the fast storage of metrics. Monitoring Source Figure 3: Common Monitoring Management System Architecture Monitoring Agents - Monitoring Agents have three main tasks, the collection, processing and exposure of monitoring data. The first step, the collection, is where all the raw monitoring data is generated by closely tracking the monitoring targets. The processing will normalize the raw data according to the specific metric registration within the Aggregator. The following step will be the exposure of the monitoring data by delivering it to Aggregator. Frontend - The Frontend of the MaaS provides an abstraction layer between the MaaS internals and the Monitoring Consumer. Monitoring consumers will use the Frontend to interact with the MaaS through well-defmed interfaces. This interaction can be for configuration of the MaaS or for the retrieval of monitoring data. The Frontend must expose all the necessary commands for the monitoring VI. MONITORING AS A SUPPORTING SERVICE In the MCN architecture, the MaaS acts as a supporting service for other MCN Services. This means that a generic MCN Service, or its components, can use the MaaS to collect different types of measurements and monitoring information originated and produced from other services or describing the utilization of the virtual infrastructure resources where they are running. In this sense, the MaaS can be considered as a specific component of a whole end-to-end MCN service. As such, following the common life-cycle of MCN service components, a service instance of MaaS can be provisioned, deployed and disposed (together with other atomic and supporting service instances) during the corresponding phases of MCN service life-cycle. Once provisioned and deployed, the MaaS will be able to collect monitoring information from the virtual infrastructure and the running services, so that they can be exposed from a single access point towards a variety of other services and applications. 178

6 This section describes the individual life-cycle stages, presenting the main steps and workflows required to instantiate the MaaS as part of a MCN service. The MaaS deployment can be started any time during the life-cycle of a general MCN service. Since in many cases the MaaS is a mandatory block to allow the proper working of all the other components, it is usually deployed and provisioned jointly with the MCN service itself. However, from a conceptual point of view, it may be instantiated any time during the runtime of the main service. MaaS SO coordinates the actions to terminate the internal services (the DBaaS in this case) and the MaaS instance. Figure 5: Monitoring as a Service Disposal Figure 4: Monitoring as a Service Deployment and Provisioning As shown in Figure 4, the Service Orchestrator of the main service is the entity that triggers the request for a new MaaS instance. This request is processed at the MaaS Service Manager, the entry point for all the external requests related to the life-cycle of a given service instance. At this stage, the Cloud Controller deploys the MaaS SO, which is the entity in charge of managing the MaaS itself, from the deployment to its removal. In other terms, the SO coordinates the creation of the different modules composing the MaaS and their configuration. This step is performed with the cooperation of the Cloud Controller, which instantiates the VM(s) to execute the MaaS components. Moreover, in this phase additional support services, like the DBaaS, are deployed. At the end of the MaaS deployment and provisioning phases, the SM returns an endpoint that can be used by other entities to interact with the MaaS service instance. Several monitoring agents can be deployed for a single MaaS, as required from the main service. The agents are external to the MaaS service core instance and they are used to collect specific types of measurements. They can be instantiated immediately, jointly with the MaaS or added later on, during the main service life-cycle. Each of them must be properly configured to interact with the MaaS and its Aggregation module. The MaaS is usually terminated during the disposal of the main MCN service, together with all its other components. The Service Orchestrator of the main service initiates the disposal procedure contacting the MaaS SM, as shown in Figure 5. The VII. CONCLUSION This paper firstly presents related work on exlstmg monitoring systems, followed by a proposal of a reference architecture for monitoring systems which results on a new concept for on-demand Monitoring as a Service, suitable for heterogeneous information technology environments. The main contribution of this paper is the design and specification of key functional elements, reference points and the usage MaaS together with other Mobile-Cloud Networking project related services. The implementation of the presented concepts and an extensive validation of MaaS are planned as future work. ACKNOWLEDGMENT This work has been funded by the FP7 EU Project # Mobile-Cloud Networking [1]. We thank our project partners for their valuable contributions. REFERENCES [1] FP7 lp Mobile-Cloud Networking project, #318109, web-site: [2] OpenFlow, Open Networking Foundation, [3] Network Function Virtualization (NFV), ETSI, [4] OpenStack, [5] Zabbix, [6] Ceilometer, [7] Meng et ai., 'Reliable State Monitoring in Cloud Datacenters', 001: I /CLOUD , June 2012, pages , [8] MySQL, [9] PostgreSQL, [10] Microsoft SQL, [II] IBM OB2, [12] Mongo DB, [13] EC2 - Amazon Web Services, aws.amazon.com/de/ec2/, 2014 [14] FP7 lp Mobile-Cloud Networking project, Deliverable 02.2 Overall Architecture Definition, Release 1, version 0.6, 30 October 2013, 179