EEC-681/781 Distributed Computing Systems Lecture 4 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University [email protected]

EEC-681/781EEC-681/781Distributed Computing Distributed Computing

SystemsSystems

Lecture 4Lecture 4

Wenbing ZhaoWenbing ZhaoDepartment of Electrical and Computer EngineeringDepartment of Electrical and Computer Engineering

Cleveland State UniversityCleveland State University

[email protected]@ieee.org

Fall Semester 2006Fall Semester 2006 EEC-681: Distributed Computing SystemsEEC-681: Distributed Computing Systems Wenbing ZhaoWenbing Zhao

22

OutlineOutline

• Architecture Model

• Server load balancing

• End-to-end arguments in system design

• Inter-process communications (part 1)


33

Architectural ModelsArchitectural Models

• Client-server model

• Peer-to-peer model


44

Basic Client–Server ModelBasic Client–Server Model


55

ServersServers

• Servers: Generally provide services related to a shared resource:– Servers for file systems, databases,

implementation repositories, etc.– Servers for shared, linked documents– Servers for shared applications– Servers for shared distributed objects


66

ClientClient

• Clients: Allow remote service access– Programming interface transforming client’s local

service calls to request/reply messages– Devices with (relatively simple) digital components

(barcode readers, teller machines, hand-held phones)– Computers providing independent user interfaces for

specific services– Computers providing an integrated user interface for

related services (compound documents)


77

Application LayeringApplication Layering

• Traditional three-layered view:– User-interface layer contains units for an

application’s user interface– Processing layer contains the functions of an

application, i.e. without specific data– Data layer contains the data that a client

wants to manipulate through the application components


88

Multitiered ArchitectureMultitiered Architecture


99

Multitiered ArchitectureMultitiered Architecture

1-30


1010

Horizontal DistributionHorizontal Distribution

1-31


1111

Modern ArchitecturesModern Architectures

• Vertical distribution– According to application logic

• Horizontal distribution– Scalability and availability

• In practice, a system is distributed in both directions


1212

Peer-to-Peer ModelPeer-to-Peer Model

• A different way to construct client-server systems where most, or all, of the server functionality resides on the clients themselves

• Advantages– Scalable to very large numbers (millions)– Stable under very high load– Self-repairing when disruptive failures occur


1313

Why Server Load Balancing?Why Server Load Balancing?

• Scalable - Upgrade out instead of up • Easily grow - Spread your load across your

existing low-cost servers as your needs grow• HA - Can work closely with High Availability

solutions to add and remove servers as necessary

Slides on server load balancing taken from Dustin Puryear’s talk on “LVS – Load Balancing and High Availability for Free” at USENIX LISA 2003


1414

SLB LayoutSLB Layout


1515

SLB DefinitionsSLB Definitions

• Virtual IP (VIP) – The IP used by clients to access a service

• Load Balancer (LB) or Server Load Balancer (SLB) – the server that balances packets going to or from the servers providing the service

• Real Server – The server providing the actual service (i.e., the server running Apache)

• Real IP (RIP) – The IP of each real server• Schedule – How the SLB determines which real

server gets the next connection


1616

SLB Transaction WalkthroughSLB Transaction Walkthrough

1. Client established TCP connection with SLB.

2. SLB determines which real server is ready for a connection using configured schedule, and creates a connection to that server.

3. Client sends HTTP request.4. SLB forwards HTTP request

to real server.5. Real server responds back

to.. Who?


1717

So How Exactly Does the Real So How Exactly Does the Real Server Respond?Server Respond?

• There are two traditional methods to solving this problem:– Network Address Translation (NAT)– Direct Routing/Direct Server Return


1818

NAT-Based SLBNAT-Based SLB


1919

NAT-Based SLBNAT-Based SLB

• SLB sits between the client and real servers for all incoming and outgoing packets, just like a router that does NAT

• The SLB can rewrite the IP packet in one of two ways:– Half-NAT: load-balancer rewrites the destination IP– Full-NAT: load-balancer rewrites the source and

destination IP• The VIP is only assigned on the load-balancer


2020

Half-NATHalf-NAT

1. SLB gets packet from client2. SLB changes the destination IP in the header

of the packet3. SLB forwards packet to real server

• Major benefit of this method is that the real server knows the real IP of the client

– The real server can properly log client IP’s– The real server can do better security based on the

IP address of the client


2121

Full-NATFull-NAT

1. SLB gets packet from client.

2. SLB changes the destination IP and source IP in the header of the packet.

3. SLB forwards packet to real server.

• Major drawback to this technique:– The real server has no idea who sent the original

request


2222

Direct Routing/Direct Server ReturnDirect Routing/Direct Server Return

