用語集

用語 説明
Active/Active HAクラスタにおける構成のひとつです。

クラスタを構成する各ノード上で、フェイルオーバ可能な何らかのリソースが平常時にアクティブ状態となるよう構成されているシステムを指します。また各ノードは他のノードのフェイルオーバ先として機能することが出来なければなりません。

例えば、ServerA、ServerBの2ノード構成のクラスタがあるとします。

ServerA:Oracleリソースのプライマリーノード
ServerB:Apacheリソースのプライマリーノード

上記の構成では、ServerAは平時にOracleリソースを起動しており、ServerBはApacheリソースを起動していることになります。このように各ノードが、それぞれ何らかのActiveなリソースを保持する状態を指してActive/Active構成といいます。

Active/Standby HAクラスタにおける構成のひとつです。

クラスタを構成する各ノードのうち、どれかひとつのノードが全てのサービスを起動するよう構成されているものを指します。

例えば、ServerA、ServerBの2ノード構成のクラスタがあるとします。

ServerA:Oracleリソース、Apacheリソースのプライマリーノード
ServerB:スタンバイノード

上記の構成では、ServerAは平時にOracleリソース、Apacheリソースの両方を起動しています。通常、これらのリソースには依存関係を結び、障害時には一緒にフェイルオーバを行うよう設定します。

ServerBはスタンバイノードとして機能します。障害発生時にはServerA上で動作している全てのリソースを引き受けます。

このように、クラスタノードの中でどれか1つのノードだけが、クラスタノード間で共有するリソースを起動する構成をActive・Standby構成と呼びます。

なお、Active-Passive(パッシブ)とも同義。

ARP Address Resolution Protocolの略。

IPアドレスからネットワークカードのMACアドレスを求める時に使用するプロトコルです。

関連サイト:http://www.ietf.org/rfc/rfc826.txt

Broadcast ネットワーク内で、不特定多数の相手に向かってデータを送信することです。

LifeKeeperのIPリソースの監視処理では、ネットワーク通信確認としてpingをBroadcastで送信し応答の有無を確認しています。

関連サイト:http://www.ietf.org/rfc/rfc919.txt

CCISS HP社のストレージコントローラー(SmartArrayなど)を使用している場合、OS上でディスクを認識するために使用されるドライバーです。

LifeKeeperではこのHP社のCCISSのドライバーを使用するストレージコントローラー経由のディスクを保護対象とするために標準でCCISS Recovery Kitを用意してます。

