error: [Errno 104] Connection reset by peer nova server-list结果结算节点down

admin · 发表于 2021-6-17 15:47:38

2021-06-17 15:38:54.687 25 ERROR oslo.messaging._drivers.impl_rabbit [req-16c1bbd6-5bb1-4c14-a05f-8dbbd6c709b0 - - - - -] [7c38fc9d-5a2e-482e-8f51-fd364d05359d] AMQP server on 10.160.77.3:5672 is unreachable: [Errno 104] Connection reset by peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset by peer
2021-06-17 15:38:55.412 26 INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Errno 104] Connection reset by peer
2021-06-17 15:38:55.708 25 INFO oslo.messaging._drivers.impl_rabbit [req-16c1bbd6-5bb1-4c14-a05f-8dbbd6c709b0 - - - - -] [7c38fc9d-5a2e-482e-8f51-fd364d05359d] Reconnected to AMQP server on 10.160.77.3:5672 via [amqp] client with port 53712.

admin · 发表于 2021-6-17 15:52:10

在本人openstack集群环境中，新增一台compute节点，启动nova-compute服务的时候卡死。而已有的计算节点并没有此问题。从侧面反映出整个集群应该是没有问题的，问题出在新增的这台compute节点上。

查看/var/log/nova/nova-compute.log日志可以看到报错日志信息：

ERROR oslo.messaging._drivers.impl_rabbit [-] [1e21a744-9754-44d3-907b-92e72efdcd7d] AMQP server on controller-150:5672
is unreachable: [Errno 104] Connection reset by peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset by peer

ERROR oslo.messaging._drivers.impl_rabbit [-] [1e21a744-9754-44d3-907b-92e72efdcd7d] AMQP server on controller-150:5672
is unreachable: [Errno 111] ECONNREFUSED. Trying again in 2 seconds.: error: [Errno 111] ECONNREFUSED

INFO oslo.messaging._drivers.impl_rabbit [-] A recoverable connection/channel error occurred, trying to reconnect: [Err
no 104] Connection reset by peer

ERROR oslo.messaging._drivers.impl_rabbit [-] Connection failed: [Errno 111] ECONNREFUSED (retrying in 2.0 seconds): er
ror: [Errno 111] ECONNREFUSED

INFO oslo.messaging._drivers.impl_rabbit [-] [1e21a744-9754-44d3-907b-92e72efdcd7d] Reconnected to AMQP server on contr
oller-150:5672 via [amqp] client with port 40872.

WARNING nova.conductor.api [req-9a93ad73-7269-4375-9f67-987d98223d4d - - - - -] Timed out waiting for nova-conductor.
Is it running? Or did this service start before nova-conductor? Reattempting establishment of nova-conductor connection...: MessagingTimeout: Timed
out waiting for a reply to message ID b0de8895bd074645a7d7f6058fc5d8cf

从日志看，是无法连到控制节点的nova-conductor。

查看控制节点nova-conductor和rabbitmq的日志，在疯狂刷下面的日志，而43602端口所属进程就是nova-conductor的。说明nova-conductor一直在尝试通过rabbitmq进行通信，但是失败了。

/var/log/nova/nova-conductor.log

ERROR oslo.messaging._drivers.impl_rabbit [req-602672bc-7325-41ad-ac69-2b735b07c875 - - - - -] [73043348-2b34-44b3-8ab
a-7fa9769b64e0] AMQP server on controller-150:5672 is unreachable: [Errno 104] Connection reset by peer. Trying again in 1 seconds.: error: [Errno 10
4] Connection reset by peer

/var/log/rabbitmq/rabbit\@controller-150.log

=ERROR REPORT==== 17-Aug-2020::20:53:24 ===
Channel error on connection <0.22032.9> (172.5.1.150:43602 -> 172.5.1.150:5672, vhost: '/', user: 'openstack'), channel 1:
operation basic.publish caused a channel exception not_found: no exchange 'reply_7fab30efd0cf4889a35e402ebf0c18ba' in vhost '/'

通过查资料，很多人讲：

重启openstack-nova-conductor服务就OK了。 ========然而并没用。==========
重新安装rabbitmq-server。 =========然而并没用。==============
最后，还是坚信自己一开始的推断，问题出在了新增的compute节点上。

但是，该节点上的配置文件是来自于模板，与其他计算节点配置一样。。应该排除配置出错的问题。

既然配置没问题，那有可能出在安装的介质身上了：

已有的集群部署的是openstack queens，新增节点一开始部署的是train版。有问题之后就删了train版，然后重新安装的queens版本。看来是没有删除干净。

结论：openstack集群所有节点要严格统一版本，不能使用不同的版本，否则会出现很多莫名其妙的错误。

解决方案：

