ロードバランサを使用したイベントサービスデータの移行

イベントサービス 4.5.x から 23.x への移行に必要な時間は、データ量によって異なる場合があります。したがって、差分データとメタデータを複数回に分けて移行して、イベントサービス 23.x でカットオーバー後のデータを最小限に抑えることをお勧めします。

イベントサービス 4.5.x ノードが DNS を使用している場合、データ移行が遅延し、データが失われる可能性があります。遅延時間は、設定したエージェントの数によって異なります。

はじめに

移行ユーティリティを使用する前に、次の手順を実行します。

1. analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar をダウンロードします。

   1. Enterprise Console 23.8.0 をインストールします。「Enterprise Console のインストール」を参照してください。
   2. events-service.zip ファイルを展開します。
   3. events-service/bin/migration に移動して、移行ユーティリティ jar を使用します。
2. JDK 17 および SQLite 3.x を、移行ユーティリティをダウンロードしたマシンにインストールします。SQLite は、移行ステータスをモニターするために役立ちます。

移行中は、この SQLlite データベース（dataMigration.db）に接続するツールを使用しないでください。 

移行のためのイベントサービス 4.5.x データの準備

1. $APPDYNAMICS_HOME/platform/events-service/processor/conf/events-service-api-store.yml に移動し、イベントサービス 4.5.x クラスタで次のプロパティを有効にします。

   ad.es.node.http.enabled=true

   CODE
   

   イベントサービス 4.5.x クラスタの各ノードでこの手順を繰り返します。

2. Enterprise Console からイベントサービス 4.5 ノードを再起動します。

3. イベントサービス 23.x で INDEX_COMPACTION_PARENT_JOB に対するジョブ圧縮を無効にします。

   curl -H 'Content-type: application/json' -XPOST 'http://<ELB_hostname_of_Events_Service_23.x>:<ElasticSearch_Port>/job_framework_job_details_v1/_update_by_query' -d '{
    "query": {
     "term": {
      "name": "INDEX_COMPACTION_PARENT_JOB"
     }
    },
    "script": {
     "inline": "ctx._source.jobDataMap.enabled = false",
     "lang": "painless"
    }
   }'

   CODE
   

   Elasticsearch の HTTP ポートは、対応するイベント サービス インスタンスの $APPDYNAMICS_HOME/platform/events-service/processor/conf/events-service-api-store.properties ファイルの ad.es.node.http.port プロパティで確認できます。

4. イベントサービス 23.x で、構成ファイル $APPDYNAMICS_HOME/platform/events-service/processor/conf/events-service-api-store.yml を編集して、カンマ区切りリストでプロパティ reindex.remote.whitelist を追加します。このリストの構成は次のとおりです。
   
   
   • Elasticsearch 2.x のロードバランサホスト名とポート。

   • Elasticsearch 8.x のロードバランサホスト名とポート。

     Syntax to Update reindex.remote.whitelist

     - className: com.appdynamics.analytics.processor.elasticsearch.configuration.ElasticsearchConfigManagerModule
       properties:
         nodeSettings:
           cluster.name: ${ad.es.cluster.name}
           reindex.remote.whitelist: "<ELB_hostname_of_Events_Service_4.5.x>:<Port>,<ELB_hostname_of_Events_Service_23.x>:<Port>,<node1_hostname_of_Events_Service_4.5.x>:<Port>,<node2_hostname_of_Events_Service_4.5.x>:<Port>"

     CODE

     Example

     reindex.remote.whitelist: "es2.elb.amazonaws.com:9200,es8.elb.amazonaws.com:9200,es2node1.amazonaws.com:9200,es2node2.amazonaws.com:9200,10.20.30.40:9200,10.20.30.41:9200,10.20.30.42:9200"

     CODE

