Edge for Private Cloud v4.17.01
Edge 4.17.01 への更新時にエラーが発生した場合、エラーの原因となったコンポーネントをロールバックしてから更新を再試行できます。たとえば、Postgres 9.4 への更新が失敗した場合は、Postgres ノードのみをロールバックして更新を再試行できます。
ロールバックを実行するシナリオは 2 つあります。
- 古いリリースにロールバックする。たとえば、4.17.01 から 4.16.09 へのロールバックです。
- 同じリリースの古いバージョンにロールバックする。
両方のシナリオでロールバックを実行する手順は次のとおりです。
ロールバックを実行できるユーザー
ロールバックを行うユーザーは、最初に Edge を更新したユーザーまたは root ユーザーである必要があります。
デフォルトでは、Edge コンポーネントはユーザー「apigee」として実行されます。場合によっては、Edge コンポーネントが異なるユーザーとして実行されていることがあります。たとえば、Router が特権ポート(1,000 未満のポートなど)にアクセスする必要がある場合、Router を root として実行するか、それらのポートにアクセスできるユーザーとして実行する必要があります。また、あるコンポーネントを別のユーザーとして、別のコンポーネントを別のユーザーとして実行することもできます。
ロールバックできるコンポーネント
ロールバックを実施する際は、次の点に注意してください。
- 以下の 5 つの Edge コンポーネントは、共通のコードを共有します。したがって、ノード上の 5 つのコンポーネントのいずれかをロールバックするには、ノードにインストールされている 5 つのコンポーネントのいずれかをロールバックする必要があります。たとえば、Management Server、Router、Message Processor がノードにインストールされている場合、これらのいずれかをロールバックするには、3 つすべてをロールバックする必要があります。
コードを共有するのは次の 5 つのコンポーネントです。- 管理サーバー
- ルーター
- Message Processor
- Qpid Server
- Postgres Server
- Edge 4.16.01 から更新する場合は、Cassandra をロールバックしないでください。Edge のこのリリースには Cassandra の更新バージョンが含まれています。コンポーネントをロールバックする場合は、Cassandra を 4.17.01 バージョンのままにしておきます。
4.17.01 のロールバック
このセクションでは、Edge 4.17.01 を以前のバージョンにロールバックする手順を説明します。このセクションは、
- 4.16.01 または 4.16.05 からのみ更新する場合 - Postgres の更新をバージョン 9.4 にロールバックする場合
4.16.01 または 4.16.05 からの更新手順の最後の部分では、Postgres ノードをバージョン 9.4 に更新します。この更新に失敗した場合は、次の手順で更新をロールバックできます。 - その他すべての Edge コンポーネントをロールバックする
この手順は、すべての Edge コンポーネントをロールバックする場合に行います。
Postgres 9.4 のアップデートをロールバックするには
マスター / スタンバイ構成で Postgres を更新する際に Postgres の更新をロールバックするには、次の操作を行います。
- 新しいスタンバイ ノードを Postgres マスターに昇格させます。新しい Postgres マスターのバージョンは、前の Edge インストール環境でのバージョンと同じです。
- 旧スタンバイ ノードを構成して、新しいマスターのスタンバイ ノードにします。旧スタンバイ ノードのバージョンは、前の Edge インストール環境でのバージョンと同じです。
- 新しいマスターノードとスタンバイ ノードを分析グループとコンシューマ グループに登録します。
ロールバックが完了すると、旧マスターノードは不要になります。その後、旧マスターノードを廃止できます。
- 新しいスタンバイ Postgres ノードが稼働していることを確認します。
> /opt/apigee/apigee-service/bin/apigee-all status
Postgres が稼働していない場合は、次の手順で起動してください。
> /opt/apigee/apigee-service/bin/apigee-all start - 旧マスターノードと旧スタンバイ ノードで Postgres が停止していることを確認します。
> /opt/apigee/apigee-service/bin/apigee-all status
Postgres が稼働している場合は、停止します。
> /opt/apigee/service/bin/apigee-service edge-postgres-server stop
> /opt/apigee-service/bin/apigee-service apigee - インストール済みの場合は、旧スタンバイ ノードで Qpid を起動します。
> /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
注: 多くの構成では、旧スタンバイ ノードは Postgres のみをホストし、Qpid はホストしません。 - Postgres マスターとして新しいスタンバイ ノードを昇格させます。
- 新しいスタンバイ ノードを新しいマスターに昇格させます。
> apigee-service apigee-postgresql promotion-standby-to-master new_standby_IP
プロンプトが表示されたら、「apigee」ユーザーの Postgres パスワードを入力します。デフォルトのパスワードは「postgres」です。 - Edge の現在のバージョンのインストールに使用した構成ファイルを編集し、次の内容を指定します。
# 新しいマスターの IP アドレス:
PG_MASTER=new_standby_IP
# 古いスタンバイ ノードの IP アドレス
PG_STANDBY=old_standby_IP - 新しいマスターを構成します。
> /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
- 新しいスタンバイ ノードを新しいマスターに昇格させます。
- 旧スタンバイ ノードを再ビルドします。
- Edge の現在のバージョンのインストールに使用した構成ファイルを編集し、次の内容を指定します。
# 新しいマスターの IP アドレス:
PG_MASTER=new_standby_IP
# 古いスタンバイ ノードの IP アドレス
PG_STANDBY=old_standby_IP - 旧スタンバイ ノードからデータ ディレクトリを削除します。
> cd /opt/apigee/data/apigee-postgresql/pthen
> rm -rf * - 旧スタンバイ ノードを再構成して、新しいマスターのスタンバイ ノードにします。
> /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile - Postgres が旧スタンバイ ノードで実行されていることを確認します。
> /opt/apigee/apigee-service/bin/apigee-all status
実行されていない場合は、起動します。
> /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
- Edge の現在のバージョンのインストールに使用した構成ファイルを編集し、次の内容を指定します。
- 新しいマスターで /opt/apigee/apigee-postgresql/conf/pg_hba.conf ファイルを表示して、新しいスタンバイ ノードが追加されたことを確認します。
- Management Server で次のコマンドを実行して、現在の分析グループとコンシューマ グループ情報を表示します。
> curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/analytics/groups/ax
name フィールドのアナリティクス グループ名と、name- フィールドのコンシューマ グループ名が返されます。また、旧 Postgres マスターノードと旧 Postgres スタンバイ ノードの UUID を、postgres-server フィールドと datastores フィールドに返します。"
" fc " fc " fc " fc " fc " fc " fc " fic " fic " fact " fact " fact " fact " fact " fact " fact " fact " fic " fic " fic " fac " fac " fact " fic "
ft " fac " fact Analytics div 手順 " 必ず手順を示す - 古いマスターノードの UUID アドレスを取得します。
> curl -u sysAdminEmail:password http://<node_IP>:8084/v1/servers/self
"
"
"
"
""
""
""
""
""
" とします。
Postgres サーバーが実行されていない場合は、Management Server で次のコマンドを実行して UUID を確認できます。
> curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/servers?pod=analytics
このコマンドの出力には、各 Postres ノードの UUID がリストされます。 - 前の手順を繰り返して、旧スタンバイ ノードと新しいマスターノードの IP アドレスを取得します。
- 旧マスターノードと旧スタンバイ ノードをコンシューマ グループから削除します。
> curl -u sysAdminEmail:password -X DELETE "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001https://consumers.group
masterUUID,standbyUUID は、上記の現在の分析グループとコンシューマ グループの情報を表示したときと同じ順序で表示されます。standbyUUID,masterUUID として指定する必要があります。
これで、consumer-groups の datastores プロパティが空白になります。 - 旧マスターノードと旧スタンバイ ノードを分析グループから削除します。
> curl -u sysAdminEmail:password -X DELETE "http://<ms_IP>:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,sander-postgres.snow-postgres - 新しい PG マスターノードと PG スタンバイ ノードを登録します。
curl -u sysAdminEmail:password"
"
""
"
"
"
"
"
"
"
"
"所有している デバイスの商品を有効にすると
""
""
" Test "" " [ホーム] - 分析グループを検証します。
> curl -u sysAdminEmail:password http://<ms_IP>:8080/v1/analytics/groups/ax
分析グループとコンシューマ グループに新しいマスターノードとスタンバイ ノードの UUID がリストされるはずです。 - Edge Management Server を再起動します。
> /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart - すべての Qpid サーバーを再起動します。
> /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart - すべての Postgres サーバーを再起動します。
> /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart - 両方のサーバーで、次のスクリプトを実行してレプリケーション ステータスを確認します。両方のサーバーで同じ結果が表示されれば、レプリケーションは成功しています。
新しいマスターで、次のコマンドを実行します。
> /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master
マスターと記述されていることを確認します。
旧スタンバイ ノードの場合:
> /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby
スタンバイと表示されることを確認します。 - 複数の API リクエストを実行してノードが同期していることを確認してから、前のステップを繰り返します。
- Apigee Edge を 4.16.09 に更新するの手順に沿って、古い Postgres マスターを廃止します。
注: 旧マスターノードで Qpid が実行されていた場合は、Qpid を実行するためにそのサーバーを稼働したままにできます。サーバーが稼働していることを確認してください。起動していない場合は、起動します。
> /opt/apigee/apigee-service/bin/apigee-service edge-management-server start
または、次に示すように、旧マスターノードから Qpid をアンインストールし、新しいマスターノードに Qpid をインストールすることもできます。Qpid をインストールした後、旧マスターノードを廃止できます。
Qpid を古いマスターからアンインストールし、Qpid を新しいマスターにインストールします。
旧マスターから Qpid をアンインストールし、新しいマスターにインストールする手順は次のとおりです。
- すべての Message Processor で次のコマンドを実行して、古いマスターの Qpid ポート 5672 による Message Processor によるアクセスをブロックします。
> iptables -A OUTPUT -p tcp -d 10.233.147.20 --dport 5672 -j DROP - 次のコマンドを実行して、Qpid メッセージ キューが空であることを確認します。すべての保留中のメッセージを処理するまで、Qpid をアンインストールすることはできません。
> qpid-stat -q
このコマンドは、msg、msgIn、msgOut のカウントを含むテーブルを表示します。msg=0 と msgIn=msgOut のすべてのメッセージは処理済みです。 - 旧マスターで次のコマンドを実行して、旧マスターで Qpid サーバーの UUID を確認します。この情報は後の手順で保存します。
> curl -u sysAdminEmail:password http://<node_IP>::8083/v1/servers/self - 旧マスターで Qpid を停止します。
> /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
> /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop - Qpid サーバーのアンインストール:
> /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server uninstall
> /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall - 既存の Qpid サーバーをアナリティクス グループとコンシューマ グループから削除します。
> curl -u
http
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
/
"
"
"
/
"
"
"
/[繁体/グループ名]/
/http/
/[例: /http/[グループ名]
"
"
"[HTTP/HTTP"."""""
"
"
"
/[例]"
"
"/[HTTP / "
"" "
"" """<https" " """発注" / " / " """]" - 古い Qpid サーバーを Zookeeper から削除します。
> curl -u sysAdminEmail:password -X DELETE http://<ms_IP>:8080/v1/servers/qpid_UUID - 新しいマスターに Qpid をインストールします。
> /opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile - 新しいマスターで次のコマンドを実行し、新しいマスターで Qpid サーバーの UUID を確認します。この情報は後の手順で保存します。
> curl -u sysAdminEmail:password http://<node_IP>::8083/v1/servers/self - 新しい Qpid Server をアナリティクス グループとコンシューマ グループに登録します。
-
http://id/
"
"
"
"
/
"
"
"
"
"
"
"
"
"
"登録チャンネル 認証手順の開 / X" "" http://example ""
" "
"登録チャンネル / 手順の ""
"""http://example.""example" ""http://example."" ""example" """ - すべての Message Processor を再起動します。
> /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart - 新しい Qpid サーバーで次のコマンドを実行して、キューが作成されたことを確認します。
> qpid-stat -q
Qpid サーバーがメッセージを処理する際に、msg、msgIn、
Out が更新されていることを確認します。
4.17.01 から個々のコンポーネントをロールバックするには
ロールバックの一環として、最新バージョンの Edge 用の bootstrap.sh ファイルをダウンロードする必要があります。
- 4.16.09 にロールバックする場合は、bootstrap_4.16.09.sh をダウンロードします。
- 4.16.05 にロールバックする場合は、bootstrap_4.16.05.sh をダウンロードします。
- 4.16.01 にロールバックする場合は、bootstrap.sh をダウンロードします。
コンポーネントをホストしているロールバック対象のノードごとに、次の操作を行います。
- ロールバックするコンポーネントを停止します。
-
ノード上のいずれかのコンポーネント(Management Server、Router、Message Processor、Qpid Server、Postgres Server)をロールバックする場合は、それらをすべて停止する必要があります。
- > apigee-service edge-management-server stop
- > apigee-service edge-router stop
- > apigee-service edge-message-processor stop
- > apigee-service edge-qpid-server stop
- > apigee-service edge-postgres-server stop
-
ノード上の他のコンポーネントをロールバックする場合は、そのコンポーネントのみを停止します。
- > apigee-service comp stop
-
ノード上のいずれかのコンポーネント(Management Server、Router、Message Processor、Qpid Server、Postgres Server)をロールバックする場合は、それらをすべて停止する必要があります。
- Monetization をロールバックする場合は、すべての Management Server ノードと Message Processor ノードから Monetization をアンインストールします。
> apigee-service edge-mint-gateway アンインストール - ロールバックするコンポーネントをノードからアンインストールします。
- ノード上の次のコンポーネント(Management Server、Router、Message Processor、Qpid Server、Postgres Server)をロールバックする場合は、それらのコンポーネントをすべてアンインストールします。
> apigee-service edge-gateway のアンインストール - ノード上の他のコンポーネントをロールバックする場合は、そのコンポーネントのみをアンインストールします。
> apigee-service comp をアンインストールします。 - Router をロールバックする場合は、/opt/nginx/conf.d の内容を削除する必要があります。
> cd /opt/nginx/conf.d
> rm -rf *
- ノード上の次のコンポーネント(Management Server、Router、Message Processor、Qpid Server、Postgres Server)をロールバックする場合は、それらのコンポーネントをすべてアンインストールします。
-
コンポーネントをロールバックするには:
- 4.17.01 バージョンの apigee-setup をアンインストールします。
> /opt/apigee/apigee-service/bin/apigee-service apigee-setup アンインストール - 4.16.01、4.16.05、または 4.16.09 リリースの bootstrap.sh をダウンロードします。
例:4.16.09 の場合:
> curl https://software.apigee.com/bootstrap_4.16.09.sh -o /tmp/bootstrap - 4.16.01、4.16.05、または 4.16.09 の apigee-service ユーティリティと依存関係をインストールします。
4.16.09 の場合:
> sudo bash /tmp/bootstrap_4.16.09.sh apigeeuser=uName apigeepassword=pWord
ここで、uName と pWord は Apigee から取得したユーザー名とパスワードです。
pWord を省略すると、パスワードの入力を求められます。 - apigee-setup の 4.16.01、4.16.05、または 4.16.09 バージョンをインストールします。
> /opt/apigee/apigee-service/bin/apigee-service apigee-setup install - 4.16.01、4.16.05、または 4.16.09 バージョンのコンポーネントをインストールします。
> /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile
ここで、comp はインストールするコンポーネントで、
0.4.4.4 または 6.4.4 です。 - Qpid をロールバックする場合は、iptables を消去します。
> sudo iptables -F
- 4.17.01 バージョンの apigee-setup をアンインストールします。
-
4.17.01 リリースの特定のバージョンにコンポーネントをロールバックするには:
- 特定のコンポーネントのバージョンをダウンロードします。
> /opt/apigee/apigee-service/bin/apigee-service comp-version install
ここで、comp-version はインストールするコンポーネントとバージョンです。次に例を示します。
> /opt/apigee/apigee-service/bin/apigee-service edge-ui-4.17.01-0.0.3749 install
Apigee オンライン リポジトリを使用している場合は、次のコマンドを使用してコンポーネントのバージョンを確認できます。
> yum --showduplicates list com
例: - apigee-setup を使用して、コンポーネントをインストールします。
> /opt/apigee/apigee-setup/bin/setup.sh -p comp -f configFile
例:
> /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile のインストール時に指定する
方法では
コンポーネントのみを指定する
- 特定のコンポーネントのバージョンをダウンロードします。
ロールバック時に問題が発生した場合は、Apigee サポートにお問い合わせください。