LifeKeeper Core - 既知の問題と制限

SLES 15では、ログのローテーション後に LifeKeeper のログが LifeKeeper ログファイルに表示されない場合があります

コマンドラインで logrotate を実行した場合、またはログのサイズが原因でバックグラウンドでログのローテーションが発生した場合、LifeKeeper はロギングを停止します。

対応策: systemctl reload rsyslog を実行して、LifeKeeper のロギングを再開してください。 

lkbackup を実行すると、LifeKeeperログにエラーが表示される場合があります

lkbackup[30809]: ERROR:lkbackup:::010064:Possible Configuration error: More than one LifeKeeper version is installed on this host

このエラーメッセージは無視しても問題ありません。 

RHEL 8.0では、すべてのメッセージが /var/log/lifekeeper.log に2回記録されます

/etc/rsyslog.conf ファイルの構成が正しくないため、すべてのメッセージがログファイルに2回表示されます。

対応策: /etc/rsyslog.conf を編集し、次のようにファイルの最後の行をコメントアウトしてください。

# $IncludeConfig /etc/rsyslog.d/lifekeeper.conf

rsyslogを再起動します。

systemctl restart rsyslog 

ファイルシステムラベルは、大規模な設定で使用しないことを推奨します

ファイルシステムラベルを使用すると、大きなクラスタの場合、起動時にパフォーマンスが低下する可能性があります。ラベルを使用するには、システムに接続されるすべてのデバイスをスキャンする必要があり、通常はその結果として問題が生じます。SAN に接続されているシステム、特にデバイスへのアクセスがブロックされている LifeKeeper が導入されているシステムの場合、このスキャニングは非常に遅くなる可能性があります。 

Red Hat システムでこのパフォーマンスの問題を防ぐには、/etc/fstab を編集し、ラベルをパス名に置き換えます。 

lkscsid は、一部環境においてディスク障害時にシステムを停止します

lkscsid がディスク障害を検出すると、デフォルトでは sendevent を LifeKeeper に発行し、障害から復旧しようとします。sendevent はまず、ローカルで障害から復旧しようとします。それに失敗すると、ディスクの階層を別のサーバに切り替えて障害から復旧しようとします。一部のバージョンの Linux (SLES11) では、lkscsid は sendevent を発行できないため、代わりにすぐにシステムを停止します。これは、/dev/sda などの SCSI デバイスノードを使用している階層にのみ影響します。

DataKeeper の Create Resource が失敗します

特定の環境 (IDE ディスクエミュレーションを使用する仮想環境、HP CCISS ストレージを装備したサーバなど) で DataKeeper を使用している場合、ミラーの作成時にエラーが発生することがあります。

ERROR 104052: Cannot get the hardware ID of the device “dev/hda3”

この原因は、LifeKeeper が該当ディスクを認識せず、デバイスに関連付けられている一意の ID を取得できないからです。  

対応策: GUIDパーティションを使用することで該当ディスクを認識できるようになります。もしくはディスクのパターンを DEVNAME device_pattern ファイルに追加します。次に例を示します。

# cat /opt/LifeKeeper/subsys/scsi/resources/DEVNAME/device_pattern
/dev/hda*

API アクセスに対するホスト名の指定

LifeKeeper サーバ認証情報の格納に使用するキー名は他の LifeKeeper サーバのホスト名と 完全に 一致する必要があります (そのサーバに対する hostname コマンドで表示されます)。ホスト名が FQDN の場合、認証キーは FQDN である必要があります。ホスト名が短縮名の場合、キーも短縮名にする必要があります。

対応策: credstore によって格納されたホスト名がホスト名と完全に一致していることを確認します。

8.2.0 より前のバージョンの LifeKeeper の lkbackup を使用する場合は、それ以降のバージョンでリストアするときに /etc/default/LifeKeeper を手動で更新する必要があります

LifeKeeper/SPS の現在のバージョンでは、ロギングなどの主要なコアコンポーネントに対して大幅な機能強化が加えられています。これらの機能強化は /etc/default/LifeKeeper ファイルの設定に影響します。旧バージョンの LifeKeeper/SPS で作成した lkbackup を新しいバージョンの LifeKeeper/SPS でリストアすると、これらの設定値が正しくなくなり、矛盾が発生します。

