Transcript 6/9

クイズ


非同期システムにおいて，1プロセスがクラッシュ故
障する可能性がある場合，次のアルゴリズムで非ブ
ロッキング原子コミットが解けないことを示せ
アルゴリズム
 V(=Yes
or No)を高信頼ブロードキャスト
 全プロセスから値を受信した場合


すべてYesならコミットを決定
そうでなければアボートを決定
 全プロセスから受信する前に一定時間T経過した場合：

アボートを決定
3.5 プロセス多重化

プロセスを多重化し故障に対処する手法

Stateless Server
 状態を持たないサーバ（静的に与えられたデータ
の読み出しのみを実行）


多重化が容易
Stateful Server
 状態を持つサーバ

多重化には，複雑な機構が必要
多重化サーバ
op(arg)
Client
process pi
Invocation
ok(res)
Response
Nonreplicated server x
x
Replicated server x
Replica x1
Replica x2
Replica x3
例．FIFOキュー
enqueue(a)
Client
process pi
dequeue()
Invocation
ok(res)
Response
Replicated server x
Replica x1
Replica x2
Replica x3
Invocation
Client
process pj
enqueue(b)
dequeue()
Response
ok’(res’)
FIFO Queue
Service
Erroneous Execution
enqueue(a)
dequeue()
Client
process pi
ok(b)
Replica x1
Replica x2
ok(a)
ab
ba
Replica x3
ok(b)
Client
process pj
enqueue(b)
dequeue()
ok (a)
FIFO Queue
Service
多重化のアプローチ

3.5.1 能動的多重化 (Active replication)
 全Replicaが同じ処理を実行
P
p1
Q
p3
p2

3.5.3 受動的多重化 (Passive replication)
 1つのReplicaのみが処理を実行
P
p1
Q
Update
p2
Update
p3
3.5.1 能動的多重化
op(arg)
Client
process pi
Invocations
ok(res)
Responses
Replica x1
Replica x2
Replica x3

Atomicity (原子性)


Order (順序)


命令が実行されるなら，正常な全Replicaが実行
同じ順序で命令を処理
Determinism (決定性)
原子性，順序

満たされない場合
 状態の不整合が起こる
Client
process pi
Replica x1
Replica x2
Replica x3
Client
process pj
状態が
異なる
原子性，順序

正常なすべてのReplicaに，同じ順序でメッ
セージを配送する手段が必要
→ 原子ブロードキャスト
Client
process pi
Replica x1
Replica x2
Replica x3
Client
process pj
状態が
一致
決定性

決定性 Determinism
 初期状態と，それまでの処理の過程から一意に
結果が定まること
 各replicaの処理は決定的(deterministic)でなけ
ればならない


そうでなければ状態の一貫性が無くなる．
非決定性の要因
 例．マルチスレッド
多重化とグループ通信

グループ通信機能を下部に用いることで，容
易に多重化を実現
アプリケーション
受容 (deliver)
受信(receive)

グループ通信
原子ブロードキャスト等
送信
オペレーティングシステム
グループ通信システムの例
 ISIS,
Horus (Cornell University)
(多重化のための)グループ通信

