Brokering Techniques for Managing Three- Tier Applicatjons in - PowerPoint PPT Presentation

Brokering Techniques for Managing Three- Tier Applicatjons in Distributed Cloud Computjng Environments Nikolay Grozev Supervisor: Prof. Rajkumar Buyya 7 th October 2015 PhD Completjon Seminar 1

2

3

Cloud Computjng • Cloud computjng ... • is a model for delivering virtualized computjng resources over the Internet; • is supported by large scale data centres aggregatjng commodity hardware; • is subscriptjon based (pay-as-you-go); • Challenges - outages, security, etc. www.google.com/datacenters/ 4

Inter-Cloud Computjng • Motjvatjon: • Mitjgate efgects of cloud outage; • Diversify geographical locatjons; • Avoid vendor lock-in; • Latency. • Solutjon - use multjple clouds 5

Inter-Cloud Computjng: Architectures 6

Inter-Cloud Computjng: Architectures 7

3-Tier applicatjons in cloud 8

3-Tier applicatjons in a Multj-Cloud 9

Research Questjon • H o w t o b r o k e r 3 - T i e r a p p l i c a tj o n s i n a M u l tj - C l o u d e n v i r o n m e n t , considering Quality of Service (QoS) requirements in terms of: • N e t w o r k L a t e n c y A w a r e n e s s — e n d u s e r s s h o u l d b e s e r v e d n e a r t h e i r geographical locatjon to experience betuer responsiveness; • Pricing Awareness — the overall costs for hostjng should be minimized; • Legislatjon/Policy Awareness — legal and politjcal consideratjons about where individual users are served should be honoured; • Code Re-usability — few changes to existjng 3-Tier applicatjons should be made. The technical overhead of moving an existjng 3-Tier system to a Multj- Cloud should be minimal. 10

Research Questjon ? • How to broker 3-Tier applicatjons in a Multj-Cloud environment, considering Quality of Service (QoS) requirements in terms of: • Network Latency Awareness — end users should be served near their geographical locatjon to experience betuer responsiveness; • Pricing Awareness — the overall costs for hostjng should be minimized; • Legislatjon/Policy Awareness — legal and politjcal consideratjons about where individual users are served should be honoured; • Code Re-usability — few changes to existjng 3-Tier applicatjons should be made. The technical overhead of moving an existjng 3-Tier system to a Multj- Cloud should be minimal. 11

12

13

Background and Objectjves • Distributed systems simulatjon has already fostered the research efgorts; • Existjng simulators can be used to simulate batch processing and infrastructure utjlisatjon workloads only; • Previous works on multj-tjer applicatjon modelling have series of shortcomings; • Goal – defjne a fmexible and coarse grained model and simulator for 3-Tier applicatjons in one and multjple clouds. 14

Target Scenario 15

Session Performance Model • AS Memory Load - • AS CPU Load - • DB Memory Load - • DB CPU Load - • DB Disk I/O Load - • Step Size – • Session arrival model: • Model each session type separately • Poison distributjon of a frequency functjon - 16

Simulator Implementatjon 17

Validatjon Environment • 3 - T i e r a p p . d e s i g n e d a fu e r e b a y ; • Client applicatjon, generatjng requests; • Transitjon table; • "Think tjmes“; • Experiments; • B e n c h m a r k i n g ; • Experiment 1 - statjc workload on local infrastructure; • Experiment 2 - dynamic workload on local infrastructure (DC1) and EC2(DC2); 18

Model Extractjon - Example • Execute 2 Experiments: • With 1 user; • With 100 users; • Compute the “average” session behavior; • Standard Linux utjlisatjon measurement tools. 19

Experiment 1: Statjc Workload in 1 cloud Predicted and actual disk I/O utjlisatjon of the DB server with 50, 300, and 600 simultaneous sessions in Experiment 1. 20

21

22

Background and Objectjves • Current Multj-Cloud 3-Tier have limitatjons manage resources and workload suboptjmally; • They do not consider essentjal regulatory requirements; • Goal : propose a general and fmexible architecture that honours key non-functjonal requirements and optjmises cost and latency. 23

Overall Architecture 24

Overall Architecture 25

Load Balancing and Autoscaling • Load balancing algorithm – stjcky or not? • Monitor VM utjlizatjon; • Free underutjlized VMs. • Autoscaling algorithm: • Repeated periodically; • Number of pre-provisioned instances; • Do not terminate before billing tjme is over; 26

