[KE16] CentOS7 冗長構成アップデートの注意点 (v1.6.2.post1以前→v1.6.2.post2 以降)
# 1. はじめに
CentOS7 環境において Kompira enterprise (以下KE) v1.6 系の冗長構成をアップデートする際の注意点について示します。
## 1.1. 前提条件
以下にすべて当てはまる場合は、本記事での対象となります。
- 冗長構成が構築済みの場合
- KE v1.6.0 以降がインストール済みの場合
- KE v1.6.2.post2 以降にアップデートする場合
- アップデート前の rabbitmq-server / erlang が下記バージョンに該当する場合
- rabbitmq-server-3.3.X （およびそれ以前）
- erlang-R16B-XX.XX （およびそれ以前）
- erlang-22.X.X や erlang-23.X.X などは上記より新しいので該当しません
通常は以下のときに該当します。
- OS が CentOS7 系（未確認ですが RHEL7 系も同様と考えられます）
- KE v1.6.0 ～ v1.6.2.post1 で冗長構成を構築済み
本記事では vSphere 上の CentOS7 環境で、KE を v1.6.1.post4 から v1.6.2.post7 へとアップデートさせる条件で動作確認を実施しています。
なお、KE 1.5 系以前の冗長構成アップデートについては、本記事の対象外です。
# 2. アップデート時の問題点と対策
上記条件においては、通常のアップデート手順ではエラーが発生して、適切に冗長構成を回復することができません。場合によっては、アップデート手順途中で動作中の系が停止してしまうこともあります。
## 2.1. 失敗例
1. スタンバイ系の Pacemaker を停止: `pcs cluster stop`
2. スタンバイ系の Kompira をアップデート: `./install.sh`
3. スタンバイ系をアクティブ系に再同期: `/opt/kompira/bin/sync_master.sh`
- **ここで RabbitMQ が適切に動作できずにエラーとなります。**
この状態になったとき、`pcs cluster stop` でクラスタ停止しようとしても失敗する場合もあります。`kill` コマンドなどで各プロセスを強制終了させてください。
また、場合によってはアクティブ系が停止するなどの問題が生じることもあります。スタンバイ系の pacemaker および各リソースのプロセスを停止させてから、アクティ系を再起動してみてください。
## 2.2. 原因
アップデート前後で RabbitMQ のバージョンが大きく変わるため、設定ファイルの形式が異なること、異バージョン同士でクラスタ構成が組めないこと、といった理由でアップデートしたスタンバイ系が正常に動作できずにエラーとなってしまいます。
## 2.3. 対策
そのため、（少なくとも現時点では）「アクティブ系を動作させたまま、スタンバイ系をアップデートしてクラスタに再度参加させる。その後、系を切り替えて同じ手順を実施する」（フェイルオーバが１回発生する）というアップデートの方針をとることができません。
そこで、**両系を一旦完全に停止させたうえで**、アクティブ系およびスタンバイ系の KE アップデート、およびクラスタ構成の再設定を実施する、という手順が必要になります。
この方針では、前述のフェイルオーバが１回発生する手順にくらべて、サービスの停止時間が長くなることにご注意ください。
# 3. 両系停止アップデート手順
## 3.1. アップデート手順
以下にアップデート手順を示します。ただし、以下を前提としています。
- 冗長構成が適切に構成済みで両系が正常に動作していること。
- クラスタを構築したときと、アクティブ系・スタンバイ系のノードが同一であること。
- クラスタを構築したときの、セットアップ手順が分かっていること。
データのバックアップについては必要に応じて取得してください。
### 3.1.1. クラスタ設定のバックアップ
アクティブ系で以下のコマンドを実行してください。実行したディレクトリに `cib-org.xml` というファイルが出来るので保管しておいてください（以後の手順では特に利用しません）。
```
# pcs cluster cib ./cib-org.xml
```
### 3.1.2. スタンバイ系停止
以下のコマンドでスタンバイ系を停止させてください。
```
# pcs cluster stop
```
可能であれば、この段階でスタンバイ系のスナップショットを取得しておいてください。スナップショット取得のために poweroff する場合は、再起動後に上記コマンドでクラスタを停止させてください。
### 3.1.3. アクティブ系停止
スタンバイ系が停止しているのを確認したうえで、以下のコマンドでアクティブ系を停止させてください。
```
# pcs cluster stop --force
```
可能であれば、この段階でアクティブ系のスナップショットを取得しておいてください。スナップショット取得のために poweroff する場合は、再起動後に上記コマンドでクラスタを停止させてください。
### 3.1.4. スタンバイ系 KE アップデート
両系のクラスタが停止しているのを確認したうえで、スタンバイ系の KE をアップデートしてください。
```
# tar zxf kompira-1.6.2.post7-bin.tar.gz
# cd zxf kompira-1.6.2.post7-bin
# ./install.sh
```
もし、**KE のアップデート自体に失敗する場合は、次の手順に進まないようにしてください**。まずは、環境的な問題がないか、例えばディスクの空き容量はあるか、外部ネットワークに接続できているかなど確認してください。原因が特定できない場合はサポートにお問い合わせください。
KE アップデートに成功しない場合は、冗長構成のアップデートを中止してください。
- アクティブ系を再起動（または `pcs cluster start`）して縮退運転に回復させてください。
- アップデートに失敗したスタンバイ系をそのまま起動させないでください。事前のスナップショットに回復させてから、クラスタに参加させるようにしてください。
### 3.1.5. アクティブ系 KE アップデート
スタンバイ系の KE がアップデートできたことを確認したうえで、同様にアクティブ系の KE もアップデートしてください。アップデート手順はスタンバイ系と同じになります。
KE アップデートに成功しない場合は、冗長構成のアップデートを中止してください。
- アップデートに失敗したアクティブ系をそのまま起動させないでください。事前のスナップショットに回復させてから起動させて、その後同様にスタンバイ系もスナップショットに回復してからクラスタに参加させるようにしてください。
### 3.1.6. アクティブ系クラスタ再設定
両系の KE がアップデートできたことを確認したうえで、アクティブ系でクラスタの再設定を実施してください。
```
# ./setup_cluster --primary ...
```
※ 以前にクラスタを構築したときと同じオプションを指定して `setup_cluster.sh` を実行してください。
正常にクラスタを再設定できていれば、アクティブ系で各リソースが動作を開始するはずです。`pcs status` コマンドなどを用いてリソースの状態を確認してみてください。
```
# pcs status
Cluster name: ha-kompira-52e20d
Stack: corosync
Current DC: ha-kompira1 (version 1.1.23-1.el7_9.1-9acf116022) - partition WITHOUT quorum
Last updated: Mon Oct 11 15:48:27 2021
Last change: Mon Oct 11 10:20:23 2021 by root via cibadmin on ha-kompira1
2 nodes configured
9 resource instances configured
Online: [ ha-kompira1 ]
OFFLINE: [ ha-kompira2 ]
Full list of resources:
Resource Group: webserver
res_memcached (systemd:memcached): Started ha-kompira1
res_httpd (ocf::heartbeat:apache): Started ha-kompira1
res_kompirad (systemd:kompirad): Started ha-kompira1
res_kompira_jobmngrd (systemd:kompira_jobmngrd): Started ha-kompira1
res_lsyncd (systemd:lsyncd): Started ha-kompira1
Master/Slave Set: ms_pgsql [res_pgsql]
Masters: [ ha-kompira1 ]
Stopped: [ ha-kompira2 ]
Clone Set: res_rabbitmq-clone [res_rabbitmq]
Started: [ ha-kompira1 ]
Stopped: [ ha-kompira2 ]
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled
```
すべてのリソースがアクティブ系で起動していれば（`Started` または `Masters` になっていれば）縮退運転できていることになります。ブラウザで Kompira にアクセスできるか確認してみてください。
### 3.1.7. スタンバイ系クラスタ再設定
アクティブ系ですべてのリソースが正常に動作しているのを確認したうえで、スタンバイ系でクラスタの再設定を実施してください。
```
# ./setup_cluster --secondary ...
```
※ 以前にクラスタを構築したときと同じオプションを指定して `setup_cluster.sh` を実行してください。
### 3.1.8. クラスタパラメータの確認と更新
クラスタ構成の一部パラメータについてはアップデートできていない場合があります。まず `pcs` コマンドを用いてリソース `res_pgsql` の設定を確認してください。
```
# pcs resource show res_pgsql
Resource: res_pgsql (class=ocf provider=heartbeat type=pgsqlms)
Attributes: bindir=/usr/pgsql-12/bin pgdata=/var/lib/pgsql/12/data
Operations: demote interval=0s on-fail=restart timeout=60s (res_pgsql-demote-interval-0s)
methods interval=0s timeout=5 (res_pgsql-methods-interval-0s)
monitor interval=7s on-fail=restart timeout=60s (res_pgsql-monitor-interval-7s)
monitor interval=5s on-fail=restart role=Master timeout=60s (res_pgsql-monitor-interval-5s)
notify interval=0s timeout=60s (res_pgsql-notify-interval-0s)
promote interval=0s on-fail=restart timeout=60s (res_pgsql-promote-interval-0s)
reload interval=0s timeout=20 (res_pgsql-reload-interval-0s)
start interval=0s on-fail=restart timeout=60s (res_pgsql-start-interval-0s)
stop interval=0s on-fail=ignore timeout=60s (res_pgsql-stop-interval-0s)
```
ここで `Operations:` に続けて表示される部分に注目してください。`demote ...` の行に `on-fail=stop` とある場合、または、`stop ...` の行に `on-fail=block` とある場合は、設定内容が古いままになっています。
その場合は、最新の設定に更新するため、アクティブ系において以下のコマンドを実行してください。
```
# pcs resource update res_pgsql op demote on-fail=restart timeout=60s op stop on-fail=ignore timeout=60s
```
※ v1.6.3 でセットアップスクリプトが修正され、v1.6.3 以降へのアップデートではこの手順は不要となります。
## 3.2. アップデート後の動作確認
### 3.2.1. 基本動作の確認
アップデート完了後には、可能な限り既存システムの動作確認を実施してください。
すくなくとも、下記については確認を行なうようにしてください。
- ブラウザから冗長構成の Kompira にアクセスできること。
- 自動機能設定されたジョブフローがある場合は、プロセスが動作していること。
- 管理領域のデフォルト領域で、ジョブマネージャのステータスが動作中であること。
### 3.2.2. フェイルオーバ／フェイルバックの確認
必要に応じてフェイルオーバやフェイルバックの動作確認を実施してください。以下に簡単な確認手順を示します。
1. アクティブ系停止: 両系が正常に動作している状態で、アクティブ系で `pcs cluster stop` コマンドでクラスタを停止させることで、フェイルオーバが発動します。系が切り替わって旧スタンバイ系で縮退運転していることが確認できれば成功です。
2. データ同期とクラスタ復帰: フェイルオーバ後に、上記手順でダウンさせた旧アクティブ系で `/opt/kompira/bin/sync_master.sh` コマンドを実行することで、新アクティブ系とデータ同期してクラスタに復帰します。
切り替わった系において同じ手順をもう一度実施することで、元の系の状態に戻ります（フェイルバック）。