5. 移行ユーティリティをダウンロードしたフォルダに application.yml ファイルを作成します。

   Folder Structure

   /home/username/
   	- analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar
   	- config
   		- application.yml

   CODE
   Click here to expand...

   Example: application.yml

   es:
     # Target Elasticsearch hostname and port for the data migration
     #(Get this from $APPDYNAMICS_HOME/platform/events-service/processor/conf/events-service-api-store.properties ad.es.node.http.port from events-service 23.x)
     targetHostName: es8.elb.amazonaws.com
     targetPort: 9200
    
     # Source Elasticsearch hostname and port for the data migration
     #(Get this from $APPDYNAMICS_HOME/platform/events-service/processor/conf/events-service-api-store.properties ad.es.node.http.port from events-service 4.x)
     sourceHostName: es2.elb.amazonaws.com
     sourcePort: 9200
    
     # Maximum number of retries per index during the migration
     maxRetriesPerIndex: 3
    
     # Delay in milliseconds between each retry attempt
     delayBetweenRetry: 2000
    
     # Set this to true if you want to use an external version for iteration 2 and subsequent,
     # or false if you want to use an internal version for migration.
     useExternalVersion: true
    
   clusters:
     source:
       api:
         keys:
           # Controller API key for the source Elasticsearch v2.x cluster
           #(Get this from $APPDYNAMICS_HOME/platform/events-service/processor/conf/events-service-api-store.properties ad.accountmanager.key.controller  from events-service 4.x)
           CONTROLLER: 12a12a12-12aa-12aa-a123-123a12a1a123
    
           # OPS API key for the source Elasticsearch v2.x cluster
           #(Get this from $APPDYNAMICS_HOME/platform/events-service/processor/conf/events-service-api-store.properties ad.accountmanager.key.ops  from events-service 4.x)
           OPS: "a1a12ab1-a12a-1a12-123a-a1234a12a123"
    
         # API hostname and port of the source events-service cluster
         # Get the port from the events-service-api-store.properties file ad.dw.http.port from events-service 4.x
         api: http://es2.elb.amazonaws.com:9080 
   
         # Provide the absolute path of the certificate (if needed) for the source events-service cluster
         cert: "/home/username/wildcart.crt"
    
         # Set this to true if you want to verify the hostname when creating the SSL context
         # or false to skip the hostname verification.
         check: false
    
       elasticsearch:
         # URL and internal URL of the source Elasticsearch v2.x cluster
         #(Get this from $APPDYNAMICS_HOME/appdynamics/platform/events-service/processor/conf/events-service-api-store.properties ad.es.node.http.port from events-service 4.x)
         url: http://es2.elb.amazonaws.com:9200
         internal: http://es2.elb.amazonaws.com:9200
    
         # Elasticsearch version of the source cluster (v2.x in this case)
         version: 2
    
         # Protocol to connect to the source Elasticsearch v2.x cluster (http)
         protocol: http
    
     destination:
       api:
         keys:
           # Controller API key for the destination Elasticsearch v8.x cluster
           # Get this from $APPDYNAMICS_HOME/appdynamics/platform/events-service/processor/conf/events-service-api-store.properties ad.accountmanager.key.controller from events-service 23.x
           CONTROLLER: 12a12a12-12aa-12aa-a123-123a12a1a123
    
           # OPS API key for the destination Elasticsearch v8.x cluster
           # Get this from $APPDYNAMICS_HOME/platform/events-service/processor/conf/events-service-api-store.properties ad.accountmanager.key.ops from events-service 23.x
           OPS: "a1a12ab1-a12a-1a12-123a-a1234a12a123"
    
         # API hostname and port of the destination events-service cluster (not Elasticsearch v8.x cluster)
         # Get the port from the events-service-api-store.properties file ad.dw.http.port from events-service 4.x
         api: "http://es8.elb.amazonaws.com:9080"
    
         # Provide the absolute path of the certificate (if needed) for the destination events-service cluster
         cert: "/home/username/wildcart.crt"
            
         # Set this to true if you want to verify the hostname when creating the SSL context
         # or false to skip the hostname verification.
         check: true
    
       elasticsearch:
         # URL and internal URL of the destination Elasticsearch v8.x cluster
         url: http://es8.elb.amazonaws.com:9200
         internal: http://es8.elb.amazonaws.com:9200
    
         # Elasticsearch version of the destination cluster (v8.x in this case)
         version: 8
    
         # Protocol to connect to the destination Elasticsearch v8.x cluster (http or https). If elasticsearch is SSL/TLS enabled, then use https scheme.
         protocol: http
    
         # Provide the absolute path of the .cer file.
         # (needed if https is enabled)
         trustStoreFile: "/home/username/client-ca.cer"
    
         # Elasticsearch username and password (if required) for the destination v8.x cluster
         # If the protocol is https, this is mandatory
         elasticsearchUsername: "elastic"
         elasticsearchPassword: "test123"
    
   migration:
     # Number of search hits per request during migration,
     search_hits: 5000
    
     # Number of concurrent reindex requests during migration (based on CPU cores), maximum value recommended is 8.
     reindex_concurrency: 4
    
     # Batch size for scrolling through search results during migration, reduce this if you hit the exception : Remote responded with chunk size
     reindex_scroll_batch_size: 5000
    
     # Number of reindex requests per second during migration
     reindex_requests_per_second: 8000
    
     # Threshold size in bytes for large rollovers during migration (60GB in this case). This value determines when the index rollover should occur depending on the anticipated ingestion speed and migration duration.
     # For example, if the migration tool is utilizing 4 reindex_concurrency threads and the migration takes 15 hours to complete on a 1 TB setup, and if the average ingestion speed is 3 GB per hour, then the index is expected to grow to approximately 45 GB by the end of the migration.
     # Set the value of "large_rollover_threshold_size_bytes" to 60 GB in this scenario. If any index exceeds 60 GB during migration, the migration tool will trigger a rollover.
     large_rollover_threshold_size_bytes: 60000000000
     
     
     # Threshold size in bytes for small rollovers during migration (20GB in this case). This value determines when the index rollover should occur depending on the anticipated ingestion speed and migration duration.
     # For example, if the migration tool is utilizing 4 reindex_concurrency threads and the migration takes 15 hours to complete on a 1 TB setup, and if the average ingestion speed is 1 GB per hour, then the index is expected to grow to approximately 15 GB by the end of the migration.
     # set the value of "small_rollover_threshold_size_bytes" to 20 GB in this scenario. If any index exceeds 20 GB during migration, the migration tool will trigger a rollover.
     small_rollover_threshold_size_bytes: 20000000000
     
     # Required low disk size watermark during migration (85% in this case)
     required_low_disk_size_watermark: 85
    
   #SQLite3 configuration for status monitoring
   spring:
     jpa:
       properties:
         hibernate:
           # Hibernate dialect for SQLite database
           dialect: org.hibernate.community.dialect.SQLiteDialect

   YML