1、通过yum erase package_name 卸载并没有卸载干净。按道理这种方式应该把包依赖一起卸载的。。

2、通过 yum history list openstack-nova-compute 查看所有和openstack-nova-compute相关的yum安装历史；然后通过 yum history undo ID，将最早安装train版的安装历史回滚掉。这样，就干净的卸载掉了。最后，再重装。问题解决。

admin · 发表于 2021-6-17 15:55:06

使用 rabbitmq 中 heartbeat 功能可能会遇到的问题
【问题场景】客户端以 consumer 身份订阅到 rabbitmq server 上的 queue 上，客户端侧在 AMQP 协议的 Connection.Tune-Ok 信令中，设置 heartbeat 为 0，即要求服务器侧不启用 heartbeat 功能。服务器由于异常断电原因停止服务，结果客户端在短时间内无法感知到服务器端已经异常。

刚刚出现这个问题时，就有测试人员和业务人员找到我这边说：经过改造的 rabbitmq-c 库可能存在重大 bug，服务器都关闭了，客户端怎么还那像什么都没发生一样继续工作着呢？听到这种疑问，我只问了两个问题就想到了答案：

业务中是不是仅仅作为 consumer 运行的？
服务器能否确认是因为异常断电导致停止服务？
服务器和业务程序之间是否还有中间路由设备？
业务人员告诉我上述问题的答案分别是：是的、是的、没有。呵呵~~所以答案就已经确定了，你想到了么？

【问题分析】
这个问题可以从以下两个层面进行分析：

TCP 协议层面
在此层面上讲，上述问题属于典型的 TCP 协议中的“半打开”问题，典型描述如下：
如果一方已经关闭或异常终止连接而另一方却还不知道，我们将这样的 TCP 连接称为半打开（Half-Open）的。任何一端的主机异常都可能导致发生这种情况。只要不打算在半打开连接上传输数据，仍处于连接状态的一方就不会检测另一方已经出现异常。半打开连接的一个常见原因是，当客户主机突然掉电，而不是正常的结束客户应用程序后再关机。当然这里所谓的客户机并不是仅仅表示客户端。
在这种情况发生时，作为 TCP 链路上只接收不发送数据的一方，只能依靠 TCP 协议本身的** keepalive 机制**来检查链路是否处于正常状态。而通常 keepalive 机制下，需要大约 2 个小时时间才能触发。

AMQP 协议层面
在此层面上讲，客户端由于是作为 consumer 订阅到 queue 上的，所以在该 AMQP/TCP 连接上客户端不会主动发送数据到 rabbitmq server 侧。当服务器由于异常断电停止服务后，consumer 不会接收到 AMQP 协议层面的终止信令，所以无法感知对端的情况。

一种可能的解决办法是客户端侧在接收 N 次超时后，通过发送 AMQP 协议中的 Heartbeat 信令检测服务器端是否处于正常状态。

在场景描述中说道“客户端侧在 AMQP 协议的 Connection.Tune-Ok 信令中，设置 heartbeat 为 0”，如果是将 heartbeat 设置为 30 会如何？答案是会同时触发服务器端和客户端的 heartbeat 功能，即服务器端会在一段时间内没有数据需要发送给客户端的情况下，发送一个心跳包给客户端；或者一段时间内没有收到任何数据，则判定为心跳超时，最终会关闭tcp连接（参考这里）。而客户端侧同样会触发对发送和接收 heartbeat 计时器的维护，分别用于判定发送和接收的超时情况。

所以，需要解决的问题可以描述为：客户端作为 consumer 订阅到服务器上的 queue 后，在无业务数据需要处理时，需要通过检测 Heartbeat 帧（信令）来判定服务器是否处于异常状态（换句话说，自己是否已经是“半打开”的 TCP 连接）。

【解决办法】
建议的解决办法如下：

客户端必须启用 heartbeat 功能（解决“半打开”问题的基础）；
客户端需要支持在发送空闲时，发送 heartbeat 的功能（因为目前客户端作为 producer 是长连接到 rabbitmq server 上的）；
客户端需要支持在接收空闲时，通过检测服务器端发送来的 heartbeat 帧来判定服务器端（或网络）是否处于正常状态（因为客户端作为 consumer 也是长连接到 rabbitmq server 上的，同时不会主动向 rabbitmq server 发送数据）。

总结：
只要客户端启用 heartbeat ，那么服务器就会在满足“一定条件”时，定时向客户端发送 heartbeat 信令，同时也会检测在空闲状态达到规定时间后是否收到 heartbeat 信令；而客户端侧作为 consumer 时，需要判定是否接收到数据（无论是常规数据还是 heartbeat 信令），若在一定时间内没有接收到数据，则认为当前链路可能存在问题。后续可以从业务上触发 consume 关系的重新建立。

