インフラ部分の可用性については一定の担保を提供するクラウド環境ですが、その上で動作しているアプリケーションの可用性は利用者に任されているのが現状です。
LifeKeeper for Linux（以降は、LifeKeeperと記載）はクラウド環境において担保外となっているアプリケーションの可用性を実現させるソフトウェアとなります。今回はLifeKeeperをAWSの無料枠を使用してEC2上に導入してみます。
AWSの無料枠
AWSの幾つかのサービス（EC2やS3、RDS等）は、新規の利用者に対して初回ログインから利用できる無料枠を提供しています。期間は12ヶ月となっていますが、無料枠自体は月単位の時間制（750時間）となっており、12ヶ月未満でも月間の無料枠を超えてしてしまうと、以降は従量課金となりますので注意してください。
詳細はAWSのページをご確認ください。
| https://aws.amazon.com/jp/free/ |
環境設定
環境設定は以下となります。
| 項目 | 設定内容 |
| リージョン | Tokyo |
| AvailabilityZone | ap-northeast-1a |
| インスタンスタイプ | t2.micro |
| AMI | Red Hat Enterprise Linux 7.3 (HVM), SSD Volume Type |
| インスタンス数 | 2つ |
| プライベートIP | プライマリ / セカンダリ |
| Elastic IP | 1つ |
| ディスクストレージ | プライマリボリューム / データ共有用ボリューム |
| LifeKeeper | LifeKeeper for Linux v9.1.1 |
| データ共有方式 | LifeKeeperのData Replication機能を利用 |
| ※無料枠内での環境となるため最小構成となります。実際にサービスを稼動させる場合は、サービス内容にあった構成を検討してください。 |
構成イメージ
環境イメージは以下となります。
Clustering subnet A/Bで起動した各インスタンスに導入したLifeKeeperのData Replication機能を使用して、各インスタンスの追加ボリュームを共有ファイルシステム化し任意のマウントポイント（今回は”/data”）へマウントします。
フェールオーバー時の挙動は、セカンダリ側がプライマリへ昇格し、共有ファイルシステム化しているボリュームを、プライマリ側と同じマウントポイントへマウントします。
導入の流れ
以下の流れで導入を行います。
■インフラを構築してみた
AWS上にインフラ環境を構築してみました。
■クライアントの準備をしてみた
インスタンスへアクセスするためのクライアント側の準備をしてみました。
■導入の準備をしてみた
インスタンスにてLifeKeeperの導入準備をしてみました。
■導入してみた
LifeKeeperを導入してみました。
■操作してみた
LifeKeeperの設定を行ってみました。
■検証してみた
擬似的に障害を発生させ、フェールオーバーを確認してみました。
インフラを構築してみた
まずは、AWSにてインフラ環境を構築します。
WebUIで直感的に操作できることから、ポイントとなる箇所をピックアップして記載します。
- リージョンを選択
AWS Management Consoleにサインインして、右上メニューからアジアパシフィック（東京）を選択します。
- VPCの作成
ネームタグは任意の名前で問題ありません。IPv4 CIDR blockは最大”/16”まで設定できますので、今回は最大で設定します。他の項目はそのままで作成します。 - インターネットゲートウェイの作成
ネームタグは任意の名前で問題ありません - インターネットゲートウェイのアタッチ
作成したインターネットゲートウェイを作成したVPCにアタッチします。 - サブネット（Clustering subnet A）の作成
ネームタグは任意の名前で問題ありません。VPCは作成したVPCを選択します。
アベイラビリティゾーンはap-northeast-1aを選択します。
IPv4 CIDR blockはVPCに設定したサブネットマスクの範囲内となります。今回は”/24”で設定します。 - サブネット（Clustering subnet B）の作成
Clustering subnet Aと同じ方法で、IPv4 CIDR blockを変更します。こちらもサブネットマスクは”/24”で設定します。 - ルートテーブルの作成
ネームタグは任意の名前で問題ありません。VPCは作成したVPCを選択します。 - ルーティングの設定
ルートテーブルへ作成したインターネットゲートウェイに対するルーティングを設定します。 - ルートテーブルへサブネットの関連付け
作成したサブネットを関連付けます。 - セキュリティグループの作成
ネームタグ、グループ名、説明は全て任意の名前や文言で問題ありません。
※ここでは2バイト文字（日本語等）は使用できないため、注意してください。
- インバウンドルールの設定
タイプを全てのトラフィックとし、送信元にはアクセス元となるグローバルIPを設定します。また、ルールを一つ追加し、タイプを全てのトラフィックとして、送信元に自身のセキュリティグループを設定します。
- アウトバウンドルールの設定
そのままで問題ありません。 - インスタンスの作成クラスタリング用インスタンスを二つ作成します。
（1） AMIは「Red Hat Enterprise Linux 7.3 (HVM), SSD Volume Type」を選択します。
（2） インスタンスタイプは「t2.micro」を選択します。
（3） インスタンスの詳細にて、ネットワークには作成したVPCを選択し、サブネットはインスタンス毎にそれぞれClustering subnet A、Clustering subnet Bを設定します。
更に、ネットワークインターフェースの項目で、セカンダリIPアドレスを追加します。
（4） 新しいボリュームを追加します。今回は”8G”を選択します。
（5） アクセス用キーペアを新規作成します。
新しいキーペアの作成を選択後、キーペア名に任意の名前を入力しダウンロードします。
※一度、キーペアを作成した後は「既存のキーペアを使用する。」を選択し、作成したキーペア名を指定すれば、他インスタンスでも同じキーペアを使用できます。 - Elastic IPの設定
インターネット経由でインスタンスに接続するためのIPアドレス（Elastic IP）を関連付けます。インスタンスはアクセスしたいインスタンスを選択します。プライベートIPは、プライマリプライベートIPアドレスを選択します。
※Elastic IPは関連付けされたインスタンスが停止している場合や、関連付けされずにただ保有している状態になると、課金が発生するため注意してください。
- インスタンスへの接続
これでクライアント（ローカル端末）からインターネット経由でElastic IP宛にインスタンスへSSH接続することが可能になります。なお、今回はElastic IPは一つ（無料枠で使用できるのは一つ）しか使用しないため、各インスタンスでインターネットを使用する際はElastic IPを付け替える必要があります。
クライアントの準備をしてみた
AWSにてインフラ環境は構築しましたので、インスタンスに接続してLifeKeeperの導入を行いたいところですが、その前に接続元となるクライアント側でLifeKeeperを使用する準備が必要になります。
- ターミナルソフトの準備
今回はTeraTermを使用します。
※ソフトの取得や導入方法については、TeraTermのサイトを参照してください - Xサーバーの準備
LifeKeeperの設定はGUIで行いますが、このGUIはX Window Systemを使用しているため、クライアント側にもWindows用Xサーバーが必要になります。今回はXmingを使用します。
※ソフトの取得や導入方法については、Xmingのサイトを参照してください - TeraTermの設定
ターミナルソフトにてX WindowへのSSH転送の設定を追加します。
設定＞SSH転送を選択しリモートの（X）アプリケーションをローカルのXサーバーに表示する。にチェックを入れます。
※設定を行った後は、変更内容を設定ファイルに保存するのは忘れないでください。
※この設定は使用するターミナルソフトの全てで設定が必要となるので、各ソフトのマニュアルを参照して設定を行ってください。 - インスタンスへの接続
Elastic IPアドレス宛にSSH接続を行います。ログイン情報は以下となります。IPアドレス：Elastic IP
ログインID：ec2-user
PW：インスタンス作成時に作成したキーペアを使用※Elastic IPを付け替えてインスタンスへ接続する場合、ホスト鍵が一致しない旨のメッセージが表示されますので、都度ホスト鍵を上書きするようにしてください。
導入の準備をしてみた
クライアントの準備ができましたので、作成したインスタンスへ接続しOSの設定とLifeKeeperの導入の準備を行います。ここからは主にコマンドラインでの操作となります。
※コマンドラインのプロンプトは「$」がログインユーザーとなり、「#」がrootユーザーとなります。
rootユーザーへのスイッチは”su -”で変更してください。
- タイムゾーンの変更（日本時間に変更）
# timedatectl set-timezone Asia/Tokyo - SELinuxの無効化
# cp -p /etc/selinux/config /etc/selinux/config.org
# vi /etc/selinux/config
SELINUX=enforcing
↓ ※書き換える
SELINUX=disabled - X Windowの導入
# yum -y groupinstall “x11”
# systemctl set-default graphical.target - redhat-lsbの導入
# yum -y install redhat-lsb - 名前解決の設定
自身のDNS情報と対向インスタンスの名前解決設定を追加します。
なおIPアドレスは各インスタンスのプライマリプライベートIPアドレスを設定してください。# cp -p /etc/hosts /etc/hosts.org
# vi /etc/hosts
10.10.20.*** ip-10.10.20.***.ap-northeast-1.compute.internal
10.10.30.*** ip-10.10.30.***.ap-northeast-1.compute.internal※ IPアドレス△ホスト名 の書式で記載してください。（△はスペース）
※各インスタンスのホスト名は、インスタンス作成時にAWSが自動で設定します。ホスト名の確認方法は各インスタンスにて”hostname”コマンドで確認してください。
- NICの追加
インスタンス作成時に追加したセカンダリプライベートIPアドレスは、OS側では自動で認識しないため、ファイルを作成して認識させる必要があります。# vi /etc/sysconfig/network-scripts/ifcfg-eth0:1
DEVICE=”eth0:1″
BOOTPROTO=”static”
IPADDR=”セカンダリプライベートIPアドレス”
NETMASK=”255.255.255.0″
ONBOOT=”yes”
TYPE=”Ethernet”
USERCTL=”yes”
PEERDNS=”yes”
IPV6INIT=”no” - 再起動
# reboot - X Windowの設定確認・変更
X Windowはログインしたユーザーの環境変数と認証情報、GUI画面を起動したユーザーの環境変数と認証情報がそれぞれ一致している必要があります。$ echo $DISPLAY
# echo $DISPLAY
$ xauth list
# xauth list
※ それぞれの出力結果が一致していることを確認します。※それぞれの情報が一致していない場合、以下のコマンドでログインユーザー側の情報と一致させてください。
# export DISPLAY=ログインユーザーの＄DISPLAYの出力結果
# xauth add ログインユーザーのxauth listの出力結果
また、永続的に環境変数を設定する場合は、別途ユーザーの環境変数（.bash_profile等）を編集してください。
導入してみた
インフラ環境、クライアント、OSの準備ができましたので、いよいよLifeKeeperの導入を行います。
なお、LifeKeeperはクラスタリングする全てのインスタンスへ導入する必要があります。
- LifeKeeperのイメージファイルとライセンスキーファイルのアップロード
各インスタンスのログインユーザーのホームディレクトリ”/home/ec2-user”へアップロードします。 - イメージファイルのマウント
# mount -o loop -t iso9660 /home/ec2-user/LKL_V911_011617.iso /media
# mount /media/sps_911.img -t iso9660 -o loop /mnt
# /mnt/setup※イメージファイルのマウント時に以下のメッセージが出力されますが、無視して問題ありません。
mount: /dev/loop0 is write-protected, mounting read-only - LifeKeeperの導入
Enterキーを押して、LifeKeeperのインストールを開始します。
なお、以降はウィザードに従って進めるだけで導入が完了します。
- データ共有用（DataKeeper）のモジュールの導入
Data Replication機能を使用するため、Enterキーを押下します。
- ライセンスキーの導入
後ほど実施するため、そのままEnterを押下します。
- Recovery Kitパッケージの導入
lkDRを選択し、Enterを押下します。
- 導入の完了
以下の表示が出力されれば、導入は完了です。
- ライセンスキーの登録
LifeKeeperのライセンスキーを登録します。# /opt/LifeKeeper/bin/lkkeyins /home/ec2-user/＜ライセンスーファイル名＞ - rootの環境変数への追記
LifeKeeperのコマンド等のPATHを登録します。# cp -p /root/.bash_profile /root/.bash_profile.org
# vi /root/.bash_profile
# For LifeKeeper
PATH=$PATH:/opt/LifeKeeper/bin
MANPATH=$MANTPATH:/opt/LifeKeeper/manexport PATH MANPATH
操作してみた
LifeKeeperの導入が完了しましたので、GUIを起動して各インスタンスをクラスタリングし、その後、Data Replication機能を使用して追加ボリュームを共有ファイルシステム化します。
- LifeKeeperの起動
各インスタンスにてLifeKeeperを起動します。# lkstart - LifeKeeperGUIの起動
プライマリインスタンスにてLifeKeeperGUIを起動します。# lkGUIapp ※LifeKeeperGUIを起動する時は、クライアント側でXサーバー（Xming）を起動しておいてください。
- ログイン
インスタンスのrootユーザーでログインします。
※インスタンスのrootユーザーのPWを設定していない場合、以下のコマンドでPWを設定してください。# passwd - 一つ目のコミュニケーションパスの作成
下記のボタンを押下して、コミュニケーションパスを作成します。
必要な情報は以下となります。項目 入力/選択する値 備考 Local Server プライマリインスタンスのホスト名 Remote Server セカンダリインスタンスのホスト名 Device Type TCP Local IP Address プライマリインスタンスのIPアドレス プライマリプライベートIP Remote IP Address セカンダリインスタンスのIPアドレス プライマリプライベートIP Priority 1 - 二つ目のコミュニケーションパスの作成
予備用のコミュニケーションパスを作成します。
再度、以下のボタンを押下して、予備用コミュニケーションパスを作成します。
なお、以下の情報のみ変更します。
項目 入力/選択する値 備考 Local IP Address プライマリインスタンスのIPアドレス セカンダリプライベートIP Remote IP Address セカンダリインスタンスのIPアドレス セカンダリプライベートIP Priority 1 - Data Replicationの設定
以下のボタンを押下して、Data Replication機能を使用した共有ファイルシステムを作成します。
必要な情報は以下となります。
項目 入力/選択する値 備考 Please Select Recovery Kit Data Replication Switchback Type intelligent Server プライマリインスタンスのホスト名 Hierarchy Type Replicate New Filesystem Source Disk /dev/xvdf (8G) 追加ボリューム New Mount point /data New Filesystem Type ext4 Data Replication Resource Tag datarep-data File System Resource Tag /data Bitmap File /opt/LifeKeeper/bitmap__data Enable Asynchronous Replication? no Target Server セカンダリインスタンスのホスト名 Switchback Type intelligent Template Priority 1 Target Priority 10 Mount point /data Root Tag /data Target Disk /dev/xvdf (8G) 追加ボリューム Data Replication Resource Tag datarep-data Bitmap File /opt/LifeKeeper/bitmap__data Replication Path 予備用コミュニケーションパス - クラスタリングの完了
以上まで行えば、以下の状態となります。これで共有ファイルシステムを搭載したクラスタリング環境の完成です。
検証してみた
これでAWS上にLifeKeeperの導入は完了しましたが、最後に実際に動作（フェールオーバー）するか確認してみます。しかし、今回の構成ではElastic IPが一つしかないことから、ログインしているインスタンスのNICを落としてしまうと、LifeKeeperGUIも落ちてしまいます。
そのため、セカンダリインスタンスからログインして検証をしてみます。
- Elastic IPをセカンダリインスタンスに関連付ける
まずは、「インフラ環境を構築してみた」の項番14を参照して、Elastic IPをセカンダリインスタンスに関連付けます。 - LifeKeeperGUIの起動
LifeKeeperGUIを起動します。# lkGUIapp - LifeKeeperの状態確認
LifeKeeperGUIへログインします。プライマリインスタンスにてGUIを起動していた場合と表示が逆になっているのを確認します。
- セカンダリインスタンスへキーペアをアップロード
セカンダリインスタンスへのホームディレクトリ”/home/ec2-user”へキーペアをアップロードします。 - ターミナルをもう一つ起動する。
ターミナルをもう一つ起動して、セカンダリインスタンスへログインします。 - “/data”のマウント状況を確認
”/data”がマウントされていないことを確認します。$ df –T - プライマリインスタンスへログイン
セカンダリインスタンスからプライマリインスタンスへログインします。$ ssh –i <キーペア名> ec2-user@<プライマリインスタンスのプライマリプライベートIP> - プライマリインスタンスで擬似的に障害を発生させる
プライマリインスタンスのNICを落とすことで、擬似的に障害を発生させます。プライマリインスタンスで以下のコマンドを実行します。# service network stop
※ifdownコマンドでも問題ありません。 - LifeKeeperGUIを確認してみる
プライマリインスタンスにてコマンドを実行後、暫くすると以下の表示になりました。右側で表示されていたAct表示が、左に移動しています。また、プライマリインスタンスが異常となったため、左ペインやインスタンスの画像に下記の注意マークがついています。
- “/data”のマウント状況を確認
もう一度、セカンダリインスタンスにて以下のコマンドを実行します。$ df –T
/dev/md0– – – ext4 — – – 16382844– – -45080– 15482520– – 1% /data
※上記のような表示が出力されます。
ちゃんと切り替わって、ボリュームがマウントされています。
これで正常にフェールオーバーがされていることが確認できました。
※NICを落としたプライマリインスタンスはAWS Management Console から、インスタンスの再起動処理を行えば、アクセスできるようになります。
まとめてみた
AWSでの構築はGUIとなるため直感的に操作しやすいのですが、独自の用語が多く、理解していないと次の作業に取り掛かれない場合があるかと思います。記事内では作業毎に必要なポイントを記載しておりますので、インフラ環境の構築はできるかと思いますが、用語や操作の意味などは別の機会にお調べすることをお勧めします。
なお、LifeKeeper自体は、基本的にウィザードに従えば導入できてしまうため、インフラ環境と必要な資材の準備ができれば難しいことは無いと思います。
LifeKeeperの設定について、疑問点や別の構成で導入する場合等は、豊富に用意されている公式のドキュメントをご参照ください。
次は今回作成した環境にPostgreSQLを導入し、LifeKeeperと連携させてみようと思います。
＞第2回 「AWS上のLifeKeeper for Linux とPostgreSQLを連携させてみた」を読む
AWS関連情報
LifeKeeperやDataKeeperによるAmazon EC2上でのクラスター構成についてご紹介しています。
