Apigee Edge 4.52.02 を 4.53.00 に更新する

Apigee は、Edge for Private Cloud をバージョン 4.52.02 からバージョン 4.53.00 に直接アップグレードすることをサポートしています。このページでは、このようなアップグレードを行う方法について説明します。

互換性のあるアップグレード パスの概要については、Edge for Private Cloud リリースのアップグレード互換性マトリックスをご覧ください。

更新を行えるユーザー

更新を行うユーザーは、最初に Edge をインストールしたユーザーまたは root ユーザーである必要があります。

Edge RPM をインストールした後は、すべてのユーザーがそれを構成できます。

更新する必要のあるコンポーネント

すべての Edge コンポーネントを更新する必要があります。Edge では、コンポーネントのバージョンが混在する設定はサポートされません。

更新の前提条件

Apigee Edge をアップグレードする前に、次の前提条件を確認してください。

• すべてのノードをバックアップする
  安全上の理由から、更新する前にすべてのノードの完全なバックアップを行うことをおすすめします。現在の Edge バージョンのバックアップ手順に沿ってください。

  これにより、新しいバージョンへの更新が失敗した場合に備えてバックアップ計画を立てることができます。バックアップの詳細については、バックアップと復元をご覧ください。

• Edge が動作していることを確認する
  次のコマンドを使用して、更新中に Edge が動作していることを確認します。

  /opt/apigee/apigee-service/bin/apigee-all status

• Cassandra の前提条件を確認する
  

  以前に Edge for Private Cloud の古いバージョンからバージョン 4.52.02 にアップグレードし、バージョン 4.53.00 にアップグレードする予定の場合は、Cassandra のアップグレード後の必要な手順を完了していることを確認してください。これらの手順は、バージョン 4.52.02 のアップグレード ドキュメントに記載されています。また、Cassandra アップグレードの前提条件にも記載されています。これらの手順が以前のアップグレードで完了したかどうか不明な場合は、バージョン 4.53.00 へのアップグレードに進む前に、再度完了してください。

• Edge for Private Cloud 4.53.00 で IDP 鍵と証明書を構成する
  

  Edge for Private Cloud 4.53.00 では、apigee-sso コンポーネントで使用される IDP 鍵と証明書がキーストアを介して構成されるようになりました。以前に使用した鍵と証明書をキーストアにエクスポートする必要があります。SSO コンポーネントを更新する前に、古いバージョンから Apigee SSO を更新する手順セクションの手順に沿って操作します。

• Python の要件
  アップグレードを試みる前に、Cassandra ノードを含むすべてのノードに Python 3 がインストールされていることを確認します。

プロパティ設定の自動伝播

/opt/apigee/customer/application にある .properties ファイルを編集してプロパティを設定した場合、それらの値は更新の際にも保持されます。

Edge-Router での Nginx 1.26 へのアップグレード

以前のバージョンから Edge for Private Cloud 4.53.00 にアップグレードしても、Nginx ソフトウェアは自動的に最新バージョン（1.26.x）にアップグレードされません。これは、Apigee Edge 4.53.00 の Nginx 1.26 の変更に記載されている変更の結果として、ランタイムで予期しない副作用が発生することを防ぐためです。下位環境で検証した後、Nginx を 1.20.x から 1.26.x に手動でアップグレードできます。手動でアップグレードするには:

1. エッジルーター ノードに最新の 4.53.00 ソフトウェアがあることを確認する

   /opt/apigee/apigee-service/bin/apigee-service edge-router version

2. 現在実行中の Nginx のバージョンを確認する

   /opt/nginx/sbin/nginx -V

   古いバージョンの Nginx を運用している場合は、次の手順に沿って、ルーターノードで Nginx をバージョン 1.26.X にアップグレードできます。

3. ルーターノードで edge-router プロセスを停止する

   /opt/apigee/apigee-service/bin/apigee-service edge-router stop

4. ルーターノードで nginx ソフトウェアをアップグレードする

   dnf update apigee-nginx

5. Nginx のバージョンが更新されていることを確認する

   /opt/nginx/sbin/nginx -V

6. ノードでルーター プロセスを開始する

   /opt/apigee/apigee-service/bin/apigee-service edge-router start

7. 各ルーターノードでこのプロセスを 1 つずつ繰り返します。

Cassandra 4.0.13 へのアップグレードが必須

Apigee Edge for Private Cloud 4.53.00 には、Cassandra のバージョン 4.0.13 へのアップグレードが含まれています。

アップグレードとロールバック