Layer 2 LB


2323

Direct Routing/Direct Server ReturnDirect Routing/Direct Server Return

1. SLB gets packet from client2. SLB changes destination IP in packet header3. SLB forwards packet to real server, which also has VIP4. Real server responds directly to the client with VIP as

the source IP

• There are benefits and costs to this approach– Without having to push data back through the SLB

you can decrease latency– How do you handle ARP if multiple devices have the

same IP (the VIP)?


2424

End-to-End Arguments End-to-End Arguments in System Designin System Design

• Concerned with placement of functions among modules of a distributed system

• Layered systems are very common– Network protocols and Middleware

• Claim– Functions at low levels of a system may be

redundant or of little use– Moving a function upward in a layered system

closer to application that uses the function


2525

Careful File TransferCareful File Transfer

• Objective: move a file from computer A’s storage to computer B’s storage

• Application program: file transfer program


2626


• Fault-free steps of file transfer– A reads the file from its disk– A sends the file to its networking stack and the file is

packetized at the networking protocol stack– Communication network moves packets from A to B– At B, B’s networking protocol stack delivers

transmitted file to the file transfer program running in B

– B’s file transfer program asks its file system to write the file to B’s disk


2727


• What can go wrong in each step– File corrupted due to disk error– Software bugs in buffering and copying the file,

in A or B– Processor or memory transient error during

buffering or copying– Communication system error, e.g., drop or

change bits, or duplicate delivery– Host might crash


2828


• How to cope with the threats– Reinforce each step along the way using time-

out and retry, error detection, crash recovery, etc.

– Doing everything three times


2929

End-to-end Check and RetryEnd-to-end Check and Retry

• Assuming low probability of the threats

• As a final additional step– B reads back the file from disk into memory– Recalculates checksum– Sends this value back to A– A compares the value with checksum of

original file– If two checksums agree, file transfer

completes. Otherwise, retry from beginning


3030

Is Reliable Communication Useful?Is Reliable Communication Useful?

• Communication system can be made reliable with Packet checksums, sequence number, internal retry, etc.

• Is it enough to ensure correct file transfer?– No. Other threats can still corrupt the file– The extra end-to-end check and retry still necessary– Usefulness: Reducing frequency of retry


3131

Is Reliable Communication Useful?Is Reliable Communication Useful?

• Conclusion– Communication system to go out of its way to

be extraordinarily reliable does not reduce the burden on the application program to ensure reliability


3232

Performance AspectsPerformance Aspects

• Cannot conclude that lower levels should play no part in obtaining reliability– If file is long, retry the transfer of the file is too

expensive– By providing reliable communication, can

significantly enhance the performance


3333

Performance AspectsPerformance Aspects

• Putting reliability measures in lower level– An engineering trade-off based on performance– Not a requirement for correctness– Must be careful. Might not always improve

performance• Other application might not need the extra

functionality• Might not have enough information to operate

efficiently


3434

Inter-Process CommunicationsInter-Process Communications

• Techniques:– Shared memory– Message passing

• Objectives:– Data exchange– Synchronization: processes at different

hosts, executing at different rates, need to influence the overall execution pattern => Constraints on the order of events


3535

The OSI Network ArchitectureThe OSI Network Architecture


3636

Low-level LayersLow-level Layers

• Physical layer: contains the specification and implementation of bits, and their transmission between sender and receiver

• Data link layer: prescribes the transmission of a series of bits into a frame to allow for error and flow control

• Network layer: describes how packets in a network of computers are to be routed


3737

Transport LayerTransport Layer

• The transport layer provides the actual communication facilities for most distributed systems.

• TCP: connection-oriented, reliable, stream-oriented communication

• UDP: unreliable (best-effort) datagram communication


3838

Application LayerApplication Layer

• Many application protocols are directly implemented on top of transport protocols that do a lot of application-independent work

FTP WWW

Transfer FTP HTTP

Encoding 7-bit text + 8-bit binary 8-bit + content type

Naming Host + path URL

Distribution Pull Pull

Replication Caching + DNS tricks Caching + DNS tricks


3939

Message LayoutMessage Layout


4040

Middleware LayerMiddleware Layer

• Middleware is invented to provide common services and protocols that can be used by many different applications:– A rich set of communication protocols– Marshaling and unmarshaling of data– Naming protocols– Security protocols– Scaling mechanisms

• What remains are truly application-specific protocols


4141An Adapted Reference Model An Adapted Reference Model with Middleware Layerwith Middleware Layer

2-5

Documents

EEC-681/781 Distributed Computing Systems Lecture 4 Wenbing Zhao Department of Electrical and Computer Engineering Cleveland State University [email protected]