- Apache Hadoopプロジェクトの1つ
- GoogleのChubbyに関する論文がベース
- 分散ロックサービス以上のもの
- 高可用性の分散メタデータファイルシステム実装と考えたほうがよい
- ツリーベースのファイルシステムAPI
- クライアントはノードを作れる
- ノードには1MBまでのデータを格納できる
- 複数の子ノードを関連付けられる
- 無い機能
- ノードのリネームはない
- ソフトまたはハードリンクはない
- 追記のセマンティクスはない
- 機能を削ることで完全に順序付けられた更新、データバージョニング、条件付きの更新（CAS）などが実現された
- ephemeral nodesやgenerated names、async notification("watch") APIのどの先進的機能も実現された
- 機能はリモートサービスとして公開される
- ネットワーク越しのクライアントがノード追加、CAS、非同期の通知などを利用できる
- クライアントは衝突することの無いノード名の生成をZookeeperにリクエストできる
- クライアントがZookeeperに接続している間だけ存在するノードはephemeral nodesとして作成できる
- ephemeral nodesはプレゼンス情報を提供する
- 分散アーキテクチャ
- Chubby
- 可用性を実現するために最低5台のマシンで稼働する
- 透過的なビルトインのマスター選出とファイルオーバー機構を備える
- Zookeeperも同じモデル
- Zookeeperサーバーのクラスタ
- 1つが、すべての書き込みを（定数割り当てによって）調停・受理するリーダーとなる
- 他のサーバーはマスターのリードオンリーレプリカ
- マスターがダウンするとどれか他のサーバーが代理となって直ちにリクエストの処理を続行する
- スタンバイサーバーが読み込みを処理することができる * Chubbyではすべての読み書きが単一のマスターのみだった
- 制限 * クラスタ内のすべてのノードが正確なレプリカであり、シャーディングがないため、サービスのキャパシティは単一のマシンのサイズに左右される
- Hadoop/HBaseではZookeeperがマスター選出と他プロセスのメタデータ格納に使われる
- ZookeeperがSPOFだと言われるが、実際は背後のアーキテクチャを考慮するとこれは大げさに表現されすぎている
- Googleの論文によると、Chubbyは事実上Googleインフラ内のDNSを置き換えてしまったことになる
- データベースクラスタが設定情報を共有する場合
- 設定情報
- シャーディング情報
- システム設定
- など
- 1つのネームスペースに格納（"/app/database/config"）
- 各データベースがこのノードをウォッチできる
- 誰かがデータを更新するとリアルタイムに通知を受けられる
- 新しいデータベースがクラスタに追加されたことによるデータの再バランシングが発生した場合など
- ephemeral nodesは基本的なプレゼンス情報を提供する
- 各ワーカーマシンをZookeeperに登録することでリアルタイムのグループメンバーシップクエリが実現できる * どのノードがオンラインかを知ることができる * 各ノードが何をしているかも知ることができる
- コンセンサス
- データバージョンニングと通知API * ワーカーキューとバリアのような分散プリミティブを構築できる
- ロックとコンセンサスを得ることで事実上どんな分散問題にも取り組める * マスター選出 * quorum commits * など
- Zookeeperを試す
- ソースコードをダウンロードする
- jarファイルをロードする
- シングルノードモードの実行準備は完了
- シェルを通じて操作できる
world read-writeパーミッションでルートノードを作成する。
create /myapp description world:anyone:cdrw
Created /myapp
シーケンシャル(-s)でephemeral(-e)なノードを作成する。
create -s -e /myapp/server- appserver world:anyone:cdrw
Created /myapp/server-0000000001
現在のノードを一覧する。
ls /myapp
=> [server-0000000001]
1つのノードのデータを取得する。
get /myapp/server-0000000001
appserver