• Cassandra 3.11.X から Cassandra 4.0.X へのアップグレードはスムーズに実行できます。Edge for Private Cloud 4.53.00 でリリースされた Cassandra 4.0.X は、Private Cloud 4.52.02 のランタイム コンポーネントと管理コンポーネントと互換性があります。
• Cassandra 4.0.X から 3.11.X への直接のインプレース ロールバックはできません。レプリカまたはバックアップを使用してロールバックするのは複雑な手順であり、ダウンタイムやデータ損失が発生する可能性があります。問題をトラブルシューティングして Cassandra 4.0.X にアップグレードすることをおすすめします。
• アップグレードを試みる前に、ロールバック手順をよく理解しておくことが重要です。アップグレード中のロールバックのニュアンスを考慮することは、適切なロールバック パスを確保するために重要です。

単一データセンター

単一のデータセンター内で Cassandra を 3.11.X から 4.0.X にアップグレードするのはシームレスですが、ロールバックは複雑で、ダウンタイムやデータ損失が発生する可能性があります。本番環境のワークロードでは、アップグレードを開始する前に、新しいデータセンターで少なくとも Cassandra ノードを使用できるようにして、新しいデータセンターを追加することを強くおすすめします。これにより、データ損失や API トラフィックの中断を発生させることなく、Cassandra のロールバックが可能になります。この追加のデータセンターは、アップグレードが完了するか、チェックポイント 2 に達すると廃止できます。

新しいデータセンターの追加が実現不可能で、ロールバック機能が必要な場合は、Cassandra 3.11.X の復元にバックアップが必要になります。ただし、この方法ではダウンタイムとデータ損失の両方が発生する可能性があります。

複数のデータセンター

Edge for Private Cloud 4.52.02 で複数のデータセンターを運用すると、Edge for Private Cloud 4.53.00 へのアップグレード中にロールバックの柔軟性が向上します。

• ロールバックは、古い Cassandra バージョン（3.11.X）を実行しているデータセンターが少なくとも 1 つ存在することを前提としています。
• Cassandra クラスタ全体が 4.0.X にアップグレードされている場合は、Cassandra 3.11.X にロールバックしないでください。Private Cloud 4.53.00 または 4.52.02 の他のコンポーネントでは、引き続き新しい Cassandra バージョンを使用する必要があります。

推奨されるアップグレード方法

1. Cassandra データセンターを一度に 1 つずつアップグレードする: まず、単一のデータセンター内の Cassandra ノードを個別にアップグレードします。次のデータセンターに進む前に、1 つのデータセンター内のすべての Cassandra ノードのアップグレードを完了します。
2. 一時停止して検証する: 1 つのデータセンターをアップグレードしたら、一時停止して、プライベート クラウド クラスタ（特にアップグレードされたデータセンター）が正しく機能していることを確認します。
3. 注意: 以前の Cassandra バージョンにロールバックできるのは、古いバージョンを実行しているデータセンターが 1 つ以上ある場合のみです。
4. 時間依存性: 機能の検証のために短期間（数時間推奨）一時停止することはできますが、混合バージョン状態を無期限に維持することはできません。これは、Cassandra クラスタが均一でない（ノードのバージョンが異なる）と、運用上の制限があるためです。
5. 徹底的なテスト: 次のデータセンターをアップグレードする前に、パフォーマンスと機能の包括的なテストを行うことを強くおすすめします。すべてのデータセンターがアップグレードされると、以前のバージョンにロールバックすることはできません。

2 つのチェックポイント プロセスとしてのロールバック

1. チェックポイント 1: すべてのコンポーネントがバージョン 4.52.02 の初期状態。少なくとも 1 つの Cassandra データセンターが古いバージョンのままであれば、完全なロールバックが可能です。
2. チェックポイント 2: すべてのデータセンターのすべての Cassandra ノードが更新された後。この状態にロールバックすることはできますが、チェックポイント 1 に戻すことはできません。

例

2 つのデータセンター（DC）クラスタについて考えてみましょう。

1. 開始状態: 両方の DC の Cassandra ノードがバージョン 3.11.X です。他のすべてのノードは Edge for Private Cloud バージョン 4.52.02 にあります。DC ごとに 3 つの Cassandra ノードがあるとします。
2. DC-1 をアップグレードする: DC-1 の 3 つの Cassandra ノードを 1 つずつアップグレードします。
3. 一時停止して検証する: 一時停止して、クラスタ（特に DC-1）が正しく動作していることを確認します（パフォーマンスと機能を確認します）。DC-2 の Cassandra ノードを使用して、初期状態にロールバックできます。混合バージョンの Cassandra クラスタの制限により、この一時停止は一時的なものである必要があります。
4. DC-2 をアップグレードする: DC-2 の残りの 3 つの Cassandra ノードをアップグレードします。これが新しいロールバック チェックポイントになります。
5. 他のコンポーネントをアップグレードする: 通常どおり、すべてのデータセンターで管理ノード、ランタイム ノード、分析ノードを一度に 1 つのノードと 1 つのデータセンターずつアップグレードします。問題が発生した場合は、ステップ 4 の状態にロールバックできます。

