☰

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

ペースメーカーの構成：

[~] 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つのロードバランサーがあります。高可用性は、単純な接続維持構成と2つのVIP（デュアルアクティブ構成、通常は各LVSに1つのVIPがある）によって達成されました。しかし、一部の人々は最近定期的にDDoSを開始しており、接続の維持設定はもはや期待どおりに機能しません。 DDoS 1 VIP（たとえば、1つのホスト）がある場合でも、接続の維持は他のホストからのインバウンドトラフィックを失い、2番目のホストを占有します。 VIPになり、システム全体を弱めます。

そこで、a)分割ブレインを避けるために定足数でVIPを管理する方法を探し、b)LVSホストを少なくとも2倍に増やす方法を考えました.

それで、私は2つのプライマリノードと1つのスタンバイノードがあるときに設定するのが非常に簡単なPacemaker + corosyncをテストしました。予想どおり、VIP の 1 つが DDoSed 攻撃を受けると、VIP は最初に別のノードに移行され、その後完全にシャットダウンされます。ノードを追加すると、「リソースワーク」が長くなりますが、これはまさに私たちが望むものではありません。 VIPをできるだけ早く終了したいのですが、もちろん内部から自動的に回復する機会も残したいと思います。ハードウェアの問題（ノードが突然ダウンした場合はFE）。だから私は…リソースを一度だけ移行し、それでも失敗したら終了する方法があるかもしれないと思いました。ハードウェア障害から私たちを保護します。部分的な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

お役に立てば幸いです。

関連情報