2016年9月28日水曜日

LifeKeeperブログのリニューアルについて



LifeKeeperブログを、2016928日より新たにリニューアルしました。


新サイトURLはこちら

今後は、ビジネス継続とITの継続性に関する有意義な情報について、この新ブログサイトを通じて発信していきます。

2016年9月27日火曜日

Higher Availability DBを目指して、LifeKeeperのチューニングを試してみました。(第4回)



こんにちは
サイオステクノロジー 宇野です。
2回、第3回でリソース監視、リカバリーの短縮、ノード監視、リカバリーの短縮に取り組んできました。今回はこれまで紹介した以外の方法について考えてみます。

1.     ローカルリカバリーを無効化する事による切り替え処理の短縮

LifeKeeperではリソース障害発生時、フェイルオーバーによるリカバリーの前に、障害の発生したノードでの復旧(ローカルリカバリー)を試みます。この処理に成功した場合、フェイルオーバーは引き起こさずに、稼働していたアクティブノードで復旧します。失敗した場合は、フェイルオーバーに処理が移ります。














ローカルリカバリーは、成功すればフェイルオーバーが不要となりリカバリーに要する時間の短縮となりますが、失敗した場合は失敗後にフェイルオーバーをしますので、サービス停止の停止時間が長くなってしまいます。
今回はフェイルオーバーでしかリカバリー出来ない障害を手動で引き起こし、ローカルリカバリーにどの程度の時間を要したのか測定しました。またローカルリカバリーをオフにすることでどの程度リカバリーに要する時間が短縮されるのか確認してみました。

リソース障害時の処理となりますので、以下のパラメータの間隔で行われる監視処理で異常と判定される障害を引き起こします。具体的にはpostgresの実行ファイルが再起動出来なくする(実行ファイルから実行権限を取り除く)擬似障害環境を用意して、postgresプロセスを停止しました。

最初に、比較用にローカルリカバリーがオンの状態でリカバリーに要した時間を測定します。監視処理の間隔は確認した以下の最小値を使用しました。

LKCHECKINTERVAL=26

以下の様にプロセスを確認して、実行権限を取り外して、プロセスを停止しました。
l  postgresプロセスを確認
[root@pd108 ~]# ps afx | grep postgres
11621 pts/0    S+     0:00          \_ grep --color=auto postgres
10322 ?        S      0:00 /usr/local/pgsql/bin/postgres -D /usr/local/pgsql/data -i -k /tmp -p 5432 -d 5
10324 ?        Ss     0:00  \_ postgres: checkpointer process
10325 ?        Ss     0:00  \_ postgres: writer process
10326 ?        Ss     0:00  \_ postgres: wal writer process
10327 ?        Ss     0:00  \_ postgres: autovacuum launcher process
10328 ?        Ss     0:00  \_ postgres: stats collector process

l  実行権限を停止する
[root@pd108 ~]# chmod 644 /usr/local/pgsql/bin/postgres
*必ず、元の権限を確認しておきます。またテストが終わったら、元の権限に戻します。

l  プロセスを停止する。
[root@pd108 ~]# killall /usr/local/pgsql/bin/postgres


停止したプロセスを、次の監視処理が検出して、障害として切り替わりました。その際のログは以下です。

# 障害を検出した際のログです。
Aug 31 14:13:26 pd108 quickCheck[3303]: INFO:RKBase:quickCheck::001001:Calling sendevent for resource "pgsql-5432" on server "pd108.labs.sios.com"
Aug 31 14:13:26 pd108 lkexterrlog[3435]: INFO:lkexterrlog:quickCheck:pgsql-5432:010120:Extended logs saved to /var/log/lifekeeper.err.