背景
由于长期以来，在我们的 Node.js 服务端项目中，离线任务大部分用的是 kue，这是个轻量级的任务队列，之前也有过介绍。而周五那天我正准备将之前的 kue 队列重构成 RabbitMQ 的队列的相关代码上线。

RabbitMQ 任务队列是我基于 amqplib 实现的，在生产环境跑了半年有余，没什么大问题。

但是，按照墨菲定理，你最担心的事情总会发生，或者说：出来混迟早是要还的。

悲剧
结果，明明在预发布环境测试没问题的，却在正式环境完全不起作用，一直在报 EPIPE 的错误，并且在之后 ack 时报 channel closed 的错误。

同时，RabbitMQ 管理后台看到，任务队列在一直堆积，已经累计了 5k 的任务量，可能你会觉得不多，但是如果告诉你，每个任务需要执行 1 到 20 分钟不等呢？

显然，先是把我吓了一跳，不过又马上镇定下来，毕竟处理过的线上事故大于十个手指能数的数量了。

回滚
冷静想了想，这个离线任务里的业务虽说重要，但一时的任务堆积关系不是很大，而且任务会重新创建，回滚到旧代码就行，于是我将所有的代码一键回滚。

现在，改来找问题原因了。

寻找
按照目前的所掌握的信息，似乎还不能定位问题所在，大致能确定的是：TCP 连接有问题，导致 ack 数据写到了已经关闭的 sockets 上面了，才会导致 EPIPE 的错误。

TCP 连接为什么会关闭连接？
一般来说，TCP 正常的关闭，会有四次握手：

『我要关了哈』
『好的』，『我也要关了』
『恩，拜拜』

而不正常的错误，会有 ECONNRESET 或者 Connection reset by peer 之类的错误提示，EPIPE 的话，一般是对方主动关闭，而没有通知到我方。

于是，原因显然是需要在对方机器上去找，因此登录到 RabbitMQ 的机器上查看日志，果然，发现了非常多的错误日志：

=ERROR REPORT==== 9-Jun-2017::16:07:39 ===
closing AMQP connection <0.9305.6670> (X.X.X.1:33647 -> X.X.X.2:5672):
missed heartbeats from client, timeout: 60s

这是什么意思呢？关键信息是最后一行，missed heartbeats from client, timeout: 60s 。

很明显，超过默认 heartbeats timeout 的时间了，于是 RabbitMQ 认为这个客户端已经不行了，所以主动断了连接。

好了，那么继续下一步。

为什么会出现 heartbeats timeout ?
在 RabbitMQ 官方文档上 [1] 找到这样的解释：在 server 3.0 以及之后的版本中，client 以及 server 会协商一个 timeout 值，默认是 60s （3.5.5 之前是 580s），回过头来看服务器版本，已经大于 3.5.5，（其实看日志也知道了），也就是 60s。

server 每隔 timeout / 2 就会发送一个心跳包，如果都错过，就会认为这客户端没救了，会主动关闭连接，然后客户端需要重新连接。

于是，兴奋地赶紧设置下 heartbeat 时间，来个 3600s。

很明显，问题没那么简单，错误还是在出现。

回过头来，再看看文档，注意『协商』这两个字，也就是说，结果不是我设置了就能成功的，server 该怎么做还是怎么做，于是 60s 的默认 timeout 不能通过 client 来修改。

但是这会儿我又不敢修改了，server 的 timeout 是全局的 [2]，如果改了就意味着所有的连接都是这个数了，这可太危险了。

整理下思路，看看手头上已有的信息，于是把眼光放到了 client。

为什么会超过默认 heartbeats timeout 的时间？
其实这会儿，答案已经呼之欲出了：

事件循环太长导致

Node.js 不同于其它正常语言，它是单进程模型，没有所谓的进程并发，即使底层的线程也是为了异步 io。

也就是说，一旦一个事件里面的 CPU 被占满，其它 io 操作都会在事件队列中等待，导致事件循环过长。而在这个问题中，它的表现就是：client 的心跳包所在的事件，无法通过 TCP 这样的网络 io 操作发送至 server。

这才明白，我重构的部分是 CPU 密集型的任务，这恰恰是 Node.js 最软肋的地方。

解决
显然对于 CPU 密集型任务，我们一般有这几种方案：

fork 一个进程去处理，父进程负责 RabbitMQ 通信，子进程负责跑任务；
setImmediate，分拆 CPU 任务；
换语言，用 Go，Rust 或者 Python之类的语言去处理；
那么，为了尽快解决线上的问题，第一个就是我们的选择：最快，最直接。

总结
staging 环境不一致问题需要解决；
重构有风险，入坑需谨慎；
造轮子可以，测试需完善；
Ref
https://www.rabbitmq.com/heartbeats.html
https://www.rabbitmq.com/configure.html
确保与心跳和阻塞连接超时的良好连接
此示例演示了心跳的明确设置和阻止的连接超时。

