SIOS TECHNOLOGY CORP.

LifeKeeper Core – 既知の問題と制限

説明
“Incorrect SELinux configuration (<setting>). LifeKeeper can not startup”というメッセージが表示され、LifeKeeperが起動できない

ここでは、<setting>はSELinuxブール値であり、LifeKeeperには適さない設定です。 たとえば、SELinuxモードがEnforcingに設定されている場合、LifeKeeperを起動するには mmap_low_allowedを on に設定する必要があります。 その場合、メッセージは “Incorrect SELinux configuration (mmap_low_allowed=off). LifeKeeper can not startup.” になります。これはsetseboolユーティリティを使用して実行できます。

setsebool -P mmap_low_allowed=on
リカバリーキットをLifeKeeper Configuration Databaseからインストールしても対応したリソースタイプは削除されません。

症状: リソースタイプは対応したリカバリーキットがアンインストールされた後も /opt/LifeKeeper/bin/typ_list の出力に表示され続けることがあります。

解決方法: 有効なリソースタイプのリストを更新するためにLifeKeeperを再起動してください。
SELinux が“enforcing”に設定されており、SELinuxパラメーター“mmap_low_allowed”が“off”の場合、セットアップの実行時に次のメッセージが表示されます。

“SELinux appears to be set to Enforcing.

SELinux configuration changes are required to run LifeKeeper in Enforcing mode. If you continue setup, mmap_low_allowed will be changed in the SELinux configuration. If you exit setup, no changes will be made.”

<Continue> を選択すると、“mmap_low_allowed”が“off”に設定され、インストールが続行されます。 <Exit> を選択すると“mmap_low_allowed”は変更されず、LifeKeeperのインストールは中止されます。
SELinux が“permissive”に設定されており、SELinuxパラメーター“mmap_low_allowed”が“off”の場合、LifeKeeperをインストールするためのセットアップを実行すると、次のメッセージが表示されます。

“SELinux appears to be set to Permissive.

SELinux configuration changes are required to run LifeKeeper in Permissive mode. If you continue setup, mmap_low_allowed will be changed in the SELinux configuration. If you exit setup, no changes will be made.”

<Continue> を選択すると、“mmap_low_allowed”が“on”に設定され、インストールが続行されます。 <Exit> を選択すると“mmap_low_allowed”は変更されず、LifeKeeperのインストールは中止されます。
SELinux が“permissive”に設定されており、SELinuxパラメーター“mmap_low_allowed”が“off”の場合、LifeKeeperをアップグレードするためのセットアップを実行すると、次のメッセージが表示されます。

“SELinux appears to be set to Permissive.

SELinux configuration changes are required to run LifeKeeper in Permissive mode. The SELinux configuration should have mmap_low_allowed enabled to avoid errors being logged.”

構成の変更は行われません。 LifeKeeperプログラムの実行時にSELinuxエラーメッセージが記録されるのを避けるには、mmap_low_allowed を“on”に設定する必要があります。 これは、以下を実行することで実行できます。

setsebool -P mmap_low_enabled=true
ウイルス対策ソフトウェア – LifeKeeper for Linuxの除外事項

CrowdStrike

CrowdStrikeはnbdプロセスに干渉し、ミラーの同期が維持されなくなる可能性があります。

推奨設定

LifeKeeperに次のパス除外を追加します。
/usr/local/bin/nbd-client
/usr/local/bin/nbd-server
アンチウィルスソフトウェア – LifeKeeper for Linuxでの除外事項
注意：SIOSではSentinelOneを使用してテストを実施しています。

ウイルス対策ソフトが動作している環境でLifeKeeper for Linuxを使用すると、LifeKeeperが正常に動作しない場合があります。

推奨される対応

