CS4513 Goals Sof t war e Dist ribut ed Comput er Client Server - - PDF document

1

CS4513 Dist ribut ed Comput er Syst ems

I nt roduct ion (Ch 1: 1.1-1.2, 1.4-1.5)

Out line

• Overview
• Goals
• Sof t war e
• Client Server

The Rise of Dist r ibut ed Syst ems

• Comput er har dwar e pr ices f alling, power incr easing

– I f cars t he same, Rolls Royce would cost 1 dollar and get 1 billion miles per gallon (wit h 200 page manual t o

• pen t he door)
• Net wor k connect ivit y incr easing

– Everyone is connect ed wit h f at pipes

• I t is easy t o connect har dwar e t oget her
• Def init ion: a dist r ibut ed syst em is

– A collect ion of independent comput ers t hat appears t o it s users as a single coherent syst em.

Def init ion of a Dist ribut ed Syst em

A dist ribut ed syst em organized as middleware. Not e t hat t he middleware layer ext ends over mult iple machines. Users can int eract wit h t he syst em in a consist ent way, regardless

• f where t he int eract ion t akes place

Examples:

• The Web
• Pr ocessor Pool
• Air line

Reservat ion

Transparency in a Dist ribut ed Syst em

Dif f erent f orms of t ransparency in a dist ribut ed syst em.

Hide whether a (software) resource is in memory or on disk Persistence Hide the failure and recovery of a resource Failure Hide that a resource may be shared by several competitive users Concurrency Hide that a resource may be shared by several competitive users Replication Hide that a resource may be moved to another location while in use Relocation Hide that a resource may move to another location Migration Hide where a resource is located Location Hide differences in data representation and how a resource is accessed Access Description Transparency

Scalabilit y Problems

• As dist r ibut ed syst ems gr ow, cent r alized solut ions

are limit ed

– Consider LAN name resolut ion vs. WAN

Doing r out ing based on complet e inf or mat ion Cent ralized algorit hms A single on-line t elephone book Cent ralized dat a A single server f or all users Cent r alized ser vices Example Concept

• Somet imes, har d t o avoid (consider a bank)
• Need t o collect inf or mat ion in dist r ibut ed f ashion

and dist r ibut ed in a dist r ibut ed f ashion

• Challenges:

– geography, ownership domains, t ime synchronizat ion

2

Scaling Techniques: Hiding Communicat ion Lat ency

• Especially import ant f or int eract ive applicat ions
• I f possible, do asynchronous communicat ion
• Not always possible when client has not hing t o do
• Instead, can hide latencies

Scaling Techniques: Dist ribut ion

1.5 Example: DNS name space int o zones (nl.vu.cs.fluit – z1 gives addr ess of vu gives addr ess of cs) Example: The Web

Scaling Techniques: Replicat ion

• Copy of inf ormat ion t o increase availabilit y

and decrease cent ralized load

– Example: P2P net wor ks (Gnut ella +) dist ribut e copies unif ormly or in proport ion t o use – Example: akamai – Example: Caching is a replicat ion decision made by client

• I ssue: Consist ency of replicat ed

inf or mat ion

– Example: Web Br owser cache

Out line

• Overview

(done)

• Goals

(done)

• Sof t war e

← ←

• Client Server

Sof t ware Concept s

• DOS (Dist ribut ed Operat ing Syst ems)
• NOS (Net wor k Oper at ing Syst ems)
• Middleware

Provide distribution transparency Additional layer atop of NOS implementing general -purpose services Middleware Offer local services to remote clients Loosely -coupled operating system for heterogeneous multicomputers (LAN and WAN) NOS Hide and manage hardware resources Tightly-coupled operating system for multi - processors and homogeneous multicomputers DOS Main Goal Description System

Uniprocessor Operat ing Syst ems

• Separ at ing applicat ions f r om oper at ing

syst em code t hr ough a micr oker nel – Can ext end t o mult iple comput ers

3

Mult icomput er Operat ing Syst ems

• But no longer have shared memory

– Can t ry t o provide dist ribut ed shared memory

• Tough, coming up

– Can provide message passing

Mult icomput er Operat ing Syst ems

• Message passing primit ives vary widely bet ween syst ems

– Example: consider buf f ering and synchronizat ion (optional) (optional)

