Apigee Edge 4.52.02 または 4.53.00 を 4.53.01 に更新する

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

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

更新を行えるユーザー

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

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

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

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

更新の前提条件

このバージョンでは、いくつかのセキュリティの問題に対処しました。これらのセキュリティ強化は不可欠ですが、後方互換性のない変更も導入されています。つまり、アップグレード中またはアップグレード後に中断が発生しないように、アップグレードに追加の手順が必要になります。詳細については、古い Private Cloud バージョンからバージョン 4.53.01 にアップグレードする際に、こちらのトピックをよくお読みください。

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

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

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

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

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

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

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

• Edge for Private Cloud 4.53.01 での IDP 鍵と証明書の構成
  

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

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

アップグレードで考慮すべき特別な手順

Edge for Private Cloud 4.53.01 にアップグレードするには、特定のソフトウェアをアップグレードするための特定の手順の実行を検討してください。必要な手順は現在のバージョンによって異なります。補足の手順が必要なソフトウェアについては、以下の表を参照し、それぞれの詳細な手順に沿って操作してください。必要なタスクを完了したら、メインのアップグレード手順に戻ってアップグレード プロセスを続行します。

バージョンに基づいて必要な手順を実行したら、メインのアップグレード手順に戻って続行します。

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

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

OpenLDAP 2.6 へのアップグレードが必須

Apigee Edge for Private Cloud の基盤となる LDAP サービスを以前の OpenLDAP 2.4 から OpenLDAP 2.6 にアップグレードする手順は次のとおりです。このアップグレードは、Apigee Edge for Private Cloud バージョン 4.53.01 以降への更新の必須要件です。このアップグレードは、シングル サーバー、アクティブ / パッシブ、アクティブ / アクティブ（マルチマスター）など、すべての Apigee LDAP デプロイ トポロジに適用されます。

前提条件と考慮事項

• LDAP アップグレード プロセス中は、管理 API と Apigee UI がすべてのリージョンで完全に利用できなくなることに注意してください。ユーザー、ロール、アプリ、組織の管理などのすべての管理タスクが失敗し、一時停止されます。API プロキシ トラフィックの処理に影響はありません。LDAP のアップグレードを続行する前に、すべての edge-management-server と edge-ui をシャットダウンしてください。

• バックアップは重要: 既存の LDAP データの完全で検証済みのバックアップは必須です。有効なバックアップがない状態で続行すると、データが復元できなくなります。LDAP データの整合性のある特定の時点のスナップショットをキャプチャするには、LDAP サービスが実行中にバックアップを開始する必要があります。実際のアップグレードを行うには、バックアップが必要です。バックアップがないと、アップグレードを実行することも、ロールバックすることもできません。アップグレード手順には LDAP データの消去が含まれているためです。

準備とインストール（すべての LDAP サーバー）

このセクションの手順（ステップ 2 ～ステップ 5）は、すべての LDAP デプロイ トポロジで同じです。これらのアクションは、ロールに関係なく、apigee-openldap コンポーネントがインストールされているすべてのサーバーで実行する必要があります。

1. LDAP のアップグレードを続行する前に、すべての edge-management-server と edge-ui をシャットダウンしてください。

   apigee-service edge-management-server stop
   apigee-service edge-ui stop

2. 既存の LDAP データをバックアップする

   変更を行う前に、すべての LDAP サーバーから現在の LDAP データの完全バックアップを実行します。これにより、安全な復元ポイントが作成されます。

   • バックアップ コマンドを実行します。このアクションにより、/opt/apigee/backup/openldap ディレクトリ内にタイムスタンプ付きのバックアップ アーカイブが作成されます。

     apigee-service apigee-openldap backup

   • レコードの合計数を取得する: アップグレード後の検証用に、ディレクトリ内のレコード数を取得します（レコード数はすべての LDAP サーバーで一致している必要があります）。これは健全性チェックです。

     # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
     ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
     -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l