# ローカルリカバリーを開始しました。
Aug 31 14:13:26 pd108 recover[3430]: NOTIFY:lcd.recmain:recover:pgsql-5432:011115:BEGIN recover of "pgsql-5432" (class=pgsql event=dbfail)
Aug 31 14:13:26 pd108 recover[3430]: ERROR:lcd.recover:recover:pgsql-5432:004779:resource "pgsql-5432" with id "pd108.pgsql-5432" has experienced failure event "pgsql,dbfail"
Aug 31 14:13:26 pd108 recover[3430]: INFO:lcd.recover:recover:pgsql-5432:004784:attempting recovery using resource "pgsql-5432" after failure by event "pgsql,dbfail" on resource "pgsql-5432"
Aug 31 14:13:26 pd108 dbfail[3445]: INFO:RKBase:dbfail::000000:BEGIN dbfail of "pgsql-5432" on server "pd108.labs.sios.com"
Aug 31 14:13:45 pd108 dbfail[3445]: INFO:RKBase:dbfail::001022:END failed hierarchy "dbfail" of resource "pgsql-5432" on server "pd108.labs.sios.com" with return value of 1
Aug 31 14:13:45 pd108 lkexterrlog[4780]: INFO:lkexterrlog:recover:pgsql-5432:010120:Extended logs saved to /var/log/lifekeeper.err.
Aug 31 14:13:45 pd108 recover[3430]: ERROR:lcd.recover:recover:pgsql-5432:004786:recovery failed after event "pgsql,dbfail" using recovery at resource "pgsql-5432" on failing resource "pgsql-5432"
#ローカルリカバリーに失敗しました。
Aug 31 14:13:45 pd108 recover[3430]: ERROR:lcd.recover:recover:pgsql-5432:004028:all attempts at local recovery have failed after event "pgsql,dbfail" occurred to resource "pgsql-5432"
Aug 31 14:13:45 pd108 recover[3430]: INFO:lcd.recover:recover:pgsql-5432:004790:removing resource "pgsql-5432" for transfer
# ローカルリカバリーに失敗した為、フェイルオーバー処理を開始します。
Aug 31 14:13:45 pd108 remove[4811]: INFO:RKBase:remove::000000:BEGIN remove of "pgsql-5432" on server "pd108.labs.sios.com"
<省略>

# 切り替え先のノードでPostgreSQLのリソースが起動完了しました。
Aug 31 14:14:24 pd109 restore[20369]: INFO:RKBase:restore::000000:BEGIN restore of "pgsql-5432" on server "pd109.labs.sios.com"
Aug 31 14:14:24 pd109 restore[20369]: INFO:pgsql:restore::113041:server starting
Aug 31 14:14:27 pd109 restore[20369]: INFO:RKBase:restore::000000:END successful restore of "pgsql-5432" on server "pd109.labs.sios.com"

ローカルリカバリーをオンにした状態では、上記のように障害を検出してからPostgreSQLリソースが起動完了するまでに61秒を要しました。

次に、ローカルリカバリーをオフにして同じテストを行ってみました。

ローカルリカバリーをオフにする場合は、lkpolicyコマンドを使用してオン/オフすることが出来ます。以下のコマンドは、ノード全体のローカルリカバリーをオフにする方法となります。リソース毎に設定する場合は、”tag=”リソース名を使用してください。

[root@pd108 ~]# lkpolicy -s LocalRecovery –off



ローカルリカバリーをオフにして同じテストを行った場合、以下の様にログが出力しました。