Load Balancing and Autoscaling • Load balancing algorithm – stjcky or not? • Monitor VM utjlizatjon; • Free underutjlized VMs. • Autoscaling algorithm: • Repeated periodically; • Number of pre-provisioned instances; • Do not terminate before billing tjme is over; 27

Load Balancing and Autoscaling • Load balancing algorithm – stjcky or not? • Monitor VM utjlizatjon; • Free underutjlized VMs. • Autoscaling algorithm: • Repeated periodically; • Number of pre-provisioned instances; • Do not terminate before billing tjme is over; 28

Load Balancing and Autoscaling • Load balancing algorithm – stjcky or not? • Monitor VM utjlizatjon; • Free underutjlized VMs. • Autoscaling algorithm: • Repeated periodically; • Number of pre-provisioned instances; • Do not terminate before billing tjme is over; 29

Load Balancing and Autoscaling • Load balancing algorithm – stjcky or not? • Monitor VM utjlizatjon; • Free underutjlized VMs. • Autoscaling algorithm: • Repeated periodically; • Number of pre-provisioned instances; • Do not terminate before billing tjme is over; 30

Cloud Selectjon Algorithm • Ensure users are served in eligible clouds; • Timeout; • Estjmate network latency; • Estjmate potentjal cost; • Overloaded infrastructure; • Optjmise latency and cost. 31

Performance Evaluatjon • Previous simulatjon env.; • Clouds of AWS and Google in the US and Europe; • Baseline: • AWS Route 53; • AWS Elastjc LB; • AWS Autoscaling; 32

33

34

Background and Objectjves • Current autoscaling approaches select VMs statjcally: • Applicatjons change over tjme; • Workload changes over tjme; • Infrastructure capacity changes over tjme. • Goal : propose a fmexible approach to VM selectjon that adapts to such changes. 35

Background and Objectjves • Current autoscaling approaches select VMs statjcally: • Applicatjons change over tjme; • Workload changes over tjme; • Infrastructure capacity changes over tjme. • Goal : propose a fmexible approach to VM selectjon that adapts to such changes. 36

Approach Overview 37

Capacity Estjmatjon and Normalisatjon • . • Linux kernel fjle: / p r o c / c p u i n f o ; • Mpstat: %steal, %idle, actjve_memory ; • . • Frequencies: fr 1 , ... fr n ; • . • n max_cores , f rmax , RAM max ; active memory • . r amLoadN orm RAM 38

ANN based online regression • Learning rate and Momentum; • Increase learning rate in the beginning and when anomaly is detected; • Increase momentum at later stages and when no anomaly is detected; • Online training and fjltering; 39

VM type selectjon algorithm • For each VM type: • Estjmate its capacity; • Estjmate how many users it can serve; • Choose best VM type in terms of cost per user; 40

Experimental setup and workload • CloudStone in AWS EC2; • Choose best VM type in terms of cost per user; • Increasing workload for 5 hours; • Workload change afuer 3.5 hours; • Baseline – AWS-like autoscaling; 41

Experimental Results 42

43

44

Background and Objectjves • How to implement the system from Chapter 4 with modern sofuware technologies; • How to easily model user redirectjon requirements; 45

Scope 46

Entry Point – Admission Controller interactjon • Restgul web servers; • Entry Point bufgers and sends requests in batch; • Admission Controller uses a rule inference engine; • Entry Point choses optjmal cloud site. 47

Admission rules • Drools rule inference engine; • 3 layers of rules; • Polymorphism and rules; • Admission through contradictjon. 48

Experimental setup and workload • 24 hours, 2 users per second; • 50% of users require PCI-DSS compliant clouds; • Random citjzenship: Germany, USA, Australia, or Canada; • 50% of US citjzens are government offjcials. 49

Results: dispatch tjmes and destjnatjons 50

Results: dispatch tjmes and destjnatjons 51

52

53

Summary • Proposed a performance model and a simulator for 3-Tier apps in clouds; • Defjned a generic architecture for such applicatjons that honors the key functjonal and non-functjonal requirements; • Proposed a method for VM type selectjon during autoscaling; • Proposed and implemented a user redirectjon approach in Multj- Clouds. 54

Future Directjons • Provisioning Techniques Using A Mixture of VM Pricing Models; • Dynamic Replacement of Applicatjon Server VMs; • VM Type Selectjon In Private Clouds; • Regulatory Requirements Specifjcatjon Using Industry Standards; • Generalisatjon to Multj-Tier Applicatjons. 55