1. ホーム /
  2. やってみた /
  3. [Linux] DynamicDR（オンプレto AWS ディザスタリカバリ環境）の実現（第4回）～WordpressとWebサーバーの起動設定

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

    サイトのホーム画面を確認

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

    第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アドレスを入力します。各サーバーで入力する値が異なります。
    ※  認証用ユニークキーの値は、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を選択します。「新しいアドレスの割り当て」を選択します。表示される画面に沿って進めると作成できます。

    新しいEPIを割り振ります

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

    アドレスの関連付け

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

    アドレスの関連付け-WEBサーバを指定

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

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

    ※  この作業を行うためにはDBへ接続する必要があります。そのため、AWS側で作業する際は、AWS側のDBサーバーで全てのリソースが起動している必要があります。リソースの起動方法の詳細については、以下の資料を参照してください。

    (1)AWSのマネジメントコンソールからEC2を選択します

    4EC2を選択

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

    WordPressへログイン

    (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を作成します。

    AMIを作成

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

    AMI名を入力

     

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

    作成したAMIを確認

    2.2 Webサーバーの削除

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

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

    AWSサーバの削除

    (2)デフォルトでは、サーバー削除後もEIPは残ります。サーバーに関連付けられていない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
     # 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画面では以下のように表示されます。

    LifeKeeperのGUI

    2.6 AWS側のサーバーでの起動スクリプトを入れ替え

    AWSDB側のGenericリソースのスクリプトを手順2.4(１)で作成したAMI起動用のスクリプトに入れ替えます。

    (1)AWS側のGenericリソースのプロパティ画面を表示します。

    Genericリソースのプラパティ画面

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

    AWS側のサーバー選択を確認

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

    Restoreを選択

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

    フルパスでスクリプトを指定

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

    変更内容を確認

    (6)オンプレ側のスクリプト変更しないため、「No」を選択します。
    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回から読む

    SNSでもご購読できます。