# 障害を検出した際のログです。
Aug 31 15:22:46 pd108 quickCheck[14791]: INFO:RKBase:quickCheck::001001:Calling sendevent for resource "pgsql-5432" on server "pd108.labs.sios.com"
Aug 31 15:22:46 pd108 lkexterrlog[14939]: INFO:lkexterrlog:quickCheck:pgsql-5432:010120:Extended logs saved to /var/log/lifekeeper.err.
#ローカルリカバリーを開始します。
Aug 31 15:22:46 pd108 recover[14934]: NOTIFY:lcd.recmain:recover:pgsql-5432:011115:BEGIN recover of "pgsql-5432" (class=pgsql event=dbfail)
Aug 31 15:22:46 pd108 recover[14934]: ERROR:lcd.recover:recover:pgsql-5432:004779:resource "pgsql-5432" with id "pd108.pgsql-5432" has experienced failure event "pgsql,dbfail"
#ローカルリカバリーは無効化されている事を確認しました。その為、ローカルリカバリーは行われません。
Aug 31 15:22:46 pd108 recover[14934]: ERROR:lcd.recover:recover:pgsql-5432:004780:local recovery is disabled by the current settings.  The recovery of resource "pgsql-5432" will not be attempted.
Aug 31 15:22:46 pd108 recover[14934]: INFO:lcd.recover:recover:pgsql-5432:004790:removing resource "pgsql-5432" for transfer
#フェイルオーバー処理を開始します。
Aug 31 15:22:46 pd108 remove[14949]: INFO:RKBase:remove::000000:BEGIN remove of "pgsql-5432" on server "pd108.labs.sios.com"

<省略>
# 切り替え先のノードでPostgreSQLのリソースが起動完了しました。
Aug 31 15:23:26 pd109 restore[31024]: INFO:RKBase:restore::000000:BEGIN restore of "pgsql-5432" on server "pd109.labs.sios.com"
Aug 31 15:23:27 pd109 restore[31024]: INFO:pgsql:restore::113041:server starting
Aug 31 15:23:29 pd109 restore[31024]: INFO:RKBase:restore::000000:END successful restore of "pgsql-5432" on server "pd109.labs.sios.com"

ローカルリカバリーをオフにした状態では、障害を検出してからPostgreSQLリソースが起動完了するまでに43秒を要しました。
今回の環境ではローカルリカバリーのオン、オフで61秒、43秒と18秒程度の差が確認できました。ローカルリカバリーはフェイルオーバーを起こさずに障害を復旧する可能性のある処理ですが、復旧しない場合もあります。その為、上記のように事前にローカルリカバリーをオフにして運用する事も可能です。



2.     PostgreSQL ARKのパラメータ

その他、各リソースのパラメータについて確認しました。PostgreSQL ARKは以下の様に多数のパラメータを用意していますが、初期設定が全て最短の処理となるよう設計されていました。その為、インストール後のパラメータのカスタマイズによる障害検出時間の短縮やリカバリー処理を早める事は出来そうにありませんでした。その為、デフォルトの設定で問題なく稼働するようであれば、パラメータ変更を行なわずに利用して頂くのが最も停止時間を短縮する方法でした。

以下がPostgreSQL ARKのパラメータ一覧です。
















































以上が、4回にわたって紹介したHigher Availability(より高い可用性)を実現する手法です。今回紹介した以外の方法についても施策を考えていますが、また検証が行えましたら紹介してゆきたいと考えています。



3. まとめ

これまでの検証で、アプリケーション監視時間間隔(LKCHKINTERVAL)の短縮(120→30秒)、ノード障害検出時間(LCMHBEATTIME×LCMNUMHBEATS)の短縮(15→4秒)、フェイルオーバー時間の短縮(ローカルリカバリーON/OFF)などの調整(43→18秒)というPostgreSQL ARKにおけるLifeKeeperチューニングのベストプラクティスが得られました。
 アプリケーション障害の場合、30秒以内にPostgreSQLの障害を検知し、11秒~18秒でフェイルオーバーが完了します。適切なシステムリソース(CPU、メモリー)を配置することで障害検知から待機系でのサービス再開まで60秒以内で完了させることが可能です。
                                                      
障害検知にかかる時間の短縮
ノード監視       15→4
リソース監視      120→30

アプリケーション起動時間の短縮
ローカルリカバリー時のアプリの起動     ローカルリカバリーON→OFF
フェイルオーバー時のアプリの起動     11秒~18秒(DBのリカバリー処理が無い場合)
DBのリカバリー処置に要する時間      障害時の書き込み系トランザクションに依存するため不定



