Skip to content

Instantly share code, notes, and snippets.

@suma
Created September 26, 2012 05:23
Show Gist options
  • Select an option

  • Save suma/3786262 to your computer and use it in GitHub Desktop.

Select an option

Save suma/3786262 to your computer and use it in GitHub Desktop.
Jubatus設定情報ををZKに置いたとき、同一インスタンスのサーバ間での一貫性保証手段について
【基本方針】
- standalone:設定は引数などで指定する(ファイルから?)
- 分散時(非standalone)
- set_config メソッド廃止し、代わりにZKに設定ファイルをおく
- サーバはZKから対応するインスタンスの設定ファイルをとってくる(またクラスタ、自動的に適宜 MIXを行う)
【問題: ZK上の設定が動的変更される可能性がある】
- 既にサーバが起動している状態で、ZK上の設定ファイルを変更し、新しくサーバを追加する
- 設定の異なるサーバが同じインスタンス上に存在してしまう → インスタンス全体で設定に不整合有り、MIXできない問題
【回避手段案 幾つか】
- ZKの設定変更を動的に行うインタフェース(ツール)を提供しない
- ZKのファイルを他ツールから操作が可能である(変更される可能性がある、変更・削除等が可能である)
- → 他のクラスタ管理情報にしても、人間が手動でZKのファイル削除等の、おかしな操作の実行は想定していない
- 問題 次が同時に発生しないように実装する:→ <インスタンス単位でZKのロックを取得すれば簡単に解決できそう>
- 1台目のサーバ「起動中(ZK設定取得済み)...まだZKのインスタンスのメンバ管理に追加されてない」
- 管理ツール「まだインスタンスのサーバががいないので、設定を更新しよう」
- 起動時に設定ファイルにZKでロック取る案
- → 一斉にサーバが起動したとき大丈夫か?
- MIX時にconfigのHash値等を用いて、異なる設定でのMIXを回避する
- インスタンス全体で設定の一貫性が取れていないことは解決できてない
【そもそも設定を動的更新したいとき】
- 設定情報の一括変更のトランザクションどう実現しようか問題
- 1インスタンスに複数の設定を保存する、もしくはインスタンスに関係なく設定を保存したくなる可能性(また、その設定をID等で指定するインタフェースも含めて)
- 設定のバージョン管理っぽいことが必要になるかも
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment