ダウンタイムなしで Confluence クラスタを手動アップグレード
このドキュメントでは、自動化がほとんどまたはまったく行われないデプロイでローリング アップグレードを実行する方法のステップバイステップの手順について説明します。その手順は、Azure テンプレートに基づくデプロイにも適しています。
ローリング アップグレードの概要 (計画および準備情報を含む) については、ダウンタイムなしで Confluence をアップグレードを参照してください。
ステップ 1: アップグレード ファイルをダウンロードする
また、
> [全般設定] > [アップグレードを計画] に移動して、アップグレード前チェックを実行し、対応しているバグ修正アージョンをダウンロードすることもできます。
ステップ 2 - アップグレード モードの有効化
アップグレード モードを有効化するには、次の手順を実行します。
- > [一般設定] > [Rolling upgrades (ローリング アップグレード)] に移動します。
- アップグレード モード トグル (1) を選択します。
スクリーンショット: ローリング アップグレード画面。
クラスタの概要は、最初にアップグレードするノードを選択する際に役立ちます。タスク実行中 (2) 列ではそのノードで長時間実行されているタスクの数が、[アクティブなユーザー] ではログイン済みのユーザー数が表示されます。最初にアップグレードするノードを選択する際は、実行中のタスク数とアクティブ ユーザーが最も少ないノードから始めましょう。
アップグレード モードでは、クラスタは異なる Confluence バージョンを実行しているノードを一時的に受け入れられます。これによって、1 つのノードをアップグレードして (アップグレードされていない他のノードと併せて) クラスタに再度追加できます。アップグレード済みとアップグレードされていないアクティブ ノードの両方が連携することで、すべてのユーザーが Confluence を使用できます。まだノードをアップグレードしていない場合は、アップグレード モードを無効化できます。
ステップ 3: 1 つ目のノードをアップグレードする
最も負荷のノードから開始する
実行中のタスクとアクティブ ユーザーの数が最も少ないノードのアップグレードを開始することをお勧めします。これは、ローリング アップグレードのページで確認できます。
まず、ノードで Confluence をグレースフル シャットダウンします。
コマンド ラインまたは SSH からノードにアクセスします。
ノードで Confluence をグレースフル シャットダウンします。これを行うには、オペレーティング システムと設定に対応する停止スクリプトを実行します。たとえば、Linux 上のサービスとして Confluence をインストールした場合、次のコマンドを実行してください。
$ sudo /etc/init.d/confluence stop
グレースフル Confluence シャットダウンの詳細をご確認ください
グレースフル シャットダウンによって、Confluence ノードがオフラインになる前にすべてのタスクを終了できるようになります。シャットダウン中、ノードのステータスは終了になり、ノードに送信されたユーザー リクエストはロード バランサーによって他のアクティブ ノードにリダイレクトされます。Linux または Docker で実行中のノードの場合、
killコマンドでグレースフル シャットダウンをトリガーすることもできます (これは、Confluence プロセスに直接SIGTERM信号を送信します)。ノードがオフラインになるまで待ちます。[ローリング アップグレード] ページの [クラスタ概要] セクションの [ノード ステータス] 列でステータスを監視できます。
ノードのステータスがオフラインになったら、ノードのアップグレードを開始できます。そのノードのローカル ファイル システムにダウンロードされた Confluence インストール ファイルをコピーします。
1 つ目のノードをアップグレードするには：
- ディレクトリ（新しいインストールディレクトリ。既存のインストール ディレクトリとは異なる必要があります）にファイルを抽出（解凍）する
<Installation-Directory>\confluence\WEB-INF\classes\confluence-init.propertiesファイルで次の行を更新し、対象のノードの既存のローカル ホーム ディレクトリを指すようにします。- でプリで MySQL データベースを利用している場合、既存の Confluence インストール ディレクトリから新しいインストール ディレクトリの
confluence/WEB-INF/libに jdbc ドライバーの jar ファイルをコピーします。
jdbc ドライバーは<Install-Directory>/common/libまたは<Installation-Directory>/confluence/WEB-INF/libディレクトリにあります。詳細については、MySQL データベース セットアップを参照してください。 - Confluence をサービスとして実行している場合、
<install-directory>/bin/service.batを実行して、既存のサービスを削除してサービスを再インストールします。- Linux で、サービスを更新して新しいインストール ディレクトリを指定します (または、シンボリック リンクを使用して指定します)。
その他の必要なカスタマイズを旧バージョンから新バージョンに直ちにコピーします (Confluence をデフォルトのポートで実行していない場合、または外部でユーザーを管理している場合、関連ファイルをアップデートおよびコピーする必要があります - 詳細は Confluence を手動でアップグレードするを参照してください)。
Confluence が Windows または Linux サービスとして実行されるように設定している場合、必ずサービス設定も更新してください。関連情報については、Confluence をサービスとして Windows 上で自動的に開始または Linux で systemd サービスとして Conluence を実行を参照してください。
- Confluence を起動し、次のステップに進む前に、ログインできるか、ページを閲覧できるか、確認してください。
最初にアップグレードされたノードがクラスタに参加するとすぐに、クラスタのステータスは Mixed に移行します。つまり、すべてのノードで同じバージョンが実行されるまで、アップグレード モードを無効にすることはできません。
Synchrony のアップグレード (オプション)
Confluence で Synchrony を管理している場合 (推奨)、操作は不要です。Synchrony は Confluence によって自動的にアップグレードされます。
自分の Synchrony クラスタを実行している場合、アップグレードされた Confluence ノードの <local-home> ディレクトリから新しい synchrony-standalone.jar を入手します。その後、各 Synchrony ノードで次の手順を実行します。
- Synchrony ホーム ディレクトリから
start-synchrony.sh(Linux の場合) またはstart-synchrony.bat(Windows の場合) を使用して、ノード上の Synchrony を停止します。 - Synchrony ホーム ディレクトリに新しい
synchrony-standalone.jarをコピーします。 - Synchrony を通常どおり起動します。
関連情報については、「Confluence Data Center 用に Synchrony クラスタをセットアップする」を参照してください。
ステップ 4: 残りのノードを個別にアップグレードする
アップグレードしたノードを起動したら、クラスターの概要でステータスが「アクティブ」に変わるのを待ちます。この時点で、そのノードのアプリケーション ログを確認した上で、そのノードで Confluence にログインしてすべてが機能していることをご確認ください。この時点ではアップグレードをまだロール バックできるため、テストすることをお勧めします。
最初のノードをテストしたら、同じ手順に従って別のノードのアップグレードを開始できます。これを他の各ノードにも行います – 通常どおり、毎回、実行するタスクの数が最も少ないノードをアップグレードすることをお勧めします。
ステップ 5. アップグレードを完了する
バグ修正バージョンへのアップグレードを完了する
アップグレードを完了するには、次の手順に従います。
- クラスタのステータスが [完了する準備ができました] に変わるのを待ちます。これは、すべてのノードがアクティブとなり、同じアップグレード バージョンを実行するまで発生しません。
- [アップグレードを完了] を選択します。
- アップグレードの完了が確認されるのを待ちます。クラスターのステータスが [安定] に変わります。
これでアップグレードは完了です。
機能バージョンへのアップグレードを完了する
アップグレードを完了するには、次の手順に従います。
- クラスターのステータスが [アップグレード タスクを実行する準備が完了しました] に変わるまで待ちます。すべてのノードがアクティブになって同じアップグレード バージョンを実行するようになるまで、このステータスにはなりません。
- [アップグレード タスクを実行してアップグレードを完了 (Run upgrade tasks and finalize upgrade)] ボタンを選択します。
- 1 つのノードでアップグレード タスクの実行が開始されます。プロセスを監視する場合は、このノードのログを確認します。
- アップグレードの完了が確認されるのを待ちます。クラスターのステータスが [安定] に変わります。
これでアップグレードは完了です。
スクリーンショット: クラスタ全体のアップグレード タスクを実行している 1 つのクラスタ ノード。
トラブルシューティング
ローリング アップグレード中のノード エラー
対処方法はいくつかあります。
ノードで Confluence をグレースフル シャットダウンします。これにより、ノードがクラスタから切断され、ノードが Offline ステータスにトランジションできるようになります。
Confluence を正常にシャットダウンできない場合は、ノードを完全にシャットダウンしてください。
すべてのアクティブ ノードがアップグレードされたら、ローリング アップグレードを完了できます。問題のあるノードの問題を後で調査し、エラーに対処したら、クラスタに再接続できます。
アップグレード タスク失敗のエラー
- アップグレード タスクを実行しているノードのアプリケーション ログで、エラーがないかどうかを確認します。ノード識別子はクラスター ステータス メッセージに含まれています。
- 明らかな問題 (ファイル システムの権限やネットワーク接続の問題など) を解決します
- [アップグレード タスクを再実行してアップグレードを完了する (Re-run upgrade tasks and finalize upgrade)] を選択してしてもう一度お試しください。
アップグレード タスクがまだ失敗して原因を特定できない場合は、サポート チームに相談する必要があります。この時点でアップグレードをロール バックすることもお勧めします。Confluence を長期間アップグレード モードのままにしておくことはお勧めしません。
ノードを元のバージョンにロールバックする
アップグレード モードが無効になっている Mixed ステータス
アップグレード モードが無効のノードが Error 状態の場合、アップグレード モードを有効にすることはできません。問題を修正するか、クラスタからノードを削除して、アップグレード モードを有効にします。
ロード バランサーを使用してクラスタからノードを切断する
ノード エラーによって Confluence をグレースフル シャットダウンできない場合は、ロード バランサーを使用してクラスタからノードを切断してみてください。次の表に、一般的なロード バランサーでこれを行う方法を示します。
| NGINX | NGINX は、アップストリーム ディレクティブを介してクラスタ ノードのグループを定義します。ロード バランサーがノードに接続できないようにするには、対応するアップストリーム グループからノードのエントリを削除します。ngx_http_upstream_module モジュールのアップストリーム ディレクティブの詳細をご確認ください。 |
|---|---|
| HAProxy | HAProxy で、ノードへのトラフィックをすべて無効にするには、 サーバーの管理状態の強制の詳細をご確認ください。 |
| Apache | ノード (または「ワーカー)」 を無効にするには、そのアクティブ化メンバー属性を disabled に設定します。Apache における高度なロード バランサー ワーカー プロパティの詳細をご確認ください。 |
| Azure アプリケーション ゲートウェイ | Azure の Confluence Data Center 用のデプロイ テンプレートを提供しています。このテンプレートは、ロード バランサーとして Azure Application Gateway を使用しています。Azure Application Gateway は、各ノードをバックエンド プール内のターゲットとして定義しています。ノードの対応するエントリを削除するには、バックエンド プール編集インターフェイスを使用します。バックエンド プールからのターゲットの追加 (および削除) の詳細をご確認ください。 |
アップグレード中またはアップグレード後にトラフィックが不均一に分散しています
ロード バランサーによっては、新しくアップグレードされたノードに、不均一な数のアクティブ ユーザーを送信する方法が採用される場合があります。この場合、ノードが過負荷になり、ノードにログインしているすべてのユーザーの Confluence が遅くなる可能性があります。
この問題に対処するには、ノードをクラスタから一時的に切断することもできます。これにより、ロード バランサーは、他のすべての利用可能なノード間でアクティブなユーザーを再分配します。その後、クラスタにノードを再度追加できます。