4.     今後の展開
LifeKeeperのチューニングは、いかにノード障害、アプリケーション障害を素早く検知しフェイルオーバー処理を開始するかという点に関しては有効な手段であることが分かります。一方で、監視対象であるアプリケーションはフェイルオーバー時に待機系で起動するため、待機ノードでのDB起動時間、DBリカバリー時間の短縮という2つの課題をクリアするのは非常に困難です。
Higher Availability DBのゴールである、「障害検知からフェイルオーバー完了(待機系でのサービス再開)までを30秒以内で完了する」という課題をクリアするためには、根本的な対応が必要です。
そこで私たちが着目したのが、EnterpriseDB DB マルチマスターレプリケーションです。DBサーバーが相互に表の同期(レプリケーション)を行い、どのDBサーバーにアクセスしても参照・更新が可能となるものです。
















図1 xDB Multi Master Replication(MMR) 基本構成 
・全てのDBノードがマスターノードとして動作し相互に
   レプリケーションを実行
・どのノードのDBに対しても参照・更新が可能


この仕組みを利用することで待機系でのDB起動をしなくても良い仕組みが構築できるのではないかと考え、以下のようなLifeKeeperと組み合わせた構成を検討しました。

















DB MMR LifeKeeper構成に関しては、現在検証作業を実施中です。検証結果については順次当ブログにてお伝えして行く予定です。


2016年9月21日水曜日

DynamicDR(オンプレto AWS ディザスタリカバリ環境)の実現 (第4回)


こんにちは。SIOSの高田です。
DynamicDR4回目(最終回)のブログです。

前回の第3回目では、サーバーの設定とLifeKeeperを利用したDBサーバーのクラスタ化について記載しました。今回の第4回目では、WordPressの設定とAWS側のWebサーバー
AMIから起動する設定を行います。

まずは、WordPressの設定から行います。

1 WordPressの設定

オンプレミスおよびAWS環境のWebサーバーでWordPressの設定を行います。一部設定内容が各サーバーで異なります。

1.1     wp-config.phpの編集

WordPressの設定ファイルをサンプルからコピーして編集します。
# cp /var/www/wordpress/wp-config-sample.php /var/www/wordpress/wp-config.php
# vi /var/www/wordpress/wp-config.php

wp-config.phpの以下の部分を変更します。
/** WordPress のためのデータベース名 */
define( 'DB_NAME', 'wp' );
/** MySQL データベースのユーザー名 */
define( 'DB_USER', 'wp' );
/** MySQL データベースのパスワード */
define( 'DB_PASSWORD', 'パスワード' );
/** MySQL のホスト名 */
define( 'DB_HOST', 'DBサーバーのIPアドレス' );
/** データベースのテーブルを作成する際のデータベースの文字セット */
define( 'DB_CHARSET', 'utf8' );
define('AUTH_KEY',         '************************************');
define('SECURE_AUTH_KEY',  '************************************');
define('LOGGED_IN_KEY',    '************************************');
define('NONCE_KEY',        '************************************');
define('AUTH_SALT',        '************************************');
define('SECURE_AUTH_SALT', '************************************');
define('LOGGED_IN_SALT',   '************************************');
define('NONCE_SALT',       '************************************');

DB_PASSWORDには、データベースのパスワードを入力します。
DB_HOSTには、それぞれサーバーから参照するDBサーバーのIPアドレスを入力します。各サーバーで入力する値が異なります。
※認証用ユニークキーの値は、https://api.wordpress.org/secret-key/1.1/salt/ WordPress.orgで取得可能です。取得した認証用ユニークキーを貼り付けます。

※本手順では、オンプレミス側からWordPressの設定を行っています。この後の手順
1.2を行うとオンプレミス側のサイトURLが登録されます。AWS側のサイトURL
異なる場合は、AWS側のwp-config.phpの以下を追記します。指定するIPアドレス
AWSDBサーバーのElastic IP アドレス(以下、EIP)です。
define('WP_SITEURL', 'http://52.***.***.***');
define('WP_HOME', 'http://52.***.***.***');

EIPの割り当ておよび関連付けの方法は以下のとおりです。

   (1)   新しいEIPを割り当てます
