e - Department of Computer Engineering

Fault-Tolerant
Computing Systems
#8 Distributed Systems
Pattara Leelaprute
Computer Engineering Department
Kasetsart University
[email protected]
1
Basic Concepts of Distributed Systems

Distributed Systems (分散システム)
 Networkを通して通信可能な複数のノードから構
成
 以下のものを持たない
Shared memory
 Clock

2
System Model (at the logical level
of applications)

Model


複数のプロセス(process)から構成される．
各プロセスはメッセージ通信によって情報を送受できる






どのプロセスとも通信可
各Channel は FIFO
各プロセスは共通のクロックを持たない．
各プロセスの処理の速度は可変である．
メッセージの遅延の大きさは可変である．
分散システムに特有の様々な問題が生じる．
3
Fault Model

Crash Fault
故障したプロセスは停止
 aka Fail-stop fault


Byzantine Fault
 任意の動作
Crash
Faults
Byzantine Faults
4
7.2 Ordering of Events and Logical
Clocks

Event(イベント)のOrdering(順序付け)
 必要性

例．複数のプロセスが協調して同じ順番で要求を処理
する必要がある場合 (Ricart-Agrawala mutual
exclusion algorithmなど)
 困難さ
共通のClockがない
 メッセージ遅延，プロセス実行速度が可変

5
Partial Ordering of Events

Happened before relation (→で表記)
 同一プロセス上での生起順と，メッセージの送受から規定
される，分散システム上のevent間での因果関係
 Irreflexive partial order relation (非反射的半順序関係)


(a, a)  R が成り立たない (irreflexivity, 非反射律)
(a, b)  R, (b, c)  R  (a, c)  R (transitivity, 推移律)
 Partial order relation (半順序関係)
 Relation (関係) ・・・要素のtuple(組)の集合
 Partial order relation (半順序関係)



(a, a)  R (reflexivity, 反射律)
(a, b)  R, (b, a)  R  a = b (antisymmetry 反対称律)
(a, b)  R, (b, c)  R  (a, c)  R (transitivity, 推移律)
6
Partial Ordering of Events

Happened before relation (→で表記)

1~3を満たす最小の関係
1.
2.
3.
同じプロセスでaがbより先に起こったならa→b
同じメッセージについてaが送信，bが受信ならa→b
a→bかつb→cならばa→c
注． Reflexiveではない
P1
P2
e11
e21
e12
e22
e23
e11 → e12
e21 → e22
e21 → e23
e22 → e23
e11 → e22
e21 → e12
e11 → e23
7
Partial Ordering of Events

Happened before relation (→で表記)

Concurrent (並行)


a→bもb→a も成り立たない（例．e11 と e21 ）
Causality

a→bなら，a causally affects b.
P1
P2
e11
e21
e12
e22
e23
e11 → e12
e21 → e22
e21 → e23
e22 → e23
e11 → e22
e21 → e12
e11 → e23
8
Logical Clocks

Logical Clock (論理時計)
 整数Ci：各プロセスPiのevent
aのlogical clock値
 Happen-before relation に矛盾しない時間

a,b, a→b ならば Ci(a) < Cj(b)
P1
e11
e12 e13 e14
(1)
(2)
(3)
(4)
e15 e16
(5) (6)
e17
(7)
Clock
values
P2
(1)
(2)
(3)
e21
e22
e23
(4)
e24
(7)
e25
9
Logical Clocks

ルール
同じプロセスでa，bが連続して起こったら
Ci(b) := Ci(a) + 1
2. メッセージには送信イベントの時刻をtimestamp (時刻印)
tmとして付加．受信イベントaは
Ci(a) := max(Ci(a), tm + 1)
 a,b, a→b ならば Ci(a) < Cj(b) !?
e11
e12 e13 e14 e15 e16
e17
P1
1.
(1)
(1)
(2)
(5) (6)
tm=6
tm=2
tm=4
(3)
(4)
e21
e22
e23
Clock
values
P2
(2)
(3)
tm=2
(4)
e24
(7)
(7)
e25
10
Total Ordering

同じLogical Clock値を持つイベントの解消
 Total

(a, a)  R (reflexivity, 反射律)
(a, b)  R, (b, a)  R  a = b (antisymmetry 反対称律)
(a, b)  R, (b, c)  R  (a, c)  R (transitivity, 推移律)

a,b, (a, b)  Rまたは (b, a)  R (totalness, 完全律)



