Kolla OpenStack yoga 版本部署时 haproxy 无法正常工作的问题排查

前言

这个缺陷很奇怪，仅在使用我的公司自研的操作系统上部署时产生。但是这个由于 haproxy 的配置缺陷导致的问题确实存在，记录以供后续参考。

问题表现

在部署过程与部署完成后均出现 mysql 数据无法连接的问题。导致集群无法工作。

问题原因排查

进入 mysql 容器，通过命令行工具指定 host 登录 mysql 发现 mysqld 是正常工作的，但是 api 地址(经过 haproxy 代理的服务地址上) 3306 并未监听。
此时问题基本就定位到了 haproxy 上，查看日志，日志没有关于 3306 端口的错误（其实此刻3306端口根本没有被代理）。检查 haproxy 配置 /etc/kolla/haproxy/services.d/mariadb.cfg

# /etc/kolla/haproxy/services.d/mariadb.cfg
frontend mariadb_front
    mode tcp
    option clitcpka
    timeout client 3600s
    option tcplog
    bind 10.50.124.236:3306
    default_backend mariadb_back

backend mariadb_back
    mode tcp
    option srvtcpka
    timeout server 3600s
    option httpchk
     server DAS-OS 10.50.124.235:3306 check port 4569 inter 2000 rise 2 fall 5

貌似一切都正常。
查看 haproxy 的控制台（1984 端口，账号密码写在/etc/kolla/haproxy/haproxy.cfg配置文件中）。我们发现了 mariadb_back 这个状态是错误的。？？？

猜测

这样问题就很奇怪了，对比该别的集群 haproxy 的配置完全一样，为什么这里会发生错误呢。并且 haproxy 的容器到 mariadb 的容器网络是畅通的，mariadb 的服务也是正常工作的。为何会检测不通过内，我手动测试是完全OK的。
抱着尝试的心态看了下 haproxy mariadb_back 的配置，有一项引起了我的注意 option httpchk。这是一个非 http 的服务为什么使用 http 这个状态检测方式呢，不应该是 tcp 什么的么？但是，但是 ！有经验的同学也会知道，当我们用 nc 或者 curl 访问 mysql 的 3306 端口是有一定的回显的（嗯大概是 http 1.0 那种毫无格式的回显）。于是我尝试着在 harproxy 的容器中 curl 访问 mariadb 的 3306 端口。嗯~~~，报错了 ---- 不支持 http 1.0 格式。具体的回显我忘记的，但是大概是这个意思。但是这个方式在其他的系统中是可以正常获得 mariadb 的回显的，唯独这里不行，由于时间紧急，这个问题我将会放到后续探究。

解决

确认了问题所在问题的解决就变得简单了。修改为 tcplog 重启后即可正常工作。