Topic 3: Large-scale Distributed Systems

3: Large-scale Distributed Systems

Zubair Nabi

[email protected]

April 17, 2013

Zubair Nabi 3: Large-scale Distributed Systems April 17, 2013 1 / 29

Outline

1 Introduction

2 Client-server Interaction

3 Characteristics

4 Message Passing Interface


Outline

1 Introduction


3 Characteristics



Distributed Systems

Set of discrete machines which cooperate to perform computation

Give the notion of a single “machine”Examples:

I Compute clustersI Distributed storage systems, such as Dropbox, Google Drive, etc.I The Web


Distributed Systems


Give the notion of a single “machine”

Examples:I Compute clustersI Distributed storage systems, such as Dropbox, Google Drive, etc.I The Web


Distributed Systems



I Compute clusters

I Distributed storage systems, such as Dropbox, Google Drive, etc.I The Web


Distributed Systems



I Compute clustersI Distributed storage systems, such as Dropbox, Google Drive, etc.

I The Web


Distributed Systems



I Compute clustersI Distributed storage systems, such as Dropbox, Google Drive, etc.I The Web


Advantages

Scalability:I The scale of the Internet (think how many queries Google servers

handle daily)

I Only a matter of adding more machinesI Cheaper than super computersI More machines means more parallelism, hence better performance

Sharing:I The same resource is shared between multiple usersI Just like the Internet is shared between millions of users

Communication:I Communication between (potentially geographically isolated) machines

and users (via email, Facebook, etc.)

Reliability:I The service can remain active even if multiple machines go down


Advantages


handle daily)I Only a matter of adding more machines

I Cheaper than super computersI More machines means more parallelism, hence better performance






Advantages


handle daily)I Only a matter of adding more machinesI Cheaper than super computers

I More machines means more parallelism, hence better performance






Advantages


handle daily)I Only a matter of adding more machinesI Cheaper than super computersI More machines means more parallelism, hence better performance






Advantages



Sharing:I The same resource is shared between multiple users

I Just like the Internet is shared between millions of users





Advantages








Challenges

Concurrency:I Concurrent execution requires some form of coordination

Fault-tolerance:I Any component can fail at any instant due to a software or a hardware

bug

Security:I One machine can compromise the entire system

Coordination:I No global time so non-trivial to coordinate

Trouble shooting:I Hard to trouble shoot because hard to reason about the system


Transparency

Distributed systems give the notion of a single machine or keep thedistribution transparent

The degree of this transparency can be mapped onto an entirespectrum of options for both users and programmersFor instance:

I A web user is aware of network communication but the number ofaccessed machines is transparent

Transparency can be ensured by middleware that adds a layer ofabstraction

Can span access, concurrency, failure, location, migration,persistence, relocation, replication


Transparency


The degree of this transparency can be mapped onto an entirespectrum of options for both users and programmers

For instance:I A web user is aware of network communication but the number of

accessed machines is transparent




Transparency


The degree of this transparency can be mapped onto an entirespectrum of options for both users and programmersFor instance:

I A web user is aware of network communication but the number ofaccessed machines is transparent




Outline

1 Introduction


3 Characteristics



Request-reply protocol

Standard operation1 Client sends request to the server

2 Server processes the request and sends a corresponding response

In the synchronous model, the client blocks till the response is received

In case of the asynchronous model, the client continues its executionFor instance: HTTP 1.0

1 Client sends GET /index.html2 Server responds with index.html3 Client renders index.html



Standard operation1 Client sends request to the server2 Server processes the request and sends a corresponding response








In case of the asynchronous model, the client continues its execution

For instance: HTTP 1.01 Client sends GET /index.html2 Server responds with index.html3 Client renders index.html






1 Client sends GET /index.html

2 Server responds with index.html3 Client renders index.html






1 Client sends GET /index.html2 Server responds with index.html

3 Client renders index.html


Errors and failures

Errors are handled at the application-level

I For instance, if the client requests a non-existent web page just return aspecial reply: 404 Not Found

Failures are system-level thingsI For instance, lost message, client/server crash, etc.

To handle failure, the client must timeout after TI The client can retry on a timeoutI Setting value of T is system-specific


Errors and failures

Errors are handled at the application-levelI For instance, if the client requests a non-existent web page just return a

special reply: 404 Not Found




Errors and failures



Failures are system-level things

I For instance, lost message, client/server crash, etc.



Errors and failures






Errors and failures




To handle failure, the client must timeout after T

I The client can retry on a timeoutI Setting value of T is system-specific


Errors and failures




To handle failure, the client must timeout after TI The client can retry on a timeout

I Setting value of T is system-specific


Errors and failures






Remote Procedure Call

Request/response protocols are widely used but too low level

I Need to define each request separately including their network messagerepresentation