カットオーバー方法を使用したイベントサービスデータの移行

移行ユーティリティは、最初に既存のイベントサービスデータをイベントサービス 4.5.x から 23.x クラスタに移行します。移行中にイベントサービス 4.5.x クラスタでデータまたはメタデータが収集されると、移行ユーティリティは次の処理を実行します。

1. タイムスタンプを使用して、差分データまたはメタデータを識別します
2. 差分をイベントサービス 23.x クラスタにコピーします。
3. 新しいデータとメタデータがイベントサービス 23.x クラスタに流れるようにします。

移行には、次のように設定された 2 つのロードバランサが必要です。

• ロードバランサ 1（LB1）は、イベントサービス 4.5.x ノードを指します。
• ロードバランサ 2（LB2）は、イベントサービス 23.x ノードを指します。
• コントローラ、EUM、およびエージェントは、LB1 を指します。

カットオーバー方法では、ロールバックオプションは提供されません。移行後にロールバックオプションが必要な場合は、「ロールバックオプションを使用したイベントサービスデータの移行」を参照してください。

要件に基づいて、次の移行方法のいずれかを使用できます。

• 方法 1：シンプルなカットオーバー手順で 2 つのロードバランサを使用する（推奨）。この方法では、カットオーバー後にデータを移行するためにイベントサービス 4.5.x ノードの IP アドレスを指定する必要があります。
• 方法 2：詳細なカットオーバー手順で 2 つのロードバランサを使用する。この方法では、カットオーバー後にデータを移行するために LB1 と LB2 の IP アドレスを指定する必要があります。そのため、カットオーバー後にイベントサービス 4.5.x クラスタをロードバランサに追加する必要があります。