CDP(Continuous Data Protection CDPは、ディスクに記録されるデータの変更履歴を保持し、必要に応じて過去のデータを復元することが出来る機能を指します。日本語では「継続的データ保護」と訳されます。

SteelEye DataReplicationでは、このCDPを実現する「リワインド機能」を搭載しており、データが更新されるたびにビットマップファイルに変更履歴を記録し、任意の時点へのリカバリが可能となっています。

Data Replication 別々サーバー上にあるハードディスクの論理ディスクをリアルタイムに同期する仕組みです。LifeKeeperではSteelEye Data Replicationを使用することによって利用することができます。
DISKCA.exe LifeKeeper for Windowsで共有ストレージを使用したコミュニケーションパスの通信の管理をおこなうプロセスです。
DNSリソース LifeKeeper for WindowsでDNSプライマリー・サーバーのA(Address)レコードとPTR(domain name PoinTeR)レコード、またはホストの別名を更新するメカニズムを提供します。

詳細についてはユーザーサイトのFAQ「[Windows]DNS ARKの機能概要をおしえてください」や、プランニングおよびインストールの手引きの「DNSリソースの要件」をご参照ください。

Entitlement ID/Activation ID 製品を購入するとパッケージに付属するLifeKeeperのライセンスキー取得に必要な文字列です。
Entitlement IDは複数のActivation IDを1つにまとめたものです。
ETERNUS マルチパスドライバ ETERNUS マルチパスドライバ(EMPD)は、富士通社製ストレージでマルチパス環境を構成する際に用いられるソフトウェアです。

EMPDを使用したマルチパス構成をLifeKeeperで保護する場合は、特別なリカバリキットは必要ありません。通常のファイルシステムリソースと同様の手順で作成することができます。

関連サイト:http://storage-system.fujitsu.com/jp/products/software/eternusmpd/

Generic ARK 製品として提供しているARKが無いアプリケーションをLifeKeeperで保護対象(切り替え対象)とするときに使用するARKです。

ユーザは、起動、停止、監視、再起動(監視と再起動はオプション)の各スクリプトを作成し、GenericARKリソースとして組み込むことが出来ます。スクリプトの内容は任意であるため、ユーザは要件に合わせて自由に処理内容を記述することができます。

なお、この機能はLifeKeeper Coreに含まれます。

Gratuitous ARP ARP REQUESTの送信元IPアドレスとMACアドレスを使用し、他のノードのARPテーブルの更新を行う手法。MACアドレスの仮想化をしないクラスターソフトでは、この方法を使う事が一般的。

LifeKeeperではOSに付属されるarpingコマンドによりこれを実現している。

GUI管理クライアント LifeKeeperが提供するGUI管理ユーティリティです。

LifeKeeperでは、このGUI管理クライアント(またはGUI管理画面とも呼びます)を使用することで、LifeKeeperクラスタの構築から運用まで、一括して操作することが可能です。

GUI管理クライアントは、ローカルノード上のJavaアプリケーションとして実行します。また、ブラウザからJavaアプレットとして起動することも可能です。その場合は、ブラウザのURL入力バーに、”http://<クラスタノード>:81″と入力してください。

GUIサーバー LifeKeeperの管理GUIクライアントと通信を行うサーバープロセスです。

LifeKeeperの起動と共にrunGuiServerプロセスが起動されます。ただし、初回のLifeKeeper起動後のみlkGUIserverコマンドで起動させる必要があります。

このGUIサーバーが起動していない場合はクラスターノード上での管理GUIクライアントやリモートからブラウザ経由での管理GUIクライアントを操作することができません。”

ILLSTATE ステータスが読み取れない状態に陥っていることを意味します。

LifeKeeper の起動時などにも一時的にこのステータスとなることがございますがステータスの確認が取れた時点で復帰します。

IPS IBM社のストレージコントローラ ServeRAIDを使用している場合、OS上でディスクを認識するために使用されるドライバーです。

LifeKeeperではこのIBM社のServeRAID経由のディスクを保護対象とするために標準でIPS Recovery Kitを用意しています。

なお、IPS Recovery Kitをインストールする場合はIBMが提供しているRaidManパッケージが事前に必要です。

iSCSI TCP/IP上でSCSIプロトコルを使用する規格です。
通常のSANでは高価なファイバーチャネルを使用しますが、iSCSIではイーサネットを使用できるので、より安価にSANを構成できます。
ISP LifeKeeper内部で使用されるリソースのステータス一つで「In-Service Protected」の略です。
リソースが正常に起動している状態を表し、GUI上ではアクティブのステータスとして表示します。
Language supplement LifeKeeper for WindowsのGUIを日本語化するパッチです。
LifeKeepr for Windows v6以降を使用する場合は、必ずインストールする必要があります。
LCM TCPによるハートビート通信の管理や、クラスターを構成するノード間の通信の管理を行うプロセスです。
LCD LifeKeeperが保持するHA情報のデータベースです。またはそのデータベースを制御するプロセスを指します。

以下のような情報を格納しています。

– リソースタイプ毎のリカバリ情報を格納
– リソースインスタンスのステータス情報を保持
– システム, ネットワーク, リソース,依存関係、エクイバレンシイ

LifeKeeper サイオステクノロジーで開発、販売を行っているソフトウェアHAクラスターです。オプションのRecoveryKitを用いることで、2ノード以上のHAクラスタを簡単に構築することができることが特色です。

LifeKeeperはWindow版とLinux版の2種類が存在します。以下のサイトにも情報がございます。ご参照ください。

関連サイト:http://www.sios.com/product/lifekeeper/index.html

MTBF(Mean Time Between Failure) システム故障が生じるまでの平均時間のことです。値が大きいほど故障間隔が長い、つまり故障しにくいシステムであると言えます。

また、MTTR(Mean Time To Repair)の値と組み合わせて計算することで、システムの稼働率を求めることが出来ます。

MTTR(Mean Time To Repair) システムに故障が生じてから復旧までの平均所要時間を指します。

MTBF(Mean Time Between Failure)の値と組み合わせて計算することで、システムの稼働率を求めることが出来ます。

NAS NAS(Network Attached Storage)は、ネットワークに接続して使用するタイプのストレージサーバです。クライアントは、NFSプロトコルやCIFS、SMBなどでエクスポートされたファイルシステムを利用することが出来ます。

LifeKeeper for Linuxでは、NAS ARKを使用することで、NFSでエクスポートされたNASデバイスを共有ディスクとして利用することが出来ます。

Network Block Device (NBD) リモートサーバーのディスクをネットワーク経由でローカルディスクの様に扱う事ができるLinuxの機能です。

LifeKeeper for LinuxのLKDRやSDRは、NBDを利用しています。

関連サイト:http://archive.linux.or.jp/JF/JFdocs/kernel-docs-2.6/nbd.txt.html

OSF LifeKeeper内部で使用するリソースのステータス一つで「Out-of-Service Failed」の略です。
直前にリソース停止や起動に失敗したことを表しており、GUI上では障害のステータスとして表示します。
OSU LifeKeeper内部で使用されるリソースのステータス一つで「Out-of-Service Unimpaired」の略です。リソースが停止している状態を表し、GUI上ではスタンバイのステータスとして表示します。下位リソースが起動に失敗したため、起動処理が行われなかった場合にもこのステータスとなります。
Out Of Memory Killer OOM Killerと略すこともあります。

システムが実メモリやスワップを消費し尽くしてしまい、新たなメモリの割り当てを行えない状態となった場合に、プロセスを強制終了して空きメモリを確保するというLinuxカーネルの機構です。

停止するプロセスは基本的にLinuxカーネルにより決定されますが、サービスに影響を与えるプロセスを停止することもあるため、トラブルの原因となることもあります。

Perl Larry Wall氏が開発したプログラミング言語。テキストの検索や抽出、レポート作成に向いた言語で、表記法はC言語に似ている。インタプリタ型であるため、プログラムを作成したら、コンパイルなどの処理を行なうことなく、すぐに実行することができる。CGIの開発によく使われる。

関連サイト:http://www.perl.org/

quickCheck LifeKeeperがリソース監視を行う際に実行されるスクリプトです。このスクリプトには、対象となるサービスが正しく動作しているかを確認するための処理を記述します。

このスクリプトはLifeKeeperのlkcheckデーモンより、/etc/default/LifeKeeperのLKCHECKINTERVALの値秒(初期値では120)ごとに実行されています。実行した結果の戻り値が0であれば正常、1であれば異常と判定してリカバリ動作を行います。

なおこのスクリプトはオプションであり、監視の必要の無いものに対しては存在しません。

リカバリーキットのquickCheckクリプトは、以下のパスに格納されています。
/opt/LifeKeeper/subsys/<リソースの種類>/resources/<アプリケーションの種類>/actions/quickCheck

quota ディスクの使用量を制限する仕組みです。

Linuxではquotaプログラムを使用してディスクの使用容量を制限することができます。

関連サイト:http://www.linux.or.jp/JF/JFdocs/Quota/

RAID (Redundant Arrays of Inexpensive Disks) 複数のハードディスクをまとめて1台のハードディスクとして管理する技術です。

RAID0からRAID6まで7つのレベルがあり、それぞれRAIDの構成に必要なディスクの数や信頼性、パフォーマンスが異なります。

高可用性が目的である場合は、RAID0(ミラーリング)、RAID5(パリティの分散記録)、RAID6(パリティデータの2重可)が選択されるケースが多くなります。

関連サイト:http://ja.wikipedia.org/wiki/RAID

recover LifeKeeperの各ARKにおける、サービスの起動を目的としたスクリプトを指します。

GUI管理画面から”in-service”を行った場合や、perform_actionコマンドでの起動など、ユーザの操作に応じて実行されますし、障害検知に起因したフェイルオーバでも同様のスクリプトが実行されます。

なお、restoreスクリプトは、以下のパスに格納されています。
/opt/LifeKeeper/subsys/<リソースの種類>/resources/<アプリケーションの種類>/actions/restore

remove LifeKeeperの各ARKにおける、サービスの停止を目的としたスクリプトを指します。

GUI管理画面から”out-of-service”を行った場合や、perform_actionコマンドでの停止など、ユーザの操作に応じて実行されますし、障害検知に起因したフェイルオーバにおける停止処理でも、同様のスクリプトが実行されます。

なお、removeスクリプトは、以下のパスに格納されています。
/opt/LifeKeeper/subsys/<リソースの種類>/resources/<アプリケーションの種類>/actions/remove

restore LifeKeeperの各ARKにおける、サービスの起動を目的としたスクリプトを指します。

GUI管理画面から”in-service”を行った場合や、perform_actionコマンドでの起動など、ユーザの操作に応じて実行されますし、障害検知に起因したフェイルオーバでも同様のスクリプトが実行されます。

なお、restoreスクリプトは、以下のパスに格納されています。
/opt/LifeKeeper/subsys/<リソースの種類>/resources/<アプリケーションの種類>/actions/restore

RFC952 ホスト名に使用できる文字の規程の一つです。
JavaのRMIを使用するには、このRFC952に準拠したホスト名をつける必要があります。

関連サイト:http://www.ietf.org/rfc/rfc952.txt

RMI 別のホストのJavaオブジェクトのメソッドを呼び出すための通信手段で、Remote Method Invocationの略です。
LifeKeeperのGUIでは対向ノードの状態などを表示させるためRMI通信を使用しています。
Safety Check LifeKeeper for Windowsにおいて、ハートビートの全断が発生した場合に、対向ノードが起動しているかを確認するために実施するチェック機構です。

LifeKeeperではハートビートの全断が生じると、両ノードがリソースを起動しようとします。Windows版ではその前に全てのNICの、あらゆる通信経路を用いて、クラスタを構成する相手ノードと通信できないかを確認します。

全ての通信経路において、相手サーバと通信ができないことを確認すると、フェイルオーバを行います。

Single Point of Failure(SPOF) Single Point of Failure(SPOF)は、日本語では単一障害点と訳します。

SPOFとは、障害が起きるとサービス停止に直結するシステム上の構成要素を指します。このSPOFを極力排除し、システム全体を冗長化することで、障害に対する可用性を向上させることが出来ます。

LifeKeeperで冗長化されたシステムであっても、ネットワークや電源などを含んだ構成要素の中にSPOFが含まれている場合は、その部位に障害が生じた場合にサービスの停止に繋がります。

例えば、ネットワークやサーバ、ストレージが2重化されているにも関わらず、電源が1系統しか用意されていないのであれば、停電が発生した際にはサービスが停止することになります。

SNMP SNMP(Simple Network Management Protocol)は、UDP/IPベースのネットワーク監視、ネットワーク管理を行うためのプロトコルです。v1,v2,v3があります。

LifeKeeperには、発生したイベントに応じてSNMP TRAPを発行する機能があります。設定方法については、FAQ の「[Linux]SNMPTRAPの設定方法は?」をご参照ください。

teaming 冗長性やパフォーマンスの向上を目的として、複数のNICを仮想的に一つのNICにまとめる技術全般を指します。Linuxでは、Bondingドライバを用いることでチーミングデバイスを作成することができます。

このようなデバイスには、通常のNICとは異なるデバイス名が割り振られます。例えば、Bondingデバイスの場合は”bond0″といったデバイス名になります。

TTY シリアルインターフェース、特にIAサーバーではRS-232C(9pin)を指します。

LifeKeeperではシリアルインターフェースをクロス(null)ケーブルで接続することでコミュニケーションパスとして使用することができます。

UPS Uninterruptible Power Supplyの頭文字をとったもので、日本語では無停電電源装置と呼びます。

停電発生時に、UPSに接続されたサーバに対して電力を供給する装置です。一般的にはコンセントとサーバの間に配置します。

コンセントからの電力供給が停止すると、自動的に内蔵された電池により、サーバへ電力を供給します。また、一般的な用途としては、この電力を用いてサーバを稼動し続けるのではなく、UPSの保持する電力が切れる前に、正常な手段でサーバの停止を行うことを目的とします。

また電力停止時にサーバの停止を行うため、UPSとノードはシリアルケーブルなどで接続します。

依存関係(従属関係) LifeKeeperではそれぞれのリソースに対して依存関係(従属または親子関係)を持たせることができます。この依存関係が構成されたリソースには起動と停止順が決定付けられます。

リソースの起動動作は、この依存関係により下位のリソースから順に上位のリソースへと行われます。逆にリソースの停止動作は、上位のリソースから下位のリソースへと行われます。

例:
Oracleリソースは子リソースとしてファイル・システムリソースが下位に位置します。

リソースの起動順:ファイル・システムリソースを起動->Oracleリソースを起動
リソースの停止順:Oracleリソースを停止->ファイル・システムリソースを停止

*上記は説明上簡単にしています。実際にはファイル・システムリソースも下位にリソースを持つため順に処理されます。

(リソースの)拡張 LifeKeeperでは、アクティブノード上で構成されたリソースの設定を、他のスタンバイノード上にも同様に設定する事を「拡張」と呼びます。また、スタンバイノードが複数存在する場合は、拡張先にプライオリティを設定する事ができます。

拡張されたリソースはノード間でそのリソースに対する情報を共有することになります。この共有された情報をイクイバレンシと呼びます。

可用性 ある期間にいて、システムが正常稼働することが出来る割合を示す数値です。可用性は以下の式で求めることができます。

==============
可用性 = MTBF/(MTBF + MTTR)
==============

共有ストレージ クラスタを構成する各ノードに対して、同時に接続することができ、また各ノードが交互にアクセスすることが可能なストレージ全般を指します。

共有ストレージ以外にも、共有ディスクや共有ファイルシステムといった呼び方をする場合があります。

共有ストレージには、クラスタを構成した際に各ノードが参照する共通のデータを配置します。例えば2ノードで構成されたクラスタであれば、両方のサーバが同じデータを参照することになります。このようにすることで、フェイルオーバーが発生してもクライアントは同じデータにアクセスすることが出来るというわけです。

共有ディスクとサーバの接続形態には、以下の種類があります。
・SCSI
・FiberChannel
・iSCSI

また、サーバとストレージ間の接続経路を冗長化することで、マルチパスを構成することが出来ます。

クラスタシステム クラスタシステムとは、一般的に複数のサーバを1つのサーバのように稼働させるシステムを指します。

クラスタシステムの用途は、大きく分けて以下の2種類があります。

・複数のサーバを並列的に配置し、負荷分散を行う。
これはパフォーマンスの向上が主な目的です。HPC(High Performance Computing)、パラレルコンピューティング、グリッドコンピューティングなどがこの部類に含まれます。

・スタンバイサーバを用意してシステムの信頼性を向上させる。
一般的にこのようなクラスタをハイアベイラビリティクラスタ(HAクラスタ)といいます。

LifeKeeperはこのHAクラスタを実現するためのソフトウェアになります。

コミュニケーションパス クラスターノード間でクラスタやリソースの情報のやりとりを行うために使う通信経路のことを指します。このパス上ではハートビート通信も行われるため、冗長構成が必須となります。

※コミュニケーションパスの冗長構成はLifeKeeper上の設定で実行してください。

複数のコミュニケーションパスが設定されている場合、プライオリティが一番高いパスで情報通信が行われます。

詳細チェック LifeKeeper for Windowsのみにあるリソース監視の仕組みです。

LifeKeeper for Windowsではクイックチェックと詳細チェックの2種類の監視を時間差で実行させることができます。監視の内容はARKごとに異なります。

スイッチオーバ 管理者が手動オペレーションによりリソースを切り替える操作のことをいいます。

対義語:フェイルオーバ
同義語:手動フェイルオーバ

スプリットブレイン LifeKeeperを含む多くのHAクラスターは、ハートビートと呼ばれるノード間のポーリングにより、お互いのノードの状態を監視しています。一般に、ノード障害が発生すると待機状態のノードがハートビートによりそのことを検知し、フェイルオーバーを行います。

スプリットブレインとは、全てのハートビートが切れてしまい、相手ノードの状態が確認できなくなる状態を指します。この場合、それぞれのノードがフェイルオーバーを実行する動作となるケースがあり、最悪の場合は共有データの破壊が生じかねない危険な状態です。

LifeKeeper for Linuxでは、このスプリットブレインへの対策として、SCSI-2 RESERVEを発行して共有ディスクへアクセスできるノードの制限を行っています。これにより、複数のノードが同時に共有ディスクにアクセスを行ったとしても、共有ディスク上のデータは保護されます。

またLifeKeeper for Windowsでは、全てのネットワーク接続を用いたpingチェックを実行して相手ノードの生死を確認しており、やはり共有ディスクへの多重アクセスが生じないよう設計されています。

LifeKeeperのスプリットブレイン発生時の動作シナリオについては、以下のURLでご紹介しています。

<改定履歴>

 [2010年9月16日 改定]
関連記事:
参考文献:
関連サイト:[Linux][Windows]共有ストレージを使用しています。ハートビートが全て切断された場合、どのような挙動を示しますか?

名前解決 コンピュータやネットワーク機器につけたホスト名とアドレスを、ネットワーク上の通信のために関連付けることを指します。

LifeKeeperを使用する場合、クラスターを構成するノード同士でこの名前解決が行われている必要があります。また、ブラウザを使用してリモートからGUIを表示させる場合は、クライアントからクラスターノードについても、名前解決が行われている必要があります。

ノード障害 LifeKeeper上ではハートビート通信の応答が一定時間確認できなくなった状況を表します。
この状態になった場合に、LifeKeeperはフェイルオーバの処理を開始します。
ノンノードロックライセンス LifeKeeper for Linux v6.x、LifeKeeper for Windows v6.x で使用しているライセンス形式です。
LifeKeeper v5.xおよびv7以降(Linux/Windows共)のバージョンでは、パーマネントライセンスを取得するためにhostID(MACアドレス)が必要ですが、LifeKeeper v6ではEntitlement ID/Activation IDのみで取得できます。
ハイアベイラビリティ 高可用性を目的として構築したコンピュータシステムを指します。

可用性を高めるためには、システムの2重化による耐障害性の向上や、障害から迅速なリカバリを行う仕組みなどが有効です。弊社の製品では、LifeKeeperは耐障害性の向上に、障害からのデータリカバリにはDataReplicationのリワインドログ機能が有効です。

バックアップインターフェース LifeKeeper for Linux LifeKeeper for WindowsのIPリソースが持っている機能の一つです。複数のNICがある場合、それを使用してNICの冗長化を行うことができます。バックアップインターフェースを設定した場合、プライマリのNICが故障するとバックアップのNICを使用して通信を継続できるようにLifeKeeperが制御します。

OSのNIC冗長化の機能(bonding、あるいはTeaming)の代替として使用することができます。OS上でNICの冗長化を実施している場合には、LifeKeeperでバックアップインターフェースの設定をする必要はありません。

パラメータ プログラムやコマンドに与える引数。処理方法を指示したり、処理対象(ファイル名など)を指示するために使われる。例えば、WindowsのDIRコマンドに「/W」というパラメータを与えると、出力形式が変更される。
ハートビート 各クラスターノードが相互に状態を確認するために、周期的に死活監視を行う仕組みです。

LifeKeeperではコミュニケーションパスの全ての経路で、このハートビートによる死活監視を行っています。

なお、LifeKeeperのハートビートはTCP 7365ポートを使用しています。また、ハートビート及びコミュニケーションパスの仕組みは、lcmデーモンにより提供されています。

ファイル共有リソース LifeKeeper for Windowsにおける、共有ボリュームリソースで保護されたボリューム、あるいはディレクトリに設定した共有設定を、スタンバイノードに引き継ぐための リソースです。設定をするための要件についてはリリースノートやオンラインマニュアルなどをご確認ください。
フェイルオーバー LifeKeeperが障害を検知し、自動的にスタンバイ状態のノードにリソースを切り替える動作を指します。管理者が手動でリソースを切り替える操作は「スイッチオーバー」と言い、LifeKeeperではこの二つの動作を分けて呼称しています。

フェイルオーバーには、大きく分けて以下の2種類の発生要因があります。

・ノード障害に起因するフェイルオーバー
各クラスタノードは相互にハートビートを実行してノードの死活監視を行っています。このハートビートに応答がタイムアウトした場合、相手ノードの停止と判断し、全てのリソースのフェイルオーバーを行います。

・リソース障害に起因するフェイルオーバー
LifeKeeperは120秒に一度(初期値)の頻度でリソースの状態チェックを行っています。リソースの状態チェックは、各リソースのリカバリキットに含まれている”quickCheck”というスクリプトで実行しており、このチェックで障害を検知するとリソースを他のクラスタノードに切り替えます。

フォールト・トレランス サーバー・システムの一部に障害が発生しても、全体を停止させずに処理を続けるようにする仕組みであり、その間に故障部分を修復できます。

このような仕組みを持つサーバーをFTサーバーと呼びます。

ボリュームリソース LifeKeeper for Windowsで共有ストレージやSDRでミラーリングしたボリュームを保護する場合に作成するリソースです。
マルチパス 外部ストレージを使用している環境において、サーバとストレージ間の接続経路を複数用意し、冗長性を持たせた構成のことを指します。
クラスタシステムにおいて各ノードから共有ストレージへの経路を冗長化することは、可用性を高めるための有効な手段です。

マルチパスの特長である接続経路の冗長化、および経路の制御は、OS およびドライバ・ソフトウェアが提供する機能により実現されています。
マルチパス構成の共有ストレージを LifeKeeper から制御するためには、ドライバ・ソフトウェアが正しく機能し、OS
がデータ領域を正常に認識できている必要があります。
なお、一部のドライバ・ソフトウェアを制御するためには、対応するリカバリキットを導入する必要があります。

LifeKeeper が対応可能なマルチパス・ドライバを以下に記載します。

[LifeKeeper for Linux]
– 以下は LifeKeeper for Linux が標準で対応可能なドライバです。

・qlogic ドライバ
・Emulex ドライバ
・ETERNUS マルチパスドライバ
・Redundant Disk Array Controller(RDAC)

– 以下は、対応するリカバリキットの導入で LifeKeeper for Linux で対応可能となるドライバ・ソフトウェアです。
・Subsystem Device Driver (SDD)
・PowerPath
・device-mapper-multipath
・JP1/HiCommand Dynamic Link Manager
・NEC iStorage StoragePathSavior

[LifeKeeper for Windows]
Windows OS の Multipath I/O 機能が正常に動作し、ボリュームを正しく認識していれば、LifeKeeper で対応することができます。

リソース リソースとは保護対象(切り替え対象)サービスのオブジェクトです。

LifeKeeperでは各サービスに対して、起動、停止、切り替えなどをこのオブジェクトに対して行います。

例:
WebサービスであるApacheをLifeKeeperでHA設定した後、オブジェクトとしてApacheリソースが作成されます。

ローカルリカバリ LifeKeeperのリソース監視処理で障害を検知した後で、Standbyノードへのフェイルオーバーを実施する前に、自ノード上で該当するリソースの再起動を試みる機能です。

※リカバリキットによってはローカルリカバリの機能がないものもあります。

return top