順番を保つために，受信しても一旦bufferingするこ
とが必要
 受信 (receipt)
 ノードがメッセージを受け取ること
 受容 (delivery)
 プロセスがメッセージを渡すこと (受容，配送）
p1
Sender
Sender
B
A
p2
delivery A, B delivery A, B
receipt A, B
Network
receipt B, A
3.5.2 原子ブロードキャスト
プロセス={P1, P2, …}
 条件

 停止性:
正常なPiがabcast(m)したら，いずれPi
はdeliver(m)
 一律合意: あるPiがdeliver(m)したなら，正常など
のプロセスPjもdeliver(m)
 妥当性: deliver(m)したなら，abcast(m)済み
 全順序: Pi, Pjがdeliver(m)しており，Piがそれよ
り前にdeliver(m’)しているなら，Pjもそれ以前に，
deliver(m’)
コンセンサスを用いた原子ブロード
キャスト

受信したメッセージの集合を提案値として，定
期的にコンセンサス問題を解く
コンセサス
a
propose({b})
P1
decide({a,b})
{b}
propose({a,b})
P2
decide({a,b})
{a,b}
propose({a,b}) decide({a,b})
P3
{a,b}
b
3.5.3 受動的多重化

1つのReplicaのみが実際には処理を実行
 レプリカの動作は非決定的でもよい
Client
process pi
Invocation
Response
Server x
Primary replica x1
Update
Ack
Backup replica x2
Backup replica
x3
Update
Ack
主プロセスの故障1
op(arg)
Client
process pi
Invocation
Prim(x) = x1
Invocation
Prim(x) = x2
A
Primary replica x1
Backup replica x2
Ｗ
Update
Backup → Primary
Backup replica x3

新しい主プロセスを決定
主プロセスの故障2
op(arg)
Client
process pi
ok(res)
Invocation
with invID
Invocation
with invID
Response
B
Primary replica x1
Backup replica
x2
Update
Backup replica x3


Updateを受信したBackupと受信していない
Backupが存在→ Replicaの状態の不一致
グループ通信機能が必要
3.7 分散チェックポインティング

チェックポインティングとロールバックリカバリ
（2.2.2）
 定期的に状態を信頼できる記憶装置に保存し，
故障の際にその情報を利用して以前の正常な状
態に回復する手法

単一プロセスなら実現は容易
Rollback
time
Process
Checkpoint
Checkpoint
分散システムにおけるチェックポイン
ティング

分散システムでは通信を考慮する必要がある
P1
P2
m1
m2
P3

Inconsistentな（整合性のない）状態
 孤児メッセージ(Orphan

message)の存在
送信していないのに受信されたメッセージ
分散システムにおけるチェックポイン
ティング

In-transit message
 送信したが受信されていないメッセージ
P1
P2
P3

m1
m2
Consistentな（整合性のある）状態


実際に起こりうる状態
In-transit messageは，通常のメッセージ喪失と同様に，通信プロトコ
ルにより対処できる
ドミノ効果 (Domino Effect)
c1,1
P1
P2
P3
c1,2
c2,1
c3,1
c1,3
c2,2
c3,2
c2,3
c3,3
c2,4
c3,4
Recovery line

回復線 (Recovery Line)
 孤児メッセージを含まないチェックポイントの集合

ドミノ効果
 リカバリラインがドミノ倒しのように後退してしまう現象

ドミノ効果を起こさないようなCheckpointの取り方が
必要
分散チェックポインティングの種類

非連携 Uncoordinated
 各プロセスが非同期的にチェックポイントを取得
 ドミノ効果の危険

連携 Coordinated
 プロセスが協調してチェックポイントを取得
 ドミノ効果を防止

通信誘導 Communication-Induced
 メッセージのやり取りのパターンを基づいて，ドミノ効果が
起こらないようにチェックポイントを取得
連携チェックポインティング
時間同期を利用したアルゴリズム


同期のとれたクロックを使用
| Ci(t) - Cj(t) |  e
一定時間p毎にチェックポイントを取得
Orphan Messageが起こるシナリオ
e
p
P1
P2
p
連携チェックポインティング
時間同期を利用したアルゴリズム

チェックポイント後，時間e 経過するまで送信をしな
い
T
e
T+e
P1
P2
T
通信誘導チェックポインティング


メッセージのやり取りのパターンを基づいて，無用
(Useless)チェックポイント が発生しないようにチェッ
クポイントを取得
無用チェックポイント
 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
Z-Paths, Z-Cycles
Z-Path
m1, …, mn はCi,xからＣj,yへのZ-Path

 m1はCi,x
以降に送信（プロセスPi）
 l = 1, …, n-1:

mlの受信と，ml+1の送信について，直前のチェックポイントが同じ
 mnをＣj,y 以前に受信
c1,1
P1
c2,1
（プロセスPj）
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
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
P3
c3,2 m3
m5
c3,3
c2,4
m6
c3,4
通信誘導チェックポインティングの例
Z-Cycleを作らないようにする．
 例．論理時計の利用
 チェックポイントを取得したら
lc := lc+1
 送信メッセージmにはlcを時刻印として添付(tc(m))
 メッセージmを受信した際,tc(m) >lcならlc:= tc(m)

Idea
 Z-Pathの時刻印が単調増加ならZ-Cycleにはならない
P1
P2
P3
2
1
1
2
2
m1
4
3
3
m2
m3
m4
m5
4
4
m6
5
通信誘導チェックポインティングの例

Idea
 Z-Pathの時刻印が単調増加ならZ-Cycleにはならない

方法
 受け取ったメッセージ(m2)より小さい時刻印のメッセージ
(m1)を送信していたら，m2を受容する前にチェックポイント
を取る
P1
m2
P2
P3
P1
m2
P2
m1
ts(m1) ≥ ts(m2)
P3
m1
ts(m1) < ts(m2)
通信誘導チェックポインティングの例

Idea
 Z-Pathの時刻印が単調増加ならZ-Cycleにはならない

方法
 受け取ったメッセージより小さい時刻印のメッセージを送信
していたら，deliverする前にチェックポイントを取る
P1
P2
P3
2
1
1
2
2
m1
4 5
3
3
m2
m3
m4
m5
4
4
m6