DDS-Enabled Cloud Management Support for Fast Task Offloading

Transcription

1 DDS-Enabled Cloud Management Support for Fast Task Offloading IEEE ISCC 2012, Cappadocia Turkey Antonio Corradi 1 Luca Foschini 1 Javier Povedano-Molina 2 Juan M. Lopez-Soler 2 1 Dipartimento di Elettronica, Informatica, e Sistemistica Università di Bologna (Italy) 2 Departamento de Teoría de la Señal, Telemática y Comunicaciones Universidad de Granada (Spain) 2nd July, 2012

2 Agenda Cloud Monitoring and Management DARGOS Data-Centric Publish-Subscribe Architecture Experimental Results Testbed Description Results Conclusions and Future Work

3 Cloud monitoring Cloud monitoring systems can be categorized: Architectural model: Centralized vs. Decentralized Communication model: Pull vs. Push Deployment model: Agent-based vs. Agentless

4 Resource monitoring in Clouds A typical approach: centralized pull Central node queries and stores remote resource usage pros: easy to implement cons: central point of failure, request-reply, scalability in N:M scenarios, support for different update rates, no notifications

5 Centralized Cloud management Centralized architecture (OpenStack)

6 Centralized Cloud management (II) Virtual Machine instantiation Typical Cloud scenario (OpenStack)

7 Types of loads in Clouds Services Long term duration Load is (almost) stable (e.g. Web server, Databases,...) Tasks Short duration (from seconds to few minutes) Load of each task is unknown a priori

8 Cloud resource monitoring in dynamic scenarios Short-mid tasks with dynamic load Bag of Tasks (BoT) Media transcoding Computation offloading Require an accurate and reliable snapshot of resources available (real-time update) CPU load, memory usage, system load, hypervisor,... Different goals: maximize throughput, minimize power consumption,...

9 DARGOS Distributed Architecture for Resource management and monitoring in clouds A distributed monitoring system Argos Panoptes : Argos the 100 eyed guardian Uses a Publish Subscribe approach Used to collect real time monitoring data for taking scheduling decisions

10 DCPS Data-Centric Publish-Subscribe Entities share a data model instead using interfaces Producers publish data conforming this data model Subscribers receive data matching their interests Publishers and subscribers are decoupled in space and time Middleware can manage data samples

11 DCPS Data Distribution Service (DDS) OMG Specification for Data-Centric Publish-Subscribe Data model Wire protocol Entities exchange Topics (e.g. temperature, 2D position,...) Topics are defined by their name and data type Topic samples can contain key data to identify them Publishers pushes Topic updates into Subscribers local cache QoS control and management Partition mechanisms Unicast and multicast support Adopted in time critical systems (avionics, stock exchange quotations,...)

12 DCPS Data Distribution Service

13 Architecture DARGOS Entities DARGOS has two kinds of entities: Node Monitoring Agent (NMA): collect and publishs local resource usage Installed at each node (e.g. CPU, system load, memory,...) 1 resource, 1 topic Cloud Monitoring Supervisor (CMS): interested in remote monitoring data Discovers and subscribes remote resources Define their own requirements (reliability, acceptable deadlines) Installed in every application interested in resource data (schedulers, dashboard,...)

14 Architecture DARGOS scenario

15 Architecture Node Monitoring Agents (NMA) Collect local resource data and publishes as DARGOS Topics DARGOS NMAs have two operation modes: Periodic NMA pushes periodically resource usage information Maximizes Accuraccy Event based NMA pushes resource information under certain conditions (e.g. resource usage delta exceeds threshold) Maximizes Scalability and bandwidth saving

16 Architecture Periodic vs. Event based Periodic Event-based Period=1 second Samples published=10 Samples sent when usage changes range Samples published=5

17 Architecture Cloud Monitoring Supervisor (CMS) CMS discovers available nodes and their available sensors (DARGOS Topics) CMS subscribe to sensor information of interest (CPU, memory,...) Applications that use CMS: Cloud dashboards, schedulers Each CMS define their own quality of service (QoS) requirements Reliability or best effort (RELIABILITY) Maximum allowable delay between updates (DEADLINE) Maximum refresh rate (TIME BASED FILTER) CMSs establish subscription contracts with NMAs On QoS violations, a CMS can trigger actions

18 Architecture DARGOS-based Cloud management Cloud scenario (OpenStack+DARGOS)

19 Testbed Description Experimental testbed Testbed with DARGOS-enabled OpenStack Cloud DARGOS based OpenStack scheduler Server Consolidation Load balancing Run multiple tasks with random durations and loads

20 Testbed Description Testbed description OpenStack Cloud fabric DARGOS enabled scheduler service Three DARGOS enabled compute nodes RTI DDS 4.5d middleware 1Gbps switch

21 Results Results (VM per node) OpenStack out-of-the-box scheduler OpenStack DARGOS-based scheduler (consolidation)

22 Results Results (bandwidth) Bandwidth consumption per protocol

23 Conclusions Typical centralized Cloud monitoring systems are not suitable for dynamic scenarios DARGOS is a decentralized Cloud monitoring system suitable for fast task DARGOS can also satisfy service scenarios DARGOS is more robust than centralized systems The Data-Centric Publish-Subscribe model used by DARGOS makes possible to manage task oriented Clouds accurately and reliably DARGOS introduce low overhead while maintaining accuracy

24 Future Directions Include more sofisticated scheduling algorithm (e.g. include historical data) Extend the notification mechanism to include alarms or complex events Add customized action registration to automatically react to certain events (e.g. live migrations)

25 Q&A Thank You