web-dev-qa-db-ja.com

Linuxペースメーカー-スプリットブレインを防ぐ

centOS 7を使用してから、通常のハートビート設定からペースメーカーに切り替えました。

主に、1つのノードでアクティブでフェイルオーバーが発生した場合に2番目のノードに切り替えるIPリソースがあります。また、フェイルオーバーの場合にいくつかのスクリプトを実行します。特にない。

リソースが常にプライマリノードで開始されるようにするには、

pcs constraint location Cluster_IP prefers server1=master-server

私も使っています

pcs resource defaults resource-stickiness=INFINITY

フェイルオーバー後にリソースが戻るのを防ぐため。

マスターに障害が発生した場合（ハードウェア障害など）、これは問題なく機能します。

フェイルオーバーに時間がかかっても問題ないので、スプリットブレインが短い場合に備えて、なんらかの遅延を実装したいと思います。

何かをする前に、スレーブは、マスターがこの約2分以内に再び到達可能になった場合に備えて、引き継ぐ前に約2分待つ必要があります。

私はそれをするための最良の方法は何でしょうか？

linuxpacemaker
1
sebkoe

Corosyncでトークンタイムアウトを10秒を超える値に設定したことはありませんが、corosync.confのtoken値を120000（ミリ秒で120秒）に増やしたり設定したりしてみてください。 。 tokenは、totem{}のcorosync.confセクションで定義する必要があります。詳細については、man corosync.confを参照してください。

これにより、ネットワークがフレークアウトしたときにCorosyncがノードが120秒間停止したと宣言するのを防ぐことができます。

0
Matt Kereczman

リソースの監視間隔はop monitor interval=Nsで変更できます。ここで、Nは秒数で、リソースのmigration-thresholdを2に設定します。 120sの設定では、監視間隔で最初の障害が発生した時期に応じて、合計で120〜240秒の遅延が発生する可能性があることに注意してください。

migration-thresholdに適用された失敗カウンターが成功してもリセットされないという点で、これには他にも注意点があります。これを行うには、failure-timeoutを設定するか、手動で介入する必要もあります。

op monitor interval=120s、migration-threshold=2、failure-timeout=121sおよびresource-stickiness設定を使用して、これが期待する機能を提供し、元のマスターの場合の障害カウンターの動作を確認するためにテストする必要があります。回復します。手作業による介入が必要になる可能性がありますが、100％確実ではありません

0
brent