Japan
サイト内の現在位置を表示しています。
AWSのAMIによるリージョンを跨いだHAクラスターのバックアップ・リストア方法～リストア編～
CLUSTERPRO オフィシャルブログ ～クラブロ～はじめに
Amazon Web Services(以降、AWS)上に構築したCLUSTERPRO Xのミラーディスク型HAクラスターについて、普段利用しているリージョンで障害が発生し業務継続が困難になった状況を想定して、バックアップしたクラスターを別のリージョンでリストアする方法を試してみました。この方法は、リージョン全体に影響するような大規模災害等が発生した場合のディザスターリカバリー(DR)の実現手段として利用することもできます。
バックアップ・リストア全体の手順のうち、この記事ではリストアの手順について説明しています。バックアップに関する説明は
バックアップ編を参照してください。
リージョンを跨ぐようなディザスターリカバリーを目的としてAMIからリストアを行う場合、以下のような復旧パターンが考えられます。
バックアップ・リストア全体の手順のうち、この記事ではリストアの手順について説明しています。バックアップに関する説明は
バックアップ編を参照してください。リージョンを跨ぐようなディザスターリカバリーを目的としてAMIからリストアを行う場合、以下のような復旧パターンが考えられます。
- リストア後にネットワークやCLUSTERPROのリソース設定などを変更して、HAクラスターの複製に近い形で業務を復旧する
- 一部のサーバーのみリストアして、HAクラスターではなく単体サーバーとして業務を復旧する
今回は1つ目のHAクラスターの複製に近いパターンでのリストアを実施します。
- ※EC2のリストア前後でEBS高速スナップショット復元を有効/無効化する手順を追記しました。(2023/01/19)
この記事の内容
1.リストア時に考慮が必要な点
1.1 バックアップ、リストア時のライセンスの考え方
CLUSTERPRO Xを含むイメージをバックアップ・リストアする際のライセンスの考え方について解説します。CLUSTERPRO Xではライセンスの使用許諾上、1つのライセンスが複数箇所で同時に存在することを認めていないため、ライセンス登録済みイメージを別の仮想マシンにリストア(複製)すると、通常は使用許諾違反となってしまいます。しかし、以下のいずれかの対応を行った場合に限り例外として許可しています。
今回はリストア後にライセンスを入れ替える方式で対応します。
- バックアップ取得時点で、複製予定の仮想マシン数分のライセンスを余分に登録しておく
- イメージからリストア後、速やかに新規環境用のライセンスに入れ替える
1.2 リストア後のミラーディスクのデータコピーについて
今回のリストア手順で利用するAMIは、AMI作成前に同じタイミングで停止したEC2インスタンスから作成しているため、両サーバーのミラーディスクのデータが同一となっています(詳細手順はバックアップ編を参照)。このように完全な静止点を確保して作成したAMIからリストアする場合は、リストア後にミラーデータのフルコピーを行う必要がありません。
一方、バックアップの取得タイミングが異なるなど、サーバー間のミラーディスクのデータに差がある場合はミラーデータのフルコピーを行う前提の手順とする必要がありますが、今回の記事ではこのパターンについては対象外としています。
バックアップ編を参照)。このように完全な静止点を確保して作成したAMIからリストアする場合は、リストア後にミラーデータのフルコピーを行う必要がありません。一方、バックアップの取得タイミングが異なるなど、サーバー間のミラーディスクのデータに差がある場合はミラーデータのフルコピーを行う前提の手順とする必要がありますが、今回の記事ではこのパターンについては対象外としています。
2.リストアするHAクラスター構成
今回はクラウド環境(AWS)における2ノードミラーディスク型HAクラスターを例として使用します。HAクラスター構成は以下のリソース設定の変更を除いてバックアップ編と基本的に同様となりますので、詳しい構成はバックアップ編をご参照ください。リソース設定を変更する理由としては、明示的に大阪リージョンにおける接続先を変更することで、東京リージョンが障害から復旧した際に不意にクライアントが東京リージョンに接続するといった事が起きないようにするためです。
－CLUSTERPRO のリソース設定(バックアップ編構成からの変更点)
- ■ AWS 仮想IPリソース(awsvip)
- ・仮想IPアドレス： 172.32.0.1
- ■ AWS DNSリソース(awsdns)
- ・リソースレコードセット名： osaka.clusterpro.local.
リストアを行う前のAWS環境は以下のとおりです。
東京リージョンは障害により利用できないと仮定し、大阪リージョンにおいてVPC内にHAクラスターを構築するためのネットワークリソースを作成済み、東京リージョンからコピーしたAMIが保管された状態としています。
東京リージョンは障害により利用できないと仮定し、大阪リージョンにおいてVPC内にHAクラスターを構築するためのネットワークリソースを作成済み、東京リージョンからコピーしたAMIが保管された状態としています。
次に、リストアを行った後のAWS環境及びHAクラスターの構成は以下のとおりです。バックアップ対象であった東京リージョンと同様に、server01とserver02の2ノードActive-Standbyクラスター構成で、アプリケーションデータをミラーディスク上に置くことでデータを共有しています。VIP(仮想IPアドレス)や仮想ホスト名(Route 53のDNSレコード)の向いている側(クライアントがアクセスするサーバー)が現用系サーバーとなり、他方は待機系サーバーとなります。
3. リストア手順
3.1 AMIからEC2インスタンスを起動
AMIからEC2インスタンスを作成します。必要に応じて、EC2インスタンス作成前にEBS高速スナップショット復元を有効化します。
3.1.1 EBS高速スナップショット復元の有効化(任意)
EBSスナップショットから作成した直後のEBSボリュームは、初回アクセス時にストレージブロックがAmazon S3からプルダウンされ、ボリュームに書き込まれる必要があります。この事前処理に一定の時間がかかるため、各ブロックへの初回アクセス時はI/O性能が低下します。このI/O性能低下は、ユーザ作成のAMIからEC2インスタンスを起動する際に作成されるEBSボリュームも例外ではないため、特に対処を行わない場合、このI/O性能低下が原因でリストア後の業務再開時にサービス応答性能が低下したり、処理遅延による監視異常が発生する可能性があります。
今回は、リストア前にバックアップ(EBSスナップショット)に対してEBS高速スナップショット復元の有効化を行うことで、EC2の起動直後から諸元どおりのI/O性能を得られる状態にします。この時、有効化が完了するまでにTiBあたり60分を要すること、同時に有効化可能なスナップショット数に上限(リージョンあたり50個)があることに注意します。
なお、I/O性能が問題にならない場合は本手順を省略することも可能です。
AWS マネジメントコンソールでリストア対象のAMIを構成するEBSスナップショットを選択し、[アクション]から[スナップショットの高速復元を管理]を開きます。[高速スナップショット復元の設定]からEC2をリストアする予定のアベイラビリティーゾーンにチェックを入れて、[有効化]を選択します。同様の手順でリストア対象のAMIを構成する全てのEBSスナップショットでEBS高速スナップショット復元を有効化します。
今回は、リストア前にバックアップ(EBSスナップショット)に対してEBS高速スナップショット復元の有効化を行うことで、EC2の起動直後から諸元どおりのI/O性能を得られる状態にします。この時、有効化が完了するまでにTiBあたり60分を要すること、同時に有効化可能なスナップショット数に上限(リージョンあたり50個)があることに注意します。
なお、I/O性能が問題にならない場合は本手順を省略することも可能です。
AWS マネジメントコンソールでリストア対象のAMIを構成するEBSスナップショットを選択し、[アクション]から[スナップショットの高速復元を管理]を開きます。[高速スナップショット復元の設定]からEC2をリストアする予定のアベイラビリティーゾーンにチェックを入れて、[有効化]を選択します。同様の手順でリストア対象のAMIを構成する全てのEBSスナップショットでEBS高速スナップショット復元を有効化します。
3.1.2 EC2インスタンスの起動
AWS マネジメントコンソールで大阪リージョンにコピーしたAMIのメニューから[AMIからインスタンスを起動]を選択してEC2インスタンスの作成メニューを開き、IAMロールやセキュリティグループ等の設定を必要に応じて行います。この時、EC2インスタンス起動前の確認においてキーペアの選択が必要となるため、Linux環境の場合はバックアップ環境で利用していたものと同じキーペアを設定します。Windows環境ではバックアップ環境と同じパスワードを利用するため、キーペアの設定は必須ではありません。
3.1.3 EBS高速スナップショット復元の無効化(任意)
EBS高速スナップショット復元が有効化されている間は追加の料金が発生します。
そのためEBS高速スナップショット復元を有効化していた場合は、無効化します。
AWS マネジメントコンソールで「3.1.1 EBS高速スナップショット復元の有効化(任意)」においてEBS高速スナップショット復元を有効化したEBSスナップショットを選択し、[アクション]から[スナップショットの高速復元を管理]を開きます。[高速スナップショット復元の設定]から有効化されているアベイラビリティーゾーンにチェックを入れて、[無効化]を選択します。同様の手順で「3.1.1 EBS高速スナップショット復元の有効化(任意)」で有効化した全てのEBS高速スナップショット復元を無効化します。
そのためEBS高速スナップショット復元を有効化していた場合は、無効化します。
AWS マネジメントコンソールで「3.1.1 EBS高速スナップショット復元の有効化(任意)」においてEBS高速スナップショット復元を有効化したEBSスナップショットを選択し、[アクション]から[スナップショットの高速復元を管理]を開きます。[高速スナップショット復元の設定]から有効化されているアベイラビリティーゾーンにチェックを入れて、[無効化]を選択します。同様の手順で「3.1.1 EBS高速スナップショット復元の有効化(任意)」で有効化した全てのEBS高速スナップショット復元を無効化します。
3.2 AWS環境の設定
AMIから新規にEC2インスタンスを作成した場合、AMI作成元の設定に関わらずネットワークインターフェイスの送信元/送信先チェック(Source/Dest. Check)が有効化されるため、AWS マネジメントコンソールでEC2インスタンスの[アクション] - [ネットワーキング] - [ソース/宛先チェックを変更]から[送信元/送信先チェック中]の[停止]にチェックを付けて保存することで無効化します。
「3.1 AMIからEC2インスタンスを起動」で作成したEC2インスタンスのENI ID、プライベートIPアドレス等の情報を基に、AWS 仮想IPリソースを利用するためのVPCのルートテーブルの設定、AWS DNSリソースを利用するためのRoute 53の設定を行います。AWS環境の詳細な設定方法については構築ガイドを参考にしてください。
「3.1 AMIからEC2インスタンスを起動」で作成したEC2インスタンスのENI ID、プライベートIPアドレス等の情報を基に、AWS 仮想IPリソースを利用するためのVPCのルートテーブルの設定、AWS DNSリソースを利用するためのRoute 53の設定を行います。AWS環境の詳細な設定方法については構築ガイドを参考にしてください。
【参考】
- Windows > クラウド > Amazon Web Services > CLUSTERPRO X 5.0 向け HAクラスタ 構築ガイド
- Linux > クラウド > Amazon Web Services > CLUSTERPRO X 5.0 向け HAクラスタ 構築ガイド
→第5章 VIP 制御による HA クラスタの設定
→5.1 VPC 環境の設定
→第7章 DNS 名制御による HA クラスタの設定
→7.1 VPC 環境の設定
3.3 OS上の各種設定
各EC2インスタンスのOS上で設定を行います。最初に、ホスト名がバックアップした環境と同じであることを確認し、もし変更されている場合はバックアップ環境と同じホスト名に変更します。
次にミラーディスクで利用しているパーティションがバックアップ環境と同様に認識されていることの確認と、AWS CLIの設定をOS上で行います。
次にミラーディスクで利用しているパーティションがバックアップ環境と同様に認識されていることの確認と、AWS CLIの設定をOS上で行います。
3.3.1 OS上の各種設定(Windows)
ミラーディスクで利用しているパーティションがバックアップ環境と同様に認識されていることを確認します。
[コンピュータの管理] - [ディスクの管理]から、ミラーディスクに設定しているディスクのドライブ文字に変更がないこと、パーティションのファイルシステムがRAWであること(ミラーディスクドライバによるアクセス制御が効いていること)を確認します。もし、パーティション形式にGPTではなくMBRを使用している等の理由によりGUIDに変更がある場合は、ミラーディスクドライバによるアクセス制御が機能せず各ドライブにアクセス可能な状態になっているため、ドライブ文字をミラーディスクリソースの設定に合わせて再設定します。
[コンピュータの管理] - [ディスクの管理]から、ミラーディスクに設定しているディスクのドライブ文字に変更がないこと、パーティションのファイルシステムがRAWであること(ミラーディスクドライバによるアクセス制御が効いていること)を確認します。もし、パーティション形式にGPTではなくMBRを使用している等の理由によりGUIDに変更がある場合は、ミラーディスクドライバによるアクセス制御が機能せず各ドライブにアクセス可能な状態になっているため、ドライブ文字をミラーディスクリソースの設定に合わせて再設定します。
AWS CLIの設定を行います。
使用しているAMIのOSがWindows Server 2016またはWindows Server 2019の場合、既定でEC2Launch(v1)がインストールされているため、別サブネットへリストアした際にルートの再設定を行う必要がありますので、以下のコマンドを実行します。
使用しているAMIのOSがWindows Server 2016またはWindows Server 2019の場合、既定でEC2Launch(v1)がインストールされているため、別サブネットへリストアした際にルートの再設定を行う必要がありますので、以下のコマンドを実行します。
> Import-Module c:\ProgramData\Amazon\EC2-Windows\Launch\Module\Ec2Launch.psm1; Add-Routes
使用しているAMIのOSがWindows Server 2022以降の場合は既定でEC2Launch v2がインストールされているため、上記のコマンドを実行する必要はありません。
次に、管理者権限で「aws configure」を実行してAWS CLIの既定のリージョンを大阪リージョン(ap-northeast-3)に変更します。既定のリージョン以外の設定は利用環境に合わせて設定してください。
> aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [ap-northeast-1]: ap-northeast-3
Default output format [text]:
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [ap-northeast-1]: ap-northeast-3
Default output format [text]:
3.3.2 OS上の各種設定(Linux)
今回はLVMによりディスクを構成しているためlvdisplayコマンド等を利用してパーティションを正しく認識していることを確認します。非LVM環境の場合はlsblkやpartedコマンド等を利用して確認します。
# lvdisplay
--- Logical volume ---
LV Path /dev/clp_md2/cp
LV Name cp
VG Name clp_md2
LV UUID XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX
LV Write Access read/write
LV Creation host, time server01, 2022-08-15 08:54:54 +0000
LV Status available
<以下略>
--- Logical volume ---
LV Path /dev/clp_md2/cp
LV Name cp
VG Name clp_md2
LV UUID XXXXXX-XXXX-XXXX-XXXX-XXXX-XXXX-XXXXXX
LV Write Access read/write
LV Creation host, time server01, 2022-08-15 08:54:54 +0000
LV Status available
<以下略>
次に、管理者権限で「aws configure」を実行してAWS CLIの既定のリージョンを大阪リージョン(ap-northeast-3)に変更します。既定のリージョン以外の設定は利用環境に合わせて設定してください。
# aws configure
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [ap-northeast-1]: ap-northeast-3
Default output format [text]:
AWS Access Key ID [None]:
AWS Secret Access Key [None]:
Default region name [ap-northeast-1]: ap-northeast-3
Default output format [text]:
3.4 CLUSTERPROのライセンス入れ替え
各EC2インスタンスのOS上でCLUSTERPROのライセンスをリストア環境(大阪リージョンのHAクラスター)用のライセンスに入れ替えます。
以下ではコマンド実行サーバーに登録されているライセンスを一括で削除した後に、カレントディレクトリ配下にある拡張子が".key"であるライセンスファイルを一括で登録しています。同様の処理を各サーバーで行います。
以下ではコマンド実行サーバーに登録されているライセンスを一括で削除した後に、カレントディレクトリ配下にある拡張子が".key"であるライセンスファイルを一括で登録しています。同様の処理を各サーバーで行います。
3.4.1 CLUSTERPROのライセンス入れ替え(Windows)
実行例
> clplcnsc -d -a
Are you sure to remove the license? [y/n] y
<Serial No : eval-base-sv1> License delete succeeded.
<Serial No : eval-repl-sv1> License delete succeeded.
Processed license num (success: 2, error: 0).
> clplcnsc -i *.key
<Filename : eval_base_50_sv3.key>
<Serial No : eval-base-sv3> License registration succeeded.
<Filename : eval_repl_50_sv3.key>
<Serial No : eval-repl-sv3> License registration succeeded.
Command succeeded.
But the license was not applied to all the servers in the cluster
because there are one or more servers that are not started up.
Processed license num (success: 2, error: 0).
Are you sure to remove the license? [y/n] y
<Serial No : eval-base-sv1> License delete succeeded.
<Serial No : eval-repl-sv1> License delete succeeded.
Processed license num (success: 2, error: 0).
> clplcnsc -i *.key
<Filename : eval_base_50_sv3.key>
<Serial No : eval-base-sv3> License registration succeeded.
<Filename : eval_repl_50_sv3.key>
<Serial No : eval-repl-sv3> License registration succeeded.
Command succeeded.
But the license was not applied to all the servers in the cluster
because there are one or more servers that are not started up.
Processed license num (success: 2, error: 0).
3.4.2 CLUSTERPROのライセンス入れ替え(Linux)
実行例
# clplcnsc -d -a
Are you sure to remove the license? [y/n] y
<Serial No : eval-base-sv1> License delete succeeded.
<Serial No : eval-repl-sv1> License delete succeeded.
Processed license num (success: 2, error: 0).
# clplcnsc -i *.key
<Filename : /home/ec2-user/eval_base_50_sv3.key>
<Serial No : eval-base-sv3> License registration succeeded.
<Filename : /home/ec2-user/eval_repl_50_sv3.key>
<Serial No : eval-repl-sv3> License registration succeeded.
Command succeeded.
But the license was not applied to all the servers in the cluster
because there are one or more servers that are not started up.
Processed license num (success: 2, error: 0).
Are you sure to remove the license? [y/n] y
<Serial No : eval-base-sv1> License delete succeeded.
<Serial No : eval-repl-sv1> License delete succeeded.
Processed license num (success: 2, error: 0).
# clplcnsc -i *.key
<Filename : /home/ec2-user/eval_base_50_sv3.key>
<Serial No : eval-base-sv3> License registration succeeded.
<Filename : /home/ec2-user/eval_repl_50_sv3.key>
<Serial No : eval-repl-sv3> License registration succeeded.
Command succeeded.
But the license was not applied to all the servers in the cluster
because there are one or more servers that are not started up.
Processed license num (success: 2, error: 0).
3.5 CLUSTERPROの設定
マスタサーバのCluster WebUI上でリストア先の環境に合わせてCLUSTERPROの設定変更を行います。
3.5.1 CLUSTERPROの設定変更(Windows)
リストアしたマスタサーバのEC2インスタンスのIPアドレスにCluster WebUIで接続し、設定モードを開きます。この時、「1台以上のサーバでクラウド環境情報の取得に失敗しました。」というメッセージが表示される場合がありますが、無視して問題ありません。[クラスタのプロパティ] - [インタコネクト]から各サーバーのIPアドレスをリストア先に合わせて変更し、[設定の反映]を行います。この時、IPアドレス以外の設定を同時に変更しないでください。設定反映時に手動でのOSの再起動が必要であるメッセージが表示されますが、無視して以降の手順を実施します。
IPアドレスの設定反映完了後、続けて以下の設定変更を行います。
AWS 仮想IPリソースのプロパティを開き、[詳細]タブからリストア先の環境に合わせて[IPアドレス]や[VPC ID]、[ENI ID]を共通/個別設定で変更します。
AWS DNSリソースのプロパティを開き、詳細タブからリストア先の環境に合わせて[ホストゾーンID]や[リソースレコードセット名]、[IPアドレス]を共通/個別設定で変更します。
ミラーディスクリソースのプロパティを開き、[詳細]タブの[調整]から[初期ミラー構築を行う]のチェックを外します。
[詳細]タブの[起動可能サーバ]から各サーバーを選択後、[編集]ボタンを押した後に[情報取得] - [接続]ボタンを押して、データパーティションやクラスタパーティションの設定が正しいこと確認します。「3.3 OS上の各種設定」においてドライブ文字の再設定などを行った場合は、変更後の情報に合わせてパーティションを選択し直します。
これらの設定変更後に[設定の反映]を実行します。
IPアドレスの設定反映完了後、続けて以下の設定変更を行います。
AWS 仮想IPリソースのプロパティを開き、[詳細]タブからリストア先の環境に合わせて[IPアドレス]や[VPC ID]、[ENI ID]を共通/個別設定で変更します。
AWS DNSリソースのプロパティを開き、詳細タブからリストア先の環境に合わせて[ホストゾーンID]や[リソースレコードセット名]、[IPアドレス]を共通/個別設定で変更します。
ミラーディスクリソースのプロパティを開き、[詳細]タブの[調整]から[初期ミラー構築を行う]のチェックを外します。
[詳細]タブの[起動可能サーバ]から各サーバーを選択後、[編集]ボタンを押した後に[情報取得] - [接続]ボタンを押して、データパーティションやクラスタパーティションの設定が正しいこと確認します。「3.3 OS上の各種設定」においてドライブ文字の再設定などを行った場合は、変更後の情報に合わせてパーティションを選択し直します。
■ X 4.1/X 4.2の場合
上記設定に加えて、failoverのグループのプロパティを開き、[属性]タブの[グループ起動属性]から手動起動を選択します。
上記設定に加えて、failoverのグループのプロパティを開き、[属性]タブの[グループ起動属性]から手動起動を選択します。
これらの設定変更後に[設定の反映]を実行します。
3.5.2 CLUSTERPROの設定変更(Linux)
リストアしたマスタサーバのEC2インスタンスのIPアドレスにCluster WebUIで接続し、設定モードを開きます。この時、「1台以上のサーバでクラウド環境情報の取得に失敗しました。」というメッセージが表示される場合がありますが、無視して問題ありません。[クラスタのプロパティ] - [インタコネクト]から各サーバーのIPアドレスをリストア先に合わせて変更し、[設定の反映]を行います。この時、IPアドレス以外の設定を同時に変更しないでください。
IPアドレスの設定反映完了後、続けて以下の設定変更を行います。
AWS 仮想IPリソースのプロパティを開き、[詳細]タブからリストア先の環境に合わせて[IPアドレス]や[VPC ID]、[ENI ID]を共通/個別設定で変更します。
AWS DNSリソースのプロパティを開き、詳細タブからリストア先の環境に合わせて[ホストゾーンID]や[リソースレコードセット名]、[IPアドレス]を共通/個別設定で変更します。
ミラーディスクリソースのプロパティを開き、[詳細]タブの[調整] - [ミラー]タブから[初期ミラー構築を行う]のチェックを外します。
これらの設定変更後に[設定の反映]を実行します。
IPアドレスの設定反映完了後、続けて以下の設定変更を行います。
AWS 仮想IPリソースのプロパティを開き、[詳細]タブからリストア先の環境に合わせて[IPアドレス]や[VPC ID]、[ENI ID]を共通/個別設定で変更します。
AWS DNSリソースのプロパティを開き、詳細タブからリストア先の環境に合わせて[ホストゾーンID]や[リソースレコードセット名]、[IPアドレス]を共通/個別設定で変更します。
ミラーディスクリソースのプロパティを開き、[詳細]タブの[調整] - [ミラー]タブから[初期ミラー構築を行う]のチェックを外します。
これらの設定変更後に[設定の反映]を実行します。
3.6 CLUSTERPRO のリストア事後処理
各EC2インスタンスのOS上でCLUSTERPROのリストア後の事後処理を行い、HAクラスターとして稼働可能な状態にします。今回の手順はリストア後にミラーデータのフルコピーが必要ない前提の手順となります。
手順はCLUSTERPRO Xのバージョンによって異なります。
手順はCLUSTERPRO Xのバージョンによって異なります。
3.6.1 CLUSTERPROのリストア事後処理(Windows)
■ X 4.3以降の場合
clprestoreコマンドを"--skip-copy"オプションを付けて実行します。コマンドの処理が完了するとサーバーが自動的に再起動します。
clprestoreコマンドを"--skip-copy"オプションを付けて実行します。コマンドの処理が完了するとサーバーが自動的に再起動します。
> clprestore --post --skip-copy
Command succeeded.
clprestore.bat : Changing the setting of cluster services to Auto Startup.
clprestore.bat : Rebooting...
Reboot server01 : Command succeeded.
Command succeeded.
clprestore.bat : Changing the setting of cluster services to Auto Startup.
clprestore.bat : Rebooting...
Reboot server01 : Command succeeded.
■ X 4.2の場合
clpsvcctrlコマンドを使用して所定のCLUSTERPROサービスを自動起動に変更します。その後サーバーを再起動します。
clpsvcctrlコマンドを使用して所定のCLUSTERPROサービスを自動起動に変更します。その後サーバーを再起動します。
> clpsvcctrl --enable core
> clpdown -r
> clpdown -r
再起動後のマスタサーバのOS上で、ミラーディスクリソース(md1、md2)の強制ミラー復帰を行います。その後、failoverグループを起動します。(本操作はCluster WebUI上で行うことも可能です。)
> clpmdctrl --force server01 md1
Command succeeded.
> clpmdctrl --force server01 md2
Command succeeded.
> clpgrp -s failover
Command succeeded.
Command succeeded.
> clpmdctrl --force server01 md2
Command succeeded.
> clpgrp -s failover
Command succeeded.
■ X 4.1の場合
OSが提供するコマンドを使用して所定のCLUSTEREPROサービスを自動起動に変更します。その後サーバーを再起動します。
OSが提供するコマンドを使用して所定のCLUSTEREPROサービスを自動起動に変更します。その後サーバーを再起動します。
> sc.exe config clppm start= auto
[SC] ChangeServiceConfig SUCCESS
> shutdown -r -t 0
[SC] ChangeServiceConfig SUCCESS
> shutdown -r -t 0
再起動後のマスタサーバのOS上で、ミラーディスクリソース(md1、md2)の強制ミラー復帰を行います。その後、failoverグループを起動します。(本操作はCluster WebUI上で行うことも可能です。)
> clpmdctrl --force server01 md1
Command succeeded.
> clpmdctrl --force server01 md2
Command succeeded.
> clpgrp -s failover
Command succeeded.
Command succeeded.
> clpmdctrl --force server01 md2
Command succeeded.
> clpgrp -s failover
Command succeeded.
3.6.2 CLUSTERPROのリストア事後処理(Linux)
■ X 4.3以降の場合
clprestoreコマンドを"--skip-copy"オプションを付けて実行します。コマンドの処理が完了するとサーバーが自動的に再起動します。
clprestoreコマンドを"--skip-copy"オプションを付けて実行します。コマンドの処理が完了するとサーバーが自動的に再起動します。
# clprestore.sh --post --skip-copy
Mirror info will be set as default.
The main handle on initializing mirror disk <md1> success.
The main handle on initializing mirror disk <md2> success.
Initializing mirror disk complete.
clprestore.sh : Changing the setting of cluster services to Auto Startup.
clprestore.sh : Rebooting...
Mirror info will be set as default.
The main handle on initializing mirror disk <md1> success.
The main handle on initializing mirror disk <md2> success.
Initializing mirror disk complete.
clprestore.sh : Changing the setting of cluster services to Auto Startup.
clprestore.sh : Rebooting...
■ X 4.2の場合
clpsvcctrlコマンドを使用して所定のCLUSTERPROサービスを自動起動に変更します。その後サーバーを再起動します。
clpsvcctrlコマンドを使用して所定のCLUSTERPROサービスを自動起動に変更します。その後サーバーを再起動します。
# clpsvcctrl.sh --enable core
# clpdown -r
# clpdown -r
■ X 4.1の場合
OSが提供するコマンドを使用して所定のCLUSTEREPROサービスを自動起動に変更します。その後サーバーを再起動します。
OSが提供するコマンドを使用して所定のCLUSTEREPROサービスを自動起動に変更します。その後サーバーを再起動します。
# 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.7 リストア完了後のCLUSTERPROの設定変更
マスタサーバのCluster WebUI上でリストア時に変更した設定を必要に応じて戻します。今回はWindowsのCLUSTERPRO X 4.1/4.2環境のみ設定を戻します。
マスタサーバのEC2インスタンスのIPアドレスにCluster WebUIで接続し、設定モードを開きます。failoverのグループのプロパティを開き、[属性]タブの[グループ起動属性]から自動起動を選択します。設定変更後に[設定の反映]を実行します。
※「3.5 CLUSTERPROの設定」で設定変更した[初期ミラー構築を行う]設定は、リストア完了後の動作には影響しないため、設定を元に戻す必要はありません。
マスタサーバのEC2インスタンスのIPアドレスにCluster WebUIで接続し、設定モードを開きます。failoverのグループのプロパティを開き、[属性]タブの[グループ起動属性]から自動起動を選択します。設定変更後に[設定の反映]を実行します。
※「3.5 CLUSTERPROの設定」で設定変更した[初期ミラー構築を行う]設定は、リストア完了後の動作には影響しないため、設定を元に戻す必要はありません。
4. 動作確認
大阪リージョンのクライアントマシンからVIPアドレス(172.32.0.1)とDNS名(osaka.clusterpro.local)を使用してHAクラスターにアクセスできること、各サーバー上でリストアしたデータに正常にアクセスできることを確認します。
- 1.server01でフェールオーバーグループを起動します。
- 2.クライアントマシンから、VIP(172.32.0.1)とDNS名(osaka.clusterpro.local)にアクセスし、server01にアクセスできることを確認します。
- 3.server01上でバックアップ時点のデータに正常にアクセスできることを確認します。
- 4.Cluster WebUIやclpgrpコマンドにより、フェールオーバーグループをserver02に手動で移動します。
- 5.クライアントマシンから、VIP(172.32.0.1)とDNS名(osaka.clusterpro.local)にアクセスし、server02にアクセスできることを確認します。
- 6.server02上でバックアップ時点のデータに正常にアクセスできることを確認します。
大阪リージョンでリストアしたHAクラスターにおいて業務が復旧したことを確認できました。
まとめ
お問い合わせ
本記事に関するお問い合わせは、お問い合わせ窓口までお問い合わせください。
お問い合わせ窓口までお問い合わせください。