Google は AI 技術を使用して、コンテンツをご希望の言語に翻訳しています。AI 翻訳には誤りが含まれる場合があります。

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

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

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

更新を行えるユーザー

アップデートを実行するユーザーは、Edge を最初にインストールしたユーザーと同じか、root として実行するユーザーである必要があります。

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

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

すべての Edge コンポーネントを更新する必要があります。Edge は、複数のバージョンのコンポーネントを含む設定をサポートしていません。

事前資料

Edge for Private Cloud 4.54.00 で導入された変更に関する重要な情報については、次のトピックをご覧ください。

4.54.00 の変更点: アップグレード前に準備が必要な TLS と Java Callout の変更点を確認します。詳細については、4.54.00 の変更点をご覧ください。
デュアル Java ランタイムアーキテクチャ（Java 17 と Java 21）: 4.54.00 以降、Edge for Private Cloud は Java 8 のサポートを終了し、Java 17 または Java 21 でコンポーネントを実行します。詳細については、4.54.00 の変更点をご覧ください。
ブートストラップ中の Java の自動インストールなし: Edge for Private Cloud 4.54.00 には、Java インストールを検出する機能があり、Java 17 と 21 の両方がインストールされていることを検証します。
4.54.00 の新しい Edge UI: デフォルトの管理インターフェースとしての新しい Edge UI への移行と、Classic UI（edge-ui）の削除について説明します。詳細については、新しい Edge UI をご覧ください。
4.54.00 の Apigee SSO: 更新された SSO アーキテクチャと認証の構成変更について理解します。詳細については、Apigee SSO をご覧ください。
4.54.00 の Nginx 1.30: Edge Router での Nginx 1.30.x の自動アップグレード、ランタイムへの潜在的な影響、緩和手順を確認します。詳細については、Nginx 1.30 の変更点をご覧ください。

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

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

リリースノートと新機能を確認する

アップグレードプロセスを開始する前に、Edge for Private Cloud バージョン 4.54.00 のリリースノートに記載されているすべての新機能、動作の変更、廃止を十分に確認し、理解してください。
アップグレード中の Java バイナリの自動検出と共存: 標準のパッケージマネージャー（yum など）または標準の場所（/usr/lib/jvm や update-alternatives など）を使用して Java をインストールします。システム PATH で両方のバージョンを同時に構成する必要はありません。アップグレード前に Java 8 をアンインストールしないでください。Java 17 と Java 21 とともに Java 8 をインストールしたままにして、既存の Edge for Private Cloud 4.53.xx サービスが更新されるまで中断なく実行されるようにします。
すべてのノードをバックアップする

更新する前に、安全のため、すべてのノードの完全バックアップを実行することをおすすめします。現在の Edge バージョンのバックアップ手順に沿ってください。これにより、新しいバージョンへの更新が正常に機能しない場合に備えて、バックアッププランを用意できます。バックアップの詳細については、バックアップと復元をご覧ください。
サイレント構成ファイルのバックアップ

必要に応じてロールバックを容易にするため、Edge for Private Cloud 4.53.00 または 4.53.01 のサイレント構成ファイルのバックアップコピーが保持されていることを確認します。
Edge が実行されていることを確認する

更新プロセス中に Edge が稼働していることを確認するには、次のコマンドを使用します。
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Cassandra の前提条件を確認する

以前に Edge for Private Cloud の古いバージョンからバージョン 4.53.00（または 4.53.01）にアップグレードし、バージョン 4.54.00 にアップグレードする予定の場合は、Cassandra のアップグレード後の必要な手順を完了していることを確認してください。これらの手順は、バージョン 4.53.00（または 4.53.01）のアップグレードドキュメントに記載されています。また、Cassandra のアップグレードの前提条件にも記載されています。前回のアップグレード時にこれらの手順が完了したかどうかわからない場合は、バージョン 4.54.00 へのアップグレードに進む前に、もう一度これらの手順を完了してください。
apigee-monit を停止する: apigee-monit がノードで実行されている場合は、アップグレードする前に /opt/apigee/apigee-service/bin/apigee-service apigee-monit stop で停止します。これにより、アップグレード中に apigee-monit がコンポーネントを自動的に再起動するのを防ぐことができます。アップグレードが完了したら、apigee-service apigee-monit start で再度有効にします。

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

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

Router と Message Processor をアップグレードする

データセンター全体のすべての Router ノードと Message Processor ノードを 1 つずつアップグレードします。

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

Management Server をアップグレードする

データセンター全体のすべての Management Server ノードを 1 つずつアップグレードします。

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

OpenLDAP 2.6.10 にアップグレード

Edge for Private Cloud 4.54.00 では、OpenLDAP 2.6.10 が導入されています。このアップグレードは、シングルサーバー、アクティブ / パッシブ、アクティブ / アクティブ（マルチマスター）など、すべての Apigee OpenLDAP デプロイトポロジに適用されます。

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

LDAP を 4.53.00 から 4.54.00 にアップグレードする手順

前提条件と考慮事項

OpenLDAP 2.4 から 2.6.10 への移行プロセス（4.53.00 からアップグレードする場合）では、すべてのリージョンで管理 API と Apigee UI が使用できなくなることに注意してください。ユーザー、ロール、アプリ、組織の管理などのすべての管理タスクが失敗し、一時停止する必要があります。API プロキシトラフィックの処理には影響しません。LDAP の移行に進む前に、すべての edge-management-server インスタンスと edge-ui インスタンスをシャットダウンします。
バックアップが重要（4.53.00 からアップグレードする場合）: Edge for Private Cloud 4.53.00（OpenLDAP 2.4.46）からアップグレードする場合は、既存の LDAP データの完全で検証済みのバックアップが必須です。有効なバックアップがない状態で続行すると、復元不能なデータ損失が発生します。LDAP サービスがまだ実行されている間にバックアップを開始して、LDAP データの整合性のあるポイントインタイムスナップショットをキャプチャします。バックアップがないと、2.4 から 2.6.10 への移行を実行することも、ロールバックすることもできません。これは、4.53.00 の移行手順で以前の LDAP データディレクトリが消去されるためです。

