エンジニアリング

Elasticsearch 1.x から 2.x へのアップグレード時の注意点

概要

ソフトウェア開発ライフサイクルにおいては、新しい機能やバグ修正を利用したり、サポートを確保したりするために、製品の最新リリースにアップグレードする必要が生じます。Elasticsearch もその例外ではありません。バージョン 2.0 には数多くのすばらしい変更が盛り込まれているのですが、アップグレードした時点で現行の 1.x バージョンはブレークされます (使えなくなります)。文字どおりブレーキングチェンジ(互換性のない変更)です。全クラスタの再起動も必要ですのでご注意ください。

Elasticsearch 1.x から 2.x へのアップグレードに関する動画を見る

2014-08-29_15_20_20_-Upgrade_-_Maintain_Speed.JPG

Elasticsearch 2 にスムーズにアップグレードするには

テスト環境で事前にテストしておけば、アップグレードに失敗したり、既存のデータとの不整合が生じたりする心配はほとんどなくなるはずです。ただし、テストには次のような計画が必要です。

  • 「あの機能はどうなった?」と後で焦ることがないように、新しいリリースに含まれる重要な変更のリストをよく読んでおく。
  • elasticsearch.ymlでnetwork.host_non_loopbackのaddressに設定する。インターフェイスは「_[networkInterface]_」 (例えば、「_en0_」 や「_ens160_」または「_eth0」) として構成されることもあります。
  • アップグレードを試みる前に、クラスタに移行プラグインをダウンロードしてインストールする。ノードの再起動は不要です。このプラグインは、マッピング、インデックス設定、セグメントをチェックして、移行プロセスを開始する前に何を変更する必要があるのかをハイライトしてくれます(ただし、チェックするだけで変更まではしてくれません)。手作業で必要な変更を行う前に、新しいリリースでの変更内容をすべて見直して確認する必要があります。このプラグインはインデックステンプレートのチェックはしません。
  • スナップショットとリストア機能を使って、テスト環境の実稼働データのコピーをとっておく。このコピーしたデータで移行アップグレードのテストを行います。何か起きても、実稼働クラスタではなく、コピーデータが壊れるだけで済みます。
  • メジャーバージョン(1.x から 2.x)のアップグレードにはクラスタ全体の再起動が必要になります。
  • systemd以外のインストールの場合、1.xから2.xの最新のelasticsearch initスクリプトを使用することをお勧めします(スクリプトはかなり違います):

        2.1 DEB init
        2.1 RPM init

  • 推奨される変更すべてをクラスタ構成に適用する。これに関連してアプリケーションで使用されるバックエンド/フロントエンドコードも変更します。移行プラグインを実行してハイライトされた部分と重要な変更に関するドキュメントに従って、必要な変更を行います。
  • 最新リリースでも正常に動作するように、Elasticsearchのプラグインについても、アップグレードに関するドキュメントの指示に従います。
  • Elasticsearch 2.xとの完全な互換性を確保するためには、LogstashKibanaもサポートされるバージョンにアップグレードする必要があります。
  • MarvelプラグインとエージェントのアップグレードにはKibanaのアップグレードも必要です。UIがKibanaのプラグインに変更されました。
  • Senseは、オープンソースになりました。また、Marvelではなく、Kibanaのプラグインでもあります。したがって、アップグレード後に手動でインストールする必要があります。
  • Logstash 2.xではHTTPプロトコルがデフォルトで使用されるため、logstash設定を手作業で変更する必要が生じる可能性があります。必要に応じてelasticsearch_java出力プラグインをインストールすることもできます。
  • 正しいアップグレードパスに従っていることを確認してください。
  • インデックスのアップグレードプロセスはモニタできます。'check upgrade status' APIコマンドを見てください。

アップグレードで問題が起きた場合

どんなに慎重に手順に従っても、アップグレードで問題が起きることはあります。そのような場合でも、手はあります。

  • フォーラムに質問を投稿してみてください。ユーザーコミュニティは驚くほど頼りになります。
  • ユーザーコミュニティは驚くほど頼りになります。 · アップグレード中に新しいバグを見つけたと思ったら、 GitHubにバグレポートを送ってください。
  • サブスクリプションにご契約されている場合はサポートポータルにチケットを登録してください。Elasticの専任スタッフがアップグレードプロセスのお手伝いをさせていただきます。

クラスタ全体の再起動に伴うダウンタイムやメンテナンス時間枠をできるだけ短くするには

