Japan
サイト内の現在位置を表示しています。
AWSのAMIによるリージョンを跨いだHAクラスターのバックアップ・リストア方法～バックアップ編～
CLUSTERPRO オフィシャルブログ ～クラブロ～はじめに
Amazon Web Services(以降、AWS)上に構築したCLUSTERPRO Xのミラーディスク型HAクラスターについて、普段利用しているリージョンで障害が発生し業務継続が困難になった状況を想定して、バックアップしたクラスターを別のリージョンでリストアする方法を試してみました。この方法は、リージョン全体に影響するような大規模災害等が発生した場合のディザスターリカバリー(DR)の実現手段として利用することもできます。
AWSのリソースをバックアップする手段としては、AWSが提供している機能やサードパーティ製のツール・サービスなど様々なものがありますが、今回はAWSが提供している機能のみを使用するようにしています。
バックアップ・リストア全体の手順のうち、この記事ではバックアップの手順について説明しています。リストアに関する説明は
リストア編を参照してください。
AWSのリソースをバックアップする手段としては、AWSが提供している機能やサードパーティ製のツール・サービスなど様々なものがありますが、今回はAWSが提供している機能のみを使用するようにしています。
バックアップ・リストア全体の手順のうち、この記事ではバックアップの手順について説明しています。リストアに関する説明は
リストア編を参照してください。この記事の内容
1.EC2インスタンスのバックアップ方法
EC2インスタンスのバックアップ方法として よく用いられる"EBSスナップショット"と"Amazon マシンイメージ (以降、AMI)"について紹介します。
EBSスナップショット
EC2インスタンスのデータが格納されているEBSボリュームのスナップショットを作成するバックアップ方法で、Amazon S3に保存されます。EBSスナップショットから新しいEBSボリュームを作成(復元)し、既存のEC2インスタンスにアタッチされているボリュームと付け替えることで、EC2インスタンスのデータをスナップショット取得時点のデータにリストアすることができます。
EBSスナップショットにはEC2インスタンスの起動に必要な構成情報は含まれていません。そのため、EBSスナップショットから新しいEC2インスタンスを作成したい場合は、まずルートボリュームのスナップショットから新しいイメージ(AMI)を作成し、次にそのイメージから新規EC2インスタンスを作成するという複数のステップが必要となります。さらに、EC2インスタンスに複数のEBSボリュームがアタッチされていた場合は、"スナップショットから新しいボリュームを作成して新規EC2インスタンスにアタッチする"という作業をボリューム毎に実施する必要があります。
AMI
EBSスナップショットに加えて、EC2インスタンスの起動に必要な構成情報も含まれるバックアップ方法です。EC2インスタンスに複数のEBSボリュームがアタッチされている場合、全ボリュームのスナップショットが1つのAMIに含まれます。AMIのデータは、EBSスナップショットと同様にAmazon S3に保存されます。AMIから新しいEC2インスタンスを作成(復元)することで、AMIを作成した時点のデータを持ったインスタンスをリストアすることができます。
本ブログではバックアップしたEC2インスタンスのデータを使ってリストア先のリージョンで新しいサーバーを作るという想定であるため、EC2インスタンスを容易に作成できるAMIをバックアップ方法として採用しています。
EBSスナップショット
EC2インスタンスのデータが格納されているEBSボリュームのスナップショットを作成するバックアップ方法で、Amazon S3に保存されます。EBSスナップショットから新しいEBSボリュームを作成(復元)し、既存のEC2インスタンスにアタッチされているボリュームと付け替えることで、EC2インスタンスのデータをスナップショット取得時点のデータにリストアすることができます。
EBSスナップショットにはEC2インスタンスの起動に必要な構成情報は含まれていません。そのため、EBSスナップショットから新しいEC2インスタンスを作成したい場合は、まずルートボリュームのスナップショットから新しいイメージ(AMI)を作成し、次にそのイメージから新規EC2インスタンスを作成するという複数のステップが必要となります。さらに、EC2インスタンスに複数のEBSボリュームがアタッチされていた場合は、"スナップショットから新しいボリュームを作成して新規EC2インスタンスにアタッチする"という作業をボリューム毎に実施する必要があります。
AMI
EBSスナップショットに加えて、EC2インスタンスの起動に必要な構成情報も含まれるバックアップ方法です。EC2インスタンスに複数のEBSボリュームがアタッチされている場合、全ボリュームのスナップショットが1つのAMIに含まれます。AMIのデータは、EBSスナップショットと同様にAmazon S3に保存されます。AMIから新しいEC2インスタンスを作成(復元)することで、AMIを作成した時点のデータを持ったインスタンスをリストアすることができます。
本ブログではバックアップしたEC2インスタンスのデータを使ってリストア先のリージョンで新しいサーバーを作るという想定であるため、EC2インスタンスを容易に作成できるAMIをバックアップ方法として採用しています。
2. HAクラスター構成
今回は東京リージョンに構築した2ノードミラーディスク型HAクラスターを使用し、バックアップとして作成したAMIを利用して大阪リージョンに同等のHAクラスターを構築します。評価を行った環境の組み合わせは以下のとおりです。
| AWSリージョン | 東京(ap-northeast-1)および大阪(ap-northeast-3) |
| サーバーOS および CLUSTERPRO X のバージョン | Windows ・CLUSTERPRO X 4.1 ＋ Windows Server 2019 ・CLUSTERPRO X 4.2 ＋ Windows Server 2016 ・CLUSTERPRO X 4.3 ＋ Windows Server 2019 ・CLUSTERPRO X 5.0 ＋ Windows Server 2022 Linux ・CLUSTERPRO X 4.1 ＋ Red Hat Enterprise Linux 7.5 ・CLUSTERPRO X 4.2 ＋ Red Hat Enterprise Linux 7.5 ・CLUSTERPRO X 4.3 ＋ Red Hat Enterprise Linux 8.4 ・CLUSTERPRO X 5.0 ＋ Red Hat Enterprise Linux 8.4 |
HAクラスターの構成は以下のとおりです。図の左側(東京リージョン内のクラスター)に注目してください。
server01とserver02の2ノードActive-Standbyクラスター構成で、Active側のミラーディスクに書き込まれたアプリケーションデータをStandby側のEBSボリュームにミラーリングしています。VIP(仮想IPアドレス)や仮想ホスト名(Route 53のDNSレコード)の向いている側(クライアントがアクセスするサーバー)が現用系サーバーとなり、他方は待機系サーバーとなります。
あくまでミラーディスクを利用したCLUSTERPROによる一般的な冗長構成の例示であるため、EC2インスタンスのバックアップ・リストアを行う上でネットワーク構成などが同じである必要はありません。適宜ご利用の環境に合わせて読み替えてください。
server01とserver02の2ノードActive-Standbyクラスター構成で、Active側のミラーディスクに書き込まれたアプリケーションデータをStandby側のEBSボリュームにミラーリングしています。VIP(仮想IPアドレス)や仮想ホスト名(Route 53のDNSレコード)の向いている側(クライアントがアクセスするサーバー)が現用系サーバーとなり、他方は待機系サーバーとなります。
あくまでミラーディスクを利用したCLUSTERPROによる一般的な冗長構成の例示であるため、EC2インスタンスのバックアップ・リストアを行う上でネットワーク構成などが同じである必要はありません。適宜ご利用の環境に合わせて読み替えてください。
CLUSTERPROのミラーディスクに関する構成は以下の通りです。
サーバー用インスタンスにアタッチされているブロックデバイスの個数は、インスタンス作成時に最初から用意されているルートボリュームのEBS1つと、ミラーディスク用に追加したEBS2つで、合計3つとなります。
ミラーディスク用のEBSにおいてクラスターパーティションおよびデータパーティション用の領域を作成する際、以下の設定を推奨します。
・Windows環境：パーティション形式としてGPTを指定する
・Linux環境：LVM(Logical Volume Manager)を使用してパーティションを作成する
AWS環境では、インスタンスにアタッチされているEBSのデバイス名がリストアの前後で一致しない可能性があります。リストア後のデバイス名がリストア前と異なると、CLUSTERPROのミラーディスクリソースの設定を変更して対応する必要が生じます。そのため、前述の設定を行うことにより、リストア後の CLUSTERPROの設定変更は不要になるように対策しています。
サーバー用インスタンスにアタッチされているブロックデバイスの個数は、インスタンス作成時に最初から用意されているルートボリュームのEBS1つと、ミラーディスク用に追加したEBS2つで、合計3つとなります。
ミラーディスク用のEBSにおいてクラスターパーティションおよびデータパーティション用の領域を作成する際、以下の設定を推奨します。
・Windows環境：パーティション形式としてGPTを指定する
・Linux環境：LVM(Logical Volume Manager)を使用してパーティションを作成する
AWS環境では、インスタンスにアタッチされているEBSのデバイス名がリストアの前後で一致しない可能性があります。リストア後のデバイス名がリストア前と異なると、CLUSTERPROのミラーディスクリソースの設定を変更して対応する必要が生じます。そのため、前述の設定を行うことにより、リストア後の CLUSTERPROの設定変更は不要になるように対策しています。
－サーバーのストレージ内訳(server01/server02共通)
| デバイス名(例) | 用途 | ドライブ名(Windows)またはデバイスファイル名(Linux) |
| /dev/sda1 | OSのシステム領域 | C: または /dev/sda1 |
| xvdf または /dev/sdf | ミラーディスク(md1) - クラスターパーティション - データパーティション |
D: または /dev/clp_md1/cp E: または /dev/clp_md1/dp |
| xvdg または /dev/sdg | ミラーディスク(md2) - クラスターパーティション - データパーティション |
F: または /dev/clp_md2/cp G: または /dev/clp_md2/dp |
－CLUSTERPROのリソース設定
- フェールオーバーグループ(failover)
- ■ミラーディスクリソース1(md1)
- ・クラスターパーティション： D: または /dev/clp_md1/cp
- ・データパーティション： E: または /dev/clp_md1/dp
- ■ミラーディスクリソース2(md2)
- ・クラスターパーティション： F: または /dev/clp_md2/cp
- ・データパーティション： G: または /dev/clp_md2/dp
- ■AWS 仮想IPリソース(awsvip)
- ・仮想IPアドレス： 172.16.0.1 (大阪リージョンでリストアする際に変更)
- ■AWS DNSリソース(awsdns)
- ・リソースレコードセット名： tokyo.clusterpro.local. (大阪リージョンでリストアする際に変更)
- モニタリソース
- ※上記のグループリソース追加により自動的に登録されるため割愛
－その他の注意点
- EC2インスタンス作成時からホスト名を変更していない場合、AMIからリストアした各サーバーのホスト名はバックアップ元のホスト名と異なったものに変化します。ホスト名が変化すると、リストア手順におけるCLUSTERPROの構成情報更新の作業量が増加します。そのため、今回はホスト名が固定化されるように事前に設定しています。
- 今回説明する内容は、再利用可能なAMI(ゴールデンイメージ)の作成を目的としたものではありません。そのため、AMI作成前にWindows環境のインスタンスからインスタンスセキュリティ識別子(SID)やコンピュータ名などを削除するSysprepを実行していません。
- 大阪リージョン側にリストアされるサーバーにログインするための認証情報が必要です。サーバーがLinux環境であれば、東京リージョンにある既存のキーペアを大阪リージョンにインポートしておきます。サーバーがWindows環境であれば、サーバーのログインパスワードを忘れないように控えておきます。
3. バックアップ手順
3.1 バックアップ取得の事前処理
ミラーディスクが正常に同期できていることを確認します。
server01もしくはserver02で以下のコマンドを実行します。
(以降の各コマンドについては、管理者権限を持つユーザーで実行します。)
server01もしくはserver02で以下のコマンドを実行します。
(以降の各コマンドについては、管理者権限を持つユーザーで実行します。)
実行例
# clpmdstat --mirror md1
Mirror Status: Normal
md1 server01 server02
------------------------------------------------------------
Mirror Color GREEN GREEN
(以下 省略)
Mirror Status: Normal
md1 server01 server02
------------------------------------------------------------
Mirror Color GREEN GREEN
(以下 省略)
server01、server02の両方でMirror ColorがGREENであればミラーディスクは正常に同期されています。
同期状態の確認後、フェールオーバーグループを停止します。フェールオーバーグループが起動している現用系サーバーで以下のコマンドを実行します。
同期状態の確認後、フェールオーバーグループを停止します。フェールオーバーグループが起動している現用系サーバーで以下のコマンドを実行します。
実行例
# clpgrp -t failover
Command succeeded.
Command succeeded.
続いて、server01、server02の両方で以下の手順を実行します。
手順はCLUSTERPRO Xのバージョンによって異なります。
手順はCLUSTERPRO Xのバージョンによって異なります。
■ X 4.3以降の場合
clpbackupコマンドを実行します。コマンドの処理が完了するとサーバーが自動的にシャットダウンします。
clpbackupコマンドを実行します。コマンドの処理が完了するとサーバーが自動的にシャットダウンします。
実行例(Windows)
> clpbackup --pre
clpbackup.bat : Beginning backup-mode.
Command succeeded.
clpbackup.bat : Changing the setting of cluster services to Manual Startup.
clpbackup.bat : Shutting down...
Command succeeded.
clpbackup.bat : Command succeeded.
clpbackup.bat : Beginning backup-mode.
Command succeeded.
clpbackup.bat : Changing the setting of cluster services to Manual Startup.
clpbackup.bat : Shutting down...
Command succeeded.
clpbackup.bat : Command succeeded.
実行例(Linux)
# 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.
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.
■ X 4.2の場合
clpsvcctrlコマンドを使用して所定のCLUSTERPROサービスを手動起動に変更します。その後サーバーをシャットダウンします。
clpsvcctrlコマンドを使用して所定のCLUSTERPROサービスを手動起動に変更します。その後サーバーをシャットダウンします。
実行例(Windows)
> clpsvcctrl --disable core
> clpdown
> clpdown
実行例(Linux)
# clpsvcctrl.sh --disable core
# clpdown
# clpdown
■ X 4.1の場合
OSが提供するコマンドを使用して所定のCLUSTERPROサービスを手動起動に変更します。その後サーバーをシャットダウンします。
OSが提供するコマンドを使用して所定のCLUSTERPROサービスを手動起動に変更します。その後サーバーをシャットダウンします。
実行例(Windows)
> sc.exe config clppm start= demand
[SC] ChangeServiceConfig SUCCESS
> clpdown
[SC] ChangeServiceConfig SUCCESS
> clpdown
実行例(Linux)
# systemctl disable clusterpro
Removed /etc/systemd/system/multi-user.target.wants/clusterpro.service.
# systemctl disable clusterpro_md
Removed /etc/systemd/system/multi-user.target.wants/clusterpro_md.service.
# clpdown
Removed /etc/systemd/system/multi-user.target.wants/clusterpro.service.
# systemctl disable clusterpro_md
Removed /etc/systemd/system/multi-user.target.wants/clusterpro_md.service.
# clpdown
3.2 バックアップの取得
server01、server02のAMIを作成することで、各EBSのバックアップを取得します。
AWS マネジメントコンソールでserver01、server02のEC2インスタンスをそれぞれ選択し、[イメージを作成]を選択します。
AWS マネジメントコンソールでserver01、server02のEC2インスタンスをそれぞれ選択し、[イメージを作成]を選択します。
[イメージを作成]の画面でバックアップ対象のボリュームが全て含まれていることを確認し、イメージの名前や説明などの入力が完了したら、[イメージを作成]ボタンを押下します。
作成したイメージがAWS マネジメントコンソールのAmazon マシンイメージ(AMI)の一覧に表示されたら、バックアップの取得は完了です。
3.3 バックアップ取得の事後処理
server01、server02のEC2インスタンスを起動します。
インスタンスの起動後、server01、server02の両方で以下の手順を実行し、HAクラスターとして稼働可能な状態にします。
手順はCLUSTERPRO Xのバージョンによって異なります。
インスタンスの起動後、server01、server02の両方で以下の手順を実行し、HAクラスターとして稼働可能な状態にします。
手順はCLUSTERPRO Xのバージョンによって異なります。
■ X 4.3以降の場合
clpbackupコマンドを実行します。コマンドの処理が完了するとサーバーが自動的に再起動します。
clpbackupコマンドを実行します。コマンドの処理が完了するとサーバーが自動的に再起動します。
実行例(Windows)
> clpbackup --post
clpbackup.bat : Ending backup-mode.
Command succeeded.
clpbackup.bat : Changing the setting of cluster services to Auto Startup.
clpbackup.bat : Rebooting...
clpbackup.bat : Ending backup-mode.
Command succeeded.
clpbackup.bat : Changing the setting of cluster services to Auto Startup.
clpbackup.bat : Rebooting...
実行例(Linux)
# 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...
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...
■ X 4.2の場合
clpsvcctrlコマンドを使用して所定のCLUSTERPROサービスを自動起動に変更します。その後サーバーを再起動します。
clpsvcctrlコマンドを使用して所定のCLUSTERPROサービスを自動起動に変更します。その後サーバーを再起動します。
実行例(Windows)
> clpsvcctrl --enable core
> clpdown -r
> clpdown -r
実行例(Linux)
# clpsvcctrl.sh --enable core
# clpdown -r
# clpdown -r
■ X 4.1の場合
OSが提供するコマンドを使用して所定のCLUSTERPROサービスを自動起動に変更します。その後サーバーを再起動します。
OSが提供するコマンドを使用して所定のCLUSTERPROサービスを自動起動に変更します。その後サーバーを再起動します。
実行例(Windows)
> sc.exe config clppm start= auto
[SC] ChangeServiceConfig SUCCESS
> shutdown -r -t 0
[SC] ChangeServiceConfig SUCCESS
> shutdown -r -t 0
実行例(Linux)
# systemctl enable clusterpro
Created symlink /etc/systemd/system/multi-user.target.wants/clusterpro.service → /usr/lib/systemd/system/clusterpro.service.
# systemctl enable clusterpro_md
Created symlink /etc/systemd/system/multi-user.target.wants/clusterpro_md.service → /usr/lib/systemd/system/clusterpro_md.service.
# reboot
Created symlink /etc/systemd/system/multi-user.target.wants/clusterpro.service → /usr/lib/systemd/system/clusterpro.service.
# systemctl enable clusterpro_md
Created symlink /etc/systemd/system/multi-user.target.wants/clusterpro_md.service → /usr/lib/systemd/system/clusterpro_md.service.
# reboot
3.4 イメージのコピー
作成したAMI(バックアップ)を他のリージョンにコピーします。
AWS マネジメントコンソールのAmazon マシンイメージ(AMI)一覧で対象のイメージを選択し、[AMIをコピー]を選びます。
AWS マネジメントコンソールのAmazon マシンイメージ(AMI)一覧で対象のイメージを選択し、[AMIをコピー]を選びます。
[AMIをコピー]の画面で送信先リージョンを選択し、[AMIをコピー]を押下します。
AWS マネジメントコンソールの接続先リージョンをAMIのコピー先のリージョンに変更して、Amazon マシンイメージ(AMI)の一覧を表示します。コピーしたAMIが表示されていることを確認します。
まとめ
お問い合わせ
本記事に関するお問い合わせは、お問い合わせ窓口までお問い合わせください。
お問い合わせ窓口までお問い合わせください。