AWSのマネジメントコンソールからEC2(またはVPC)を選択した後、Elastic IPを選択します。「新しいアドレスの割り当て」を選択します。表示される画面に沿って進めると作成できます。
















(2)   EIPWebサーバーに関連付けます。アクションから「アドレスの関連付け」を選択します。
















(3)   Webサーバーを指定します。












   


1.2     ブラウザでの設定およびログイン

ブラウザを起動して外部からアクセスするIPアドレスを入力します。画面に従って入力してサイトに参照できることを確認します。

※この作業を行うためにはDBへ接続する必要があります。そのため、AWS側で作業する際は、AWS側のDBサーバーで全てのリソースが起動している必要があります。リソースの起動方法の詳細については、以下の資料を参照してください。
 
  
(1)   AWSのマネジメントコンソールからEC2を選択します


















(2)   WordPressのインストールが完了したので、ログインします。AWS側では既にインストール済みである旨のメッセージが出力されます。
















(3)   先程指定したユーザー名およびパスワードを入力します。



















(4)   管理画面にログインできました。サイトのホーム画面も確認します。















(5)   サイトのTOPページが参照できました。













(6)   必要に応じてパーマリンクを変更します。管理画面の「設定」「パーマリンク設定」から「基本」を選択して保存します。オンプレミス側で設定している場合、AWS側でも同じ設定となります。



      
2 WebサーバーのAMI化およびAWS CLI設定

オンプレミスで通常運用する際、AWS側のWebサーバーは稼働しません。このWebサーバーをAmazon マシンイメージ(以下、AMI)として保存して置き、障害時に稼働するように設定します。

2.1      WebサーバーのAMI

AWS側のWebサーバーのAMIを作成します。

    (1)   AWSマネジメントコンソールのEC2画面からWebサーバーを指定してAMIを作成します。
















(2)   「イメージ名」を入力します。必要に応じて「イメージの説明」も入力します。

















(3)   作成したAMIを確認します。
















2.2     Webサーバーの削除 
AWS側のWebサーバーは平時は稼働しないため、AMI取得後にサーバーを削除します


(1)   AWSマネジメントコンソールのEC2画面からWebサーバーを指定してインスタンスを削除します。他のサーバーを削除しないように注意してください。















(2)   デフォルトでは、サーバー削除後もEIPは残ります。サーバーに関連付けられていないEIPは課金対象であることに注意してください。

















2.3     AWS CLIの設定
AWS側のWebサーバーは平時は稼働しないため、AMI取得後にサーバーを削除します


AWS CLI の設定を行います。AWS CLIを設定することで、コマンドラインでAMIからサーバーを起動することが可能になります。

(1)   pip のインストールスクリプトをダウンロードし実行します。
# curl "https://bootstrap.pypa.io/get-pip.py" -o "get-pip.py" | python get-pip.py
※この後awscliをインストールするために「pip install awscli」コマンドを実
行したが、Python2.6はサポートできないメッセージが出力されたため、
Pythonをアップデートしました。

(2)   必要なパッケージをインストールします。
# yum install -y git gcc make openssl-deve

(3)   Python管理用のpyenvをインストールします。
# echo 'export PYENV_ROOT="$HOME/.pyenv"' >> ~/.bash_profile
# echo 'export PATH="$PYENV_ROOT/bin:$PATH"' >> ~/.bash_profile
# echo 'eval "$(pyenv init -)"' >> ~/.bash_profile
# source ~/.bash_profile

(4)   pyenvを利用してPython2.7インストールします。
# pyenv install 2.7.11
# pyenv global 2.7.11

(5)   pipを利用してawscliをインストールします。
# pip install awscli
# pip install --upgrade pip

(6)   必要なパッケージをインストールします。
# aws configure

上記コマンドを実行時に下記項目の入力を求められます。事前にアクセスキーIDおよびシークレットアクセスキーの認証情報を取得しておきます。
AWS Access Key ID [None]: ********************
AWS Secret Access Key [None]: ****************************************
Default region name [None]: ap-northeast-1
Default output format [None]:
※「ap-northeast-1」は東京リージョンを指します。

