現在進行形で色々試している途中ではありますが、とりあえず、検索システムを利用頻度の高いアプリでの検索に利用したいということで、１台構成では心細いので複数台のクラスタ構成にします。
ElasticSearchのクラスタ構成はググってもらえれば分かると思うのですが、普通に使う分にはめちゃくちゃ簡単です。たぶん、色々コツはあるのでしょうが、それは運用しながら経験していくということでここでは凄くシンプルに構成してみます。
まずは設定ファイルを見てみると
################################### Cluster ###################################
# Cluster name identifies your cluster for auto-discovery. If you're running
# multiple clusters on the same network, make sure you're using unique names.
#
#cluster.name: elasticsearch
#################################### Node #####################################
# Node names are generated dynamically on startup, so you're relieved
# from configuring them manually. You can tie this node to a specific name:
#
#node.name: "Franz Kafka"
# Every node can be configured to allow or deny being eligible as the master,
# and to allow or deny to store the data.
#
# Allow this node to be eligible as a master node (enabled by default):
#
#node.master: true
#
# Allow this node to store data (enabled by default):
#
#node.data: true
# You can exploit these settings to design advanced cluster topologies.
#
# 1. You want this node to never become a master node, only to hold data.
# This will be the "workhorse" of your cluster.
#
#node.master: false
#node.data: true
#
# 2. You want this node to only serve as a master: to not store any data and
# to have free resources. This will be the "coordinator" of your cluster.
#
#node.master: true
#node.data: false
#
# 3. You want this node to be neither master nor data node, but
# to act as a "search load balancer" (fetching data from nodes,
# aggregating results, etc.)
#
#node.master: false
#node.data: false
# Use the Cluster Health API [http://localhost:9200/_cluster/health], the
# Node Info API [http://localhost:9200/_nodes] or GUI tools
# such as <http://www.elasticsearch.org/overview/marvel/>,
# <http://github.com/karmi/elasticsearch-paramedic>,
# <http://github.com/lukas-vlcek/bigdesk> and
# <http://mobz.github.com/elasticsearch-head> to inspect the cluster state.
# A node can have generic attributes associated with it, which can later be used
# for customized shard allocation filtering, or allocation awareness. An attribute
# is a simple key value pair, similar to node.key: value, here is an example:
#
#node.rack: rack314
# By default, multiple nodes are allowed to start from the same installation location
# to disable it, set the following:
#node.max_local_storage_nodes: 1
とあります。Cluster設定そのものに関しては、英語を見てみれば何となく分かるとおり、ElasticSearchはcluster名で勝手にclusterしてくれます。
なので、最低限はクラスタ名をあわせればいい訳です。
あとは、cluster化された自分のnodeがどう動くかの設定になるわけです。
まずはnode.name。これは分かりやすい名前にしましょう。
んで、どう動くかを設定するのが
node.master = true or false
node.data = true or false
上記の設定の組み合わせ（４通り）になるわけです。
masterはマスタになるかならないか？
dataはデータを持つか持たないか？
node.master = true
node.data = true
だと、マスタにもなるし、データも持つ。普通に使う分にはこれが楽。
node.master = true
node.data = false
だとデータは持たないマスタだけということで、Elasticsearchではcoordinatorと呼んでいる。
node.master = false
node.data = true
だとデータだけを持つ。
node.master = false
node.data = false
だと、elasticsearchではロードバランサーとしてのみ作用するとのこと。
私のケースでは両方ともtrueの３台構成でのクラスタ化した。
構成したサーバどこでもいいので、以下の構成を確かかめる。
curl -XGET http://localhost:9200/_cluster/state?pretty
{
"cluster_name" : "*****-search",
"version" : 7,
"master_node" : "EKEbvVZrRDCRCcimEsKdKg",
"blocks" : { },
"nodes" : {
"EKEbvVZrRDCRCcimEsKdKg" : {
"name" : "*****-*****",
"transport_address" : "inet[/***.***.***.***:9300]",
"attributes" : { }
},
"ZCGmnee6QuC4Mrxb19NzGg" : {
"name" : "*****-*****",
"transport_address" : "inet[/***.***.***.***:9300]",
"attributes" : { }
},
"nX0umaReSDK57okDmTu-hA" : {
"name" : "*****-*****",
"transport_address" : "inet[/***.***.***.***:9300]",
"attributes" : { }
}
},
"metadata" : {
"indices" : { }
},
"routing_table" : {
"indices" : { }
},
"routing_nodes" : {
"unassigned" : [ ],
"nodes" : {
"EKEbvVZrRDCRCcimEsKdKg" : [ ],
"ZCGmnee6QuC4Mrxb19NzGg" : [ ],
"nX0umaReSDK57okDmTu-hA" : [ ]
}
},
"allocations" : [ ]
}
と３台構成を確認できました。
さて、次に気になるのは、色々苦労して今の形になったテンプレート構成。
これ３台全部に適用する必要があるのか？？？と疑いつつ。Elasticsearchはデータを分散して持つわけだから一つの適用が全体に適用されるのでは？とも思いつつ試してみたら。。。。見事に全てに適用されました。
これは、操作間違えたらコエェーーとか思いつつも、面倒な作業から開放されて良かったともおもったり。
もちろんデータの同期も問題なし。
後はクラスタのヘルスチェックですがこちらは以前書いた気がしなくもないelastic-HQのPlugInを入れてみようかなと。
もし自力でやるならば以下の２点を最低限見る必要があるかなと思っています。
クラスタのヘルスチェック
curl -XGET 'http://localhost:9200/_cluster/health?pretty=true'
クラスタのステータス監視
curl -XGET 'http://localhost:9200/_cluster/stats?pretty=true'
クラスタのノードのステータス監視
curl -X GET http://localhost:9200/_nodes/stats?pretty
このアタリをheartbeatして、おかしいところがあったらAlertするところから始める感じなのでしょうか。
次回は、一つVIP作ってもらって、そこからとりあえずラウンドロビンでいいので分散処理してくれればそのログなどをあさってみたいと思います。