みなさん、こんにちは。SCSK株式会社の津田です。
LifeKeeperではサービスをリソース化してHAクラスタの保護対象とする際、どのオプション製品を使うか？
というのはLifeKeeperの設計フェーズでのポイントの一つになるかと思います。
今回はQuick Service Protection(以下QSP)についてご紹介します！
オプション製品についておさらい
はじめに、第２回 「LifeKeeper」で可用性を高められるミドルウェアはこれだ！でも少しお伝えしている
オプション製品についておさらいとなります。
LifeKeeperではサービスをHAクラスタの保護対象とする際、ARKというスクリプト集で起動・停止・監視・回復を制御します。
サイオステクノロジー社により様々なサービスに沿った専用のARKが用意されてはいますが、
もし保護対象にしたいサービスの専用ARKがない場合は、以下の選択肢があります。
選択肢➀ Generic ARK
選択肢➁ QSP
有償オプションの専用ARKとは異なり、上記選択肢はどちらも無償オプションとなります。
「Generic ARK」を利用する場合の特徴として、アプリケーションの起動・停止・監視・回復(任意)を制御するスクリプトの作成が必要となります。
サイオステクノロジー社よりベースとなるスクリプトは提供されているものの、スクリプトを準備することはGenericARKを利用する上でのハードルとなるケースがあります。
対する「QSP」を利用する場合の特徴として、OSの機能(init,systemdやWindowsサービス)で起動・停止・監視・回復を行います。
そのためスクリプトの作成は不要で簡単にLinux、Windows上の一般的なサービスをLifeKeeperの保護対象とすることができるんです！
QSPメリット・デメリット
以下QSPの主なメリット・デメリットをあげていきます。
QSP検討の際の参考となれば幸いです。
・スクリプトの準備が不要
GenericARKのようなスクリプトの事前準備は不要となります。
・設計・構築スケジュール短縮が見込める
スクリプトの準備不要でGUIより簡単にQSPのリソースを構築することができます。
・導入コストを抑えられる
設計・構築スケジュール短縮に加え、QSPは無償オプションとなりますのでコストを抑えることができます。
・サービスがinit、systemd、Windowsサービスに対応していない場合は利用できない
(※init,systemd、Windowsサービスに対応していてもQSPが利用できない場合があります。注意点として後述します。)
・専用ARKが用意されているサービスに対しては利用できない
・OSの機能による簡単な監視処理しかできない
監視処理はOS機能によるステータスでの判断となるため、細かな監視は行えません。
※監視内容を細かく設定したい場合は、Generic ARKの利用が適しています。
QSP利用前の注意点
前述の「QSPメリット・デメリット」でも少し記載しましたが、
一部のサービスについては、init、systemd、Windowsサービスに対応していてもQSPが利用できない場合もありますので注意が必要です。
QSPで保護対象としたいサービスがある場合は、一度以下で確認されることをおすすめします。
▼サイオステクノロジー社公開のHA化で実績のある対応ソフトウェア一覧です。
https://bccs.sios.jp/lifekeeper/sw.html
※「ARK以外の保護方法」欄にQSPの記載があるものはLifeKeeperでのリソース化実績があるものになります。
QSPの記載はないが最新の実績状況を知りたい、この表にないソフトウェアのサービスを保護したいという場合は、
サイオステクノロジー社またはSCSKにお気軽にお問合せください。
▼サイオステクノロジー社公開のLinuxのQSPの保護対象外サービスの一覧です。
https://lkdkuserportal.sios.jp/hc/ja/articles/900000555366
まとめ
今回はQSPについてご紹介いたしました。
以下に該当する場合はQSPでのサービス保護をぜひご検討頂ければと思います！
・スクリプト作成の手間を省きたい
・監視はサービスの起動・停止確認だけでよい
