Page 1 Page 1 Go Over Minqi Zhou( 周周周 ) [email protected] Room 111 (East) Mathematics Building 021-32204750-167 Distributed Systems
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1Page 1
Go Over
Minqi Zhou(周敏奇 )[email protected]
Room 111 (East) Mathematics Building021-32204750-167
Distributed Systems
Page 2
Over View• Why distributed system• Naming• Communication• Synchronization• Secure
2
Page 3Page 3
What can we do nowthat we could not do
before?
Page 4
Technology advances
Processors Memory
Networking
StorageProtocols
4
Page 5Page 5
Building and classifyingdistributed systems
Page 6
Flynn’s Taxonomy (1972)
SISD– traditional uniprocessor system
SIMD– array (vector) processor– Examples:
• APU (attached processor unit in Cell processor)• SSE3: Intel’s Streaming SIMD Extensions• PowerPC AltiVec (Velocity Engine)
MISD– Generally not used and doesn’t make sense– Sometimes applied to classifying redundant systems
MIMD– multiple computers, each with:
• program counter, program (instructions), data– parallel and distributed systems
number of instruction streamsand number of data streams
6
Page 7
Subclassifying MIMD
memory– shared memory systems: multiprocessors– no shared memory: networks of computers,
multicomputersinterconnect
– bus– switch
delay/bandwidth– tightly coupled systems– loosely coupled systems
7
Page 8
You know you have a distributed system when the crash of a computer you’ve never heard of stops you from getting any work done.
– Leslie Lamport
8
Page 9
Coupling
Tightly versus loosely coupled software
Tightly versus loosely coupled hardware
9
Page 10
Design issues: TransparencyHigh level: hide distribution from usersLow level: hide distribution from software
– Location transparency:users don’t care where resources are
– Migration transparency:resources move at will
– Replication transparency:users cannot tell whether there are copies of resources
– Concurrency transparency:users share resources transparently
– Parallelism transparency:operations take place in parallel without user’s knowledge
10
Page 11
Design issues
Reliability– Availability: fraction of time system is
usable• Achieve with redundancy
– Reliability: data must not get lost• Includes security
Performance– Communication network may be slow and/or
unreliableScalability
– Distributable vs. centralized algorithms– Can we take advantage of having lots of
computers?11
Page 12Page 12
Service Models
Page 13
Centralized model• No networking• Traditional time-sharing
system• Direct connection of user terminals to
system• One or several CPUs• Not easily scalable• Limiting factor: number of CPUs in system
– Contention for same resources
13
Page 14
Client-server model
Environment consists of clients and serversService: task machine can performServer: machine that performs the taskClient: machine that is requesting the service
Directory server Print server File server
client client
Workstation modelassume client is used by one user at a time
14
Page 15
Peer to peer model• Each machine on network has (mostly)
equivalent capabilities
• No machines are dedicated to serving others
• E.g., collection of PCs:– Access other people’s files– Send/receive email (without server)– Gnutella-style content sharing– SETI@home computation
15
Page 16
Processor pool model
What about idle workstations(computing resources)?– Let them sit idle– Run jobs on them
Alternatively…– Collection of CPUs that can be assigned
processes on demand– Users won’t need heavy duty workstations
• GUI on local machine– Computation model of Plan 9
16
Page 17
Grid computing
Provide users with seamless access to:– Storage capacity– Processing– Network bandwidth
Heterogeneous and geographically distributed systems
17
Page 18Page 18
Naming
Page 19
Naming things• User names
– Login, email• Machine names
– rlogin, email, web• Files• Devices• Variables in programs• Network services
19
Page 20
Naming ServiceAllows you to look up names
– Often returns an address as a response
Might be implemented as– Search through file– Client-server program– Database query– …
20
Page 21
What’s a name?
Name: identifies what you want
Address: identifies where it is
Route: identifies how to get there
Binding: associates a name with an address– “choose a lower-level-implementation for a
higher-level semantic construct”
21RFC 1498: Inter-network Naming, addresses, routing
Page 22
NamesNeed names for:
– Services: e.g., time of day– Nodes: computer that can run services– Paths: route– Objects within service: e.g. files on a file
serverNaming convention can take any format
– Ideally one that will suit application and user
– E.g., human readable names for humans, binary identifiers for machines
22
Page 23
Naming 5.2 Flat Naming
Flat naming
ProblemGiven an essentially unstructured name (e.g., an identifier), how canwe locate its associated access point?
Simple solutions (broadcasting)Home-based approachesDistributed Hash Tables (structured P2P)Hierarchical location service
6 / 38
Page 24Page 24
RPC
Page 25
Problems with sockets
Sockets interface is straightforward– [connect]– read/write– [disconnect]
BUT … it forces read/write mechanism – We usually use a procedure call
To make distributed computing look more like centralized:– I/O is not the way to go
Page 26
RPC1984: Birrell & Nelson
– Mechanism to call procedures on other machines
Remote Procedure Call
Goal: it should appear to the programmer that a normal call is taking
place
Page 27
Implementing RPC
The trick:
Create stub functions to make it appear to the user that the call is local
Stub function contains the function’s interface
Page 28
client server
Stub functions Marshal, Unmarshal return, return to client code
client functions
client stub
network routines
server functions
server stub(skeleton)
network routines
Page 29
Parameter passing
Pass by value– Easy: just copy data to network message
Pass by reference– Makes no sense without shared memory
Page 30
Representing data
No such thing asincompatibility problems on local system
Remote machine may have:– Different byte ordering– Different sizes of integers and other types– Different floating point representations– Different character sets– Alignment requirements
Page 31Page 31
Concurrency
Page 32
Schedules• Transactions must have scheduled so that
data is serially equivalent• Use mutual exclusion to ensure that only one
transaction executes at a time• or…• Allow multiple transactions to execute
concurrently– but ensure serializability
• concurrency control
• schedule: valid order of interleaving32
Page 33
Methods • Two Phase locking• Strict two phase locking• Read/write lock• Two version locking
33
Page 34Page 34
Synchronization
Page 35
Physical clocks in computers
Real-time Clock: CMOS clock (counter) circuit driven by a quartz oscillator
– battery backup to continue measuring time when power is off
OS generally programs a timer circuit to generate an interrupt periodically
– e.g., 60, 100, 250, 1000 interrupts per second(Linux 2.6+ adjustable up to 1000 Hz)
– Programmable Interval Timer (PIT) – Intel 8253, 8254– Interrupt service procedure adds 1 to a counter in
memory
Page 36
Problem
Getting two systems to agree on time– Two clocks hardly ever agree– Quartz oscillators oscillate at slightly different
frequencies
Clocks tick at different rates– Create ever-widening gap in perceived time– Clock Drift
Difference between two clocks at one point in time– Clock Skew
Page 37
RPCSimplest synchronization technique
– Issue RPC to obtain time– Set time
Does not account for network or processing latency
client serverwhat’s the time?
3:42:19
Page 38
Cristian’s algorithmCompensate for delays
– Note times:• request sent: T0
• reply received: T1
– Assume network delays are symmetric
server
clienttime
request reply
T0 T1
Tserver
Page 39
Cristian’s algorithmClient sets time to:
server
clienttime
request reply
T0 T1
Tserver
= estimated overhead in each direction
Page 40
Time synchronization• Berkeley algorithm• NTP• SNTP
40
Page 41
Logical clocks
Assign sequence numbers to messages– All cooperating processes can agree on order
of events– vs. physical clocks: time of day
Assume no central time source– Each system maintains its own local clock– No total ordering of events
• No concept of happened-when
Page 42
Happened-before
Lamport’s “happened-before” notation
a b event a happened before event be.g.: a: message being sent, b: message
receipt
Transitive:if a b and b c then a c
Page 43
Lamport’s algorithm• Each message carries a timestamp of the
sender’s clock
• When a message arrives:– if receiver’s clock < message timestamp
set system clock to (message timestamp + 1)
– else do nothing
• Clock must be advanced between any two events in the same process
Page 44
Lamport’s algorithm
Algorithm allows us to maintain time ordering among related events
– Partial ordering
Page 45
Event counting example
a b
i
kj
P1
P2
P3
1 2
1 7
21
d f
g3
c
2
4 6
6
7
h
e5
Page 46
Problem: Detecting causal relations
If L(e) < L(e’)– Cannot conclude that ee’
Looking at Lamport timestamps– Cannot conclude which events are causally
related
Solution: use a vector clock
Page 47
Vector clocksRules:
1. Vector initialized to 0 at each processVi [j] = 0 for i, j =1, …, N
2. Process increments its element of the vector in local vector before timestamping event: Vi [i] = Vi [i] +1
3. Message is sent from process Pi with Vi attached to it
4. When Pj receives message, compares vectors element by element and sets local vector to higher of two values
Vj [i] = max(Vi [i], Vj [i]) for i=1, …, N
Page 48Page 48
Group Communication
Page 49
Modes of communication• unicast
– 11– Point-to-point
• anycast– 1nearest 1 of several identical nodes– Introduced with IPv6; used with BGP
• netcast– 1 many, 1 at a time
• multicast– 1many– group communication
• broadcast– 1all
49
Page 50
Groups
Groups are dynamic– Created and destroyed– Processes can join or leave
• May belong to 0 or more groupsSend message to one entity
– Deliver to entire group
Deal with collection of processes as one abstraction
50
Page 51
For multicast• atomic • Reliable • unreliable• ordering
51
Page 52
Multicasting considerations
atomic
reliableunreliable
unordered synccausal
totalglobal
unordered FIFO
Message Ordering
Relia
bilit
y
52
Page 53Page 53
Distributed shared memory
Page 54
MotivationSMP systems
– Run parts of a program in parallel– Share single address space
• Share data in that space– Use threads for parallelism– Use synchronization primitives to prevent race
conditions
Can we achieve this with multicomputers?– All communication and synchronization must
be done with messages54
Page 55
Distributed Shared Memory (DSM)Goal: allow networked computers to
share a region of virtual memory
• How do you make a distributed memory system appear local?
• Physical memory on each node used to hold pages of shared virtual address space. Processes address it like local memory.
55
Page 56
issues• Access (MMU)• Cache• Replication• consistency
56
Page 57Page 57
Security
Page 58
Terms: types of ciphers
• restricted cipher
• symmetric algorithm
• public key algorithm
58
Page 59
Classic Cryptosystems• Substitution Ciphers• Transposition Ciphers• Combined ciphers• Rotor machines• One-time pads
59
Page 60
public key algorithm
• Diffie-Hellman exponential key exchange• RSA algorithm
60
Page 61
Digital signature• Arbitrated protocol• Integrity of the document
61
Page 62
Authentication
Three factors:– something you have key, card
• can be stolen
– something you knowpasswords• can be guessed, shared, stolen
– something you are biometrics• costly, can be copied (sometimes)
62
Page 63
password• Reusable password• One time password• Skey authentication• SKID2/SKID3 authentication• Kerberos authentication
63
Page 64Page 64
The end.
Related Documents