Management Server と UI をシャットダウンする: バージョン 4.53.00 から LDAP 移行を続行する前に、すべての edge-management-server インスタンスと edge-ui インスタンスをシャットダウンします。
```
apigee-service edge-management-server stop
apigee-service edge-ui stop
```
既存の LDAP データをバックアップする: バージョン 4.53.00（OpenLDAP 2.4.46）からアップグレードする際に変更を行う前に、すべての LDAP サーバーから現在の LDAP データのフルバックアップを実行します。これにより、安全な復元ポイントが作成されます。（バージョン 4.53.01 から 4.54.00 にアップグレードする場合は、このバックアップ、停止、クリーンアップのシーケンスは必要ありません）。
- バックアップコマンドを実行します。この操作により、/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
```
LDAP を停止してデータディレクトリをクリーンアップします。この手順は、バージョン 4.53.00（OpenLDAP 2.4.46）からアップグレードする場合にのみ、すべての LDAP サーバーで実行します。バージョン 4.53.01（OpenLDAP 2.6.7）からアップグレードする場合は、LDAP を停止したり、/opt/apigee/data/apigee-openldap/* を削除したりしないでください。4.53.00 のアップグレードでは、メジャーバージョンの変更と基盤となるデータベースの構造の違いにより、このステップは必須です。すべての LDAP サーバーが停止すると、Management API と UI の中断が始まります。
- LDAP サービスを停止します。
```
apigee-service apigee-openldap stop
```
- 古い LDAP データと構成ディレクトリを完全に削除します。
```
rm -rf /opt/apigee/data/apigee-openldap/*
```
新しい LDAP バージョンをインストールして構成する: すべての LDAP サーバーで、標準の Apigee スクリプトを使用して新しいコンポーネントバージョンをダウンロードしてインストールします。
- 新しい LDAP コンポーネントをインストールする: 更新スクリプトが構成ファイルを読み取り、新しい apigee-openldap パッケージをインストールします。
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
- 新しい LDAP バージョンを検証する: インストールが完了したら、プロファイルを再読み込みし、新しい LDAP バージョン（2.6.10）がインストールされていることを確認します。
```
echo 'export PATH=/opt/symas/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile
ldapsearch -VV
```
  上記のコマンドの出力で、次のように LDAP バージョン 2.6.10 が確認されている必要があります。
```
Expected output:
ldapsearch: @(#) OpenLDAP: ldapsearch 2.6.10
```
データを復元する前に、すべてのサーバーで LDAP を停止します。バージョン 4.53.00（OpenLDAP 2.4.46）からアップグレードする場合のみ、ステップ 5、6、7 を実行します（ステップ 4 でバージョン 4.53.01 からインプレースアップグレードした場合、既存の LDAP データは保持され、アップグレードは完了しています）。4.53.00 からバックアップを復元する前に、新しくインストールされた LDAP サービスがすべてのサーバーで停止していることを確認してください。すべての LDAP サーバーで、次のコマンドを実行します。
```
apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/ldap/*
```
LDAP データを復元する: 最初の有効なサーバーでバックアップを復元する戦略です。このサーバーは信頼できる情報源として機能し、マルチサーバー設定でピアにデータを複製します。
1. 復元に使用する最初のアクティブサーバーを特定します。
  - 単一サーバーの設定の場合: これは唯一の LDAP サーバーです。次のステップに直接進んでください。
  - アクティブ / パッシブとアクティブ / アクティブのセットアップの場合: 各 LDAP サーバーで次の診断コマンドを実行します。
```
grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
```
    注:
    - 上記のコマンドが出力を返した場合、サーバーはパッシブサーバーです。
    - 出力が返されない場合、サーバーはアクティブサーバーです。
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
```
残りの LDAP サーバーを起動する: マルチサーバー設定の場合は、各 LDAP サーバーでサービスを起動します。
```
apigee-service apigee-openldap start
```
注: これらのピアサーバーでデータを手動で復元する必要はありません。起動時に、最初のサーバー（復元されたデータが含まれているサーバー）に接続し、レプリケーションを介してディレクトリ全体を自動的に同期します。
最終検証: 最後のステップは、アップグレードが成功したこと、および 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、その他の依存コンポーネントを起動できます。

LDAP を 4.53.01 から 4.54.00 にアップグレードする手順

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

新しい LDAP コンポーネントをインストールする: 更新スクリプトが構成ファイルを読み取り、新しい apigee-openldap パッケージをインストールします。
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
新しい LDAP バージョンを検証する: インストールが完了したら、プロファイルを再読み込みし、新しい LDAP バージョン（2.6.10）がインストールされていることを確認します。
```
echo 'export PATH=/opt/symas/bin:$PATH' >> ~/.bash_profile
source ~/.bash_profile
ldapsearch -VV
```
上記のコマンドの出力で、次のように LDAP バージョン 2.6.10 が確認されている必要があります。
```
Expected output:
ldapsearch: @(#) OpenLDAP: ldapsearch 2.6.10
```

New Edge UI と Apigee SSO（インストールされている場合）にアップグレードする

Apigee Edge for Private Cloud 4.54.00 では、従来の UI（edge-ui）が削除され、新しい Edge UI（edge-management-ui）に置き換えられます。設定で Apigee シングルサインオン（SSO）がインストールされて使用されているかどうかに応じて、次の 2 つのオプションのいずれかの手順を行います。

オプション 1: アップグレード UI（Apigee SSO なし）

このセクションは、既存の Edge for Private Cloud バージョン 4.53.00 または 4.53.01 のインストールで Apigee SSO（apigee-sso）が構成 / インストールされていない場合にのみ適用されます。

Edge for Private Cloud バージョン 4.54.00 のアップグレードプロセスの一環として、Classic UI（edge-ui）が削除されます。次のアップグレードコマンドを実行すると、UI ノードが従来の UI（edge-ui）から新しい Edge UI（edge-management-ui）に移行されます。

ステップ 1: 構成ファイルをバックアップする

開始する前に、すべての UI ノードで既存のサイレント構成ファイル（configFile）と /opt/apigee/customer/application/ ディレクトリのバックアップを実行します。

ステップ 2: 基本認証のサイレント構成ファイルを更新する

サイレント構成ファイル（/opt/silent.conf など）を編集し、基本認証用の次の New Edge UI プロパティを追加します。

# Authentication mode for New Edge UI (Basic Authentication - No Apigee SSO)
AUTH_MODE=basic

# Access configuration for the New Edge UI
MANAGEMENT_UI_PORT=3001
MANAGEMENT_UI_APP_ENV=OPDK
MANAGEMENT_UI_IP=MANAGEMENT_UI_NODE_IP #Replace MANAGEMENT_UI_NODE_IP with the IP address or hostname of the UI node.
MANAGEMENT_UI_SCHEME=http

ステップ 3: UI コンポーネントをアップグレードする

コンポーネント -c ue を指定して update.sh スクリプトを実行し、Classic UI（edge-ui）から新しい Edge UI（edge-management-ui）にアップグレードします。

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

ステップ 4: 新しい Edge UI のアップグレードを確認する

すべての UI ノードでアップグレードプロセスが正常に完了したら、バージョン 4.54.00 の新しい Edge UI が完全に動作し、アクセス可能であることを確認してください。

edge-management-ui サービスが実行されていることを確認します。
```
apigee-service edge-management-ui status
```
ブラウザを開き、次の URL に移動します。
```
http://MANAGEMENT_UI_NODE_IP:3001
```
確認したら、オプション 2: UI をアップグレードする（Apigee SSO を使用）をスキップして、Qpid への必須アップグレードに直接進みます。

オプション 2: UI をアップグレードする（Apigee SSO を使用）

このセクションは、Edge for Private Cloud 4.53.00 または 4.53.01 環境で Apigee SSO（apigee-sso） が構成 / インストールされている場合に使用します。

Apigee Edge for Private Cloud 4.54.00 の場合:

基盤となる Apigee SSO サービスは、以前の apigee-sso コンポーネントから apigee-openldap で管理される Apigee SSO に移行します。Edge for Private Cloud バージョン 4.53.00 または 4.53.01 で SSO が有効になっている場合、Apigee Edge for Private Cloud バージョン 4.54.00 にアップグレードする際は、このアップグレードが必須です。
4.53.x Classic UI（edge-ui）と SSO、4.53.x New Edge UI（edge-management-ui）と SSO の両方が、4.54.00 New Edge UI（edge-management-ui）と Apigee SSO にアップグレードされます。

新しい Apigee SSO の設計と、Management API を使用したユーティリティと自動化フローへの影響については、次の記事をご覧ください。
新しい Apigee SSO 構造について
SSO を使用したタスクの自動化

以下の統合されたエンドツーエンドの手順に沿って、UI と Apigee SSO の両方をクリーンにアップグレードします。構成手順の重複はありません。

ステップ 1: 構成ファイルをバックアップする

続行する前に、すべての UI ノードと SSO ノードで、既存のサイレント configFile と /opt/apigee/customer/application/ ディレクトリをバックアップします。

ステップ 2: 非推奨の UI/SSO 変数を削除し、サイレント構成ファイル（`configFile`）を更新する

新しい Edge UI をアップグレードして Apigee SSO モジュールを構成する前に、現在の 4.53.x UI の設定に基づいて、サイレント構成ファイル（configFile）を 1 つの手順で更新します。

非推奨の 4.53.x UI と SSO 変数を configFile から削除するか、コメントアウトします。

apigee-sso を使用して Classic UI（edge-ui）からアップグレードする場合: Classic UI と SSO 関連のプロパティを削除するか、コメントアウトします。

EDGEUI_SSO_ENABLED=y
EDGEUI_SSO_CLIENT_NAME=edgeui
EDGEUI_SSO_CLIENT_SECRET=edgeuisecret
EDGEUI_PUBLIC_URIS=
EDGEUI_SSO_CLIENT_OVERWRITE=y
EDGEUI_SSO_REGISTERD_PUBLIC_URIS=$EDGEUI_PUBLIC_URIS

apigee-sso を使用して新しい Edge UI（edge-management-ui）からアップグレードする場合: 非推奨の 4.53.x Classic UI、Shoehorn、SSO 関連のプロパティを削除またはコメントアウトします。

EDGEUI_SSO_ENABLED=y
EDGEUI_SSO_CLIENT_NAME=edgeui
EDGEUI_SSO_CLIENT_SECRET=edgeuisecret
EDGEUI_PUBLIC_URIS=
EDGEUI_SSO_CLIENT_OVERWRITE=y
EDGEUI_SSO_REGISTERD_PUBLIC_URIS=$EDGEUI_PUBLIC_URIS
EDGEUI_ENABLE_UNIFIED_UI=n
SHOEHORN_SCHEME=$MANAGEMENT_UI_SCHEME
SHOEHORN_IP=$MANAGEMENT_UI_IP
SHOEHORN_PORT=9000
CLASSIC_UI_SCHEME=http
CLASSIC_UI_PORT=9000
MANAGEMENT_UI_PUBLIC_URIS=http://Public_IP:3001
MANAGEMENT_UI_SSO_REGISTERD_PUBLIC_URIS=$MANAGEMENT_UI_PUBLIC_URIS
ROUTES_CLASSICUI=""
ROUTES_SHOEHORN=""

apigee-openldap ノードで次のコマンドを使用して、New Edge UI のマシンユーザーを作成します。次のステップでサイレント構成ファイル（configFile）にプロパティを定義するときに、まったく同じ認証情報を使用してください。詳細については、UI のマシンユーザーを作成するをご覧ください。
```
/opt/apigee/apigee-openldap/bin/apigee-machineuser.sh add -u ui-machine-user@apigee.com -p Secret123
```

configFile で、必要な 4.54.00 Apigee SSO と New Edge UI のプロパティを追加または更新します。

# ==========================================
# SSO Enablement
# ==========================================
ENABLE_SSO=y

# ==========================================
# SSO Hostname/IP and Port config for Apigee SSO
# ==========================================
SSO_PUBLIC_URL_SCHEME=http
SSO_PUBLIC_URL_HOSTNAME=YOUR_SSO_NODE_IP_OR_HOSTNAME #Replace YOUR_SSO_NODE_IP_OR_HOSTNAME with the IP address or hostname of the SSO node.
SSO_PUBLIC_URL_PORT=9099

# ==========================================
# Static Client UI credentials
# ==========================================
MANAGEMENT_UI_SSO_CLIENT_ID=YOUR_SSO_CLIENT_ID #Example : MANAGEMENT_UI_SSO_CLIENT_ID=unifiedui
MANAGEMENT_UI_SSO_CLIENT_SECRET=YOUR_SSO_CLIENT_SECRET #Example : MANAGEMENT_UI_SSO_CLIENT_SECRET=secret123

# ==========================================
# Management UI & SSO redirect URLs
# ==========================================
MANAGEMENT_UI_SCHEME=http
MANAGEMENT_UI_IP=MANAGEMENT_UI_NODE_IP #Replace MANAGEMENT_UI_NODE_IP with the IP address or hostname of the UI node.
MANAGEMENT_UI_PORT=3001

# ==========================================
# Management Server parameters (Required for SSO registration)
# ==========================================
MSIP=MS_IP_OR_HOSTNAME #Replace MS_IP_OR_HOSTNAME with the IP address or hostname of the Management Server node.
ADMIN_EMAIL=your@email.com
APIGEE_ADMINPW=your_password

# ==========================================
# Machine user for UI
# ==========================================
UI_MACHINE_USER=ui-machine-user@apigee.com
UI_MACHINE_PWD=Secret123

# ==========================================
# Postgres connection parameters
# ==========================================
# Postgres username and password as set when you installed Edge.
PG_HOST=PG_IP_OR_HOSTNAME
PG_USER=apigee
PG_PWD=YOUR_PG_PASSWORD

# ==========================================
# Other UI Parameters
# ==========================================
AUTH_MODE=sso

# Y to use Internal/Local LDAP for authentication, N to use external IDP
SSO_LOCAL_LDAP=y

MANAGEMENT_UI_APP_ENV=OPDK
MANAGEMENT_UI_SSO_ENABLED=y
MANAGEMENT_UI_SSO_CSRF_SECRET=YOUR_CSRF_SECRET
MANAGEMENT_UI_SSO_CSRF_EXPIRATION_HOURS=24
MANAGEMENT_UI_SSO_STRICT_TRANSPORT_SECURITY_AGE_HOURS=24
MANAGEMENT_UI_SSO_PUBLIC_KEY_CACHE_HOURS=0.5

ステップ 3: New Edge UI コンポーネントをアップグレードする

注:

マルチノードトポロジでの新しい Edge UI に関して（Edge for Private Cloud v4.53.01 より前は、従来の UI と新しい Edge UI で別々のノードを維持することが必須でした）: たとえば、マルチノード 4.53.01 設定で、ノード 1 が edge-ui（ui.properties で構成）を運用し、ノード 2 が edge-management-ui と Shoehorn UI edge-ui（management-ui.properties で構成）を運用している場合:

カスタム構成（CWC）をコピーする: /opt/apigee/customer/application/management-ui.properties ファイルをノード 2 からノード 1 の同じパスに転送します。以前の apigee-sso オーバーライド CWC がすべて削除されていることを確認し、ファイルの所有権が apigee:apigee にあることを確認します。

現在 New Edge UI を使用している場合は、edge-management-ui（New Edge UI）コンポーネントと edge-ui（Shoehorn UI）コンポーネントの両方を停止してアンインストールします。

#Remove 4.53.xx New Edge UI from installation node 
apigee-service edge-management-ui stop
apigee-service edge-management-ui uninstall

#Remove Shoehorn UI from the node with 4.53.xx New Edge UI
apigee-service edge-ui stop
apigee-service edge-ui uninstall

Classic UI（edge-ui）ノードで update.sh スクリプトを実行して、新しい Edge UI（edge-management-ui）コンポーネントをインストールしてアップグレードします。
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```

ステップ 4: `apigee-sso` を停止する

レガシー apigee-sso サービスがインストールされているすべてのノードで、このサービスを停止します。

apigee-service apigee-sso stop

ステップ 5: Postgres ノードに Apigee SSO 用の `apigee_dex` データベースを作成する

Postgres プライマリノードで、次のコマンドを使用して Postgresql にログインします。
```
psql -h $(hostname -i) -U apigee
```
psql プロンプトで次のコマンドを実行して、Apigee SSO データベースを作成します。
```
create database apigee_dex;
```

ステップ 6: OpenLDAP ノードに Apigee SSO を設定する

Apigee SSO がインストールされる apigee-openldap ノードで次のコマンドを実行します。

/opt/apigee/apigee-service/bin/apigee-service apigee-openldap setup-sso -f configFile

ステップ 7: Apigee SSO 用に管理 UI を構成して UI を再起動する

Edge for Private Cloud 4.54.00 edge-management-ui がインストールされているすべてのノードで、次のコマンドを実行します。

/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile

ステップ 8: 新しい Edge UI と Apigee SSO のアップグレードを確認する

上記の手順を完了したら、4.54.00 の新しい Edge UI と Apigee SSO が実行され、アクセス可能であることを確認します。

edge-management-ui サービスが実行されていることを確認します。
```
apigee-service edge-management-ui status
```
ブラウザを開き、次の場所に移動します。
```
http://MANAGEMENT_UI_NODE_IP:3001
```
構成済みの SSO 認証情報を使用してログインします。

ステップ 9: 以前の `apigee-sso` をアンインストールする

以前の apigee-sso がインストールされているすべてのノードで、apigee-sso コンポーネントをアンインストールします。

apigee-service apigee-sso uninstall

Qpid 10.0.1 にアップグレードする

この方法では、Edge ランタイム環境のダウンタイムが発生せず、分析用に取得されたランタイムデータの損失を最小限に抑えることができます。

Qpid へのインプレースアップグレードをダウンタイムなしで実行するには:

まず、1 つの Qpid ノードを選択します。
ノードで Qpid ブローカーを停止します。
```
apigee-service apigee-qpidd stop
```
ファイアウォールを適用して、すべての Message Processor からのブローカーポート 5672 への受信トラフィックをブロックします。このファイアウォールは、Qpid ノードインスタンスレベルまたは他の外部ファイアウォール/ネットワークコンポーネントレベルで適用できます。

すべての Message Processor の IP アドレスに対して同じ手順を行うことをおすすめします。たとえば、IPTables を使用して、Message Processor の IP アドレスからポート 5672 の Qpid ノードに送信されるリクエストをドロップするには、次のようなコマンドを使用します。
```
iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
```
Qpid ブローカーを再度起動して、既存のメッセージをドレインします。
```
apigee-service apigee-qpidd start
```
既存のキューが空であることを確認します。
```
/opt/apigee/apigee-qpidd/bin/qpid-stat -q
```
メッセージがデッドレターキュー（DLQ）（ax-q-axgroup-001-consumer-group-001-dl）でスタックしている場合は、デッドレターキューでスタックしている分析データを解決する手順に沿ってキューをドレインします。
古いノードでキューがドレインされたことを確認したら、apigee-qpidd を停止します。
```
apigee-service apigee-qpidd stop
```

ノード上の Qpid をアップグレードします。

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

edge-qpid-server を再起動します。
```
apigee-service edge-qpid-server restart
```
ステップ 3 で適用したファイアウォールルールを削除します。

ファイアウォールが適用されたすべての Message Processor の IP アドレスに対して、同じ削除手順を行います。ファイアウォールが削除されると、Message Processor の IP アドレスからポート 5672 の Qpid ノードへのリクエストが受け入れられます。iptables を使用してファイアウォールを追加した場合は、次のコマンドを使用してファイアウォールを削除し、既存の設定を一覧表示できます。
```
iptables -F
iptables -L
```
ウェブモニタリングを使用して、Qpid キューがメッセージを受信していることを確認します。
```
http://QPID_NODE_IP:8090
```
各 Qpid ノードに対して手順 1 ～ 9 を繰り返します。

Postgres 18.6 にアップグレードする

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

ほとんどの 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 ノードを直接更新できます。
Apigee が推奨するように、Postgres ノードにネットワークストレージを使用している場合は、新しい Postgres ノードをインストールする必要はありません。以下の手順では、新しい Postgres スタンバイノードをインストールして後で廃止する手順をスキップできます。更新プロセスを開始する前に、Postgres で使用されるデータストアのネットワークスナップショットを取得します。更新中にエラーが発生してロールバックを強制的に実行する必要がある場合は、そのスナップショットから Postgres ノードを復元できます。

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

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

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

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

現在の 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 アドレスです。

Postgres プライマリで apigee-postgresql を再起動します。

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

プライマリの /opt/apigee/apigee-postgresql/conf/pg_hba.conf ファイルを表示して、新しいスタンバイノードが追加されたことを確認します。このファイルには、次の行が含まれています。
```
host replication apigee existing_standby_ip/32 trust
host replication apigee new_standby_ip/32 trust
```
新しい Postgres スタンバイサーバーをインストールします。
1. 現在のバージョンの Edge のインストールに使用した構成ファイルを編集して、次のように指定します。
```
# IP address of the current primary(master):
PG_MASTER=PG_MASTER_NODE_IP
# IP address of the new standby node
PG_STANDBY=PG_STANDBY_NODE_IP
```
2. Edge apigee-setup ユーティリティのインストールの説明に従って、SELinux を無効にします。
3. 現在の Edge バージョンに基づいてブートストラップスクリプトをダウンロードして実行します。
  - 現在 Edge 4.53.00 を使用している場合:
    
    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
```
    Edge apigee-service ユーティリティと依存関係をインストールします。
```
bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
```
  - 現在 Edge 4.53.01 を使用している場合:
    
    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
```
    Edge apigee-service ユーティリティと依存関係をインストールします。
```
bash /tmp/bootstrap_4.53.01.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 プロパティを更新します。

存在しない場合は、/opt/apigee/customer/application/postgresql.properties ファイルを作成します。

このファイルのオーナー権限を apigee に変更します。

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

ファイルに次のプロパティを追加します。
```
conf/postgresql.conf+max_locks_per_transaction=30000
```

apigee-postgresql を構成します。

apigee-service apigee-postgresql configure

apigee-postgresql を再起動します。
```
apigee-service apigee-postgresql restart
```

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

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

プライマリホストで postgres をアップグレードする
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
プライマリホストでセットアップコマンドを実行します。
```
apigee-service apigee-postgresql setup -f configFile
```
プライマリホストで構成コマンドを実行します。
```
apigee-service apigee-postgresql configure
```
プライマリホストを再起動します。
```
apigee-service apigee-postgresql restart
```

プライマリとして構成します。

apigee-service apigee-postgresql setup-replication-on-master -f configFile

プライマリホストが起動していることを確認します。
```
apigee-service apigee-postgresql wait_for_ready
```
スタンバイを停止します。
```
apigee-service apigee-postgresql stop
```
スタンバイをアップグレードします。

注: この手順でエラーが発生した場合は、無視してかまいません。update.sh は、誤った構成でスタンバイサーバーを起動しようとします。Postgres のインストールが 18 にアップグレードされていれば、このエラーは無視できます。
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
スタンバイが停止していることを確認します。
```
apigee-service apigee-postgresql stop
```
古いスタンバイ構成を削除します。
```
rm -rf /opt/apigee/data/apigee-postgresql/
```

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

apigee-service apigee-postgresql setup-replication-on-standby -f configFile

プライマリホストとスタンバイの両方で、ファイル /opt/apigee/customer/application/postgresql.properties から conf/postgresql.conf+max_locks_per_transaction=30000 行を削除します。この行は準備ステップで追加したものです。

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

Postgres ノードを廃止する

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

Postgres が実行されていることを確認します。
```
/opt/apigee/apigee-service/bin/apigee-all status
```
Postgres が実行されていない場合は、起動します。
```
/opt/apigee/apigee-service/bin/apigee-all start
```
新しいスタンバイノードで次の curl コマンドを実行して、新しいスタンバイノードの UUID を取得します。
```
curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self
```
出力の最後に、ノードの UUID が次の形式で表示されます。
```
"type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
```
新しいスタンバイノードで次のコマンドを実行して、新しいスタンバイノードを停止します。
```
/opt/apigee/apigee-service/bin/apigee-all stop
```
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
```

Postgres プライマリで apigee-postgresql を再起動します。

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

プライマリの /opt/apigee/apigee-postgresql/conf/pg_hba.conf ファイルを表示して、新しいスタンバイノードが削除されたことを確認します。このファイルには次の行のみが表示されます。
```
host replication apigee existing_standby_ip/32 trust
```
Management Server ノードで次の Edge Management 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 を実行することもできます。

ZooKeeper 3.8.5 にアップグレードする

このリリースの Edge for Private Cloud には、ZooKeeper 3.8.5 へのアップグレードが含まれています。このアップグレードの一環として、すべての ZooKeeper データが ZooKeeper 3.8.5 に移行されます。

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

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

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

バックアップを作成する

ロールバックが必要な場合に備えて、ZooKeeper のすべてのノードのバックアップを作成します。ロールバックすると、ZooKeeper がバックアップ取得時の状態に復元されます。

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

仮想マシンを使用していて、その機能がある場合は、復元またはロールバック（必要な場合）のために VM のスナップショットまたはバックアップを取得することもできます。

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

ZooKeeper ノードにインストールされていない場合は、nc をインストールします。
```
yum install nc
```
ノードで次の nc コマンドを実行します。ここで、2181 は ZooKeeper ポートです。
```
echo stat | nc localhost 2181
```
次のような出力が表示されます。
```
Zookeeper version: 3.8.5-19f1842d4b6ee1f82cc8b05284959b26c6ae507d, built on 2025-09-03 21:35 UTC
Clients:
 /[0:0:0:0:0:0:0:1]:40696[0](queued=0,recved=1,sent=0)

Latency min/avg/max: 3/4.3333/6
Received: 4
Sent: 3
Connections: 1
Outstanding: 0
Zxid: 0x500000005
Mode: follower
```
ノードの出力の Mode 行には、ノード構成に応じて、オブザーバー、リーダー、フォロワー（リーダーではない投票者）が表示されます。

各 ZooKeeper ノードで手順 1 と 2 を繰り返します。

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

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

外部インターネット接続があるノードで 4.54.00 に更新するの説明に沿って、Edge for Private Cloud 4.54.00 のブートストラップをダウンロードして実行します。このプロセスは、ノードに外部インターネット接続があるかどうか、またはオフラインインストールを実行しているかどうかによって異なる場合があります。
ZooKeeper コンポーネントをアップグレードします。
```
/opt/apigee/apigee-setup/bin/update.sh -c zk -f silent-config-file
```
注: これらのノードに他のコンポーネント（Cassandra など）がインストールされている場合は、それらのコンポーネントも今すぐアップグレードするか（zk,cs プロファイルなど）、後でアップグレードできます。Apigee では、まず ZooKeeper のみをアップグレードし、クラスタが正しく動作していることを確認してから、他のコンポーネントをアップグレードすることをおすすめします。
各 ZooKeeper オブザーバーノードとフォロワーノードで上記の手順を繰り返します。

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

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

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

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

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

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

アップグレードリーダー

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

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

Cassandra 5.0.8 にアップグレードする

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

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

Cassandra 4.0.X から Cassandra 5.0.X へのアップグレードは、ローリングプロセスです。
Cassandra 5.0.X から 4.0.X への直接のインプレースロールバックはできません。レプリカまたはバックアップを使用したロールバックは複雑な手順であり、ダウンタイムやデータ損失を伴う可能性があります。ロールバックするよりも、問題のトラブルシューティングを行い、Cassandra 5.0.X にアップグレードすることをおすすめします。
アップグレードを試みる前に、ロールバック手順をよく理解しておくことが重要です。アップグレード中のロールバックのニュアンスを考慮することは、適切なロールバックパスを確実に利用できるようにするために重要です。

単一のデータセンター

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

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

複数のデータセンター

Edge for Private Cloud 4.53.00（または 4.53.01）で複数のデータセンターを運用すると、Edge for Private Cloud 4.54.00 へのアップグレード中にロールバックをより柔軟に行うことができます。

ロールバックには、以前の Cassandra バージョン（4.0.X）を実行しているデータセンターが少なくとも 1 つ必要です。

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

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

ロールバックチェックポイントプロセス

単一のロールバックチェックポイント: すべてのコンポーネントが 4.54.00 にアップグレードされた場合、Cassandra のロールバックは、少なくとも 1 つの Cassandra データセンターが古いバージョンを実行し続けている場合にのみ可能です。最後の Cassandra データセンターがアップグレードされると、Edge for Private Cloud 4.54.00 へのアップグレードが完了し、ロールバックはできなくなります。

例

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

開始状態: 両方の DC の Cassandra ノードがバージョン 4.0.X である。他のすべてのノードは Edge for Private Cloud バージョン 4.54.00 にあります。DC ごとに 3 つの Cassandra ノードがあるとします。
DC-1 をアップグレードする: DC-1 の 3 つの Cassandra ノードを 1 つずつアップグレードします。
一時停止して検証する: クラスタ（特に DC-1）が正しく動作していることを確認するために一時停止します（パフォーマンスと機能を確認します）。DC-2 の Cassandra ノードを使用して、初期状態にロールバックできます。この一時停止は、Cassandra クラスタのバージョンが混在していることによる制限のため、一時的なものである必要があります。
DC-2 をアップグレードする: DC-2 の残りの 3 つの Cassandra ノードをアップグレードします。DC-2 のすべての Cassandra ノードが正常にアップグレードされると、Edge for Private Cloud 4.54.00 のアップグレードは完了です。

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

Edge for Private Cloud 4.53.00（または 4.53.01）で Cassandra 4.0.X を実行し、次のことを確認する必要があります。

サーバーのデフォルトの Java バージョンとして Java 17 を設定する: Cassandra 5.0.X では Java 8 のサポートが削除されています。Cassandra 5.0.X またはその nodetool ユーティリティを Java 8 で実行することはできません。各 Cassandra ノードに Java 17 がインストールされていることを確認し、Cassandra のアップグレード手順を実行する前に Java 17 をデフォルトの Java バージョンとして設定します。これにより、nodetool コマンドが Java 17 で実行されます。
```
alternatives --set java JAVA_17_PATH/bin/java
```
アクティブなデフォルトの Java バージョンが Java 17 であることを確認します。
```
java -version
```
クラスタ全体が稼働しており、Cassandra 4.0.X で完全に機能しています。
圧縮戦略が LeveledCompactionStrategy に設定されている（バージョン 4.53.00 または 4.53.01 へのアップグレードの前提条件）。
Edge for Private Cloud 4.53.00 または 4.53.01 で Cassandra 4.0.X の初期アップグレードの一部として、以下の各ステップが完了していることを確認します。
- 前回のアップグレード時に各 Cassandra ノードで post_upgrade コマンドが実行された
- 前のアップグレード中に、drop_old_tables コマンドが Cassandra クラスタ全体で実行されました。

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

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

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

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

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

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

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

Cassandra ノードをアップグレードするには、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c cs -f configFile
```
ノードが更新されたら、ノードで次のコマンドを実行して、いくつかの検証を行ってから先に進みます。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra validate_upgrade -f configFile
```

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

Cassandra version is verified - [cqlsh 6.2.0 | Cassandra 5.0.8 | CQL spec 3.4.7 | Native protocol v5]
Metadata is verified

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

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

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

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra cleanup_old_index

次の 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 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 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 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 cache cache_entries cache_entries_cache_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 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

Apigee mTLS での更新

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

更新のロールバック

更新に失敗した場合は、問題を修正してから update.sh を再度実行できます。アップデートは複数回実行でき、前回中断したところから再開されます。

障害により、以前のバージョンに更新をロールバックする必要がある場合は、4.54.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 をロードバランサに再び追加します。

マシンの更新順序の説明に沿って、インストールに適した順序でマシンを更新します。
Router を更新するタイミングになったら、サーバー（Message Processor / Router）のネットワーク到達性の有効化と無効化の説明に従って、いずれか 1 つの Router を選択して到達不能にします。
選択した Router と、その Router と同じマシンにある他のすべての Edge コンポーネントを更新します。すべての Edge 構成で、Router と Message Processor が同じノードに表示されます。
ルーターに再度アクセスできるようにします。
残りのルーターについて、手順 2 ～ 4 を繰り返します。
インストール環境内の残りのマシンで更新を続行します。

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

Router と Message Processor の組み合わせノードの場合:
- 更新前 - 次の操作を行います。
  1. ルーターにアクセスできないようにする。
  2. Message Processor を到達不能にします。
- 更新後 - 次の操作を行います。
  1. Message Processor に到達できるようにします。
  2. ルーターにアクセスできるようにする。
単一のルーターノードの場合:
- 更新する前に、Router にアクセスできないようにします。
- 更新後、Router をアクセス可能にします。
単一の Message Processor ノードの場合:
- 更新前に、Message Processor にアクセスできないようにします。
- 更新後、Message Processor を到達可能にします。

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

update コマンドにサイレント構成ファイルを渡す必要があります。サイレント構成ファイルは、Edge for Private Cloud 4.53.00 または 4.53.01 のインストールに使用したファイルとほぼ同じですが、新しい Edge UI と Apigee SSO へのアップグレード（インストールされている場合）で説明されているように、UI や SSO などのコンポーネントの変更が必要になる場合があります。

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

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

存在する場合は、更新が完了するまで、Cassandra で修復オペレーションを実行するように構成された cron ジョブを無効にします。
root としてノードにログインし、Edge RPM をインストールします。

注: RPM のインストールには root アクセス権が必要ですが、Edge の構成は root アクセス権がなくても実行できます。
Edge apigee-setup ユーティリティのインストールの説明に従って、SELinux を無効にします。

AWS にインストールする場合 は、次の yum-configure-manager コマンドを実行します。

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

現在 Edge for Private Cloud 4.53.00 または 4.53.01 を使用している場合:
1. Edge bootstrap_4.54.00.sh ファイルを /tmp/bootstrap_4.54.00.sh にダウンロードします。
```
curl https://software.apigee.com/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh
```
2. 次のコマンドを実行して、Edge 4.54.00 apigee-service ユーティリティと依存関係をインストールします。
```
bash /tmp/bootstrap_4.54.00.sh apigeeuser=uName apigeepassword=pWord
```
  ここで、uName:pWord は Apigee から受け取ったユーザー名とパスワードです。pWord を省略すると、入力を求めるプロンプトが表示されます。
  
  デフォルトでは、インストーラは Java 17 と 21 がインストールされていることを確認します。
3. 次の例に示すように、apigee-service を使用して apigee-setup ユーティリティを更新します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
4. 次の例に示すように、管理サーバーで apigee-validate ユーティリティを更新します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
5. 次の例に示すように、管理サーバーで 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 コンポーネントです。有効な値は次のとおりです。
    - edge: 新しい Edge UI を除くすべての Edge コンポーネント（Management Server、Message Processor、Router、QPID Server、Postgres Server）
    - ldap : OpenLDAP
    - ue : 新しい Edge UI
    - qpid : Apigee Qpid
    - ps : Apigee Postgresql
    - zk : ZooKeeper
    - cs : Cassandra
  - configFile は、4.53.00（または 4.53.01）のインストール時に Edge コンポーネントを定義するために使用した構成ファイルと同じです。
  注: 構成ファイルは「apigee」ユーザーが読み取れる必要があります。所有者を変更するには、次のコマンドを使用します。
```
chown apigee:apigee configFile
```
  component を「all」に設定すると、すべてのコンポーネントに対して update.sh を実行できますが、Edge オールインワン（AIO）インストールプロファイルがある場合に限ります。次に例を示します。
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
7. New Edge UI コンポーネントを実行するすべてのノードで New Edge UI コンポーネントを再起動します（まだ再起動していない場合）。
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
8. インストールのテストの説明に沿って、Management Server で apigee-validate ユーティリティを実行して更新をテストします。

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

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

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

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

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

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

Edge apigee-setup ユーティリティのインストールの「ローカルに Apigee リポジトリを作成する」の手順で 4.54.00 リポジトリをローカルに作成します。

注: すでにリポジトリが存在する場合は、Edge apigee-setup ユーティリティのインストールの「ローカルの Apigee リポジトリを更新する」の手順に沿って、4.54.00 リポジトリを追加できます。
次のいずれかの方法で、ターゲットノードに apigee-service をインストールします。
- オプション 1: .tar ファイルから apigee-service をインストールする
  1. ローカルリポジトリがあるノードで、次のコマンドを使用して、ローカルリポジトリを /opt/apigee/data/apigee-mirror/apigee-4.54.00.tar.gz という名前の単一の .tar ファイルにパッケージ化します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-mirror package
```
  2. Edge を更新する対象のノードに .tar ファイルをコピーします。たとえば、新しいノードの /tmp ディレクトリにコピーします。
  3. 新しいノードで、ファイルを /tmp ディレクトリに解凍します。
```
tar -xzf apigee-4.54.00.tar.gz
```
    このコマンドにより、.tar ファイルを含むディレクトリに repos という名前の新しいディレクトリが作成されます。例: /tmp/repos
  4. /tmp/repos から Edge apigee-service ユーティリティと依存関係をインストールします。
```
bash /tmp/repos/bootstrap_4.54.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos
```
    コマンドに repos ディレクトリへのパスが含まれている点に注意してください。
- オプション 2: Nginx ウェブサーバーを使用して apigee-service をインストールする
  1. Edge apigee-setup ユーティリティのインストールの「Nginx ウェブサーバーを使用してリポジトリからインストールする」の手順に沿って、Nginx ウェブサーバーを構成します。
  2. リモートノードで、Edge bootstrap_4.54.00.sh ファイルを /tmp/bootstrap_4.54.00.sh にダウンロードします。
```
/usr/bin/curl http://uName:pWord@remoteRepo:3939/bootstrap_4.54.00.sh -o /tmp/bootstrap_4.54.00.sh
```
    ここで、uName:pWord は、以前にリポジトリに設定したユーザー名とパスワードです。remoteRepo は、リポジトリノードの IP アドレスまたは DNS 名です。
  3. リモートノードで、Edge apigee-service ユーティリティと依存関係をインストールします。
```
bash /tmp/bootstrap_4.54.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://
```
    ここで、uName:pWord はリポジトリのユーザー名とパスワードです。
次の例に示すように、apigee-service を使用して apigee-setup ユーティリティを更新します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-setup update
```
次の例に示すように、管理サーバーで apigee-validate ユーティリティを更新します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-validate update
```
次の例のように、Management Server で apigee-provision ユーティリティを更新します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-provision update
```
マシンの更新順序で説明されている順序で、ノードで update ユーティリティを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c component -f configFile
```
ここで
- component は、更新する Edge コンポーネントです。有効な値は次のとおりです。
  - edge: 新しい Edge UI を除くすべての Edge コンポーネント（Management Server、Message Processor、Router、QPID Server、Postgres Server）
  - ldap : OpenLDAP
  - ue : 新しい Edge UI
  - qpid : Apigee Qpid
  - ps : Apigee Postgresql
  - zk : ZooKeeper
  - cs : Cassandra
- configFile は、4.53.00（または 4.53.01）のインストール時に Edge コンポーネントを定義するために使用した構成ファイルと同じです。
  
  注: 構成ファイルは「apigee」ユーザーが読み取れる必要があります。所有者を変更するには、次のコマンドを使用します。
```
chown apigee:apigee configFile
```
component を「all」に設定すると、すべてのコンポーネントに対して update.sh を実行できますが、Edge オールインワン（AIO）インストールプロファイルがある場合に限ります。次に例を示します。
```
/opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
```
UI コンポーネントを実行するすべてのノードで UI コンポーネントを再起動します（まだ再起動していない場合）。
```
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart
```
インストールのテストの説明に沿って、Management Server で apigee-validate ユーティリティを実行して更新をテストします。

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

マシンの更新順序

Edge インストールでマシンを更新する順序は重要です。以下の順序でコンポーネントをアップグレードします。

-c edge オプションを使用して、すべてのデータセンターのすべての Router ノードと Message Processor ノードをアップグレードします。
-c edge オプションを使用して、すべてのデータセンターのすべての Management Server ノードをアップグレードします。
すべてのデータセンターのすべての LDAP ノードをアップグレードします。Edge for Private Cloud 4.53.00 からアップグレードする場合は、LDAP アップグレードの特別な手順に沿って追加の手順を行う必要があります。
すべてのデータセンターで UI と Apigee SSO（インストールされている場合）をアップグレードします。
1. apigee-sso がインストールされていない場合: オプション 1: UI のアップグレード（Apigee SSO なし）に沿って、新しい Edge UI にアップグレードします。
2. apigee-sso がインストールされている場合: オプション 2: UI のアップグレード（Apigee SSO を使用）の手順に沿って、新しい Edge UI と Apigee SSO にアップグレードします。
Qpid の特別な手順に沿って、すべてのデータセンターのすべての Qpid コンポーネントと edge-qpid-server コンポーネントをアップグレードします。
Postgres の特別な手順に沿って、すべてのデータセンターのすべての Postgresql コンポーネントと edge-postgres-server コンポーネントをアップグレードします。
Zookeeper アップグレードの特別な手順に沿って、すべてのデータセンターのすべての Zookeeper コンポーネントをアップグレードします。
Cassandra のアップグレードの特別な手順に沿って、すべてのデータセンターのすべての Cassandra コンポーネントをアップグレードします。
Monetization を更新するための個別のステップはありません。-c edge オプションを指定すると更新されます。

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

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

Edge for Private Cloud 4.53.00 からアップグレードする場合は、すべてのコンポーネントのアップグレードを開始する前に、4.53.00 から 4.54.00 へのアップグレード手順に沿って LDAP を最初にアップグレードする必要があります。

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

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

（apigee-adminapi をインストールした場合）apigee-adminapi ユーティリティを更新します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

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

2 ノードのスタンドアロンインストールで次のコンポーネントを更新します。

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

マシン 1 の Edge コンポーネントを更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

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

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

マシン 1 で新しい Edge UI を更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
注: apigee-sso がインストールされている場合は、オプション 2: UI のアップグレード（Apigee SSO を使用）で Apigee SSO に構成する手順をご覧ください。
マシン 2 の Edge コンポーネントを更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

マシン 2 で Qpid を更新します。

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

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

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

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

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

（apigee-adminapi をインストールした場合）マシン 1 の apigee-adminapi ユーティリティを更新します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

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

5 ノードのインストールで次のコンポーネントを更新します。

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

マシン 2、3、1 の Edge コンポーネントを更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

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

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

マシン 1 の新しい Edge UI を更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
注: apigee-sso がインストールされている場合は、オプション 2: UI のアップグレード（Apigee SSO を使用）で Apigee SSO に構成する手順をご覧ください。
マシン 4、5 で Edge コンポーネントを更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

マシン 4、5 で Qpid を更新します。

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

マシン 4、5 で Postgres を更新します。

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

マシン 1、2、3 で Cassandra と ZooKeeper を更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
（apigee-adminapi をインストールした場合）マシン 1 の apigee-adminapi ユーティリティを更新します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

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

9 ノードクラスタインストールで次のコンポーネントを更新します。

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

マシン 4、5、1 の Edge コンポーネント（router、message-processor、management-server）をこの順序で更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

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

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

マシン 1 の新しい Edge UI を更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
注: apigee-sso がインストールされている場合は、オプション 2: UI をアップグレードする（Apigee SSO を使用）で、Apigee SSO に構成する手順をご覧ください。
マシン 6、7、8、9 の順に Edge コンポーネントを更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

マシン 6 と 7 で Qpid を更新します。

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

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

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

マシン 9 で Postgres を更新します。

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

マシン 1、2、3 で Cassandra と ZooKeeper を更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
（apigee-adminapi をインストールした場合）マシン 1 の apigee-adminapi ユーティリティを更新します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

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

13 ノードのクラスタインストール用に次のコンポーネントを更新します。

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

マシン 10、11、6、7 の順に Edge コンポーネントを更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

マシン 4 と 5 で LDAP を更新します。

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

マシン 6、7 の新しい Edge UI を更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
注: apigee-sso がインストールされている場合は、オプション 2: UI をアップグレードする（Apigee SSO を使用）で、Apigee SSO に構成する手順をご覧ください。
マシン 12、13、8、9 の順に Edge コンポーネントを更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```

マシン 12 と 13 で Qpid を更新します。

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

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

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

マシン 9 で Postgres を更新します。

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

マシン 1、2、3 で Cassandra と ZooKeeper を更新します。
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
（apigee-adminapi がインストールされている場合）マシン 6、7 の apigee-adminapi ユーティリティを更新します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

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

12 ノードのクラスタインストール用に次のコンポーネントを更新します。

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

Edge（Router と Message Processor）コンポーネントを更新します。
- データセンター 1 のマシン 2、3 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
- データセンター 2 のマシン 8、9 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
Edge（管理サーバー）コンポーネントを更新します。
- データセンター 1 のマシン 1 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
- データセンター 2 のマシン 7 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
LDAP を更新:
- データセンター 1 のマシン 1 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
- データセンター 2 のマシン 7 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
```
新しい Edge UI コンポーネントを更新します。
- データセンター 1 のマシン 1 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
  注: apigee-sso がインストールされている場合は、オプション 2: UI をアップグレードする（Apigee SSO を使用）で、Apigee SSO に構成する手順をご覧ください。
- データセンター 2 のマシン 7 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c ue -f configFile
```
  注: apigee-sso がインストールされている場合は、オプション 2: UI をアップグレードする（Apigee SSO を使用）で、Apigee SSO に構成する手順をご覧ください。
Edge コンポーネントを更新します。
- データセンター 1 のマシン 4、5、6 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
- データセンター 2 のマシン 10、11、12 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
```
qpidd を更新します。
- データセンター 1 のマシン 4、5 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
- データセンター 2 のマシン 10、11 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
```
Postgres を更新します。
- データセンター 1 のマシン 6 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
- データセンター 2 のマシン 12 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
```
Cassandra と ZooKeeper を更新します。
- データセンター 1 のマシン 1、2、3:
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
- データセンター 2 のマシン 7、8、9 で、次のコマンドを実行します。
```
/opt/apigee/apigee-setup/bin/update.sh -c zk,cs -f configFile
```
（apigee-adminapi をインストールした場合）apigee-adminapi ユーティリティを更新します。
- データセンター 1 のマシン 1 で、次のコマンドを実行します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```
- データセンター 2 のマシン 7 で、次のコマンドを実行します。
```
/opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
```

非標準構成のアップグレード

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

ルーター
Message Processor
管理サーバー
LDAP
UI（従来の UI または新しい UI）
SSO（該当する場合）
Qpid と edge-qpid-server
Postgres と edge-postgres-server
ZooKeeper
Cassandra
apigee-adminapi

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

更新を行えるユーザー

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

事前資料

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

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

Router と Message Processor をアップグレードする

Management Server をアップグレードする

OpenLDAP 2.6.10 にアップグレード

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

LDAP を 4.53.00 から 4.54.00 にアップグレードする手順

前提条件と考慮事項

LDAP を 4.53.01 から 4.54.00 にアップグレードする手順

New Edge UI と Apigee SSO（インストールされている場合）にアップグレードする

オプション 1: アップグレード UI（Apigee SSO なし）

ステップ 1: 構成ファイルをバックアップする

ステップ 2: 基本認証のサイレント構成ファイルを更新する

ステップ 3: UI コンポーネントをアップグレードする

ステップ 4: 新しい Edge UI のアップグレードを確認する

オプション 2: UI をアップグレードする（Apigee SSO を使用）

ステップ 1: 構成ファイルをバックアップする

ステップ 2: 非推奨の UI/SSO 変数を削除し、サイレント構成ファイル（configFile）を更新する

ステップ 3: New Edge UI コンポーネントをアップグレードする

ステップ 4: apigee-sso を停止する

ステップ 5: Postgres ノードに Apigee SSO 用の apigee_dex データベースを作成する

ステップ 6: OpenLDAP ノードに Apigee SSO を設定する

ステップ 7: Apigee SSO 用に管理 UI を構成して UI を再起動する

ステップ 8: 新しい Edge UI と Apigee SSO のアップグレードを確認する

ステップ 9: 以前の apigee-sso をアンインストールする

Qpid 10.0.1 にアップグレードする

Postgres 18.6 にアップグレードする

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

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

予備の手順

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

Postgres ノードを廃止する

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

ZooKeeper 3.8.5 にアップグレードする

バックアップを作成する

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

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

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

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

アップグレード リーダー

Cassandra 5.0.8 にアップグレードする

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

単一のデータセンター

複数のデータセンター

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

ロールバック チェックポイント プロセス

例

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

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

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

Apigee mTLS での更新

更新のロールバック

更新情報のロギング

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

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

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

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

マシンの更新順序

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

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

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

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

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

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

非標準構成のアップグレード

ステップ 2: 非推奨の UI/SSO 変数を削除し、サイレント構成ファイル（`configFile`）を更新する

ステップ 4: `apigee-sso` を停止する

ステップ 5: Postgres ノードに Apigee SSO 用の `apigee_dex` データベースを作成する

ステップ 9: 以前の `apigee-sso` をアンインストールする

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

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

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

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

アップグレードリーダー

ロールバックチェックポイントプロセス

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

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

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