ダウンタイムなしで Confluence クラスタを手動アップグレード
このドキュメントでは、自動化がほとんどまたはまったく行われないデプロイでローリング アップグレードを実行する方法のステップバイステップの手順について説明します。その手順は、Azure テンプレートに基づくデプロイにも適しています。
ローリング アップグレードの概要 (計画および準備情報を含む) については、ダウンタイムなしで Confluence をアップグレードを参照してください。
ステップ 1: アップグレード ファイルをダウンロードする
また、
> [全般設定] > [アップグレードを計画] に移動して、アップグレード前チェックを実行し、対応しているバグ修正アージョンをダウンロードすることもできます。
ステップ 2 - アップグレード モードの有効化
アップグレード モードを有効化するには、次の手順を実行します。
- > [一般設定] > [Rolling upgrades (ローリング アップグレード)] に移動します。
- アップグレード モード トグル (1) を選択します。
スクリーンショット: ローリング アップグレード画面。
実行中のタスクとアクティブ ユーザー
各ノードについて、[Tasks running (実行中のタスク)] (2) 列には、そのノードで実行されている長時間実行のタスクの数が表示され、[Active users (アクティブ ユーザー)]はログインしているユーザーの数を示します。最初にアップグレードするノードを選択するときは、実行中のタスク数とアクティブ ユーザーが最も少ないノードから始めます。
アップグレード モードを有効にすると、クラスタは、新しいバグ修正バージョンを実行しているノードを受け入れることができます。これにより、1 つのノードをアップグレードし、そのノードを (アップグレードされていない他のノードとともに) クラスタに再追加できます。アップグレードされたアクティブ ノードとアップグレードされていないアクティブ ノードの両方が連携して、Confluence をすべてのユーザーが使用できるようにします。
まだノードをアップグレードしていない場合、アップグレード モードを無効化できます。
ステップ 3: 1 つ目のノードをアップグレードする
最も負荷のノードから開始する
実行中のタスクとアクティブ ユーザーの数が最も少ないノードのアップグレードを開始することをお勧めします。[ローリング アップグレード] ページの [Cluster overview (クラスタの概要)] セクションに両方が表示されます。
まず、ノードで 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: 残りのノードを個別にアップグレードする
アップグレードしたノードを起動した後、Cluster の概要に Active ステータスでノードが表示されるのを待ちます。アップグレードが終了したら、前のステップの手順を使用して、別のノードのアップグレードを開始できます。これを他の各ノードにも行います – 通常通り、毎回、実行するタスクの数が最も少ないノードをアップグレードすることをお勧めします。
ステップ 5. アップグレードを完了する
トラブルシューティング
ローリング アップグレード中のノード エラー
対処方法はいくつかあります。
ノードで Confluence をグレースフル シャットダウンします。これにより、ノードがクラスタから切断され、ノードが Offline ステータスにトランジションできるようになります。
Confluence を正常にシャットダウンできない場合は、ノードを完全にシャットダウンしてください。
すべてのアクティブ ノードがアップグレードされたら、ローリング アップグレードを完了できます。問題のあるノードの問題を後で調査し、エラーに対処したら、クラスタに再接続できます。
ノードを元のバージョンにロールバックする
- まだアップグレードされていない
- エラー状態になっている
アップグレードされたノードがクラスタに参加するか、ノードがエラー状態になると、クラスタのステータスは Mixed に変わります。
アップグレード モードが無効になっている Mixed ステータス
アップグレード モードが無効のノードが Error 状態の場合、アップグレード モードを有効にすることはできません。問題を修正するか、クラスタからノードを削除して、アップグレード モードを有効にします。
アップグレードしたノードを元のバージョンにロール バックするには、次の手順を実行します。
コマンド ラインまたは SSH からノードにアクセスします。
ノードで Confluence をグレースフル シャットダウンします。
ノードがオフラインになるまで待ちます。[ローリング アップグレード] ページの [クラスタ概要] セクションの [ノード ステータス] 列でステータスを監視できます。
- Confluence をサービスとして実行している場合、
- Windows の場合、
<old-install-directory>/bin/service.batを実行して、新しいサービスを削除して古いサービスを再インストールします。 - Linux の場合、サービスを更新して古いインストール ディレクトリを指定します (または、シンボリック リンクを使用して指定します)。
- Windows の場合、
1 つのノードで Confluence を起動します。セットアップ ウィザードが表示されないはずです。
すべてのノードで同じバージョンが実行されると、クラスタのステータスは [Ready to upgrade (アップグレードの準備完了)] に戻ります。アップグレード モードをオフにできます。
ロード バランサーを使用してクラスタからノードを切断する
ノード エラーによって Confluence をグレースフル シャットダウンできない場合は、ロード バランサーを使用してクラスタからノードを切断してみてください。次の表に、一般的なロード バランサーでこれを行う方法を示します。
| NGINX | NGINX は、アップストリーム ディレクティブを介してクラスタ ノードのグループを定義します。ロード バランサーがノードに接続できないようにするには、対応するアップストリーム グループからノードのエントリを削除します。ngx_http_upstream_module モジュールのアップストリーム ディレクティブの詳細をご確認ください。 |
|---|---|
| HAProxy | HAProxy で、ノードへのトラフィックをすべて無効にするには、 サーバーの管理状態の強制の詳細をご確認ください。 |
| Apache | ノード (または「ワーカー)」 を無効にするには、そのアクティブ化メンバー属性を disabled に設定します。Apache における高度なロード バランサー ワーカー プロパティの詳細をご確認ください。 |
| Azure アプリケーション ゲートウェイ | Azure の Confluence Data Center 用のデプロイ テンプレートを提供しています。このテンプレートは、ロード バランサーとして Azure Application Gateway を使用しています。Azure Application Gateway は、各ノードをバックエンド プール内のターゲットとして定義しています。ノードの対応するエントリを削除するには、バックエンド プール編集インターフェイスを使用します。バックエンド プールからのターゲットの追加 (および削除) の詳細をご確認ください。 |
アップグレード中またはアップグレード後にトラフィックが不均一に分散しています
ロード バランサーによっては、新しくアップグレードされたノードに、不均一な数のアクティブ ユーザーを送信する方法が採用される場合があります。この場合、ノードが過負荷になり、ノードにログインしているすべてのユーザーの Confluence が遅くなる可能性があります。
この問題に対処するには、ノードをクラスタから一時的に切断することもできます。これにより、ロード バランサーは、他のすべての利用可能なノード間でアクティブなユーザーを再分配します。その後、クラスタにノードを再度追加できます。