Euro-TM meeting 19-20 May 2011 WG5: Applications & Performance Evaluation S. Distefano, M. Fazio, A. Puliafito (sdistefano, mfazio, unime.it.

Presentazione sul tema: "Euro-TM meeting 19-20 May 2011 WG5: Applications & Performance Evaluation S. Distefano, M. Fazio, A. Puliafito (sdistefano, mfazio, unime.it."— Transcript della presentazione:

1 Euro-TM meeting 19-20 May 2011 WG5: Applications & Performance Evaluation S. Distefano, M. Fazio, A. Puliafito (sdistefano, mfazio, apuliafito) @ unime.it

2 2 Applications/services and basic functions provided in a Cloud are based on the Virtual Resources which are abstracted from Physical Resources. Virtual physical resources, such as V-CPUs, V-Storages, V-Networks etc. V-Networks can be further divided into V-Routers, V-Switches, V-Firewalls, VPNs, V-Interfaces, V-Links based on physical Router/ Switch equipments. Computational resources are managed in terms of Virtual Machines(VMs) and/or Virtual Clusters (VCs). Virtual cluster: a group of VM instances providing same service, front-ended by a network load balancer

3 To prepare VMs with appropriate resources and make them ready for user applications Allocating resources to VMs to match the workloads To prepare a virtual cluster with appropriate instances and make it ready for virtual cluster computation To manage changes in resources availability through VMs restore or migration Goals: High resource utilization Energy efficiency reliability of services Low performance interference

4 Resource Broker 3 Resource Broker 2 Resource Broker 1 VM Virtualized Service VM Virtualized Service VM Virtualized Service VM Virtualized Service

5 5 Resource Providers (RPs) Business companies, cluster managers and even hosts which provide physical resources as IaaS (Infrastructure as a Service). Clients Users/Application that are interested in resource provisioning. They do not have knowledge regarding or control over the underlying data center infrastructures of the Clouds Resource Brokers (RBs) allocate resources for applications/services on multiple VMs in order to fulfill requests of different Clients manage resources provided by several RPs deploying VMs on several Physical Servers in the same Cloud, or even different Clouds. resource allocation in order to obtain the most cost-effective resources

6 collecting and indexing all the resources available from several cloud providers translating the application requirements (expressed in terms of high-level parameters such as execution time, throughput, transaction rate) into low-level criteria related to computing, storage and network distributed resources estimating the capacity needs of Virtual Machines (VMs), managing the available resources in order to ensure specific requirements of QoS monitoring the usage of allocated resources in order to guaratee the SLA with the user performing load balancing based on resource consumption. dynamically reallocating resources, so to have a more efficiently use of available resources when Application/Services request to allocate (extra) resources, checking whether they are authorized managing VMs migration among different physical sites.

7 Transactions can be proposed as a lightweight mechanism to synchronize all the activities of resource Brokers Transactions alleviates many of the problems associated with the locking of VRs during the allocation task STM implementation to protect shared VRs

8 8

9 Managing concurrent allocations from different RBs cut off locks and their related problems in process concurrence Consistency of information whenever RPs update their resources RBs can force some kind of priorities among transactions Depending on the implementation, this priority could either be the age of a transaction or the type of activity (e.g. VM allocation, VM migration, resource discovery...)

10 Granularity of transactions is object-based, where objects are VMs. Objects are shadowed, rather than changed in place. Commit tries to set the clone as the current object. Abort destroy the current clone and tries to set a new clone from the current objects.

11 BufferingLocal cache of available VR clones Conflict detectionCache coherence protocol Abort/RecoveryInvalidate transactional cache activity CommitValidate transactional cache activity Resource Broker VM Virtualized Service VM Buffering Commit Conflict detection Abort/Recovery Transaction Manager Resource Discovery

12 CM is an agent in the Transaction Manager. Notified of transaction events Decides what to do on a conflict: Abort a transaction or spin-wait Which transaction to abort, if any Several available policies Aggressive, Polite, Randomized, Greedy, Karma, Timestamp In Cloud systems, new policies need to be designed to manage different types of activities user-oriented policy provider-oriented policy economy-driven policy

13 Several policies to manage transactions Default : Esegue immediatamente l'abort dell'attaccante, non necessita di meccanismi ausiliari e non comporta overhead di gestione, ma non si adatta al workload. Spinning temporaneo : prevede che l'attaccante attenda in maniera attiva (spinning) il rilascio del lock, non richiede strutture ausiliare e non comporta overhead di gestione (se non quello legato al tempo di attesa), ma non si adatta al workload. Aggressive : Esegue sempre l'abort della vittima, non richiede meccanismi ausiliari e non comporta overhead di gestione, ma non si adatta al workload e può condurre al livelock. Polite : Utilizza un meccanismo di backoff esponenziale, imponendo ad una transazione che rileva un conflitto di attendere per un tempo proporzionale a 2^n ns, con n pari al numero di restart finora eseguiti dalla transazione. Quando n diventa uguale o maggiore di 8, la transazione attaccante esegue l'abort della vittima Randomized : In base ad una certa probabilità (stabilita a priori), la transazione attaccante può eseguire l'abort della vittima (come nel contention manager Aggressive) oppure attendere per un tempo prefissato. Greedy : Ad ogni transazione viene assegnato un timestamp (logico) univoco e monotonicamente crescente. In caso di conflitto, la transazione col timestamp più basso deve eseguire il restart (mantenendo lo stesso timestamp). Greedy parziale : solo le transazioni che hanno eseguito un certo numero prefissato di scritture ricevono un timestamp logico, mentre le altre transazioni vengono eseguite come se il loro timestamp avesse un valore fisso. L'obiettivo è quello di favorire le transazioni più lunghe e non rallentare le transazioni più brevi o read-only. Karma : L'obiettivo è preservare le transazioni che hanno eseguito più lavoro computazionale, stimandolo attraverso il numero di data-item che una transazione ha acceduto. In caso di abort, la priorità non viene resettata, dando alla transazione una maggiore possibilità di completamento. Timestamp : ogni transazione memorizza un timestamp pari al valore del tempo corrente del sistema. In caso di conflitto, confronta il suo timestamp con quella della transazione vittima. Nel caso in cui il timestamp della vittima risulti più recente, il contention manager ne esegue l'abort. In caso contrario, l'attaccante inizia ad attendere per una serie fissata di intervalli: dopo che ne sono trascorsi la meta, l'attaccante segnala con un apposito flag che la vittima potrebbe essere defunta; se alla fine degli intervalli il flag e ancora attivo, il contention manager esegue l'abort della vittima. Il flag viene resettato dalla vittima quando esegue una qualsiasi operazione transazionale, e quando la transazione attaccante se ne accorge, raddoppia il numero di intervalli e ricomincia ad attendere. L'obiettivo di questa

14 Representation of VRs VMs and VCs Atomization strategies to design RB tasks Managing dynamic resources resources abruptly disappear during a transaction

15 Clever Virtual Infrastructure management layer to access and administrate private/hybrid clouds. Provider of Iaas https://clever.unime.it Cloud@Home volunteer computing into the Cloud computing paradigm C@H architecture works as a Cloud Broker https://cloudathome.unime.it/

16 RQM is responsible for the management of resources and services needed to achieve the application requirements imposed by the SLA manager.

17 State Tracker Request Handler Front end Interface Resource Manager Discovery Layer Interface Front end SLA Cloud Providers Discovery Layer Deuce: runtime environment for Java Software Transactional Memory (STM) http://www.deucestm.org Deuce: runtime environment for Java Software Transactional Memory (STM) http://www.deucestm.org State Tracker It keeps the state of the requests stored by the Request Handler and their associated resources It also acts as the essential event dispatcher into which other components can hook routines.

18 STM to support resource provisioning in Cloud environments: Managing concurrent RBs activities and resource updates from RPs Increasing VMs allocation efficiency Specific policies in the CM to design transaction management strategies Use case: C@H project

19