AWS環境に構築する場合のRabbitMQ(TCP5671)の冗長化について

フォローする
mtakagi

AWSに構築したKompira Enterprise（EC2）について御社から提供されている構築ガイドを参考に構築いたしました。
この際、構築ガイドからの変更点としてkompira_sendevtでの連携のために、ALB同様の方法でNLBを構築しました。

----
＜参考構成＞
ap-northeast-1aおよび1cにEC2がそれぞれ1台ずつ、および1a, 1cのサブネットを指定したNLBが存在しています。
NLBおよびターゲットグループでのロードバランシング設定は以下設定になっています。

・TCP443を利用してヘルスチェックを行う
・ロードバランシングを行うポートはTCP5671
・NLBのリスナーはTCP5671で上記ターゲットグループを指定する
・NLBはクロスゾーン分散を有効化する

また、EC2はpacemakerによりどちらか一台がapacheの機能を停止させているため（ACT-SBY構成）、上記TCP443でのヘルスチェックは1a側、1c側の一方がhealthy, もう一方がunhealthyと判定されています。
----

【課題】
このとき、NLBにてunhealthy状態のホストにロードバランシングされてしまう問題が発生しております。
NLBの動作としてunhealthyとなっているEC2にはロードバランシングしないでほしいのですが、動作としてhealthy、unhealthy関係なくロードバランシングされてしまっています。 
これは、NLBの名前解決を行う際にunhealthyのホストしか存在しないAZ側のNLBのIPが割り当てられ、通信が経由する際に発生します。
※名前解決を行う際にhealthyのホストしか存在しないAZ側のNLBのIPが割り当てられた場合は問題なくhealthyなホストのみに通信が向きます。


【ご質問】
上記構成に限らず一般的な構成での回答で構わないのですが、
掲題の通り、AWSに構築したKompira Enterpriseクラスタに対してのkompira_sendevt（RabbitMQ）の利用はどのような構成で実装すればよろしいのでしょうか？

0

コメント

3件のコメント

日付 投票
  • Ichiro Takahashi

    フィックスポイントの高橋です。

    NLB による kompira_sendevt によるメッセージ送信の振り分け、というのは構成的に試してみたことございません。申し訳ありませんが、調査してから改めて回答させていただきたいと思います。

    つきましては、以下について情報をいただけますでしょうか。

    • ご利用中の Kompira のバージョン
    • ご利用中の OS の種類およびバージョン
    • kompira_sendevt は外部からホスト名を指定してメッセージを送信したい、という想定で合っていますでしょうか？

    以上、よろしくお願いいたします。

     

    0
    コメントアクション パーマリンク
  • mtakagi

    ご返答ありがとうございます。
    以下ご回答となります。

    > ご利用中の Kompira のバージョン
    1.6.8.post1

    > ご利用中の OS の種類およびバージョン
    Red Hat Enterprise Linux 8.8 (Ootpa)
    ※AMI：RHEL_HA-8.4.0_HVM-20230419-x86_64-41-Hourly2-GP2（ami-006f28e2c3645caa4）

    > kompira_sendevt は外部からホスト名を指定してメッセージを送信したい、という想定で合っていますでしょうか？
    はい、ご認識の通りとなります。
    クライアント（監視サーバ等）からNLBのDNS名を名前解決してkompira_sendevtでメッセージ送信するような用途を想定しています。
    ALBを利用してHTTPS通信に関してACT-SBY構成を取っているようにHTTPS以外の通信に関してもHTTPSと合わせてACT-SBY構成を取りたいという意図です。
    ※なおTCP5671（RabbitMQ）に関して上記では参考までに記載させていただきましたが、TCP22(SSH)に関しても同様の事象が起きています。

    Kompiraの標準的な機能としてRabbitMQ（kompira_sendevt）が利用できる一方、自身の環境では上記の通り動作に問題があったため、本来どのような構成で利用すべきなのかをご教示いただきたいと思っております。

    0
    コメントアクション パーマリンク
  • mtakagi

    上記の事象なのですが、こちらの設定ミスが原因であったことが分かりました。
    本来NLBのヘルスチェック用に許可するAZ-1c側用のCIDRの記載にミスがありEC2のセキュリティグループで誤った指定をしていたことにより、AZ-1a側のNLBノードはヘルスチェックに成功するが、AZ-1c側のNLBノードではヘルスチェックに失敗するという状況になっていたことが根本原因だったようです。

    調査対応にお手数おかけしてしまいまして大変申し訳ありませんでした。

    一方、kompira_sendevt用にRabbitMQのポートをNLBで受ける、ただしヘルスチェックはTCP443で行うという構成が推奨されるものなのかは公式見解がいただきたく、こちらについてはお手数ですが引き続きご回答をお願いできればと思います。

    ※補足：Kompira Enterpriseのインストーラで導入したPacemakerの設定ではRabbitMQはACT-SBYではなく両側で起動したままの状態であるようでしたので、RabbitMQのポートTCP5671を直接ヘルスチェックには利用せず、ACT-SBYが保たれるApacheのTCP443をヘルスチェックに代用しております。

    どうぞよろしくお願いいたします。

    0
    コメントアクション パーマリンク

サインインしてコメントを残してください。

お探しのものを見つけられませんでしたか？

新規投稿