(7)   AWS CLI実行時にをjqコマンドを利用するため、インストールします。
# yum install -y jq

(8)   コマンドが実行可能か確認します。サーバーのインスタンスIDが表示されれば完了です。
# aws ec2 describe-instances | jq '.Reservations[].Instances[].I nstanceId'

2.4     AMIからの起動スクリプト作成

AWS CLIを利用してAMIからサーバーを起動するスクリプトを作成します。この後にGenericリソースとして組み込むための他のスクリプトも合わせて作成します。Genericリソースで利用するスクリプトの作成方法およびサンプルについては、以下のURLを参照してください。

[Linux] GenericARK開発ガイドとサンプルスクリプト

(1)   AMIを起動するスクリプトを作成します。

※作成したスクリプトはAWS側のサーバーに配置します。
スクリプトには実行権限が付与されている必要があります。
※今回は、AMI起動だけ行う最低限のスクリプトを参考例として示します。上部
パラメーターを該当の環境に合わせて指定します。

[サンプル]
#!/bin/sh
# Copyright (c) 2016 SIOS Technology, Inc.
################################################
#
# Title:       restore for DynamicDR
#
# Description: This script start deploy AWS instance from AMI
#
# Usage:       restore -t tagname -i id [-R]
#
#
################################################
# CHANGE LOG
#
# 16Aug26 ism Initial code
#
################################################
###User define Variables
ElasticIDs=eipalloc-*******     #Elastic-IP ID
PIPADDRS=10.10.1.10           #private ip address
SSHKEY=*******               #SSH-KEY
SecurityGID=sg-*******        #Scullity Groupe ID
SubnetID=subnet-*******      #Subnet ID for AWS Web
InsType=t1.micro                #Instance Type for AWS Web
AMIID=ami-*******             #AMI ID
AWSVMNAME=Web               #AWS VM Tag Name
##### Create instance from AMI #####
aws ec2 run-instances --image-id $AMIID --key-name $SSHKEY --count 1 --security-group-ids $SecurityGID --subnet-id $SubnetID --instance-type $InsType --private-ip-address $PIPADDRS > /dev/null 2>&1
if [ $? != "0" ]; then 
        exit 1
fi
##### Create State Checking #####
STATE=null
waittime=0
while [ "$STATE" != "running" ];
do 
        STATE=`aws ec2 describe-instances --filter
"Name=private-ip-address,Values=$PIPADDRS"| jq
'.Reservations[].Instances[].State.Name'|sed  's/\"//g'|sed 's/null//g'` 
        sleep 1
if [ $? != 0 ]; then 
        exit 1
fi
done
##### Getting Instance ID #####
InsID=`aws ec2 describe-instances --filter "Name=private-ip-address,Values=$PIPADDRS"| jq '.Reservations[].Instances[].InstanceId'|sed  's/\"//g'|sed 's/null//g'` > /dev/null 2>&1
if [ $? != 0 ]; then 
        exit 1
fi
##### Atach VM name #####
aws ec2 create-tags --resources $InsID --tags Key=Name,Value=$AWSVMNAME > /dev/null 2>&1
if [ $? != 0 ]; then 
        exit 1
fi
##### Associate Elastic IP #####
aws ec2 associate-address --instance-id $InsID --allocation-id $ElasticIDs > /dev/null 2>&1
if [ $? != 0 ]; then 
        exit 1
fi
exit 0
##### END

(2)   exit 0」を返すだけのスクリプトを作成します。

※作成したスクリプトはオンプレミス側のサーバーに配置します。
スクリプトには実行権限が付与されている必要があります。
※オンプレミス側での起動と停止時およびAWS側での停止時は、AMIからの起
動処理は行いません。そのため、処理をしない項目については、常にスクリプ
トの実行結果が「成功」となるようにします。スクリプトには実行権限が付与
されている必要があります。