Mult icomput er Operat ing Syst ems

• Relat ion bet ween blocking, buf f ering, and reliable

communicat ions.

• These issues make synchronizat ion harder. I t was easier when

we had shared memory. – So … dist ribut ed shared memory

Necessary No Block sender until message delivered Necessary No Block sender until message received Not necessary No Block sender until message sent Not necessary Yes Block sender until buffer not full Reliable comm. guaranteed? Send buffer Synchronization point

Dist ribut ed Shared Memory Syst ems

a) Pages of addr ess space dist r ibut ed among f our machines b) Sit uat ion af t er CPU 1 r ef er ences page 10 c) Sit uat ion if page 10 is r ead only and r eplicat ion is used

Dist ribut ed Shared Memory Syst ems

• Over all, DSM syst ems have st r uggled t o pr ovide ef f iciency and

convenience (and been ar ound 15 year s) – For higher-per f or mance, t ypically st ill do message passing

– Likely will remain t hat way

• I ssue: how large should page sizes be? What are t he

t radeof f s?

Net wor k Oper at ing Syst em

• OSes can be dif f er ent (Windows or Linux)
• Typical ser vices: r login, r cp

– Fairly primit ive way t o share f iles

4

Net wor k Oper at ing Syst em

• Can have one comput er pr ovide f iles t r anspar ent ly

f or ot her s (NFS)

– (t ry a “df” on t he WP I host s t o see. Similar t o a “mount net work drive” in Windows)

Net wor k Oper at ing Syst em

• Dif f erent client s may mount t he servers in dif f erent places
• I nconsist encies in view make NOSes harder, in general f or

users t han DOSes. – But easier t o scale by adding comput ers

Posit ioning Middleware

• Net wor k OS not t r anspar ent . Dist r ibut ed OS not

independent comput er s. – Middleware can help

• Much middleware built in-house to help use networked
• perating systems(distributed transactions, better comm, RPC)
• Unfortunately, many different standards

Middleware and Openness

• I n an open middleware-based dist ribut ed syst em, t he

prot ocols used by each middleware layer should be t he same, as well as t he int erf aces t hey of f er t o applicat ions. – I f dif f erent , compat ibilit y issues – I f incomplet e, t hen users build t heir own or use lower - layer services (f rowned upon)

1.23

Compar ison bet ween Syst ems

• DOS most t ransparent , but closed and only moderat ely

scalable

• NOS not so t ransparent , but open and scalable
• Middleware provides a bit more t ransparency t han NOS

Open Open Closed Closed Openness Varies Yes Moderately No Scalability Per node Per node Global, distributed Global, central Resource management Model specific Files Messages Shared memory Basis for communication N N N 1 Number of copies of OS No No Yes Yes Same OS on all nodes High Low High Very High Degree of transparency Multicomp. Multiproc. Middleware- based OS Netw ork OS Distributed OS I tem

Out line

• Overview

(done)

• Goals

(done)

• Sof t war e

(done)

• Client Server

← ←

5

Client s and Ser ver s

• Thus f ar , have not t alked about or ganizat ion of

pr ocesses

– Again, many choices but most agree upon client -server

• I f can do so wit hout connect ion, quit e simple
• I f underlying connect ion is unreliable, not t rivial
• Resend? What if receive t wice
• Use TCP f or r eliable connect ion (apps on I nt er net )
• Not always appropriat e f or high-speed LAN connect ion

(4513)

Example Client and Ser ver : Header

• Used by bot h t he client and ser ver .

Example Client and Ser ver : Ser ver Example Client and Server: Client

• One issue, is how t o clearly dif f erent iat e

Client -Server I mplement at ion Levels

• Example of an I nt ernet search engine

– UI on client – P rocessing can be on client or server – Dat a level is server, keeps consist ency

Mult it ier ed Ar chit ect ur es

• Thin client (a) t o Fat client (e)

– (d) and (e) popular f or NOS environment s

6

Mult it ier ed Ar chit ect ur es: 3 t ier s

• Ser ver may act as a client

– Example would be t ransact ion monit or across mult iple dat abases

Modern Archit ect ures: Horizont al

• Rat her t han ver t ical, dist r ibut e ser ver s acr oss

nodes – Example of Web server “f arm” f or load balancing – Client s, t oo (peer-to-peer syst ems)