Ansibleで、MariaDBのGalera Cluster、HAProxy、Keepalivedを構築したのですが、VIP経由でデータベースに接続できません。

前提・実現したいこと

Ansibleで、MariaDBのGalera Cluster、HAProxy、Keepalivedを構築しました。
HAProxyとKeepalivedの構築は、可用性かつ冗長構成がとれたGalera Clusterへのアクセスを可能にするためです。
Keepalivedの構築後に、DBサーバからVIP経由でデータベースに接続確認すると、エラーになります。
VIP経由の確認はSSTユーザー（galeraユーザー）を利用しています。

db1i(=db1i2):192.168.10.31
db2i(=db2i2):192.168.10.32
db3i(=db3i2):192.168.10.33
db_v1i:192.168.10.1
app1i:192.168.10.21
app2i:192.168.10.22
app3i:192.168.10.23
lb1i:192.168.10.11
lb2i:192.168.10.12
lb1e:10.0.0.11
lb2e:10.0.0.12
app_v1e:10.0.0.1

発生している問題・エラーメッセージ

[root@db1]# mysql -u galera -p -h 192.168.10.1
Enter password:
ERROR 2013 (HY000): Lost connection to MySQL server at 'handshake: reading initial communication packet' , system error: 11

該当のソースコード

・MariaDB上でgaleraユーザーの設定や権限に問題ないことを確認
　・MariaDB [(none)]> select user, host from mysql.user;
    +-------------------------------------+
    | user   | host                       |
    +--------+----------------------------+
    | galera | 192.168.10.0/255.255.255.0 |

・/etc/my.cnf.d/server.cnf（MariaDBの設定ファイル：db1i2）
[galera]
wsrep_provider=/usr/lib64/galera/libgalera_smm.so 
wsrep_cluster_address="gcomm://192.168.10.31,192.168.10.32,192.168.10.33"
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=192.168.10.31
wsrep_cluster_name="MariaDB_Cluster"
wsrep_node_name="db1i2"
wsrep_node_address=192.168.10.31
wsrep_sst_method=rsync
wsrep_sst_auth=galera:galera
wsrep_on=ON

・/etc/my.cnf.d/server.cnf（MariaDBの設定ファイル：db2i2）
[galera]
wsrep_provider=/usr/lib64/galera/libgalera_smm.so 
wsrep_cluster_address="gcomm://192.168.10.31,192.168.10.32,192.168.10.33"
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=192.168.10.32
wsrep_cluster_name="MariaDB_Cluster"
wsrep_node_name="db2i2"
wsrep_node_address=192.168.10.32
wsrep_sst_method=rsync
wsrep_sst_auth=galera:galera
wsrep_on=ON

・/etc/my.cnf.d/server.cnf（MariaDBの設定ファイル：db3i2）
[galera]
wsrep_provider=/usr/lib64/galera/libgalera_smm.so 
wsrep_cluster_address="gcomm://192.168.10.31,192.168.10.32,192.168.10.33"
binlog_format=row
default_storage_engine=InnoDB
innodb_autoinc_lock_mode=2
bind-address=192.168.10.33
wsrep_cluster_name="MariaDB_Cluster"
wsrep_node_name="db3i2"
wsrep_node_address=192.168.10.33
wsrep_sst_method=rsync
wsrep_sst_auth=galera:galera
wsrep_on=ON

・/etc/haproxy/haproxy.cfg（haproxyの設定ファイル：db1i2,db2i2,db3i2）
#---------------------------------------------------------------------
# Global settings
#---------------------------------------------------------------------
global
    chroot      /var/lib/haproxy
    pidfile     /var/run/haproxy.pid
    maxconn     10000
    user        haproxy
    group       haproxy
    daemon
    stats       socket /var/run/haproxy.sock mode 600 level admin
    stats       bind-process 1
    nbproc      1

#---------------------------------------------------------------------
# common defaults that all the 'listen' and 'backend' sections will
# use if not designated in their block
#---------------------------------------------------------------------
defaults
    mode                    tcp
    log                     127.0.0.1 local2
    option                  tcplog
    option                  tcpka
    option                  dontlognull
    retries                 3
    timeout http-request    10s
    timeout queue           1m
    timeout connect         10s
    timeout client          10m
    timeout server          1m
    timeout check           10s
    maxconn                 300

listen stats :10080
    mode http
    stats enable
    stats uri /
    stats realm HAProxy\ Statistics
    stats auth haproxy:haproxy

#---------------------------------------------------------------------
# main frontend which proxys to the backends
#---------------------------------------------------------------------
frontend  main 192.168.10.1:3306
    default_backend     db_cluster
    maxconn  1000

#---------------------------------------------------------------------
# the various backends
#---------------------------------------------------------------------
backend db_cluster
    balance  source
   #server   db1i2 192.168.10.31:3306 check inter 2000 rise 2 fall 5
    server   db1i2 192.168.10.31:22 check inter 2000 rise 2 fall 5
   #server   db2i2 192.168.10.32:3306 check inter 2000 rise 2 fall 5
    server   db2i2 192.168.10.32:22 check inter 2000 rise 2 fall 5
   #server   db3i2 192.168.10.33:3306 check inter 2000 rise 2 fall 5
    server   db3i2 192.168.10.33:22 check inter 2000 rise 2 fall 5

