（ES6.2.3 on AWS EC2）AZごとのShard Allocation Awareness について

mkokui · April 5, 2018, 5:41am

■環境
Elasticsearch 6.23
－ Plugin に「discovery-ec2 6.2.3」をインストール済
OS: Amazon Linux AMI 2017.09.1 (HVM), SSD Volume Type - ami-a77c30c1

■やりたいこと
１つのAZ内に配置されているElasticsearchのノードだけで完全なインデックス（シャード）を保持し、受け付けた検索要求は同じAZ内で検索を完結できるような構成にしたい。
↓こちらの記事を拝見しました。

■今できていることとできていないこと
以下の設定（elasticsearch.yml）で、Nodeを起動すると自動的にMaster Nodeに認識されクラスタに追加されるところまでができています。

elasticsearch.yml

cluster.name: my-cluster
cluster.routing.allocation.awareness.attributes: aws_availability_zone
cluster.routing.allocation.awareness.force.aws_availability_zone.values: ap-northeast-1a,ap-northeast-1c,ap-northeast-1d

node.name: ${HOSTNAME}

path.data: /var/lib/elasticsearch
path.logs: /var/log/elasticsearch

network.host: 0.0.0.0

discovery.zen.hosts_provider: ec2
discovery.ec2.endpoint: ec2.ap-northeast-1.amazonaws.com

cloud.node.auto_attributes: true

ただ、以下のコマンドでShardを確認した通り、同一AZで完結するような配置にはなっていません。ホスト名にAZと連番を入れています。（kokui-az1a-02... は、AZ：ap-northeast-1aに立てた2台目。）
プライマリ（p）を確認すると、AZ1aとAZ1dの2つのAZに跨って配置されています。

GET _cat/shards

index-2018-04-03t00-57-00-000z 0 p STARTED 860 2.3mb 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-03t00-57-00-000z 0 r STARTED 860 2.3mb 10.1.3.9   kokui-az1d-01.localdomain
index-2018-04-03t00-57-00-000z 1 p STARTED 853 2.3mb 10.1.3.9   kokui-az1d-01.localdomain
index-2018-04-03t00-57-00-000z 1 r STARTED 853 2.3mb 10.1.1.115 kokui-az1a-03.localdomain
index-2018-04-03t00-57-00-000z 2 p STARTED 835 2.3mb 10.1.3.147 kokui-az1d-02.localdomain
index-2018-04-03t00-57-00-000z 2 r STARTED 835 2.3mb 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-03t00-57-00-000z 3 p STARTED 947 2.6mb 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-03t00-57-00-000z 3 r STARTED 947 2.6mb 10.1.2.90  kokui-az1c-01.localdomain
index-2018-04-03t00-57-00-000z 4 p STARTED 846 2.3mb 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-03t00-57-00-000z 4 r STARTED 846 2.3mb 10.1.2.90  kokui-az1c-01.localdomain

同一AZ内で完結するようなShard配置にしたいのですが、助言を頂けないでしょうか。
AWS EC2上でクラスタ化するまでであれば「cluster.routing.allocation.awareness.force.aws_availability_zone.values: ap-northeast-1a,ap-northeast-1c,ap-northeast-1d」はなくても動きました。これを追加することで同一AZに縛られるのかと思いましたが違ったようです。

mkokui · April 6, 2018, 2:49am

引き続き追加検証しました。（少し長いです。）

・elasticsearch.ymlは前のコメントのまま
・AZ-1aに3台、AZ-1cに2台の合計5台でクラスタ化
・作成IndexのShardは5、Replicaは1

＜検証パターン①＞

最初から全Nodeを起動した状態でIndexを作成

GET _cat/shards
index-2018-04-06t00-00-00-000z 0 p STARTED 0 230b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 1 p STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain
index-2018-04-06t00-00-00-000z 2 p STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 3 p STARTED 0 230b 10.1.1.115 kokui-az1a-03.localdomain
index-2018-04-06t00-00-00-000z 4 p STARTED 0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 0 r STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 1 r STARTED 0 230b 10.1.1.115 kokui-az1a-03.localdomain
index-2018-04-06t00-00-00-000z 2 r STARTED 0 230b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 3 r STARTED 0 230b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 4 r STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain

AZ-1a に3Shard、AZ-1cに2Shardで配分されている。
・・求める挙動はどちらかに片寄してできて欲しいので、求める挙動と異なる。

＜検証パターン２＞

段階的にNodeを起動
①AZ-1a の2Node（kokui-az1a-01、kokui-az1a-02）を起動した状態でIndexを作成

GET _cat/shards
index-2018-04-06t00-00-00-000z 0 p STARTED    0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 1 p STARTED    0   0b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 2 p STARTED    0   0b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 3 p STARTED    0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 4 p STARTED    0   0b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 0 r UNASSIGNED                   
index-2018-04-06t00-00-00-000z 1 r UNASSIGNED                   
index-2018-04-06t00-00-00-000z 2 r UNASSIGNED                   
index-2018-04-06t00-00-00-000z 3 r UNASSIGNED                   
index-2018-04-06t00-00-00-000z 4 r UNASSIGNED

同一AZ内でShardが作成され、Replicaは異なるAZにできて欲しいのでUNASSINGEDとなるのは納得できる。

②AZ-1c の2Node（kokui-az1c-01、kokui-az1c-02）を起動