Cassandra のアップグレードの前提条件

1. クラスタ全体が動作し、Cassandra 3.11.16 で完全に機能します。
2. 圧縮戦略が LeveledCompactionStrategy に設定されている（バージョン 4.52.02 へのアップグレードの前提条件）。
3. Edge for Private Cloud 4.52.02 で Cassandra 3.11 の初回アップグレードの一環として、次のすべての手順が完了していることを確認します。
   • 以前のアップグレード時に、各 Cassandra ノードで post_upgrade コマンドが実行されているはずです。
   • 以前のアップグレードで、Cassandra クラスタ全体で drop_old_tables コマンドが実行されている必要があります。

上記の手順が完了したかどうか不明な場合は、再度実行しても問題ありません。Edge for Private Cloud 4.52.02 の状態のまま、4.53.00 へのアップグレードを試みる前に、Cassandra 3.11 で次の手順が実行されていることを確認します。

1. 各 Cassandra ノードで、次の post_upgrade コマンドを 1 つずつ実行します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade

2. 次のコマンドを実行して、Cassandra クラスタから古い未使用のテーブルを削除します。このコマンドは、クラスタ内の 1 つのノードでのみ実行する必要があります。

   /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra drop_old_tables -f configFile

ステップ 1: アップグレードの準備をする

以下の手順は、コンポーネントのアップグレードを有効にするための Apigee の標準構成ファイルなど、通常作成する標準ファイルに加えて行うものです。

1. Apigee を使用して Cassandra をバックアップします。
2. Cassandra ノードの VM スナップショットを作成します（可能な場合）。
3. ポート 9042 が、Management Server、Message Processor、Router、Qpid、Postgres などのすべての Edge for Private Cloud コンポーネントから Cassandra ノードにアクセスできることを確認します（まだ構成されていない場合）。詳細については、ポートの要件をご覧ください。

ステップ 2: すべての Cassandra ノードをアップグレードする

すべての Cassandra ノードは、各データセンターで 1 つずつ、一度に 1 つのデータセンターで更新する必要があります。データセンター内のノードのアップグレードの間は、数分間待ってから、同じデータセンター内の別のノードのアップグレードに進みます。これにより、更新されたノードが完全に起動してクラスタに参加していることを確認できます。

データセンター内のすべての Cassandra ノードをアップグレードしたら、しばらく（30 分から数時間）待ってから、次のデータセンターのノードに進みます。この期間中に、更新されたデータセンターを徹底的に確認し、Apigee クラスタの機能とパフォーマンスの指標が維持されていることを確認します。この手順は、Cassandra がバージョン 4.0.X にアップグレードされ、残りの Apigee コンポーネントがバージョン 4.52.02 のままになっているデータセンターの安定性を確保するために不可欠です。

1. Cassandra ノードをアップグレードするには、次のコマンドを実行します。

   /opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile

2. ノードが更新されたら、ノードで次のコマンドを実行して、先に進む前にいくつかの検証を実行します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile

3. 上記を実行すると、次のような出力が得られます。

   Cassandra version is verified - [cqlsh 6.0.0 | Cassandra 4.0.13 | CQL spec 3.4.5 | Native protocol v5] 
   Metadata is verified

4. Cassandra ノードで次の post_upgrade コマンドを実行します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra post_upgrade

5. 次の nodetool コマンドを実行して、Cassandra ノードのインデックスを再構築します。

   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms api_products api_products_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_api_products_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_credentials app_credentials_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms app_end_user app_end_user_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_family_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_app_type_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_parent_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms apps apps_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms maps maps_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_consumer_key_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_access_tokens oauth_10_access_tokens_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_consumer_key_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_request_tokens oauth_10_request_tokens_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_10_verifiers oauth_10_verifiers_request_token_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_app_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_client_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_access_tokens oauth_20_access_tokens_refresh_token_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_client_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index kms oauth_20_authorization_codes oauth_20_authorization_codes_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect companies companies_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_company_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_developer_email_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect company_developers company_developers_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_email_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_organization_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index devconnect developers developers_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index cache cache_entries cache_entries_cache_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_operation_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_requesturi_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_responsecode_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_timestamp_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index audit audits audits_user_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis a_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_active_rev
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_index_template
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_def_method_template
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_latest_rev
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_a_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_base_url
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_active
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_is_latest
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rel_ver
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 apis_revision ar_rev_num
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_base_url
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_r_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_res_path
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 method m_rev_num
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_base_url
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_res_path
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 resource r_rev_num
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 schemas s_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 security sa_ar_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_a_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_entity
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template t_org_name
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index apimodel_v2 template_auth au_api_uuid
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index dek keys usecase_index

   収益化を使用している場合は、収益化キースペースに関連する次のインデックスの再構築コマンドも実行します。

   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_created_date_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint limits limits_updated_date_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_created_date_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_currency_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_dev_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_limit_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_prod_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_reason_code_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint suspended_developer_products suspended_developer_products_sub_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_company_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_created_at_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_developer_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_lastmodified_at_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index mint invitations invitations_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_env_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_job_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers triggers_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_class_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_group_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus job_details job_details_job_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus org_triggers org_triggers_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_group_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index taurus triggers_suite triggers_suite_suite_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_item notification_service_item_status_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_org_id_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_service_black_list_item notification_service_black_list_item_to_email_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_name_idx
   /opt/apigee/apigee-cassandra/bin/nodetool rebuild_index notification notification_email_template_item notification_email_template_item_org_id_idx

