ip_conntrack配置导致用户连接RDS报错

RDS作为一个对外提供的关系型数据库服务，面对的外部环境也多种多样，这里介绍一个ip_conntrack配置导致的RDS连接失败的案例，以供参考。
起因
收到客户反馈说，他们的VM连接RDS有异常，时好时坏，严重影响到业务的正常运行。用户提供了如下报错信息：

从客户截屏的报错来看，“Unknown MySQL server host”在MySQL源码中对应的错误码是CR_UNKNOWN_HOST，只在解析主机地址出错的时候会报，所以我们和客户的判断是一致的：在解析DNS上出了问题。

下面是MySQL解析主机名的代码：

关于getaddrinfo函数的说明，可以参考：getaddrinfo()函数详解
继续深入调查
先确认DNS解析是否存在问题，经过连续的测试（RDS内部环境，用户的vm上），dns都是可以正常解析，安全团队这边确认也没有存在攻击之类的事件，cat /etc/resolv.conf 设置的nameserver也是正常的。
排除掉DNS服务器解析问题之后，我们再进一步检查VM本身是否存在异常，于是查看系统的报错信息。
这里，我们有了新的返现，在dmesg输出中，看到了大量的系统报错，如下：
查看messages文件，tail -f /var/log/messages：
关于这里报错的解释：
“ip_conntrack: table full, dropping packet”，iptables使用一个连接跟踪表来描述网络的连接状态，在启用了iptables的情况下，iptables会把所有的连接都做链接跟踪处理，当这个连接跟踪表满的时候，会出现上面的错误导致大量的网络丢包现象。

在服务正常的时候，查看连接表的使用数量：

xxx># cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
55205

查看系统默认配置：

xxx># sysctl net.ipv4.netfilter.ip_conntrack_max
net.ipv4.netfilter.ip_conntrack_max = 65536

使用默认配置是，如果有业务高峰，很容易导致ip_conntrack表满，导致网络出现大量的丢包现象。从系统报错日志和用户反馈的时间点大体也基本吻合，从vm上查看系统其他负载指标，网络连接指标都很高，包括网络通讯各种连接状态，在高并发的应用场景下，很容易导致网络通信异常（表象为解析异常，create socket异常）。
解决
适当的增加ip_conntrack配置：

vi /etc/sysctl.conf
net.ipv4.ip_conntrack_max = 655360
sysctl –p

这个案例在RDS客户出现好多次了，建议大家在初始化后os的时候，根据自己的应用特性，把需要调整的参数（比如ip_conntrack，nofile，nproc之类）尽量配置好，减少后期出问题的可能。

ip_conntrack参考文档

http://linxucn.blog.51cto.com/1360306/740130