・/etc/keepalived/keepalived.conf（keepalivedの設定ファイル：db1i2）
vrrp_script chk_haproxy {
  script "killall -0 haproxy"
  interval 2
  timeout  3
  raise    2
  fall     4
}

vrrp_instance VI_1 {
  interface enp0s8
  state BACKUP
  virtual_router_id 21
  priority 100
  nopreempt
  advert_int 2
  garp_master_refresh 2

  virtual_ipaddress {
    192.168.10.1 dev enp0s8
  }
  track_script {
    chk_haproxy
  }
}

vrrp_sync_group VG_SYNC_GROUP {
  group {
    VI_1
  }
}

・/etc/keepalived/keepalived.conf（keepalivedの設定ファイル：db2i2）
vrrp_script chk_haproxy {
  script "killall -0 haproxy"
  interval 2
  timeout  3
  raise    2
  fall     4
}

vrrp_instance VI_1 {
  interface enp0s8
  state BACKUP
  virtual_router_id 21
  priority 50
  nopreempt
  advert_int 2
  garp_master_refresh 2

  virtual_ipaddress {
    192.168.10.1 dev enp0s8
  }
  track_script {
    chk_haproxy
  }
}

vrrp_sync_group VG_SYNC_GROUP {
  group {
    VI_1
  }
}

・/etc/keepalived/keepalived.conf（keepalivedの設定ファイル：db3i2）
vrrp_script chk_haproxy {
  script "killall -0 haproxy"
  interval 2
  timeout  3
  raise    2
  fall     4
}

vrrp_instance VI_1 {
  interface enp0s8
  state BACKUP
  virtual_router_id 21
  priority 50
  nopreempt
  advert_int 2
  garp_master_refresh 2

  virtual_ipaddress {
    192.168.10.1 dev enp0s8
  }
  track_script {
    chk_haproxy
  }
}

vrrp_sync_group VG_SYNC_GROUP {
  group {
    VI_1
  }
}

試したこと

■（試したこと）⇒　接続成功（〇）/　接続失敗（×）
・MariaDB上でgaleraユーザーの設定や権限に問題ないことを確認（詳細はソースコード欄に記述）
・journalctl、MariaDBのエラーログ、/var/log/messages、/var/log/secureにエラーログなし
・DBサーバからVIPへpingOK
・mysql -u user -p -h hostコマンドにおいて、ユーザーがgaleraユーザーの場合、ホストがDBサーバでは、DB接続可能。ホストがVIPでは、DB接続不可。　⇒　×（DB接続不可のエラー出力はエラーメッセージ欄に記述）
・すべてのDBサーバの/etc/hosts.allowにmysqld: ALLを追記　⇒　×
・ルータのポート開放（DBサーバに対して4444/tcp, 4567/tcp, 4568/tcp、VIPに対して3306/tcp）　⇒　×
・ホストOS（Windows10）のWindowsDefenderファイアウォールで3306/tcp, 4444/tcp, 4567/tcp, 4568/tcpのポート開放　⇒　×
・firewalldでzone=trustedに対して、3306/tcp, 4444/tcp, 4567/tcp, 4568/tcpのポート開放　⇒　×
・nmap -Pn VIP　→　3306/tcp open mysql, 4444/tcp closed krb524, 4567/tcp open tram
・VIPアドレスをすべてのDBサーバのループバックアドレスに設定　⇒　×（詳細はソースコード欄に記述）

補足情報（FW/ツールのバージョンなど）

Ansible: 2.9.21
MariaDB: 10.3.30
ゲストOS: CentOS 7.9
ホストOS：Windows10
仮想環境： VirtualBox

TaichiYanagiya

2021/07/13 08:46

