PCを使用したRHEL高可用性クラスタ、サービスをリソースとして構成

PCを使用したRHEL高可用性クラスタ、サービスをリソースとして構成

RHEL 6.9には2ノードクラスタがあります。/etc/init.d/myApplication呼び出すサービスによって生成されたシェルスクリプトを介して起動するアプリケーションを生成するのに問題があることを除いて、すべてが構成されました。「マイアプリ」。そのアプリでpcs resource create myApp lsb:myApp op monitor interval=30s op start on-fail=standby私はこのセットを使い始めましたが、仕事用です。必要なのは、このアプリケーションを手動で起動する必要があるため、両方のノードで同時に起動することです。したがって、最初のノードが失敗した場合は、パッシブノードでまだアクティブでない場合は介入が必要です。

2つの異なるサービスがあります。
-VirtIP (ocf:heartbeat:IPaddr2)アプリケーションサーバーへのサービスIPの提供
-Cron (lsb:crond)アプリケーションファイルの同期(共有ストレージを使用しない)

myAppにホストして、VirtIPとCronを依存関係として使用しています。

マスター/スレーブとレプリケーションの両方を試しましたが、その構成について何かを見逃したようです。アプリケーションをオフラインにすると、Pacemakerはサービスがダウンしていることを検出せず、pcs statusmyAppがノード(または私の設定に従ってノード)で実行され続けていると出力します。また、パッシブノードのペースメーカーによってアプリケーションを実行しているサービスが停止することもあります。

どのように設定する必要がありますか? RHEL文書を読んだが、まだ止まっている。 myAppサービスが失敗した場合にペースメーカーにフェイルオーバーを開始させるにはどうすればよいですか?場合によっては、サービスが停止したことを検出できない理由がわかりません。

編集:したがって、テスト目的で開始/再起動のパスワード要件を削除し、サービスが正常に開始/再起動され、管理対象の依存リソースが期待どおりに停止/開始されました。ただし、myAppサービスを停止すると、停止したリソースには反映されず、起動されたノード1にのみ保持されます。同様に、ノード1をスタンバイ状態に切り替えてフェイルオーバーをシミュレートすると、ノード1のすべてのリソースのみが停止します。

答え1

私の考えでは、シェル/初期化スクリプトが正しい戻りコードを返さないようです。 Pacemakerがinitスクリプトとうまく機能するためには、initスクリプトはLSBと完全に互換性がなければなりません。ここで互換性チェックでinitスクリプトを実行してください。http://www.linux-ha.org/wiki/LSB_Resource_Agents

あなたのスクリプトは0を返すべきではありませんが、0を返すようです。

答え2

私はこの問題に直面しました。コンピュータは、リソースの状態が悪化したときにそれを認識できません。この記事では、「開始済み」および「停止済み」の状態を確認するように構成する方法があるようです。

https://clusterlabs.org/pacemaker/doc/deprecated/en-US/Pacemaker/2.0/html/Pacemaker_Explained/s-resource-monitoring.html

Pacemakerは、リソースを初めて起動するときに1回の監視タスク(プローブと呼ばれる)を実行して、リソースが存在する場所で実行されていない場所で実行されていることを確認します。 (この動作はリソース検索位置制約属性の影響を受ける可能性があります。)これらの初期プローブに加えて、Pacemakerはデフォルトでリソースが正常であるかどうかをチェックしません。 ⁠これらの検査を実行するには、モニタージョブを明示的に構成する必要があります。

継続的な監視のためにリソースを構成する方法は次のとおりです。

pcs resource update CoreVIP op monitor interval=60s OCF_CHECK_LEVEL=5 role=Started
pcs resource update CoreVIP op monitor interval=61s OCF_CHECK_LEVEL=5 role=Stopped

関連情報