CSE 486/586 Distributed Systems Global States

Slides:



Advertisements
Similar presentations
Global States.
Advertisements

CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Consensus Steve Ko Computer Sciences and Engineering University at Buffalo.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Reliable Multicast Steve Ko Computer Sciences and Engineering University at Buffalo.
SES Algorithm SES: Schiper-Eggli-Sandoz Algorithm. No need for broadcast messages. Each process maintains a vector V_P of size N - 1, N the number of processes.
Uncoordinated Checkpointing The Global State Recording Algorithm Cristian Solano.
Time and Global States Part 3 ECEN5053 Software Engineering of Distributed Systems University of Colorado, Boulder.
CS542 Topics in Distributed Systems Diganta Goswami.
CS514: Intermediate Course in Operating Systems Professor Ken Birman Vivek Vishnumurthy: TA.
CS 582 / CMPE 481 Distributed Systems
Causality & Global States. P1 P2 P Physical Time 4 6 Include(obj1 ) obj1.method() P2 has obj1 Causality violation occurs when order.
Ordering and Consistent Cuts Presented By Biswanath Panda.
CMPT 431 Dr. Alexandra Fedorova Lecture VIII: Time And Global Clocks.
Distributed Systems Fall 2009 Logical time, global states, and debugging.
Slides for Chapter 10: Time and Global State
EEC-681/781 Distributed Computing Systems Lecture 11 Wenbing Zhao Cleveland State University.
CSE 486/586, Spring 2012 CSE 486/586 Distributed Systems Logical Time Steve Ko Computer Sciences and Engineering University at Buffalo.
Cloud Computing Concepts
Computer Science Lecture 10, page 1 CS677: Distributed OS Last Class: Clock Synchronization Physical clocks Clock synchronization algorithms –Cristian’s.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Logical Time Steve Ko Computer Sciences and Engineering University at Buffalo.
1 Distributed Systems CS 425 / CSE 424 / ECE 428 Global Snapshots Reading: Sections 11.5 (4 th ed), 14.5 (5 th ed)  2010, I. Gupta, K. Nahrtstedt, S.
Lecture 6-1 Computer Science 425 Distributed Systems CS 425 / ECE 428 Fall 2013 Indranil Gupta (Indy) September 12, 2013 Lecture 6 Global Snapshots Reading:
CSE 486/586 CSE 486/586 Distributed Systems Logical Time Steve Ko Computer Sciences and Engineering University at Buffalo.
Distributed Systems Fall 2010 Logical time, global states, and debugging.
CSE 486/586, Spring 2013 CSE 486/586 Distributed Systems Global States Steve Ko Computer Sciences and Engineering University at Buffalo.
Ordering of Events in Distributed Systems UNIVERSITY of WISCONSIN-MADISON Computer Sciences Department CS 739 Distributed Systems Andrea C. Arpaci-Dusseau.
CSE 486/586 CSE 486/586 Distributed Systems Global States Steve Ko Computer Sciences and Engineering University at Buffalo.
Lecture 4-1 Computer Science 425 Distributed Systems (Fall2009) Lecture 4 Chandy-Lamport Snapshot Algorithm and Multicast Communication Reading: Section.
1 Chapter 11 Global Properties (Distributed Termination)
Hwajung Lee. -- How many messages are in transit on the internet? --What is the global state of a distributed system of N processes? How do we compute.
CSE 486/586, Spring 2014 CSE 486/586 Distributed Systems Logical Time Steve Ko Computer Sciences and Engineering University at Buffalo.
Distributed Systems Lecture 6 Global states and snapshots 1.
Ordering of Events in Distributed Systems UNIVERSITY of WISCONSIN-MADISON Computer Sciences Department CS 739 Distributed Systems Andrea C. Arpaci-Dusseau.
CSCE 668 DISTRIBUTED ALGORITHMS AND SYSTEMS
Global state and snapshot
CSE 486/586 Distributed Systems Reliable Multicast --- 1
Advanced Topics in Concurrency and Reactive Programming: Time and State Majeed Kassis.
Global state and snapshot
CSE 486/586 Distributed Systems Logical Time
Lecture 3: State, Detection
Vector Clocks and Distributed Snapshots
CSE 486/586 Distributed Systems Global States
CSE 486/586 Distributed Systems Time and Synchronization
Theoretical Foundations
CSE 486/586 Distributed Systems Logical Time
Distributed Snapshot.
Global State and Gossip
COT 5611 Operating Systems Design Principles Spring 2012
EECS 498 Introduction to Distributed Systems Fall 2017
湖南大学-信息科学与工程学院-计算机与科学系
Slides for Chapter 14: Time and Global States
Time And Global Clocks CMPT 431.
Chapter 5 (through section 5.4)
Slides for Chapter 11: Time and Global State
Slides for Chapter 14: Time and Global States
ITEC452 Distributed Computing Lecture 8 Distributed Snapshot
Distributed Snapshot.
Chap 5 Distributed Coordination
Jenhui Chen Office number:
CSE 486/586 Distributed Systems Consistency --- 2
CIS825 Lecture 5 1.
CSE 486/586 Distributed Systems Consistency --- 1
CSE 486/586 Distributed Systems Reliable Multicast --- 2
CSE 486/586 Distributed Systems Logical Time
Consistent cut If this is not true, then the cut is inconsistent
CSE 486/586 Distributed Systems Time and Synchronization
Slides for Chapter 14: Time and Global States
COT 5611 Operating Systems Design Principles Spring 2014
CSE 486/586 Distributed Systems Reliable Multicast --- 1
Distributed Snapshot.
Distributed Snapshots
Presentation transcript:

CSE 486/586 Distributed Systems Global States Steve Ko Computer Sciences and Engineering University at Buffalo

Last Time Ordering of events Logical time Many applications need it, e.g., collaborative editing, distributed storage, etc. Logical time Lamport clock: single counter Vector clock: one counter per process Happens-before relation shows causality of events Today: An important algorithm related to the discussion of time

Today’s Topic Global snapshots For distributed programming, it’s important to be able to reason about your system’s behavior in the abstract. Today’s topic will further increase your understanding.

Today’s Question Example question: who has the most friends on Facebook? Challenges to answering this question? It changes! What do we need? A snapshot of the social network graph at a particular time

Today’s Question Distributed debugging How do you debug this? Log in to one machine and see what happens Collect logs and see what happens Taking a global snapshot! P0 P1 P2 Both waiting… Deadlock!

What is a Snapshot? Single process snapshot Multi-process snapshot Just a snapshot of the local state, e.g., memory dump, stack trace, etc. For the sake of this lecture, let’s say a log of events. Multi-process snapshot Two things Process snapshots: Snapshots of all process states Network snapshot: All messages in the network

What Do We Want? A “cut” P1 P2 P3 Would you say this is a good snapshot? “Good”: we can explain all the causality, including messages No because e21 might have been caused by e31. Three things we want. Per-process state Messages that are causally related to each and every local snapshot and in flight All events that happened before each event in the snapshot

Obvious First Try Synchronize clocks of all processes Problems? Ask all processes to record their states at known time t Problems? Time synchronization possible only approximately Another issue? Does not record the state of messages in the channels Again: synchronization not required – causality is enough! What we need: logical global snapshot The state of each process Messages in transit in all communication channels P0 P1 P2 msg

How to Do It? Definitions P1 e21 P2 e22 e20 P3 e30 e31 e32 For a process Pi , where events ei0, ei1, … occur, history(Pi) = hi = <ei0, ei1, … > prefix history(Pik) = hik = <ei0, ei1, …,eik > Sik : Pi ’s state immediately after kth event For a set of processes P1 , …,Pi , …. : Global history: H = i (hi) Global state: S = i (Siki) A cut C  H = h1c1  h2c2  …  hncn The frontier of C = {eici, i = 1,2, … n}

Consistent States A cut C is consistent if and only if e  C (if f  e then f  C) A global state S is consistent if and only if it corresponds to a consistent cut e10 e11 e12 e13 P1 e21 P2 e22 e20 P3 e30 e31 e32 Inconsistent cut Consistent cut

Why Consistent States? #1: For each event, you can trace back the causality. #2: The state machine view of a distributed system The execution of a distributed system as a series of transitions between global states: S0  S1  S2  … …where each transition happens with one single action from a process (i.e., local process event, send, and receive) Each state (S0, S1, S2, …) is a consistent state.

CSE 486/586 Administrivia PA2-A deadline: This Friday PA1: Will start grading from today Please come and ask questions during office hours.

The Snapshot Algorithm: Assumptions There is a communication channel between each pair of processes (@each process: N-1 in and N-1 out) Communication channels are unidirectional and FIFO-ordered (important point) No failure, all messages arrive intact, exactly once Any process may initiate the snapshot Snapshot does not interfere with normal execution Each process is able to record its state and the state of its incoming channels (no central collection)