ステップ 3: すべての管理ノードをアップグレードする

すべてのリージョンのすべての管理ノードを 1 つずつアップグレードします。

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

ステップ 4: すべての Runtime ノードをアップグレードする

すべてのリージョンのすべての Router ノードと Message Processor ノードを 1 つずつアップグレードします。

/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

ステップ 5: 残りの Edge for Private Cloud 4.53.00 コンポーネントをすべてアップグレードする

すべてのリージョンで、残りの edge-qpid-server ノードと edge-postgres-server ノードを 1 つずつアップグレードします。

古いバージョンから Apigee SSO を更新する手順

Edge for Private Cloud 4.53.00 では、apigee-sso コンポーネントで使用される IDP 鍵と証明書がキーストアを介して構成されるようになりました。以前に使用した鍵と証明書をキーストアにエクスポートし、構成してから、通常どおり SSO の更新に進む必要があります。

1. IDP の構成に使用されている既存の鍵と証明書を特定します。

   1. SSO インストール構成ファイルで SSO_SAML_SERVICE_PROVIDER_CERTIFICATE の値を検索するか、apigee-sso コンポーネントに conf_login_service_provider_certificate をクエリして、証明書を取得します。

      SSO ノードで次のコマンドを使用して、IDP 証明書パスの apigee-sso をクエリします。出力の最後の行の値を確認します。

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

   2. SSO インストール構成ファイルで SSO_SAML_SERVICE_PROVIDER_KEY の値を検索するか、apigee-sso コンポーネントに conf_login_service_provider_key をクエリして、キーを取得します。

      SSO ノードで次のコマンドを使用して、IDP 鍵パスの apigee-sso をクエリします。出力の最後の行の値を確認します。

      apigee-service apigee-sso configure -search conf_login_service_provider_key

2. 鍵と証明書をキーストアにエクスポートします。
   1. 鍵と証明書を PKCS12 キーストアにエクスポートします。

      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      パラメータ:

      • certificate_path: 手順 1.a で取得した証明書ファイルのパス。
      • key_path: 手順 1.b で取得した秘密鍵ファイルのパス。
      • keystore_path: 証明書と秘密鍵を含む新しく作成されたキーストアのパス。
      • alias: キーストア内の鍵と証明書のペアに使用されるエイリアス。

      詳細については、OpenSSL のドキュメントをご覧ください。

   2. （省略可）鍵と証明書を PKCS12 から JKS キーストアにエクスポートします。

      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      パラメータ:

      • PKCS12_keystore_path: ステップ 2.a で作成した PKCS12 キーストアのパス。証明書と鍵が含まれています。
      • destination_keystore_path: 証明書と鍵がエクスポートされる新しい JKS キーストアのパス。
      • alias: JKS キーストア内の鍵と証明書のペアに使用されるエイリアス。

   詳しくは、keytool のドキュメントをご覧ください。

3. 出力されたキーストア ファイルの所有者を「apigee」ユーザーに変更します。

   sudo chown apigee:apigee <keystore_file>

4. Apigee SSO 構成ファイル に次のプロパティを追加し、キーストア ファイルのパス、パスワード、キーストア タイプ、エイリアスで更新します。

   # Path to the keystore file
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PATH=${APIGEE_ROOT}/apigee-sso/source/conf/keystore.jks
   
   # Keystore password
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_PASSWORD=Secret123  # Password for accessing the keystore
   
   # Keystore type
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_TYPE=JKS  # Type of keystore, e.g., JKS, PKCS12
   
   # Alias within keystore that stores the key and certificate
   SSO_SAML_SERVICE_PROVIDER_KEYSTORE_ALIAS=service-provider-cert 

5. 次のコマンドを使用して、通常どおり SSO ノードの Apigee SSO ソフトウェアを更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f /opt/silent.conf

新しい Edge UI

このセクションでは、Edge UI に関する注意事項を示します。詳細については、Private Cloud 用の新しい Edge UI をご覧ください。

Edge UI をインストールする