リスクが大きすぎる、アップグレードが大変すぎる、というような場合は次のような選択肢もあります。

  • 新しいバージョンのElasticsearchで新しいクラスタを構築し、必要に応じてLogstashとKibana、他のプラグインの対応する新しいリリースを導入する。
  • ソースイベントデータを既存のクラスタと新しいクラスタの両方にフィードしておいて、必要な維持期間が経過したら、既存のクラスタの使用を中止する。この方法は、7日や1か月など、維持期間が短い方が効果的です。
  • ソースのデータセットのインデックスを再作成して新しいクラスタに移行し、その後、古いデータセットの使用を中止する。

この方法では、最初だけ物理的(または仮想的)なリソースが追加で必要になりますが、それもわずかな期間だけです(この目的のために一時的にテスト環境を利用すれば、追加のキャパシティコストはほとんど生じません)。新しいクラスタに既存のデータが完全に移行され、フロントエンドアプリケーションのその他の必要な機能も移行できれば、完全な切り替えも簡単に達成できます。

注意: Elasticsearchとのデータのやり取りのためのコードに、新リリースで変更されたマッピングや関数が使用されている場合(「重要な変更」を参照)、どのアップグレードパスを選んだとしても、やはり手作業で変更する必要があります。

既知の問題

以下に既知の問題をまとめました。アップグレードプランを立てる際に参考にしてください。アップグレードがうまく行かなかった場合や、一部しかアップグレードできなかった場合のトラブルシューティングにも役立つかも知れません。

  • network.hostが設定されていない(または正しく設定していない)。Elasticsearch 2.xを起動する前に、elasticsearch.ymlに network.host_non_loopbackが設定されていることを確認してください。
  • 移行プラグイン はElasticsearchバージョン1.xにのみ対応しています。したがって、アップグレード前に変更が必要ないことが確認できたら、他のすべての1.xプラグインと共に、実際のアップグレードを実行する前にこのプラグインを削除しておく必要があります。
  • パッケージアップグレード(DEB、RPMなど)の一部として置換ができるように、すべての構成ファイルのバックアップをとっておきます。以降は、必要なクラスタ設定に応じて、新しい構成ファイルを変更すれば良いわけです。
  • アップグレードを試みる前に、クラスタノードに十分なディスクスペースを確保しておきます。実はこの基本的なアップグレード原則は見落とされやすいのです。
  • 非常に古いリリース(0.90以前)からもアップグレードは可能です。LuceneのバージョンがElasticsearch 2.xに対応している必要があるため、upgrade APIに関するドキュメントを参照の上、事前にupgrade APIリクエストが必要になるかどうか判断してください。
  • Elasticsearchの最新リリースとの互換性を確保するには、常に最新のプラグインを使用する必要があります。Elasticsearch 2.xに対応するもっと新しいプラグインのバージョンがあるなら、古いプラグインを削除して、アップグレードを実行し、その後で新しいプラグインをインストールする必要があります。同様に、無効なプラグインが入ったプラグインフォルダがあると、Elasticsearchも起動も起動しません
  • クラスタ内のすべてのノードにmarvel-agentをインストールする必要があります。marvel-agentプラグインにはライセンスプラグインが必要になるため、まずはすべてのノードにライセンスプラグインをインストールしておかなければなりません。これをやっておかないと、問題が発生します。特に、javaノードクライアントを使用している場合は、ライセンスjarがプロジェクトに含まれていないと問題になります。
  • 2.0では、marvelを実行しているノードについて既知の問題があるため、marvel-agentを実行しているクライアントノードは、Elasticsearch 2.1以上にアップグレードする必要があります。
  • フィールドマッピングが競合するインデックスはElasticsearch 2.xにアップグレードできません(それらのインデックスは起動しません!)。これは前述の移行プラグインがハイライトしてくれます。
  • closeしたインデックスがあり、かつ移行プラグインでフィルタを使用していて移行プラグインが正常に実行できない場合は、この対処法を参照してください。
  • index_analyzer はもうありません。また、移行プラグインはテンプレートもチェックしません。そのため、例外がスローされる可能性があります。この場合には、古いテンプレートを手作業で更新する必要があります。
  • カーネルのバージョンが最新かどうかを確認してください。以前のリリースは、Elasticsearch 2.xで使用されている新しいfyncで正常に動作しません。
  • 一部のノードにまだ古いリリースがのこっていると、Elasticsearch 2.xなどのメジャーリリースへのアップグレードがうまく行きません。アップグレード手順再開の一部として、すべてのノードを新しいリリースにアップグレードする必要があります
  • Elasticsearch 2.xにアップグレードした後LogstashKibanaの互換性のないリリースを実行している。