Pacemaker / Corosyncリソースのクリーンアップにより、Ubuntu（任意のバージョン）で再起動します
Ubuntu（12.04/14.04/16.04および18.04）のペースメーカー/コロシンク（2ノード）クラスターに問題があり、見つかりませんでしたこの問題を説明している他の人。 ressourceには、res_ip（仮想IP）とres_Apache（Apache2）の2つがあります。これらは単なるリソースの例です。この問題は、あらゆる種類の相互に関連する/同じ場所に配置されたリソースで発生します。
Res_Apacheはres_ipと同じ場所に配置され、仮想IPを介して利用できる「アクティブ」サーバーでApacheを常に実行できるようにします。 res_ipが失敗して再起動する場合があります。これにより、res_Apacheも（予想どおりに）再起動し、failcountが残ります。
問題：リソースres_ip（crmリソースクリーンアップres_ip）をクリーンアップしようとするとres_Apache（res_ipによって異なります）を再起動しますが、理由はわかりません。
CentOSで同じコマンドを実行しても、Webアプリケーションの操作が中断されることはありません。このコマンドは、失敗数をクリーンアップするだけです。
添付のnode1_corosync.log.extract.txtは、res_ipがstopped（951行目）として認識され、依存するres_Apacheが再起動されることを示しています。クリーンアップコマンドはその頃（15:18:17）に実行されるため、リソースが実行されているかどうかのチェックは、クリーンアップコマンドによって開始されると思います。 'stopped'状態であってはならないため、依存リソースres_Apacheを再起動しないでください。
繰り返しになりますが、この問題はすべてのUbuntuリリースで発生しますが、CentOSでは発生せず、リソースの種類は重要ではないことを指摘する必要があります。
なぜこれが起こるのか（そしてUbuntuでのみ起こる）誰かアイデアはありますか？
ログファイルと設定： https://1drv.ms/u/s!Av4S568oLfJmgZtQ6pcE40FOKN8yDg?e=IOHKX8
（あなたはソフトウェアのメーリングに参加しているはずです（そこで試しましたか？）実際に使用し、最初にそこで探してヘルプを提供します！）以下はclusterlabメーリングリストからの抜粋です。クラスターのバージョンからバージョンへ）......。
「pcsresourcecleanup Res1」と呼ぶと、Res2側でサービスが中断されます（つまり、Res2を停止します…）。私の–未確認–仮定は、ペースメーカーが最初にリソースの現在の状態を検出するというものでした。モニターを呼び出し、実行するアクションがあるかどうかを決定します。しかし、ログファイルの読み取りから、Res1が一時的にcibから削除され、再度挿入されたと解釈します。そしてこれにより、Res1が状態「開始」を確認するまでRes2を停止します。
正解です。リソースの操作履歴を削除すると、ペースメーカーが現在のステータスの再プローブをトリガーします。
ドキュメントを解釈すると、kind = Optionalで順序制約を構成することにより、この動作を回避することができます。しかし、これが他の不当な副作用を引き起こすかどうかはわかりません。 （停止時の逆順など）
kind =オプションの制約は、両方のアクションを同じ遷移で実行する必要がある場合にのみ適用されます。つまり単一のクラスターチェックでRes1とRes2の両方を開始する必要があることが判明した場合、Res1はRes2の前に開始されます。ただし、Res2は、Res1がまだ停止している状態で、以前の遷移で開始でき、その後の遷移でRes1が開始される可能性があります。同様に、停止するとき、両方を停止する必要がある場合は、Res2が最初に停止します。
元のシナリオでは、マスター/スレーブリソースが稼働した後にのみIPにバインドする場合、kind = Optionalは信頼できません。ただし、マスター/スレーブリソースがワイルドカードIPにバインドされている場合、順序は実際には重要ではありません。コロケーション制約を維持し、順序を削除できます。
別の回避策は、依存リソースを管理対象外に設定し、クリーンアップを実行してから管理対象に戻すことです。
これは、必須の順序を維持する必要がある場合に私がお勧めするものです。
そして、状態の変更が必要ない場合、「pcs resource failcount reset」が実行されるアクションなしでトリックを実行するのだろうかと思います。しかし、私たちはすでにこれを時々試したことがあることを覚えていると思います。失敗したリソースは、failcountのリセット後に開始されないことがありました。 （しかし、確信が持てず、再現する時間もありませんでした。）
いいえ、新しいペースメーカーバージョンでは、crm_failcount --deleteはcrm_resource --cleanupと同等です。 （pcsは実際に作業を実行するためにこれらを呼び出します）
この問題を正しく理解するのに役立つ可能性のある、より深い洞察はありますか？
これは、現在のCIB実装の副作用です。 Pacemakerのポリシーエンジンは、CIBでの操作履歴をチェックすることにより、リソースの現在の状態を判別します。クリーンアップにより操作履歴が削除されるため、現在の状態が不明になり、再プローブが強制されます。副次的な影響として、再プローブが完了するまで、依存関係の制約は満たされなくなります。
現在の状態の決定を変更しない限り、リソースの失敗カウントをクリアし、失敗した操作の操作履歴エントリのみを削除する「古い失敗のクリーンアップ」オプションを実装することは理論的には可能です。しかし、これはかなり複雑になるため、リソースを管理対象外に設定するのは簡単な回避策です。
>