[Linux]QSP(Quick Service Protection)を使って簡単にNginxをクラスター化してみる

    LifeKeeperでアプリケーションを保護しクラスター化する方法3つ

    こんにちは。
    サイオステクノロジー國政です。プリセールスを担当しています。

    今回は、LifeKeeper for Linux Version 9.1(2016年8月リリース)の機能の一つであるQSP(Quick Service Protection)の具体的な使い方の一つをご紹介いたします。

     QSP(Quick Service Protection)とは

    LifeKeeperでアプリケーションを保護しクラスター化するには、専用のARKを使うか、汎用フレームワークのGeneric ARKを利用し、スクリプトを用意する必要があります。
    QSPはいくつか条件がありますが、条件さえクリアできていればスクリプト不要でLifeKeeperで簡単にHAクラスターの構成が行えます。

     LifeKeeperでアプリケーションを保護しクラスター化する方法3つ

    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の利用できる/できない条件を考えながらいくつか適用シーンを考察してみると、実はそれほど敷居が高くないのが分かるかと思います。

    Quick-Service-Protection利用シナリオ

    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/をデータの置き場所として指定します。

    Nginx設定ファイルを編集しデータの置き場所を指定

    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ステップで作成できます。
    しかも必要項目は選択式でキーボードからの入力はなく、間違える事なく誰でも簡単に操作できます。

    create-resouce

     

    リソース作成(QSP)後、拡張作業でLK4L-Bへのリソース拡張を行います。

    リソース作成(QSP)後、拡張作業

     

    6. リソース階層の紐づけを行い、Nginxとミラー領域、仮想IPが連動して動作するよう階層の調整を行います。

    リソース階層の紐づけ

    7. これでQSPによる保護は完了です。LK4L-BのホストにてQSP-nginxをInserviceにすることで手動切替えが行えます。切り替わり前後で仮想IP(192.168.50.77)にwebブラウザでアクセスし、test test test と追記したhtmlが表示される事を確認します。

    html確認

    [ 簡単な障害テスト ]
    QSPはスクリプトレスの簡単操作でLifeKeeperの保護対象とできますが、監視設定を有効にし、サービスが落ちた時にフェイルオーバーが発生するようにします。

    QSP-nginxタグを右クリック→Change Monitoring →モニタリングを有効(Enable)となっている事を確認し、Changeを押下します。

    Change Monitoring

    一つ前の画面下方のChange Timeoutの項の中から quickCheckを選択し Nextを押下、

    Change-Timeout

     

    次に表示される秒数に 5を入れChangeを押下します。

    chage-second

     

    これと同様の手順を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)ヘアクセスでき、正しいコンテンツを返している事を確認します。

    仮想IPでコンテンツ確認

    これにて、QSPによるクラスター化作業は完了です。
    実運用に入る前に、監視のタイミングや、タイムアウト値など適切な値を決めて頂ければと思います。
    また、タイムアウト以外の条件付けを行いたい場合などは、従来通りの汎用フレームワークのGeneric ARKでスクリプトを準備頂く手法もございます。

    いかがでしたでしょうか。
    今回記載したNginx以外にもserviceコマンドに対応しているOSSアプリケーションなどもQSPで保護できる場合があります。少しでもHAクラスター導入の敷居が下がる事を実感頂ける内容ではないかと思います。