ZooKeeperのZAB（多数決）の仕組み

[pandazx]

書籍「Hadoop Hacks」のZooKeeperの章を読んで

ZABによる多数決の仕組みについて疑問が湧きましたので

質問させていただきます。

ZABがデータ同期を保証するために、二層コミットを使っており、

コミットの実行条件として、ZooKeeperサーバの多数決を取っている。

多数決が決まるには過半数の投票がないといけないので、

ZooKeeperサービスの稼働には過半数以上のサーバ数の稼働が必要という制限がある。

というのはわかりました。

Hadoop HacksのP.361 図68-1で「ACK総数 ＞ Lerner総数／２」とありますが、

文章では「Leaderは各Followerから返信されたACKパケットを確認し、

過半数（＞全Follower数／２）を超えているかを確認。」とあります。

最初、Lernerについて説明がないので、Followerの誤字と思われましたが、

以下の9ページ目にPaxosの二層コミットの仕組みが掲載されており、

「Learner」とあります（結局、誤字ではあるのですが）

http://www.slideshare.net/FlavioJunqueira/zab-dsn2011-8493524

9ページ目の図から、Learnerはデータを保存する役割のように考えられます。

そうすると、上記の「Lerner総数」はLeaderを含んだZooKeeperサーバ数と考えられます。

一方、ACKはFollowerから返ってきます。

上記の条件式ではLeaderがFollowerからZooKeeperサーバ数の

過半数のACKを受け取ればコミットできるということになります。

（３台構成で２台のFollowerからのACKが必要）

３台構成（Leaderが１台、Followerが２台）でFollowerが１台故障した場合、

「ACK総数＞Learner総数／２」の条件を満たせなくなるので、

ZooKeeperはサービスを提供できなくなるのではないか？という疑問が湧きました。

しかし、３台構成なら１台の故障を許容できるはずです。

コミット準備が完了したサーバ数という意味でLeaderを含めて

「ACK総数 + 1 > Learner総数」とすればFollowerが１台故障しても条件を満たせるので

Followerが１台故障しても、ZooKeeperがサービスを提供できることに納得できます。

このような理解で間違いないでしょうか。

長文となりましたが、よろしくお願い致します。

[飯田 慎司]

飯田と申します。

まず、ZooKeeperにおけるLearnerとは、FollowerとObserverを含めた呼び名となります。
分かり辛いですが、Hacks #70, p368の欄外に少々説明が載っています。
図中の"Lerner" はどちらにしろ誤字ですね。。

また、Clientに対してサービスを行っている全てのZooKeeperServerとして理解頂けると、
下記条件も何となくイメージして頂けるかと。。

> Hadoop HacksのP.361 図68-1で「ACK総数 ＞ Lerner総数／２」とありますが、

Leaderは常にACKを返しているのと同じ状態ですので、ご指摘の通り左辺に +1 で良いと思います。
図中の為、いろいろと省略し過ぎてしまったようです。申し訳ありません。

ZooKeeper-3.4.3のソースを確認したところ、現在では下記のようになっているようです。
(Leader + Follower 総数) / 2
# Observerは含まれないようです。
# ソース中ではparticipantと表記されています。
# participantはp.368に少々説明を載せています。

3台構成におきましては、Leader=1台とFollower=1台のみの構成になってしまっても
2台が共にACK(commit待ち)の状態であればサービスを提供することは十分可能です。
# ご認識の通りです。

ZooKeeper自体は単にアンサンブル内で協調して順に処理を行っているに過ぎませんので、
ACK応答が足らずに、サービスを提供できない状態になることは稀だと思います。
Hacks内では仮にNGと表記している箇所もありますが、ACK応答が足らずに
書き込みの処理が失敗する、サービスが落ちる、といった事は経験上まだありません。

以上です。



2012年8月19日 23:52 pandazx <pand...@gmail.com>:

[pandazx]

ご回答ありがとうございます。
仕組みが理解できました。