初期インストールが完了した後、Edge UI をインストールすることをおすすめします。Edge UI は、Apigee Edge for Private Cloud のデベロッパーと管理者向けの強化されたユーザー インターフェースです。

Edge UI では、Basic 認証を無効にし、SAML や LDAP などの IDP を使用する必要があります。

詳細については、新しい Edge UI をインストールするをご覧ください。

Apigee mTLS での更新

Apigee mTLS を更新する手順は次のとおりです。

• Apigee mTLS をアンインストールします。
• Apigee mTLS を再インストールします。

更新のロールバック

更新に失敗した場合は、問題の解決を試みた後で update.sh を再び実行できます。更新を複数回実行することができ、最後に終了したところから更新が続行されます。

失敗した結果、前のバージョンへのロールバックが必要になった場合の詳しい手順については、4.53.00 のロールバックをご覧ください。

更新情報のロギング

デフォルトでは、update.sh ユーティリティからのログ情報は次のファイルに書き込まれます。

/opt/apigee/var/log/apigee-setup/update.log

update.sh ユーティリティを実行しているユーザーにこのディレクトリへのアクセス権がない場合は、/tmp ディレクトリの update_username.log というファイルにログが書き込まれます。

ユーザーに /tmp へのアクセス権がない場合、update.sh ユーティリティは失敗します。

ゼロダウンタイムでの更新

ゼロダウンタイム更新（つまりローリング アップデート）により、Edge をダウンさせることなく、インストール済みの Edge を更新できます。

ゼロダウンタイム更新は、ノードが 5 つ以上の構成でのみ利用可能です。

ゼロダウンタイムでアップグレードする場合に重要となる点は、各 Router をロードバランサから一度に 1 台ずつ削除することです。削除した Router と、その同じマシンにあるすべてのコンポーネントを更新してから、Router をロードバランサに再び追加します。

1. マシンの更新順序に記載された正しい順序でマシンを更新してください。
2. Router を更新するときは、任意の Router を 1 つ選択し、サーバー（Message Processor または Router）のネットワーク到達性の有効化 / 無効化の説明に従ってその Router を到達不能な状態にします。
3. 選択した Router と、その同じマシンにある他のすべての Edge コンポーネントを更新します。すべての Edge 構成で、Router と Message Processor は同じノードにあります。
4. Router を到達可能な状態に戻します。
5. 残りの Router に対し、2 ～ 4 の手順を繰り返します。
6. インストール中の残りのすべてのマシンで更新を続行します。

更新の前後で次の点に注意してください。

• Router と Message Processor の共存ノード:
  • 更新前 - 次のことを行います。
    1. Router を到達不能な状態にします。
    2. Message Processor を到達不能な状態にします。
  • 更新後 - 次の作業を行います。
    1. Message Processor を到達可能な状態にします。
    2. Router を到達可能な状態にします。
• Router 単独のノード:
  • 更新前に、Router を到達不能な状態にします。
  • 更新後に、Router を到達可能な状態にします。
• Message Processor 単独のノード:
  • 更新前に、Message Processor を到達不能な状態にします。
  • 更新後に、Message Processor を到達可能な状態にします。

サイレント構成ファイルを使用する

サイレント構成ファイルを更新コマンドに渡す必要があります。サイレント構成ファイルは、Edge for Private Cloud 4.52.02 のインストールに使用したものと同じである必要があります。

外部インターネット接続があるノードで 4.53.00 に更新する

ノードで Edge コンポーネントを更新する手順は次のとおりです。

1. Cassandra の修復オペレーションを行う cron ジョブが設定されている場合は、更新が完了するまでそれらのジョブを無効にします。
2. ノードに root としてログインし、Edge RPM をインストールします。
3. Edge apigee-setup ユーティリティのインストールの説明に従って、SELinux を無効にします。
4. AWS にインストールする場合は、次の yum-configure-manager コマンドを実行します。

   yum update rh-amazon-rhui-client.noarch
   sudo yum-config-manager --enable rhui-REGION-rhel-server-extras rhui-REGION-rhel-server-optional

