現在地:はじめに > 運用の原則

運用の原則

LifeKeeper は、仮想 IP アドレスをプライマリサーバの物理ネットワークインターフェースの 1 つに作成することによって、IP リソースを In Service が可能な状態にしています。ユーザはこの仮想 IP アドレスを使用してノードに接続します。

IP Recovery Kit ソフトウェアは、選択されたアドレス、ネットワークマスク、インターフェースが確実に正しく機能できるかをチェックします。ソフトウェアがチェックする要素は以下のとおりです。

プライマリサーバに障害が発生すると、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 です。

図 1.管理および運用のシナリオ

AdminandOperation.jpg

システム管理者は、ipname という名前の IP リソースのエイリアスアドレスとして 25.0.1.10 を使用することにしました。システム管理者は、/etc/hosts ファイル (および使用されている場合は DNS) に以下のようなエントリを作成します。

25.0.1.6

25.0.1.7

25.0.1.10

server1

server2

ipname

 

Server1 がこのリソースのプライマリサーバであれば、システム管理者はIP リソース階層の作成セクションで説明しているウィザードを使用して、Server1 上に ipname 用の IP リソース階層を作成します。IP Recovery Kit は、ipname (25.0.1.10) に関連付けられているアドレスを /etc/hosts で見つけて使用可能であることを確認し、セカンダリアドレスを Server1 上の eth0 で設定することによって、アドレスを In Service にします。これで Server1 上の eth0 は、server1ipname の両方に応答するようになります。

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 であるかにかかわらず、アドレスとしての server1server2 はアクティブで、使用することができます。ただし、これらは 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 のチューニングを確認してください。

/ ページ

c 2012 SIOS Technology Corp., the industry's leading provider of business continuity solutions, data replication for continuous data protection.