解決方法: lkbackup をリストアする前に、/etc/default/LifeKeeper を保存してください。lkbackup からリストアした後、以下のチューニングパラメータにマージします。

8.0.0 より前のバージョンから取得した lkbackup を使用して、8.0.0 以降でリストアする場合:

LKSYSLOGTAG=LifeKeeper

LKSYSLOGSELECTOR=local6

9.0.1より前のバージョンから取得した lkbackup を使用して、9.0.1以降でリストアする場合:
PATH=/opt/LifeKeeper/bin:/usr/java/jre1.8.0_51/bin:/usr/java/bin:/usr/java/jdk1.8.0_51/bin:/bin:/usr/bin:/usr/sbin:/sbin
詳細については、syslog でのロギング を参照してください。

リソースの作成後に lkbackup をリストアすると、破損したイクイバレンシが残されます

作成したリソースの設定ファイルは lkbackup 中に保存されます。lkbackup でバックアップした後に初めて作成したリソースは、このバックアップからリストアする際に適切に把握されない可能性があります。

解決方法: 新しいリソースを初めて追加する前に lkbackup からリストアしてください。新しいリソースが lkbackupの後で追加された場合、リストアの前に削除するか、リソースの階層のインスタンスを削除し、リストアの後で階層を再拡張してください。 注記 : 特定のリソースを初めて作成する際に lkbackup を実行することを推奨します。

フェイルオーバ時に誤った順序でリソースが停止されます

階層が共通リソースインスタンスを別のルート階層と共有している場合、カスケーディングフェイルオーバまたはリソースフェイルオーバの間、リソースは誤った順序で停止されることがあります。

解決方法: 共通ルートを作成すると、階層のリソースの停止がトップダウンで実行されます。

1. restore と remove を常に進める gen/app を作成します。
   
   
2. 現在のルートをすべて、この新しい gen/app の子にします。
   
   

/var/run/utmp kr
sbin.syslog-ng に追加すると、(再起動することなく) 既存の AppArmor の定義を以下の定義で置き換えることができます。

apparmor_parser -r /etc/apparmor.d/sbin.syslog-ng
以下のコマンドで EMERG syslog エントリを送信し、AppArmor が更新されたことを確認してください。
logger -p local6.emerg "This is a syslog/lk/apparmor test."

RHEL 6.0 は推奨されません

RHEL 6.0 の使用はできるだけ避けてください。RHEL 6.0 を使用する場合、以下のような問題 (これらに限定されません) を解決するために OS のアップデートが必要になることを理解してください。

• EMC CLARiiON において、DMMP はケーブルの抜線からの復旧に失敗します ( RHEL 6.1 で修正済み )。
  
  
• md のリカバリプロセスがハングします ( RHEL 6.1 のカーネルの最初のアップデートで修正済み )
  
  

ネストされたファイルシステム階層を削除すると、メッセージ「Object does not exist」が生成されます

解決方法: これは問題ではないので、メッセージを無視してかまいません。

ネストされたマウントの作成時に filesyshier が正しくないタグを返します

ネストされたファイルシステムのリソースがデータベースに存在する場合、ファイルシステムキットは、親とネストされた子の両方にファイルシステムを作成します。ただし、filesyshier は子のタグのみを返します。これにより、アプリケーションは子の依存関係を作成しますが、親の依存関係は作成しません。

解決方法: 1 つのマウントポイント内で複数のファイルシステムがネストされている場合、dep_create または UI の [Create Dependency] を使用して、親アプリケーションタグの追加の依存関係を手動で作成しなければならないことがあります。

DataKeeper: ネストされているファイルシステムの作成は DataKeeper で失敗します

既存のファイルシステムを複製するために DataKeeper ミラーを作成するときに、ファイルシステムがこの構造内でネストされている場合、ファイルシステムをアンマウントしてからファイルシステムリソースを作成する必要があります。

対応策: ネストされているファイルシステムを手動でアンマウントしてから、個々のネストされているマウントの再マウント / 作成を行ってください。

lkstart on SLES 11 SP2 generates insserv message

SLES 11 SP2 で lkstart の実行中に、以下の insserv メッセージが生成されます。

