独自の ES クラスターをクラウドに移行するための完全なガイド

サービスをクラウドに移行する過程では、企業内で自社構築したミドルウェアなどのサービスの移行も必然的に必要になります。この記事では、自社構築の ES サービスをクラウドに移行するための移行ソリューションと、ビジネスシナリオに基づいて適切な移行ソリューションを選択する方法について説明します。

移行計画

1. OSSスナップショット

原則: OSS をトランジットストレージメディアとして使用し、elasticsearch-repository-oss プラグインを使用して 2 つのクラスターをリンクします。ソースクラスターはデータをバックアップし、ターゲットクラスターはデータを復元します (クラウドベンダーの管理対象 ES クラスターは、デフォルトで oss プラグインとともにインストールされます)。スナップショットモードなので、データの一貫性が保証され、データの復旧速度が速くなります。

OSS 移行の原則

移行手順の詳細

ソースクラスター

OSS バケットを作成し、ak、sk などの情報を設定します
自分で構築したクラスターに elasticsearch-repository-oss プラグインをインストールします。プラグインのバージョンがクラスターのバージョンと一致していることを確認します。
移行する必要があるインデックスのスナップショットを作成し、作成したウェアハウスにスナップショットをバックアップします。

ターゲットクラスター

スナップショットAPIを使用して、自分で構築したElasticsearchクラスターと同じスナップショットバックアップウェアハウスを作成します。
ウェアハウス内のバックアップされたスナップショットをターゲットクラスタに復元して、データ移行を完了します。
スナップショットが復元されたら、復元されたインデックスとインデックスデータを表示します。

予防

このソリューションでは、元のクラスターに同期プラグインをインストールする必要があります。プラグインにはバージョン互換性に関する大きな問題があります。バージョンの互換性については、プラグインのドキュメントを参照してください。
元のクラスターのバックアップは増分バックアップをサポートしており、比較的高速です。ターゲットクラスターは完全に復元されており、増分バックアップはサポートされていません。つまり、ターゲットクラスターが復元されるたびに、最初にインデックスが作成され、次にデータが復元されます (ターゲットクラスターに同じ名前のインデックスが存在することはできません。存在する場合、回復タスクは失敗します)。
OSS はプライマリパーティションのデータをバックアップし、リカバリプロセスでもプライマリパーティションのデータがバックアップされます。レプリカシャードのデータ復旧は、クラスターの内部復旧ロジックです。つまり、リカバリタスクが完了すると、コピーデータのリカバリ時間は含まれません。インデックスが書き込み一貫性を持つように構成されている場合は、正常に書き込みを行う前にレプリカが復元されるまで待機する必要があります。

2. ログスタッシュ

原則: Logstash は、両端で異なるデータソースを接続する単純なパイプラインです。その動作原理は、ソースデータ (入力) を読み取り、それを処理 (フィルター) し、ターゲットエンド (出力) に送信することです。この機能を使用すると、2 つのクラスターを接続してデータを移行できます。

Logstashの仕組み

移行手順の詳細

logstashをインストールして展開する
logstash パイプラインを設定して実行します。コア構成は以下のとおりです

