AWS環境におけるsetup_cluster.sh 実行時のエラーについて

フォローする
auto-kn

いつもお世話になっております。

下記の構成でkompiraの冗長構成を組むため作業していた所、
セカンダリ機において、setup_cluster.sh がstatus=1で終了しました。
メールにて詳細を送付させて頂きますので、ご確認頂けますでしょうか。

<構成>
インフラ：AWS
OS：RHEL8.4
AMI:RHEL_HA-8.4.0_HVM-20210504-x86_64-2-Hourly2-GP2
kompira version：1.6.12.post1
EC2：2台（EC2#1:Master,EC2#2:Slave）

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

0

コメント

3件のコメント

日付 投票
  • 正式なコメント
    Ichiro Takahashi

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

    ご提供いただいたログを確認したところ、セカンダリ機のセットアップの終盤において、プライマリ機からデータベースの同期を行なう処理で以下のようなエラーが記録されていることが気にかかります。

    pg_basebackup: error: connection to server at "ha-kompira-other" (XXX.XXX.XXX.133), port 5432 failed: FATAL:  no pg_hba.conf entry for replication connection from host "YYY.YYY.YYY.229", user "repl", no encryption

    XXX.XXX.XXX.133 は setup_cluster.sh で指定されたプライマリ機のIPアドレスですが、YYY.YYY.YYY.229 は指定されたプライマリ機／セカンダリ機いずれのIPアドレスでもありません。

    この YYY.YYY.YYY.229 についてはいただいた他のログでも登場しませんが、プライマリ機から見てセカンダリ機の接続元IPアドレスが setup_cluster.sh で指定した XXX.XXX.XXX.126 ではなく、YYY.YYY.YYY.229 になるようなシステム構成／ネットワーク構成になっている、ということはないでしょうか？

    ネットワーク構成を見直す、あるいは、両系の postgresql の設定で YYY.YYY.YYY.229 など実際に対向系から接続されるIPアドレスからのアクセスを許可するようにすることで、正常にクラスタ構成ができるようになるかもしれません。

    参考になさってみてください。

    コメントアクション パーマリンク
  • auto-kn

    ご回答ありがとうございます。

    構成について補足いたします。

    EC2のNW構成は以下のようになっておりました。

    ・EC2#1
    ①メイン用ENI（---.---.yyy.93）
    ②ハートビート用ENI（---.---.yyy.133）

    ・EC2#2
    ①メイン用ENI（---.---.zzz.229）
    ②ハートビート用ENI（---.---.zzz.126）

    setup_cluster.sh を実行する前に、EC2#1、EC2#2それぞれで静的ルートを設定しております。

    ・EC2#1
    sudo nmcli conn mod "System eth1" +ipv4.routes "---.---.zzz.126/32 ---.---.yyy.1

    ・EC2#2
    sudo nmcli conn mod "System eth1" +ipv4.routes "---.---.yyy.133/32 ---.---.zzz.1

    ------------------

    以下、当方で調査した結果、クラスタ構成が確立出来ております。

    ご指摘頂きました通り、セカンダリ機から setup_cluster.sh を実行した所、
    セカンダリ機のメイン用IPから、プライマリのハートビート用IPに向かって
    pg_basebackupが実行されましたが、DB接続を拒否されておりました。

    　・プライマリ機の/etc/hostsを確認
    　　---.---.zzz.126 kompira-redundant2 ha-kompira-other

    　・プライマリ機の/var/lib/pgsql/17/data/pg_hba.conf を確認
    　　host replication repl kompira-redundant2 trust

    この事から「プライマリ機は ha-kompira-other（---.---.zzz.126）からのアクセスを許可していたが、
    セカンダリ機が---.---.zzz.229（メインIP）からpg_basebackupを試みたため、認証で弾かれていた」と考えております。


    （対処方法）
    ※プライマリ機の認証を更新すべきか、セカンダリ機のIPを更新すべきか、
    　判断がつかなかったため、今回は前者を実施しております。


    ・プライマリ機の /etc/hosts を更新
    →kompira-redundant2 と ha-kompira-otherの名前解決を分離
    　---.---.zzz.126 kompira-redundant2
    　---.---.zzz.229 ha-kompira-other

    ・プライマリ機の /var/lib/pgsql/17/data/pg_hba.conf を更新
    →ha-kompira-otherを許可
    (旧)host replication repl kompira-redundant trust
    (新)host replication repl ha-kompira-other trust

    ・設定反映
    psql -U xxxxxxx -c "select pg_reload_conf();"

    ・セカンダリ機でsetup_cluster.sh を再実行
    -> status=0 で完了


    （確認させて頂きたい事）
    ・事象が発生した原因について調査をしております。
    　今回のNW構成で setup_cluster.sh を実行する場合、
    　静的ルートの設定を含め、どのような対応が妥当であったかご教示願えますでしょうか。

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

    0
    コメントアクション パーマリンク
  • Ichiro Takahashi
    フィックスポイントの高橋です。
     
    メイン用NICとハートビート用NICを分ける場合は、それぞれ別ネットワークに所属するように構築することが多いかと思います。

    - 1号機と2号機のメインNICは同じネットワークに接続する。
    - 1号機と2号機のハートビートNICは同じネットワークに接続する。

    setup_cluster.sh で2台のIPアドレスを指定するとき、NICが上記のように二枚構成であればハートビート用のIPアドレスを指定していただく想定ではいます（メイン用のIPアドレスで構成できない、というわけではありません）。

    setup_cluster.sh で指定したIPアドレスを使って、クラスタ構成の設定を行ないます。
    その対象としては pacemaker だけでなく postgresql や rabbitmq にも及びます。

    今回 pacemaker や rabbitmq は問題なく接続できているように見える一方で、postgrtesql だけが接続失敗しているようでした。これは postgresql の pg_hba で接続元IPアドレスで接続許可を設定しており、それが setup_cluster.sh で指定したアドレスを元に行っています。

    setup_cluster.sh にはハートビート用NICのアドレスを指定いただいていたので、これは想定どおりです。しかし、実際に postgresql の接続としてはメイン用NICのアドレスが接続元となっていて、それは許可設定されておらず接続エラーになった（クラスタ構成に失敗した）と考えられます。

    2号機から1号機のハートビートNICのアドレスに接続する際に、接続元として2号機のメイン用NICが選択された（そのIPアドレスが接続元アドレスとなった）、のではないかと考えられます。

    ここで確認なのですが、各VMのメイン用NICとハートビート用NICは、それぞれ異なるネットワークに接続されていますでしょうか？

    上記のようにメイン用NICのハートビート用NICが異なるネットワークに接続されていれば、各NICには異なるネットワークのIPアドレスが割り当てられている（1号機と2号機のハートビート用NICは同じサブネットに属している）のではないかと思います。そのような構成になっていれば、2号機から1号機のハートビートNICのアドレスへの接続は、2号機のハートビートNICのアドレスが接続元となるはずで、今回の事象は起きていなかったのではないかと考えています。

    あるいは、ネットワーク構成が1号機と2号機でそもそも分離している、そのために静的ルートを追加している、ということになるでしょうか？

    もしかしたら静的ルートの設定方法に改善の余地があるかもしれません。

    sudo nmcli conn mod "System eth1" +ipv4.routes "---.---.zzz.126/32 ---.---.yyy.1

    sudo nmcli conn mod "System eth1" +ipv4.routes "---.---.yyy.133/32 ---.---.zzz.1

    宛先アドレスとゲートウェイアドレスを指定されているかと思いますが、複数NICのいずれもゲートウェイに到達できるなら、メトリックの小さいNICが優先されるかと思います。

    いずれのNICでもゲートウェイに到達するけど、ハートビート用NICを優先したいということであれば、静的ルートの設定に送信元NICか送信元アドレスを設定するといった方法があるのではないかと思います。ネットワーク管理者に適切なルート設定となっているかをご確認いただくのがよいかと思います。

    以上、参考になさってみてください。
    0
    コメントアクション パーマリンク

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

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

新規投稿