insserv: Service syslog is missed in the runlevel 4 to use service steeleye-runit

LifeKeeper と steeleye-runit のスクリプトは、デフォルトで実行レベル 4 で起動するように設定されていますが、依存する init スクリプトの syslog はそのように設定されていません。システムの実行レベルが 4 に変更された場合、syslog は終了し LifeKeeper はロギングができなくなります。

解決方法: システムの実行レベルを絶対に実行レベル 4 に変更しないでください。

ファイルシステムリソースに保護されたデバイスのマウントポイントの変更は、データ破損を引き起こす可能性があります

ファイルシステムリソースに保護されたデバイスのマウントポイントは変更しないでください。変更した場合は、ファイルシステムリソースが仕様通りにデバイスを処理することができず、デバイスが２つのノードにマウントされて、データ破損を引き起こす可能性があります。

XFSファイルシステム使用時に、quickCheckに失敗することがあります

Red Hat Enterprise Linux 7 / Oracle Linux 7 / CentOS 7 にインストールしたLifeKeeper で CHECK_FS_QUOTAS 設定を有効としたとき、 保護する XFS ファイルシステムリソースに uquota、gquota オプションを設定すると、quickCheck に失敗します。 解決方法: XFSファイルシステムのマウントオプションに uquota、gquota の代わりにusrquota、grpquota をご使用ください。 もしくは、CHECK_FS_QUOTAS 設定を無効にしてください。

Btrfs はサポートしません

LifeKeeper をインストールするファイルシステム（/opt/LifeKeeper）に Btrfs を使用することはできません。またビットマップファイルやその他 LifeKeeper　に関連するファイルを置くファイルシステムに 　Btrfs　を使用することはできません。 Btrs　ファイルシステムをリソース保護することもできません。

AWS 上で SLES12SP1以降を用いた場合に発生する問題

・静的ルーティング設定ができない

　/etc/sysconfig/network/routes に静的ルーティングが設定されている場合、DHCPにより自動で割り当てられたIPアドレスを用いた通信に失敗することがあります。

　解決方法: /etc/sysconfig/network/ifroute-ethX の ROUTE を正しく設定し、ルーティング情報を更新してください。

・"Change Hostname via DHCP"が無効になっているにもかかわらず、ホスト名が変更される

　LifeKeeper はホスト名が変更された場合正しく動作しません。AWS上で動作するSLES12SP1以降において、"Change Hostname via DHCP"が無効になっているにもかかわらず、ホスト名が変更されることがあります。

　解決方法:

• /etc/cloud/cloud.cfg にて update_hostname をコメントアウトしてください
  
  
• /etc/cloud/cloud.cfg にて preserve_hostname に true を設定してください
  
  
• /etc/sysconfig/network/dhcp にて DHCLIENT_SET_HOSTNAME を no に設定してください

Quorum/Witness Kit を Witness モードで利用している環境において、Shutdown Strategy を ”Switchover Resources” に設定した場合

Quorum/Witness Kit を Witness モードで利用している環境において、Shutdown Strategy を ”Switchover Resources” に設定した場合に、正しくスイッチオーバーが行われない場合があります。

解決方法: シャットダウン前に手動での切り替えを行ってください。

/etc/service ファイルの編集

/etc/service にある以下の行を削除すると LifeKeeper が起動できなくなります。

lcm_server 7365/tcp

このファイルを編集する場合は、この行を削除しないように注意してください。

SCSI ID にスペースを含む文字列を返すストレージユニットは LifeKeeper で保護できません

RHEL6.x において、ボンディングを用いた場合ケーブルの挿抜でネットワークが自動で復旧しない問題について

RHEL6.x において、ネットワークケーブルの再接続やネットワーク機器の故障、ifdown -> ifupなどによりボンディングインターフェースがリンクダウンした場合、ネットワークを自動的に復帰させることができません。

この状態から復帰するためには、root権限で以下のコマンドを実行してください。

# service network restart

なお、RHEL7系ではこの問題は修正されています。

またSLES系では本問題は発生しません。

bind マウントはサポートしません

LifeKeeper で保護するファイルシステムには、bind マウント (mount --bind) を使用できません。