Amazon Web Services(以降、AWS)に構築したCLUSTERPRO X HAクラスターのミラーディスクについて、Amazon EBSスナップショット(以降、EBSスナップショット)を利用したバックアップ・リストアを試してみました。
本ブログでは、過去にCLUSTERPRO X for WindowsでEBSスナップショットを利用したバックアップ・リストアを紹介しました。
今回はCLUSTERPRO X for Linuxを利用したバックアップ・リストアをご紹介します。また、バックアップ・リストアの際にCLUSTERPRO X 4.3で追加されたバックアップ・リストア事前事後処理コマンドを利用します。
バックアップ・リストアの事前事後処理コマンドは、ミラーディスク・ハイブリッドディスク用パーティションのイメージバックアップ・リストアを行う際に必要な複雑な前処理・後処理をシンプルかつ安全に実行可能にするものです。
今回は、クラウド環境(AWS)における、Linux系OSの2ノードミラーディスク型HAクラスターを例として使用します。環境および使用バージョンは以下の通りです。
|
AWSリージョン |
東京（ap-northeast-1） |
| CLUSTERPRO Xのバージョン |
CLUSTERPRO X 4.3 for Linux |
| クラスター構成サーバーのOS、AMI |
RHEL-8.2.0_HVM-20210907-x86_64-0-Hourly2-GP2
(ami-05bd7307eceee3fc4) |
HAクラスターの構成は以下の通りです。
server1とserver2の2ノード Active-Standbyクラスター構成で、アプリケーションデータをミラーディスク上に置くことでデータを共有しています。VIP(仮想IPアドレス)の向いている側(クライアントがアクセスするサーバー)が現用系サーバーとなり、他方は待機系サーバーとなります。
あくまでミラーディスクを利用したCLUSTERPROによる一般的な冗長構成の例示であるため、EBSのバックアップ・リストアを行う上でネットワーク構成などが同じである必要はありません。適宜ご利用の環境に合わせて読み替えてください。
CLUSTERPROのミラーディスクに関する構成は以下の通りです。
1つのサーバー用インスタンスにアタッチされるブロックデバイスは、インスタンス作成時に最初から用意されているルートデバイスと、ミラーディスク用に追加したEBSの2個となります。
－EC2 instance、ストレージ
■ server1 (インスタンスID：i-11111111aaaaaaa) / server2 (インスタンスID：i-11111111ccccccc) 共通
| ブロックデバイス名(EBS) |
OS上で認識されるパーティションのデバイスファイル名 |
用途 |
| /dev/sda1(ルートデバイス) |
/dev/xvda1 |
BIOS boot |
| 〃 |
/dev/xvda2 |
/ (OSのルートパーティション) |
| /dev/sdb |
/dev/xvdb1 |
ミラーディスクmd1
(クラスターパーティション) |
| 〃 |
/dev/xvdb2 |
ミラーディスクmd1
(データパーティション) |
CLUSTERPRO
－フェールオーバーグループ (failover1)
■ミラーディスクリソース
・リソース名： md1
・クラスターパーティション：/dev/xvdb1
・データパーティション：/dev/xvdb2
－モニタリソース
■ミラーコネクトモニタリソース
・リソース名： mdnw1
■ミラーディスクモニタリソース
・リソース名： mdw1
※実際の運用時はミラーディスクを利用するサービス用リソースも存在しますが、ここでは割愛します。
AWS環境での設定手順については下記を参照ください。
本手順ではEC2インスタンスの起動、EBSスナップショット作成、EBSスナップショットからのEBS作成、EBSをデタッチ・アタッチなどの操作を行う際に操作用clientからAWS CLIを実行するため、これらのアクションに対するアクセス許可を記述したポリシーをあわせて作成し、操作用clientに付与しておきます。
以下の権限を追加します。
ec2:StartInstances
ec2:CreateSnapshot
ec2:CreateVolume
ec2:DetachVolume
ec2:AttachVolume
ec2:EnableFastSnapshotRestores
ec2:DisableFastSnapshotRestores
もしAWS CLIを使用せず、AWSマネジメントコンソールからEBSの操作を行う場合は上記権限の追加は特に不要です。
ミラーディスクについてバックアップを作成します。
バックアップ方式の手順は何通りかありますが、今回は「待機系側のミラーディスクをバックアップする場合」の手順をご紹介します。
その他のバックアップ方式の手順や詳細については以下を参照ください。
【参考】
- CLUSTERPRO X 4.3 > Linux > メンテナンスガイド
→ミラー/ハイブリッドディスクをディスクイメージでバックアップするには
ミラーディスクが正常に同期できていることを確認します。
現用系、または待機系サーバーで以下のコマンドを実行します。
実行例
# clpmdstat --mirror md1
Mirror Status: Normal
md1 server1 server2
------------------------------------------------------------
Mirror Color GREEN GREEN
同期状態の確認後、静止点を確保するためにフェールオーバーグループを停止します。
現用系サーバーで以下のコマンドを実行します。
実行例
# clpgrp -t failover1
Command succeeded.
自動ミラー復帰が動作しないようにするために、ミラーディスクの監視を一時停止します。
現用系、または待機系サーバーで以下のコマンドを実行します。
※ 現用系/待機系の両サーバーについてミラーディスクモニタリソースを一時停止します。
実行例
# clpmonctrl -s -h server1 -m mdw1
Command succeeded.
# clpmonctrl -s -h server2 -m mdw1
Command succeeded.
ミラーディスクの同期を中断します。
待機系サーバーで以下のコマンドを実行します。
実行例
# clpmdctrl --break md1
md1: Isolated completed successfully
業務をすぐに再開したい場合は、この段階で現用系サーバーでフェールオーバーグループを起動します。
現用系サーバーで以下のコマンドを実行します。
実行例
# clpgrp -s failover1
Command succeeded.
2.4 バックアップ事前処理コマンドの実行（待機系サーバー停止）
待機系サーバーで以下のコマンドを実行します。
実行例
# clpbackup.sh --pre
clpbackup.sh : Beginning backup-mode.
All backup flags have set to <ON>.
clpbackup.sh : Changing the setting of cluster services to Manual Startup.
clpbackup.sh : Shutting down...
Command succeeded.
clpbackup.sh : Command succeeded.
コマンドを実行すると、待機系サーバーのミラーディスクがバックアップモードになり、CLUSTERPROの各種サービスの自動起動がオフに設定され、待機系サーバーがシャットダウンします。
待機系サーバーのミラーディスクのEBSスナップショットを取得します。
操作用clientで以下のコマンドを実行します。
実行例
> aws ec2 create-snapshot --volume-id vol-11111111ccccccc (待機系サーバーのミラーディスクのボリュームID) --description "Mirror Volume Snapshot"
AWSマネジメントコンソールなどで、スナップショットが作成されていることを確認してください。
作成したEBSスナップショットのスナップショットIDは後で利用しますので控えておきます。スナップショットIDは、コマンド実行結果に含まれる[SnapshotId]でも取得可能です。
スナップショットの取得は非同期に行われるため、EBSのスナップショットの取得を実行した後は、スナップショットの作成中でも、次の「2.6 待機系サーバーの起動」に進んで問題ありません。ただし、スナップショットを作成する際はデータの整合性を保つため、静止点を設けることを推奨します（「2.2 フェールオーバーグループの停止」、「2.3 ミラーディスク同期の停止」が静止点を設ける手順に該当します）。
以下のコマンドを実行し、待機系サーバーを起動します。
実行例
> aws ec2 start-instances --instance-ids i-11111111ccccccc (待機系サーバーのインスタンスID)
2.7 バックアップ事後処理コマンドの実行(待機系サーバー再起動)
待機系サーバーで以下のコマンドを実行します。
実行例
# clpbackup.sh --post
clpbackup.sh : Starting Mirror Agent.
Command succeeded.
clpbackup.sh : Ending backup-mode.
All backup flags have set to <OFF>.
clpbackup.sh : Changing the setting of cluster services to Auto Startup.
clpbackup.sh : Stopping Mirror Agent.
Command succeeded.
clpbackup.sh : Rebooting...
コマンドを実行すると、ミラーディスクが通常モードになり、CLUSTERPROの各種サービスの自動起動がオンに設定され、待機系サーバーが再起動します。
現用系サーバーのミラーディスクの監視を再開します。
現用系サーバーで以下のコマンドを実行します。
実行例(現用系サーバーがserver1の場合)
# clpmonctrl -r -h server1 -m mdw1
Command succeeded.
※待機系サーバーは再起動後に、自動的にクラスターへ復帰し、ミラーディスク監視も自動的に再開します。
「2.3 ミラーディスク同期の停止」で現用系サーバーでフェールオーバーグループを起動していない場合は、ここで起動します。現用系サーバーで以下のコマンドを実行します。
実行例
# clpgrp -s failover1
Command succeeded.
自動ミラー復帰が有効な場合は、バックアップ作業中に現用系ミラーディスクと待機ミラーディスクとの間に生じた差分が自動的に同期され、正常な状態になります。もし自動ミラー復帰が行われずに正常な状態にならない場合は、現用系、または待機系サーバーで以下のコマンドを実行します。
実行例
# clpmdctrl --recovery md1
操作ミスにより現用系ミラーディスクからデータを削除してしまい、さらに待機系ミラーディスクにも同期されたことで両系のミラーディスクからデータが削除されてしまったケースを想定します。
フェールオーバーグループを停止し、現用系/待機系サーバーのミラーディスクを、同一のバックアップ(EBSスナップショット)から作成したボリュームと交換します。現用系と待機系のミラーディスクで中身が同じであり差分がないため、ミラーディスクのフルコピー処理は不要となります。
リストア事後処理コマンド実行時には、ミラーディスクリソースの設定で[初期ミラー構築を行う]がオフになっている必要があります(もしオンになっているとリストア事後処理コマンドの実行がガードされます)。
Cluster WebUIに接続し、「設定モード」に切り替えます。ミラーディスクリソースのプロパティにおいて[詳細]タブの[調整]ボタンをクリックします。[ミラー]タブの[初期ミラー構築を行う]がオンになっていた場合はオフにします。設定変更後、設定の反映を実行します。
EBSスナップショットから作成した直後のEBSボリュームは、初回アクセス時にストレージブロックがAmazon S3からプルダウンされ、ボリュームに書き込まれる必要があります。
この事前処理に一定の時間がかかるため、各ブロックへの初回アクセス時はI/O性能が低下します。特に対処を行わない場合、このディスクI/O遅延が原因でリストア後の業務再開時にサービス応答性能が低下したり、処理遅延による監視異常が発生する可能性が高くなります。
詳細、および対処方法については以下を参照ください。
ディスクI/O遅延を避けるために、今回はリストア前にバックアップ（EBSスナップショット）に対してEBS高速スナップショット復元の有効化を行います。有効化が完了するまでにTiBあたり60分を要することに注意します。
なお、I/O性能が問題にならない場合は本手順を省略することも可能です。
操作用clientで以下のコマンドを実行します。
実行例(ap-northeast-1aとap-northeast-1cで有効化)
> aws ec2 enable-fast-snapshot-restores --availability-zones ap-northeast-1a ap-northeast-1c --source-snapshot-ids snap-11111111ccccccc(EBSスナップショットID)
EBS高速スナップショット復元の詳細については、以下を参照ください。
バックアップ(EBSスナップショット)からリストア用のEBSを作成します。
「2.5 EBSスナップショット作成」で取得したEBSスナップショットから現用系/待機系サーバーそれぞれのミラーディスク用EBSボリュームを作成します。このとき作成先のAvailability Zone(以下、AZ)はEBSをアタッチするサーバーと同じAZとなるようにします。
操作用clientで以下のコマンドを実行します。
実行例
> aws ec2 create-volume --region ap-northeast-1 --availability-zone ap-northeast-1a --snapshot-id snap-11111111ccccccc(EBSスナップショットID) --volume-type gp3
> aws ec2 create-volume --region ap-northeast-1 --availability-zone ap-northeast-1c --snapshot-id snap-11111111ccccccc(EBSスナップショットID) --volume-type gp3
AWSマネジメントコンソールなどから、EBSが作成されていることを確認してください。
作成したEBSのボリュームIDは後で利用しますので控えておきます。
ボリュームIDは、コマンド実行結果に含まれる[VolumeId]でも取得可能です。
EBS高速スナップショット復元が有効化されている間、継続料金が発生します。
そのためEBS高速スナップショット復元を有効化していた場合は、無効化します。
操作用clientで以下のコマンドを実行します。
実行例(ap-northeast-1aとap-northeast-1cで無効化)
> aws ec2 disable-fast-snapshot-restores --availability-zones ap-northeast-1a ap-northeast-1c --source-snapshot-ids snap-11111111ccccccc(EBSスナップショットID)
フェールオーバーグループを停止します。
現用系サーバーで以下のコマンドを実行します。
実行例
# clpgrp -t failover1
Command succeeded.
3.7 リストア事前処理コマンドの実行(現用系/待機系サーバー停止)
現用系/待機系の両サーバーで、以下のコマンドを実行します。
実行例
# clprestore.sh --pre
clprestore.sh : Changing the setting of cluster services to Manual Startup.
clprestore.sh : Shutting down...
Command succeeded.
clprestore.sh : Command succeeded.
コマンドを実行すると、自動的にCLUSTERPROの各種サービスの自動起動をオフにして、サーバーをシャットダウンします。
各サーバーのミラーディスクのEBSをデタッチします。
操作用clientで以下のコマンドを実行します。
実行例
> aws ec2 detach-volume --volume-id vol-11111111aaaaaaa(server1用ミラーディスクのボリュームID)
> aws ec2 detach-volume --volume-id vol-11111111ccccccc(server2用ミラーディスクのボリュームID)
ミラーディスクのEBSをデタッチした際のコマンド実行結果に含まれる[Device]の値は、EBSスナップショットから作成したEBSをアタッチする際、--deviceオプションの設定値とするため控えておきます。
各サーバーに、「3.4 EBSボリュームの作成」で作成したEBSをアタッチします。
操作用clientで以下のコマンドを実行します。
実行例
> aws ec2 attach-volume --volume-id vol-22222222aaaaaaa --instance-id i-11111111aaaaaaa --device /dev/sdb
■ vol-22222222aaaaaaa ：server1のリストア用に作成したEBSのボリュームID
■ i-11111111aaaaaaa ：server1のインスタンスID
■ /dev/sdb ：「3.8 旧EBSのデタッチ」の際に控えておいたserver1側の[Device]の値
> aws ec2 attach-volume --volume-id vol-22222222ccccccc --instance-id i-11111111cccccc --device /dev/sdb
■ vol-22222222ccccccc ：server2のリストア用に作成したEBSのボリュームID
■ i-1111111ccccccc ：server2のインスタンスID
■ /dev/sdb ：「3.8 旧EBSのデタッチ」の際に控えておいたserver2側の[Device]の値
以下のコマンドを実行し、現用系/待機系の両サーバーを起動します。
実行例
> aws ec2 start-instances --instance-ids i-11111111aaaaaaa (server1のインスタンスID)
> aws ec2 start-instances --instance-ids i-11111111ccccccc (server2のインスタンスID)
現用系/待機系の両サーバーを起動し、リストアしたクラスターパーティションやデータパーティションのデバイスファイル名をlsblkコマンドなどで確認します。
実行例
# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
xvda 202:0 0 10G 0 disk
├─xvda1 202:1 0 1M 0 part
└─xvda2 202:2 0 10G 0 part /
xvdb 202:16 0 20G 0 disk
├─xvdb1 202:17 0 1G 0 part ← クラスタパーティション
└─xvdb2 202:18 0 19G 0 part ←データパーティション
もしミラーディスクリソースで設定したデバイスファイル名から変わっている場合はミラーディスクの設定を変更します。Cluster WebUIに接続し、「設定モード」に切り替えます。ミラーディスクリソースのプロパティにおいて[詳細]タブの[データパーティションデバイス名]と[クラスターパーティションデバイス名]に正しいデバイスファイル名を入力します。
入力後、設定の反映を実行します。
※ミラーディスク用EBSボリューム交換後、環境によってはOSが認識するデバイスファイル名が変わることがあり、その状態のままミラーディスクを起動しようとすると失敗します。失敗した場合はパーティションが破壊されている可能性があるため、リストア処理を最初からやり直す必要があります。
本件の回避策として、論理ボリューム(LVM)を使用する方法があります。詳細は以下の記事をご覧ください。
3.12 リストア事後処理コマンドの実行(現用系/待機系サーバー再起動)
現用系/待機系の両サーバーで、以下のコマンドを実行します。
実行例
# clprestore.sh --post --skip-copy
Mirror info will be set as default.
The main handle on initializing mirror disk <md1> success.
Initializing mirror disk complete.
clprestore.sh : Changing the setting of cluster services to Auto Startup.
clprestore.sh : Rebooting...
コマンドを実行すると、自動的にCLUSTERPROの各種サービスの自動起動をオンにして、サーバーを再起動します。
今回は、同じEBSスナップショットから現用系/待機系サーバー両方のミラーディスク用EBSを作成したため、クラスタパーティション、データパーティションの中身は同じものとなりミラーのフルコピーは不要となります。clprestore.shコマンドを--skip-copyオプション付きで実行することでフルコピーが省略され、ミラーディスクが正常な状態で起動します。
CLUSTERPRO Xが正常に起動し、ミラーディスクリソースのステータスが正常になっていることを確認します。
現用系、または待機系サーバーで以下のコマンドを実行します。
実行例
# clpmdstat --mirror md1
Mirror Status: Normal
md1 server1 server2
------------------------------------------------------------
Mirror Color GREEN GREEN
リストアにより、誤って削除されたデータなどが復活していることを確認します。
必要に応じてフェールオーバーグループや各サービスに問題がないことを確認し、リストア作業を終了します。
今回は、CLUSTERPRO X 4.3で追加されたバックアップ・リストアの事前事後処理コマンドを使用して、AWS環境のミラーディスクをバックアップ・リストアする手順をご紹介しました。
ミラーディスクは業務の重要なデータを保管することが多いため、障害や作業ミスなどでデータが破壊・削除されるトラブルに備えたバックアップ手順の整備は運用上必須といえます。実際の運用にあたっては、
CLUSTERPRO X メンテナンスガイド の「第２章 保守情報」に記載されているバックアップ・リストア手順もあわせてご覧ください。
