image credit Fabien Hermenier Cloud compting 101

Transcription

1 image credit Fabien Hermenier Cloud compting 101 1

2 ? was cloud computing needed 2

3 3 Mainframes

4 Then came with affordable PCs Then we spread out the load for security, performance, manageability Then we bought tons of servers to support load spikes 4

5 5

6 6 Amazon X-mas items sold each second

7 Where is energy spent? 7

8 episode 0 rise of the cloud 8

9 2011 Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources that can be rapidly provisioned and released with minimal management effort or service provider interaction. 9

10 1 self-provisioning, On-demand self-services no human intervention

11

12 2 broad network access availability over the network standard mechanisms

13 3 multi-tenant resource pooling virtual or physical resources on-demand allocation location independance

14 reserved instances (yearly based) on-demand instances (hourly based) hotspot instances (market based)

15 Amazon EC2 HotSpot instances bid over the market price to get the instance 15

16 rapid elasticity fast (de-)allocation of resources scale to infinity 4

17 vertical elasticity Tiers 1 Tiers 2 Tiers 3 17

18 vertical elasticity Tiers 1 Tiers 2 Tiers 3 17

19 Tiers 1 Tiers 2 Tiers 3 horizontal elasticity 18

20 Tiers 1 Tiers 2 Tiers 3 horizontal elasticity 18

21 5 metering measured service 19 capabilities transparent reporting

22 20

23 and I will call it cloud computing 21

24 Cloud Computing origins 22

25 If computers of the kind I have advocated become the computers of the future, then computing may someday be organized as a public utility just as the telephone system is a public utility... The computer utility could become the basis of a new and important industry John McCarthy, 23

26 cluster computing 80s loosely coupled co-located servers single tenant non-interactive workload rigid jobs 24

27 Cloud or not? on demand self-services broad network access resource pooling rapid elasticity measured service 25

28 Cloud or not? on demand self-services broad network access resource pooling rapid elasticity measured service 26

29 grid computing Ian Foster et al

30 Power Grid Analogy 28

31 Power grid Computing grid multiple providers heterogeneous sources multiple clients abstract source virtual organisation heterogeneous hw. multiple applications abstract resources live consumption location doing * at batch jobs independence large scale 29

32 Worldwide LHC Computing grid 25k T ransfer T hroughput :40 t o :40 UTC 20k T hroughput (MB/s) 15k 10k 5k 0k 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 alice atlas cms lhcb 30 22:00 23:00 00:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 10:00 11:00 12: centres to analyse 30 PB / year

33 Cloud or not? on demand self-services broad network access resource pooling rapid elasticity measured service 31

34 Cloud or not? on demand self-services broad network access resource pooling rapid elasticity measured service 32

35 Client 1 Client 2 Client 3 Application Service Provider 95+ remote access to dedicated applications service oriented pay as you go

36 Cloud or not? on demand self-services broad network access resource pooling rapid elasticity measured service 34

37 Cloud or not? on demand self-services broad network access resource pooling (not real hw resources) rapid elasticity measured service

38 2002 computers on demand. Deploy full custom stacks (OS to applications)

39 to (re)deploy reproducible network experiments multi-tenant, (limited on purpose) resource pooling, 37

40 to (re)deploy reproducible network experiments 50ms, 5% loss 10ms 100Mb/s 10ms 38

41 to (re)deploy reproducible network experiments 50ms, 5% loss 10ms 10ms 39

42 Cloud or not? on demand self-services broad network access resource pooling rapid elasticity measured service 40

43 Cloud or not? on demand self-services broad network access resource pooling rapid elasticity measured service 41

44 2001+ S ervice O oriented A rchitecture composable unassociated, loosely coupled units 42

45 exponential grows since 2001 private and public services to support its growth

46 Two pizza rule If a team can t be fed by two pizzas then it is to big - Jeff Bezos (founder/ CEO of amazon.com) 44

47 800 x tons of API, microservices devoted to automation, flexibility, on-demand services for public and private use 45

48 2006 scalable web services for other websites or client-side applications

49 SOAP & REST over HTTP pay as you go elastic *-oriented services *data, network or computation 47

50 on demand self-services Cloud! broad network access resource pooling rapid elasticity measured service 48

51 RECAP 49

52 I have a dream, it was about Utility Computing John McCarthy

53 web + grid computing + resources on demand + service oriented architectures cloud computing (2006) 51

54 can we talk about cloud computing now? 52

55 ?aas 53

56 SaaS Service as a Service web access to commercial sw. one to many model customers don t handle upgrades API for integration 54

57 55

58 56

59 PaaS Platform as a Service jailed runtime available to host applications generic or provider-specific APIs no control over the environment 57

60 $ heroku login $ git clone $ cd java-getting-started $ heroku create Creating warm-eyrie done, stack is cedar-14 git@heroku.com:warm-eyrie-9006.git Git remote heroku added $ git push heroku master deployed to Heroku $ heroku ps:scale web=1 58

61 59

62 IaaS Infrastructure as a Service low-level resources to deploy arbitrary software stacks complete control over its network, storage and OS

63

64 62

65 applications runtimes ol school IT you manage integration/security database servers virtualisation server HW storage network

66 applications runtimes SaaS integration/security database servers virtualisation server HW managed by vendor storage network

67 you manage applications runtimes PaaS integration/security database servers virtualisation server HW managed by vendor storage network

68 Open-source PaaS stacks

69 IaaS you manage applications runtimes integration/security database servers virtualisation server HW storage network managed by vendor

70 Open-source IaaS stacks (2008+) (2008+) cloudstack (2010+) (2012+)