3. LDAP を停止してデータ ディレクトリをクリーンアップする

   この手順は、すべての LDAP サーバーで実行する必要があります。メジャー バージョンの変更と基盤となる構造の違いにより、必須となっています。クリーンなディレクトリを使用すると、競合が発生しません。すべての LDAP サーバーが停止すると、Management API と UI の中断が始まります。

   • LDAP サービスを停止します。

     apigee-service apigee-openldap stop

   • 古い LDAP データ ディレクトリと構成ディレクトリを完全に削除します。

     rm -rf /opt/apigee/data/apigee-openldap/*

4. 新しい LDAP バージョンをインストールして構成する

   すべての LDAP サーバーで、標準の Apigee スクリプトを使用して新しいコンポーネント バージョンをダウンロードしてインストールします。

   • 新しい LDAP コンポーネントをインストールする: 更新スクリプトは構成ファイルを読み取り、新しい apigee-openldap パッケージをインストールします。

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

   • 新しい LDAP バージョンを検証する: インストールが完了したら、プロファイルを再読み込みし、新しい LDAP バージョンが正しくインストールされていることを確認します。

     source ~/.bash_profile
     ldapsearch -VV
     Expected output:
     ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7

5. データ復元前にすべてのサーバーで LDAP を停止する

   これは重要な同期ステップです。バックアップを復元する前に、新しくインストールした LDAP サービスがすべてのサーバーで停止していることを確認する必要があります。各 LDAP サーバーで、次のコマンドを実行します。

   apigee-service apigee-openldap stop
   rm -rf /opt/apigee/data/apigee-openldap/ldap/*

6. LDAP データを復元する

   戦略は、最初のアクティブ サーバーでバックアップを復元することです。このサーバーは信頼できる情報源として機能し、マルチサーバー設定でピアにデータを複製します。

   1. 復元する最初の有効なサーバーを特定する

      • 単一サーバーの設定の場合: これは唯一の LDAP サーバーです。次のステップに直接進んでください。
      • アクティブ / パッシブ設定とアクティブ / アクティブ設定の場合: 各 LDAP サーバーで次の診断コマンドを実行します。

        grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*\ldif
        Note:
        -If this command returns output, the server is a passive server.
        -If it returns no output, the server is the active server.

   2. バックアップ データを復元する

      続行する前に、すべての LDAP サーバーで手順 5 が正常に完了していることを再確認してください。

      • 上記で特定した最初のアクティブ サーバーで、バックアップ ディレクトリに移動します。

        cd /opt/apigee/backup/openldap

      • restore コマンドを実行します。意図しないバージョンや古いバージョンが復元されないように、ステップ 2 で取得したバックアップの正確なタイムスタンプを指定することを強くおすすめします。

        # To restore a specific backup (recommended):
        apigee-service apigee-openldap restore 2025.08.11,23.34.00
        
        # To restore the latest available backup by default:
        apigee-service apigee-openldap restore

      • 復元プロセスが正常に完了したら、最初のアクティブ サーバーで LDAP サービスを開始します。

        apigee-service apigee-openldap start

7. 残りの LDAP サーバーを起動する

   マルチサーバー設定の場合は、各 LDAP サーバーでサービスを開始します。

   apigee-service apigee-openldap start

8. 最終検証

   最後のステップは、アップグレードが正常に完了し、データが LDAP クラスタ全体で一貫していることを確認することです。

   • すべての LDAP サーバーで検証コマンドを実行します。レコード数はすべてのサーバーで同じである必要があり、手順 2 で取得した数と一致する必要があります。

   # Note: Replace 'YOUR_PASSWORD' with your LDAP manager password.
   ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" \
   -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l

   • データが正しく一貫していることを確認したら、LDAP のアップグレードは完了です。これで、組織の標準アップグレード手順に沿って、edge-management-server、edge-ui、その他の依存コンポーネントの起動に進むことができます。

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

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

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

• 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 コマンドが実行されました
   • 以前のアップグレード中に、drop_old_tables コマンドが Cassandra クラスタ全体で実行されました。

Edge for Private Cloud 4.52.02 を使用しているときに post_upgrade コマンドと drop_old_tables コマンドが Cassandra 3.11 で実行されたかどうか不明な場合は、4.53.01 へのアップグレードを試みる前に、これらのコマンドを安全に再実行できます。

ステップ 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.18 | 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.01 コンポーネントをすべてアップグレードする

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

Zookeeper 3.8.4 へのアップグレードが必須

このリリースの Edge for Private Cloud には、Zookeeper 3.8.4 へのアップグレードが含まれています。アップグレードの際に、すべての Zookeeper データが Zookeeper 3.8.4 に移行されます。

Zookeeper をアップグレードする前に、Zookeeper メンテナンス ガイドをお読みください。ほとんどの Edge 本番環境システムでは、複数のデータセンターに分散された Zookeeper ノードのクラスタを使用します。これらのノードの一部は、Zookeeper リーダーの選出に参加するボーターとして構成され、残りはオブザーバとして構成されます。詳細については、 リーダー、フォロワー、ボーター、オブザーバについてをご覧ください。ボーターノードはリーダーを選出し、その後、ボーターノード自体がフォロワーになります。

更新プロセス中に、リーダーノードがシャットダウンされると、Zookeeper への書き込みが一時的に遅延したり、失敗したりすることがあります。これは、プロキシのデプロイ オペレーションや、メッセージ プロセッサの追加や削除などの Apigee インフラストラクチャの変更など、Zookeeper に書き込む管理オペレーションに影響する可能性があります。以下の手順に沿って Zookeeper をアップグレードしている間は、Apigee のランタイム API に影響はありません（これらのランタイム API が管理 API を呼び出さない限り）。

大まかに、アップグレード プロセスでは各ノードのバックアップを作成します。次に、すべてのオブザーバーとフォロワーをアップグレードし、最後にリーダーノードをアップグレードします。

バックアップを作成する

ロールバックが必要になった場合に備えて、ZooKeeper のすべてのノードのバックアップを作成します。ロールバックすると、Zookeeper がバックアップ作成時の状態に復元されます。注: バックアップの取得以降に Apigee で行われたデプロイやインフラストラクチャの変更（Zookeeper に情報が保存されているもの）は、復元時に失われます。

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper backup

仮想マシンを使用している場合は、必要に応じて復元またはロールバックのために VM スナップショットまたはバックアップを作成することもできます。

リーダー、フォロワー、オブザーバを特定する

注: 以下のサンプル コマンドでは、nc ユーティリティを使用してデータを Zookeeper に送信します。別のユーティリティを使用して、データを Zookeeper に送信することもできます。

1. nc が ZooKeeper ノードにインストールされていない場合は、次のコマンドを使用してインストールします。

     sudo yum install nc

2. ノードで次の nc コマンドを実行します。ここで、2181 は ZooKeeper ポートです。

     echo stat | nc localhost 2181

   次のような出力が表示されます。

     Zookeeper version: 3.8.4-5a02a05eddb59aee6ac762f7ea82e92a68eb9c0f, built on 2022-02-25 08:49 UTC
     Clients:
      /0:0:0:0:0:0:0:1:41246[0](queued=0,recved=1,sent=0)
     
     Latency min/avg/max: 0/0.2518/41
     Received: 647228
     Sent: 647339
     Connections: 4
     Outstanding: 0
     Zxid: 0x400018b15
     Mode: follower
     Node count: 100597

   ノードに対する出力の Mode 行に、ノード構成に応じてオブザーバ、リーダー、フォロワー（リーダーではないボーター）が表示されます。注: ZooKeeper ノードが 1 つしかない Edge のスタンドアロン インストールでは、Mode は standalone に設定されます。

3. ZooKeeper ノードごとにステップ 1 と 2 を繰り返します。

オブザーバー ノードとフォロワー ノードで Zookeeper をアップグレードする

オブザーバー ノードとフォロワー ノードで、次のように Zookeeper をアップグレードします。

1. 外部インターネット接続があるノードで 4.53.01 に更新するの説明に沿って、Edge for Private Cloud 4.53.01 のブートストラップをダウンロードして実行します。このプロセスは、ノードに外部インターネット接続があるかどうか、またはオフライン インストールを実行しているかどうかによって異なる可能性があります。
2. Zookeeper コンポーネントをアップグレードします。

     /opt/apigee/apigee-setup/bin/update.sh -c zk -f <silent-config-file>

   注: これらのノードに他のコンポーネント（Cassandra など）がインストールされている場合は、今すぐ（cs、zk プロファイルなどを使用して）アップグレードすることも、他のコンポーネントを後でアップグレードすることもできます。Apigee では、まず ZooKeeper のみをアップグレードし、クラスタが正常に動作していることを確認してから、他のコンポーネントをアップグレードすることをおすすめします。
3. Zookeeper オブザーバー ノードとフォロワー ノードごとに上記の手順を繰り返します。

リーダーをシャットダウンする

すべてのオブザーバー ノードとフォロワー ノードがアップグレードされたら、リーダーをシャットダウンします。リーダーとして識別されたノードで、次のコマンドを実行します。

  /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop

このイベント中、新しいリーダーが選出される前に、Zookeeper で一時的な遅延や書き込みエラーが発生する可能性があります。これは、プロキシのデプロイ アクションや、メッセージ プロセッサの追加や削除などの Apigee インフラストラクチャの変更など、Zookeeper に書き込むオペレーションに影響する可能性があります。

新しいリーダーが選出されたことを確認する

上記のリーダー、フォロワー、オブザーバーを特定するの手順に沿って、既存のリーダーが停止した後に、フォロワーから新しいリーダーが選出されたことを確認します。リーダーは、現在のリーダーとは異なるデータセンターで選出されている可能性があります。

アップグレード リーダー

上記の オブザーバー ノードとフォロワー ノードで Zookeeper をアップグレードすると同じ手順を行います。

古いリーダーノードもアップグレードされたら、クラスタの健全性を確認し、リーダーノードがあることを確認します。

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

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

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

   /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 つずつ繰り返します。

Postgres 17 への必須アップグレード

Edge のこのリリースには、Postgres 17 へのアップグレードが含まれています。アップグレードの際に、すべての Postgres のデータが Postgres 17 に移行されます。

本番環境の Edge システムの場合、通常は 2 台の Postgres ノードでマスター / スタンバイのレプリケーションを構成します。更新の際、Postgres ノードはダウンしますが、分析データは Qpid ノードに書き込まれます。Postgres ノードが更新され、オンラインに復帰すると、分析データが Postgres ノードに送信されるようになります。

Postgres の更新方法は、Postgres ノードのデータ ストレージの構成方法によって異なります。

• Postgres ノードにローカルデータ ストレージを使用する場合は、アップグレード中に新しい Postgres スタンバイ ノードをインストールする必要があります。アップグレードが完了したら、新たに用意した Postgres スタンバイ ノードは廃止できます。

  なんらかの理由で更新をロールバックする場合は、Postgres スタンバイ ノードを追加する必要があります。更新をロールバックする必要がある場合は、ロールバック後に、新しい Postgres スタンバイ ノードがマスター Postgres ノードになります。そのため、新しい Postgres スタンバイ ノードをインストールする際は、Edge のインストール要件に定められた Postgres サーバーのハードウェア要件をすべて満たすノードにインストールする必要があります。

  Edge の 1 ノードまたは 2 ノード構成（プロトタイピングやテストに使用するトポロジ）では、Postgres ノードは 1 つだけです。このような Postgres ノードは、新しい Postgres ノードを作成せずに直接更新できます。

• Postgres ノードにネットワーク ストレージを使用している場合は、Postgres ノードを新しくインストールする必要はありません。この方法は Apigee からも推奨されています。以下の手順では、新しい Postgres スタンバイ ノードのインストールとその後の廃止の手順は省略できます。

  更新を始める前に、Postgres で使用されるデータストアのネットワーク スナップショットを取得します。更新の際になんらかのエラーが発生し、ロールバックを行う必要が生じた場合は、スナップショットから Postgres ノードを復元できます。

新しい Postgres スタンバイ ノードをインストールする

この手順では、新しいノードに Postgres のスタンバイ サーバーを作成します。新しい Postgres スタンバイ サーバーは、（バージョン 4.53.01 のものではなく）既存の Edge バージョン（4.52.02 または 4.53.00）のものをインストールしてください。

インストールには、Edge の現行バージョンのインストールに使用したものと同じ構成ファイルを使用します。

Postgres スタンバイ ノードを新たに作成するには:

1. 現在の Postgres マスターで、/opt/apigee/customer/application/postgresql.properties ファイルを編集して次のトークンを設定します。このファイルが存在しない場合は作成します。

   conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust\ \nhost replication apigee new_standby_ip/32 trust

   ここで、existing_standby_ip は現在の Postgres スタンバイ サーバーの IP アドレス、new_standby_ip は、新しいスタンバイ ノードの IP アドレスです。

2. Postgres マスターで apigee-postgresql を再起動します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

3. マスターの /opt/apigee/apigee-postgresql/conf/pg_hba.conf ファイルを表示して、新しいスタンバイ ノードが追加されたことを確認します。ファイルに次の行が確認できるはずです。

   host replication apigee existing_standby_ip/32 trust
   host replication apigee new_standby_ip/32 trust

4. 新しい Postgres スタンバイ サーバーをインストールします。
   1. 現在のバージョンの Edge をインストールする際に使用した構成ファイルを編集し、次の内容を指定します。

      # IP address of the current master:
      PG_MASTER=192.168.56.103
      # IP address of the new standby node
      PG_STANDBY=192.168.56.102

   2. Edge apigee-setup ユーティリティのインストールの説明に従って、SELinux を無効にします。

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

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

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

      2. Edge apigee-service ユーティリティと依存関係をインストールします。

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

      現在 Edge 4.53.00 を使用している場合:

      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 apigee-service ユーティリティと依存関係をインストールします。

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

   4. apigee-service を使用して apigee-setup ユーティリティをインストールします。

      /opt/apigee/apigee-service/bin/apigee-service apigee-setup install

   5. Postgres をインストールします。

      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile

   6. 新しいスタンバイ ノードで、次のコマンドを実行します。

      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

      スタンバイであることを確認します。

Postgres のインプレース アップグレードの実行

予備の手順

Postgres のインプレース アップグレードを行う前に、マスターホストとスタンバイの両方で次の手順を行い、apigee-postgresql の max_locks_per_transaction プロパティを更新します。

1. 存在しない場合は、/opt/apigee/customer/application/postgresql.properties ファイルを作成します。
2. このファイルの所有権を apigee に変更します。

   sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties

3. ファイルに次のプロパティを追加します。

   conf/postgresql.conf+max_locks_per_transaction=30000

4. apigee-postgresql を構成します。

   apigee-service apigee-postgresql configure

5. apigee-postgresql を再起動します。

   apigee-service apigee-postgresql restart

インプレース アップグレードを行う

Postgres 17 へのインプレース アップグレードを行うには、次の手順を行います。

1. マスターホストで postgres をアップグレードします。

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

2. マスターホストで setup コマンドを実行します。

   apigee-service apigee-postgresql setup -f /opt/silent.conf

3. マスターホストで configure コマンドを実行します。

   apigee-service apigee-postgresql configure

4. マスターホストを再起動します。

   apigee-service apigee-postgresql restart

5. マスターとして構成します。

   apigee-service apigee-postgresql setup-replication-on-master -f /opt/silent.conf

6. マスターホストが起動していることを確認します。

   apigee-service apigee-postgresql wait_for_ready

7. スタンバイを停止します。

   apigee-service apigee-postgresql stop

8. スタンバイをアップグレードします。

   注: このステップが失敗する場合やエラーになる場合、これは無視できることがあります。update.sh は、不適切な構成でスタンバイ サーバーを起動しようとします。インストールされている Postgres が 17 にアップグレードされていれば、エラーは無視できます。

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

9. スタンバイが停止していることを確認します。

   apigee-service apigee-postgresql stop

10. 古いスタンバイ構成を削除します。

    rm -rf /opt/apigee/data/apigee-postgresql/

11. スタンバイ サーバーでレプリケーションを設定します。

    apigee-service apigee-postgresql setup-replication-on-standby -f /opt/silent.conf

12. マスターホストとスタンバイの両方で、ファイル /opt/apigee/customer/application/postgresql.properties から行 conf/postgresql.conf+max_locks_per_transaction=30000 を削除します。この行は準備手順で追加されています。

この手順を完了すると、スタンバイが正常に開始されます。

Postgres ノードを廃止する

更新が完了したら、新たに用意したスタンバイ ノードを廃止します。

1. Postgres が実行中であることを確認します。

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

   Postgres が稼働していない場合は、起動します。

   /opt/apigee/apigee-service/bin/apigee-all start

2. 新しいスタンバイ ノードで次の curl コマンドを実行して、新しいスタンバイ ノードの UUID を取得します。

   curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

   出力結果の最後の行に、次の形式でノードの UUID が表示されます。

   "type" : [ "postgres-server" ],
   "uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"

3. 新しいスタンバイ ノードで、次のコマンドを実行して、新しいスタンバイ ノードを停止します。

   /opt/apigee/apigee-service/bin/apigee-all stop

4. Postgres マスターノードで /opt/apigee/customer/application/postgresql.properties を編集して、conf_pg_hba_replication.connection から新しいスタンバイ ノードを削除します。

   conf_pg_hba_replication.connection=host replication apigee existing_standby_ip/32 trust

5. Postgres マスターで、apigee-postgresql を再起動します。

   /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql restart

6. マスターの /opt/apigee/apigee-postgresql/conf/pg_hba.conf ファイルを表示して、新しいスタンバイ ノードが削除されたことを確認します。ファイルには、次の行だけが表示されます。

   host replication apigee existing_standby_ip/32 trust

7. Management Server ノードで、次の Edge 管理 API を呼び出して、ZooKeeper からスタンバイ ノードの UUID を削除します。

   curl -u sysAdminEmail:password -X DELETE http://ms_IP:8080/v1/servers/new_standby_uuid

Postgres のアップグレード後の手順

Postgres のメジャー アップグレード後、Postgres の内部統計情報が消去されます。これらの統計情報は、Postgres クエリ プランナーがクエリを実行するための最適なインデックスとパスを利用するのに役立ちます。

Postgres は、クエリの実行時や自動バキューム デーモンの実行時に、統計情報を徐々に再構築できます。ただし、統計情報が再構築されるまで、クエリが遅くなる可能性があります。

この問題を解決するには、マスター Postgres ノードのデータベース内のすべてのテーブルで ANALYZE を実行します。または、一度に複数のテーブルに対して ANALYZE を実行することもできます。

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

Edge for Private Cloud 4.53.01 では、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.01 のロールバックをご覧ください。

更新情報のロギング

デフォルトでは、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 のインストールに使用したものと同じである必要があります。

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

ノードで 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 または 4.53.00 を使用している場合:

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

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

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

      sudo bash /tmp/bootstrap_4.53.01.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 または 4.53.00 のインストール時に 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.01 のロールバックの手順に沿ってください。

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

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

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

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

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

1. Edge apigee-setup ユーティリティのインストールの「ローカルに Apigee リポジトリを作成する」の手順で 4.53.01 リポジトリをローカルに作成します。
2. .tar ファイルから apigee-service をインストールするには:
   1. ローカル リポジトリが存在するノードで次のコマンドを使用し、ローカル リポジトリを /opt/apigee/data/apigee-mirror/apigee-4.53.01.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.01.tar.gz

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

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

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

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

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

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

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

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

      sudo bash /tmp/bootstrap_4.53.01.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.52.02 または 4.53.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.01 のロールバックの手順に沿ってください。

マシンの更新順序

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

• 他のコンポーネントを更新する前に、すべての LDAP ノードを更新する必要があります。LDAP をアップグレードするには、特別な手順を行う必要があります。
• すべての Cassandra ノードと ZooKeeper ノードを更新する必要があります。4.52.02 からアップグレードする場合は、特別な手順に沿って cassandra をアップグレードします。4.52.02 または 4.53.00 の Zookeeper をアップグレードするには、特別な手順に沿って操作する必要があります。
• -c edge オプションを使用して、すべての Management Server と Router & Message Processor をアップグレードして更新する必要があります。
• Postgres をアップグレードするの特別な手順に沿って、すべての Postgres ノードをアップグレードする必要があります。
• すべてのデータセンターで edge-qpid-server コンポーネントと edge-postgres-server コンポーネントを更新する必要があります。
• すべての Qpid ノードをアップグレードする必要があります。
• Edge UI ノードをアップグレードし、新しい Edge UI ノードと SSO ノードもアップグレードする必要があります（該当する場合）。
• Monetization の更新に関して特別な手順はありません。これは -c edge オプションを指定した場合に更新されます。

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

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

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 の LDAP を更新します。

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

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

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

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

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

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

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

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

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

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

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

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

   /opt/apigee/apigee-setup/bin/update.sh -c ui -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. マシン 1 の Edge UI コンポーネントを再起動します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

9. 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

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

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

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

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

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

12. 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 の LDAP を更新します。

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

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

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

3. マシン 1、4、5（Management Server、Message Processor、Router）の順に Edge コンポーネントを更新します。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

11. 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. 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

2. 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

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

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

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

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

4. 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

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

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

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

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

6. 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

7. 新しい 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

8. 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

9. 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 をインストールしたときに作成した構成ファイルです。

10. マシン 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. LDAP
2. Cassandra
3. Zookeeper
4. 管理サーバー
5. Message Processor
6. ルーター
7. Postgres
8. Edge（すべてのノードの「-c edge」プロファイルを意味します。順序は Qpid Server ノード、Edge Postgres Server ノードの順です）。
9. qpidd
10. Edge UI（従来または新規の UI）
11. apigee-adminapi
12. Apigee SSO

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