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 へのアップグレードに進む前に、手順を再度完了してください。
  • Edge for Private Cloud 4.53.00 で IDP 鍵と証明書を構成する

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

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

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

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

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. ポート 9042 が、Management Server、Message Processor、Router、Qpid、Postgres など、すべての Edge for Private Cloud コンポーネントから Cassandra ノードにアクセス可能であることを確認します（まだ構成されていない場合）。詳細については、ポートの要件をご覧ください。

ステップ 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
  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: すべての管理ノードをアップグレードする

すべてのリージョンのすべての 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 つずつアップグレードします。

以前のバージョンから Apigee SSO を更新する手順

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

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

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

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

      apigee-service apigee-sso configure -search conf_login_service_provider_certificate

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

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

      apigee-service apigee-sso configure -search conf_login_service_provider_key
  2. 鍵と証明書をキーストアにエクスポートします。
    1. 鍵と証明書を PKCS12 キーストアにエクスポートします。
      sudo openssl pkcs12 -export -clcerts -in <certificate_path> -inkey <key_path> -out <keystore_path> -name <alias>

      パラメータ:

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

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

    2. （省略可）鍵と証明書を PKCS12 から JKS キーストアにエクスポートします。
      sudo keytool -importkeystore -srckeystore <PKCS12_keystore_path> -srcstoretype PKCS12 -destkeystore <destination_keystore_path> -deststoretype JKS -alias <alias>

      パラメータ:

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

      3. 詳しくは、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 を更新する手順は次のとおりです。

更新のロールバック

更新に失敗した場合は、問題の解決を試みた後で 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. インストール中の残りのすべてのマシンで更新を続行します。

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

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

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

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

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

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

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

    1. Edge bootstrap_4.53.00.sh ファイルを /tmp/bootstrap_4.53.00.sh にダウンロードします。 
      curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh
    2. 次のコマンドを実行して、Edge 4.53.00 の apigee-service ユーティリティと依存関係をインストールします。
      sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

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

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

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

      • I: OpenJDK 1.8 をインストールします（デフォルト）。
      • C: Java をインストールせずに続行します。
      • Q: 終了します。この場合、Java を自分でインストールする必要があります。
    3. 次の例のように、apigee-service を使用して apigee-setup ユーティリティを更新します。
      /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
    4. 次の例のように、Management Server で apigee-validate ユーティリティを更新します。
      /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
    5. 次の例のように、Management Server で apigee-provision ユーティリティを更新します。
      /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
    6. 次のコマンドを実行して、各ノードで update ユーティリティを実行します。
      /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

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

      ここで

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

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

      /opt/apigee/apigee-setup/bin/update.sh -c all -f ./sa_silent_config
    7. Edge UI コンポーネントを実行しているすべてのノードで Edge UI コンポーネントを再起動します（まだ再起動していない場合）。
      /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
    8. インストールのテストの説明に従って Management Server で apigee-validate ユーティリティを実行し、更新をテストします。

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

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

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

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

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

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

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

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

    4. /tmp/repos から Edge apigee-service ユーティリティと依存関係をインストールします。
      sudo bash /tmp/repos/bootstrap_4.53.00.sh apigeeprotocol="file://" apigeerepobasepath=/tmp/repos

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

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

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

    3. リモートノードで、Edge apigee-setup ユーティリティと依存関係をインストールします。
      sudo bash /tmp/bootstrap_4.53.00.sh apigeerepohost=remoteRepo:3939 apigeeuser=uName apigeepassword=pWord apigeeprotocol=http://

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

  4. 次の例のように、apigee-service を使用して apigee-setup ユーティリティを更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup update
  5. 次の例のように、Management Server で apigee-validate ユーティリティを更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-validate update
  6. 次の例のように、Management Server で apigee-provision ユーティリティを更新します。
    /opt/apigee/apigee-service/bin/apigee-service apigee-provision update
  7. マシンの更新順序に記載された順に、各ノードで update ユーティリティを実行します。
    /opt/apigee/apigee-setup/bin/update.sh -c component -f configFile

    ここで

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

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

    /opt/apigee/apigee-setup/bin/update.sh -c all -f /tmp/sa_silent_config
  8. UI コンポーネントが実行されているすべてのノードで UI コンポーネントを再起動します（まだ再起動していない場合）。
    /opt/apigee/apigee-service/bin/apigee-service [edge-management-ui|edge-ui] restart
  9. インストールのテストの説明に従って Management Server で apigee-validate ユーティリティを実行し、更新をテストします。

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

