Quorum loss action で “fastboot” を使用すると、Quorum 喪失後に Automatic switchback が成功しない場合がある 回避策: Quorum loss action の “fastboot”(QUORUM_LOSS_ACTION=fastboot)を使用する場合、サーバーは Quorum を失うと強制的に再起動されます。(詳細については、Quorum/Witness を参照してください。) サーバーがオンラインに戻ったときに、Automatic switchback を使用するように設定されたリソース階層が、LifeKeeper によって優先度の高いサーバーで自動的に In-Service に戻されない場合があります。 この場合、ユーザーは優先度の高いサーバーでリソース階層を手動で In-Service に戻す必要があります。 |
ネットワークの接続などに問題が生じた場合、ネットワークを自動構成するサービスは停止してください LifeKeeper を用いて IP アドレスを保護している環境では、avahi-daemon などのネットワークを自動構成するデーモンやサービスと IP リソースが 競合する場合があります。コミュニケーションパスの復旧や IP リソースの起動などに問題が生じた場合は、ネットワークを自動構成するサービスを停止してください。 |
ifconfig down や ip link down コマンドによるネットワークの切断はしないでください 仮想 IP リソースの保護対象となっているネットワークインタフェースがコミュニケーションパスでも使用されている場合、ネットワークインタフェースを ifconfig down や ip link down コマンドを実行して切断すると、再接続後もコミュニケーションパスが復帰しないことがあります。そのような操作は行わないでください。 |
マルチユーザーに設定された systemd ターゲットでは LifeKeeper は起動しません LifeKeeper を適切に機能させるためには、「systemctl set-default」 または「systemctl isolate」 を実行する時に、「lifekeeper-graphical.target」(グラフィカルモードの場合)または「lifekeeper-multi-user.target」(コンソールモードの場合)を使用する必要があります。通常の「graphical.target」 および「multi-user.target」 systemd ターゲットを使用しないでください。 |
ディスクのUUIDに関するDataKeeperの制限事項 バージョン9.5.0以降、DataKeeperはオペレーティングシステムにUUIDを提示しないディスクをミラーリングできなくなりました。このようなディスクをミラーリングする一番良い方法は、GPT(GUID Partition Table)でパーティションに分割することです。これは「parted」ツールを使用して実施できます。 注意: ディスクをパーティションに分割すると、ディスクにすでに保存されているデータはすべて破壊されます。 |
SLES 15では、ログのローテーション後に LifeKeeper のログが LifeKeeper ログファイルに表示されない場合があります コマンドラインで logrotate を実行した場合、またはログのサイズが原因でバックグラウンドでログのローテーションが発生した場合、LifeKeeper はロギングを停止します。 回避策: systemctl reload rsyslog を実行して、LifeKeeper のロギングを再開してください。 |
lkbackup を実行すると、LifeKeeperログにエラーが表示される場合があります このエラーメッセージは無視しても問題ありません。 |
ファイルシステムラベルは、大規模な設定で使用しないことを推奨します ファイルシステムラベルを使用すると、大きなクラスタの場合、起動時にパフォーマンスが低下する可能性があります。ラベルを使用するには、システムに接続されるすべてのデバイスをスキャンする必要があり、通常はその結果として問題が生じます。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パーティションを使用することで該当ディスクを認識できるようになります。 |
API アクセスに対するホスト名の指定 LifeKeeper サーバー認証情報の格納に使用するキー名は他の LifeKeeper サーバーのホスト名と 完全に 一致する必要があります (そのサーバーに対する hostname コマンドで表示されます)。ホスト名が FQDN の場合、認証キーは FQDN である必要があります。ホスト名が短縮名の場合、キーも短縮名にする必要があります。 回避策: credstore によって格納されたホスト名がホスト名と完全に一致していることを確認します。 |
リソースの作成後に lkbackup をリストアすると、破損したイクイバレンシが残されます 作成したリソースの設定ファイルは lkbackup 中に保存されます。lkbackup でバックアップした後に初めて作成したリソースは、このバックアップからリストアする際に適切に把握されない可能性があります。 回避策: 新しいリソースを初めて追加する前に lkbackup からリストアしてください。新しいリソースが lkbackupの後で追加された場合、リストアの前に削除するか、リソースの階層のインスタンスを削除し、リストアの後で階層を再拡張してください。 注意 : 特定のリソースを初めて作成する際に lkbackup を実行することを推奨します。 |
フェイルオーバー中にリソースが間違った順序で停止される リソース階層が別のルート階層と共通のリソースインスタンスを共有している場合、カスケードフェールオーバーまたはリソースフェールオーバー中に、リソースが間違った順序で停止されることがあります。 回避策: 共通ルートを作成すると、階層内のリソースの停止が上から下に確実に行われます。
注意: restoreおよびremoveスクリプトに /bin/true を使用することもできます。 |
ネストされたファイルシステム階層を削除すると、メッセージ「Object does not exist」が生成されます 回避策: これは問題ではないので、メッセージを無視してかまいません。 |
ネストされたマウントの作成時に filesyshier が正しくないタグを返します ネストされたファイルシステムのリソースがデータベースに存在する場合、ファイルシステムキットは、親とネストされた子の両方にファイルシステムを作成します。ただし、filesyshier は子のタグのみを返します。これにより、アプリケーションは子の依存関係を作成しますが、親の依存関係は作成しません。 回避策: 1 つのマウントポイント内で複数のファイルシステムがネストされている場合、dep_create または UI の [Create Dependency] を使用して、親アプリケーションタグの追加の依存関係を手動で作成しなければならないことがあります。 |
DataKeeper: ネストされているファイルシステムの作成は DataKeeper で失敗します 既存のファイルシステムを複製するために DataKeeper ミラーを作成するときに、ファイルシステムがこの構造内でネストされている場合、ファイルシステムをアンマウントしてからファイルシステムリソースを作成する必要があります。 回避策: ネストされているファイルシステムを手動でアンマウントしてから、個々のネストされているマウントの再マウント / 作成を行ってください。 |
ファイルシステムリソースに保護されたデバイスのマウントポイントの変更は、データ破損を引き起こす可能性があります ファイルシステムリソースに保護されたデバイスのマウントポイントは変更しないでください。変更した場合は、ファイルシステムリソースが仕様通りにデバイスを処理することができず、デバイスが2つのノードにマウントされて、データ破損を引き起こす可能性があります。 |
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 (またはサポートされていないその他の SPS for Linux ファイルシステム)を使用することはできません。またビットマップファイルやその他 LifeKeeper に関連するファイルを置くファイルシステムに Btrfs (またはサポートされていないその他の SPS for Linux ファイルシステム)を使用することはできません。 Btrfs ファイルシステムをリソース保護することもできません。 回避策: Btrfs ファイルシステムに /opt/LifeKeeper を配置するための簡単な回避策は、インスタンスに小さなディスクを追加し、ext4 または xfs でそのディスクをフォーマットし、このファイルシステムを /opt/LifeKeeper としてマウントすることです。
|
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"が無効になっているにもかかわらず、ホスト名が変更されることがあります。 回避策:
|
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 で保護できません |
bind マウントはサポートしません LifeKeeper で保護するファイルシステムには、bind マウント (mount --bind) を使用できません。 |
AWSやAzure上で動作するバージョン12以降のSLES環境において、クラウド ネットワーク プラグインによって仮想 IP アドレスが削除されるのを防ぐために、ネットワーク インターフェイスの構成ファイルを変更する必要があります。 詳細は こちら を参照してください。 |
log ID 4739 – ミラー再同期の回復イベントによって、スイッチオーバーのコア階層リザベーションロックがリセットされると、スイッチオーバー要求が失敗します。 スイッチオーバーが正常に完了し、ロックを解除しようとしたときに別のプロセスによって所有されていると検知し、正常に復元されたにもかかわらず、切り替えに失敗してルートリソースに失敗とマークされます。 回避策: RESRVRECTIMEOUT の値を調整します。RESRVRECTIMEOUT が 600 よりも高くなった場合、RESRVTIMEOUT の値もそれに合わせて高くする必要があります。 注意: RESRVRECTIMEOUT および RESRVTIMEOUTのタイムアウトを設定する場合、値はリソースの数と階層内の各リソースのタイプによって大きく異なります。この値には、現在のソースノードで各リソースを停止する時間と、新しいソースノードで各リソースを復元する時間が含まれている必要があります。リソースのリストアと削除の時間はクラスタや時間によって異なるため、これらの調整値の推定値を得るには、次の手順に従います。 調整の手順:
RESRVRECTIMEOUTの「x」値 > 600であれば、RESRVTIMEOUTを x に設定する。 [もし x >600なら、x = y] 。 |
このトピックへフィードバック