Cloud Computing. Up until now

Transcription

1 Cloud Computing Lectures6 and 7 CDNs& Cycle Sharing Up until now Introduction. Definition of Cloud Computing. Grid Computing. 1

2 Summary Content Distribution Networks. Cycle-Sharing: BOINC COFF Content Distribution Networks Mechanism to speedup access to web contents. Before there were web caches, but: The hit percentage grows only logarithmically with the number of clients. In general, they are controlled by ISP (large number of clients). There is a high risk of outdated content. 2

3 Content Distribution Networks Groups of servers in strategic locations on the web. Providing static content: images, video streaming. Large scale content replication + local data access. Replica location is done using DNS redirection or by rewriting URLs at the server: Pros: Reduction of access time. Use of down time for data transfer. Shared infra-structure among content providers. Cons: Performance penalty due to the redirection. Akamai 3

4 Akamai servers in 50 countries clients. Most clients submit all content to Akamaito speedup redirection. Enhanced CDNswith ESI (Edge Side Includes): XML mechanism to create dynamic content in Akamai s caches in order to adapt to local conditions: browser type, region, date, hour Edge Side Includes Examples <esi:try> <esi:attempt> <esi:choose> <esi:when test="$(isie) == 'true'"> <esi:include src="getiframeadfromdb.cgi" maxwait="5000"/> </esi:when> <esi:when test="$(isnn) == 'true'"> <esi:include src="getjavascriptadfromdb.cgi" maxwait="5000"/> </esi:when> <esi:otherwise> <esi:include src="gethtmladfromdb.cgi" maxwait="5000"/> </esi:otherwise> </esi:choose> </esi:attempt> </esi:try> 4

5 Edge Side Includes Examples <esi:choose> <esi:when test="$(geo{'country_code'})"> <tr><td align=left>country Code</td><td align=left>$(geo{'country_code'})</td></tr> </esi:when> </esi:choose> <esi:include src="index$(geo{'country_code'} 'US' ).html" alt="indexus.html" ttl="2h" maxwait="5000"/> Loss of Relevance of CDNs Expensive system administration. Growth of backbone bandwidth. Increase in the percentage of highly dynamic content. Growth of P2P networks. 5

6 Cycle-Sharing Cycle-Sharing or Desktop Grid: the Grids successors The gridssuccess and the inclusion of desktop workstations in grids suggested that: There were underused machines. It s possible to distribute tasks on a wide-area network.. It s not realistic to include those nodes in a integrated administrative infra-structure. However, it s not exactly the same thing More adapted: High computing/communication ratio. Independent tasks. That tolerate errors on a fraction of the tasks. 6

7 Cycle-Sharing Applications Four application types benefit from CPU cycle-sharing (by order of relevance/popularity): Bag-of-tasks. Tasks with a deadline. Tree searches. Point-of-presence. Application Types: Bag-of-Tasks Consume large amount of CPU. Master-slave model. Embarrassingly parallel : no communication between the nodes. Examples: SETI@home, Stanford Folding, etc. 7

8 Application Types: tasks with a deadline Similar to the previous but more moderate. They must be concluded by a particular deadline. Often they refine results as more time becomes available. Ex: sweeping large parameter spaces, ray tracing, genetic algorithms Tree Search A tree of slave processes coordinated by a central master process. Low levels of communication between slave processes. The tree grows dynamically as the search space grows. Dynamic pruning as solutions that are wrong or too expensive are identified. Examples: distributed branch-and-bound, alpha-beta search, distributed backtracking. 8

9 Point-of-Presence Placement of application code on particular web nodes that satisfy specific requirements such as: location, topology or special resources. Minimum CPU consumption. Examples: Monitoring systems, traffic analysis systems, network protocol testing, distributed games. Organization: Classification of Cycle-Sharing Centralized: central server manages node population and application execution Distributed: Each node searches for others to share the work (CCOF). Platform: Web, generally Java Applet. Specific middleware. 9

10 Classification of Cycle-Sharing (2) Scale: Internet LAN (at a company, university, etc ) Participation: Voluntary Mandatory Characterization of Volunteers Celebrating Diversity in Volunteer Computing Anderson, Reid,

11 Characterization of Volunteers Available Disk (GB) Memory (MB) Connection time (h) Bandwidth (kb) Grid / Cycle-Sharing Comparison Public CS Private CS Grid Resources Anonymous PC Known PC Supercomp., cluster, storage, workstation, etc. Network Shared, low bandwidth, firewall, NAT, Dyn. DNS LAN without obstacles High bandwidth dedicated network Heterogeneity High Medium Medium Dedication High volatility, requires incentives Low volatility, no incentives required Dedicated, allows for reservation Trust Faults Low reliability, may be malicious, requires verification Unreliable Good reliability Unreliable High reliability Medium/High reliability Management independent Isolated but there may be interventions Professional management available Aplication Type Independent, CPU-bound Independent, CPU-bound (or I/O-bound) Suports many variants 11

