なんかかきたい

プログラミングなどの個人的なメモやサークル「ゆきいろパラソル」の情報を載せてます

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/elasticsearchES_HEAP_SIZEを明示的に指定し、 elasticsearch.ymlbootstrap.mlockall: trueを記述する。

JVM起動時にメモリを確保するようになり、JVMのヒープサイズもここで指定したサイズに固定される。 メモリが不足する場合、エラーを出して落ちるようになる。ヒープのサイズはドキュメントの2倍程度がよいとか聞いた気もするけど、どこに書いてあるんだろ。デフォルトは1gbなので、必要に応じて大きくする。

ファイルディスクリプタ

ElasticSearchが開けるファイルの数は、32kまたは64kを公式では推奨している。

この値は/etc/init.d/elasticsearchMAX_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モードの利点が活かせるかもしれない。


今回はここらで。手元のメモの続きはフェイルオーバーの話が続いているけど、次回はプラグイン周りの紹介がいいような気もする。