Single Process vs. Multiple Processes Single process snapshot Just a snapshot of the local state, e.g., memory dump, stack trace, etc. But for the sake of this lecture, let’s say a log of all events Multi-process snapshot Snapshots of all process states Network snapshot: All messages in the network Two questions: #1: When to take a local snapshot at each process so that the collection of them can form a consistent global state? (Process snapshot) #2: How to capture messages in flight? (Network snapshot)

Reminder: Clock-Sync’d Snapshot Instantaneous snapshot Process snapshots and network messages at time t We can’t quite do it due to (i) imperfect clock sync and (ii) no help from the network. P1 a b P2

Chandy and Lamport’s Snapshot: Basic Idea Goal: taking a consistent (not instantaneous) global snapshot Any process can initiate a snapshot-taking process by taking a local snapshot and sending a message called a marker. Upon receiving a marker, a process takes a local snapshot of its own. (The proc. snapshot part done) Still need to take a network snapshot. How do we take a network snapshot? Insight: messages in flight will eventually arrive. P1 b a M P2

Chandy and Lamport’s Snapshot: Basic Idea Each process that has taken a snapshot also starts recording incoming messages Since those messages were in the network when the snapshot was being taken. If every process does this, we will capture all messages in flight, recording messages destined to each process. Tricky part: the algorithm has a mechanism to stop recording incoming messages at some point. P1 b a M P2

Chandy and Lamport’s Snapshot: Basic Idea Reminder: which messages do we want to record? Messages that were in the network at the time of taking a snapshot How do we record just those messages? Insight: we can mark the end of relevant messages. After taking a local snapshot, each process sends a message saying that it’s done sending all messages relevant to the snapshot. In fact, we don’t need a different message type, we use the same marker message. P1 b M a M P2

Chandy and Lamport’s Snapshot Marker broadcast & recording The initiator broadcasts a “marker” message to everyone else If a process receives a marker for the first time, it takes a local snapshot, starts recording all incoming messages, and broadcasts a marker again to everyone else. A process stops recording for each channel, when it receives a marker for that channel. P1 M M M M a P2 M M b P3

The Snapshot Algorithm 1. Marker sending rule for initiator process P0 After P0 has recorded its own state for each outgoing channel C, send a marker message on C 2. Marker receiving rule for a process Pk on receipt of a marker over channel C if Pk has not yet recorded its own state record Pk’s own state record the state of C as “empty” for each outgoing channel C, send a marker on C turn on recording of messages over other incoming channels else record the state of C as all the messages received over C since Pk saved its own state; stop recording state of C

Exercise P1 P2 P3 e11,2 e14 e13 e10 e13 e21,2,3 e32,3,4 e24 e23 e20 M e11,2 1- P1 initiates snapshot: records its state (S1); sends Markers to P2 & P3; turns on recording for channels C21 and C31 e14 3- P1 receives Marker over C21, sets state(C21) = {a} e13 7- P1 receives Marker over C31, sets state(C31) = {} e10 e13 P1 e21,2,3 M 2- P2 receives Marker over C12, records its state (S2), sets state(C12) = {} sends Marker to P1 & P3; turns on recording for channel C32 e32,3,4 M 4- P3 receives Marker over C13, records its state (S3), sets state(C13) = {} sends Marker to P1 & P2; turns on recording for channel C23 e24 5- P2 receives Marker over C32, sets state(C32) = {b} a e23 P2 e20 b P3 e31 6- P3 receives Marker over C23, sets state(C23) = {} e30

One Provable Property The snapshot algorithm gives a consistent cut Meaning, Suppose ei is an event in Pi, and ej is an event in Pj If ei  ej, and ej is in the cut, then ei is also in the cut. Proof sketch: proof by contradiction Suppose ej is in the cut, but ei is not. Since ei  ej, there must be a sequence M of messages that leads to the relation. Since ei is not in the cut (our assumption), a marker should’ve been sent before ei, and also before all of M. Then Pj must’ve recorded a state before ej, meaning, ej is not in the cut. (Contradiction)

Summary Global states The “snapshot” algorithm A union of all process states Consistent global state vs. inconsistent global state The “snapshot” algorithm Take a snapshot of the local state Broadcast a “marker” msg to tell other processes to record Start recording all msgs coming in for each channel until receiving a “marker” Outcome: a consistent global state

Acknowledgements These slides contain material developed and copyrighted by Indranil Gupta at UIUC.