Remote procedure call (RPC) presents a simpler abstractionI Programmer invokes a procedure which executes on a remote machine

(the server)I RPC subsystem takes care of message formats, communication,

timeouts, etc.

Distribution of the system becomes transparent

Integrated with the programming language

RPC layer adds stubs at client end which when invoked execute amethod at the server



Request/response protocols are widely used but too low levelI Need to define each request separately including their network message

representation



timeouts, etc.







representation

Remote procedure call (RPC) presents a simpler abstraction

I Programmer invokes a procedure which executes on a remote machine(the server)

I RPC subsystem takes care of message formats, communication,timeouts, etc.







representation


(the server)

I RPC subsystem takes care of message formats, communication,timeouts, etc.







representation



timeouts, etc.





Example: XML-RPC

XML is used to encode method invocations (method names,parameters, etc.)

HTTP POST used to send request and receive response (alsoencoded in XML)

Looks like a regular web session on wire so plays well withmiddleboxes

Language agnostic and extensible

Extended with more features (namespaces, user-defined types, etc.)and diverse transports (TCP, UDP, etc.) to result in Simple ObjectAccess Protocol (SOAP)


RPC shortcomings

RPC mechanisms are synchronous

I Client blocks till response is receivedI Poor responsiveness, especially in high latency networks

2006 ushered in the age of Asynchronous JavaScript with XML (AJAX)I Update web page without reloadingI For instance, Google Maps, Gmail, etc.


RPC shortcomings

RPC mechanisms are synchronousI Client blocks till response is received

I Poor responsiveness, especially in high latency networks



RPC shortcomings

RPC mechanisms are synchronousI Client blocks till response is receivedI Poor responsiveness, especially in high latency networks



RPC shortcomings


2006 ushered in the age of Asynchronous JavaScript with XML (AJAX)

I Update web page without reloadingI For instance, Google Maps, Gmail, etc.


RPC shortcomings


2006 ushered in the age of Asynchronous JavaScript with XML (AJAX)I Update web page without reloading

I For instance, Google Maps, Gmail, etc.


RPC shortcomings




Representational State Transfer

AJAX still revolves around RPC (just asynchronously)

Representational State Transfer (REST) offers an alternativeI All resources have a name: URL or URII Resources are manipulated with PUT, GET, POST, and DELETE

methodsI State is sent along with operations

Widely used these days (For instance, by Amazon, Twitter, etc.)



AJAX still revolves around RPC (just asynchronously)Representational State Transfer (REST) offers an alternative

I All resources have a name: URL or URI

I Resources are manipulated with PUT, GET, POST, and DELETEmethods

I State is sent along with operations





I All resources have a name: URL or URII Resources are manipulated with PUT, GET, POST, and DELETE

methods

I State is sent along with operations





I All resources have a name: URL or URII Resources are manipulated with PUT, GET, POST, and DELETE

methodsI State is sent along with operations



Outline

1 Introduction


3 Characteristics



Clocks

Distributed systems need to be able to:

I Order events produced by concurrent processesI Synchronize senders and receivers of messagesI Serialize concurrent accesses to shared objectsI Coordinate joint activity

Clocks are employed for this

But quartz oscillators oscillate at slightly different frequencies leadingto clock drift and resulting in clock skew between clocks


Clocks

Distributed systems need to be able to:I Order events produced by concurrent processes

I Synchronize senders and receivers of messagesI Serialize concurrent accesses to shared objectsI Coordinate joint activity




Clocks

Distributed systems need to be able to:I Order events produced by concurrent processesI Synchronize senders and receivers of messages

I Serialize concurrent accesses to shared objectsI Coordinate joint activity




Clocks

Distributed systems need to be able to:I Order events produced by concurrent processesI Synchronize senders and receivers of messagesI Serialize concurrent accesses to shared objects

I Coordinate joint activity




Clocks

Distributed systems need to be able to:I Order events produced by concurrent processesI Synchronize senders and receivers of messagesI Serialize concurrent accesses to shared objectsI Coordinate joint activity




Clock synchronization

Clock synchronization algorithms try to minimize skew between a set ofclocks

I Decide upon a correct timeI Communicate to agree (compensating for delays)I Possibly multiple servers involved

In reality, still a 1-10ms skew after sync (but we can live with that)




I Decide upon a correct time

I Communicate to agree (compensating for delays)I Possibly multiple servers involved





I Decide upon a correct timeI Communicate to agree (compensating for delays)

I Possibly multiple servers involved





I Decide upon a correct timeI Communicate to agree (compensating for delays)I Possibly multiple servers involved



Ordering

Time is used to ensure ordering

I Withdraw money at 23:59.45I Bank calculates interest at 00:00.0I The withdraw money should not be included in the interest calculation

