はじめに
6.0.0が11/14にGAされてました。
https://www.elastic.co/jp/blog/elastic-stack-6-0-0-released
beatsの他のパッケージについて書こうと思いましたが、どうせなら最新版で書きたいということで今回はアップグレードしたいと思います。
今回の構成
前回、Beatsサーバを追加した構成を使用します。
アップグレードする対象は、Elasticsearch・kibana・beatsになります。
AWS側の設定について
今回は特に変更ありません。
1.アップグレード作業
1.1.事前準備
まず、現状のバージョンを確認します。
Elasticsearchの現在のバージョン
srv1,srv2,srv3共に同じバージョンですので、srv1でのコマンド実行結果のみ表示します。
# curl -XGET 'http://localhost:9200'
{
"name" : "node001",
"cluster_name" : "my-cluster",
"cluster_uuid" : "e06BKBFFSpiSkFwNT3kWLw",
"version" : {
"number" : "5.6.2",
"build_hash" : "57e20f3",
"build_date" : "2017-09-23T13:16:45.703Z",
"build_snapshot" : false,
"lucene_version" : "6.6.1"
},
"tagline" : "You Know, for Search"
}
Kibanaの現在のバージョン
Kibanaはブラウザから確認
Filebeatの現在のバージョン
Filebeatをインストールしているsrv4でコマンド実行
# filebeat -version
filebeat version 1.3.1 (amd64)
1.2.事前準備2
アップグレードのドキュメントを確認
https://www.elastic.co/guide/en/elastic-stack/current/upgrading-elastic-stack.html
一部を機械翻訳した結果
X-Pack 5.6では、Elasticsearchの移行およびアップグレードAPIと、
KibanaのアップグレードアシスタントUIが提供されています。
これらのツールは、X-Pack体験版ライセンスと無料の基本ライセンスに含まれています。
どうもbasicライセンスにすることでGUIでアップグレードのお手伝いをしてくれる模様。
Management画面の薄くなって無効化されているこれかな？
1.2.1.現在のライセンス状態の確認
# curl -XGET -u elastic:changeme 'http://localhost:9200/_xpack/license'
{
"license" : {
"status" : "expired",
"uid" : "7977deb4-d253-4ef4-8fd1-bf01e1d86315",
"type" : "trial",
"issue_date" : "2017-09-28T09:19:55.537Z",
"issue_date_in_millis" : 1506590395537,
"expiry_date" : "2017-10-28T09:19:55.537Z",
"expiry_date_in_millis" : 1509182395537,
"max_nodes" : 1000,
"issued_to" : "my-cluster",
"issuer" : "elasticsearch",
"start_date_in_millis" : -1
}
}
"type" : "trial",となっていることが確認できます。
このライセンスをbasicライセンスにしたいと思います。
1.2.2.ライセンスの更新
Basicライセンスは無料で利用可能ですが、その為にユーザ登録が必要になります。
以下のページのフォームに必要な情報を入力して送信します。
入力後Sendします。
登録完了すると上記ページに遷移し、しばらくするとメールが送られてきます。
メール本文は以下
Thank you for using the Elastic Stack and registering for your free Basic license! This license expires on November 30, 2018.
To download your license, please go to:
--> http://license.elastic.co/registration/download/xxxxxxxxxxxxxxx
For license installation instructions:
Elasticsearch 6.x -- https://www.elastic.co/guide/en/x-pack/current/installing-license.html
Elasticsearch 5.x -- https://www.elastic.co/guide/en/x-pack/5.6/installing-license.html
Elasticsearch 2.x -- https://www.elastic.co/guide/en/marvel/current/license-management.html
Elasticsearch 1.x -- Use license code '1010' to register
If you have any questions or issues, please visit us on the forums: https://discuss.elastic.co/ or reach out to us directly at info@elastic.co.
Best,
The Elastic Team
--
http://elastic.co
ライセンスのダウンロードページからライセンスをダウンロードし保管します。
また、srv1にアップロードします。
ダウンロードしてきたときにはファイル名に長い名前が付いていますので、
basiclicense.jsonとでもリネームしてアップロードしておきました。
srv1にて以下コマンドを実行し、basicライセンスを適用します。
# curl -XPUT -u elastic:changeme 'http://localhost:9200/_xpack/license?acknowledge=true' -H "Content-Type: application/json" -d @basiclicense.json
{"acknowledged":true,"license_status":"valid"}[root@ip-192-100-0-4 ~]#
うん？出力がおかしいような気がしますが、ライセンスが更新されたか確認します。
# curl -XGET -u elastic:changeme 'http://localhost:9200/_xpack/license'
{
"license" : {
"status" : "active",
"uid" : "7370b0b5-e3cf-47ba-af90-8ad1040b808b",
"type" : "basic",
"issue_date" : "2017-11-30T00:00:00.000Z",
"issue_date_in_millis" : 1512000000000,
"expiry_date" : "2018-11-30T23:59:59.999Z",
"expiry_date_in_millis" : 1543622399999,
"max_nodes" : 100,
"issued_to" : "xxxx xxxx (Xxxxxx xxxxx., Ltd.)",
"issuer" : "Web Form",
"start_date_in_millis" : 1512000000000
}
}
"type" : "basic",に変わっていますね。
Elasticsearchサーバは3台あるので、他のサーバから見たらどうなるのか気になります。確認します。
# curl -XGET -u elastic:changeme 'http://localhost:9200/_xpack/license'
{
"license" : {
"status" : "active",
"uid" : "7370b0b5-e3cf-47ba-af90-8ad1040b808b",
"type" : "basic",
"issue_date" : "2017-11-30T00:00:00.000Z",
"issue_date_in_millis" : 1512000000000,
"expiry_date" : "2018-11-30T23:59:59.999Z",
"expiry_date_in_millis" : 1543622399999,
"max_nodes" : 100,
"issued_to" : "xxxx xxxx (Xxxxxx xxxxx., Ltd.)",
"issuer" : "Web Form",
"start_date_in_millis" : 1512000000000
}
}
# curl -XGET -u elastic:changeme 'http://localhost:9200/_xpack/license'
{
"license" : {
"status" : "active",
"uid" : "7370b0b5-e3cf-47ba-af90-8ad1040b808b",
"type" : "basic",
"issue_date" : "2017-11-30T00:00:00.000Z",
"issue_date_in_millis" : 1512000000000,
"expiry_date" : "2018-11-30T23:59:59.999Z",
"expiry_date_in_millis" : 1543622399999,
"max_nodes" : 100,
"issued_to" : "xxxx xxxx (Xxxxxx xxxxx., Ltd.)",
"issuer" : "Web Form",
"start_date_in_millis" : 1512000000000
}
}
問題ないようです。ライセンスの更新ができました。
1.3.security機能の無効化・再起動
手順を見ると、sevurity機能を有効にしている場合は、ElasticsearchとKibanaの
secuirty機能を無効化し再起動するとなっていますが、
今回の構成では元々無効化してありますので、飛ばします。
2.1.Elasticsearchのアップグレード
KibanaのManagement画面を確認します。
トライアルライセンスでは表示されていたWatcherが無くなっています。
(他の機能も一部無くなっています。Basicライセンスでは使用できない為でしょう。)
トライアルライセンスも30日しか使えませんので仕方ありません。
Upgrade Assistantが有効になっています。
これを利用してElasticsearchをアップグレードします。
2.1.1.Upgrade Assistantの利用
KibanaのManagement画面からUpgrade Assistantを選択します。
遷移した画面からCluster Checkupを選択します。
Index SettingsとNode Settings両方にエラーが出ていました。
2.1.2.Node Settingsのエラー対応
ひとまずNode側のエラーをなんとかするかと、メッセージにあるドキュメントを読みます。
結果、Elasticsearch.ymlにpath.data or path.logsを明示的に記載する必要が
あるとのことでしたのでsrv1,srv2,srv3で以下の作業を実施します。
# vi /etc/elasticsearch/elasticsearch.yml
※以下2行を追記
path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch
# service elasticsearch restart
実行してみたものの、エラー表示が無くならずどういうことかと調べていると、
https://discuss.elastic.co/t/upgrade-assistant-default-path-settings-are-removed/107110
うーん。同じ症状で悩んでいる人がいるが、解決していないようでした。
/usr/lib/systemd/system/elasticsearch.serviceを編集してみてという
書き込みがあったので試してみましたが、何も変わりません。
コンフィグファイルが問題ならパッケージをアップグレード後に試してみるかと
考え、一旦放置することに。(検証環境じゃないとこんなことできませんが・・・)
2.1.2.Index Settingsのエラー対応
どうやらBasicライセンスになったことで、無効化されたWatcherのindexが存在することでエラーになっているような感じがします。
Reindex Helperを見てみます。
まさに対象の二つが表示されます。これをReindexすれば解決でしょうか？
現在のライセンスではWatcherが使えないという感じでエラーがでてしまいます。
使えないライセンスに変えましたからエラーになっているのは良いのですが、
修正方法が分からず。使って無い機能のエラーなので無視ですかね・・
とりあえずいくらか問題を抱えている状況ですが、アップグレードしていきたいと思います。
3.ElastiSearchのアップグレード
公式のドキュメントを読むと、5.6系は6.0系にローリングアップグレードが実施できるとのこと。無停止でできるならそれに越したことは無いので実施してみます。
公式のドキュメントが英語なので、正直内容の意味がわかっていないところもあるのですが、目次はそれに沿って書いていきたいと思います。
SRV3,SRV2,SRV1の順番で作業を実施します。
3.1.Disable shard allocation.
ノードのシャットダウン前にシャード割り当てを無効にすることで無駄なI/Oの発生を防ぐようです。
調べると、通常時はノードをダウンさせると自動的にshardとレプリカの再配置が実行されてしまうようです。
[root@ip-192-100-0-6 ~]# curl -XPUT 'http://localhost:9200/_cluster/settings' -d'
> {
> "persistent": {
> "cluster.routing.allocation.enable": "none"
> }
> }'
※コマンドここまで、以下返り値
{"acknowledged":true,"persistent":{"cluster":{"routing":{"allocation":{"enable":"none"}}}},"transient":{}}[root@ip-192-100-0-6 ~]#
3.2.Stop non-essential indexing and perform a synced flush. (Optional)
これを実行しておくと、シャードリカバリがとても高速になるようです。
[root@ip-192-100-0-6 ~]# curl -POST 'http://localhost:9200/_flush/synced'
{"_shards":{"total":92,"successful":92,"failed":0},".triggered_watches":{"total":2,"successful":2,"failed":0},".monitoring-kibana-6-2017.11.30":{"total":2,"successful":2,"failed":0},".monitoring-es-6-2017.11.30":{"total":2,"successful":2,"failed":0},".monitoring-es-6-2017.12.01":{"total":2,"successful":2,"failed":0},".monitoring-es-6-2017.10.27":{"total":2,"successful":2,"failed":0},".monitoring-es-6-2017.10.05":{"total":2,"successful":2,"failed":0},"filebeat-2017.11.06":{"total":10,"successful":10,"failed":0},".watcher-history-6-2017.09.28":{"total":2,"successful":2,"failed":0},"filebeat-2017.12.01":{"total":10,"successful":10,"failed":0},"filebeat-2017.11.30":{"total":10,"successful":10,"failed":0},".monitoring-es-6-2017.09.28":{"total":2,"successful":2,"failed":0},".watches":{"total":2,"successful":2,"failed":0},".monitoring-kibana-6-2017.11.06":{"total":2,"successful":2,"failed":0},".monitoring-es-6-2017.11.20":{"total":2,"successful":2,"failed":0},".monitoring-kibana-6-2017.11.20":{"total":2,"successful":2,"failed":0},".monitoring-es-6-2017.11.06":{"total":2,"successful":2,"failed":0},"filebeat-2017.10.27":{"total":10,"successful":10,"failed":0},".tasks":{"total":2,"successful":2,"failed":0},".monitoring-kibana-6-2017.09.28":{"total":2,"successful":2,"failed":0},".watcher-history-6-2017.10.27":{"total":2,"successful":2,"failed":0},".watcher-history-6-2017.10.05":{"total":2,"successful":2,"failed":0},"filebeat-2017.11.20":{"total":10,"successful":10,"failed":0},".kibana-6":{"total":2,"successful":2,"failed":0},".monitoring-kibana-6-2017.12.01":{"total":2,"successful":2,"failed":0},".monitoring-kibana-6-2017.10.05":{"total":2,"successful":2,"failed":0},".monitoring-kibana-6-2017.10.27":{"total":2,"successful":2,"failed":0}}[root@ip-192-100-0-6 ~]#
3.3.Shut down a single node.
これは大丈夫です。Elasticsearchを停止します。
[root@ip-192-100-0-6 ~]# service elasticsearch stop
Stopping elasticsearch: [ OK ]
[root@ip-192-100-0-6 ~]#
3.4.Upgrade the node you shut down.
RPMパッケージを利用してアップグレードをするようです。
公式サイトからパッケージのリンクをコピーし、srv3から拾いに行かせます。
[root@ip-192-100-0-6 ~]# wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.0.0.rpm
--2017-12-01 08:08:07-- https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-6.0.0.rpm
Resolving artifacts.elastic.co (artifacts.elastic.co)... 184.73.156.41, 23.21.118.61, 54.225.188.6, ...
Connecting to artifacts.elastic.co (artifacts.elastic.co)|184.73.156.41|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 27970243 (27M) [application/octet-stream]
Saving to: ‘elasticsearch-6.0.0.rpm’
elasticsearch-6.0.0.rpm 100%[================================================================================================>] 26.67M 8.07MB/s in 3.3s
2017-12-01 08:08:12 (8.07 MB/s) - ‘elasticsearch-6.0.0.rpm’ saved [27970243/27970243]
パッケージのインストールについては、yum localinstallで実行してみます。
[root@ip-192-100-0-6 ~]# yum localinstall elasticsearch-6.0.0.rpm
Loaded plugins: priorities, update-motd, upgrade-helper
Examining elasticsearch-6.0.0.rpm: elasticsearch-6.0.0-1.noarch
Marking elasticsearch-6.0.0.rpm as an update to elasticsearch-5.6.2-1.noarch
Resolving Dependencies
amzn-main/latest | 2.1 kB 00:00:00
amzn-updates/latest | 2.5 kB 00:00:00
--> Running transaction check
---> Package elasticsearch.noarch 0:5.6.2-1 will be updated
---> Package elasticsearch.noarch 0:6.0.0-1 will be an update
--> Finished Dependency Resolution
Dependencies Resolved
=======================================================================================================================================================================================
Package Arch Version Repository Size
=======================================================================================================================================================================================
Updating:
elasticsearch noarch 6.0.0-1 /elasticsearch-6.0.0 30 M
Transaction Summary
=======================================================================================================================================================================================
Upgrade 1 Package
Total size: 30 M
Is this ok [y/d/N]: y
Downloading packages:
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
Updating : elasticsearch-6.0.0-1.noarch 1/2
warning: /etc/elasticsearch/elasticsearch.yml created as /etc/elasticsearch/elasticsearch.yml.rpmnew
Cleanup : elasticsearch-5.6.2-1.noarch 2/2
warning: /etc/elasticsearch/scripts saved as /etc/elasticsearch/scripts.rpmsave
Verifying : elasticsearch-6.0.0-1.noarch 1/2
Verifying : elasticsearch-5.6.2-1.noarch 2/2
Updated:
elasticsearch.noarch 0:6.0.0-1
Complete!
[root@ip-192-100-0-6 ~]#
問題無いようです。
3.5.Upgrade any plugins.
プラグインの更新。事前に調べるのを忘れていましたが、過去の記事から見直しますと、
analysis-kuromoji 5.6.2
x-pack 5.6.2
この二つがインストールされていますので、更新してみます。
基本的に現行verを削除、再インストールのようです。
[root@ip-192-100-0-6 ~]# /usr/share/elasticsearch/bin/elasticsearch-plugin remove analysis-kuromoji
-> removing [analysis-kuromoji]...
[root@ip-192-100-0-6 ~]# /usr/share/elasticsearch/bin/elasticsearch-plugin remove x-pack
-> removing [x-pack]...
-> preserving plugin config files [/etc/elasticsearch/x-pack] in case of upgrade; use --purge if not needed
[root@ip-192-100-0-6 ~]# /usr/share/elasticsearch/bin/elasticsearch-plugin install analysis-kuromoji
-> Downloading analysis-kuromoji from elastic
[=================================================] 100%??
-> Installed analysis-kuromoji
[root@ip-192-100-0-6 ~]# /usr/share/elasticsearch/bin/elasticsearch-plugin install x-pack
-> Downloading x-pack from elastic
[=================================================] 100%??
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: plugin requires additional permissions @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
* java.io.FilePermission \\.\pipe\* read,write
* java.lang.RuntimePermission accessClassInPackage.com.sun.activation.registries
* java.lang.RuntimePermission getClassLoader
* java.lang.RuntimePermission setContextClassLoader
* java.lang.RuntimePermission setFactory
* java.net.SocketPermission * connect,accept,resolve
* java.security.SecurityPermission createPolicy.JavaPolicy
* java.security.SecurityPermission getPolicy
* java.security.SecurityPermission putProviderProperty.BC
* java.security.SecurityPermission setPolicy
* java.util.PropertyPermission * read,write
* java.util.PropertyPermission sun.nio.ch.bugLevel write
See http://docs.oracle.com/javase/8/docs/technotes/guides/security/permissions.html
for descriptions of what these permissions allow and the associated risks.
Continue with installation? [y/N]y
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: plugin forks a native controller @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
This plugin launches a native controller that is not subject to the Java
security manager nor to system call filters.
Continue with installation? [y/N]y
Elasticsearch keystore is required by plugin [x-pack], creating...
-> Installed x-pack
プラグインを沢山いれていたら物凄い大変ですねこれ。
バージョンアップに対応できていないプラグインとかあったらどうなるのか。
サポートが間に合って無いプラグインがあると起動できなかったりするようです。
3.6.Start the upgraded node.
ノードを起動し、クラスタへ参加したかを確認します。
[root@ip-192-100-0-6 ~]# service elasticsearch start
Starting elasticsearch: [ OK ]
[root@ip-192-100-0-6 ~]# curl -GET 'http://localhost:9200/_cat/nodes'
192.100.0.5 7 34 0 0.06 0.04 0.00 mdi - node002
192.100.0.6 14 22 1 0.21 0.07 0.02 mdi - node003
192.100.0.4 11 36 1 0.00 0.02 0.00 mdi * node001
[root@ip-192-100-0-6 ~]#
良かった。ちゃんとクラスタへ参加できています。
公式の手順にはありませんが、現在のパッケージの状態を確認しました。
[root@ip-192-100-0-6 ~]# curl -XGET 'localhost:9200/'
{
"name" : "node003",
"cluster_name" : "my-cluster",
"cluster_uuid" : "e06BKBFFSpiSkFwNT3kWLw",
"version" : {
"number" : "6.0.0",
"build_hash" : "8f0685b",
"build_date" : "2017-11-10T18:41:22.859Z",
"build_snapshot" : false,
"lucene_version" : "7.0.1",
"minimum_wire_compatibility_version" : "5.6.0",
"minimum_index_compatibility_version" : "5.0.0"
},
"tagline" : "You Know, for Search"
}
[root@ip-192-100-0-6 ~]# curl -XGET 'http://localhost:9200/_cat/plugins?v'
name component version
node002 analysis-kuromoji 5.6.2
node002 x-pack 5.6.2
node003 analysis-kuromoji 6.0.0
node003 x-pack 6.0.0
node001 analysis-kuromoji 5.6.2
node001 x-pack 5.6.2
パッケージ・プラグインが更新できていることを確認できました。
3.7.Reenable shard allocation.
シャードの割り当てを再有効化します。
# curl -PUT 'http://localhost:9200/_cluster/settings' -d'
> {
> "transient": {
> "cluster.routing.allocation.enable": "all"
> }
> }
> '
{"error":"Incorrect HTTP method for uri [/_cluster/settings] and method [POST], allowed: [PUT, GET]","status":405}[root@ip-192-100-0-6 ~]#
エラーでますね。ドキュメントを調べていくと、以下のような情報が見つかりました。
https://www.elastic.co/guide/en/elasticsearch/reference/6.x/breaking_60_rest_changes.html
間違ったHTTP動詞を持つ既存のエンドポイントへのリクエストで405応答が返されるようになりました
存在するが、間違ったHTTP動詞（例えば、/ myindex / _settingsへのPOST要求）を持つエンドポイントへの要求を出すと、404ではなくHTTP 405応答が返されるようになりました。
となると、3.1.のコマンド実行時時点でエラーが出てたけど、アップグレード前は分からなくて、アップグレードしたことによって分かるようになったということでしょうか。
srv2と_cluster/settingsの状態を比べてみます。
[root@ip-192-100-0-6 ~]# curl -PUT 'http://localhost:9200/_cluster/settings'
{"persistent":{"cluster":{"routing":{"allocation":{"enable":"none"}}}},"transient":{}}[root@ip-192-100-0-6 ~]#
[root@ip-192-100-0-5 ~]# curl -PUT 'http://localhost:9200/_cluster/settings'
{"persistent":{"cluster":{"routing":{"allocation":{"enable":"none"}}}},"transient":{}}[root@ip-192-100-0-5 ~]#
同じですね・・
シャードって昔の記事を見たら、デフォルトで5個作られるとか記事あったので、気にしていなかったんですが、本環境のelasticsearch.ymlには何の記述も無いので、存在していないのかな、と思いましたのでシャードを確認してみました。
[root@ip-192-100-0-6 ~]# curl -XGET 'http://localhost:9200/_cat/shards'
.monitoring-es-6-2017.11.30 0 p STARTED 30970 21mb 192.100.0.5 node002
.monitoring-es-6-2017.11.30 0 r UNASSIGNED
filebeat-2017.12.01 3 r STARTED 2 8.4kb 192.100.0.5 node002
filebeat-2017.12.01 3 p STARTED 2 8.4kb 192.100.0.4 node001
filebeat-2017.12.01 2 p STARTED 0 191b 192.100.0.4 node001
※一部抜粋
あ、大量にありますね。そして全部確認したのですが、srv3(node003)のシャードがありません。これ駄目なやつですかね。
シャードの回復状況を確認します。
[root@ip-192-100-0-6 ~]# curl -XGET 'http://localhost:9200/_cat/recovery'
.triggered_watches 0 620ms peer done 192.100.0.6 node003 192.100.0.5 node002 n/a n/a 0 0 0.0% 0 0 0 0.0% 0 0 0 100.0%
.monitoring-kibana-6-2017.11.30 0 789ms peer done 192.100.0.6 node003 192.100.0.5 node002 n/a n/a 30 30 100.0% 30 1279239 1279239 100.0% 1279239 0 0 100.0%
.monitoring-kibana-6-2017.11.30 0 765ms peer done 192.100.0.6 node003 192.100.0.4 node001 n/a n/a 30 30 100.0% 30 1279239 1279239 100.0% 1279239 0 0 100.0%
※一部抜粋
見たところ、全てステータスがdoneになっているので、シャードは回復しているようです。
ではクラスターの状態を確認してみます。
[root@ip-192-100-0-6 ~]# curl -XGET 'http://localhost:9200/_cat/health'
1512120283 09:24:43 my-cluster yellow 3 3 62 46 0 0 30 0 - 67.4%
ステータスがyellowです。これがGreenになると作業完了なのですが、恐らくシャードは回復したけど、再割り当てができていないので、yellowのままなのかなと推測しています。
色々と調べたのですが、最終的な回答はこれなのかなと。
During a rolling upgrade, primary shards assigned to a node running the new version cannot have their replicas assigned to a node with the old version. The new version might have a different data format that is not understood by the old version.
If it is not possible to assign the replica shards to another node (there is only one upgraded node in the cluster), the replica shards remain unassigned and status stays yellow.
In this case, you can proceed once there are no initializing or relocating shards (check the init and relo columns).
As soon as another node is upgraded, the replicas can be assigned and the status will change to green.
バージョン違いで、認識できないデータが含まれていて、その場合は他のノードもアップグレードする必要があると。これはもう危険覚悟で一旦全ノードアップグレードしてみます。
(ローリングアップデートの意味があるのか・・・)
3.1の手順を省略し(設定変更前にすでに、"cluster.routing.allocation.enable": "none"になっているので。)srv1,srv2もアップグレードしました。
全台アップグレード後に確認しましたが、やはりステータスがyellowのままです。
[root@ip-192-100-0-4 ~]# curl -XGET 'http://localhost:9200/_cat/health'
1512123059 10:10:59 my-cluster yellow 3 3 46 46 0 0 46 0 - 50.0%
最終的なシャードの状態は以下
[root@ip-192-100-0-4 ~]# curl -XGET 'http://localhost:9200/_cat/shards'
.monitoring-es-6-2017.09.28 0 p STARTED 877 885.9kb 192.100.0.4 node001
.monitoring-es-6-2017.09.28 0 r UNASSIGNED
filebeat-2017.11.30 3 p STARTED 1 8kb 192.100.0.4 node001
filebeat-2017.11.30 3 r UNASSIGNED
filebeat-2017.11.30 4 p STARTED 2 9.4kb 192.100.0.6 node003
filebeat-2017.11.30 4 r UNASSIGNED
filebeat-2017.11.30 1 p STARTED 2 8.4kb 192.100.0.4 node001
filebeat-2017.11.30 1 r UNASSIGNED
filebeat-2017.11.30 2 p STARTED 0 228b 192.100.0.4 node001
filebeat-2017.11.30 2 r UNASSIGNED
filebeat-2017.11.30 0 p STARTED 2 15.6kb 192.100.0.4 node001
filebeat-2017.11.30 0 r UNASSIGNED
.monitoring-kibana-6-2017.11.06 0 p STARTED 383 268.7kb 192.100.0.6 node003
.monitoring-kibana-6-2017.11.06 0 r UNASSIGNED
.monitoring-es-6-2017.11.06 0 p STARTED 384 153.5kb 192.100.0.4 node001
.monitoring-es-6-2017.11.06 0 r UNASSIGNED
.monitoring-es-6-2017.12.01 0 p STARTED 33256 25.4mb 192.100.0.5 node002
.monitoring-es-6-2017.12.01 0 r UNASSIGNED
filebeat-2017.11.20 3 p STARTED 0 264b 192.100.0.6 node003
filebeat-2017.11.20 3 r UNASSIGNED
filebeat-2017.11.20 4 p STARTED 1 7.8kb 192.100.0.6 node003
filebeat-2017.11.20 4 r UNASSIGNED
filebeat-2017.11.20 1 p STARTED 0 228b 192.100.0.4 node001
filebeat-2017.11.20 1 r UNASSIGNED
filebeat-2017.11.20 2 p STARTED 1 7.7kb 192.100.0.4 node001
filebeat-2017.11.20 2 r UNASSIGNED
filebeat-2017.11.20 0 p STARTED 1 7.8kb 192.100.0.4 node001
filebeat-2017.11.20 0 r UNASSIGNED
.monitoring-es-6-2017.11.20 0 p STARTED 1065 288.7kb 192.100.0.4 node001
.monitoring-es-6-2017.11.20 0 r UNASSIGNED
filebeat-2017.11.06 4 p STARTED 3 23.5kb 192.100.0.4 node001
filebeat-2017.11.06 4 r UNASSIGNED
filebeat-2017.11.06 3 p STARTED 5 24.9kb 192.100.0.6 node003
filebeat-2017.11.06 3 r UNASSIGNED
filebeat-2017.11.06 1 p STARTED 7 26.6kb 192.100.0.4 node001
filebeat-2017.11.06 1 r UNASSIGNED
filebeat-2017.11.06 2 p STARTED 3 24.3kb 192.100.0.6 node003
filebeat-2017.11.06 2 r UNASSIGNED
filebeat-2017.11.06 0 p STARTED 3 16.7kb 192.100.0.4 node001
filebeat-2017.11.06 0 r UNASSIGNED
.monitoring-kibana-6-2017.12.01 0 p STARTED 1014 1mb 192.100.0.4 node001
.monitoring-kibana-6-2017.12.01 0 r UNASSIGNED
.watches 0 p STARTED 0 232b 192.100.0.5 node002
.watches 0 r UNASSIGNED
.kibana-6 0 p STARTED 2 8.2kb 192.100.0.4 node001
.kibana-6 0 r UNASSIGNED
.monitoring-kibana-6-2017.10.05 0 p STARTED 131 167.6kb 192.100.0.4 node001
.monitoring-kibana-6-2017.10.05 0 r UNASSIGNED
.monitoring-kibana-6-2017.11.30 0 p STARTED 2864 1.2mb 192.100.0.4 node001
.monitoring-kibana-6-2017.11.30 0 r UNASSIGNED
.watcher-history-6-2017.09.28 0 p STARTED 44 135.5kb 192.100.0.4 node001
.watcher-history-6-2017.09.28 0 r UNASSIGNED
.tasks 0 p STARTED 8 46.1kb 192.100.0.6 node003
.tasks 0 r UNASSIGNED
.monitoring-kibana-6-2017.11.20 0 p STARTED 1063 436.6kb 192.100.0.6 node003
.monitoring-kibana-6-2017.11.20 0 r UNASSIGNED
filebeat-2017.10.27 4 p STARTED 5 17.8kb 192.100.0.4 node001
filebeat-2017.10.27 4 r UNASSIGNED
filebeat-2017.10.27 3 p STARTED 2 15.6kb 192.100.0.6 node003
filebeat-2017.10.27 3 r UNASSIGNED
filebeat-2017.10.27 1 p STARTED 8 20.5kb 192.100.0.4 node001
filebeat-2017.10.27 1 r UNASSIGNED
filebeat-2017.10.27 2 p STARTED 5 18.5kb 192.100.0.4 node001
filebeat-2017.10.27 2 r UNASSIGNED
filebeat-2017.10.27 0 p STARTED 8 20.4kb 192.100.0.4 node001
filebeat-2017.10.27 0 r UNASSIGNED
.monitoring-es-6-2017.10.27 0 p STARTED 26153 19.4mb 192.100.0.6 node003
.monitoring-es-6-2017.10.27 0 r UNASSIGNED
.watcher-history-6-2017.10.05 0 p STARTED 84 247.9kb 192.100.0.4 node001
.watcher-history-6-2017.10.05 0 r UNASSIGNED
.monitoring-es-6-2017.10.05 0 p STARTED 2027 1.7mb 192.100.0.6 node003
.monitoring-es-6-2017.10.05 0 r UNASSIGNED
filebeat-2017.12.01 3 p STARTED 2 8.4kb 192.100.0.4 node001
filebeat-2017.12.01 3 r UNASSIGNED
filebeat-2017.12.01 4 p STARTED 1 8kb 192.100.0.6 node003
filebeat-2017.12.01 4 r UNASSIGNED
filebeat-2017.12.01 1 p STARTED 0 228b 192.100.0.4 node001
filebeat-2017.12.01 1 r UNASSIGNED
filebeat-2017.12.01 2 p STARTED 0 228b 192.100.0.4 node001
filebeat-2017.12.01 2 r UNASSIGNED
filebeat-2017.12.01 0 p STARTED 2 8.6kb 192.100.0.4 node001
filebeat-2017.12.01 0 r UNASSIGNED
.triggered_watches 0 p STARTED 0 117.1kb 192.100.0.5 node002
.triggered_watches 0 r UNASSIGNED
.monitoring-kibana-6-2017.10.27 0 p STARTED 1390 656.7kb 192.100.0.4 node001
.monitoring-kibana-6-2017.10.27 0 r UNASSIGNED
.monitoring-es-6-2017.11.30 0 p STARTED 30970 21mb 192.100.0.6 node003
.monitoring-es-6-2017.11.30 0 r UNASSIGNED
.watcher-history-6-2017.10.27 0 p STARTED 924 893.9kb 192.100.0.4 node001
.watcher-history-6-2017.10.27 0 r UNASSIGNED
.monitoring-kibana-6-2017.09.28 0 p STARTED 68 124.6kb 192.100.0.4 node001
.monitoring-kibana-6-2017.09.28 0 r UNASSIGNED
プライマリシャードは各srvに分散されています。
しかしレプリカシャードがアサインされていません。healthの状態が50%というのは、この項目の半分を占めるレプリカがアサインされていないせいですかね。
Kibana的にみると、データはちゃんと確認できています。
一旦はこれで良しとするしか無い感じでしょうか。
3.8.Wait for the node to recover.
今回途中であきらめて他のサーバも作業してしまいましたが、本来は3.7の後に
curl -XGET 'http://localhost:9200/_cat/health'
上記を実行してステータスがGreenになると一台のサーバの作業は完了。他のサーバの作業もするという流れのようです。
おわりに
シャードの再配置がコマンドで実行できないのが最後まで分かりませんでした。
多分ここさえクリアできれば問題無いと思うのですが・・・
Upgrade Assistantを使ってみようとライセンスを更新したのがいけなかったのか、
色々悔いが残った結果となりました。
ちなみにですが、Upgrade AssistantでWatcherが使えなくてReIndexできなかったものが有りましたが、気になって後でReIndexしてみたら、正常にReIndex終了しました。
また、Node settingsについてもエラーは消えていました。ここは気にしないでいいようです。結果Kibanaは綺麗になりました。
レプリカの件はまた時間ある時に調べておきたいと思います。
kibanaとbeatsパッケージの更新は次の機会に実施したいと思います。