catalog.json作成手順

実現したいクラスタ構成

考え方

worker用ノードは、検索の速度と堅牢性の両方をなるべく高いレベルで実現したい。 そのため、RAID 1+0と同様の構成を取る事が望ましい。

以上を踏まえ、初期状態ではworker用に以下の4ノードを用意する。

• 192.168.X.11
• 192.168.X.12（11のreplica）
• 192.168.X.21
• 192.168.X.22（21のreplica）

A案

+------------------+ +------------------+    +--------------------+
|192.168.X.11      | |192.168.X.12      | ← |LVS                 |
|[D.E. id:0〜99]   | |[D.E. id:0〜99]   |    |・各ノードの死活監視|
|[P.A.]            | |[P.A.]            |    |・リクエストを      |
+------------------+ +------------------+    |  各ノードに振り分け|
+------------------+ +------------------+    +--------------------+
|192.168.X.21      | |192.168.X.22      |
|[D.E. id:100〜199]| |[D.E. id:100〜199]| → Webアプリサーバへ直接レスポンス
|[P.A.]            | |[P.A.]            |
+------------------+ +------------------+
...

B案

+------------------+    +-------------------------+    +----------+
|192.168.X.11      | ← |192.168.X.101[D.E.][P.A.]| ← |LVS       |
|[D.E. id:0〜99]   | → |・masterプロセスとして   |    |・死活監視|
+------------------+    |  リクエストを           |    +----------+
+------------------+    |  各ノードに振り分け     |
|192.168.X.12      |    +-------------------------+
|[D.E. id:0〜99]   |    +-------------------------+
+------------------+ ← |192.168.X.102[D.E.][P.A.]| → Webアプリサーバへ
+------------------+ → +-------------------------+
|192.168.X.21      |    ...
|[D.E. id:100〜199]|
+------------------+
+------------------+
|192.168.X.22      |
|[D.E. id:100〜199]|
+------------------+
...

C案

+------------------+    +-------------+    +----------+
|192.168.X.11      | ← |192.168.X.101| ← |LVS       |
|[D.E. id:0〜99]   | → |[D.E.][P.A.] |    |・死活監視|
+------------------+    |[Webアプリ]  |    +----------+
+------------------+    +-------------+
|192.168.X.12      |    +-------------+
|[D.E. id:0〜99]   | ← |192.168.X.102| → クライアントへ
+------------------+ → |[D.E.][P.A.] |
+------------------+    |[Webアプリ]  |
|192.168.X.21      |    +-------------+
|[D.E. id:100〜199]|    ...
+------------------+
+------------------+
|192.168.X.22      |
|[D.E. id:100〜199]|
+------------------+
...

実際のcatalog.json

A〜Cいずれのパターンも、workerとなるノードの構成は同じである。 また、B案とC案でmasterプロセス専用となるノードはsingle volumeの割り当て先ではないため、catalog.json上には名前が出てこない。

よって、catalog.jsonは全パターン共通で以下の形となる。

{
  "version": 2,
  "effectiveDate": "2013-09-01T00:00:00Z",
  "datasets": {
    "Wikipedia": {
      "nWorkers": 4,
      "plugins": ["groonga", "crud", "search"],
      "schema": {...},
      "replicas": [
        {
          "dimension": "id",
          "slicer": "???", ← ordinal-scaled型で整数を引数に取るスライサー名。どんな名前かは未定。
          "boundary": "???", ← 整数の範囲か閾値。どんな形式かは未定。
          "slices": [
            {
              "replicas": [
                {
                  "volume": {
                    "address": "192.168.X.11:24224/wikipedia.011"
                  }
                },
                {
                  "volume": {
                    "address": "192.168.X.12:24224/wikipedia.012"
                  }
                }
              ]
            },
            {
              "replicas": [
                {
                  "volume": {
                    "address": "192.168.X.21:24224/wikipedia.021"
                  }
                },
                {
                  "volume": {
                    "address": "192.168.X.22:24224/wikipedia.022"
                  }
                }
              ]
            }
          ]
        }
      ]
    }
  }
}

自動化の指針

• RAID 1+0同様の構成を基本と考える。
• 自動化を簡単にするため、基本的には、replicaの数は各sliceで同じになるようにする。 （柔軟に変えたい場合は後で自分で変える。これはあくまで初期状態の作成処理の自動化について。）
• 以下のパラメータを受け付ける。
  • effectiveDate
  • datasetの定義
    • dataset名（tag名はdataset名のlower caseにする）
    • slicer関数名
    • dimension
    • boundary
    • そのdatasetに入れるテーブルの定義（schema）
    • sliceの数
    • replicaの数
    • fluentd ポート番号
• ホスト名部分は、プレースホルダのみ設定して出力してあとからユーザが自分で書き換える形か、もしくはウィザードで指定する必要がありそう。

Chef cookbookを使うのであれば、上記のパラメータを受け付けるようにする必要がある。