Contents
はじめに
みなさんこんにちは。東日本担当のプリセールスの西下（にしした）です。
前回のブログ記事ではAmazon EC2向けのLinux版のLifeKeeperによるHAクラスター構成の1つの「ルートテーブルシナリオ」の準備としてAWS側の設定手順をご紹介し、インスタンスを作成し踏み台のWindowsサーバーの接続の手順まで進めました。
今回はいよいよLifeKeeperの導入および設定手順をご紹介します。できるだけ最小限の手順で構成しました。
・ 実際の構築手順（LifeKeeperの設定編） ←今回
・ 実際の構築手順（保護対象のソフトウェアの設定編）
手順はこの通り行わければならないものではありませんので参考としてご覧ください。また、内容を参考にされた結果生じたいかなる損害も当社は責任を負いませんので、事前に十分な動作検証をお願いします。 |
Amazon EC2の構成（再掲）
今回は下記の構成を前提に構築手順を進めています。NATインスタンスなどのAWSの構成要素は下記の第2回の記事をご参照下さい。
※よりシンプルにするために、サブネットC2のクライアントは省略してあります。
LifeKeeperのインストール作業の主な手順
今回は下記の手順で行います。
- インストールの準備
- LifeKeeperのインストール
- LifeKeeperの設定
- GUI管理画面の起動とログイン
- コミュニケーションパスの作成
- IPリソースの作成
- AWS ECCリソース（EC2™リソース）の作成
- DataKeeperリソースの作成
各手順
以降の手順は断りがない限り踏み台のWindowsサーバーから行います。
インストールの準備 ※Node1およびNode2の両方で必要
踏み台のWindowsサーバーにRDPで接続します。具体的な手順は前回記事の「10.インスタンスへの接続」をご参照下さい。
WinSCPでクラスターノードのNode1とNode2の両方に下記をコピーしておきます。コピー先はデフォルトだと/home/ec2-userになります。
・LifeKeeper for Linuxのインストールイメージ（ISOファイル）
・LifeKeeper for Linuxの評価ライセンス（txtファイル）
PuTTYでNode1およびNode2に接続します。
以降の作業はNode1とNode2の双方に対して行います。
まず先程WinSCPでNode1に転送した2つのファイルが無事存在することを確認します。
今回ライセンスファイルは「Linux_evalkeys-90day.txt」、インストールイメージは「sps_920.img」としました。
[ec2-user@ip-10-0-2-4 ~]$ ls |
続いて適当なURL(例ではgoogle)へpingをしてインターネットに疎通できることを確認します。下記のように即応答が返ってくれば成功です。
[ec2-user@ip-10-0-2-4 ~]$ ping google.com |
しかしながら、下記のように応答が返ってこない場合があります。
[ec2-user@ip-10-0-2-4 ~]$ ping google.com |
この場合は恐らく次の2つの内のどちらかに問題があるはずなので確認して下さい。特に後者は私も何度か経験しました。
・該当するNATインスタンスが起動していない（Node1の場合はNAT1）。
・NATインスタンスまたはクラスターノードのインスタンスにおいて、[送信元/送信先の変更チェック]が「False（無効）」になっていない。（デフォルトは「True（有効）」）→前回記事の「8.送信元 送信先の変更チェックの無効化」をご参照下さい。
インターネットに無事疎通できることが確認できれば、下記の通りyumを使ってX11をインストールします。EC2上でyumによるオンラインアップデートを行う場合は、インターネットに疎通できることが前提となります。
[ec2-user@ip-10-0-2-4 ~]$ sudo yum groupinstall “x11” |
X11のインストールが完了したらLinuxの動作モード(ランレベル）を下記のコマンドでGUIにします。
[ec2-user@ip-10-0-2-4 ~]$ sudo systemctl set-default graphical.target |
RHEL7 でLifeKeeperをインストールする場合、redhat-lsb が必須パッケージになるので、yumでインストールしておきます。
[ec2-user@ip-10-0-2-4 ~]$ sudo yum install redhat-lsb |
LifeKeeper for Linuxでは各ノードをホスト名で参照します。そのため/etc/hostsファイルに両クラスターノードのIPアドレスとホスト名を登録します（下記の赤字箇所）。編集はvi等を適宜お使い下さい。
[ec2-user@ip-10-0-2-4 ~]$ cat /etc/hosts |
続いてSELinuxの無効化を行います。LifeKeeper for LinuxはSELinuxをサポートしていないため、導入に際してSELinuxを無効にしていただく必要があります。
まず状態を確認します。下記の通り有効になっています。
[ec2-user@ip-10-0-2-4 ~]$ sudo getenforce |
有効になっている設定を無効化します。
[ec2-user@ip-10-0-2-4 ~]$ sudo setenforce 0 |
以降恒久的にSELinuxを無効にするように/etc/selinux/configを編集します。（vi等で編集していただいても構いません）
[ec2-user@ip-10-0-2-4 ~]$ sudo sed -i -e ‘s/enforcing/disabled/g’ /etc/selinux/config |
続いてファイアウォールの無効化を行います。
まず下記のコマンドで現在のファイアウォールの有効/無効を確認します。
[ec2-user@ip-10-0-2-4 ~]$ sudo systemctl status firewalld |
上記の通り有効(「Loaded」)になっているのでこれを無効(「Disable」)に設定します。
[ec2-user@ip-10-0-2-4 ~]$ sudo systemctl disable firewalld.service |
ここまでの作業を行い、一旦仮想インスタンスを再起動します。
ここからは権限上rootユーザーで行います。
[ec2-user@ip-10-0-2-4 ~]$ sudo su – |
LifeKeeper のインストールでは rootのパスワードが必要となるため、rootのパスワードを設定します。
[root@ip-10-0-2-4 ~]# passwd |
LifeKeeperのインストールの準備は以上で完了です。
ここまでの作業をNode2に対しても行います。
LifeKeeperのインストール ※Node1およびNode2の両方で必要
ここからはrootでLifeKeeper for Linuxのインストールを行います。詳細については下記のユーザーサイトで公開されているスタートアップガイドをご参照下さい。
→[ユーザーサイト：スタートアップガイドの検索結果（該当するバージョンをお選び下さい）]
まず既に踏み台のWindowsサーバーからコピーしておいたLifeKeeperをインストールするために、
インストールイメージファイル（下記の例では「sps_920.img」）を/mntにマウントしてsetupを実行します。
[root@ip-10-0-2-4 ec2-user]# mount sps_920.img -t iso9660 -o loop,ro /mnt |
ここからはウイザードの操作になります。大半の項目はそのまま[Enter]を押して進めます。
LifeKeeper の基本パッケージのインストールです。[Enter]を押してください。
[Enter]を押します。
Java パッケージのインストール。Enter キーを押してください。
[Enter]を押します。
DataKeeper 用のカーネルモジュールのインストール。[Enter]キーを押してください。
[Enter]を押します。
NFS ユーティリティパッケージのインストール。Enter キーを押してください。
NFS サービスの再起動。Enter キーを押してください。
[Enter]を押します。
必須パッケージのインストール。Enter キーを押してください。
[Enter]を押します。
コア（本体）パッケージのインストール。Enter キーを押してください。
[Enter]を押します。
グループとログインユーザの設定。Enter キーを押してください。
[Enter]を押します。
ライセンスキーインストールの確認です。ここではインストールしないので[Enter]を押してください。（この後Recovery Kit for EC2™のインストール時に行います。）
インストールするオプション・リカバリキットの選択画面です。今回はlkDR（DataKeeper）とlkPGSQL（PsotgreSQL）を選択します。
インストールするパッケージの確認画面が表示されます。[Enter]を押してください。
パッケージのインストールに成功すると下記の画面が出るので[Enter]を押して下さい。
以上でsetupスクリプトによるインストールが完了しました。[Enter]を押して完了させてください。
Recovery Kit for EC2™のインストール
続いてRecovery Kit for EC2™をインストールします。
Recovery Kit for EC2™については上記のsetupスクリプトの中ではインストールされないため、下記のようにrpmコマンドで個別にインストールします。Recovery Kit for EC2™は、先程マウントした/mnt配下のamazonディレクトリの中にあります。
[root@ip-10-0-2-4 mnt]# cd /mnt/amazon/ |
上記の内「steeleye-lkECC-9.2.0-6629.noarch.rpm」を使います。ファイル名の内「9.2.0-6629」は使用するLifeKeeperのバージョンにより異なるので、適宜読み替えて下さい。
rpmコマンドでインストールします。
[root@ip-10-0-2-4 amazon]# rpm -Uvh steeleye-lkECC-9.2.0-6629.noarch.rpm |
lkkeyinsコマンドを使ってライセンスキーのインストールを行います。
[root@ip-10-0-2-4 amazon]# cd /home/ec2-user/ |
LifeKeeperのIPリソースでは、ブロードキャストpingを使いクラスター外部との疎通確認を行うことで仮想IPアドレスの監視処理を行っています。しかしAmazon EC2上ではAZ（Availability Zone）を跨いだHAクラスター構成となり、サブネットも跨いだ構成となります。このため、ブロードキャストpingでの疎通確認は行えない為この設定を無効化しておきます。
[root@ip-10-0-2-4 ec2-user]# sed -i -e ‘s/NOBCASTPING=0/NOBCASTPING=1/g’ /etc/default/LifeKeeper |
LifeKeeperのインストール作業は以上で完了です。
ここまでの作業をNode2に対しても行います。
LifeKeeperの設定
以降の手順はLifeKeeperのGUI管理画面を使います。但しEC2はネットワーク経由でしか操作できないため、モニタへ直接アクセスできません。このため、OSに関わらずGUIアクセスするにはリモート接続が必要です。
LifeKeeperの設定は直感的なGUI（X Window System）で行うため、クライアント（踏み台のWindowsサーバー）側にもXサーバーが必要となります。今回はWindowsの踏み台サーバー上にXサーバーをXmingで用意し、そのXmingに対して仮想インスタンス（Node1または2）からXをフォワードします。
踏み台のWindowsサーバーには既に下記の2点がここまでの手順で設定されているはずなので、改めて確認して下さい。
1.puTTYのSSHの設定で[enable X11 forwarding]を有効にしていること
2.XmingのインストールおよびLaunchしていること
上記の構成を使うにあたり、まずは下記の2つの環境変数について、「ec2-userでログインした時の内容」を、「rootでログインした時の内容」に対して反映する必要があります。
1.環境変数$DISPLAYの値
2.xauthのディスプレイ名
上記1.の環境変数$DISPLAYの値は下記のコマンドで確認します。
※この値は、踏み台のWindowsサーバーからpuTTYでSSH接続する度に変更します。
[ec2-user@ip-10-0-2-4 ~]$ echo $DISPLAY |
上記2.のxauthのディスプレイ名は下記のコマンドで確認します。（後で使うのでクリップボードに貼り付けておきます）
[ec2-user@ip-10-0-2-4 ~]$ xauth list |
一方、ec2-userからrootにスイッチして同じコマンドを試すと、下記のような値になります。
これらのrootの値をec2-userに合わせる必要があります。
[ec2-user@ip-10-0-2-4 ~]$ sudo su – |
まずDISPLAY変数への反映は、下記のようにexportコマンドで行います。
[root@ip-10-0-2-4 ~]# export DISPLAY=localhost:11.0 |
続いてxauthに先程クリップボードに貼り付けたディスプレイ名を追加します。
[root@ip-10-0-2-4 ~]# xauth add ip-10-0-2-4.ap-northeast-1.compute.internal/unix:11 MIT-MAGIC-COOKIE-1 193d48c60ec49fc41775afa7479157b0 |
上記の手順を忘れると下記のエラーが出て、踏み台のWindowsサーバー上でGUIが表示されません。
逆に下記のエラーが出た時はこれらの設定を疑ってみて下さい。
例：環境変数DISPLAYが空白のままの場合
[root@ip-10-0-2-4 default]# /opt/LifeKeeper/bin/lkGUIapp |
例：環境変数DISPLAYの値がec2-userの値と異なる場合（「localhost:11.0」なのに「localhost:10.0」とした場合）
[root@ip-10-0-2-4 ~]# /opt/LifeKeeper/bin/lkGUIapp |
例：DISPLAYの値が正しくてもxauthのディスプレイ名の整合が取れていない場合
[root@ip-10-0-2-4 ~]# /opt/LifeKeeper/bin/lkGUIapp |
上記の設定ができれば正常にLifeKeeperのGUI管理画面が踏み台のWindowsサーバー上で表示されます。
LifeKeeperの起動
続いてLifeKeeperの起動に入ります。
rootで下記のコマンドを実行し、LifeKeeperを起動します。（Node1とNode2の双方で必要）
[root@ip-10-0-2-4 default]# /opt/LifeKeeper/bin/lkstart |
Node1（稼動系ノード）側で、以下のコマンドでLifeKeeperのGUI管理画面を起動します。
[root@ip-10-0-2-4 ~]# /opt/LifeKeeper/bin/lkGUIapp |
A)GUI管理画面の起動とログイン
LifeKeeperの管理画面での認証画面で[Login]に「root」、[Password]に先程手順①の末尾で設定したパスワードを入力します。
下記の画面が表示されれば接続成功です。（Node1：10.0.2.4にログイン）
まず相手ノードとしてNode2（10.0.4.4）を登録します。
上記の左端のボタンをクリックすると[Cluster Connect]画面が表示されるので、Server Name に「ip-10-0-4-4.ap-northeast-1.compute.internal」、[login]に「root」、①の手順の末尾でPassword に設定した root パスワードを入力して[OK]をクリックします。
接続が成功すれば下記の画面が表示されます。
以上でログインとクラスターノード間の接続は完了です。
B)コミュニケーションパスの作成
相手ノードとコミュニケーションパスを作成します。
[Create Communication Path]ボタンをクリックしてウイザードを開始します。
以降は下記の値に従いウイザードを進めて下さい。
No. | 項目 | 入力値/選択値 | 備考 |
1 | Local Server | ip-10-0-2-4.ap-northeast1.compute.internal | 稼動系ホスト名 |
2 | Remote Server | ip-10-0-4-4.ap-northeast1.compute.internal | 待機系ホスト名 |
3 | Device Type | TCP |
|
4 | Local IP Address | 10.0.2.4 | 稼動系ノードのIPアドレス |
5 | Remote IP Address | 10.0.4.4 | 待機系ノードのIPアドレス |
6 | Priority | 1 |
|
[Done]で完了させます。
なお、LifeKeeperでは通常「2系統以上」のコミュニケーションパスの作成を推奨しています。
今回は出来る限り「最小限」の構成を目標にしているのと、物理環境と異なりクラウド環境では、仮想NICを冗長化メリットが少ないことから単一の仮想NICで構成されるケースが今後増えると考えられる背景から、今回はあえて単一のコミュニケーションパスで構成しています。
そのため、管理画面上ではノードの上に「！」マークが表示されたままになります。（2系統以上のコミュニケーションパスを設定すると、本来の緑色の「チェックマーク」です）
以上でコミュニケーションパスの設定は完了です。
C)IPリソースの作成
続いて「IPリソース」を作成します。
緑色の「＋」マークの「Create Resource Hierarchy」をクリックしてウイザードを開始します。
以降は下記の値に従いウイザードを進めて下さい。
No. | 項目 | 入力値/選択値 |
1 | Switchback Type | Intelligent |
2 | Server | ip-10-0-2-4.ap-northeast-1.compute.internal |
3 | IP Resource | 10.1.0.10 |
4 | Netmask | 255.255.255.0 |
5 | Network Interface | eth0 |
6 | IP Resource Tag | IP-10.1.0.10 |
各パラメータの意味については下記をご参考下さい。
→[オンラインマニュアル：IP リソース階層の作成] ※v9.2当時のものになります。
IPリソースの処理概要については下記をご参照下さい。
LifeKeeperユーザーポータル [Linux] IP Recovery Kit の処理概要(v7.4.0-)
なお、上記のウイザードの途中で[IP Resource]の項目設定があります。
ここでは仮想IPアドレスを設定します。今回は既に前回サブネットA2（10.0.2.0/24）およびサブネットC2（10.0.4.0/24）向けに作成したルートテーブルで定義したダミーの接続先（10.1.0.10）を指定します。
「End of successful Create of…」と表示されれば成功です。[Next]をクリックして次に進みます。
ここからはこれまで設定した値を相手側のNode2（10.0.4.4）に拡張（extend）する手順になります。
以降は下記の値に従いウイザードを進めて下さい。
No. | 項目 | 入力値/選択値 |
1 | Target Server | ip-10-0-4-4.ap-northeast-1.compute.internal |
2 | Switchback Type | Intelligent |
3 | Template Priority | 1 |
4 | Target Priority | 10 |
Pre-Extend が開始されます。「Pre Extend checks were successful」と表示されれば成功です。[Next]をクリックして次に進みます。
続いて「Extend comm/ip Resource Hierarchy」ウィンドウが表示されます。
以降は下記の値に従いウイザードを進めて下さい。
No. | 項目 | 入力値/選択値 |
1 | IP Resource | 10.1.0.10 |
2 | Netmask | 255.255.255.0 |
3 | Network Interface | eth0 |
4 | IP Resource Tag | IP-10.1.0.10 |
[Extend]をクリックするとextendが開始されます。
Extend が開始されます。「Hierarchy successful extended」と表示されれば成功です。[Finish]をクリックします。
[Done]で完了させます。
IPリソースが出来ました。
簡単にスイッチバック（手動切替）のテストをしてみましょう。
右側のスタンバイノードのリソースの上で右クリックメニューの[In Service]をクリックすると、スイッチオーバーします。
下記のように「Active（稼動系）」「Standby（待機系）」が切り替わります。
D)AWS ECCリソース（EC2™リソース）の作成
続いてAWS ECCリソースの作成を行いますが、その前に必要な準備を説明致します。
まず踏み台のWindowsサーバーからpuTTYでクラスターノードにログインします。この作業はNode1およびNode2の両方で必要です。
まずec2-userからrootにスイッチします。
[ec2-user@ip-10-0-2-4 lib]$ sudo su – |
AWS ECCリソースでは、ルートテーブルの書き換えをEC2のAPIツールをkickして行います。
そこでNode1（10.0.2.4）およびNode2（10.0.4.4）に対してEC2 の API ツールをダウンロードします。
root@ip-10-0-2-4 ~]# curl -o /root/ec2-api-tools.zip http://s3.amazonaws.com/ec2-downloads/ec2-api-tools.zip |
ダウンロードしたAPIツールを解凍します。
但し環境にはunzipがインストールされていないはずなので、下記のコマンドでunzipをインストールします。
[root@ip-10-0-2-4 ~]# yum install unzip |
続いてec2-api-tools.zipをunzipで解凍します。
[root@ip-10-0-2-4 ~]# unzip ec2-api-tools.zip |
unzipの展開先は/ ec2-api-tools-1.7.5.1/になっているので、これを/opt/aws/にリネームします。
[root@ip-10-0-2-4 ~]# mv ec2-api-tools-1.7.5.1/ /opt/aws/ |
このパスの情報を/.bash_profileにEC2_HOMEとして追記して反映します。この定義内容は、後のAWS ECCリソースの作成時に使われます。
[root@ip-10-0-2-4 aws]# echo “export EC2_HOME=”/opt/aws”” >>~/.bash_profile |
続いてJavaをインストールします。（LifeKeeper同梱のものとは別のJavaです。）
[root@ip-10-0-2-4 aws]# yum install java-1.8.0-openjdk |
これらは/usr/lib/jvm/にインストールされます。（jvmディレクトリが作成される）
jvmディレクトリは下記の構成となります。
この後、今はまだ無いJAVA_HOMEにここでインストールしたjreのpathを登録します。
[root@ip-10-0-2-4 jre]# echo $JAVA_HOME |
JAVA_HOMEにjreのpathを登録します。
※「Openjdk-1.8.0」以降のpathの文字列は変わっている可能性があります。
[root@ip-10-0-2-4 jre]# export JAVA_HOME=”/usr/lib/jvm/jre-1.8.0-openjdk-1.8.0.161-0.b14.el7_4.x86_64″ |
ここまでの手順を両クラスターノード（Node1およびNode2）に対して行います。
なお、AWS ECCリソースの作成ではAWSアクセスキーが必要になります。
そこでAPI Toolsに設定する「AWSアクセスキー」と「AWS秘密鍵」を取得する為に「IAM User」を作成します。
下記のようにWebブラウザ上でIAMのマネジメントコンソールで作成します。
https://console.aws.amazon.com/iam/home?#security_credential
にアクセス。
ナビゲーションペインで[ユーザー]を選択し、[ユーザーを追加]をクリック。
ユーザ名は「lifekeeper」として、[アクセスの種類]は「プログラムによるアクセス」を選択します。
[既存のポリシーを直接アタッチ]を選択します。
その既存のポリシーは[AmazonEC2FullAccess]を選択します。
[ユーザーの作成]ボタンをクリック
忘れずに[.csvのダウンロード]をクリックしてダウンロードして下さい。このファイルの中に「AWSアクセスキー」と「AWS秘密鍵」が記載されています。次のステップでコピペして使います。
最後に再びpuTTYのコンソールに戻って、上記で入手したAWSアクセスキーIDとシークレットアクセスキーを下記のように環境変数に設定（先程ダウンロードしたcsvファイルからコピペ）します。
[root@ip-10-0-2-4 jre]# export AWS_ACCESS_KEY=”（AWSアクセスキーID）” |
ここまでの設定内容を以下のコマンドにて反映します。
[root@ip-10-0-2-4 jre]# source ~/.bash_profile |
下記のコマンドでリージョンが表示されることを確認します。
[root@ip-10-0-2-4 ~]# /opt/aws/bin/ec2-describe-regions |
ここまでのコマンドラインの手順を両クラスターノード（Node1およびNode2）に対して行います。
いよいよ次はAWS ECCリソースを作成します。
GUI管理画面で[Create Resource Hierarchy]をクリックしてリソース作成を開始します。
ウイザードが開始するとプルダウンメニューでRecovery Kitに[Amazon EC2]を選択して[Next]をクリックします。
以降は下記の値に従いウイザードを進めて下さい。
No. | 項目 | 入力値/選択値 | 備考 |
1 | Switchback Type | Intelligent |
|
2 | Server | ip-10-0-2-4.ap-northeast1.compute.internal |
|
3 | EC2 Home | /opt/aws |
|
4 | EC2 URL | ec2.ap-northeast-1.amazonaws.com | 東京リージョン |
5 | AWS Access Key | アクセスキー | 先程作成したもの |
6 | AWS Security Key | シークレットアクセスキー | 先程作成したもの |
7 | EC2 Resource type | Route Table(Backend Cluster) |
|
8 | IP Resource | IP-10.1.0.10 |
|
9 | EC2 Resource Tag | ec2-10.1.0.10 |
|
EC2 Resource Tagまで設定すると最後に[Create]ボタンをクリックするとリソース作成が開始します。
「End of successful Create of…」と表示されれば成功です。[Next]をクリックして進めてください。
続いてPre-Extendに進みます。
以降は下記の値に従いウイザードを進めて下さい。
No. | 項目 | 入力値/選択値 |
1 | Target Server | ip-10-0-4-4.ap-northeast1.compute.internal |
2 | Switchback Type | Intelligent |
3 | Template Priority | 1 |
4 | Target Priority | 10 |
「Pre Extend checks were successful」と表示されれば成功です。[Next]をクリックして進めてください。
「Extend comm/ec2 Resource Hierarchy」ウィンドウが表示されます。
[ec2 Resource Tag]が「ec2-10.1.0.10」になっていることを確認したら[Next]をクリックします。
「Hierarchy successful extended」と表示されれば成功です。[Finish]をクリックします。
[Done]で完了させます。
リソースツリーが下記のようになっていることを確認します。
以上でAWS ECCリソースの設定を完了です。
E)DataKeeperリソースの作成
オンプレ環境と異なり、AWS上では共有ストレージが使えません。
そこでLifeKeeperによるHAクラスター構成では、DataKeeperのレプリケーション領域を共有ストレージとしてLifeKeeperが認識して使うことで、AWS環境でもオンプレ環境と同様のHAクラスター構成を実現しています。
ここではそのDataKeeperのリソースを作成します。
その前に、DataKeeperで使用するディスクの設定をコマンドラインで行います。
インスタンス作成時に追加したDB用のEBSボリュームに対して、パーティション設定を行います。Node1とNode2の両方に実行して下さい。
踏み台のWindowsサーバーからpuTTYでNode1にrootでログインします。
[ec2-user@ip-10-0-2-4 dev]$ sudo su – |
DB用のマウントポイントは「u01」としました。
Node1（10.0.2.4）とNode2（10.0.4.4）の両ノードで/u01ディレクトリを作成します。
※両ノードで必要※
[root@ip-10-0-2-4 ~]# mkdir /u01 |
lsblkコマンドで利用可能なブロックデバイスの一覧を表示します。
インスタンスの作成の際に拡張した8GBのEBSは「xvdb」として認識されています。
※両ノードで必要※
[root@ip-10-0-2-4 ~]# lsblk |
このEBS「xvdb」に対してfdiskコマンドでパーティションを設定します。
※両ノードで必要※
[root@ip-10-0-2-4 ~]# fdisk /dev/xvdb |
fdiskの結果を確認します。
[root@ip-10-0-2-4 ~]# fdisk -l /dev/xvdb |
上記のxvdb1をフォーマットします。
※両ノードで必要※
[root@ip-10-0-2-4 ~]# mkfs -t xfs /dev/xvdb1 |
※Node1のみ※フォーマットした領域を、マウントポイントの/u01にマウントします。
[root@ip-10-0-2-4 ~]# mount /dev/xvdb1 /u01 |
マウント後改めてlsblkコマンドで確認してみると、xvdb1が/u01にマウントされていることが確認できます。
[root@ip-10-0-2-4 ~]# lsblk |
CLIの作業は以上です。
GUI管理画面で[Create Resource Hierarchy]をクリックしてリソース作成を開始します。
ウイザードが開始します。プルダウンメニュで Recovery Kit に[Data Replication]を選択して[Next]をクリックします。
以降は下記の値に従いウイザードを進めて下さい。
No. | 項目 | 入力値/選択値 | 備考 |
1 | Switchback Type | Intelligent |
|
2 | Server | ip-10-0-2-4.ap-northeast1.compute.internal |
|
3 | Hierarchy Type | Replication Exiting Filesystem |
|
4 | Existing Mount Point | /u01 |
|
5 | DataReplication Resource Tag | datarep-u01 | デフォルト値 |
6 | File System Resource Tag | /u01 | デフォルト値 |
7 | BitmapFile | /opt/LifeKeeper/bitmap__u01 | デフォルト値 |
8 | Enable Asynchronous Replication | No
| デフォルト値 |
4.の後に下記の確認画面が出たら[continue]をクリックして進めます。
「End of successful Create of…」と表示されれば成功です。[Next]をクリックして進めてください。
続いてPre-Extendの設定を行います。
以降は下記の値に従いウイザードを進めて下さい。
No. | 項目 | 入力値/選択値 |
1 | Target Server | ip-10-0-4-4.ap-northeast1.compute.internal |
2 | Switchback Type | Intelligent |
3 | Template Priority | 1 |
4 | Target Priority | 10 |
「Pre Extend checks were successful」と表示されれば成功です。[Next]をクリックして進めてください。
/dev/xvdb1を選択します。
以降は下記の値に従いウイザードを進めて下さい。
No. | 項目 | 入力値/選択値 | 備考 |
1 | Target Disk | /dev/xvdc1 |
|
2 | DataReplication Resource Tag | datarep-u01 | デフォルト値 |
3 | BitmapFile | /opt/LifeKeeper/bitmap__u01 | デフォルト値 |
4 | Replication Path | 10.0.2.4/10.0.4.4 |
|
5 | Mount Point | /u01 |
|
6 | Root Tag | /u01 |
|
「Hierarchy successful extended」と表示されれば成功です。[Finish]をクリックします。
[Done]で完了させます。
リソースツリーは下記のようになります。
現在はリソースツリーのルートが分かれているので、それぞれ別個にスイッチオーバーすることを確認します。
ついでにルートテーブルの内容がLifeKeeper側の切り替えでどのように変わるのかを見てみましょう。
Recovery Kit for EC2™のルートテーブルシナリオの考え方や動きについては、「ルートテーブルシナリオ」によるEC2のHAクラスター構成の記事をご参照下さい。
サービスをクリックし、右側のペインからVPCを選択します。
VPCダッシュボードから「ルートテーブル」を選択します。
表示される作成済みのルートテーブルの一覧からRT-yattemiyo-A2またはRT-yattemiyo-C2を選択します。
◇切り替え前＝Node1がActive
サブネットA2と紐付いているルートテーブルRT-yattemiyo-A2の内容
サブネットC2と紐付いているルートテーブルRT-yattemiyo-C2の内容
ダミーの仮想IPアドレスである10.1.0.10が指しているENIのIDに着目して下さい。上記のいずれのルートテーブルにおいても、10.1.0.10/32が指している先は同じNode1のENIのID（eni-b8255584）が表示されています。
それではここでAWS ECCリソースがある方のリソースツリーを手動で切り替えます（＝スイッチオーバー）。
◇切り替え後＝Node2がActive
サブネットA2と紐付いているルートテーブルRT-yattemiyo-A2の内容
サブネットC2と紐付いているルートテーブルRT-yattemiyo-C2の内容
ダミーの仮想IPアドレスである10.1.0.10が指しているENIのIDに着目して下さい。上記のいずれのルートテーブルにおいても、10.1.0.10/32が指している先は同じNode2のENIのID（eni-a6a6a8a9）が表示されています。このことからまさにルートブルシナリオ通りにAWSのルートテーブルがLifeKeeperの切り替えによって制御されていることが確認できます。
以上でAWS ECCリソースの設定は完了です。
以上で基本的なHAクラスターの構成の設定は完了です。
次回は具体的なソフトウェアとして、PostgreSQLを専用のリカバリキットのPotgreSQL ARKを使って保護（監視や切り替え）する手順についてご紹介します。お楽しみに。
ご案内
Linux版のLifeKeeperおよびDataKeeperのマニュアルは下記をご参照下さい。
→[オンラインマニュアル]
一般公開されている技術情報は下記をご参照下さい。各リカバリキットの処理概要もこちらです。
→[ユーザーサイト]
AWS関連情報
LifeKeeperやDataKeeperによるAmazon EC2上でのクラスター構成についてご紹介しています。
お問い合わせ先
「もっと詳しい話を聞いてみたい。」「自分の持っている案件は対応できそうか？」といった場合は、下記までお気軽にお問い合わせください。
ご評価版は下記からお申し込みいただけます。30日間無償でご検証いただけます。
※評価版のご使用にあたっては、十分に規約をご確認の上ご活用願います。
評価中の技術的なお問合わせは評価サポートにて承っております。
当記事の内容は全て公開日時点での当社独自見解となりますので、製品選定時のご参考に用途を限定し、二次配布や資料の改変はご遠慮願います。 内容を参考にされた結果生じたいかなる損害も当社は責任を負いませんので、事前に十分な動作検証をお願いします。 |
