LifeKeeper の機能
| 項目 | 説明 |
|---|---|
| ライセンス | LifeKeeper を使用するには、各サーバに一意の実行時ライセンスキーが必要です。これは物理サーバおよび仮想サーバの両方に適用されます。ライセンスキーは、LifeKeeper Core ソフトウェア、および LifeKeeper リカバリキットの各パッケージにそれぞれ必要です。インストールスクリプトで、サーバの Host ID を取得して表示するラインセンスユーティリティパッケージをインストールします。ライセンスがインストールされた後、ユーティリティが、使用可能な Entitlement ID、または Host ID (Entitlement ID が使用できない場合) を返します。ホスト ID およびソフトウェアに付属のアクティベーション ID を使用して SIOS Technology Corp. の Web サイト からライセンスキーを取得してください。 |
| 大型クラスタのサポート | LifeKeeper は、最大 32 台のサーバを持つ大型クラスタの設定をサポートします。ただし、LifeKeeper 以外の多くの要因が、クラスタ内でサポートされるサーバの台数に影響することがあります。この要因として、ストレージの相互接続、オペレーティングシステム、ストレージソフトウェアの制限などがあります。サポートされる最大クラスタサイズを調べるには、ベンダ固有のハードウェアとソフトウェアの設定情報を参照してください。 |
| 国際化とローカライズ | LifeKeeper for Linux v5.2 以降は、リソース名とタグ名でのワイド / マルチバイト文字の使用をサポートしていますが、ネイティブの言語メッセージサポートは含まれていません。Java のプロパティファイルのロケール固有バージョンを作成することにより、LifeKeeper の GUI をローカライズできますが、現在フルにローカライズされているのは英語バージョンのみです。ただし、LifeKeeper の GUI に表示される多くのメッセージは LifeKeeper Core から来ているので、GUI のローカライズは、ユーザにとって、Core ソフトウェアがフルにローカライズされるまでの単なる部分的な解決法です。 追加情報については、制限または既知の問題 の 「言語環境の影響」 も参照してください。 |
| LifeKeeper の MIB ファイル | LifeKeeper は、LifeKeeper クラスタ内で発生するイベントを記述する SNMP トラップを送出するように設定できます。この機能の設定に関する詳細については、lk_configsnmp(8) のマニュアルページを参照してください。LifeKeeper のトラップを記述する MIB ファイルは、 /opt/LifeKeeper/include/LifeKeeper-MIB.txt に記載されています。 |
| Watchdog | LifeKeeper は、Watchdog 機能をサポートしています。この機能は、SIOS Technology Corp. により Red Hat EL 6 + softdog 、および Red Hat EL 7 + softdog でテスト済みです。 |
| STONITH | LifeKeeper は、STONITH 機能をサポートしています。この機能は、SIOS Technology Corp. により IBM x3550 x86_64 アーキテクチャ上の SLES 11、および RHEL5.5 の 64-ビットでテスト済みです。 |
| XFS ファイルシステム | XFS ファイルシステムは、ファイルシステムのチェックと修正に fsck ユーティリティを使用しません。その代わりに、ログの再生をマウントに依存します。整合性の問題についての懸念がある場合は、システム管理者がファイルシステムを out of service にしてシステムをアンマウントし、xfs_check(8) と xfs_repair(8) を実行して問題を解決する必要があります。 |
| IPv6 | SIOS は、ip コマンドの使用に移行し、ifconfig コマンドを使用しなくなりました (詳細については IPv6 の既知の問題 を参照)。 |
チューニング
| 項目 | 説明 |
|---|---|
| IPC セマフォと IPC 共有メモリ | LifeKeeper には、プロセス間通信 (IPC) セマフォと IPC 共有メモリが必要です。以下の Linux カーネルオプションの Red Hat のデフォルト値は、 /usr/src/linux/include/linux/sem.h にあり、LifeKeeper の多数の設定をサポートするのに十分な値です。 必要なオプション Red Hat 6.2 のデフォルト値
|
| システムファイルテーブル | LifeKeeper がバックアップシステムに正常にフェイルオーバするためには、システムリソースが使用可能である必要があります。例えば、システムファイルテーブルがフルの場合、LifeKeeper が新しいプロセスを開始してリカバリを実行することができない可能性があります。エンタプライズパッチを持つカーネル (LifeKeeper がサポートするものを含む) では、file-max、つまりシステムで開いているファイルの最大数は、デフォルトでシステムメモリサイズの 1/10 に設定されます。これは、LifeKeeper の多数の設定をサポートするのに十分な値です。file-max 値をデフォルト値よりも低く設定すると、予期しない LifeKeeper の障害が発生することがあります。 file-max 値は、以下のコマンドで取得できます。 cat /proc/sys/fs/file-nr このコマンドは、3 つの値を返します。1 番目の値はファイルテーブルのエントリのこれまでの最大値 (システムがこれまでに検出した最大値)、2 番目の値は現在のファイルテーブルのエントリ数、3 番目の値は file-max 値です。 file-max を調整するには、/etc/sysctl.conf の「fs,file-max」値を追加 (または変更) し (フォーマットについては sysctl.conf(5) を参照)、 sysctl –p 次にこのファイルを実行して、システムを更新します。/etc/sysctl.conf の値は、再起動後も保持されます。 |
LifeKeeper の動作
| 項目 | 説明 |
|---|---|
| カーネルデバッガ (kdb) init s |
LifeKeeper が保護するサーバでカーネルデバッガ ( kdb ) を使用したり init s に移動する前に、そのサーバで LifeKeeper をシャットダウンするか、LifeKeeper が保護するリソースをバックアップサーバにスイッチオーバする必要があります。LifeKeeper の SCSI 予約デーモン ( lkscsid と lkccissd ) を有効にした状態で (デフォルトで有効)、 kdb を使用すると、予期しないパニックが発生することがあります。 |
| ロックしている共有デバイスでのシステムパニック | LifeKeeper はロックを使用して、共有 SCSI バス上にある他のサーバがアクセスしないように共有データを保護します。他のサーバがデバイスをロックしたことにより LifeKeeper がデバイスにアクセスできない場合、致命的なエラーが発生し、即座に対処する必要があります。対処しない場合、データが破損するおそれがあります。この条件が検出された場合、LifeKeeper はシステムにパニックを発生させる機能を有効にします。 共有デバイスが予約された状態で、LifeKeeper が「/etc/init.d/lifekeeper stop-nofailover」以外の方法により停止した場合 ( init s の実行で発生することがある)、他のサーバがリソースを復旧するときに LifeKeeper のロックメカニズムによりカーネルのパニックがトリガされることがあります。この方法で LifeKeeper を停止する前に、リソースをすべて out-of-service にする必要があります。 |
| nolock オプション | NFS 領域でロックを使用するアプリケーションを使用し、SPS の推奨するマウントオプションを使用する場合は、nolock を追加する必要があります。 rw,nolock,bg,hard,tcp,nfsvers=3,timeo=600,rsize=32768,wsize=32768,actimeo=0 |
| Out-of-Service 階層の復旧 | LifeKeeper サーバの障害発生後のリカバリの一部として、障害が発生したサーバに設定されているリソース階層のうち、障害発生時にいずれかのサーバで in-service ではないものは、その時点で優先順位が最高の alive のサーバで復旧されます。これは、障害が発生したサーバ、復旧中のサーバ、クラスタ内の他のサーバを含め、 out of service の階層が最後にどこで in service だったかには無関係です。 |
| Linux ファイアウォールとの共存 | ファイアウォールが OS インストール時に有効になります。インストールの完了後、ファイアウォールを変更する必要があります。 ホストのファイアウォールが有効の場合、LifeKeeper は機能します。ただし、絶対に必要な場合を除き、ファイアウォールを無効にし、LifeKeeper で保護するリソースは別の保護ファイアウォール内に配置することをお勧めします。 LifeKeeper がファイアウォールを有効にしたホストと共存させる必要がある場合、LifeKeeper はコミュニケーションパス、GUI、IP、およびデータレプリケーションに特定のポートを使用することに注意してください。Linux のファイアウォール機能を使用する場合、LifeKeeper が使用している特定のポートを開放する必要があります。詳細については、ファイアウォールを使用した状態での LifeKeeper の実行 を参照してください。 |
| SELinux との共存 | SELinux モードが 「有効」の場合、LifeKeeper はインストールも機能もしません。 SELinux を無効にするには、お使いの OS ディストリビューションのマニュアルを参照してください。 SELinux の permissive モード。 SAP 環境で必要な場合を除いて、SIOS は SELinux を permissive モードで使用することは推奨しません。クラスターで実行中のアプリケーションが、permissive モードの SELinux をサポートしていることを確認してください。次のアプリケーションリカバリーキットはテスト済みです： SAP、SAP MaxDB、Sybase、Oracle、DB2、NFS、DataKeeper、NAS、EC2、IP、FileSystem、MQ AppArmor （このセキュリティモデルを使用するディストリビューションの場合）は有効にすることができます。 |
| Suid マウントオプション | suid マウントオプションは、 root としてマウントするときのデフォルトであり、マウントコマンドにより /etc/mtab に書き込まれることはありません。LifeKeeper 環境では、suid マウントオプションは不要です。 |
サーバの設定
| 項目 | 説明 |
|---|---|
| BIOS のアップデート | 使用可能な最新の BIOS を常にすべての LifeKeeper サーバにインストールする必要があります。 |
LifeKeeper 8.2.0 以降の GUI 要件
LifeKeeper GUI クライアントでユーザを正常に認証するには、64 ビットバージョンの PAM 関連のパッケージがすべて必要です。
[Confirm Failover] と [Block Resource Failover] の設定
以下の説明、例、および考慮事項をよく読んで理解してから、お使いの LifeKeeper 環境で [Confirm Failover] または [Block Resource Failover] を設定してください。これらの設定は、コマンドライン、または LifeKeeper の GUI の [Properties] パネルから使用できます。
Confirm Failover On:
定義 – システム A から システム B へのフェイルオーバの手動確認を有効にします ( システム A はプロパティが [Properties] パネル に表示されるサーバで、 システム B はチェックボックスの左にあるシステム)。あるシステムでこのオプションをオンに設定した場合、障害発生が検出されたシステムについて LifeKeeper がフェイルオーバリカバリを実行するには、システム管理者による手動確認が必要になります。
フェイルオーバを確認するには、lk_confirmso コマンドを使用してください。デフォルトでは、このコマンドを実行するまで管理者には 10 分の猶予時間があります。この時間は、 /etc/default/LifeKeeper の CONFIRMSOTO 設定で変更できます。管理者が 10 分以内に lk_confirmso コマンドを実行しない場合、フェイルオーバは続行されるか、ブロックされます。デフォルトでは、フェイルオーバが続行されます。この動作は、 /etc/default/LifeKeeper の COMFIRMSODEF 設定で変更できます。
例 : 自動フェイルオーバをすべてブロックする場合は、 [Properties] パネルの [Confirm Failover On] オプションを設定し、さらに CONFIRMSODEF を 1 (フェイルオーバをブロック)、 CONFIRMSOTO を 0 (フェイルオーバ動作が決定されるまで待機しない) に設定してください。
この設定を選択するタイミング:
この設定は、設定に冗長ハートビートコミュニケーションパスを含まない多くのディザスタリカバリ、その他の WAN 設定で使用されます。
あるサーバで [Properties] ページを開き、 [Confirm Failover] フラグ をオンに設定するサーバを選択してください。
Block Resource Failover On:
定義 - デフォルトでは、リソースのすべての障害について復旧イベントが発生し、ローカルシステムの障害リソースの復旧が試行されます。ローカルリカバリが失敗した場合、または有効になっていない場合は、リソースが定義されている、優先順位が次に最も高いシステムに、LifeKeeper がローカル履歴を転送します。ただし、宛先として指定したシステムでこの設定を選択している場合、リソース障害に起因するリソースの転送はすべてブロックされます。
この設定が有効の場合、以下のメッセージがログに記録されます。
Local recovery failure, failover blocked, MANUAL INTERVENTION REQUIRED
NFS クライアントのオプション
LifeKeeper で保護する NFS サーバを設定するときには、NFS クライアントがこのサーバに接続する方法が、フェイルオーバ時に再接続する速さに大きな影響を与えます。
NFS クライアントをマウントするときの考慮事項
NFS サーバは、クライアントコンピュータにネットワークベースのストレージシステムを提供します。このリソースを使用するには、クライアントシステムは、NFS サーバによりエクスポートされた、既に NFS であるファイルシステムを「マウント」する必要があります。NFS クライアントを LifeKeeper が保護する NFS リソースに接続する方法について、いくつかのオプションをシステム管理者は考慮する必要があります。
UDP または TCP の選択
NFS プロトコルは、ユーザデータグラムプロトコル (UDP) と伝送制御プロトコル (TCP) のいずれかを活用できます。.NFS は従来、クライアント / サーバの通信に UDP プロトコルを使用してきました。この理由の 1 つは、NFS が UDP プロトコルを使用してステートレス方式で動作するほうが容易だからです。この「ステートレス」であることが、高可用性のクラスタ化では重要です。これは、保護されている NFS サーバリソースがクラスタホスト間で切り替えられた場合に、クライアントを容易に認識できるからです。一般的に、LifeKeeper が保護する NFS リソースを操作するときには、UDP プロトコルが TCP よりも良好に動作する傾向があります。
/etc/exports の Sync オプション
LifeKeeper が保護する NFS リソースの場合、エクスポートオプションとして「 sync 」を指定することが推奨されます。「 sync 」オプションは、ディスクに書き込みを実行してから肯定応答を NFS クライアントに送信するように NFS に指示します。もう 1 つのオプションである「 async 」も使用できますが、このオプションを使用するとデータが破損するおそれがあります。これは、ディスクに書き込みを実行する前に NFS 書き込みの肯定応答をクライアントに送信するからです。NFS クライアントも、NFS ファイルシステムのマウント時にオプションとして「 sync 」を指定できます。
Red Hat EL6 (および Fedora 14) クライアントと Red Hat EL6 NFS サーバの使用
Red Hat EL6 用 NFS サーバのバグと思われるものにより、Red Hat EL6 (および Fedora 14) を実行する NFS クライアントは、NFS のバージョン (nfsvers) および UDP の両方をマウントコマンドに指定できません。これと同じ動作が、Ubuntu10.10 クライアントでも確認されています。この動作は、Red Hat EL6 NFS を使用する Red Hat EL5 クライアントでは確認されておらず、Red Hat EL5 NFS サーバを使用するすべてのクライアントで確認されていません。Red Hat EL6 (Fedora 14) クライアントと Red Hat EL 6 NFS サーバを使用するための NFS マウントディレクトリの最善の組み合わせは以下のとおりです。
mount <protected-IP>:<export> <mount point>
-o nfsvers=2,sync,hard,intr,timeo=1
- この組み合わせでは、LifeKeeper が保護する NFS サーバがスイッチオーバまたはフェイルオーバを実行する場合に、クライアントの再接続時間が最短になります。
Red Hat EL5 NFS クライアントと Red Hat EL6 NFS サーバの使用
Red Hat EL5 を実行する NFS クライアントと Red Hat EL6 NFS サーバを使用するときに、再接続時間が短い最善のオプションの組み合わせは以下のとおりです。
mount <protected-IP>:<export> <mount point>
-o nfsvers=3,sync,hard,intr,timeo=1,udp
このトピックへフィードバック