LifeKeeper記事では、前々回DRBD×LifeKeeperの組み合わせの製品と性能についてご紹介しました。
第10回 DRBD × LifeKeeperの高可用性リアルタイムレプリケーションを探る – TechHarmony
今回の記事では、DRBD×LifeKeeper製品であるDisaster Recovery Add-onの構築方法そして機能の検証をしていきたいと思います！
検証環境について
今回、Disaster Recovery Add-onの機能を確認する環境として
AWS上の東京リージョンに2台、大阪リージョンに1台の計3ノードによる
マルチリージョンでの高可用性構成にてDR環境を構築し、機能の検証を行っていきます。
以下 AWS での３ノード構成では、通常時の想定として
東京リージョンをメインサイトとして、東京1号機、東京2号機 が動作し、
大阪リージョンをバックアップサイトとして、大阪1号機が動作をしている想定の構成としております。
環境の設定値、ルーティング設定などは以下ブログに詳細を掲載しておりますので、気になる方はご参照下さい。
AWSマルチリージョンにおける高可用性方式を実装してみる – TechHarmony
LifeKeeperインストール/DRBD設定手順
DR環境でのLifeKeeperの設定手順について解説していきます。
まずは、LifeKeeperのインストールする際の手順となります。
LifeKeeperをインストールするタイミングでDisaster Recovery Add-onの機能を有するオプションを一緒にインストールすることが可能です。
インストール時以下のように、ARKと呼ばれるミドルウェア選択項目にて「DRBD Recovery Kit」を選択すればOKです。
インストール時の注意点として、「Quorum/Witness」の選択を忘れずにしましょう。
LifeKeeperが持つQuorum/Witness機能を使用することで、複数ノードが同時にActive状態になることを防止できます。
インストールが完了しましたら、
DRBDの設定作業を行っていくためのGUIをインストールする作業を行います。
設定に関しては、LifeKeeper GUIにて実行できますので、その事前準備を行います。
GUIはLKWMC[LifeKeeper Web Management Console]と呼ばれるWebアプリケーションを利用していきます。
LKWMCのインストールファイルを各ノードに配置し、インストールスクリプトを実行することで利用することができます。
LKWMC利用の注意点として、TCPポート5110を使用するため、通信許可の設定が必要です。
GUIの準備ができましたら、DRBDの設定を投入していきます。
設定内容は以下の5項目となります。
| 1 | コミュニケーションパス |
| 2 | DRBDリソース作成/拡張 |
| 3 | IPリソース作成/拡張 |
| 4 | Generic ARK作成/拡張 |
| 5 | Quorum設定 |
■コミュニケーションパス
LifeKeeper では、複数台のノードをお互いに接続することで、クラスターを構成していきます。
そのため、各ノード間で通信を行うための経路を事前に設定する必要があります。
この通信経路のことを LifeKeeper では「コミュニケーションパス」と呼び、こちらの設定を行います。
コミュニケーションパス＞オペレーション
にて各ノードの設定を入れていきます。作成が完了すると上記画像のような表記がされます。
コミュニケーションパスを作成する際の注意点なのですが、名前解決とTCPポートの穴あけが必要となります。
今回の環境では、/etc/hostsに各ノードの情報を記載し、コミュニケーションパスで使用する7365のポートの通信許可の設定を行いました。
■DRBDリソース作成/拡張
コミュニケーションパスの作成が完了できましたら、次はDRBDリソースの作成と各ノードに拡張をしていく作業となります。
DRBDリソースは、共有ストレージを使用せずに可用性の高いクラスターを構築する機能を提供します。
まず各ノードにて、マウントポイントの対象となるデバイスの確認(ない場合は作成)、
対象デバイスにてパーティションの作成を行います。
上記作成ができましたら、GUIにてリソース作成を行っていきます。
リソースツリー＞オペレーションからDRBDリソース作成を行えます。
作成が完了しますと、上記のように「drbd-mp」というマウントポイントの作成ができます。
このマウントポイントを各ノードへ拡張を行うと、以下のようにデータの同期先として利用できるようになります。
リソース作成/拡張の設定を投入する際に、切り替え/切り戻し動作の設定を行うことができます。
切り替えを手動 or 自動で行うのか。
切り戻しを手動 or 自動で行うのかを選択することが可能です。
今回の設定では切り替えを自動、切り戻しを手動の設定にて行いました。
■IPリソース作成
続いてIPリソースの作成を行います。
IPリソースは各ノード間で切り替えることができる仮想IPアドレスの作成を行います。
今回は、「20.1.1.1」という仮想IPアドレスを用意し、設定していきます。
AWS上での仮想IPアドレスについては過去に解説記事を投稿していますので、こちらをご参照ください。
【LifeKeeper】AWSでは仮想IPアドレスが使えない！？をこうして解決する！！ – TechHarmony
■GenericARK作成/拡張
メインサイトである東京リージョンがDownした際に、自動で大阪リージョンへルートテーブルが切り替わるためのスクリプトを組み込みます。
詳細については別記事にて紹介予定となります。
■Quorum設定
今回は自動切り替わりの動作とするため、Quorum設定を行います。
(手動切り替えの際は設定不要となります)
GUI上での設定対応が終わりましたら、Quorum機能を有効にするためmajorityからstorageへ変更、
本番/災対サイト以外のリージョンにS3の作成を行い、その情報を設定へ追記します。
Disaster Recovery 構成ではメインサイトの２台が停止する想定のため、バックアップサイトのノード１台では Quorum を持つことができず、自動起動ができなくなります。
この場合、storage モードを使用することでメインサイトの２台が停止しても、バックアップサイトのノードにフェイルオーバーして、サービスをすばやく継続することができます。
storage としては、メインサイト/バックアップサイトとは別のリージョンに Amazon S3 を準備しておきます。Quorum設定なしでも自動で起動しますが、ネットワークが分断した場合（メインサイトは生きているが、クラスタノード間のネットワークが切断）はスプリットブレインになる可能性もあるので、Quorum/Witness の使用を推奨としています。
これにてLifeKeeperのインストール及びDRBD設定が完了となります。
シナリオ/機能検証
設定が完了したところで、Disaster Recovery Add-onの機能を検証していきたいと思います。
今回の確認観点としては、
●フェイルオーバー時の動作
東京リージョンが使用不可になった際、大阪リージョンへのフェイルオーバーが問題なく行われるか。
●データレプリケーションの整合性
DRBDリソースの作成時に指定したマウントポイントである”drbd-mp”が
ファイルシステムとして稼働しているか、対象のファイルがレプリケーションされているか。
この2つの観点で機能を検証してみます。
テストシナリオとして、東京1、2号機(東京リージョン)をDownさせ、大阪1号機へフェイルオーバーを行います。
まず、通常時として以下のような状態となります。
東京1号機がActive、東京2号機/大阪1号機がStandbyの状態となります。
東京1号機に「drbd-mp」が存在し、test.txtがあります。東京2号機/大阪1号機にはありません。
今回のシナリオに沿って東京リージョンの1,2号機をDownさせていきます。
以下画像が東京東京1,2号機が落ちている状態となります。
GUIでリソースの状態を確認してみると無事フェイルオーバーされ、大阪1号機がPrimaryの状態となりました。
レプリケーションされているか確認したところ、drbd-mp(マウントポイント)が移動されており、
対象ファイルも確認できました。
切り替わり時間としては、東京リージョンをDownさせてから体感40~50秒ほどで切り替わりました。
東京1,2号機を復旧させると、大阪1号機がActiveで稼働している状態となります。
復旧後の切り戻しは手動 or 自動のどちらかを指定して戻すことができますが、
今回の切り戻し設定は、切り戻しのタイミングを管理者側のタイミングで復旧できるよう手動としておりますので、
東京が復旧してきても大阪1号機がActiveの状態のままとなります。
まとめ
今回AWS環境でのLifeKeeperを用いた災害対策としてDisaster Recovery Add-on の構築、機能検証を行い、
異なるリージョン間のデータレプリケーションの確認を行いました。
マルチAZ構成での可用性を高めるだけでなく、マルチリージョン構成をとることで、
遠隔地サイトへのスタンバイノードに対しても高速なレプリケーションと、障害発生時のフェールオーバーを可能とするため、自然災害によるシステム停止から素早くアプリケーションを回復することが可能となり、
よりシステムの信頼性と可用性を向上させ、企業のIT運用をさらに強固なものにすることができるなと感じました。
近年の災害対策としてぜひDisaster Recovery Add-onをご活用いただければと思います。