In most cases, only need to know that a happened before b, known asthe happens-before relation

Multiple algorithms exists to ensure the happens-before relation


Ordering

Time is used to ensure orderingI Withdraw money at 23:59.45

I Bank calculates interest at 00:00.0I The withdraw money should not be included in the interest calculation




Ordering

Time is used to ensure orderingI Withdraw money at 23:59.45I Bank calculates interest at 00:00.0

I The withdraw money should not be included in the interest calculation




Ordering

Time is used to ensure orderingI Withdraw money at 23:59.45I Bank calculates interest at 00:00.0I The withdraw money should not be included in the interest calculation




Distributed Mutual Exclusion

Concurrent access to shared resources needs to be synchronized

Need hardware support on local machineI Locks, semaphores, etc.

But this support is not available across a distributed system


Distributed Mutual Exclusion

Concurrent access to shared resources needs to be synchronizedNeed hardware support on local machine

I Locks, semaphores, etc.

But this support is not available across a distributed system


Distributed Mutual Exclusion (2)

Multiple methods exist to ensure this:

Central lock server: All lock requests are handled by a central server

Token passing: Arrange nodes into a ring and a token is passedaround

Totally-ordered multicast: Clients multicast requests to each other


Consensus

Getting processes in a distributed system to agree on something

Requirements for correct solutionI Agreement: All nodes arrive at the same answerI Validity: Answer is one that was proposed by someoneI Termination: All nodes eventually decide


Consensus

Getting processes in a distributed system to agree on somethingRequirements for correct solution

I Agreement: All nodes arrive at the same answer

I Validity: Answer is one that was proposed by someoneI Termination: All nodes eventually decide


Consensus


I Agreement: All nodes arrive at the same answerI Validity: Answer is one that was proposed by someone

I Termination: All nodes eventually decide


Consensus


I Agreement: All nodes arrive at the same answerI Validity: Answer is one that was proposed by someoneI Termination: All nodes eventually decide


Distributed transactions

Composite operations (i.e. A collection of reads and updates to a set ofobjects)

A transaction is atomicI If it commits, all operations are appliedI If it aborts, no state mutation at all

Distributed transactions span multiple transaction processing serversI For instance, booking flights: Lahore -> Dubai -> New YorkI Need to book entire trip

Actions need to be coordinated across multiple parties



Composite operations (i.e. A collection of reads and updates to a set ofobjects)A transaction is atomic

I If it commits, all operations are appliedI If it aborts, no state mutation at all






I If it commits, all operations are applied

I If it aborts, no state mutation at all







Distributed transactions span multiple transaction processing servers

I For instance, booking flights: Lahore -> Dubai -> New YorkI Need to book entire trip






Distributed transactions span multiple transaction processing serversI For instance, booking flights: Lahore -> Dubai -> New York

I Need to book entire trip



Replication

A number of distributed systems involve replication

I Data replication: Multiple copies of some object stored at differentservers

I Computation replication: Multiple servers capable of providing anoperation

Advantages:1 Load balancing: Work spread out across clients2 Lower latency: Better performance if replica close to the client3 Fault tolerance: Failure of some replicas can be tolerated

Examples: DNS, content distribution networks, database replication,etc.


Replication

A number of distributed systems involve replicationI Data replication: Multiple copies of some object stored at different

servers

I Computation replication: Multiple servers capable of providing anoperation




Replication


serversI Computation replication: Multiple servers capable of providing an

operation




Replication



operation

Advantages:1 Load balancing: Work spread out across clients

2 Lower latency: Better performance if replica close to the client3 Fault tolerance: Failure of some replicas can be tolerated



Replication



operation

Advantages:1 Load balancing: Work spread out across clients2 Lower latency: Better performance if replica close to the client

3 Fault tolerance: Failure of some replicas can be tolerated



Replication



operation




CAP

CAP:1 Consistency: All nodes see the same state

2 Availability: All requests get a response3 Partitioning: System continues to operate even in the face of node

failure

Brewer’s conjecture states that in a distributed system only 2 out of 3possible

In the current setup, partitioning is a given: Hardware/software fails allthe time

Therefore, systems need to choose between consistency andavailability


CAP

CAP:1 Consistency: All nodes see the same state2 Availability: All requests get a response

3 Partitioning: System continues to operate even in the face of nodefailure





CAP

CAP:1 Consistency: All nodes see the same state2 Availability: All requests get a response3 Partitioning: System continues to operate even in the face of node

failure





References

George Coulouris, Jean Dollimore, Tim Kindberg, and Gordon Blair.2011. Distributed Systems: Concepts and Design (5th ed.).Addison-Wesley Publishing Company, USA.


Topic 3: Large-scale Distributed Systems

Technology

Transcript of Topic 3: Large-scale Distributed Systems