こんにちは。
サイオステクノロジーの高田です。LifeKeeperのトレーニングを担当しています。
第3回では、サーバーの設定とLifeKeeperを利用したDBサーバーのクラスタ化について記載しました。
最終回となった第4回めは、WordPressの設定とAWS側のWebサーバーをAMIから起動する設定を行います。
まずは、WordPressの設定から行います。
Contents
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 のためのデータベース名 */ /** MySQL データベースのユーザー名 */ /** MySQL データベースのパスワード */ /** MySQL のホスト名 */ /** データベースのテーブルを作成する際のデータベースの文字セット */ define(‘AUTH_KEY’, ‘************************************’); |
※ DB_PASSWORDには、データベースのパスワードを入力します。
※ DB_HOSTには、それぞれサーバーから参照するDBサーバーのIPアドレスを入力します。各サーバーで入力する値が異なります。
※ 認証用ユニークキーの値は、WordPress.orgの https://api.wordpress.org/secret-key/1.1/salt/で取得可能です。取得した認証用ユニークキーを貼り付けます。
※ 本手順では、オンプレミス側からWordPressの設定を行っています。この後の手順1.2を行うとオンプレミス側のサイトURLが登録されます。AWS側のサイトURLが異なる場合は、AWS側のwp-config.phpの以下を追記します。指定するIPアドレスはAWS側DBサーバーのElastic IP アドレス(以下、EIP)です。
| define(‘WP_SITEURL’, ‘http://52.***.***.***’); define(‘WP_HOME’, ‘http://52.***.***.***’); |
EIPの割り当ておよび関連付けの方法は以下のとおりです。
(1)新しいEIPを割り当てます
AWSのマネジメントコンソールからEC2(またはVPC)を選択した後、Elastic IPを選択します。「新しいアドレスの割り当て」を選択します。表示される画面に沿って進めると作成できます。
(2)EIPをWebサーバーに関連付けます。アクションから「アドレスの関連付け」を選択します。
(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 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をインストールします。
| # git clone https://github.com/yyuu/pyenv.git ~/.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を参照してください。
(1)AMIを起動するスクリプトを作成します。
※ 作成したスクリプトはAWS側のサーバーに配置します。
※ スクリプトには実行権限が付与されている必要があります。
※ 今回は、AMI起動だけ行う最低限のスクリプトを参考例として示します。上部パラメーターを該当の環境に合わせて指定します。
[サンプル]
#!/bin/sh ElasticIDs=eipalloc-******* #Elastic-IP ID ##### Create instance from AMI ##### if [ $? != “0” ]; then ##### Create State Checking ##### ##### Getting Instance ID ##### if [ $? != 0 ]; then ##### Atach VM name ##### ##### Associate Elastic IP ##### 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/LifeKeeperのCONFIRMSODEFパラメータの値を「0」から「1」に変更します。両方のサーバーで同じ値になるように設定します。
| # vi /etc/default/LifeKeeper |
変更されていることを確認します。
| # cat /etc/default/LifeKeeper | grep CONFIRMSODEF CONFIRMSODEF=1 |
3.2 イベント通知設定
LifeKeeperではイベントが発生した場合、イベントの発生を通知することが可能です。何か異常があった場合に早期に検知できるようにしておきます。通知方法としては、SNMP TRAPとメールの設定が可能です。各通知方法の概要および設定方法の詳細については、以下のURLをご参照ください。
以上で全ての設定が完了です。ご興味があれば、試してみてください。
