☰

Pacemaker: フェイルオーバーにより N 回移行した後にリソースを停止する

tag-icon • tag-icon cluster pacemaker
Pacemaker: フェイルオーバーにより N 回移行した後にリソースを停止する

5 つのノード (リソースをホストできるノード 4 つとリソース 1 つ) の構成があります。 実行したいのは、ノード間で N 回移行した後、リソースを完全に停止させることです。

したがって、サンプルのシナリオは次のようになります。リソース VIP1 がノード で実行されていますone。そのモニターが失敗し、migration-thresholdに到達し、ノードtwoに移動します。その後、そこで再び失敗し、ノード に移動しますthree。その後、再び失敗しますが、何らかのルール (探しているもの) により、ノード への移行が妨げられますfour。何らかの移行カウンターが必要だと思います。

これはテスト構成です。実際には、ノードとリソースの数が増えます。そのため、構成はできるだけシンプルにしたいと思っています。各リソースに対してオプトインまたはオプトアウトの場所優先戦略を使用してこれを実現できると考えていますが、シンプルでも保守も容易でもありません。もっと良い方法はありますか?

PS 現在の構成では、VIP を でフラッドするとhping、完全に停止する前にすべてのノードを循環します (クリーンアップするかオプションを導入するまで、実行するノードがなくなるためfailure-timeout)。

バージョン:

[~] corosync -v
Corosync Cluster Engine, version '2.3.6'
Copyright (c) 2006-2009 Red Hat, Inc.
[~] crm --version
crm 2.2.0
[~] cat /etc/debian_version
8.5

Pacemaker の構成:

[~] crm configure show
node 1: one
node 2: two
node 3: three
node 4: arbitr \
        attributes standby=on
node 5: four
primitive VIP1 IPaddr2 \
        params ip=10.10.11.230 cidr_netmask=22 \
        op monitor interval=1s timeout=40ms \
        meta migration-threshold=1 target-role=Started
location preferOne VIP1 50: one
property cib-bootstrap-options: \
        dc-version=1.1.14-70404b0 \
        cluster-infrastructure=corosync \
        cluster-name=debian \
        stonith-enabled=false \
        last-lrm-refresh=1474984960 \
        have-watchdog=false

編集: 構成全体の背景と経緯は次のとおりです。フロントエンドへのトラフィックをプロキシする LVS を備えた 2 つのロード バランサーがあります。高可用性は、以前は単純な keepalived 構成と 2 つの VIP (アクティブ/アクティブ構成。通常の状況では、各 LVS に 1 つの VIP があります) で実現されていました。しかし、最近、何人かの人が定期的に DDoS 攻撃を開始し、keepalived セットアップは期待どおりに機能しなくなりました。1 つの VIP、つまり 1 つのホストのみに DDoS 攻撃を行った場合でも、keepalived は別のホストからの受信トラフィックを失い、2 番目の VIP を奪い、システム全体を機能不全にします。

そこで私たちは、a) スプリットブレインを回避するためにクォーラムで VIP を管理する方法を見つける、b) LVS ホストを少なくとも 2 倍にする、と考えました。

そこで pacemaker+corosync をテストしてみましたが、アクティブ ノードが 2 つ、スタンバイ ノードが 1 つある場合の構成は非常にシンプルです。予想どおり、VIP の 1 つが DDoS 攻撃を受けると、その VIP はまず別のノードに移行し、その後完全にシャットダウンします。ノードを追加すると、その「リソース ウォーク」が長くなりますが、これは私たちが望んでいることではありません。VIP はできるだけ早くシャットダウンする必要がありますが、もちろん、内部のハードウェアの問題 (ノードが突然ダウンした場合、FE) から自動的に回復する機会も残しておきたいものです。そこで、リソースを 1 回だけ移行し、それでも失敗する場合は、それで終了する方法があるのではないかと思いました。ハードウェア障害から私たちを救い、部分的な DDoS 攻撃を受けているときに時間を節約します。

以上です。あまりに複雑でしたら申し訳ありません。最初からこれに対処するために間違った手段を選択したのであれば、お知らせください。(もちろん、他の方法で DDoS から防御していますが、攻撃が突破された場合は、被害を最小限に抑えたいと考えています)。

答え1

それは間違いなく興味深い使用例です。共有していただきありがとうございます...

VIP が DDoS 攻撃を受けている間は、確実に ping を実行できない可能性があります。Pacemaker の「ping」リソース エージェントを調べてみてください。

clusterlabs のドキュメントでは、これについて次のように簡単に説明しています。 http://clusterlabs.org/doc/en-US/Pacemaker/1.0/html/Pacemaker_Explained/ch09s03s03.html

詳細については、お好みのクラスター構成管理ツールを使用してリソース エージェントの情報を確認してください。

# crm ra info ping
--or--
# pcs resource describe ping

参考になれば幸いです。

関連情報