web-dev-qa-db-ja.com

CentOS 7：PCS PacemakerCorosyncアクティブ/アクティブHAProxyの依存関係

アクティブ/アクティブ構成のCentOS7でHAProxy用のPCSをセットアップしようとしています。以前にアクティブ/アクティブを実行したことがありますが、制約と依存関係グループに精通していません。

ここまでは順調ですね：

 2 nodes configured
 4 resources configured

 Online: [ Host1 Host2 ]

 Full list of resources:

  Clone Set: VIPHA-clone [VIPHA] (unique)
      VIPHA:0     (ocf::heartbeat:IPaddr2):       Started Host2
      VIPHA:1     (ocf::heartbeat:IPaddr2):       Started Host1
  Clone Set: haproxy-clone [haproxy]
      Started: [ Host2 Host1 ]

ただし、ここで、IPがホストによって提供されるためにHAPRoxyが実行されている必要があるという制約を追加したいと思います。

pcs制約順序haproxy-clone、次にVIPHA-clone

これに伴う問題は、HAProxyが最初に開始されない限り、IPにバインドできないため、HAProxyが開始されないことです。

これを次のように設定するにはどうすればよいですか。

  1. ヘルスチェック（つまり、haproxyプロセスの実行）が失敗した場合、PCはホスト上でIPをオフラインにしますか？

  2. pCは、ヘルスチェック（つまり、haproxyプロセスの実行）が成功した場合にのみIPを起動しますか？

    • 上記のようにこれが不可能な場合は、同時に開始し、＃1として動作します

ご意見をいただければ幸いです。ありがとうございました！

haproxyclusterpacemakercorosync
2
namezero

Haproxy.cfgのワイルドカードをリッスンします

bind *:443

の代わりに

bind myvip:443

このようにして、ノードにVIPリソースがあるかどうかに関係なく、haproxyリソースを常に実行できます。ノードがVIPを取得すると、haproxyはすぐに応答します。

明らかな副作用は、haproxyがVIPだけでなくすべてのIPアドレスをリッスンすることです。

ポート番号が競合する場合（たとえば、別のIPまたはVIPで別の構成のポート443が必要な場合）、それをbind *:9443として定義し、DNATの背後に配置します。

3
kubanczyk

ペースメーカー/ corosyncに縛られていない場合は、以下のサービス構成ファイルを使用して、opensvcで説明する動作を実現できます。

[DEFAULT]
id = 84327b87-13f6-4d32-b90a-a7fad87a8d92
nodes = server1 server2
flex_min_nodes = 2
topology = flex
orchestrate = ha
monitor_action = freezestop

[ip#vip]
ipname@server1 = 192.168.100.240
ipname@server2 = 192.168.100.241
ipdev = br0
monitor = true

[app#haproxy]
type = simple
start = /sbin/haproxy -f /etc/haproxy/haproxy.cfg
restart = 1
monitor = true

説明：

[DEFAULTセクションはグローバル構成設定です：

  • id = ....一意のサービスID。サービスの作成時に自動的に生成されます（svcmgr -s myservice create、次にsvcmgr -s myservice edit config）

  • nodes = server1 server2は、2ノードを実行していることを意味しますopensvcクラスター

  • flex_min_nodes = 2サービスが少なくとも2つのインスタンスを実行することを期待していることを伝えます。この2ノードのクラスターでは、ノードごとに1つのインスタンスがあります。

  • topology = flexアクティブ/アクティブサービストポロジを実行していることを指定します

  • orchestrate = haは、サービスをopensvcデーモンによって自動的に管理する必要があることを示しています

  • monitor_action = freezestopは、重要なリソースがダウンしたときの動作を強制するために使用されます（haproxyプロセスのクラッシュや強制終了など）。これが発生した場合、opensvcデーモンが決定を下す必要があります。 3つの可能なパラメータ：

    • freezestop：ローカルサービスインスタンスが停止され、フリーズ状態になります。
    • reboot：ノードが再起動されます。
    • crash：ノードがクラッシュしました。

[ip#vip]：サービスvipを宣言するために使用されます：

  • server1では、IP 192.168.100.240はサービス開始時にインターフェースbr0で構成されます。
  • server2では、IP 192.168.100.241は、サービス開始時にインターフェイスbr0で構成されます。
  • monitor = trueはopensvcエージェントにこのリソースが重要であることを通知します（リソースがダウンした場合は、サービスをトリガーしますmonitor_action）

[app#haproxy]：アプリケーションに関する説明：

  • type = simpleサービスが単一プロセスアプリケーション（非フォークデーモン）を管理することを指定します
  • start = /sbin/haproxy -f /etc/haproxy/haproxy.cfgは、サービスの開始時に実行するコマンドです。
  • restart = 1は、opensvcデーモンに、このリソースがダウンした場合に1時間を再起動するように指示します。
  • monitor = truehaproxyは重要なリソースです。ダウンした場合は、前のパラメーターが原因で1回再起動を試み、失敗した場合は、monitor_actionをトリガーします。

サービスはvipに依存しているため、*：443をバインドする必要はなく、サービスvipのみをバインドする必要があります。

Haproxyがダウンした場合の再起動/ストニスに関する質問については、restart = 1に[app#haproxy]を入力して再起動を試み、DEFAULTセクションにmonitor_action = crashを入力してください。このようにして、1回の再起動が試行され、これが機能しない場合、ノードがクラッシュします。

お役に立てれば。

1
Chaoxiang N