共通のハードウェアコンポーネント

LifeKeeperのすべての設定には、以下の共通コンポーネントが含まれます。

1. サーバーグループ 。LifeKeeperが提供する障害回復機能は、2台以上のサーバーをクラスターにグループ化することを基礎にしています。サーバーは、利用可能なLinuxのディストリビューションを実行する、利用可能なプラットフォームであれば、いずれでもかまいません。LifeKeeperには、複数の重なり合うグループにサーバーを設定する柔軟性があります。ただし、リカバリー可能なリソースについての重要な要件は、リソースの役割と優先順位が定義されたサーバーのグループをリンクすることです。リソースに対するサーバーの優先順位は、現在実行中のサーバーに障害が発生した場合に、どのサーバーがそのリソースを復旧するかを決定するために使用されます。最高の優先順位を示す値は1です。特定のリソースについて、最高の優先順位の値(通常は1)を持つサーバーが通常、そのリソースのプライマリーサーバーと呼ばれます。その他のサーバーは、そのリソースのスタンバイサーバーとして定義されます。

2. コミュニケーションパス 。LifeKeeperのハートビートは、LifeKeeperクラスター内にあるサーバー間の間の定期的なメッセージで、主要な障害検出機能です。クラスター内のすべてのサーバーには、単純な通信障害でシステムに障害が発生しないように、冗長なハートビートコミュニケーションパス(commパス)が必要です。2つの独立したサブネットを使用するLANベース(TCP)の個別な2つのコミュニケーションパスが推奨されます(少なくとも1つのコミュニケーションパスをプライベートネットワークとして設定してください)。TCPコミュニケーションパスは、他のシステムの通信にも使用できます。

*注意: クラウド環境 では一般にネットワークの内部構成が公開されていないので、物理的に別経路のLAN回線を２つ用意することは困難です。しかしながら、基本的にクラウド側で物理的なネットワークの冗長化が行われている事が予想されるため、 コミュニケーションパスが一つ であっても動作上の信頼性を確保することができます。

注意: LifeKeeperのGUIは、TCP/IPを使用して、保護するリソースに関するステータス情報を通信します。TCPコミュニケーションパスが2つ設定されている場合、LifeKeeperはパブリックネットワークのコミュニケーションパスをリソースステータスの通信に使用します。このため、LifeKeeperのGUIが使用しているネットワークがダウンするとコミュニケーションパスが動作可能な場合でも、GUIには他のサーバーのステータスがUNKNOWNとして表示されます。

3. 共有データリソース 。共有ストレージの構成では、LifeKeeperクラスター内のサーバーは同一セットのディスクに対するアクセスを共有します。プライマリサーバーに障害が発生した場合、LifeKeeperは障害が発生したサーバー上にあるディスクのロック解除、および次に使用可能なスタンバイサーバーのディスクのロックを自動管理します。

4. 共有通信 。LifeKeeperはTCP/IPアドレスのような通信リソースの切り替えを自動管理できるので、アプリケーションが現在どのサーバーでアクティブになっているかには無関係に、ユーザはアプリケーションに接続できます。

すべてのLifeKeeper設定に共通するコンポーネント