仮想 IP リソース
LifeKeeper は、仮想 IP アドレスをプライマリーサーバーの物理ネットワークインターフェースの 1 つに作成することによって、IP リソースを In Service が可能な状態にしています。ユーザーはこの仮想 IP アドレスを使用してノードに接続します。
IP Recovery Kit ソフトウェアは、選択されたアドレス、ネットワークマスク、インターフェースが確実に正しく機能できるかをチェックします。ソフトウェアがチェックする要素は以下のとおりです。
- 未使用のリソース: 新しい IP アドレスが、LifeKeeper クラスター内に存在する他のどの IP リソースにも、割り当てられていないことを確認します。
- 一意のアドレス: このアドレスは、ネットワーク上で「現在は」アクティブにできません。リソース作成中のチェックに加えて、リソースを In Service にする直前にも一意であることの確認が行われます。ネットワーク上で重複するアドレスが検出された場合、そのリソースを In Service にしません。
プライマリーサーバーに障害が発生すると、IP Recovery Kit は仮想 IP を、バックアップサーバーの物理ネットワークインターフェースの 1 つに設定することによって、その IP リソースをバックアップサーバーで In Service 状態にします。
リカバリー後はセッションコンテキストが失われているため、仮想 IP を利用するユーザーは最初に接続するのに使用した手順とまったく同じ手順で再接続する必要があります。
手動のスイッチオーバーでは、IP Recovery Kit はそのエイリアスアドレスをアクティブサーバーのサービスから削除した後、バックアップサーバーに追加します。
IP Recovery Kit の管理と運用について理解しやすいように、図 1 に示したシナリオについて考えてみましょう。この設定例には、Server1 と Server2 という 2 台のサーバーで構成されています。各サーバーは 1 つの LAN インターフェース (eth0) を備え、サブネット 25.0.1 に接続されています。ユーザーシステムもこのサブネット上にあります。Server1 および Server2 上の LAN インターフェースのアドレスは、それぞれ 25.0.1.6 と 25.0.1.7 です。
システム管理者は、 ipname という名前の IP リソースのエイリアスアドレスとして 25.0.1.10 を使用することにしました。システム管理者は、 /etc/hosts ファイル (および使用されている場合は DNS) に以下のようなエントリーを作成します。
| 25.0.1.6 | server1 |
| 25.0.1.7 | server2 |
| 25.0.1.10 | ipname |
Server1 がこのリソースのプライマリーサーバーであれば、システム管理者はIP リソース階層の作成 セクションで説明しているウィザードを使用して、Server1 上に ipname 用の IP リソース階層を作成します。IP Recovery Kit は、 ipname (25.0.1.10) に関連付けられているアドレスを /etc/hosts で見つけて使用可能であることを確認し、セカンダリーアドレスを Server1 上の eth0 で設定することによって、アドレスを In Service にします。これで Server1 上の eth0 は、 server1 と ipname の両方に応答するようになります。
LifeKeeper7.3 以前のバージョンでは、新しいエイリアスアドレスは ifconfig もしくは ip addr show コマンドで確認することができました。LifeKeeper 7.4 からは、 ip addr show コマンドを使用してください (詳細については IPv6 既知の問題 を参照してください)。
ユーザーはその後、たとえば telnet ipname というように入力することで Server1 に接続できます。Server1 がクラッシュした場合、LifeKeeper は ipname のアドレスを Server2 の eth0 に自動的にスイッチオーバーします。Server1 上のユーザーセッションは終了します。ユーザーが telnet ipname を再実行した場合は、Server2 に接続されます。
ipname がどこでアクティブになって In Service であるかにかかわらず、アドレスとしての server1 と server2 はアクティブで、使用することができます。ただし、これらは LifeKeeper のリカバリーによって保護されていません。これらのアドレスは、切り替えられたアプリケーションに対してではなく、名前を使って特定のサーバーに対して接続する必要がある場合は常に使用できます。例えば、リモートシステム管理や LifeKeeper コミュニケーションパスなどがあります(この場合、LifeKeeper コミュニケーションパスとして、例えば 25.0.1.6 と 25.0.1.7 が使用されます)。
実 IP リソース
LifeKeeper は、仮想 IP アドレスだけでなく、実 IP アドレス（ネットワークインターフェース 用に構成されたプライマリー IP アドレス）を保護することが可能です。これにより、Amazon Web Services (AWS)環境において Recovery Kit for Route 53 と併用することで、仮想 IP アドレスを使わずに構成することができます。詳しくは Recovery Kit for Route 53 管理ガイド を参照してください。
IP リソースの監視
LifeKeeper は以下の方法を順番に実行して、管理下にある IP リソースの状態を定期的に監視しています。
- 該当するネットワークインターフェースにおいて、IP リソースがエイリアスとして設定されているかを確認します。
- IP リソースが設定されているネットワークインターフェースのリンク状態を確認し、物理ネットワークに正しく接続されているかを検査します。
- 保護された IP アドレスをソースアドレスとしてブロードキャスト ping テストを行い、IP リソースがネットワーク上で正しくデータの送受信を行えるかを確認します。
ブロードキャスト ping テストはデフォルトのテストメカニズムです。保護された IP アドレスをソースアドレスとして、ブロードキャスト ping パケットを IP リソースに関連付けられたサブネットのブロードキャストアドレス宛に送信し、テストを行っています。ローカルシステム以外の任意のアドレスから応答を受信するとテストは成功したと判断します。
ブロードキャスト ping に応答を返せるシステムがネットワーク上にない環境 (多くのシステムのデフォルト設定がこのような環境です) では、LifeKeeper はアドレスリストを定義し、ブロードキャスト ping の代わりに ping を送信するように設定可能です。このリストが定義されている場合、ブロードキャスト ping テストは省略され、リスト内のすべての IP アドレスに対し、同時に ping が実行されます。リスト内のいずれかの IP アドレスからの応答が受信されれば、テストは成功したと判断されます。この技術は、大規模なネットワークにおけるブロードキャストストームの抑止に有効です。
IP リソースの定期的なチェックの中で、これらのテストが失敗すると、LifeKeeper に障害が通知されます。LifeKeeper はまずローカルリカバリーを試み、IP リソースをローカルノード上でリストアしようとします。ローカルリカバリー手順の詳細については、IP ローカルリカバリーと設定に関する考慮事項 を確認してください。ローカルリカバリーが現在のノードでの IP リソースの起動に失敗した場合、LifeKeeper は IP リソースを含めたアプリケーション階層を、クラスター内の別の LifeKeeper システムに移動させます。
LifeKeeper は同じヘルスチェック機能を使い、 In Service の状態になった直後に IP リソースが正しく動作するかを判定します。チェックの結果、障害が確認された場合、起動は失敗します。
IP ヘルスチェックメカニズムは設定の変更とチューニングを実行することが可能です。詳細については、IP 構成の確認および編集 およびIP Recovery Kit のチューニング を確認してください。
このトピックへフィードバック