ElasticSearchの運用とか (2)
割と遊びのつもりで書き始めたら意外と注目が集まってしまって遊びじゃない感じになってきましたが、前回の続きでelasticsearchの運用情報を書いていきます。
@johtani さんにTwitterでElasticSearchのアップグレード情報などを色々と教えていただいたので、また後日検証してまとめてみようと思います。ありがとうございました。
今回は設定周りの情報になります。
そういえば後から見直すことを考えるとどの投稿にどういう情報が乗っているか探すのが大変になりそうだから、索引を作る必要がある気がする。そのうち考えるかも。
JVMのバージョンについて
java7を使う場合、特定のバージョンでindexが壊れる問題がLuceneで発生するので避ける必要がある。
Apache Lucene - Welcome to Apache Lucene
具体的にはjava7u25以下またはjava7u60以上java7u55以上を使う必要があるみたい。該当のバージョンの使用は避けること。Debianのaptで入れた場合は、java7u25が入るので大丈夫だけど注意する。
追記: 当初u60以降で直るという話でしたが、java7u55で直ったとの情報を @johtani さんよりいただきました。ありがとうございます。
設定
debパッケージでインストールした場合、/etc/elasticsearch/elasticsearch.yml
がデフォルトの設定ファイルになっている。
このファイルで設定した値は起動時に読み込まれるが、多くの設定はここに設定しなくてもAPI経由でDynamicに設定できる。
設定項目
特に重要そうなものを記載。
elasticsearch.yml
は環境変数を参照する形なので、必要に応じて/etc/init.d/elasticsearch
で設定する必要がある。
Node
Elasticsearchのnodeはデータを持ったり持たなかったりする。 node.dataがfalseだとnodeはデータを保持しない。 データを保持しないノードはLoadBlancerとして機能する。
設定例
node.master: true node.data: true
データノードとしてもmasterノードとしても機能する。簡単に構築でき動作を確認できるので開発時に便利。
node.master: false node.data: true
masterノードにはならない。workhorse
と呼ばれる。
node.master: true node.data: false
masterノードにはなるが、データは保持しない。coordinator
と呼ばれる。
node.master: false node.data: false
masterノードにもならず、データも保持しない。検索用のLoadBlancerとして機能する。
メモリ
(これはelasticsearchに限ったことではないけれども) ElasticSearchはスワップすると極端にレスポンスが悪くなるので、スワップしないよう十分なメモリを確保する必要がある。
公式でも推奨されている設定は、「起動時にメモリをアロケートし、スワップしないようにする」。
/etc/init.d/elasticsearch
でES_HEAP_SIZE
を明示的に指定し、
elasticsearch.yml
にbootstrap.mlockall: true
を記述する。
JVM起動時にメモリを確保するようになり、JVMのヒープサイズもここで指定したサイズに固定される。 メモリが不足する場合、エラーを出して落ちるようになる。ヒープのサイズはドキュメントの2倍程度がよいとか聞いた気もするけど、どこに書いてあるんだろ。デフォルトは1gbなので、必要に応じて大きくする。
ファイルディスクリプタ
ElasticSearchが開けるファイルの数は、32kまたは64kを公式では推奨している。
この値は/etc/init.d/elasticsearch
のMAX_OPEN_FILES
で変更可能だが、デフォルトで65535
なので変更する必要は無い気がする。
この変数に値が設定されていると、ulimit -n
によって値が書き換えられる。
mlockall:true
に設定して"Unknown mlockall error 0"
が発生する場合には、unlimitedにすることで回避できる。
クラスタリング
ElasticSearchはクラスタでの利用前提のシステムなので、同じように設定すればどのホストに問い合わせても同じように機能するように設計されている。(一応Master Nodeというのはある)
検索が重くならないように、検索用ノードとインデックス生成用ノードを分ける運用がオススメみたい。
elasticsearchはデフォルトでmulticastで通信を行い、同一ネットワークに属するノードを自動検出し、クラスタを形成する機能を有効にしている。簡単にクラスタが作れる反面、自動検出によってハマることも少なくないため、本運用時にも自動運用にさせるのは少し不安がある。
multicast discovery モード
デフォルトで有効。network.publish_host
の値を元にネットワークを自動検出し、クラスタを形成する。
networkには_eth0:ipv4_
のように具体的なIPやホスト名を指定せず、eth0
に割り当てられたIPv4のアドレスを使うという指定もできる。
このLogical Host Setting Value
はnetwork-moduleの項目に一覧がある。
unicast discovery モード
discovery.zen.ping.multicast.enabled: false
とすると、unicast discovery
モードになる。
discovery.zen.ping.unicast.hosts
に接続される全てのnodeのIPアドレスとport番号を指定する。
discovery.zen.ping.unicast.hosts: ["host1", "host2:port"]
本運用時には、自動クラスタリングによる事故を防止する目的で、multicastモードを無効にするのがよさそう。
elasticsearchのみで閉じたネットワークの場合には、unicastモードの利点が活かせるかもしれない。
今回はここらで。手元のメモの続きはフェイルオーバーの話が続いているけど、次回はプラグイン周りの紹介がいいような気もする。