order relation (全順序関係)
Logical Clock + プロセスID (Pi)
P1
Clock
values
P2
e11
e12 e13 e14
(1)
(1.1)
(2) (3) (4)
(2.1) (3.1) (4.1)
(1.2)
(1)
(2.2)
(2)
e21
e22
e15 e16
(3.2)
(3)
e23
(5) (6)
(6.1)
(5.1)
(4.2)
(4)
e24
e17
(7)
(7.1)
(7.2)
(7)
e25
11
7.3 Clock Synchronization

プロセスの持つ``physical’’ clockの値を一定の誤差の範囲
に保つこと
Hardware clock : H1
P1 00:00:00
P2

H2
00:00:00
10:00:00
Clock: C1 := H1 +CORR1
10:00:25
C2 := H2 +CORR2
| Ci(t) - Cj(t) |  b を満たすように，メッセージを交換して，
CORRiを計算

Ci(t) :時刻（real-time）tにおけるPiのクロック
12
Clock Synchronization

考慮すべき要素
Clockの故障
2. Clockのスピードの差
3. メッセージ遅延
1.
A
1:00
B
1:00
1:05
1:10
A
1:10
1:05
(a) 正常
C
1:00
B
1:00
2:55
1:10
1:15
1:10
C
(b) BがByzantine 故障
(“Dual-faced”)
13
Clock Synchronization

考慮すべき要素
Clockの故障
2. Clockのスピードの差
3. メッセージ遅延
1.
Hi(t): 時刻（real-time）tにおけるPiのHardware Clock
r
仮定： dH (t)
Hi(t)
i
dt
-1<r
通常定数ρは10-5程度
r
1-r
t
14
Fault-Tolerant Clock
Synchronization Algorithm
例．Lundelius-Welch and Lynch, 1988
 間隔DT毎にメッセージ交換を行いクロック値
を調整

DT
P1
t
[(1-r)DT, (1+r)DT]
P2
15
Lundelius-Welch – Lynch Algorithm
1.
Clockの故障
nをプロセス数, fを耐えられる故障の数とした時
3f+1n
3.
メッセージ遅延
時間の範囲[-, +]内に収まると仮定
P1
t
P2
0
  
16
Lundelius-Welch – Lynch Algorithm


DT毎，各プロセスは全プロセスにメッセージを送信
送信から時間(1 + r)(b + +)が経つまで他のプロセスのメッ
セージを受信し，受信時間を記録


own
clock
realtime
b ：前回の同期で保障されているズレの上限
 + ：メッセージ遅延の最大値
(1 + r)(b + +)
DT
P1
[(1-r)DT, (1+r)DT]
A2
A5
A3
≥ b + +
P2
17
Lundelius-Welch – Lynch Algorithm
DT
P1
[(1-r)DT, (1+r)DT]
T
A2
(1 + r)(b + +)
A5
A3
≥
b + +
AV := メッセージ到着時刻A2 A3 ・・・の大きい方と小さい方から
f 個の値を除いた残りの値の中間点
T AV A A A A
A
A A
f=2
CORR := CORR + (T +  – AV)
| Ci(t) - Cj(t) |  b  4+ 4rDT
f=2
18
19
Chapter 8. Checkpointing and RollBack Recovery
定期的に状態を信頼できる記憶装置に保存
し，故障の際にその情報を利用して以前の正
常な状態に回復する手法
 単一プロセスなら実現は容易

Rollback
time
Process
Checkpoint
Checkpoint
20
Roll-Back Recovery in MessagePassing Systems

分散システムでは通信を考慮する必要がある
P1
P2
m1
m2
P3

Inconsistentな（整合性のない）状態
 Orphan

messageの存在
送信していないのに受信されたメッセージ
21
Roll-Back Recovery in MessagePassing Systems

In-transit message
 送信したが受信されていないメッセージ
P1
P2
P3

m1
m2
Consistentな（整合性のある）状態


実際に起こりうる状態
In-transit messageは，通常のmessage lossと同様に，通信プロトコ
ル(communication protocol)により対処できる
22
Rollback and Domino Effect
c1,1
P1
P2
P3
c1,2
c2,1
c3,1
c1,3
c2,2
c3,2
c2,3
c2,4
c3,3
c3,4
Recovery line

Recovery Line (リカバリライン)
 Orphan

Messageを含まないチェックポイントの集合
Domino Effect (ドミノ効果)
 リカバリラインがドミノ倒しのように後退してしまう現象

