運用の原則

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) に以下のようなエントリを作成します。

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 リソースの状態を定期的に監視しています。

1. 該当するネットワークインターフェースにおいて、IP リソースがエイリアスとして設定されているかを確認します。

2. IP リソースが設定されているネットワークインターフェースのリンク状態を確認し、物理ネットワークに正しく接続されているかを検査します。

3. 保護された 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 のチューニング を確認してください。