71 vendor lock-in IaaS PaaS SaaS

72 Deployment models

73 public cloud general availability to everyone the real cloud reduced costs trust issues?

74 cloud computing vs. fog of war 72

75 give me your code & data Trust in me 73

76 I m aware read my mails what is my is hacked? 74

77 private cloud worldcompany SA self hosted cloud might reduce TCO stronger trust better manageability

78 worldcompany SA hybrid cloud

79 LB multi-clouds you spread your application avoid Single Point of Failures* take the benefits of each cloud

80 inter-clouds they outsource your components agreements between the providers cloud of clouds (federation)

81 distributed clouds back to volunteer computing (Boinc, ) 79

82 community cloud private cloud by and for multiple organizations

83 Assume you could start with super reliable servers (MTBF of 30 years) Build computing system with 10 thousand of those Watch one fail per day Things will crash. Deal with it! 81 Dean Keynote, LADIS 2009

84 Typical first year for a new google cluster ~0.5 overheating (power down most machines in <5 mins, ~1-2 days to recover) ~1 PDU failure (~ machines suddenly disappear, ~6 hours to come back) ~1 rack-move (plenty of warning, ~ machines powered down, ~6 hours) ~1 network rewiring (rolling ~5% of machines down over 2-day span) ~20 rack failures (40-80 machines instantly disappear, 1-6 hours to get back) ~5 racks go wonky (40-80 machines see 50% packetloss) ~8 network maintenances (4 might cause ~30-minute random connectivity losses) ~12 router reloads (takes out DNS and external vips for a couple minutes) ~3 router failures (have to immediately pull traffic for an hour) ~dozens of minor 30-second blips for dns ~1000 individual machine failures ~thousands of hard drive failures slow disks, bad memory, misconfigured machines, flaky machines, etc. Long distance links: wild dogs, sharks, dead horses, drunken hunters, etc. 82

85 A distributed system is one in which the failure of a computer you didn't even know existed can render your own computer unusable Leslie Lamport 83

86 Building fault tolerant services at every level be pessimistic deal with failures deal with inconsistency 84

87 prehistorical times internet 85

88 prehistorical times 2 Single Point of Failure limited scalability not scalable online not upgradable online 86

89 n-tiered apps to the rescue Tiers 1 Tiers 2 Tiers 3 87

90 n-tiered apps to the rescue Tiers 1 Tiers 2 load balancing horizontal scalability upgradable online Tiers 3 88

91 load balancing balancing balancing spread incoming requests to backend services synchronous communications 89

92 possible load balancing algorithms 4, 1, 6, 5, 4, 3, 2, 1 Round Robin 5, 2 6, 3 nice on homogeneous nodes

93 possible load balancing algorithms 6, 5, 3, 1, 6, 5, 4, 3, 2, 1 weighted weight the nodes or the requests depending on their size 4, 2

94 spread incoming requests to backend services synchronous communications is everything balanceable? 92

95 load balancing stateful stuff 1 3, 2, 1 Round Robin 2 3

96 load balancing stateful stuff, 4, 3, 2, 1 Round Robin 2 3

97 load balancing stateful stuff 4, 4, 3, 2, 1 Round Robin 2 3

98 load balancing stateful stuff achievement unlocked 4, 4, 3, 2, 1 Round Robin 2 3

99 load balancing stateful stuff, 4, 3, 2, 1 Round Robin

100 load balancing stateful stuff, 4, 3, 2, 1 FAIL Round Robin

101 load balancing stateful stuff + sticky sessions, 4, 3, 2, 1 Round Robin yellow stuff IP based

102 load balancing stateful stuff + sticky sessions, 4, 3, 2, 1 Round Robin yellow stuff IP based not resilient to node failures

103 elastic load balancing mod_proxy_balancer lb galera linux virtual server 96

104 scaling 97

105 scale up / down vertical sclaing Tiers 1 Tiers 2 Tiers 3 98

106 scale up / down vertical sclaing Tiers 1 Tiers 2 Tiers 3 98

107 historical method (more powerful hardware) mostly cold approaches easy to implement coldly hardware bounded does not address reliability vertical scaling 99

108 support for hot plug CPU what about the runtime? 100

109 Tiers 1 Tiers 2 Tiers 3 horizontal scaling 101

110 Tiers 1 Tiers 2 Tiers 3 horizontal scaling 101

111 horizontal scaling not application agnostic require a load balancer / synchronisation scale to the infinite in theory support node failure

112 Elasticity optimize performance in live through scaling requests

113 static elasticity initiated by the administrator not feedback based error prone under/over-estimations

114 static elasticity initiated by the administrator instances not feedback based error prone under/over-estimations 7am 8am 9am 10am time time-driven only?

115 latency-aware elasticity getting a VM takes up to 5 minutes think in terms of trends spare space just in case 105

116 static elasticity vertical elasticity horizontal elasticity forecasts reality t 106

117 dynamic elasticity initiated by the app itself rule based system feedback from monitoring data implemented inside/outside the app

118 dynamic elasticity horizontal elasticity forecasts reality t 108

119 109

120 dynamic elasticity scale where its matter monitor each tier to indentify the bottlenecks scale out apache/tomcat/mysql? 110

121 cost model for elasticity service cost instance cost (hourly based) /!\ don t scale too often 111

122 RECAP 112

123 CLOUD IS ABOUT $$

124 CLOUD IS ABOUT SCALABILITY

125 CLOUD IS ABOUT RESILIENCY

126 CLOUD IS ABOUT TRUST