[Linux] DynamicDR（オンプレto AWS ディザスタリカバリ環境）の実現（第4回）～WordpressとWebサーバーの起動設定

こんにちは。
サイオステクノロジーの高田です。LifeKeeperのトレーニングを担当しています。

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

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

Contents hide

1 WordPressの設定
- 1.1 wp-config.phpの編集
- 1.2 ブラウザでの設定およびログイン
2 WebサーバーのAMI化およびAWS CLI設定
3 その他LifeKeeperの設定
- 3.1 自動切り替えの無効化
- 3.2 イベント通知設定

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アドレスを入力します。各サーバーで入力する値が異なります。
※ 認証用ユニークキーの値は、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サーバーで全てのリソースが起動している必要があります。リソースの起動方法の詳細については、以下の資料を参照してください。

リソースを In Service にする

(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を参照してください。

[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/LifeKeeperのCONFIRMSODEFパラメータの値を「0」から「1」に変更します。両方のサーバーで同じ値になるように設定します。

# vi /etc/default/LifeKeeper

変更されていることを確認します。

# cat /etc/default/LifeKeeper | grep CONFIRMSODEF
CONFIRMSODEF=1

3.2 イベント通知設定

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

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

>>第1回から読む

[Linux] DynamicDR（オンプレto AWS ディザスタリカバリ環境）の実現（第4回）～WordPressとWebサーバーの起動設定