kompira本体が冗長構成を組んでいる場合のジョブマネージャサーバのAMQPS設定について
いつもお世話になっております。
AWSにおいて、kompira本体を冗長構成で構築しております（pacemaker を用いたAct/Sby）
別サーバに構築したジョブマネージャサーバでAMQPSを設定する際、
kompira本体のIPアドレスを指定する認識なのですが、
冗長構成を組んでいる場合はどのように設定しておくべきでしょうか？
（kompira本体の正系・副系、それぞれのIPアドレスを指定しておく事は可能なのでしょうか？）
※kompira本体の前段にALBがおりますが、AMQPSは通信出来ない認識です。NLBを使用する事になりますでしょうか？
以上です、よろしくお願いいたします。
-
正式なコメント
フィックスポイントの高橋です。
AWSにおいて、マネージャーサーバを冗長構成で構築しております（pacemaker を用いたAct/Sby）
ここで、Pacemaker を用いた冗長構成とあるので、「マネージャーサーバ」というのは Kompira サーバ自体を指し示している、またKompiraのバージョンは1.6系（2.0系ではない）をご利用になられているのかと推測します。
アクションサーバのAMQPSの設定時、マネージャーサーバのIPアドレスを指定する認識なのですが、マネージャーサーバが冗長構成の場合、どのように設定しておくべきでしょうか？（マネージャーサーバの正系・副系、それぞれのIPアドレスを指定しておく事が可能なのでしょうか？）
ここで、「アクションサーバ」とはAMQPSの設定とあるので、ジョブマネージャ (kompira_jobmngrd) のことを指し示しているのかと思います。
「冗長構成の Kompira サーバを構築し、さらに追加でジョブマネージャを外部に構築して連携させたい」、という前提でお答えします。
ジョブマネージャ (kompira_jobmngrd) は Kompira サーバ内の AMQP サーバ (rabbitmq-server) に接続する必要があります。kompira_jobmngrd のセットアップ時に接続先の IP アドレスを指定する必要がありますが、これは接続する AMQP サーバの IP アドレスのことになります。
Kompira サーバを冗長構成でセットアップするときに、イントラ環境では VIP （仮想 IP アドレス）を指定して構築する場合があります。これを指定した場合は、Pacemaker が Active 側のノードに対して VIP を追加する、という動作をとるように Pacemaker を構成します。この場合は、外部のジョブマネージャはこの VIP に接続するようにセットアップしておくことで、Kompira サーバの Active/Standby が切り替わっても、Active 側に再接続するようになります。
一方で、クラウド環境では VIP を利用できない場合が多く、冗長構成のセットアップ時にも VIP を指定しない構築を行なう場合があります。この場合は、外部のジョブマネージャは VIP を指定できないことになるので、簡単には正系あるいは副系いずれかの IP アドレスを指定しておくことになります。Kompira サーバの冗長構成は rabbitmq-server はActive系／Stanby系の両方で起動してクラスタ構成をとるように構成していますので、両系が正常動作している場面では外部のジョブマネージャから正系あるいは副系いずれの rabbitmq-server に接続できます。
しかし、片系がダウンしている場面においては、ダウンした系のIPアドレスを指定しているジョブマネージャは AMQP 接続できないため正常に機能しないことになります。簡単な対策としては、正系と副系に接続するジョブマネージャをそれぞれ個別に用意しておくこと、というのは考えられるかと思います。
マネージャーサーバの正系・副系、それぞれのIPアドレスを指定しておく事が可能なのでしょうか？
残念ながら、現状そのような構成を取ることはできません。ただ、ジョブマネージャに接続先のアドレスを複数指定できるようにする、という機能拡張のアイデアは有用かもしれません。今後の機能追加で検討してみたいと思います。
※マネージャーサーバの前段にALBがおりますが、AMQPSは通信出来ない認識です。
ALB は HTTP/HTTPS しかロードバランスできませんが、NLB であれば TCP レベルのロードバランスが可能で手元での簡単な実験では AMQPS の接続を振り分けることも出来るようでした。
ただし、ジョブマネージャと rabbitmq-server の接続は長時間に渡るため、NLB が安定的に継続して接続を維持できるかや、切り替わり時にスムーズに再接続できるか、といった点については時間をかけた評価と場合によっては各種パラメータチューニングなどが必要になってくるかもしれません（弊社では NLB 構成での十分な知見は持っておりません）。
以上、参考になさってみてください。
コメントアクション -
高橋様
お世話になっております。
ご回答ありがとうございます。サーバの呼称について失礼いたしました。
（質問文は修正しておりますが、読み替えて頂いた認識で相違ございません。バージョンも1.6系を使用しております）片系がダウンしている場面においては、ダウンした系のIPアドレスを指定しているジョブマネージャは AMQP 接続できないため正常に機能しないことになります。簡単な対策としては、正系と副系に接続するジョブマネージャをそれぞれ個別に用意しておくこと、というのは考えられるかと思います。
ありがとうございます。
今回は正系用・副系用、それぞれを指定したジョブマネージャーを用意しようと思います。
ジョブマネージャに接続先のアドレスを複数指定できるようにする、という機能拡張のアイデアは有用かもしれません。今後の機能追加で検討してみたいと思います。
ありがとうございます。ご検討よろしくお願いいたします。
ALB は HTTP/HTTPS しかロードバランスできませんが、NLB であれば TCP レベルのロードバランスが可能で手元での簡単な実験では AMQPS の接続を振り分けることも出来るようでした。
ただし、ジョブマネージャと rabbitmq-server の接続は長時間に渡るため、NLB が安定的に継続して接続を維持できるかや、切り替わり時にスムーズに再接続できるか、といった点については時間をかけた評価と場合によっては各種パラメータチューニングなどが必要になってくるかもしれません（弊社では NLB 構成での十分な知見は持っておりません）。
ご確認ありがとうございます。承知しました。
現状はNLBを用いた構成は採用せず、個別にジョブマネージャーを構築する方向で対応したいと思います。
以上です、よろしくお願いいたします。
サインインしてコメントを残してください。
コメント
2件のコメント