ドミノ効果を起こさないようなCheckpointの取り方が
必要
23
Checkpointing

Uncoordinated (非連携) Checkpointing
 各プロセスが非同期的にチェックポイントを取得
 Domino

Effectの危険
Coordinated (連携) Checkpointing
 プロセスが協調してチェックポイントを取得
 Domino

Effectを防止
Communication-Induced Checkpointing
 メッセージのやり取りのパターンを基づいて，Domino
Effectが起こらないようにチェックポイントを取得
24
Two-Phase Checkpointing Scheme

Initiator Q
1.
2.

tentative checkpointを取得し，他のプロセスに通知．
他のプロセスがtentative checkpointを取得したことを
確認したら， tentative checkpoint を permanent
checkpoint とする．
Phase 2が完了するまで，通信は停止する．
Q
P1
No Orphan Message
P2
25
Two-Phase Checkpointing Scheme

Initiator Q以外
1.
2.

Qのメッセージを受信したら，tentative checkpointを取得
し，Qに通知．
Qから再度メッセージを受信したら，tentative checkpoint
を permanent checkpoint とし，Qに通知．
Phase 2が完了するまで，送信は停止する．
Q
P1
No Orphan Message
P2
26
Checkpointing using Synchronized
Clocks


同期のとれたクロックを使用
| Ci(t) - Cj(t) |  b
一定時間p毎にチェックポイントを取得
Orphan Messageが起こるシナリオ
b
p
P1
p
P2
27
Preventing Orphan Messages

チェックポイント後，時間β経過するまで送信をしな
い
kp
b
kp + b
P1
P2
28
Communication-Induced
Checkpointing (CIC)


メッセージのやり取りのパターンを基づいて，
Useless Checkpointが発生しないようにチェックポ
イントを取得
Useless Checkpoint
 Recoveryに利用できないチェックポイント
c1,1
P1
c2,1
c1,2
c1,3
c2,2
m2
m4
c2,3
P2
c3,1 m1
P3
(例．C3,3)
c3,2 m3
m5
c3,3
c2,4
m6
c3,4
29
Z-Paths, Z-Cycles
Z-Path
m0, m1, …, mn はCi,xからＣj,yへのZ-Path



Ci,x → sendi(m0) (→: happened-before relation)
l = 0, …, n-1:



deliverk(ml)とsendk(ml+1)が同じCheckpoint Interval，または
deliverk(ml) → sendk(ml+1)
deliverk(mn) →Ｃj,y (deliver: 受信したメッセージを実際に使うこと)
c1,1
P1
c2,1
c1,2
c1,3
c2,2
m2
m4
c2,3
P2
c3,1 m1
P3
c3,2 m3
m5
c3,3
c2,4
m6
c3,4
30
Z-Paths, Z-Cycles

Z-Cycle
 一つのチェックポイントに対するZ-Path
 Useless
Checkpointの必要充分条件
c1,1
P1
c2,1
c1,2
c1,3
c2,2
m2
m4
c2,3
P2
c3,1 m1
c3,2 m3
m5
c3,3
c2,4
m6
c3,4
P3
31
CIC Scheme
Z-Cycleを作らないようにする．
 例．Logical Clockの利用
 チェックポイントを取得したら
lc := lc+1
 送信メッセージmにはlcをtimestampとして添付(tc(m))
 メッセージmを受信した際,tc(m) >lcならlc:= tc(m)

Idea
 Z-Pathのtimestampが単調増加ならZ-Cycleにはならない
P1
P2
P3
2
1
1
2
2
m1
4
3
3
m2
m3
m4
m5
5
4
4
m6
32
A CIC Scheme

Idea
 Z-Pathのtimestampが単調増加ならZ-Cycleにはならない

方法
 受け取ったメッセージ(m2)より小さいtimestampのメッセー
ジ(m1)を送信していたら，m2をdeliverする前にチェックポイ
ントを取る
P1
m2
P2
P3
P1
m2
P2
m1
m2
ts(m2) ≤ ts(m1)
P3
m1
ts(m2) > ts(m1)
33
A CIC Scheme

Idea
 Z-Pathのtimestampが単調増加ならZ-Cycleにはならない

方法
 受け取ったメッセージより小さいtimestampのメッセージを
送信していたら，deliverする前にチェックポイントを取る
P1
P2
P3
2
1
1
2
2
m1
4 5
3
3
m2
m3
m4
m5
4
4
m6
34

Download Report