こんにちは、SCSKの前田です。
4回目は、LifeKeeperの内部で使われている用語について説明したいと思います。
1回目・2回目・3回目の用語説明に関しては以下のリンクからどうぞ！
リソースの作成とは？
LifeKeeperによるリソースの作成とは、高可用性にしたいサービスやアプリケーションを LifeKeeper が監視、管理できるよう稼働系ノードに定義することを言います。
リソースを作成するためには、サービスやアプリケーションに対応した ARK や、必要に応じて起動・停止・監視・再起動を行うためのスクリプトが必要になります。
また、リソースの作成には、LifeKeeper の GUI または ターミナルによる CLI のどちらも使用することが出来きますが、視覚的に確認しながら作業が行える GUI でのリソース作成をお勧めします。
リソースの拡張とは？
LifeKeeperによるリソースの拡張とは、稼働系ノード等、別のノードで作成したリソース構成を、別のクラスターノードに複製し、待機系ノードで同じリソース構成を共有することを言います。これにより、高可用性にしたいサービスやアプリケーションのフェイルオーバーが可能になる構成が構築出来ることになります。
リソースの拡張は、リソース構成を複製するだけでなく、対象リソースに関連する階層構造やサービス・アプリケーションを制御するためのスクリプトも複製されるため、待機系ノードにてスクリプトを準備する必要はありません。
LifeKeeperとしては可用性と冗長性を高めるため、基本的にリソースの作成とリソースの拡張をセットで実施することになります。
リソースの拡張に関しても、LifeKeeper の GUI または ターミナルによる CLI のどちらも使用することが出来きますが、リソースの作成と同様に、GUI でのリソース拡張をお勧めします。
ローカルリカバリーとは？
LifeKeeperによるローカルリカバリーとは、リソース障害が発生(quickCheckが失敗)した場合、フェイルオーバーによるリカバリー（待機系への切り替え）が行われる前に、障害が発生したノード内で復旧処理を試みる機能です。
ローカルリカバリーを利用することで、フェイルオーバーを発生させずに障害を復旧出来る可能性があり、ダウンタイムを短縮することができます。
ローカルリカバリーは、システムの要件に合わせて無効にすることが可能です。ローカルリカバリーが無効の場合、リソース障害発生後、即座にフェイルオーバーが発生します。
ローカルリカバリーが成功すれば、フェイルオーバーは発生しないよ。
ローカルリカバリーが失敗しても、フェイルオーバーで復旧するから安心ね。
シャットダウンストラテジーとは？
LifeKeeper によるシャットダウンストラテジーとは、リソースが稼働しているノードのシステムを正常に停止した際に、待機系ノードへリソースの切り替え（スイッチオーバー）を行うか、行わないかを制御するための設定になります。デフォルト値では、切り替えが行われない設定になります。
シャットダウンストラテジーは、ノード毎に設定が可能になります。例えば、2台構成のクラスター環境において、1号機はシャットダウンストラテジーが切り替えを行う設定で、2号機はシャットダウンストラテジーが切り替えを行わない設定の場合、1号機にてリソースが開始している状態で正常にシステムを停止すると2号機にリソースが切り替わります。逆に2号機にてリソースが開始している状態で正常にシステムを停止すると1号機にはリソースが切り替わりません。
シャットダウンストラテジーは、LifeKeeper GUI 上から設定の変更が可能で、システムの要件に合わせ変更が可能になります。
Switchback Typeとは？
LifeKeeper による Switchback Type とは、システム障害が発生したプライマリサーバが復旧し、オンラインとして接続された際に、自動でリソースを切り戻す“Automatic”か、切り戻さない“Intelligent”かを制御するための設定になります。デフォルト値では、自動でリソースを切り戻さない“Intelligent”設定になります。
Switchback Type を自動でリソースを切り戻す“Automatic”設定にすることで、運用者の介入を必要とせず、自動に元の構成に戻ることから、迅速な復旧が可能となりますが、障害復旧直後のプライマリサーバが完全に安定する前にリソースが戻ってしまい、予期せぬ問題が発生する可能性があることから、自動でリソースを切り戻さない“Intelligent”設定をお勧めします。
LifeKeeper でデータレプリケーションを使用する場合、Switchback Type の自動でリソースを切り戻す“Automatic”に設定することが出来ないよ。
プライオリティとは？
LifeKeeper におけるプライオリティは、主に2つの種類があります。
- コミュニケーションパスによるプライオリティ
こちらは、複数のコミュニケーションパスが設定されている場合、どのパスを優先して使用するかを定義するものになります。
コミュニケーションパスは、LifeKeeper クラスターにおいてノード間通信を支える重要な機能になり、専用線のような優先的に利用出来るパスのプライオリティを高くすることが推奨されます。
コミュニケーションパスのプライオリティは数値で表され、数値が小さいほど優先度が高くなります。 - フェイルオーバーによるプライオリティ
こちらは、複数のセカンダリサーバが存在する場合、どのサーバにフェイルオーバーするかを決定するために使用されます。
フェイルオーバーのプライオリティは、リソース毎に設定することが出来ますが、リソースグループ(依存関係で確立された複数のリソースのまとまり)単位で同一にする必要があります。
フェイルオーバーのプライオリティも数値で表され、数値が小さいほど優先度が高くなります。
PingListとは？
LifeKeeper による PingList とは、IP リソースの疎通確認処理となるユニキャスト ping 機能で利用される IP アドレスが記載された一覧になります。
ユニキャスト ping は、ブロードキャスト Ping の代わりに、PingList に記載された特定の IP アドレスやサブネット内の他の IP アドレスに対し動作のチェックをしています。PingList に登録されたアドレスに対して、1つでも Ping が成功した場合、LifeKeeper は該当のIPリソースが正常に動作していると判断します。
PingList は1個から複数個を設定することが可能です。ただし、PingList の設定個数が極端に少ない場合は、誤検知を起こす可能性があり、PingList の設定個数が極端に多い場合は、対象のアドレスへのチェックが失敗することで時間が掛かり、全てのアドレスをチェックする前にタイムアウトになってしまう可能性があります。
PingList は、確実に疎通が確認出来る3～4個のアドレスを設定することをお勧めするよ！
まとめ
今回はLifeKeeperの内部で使われている用語について説明して来ましたが、いかがでしたでしょうか？
少しでもLifeKeeperを身近に感じて頂けたら幸いです。
今回でHAクラスター/LifeKeeperとしての用語説明は一旦終わりになります。
今後、気になる用語が出てきましたら、また投稿したいと思います。
