Apigee Edge 4.52.02 を 4.53.00 に更新する

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

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

更新を行えるユーザー

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

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

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

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

更新の前提条件

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

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

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

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

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

• Cassandra の前提条件を確認する
  以前に古いバージョンの Edge for Private Cloud からバージョン 4.52.02 にアップグレードし、現在バージョン 4.53.00 にアップグレードする場合は、Cassandra のアップグレード後に必要な手順を完了していることを確認してください。これらの手順は、バージョン 4.52.02 アップグレード ドキュメントのアップグレード後の手順で概説されています。これらの手順が以前のアップグレードで完了したかどうか不明な場合は、バージョン 4.53.00 へのアップグレードに進む前に、手順を再度完了してください。
• Python の要件
  アップグレードを試みる前に、Cassandra ノードを含むすべてのノードに Python 3 がインストールされていることを確認します。

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

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

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

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

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

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

単一データセンター

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

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

複数のデータセンター

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

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

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

1. 一度に 1 つの Cassandra データセンターをアップグレードする: まず、単一のデータセンター内で Cassandra ノードを個別にアップグレードします。次のデータセンターに進む前に、1 つのデータセンター内のすべての Cassandra ノードのアップグレードを完了します。
2. 一時停止して検証する: 1 つのデータセンターをアップグレードしたら、一時停止して、Private Cloud クラスタ（特にアップグレードしたデータセンター）が正しく機能していることを確認します。
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 アップグレードの前提条件

Edge for Private Cloud 4.52.02 で Cassandra 3.11.16 を実行し、次のことを確認する必要があります。

• クラスタ全体が動作し、Cassandra 3.11.16 で完全に機能します。
• 圧縮戦略が LeveledCompactionStrategy に設定されている（バージョン 4.52.02 へのアップグレードの前提条件）。
• 4.52.02 アップグレードの一部として、Cassandra 3.11.16 への最初のアップグレードからアップグレード後の手順がすべて完了しました。解決しない場合は、この手順をもう一度行います。これは、古いバージョンから Private Cloud バージョン 4.52.02 にアップグレードした場合にのみ適用されます。

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

次の手順は、コンポーネントのアップグレードを有効にする Apigee の標準構成ファイルなど、通常作成する標準ファイルに加えて行う必要があります。

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

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

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

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

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

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

2. ノードが更新されたら、ノードで次のコマンドを実行して検証を実行してから、続行します。

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

3. 上記のコードを実行すると、次のような出力が表示されます。

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

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

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

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

ステップ 4: すべてのランタイム ノードをアップグレードする

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

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

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

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

ステップ 6: アップグレード後の手順

アップグレードが完了したら、各 Cassandra ノードで次のコマンドを 1 つずつ実行します。

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

新しい Edge UI

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

Edge UI のインストール

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

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

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

Apigee mTLS での更新

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

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

更新のロールバック

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

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

更新情報のロギング

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

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

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

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

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

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

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

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

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

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

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

サイレント構成ファイルの使用

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      tar -xzf apigee-4.53.00.tar.gz

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

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

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

      コマンドに repos ディレクトリへのパスが含まれている点に注意してください。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   ここで

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

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

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

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

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

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

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

マシンの更新順序

Edge 構成内のマシンの更新順序は重要です。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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