0
0

More than 1 year has passed since last update.

Amazon OpenSearch Service の Cross-cluster replication

Last updated at Posted at 2021-10-29

クロスクラスタレプリケーションしてみる

基本はこちらのドキュメントに全部書いてあります。こちらやってみた記事です。

概要説明

左側のレプリの元になるクラスタをリーダーと呼ぶ。右側のレプリケーション先をフォロワーと呼ぶ
図では、リーダードメイン"demo-repli1"のインデックス"test1_index"を、フォロワードメイン"demo-repli2"のインデックス"rep_test1_index"にレプリケーションしている

名称未設定ファイル-ページ1.drawio (2).png

だが、実際はフォロワーからPULLする方式になる。そのため、以下の図のように示すと、この後に説明する"接続"設定や"アクセスポリシー"設定や"レプリコマンド"実行が、どちらのドメインで実行するかがスッと分かりやすい
アクセスポリシーの設定はレプリのアクセスを受ける左側のリーダーだよとか、レプリスタートはPULLをする右側のフォロワーだよとか
公式Docから引用

It follows an active-passive replication model where the follower index (where the data is replicated) pulls data from the leader index.

OpenSearch Doc

Cross-cluster replication follows a “pull” model, so most changes occur on the follower cluster, not the leader cluster.

名称未設定ファイル-ページ2.drawio.png

注意点

  • 前提条件
    • 2021/10/28現在は、Elasticsearch7.10のみだった
    • 同じメジャーバージョンを共有するか、最終的なマイナーバージョンと次のメジャーバージョンを共有する必要があります
    • M3およびT2はだめ
    • きめ細かいアクセス制御が有効
    • ノード間暗号化が有効
    • AWSCloudFormationを使用してドメインを接続することはできません
    • The user names must be identical.
    • フォロワーのIndexはリードオンリーになります。参考リンク

事前準備

ドメイン2つ作成

  • demo-repli01(リーダー), demo-repli02(フォロワー)
  • AES v7.10, 1台, r5.large.search
  • マスタユーザーを事前に作成(両方のクラスタで同じ名前にしておく)

リーダードメインのアクセスポリシーに以下を追加

リージョンは東京リージョン。AWSアカウントIDは"123456789012"としてる

xxx
xxx
xxx
,
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESHttp*",
      "Resource": "arn:aws:es:ap-northeast-1:123456789012:domain/demo-repli01/*"
    },
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "*"
      },
      "Action": "es:ESCrossClusterGet",
      "Resource": "arn:aws:es:ap-northeast-1:123456789012:domain/demo-repli01"
    }

リーダードメインに書き込みテスト

以後、操作はKibanaのDevTools
POSTしたものをGETで確認

スクリーンショット 0003-10-29 15.02.54.png

POST /test1_index/tmp_type/
{
  "group": "sales",
  "users": [
    {
      "first_name": "Taro",
      "last_name": "Kimura"
    },
    {
      "first_name": "Jiro",
      "last_name": "Maeda"
    }
  ]
}

GET test1_index/tmp_type/_search
{"query": {"match": { "users.first_name":"taro"}}}

レプリケーション設定

接続

  • フォロワードメイン"demo-repli02"のマネコン画面から、[接続]タブをクリックし[リクエスト]をクリックする。

スクリーンショット 0003-10-29 15.05.48.png

  • 接続エイリアスに"demo-repli"を入力し、送信先クラスターのドメインに"demo-repli01"を選択して、[リクエスト]をクリックする

スクリーンショット 0003-10-29 15.07.57.png

  • リーダードメインの[接続]タブをクリックしてリクエストの確認をする。"インバウンド接続"の箇所にフォロワードメイン"demo-repli02"が表示されステータスが「保留中の承認」となっている。これにチェックを入れて右上の[承認]をクリックする。

スクリーンショット 0003-10-29 15.10.51.png

  • ステータスが「承認済」になる

スクリーンショット 0003-10-29 15.13.42.png

  • フォロワードメイン側も承認されたことでステータスが「アクティブ」になる

