チュートリアル: 双方向クロスクラスター複製に基づく災害復旧

双方向クロスクラスター複製に基づいて、2つのクラスター間で災害復旧を設定する方法を学びます。以下のチュートリアルは、クエリによる更新およびクエリによる削除をサポートするデータストリーム向けに設計されています。これらのアクションはリーダーインデックスでのみ実行できます。

このチュートリアルは、データの取り込み元としてLogstashを使用します。Logstashの機能を活用し、ElasticsearchへのLogstash出力を指定されたホストの配列にわたって負荷分散できます。BeatsおよびElastic Agentsは現在、複数の出力をサポートしていません。また、このチュートリアルでは、Logstashなしでトラフィックをリダイレクトするプロキシ（ロードバランサー）を設定することも可能です。

  • clusterAおよびclusterBでリモートクラスターを設定します。
  • 除外パターンを使用して双方向クロスクラスター複製を設定します。

  • 災害時に自動負荷分散と切り替えを可能にするために、複数のホストでLogstashを設定します。

    双方向クロスクラスター複製のフェイルオーバーとフェイルバック

初期設定

  • 1. 両方のクラスターでリモートクラスターを設定します。

Python

  1. resp = client.cluster.put_settings(
  2.    persistent={
  3.    "cluster": {
  4.    "remote": {
  5.    "clusterB": {
  6.    "mode": "proxy",
  7.    "skip_unavailable": True,
  8.    "server_name": "clusterb.es.region-b.gcp.elastic-cloud.com",
  9.    "proxy_socket_connections": 18,
  10.    "proxy_address": "clusterb.es.region-b.gcp.elastic-cloud.com:9400"
  11.    }
  12.    }
  13.    }
  14.    },
  15.   )
  16.   print(resp)
  18.   resp1 = client.cluster.put_settings(
  19.    persistent={
  20.    "cluster": {
  21.    "remote": {
  22.    "clusterA": {
  23.    "mode": "proxy",
  24.    "skip_unavailable": True,
  25.    "server_name": "clustera.es.region-a.gcp.elastic-cloud.com",
  26.    "proxy_socket_connections": 18,
  27.    "proxy_address": "clustera.es.region-a.gcp.elastic-cloud.com:9400"
  28.    }
  29.    }
  30.    }
  31.    },
  32.   )
  33.   print(resp1)

Ruby

  1. response = client.cluster.put_settings(
  2.    body: {
  3.    persistent: {
  4.    cluster: {
  5.    remote: {
  6.    "clusterB": {
  7.    mode: 'proxy',
  8.    skip_unavailable: true,
  9.    server_name: 'clusterb.es.region-b.gcp.elastic-cloud.com',
  10.    proxy_socket_connections: 18,
  11.    proxy_address: 'clusterb.es.region-b.gcp.elastic-cloud.com:9400'
  12.    }
  13.    }
  14.    }
  15.    }
  16.    }
  17.   )
  18.   puts response
  20.   response = client.cluster.put_settings(
  21.    body: {
  22.    persistent: {
  23.    cluster: {
  24.    remote: {
  25.    "clusterA": {
  26.    mode: 'proxy',
  27.    skip_unavailable: true,
  28.    server_name: 'clustera.es.region-a.gcp.elastic-cloud.com',
  29.    proxy_socket_connections: 18,
  30.    proxy_address: 'clustera.es.region-a.gcp.elastic-cloud.com:9400'
  31.    }
  32.    }
  33.    }
  34.    }
  35.    }
  36.   )
  37.   puts response

Js

  1. const response = await client.cluster.putSettings({
  2.    persistent: {
  3.    cluster: {
  4.    remote: {
  5.    clusterB: {
  6.    mode: "proxy",
  7.    skip_unavailable: true,
  8.    server_name: "clusterb.es.region-b.gcp.elastic-cloud.com",
  9.    proxy_socket_connections: 18,
  10.    proxy_address: "clusterb.es.region-b.gcp.elastic-cloud.com:9400",
  11.    },
  12.    },
  13.    },
  14.    },
  15.   });
  16.   console.log(response);
  18.   const response1 = await client.cluster.putSettings({
  19.    persistent: {
  20.    cluster: {
  21.    remote: {
  22.    clusterA: {
  23.    mode: "proxy",
  24.    skip_unavailable: true,
  25.    server_name: "clustera.es.region-a.gcp.elastic-cloud.com",
  26.    proxy_socket_connections: 18,
  27.    proxy_address: "clustera.es.region-a.gcp.elastic-cloud.com:9400",
  28.    },
  29.    },
  30.    },
  31.    },
  32.   });
  33.   console.log(response1);