マシンの更新順序

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

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

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

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

  1. すべてのコンポーネントを更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c all -f configFile
  2. apigee-adminapi がインストールされている場合は、apigee-adminapi ユーティリティを更新します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update

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

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

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

  1. マシン 1 の Cassandra と ZooKeeper を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  2. マシン 2 の Postgres を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. マシン 1 の LDAP を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  4. マシン 2、1 の Edge コンポーネントを更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  5. マシン 2 で Qpid を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  6. マシン 1 の UI を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
  7. apigee-adminapi がインストールされている場合は、マシン 1 の apigee-adminapi ユーティリティを更新します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  8. Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

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

  9. マシン 1 の Edge UI コンポーネントを再起動します。
    /opt/apigee/apigee-service/bin/apigee-service edge-ui restart

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

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

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

  1. マシン 1、2、3 の Cassandra と ZooKeeper を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  2. マシン 4 の Postgres を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. マシン 5 の Postgres を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  4. マシン 1 の LDAP を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  5. マシン 4、5、1、2、3 の Edge コンポーネントを更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. マシン 4 の Qpid を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. マシン 5 の Qpid を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  8. Edge UI を更新します。
    • 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の ui コンポーネントを更新します。
      /opt/apigee/apigee-setup/bin/update.sh -c ui -f configFile
    • 新しい Edge UI: 新しい Edge UI をインストールした場合は、該当するマシン（マシン 1 ではない場合があります）の ue コンポーネントを更新します。
      /opt/apigee/apigee-setup/bin/update.sh -c ue -f /opt/silent.conf
  9. apigee-adminapi がインストールされている場合は、マシン 1 の apigee-adminapi ユーティリティを更新します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  10. Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

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

  11. UI コンポーネントを再起動します。
    • 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の edge-ui コンポーネントを再起動します。
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • 新しい Edge UI: 新しい Edge UI をインストールした場合は、該当するマシン（マシン 1 ではない場合があります）の edge-management-ui コンポーネントを再起動します。
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

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

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

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

  1. マシン 1、2、3 の Cassandra と ZooKeeper を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  2. マシン 8 の Postgres を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. マシン 9 の Postgres を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  4. マシン 1 の LDAP を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  5. マシン 6、7、8、9、1、4、5 の順に Edge コンポーネントを更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. マシン 6、7 の Qpid を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. マシン 1 の新しい UI（ue）または従来の UI（ui）を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  8. apigee-adminapi がインストールされている場合は、マシン 1 の apigee-adminapi ユーティリティを更新します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. Apigee SSO がインストールされている場合は、マシン 1 の Apigee SSO を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

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

  10. UI コンポーネントを再起動します。
    • 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 1 の edge-ui コンポーネントを再起動します。
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • 新しい Edge UI: 新しい Edge UI をインストールした場合は、該当するマシン（マシン 1 ではない場合があります）の edge-management-ui コンポーネントを再起動します。
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

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

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

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

  1. マシン 1、2、3 の Cassandra と ZooKeeper を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  2. マシン 8 の Postgres を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. マシン 9 の Postgres を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  4. マシン 4、5 の LDAP を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  5. マシン 12、13、8、9、6、7、10、11 の順に Edge コンポーネントを更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  6. マシン 12、13 の Qpid を更新します。 
    /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  7. マシン 6 と 7 の新しい UI（ue）または従来の UI（ui）を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  8. apigee-adminapi がインストールされている場合は、マシン 6、7 の apigee-adminapi ユーティリティを更新します。 
    /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  9. Apigee SSO がインストールされている場合は、マシン 6、7 の Apigee SSO を更新します。
    /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

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

  10. UI コンポーネントを再起動します。
    • 従来の UI: 従来の UI を使用している場合は、次の例のようにマシン 6 と 7 で edge-ui コンポーネントを再起動します。
      /opt/apigee/apigee-service/bin/apigee-service edge-ui restart
    • 新しい Edge UI: 新しい Edge UI をインストールした場合は、マシン 6 と 7 で edge-management-ui コンポーネントを再起動します。
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui restart

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

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

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

  1. Cassandra と ZooKeeper を更新します。
    1. データセンター 1 のマシン 1、2、3 で、次のコマンドを実行します。 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
    2. データセンター 2 のマシン 7、8、9 で、次のコマンドを実行します。 
      /opt/apigee/apigee-setup/bin/update.sh -c cs,zk -f configFile
  2. Postgres を更新します。
    1. データセンター 1 のマシン 6 で、次のコマンドを実行します。 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
    2. データセンター 2 のマシン 12 で、次のコマンドを実行します。 
      /opt/apigee/apigee-setup/bin/update.sh -c ps -f configFile
  3. LDAP を更新します。
    1. データセンター 1 のマシン 1 で、次のコマンドを実行します。 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
    2. データセンター 2 のマシン 7 で、次のコマンドを実行します。 
      /opt/apigee/apigee-setup/bin/update.sh -c ldap -f configFile
  4. Edge コンポーネントを更新します。
    1. データセンター 1 のマシン 4、5、6、1、2、3 で、次のコマンドを実行します。 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
    2. データセンター 2 の 10、11、12、7、8、9 で、次のコマンドを実行します。 
      /opt/apigee/apigee-setup/bin/update.sh -c edge -f configFile
  5. qpidd を更新します。
    1. データセンター 1 のマシン 4、5 で、次の手順を実施します。
      1. マシン 4 の qpidd を更新します。 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. マシン 5 の qpidd を更新します。 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
    2. データセンター 2 のマシン 10、11 で、次の手順を実施します。
      1. マシン 10 の qpidd を更新します。 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
      2. マシン 11 の qpidd を更新します。 
        /opt/apigee/apigee-setup/bin/update.sh -c qpid -f configFile
  6. 新しい UI（ue）または従来の UI（ui）を更新します。
    1. データセンター 1 のマシン 1 で、次のコマンドを実行します。 
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
    2. データセンター 2 のマシン 7 で、次のコマンドを実行します。
      /opt/apigee/apigee-setup/bin/update.sh -c [ui|ue] -f configFile
  7. apigee-adminapi がインストールされている場合は、apigee-adminapi ユーティリティを更新します。
    1. データセンター 1 のマシン 1 で、次のコマンドを実行します。 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
    2. データセンター 2 のマシン 7 で、次のコマンドを実行します。 
      /opt/apigee/apigee-service/bin/apigee-service apigee-adminapi update
  8. Apigee SSO がインストールされている場合は、Apigee SSO を更新します。
    1. データセンター 1 のマシン 1 で、次のコマンドを実行します。 
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file
    2. データセンター 2 のマシン 7 で、次のコマンドを実行します。
      /opt/apigee/apigee-setup/bin/update.sh -c sso -f sso_config_file

      3. ここで、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 コンポーネントを再起動してください。