スクリーンショット 0003-10-29 15.14.44.png

レプリケーションスタート

  • フォロワードメインで、"_plugins/_replication/xxx/_start"でレプリスタート。フォロワードメイン側で行うことに注意。PULL型なのでフォロワー側を起点にレプリスタートする。
    • ※ use_rolesの権限は今回テストのためall_accessにしてますが、必要に応じて絞りましょう

スクリーンショット 0003-10-29 15.18.24.png

  • フォロワー側でレプリしてきたインデックス(rep_test1_index)はこの段階で作成されている。(既存のインデックスをフォロワーインデックスに変換することはできない)

スクリーンショット 0003-10-29 15.41.54.png

  • "_plugins/_replication/xxx/_status"でレプリの状態確認。statusがsyncingなので良さそう

スクリーンショット 0003-10-29 15.19.26.png

  • searchしてみる。事前に書き込んだkimura taroさんがヒットした。レプリスタート前のデータもレプリしてくれることが分かる

スクリーンショット 0003-10-29 15.24.43.png

PUT _plugins/_replication/rep_test1_index/_start
{
   "leader_alias": "demo-repli",
   "leader_index": "test1_index",
   "use_roles":{
      "leader_cluster_role": "all_access",
      "follower_cluster_role": "all_access"
   }
}

GET _cat/indices/rep_test1_index


GET _plugins/_replication/rep_test1_index/_status


GET rep_test1_index/test_type/_search
{"query": {"match": { "users.first_name":"taro"}}}

  • リーダードメインで新規書き込み(uehara shingoを書き込み)してみる。もちろんリーダードメインではsearch出来る

スクリーンショット 0003-10-29 15.28.22.png

  • フォロワードメインでsearchするとヒットした。レプリ出来てる

スクリーンショット 0003-10-29 15.29.47.png

POST /test1_index/tmp_type/
{
  "group": "sales",
  "users": [
    {
      "first_name": "shingo",
      "last_name": "uehara"
    }
  ]
}

GET test1_index/tmp_type/_search
{"query": {"match": { "users.first_name":"shingo"}}}

フォロワー側でレプリしてるIndexに書き込んでみた

失敗。リードオンリーのようです。

スクリーンショット 0003-10-29 17.35.08.png

その他レプリ操作

  • status:ステータスチェック
  • pause:一時停止
  • resume:一時停止からの再開
  • stop:完全停止

STOPは注意が必要で、フォロワーインデックスはリーダーのフォローを解除し、リードオンリーから書き込み可能な標準インデックスになります。レプリケーションを停止した後、レプリケーションを再開することはできません

PauseしてStatus確認してみる
(注意)「12時間以上一時停止した後は、レプリケーションを再開できないことに注意してください」らしい。参考Doc

スクリーンショット 0003-10-29 15.37.13.png

GET _plugins/_replication/rep_test1_index/_status

POST _plugins/_replication/rep_test1_index/_pause
{}

POST _plugins/_replication/rep_test1_index/_resume
{}

POST _plugins/_replication/rep_test1_index/_stop
{}

他にも操作いくつかあります

opensearchのドキュメントにいろいろあります。stats系でいろいろ情報取れそうですね
https://opensearch.org/docs/latest/replication-plugin/api/

Start replication
Stop replication
Pause replication
Resume replication
Get replication status
Get leader cluster stats
Get follower cluster stats
Get auto-follow stats
Update settings
Create replication rule
Delete replication rule

スクリーンショット 0003-10-29 19.17.15.png

その他機能

Auto-followという機能でreplication ruleを作り、ルールに記述したパターンにマッチしたインデックスを自動でレプリ出来る

指定されたパターンに一致するインデックスを自動的に複製する単一のリーダードメインに対して一連の複製ルールを定義できます。 パターンの1つ(books* とか)に一致するリーダードメインにインデックスを作成すると、一致するフォロワーインデックスがフォロワードメインに作成されます。 OpenSearch Serviceは、パターンに一致する新しいインデックスを複製しますが、以前に作成したインデックスは複製しません。

公式ドキュメント

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0