Cloud computing The cloud as a pool of shared hadrware and software resources

Transcription

1 Cloud computing The cloud as a pool of shared hadrware and software resources cloud Towards SLA-oriented Cloud Computing middleware layers (e.g. application servers) operating systems, virtual machines middleware layers (e.g. application servers) operating systems, virtual machines middleware layers (e.g. application servers) operating systems, virtual machines cpu, memory, disk cpu, memory, disk cpu, memory, disk Sara Bouchenak INSA Lyon Sara.Bouchenak@insa-lyon.fr 3 rd Franco-American Workshop on CyberSecurity, December 8-10, 2014, Lyon, France The cloud as a means for distributed applications to: pick up required resources access infinite remote resources access on - demand resources (pay - as - you - go) transparent resource management December 10, QoS,, SLA QoS Many quality-of-service criteria Performance (e.g. service response time, service tjhroughput) Dependability, Availability (e.g. service abadon rate), Reliability Security, etc. Costs Energetic costs Financial costs Service Level Objective for a given QoS criterion/metric Examples: a target service level, e.g. a minimum service throughput, a maximum service abandon rate a service level interval service level maximization/minimization SLA (Service Level Agreement) A contract between the service provider and service customer Ideally, a combination of a set of and cost constraints Example: 99% of service requests are processed within 1s with a minimal energetic cost December 10, QoS and SLA in clouds? Some initiatives Amazon EC2, Rackspace, 3tera clouds Restricted to a single QoS criterion Service unavailability due to computer failures Other QoS aspects not tackled (performance, security, energy, financial costs, etc.) Ad-hoc and incomplete approaches Is the SLA guaranteed/violated by the cloud? E.g. Amazon EC2 customers must provide proofs of cloud service unavailability: capture the failure, document it, send the "proof" to Amazon, within 30 days This is against one of the main motivations of Cloud Computing: "hide complexity of resource management and provide simple access to cloud services by the customer" December 10,

2 Open Challenges & Perspectives Multicriteria SLA: dependability, performance, cost, etc. Towards scalable and distributed SLA control Consider different applications and Big Data services Objective 1: Define a new cloud model, the SLAaaS (SLA aware Service) Orthogonal to other cloud models (IaaS, PaaS, SaaS) A cloud presents, along with its service interface, a non-functional SLA interface Allow a customer to compare different cloud service providers regarding the provided From cloud provider perspective Multi-objective SLA between cloud provider and cloud customer Fully elastic cloud via dynamic resource re-allocation, reconfiguration Handle cloud dynamics, workload variations From cloud customer point of view Automatically notify the customer about SLA violation, energy footprint, etc. Stress/evaluate dependability and scalability of Big Data cloud services, real workloads AMADEOS project: MyCloud project: December 10, December 10, Objective 1: Define a new cloud model, the SLAaaS Challenges Towards a control - theoretic approach [ACM OSR 2013] ConSer: Control of server systems [IEEE Trans. Comp. 2011] MoKa: Control of multi - tier distributed web systems [IGI Global, 2011] MoMap: Control of MapReduce systems [ACM CCGrid 2013] MRBS: Bechmarking framework for Hadoop MapReduce [IEEE SRDS 2012] December 10, Objective 1: Define a new cloud model, the SLAaaS Challenges Towards a control - theoretic approach [ACM OSR 2013] ConSer: Control of server systems [IEEE Trans. Comp. 2011] MoKa: Control of multi - tier distributed web systems [IGI Global, 2011] MoMap: Control of MapReduce systems [ACM CCGrid 2013] MRBS: Bechmarking framework for Hadoop MapReduce [IEEE SRDS 2012] December 10,

