Elasticsearch:インスタンスアーキテクチャのアップグレード

• バージョン要件:

  ソースバージョン	アップグレードのサポート	アップグレード後のバージョン	特別な要件
  6.7、6.8、7.10、または 7.16	サポート対象	変更なし	バージョン 6.7 および 6.8 の場合、クローズ状態のインデックスは存在できません。
  6.3、7.4、または 7.7	サポート対象	7.4 または 7.7: 7.10 にアップグレード 6.3: 6.8 にアップグレード	インデックスにはレプリカが必要です。 テクニカルサポートに連絡して、インスタンスをホワイトリストに追加してください。
  5.5 または 5.6	サポート対象外	-	-

• アップグレード方法: v1 または v2 インスタンスを v3 アーキテクチャに手動または自動でアップグレードできます。

• 仕様の制限: 次の仕様の v1 または v2 インスタンスではアップグレードはサポートされていません: 1 コア 2 GB、2 コア 2 GB、4 コア 4 GB、8 コア 8 GB、12 コア 12 GB、または 16 コア 16 GB。

• リージョンの制限: アップグレードは同じリージョン内でのみサポートされます。v1 または v2 インスタンスと v3 インスタンスは同じリージョンにある必要があります。

• 機能の制限: v1 または v2 インスタンスで次の機能が有効になっている場合、アップグレードはサポートされません:

  • コア機能: クラスター間レプリケーション (CCR)、、インスタンス間ネットワーク接続、高可用性 (HA) 、アプリケーションパフォーマンス管理 (APM) 、または Logstash。

  • 拡張機能: スケーラビリティ (自動スケーリングなど) または Nginx リバースプロキシ。

  • ストレージ属性: OpenStore (Advanced Edition) が有効になっているか、ローカルディスクが使用されています。

  • 基本要件: X-Pack 機能が無効になっている。

  • ゾーン: プライマリゾーンが v3 アーキテクチャでサポートされているゾーンのリストに含まれていない。

• 操作の制限: アップグレード中は、すべてのインスタンス変更操作が禁止されます。事前にビジネスの準備を完了してください。

• アップグレードプロセスと期間:

  • アップグレードは、スケジュールされた期間中にブルーグリーンデプロイメントを使用して実行されます。クラスターのトポロジーには一時的に 2 倍のノード数が表示されます。追加料金は発生しません。

  • アップグレード期間はデータ量に比例し、通常は数時間かかります。古いノードは、設定した運用保守 (O&M) ウィンドウ中にオフラインになります。このプロセスにより、約 1〜2 秒のサービス中断が発生します。

    v1 から v3 にアップグレードする場合、ネットワーク隔離フェーズ中にクラスターが 2 回再起動されるため、合計期間が長くなります。

ステップ 1: アップグレードタスクの作成

1. オンラインアップグレードページに移動します。

   1. Alibaba Cloud Elasticsearch コンソールにログインします。

   2. 左側のナビゲーションウィンドウで、[Cloud Native PaaS For Elastic Stack] > [Elasticsearch Online Migration Tool] を選択して、オンラインアップグレードページに移動します。

2. [作成] をクリックしてアップグレードタスクを作成し、そのパラメーターを設定します。

   パラメーター	説明
   タイプ	[Alibaba Cloud インスタンスアーキテクチャのアップグレード] を選択します。このタイプは、v1 または v2 インスタンスを v3 アーキテクチャにアップグレードし、データ移行を完了するために使用されます。
   クラスター	ターゲットリージョンでアップグレードする v1 または v2 インスタンスを選択します。

3. [OK] をクリックしてタスクを作成します。

ステップ 2: アップグレードタスクの設定と実行

このステップでは、ページの手順に従ってアップグレードタスクを設定し、データ移行を完了します。

1. アップグレードチェックを実行し、マージを設定します。

   [ソースクラスターとターゲットクラスターの設定] タブで、次の手順に従ってアップグレードの実現可能性を確認し、マージを設定します。

   1. 実現可能性チェック: アップグレードの前に、システムはソースクラスターに対してヘルスチェックとセキュリティチェックを自動的に実行し、アップグレードが安全で実現可能であることを確認します。

      説明

      • ソースクラスターが不健康であるか、クラスターの使用率が高すぎる場合は、アップグレードを続行しないでください。

      • ソースクラスターに X-Pack がない場合、アップグレードはサポートされません。

      実現可能性チェックが失敗した場合は、ページに表示されるプロンプトに従って構成を変更してください。

   2. マージの設定: システムは、レプリカ数、シャーディングポリシー、ユーザー権限設定など、ソースクラスターの構成パラメーターを自動的に検出します。その後、システムはこの構成に基づいてターゲットクラスターを作成します。このプロセスにより、ソースクラスターとターゲットクラスターの構成パラメーター、リソース割り当て、およびシャーディングポリシーがシームレスに同期され、スムーズなアップグレードと効率的な操作が保証されます。

      説明

      このステップには約 20 分かかります。

2. データを移行します。

   [データ移行] タブで、図の手順に従ってクラスターをマージし、レプリカを移行し、マスターノードを移行し、プライマリシャードを移行します。

   操作	説明	注意
   クラスターのマージ	システムはソースクラスターとターゲットクラスターを単一の大きなクラスターにマージします。マージ後、クラスター内のノードの総数 = ソースクラスター内のノード数 + ターゲットクラスター内のノード数 となります。	クラスターがマージされると、ターゲットクラスターの Kibana は一時的にシャットダウンされます。データ移行中も、サービスの切り替えが完了するまでソースクラスターの Kibana を使用できます。
   レプリカの移行	システムは、インデックスのレプリカシャードをソースクラスターのノードからターゲットクラスターのノードに移行します。	レプリカの移行中に予期しない障害が発生した場合やビジネスに影響が出た場合は、ロールバックを実行できます。ロールバック後、現在のアップグレードタスクは続行できません。新しいアップグレードタスクを作成する必要があります。
   マスターノードの移行	システムは、マージされたクラスター内のマスターノードをソースクラスターからターゲットクラスターに移行します。	マスターノードの移行はすぐに開始され、いかなるシナリオでもロールバックできません。注意して進めてください。 説明 バージョン 7.x 以降のインスタンスの場合、マスターノードは自動的にターゲットクラスター内のノードに切り替えられます。バージョン 5.x または 6.x のインスタンスの場合、自動スイッチオーバーはサポートされていません。代わりに、ネットワーク隔離が完了し、古いノードがオフラインになった後、新しいノードがマスターノードに昇格します。
   プライマリシャードの移行	システムは、生データを格納するプライマリシャードを、ソースクラスターのノードからターゲットクラスターのノードに移行します。	プライマリシャードの移行は、開始後にいかなるシナリオでもロールバックできません。注意して進めてください。

3. ネットワーク隔離を実行します。

   [サービスの切り替え] タブで、ページの手順に従ってネットワーク隔離をリクエストします。この操作により、ソースクラスターのノードがターゲットクラスターに参加できなくなります。ソースクラスターはサービスの提供を停止し、ターゲットクラスターが引き継ぎます。

4. アップグレードを完了します。

   ネットワーク隔離が成功すると、アップグレードタスクは完了です。[インスタンスリストへ移動] をクリックして、インスタンスの詳細を表示できます。

ステップ 3: データの検証

アーキテクチャのアップグレードとデータ移行が完了したら、Kibana コンソールからターゲットの v3 インスタンスにアクセスします。クエリを実行したり、書き込み操作を行ったりして、クラスターが期待どおりに動作することを確認できます。ご不明な点がある場合は、Alibaba Cloud Elasticsearch ヘルプデスクにお問い合わせください。