[サンプル]
#!/bin/sh
exit 0

2.5     Genericリソース作成

LifeKeeper GUI管理画面より”Create Resource Hierarchy”を選択して、Genericリソースを作成します。作成時は「exit 0」を返すだけのスクリプトを登録します。リソース作成後にAMIからサーバーを起動するスクリプトに変更します。リソース作成ウィザードで入力する内容は以下の通りです。
Select Recovery Kit
Generic Application
Switchback Type
intelligent
Server
ONPREDB6B
Restore Script
<手順2.4(2)のスクリプトパス>
Remove Script
<手順2.4(2)のスクリプトパス>
QuickCheck Script [optional]
()
Application Info [optional]
()
Bring Resource In Service
Yes
Resource Tag
Launch_Instance

ターゲット(セカンダリ)サーバーに Extendするとき、入力する内容は以下の通りです。
Target Server
AWSDB6B
Switchback Type
intelligent
Template Priority
1
Target Priority
10
Resource Tag
Launch_Instance
Application Info [optional]
()

Genericリソースの作成が完了するとLifeKeeperGUI画面では以下のように表示されます。


























2.6     AWS側のサーバーでの起動スクリプトを入れ替え
 AWSDB側のGenericリソースのスクリプトを手順2.4()で作成したAMI起動用のスクリプトに入れ替えます。
    (1)   AWS側のGenericリソースのプロパティ画面を表示します。

























(2)   Script更新の処理を行います。この時、AWS側のサーバーを選択している必要があります。

























(3)   変更対象のスクリプトを指定します。今回は、restoreを選択します。


















(4)   新しく適用する手順2.4(1)で作成したスクリプトをフルパスで指定します。AWS側のサーバーに対象のスクリプトが配置されている必要があります。
















(5)   変更内容を確認します。















(6)   オンプレ側のスクリプト変更しないため、「No」を選択します。

















(7)   変更完了を確認する。

















2.7     リソース間の依存関係の構築

LifeKeeper GUI管理画面より”Create Dependency”を選択し、GenericリソースとデMySQLリソースとの間に依存関係を作成します。
下記のリソースの依存関係図例のように、Parent Resource(親リソース)がGenericリソース、Child Resource(子リソース)がMySQLリソースとなるよう設定してください。依存関係を作成することでリソース切り替え時に全てのリソースが一緒に遷移して、適切な順序で起動/停止することが可能です。

依存関係の作成方法については、以下のURLをご参照ください。

リソース依存関係の作成

リソースの依存関係図例



















3 その他LifeKeeperの設定

本検証の構成を利用する場合、以下の設定を行うことをお奨めします。

3.1     自動切り替えの無効化

本検証の構成では、AWS側はディザスターリカバリー用の環境となります。オンプレミス側が全損するようなケースにおいて切り替えて使用することを想定しています。そのため、切り替えは自動ではなく手動で行います。自動切り替えの無効化の設定方法を以下に示します。

      (1)   LifeKeeper GUI管理画面よりプロパティ画面を表示します。
























(2)   チェックボックスにチェックを入れます。両方のサーバーで同じ値になるように設定します。
























(3)   /etc/default/LifeKeeperCONFIRMSODEFパラメータの値を「0」から「1」に変更します。両方のサーバーで同じ値になるように設定します。
# vi /etc/default/LifeKeeper

変更されていることを確認します。
# cat /etc/default/LifeKeeper | grep CONFIRMSODEF
CONFIRMSODEF=1

3.2     イベント通知設定

LifeKeeperではイベントが発生した場合、イベントの発生を通知することが可能です。何か異常があった場合に早期に検知できるようにしておきます。通知方法としては、SNMP TRAPとメールの設定が可能です。各通知方法の概要および設定方法の詳細については、以下のURLをご参照ください。

SNMP による LifeKeeper イベント転送

LifeKeeper イベントメール通知

以上で全ての設定が完了です。興味あれば試してみてください。