从RabbitMQ 3.5.5开始，代理的默认心跳超时从580秒减少到60秒。因此，在同一个运行Pika连接的线程中执行冗长处理的应用程序可能会因心跳超时而出现意外断开的连接。在这里，我们为心跳超时指定显式下限。

当RabbitMQ代理耗尽某些资源（例如内存和磁盘空间）时，它可能会阻止执行资源消耗操作的连接，例如发布消息。一旦连接被阻止，RabbitMQ就会停止从该连接的套接字读取，因此客户端的命令不会通过该连接上的代理，直到代理解除阻塞。被阻止的连接可能持续一段无限期，停止连接并可能导致挂起（例如，在BlockingConnection中），直到连接被解除阻塞。阻塞连接超时旨在中断（即，丢弃）已被阻止超过给定超时值的连接。

配置hertbeat和阻塞连接超时的示例：

import pika

def main():

# NOTE: These parameters work with all Pika connection types
params = pika.ConnectionParameters(heartbeat_interval=600,
blocked_connection_timeout=300)

conn = pika.BlockingConnection(params)

chan = conn.channel()

chan.basic_publish('', 'my-alphabet-queue', "abc")

# If publish causes the connection to become blocked, then this conn.close()
# would hang until the connection is unblocked, if ever. However, the
# blocked_connection_timeout connection parameter would interrupt the wait,
# resulting in ConnectionClosed exception from BlockingConnection (or the
# on_connection_closed callback call in an asynchronous adapter)
conn.close()

if __name__ == '__main__':
main()

admin · 发表于 2021-6-17 15:55:36

rabbitmq 的心跳机制&应用
官方文档说：

If a consumer dies (its channel is closed, connection is closed, or TCP connection is lost) without sending an ack, RabbitMQ will understand that a message wasn't processed fully and will re-queue it

即：如果消费者进程挂掉了（channel关闭， connection关闭，或者tcp连接丢失），没有发回确认信息， RMQ将认为消息没有被处理完，将重新排队等待分配。

but how?

答案是：通过心跳来监控。

官方文档在这里：https://www.rabbitmq.com/heartbeats.html

摘要如下：

=====================================================================

Detecting Dead TCP Connections with Heartbeats
用心跳监控tcp连接是否丢失
Introduction
介绍
Network can fail in many ways, sometimes pretty subtle (e.g. high ratio packet loss). Disrupted TCP connections take a moderately long time (about 11 minutes with default configuration on Linux, for example) to be detected by the operating system. AMQP 0-9-1 offers a heartbeat feature to ensure that the application layer promptly finds out about disrupted connections (and also completely unresponsive peers). Heartbeats also defend against certain network equipment which may terminate "idle" TCP connections.

网络故障很多种，有时很微妙（比如，丢包比率和高）。分布式的tcp连接采取适中的时间（比如Linux默认配置大约11分钟），方便操作系统检测。AMQP 0-9-1提供heartbeat(心跳）特性来确保应用服务层及时发现已崩溃的连接（和完全无相应的peers）。心跳机制也能保证进程不被某些网络设备给杀掉。

Heartbeat Timeout Interval
心跳超时间隔
The heartbeat timeout value defines after what period of time the peer TCP connection should be considered dead by RabbitMQ and client libraries. This value is negotiated between the client and RabbitMQ server at the time of connection. The client must be configured to request heartbeats. In RabbitMQ versions 3.0 and higher, the broker will attempt to negotiate heartbeats by default (although the client can still veto them). The timeout is in seconds, and default value is 60 (580 prior to release 3.5.5).

心跳超时值决定了tcp相互连接的最大时间，超过了这个时间，该连接即被RMQ和客户端视为丢失（dead）。这个值在客户端和服务器建立连接的时候协商确定。客户端需配才能发心跳包。 RMQ3.0及以上版本， RMQ将试着将beatheart协调为默认值（客户端可以否决这个值）。超时时间单位为秒，默认值为60（ 3.5.5发布版之前是580）。

Heartbeat frames are sent about every timeout / 2 seconds. After two missed heartbeats, the peer is considered to be unreachable. Different clients manifest this differently but the TCP connection will be closed. When a client detects that RabbitMQ node is unreachable due to a heartbeat, it needs to re-connect.

心跳包每半个超时时间发送一次。丢失了两个心跳包，连接被认为不可抵达。不同的客户端有不同的提示，但tcp连接都会被关闭。当客户端检测到RMQ节点不可抵达（根据心跳判定），它需要重新连接（到服务器）。

Heartbeats can be disabled by setting the timeout interval to 0.

心跳机制可以被禁用：设定超时间隔为0。

		自动登录	找回密码
密码			注册