構成の確認ですが、DBサーバー x 2、keepalived(LVS) x 2 の計 4 台でしょうか？また、LVS の振り分けで足りると思うのですが、HAProxy は何の用途でしょうか？ DBサーバーの lo に VIP を付けるということは LVS DSR 方式だと思われますが、リアルサーバー(DBサーバー)から VIP へのアクセスはできないケースがあります(https://teratail.com/questions/58213)。まずは、ホストOS または別のVM から VIP 宛に接続を試みてどうか、ダメなら keepalived を使わず LVS 1台で試してみるとか、構成を単純にして成功することを目標とするといいと思います。

Cepheids0917

2021/07/14 08:04

構成は次のとおりです。・コントロールノード × 1 ・DBサーバ × 3 ・DB_VIP × 1 ・LB × 2（LBレイヤ） ※WordPress構築が目的であるため、全体アーキテクチャはLBレイヤ、APPレイヤ、DBレイヤで構成されますが、ここではDBレイヤのみを考えています。ロードバランサは、HAProxyとKeepalivedです。・HAProxyは負荷分散管理のため・KeepalivedはVRRPによるVIPを提供するためです。VRRPを利用して、データ送信のフェイルオーバーを実現します。 ※可用性かつ冗長構成がとれたアクセスを可能にするためです現在は、DBサーバのマスターノードにおけるenp0s8にのみVIPがあります。（DBサーバのloにVIPを付与させたいのではありません）すべてのDBサーバに対して、mysql -u galera -p -h 192.168.10.1を実行　⇒　同じエラーで接続失敗（×） Keepalivedを利用してもうまくいかないのならば、LVSの利用を試してみたいと思います。

TaichiYanagiya

2021/07/14 08:32

3306 番ポートを LVS ではなく、HAProx が受けて DBサーバーに振り分ける、ということですか？ (keepalived.conf で virtual_server の設定なし？) であれば、HAProxy は文字どおりプロキシとなって、Client<-->(VIP)HAProxy と HAProxy(Real-IP)<-->DB と別々の通信になると思います。 LVS DSR ではないので、DBサーバーの lo に VIP を持たせる必要はありません。まずは、すべて VIP 設定をはずして、HAProxy 1台構成とし、HAProxy の Real-IP:3306 で DBサーバーに振り分けられるかどうか。次に、keepalived で VIP を付けて HAProxy の VIP:3306 でどうか、試すといいと思います。

Cepheids0917

2021/07/15 07:09

3306番ポートをHAProxyが受けてDBサーバに振り分けます（keepalived.confにvirtual_serverの設定はありません）。 haproxy.cfgのhaproxy_frontend_address=192.168.10.31（db1のReal-IP）に設定すると、 ipコマンドにおいてVIPが消えました。 lsof -i:3306コマンドでは、db2とdb3はhaproxyが192.168.10.31:mysqlでLISTENしていました。しかし、db1はhaproxyが192.168.10.1:mysqlでLISTENしていました。次にkeepalivedを構築すると、db1にVIPが付きましたが、lsof -i:3306コマンドの結果に変化はありません。これは、すべてのVIP設定をはずせていないということでしょうか。それともReal-IP:3306 で DBサーバに振り分けられなかったということでしょうか。

TaichiYanagiya

2021/07/15 09:06

haproxy_frontend_address なんてパラメーターありましたっけ？しかも、なぜ DB1 の IP を？もしかして DBサーバーに HAProxy が同居している？ [keepalived+HAProxy] x 2, [DB] x 3 ではないのでしょうか。構成図、各IPアドレス、設定ファイルを質問文に追記ください。

Cepheids0917

2021/07/16 05:12

構成図、各IPアドレス、設定ファイルを質問文に追記しました。お手数ですが、ご確認をお願いします。なお、haproxy_frontend_addressはAnsibleの変数で、追記した設定ファイルはVIP設定をはずす前のものです。

行動規範の内容に同意します

回答1件

ベストアンサー

DBサーバーに HAProxy が同居していて、3306 番ポートの取り合いになるところを bind address で分けているということですね (Real-IP:3306 が DB、VIP:3306 が HAProxy)。
HAProxy は全 3ホストで稼働させておき、keepalived で 1ホストのみに VIP を付けることで有効にすると。

理論的にはよさそうですが、frontend main 192.168.10.1:3306 で指定している VIP が先に有効になっていないと HAProxy が起動に失敗するので、この設計ではダメだと思います。

解決方法として、以下のいずれかの方法が考えられます。

APP と同じように、DB とは独立した HAProxy+keepalived の構成にする。frontend main *:3306 で全IPで待ち受け。
HAProxy はデフォルト停止、keepalived で VIP が付いた後に notify_master で HAProxy を起動する。

server db1i2 192.168.10.31:22 check inter 2000 rise 2 fall 5

22番ポートにしているのはテストのため？

(2021/07/17 11:13) 追記

問題は「VIP が付く前に HAProxy を起動するには全IPで待ち受けする必要があるが、3306 番ポートは MariaDB が既に使用している。」ということなので、ポート番号を変える方法もありますね。
HAProxy 側で、例えば frontend main *:13306 で待ち受けて、APP 側から VIP:13306 で接続する。
あるいは、MariaDB 側のポート番号を変える。

投稿2021/07/16 07:27

編集2021/07/17 02:14

TaichiYanagiya

総合スコア12173

Cepheids0917

2021/07/18 05:23 編集

haproxyのbackend portを3306に設定すると解決しました。 VIP経由でデータベースに接続できました。HAProxyは全3ホストで起動していました。 22番ポートにしていた理由：HAProxyを構築した後に、統計情報を見て、バックエンドサービスを確認したのですが、DBへのヘルスチェックステータスがDOWNステータスになっていました。そこで、haproxyのbackend portを22番に変更すると、接続拒否（tcprst）の問題が解決してUPステータスになりました。＞22番ポートにしているのはテストのため？上記のご指摘のおかげで、haproxyのbackend portを22番に変更していたことに気づきました。ありがとうございました。

行動規範の内容に同意します