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 イベントメール通知

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




0 件のコメント:

コメントを投稿