方法 1：シンプルなカットオーバー手順で 2 つのロードバランサを使用する（推奨）

この方法には、2 つのロードバランサが必要です。カットオーバー後、データを移行するためにイベントサービス 4.5.x ノードの IP アドレスを指定する必要があります。

1. LB1 を送信元、LB2 を宛先として維持して、移行ユーティリティを実行します。
   

   1. イベントサービス 4.5.x インデックスをロールオーバーします。

      nohup java -jar analytics-on-prem-es2-es8-migration-23.7.0-243-exec.jar rollover > rollover_output.log 2>&1 &

      CODE

   2. データとメタデータをイベントサービス 4.5.x から 23.x に移行します。

      nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar data > data_output.log 2>&1 &
      nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar metadata > metadata_output.log 2>&1 &

      CODE

      

2. 差分をイベントサービス 4.5.x から 23.x ノードに移行します。

   nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar data > delta_data_output.log 2>&1 &
   nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar metadata > delta_metadata_output.log 2>&1 &

   CODE

   

   

   • イベントサービス 4.5.x の差分が最小になるまで、この手順を繰り返すことをお勧めします。ログを使用して、差分を移行するために各反復でどのくらいの時間がかかるかを判断します。反復にかかった合計時間が以前よりも大幅に短い場合は、イベントサービス 4.5.x クラスタの差分が減少したことを示します。最後の 2 回の反復で移行にほぼ同じ時間がかかる場合は、反復を停止できます。
     たとえば、反復で 30 秒かかり、前の反復でも 30 秒近くかかっている場合、差分は最小であると見なすことができます。
   • 差分の移行とカットオーバー移行後の時間差を短縮します。これにより、カットオーバー後に移行するデータが最小限に抑えられます。

   Example Log Excerpt

   2023-08-09T21:52:43.116+05:30  INFO 87453 --- [           main] c.a.analytics.onprem.MigrationTool       : Total time taken: 30 seconds

   CODE

   イベントサービス 4.5.x クラスタの差分が最小の場合は、イベントサービス 23.x ノードを LB1 に追加できます。これにより、カットオーバーフェーズが開始されます。
   

   

   アクティブなセッションまたはトランザクションがある場合、一部のデータが失われる可能性があります。

3. LB1 にイベントサービス 23.x ノードを追加します。この間、データはイベントサービス 23.x または 4.5.x ノードに流れることができます。

4. LB1 からイベントサービス 4.5.x ノードを削除し、カットオーバーを終了します。したがって、データはイベントサービス 23.x ノードにのみ流れます。

5. application.yml ファイルで、イベントサービス 4.5.x ノードのホスト名または IP アドレスを送信元として、LB1 をターゲットとして保持して、次のコマンドを実行します。

   nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar post_cutover_metadata > post_cutover_metadata_output.log 2>&1 &
   nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar post_cutover_data > post_cutover_data_output.log 2>&1 &

   CODE

   
   これで、イベントサービス 23.x クラスタが同期されました。

6. 移行ステータスを確認します。移行が成功した場合は、イベントサービス 4.5.x クラスタをデコミッションできます。

カットオーバー後にロードバランサをスワップしたり、application.yml ファイルを更新したりする必要がないため、この方法をお勧めします。

方法 2：詳細なカットオーバー手順で 2 つのロードバランサを使用する

この方法には、2 つのロードバランサが必要です。カットオーバー後、データを移行するには、LB1 と LB2 の IP アドレスをカットオーバー後に指定する必要があります。

1. LB1 を送信元、LB2 を宛先として維持して、移行ユーティリティを実行します。
   

   1. イベントサービス 4.5.x インデックスをロールオーバーします。

      nohup java -jar analytics-on-prem-es2-es8-migration-23.7.0-243-exec.jar rollover > rollover_output.log 2>&1 &

      CODE

   2. データとメタデータをイベントサービス 4.5.x から 23.x に移行します。

      nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar data > data_output.log 2>&1 &
      nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar metadata > metadata_output.log 2>&1 &

      CODE

      

