ダウンタイムなしで AWS で Confluence クラスタをアップグレード
このドキュメントでは、CloudFormation によってオーケストレーションされた AWS デプロイでのローリング アップグレードの実行のステップバイステップの手順について説明します。特に、これらの手順は、AWS クイック スタートに基づく Confluence Data Center デプロイに適しています。
ローリング アップグレードの概要 (計画および準備情報を含む) については、ダウンタイムなしで Confluence をアップグレードを参照してください。
ステップ 1 - アップグレード モードの有効化
アップグレード モードを有効化するには、次の手順を実行します。
> [一般設定] > [Rolling upgrades (ローリング アップグレード)] に移動します。- アップグレード モード トグル (1) を選択します。
スクリーンショット: ローリング アップグレード画面。
実行中のタスクとアクティブ ユーザー
各ノードについて、[Tasks running (実行中のタスク)] (2) 列には、そのノードで実行されている長時間実行のタスクの数が表示され、[Active users (アクティブ ユーザー)]はログインしているユーザーの数を示します。最初にアップグレードするノードを選択するときは、実行中のタスク数とアクティブ ユーザーが最も少ないノードから始めます。
アップグレード モードを有効にすると、クラスタは、新しいバグ修正バージョンを実行しているノードを受け入れることができます。これにより、1 つのノードをアップグレードし、そのノードを (アップグレードされていない他のノードとともに) クラスタに再追加できます。アップグレードされたアクティブ ノードとアップグレードされていないアクティブ ノードの両方が連携して、Confluence をすべてのユーザーが使用できるようにします。
まだノードをアップグレードしていない場合、アップグレード モードを無効化できます。
ステップ 2: スタック内の現在のすべてのアプリケーション ノードを見つける
AWS で、スタック内で実行中のすべてのアプリケーション ノードの Instance ID を記録します。これらはすべて、現在のバージョンを実行しているアプリケーション ノードです。後の手順でこれらの ID が必要となります。
AWS コンソールで、[Services] > [CloudFormation] に移動します。デプロイメントのスタックを選択してスタックの詳細を表示します。
- [Resources] ドロップダウンを展開します。[ClusterNodeGroup] を探し、その Physical ID をクリックします。Jira アプリケーション ノードの Auto Scaling Group の詳細を示すページが開きます。
- Auto Scaling Group の詳細で、[Instances] タブをクリックします。ここに表示されているすべての Instance ID を記録します。これらを以降のステップで終了します。
ステップ 3: CloudFormation テンプレートの更新
デプロイでは、環境の各コンポーネントを定義する CloudFormation テンプレートを使用します。この場合、Confluence をアップグレードすることは、テンプレートで使用されている Confluence のバージョンを更新することを意味します。アップグレード時には、クラスタにノードを一時的に追加することを強くお勧めします。
- AWS コンソールで、[Services] > [CloudFormation] に移動します。デプロイメントのスタックを選択してスタックの詳細を表示します。
- スタックの詳細画面で、[Update Stack] をクリックします。
- [Select Template] 画面で、[Use current template] を選択してから、[Next] をクリックします。
- Version パラメーターを、更新先のバージョンに設定します。これはローリング アップグレードなので、これより後のバグ修正バージョンにしか設定できません。
- 新しい Jira ノードをクラスタに追加します。これによって、クラスタでユーザー トラフィックに対するノードの不足が発生しにくくなります。これを行うには、次のパラメーターの値を 1 増やします。
- Maximum number of cluster nodes
- Minimum number of cluster nodes
- 次へ をクリックします。 以降のページをクリックして進み、[Update] ボタンを使用して変更を適用します。
スタックを更新すると、新しい Confluence バージョンを実行している追加ノードが 1 つ作成されます。アップグレード モードを有効にすると、そのノードはクラスタに参加して作業を開始できます。他のノードはまだアップグレードされません。
最初にアップグレードされたノードがクラスタに参加するとすぐに、クラスタのステータスは Mixed に移行します。つまり、すべてのノードで同じバージョンが実行されるまで、アップグレード モードを無効にすることはできません。
アップグレードされた新しいノードが Active 状態で実行されると、別のノードのアップグレードを開始できます。これを行うには、ノードをシャットダウンして終了します。AWS は、更新された Confluence バージョンを実行している新しいノードにノードを置き換えます。
ステップ 4: 他のノードをアップグレードする
最も負荷のノードから開始する
実行中のタスクとアクティブ ユーザーの数が最も少ないノードのアップグレードを開始することをお勧めします。[ローリング アップグレード] ページの [Cluster overview (クラスタの概要)] セクションに両方が表示されます。
ステップ 2 では、クラスタ内の各ノードのインスタンス ID を記録しました。Confluence を正常にシャットダウンしたノードを終了します。この操作を行うには、次の手順を実行します。
- AWS コンソールで、[Services] > [EC2] に進みます。[Running Instances] をクリックします。
- Confluence を正常にシャットダウンしたノードと一致するインスタンスを確認します。
- [Actions] ドロップダウンから、[Instance State] > [Terminate] を選択します。
- クリック スルーして、インスタンスを終了します。
ノードを終了するたびに、AWS は自動的にそれを交換します。置換では、新しいバージョンの Confluence が実行されます。新しいノードのステータスが [Active] になったら、別のノードのアップグレードに進むことができます。
ステップ 5: 残りのノードを個別にアップグレードする
この時点で、クラスタには新しいバージョンの Confluence を実行する 2 つのノードが必要です。これで、他のノードをアップグレードできます。これを行うには、別のノードで前の手順を繰り返します。通常通り、毎回、実行するタスクの数が最も少ないノードをアップグレードすることをお勧めします。
デプロイでスタンドアロン Synchrony を使用している場合は、各 Synchrony ノードで使用されているバージョンも更新する必要がある場合があります。これを行うには、すべてのノードを新しいバージョンにアップグレードした後、各 Synchrony ノードを順に終了します。
ステップ 6. アップグレードを完了する
ステップ 7: クラスタをスケール ダウンする
ステップ 3 では、終了した各ノードの置き換えとして、ノードをクラスタに一時的に追加しました。これは、通常のユーザー トラフィックを処理するのに十分なノードがあることを確認するためでした。アップグレードを完了したら、そのノードを削除できます。
- AWS コンソールで、[Services] > [CloudFormation] に移動します。デプロイメントのスタックを選択してスタックの詳細を表示します。
- スタックの詳細画面で、[Update Stack] をクリックします。
- [Select Template] 画面で、[Use current template] を選択してから、[Next] を選択します。
- 次のパラメーターの値を 1 減らします。
- Maximum number of cluster nodes
- Minimum number of cluster nodes
- 次へ をクリックします。 以降のページをクリックして進み、[Update] ボタンを使用して変更を適用します。
AWS を置き換えることなく、クラスタから 1 つのノードを削除できるようになりました。この操作を行うには、次の手順を実行します。
- 実行中のタスクの数が最も少ないノードを選択します。
- ノードで Confluence をグレースフル シャットダウンします。
- ノードを終了します。
詳細な手順については、ステップ 4 を参照してください。
トラブルシューティング
ロード バランサーを使用してクラスタからノードを切断する
エラーによってノードを終了できない場合は、ロード バランサーを使用してクラスタからノードを切断してみてください。AWS Application Load Balancer では、各ノードがターゲットとして登録されているため、ノードを切断するには、登録を解除する必要があります。これを行う方法の詳細については、Application Load Balancers のターゲット グループと登録済みターゲットを参照してください。
アップグレード中またはアップグレード後にトラフィックが不均一に分散しています
ロード バランサーによっては、新しくアップグレードされたノードに、不均一な数のアクティブ ユーザーを送信する方法が採用される場合があります。この場合、ノードが過負荷になり、ノードにログインしているすべてのユーザーの Confluence が遅くなる可能性があります。
この問題に対処するには、ノードをクラスタから一時的に切断することもできます。これにより、ロード バランサーは、他のすべての利用可能なノード間でアクティブなユーザーを再分配します。その後、クラスタにノードを再度追加できます。
ローリング アップグレード中のノード エラー
対処方法はいくつかあります。
ノードで Confluence をグレースフル シャットダウンします。これにより、ノードがクラスタから切断され、ノードが Offline ステータスにトランジションできるようになります。
Confluence を正常にシャットダウンできない場合は、ノードを完全にシャットダウンしてください。
すべてのアクティブ ノードがアップグレードされたら、ローリング アップグレードを完了できます。問題のあるノードの問題を後で調査し、エラーに対処したら、クラスタに再接続できます。
元のバージョンにロール バックする
- まだアップグレードされていない
- エラー状態になっている
アップグレードされたノードがクラスタに参加するか、ノードがエラー状態になると、クラスタのステータスは Mixed に変わります。
アップグレード モードが無効になっている Mixed ステータス
アップグレード モードが無効のノードが Error 状態の場合、アップグレード モードを有効にすることはできません。問題を修正するか、クラスタからノードを削除して、アップグレード モードを有効にします。
アップグレードしたノードを元のバージョンにロール バックするには、次の手順を実行します。
AWS コンソールで、[Services] > [CloudFormation] に移動します。デプロイメントのスタックを選択してスタックの詳細を表示します。
スタックの詳細画面で、[スタックの更新] を選択します。
[Select Template] 画面で、[Use current template] を選択してから、[Next] を選択します。
- Version パラメーターを元のバージョンに設定します。
- 次へ を選択します。以降のページをクリックして進み、[Update] ボタンを使用して変更を適用します。
その後、Confluence の新しいバージョンを実行しているすべてのノードを終了します。AWS は、それぞれを元のバージョンを実行しているノードに置き換えます。すべてのノードで同じバージョンが実行されると、クラスタのステータスは [Ready to upgrade (アップグレードの準備完了)] に戻ります。これにより、アップグレード モードを無効にすることもできます。