こんにちは。サイオステクノロジーでプリセールスを担当している高田です。
今回は、弊社HAクラスタソフト「LifeKeeper」を利用してvsftpdの冗長化を試していきます。簡単にLifeKeeperでvsftpdを保護するためにQSP(Quick Service Protection)を利用する方法について説明します。複数のアプリケーションを保護する時の、リソースの依存関係などのポイントについても簡単にご紹介します。
LifeKeeperでアプリケーションを冗長化する方法は以下の3つです。
- アプリケーションリカバリキットを利用する
- GenericARKを利用する
- QSP(Quick Service Protection)を利用する
それぞれの方法にはメリット/デメリットがありますので、そのアプリケーションに適切な方法を選択することをお勧めします。
簡単に利用シーンに分けると以下のようになると思います。
・アプリケーションリカバリキット(ARK)
ARKがあるアプリケーションを利用する場合は、SIOSが提供するアプリケーションの制御の仕組みがあるARKの利用がお勧め。
・GenericARK
細かい制御が必要でスクリプト作成に問題がない場合は、細かい部分まで制御可能なGenericARKでの実装がお勧め。
・QSP
クラスタで制御したいがスクリプト作成が難しい場合やサービスレベルの制御でよいアプリケーションの場合は、スクリプトの作成は不要なためQSPの利用がお勧め。
今回LifeKeeperで保護するアプリケーションは「vsftpd」です。vsftpd用のアプリケーションリカバリキットはないので、GenericARKかQSPを利用します。複雑なスクリプトなしで保護していきたいので、QSPを利用します。
クライアントから仮想IPアドレス(VIP)を利用して稼働系ノードのvsftpdへ接続します。フェイルオーバーしても同じVIPを利用して接続することが可能です。
vsftpdで公開するディレクトリはDataKeeperを利用してミラーリングします。フェイルオーバーしても同じデータ(ディレクトリ)が利用可能です。
※LifeKeeper(DataKeeper含む)のインストールやIPリソースおよびDataKeeperリソースの作成は予め実施しておきます。
vsftpdのインストールをしています。
※vsftpdのインストールや設定は両ノードで実施します。
# yum -y install vsftpd
接続用のユーザーを作成します。
# useradd ftpuser
vsftpdの設定ファイルを編集します。
# vi /etc/vsftpd/vsftpd.conf
以下の設定(vsftpd.conf)を変更します。
# 匿名ユーザーによるログインを拒否します。
anonymous_enable=NO
# 作成したユーザーの設定ファイルを格納するディレクトリパスを指定します。
user_config_dir=/etc/vsftpd/conf
ユーザーの設定ファイルを編集します。
# vi /etc/vsftpd/conf/ftpuser
以下の設定を入力します。
※ここで指定するディレクトリはDataKeeperリソースで保護する共有領域を指定します。それにより、サーバーが切り替わっても同じデータ(ディレクトリ)にアクセスすることが可能になります。
# ユーザの初期ディレクトリを指定します。
local_root=/ftpdata
稼働系のサーバーでvsftpdを再起動します。
※サーバー起動時の自動起動は有効化しません。LifeKeeperのリソースで起動停止を制御するため、自動起動は無効にしておく必要があります。
# systemctl restart vsftpd
待機系のサーバーでvsftpdを停止します。
# systemctl stop vsftpd
vsftpdの設定が完了したらLifeKeeperのGUI画面からリソースを作成していきます。使用するリカバリキット(QSP)と保護するサービス(vsftpd)を指定する項目以外はデフォルトの設定で進めることができます。
利用するリカバリキットは「Quick Service Protection」を選択します。
スイッチバックタイプはデフォルトで進めます。
サーバーは、vsftpdが起動している稼働系のサーバーを指定します。
保護するサービス(vsftpd)を指定します。
サービスの監視(quickCheck)を行うかを指定します。監視する場合は「enable」を指定します。
リソースの名前を入力します。デフォルトの名前で問題なければそのまま次に進みます。
稼働系のサーバーでリソースが作成されました。
リソースの拡張を行う待機系のサーバーを指定します。
スイッチバックタイプはデフォルトで進めます。
稼働系サーバー側のリソースのプライオリティを指定します。デフォルトのまま進みます。
待機系サーバー側のリソースのプライオリティを指定します。デフォルトのまま進みます。
待機系のサーバー側のチェックが完了しました。進めます。
リソースの名前を確認します。そのまま次に進みます。
リソースの作成が完了しました。更に拡張するサーバーはないので、「Finish」でリソースの作成を完了します。
リソースの作成画面を閉じます。
このようにリソースが作成されました。スクリプトを作成せずに任意のアプリケーションを簡単に保護することが出来ました。
※DataKeeperリソース(/ftpdataとdatarep-ftpdata)とIPリソースは事前に作成しています。
ただし、この状態ではリソースの障害時に他のリソースは切り替わりません。vsftpが起動する時に同じサーバーで/ftpdataディレクトリが参照出来る必要がありますので、それぞれのリソースは依存している事になります。また常に稼働系のサーバーには同じIPアドレスでアクセスしたいので、IPリソースも依存しています。
LifeKeeper側で依存関係を作成して一緒に切り替えるようにします。ここでは手順までは紹介しませんが、GUI画面から簡単に依存関係を作成することが可能です。依存関係を作成する時は、以下URLで説明しているリソース起動・停止順序を考慮して作成してください。
[Linux]リソースの起動・停止順序と依存関係について
https://lkdkuserportal.sios.jp/hc/ja/articles/900003290466
今回の構成では、先にDataKeeperリソースが起動している必要があるので、一番下にDataKeeperリソースが配置されるように設定します。IPリソースとvsftpdリソースはどちらが先に上がっても影響はないと思います。
依存関係を作成して以下のような階層にします。
ここまでの内容はvsftpdだけを保護するケースですが、アプリケーションリカバリキット(ARK)が存在するアプリケーションと同時にQSPを利用するケースもあるかと思います。
注意点としては、IPリソースやファイルシステムリソース等のリソースを共有したり、アプリケーション同士の依存関係がある場合のリソースの階層に注意していただければ問題ないと思います。
以下はOracleDBとvsftpdを同じ仮想IPアドレスでアクセスする例です。ボリュームは分けています。最終的には以下のような構成にしています。
全て1つのリソース階層に含まれていますので、いずれかのリソースで障害が発生しても全てのリソースが待機系ノードへ切り替わる構成です。
構成のポイントとしては、Oracleリソースの下位リソースにvsftpd関連のリソース(Oracleリソースでも利用しているIPリソースは除く)が存在しない事です。今回vsftpdリソースの起動が失敗してもOracleリソースの起動は行えるようにしたいと思います。
最上位のリソース(QSP-vsftpd)からみるとvsftpdで利用しているDataKeeper(/ftpdataとdatarep-ftpdata)リソースとOracle(orcl)関連リソースが子リソースとして存在しています。
上記URLでも紹介したようにリソース階層は下から上の順番でリソースの起動を行います。子リソース同士は依存関係がありませんので、お互いの起動に影響しません。また、QSP-vsftpdリソースがOracleリソースより上位のリソースとして存在することでvsftpdの起動が失敗するような場合でもOracleリソースを起動することが可能です。
<パターン1>
<パターン2>
QSPを使ってvsftpdをLifeKeeperで保護する方法について説明してきました。スクリプトなしで簡単にクラスターに組み込むことが出来るのは嬉しいですね。冒頭にも説明した通り、アプリケーションや目的に応じてLifeKeeperの機能(「アプリケーションリカバリキット」「GenercARK」「QSP」)を選択いただければと思います。
LifeKepeeperのお問い合わせや案件のご相談は以下からご連絡ください。