こんにちは。
サイオステクノロジー國政です。プリセールスを担当しています。
今回は、LifeKeeper for Linux Version 9.1(2016年8月リリース)の機能の一つであるQSP(Quick Service Protection)の具体的な使い方の一つをご紹介いたします。
QSP(Quick Service Protection)とは
LifeKeeperでアプリケーションを保護しクラスター化するには、専用のARKを使うか、汎用フレームワークのGeneric ARKを利用し、スクリプトを用意する必要があります。
QSPはいくつか条件がありますが、条件さえクリアできていればスクリプト不要でLifeKeeperで簡単にHAクラスターの構成が行えます。
QSPが利用できない条件
1. 既に専用のRecovery Kitがある 例: Oracle ARK / PostgreSQL ARK など
2. OSの動作に関連するもの 例: crond /iptabelsなど
3. LifeKeeper自身のプロセスの保護 例: lifekeeper,steeleye-runinitなど
QSPが利用できる条件
1. OSのServiceコマンドで保護したいアプリケーションの起動、停止ができ、正常時には0を返す作りである事
2. Quick Check(監視)機能を有効にする場合は、状態のリクエスト(status)に対し正常時には0を返す作りである事
QSPの利用できる/できない条件を考えながらいくつか適用シーンを考察してみると、実はそれほど敷居が高くないのが分かるかと思います。
QSPを使って、NginxをLifeKeeperで保護する
では、シナリオ3のNginxについてQSPを使ってLifeKeeperで保護してみましょう。
Nginx自体は軽量で多機能ですが、今回は単純なhtmlを扱うwebサーバー構成で試してみます。
[ システム構成：2017年2月末時点 ]
OS：CentOS 6.8 kernel-2.6.32-642.el6.x86_64
LifeKeeper：version 9.1.1(非共有ディスク構成の為DataKeeperを利用)
Nginx：Nginx/1.10.3 (コミュニティ版)
※LifeKeeperのインストール及び、Nginxのインストールは各種マニュアルをご参照ください。
[ システム構成図 ]
ホスト名：LK4L-ALK4L-B
コミュニケーションパス：192.168.50.221⇔192.168.50.222
172.16.27.221⇔172.16.27.222
クライアント接続用仮想IP 192.158.50.77
データミラー領域：/dev/sdb
マウントポイント：/mnt/mirror
Nginxは両方のホストへインストールし、Nginxで使うデータはデータミラー領域へ配置します。
[ テスト構築の流れ ]
LifeKeeper及び仮想IP(IPリソース)の設定、DataKeeperの設定は済んでいるものとし、LK4L-Aがactive、LK4L-BがStandbyとなっている事を前提とします。
1. LK4L-A サーバーでNginxをインストールします。
2. Nginx設定ファイルを編集し、/mnt/mirror/をデータの置き場所として指定します。
3. 実際に元データの/usr/share/nginx/htmlを/mnt/mirror/htmlへ置きなおし、分かりやすいよう元のhtmlファイルを編集し、test test testなど付け加え区別しておく。その際、ファイルパーミッションなども合わせて確認をしておきます。
4. LK4L-BにてNginxをインストールします。設定ファイルを編集し、LK4L-A同様 /mnt/mirrorを参照するように変更します。
5. 再びLK4L-AサーバーでQSPによる保護を行います。
Create Resource Wizard を起動し
Please Select Recovery Kitで [ Quick Service protection]を選択
次に Switchback Type で [intelligent]を選択
Server で [LK4L-A]を選択し
Service Name で [nginx]を選択
Enable or Disable monitoringで[disable]を選択
Resource Tag は表示されているままの[QSP-nginx]を選択し
Create instance で作成されます。
わずか7ステップで作成できます。
しかも必要項目は選択式でキーボードからの入力はなく、間違える事なく誰でも簡単に操作できます。
リソース作成(QSP)後、拡張作業でLK4L-Bへのリソース拡張を行います。
6. リソース階層の紐づけを行い、Nginxとミラー領域、仮想IPが連動して動作するよう階層の調整を行います。
7. これでQSPによる保護は完了です。LK4L-BのホストにてQSP-nginxをInserviceにすることで手動切替えが行えます。切り替わり前後で仮想IP(192.168.50.77)にwebブラウザでアクセスし、test test test と追記したhtmlが表示される事を確認します。
[ 簡単な障害テスト ]
QSPはスクリプトレスの簡単操作でLifeKeeperの保護対象とできますが、監視設定を有効にし、サービスが落ちた時にフェイルオーバーが発生するようにします。
QSP-nginxタグを右クリック→Change Monitoring →モニタリングを有効(Enable)となっている事を確認し、Changeを押下します。
一つ前の画面下方のChange Timeoutの項の中から quickCheckを選択し Nextを押下、
次に表示される秒数に 5を入れChangeを押下します。
これと同様の手順をLK4L-Bの方でも行います。QSPはこれらの設定を自動的に対向サーバーへ設定を拡張する事ができない為、この部分は手動設定となります。
また、監視項目は4種類ありますが、標準設定では監視されない状態となっていますので、必要に応じ適切なタイムアウト値を設定してください。
< ドキュメント参照先 >
————————————————————————————————————
http://jpdocs.us.sios.com/Linux/9.1/LK4L/TechDoc/Content/Quick_Service_Protection_Recovery_Kit.htm
————————————————————————————————————
次にテスト用にActive側(LK4L-A)のローカルリカバリーを一時的に無効にします。
これは、Nginxの障害を発生させFailoverをさせる想定動作に対し、通常設定では自ノードでの復旧動作が入り、その動作で復旧するとFailOverが発生しない為、この動作を行わず、リソース障害検出でノード切り替えが発生するようにします。
< 障害検知時の動作概要図 >
テスト時はローカルリカバリーを無効化する事により、Nginxを停止させるだけで規定の秒数経過でFailOverを発生させたい。そのためにはコマンドラインから一時的にポリシーの変更を行います。
特定のリソースのローカルリカバリーを無効化
lkpolicy -s LocalRecovery -E tag=”tagname”
※今回の場合は lkpolicy -s LocalRecovery -E tag=”QSP-nginx” となります
このポリシー変更にはrootユーザのパスワードが求められます。
特定のリソースのローカルリカバリーを有効化
lkpolicy -s LocalRecovery -e tag=”tagname”
[ 参考資料 ] LifeKeeper for Linux コマンド一覧
——————————————–
http://lk.sios.com/?p=4084
———————————————
[ 障害試験 ]
LK4L-Aサーバー上のNginxを停止させます。
結果: 暫くすると、Nginxの異常を検知し、LK4L-Bへ切り替わりが発生します。
切り替わった後で、仮想IP(192.168.50.77)ヘアクセスでき、正しいコンテンツを返している事を確認します。
これにて、QSPによるクラスター化作業は完了です。
実運用に入る前に、監視のタイミングや、タイムアウト値など適切な値を決めて頂ければと思います。
また、タイムアウト以外の条件付けを行いたい場合などは、従来通りの汎用フレームワークのGeneric ARKでスクリプトを準備頂く手法もございます。
いかがでしたでしょうか。
今回記載したNginx以外にもserviceコマンドに対応しているOSSアプリケーションなどもQSPで保護できる場合があります。少しでもHAクラスター導入の敷居が下がる事を実感頂ける内容ではないかと思います。