コンソール

  3. ### クラスターAでの設定 ###
  5. PUT _cluster/settings
  6.   {
  7.    "persistent": {
  8.    "cluster": {
  9.    "remote": {
  10.    "clusterB": {
  11.    "mode": "proxy",
  12.    "skip_unavailable": true,
  13.    "server_name": "clusterb.es.region-b.gcp.elastic-cloud.com",
  14.    "proxy_socket_connections": 18,
  15.    "proxy_address": "clusterb.es.region-b.gcp.elastic-cloud.com:9400"
  16.    }
  17.    }
  18.    }
  19.    }
  20.   }
  21.   ### クラスターBでの設定 ###
  22.   PUT _cluster/settings
  23.   {
  24.    "persistent": {
  25.    "cluster": {
  26.    "remote": {
  27.    "clusterA": {
  28.    "mode": "proxy",
  29.    "skip_unavailable": true,
  30.    "server_name": "clustera.es.region-a.gcp.elastic-cloud.com",
  31.    "proxy_socket_connections": 18,
  32.    "proxy_address": "clustera.es.region-a.gcp.elastic-cloud.com:9400"
  33.    }
  34.    }
  35.    }
  36.    }
  37.   }
  • 2. 双方向クロスクラスター複製を設定します。

Python

  1. resp = client.ccr.put_auto_follow_pattern(
  2.    name="logs-generic-default",
  3.    remote_cluster="clusterB",
  4.    leader_index_patterns=[
  5.    ".ds-logs-generic-default-20*"
  6.    ],
  7.    leader_index_exclusion_patterns="*-replicated_from_clustera",
  8.    follow_index_pattern="{{leader_index}}-replicated_from_clusterb",
  9.   )
  10.   print(resp)
  12.   resp1 = client.ccr.put_auto_follow_pattern(
  13.    name="logs-generic-default",
  14.    remote_cluster="clusterA",
  15.    leader_index_patterns=[
  16.    ".ds-logs-generic-default-20*"
  17.    ],
  18.    leader_index_exclusion_patterns="*-replicated_from_clusterb",
  19.    follow_index_pattern="{{leader_index}}-replicated_from_clustera",
  20.   )
  21.   print(resp1)

Js

  1. const response = await client.ccr.putAutoFollowPattern({
  2.    name: "logs-generic-default",
  3.    remote_cluster: "clusterB",
  4.    leader_index_patterns: [".ds-logs-generic-default-20*"],
  5.    leader_index_exclusion_patterns: "*-replicated_from_clustera",
  6.    follow_index_pattern: "{{leader_index}}-replicated_from_clusterb",
  7.   });
  8.   console.log(response);
  10.   const response1 = await client.ccr.putAutoFollowPattern({
  11.    name: "logs-generic-default",
  12.    remote_cluster: "clusterA",
  13.    leader_index_patterns: [".ds-logs-generic-default-20*"],
  14.    leader_index_exclusion_patterns: "*-replicated_from_clusterb",
  15.    follow_index_pattern: "{{leader_index}}-replicated_from_clustera",
  16.   });
  17.   console.log(response1);

コンソール

  3. ### クラスターAでの設定 ###
  5. PUT /_ccr/auto_follow/logs-generic-default
  6.   {
  7.    "remote_cluster": "clusterB",
  8.    "leader_index_patterns": [
  9.    ".ds-logs-generic-default-20*"
  10.    ],
  11.    "leader_index_exclusion_patterns":"*-replicated_from_clustera",
  12.    "follow_index_pattern": "{{leader_index}}-replicated_from_clusterb"
  13.   }
  15.   ### クラスターBでの設定 ###
  16.   PUT /_ccr/auto_follow/logs-generic-default
  17.   {
  18.    "remote_cluster": "clusterA",
  19.    "leader_index_patterns": [
  20.    ".ds-logs-generic-default-20*"
  21.    ],
  22.    "leader_index_exclusion_patterns":"*-replicated_from_clusterb",
  23.    "follow_index_pattern": "{{leader_index}}-replicated_from_clustera"
  24.   }