input { elasticsearch { hosts => ["http://<自建Elasticsearch Master节点的IP地址>:9200"] user => "elastic" index => "*,-.monitoring*,-.security*,-.kibana*" password => "your_password" docinfo => true schedule => "*/30 * * * *" #每30分钟同步一次} } filter { } output { elasticsearch { hosts => ["http:<云资源暴露的endpoint地址>//:9200"] user => "elastic" password => "your_password" index => "%{[@metadata][_index]}" document_type => "%{[@metadata][_type]}" document_id => "%{[@metadata][_id]}" } }

予防

Logstash はインデックスの削除操作を認識できません。つまり、元のクラスター内のドキュメントデータが削除されても、ターゲットクラスターはそれに応じて削除されません。更新操作は同期をサポートします。

リアルタイム要件が低いシナリオに適しています。

ヒント:

ソースデータ ID とターゲットデータ ID の増分同期要件を確実に満たすには、logstash でスケジュールタスクを構成できます。
インデックスフィールドは正規表現と否定一致をサポートします。この機能を使用して、移行インデックスを制御できます。

3. elasticsearch-ダンプ

原理: これは比較的軽量なインデックス移行ツールです。基本的な原則は、入力と出力を定義し、元のクラスターからターゲットクラスターにクエリデータを書き込むことです。 logstash に似ていますが、データのフィルタリングはサポートされていません。

移行手順の詳細

elasticdump --input 元のクラスター es アドレス/インデックス --output ターゲットクラスター es アドレス/インデックス

# type：指定迁移的类型，支持mapping、、analyzer、data elasticdump \ --input=http://production.es.com:9200/my_index \ --output=http://staging.es.com:9200/my_index \ --type=data

予防

データ量が少なく、移行されたインデックスの数が少ないシナリオに適しています。対象クラスターインデックスが存在しない場合は、インデックス属性情報とアナライザー/マッピング/データなどのデータを移行する必要があります。
増分移行はサポートされておらず、移行ごとにダウンタイムが必要になります。また、同期効率が低く、操作手順が煩雑です。

4. クラスター間のオンライン統合

原理：自作クラスターとクラウドクラスターを 1 つの大規模クラスターに統合し、ES クラスターのシャード割り当てと移行機能を組み合わせることで、データ移行が完了します。

オンラインコンバージェンス移行ソリューション

移行手順の詳細

Fusion : まず、Tencent Cloud ES コンソールで、自作 ES クラスターと同じサイズの空のクラスターを申請する必要があります。これは、上の図 2 のターゲットクラスターです。次に、クラウド上のすべてのクラスターを再起動し、独自に構築した ES クラスターに追加して、2 つのクラスターを 1 つの大きなクラスターに統合します。
移行: 統合が完了したら、ES クラスターの cluster/settings の exclude 属性を設定してシャードを移行します。以下の API を実行すると、ES クラスターは、独自に構築したクラスターノード上のシャードをクラウド上のノードに自動的に段階的に削除します。これにより、シャードの再配置とクラスターデータの移行が完了します。
オフライン: 自作クラスターノード上のすべてのシャードが移行された後、自作クラスターノードはすべてシャットダウンされ、オフラインになり、クラスター全体のクラウドへの移行が完了します。以下の API を使用して、自作ノード上のシャード数が 0 かどうかを確認できます。

予防

クラウドベンダーがサポートしているかどうかによって制限されます（Tencent Cloud はサポートしていますが、Alibaba Cloud はサポートしていません）
独自に構築した ES クラスターのバージョンは、ターゲットクラスターのバージョンより大きくすることはできません。主な理由は、クラウド上のバージョンが低いクラスターノードを、バージョンが高い独自構築のクラスターに追加できないことです。また、バージョン番号については、2 つのクラスターのメジャーバージョン番号が一致していることが最適です。
自作 ES クラスターのプラグインは、クラウド ES クラスターのプラグインと一致している必要があります。同じクラスターに統合されるため、プラグインの互換性を保証する必要があります。
独自に構築された ES クラスターでは、セキュリティ認証を有効にできません。認証により統合が失敗する

5. 再インデックス

原則: reindex は ES によって提供される API インターフェイスであり、あるクラスターから別のクラスターにデータを移行できます。再インデックスの中核は、インデックス間およびクラスター間のデータ移行です。たとえば、インデックスシャードの 1 つが大きすぎる場合は、新しいインデックスを作成し、再インデックス API を使用してデータを移行できます。

移行手順の詳細

ターゲットクラスターは whilelist ホワイトリストを設定します。

 reindex.remote.whitelist: ["10.0.xx.xx:9200","10.15.xx.xx:9200","10.15.xx.xx:9200","10.15.xx.xx:9200"]

ターゲットクラスターは、再インデックス API を呼び出して移行タスクを構成します。

 POST _reindex { "source": { "remote": { "host": "http://xxx1:9200" }, "index": "test1" }, "dest": { "index": "test2" } }

予防

再インデックスでは、ターゲットインデックスの設定は試行されません。ソースインデックスの設定はコピーされません。 _reindex 操作を実行する前に、マッピング、シャード数、レプリカなどの設定を含め、ターゲットインデックスを設定する必要があります。
ソースデータのボリュームは小さく、移行速度の要件は高くありません。

6. クラスタ間レプリケーション CCR

仕組み: クロスクラスターレプリケーション (CCR) 機能を使用すると、1 つの ElasticSearch クラスターから 1 つ以上の ElasticSearch クラスターに特定のインデックスを複製できます。 CCR には、データセンター間のレプリケーションに加えて、データのローカリゼーションや、Elasticsearch クラスターから中央レポートクラスターへのデータのレプリケーションなど、他の多くのユースケースがあります。

注: バージョン 6.7 以降でサポートされている CCR は、プラチナ機能 (有料機能) です。