Cloud Compu ng - Technische Universität Darmstadt

Technische Universität Darmstadt Telecoopera5on Lab Prof. Dr. Max Mühlhäuser TK1: Distributed Systems -­‐ Programming & Algorithms Chapter 2: Sec5on 4:
Lecturer: Distributed Programming Cloud Compu5ng Prof. Dr. Max Mühlhäuser, Dr. Aristotelis Hadjakos Copyrighted material – for TUD student use only Cloud CompuBng §  Cloud Compu5ng objec5ves § provide resources or services over the Internet to customers with the reliability of a data center § oLen virtualized infrastructure that can be scaled on demand regarding storage, computa5on and network capacity § Service providers/users do not need to have knowledge of maintaining the technology infrastructure in the "cloud" §  Cloud Compu5ng vs. tradi5onal Hos5ng § sold on demand (typically by minute or hour) §  “pay as you go” – no need for long-­‐standing contracts § elas5c: user can determine amount of service (CPU, Storage, ...) he wants at any given 5me § service is fully managed TK1-­‐2.4 Cloud Compu5ng: 2 In-­‐House vs. External HosBng Cow Supermarket: BoKle of Milk Big upfront investment Small con5nuos expense Produces more than you need Buy what you need Uses up resources Less resources needed Maintenance needed No maintenance Unpleasant waste product Waste is not my problem Source: Donald Kossmann & Kraska 2009: What is new in the Cloud?
TK1-­‐2.4 Cloud Compu5ng: 3 Cloud CompuBng: Roles Service Hoster
Service Users
(End Users)
Services, Data, VM-Images
Service Provider (Developer)
TK1-­‐2.4 Cloud Compu5ng: 4 Public vs. Private Clouds §  Public Cloud: sells service to anyone on the Internet §  Observa5on (by IBM): 70% of IT budget is spent on average for maintenance versus adding new capabili5es §  Goal: Replace fixed IT-­‐costs with variable costs §  Gartner says: “Organiza5ons are switching from company-­‐owned hardware and soLware assets to per-­‐use service-­‐based models” §  Low entry barrier §  For applica5ons you have to do once §  For applica5ons you do not have the resources for §  e.g., Amazon EC2 §  Private Cloud: used inside a business §  Observa5on: Most systems are oversized and run at 10-­‐20% u5liza5on most of the 5me §  Goal: more efficient u5liza5on of resources in a business §  e.g., IBM Blue Cloud TK1-­‐2.4 Cloud Compu5ng: 5 Cloud CompuBng §  Key characteris5cs § „Unbounded scale“ §  Rapid up-­‐ and downscaling possible §  No more oversized systems that run at 10-­‐20% u5liza5on most of the 5me §  S5ll, the peak load capacity can be provided §  Assump5on: The data center hosts many different applica5ons and not all of them need peak resources at the same 5me § Reliability §  Redundant computers and data centers § More loca5on independence §  Hoster may operate data centers worldwide § OLen based on cheap hardware § Compared to clusters and Grid slow interconnec5on network § Subscrip5on-­‐based or Pay-­‐per-­‐use TK1-­‐2.4 Cloud Compu5ng: 6 Types of Cloud Service Software as a Service (SaaS)
Platform as a Service (PaaS)
Infrastructure as a Service (IaaS)
TK1-­‐2.4 Cloud Compu5ng: 7 Infrastructure as a Service (IaaS) § Computer Infrastructure delivery model § A plakorm virtualiza5on environment -­‐ „virt. taken a step further“ § Compu5ng resources, such as processing capacity and storage § This pay-­‐for-­‐what-­‐you-­‐use model resembles the way electricity, fuel and water are consumed -­‐> also referred to as uBlity compuBng. § Example § You want to run a batch job but you don’t have the infrastructure necessary to run it in a 5mely manner -­‐> use Amazon EC2 § Providers § Amazon EC2, S3 §  virtual server instances with unique IP addresses §  blocks of storage on demand §  API to start, stop, access, configure virtual servers and storage § Rackspace: cloudServers § FlexiScale TK1-­‐2.4 Cloud Compu5ng: 8 PlaPorm as a Service (PaaS) § Plakorm delivery model § Plakorms are built upon Infrastructure § Hoster is responsible for maintenance of OS & base frameworks § Problem: currently, there are not standards for interoperability or data portability. § Examples § You want to start storage services on your network for a large number of files and you do not have the storage capacity -­‐> use Amazon S3 § You want to host a website and expect many hits, but only for a few days -­‐> Rackspace cloudSites § Providers: Google App Engine, Force.com, Rackspace, ... § Rackspace: cloudSites, cloudFiles §  cloudSites: scalable website w/o need to manage dedicated server TK1-­‐2.4 Cloud Compu5ng: 9 SoQware as a Service (SaaS) § SoLware delivery model § No hardware or soLware to manage § Service delivered through a browser (in most cases) § Provider hosts both applica5on and data § End user is free to use the service from anywhere § Customers use the service on demand § Instant Scalability § Examples § Your email is hosted on an Exchange server in your office and it is very slow. -­‐> outsource this using Hosted Exchange § Your current CRM package is not managing the load or you simply don’t want to host it in-­‐house. -­‐> use a SaaS provider such as Salesforce.com § SaaS is a very broad market: many domain-­‐specific applica5ons TK1-­‐2.4 Cloud Compu5ng: 10 Cloud CompuBng PaaS
Service Provider
(Developer)
SaaS
Service Users
(End Users)
§ PaaS for Developer • A set of soLware & product development tools hosted on the provider's infrastructure • Developers create applica5ons on the provider’s plakorm over the Internet § SaaS for End User TK1-­‐2.4 Cloud Compu5ng: 11 Cloud CompuBng: History Grid CompuBng §  Solving large problems with parallel compu5ng §  Made mainstream by Globus Alliance UBlity CompuBng • 
•  Network-­‐based Offering compu5ng subscrip5ons to resources as a applica5ons metered service • 
SoQware as a Service Introduced in late 1990s •  Gained momentum in 2001 Cloud CompuBng •  Next-­‐genera5on Internet compu5ng •  Next-­‐genera5on Data Centers TK1-­‐2.4 Cloud Compu5ng: 12 Grid CompuBng § Grid Defini5on: (Ian Foster) § Coordinated resource sharing and problem solving in dynamic, mulB-­‐
insBtuBonal virtual organizaBons § Hence, grid is coordinated, aimed at solving problems § Mo5va5on to join a grid: more resources available § Resources typically provided by everyone and usable by all § Focus on large scale resource sharing, innova5ve applica5ons, and high performance § This focus dis5nguishes grid from tradi5onal distributed compu5ng § Main challenges: authen5ca5on, authoriza5on, resource access, and resource discovery TK1-­‐2.4 Cloud Compu5ng: 13 The word „Grid“ § Word “grid” has several meanings in English § Map grid, star5ng grid, … § How do these defini5ons relate to grid compu5ng? § Are the computers arranged in a grid? ;-­‐) § Best analogy is power grid § Distribu5on of electricity § In power grid, there are producers and consumers § Grid connects them and lets any consumer use any producer seamlessly § Some5mes grid compu5ng defined in a similar way to power grid § Any5me, anywhere, just plug in and you are connected TK1-­‐2.4 Cloud Compu5ng: 14 Grid vs. Cloud CompuBng: CommonaliBes § Share a lot commonality: inten5on, architecture and technology; problems are mostly the same: § manage large, central facili5es § define methods by which consumers discover, request & use resources § provide means for efficient parallel execu5on of soLware TK1-­‐2.4 Cloud Compu5ng: 15 Grid vs. Cloud CompuBng: Differences § Business Model / accessibility §  Grids are only accessible within pre-­‐defined mul5-­‐organiza5ons §  Par5cipants share resources, i.e., most par5cipants also offer resources §  Each individual organiza5on maintains full control of their resources §  User/Hoster-­‐Roles in Cloud Compu5ng §  Cloud compu5ng hoster offers its service to anyone on the Internet § Compu5ng Model / applicaBon types §  Grids are mostly limited to batch processing §  Clouds support interacBve applicaBons (and also batch) §  Good support for “web-­‐faced” applica5ons met demand of many e-­‐commerce applica5ons -­‐> great market success § Programming Model / job/applicaBon submission §  Grid: builds mostly on source code distribuBon §  Send archive with source code to server in Grid §  Job will be compiled and executed there §  Cloud: builds on virtualizaBon TK1-­‐2.4 Cloud Compu5ng: 16 Grid vs. Cloud CompuBng § Interoperability § Grid §  Wide adop5on of the OGF (Open Grid Forum) architecture/protocol standards §  Wide adop5on of the Globus toolkit § Cloud §  Currently no interoperability §  Big players do not seem to be interested much in standards §  Amazon, MicrosoL, Salesforce, Google §  Open Cloud Consor5um §  Members: Aerospace, Cisco, Infoblox, Nasa, Yahoo, ... §  ... but the big players are not here §  -­‐> Vendor lock-­‐in! § ElasBcity § Cloud: You pay for the resources you use (pay-­‐per-­‐use) § Grid: Accoun5ng across organiza5ons never worked TK1-­‐2.4 Cloud Compu5ng: 17 Grid vs. Cloud CompuBng §  Amdahl‘s Law: s … speedup P … number of parallel processes o(P) … communica5on overhead a … sequen5al frac5on of program §  Max. expected speedup of overall system, if only a frac5on is improved §  Expresses rela5onship btw. sequen5al algorithm and parallelized version §  The sequenBal fracBon of a program (in terms of run 5me) determines the upper bound for speedup! -­‐ s5ll true, but only if we look at solving one problem §  Grids §  Parallel computers with fast interconnec5on networks -­‐> low o(P) §  Solve oLen only 1 problem §  Clouds §  Inexpensive hardware, „slow“ interconnects -­‐> high o(P) §  Either a is really small (cf. MapReduce) §  or mostly: solve n problems in parallel TK1-­‐2.4 Cloud Compu5ng: 18 The „Cloud Stack“ Application
AppEngine
(Google)
Web
Azure Web Role
(MS)
Azure Worker
Role (MS)
Services
Platform
Sherpa
(Yahoo)
Storage
Batch
Processing
Hadoop
(Apache)
BigTable
(Google)
PIG
(Yahoo)
Azure Tables
(MS)
MapReduce
(Google)
DryadLinq
(MS)
OS
Infrastructure
Virtualization
Block Storage
EC2
(Amazon)
S3
(Amazon)
GFS
(Google)
TK1-­‐2.4 Cloud Compu5ng: 19 Amazon S3 §  Amazon Simple Store Service (S3) §  Based on REST-­‐style API, also browser-­‐based management tools available §  Organized in buckets §  bucket = “drive” in which directories and files can be stored §  ACLs allow to make parts of the bucket publicly accessible §  Other services build on S3, such as EC2 §  Example: Crea5ng a Bucket PUT /onjava HTTP/1.1
Content-Length: 0
User-Agent: jClientUpload
Host: s3.amazonaws.com
Date: Sun, 05 Aug 2007 15:33:59 GMT
Authorization: AWS 15B4D3461F177624206A:YFhSWKDg3qDnGbV7JCnkfdz/IHY=
§ Authoriza5on: AWS <AWSAccessKeyID>:<Signature> §  AWSAccessKeyID: customer ID §  Signature: SHA1 hash of message, encrypted with customer’s private key TK1-­‐2.4 Cloud Compu5ng: 20 The „Cloud Stack“ Application
AppEngine
(Google)
Web
Azure Web Role
(MS)
Azure Worker
Role (MS)
Services
Platform
Sherpa
(Yahoo)
Storage
Batch
Processing
Hadoop
(Apache)
BigTable
(Google)
PIG
(Yahoo)
Azure Tables
(MS)
MapReduce
(Google)
DryadLinq
(MS)
OS
Infrastructure
Virtualization
Block Storage
EC2
(Amazon)
S3
(Amazon)
GFS
(Google)
TK1-­‐2.4 Cloud Compu5ng: 21 Google Filesystem (GFS) § Shares many same goals as previous distributed file systems: performance, scalability, reliability, and availability § GFS design has been driven by four key observa5ons @ Google: § Component failures are the norm rather than the excep5on §  quan5ty and quality of components virtually guarantees failures §  constant monitoring, error detec5on, fault tolerance, and automa5c recovery are integral to the system § Huge files (by tradi5onal standards) §  Mul5 GB files are common §  I/O opera5ons and blocks sizes must be revisited § Most files are mutated by appending new data §  focus of performance op5miza5on and atomicity guarantees § Co-­‐designing the applica5ons and APIs benefits overall system by increasing flexibility TK1-­‐2.4 Cloud Compu5ng: 22 GFS: Architecture § GFS cluster consists of § a single master § mul5ple chunkservers and § is accessed by mul5ple clients § Files organized hierarchically in directories & iden5fied by pathnames TK1-­‐2.4 Cloud Compu5ng: 23 GFS: Architecture § GFS Chunkservers §  Files are divided into fixed-­‐size chunks §  Each chunk has a immutable globally unique 64-­‐bit chunk-­‐handle §  handle is assigned by the master at chunk crea5on §  Chunk size is 64 MB §  Chunks are stored as files in local Linux file system §  Each chunk is replicated on 3 (default) servers § GFS Master §  Maintains all file system metadata: names space, access control info, file to chunk mappings, chunk (including replicas) loca5on, etc. §  Client contacts Master to get chunk loca5ons, then deals directly with chunkservers §  Master is not a bo~leneck for reads/writes §  Single master §  simplifies design §  helps make sophis5cated chunk placement and replica5on decision, using global knowledge TK1-­‐2.4 Cloud Compu5ng: 24 GFS: Architecture § GFS Clients §  GFS does not implement a standard API such as POSIX §  Linked as library into apps §  Communicates with master and chunkservers for reading and wri5ng §  Master interac5ons only for metadata §  Chunkserver interac5ons for data § Opera5ons §  Standard: create, delete, open, close, read, and write files §  Snapshot §  creates a copy of a file or a directory tree at low cost §  Record Append §  allows mul5ple clients to append data to the same file concurrently §  guaranteeing the atomicity of each individual client’s append §  useful for implemen5ng mul5-­‐way merge results §  useful for producer-­‐consumer queues that many clients can simultaneously append to without addi5onal locking TK1-­‐2.4 Cloud Compu5ng: 25 GFS: Read 1. Client sends Master a request containing file name and chunk index (= byte offset / 64MB) 2. Master replies chunk handle and locaBons of replicas 3. Client sends request to one replica (closest one) 4. Client reads data from chunkserver 1
2
3
4
TK1-­‐2.4 Cloud Compu5ng: 26 GFS: Write 1. Client asks the master for Lease Holder of chunk to write to 2. Iden5ty of the primary and loca5ons of other (secondary) replicas 3. Client pushes data to all replicas (on chunkservers) 4. Once all the replicas have acknowledged receiving the data, client sends a write request to the primary • request iden5fies all other replicas • primary assigns consecu5ve serial numbers -­‐> serializa5on of writes • data in local write buffer is ordered according to serial number order 5. Primary forwards write request to all secondary replicas • data is ordered according to serial number order 6. Secondaries all reply to primary indica5ng comple5on 7. Primary replies to Client TK1-­‐2.4 Cloud Compu5ng: 27 GFS: Atomic Record Append § Problem § In a tradi5onal write, the client specifies the offset at which data is to be wri~en § Concurrent writes to the same region are not serializable: the region may end up containing data fragments from mul5ple clients § Atomic Record Append § Client specifies only the data to write § GFS chooses and returns the offset it writes to § No need for a distributed lock manager §  GFS chooses the offset, not the client § Follows similar control flow as Write §  Primary tells secondary replicas to append at the same offset §  Data must be wri~en at the same offset for all chunk replicas for success to be reported TK1-­‐2.4 Cloud Compu5ng: 28 GFS Fault Tolerance: Chunkservers § Purpose §  maintain a consistent muta5on order across replicas by iden5fying the primary copy (muta5on = opera5on that changes contents or metadata of a chunk) §  dealloca5on of resources in case of a failure § Chunkserver: Failure Recovery §  Write, 1st step: Client asks Master for Lease Holder §  If no primary assigned for specified chunk -­‐> Master issues new Lease §  Lease has an ini5al 5meout of 60 seconds §  As long as muta5on goes on, primary periodically requests extensions from Master §  Now, if the master loses communica5on with a primary: §  Master can safely grant a new lease to another replica aLer the old lease has expired §  Now, if the faulty chunk server comes back: §  Master maintains version number for each chunk §  Allows detec5on of Stale Replicas TK1-­‐2.4 Cloud Compu5ng: 29 GFS Fault Tolerance: Master § Opera5on Log § Record of all cri5cal metadata changes § Stored on Master and replicated on other machines § Defines order of concurrent opera5ons § Changes not visible to clients un5l metadata changes are persistent § Master checkpoints its state whenever the log grows beyond a certain size §  Checkpoint is a compact B-­‐tree (used for namespace lookup) § Master Recovery § Read latest complete checkpoint § Replay opera5on log § Master Replica5on § “shadow” masters provide read-­‐only access even when primary master is down TK1-­‐2.4 Cloud Compu5ng: 30 The „Cloud Stack“ Application
AppEngine
(Google)
Web
Azure Web Role
(MS)
Azure Worker
Role (MS)
Services
Platform
Sherpa
(Yahoo)
Storage
Batch
Processing
Hadoop
(Apache)
BigTable
(Google)
PIG
(Yahoo)
Azure Tables
(MS)
MapReduce
(Google)
DryadLinq
(MS)
OS
Infrastructure
Virtualization
EC2
(Amazon)
Block Storage
S3
(Amazon)
GFS
(Google)
TK1-­‐2.4 Cloud Compu5ng: 31 Amazon EC2 §  Amazon Elas5c Cloud Compu5ng §  EC2 is not much more than “VM hos5ng” §  Amazon Machine Image (AMI) = encrypted VM image §  Images are stored in an S3 repository §  Pre-­‐configured templates provided §  OSes: Windows Server 2003, …-­‐Linux, OpenSolaris §  Databases: Oracle 11g, MSSQL, MySQL §  Communica5on/Processing: Hadoop, Condor, Open MPI §  Web hos5ng: Apache, IIS §  Instances can be controlled using a Web Service interface §  The local storage of instances is non-­‐persistent §  Instances are accessed via RDP or SSH §  Availability Zones §  Describes the loca5on of a datacenter as geographic region (e.g., us-­‐east-­‐1a) §  Placement of instances can be controlled §  Distribu5on of instances can be used for fault tolerance TK1-­‐2.4 Cloud Compu5ng: 32 Amazon EC2: Block Store §  Amazon Elas5c Block Store § Raw block device that can be mounted (“a~ached”) by an instance §  can only be mounted by a single instance at any 5me! § Allows persistence beyond the life5me of an instance § Snapshots can be stored to/restored from S3 § API func5ons §  CreateVolume / DeleteVolume §  DescribeVolume: get informa5on about a volume (size, source snapshot, crea5on 5me, status) §  A~achVolume / DetachVolume §  CreateSnapshot / DeleteShapshot §  DescribeSnapshots: get informa5on about snapshots § API accessed using XML/SOAP or REST TK1-­‐2.4 Cloud Compu5ng: 33 Amazon EC2: API §  Running § RegisterImage / DeregisterImage § RunInstances: launch the specified number of instances § TerminateInstances § RebootInstances §  Networking § AllocateAddress: acquire an elas5c IP address § AssociateAddress: associate elas5c IP address with instance §  Storage § CreateVolume / DeleteVolume § A~achVolume: mount an EBS volume § CreateSnapshot / DeleteSnapshot TK1-­‐2.4 Cloud Compu5ng: 34 Amazon EC2: Services §  Amazon Simple Store Service (S3) §  Amazon Simple DB § Cluster database for storing persistent data § Does not provide full rela5onal / SQL support §  Amazon Simple Queue Service § Message oriented middleware for inter-­‐service communica5on TK1-­‐2.4 Cloud Compu5ng: 35 The „Cloud Stack“ Application
AppEngine
(Google)
Web
Azure Web Role
(MS)
Azure Worker
Role (MS)
Services
Platform
Sherpa
(Yahoo)
Storage
Batch
Processing
Hadoop
(Apache)
BigTable
(Google)
PIG
(Yahoo)
Azure Tables
(MS)
MapReduce
(Google)
DryadLinq
(MS)
OS
Infrastructure
Virtualization
Block Storage
EC2
(Amazon)
S3
(Amazon)
GFS
(Google)
TK1-­‐2.4 Cloud Compu5ng: 36 MapReduce § Consider the problem of coun5ng the number of occurrences of each word in a large collec5on of documents § MapReduce Programming Model §  Inspired from map and reduce opera5ons commonly used in func5onal programming languages like Lisp 1. map: (key1, val1) -­‐> [(key2, val2)] 2. reduce: (key2, [val2]) -­‐> [val3] § Map §  is a pure func5on (always evals to same result & no side effects) §  processes input key/value-­‐pair §  produces set of intermediate key/value pairs §  e.g.: (document_name, document_content) -­‐> [(word1, 1),...,(wordn, 1)] § Reduce §  Combines all intermediate values for a par5cular key §  Produces a set of merged output values (usually just one) §  e.g.: (word, [1,...,1]) -­‐> [n] TK1-­‐2.4 Cloud Compu5ng: 37 MapReduce §  Example: count word occurrences map(String input_key, String input_value):
// input_key: document name
// input_value: document contents
for each word w in input_value:
EmitIntermediate(w, "1");
reduce(String output_key, Iterator intermediate_values):
// output_key: a word
// output_values: a list of counts
int result = 0;
for each v in intermediate_values:
result += ParseInt(v);
Emit(AsString(result));
TK1-­‐2.4 Cloud Compu5ng: 38 MapReduce: ExecuBon TK1-­‐2.4 Cloud Compu5ng: 39 MapReduce: Distributed ExecuBon Input Reader
Map
Partition
Compare
Reduce
Output Writer
TK1-­‐2.4 Cloud Compu5ng: 40 MapReduce: Data Flow § The sta5c part of MapReduce is a large distributed sort; applica5ons define: 1. Input Reader • Reads data from (distributed) filesystem and generates key/value pairs • e.g., read directory full of text files & return each line as record 2. Map Func5on 3. Par55on Func5on • Assigns the output of all map opera5ons to a reducer: reducerIndex = par55onFunc5on(key, numberOfReducers) • Note: all iden5cal keys must be processed by same reducer • e.g., reducerIndex = hash(key) % numberOfReducers 4. Compare Func5on • Defines which keys should be considered iden5cal • Groups input for reduce step 5. Reduce Func5on 6. Output Writer • Writes output to (distributed) filesystem TK1-­‐2.4 Cloud Compu5ng: 41 The „Cloud Stack“ Application
AppEngine
(Google)
Web
Azure Web Role
(MS)
Azure Worker
Role (MS)
Services
Platform
Sherpa
(Yahoo)
Storage
Batch
Processing
Hadoop
(Apache)
BigTable
(Google)
PIG
(Yahoo)
Azure Tables
(MS)
MapReduce
(Google)
DryadLinq
(MS)
OS
Infrastructure
Virtualization
Block Storage
EC2
(Amazon)
S3
(Amazon)
GFS
(Google)
TK1-­‐2.4 Cloud Compu5ng: 42 BigTable (Google) § BigTable is a distributed storage system for managing structured data § Lots of (semi-­‐)structured data at Google §  URLs: §  Contents, crawl metadata, links, anchors, pagerank, ... §  Per-­‐user data: §  User preference se†ngs, recent queries/search results, ... §  Geographic loca5ons: §  Physical en55es (shops, restaurants, etc.), roads, satellite image data, user annota5ons, ... § Designed to scale to a very large size §  Petabytes of data across thousands of servers §  Billions of URLs, many versions/page (~20K/version) §  Hundreds of millions of users, thousands or q/sec §  Many TB of satellite image data §  Scale is too large for most SQL databases §  Even if it weren’t, licensing costs would be very high §  Low-­‐level storage op5miza5ons help performance significantly §  Much harder to do when running on top of a database layer TK1-­‐2.4 Cloud Compu5ng: 43 BigTable: Goals § Want asynchronous processes to be con5nuously upda5ng different pieces of data § Want access to most current data at any 5me § Need to support § Very high read/write rates (millions of ops per second) § Efficient scans over all or interes5ng subsets of data § Efficient joins of large one-­‐to-­‐one and one-­‐to-­‐many datasets § OLen want to examine data changes over 5me § E.g. Contents of a web page over mul5ple crawls § Fault-­‐tolerant, persistent § Self-­‐managing § Servers can be added/removed dynamically § Servers adjust to load imbalance TK1-­‐2.4 Cloud Compu5ng: 44 BigTable: ApplicaBons § Used in many Google projects (data from 2006) TK1-­‐2.4 Cloud Compu5ng: 45 DBMS vs. Key/Value Store Database Structure
Relational Database
§  Tables w/ columns and rows, rows contain column values, rows in table all have same schema §  Data model is well-­‐defined in advance, schema is typed & has constraints & rela5onships to enforce integrity §  Data model based on „natural“ representa5on of data, independent of app data structures §  Data model is normalized to remove duplica5on. Rela5onships associate between mul5ple tables §  No good support for large amounts of binary data Key/Value Database
§  Table is a bucket were key/value pairs are put into. Different rows can have different „schemas“ §  Records are iden5fied by keys. A dynamic set of a~ributes can be associated with a key §  Some5mes a~ributes are all of a string type only §  No rela5onships are explicitly defined. No normaliza5on models §  Handles binary data well TK1-­‐2.4 Cloud Compu5ng: 46 DBMS vs. Key/Value Store Data Access
Relational Database
§  Data is created, updated, and retrieved using SQL §  SQL queries can act on single tables, but also act on mul5ple tables through table joins §  SQL provides func5ons for aggrega5on & complex filtering §  „Ac5ve Database“ with triggers, stored procedures, func5ons Key/Value Database
§  Data manipulated through proprietary APIs §  Some5mes SQL-­‐like syntax without join or update func5onality (e.g., GQL) §  Only basic filter predicates (=, !=, <, >). OLen: Processing not considered to be part of DB -­‐> MapReduce, Hadoop §  App & data integrity logic all contained in app code TK1-­‐2.4 Cloud Compu5ng: 47 DBMS vs. Key/Value Store Application Interface
Relational Database
§  De-­‐facto standards for SQL database drivers (e.g., ODBC, JDBC) §  Data is stored in „natural“ representa5on. OLen mapping between app data structures and rela5onal structure used: Object-­‐
Rela5onal Mapping (ORM) Key/Value Database
§  Proprietary APIs, some5mes SOAP/
REST §  Direct serializa5on of app objects into the value part of records TK1-­‐2.4 Cloud Compu5ng: 48 DBMS vs. Key/Value Store § Applica5ons for Key/Value Stores § data is heavily document-­‐oriented -­‐> more natural fit with the key/value model than the rela5onal model § large amounts of binary data § applica5on builds heavily on object-­‐orienta5on -­‐> key/value database minimizes the need for „plumbing“ code § data store is cheap & integrates easily with cloud plakorm § on-­‐demand, vast scalability is of vital importance §  Thousands of servers §  Terabytes of in-­‐memory data §  Petabyte of disk-­‐based data §  Millions of reads/writes per second, efficient scans TK1-­‐2.4 Cloud Compu5ng: 49 The „Cloud Stack“ Application
AppEngine
(Google)
Web
Azure Web Role
(MS)
Azure Worker
Role (MS)
Services
Platform
Sherpa
(Yahoo)
Storage
Batch
Processing
Hadoop
(Apache)
BigTable
(Google)
PIG
(Yahoo)
Azure Tables
(MS)
MapReduce
(Google)
DryadLinq
(MS)
OS
Infrastructure
Virtualization
Block Storage
EC2
(Amazon)
S3
(Amazon)
GFS
(Google)
TK1-­‐2.4 Cloud Compu5ng: 50 Google App Engine §  Allows to run own web applica5ons on Google’s infrastructure §  Python supported as programming language, now also Java (+ Spring) §  Sandbox with several limita5ons §  App code can only run as result of HTTP(S) request and may not spawn sub-­‐
processes §  Cannot write to file system §  App can only fetch URLs or use email services for communica5on §  The Datastore §  Distributed storage service with query engine and transac5ons §  Stores data objects of mixed types, each object consists of typed key/value pairs §  Query with GQL, a limited SQL variant §  Google accounts §  App can access informa5on from Google accounts TK1-­‐2.4 Cloud Compu5ng: 51 Windows Azure §  Architecture of Web Applica5ons § Applica5on has mul5ple instances, each running all or a part of the code § Each instance runs in its own VM (64-­‐bit Windows Server 2008) § Developers may provide .NET applica5ons § One-­‐to-­‐one mapping between VMs and CPU cores -­‐> guaranteed performance TK1-­‐2.4 Cloud Compu5ng: 52 Windows Azure Instances §  Web Role Instance § Can be accessed from the Web § Must be stateless! § Load balancer does not guarantee that requests from the same user will be dispatched to the same instance § Windows Azure storage must be used to maintain state §  Worker Role Instance § For “background” processes § Use queues in Azure storage for communica5on § Rela5on to three-­‐5er architectures § Presenta5on Tier -­‐> Web Role Instance § Applica5on Tier -­‐> Worker Role Instance § Data Tier -­‐> Windows Azure Storage or MS SQL Server TK1-­‐2.4 Cloud Compu5ng: 53 Windows Azure Storage §  Windows Azure Storage § Blobs §  For big, unstructured data (images, audio, video, …) §  One or more containers, each holding blobs § Tables §  No defined schema, proper5es can have various types §  Tables can be large and par55oned across many servers § Queues §  Used for communica5on between instances §  Accessed using REST, also from outside §  All data is replicated three 5mes TK1-­‐2.4 Cloud Compu5ng: 54 Summary § 
§ 
§ 
§ 
Cloud Compu5ng objec5ves Types of Cloud Service: SaaS, PaaS, IaaS Cloud vs. Grid Compu5ng, Scalability Architecture of a Cloud Plakorm, “The Cloud Stack” § 
§ 
§ 
§ 
§ 
Block Storage: Amazon S3, Google File System Virtualiza5on: Amazon EC2 Batch Processing: MapReduce, Hadoop Structured Distributed Storage: BigTable Google App Engine, MicrosoL Azure TK1-­‐2.4 Cloud Compu5ng: 55 Literature §  Sanjay Ghemawat, Howard Gobioff, Shun-­‐Tak Leung. "The Google File System". in Symposium on Opera2ng Systems Principles (SOSP), 2003. §  Jeffrey Dean, Sanjay Ghemawat. "MapReduce: Simplified Data Processing on Large Clusters". in Opera2ng Systems Design and Implementa2on (OSDI), 2004. §  Fay Chang, Jeffrey Dean, Sanjay Ghemawat, Wilson C. Hsieh, Deborah A. Wallach, Mike Burrows, Tushar Chandra, Andrew Fikes, Robert E. Gruber. "Bigtable: A Distributed Storage System for Structured Data". in Opera2ng Systems Design and Implementa2on (OSDI), 2006. §  Tony Bain. Is the Rela5onal Database Doomed?. Retrieved Feb 03, 2010, from h~p://
www.readwriteweb.com/enterprise/2009/02/is-­‐the-­‐rela5onal-­‐database-­‐doomed.php, 2009. §  Donald Kossmann, Tim Kraska, and Simon Loesing: An Evalua5on of Alterna5ve Architectures for Transac5on Processing in the Cloud, in: ACM SIGMOD’10, 2010. §  David Chappell: Introducing the Windows Azure Plakorm, retrieved Dec 07, 2010, from h~p://www.microsoL.com/windowsazure/ §  Simon Munro: The Trouble With Sharding, retrieved Dec 07, 2010, from h~p://simonmunro.com/2009/09/10/the-­‐trouble-­‐with-­‐sharding/ §  Keith Brown, Sesha Mani: MicrosoL Windows Iden5ty Founda5on (WIF) Whitepaper for Developers, 2009. TK1-­‐2.4 Cloud Compu5ng: 56