2. 差分をイベントサービス 4.5.x から 23.x ノードに移行します。

   nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar data > delta_data_output.log 2>&1 &
   nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar metadata > delta_metadata_output.log 2>&1 &

   CODE

   

   

   • イベントサービス 4.5.x の差分が最小になるまで、この手順を繰り返すことをお勧めします。ログを使用して、差分を移行するために各反復でどのくらいの時間がかかるかを判断します。反復にかかった合計時間が以前よりも大幅に短い場合は、イベントサービス 4.5.x クラスタの差分が減少したことを示します。最後の 2 回の反復で移行にほぼ同じ時間がかかる場合は、反復を停止できます。
     たとえば、反復で 30 秒かかり、前の反復でも 30 秒近くかかっている場合、差分は最小であると見なすことができます。
   • 差分の移行とカットオーバー移行後の時間差を短縮します。これにより、カットオーバー後に移行するデータが最小限に抑えられます。

   Example Log Excerpt

   2023-08-09T21:52:43.116+05:30  INFO 87453 --- [           main] c.a.analytics.onprem.MigrationTool       : Total time taken: 30 seconds

   CODE

   イベントサービス 4.5.x クラスタの差分が最小の場合、カットオーバーフェーズを開始できます。

   

   アクティブなセッションまたはトランザクションがある場合、一部のデータが失われる可能性があります。

3. カットオーバーフェーズを開始するには、イベントサービス 23.x ノードを LB1 に追加します。この間、データはイベントサービス 23.x または 4.5.x ノードに流れることができます。

4. LB1 からイベントサービス 4.5.x ノードを削除し、カットオーバーを終了します。したがって、データはイベントサービス 23.x ノードにのみ流れます。

5. LB2 からイベントサービス 23.x ノードを削除します。

6. LB2 にイベントサービス 4.5.x ノードを追加します。

7. application.yml file で LB2 を送信元、LB1 をターゲットとして保持して、次のコマンドを実行します。

nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar post_cutover_metadata > post_cutover_metadata_output.log 2>&1 &
nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar post_cutover_data > post_cutover_data_output.log 2>&1 &

これで、イベントサービス 23.x クラスタが同期されました。移行ステータスを確認し、移行が成功した場合は、イベントサービス 4.5.x クラスタをデコミッションできます。

ロールバックオプションを使用したイベントサービスデータの移行

カットオーバー方法では、ロールバックオプションは提供されません。移行をロールバックするには、ミラーリング方法を使用する必要があります。この方法では、最新のデータをイベントサービス 4.5.x クラスタに複製し、最新のデータをイベントサービス 23.x クラスタに取り込みます。後で、イベントサービス 23.x クラスタを使用するか、イベントサービス 4.5.x クラスタにロールバックするかを決定できます。

イベントサービスクラスタ間でトラフィックをミラーリングおよびロードバランシングできる Web サーバーがあることを確認します。ミラーリング機能とロードバランシング機能を備えた NGINIX Web サーバーを使用することをお勧めします。

1. LB1 を送信元、LB2 を宛先として維持して、移行ユーティリティを実行します。
   

   1. イベントサービス 4.5.x インデックスをロールオーバーします。

      nohup java -jar analytics-on-prem-es2-es8-migration-23.7.0-243-exec.jar rollover > rollover_output.log 2>&1 &

      CODE

   2. データとメタデータをイベントサービス 4.5.x から 23.x に移行します。

      nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar data > data_output.log 2>&1 &
      nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar metadata > metadata_output.log 2>&1 &

      CODE