5. 現在 Edge 4.52.02 を使用している場合:

   1. Edge bootstrap_4.53.00.sh ファイルを /tmp/bootstrap_4.53.00.sh にダウンロードします。

      curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh

   2. 次のコマンドを実行して、Edge 4.53.00 の apigee-service ユーティリティと依存関係をインストールします。

      sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

      ここで、uName:pWord は Apigee から取得したユーザー名とパスワードです。pWord を省略すると、パスワードの入力を求められます。

      デフォルトでは、Java 1.8 がインストールされているかどうかが検査されます。インストールされていない場合は自動的にインストールされます。

      JAVA_FIX オプションを使用して、Java インストールの処理方法を指定できます。JAVA_FIX の有効な値は次のとおりです。

      • I: OpenJDK 1.8 をインストールします（デフォルト）。
      • C: Java をインストールせずに続行します。
      • Q: 終了。この場合、Java を自分でインストールする必要があります。
   3. 次の例のように、apigee-service を使用して apigee-setup ユーティリティを更新します。

      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update

   4. 次の例のように、Management Server で apigee-validate ユーティリティを更新します。

      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update

   5. 次の例のように、Management Server で apigee-provision ユーティリティを更新します。

      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update

   6. 次のコマンドを使用して、各ノードで update ユーティリティを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

      これはマシンの更新順序に記載された順に行います。

      ここで

      • component は更新する Edge コンポーネントです。有効な値は次のとおりです。
        • cs: Cassandra
        • edge: Edge UI 以外のすべての Edge コンポーネント。これには、Management Server、Message Processor、Router、QPID Server、Postgres Server が含まれます。
        • ldap: OpenLDAP
        • ps: postgresql
        • qpid: qpidd
        • sso: Apigee SSO（SSO がインストールされている場合）
        • ue: 新しい Edge UI
        • ui: 従来の Edge UI
        • zk: Zookeeper
      • configFile は、4.52.02 のインストール時に Edge コンポーネントの定義に使用したのと同じ構成ファイルです。

      component を「all」に設定すると、すべてのコンポーネントに対して update.sh を実行できますが、これが可能なのは Edge オールインワン（AIO）インストール プロファイルがある場合のみです。次に例を示します。

      /opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config

   7. Edge UI コンポーネントを実行しているすべてのノードで Edge UI コンポーネントを再起動します（まだ再起動していない場合）。

      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart

   8. インストールのテストの説明に従って Management Server で apigee-validate ユーティリティを実行し、更新をテストします。

後で更新をロールバックすることにした場合は、4.53.00 のロールバックの手順に沿ってください。

ローカル リポジトリから 4.53.00 に更新する

Edge ノードがファイアウォールの背後にあるか、インターネット経由での Apigee リポジトリ アクセスが禁止されている場合は、Apigee リポジトリのローカル リポジトリ（つまりミラー）から更新を行うことができます。

ローカル Edge リポジトリを作成した後、Edge をローカル リポジトリから更新する方法は 2 通りあります。

• リポジトリの .tar ファイルを作成してそれをノードにコピーし、.tar ファイルから Edge を更新します。
• ローカル リポジトリを持つノードにウェブサーバーをインストールし、他のノードからアクセスできるようにします。Apigee から提供されているウェブサーバーは Nginx ですが、他のウェブサーバーを使用してもかまいません。

ローカルの 4.53.00 リポジトリから更新するには:

1. Edge apigee-setup ユーティリティのインストールの「ローカルに Apigee リポジトリを作成する」の手順で 4.53.00 リポジトリをローカルに作成します。
2. .tar ファイルから apigee-service をインストールするには:
   1. ローカル リポジトリが存在するノードで次のコマンドを使用し、ローカル リポジトリを /opt/apigee/data/apigee-mirror/apigee-4.53.00.tar.gz という名前の単一の .tar ファイルにパッケージ化します。

      /opt/apigee/apigee-service/bin/apigee-service apigee-mirror package

   2. Edge を更新する対象のノードに .tar ファイルをコピーします。たとえば、新しいノードの /tmp ディレクトリにコピーします。
   3. 新しいノードで、.tar ファイルを /tmp ディレクトリに解凍します。

      tar -xzf apigee-4.53.00.tar.gz

      このコマンドにより、.tar ファイルが存在するディレクトリの中に repos という新しいディレクトリが作成されます。例: /tmp/repos

   4. /tmp/repos から Edge apigee-service ユーティリティと依存関係をインストールします。

      sudo bash /tmp/repos/bootstrap_4.53.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

      このコマンドには repos ディレクトリへのパスが含まれています。

3. Nginx ウェブサーバーを使用して apigee-service をインストールするには:
   1. Edge apigee-setup ユーティリティのインストールの「Nginx ウェブサーバーを使用してリポジトリからインストールする」の手順に沿って、Nginx ウェブサーバーを構成します。
   2. リモートノードで、Edge bootstrap_4.53.00.sh ファイルを /tmp/bootstrap_4.53.00.sh にダウンロードします。

      /usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh

      ここで、uName:pWord は上記の手順でリポジトリに設定したユーザー名とパスワード、remoteRepo はリポジトリ ノードの IP アドレスまたは DNS 名です。

   3. リモートノードで、Edge apigee-setup ユーティリティと依存関係をインストールします。

      sudo bash /tmp/bootstrap_4.53.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

      ここで、uName:pWord はリポジトリのユーザー名とパスワードです。