3 Challenges in autonomic reconfiguration of cloud services 1) Complex Multiple service level objectives () performance, availability, dependability, security, etc. Challenges in autonomic reconfiguration of cloud services 3) Time-varying and nonlinear behavior Workload amount (#concurrent client requests) Trade - off antagonist at least 99% of client requests are admitted and processed within 1s, with a minimal financial cost availability performance cost 2) From to resource allocation/configuration Amazon EC2 cloud bime cloud application Resources Small instance $0.085 per hour Availability level 99% of requests are processed Large instance Extra large instance Number of instance $0.34 per hour $0.68 per hour X unitary price Nontrivial -toresource allocations Performance level Cost constraint requests processed within 1s minimal cost Workload amount of the soccer World Cup Web Site [Arlitt et. al., HP 99] December 10, December 10, A control - theoretic approach exogenous inputs Feedback control loop control knobs Target system measured service levels service costs Followed approach (1) Utility: State the objective and capture the trade-off Multicriteria utility function (2) Model: Describe system behavior Relationship between allocated resources and service levels and costs inputs exogenous variables resource allocations System model predicted service levels service costs outputs Exogenous inputs: Workload amount Workload mix Control knobs (i.e. resource allocations): Cache size Server admission control Server provisioning Content quality level System outputs: Cache hit ratio Service QoS Resource utilization Service differentiation ratio (3) Control: Solve the system Calculate (optimal) resource allocation Maximize utility function Based on the model (4) Implement the solution Translate theoretical optimal solution into concrete implementation Not trivial: automatically (re)determine model s parameters December 10, December 10,

4 Objective 1: Define a new cloud model, the SLAaaS Challenges Towards a control - theoretic approach [ACM OSR 2013] Control of server systems Server admission control Prevent server thrashing, denial-of-service Multi-Programming Level () ConSer: Control of server systems [IEEE Trans. Comp. 2011], PhD L. Malrait MoKa: Control of multi - tier distributed web systems [IGI Global, 2011], PhD J. Arnaud clients Admission control MoMap: Control of MapReduce systems [ACM CCGrid 2013], PhD M. Berekmeri MRBS: Bechmarking framework for Hadoop MapReduce [IEEE SRDS 2012], PhD A. Sangroya December 10, rejected server Classical configuration parameter in server systems Apache Web server s MaxClients MySQL database server s max_connections December 10, Trade off between server performance and availability Experiments conducted with PostgreSQL database server, running TPC-C benchmark Related work Server admission control Ad-hoc techniques, heuristics [Menascé et al., EC 01] Best - effort behavior Linear models [Diao et. al., NOMS 02] [Parekh et al., RTS 02] Can not render the whole nonlinear behavior of server systems Nonlinear models based on queueing theory [Robertsson et. al. CDC 04] [Tipper et. al., JSAC 90] [Wang et. al. INFOCOM 96] Multiple model parameters, hard to calibrate Performance (client request latency) Availability (client request abadon rate) How to configure server s trading-off performance and availability? Do not tackle full dynamics (workload types) Restricted to a single QoS aspect, SLO December 10, December 10,

5 ConSer*: Control of server systems latency and : L L abandon rate max & α ConSer modeling latency and : L L abandon rate max & α workload amount N & mix M AM-C controlled Target server L (latency) α (abandon rate) workload amount N & mix M AM-C controlled Target server L (latency) α (abandon rate) (1) Utility: State the objective and capture the trade-off AM-C (availability-maximizing objective) (P1) average client request latency does not exceed a given L max (P2) and abandon rate is made as small as possible (2) Nonlinear fluid modeling State variables: Exogenous inputs: Control input: Server model admitted requests Outputs: PM-C, PA-AM-C, AA-PM-C (workload amount) N throughput of processed requests L (latency) (incoming throughput) T i * L. Malrait, S. Bouchenak, N. Marchand. Experience with ConSer: A System for Server Control Through Fluid Modeling. IEEE Transactions on Computers, 60(7), (workload mix) M request abandon rate α (abandon rate) In collaboration with the NeCS INRIA research group on Control Theory request latency December 10, December 10, ConSer control latency and : L L abandon rate max & α ConSer AM-C control evaluation workload amount N & mix M AM-C controlled Target server L (latency) α (abandon rate) (3) Control server s AM-C (availability-maximizing control) (P1) average client request latency does not exceed a given L max (P2) and abandon rate is made as small as possible Performance improved by up to 30% ; γ > 0 If L > L max ; (P1) ; a decreased value of N e If L < L max ; (P1) & possibly (P2) ; an increased value of N e Efficient control: O(1) Experiments conducted with PostrgeSQL database server running TPC-C benchmark, AM-C control law, L max = 8s December 10, December 10,

6 ConSer AM-C control evaluation Objective 1: Define a new cloud model, the SLAaaS Challenges Towards a control - theoretic approach [ACM OSR 2013] ConSer: Control of server systems [IEEE Trans. Comp. 2011], PhD L. Malrait MoKa: Control of multi - tier distributed web systems [IGI Global, 2011], PhD J. Arnaud MoMap: Control of MapReduce systems [ACM CCGrid 2013], PhD M. Berekmeri Experiments conducted with PostrgeSQL database server running TPC-C benchmark, AM-C control law, L max = 8s MRBS: Bechmarking framework for Hadoop MapReduce [IEEE SRDS 2012], PhD A. Sangroya December 10, December 10, Big Data Systems - MapReduce MapReduce Big Data applications A popular programming model A runtime environment on cluster of commodity computers Automatic Data partitioning Data replication Task scheduling Fault tolerance A wide range of applications log analysis, data mining, web search engines, scientific computing, business intelligence, etc. Big companies use it Amazon, ebay, Facebook, LinkedIn, Twitter, Yahoo!, etc. Motivation Lots of work to improve MapReduce dependability and performance New fault-tolerance models [Costa, CloudCom 11] Replication and partitioning policies [Ananthanarayanan, EuroSys 11] [Eltabakh,VLDB 11] Scheduling policies [Zaharia, OSDI 08] [Isard, SOSP 09] [Zaharia, EuroSys 10] Cost-based optimization [Herodotou, VLDB 11] Resource provisioning [Verma, Middleware 11] Most evaluations use micro-bechmarks Not representative of full distributed, concurrent applications Not representative of realistic workloads No dependability benchmarking December 10, December 10,

7 MRBS objectives Empirical evaluation of dependability and performance of MapReduce Fault - tolerance Scalability MRBS characteristics Variety of application domains, workloads and dataloads Compute - oriented vs. data - oriented applications Batch applications vs. real - time applications Variety of Big Data workloads and faultloads Various workloads, dataloads Different fault models Different fault rates Portable and easy to use on a wide range of clouds Different cloud infrastructures * A. Sangroya, D. Serrano, S. Bouchenak. Benchmarking Dependability of MapReduce Systems. The 31 st IEEE Int. Symp. on Reliable Distributed Systems (SRDS 2012), Irvine, CA, Oct December 10, December 10, Use-case: Comparing two MapReduce frameworks w.r.t. performance & dependability How does Hadoop 1.0 compare to Hadoop 0.20 w.r.t. performance? Use-case: Comparing two MapReduce frameworks w.r.t. performance & dependability How does Hadoop 1.0 compare to Hadoop 0.20 w.r.t. dependability? Response time with Hadoop 1.0: up to +40% Throughput with Hadoop 1.0: up to -42% Less failed jobs with Hadoop 1.0 Experiments conducted on a ten node Hadoop cluster Experiments conducted on a ten node Hadoop cluster December 10, December 10,

8 Use-case: Comparing two MapReduce frameworks w.r.t. performance & dependability How does Hadoop 1.0 compare to Hadoop 0.20 w.r.t. dependability? Conclusion & Perspectives Multicriteria SLA by design Different applications Less I/O failures with Hadoop 1.0 Experiments conducted on a ten node Hadoop cluster December 10, December 10,