ダウンタイムなしで API によって Confluence クラスタをアップグレード
このドキュメントでは、API 呼び出しを使用してローリング アップグレードを開始および確定する方法について説明します。このアップグレード方法は、メンテナンス タスク (アップグレードなど) を調整するためのスキルと自動化ツールを持つ管理者に適しています。
ローリング アップグレードの概要 (計画および準備情報を含む) については、ダウンタイムなしで Confluence をアップグレードを参照してください。
API のリファレンス
ローリング アップグレード プロセス全体は、次の API によって管理されます。
http://<host>:<port>/rest/zdu/cluster/zdu/
この API では、次の呼び出しを使用します。
クラスタのステータスの概要を確認します。 | |
アップグレード モードを有効化します。 | |
クラスタのステータスを取得します。 | |
実行中のタスクの数を含む、ノードのステータスの概要を取得します。 | |
アップグレード モードを無効化します。このコールは、アップグレードの進捗が MIXED でない場合にのみ使用できます。 | |
すべてのノードがアップグレードされたら、ローリング アップグレードを終了します。これにより、アップグレード モードが無効化されます。 |
各 API 呼び出しの詳細については、Confluence REST API ドキュメントを参照してください。
ローリング アップグレードの開始
ローリング アップグレードを開始するには、最初にローリングアップ グレードを有効にします。これを行うには、次のものを使用します。
http://<host>:<port>/rest/zdu/cluster/zdu/start
アップグレード モードを有効にすると、クラスタは、新しいバグ修正バージョンを実行しているノードを受け入れることができます。これにより、1 つのノードをアップグレードし、そのノードを (アップグレードされていない他のノードとともに) クラスタに再追加できます。アップグレードされたアクティブ ノードとアップグレードされていないアクティブ ノードの両方が連携して、Confluence をすべてのユーザーが使用できるようにします。
まだノードをアップグレードしていない場合、アップグレード モードを無効化できます。
各ノード個別アップグレード
ノードをアップグレードする前に、そのノードの Confluence をグレースフル シャットダウンする必要があります。これを行うには、オペレーティング システムと設定に対応する停止スクリプトを実行します。グレースフル Confluence シャットダウンの詳細については、こちらをご覧ください。
たとえば、Linux に Confluence をサービスとしてインストールしている場合は、次のコマンドを実行します。
$ sudo /etc/init.d/confluence stop
ノードで Confluence をアップグレードした後、ノードが Active ステータスに移行するまで待ってから、別のノードをアップグレードします。
ノード ステータス
ノードのステータスを取得するには、次のものを使用します。
http://<host>:<port>/rest/zdu/cluster/zdu/nodes/<nodeID>
ACTIVE | Confluence はクラスタに接続され、エラーなしで実行されます。 |
---|---|
STARTING | Confluence はまだロード中であり、完了したら Active に移行する必要があります。 |
TERMINATING | Confluence がグレースフル シャットダウンされ、完了したら Offline に移行する必要があります。 |
OFFLINE | Confluence がどのノードでも応答していません。アップグレード モードが無効になった後もオフラインのままであれば、このノードはクラスタから完全に削除されます。 |
エラー | ノード上の Confluence で何か問題ありました。 |
クラスタ ステータス
クラスタのステータスを取得するには、次のものを使用します。
http://<host>:<port>/rest/zdu/cluster/zdu/state
STABLE | アップグレード モードをオンにできます。 |
---|---|
READY_TO_UPGRADE | アップグレード モードは有効ですが、まだアップグレードされたノードはありません。最初のノードのアップグレードを開始できます。 |
mixed | 少なくとも 1 つのノードがアップグレードされていますが、アップグレードが完了していないノードがあります。クラスタに、異なる Confluence バージョンを実行しているノードがあります。次のステータス (READY_TO_RUN_UPGRADE_TASKS) に移行するには、すべてのノードを同じバグ修正バージョンにアップグレードする必要があります。 |
READY_TO_RUN_UPGRADE_TASKS | すべてのノードがアップグレード済みです。ローリング アップグレードを完了できます。
|
アップグレード モードを有効化または無効化する
- まだアップグレードされていない
- エラー状態になっている
アップグレードされたノードがクラスタに参加するか、ノードがエラー状態になると、クラスタのステータスは Mixed に変わります。
アップグレード モードが無効になっている Mixed ステータス
アップグレード モードが無効のノードが Error 状態の場合、アップグレード モードを有効にすることはできません。問題を修正するか、クラスタからノードを削除して、アップグレード モードを有効にします。
トラブルシューティング
ローリング アップグレード中のノード エラー
対処方法はいくつかあります。
ノードで Confluence をグレースフル シャットダウンします。これにより、ノードがクラスタから切断され、ノードが Offline ステータスにトランジションできるようになります。
Confluence を正常にシャットダウンできない場合は、ノードを完全にシャットダウンしてください。
すべてのアクティブ ノードがアップグレードされたら、ローリング アップグレードを完了できます。問題のあるノードの問題を後で調査し、エラーに対処したら、クラスタに再接続できます。
ロード バランサーを使用してクラスタからノードを切断する
ノード エラーによって Confluence をグレースフル シャットダウンできない場合は、ロード バランサーを使用してクラスタからノードを切断してみてください。次の表に、一般的なロード バランサーでこれを行う方法を示します。
NGINX | NGINX は、アップストリーム ディレクティブを介してクラスタ ノードのグループを定義します。ロード バランサーがノードに接続できないようにするには、対応するアップストリーム グループからノードのエントリを削除します。ngx_http_upstream_module モジュールのアップストリーム ディレクティブの詳細をご確認ください。 |
---|---|
HAProxy | HAProxy で、ノードへのトラフィックをすべて無効にするには、
サーバーの管理状態の強制の詳細をご確認ください。 |
Apache | ノード (または「ワーカー)」 を無効にするには、そのアクティブ化メンバー属性を disabled に設定します。Apache における高度なロード バランサー ワーカー プロパティの詳細をご確認ください。 |
Azure アプリケーション ゲートウェイ | Azure の Confluence Data Center 用のデプロイ テンプレートを提供しています。このテンプレートは、ロード バランサーとして Azure Application Gateway を使用しています。Azure Application Gateway は、各ノードをバックエンド プール内のターゲットとして定義しています。ノードの対応するエントリを削除するには、バックエンド プール編集インターフェイスを使用します。バックエンド プールからのターゲットの追加 (および削除) の詳細をご確認ください。 |
アップグレード中またはアップグレード後にトラフィックが不均一に分散しています
ロード バランサーによっては、新しくアップグレードされたノードに、不均一な数のアクティブ ユーザーを送信する方法が採用される場合があります。この場合、ノードが過負荷になり、ノードにログインしているすべてのユーザーの Confluence が遅くなる可能性があります。
この問題に対処するには、ノードをクラスタから一時的に切断することもできます。これにより、ロード バランサーは、他のすべての利用可能なノード間でアクティブなユーザーを再分配します。その後、クラスタにノードを再度追加できます。