4. 次の例のように、apigee-service を使用して apigee-setup ユーティリティを更新します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-setup update 

5. 次の例のように、Management Server で apigee-validate ユーティリティを更新します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-validate update

6. 次の例のように、Management Server で apigee-provision ユーティリティを更新します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-provision update

7. マシンの更新順序に記載された順に、各ノードで update ユーティリティを実行します。

   /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

   ここで

   • component は更新する Edge コンポーネントです。通常は次のコンポーネントを更新します。
     • cs: Cassandra
     • edge: Edge UI 以外のすべての Edge コンポーネント。これには、Management Server、Message Processor、Router、QPID Server、Postgres Server が含まれます。
     • ldap: OpenLDAP
     • ps: postgresql
     • qpid: qpidd
     • sso: Apigee SSO（SSO がインストールされている場合）
     • ue 新しい Edge UI
     • ui: 従来の Edge UI
     • zk: Zookeeper
   • configFile は、4.50.00 または 4.51.00 のインストール時に Edge コンポーネントの定義に使用した構成ファイルです。

   component を「all」に設定すると、すべてのコンポーネントに対して update.sh を実行できますが、これが可能なのは Edge オールインワン（AIO）インストール プロファイルがある場合のみです。次に例を示します。

   /opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config

8. UI コンポーネントが実行されているすべてのノードで UI コンポーネントを再起動します（まだ再起動していない場合）。

   /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart

9. インストールのテストの説明に従って Management Server で apigee-validate ユーティリティを実行し、更新をテストします。

後で更新をロールバックすることにした場合は、4.53.00 のロールバックの手順に沿ってください。

マシンの更新順序

Edge のインストールにおいては、マシンを更新する順序が重要です。

• 他のノードを更新する前に、すべての Cassandra ノードと ZooKeeper ノードを更新する必要があります。
• 複数の Edge コンポーネント（Management Server、Message Processor、Router、QPID Server。ただし Postgres Server は該当しない）を搭載しているマシンでは、-c edge オプションを使用してすべてのコンポーネントを同時に更新します。
• 複数のマシンで行うよう指示されているステップは、指定されたマシン順に行ってください。
• Monetization の更新に関して特別な手順はありません。これは -c edge オプションを指定した場合に更新されます。

1 ノード スタンドアロン構成のアップグレード

1 ノード スタンドアロン構成を 4.53.00 にアップグレードするには:

1. すべてのコンポーネントを更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile

2. apigee-adminapi がインストールされている場合は、apigee-adminapi ユーティリティを更新します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

2 ノード スタンドアロン構成のアップグレード

2 ノード スタンドアロン構成では、次のコンポーネントを更新します。

Edge のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。

1. マシン 1 の Cassandra と ZooKeeper を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

2. マシン 2 の Postgres を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

3. マシン 1 の LDAP を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

4. マシン 2、1 の Edge コンポーネントを更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

5. マシン 2 の Qpid を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

6. マシン 1 の UI を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile

7. apigee-adminapi がインストールされている場合は、マシン 1 の apigee-adminapi ユーティリティを更新します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

8. Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   ここで、sso_config_file は SSO をインストールしたときに作成した構成ファイルです。

9. マシン 1 の Edge UI コンポーネントを再起動します。

   /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

5 ノード構成のアップグレード

5 ノード構成では、次のコンポーネントを更新します。

Edge のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。

1. マシン 1、2、3 の Cassandra と ZooKeeper を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

2. マシン 4 の Postgres を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

3. マシン 5 の Postgres を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

4. マシン 1 の LDAP を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

5. マシン 4、5、1、2、3 の Edge コンポーネントを更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

6. マシン 4 の Qpid を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

7. マシン 5 の Qpid を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

8. Edge UI を更新します。
   • 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の ui コンポーネントを更新します。

     /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile

   • 新しい Edge UI: 新しい Edge UI をインストールした場合は、該当するマシン（マシン 1 ではない場合があります）の ue コンポーネントを更新します。

     /opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf

9. apigee-adminapi がインストールされている場合は、マシン 1 の apigee-adminapi ユーティリティを更新します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

10. Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。

    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

    ここで、sso_config_file は SSO をインストールしたときに作成した構成ファイルです。

11. UI コンポーネントを再起動します。
    • 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の edge-ui コンポーネントを再起動します。

      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

    • 新しい Edge UI: 新しい Edge UI をインストールした場合は、該当するマシン（マシン 1 ではない場合があります）の edge-management-ui コンポーネントを再起動します。

      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

9 ノードクラスタ構成のアップグレード

9 ノードクラスタ構成では、次のコンポーネントを更新します。

Edge のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。

1. マシン 1、2、3 の Cassandra と ZooKeeper を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

2. マシン 8 の Postgres を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

3. マシン 9 の Postgres を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

4. マシン 1 の LDAP を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