12 Challenges Volatility: Churn (entry/exit rate) and performance variance. Dynamic environment: The system state never stabilizes (number of nodes, computing power, load, ). Trust: Results cannot be trusted. Faults: Interrupted or lost job executions. Heterogeneity: Varied/unknown machines make scheduling more difficult. Scalability: Centralized scheduling is a bottleneck. Distributed scheduling is inefficient. Participation: Users lose interest. Solutions Volatility Dynamic Environment Heterogeneity Scalability Faults Trust Participation Scheduling Result Checking Incentive Mechanisms 12

13 Cycle-Sharing Scheduling The normal situation is inverted: usually nodes are given jobs by the scheduler. Here nodes request jobs. Solution: Gather information in order to decide for the nodes when they contact the central server. On almost all cycle-sharing systems: no deadline, no preemption, no load-balancing. Most common algorithms: Random (Pull). Round-robin (Push). FIFO (Pull), FIFO with capability restrictions (Pull). Wave Scheduling(Pull, see CCOF). Result Checking Restricts scheduling, e.g. job replicas should be spread over nodes from different owners or with different technical features. Voting: job is repeated by several nodes. Cons: wastes work and is susceptible to collusion (several nodes providing the same wrong result on purpose). Spot-checking: randomly distribute results with known results. Failing nodes are blacklisted. Quiz: submit a set of tasks that include smaller tasks with known results. Better against collusion. Faster. Better integration of verification and real work. 13

14 Incentive Models How can we keep users interested? Complex aspect of cycle-sharing: There are very few symmetrical environments (where all nodes want to buy and sell) and it s difficult to convince users to pay in order to establish a currency. BOINC: Reputation based: after result validation, gives credits to users who finish jobs within the deadline. PlanetQuest names planets after the best users. However, BOINC is an asymmetrical system (only the server wants CPU) and non-competitive (there is no interaction between projects). Incentive Models: Possible Solution POPCORN (Cycle-Sharing on the web): Applications are applets. Centralized Java marketplace. Buyers offer popcoinsfor a given task. Salespeople sell to the best available buyer. Cheating the system requires modifying the browser. 14

15 Berkeley Open Infrastructure for Network Computing. Centralized system, middleware based, voluntary participation, global scale. Free software. Applications: Climateprediction.net, +30 Client Architecture servers Aplication Application Application Core client screensaver 15

16 Client Configuration User preferences: Work when idle. Work on limited periods during the day. Limit CPU share. Limit memory use. Network connection periods. Job scheduling interval. User control: Join/suspend/restart/abandon project. Suspend/restart/cancel job. Suspend/restart calculation. Client Architecture Core process: Communicates with the central scheduler, job and data download/upload, application starting/stopping. Manager GUI process: application selection and monitoring. Screensaver process: displays application performance graphics. 16

17 Application/Core Interaction Application has a thread that reports to the core. BOINC library has a graphics thread for the screensaver and another that communicates periodically with the core. Communication using shared memory: XML messages in fixed-size buffers with a bit indicating whether more messages will follow. Application/Core Interaction Management operations: Client core: Start suspend and abort jobs. Application is terminated if it does not report for 30s. Application reports the percentage of the jobs that has been done. Checkpointing: application announces availability with boinc_time_to_checkpoint. Result submission: application notifies core when (and if) there are partial results. 17

18 Server Architecture client Scheduler Jobs (DB) Job Cache (shared mem.) Feeder Jobs reqeusted as a function of the CPU time imbalance among projects at the client and the possibility of keeping the deadline. The Feeder fills the job cache in FIFO order (for each project) to speed up the job dispatch. Local Scheduling Policies Scheduling is local and configurable via XML. CPU scheduling: Which jobs should be run? Job acquisition: When to get more jobs? From which projects to get jobs? How many jobs? 18

19 Client Scheduling Criteria Node hardware: Number of cores, computing benchmarks. Memory. Node availability: % of time that BOINC is running jobs. % of time there is a BOINC/client connection. CCOF: Computing Cluster on the Fly Cycle-sharing in a P2P environment. Timezone based organization. Base on a distributed hash table. Application specific scheduling: Each application decides which nodes to send their jobs to. There is accounting of the work done reliably. Results are checked using a quiz. Nodes maintain control by running jobs within a sandbox. 19

20 Distributed Hash Tables Network overlays. Used for sharing storage and computation. An object s location is determined typically by a hash of its identifier. Example: Chord P2P overlay. Each node handles id between its predecessor and itself. Each node knows it successor. Lookup is aided by finger table containing jumps in the ring (1/2, ¼, etc.) Links are periodically fixed as nodes enter and exit. 20

21 CCOF Architecture COFF: Wave Scheduling Adapted for bag-of-tasks with deadline jobs. Goal: try to capture free CPU by following night time shifts around the globe. Uses DHTsto organize nodes according to time shifts. 21

22 COFF: Wave Scheduling Position in the DHT: n-dimensional value, one of the dimensions is the time shift. Nós contact other nodes in their time shift. Jobs are started in the night time shifts and migrated in the morning. CCOF Resource Location (i) Four strategies: Centralized: Does not scale. Expanding Ring: Ask the neighbours, then expand the ring. Random walk: Select k nearest neighbours Ad-based: When nodes enter the system, they broadcast their profile to the neighbours. Rendezvous Point: A set of profile repositories give information about node status. 22

23 Next time Map Reduce 23