クラスター上の既存のデータは、パターンが一致しても_ccr/auto_followによって複製されません。この機能は、新しく作成されたバックインデックス（データストリームの一部）を複製するだけです。 

  1. `````follow_index_pattern`````は小文字の文字のみを許可します。  
  2. このステップは、UIに除外パターンがないため、Kibana UIを介して実行できません。このステップではAPIを使用してください。  
  3. - 3*.* Logstashの設定ファイルを設定します。  
  4. この例では、入力ジェネレーターを使用してクラスター内のドキュメント数を示します。このセクションを自分のユースケースに合わせて再構成してください。
  7. #### Logstash
  9. ``````logstash
  12. ### Logstashサーバーでの設定 ###
  14. ### これはLogstashの設定ファイルです ###
  15.   input {
  16.    generator{
  17.    message =    'Hello World'
  18.    count =    100
  19.    }
  20.   }
  21.   output {
  22.    elasticsearch {
  23.    hosts =    ["https://clustera.es.region-a.gcp.elastic-cloud.com:9243","https://clusterb.es.region-b.gcp.elastic-cloud.com:9243"]
  24.    user =    "logstash-user"
  25.    password =    "both_clusters_same_password"
  26.    }
  27.   }
  28. `

重要な点は、cluster Aがダウンしているとき、すべてのトラフィックが自動的にcluster Bにリダイレクトされることです。cluster Aが復旧すると、トラフィックは再びcluster Aに自動的にリダイレクトされます。これは、複数のESクラスターエンドポイントが配列[clusterA, clusterB]に指定されるオプションhostsによって実現されます。
この負荷分散機能を使用するには、両方のクラスターで同じユーザーに同じパスワードを設定してください。

  • 4. 以前の設定ファイルでLogstashを起動します。
    ``````sh

Logstashサーバーでの設定

bin/logstash -f multiple_hosts.conf

  1. - 5*.* データストリーム内のドキュメント数を観察します。  
  2. この設定により、各クラスターに`````logs-generic-default`````という名前のデータストリームが作成されます。両方のクラスターが稼働しているとき、Logstashは`````cluster A`````に50%のドキュメントを書き込み、`````cluster B`````に50%のドキュメントを書き込みます。  
  3. 双方向クロスクラスター複製により、各クラスターに`````-replication_from_cluster{a|b}`````のサフィックスを持つもう1つのデータストリームが作成されます。このステップの最後には:  
  4.   - クラスターAのデータストリームには:  
  5.     - `````logs-generic-default-replicated_from_clusterb`````に50ドキュメント  
  6.     - `````logs-generic-default`````に50ドキュメント     
  7.   - クラスターBのデータストリームには:  
  8.     - `````logs-generic-default-replicated_from_clustera`````に50ドキュメント  
  9.     - `````logs-generic-default`````に50ドキュメント     
  10. - 6*.* 両方のデータストリームを検索するためのクエリを設定する必要があります。`````logs*`````でのクエリは、どちらのクラスターでも合計100ヒットを返します。
  13. #### Python
  15. ``````python
  16. resp = client.search(
  17.    index="logs*",
  18.    size="0",
  19.   )
  20.   print(resp)

Ruby

  1. response = client.search(
  2.    index: 'logs*',
  3.    size: 0
  4.   )
  5.   puts response

Js

  1. const response = await client.search({
  2.    index: "logs*",
  3.    size: 0,
  4.   });
  5.   console.log(response);

コンソール

  1. GET logs*/_search?size=0

クラスターAがダウンしているときのフェイルオーバー

  • 1. どちらかのクラスターをシャットダウンすることでこれをシミュレートできます。このチュートリアルではcluster Aをシャットダウンします。
  • 2. 同じ設定ファイルでLogstashを起動します。（このステップは、Logstashが継続的に取り込む実際のユースケースでは必要ありません。）
    ``````sh

Logstashサーバーでの設定

bin/logstash -f multiple_hosts.conf

  1. - 3*.* すべてのLogstashトラフィックが自動的に`````cluster B`````にリダイレクトされることを観察します。  
  2. この間、すべての検索トラフィックを`````clusterB`````クラスターにリダイレクトする必要があります。  
  3. - 4*.* `````cluster B`````の2つのデータストリームには、異なる数のドキュメントが含まれています。  
  4.   - クラスターA（ダウン）のデータストリーム  
  5.     - `````logs-generic-default-replicated_from_clusterb`````に50ドキュメント  
  6.     - `````logs-generic-default`````に50ドキュメント     
  7.   - クラスターB（稼働中）のデータストリーム  
  8.     - `````logs-generic-default-replicated_from_clustera`````に50ドキュメント  
  9.     - `````logs-generic-default`````に150ドキュメント
  12. ## クラスターAが復旧したときのフェイルバック
  14. - 1*.* `````cluster A`````を再起動することでこれをシミュレートできます。  
  15. - 2*.* `````cluster A`````のダウンタイム中に`````cluster B`````に取り込まれたデータは自動的に複製されます。  
  16.   - クラスターAのデータストリーム  
  17.     - `````logs-generic-default-replicated_from_clusterb`````に150ドキュメント  
  18.     - `````logs-generic-default`````に50ドキュメント     
  19.   - クラスターBのデータストリーム  
  20.     - `````logs-generic-default-replicated_from_clustera`````に50ドキュメント  
  21.     - `````logs-generic-default`````に150ドキュメント     
  22. - 3*.* この時点でLogstashが稼働している場合、両方のクラスターにトラフィックが送信されることも観察できます。
  25. ## クエリによる更新または削除の実行
  27. ドキュメントを更新または削除することは可能ですが、リーダーインデックスでのみこれらのアクションを実行できます。  
  29. - 1*.* まず、更新したいドキュメントを含むバックインデックスを特定します。
  32. #### Python
  34. ``````python
  35. resp = client.search(
  36.    index="logs-generic-default*",
  37.    filter_path="hits.hits._index",
  38.    query={
  39.    "match": {
  40.    "event.sequence": "97"
  41.    }
  42.    },
  43.   )
  44.   print(resp)

Ruby

  1. response = client.search(
  2.    index: 'logs-generic-default*',
  3.    filter_path: 'hits.hits._index',
  4.    body: {
  5.    query: {
  6.    match: {
  7.    'event.sequence' => '97'
  8.    }
  9.    }
  10.    }
  11.   )
  12.   puts response

Js

  1. const response = await client.search({
  2.    index: "logs-generic-default*",
  3.    filter_path: "hits.hits._index",
  4.    query: {
  5.    match: {
  6.    "event.sequence": "97",
  7.    },
  8.    },
  9.   });
  10.   console.log(response);

コンソール

  3. ### いずれかのクラスターでの設定 ###
  5. GET logs-generic-default*/_search?filter_path=hits.hits._index
  6.   {
  7.   "query": {
  8.    "match": {
  9.    "event.sequence": "97"
  10.    }
  11.    }
  12.   }
  • ヒットが"_index": ".ds-logs-generic-default-replicated_from_clustera-<yyyy.MM.dd>-*"を返す場合、次のステップにcluster Aで進む必要があります。
    • ヒットが"_index": ".ds-logs-generic-default-replicated_from_clusterb-<yyyy.MM.dd>-*"を返す場合、次のステップにcluster Bで進む必要があります。
    • ヒットが"_index": ".ds-logs-generic-default-<yyyy.MM.dd>-*"を返す場合、検索クエリを実行した同じクラスターで次のステップに進む必要があります。
  • 2. クエリによる更新（または削除）を実行します:

Python

  1. resp = client.update_by_query(
  2.    index="logs-generic-default",
  3.    query={
  4.    "match": {
  5.    "event.sequence": "97"
  6.    }
  7.    },
  8.    script={
  9.    "source": "ctx._source.event.original = params.new_event",
  10.    "lang": "painless",
  11.    "params": {
  12.    "new_event": "FOOBAR"
  13.    }
  14.    },
  15.   )
  16.   print(resp)

Ruby

  1. response = client.update_by_query(
  2.    index: 'logs-generic-default',
  3.    body: {
  4.    query: {
  5.    match: {
  6.    'event.sequence' => '97'
  7.    }
  8.    },
  9.    script: {
  10.    source: 'ctx._source.event.original = params.new_event',
  11.    lang: 'painless',
  12.    params: {
  13.    new_event: 'FOOBAR'
  14.    }
  15.    }
  16.    }
  17.   )
  18.   puts response

Js

  1. const response = await client.updateByQuery({
  2.    index: "logs-generic-default",
  3.    query: {
  4.    match: {
  5.    "event.sequence": "97",
  6.    },
  7.    },
  8.    script: {
  9.    source: "ctx._source.event.original = params.new_event",
  10.    lang: "painless",
  11.    params: {
  12.    new_event: "FOOBAR",
  13.    },
  14.    },
  15.   });
  16.   console.log(response);

コンソール

  3. ### 前のステップで特定されたクラスターでの設定 ###
  5. POST logs-generic-default/_update_by_query
  6.   {
  7.    "query": {
  8.    "match": {
  9.    "event.sequence": "97"
  10.    }
  11.    },
  12.    "script": {
  13.    "source": "ctx._source.event.original = params.new_event",
  14.    "lang": "painless",
  15.    "params": {
  16.    "new_event": "FOOBAR"
  17.    }
  18.    }
  19.   }

ソフト削除がフォロワーに複製される前にマージされると、リーダーの履歴が不完全なため、次のプロセスは失敗します。詳細については、index.soft_deletes.retention_lease.periodを参照してください。