5. マシン 6、7、8、9、1、4、5 の順に Edge コンポーネントを更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

6. マシン 6、7 の Qpid を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

7. マシン 1 の新しい UI（ue）または従来の UI（ui）を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

8. apigee-adminapi がインストールされている場合は、マシン 1 の apigee-adminapi ユーティリティを更新します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

9. Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   ここで、sso_config_file は SSO をインストールしたときに作成した構成ファイルです。

10. UI コンポーネントを再起動します。
    • 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の edge-ui コンポーネントを再起動します。

      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

    • 新しい Edge UI: 新しい Edge UI をインストールした場合は、該当するマシン（マシン 1 ではない場合があります）の edge-management-ui コンポーネントを再起動します。

      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

13 ノードクラスタ構成のアップグレード

13 ノードクラスタ構成では、次のコンポーネントを更新します。

Edge のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。

1. マシン 1、2、3 の Cassandra と ZooKeeper を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

2. マシン 8 の Postgres を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

3. マシン 9 の Postgres を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

4. マシン 4、5 の LDAP を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

5. マシン 12、13、8、9、6、7、10、11 の順に Edge コンポーネントを更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

6. マシン 12、13 の Qpid を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

7. マシン 6 と 7 の新しい UI（ue）または従来の UI（ui）を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

8. apigee-adminapi がインストールされている場合は、マシン 6、7 の apigee-adminapi ユーティリティを更新します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

9. Apigee SSO がインストールされている場合は、マシン 6、7 の Apigee SSO を更新します。

   /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   ここで、sso_config_file は SSO をインストールしたときに作成した構成ファイルです。

10. UI コンポーネントを再起動します。
    • 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 6 と 7 で edge-ui コンポーネントを再起動します。

      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

    • 新しい Edge UI: 新しい Edge UI をインストールした場合は、マシン 6 と 7 で edge-management-ui コンポーネントを再起動します。

      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

12 ノードクラスタ構成のアップグレード

12 ノードクラスタ構成では、次のコンポーネントを更新します。

Edge のトポロジとノード番号の一覧については、インストール トポロジをご覧ください。

1. Cassandra と ZooKeeper を更新します。
   1. データセンター 1 のマシン 1、2、3 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

   2. データセンター 2 のマシン 7、8、9 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile

2. Postgres を更新します。
   1. データセンター 1 のマシン 6 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

   2. データセンター 2 のマシン 12 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile

3. LDAP を更新します。
   1. データセンター 1 のマシン 1 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

   2. データセンター 2 のマシン 7 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile

4. Edge コンポーネントを更新します。
   1. データセンター 1 のマシン 4、5、6、1、2、3 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

   2. データセンター 2 のマシン 10、11、12、7、8、9 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile

5. qpidd を更新します。
   1. データセンター 1 のマシン 4、5 で、次の手順を実施します。
      1. マシン 4 の qpidd を更新します。

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

      2. マシン 5 の qpidd を更新します。

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

   2. データセンター 2 のマシン 10、11 で、次の手順を実施します。
      1. マシン 10 の qpidd を更新します。

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

      2. マシン 11 の qpidd を更新します。

         /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile

6. 新しい UI（ue）または従来の UI（ui）を更新します。
   1. データセンター 1 のマシン 1 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

   2. データセンター 2 のマシン 7 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile

7. apigee-adminapi がインストールされている場合は、apigee-adminapi ユーティリティを更新します。
   1. データセンター 1 のマシン 1 で、次のコマンドを実行します。

      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

   2. データセンター 2 のマシン 7 で、次のコマンドを実行します。

      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

8. Apigee SSO がインストールされている場合は、Apigee SSO を更新します。
   1. データセンター 1 のマシン 1 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   2. データセンター 2 のマシン 7 で、次のコマンドを実行します。

      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

   ここで、sso_config_file は SSO をインストールしたときに作成した構成ファイルです。

9. マシン 1 と 7 の新しい Edge UI（edge-management-ui）または従来の Edge UI（edge-ui）コンポーネントを再起動します。

   /opt/apigee/apigee-service/bin/apigee-service [edge-ui|edge-management-ui] restart

非標準構成の場合

標準外の構成で実装している場合は、次の順に Edge コンポーネントを更新します。

1. ZooKeeper
2. Cassandra
3. ps
4. LDAP
5. Edge（すべてのノードの「-c edge」プロファイルを意味します。順序は Qpid Server ノード、Edge Postgres Server ノード、Management Server ノード、Message Processor ノード、Router ノードの順です）。
6. qpidd
7. Edge UI（従来または新規の UI）
8. apigee-adminapi
9. Apigee SSO

更新が完了したら、Edge UI コンポーネントを実行しているすべてのマシンで Edge UI コンポーネントを再起動してください。