GET _cat/shards
index-2018-04-06t00-00-00-000z 0 p STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 1 p STARTED 0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 2 p STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 3 p STARTED 0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 4 p STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 0 r STARTED 0   0b 10.1.2.90  kokui-az1c-01.localdomain
index-2018-04-06t00-00-00-000z 1 r STARTED 0   0b 10.1.2.90  kokui-az1c-01.localdomain
index-2018-04-06t00-00-00-000z 2 r STARTED 0   0b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 3 r STARTED 0   0b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 4 r STARTED 0   0b 10.1.2.90  kokui-az1c-01.localdomain

異なるAZ（1c）に起動したNodeにReplicaが作成される。
ここも挙動として納得できる。

③AZ-1a の1Node（kokui-az1a-03）を起動

GET _cat/shards
index-2018-04-06t00-00-00-000z 0 p STARTED 0 230b 10.1.1.115 kokui-az1a-03.localdomain
index-2018-04-06t00-00-00-000z 1 p STARTED 0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 2 p STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 3 p STARTED 0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 4 p STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 0 r STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain
index-2018-04-06t00-00-00-000z 1 r STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain
index-2018-04-06t00-00-00-000z 2 r STARTED 0 230b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 3 r STARTED 0 230b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 4 r STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain

Shard-0が「kokui-az1a-02」から起動した「kokui-az1a-03」に移った。
挙動としては納得できるが、この検証は何度も実施したわけではないので、必ずShardが同一AZで構成されるのか不安。

④AZ-1a の1Node（kokui-az1a-03）を停止

GET _cat/shards
index-2018-04-06t00-00-00-000z 0 p STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain
index-2018-04-06t00-00-00-000z 1 p STARTED 0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 2 p STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 3 p STARTED 0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 4 p STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 0 r STARTED 0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 1 r STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain
index-2018-04-06t00-00-00-000z 2 r STARTED 0 230b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 3 r STARTED 0 230b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 4 r STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain

Shard-0の「kokui-az1a-03」を停止したので、Replica-0の「kokui-az1c-01」がShard-0に昇格。
空いたReplica-0に「kokui-az1a-01」が入った。
ReplicaがShardに昇格するのは理解できるのですが、自動的に同一AZに寄せられないものなのでしょうか。

⑤④で停止したAZ-1a の1Node（kokui-az1a-03）を起動

GET _cat/shards
index-2018-04-06t00-00-00-000z 0 p STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain
index-2018-04-06t00-00-00-000z 1 p STARTED 0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 2 p STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 3 p STARTED 0 230b 10.1.1.191 kokui-az1a-01.localdomain
index-2018-04-06t00-00-00-000z 4 p STARTED 0 230b 10.1.1.50  kokui-az1a-02.localdomain
index-2018-04-06t00-00-00-000z 0 r STARTED 0 230b 10.1.1.115 kokui-az1a-03.localdomain
index-2018-04-06t00-00-00-000z 1 r STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain
index-2018-04-06t00-00-00-000z 2 r STARTED 0 230b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 3 r STARTED 0 230b 10.1.2.120 kokui-az1c-02.localdomain
index-2018-04-06t00-00-00-000z 4 r STARTED 0 230b 10.1.2.90  kokui-az1c-01.localdomain

起動した「kokui-az1a-03」はReplica-0に入った。
※「kokui-az1a-01」→「kokui-az1a-03」にチェンジ
ここも④と同様でShardとReplicaが同一AZに寄せられるように動いて欲しかった。

ということから＜検証パターン②＞のように起動すれば立ち上げまでは同一AZに寄せられることがわかりました。ただ、＜検証パターン②＞－③のケースのように運用中でのNode追加が同一AZに寄せられるのかは疑問です。また、途中で運用中の障害なのでReplicaが昇格すると同一AZ配置が維持されなくなってしまいます。障害時はしょうがない気もしますが、手動でmoveする運用が必要でしょうか？

＜検証パターン①＞のようになってしまうのは設定がおかしいのでしょうか？
動きがまだ腑に落ちないです。

johtani · April 10, 2018, 8:26am

Shard Allocation Awarenessは、同じZoneに同じ番号のShardが配置されないようにするという機能になります。片方のZoneが落ちても、Shardが欠落しないようにというのを保証するためです。

誤解されているかもしれませんが、PrimaryとReplicaについては、違いはほぼありません。
ですので、PrimaryとReplicaの違いについては気にする必要がありません。
Primaryがなくなった場合に、ReplicaがPrimaryに昇格する、最初にPrimaryに書き込みに行くくらいの違いです。
検索時には、違いを気にせずに検索する機能となります。
こちらのPrefer local shardsにあるように、機能が有効の場合は、おなじZoneで検索するような挙動になります。
https://www.elastic.co/guide/en/elasticsearch/reference/6.2/allocation-awareness.html

mkokui · April 11, 2018, 1:13am

おっしゃる通り勘違いしておりまして、Replicaには検索にいかないものと思っておりました。
勉強させて頂きました。ありがとうございます。
改めて先の挙動を確認しましたが、確かに同じIndexのShardとReplicaが同じZoneに配置されないように動いておりました。

検索についての確認もできれば行いたいのですが、どこのNodeから検索されているかなどを確認する手段はございますでしょうか？

mkokui · April 11, 2018, 1:30am

すみません。自己解決しました。
_search にもexplainプロパティがあったのですね。

POST _search 
{
  "explain": true,
  "query": {
        "match_all": {}
    }
}

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-explain.html

system · May 9, 2018, 1:30am

This topic was automatically closed 28 days after the last reply. New replies are no longer allowed.