LifeKeeperに次のパス除外を追加します。
/opt/LifeKeeper/*
/var/log/lifekeeper*
/etc/default/LifeKeeper
/var/log/messages
/tmp/*

SAP HANAを使用している場合は、SAP HANAログディレクトリの場所を追加します。

DataKeeperの次のパス除外を追加します。
/usr/local/bin/nbd-client
/usr/local/bin/nbd-server
LifeKeeperがNBDモジュールをインストールするシステムでDataKeeperを使用する場合は、NBDモジュールを含めます。

オプションのパス除外：
/var/LifeKeeper
アンマウントの時間を増やすか、強制アンマウントが完了するまでの時間を減らす

特定の調整可能な値は、アンマウントにかかる時間を増やしたり、強制アンマウントが完了するまでの時間を減らしたりします。 このタイマーに寄与する3つの調整可能なパラメータがあります。

FS_UMOUNT_RETRIES (デフォルト値1)
FS_KERNEL_RETRIES (デフォルト値60). (この値を調整することを推奨します)
FS_UMOUNT_TIMEOUT (デフォルト値30)

Forceumount スクリプトの最大実行時間は、FS_KERNEL_RETRIES 調整パラメーターを操作することで短縮できます。 値を1下げる毎に、スクリプトの実行時間が3秒短くなります。

FS_UMOUNT_TIMEOUT (デフォルト値 30) は最大実行時間より大きい値を設定しないと機能しません。

最大実行時間 = ($FS_KERNEL_RETRIES * 3) + 3*($FS_UMOUNT_RETRIES + 3)
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に戻す必要があります。
カーネルのアップグレード後の新しいマウントオプションまたは非推奨のマウントオプション

Linuxカーネルをアップグレードすると、既存のファイルシステムマウントオプションの一部が新しいカーネルで非推奨になったり、新しいカーネルが新しいデフォルトマウントオプションを、既存のマウントに追加したりする可能性があります。 たとえば、“nobarrier“マウント オプションはRedHat Enterprise Linux 8で廃止され、一部のカーネルバージョンでは「logbufs=8」や「logbsize=32k」などの新しいデフォルトマウントオプションが追加されました。

LifeKeeperで保護されたファイルシステムリソースに、カーネルのアップグレード後に廃止されるマウントオプションが含まれている場合、廃止されたオプションは、クラスター内のすべてのサーバーでLifeKeeperリソースのマウントオプションのリストから削除する必要があります。詳細についてはLifeKeeper ファイルシステムリソースのマウントオプションの変更 を参照してください。

カーネルのアップグレード後に、LifeKeeperで保護された既存のマウントポイントに、カーネルによって新しいデフォルトのマウントオプションが追加された場合、クラスター内のすべてのサーバーでLifeKeeperリソースのマウントオプションのリストに、新しいオプションを追加する必要があります。詳細についてはLifeKeeperファイルシステムリソースのマウントオプションの変更 を参照してください。

シャットダウンストラテジーを「Do not Switchover Resources」（デフォルト）に設定している場合、LifeKeeperを停止した直後に起動しないでください。LifeKeeper停止から起動までの時間が短いと、スプリットブレインが発生する可能性があります。特にstorageモードのQuorum構成では、注意が必要です。

LifeKeeperの停止処理と起動処理で競合が発生し、スプリットブレインが発生する可能性があります。LifeKeeperを停止してから起動まで、数秒間の間隔を空けてください。storageモードのQuorum構成は停止処理に時間がかかるので、QWK_STORAGE_HBEATTIME * QWK_STORAGE_NUMHBEATS（デフォルト24秒）より長い時間を空ける必要があります。

ネットワークの接続などに問題が生じた場合、ネットワークを自動構成するサービスは停止してください

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」ツールを使用して実施できます。

注意: ディスクをパーティションに分割すると、ディスクにすでに保存されているデータはすべて破壊されます。

回避策: DataKeeper for Linuxトラブルシューティング を参照してください。

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

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

対応策: systemctl reload rsyslogを実行して、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を実行することを推奨します。
フェイルオーバー中にリソースが間違った順序で停止される
リソース階層が別のルート階層と共通のリソースインスタンスを共有している場合、カスケードフェールオーバーまたはリソースフェールオーバー中に、リソースが間違った順序で停止されることがあります。

回避策: 共通ルートを作成すると、階層内のリソースの停止が上から下に確実に行われます。

  1. restoreとremoveが常に成功するgen/appリソースを作成します。

  2. 現在のすべてのルートをgen/appリソースの子リソースとして依存関係を作成します。

注意: restoreおよびremoveスクリプトに /bin/true を使用することもできます。
ネストされたファイルシステム階層を削除すると、メッセージ「Object does not exist」が生成されます
解決方法 ：これは問題ではないので、メッセージを無視してかまいません。
ネストされたマウントの作成時にfilesyshier が正しくないタグを返します
ネストされたファイルシステムのリソースがデータベースに存在する場合、ファイルシステムキットは、親とネストされた子の両方にファイルシステムを作成します。ただし、filesyshier は子のタグのみを返します。これにより、アプリケーションは子の依存関係を作成しますが、親の依存関係は作成しません。
解決方法 ：1つのマウントポイント内で複数のファイルシステムがネストされている場合、dep_create または UI の [Create Dependency]を使用して、親アプリケーションタグの追加の依存関係を手動で作成しなければならないことがあります。
DataKeeper ：ネストされているファイルシステムの作成はDataKeeperで失敗します
既存のファイルシステムを複製するためにDataKeeperミラーを作成するときに、ファイルシステムがこの構造内でネストされている場合、ファイルシステムをアンマウントしてからファイルシステムリソースを作成する必要があります。
対応策 ：ネストされているファイルシステムを手動でアンマウントしてから、個々のネストされているマウントの再マウント / 作成を行ってください。
ファイルシステムリソースに保護されたデバイスのマウントポイントの変更は、データ破損を引き起こす可能性があります
ファイルシステムリソースに保護されたデバイスのマウントポイントは変更しないでください。変更した場合は、ファイルシステムリソースが仕様通りにデバイスを処理することができず、デバイスが２つのノードにマウントされて、データ破損を引き起こす可能性があります。
XFSファイルシステム使用時に、quickCheckに失敗することがあります
Red Hat Enterprise Linux7 / Oracle Linux7/ CentOS7にインストールしたLifeKeeperでCHECK_FS_QUOTAS設定を有効としたとき、保護するXFSファイルシステムリソースにuquota、gquotaオプションを設定すると、quickCheckに失敗します。
解決方法 ：XFSファイルシステムのマウントオプションにuquota、gquotaの代わりにusrquota、grpquotaをご使用ください。もしくは、CHECK_FS_QUOTAS設定を無効にしてください。
Btrfsはサポートしません
LifeKeeperをインストールするファイルシステム（/opt/LifeKeeper）にBtrfs（またはサポートされていないその他のLifeKeeper for Linuxファイルシステム）を使用することはできません。またビットマップファイルやその他 LifeKeeper に関連するファイルを置くファイルシステムにBtrfs（またはサポートされていないその他のLifeKeeper for Linuxファイルシステム）を使用することはできません。Btrfsファイルシステムをリソース保護することもできません。
対応策: Btrfsファイルシステムに /opt/LifeKeeper を配置するための簡単な回避策は、インスタンスに小さなディスクを追加し、ext4またはxfsでそのディスクをフォーマットし、このファイルシステムを /opt/LifeKeeper としてマウントすることです。
  1. /opt/LifeKeeper に使用する小さなディスクを作成します
    • ソフトウェアのインストールには最低110MBが必要です
    • 注意：Azureでは、最低1GBのデータディスクを作成できます。
    • 注意：追加のARKとミラーの数により、必要な合計スペースが増加する場合があります。

  2. ディスクがノードに追加されて表示されたら、ディスクをパーティションに分割します（またはlvmを使用します）。
    • 例：gdisk /dev/sdb
    • 注意：システムにディスクを追加する方法は、このKBAの対象範囲外です（お使いの環境については、自社のシステム管理者にお問い合わせください）

  3. サポートされているファイルシステムでパーティションをフォーマットします（詳細については、リリースノート を参照してください） 。
    • 例：mkfs.ext4 /dev/sdb1（sdb1は手順2で作成）

  4. 新しく作成され、フォーマットされたパーティションを /etc/fstab に追加し、システム起動時に自動的にマウントされるように設定します。

  5. 新しいパーティションを /opt/LifeKeeper としてマウントします
    • 例：mount /dev/sdb1 /opt/LifeKeeper
    • ファイルシステムがマウントされていることを確認します

  6. LifeKeeperをインストールします

  7. インストール後、/etc/fstab を編集してエントリを追加し、再起動時にディスクをマウントできるようにします
    • 例: /dev/sdb           /opt/LifeKeeper      ext4
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モードで利用している環境において、シャットダウンストラテジーを”Switchover Resources”に設定した場合
Quorum/Witness KitをWitnessモードで利用している環境において、シャットダウンストラテジーを”Switchover Resources”に設定した場合に、正しくスイッチオーバーが行われない場合があります。
解決方法: シャットダウン前に手動での切り替えを行ってください。
/etc/service ファイルの編集
/etc/service にある以下の行を削除するとLifeKeeperが起動できなくなります。


lcm_server 7365/tcp


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

注意: LifeKeeperをインストールすると、“lcm_server”（アンダースコア付き）が /etc/services に追加されます。これはLCMで使用されるポート番号を決定するために使用されます。一方で /etc/services には、“lcm-server”(ダッシュ付き) のエントリーもあります。 これらのエントリーはLCMでは使用されません。
SCSI ID にスペースを含む文字列を返すストレージユニットはLifeKeeperで保護できません
bind マウントはサポートしません
LifeKeeperで保護するファイルシステムには、bindマウント(mount --bind)を使用できません。
AWSやAzure上で動作するバージョン12以降のSLES環境において、クラウドネットワークプラグインによって仮想IPアドレスが削除されるのを防ぐために、ネットワークインターフェイスの構成ファイルを変更する必要があります。
詳細は こちら を参照してください。
$id の無効なサブディレクトリキャッシュが存在します

これにより、$idがマウント解除されず、リソースの削除が失敗する可能性があります。これは、NFSv3エクスポートのサブディレクトリをマウントするときの既知の問題が原因である可能性があります。

解決方法: サブディレクトリがマウントされないようにリソースを再構成します。エクスポートされたディレクトリのみをマウントする必要があります。

フィードバック

お役に立ちましたか?

はい いいえ
お役に立ちましたか
理由をお聞かせください
フィードバックありがとうございました

このトピックへフィードバック

送信