2. 差分をイベントサービス 4.5.x から 23.x ノードに移行します。

   nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar data > data_output.log 2>&1 &
   nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar metadata > metadata_output.log 2>&1 &

   JAVA

   

   
   

   

   イベントサービス 4.5.x の差分が最小になるまで、この手順を繰り返すことをお勧めします。ログを使用して、差分を移行するために各反復でどのくらいの時間がかかるかを判断します。反復にかかった合計時間が以前よりも大幅に短い場合は、イベントサービス 4.5.x クラスタの差分が減少したことを示します。最後の 2 回の反復で移行にほぼ同じ時間がかかる場合は、反復を停止できます。

   たとえば、反復で 30 秒かかり、前の反復でも 30 秒近くかかっている場合、差分は最小であると見なすことができます。

   2023-08-09T21:52:43.116+05:30  INFO 87453 --- [           main] c.a.analytics.onprem.MigrationTool       : Total time taken: 30 seconds

   CODE

   イベントサービス 4.5.x クラスタの差分が最小の場合、イベントサービスクラスタ間のミラーリングとロードバランシングのために NGINX を設定できます。

3. ミラーリングとロードバランシングのために NGINX Web サーバーを設定します。

   sudo yum install nginx
   sudo vi /etc/nginx/conf.d/mirror.conf

   CODE

   1. NGINX Web サーバーは LB2 を指します。

   2. NGINX Web サーバーはデータをイベントサービス 4.5.x にミラーリングします。

   3. LB1 は NGINX Web サーバーを指します。

      

      upstream backend {
          server es8-lb:9080;
      }
       
      upstream test_backend {
          server es2-node1:9080;
          server es2-node2:9080;
          server es2-node3:9080;
       }
       
       
      upstream backend_9081 {
          server es8-lb:9081;
      }
       
      upstream test_backend_9081 {
          server es2-node1:9081;
          server es2-node2:9081;
          server es2-node3:9081;
       }
       
      upstream backend_9200 {
          server es8-lb:9200;
      }
       
      upstream test_backend_9200 {
          server es2-node1:9200;
          server es2-node2:9200;
          server es2-node3:9200;
       }
       
      upstream backend_9300 {
          server es8-lb:9300;
      }
       
      upstream test_backend_9300 {
          server es2-node1:9300;
          server es2-node2:9300;
          server es2-node3:9300;
       }
       
      server {
          server_name nginx-instance;
          listen 9200;
       
          location / {
              mirror /mirror;
              proxy_pass http://backend_9200;
          }
       
          location = /mirror {
              internal;
              proxy_pass http://test_backend_9200$request_uri;
          }
      }
       
      server {
          server_name nginx-instance;
          listen 9300;
       
          location / {
              mirror /mirror;
              proxy_pass http://backend_9300;
          }
       
          location = /mirror {
              internal;
              proxy_pass http://test_backend_9300$request_uri;
          }
      }
       
      server {
          server_name nginx-instance;
          listen 9080;
       
          location / {
              mirror /mirror;
              proxy_pass http://backend;
          }
       
          location = /mirror {
              internal;
              proxy_pass http://test_backend$request_uri;
          }
      }
       
      server {
          server_name nginx-instance;
          listen 9081;
       
          location / {
              mirror /mirror;
              proxy_pass http://backend_9081;
          }
       
          location = /mirror {
              internal;
              proxy_pass http://test_backend_9081$request_uri;
          }
      }  
      

      CODE

4. application.yml ファイルで、イベントサービス 4.5.x クラスタ内の任意のノードを送信元として、イベントサービス 23.x クラスタ内の任意のノードをターゲットとして保持して、次のコマンドを実行します。

   

   ロードバランサを送信元またはターゲットとして使用しないでください。

   nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar post_cutover_metadata > post_cutover_metadata_output.log 2>&1 &
   nohup java -jar analytics-on-prem-es2-es8-migration-LATESTVERSION-exec.jar post_cutover_data > post_cutover_data_output.log 2>&1 &

   CODE

   

イベントサービス 4.5.x にロールバックする必要がある場合は、次の手順を実行します。

1. イベントサービス 4.5.x クラスタを LB1 に追加します。
2. LB1 から NGINX Web サーバーを削除します。

移行後にイベントサービス 23.x クラスタを引き続き使用するには、次の手順を実行します。

1. イベントサービス 23.x クラスタを LB1 に追加します。
2. LB1 から NGINX Web サーバーを削除します。

これで、イベントサービス 23.x クラスタが同期されました。移行ステータスを確認し、移行が成功した場合は、イベントサービス 4.5.x クラスタをデコミッションできます。