最近在测试自己写的 OpenStack 安装脚本,之前都把控制节点和网络节点合在一起,这次为了把脚本分开,遇到了不少之前没有的问题,好在大部分都通过 Google + Docs 解决了,但是最近发现网络节点的 l3-agent 时常产生与消息服务器(控制节点)断开连接的问题:

2014-02-24 16:53:01.778 2378 ERROR neutron.openstack.common.rpc.impl_qpid [-] Failed to consume message from queue: heartbeat timeout

2014-02-24 16:53:01.784 2378 INFO neutron.openstack.common.rpc.impl_qpid [-] Connected to AMQP server on controller:5672

2014-02-24 18:31:00.829 2377 ERROR neutron.openstack.common.rpc.impl_qpid [-] Failed to consume message from queue: connection aborted

2014-02-24 18:31:00.836 2377 INFO neutron.openstack.common.rpc.impl_qpid [-] Connected to AMQP server on controller:5672

就像上面的日志显示那样,常常忽然连不上,然后再隔零点几秒又显示连接成功,让人看着非常不爽。前几天恰好看到了淘测试的一篇日志 GBA历代得主 ,里面提到淘宝的集群曾遇到过每个服务器都开了 NTP 同步时间,估计是连外网的 NTP 服务器对时把,造成了时间存在微小差异,导致心跳超时,我就心想我们的网络节点需要连 Qpid 服务器(控制节点),总是差那么零点几秒就会重连成功,而且我们的机器也都是开着 NTP 对时,是不是一个问题呢?

于是我就是试着用控制节点作为我们内网的授时服务器,整个内网都与整个授时服务器同步时间,这样用局域网速度应该会快很多,鸟哥的书固然好,但好像还是有些问题,我的配置过程如下:

一、修改控制节点的 /etc/ntpd.conf 文件,开放内网的访问(查询):

restrict 192.168.1.0 mask 255.255.255.0 nomodify notrap

至于连接哪个 NTP 服务器看喜好了,我一般使用的是 cn.pool.ntp.org。

二、开放防火墙123端口,设置完规则不要忘了保存:

iptables -A INPUT -p udp dport 123 sport 123 -j ACCEPT
iptables -A OUTPUT -p udp sport 123 dport 123 -j ACCEPT

三、重启ntp服务,用 ntpstat 和 ntpq -p 查看下我们的授时服务器与上层连接的状态,我这里 delay 一般在20~50左右(单位为毫秒),由于与 sysnet.edu.cn (屏幕没有显示全)延时最小,所以使用的是这个(在屏幕上用*注明):

> ntpstat:
synchronised to NTP server (202.112.31.197) at stratum 3
time correct to within 96 ms
polling server every 1024s> ntpq -p
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*dns2.synet.edu. 202.118.1.46     2 u  420 1024  377   21.951    0.367  13.759
+dns.sjtu.edu.cn 202.112.29.82    3 u  567 1024  377   49.529   11.216  14.545
+Hshh.org        127.67.113.92    2 u  661 1024  377   48.000  -26.821   9.765

ntpq 的返回结果比较复杂,这里顺便解释下,refid 表示这个授时服务连接上一层授时服务器,在服务器名前加 * 表示是当前使用的服务器,st 指得是 stratum,里面的数字表示这个授时服务器的等级,详见鸟哥的介绍。t 这一列里边的 u 表示是 unicast 单播,在 NTP 服务中是最常见的方法,when 表示从上次连接已经过去了多久,单位是秒,poll 表示连接间隔,reach 表示是否成功,正常的话这里应该是377,delay 表示延时(应该是估计的吧)单位是毫秒,offset 表示本地与服务器的时间差,同样是毫秒,jitter 表示在反复获取时间时,获得的时间的差异,这个差异可能比较随机,详见 NTP 官网的 FAQ。

服务器的配置并不复杂,那客户端就更简单了,首先我们可以试试 ntpdate controller 来测试服务器是否能正常连接,没问题的话,只要稍修改下 /etc/ntp.conf 就ok了:

restrict controller
server controller

第一行允许内网服务器修改本地时间,第二行将本地授时服务器添加到服务器列表里,OK 后重启 NTP服务,然后拿 ntpq -p 测试下:

> ntpq -p
remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*controller      202.112.31.197   3 u  123  256  377    0.162   -2.074   1.469

可以看到局域网里的连接速度果然是快的不行,delay只有 0.162 毫秒,相比连接互联网授时延时减少了99%,抖动也有所减少,说明更加稳定。

但是改完这个我还是不大放心,看到错误的返回栈大多是这个样子:

[-] Failed to consume message from queue: heartbeat timeout
Traceback (most recent call last):
File “/usr/lib/python2.6/site-packages/neutron/openstack/common/rpc/impl_qpid.py”, line 528, in ensure
return method(*args, **kwargs)
File “/usr/lib/python2.6/site-packages/neutron/openstack/common/rpc/impl_qpid.py”, line 585, in _consume
nxt_receiver = self.session.next_receiver(timeout=timeout)
File “<string>”, line 6, in next_receiver
File “/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py”, line 665, in next_receiver
if self._ecwait(lambda: self.incoming, timeout):
File “/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py”, line 50, in _ecwait
result = self._ewait(lambda: self.closed or predicate(), timeout)
File “/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py”, line 571, in _ewait
result = self.connection._ewait(lambda: self.error or predicate(), timeout)
File “/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py”, line 214, in _ewait
self.check_error()
File “/usr/lib/python2.6/site-packages/qpid/messaging/endpoints.py”, line 207, in check_error
raise self.error
HeartbeatTimeout: heartbeat timeout

这里这个 timeout 是超时设置的延时么?打印出来看看,于是修改了 impl_qpid.py ,居然是 None?好吧那么在 endpoints.py 里呢?居然也是 None ……好吧,打开 Neutron 的配置文件,只看到了  rpc_response_timeout 这个选项勉强算是和 Qpid 有点关系吧,设置之,重启 Neutron 服务,再看 timeout 还是 None,哎,本来 Qpid 是可以试着延时的好么?

-t <secs>, –timeout=<secs>
                   Maximum time to wait for broker connection (in
                   seconds)

不过折腾了许久,然后还出去吃了顿饭,目前还没出现过心跳包/消息超时的问题,算是暂时解决了吧?

OpenStack 的部署。特别是集群上,尤其是网络上充满了坑,祝自己顺利,也祝大家顺利……

2 Thoughts on “关于Qpid心跳超时与本地ntp服务器安装

  1. 好深奥好深奥好深奥好深奥

  2. 这个似乎应该是配置ntp服务使用三个以上的上一级时间源,NTP服务会计算延迟带来的差异提供一个准确的时间标记用于网络内同步

发表评论

电子邮件地址不会被公开。 必填项已用*标注

您可以使用这些HTML标签和属性: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">

你可以管理本篇文章的订阅。

Post Navigation