云计算之路-阿里云上:重启 manager 节点引发 docker swarm 集群宕机

为了迎接春节假期后的访问高峰,我们今天对 docker swarm 集群进行了变更操作,购买了1台阿里云4核8G的服务器作为 worker 节点,由原来的  3 manager nodes + 2 worker nodes 变为  3 manager nodes + 3 worker nodes 。

晚上,我们对已经持续运行一段时间的5个节点逐一进行重启操作,重启方式如下:

1)docker node update --availability drain 让节点下线
2)阿里云控制台重启服务器
3)docker node update --availability active 让节点上线

以前多次进行过这样的操作,未曾遇到问题,而今天在将其中1台manager节点下线后竟然意外地引发了整个集群宕机 。。。21:39 - 22:02 左右,这个突发的故障给您带来很大的麻烦,请您谅解。受这次故障影响的站点有 闪存博问班级园子短信息招聘小组网摘新闻,openapi 。

经过分析,我们得到的教训是尽可能避免只有2个manager节点的情况(manager节点采用的是投票机制,少数服从多数,2个节点的投票永远是1:1,这也是一种不稳定情况)。针对这个教训,我们调整了节点的部署,改为了 5 manager nodes + 1 worker nodes ,这样即使2个manger节点下线或出问题,也不会群龙无首。

docker swarm 集群的不稳定让我们如履薄冰,今年我们会想尽一切办法彻底解决这个问题。

原文地址:https://www.cnblogs.com/cmt/p/8455956.html

时间: 2024-10-25 09:54:07

云计算之路-阿里云上:重启 manager 节点引发 docker swarm 集群宕机的相关文章

云计算之路-阿里云上:CPU 100%引发的状况

今天下午17:00-17:05之间,在请求量没有明显变化的情况下,SLB中的1台云服务器的CPU突然串到100%(当时SLB中一共有3台云服务器),见下图: 造成的直接后果是请求执行时间变得超长,最长竟然达到了53秒(下图中的紫色线条). 另外伴随的表现是大量请求排队. 再看看这个时间段其它2台服务器的表现: 从这些现象分析,我们猜测CPU 100%这台云服务器出现了CPU资源争抢问题,将之从SLB中摘除后恢复正常. 云计算之路-阿里云上:CPU 100%引发的状况,布布扣,bubuko.com

云计算之路-阿里云上:3个manager节点异常造成 docker swarm 集群宕机

今天 11:29 - 11:39 左右,docker swarm 集群 3 个 manager 节点同时出现异常,造成整个集群宕机,由此给您带来很大的麻烦,请您谅解. 受此次故障影响的站点有:博问,闪存,班级,园子,短信息,招聘,小组,网摘,新闻,openapi 最近我们刚刚确认我们所有遇到的 docker swarm 不稳定问题都与部分节点的异常状况有关,即使是一直让我们非常头疼的 docker-flow-proxy 路由问题,也是因为路由容器所在的节点出现异常状况,只要通过阿里云控制台重启这

云计算之路-阿里云上-容器难容:自建docker swarm集群遭遇无法解决的问题

我们从今年6月开始在生产环境进行 docker 容器化部署,将已经迁移至 ASP.NET Core 的站点部署到 docker swarm 集群上.开始我们选用的阿里云容器服务,但是在使用过程中我们遭遇了恐怖的路由服务(acsrouting)路由错乱问题 —— 请求被随机路由到集群中的任一容器,虽然后来阿里云修复了这个问题,但我们对容器服务失去了信心,走上了用阿里云服务器自建 docker swarm 集群的道路. 用上自建 docker swarm 集群之后,本以为可以在云上容器中过上安稳的日

云计算之路-阿里云上-容器难容:容器服务故障以及自建 docker swarm 集群故障

3月21日,由于使用阿里云服务器自建 docker swarm 集群的不稳定,我们将自建 docker swarm 集群上的所有应用切换阿里云容器服务 swarm 版(非swarm mode). 3月22日,我们进行移除与重启节点的操作时引发了故障,详见 云计算之路-阿里云上-容器服务:移除节点引发博问站点短暂故障 . 3月24日,我们参考阿里云容器服务帮助文档-指定多节点调度通过给节点添加用户标签的方式成功移除了部分节点.我们是这么操作的,当时所有节点没有添加用户标签,给待移除节点之外的所有节

云计算之路-阿里云上:消灭“黑色n秒”第三招——禁用网卡的TCP/IP Offload

程咬金有三板斧,我们有三招.在这篇博文中我们要出第三招,同时也意味着昨天在"希望的田野"上的第二招失败了. 前两招打头(CPU)不凑效,这一招要换一个部位,但依然要坚持攻击敌人最弱(最忙最累)部位的原则.那除了CPU,最忙最累的部位是哪里呢?对于Web服务器来说,毫无悬念,当然是网卡.而且阿里云的云服务器,所有的网络负载都集中在一块内网网卡上,SLB(负载均衡)用它,OCS(缓存服务)用它,RDS(数据库服务)也用它.所以,就对它出招! 招式受这篇博文(XenServer – Wind

云计算之路-阿里云上:Wireshark抓包分析一个耗时20秒的请求

这篇博文分享的是我们针对一个耗时20秒的请求,用Wireshark进行抓包分析的过程. 请求的流程是这样的:客户端浏览器 -> SLB(负载均衡) -> ECS(云服务器) -> SLB -> 客户端浏览器. 下面是分析的过程: 1. 启动Wireshark,针对内网网卡进行抓包. 2. 在IIS日志中找出要分析的请求(借助Log Parser Studio) 通过c-ip(Client IP Address)可以获知SLB的内网IP,在分析Wireshar抓包时需要依据这个IP进

云计算之路-阿里云上:超过70秒的请求抓包分析

超过70秒的请求是通过分析IIS日志发现的: 10.159.63.104是SLB的内网IP. 通过Wireshark抓包分析请求是9:22:21收到的(tcp.stream eq 23080): 09:22:21.299838000 10.159.63.104 10.161.241.208 HTTP 291 GET /eastsea/p/3764040.html HTTP/1.0 这个请求响应内容的长度是:Content-Length 1154110(1.1MB) 云服务器(ECS)在收到请求后

云计算之路-阿里云上:对“黑色n秒”问题的最终猜想——CPU C-states引起的

如果说2013年云计算之路的主题是"踩坑",那么2014年我们希望云计算之路的主题变成"填坑"--当然填坑是阿里云来完成的,我们只是见证曾经的坑坑洼洼变成平坦大道. 15号(周四)晚上我们发现了SLB会话保持的坑,16号晚上阿里云成功定位并进行修复,这两天正式发布后会填平这个坑.这次从踩坑到填坑的过程是最痛快的一次. 接下来我们的目标锁定在"黑色n秒"(刚发现一个英文说法:stuck for x seconds)这个坑我们最多.最神秘.最诡异的坑

云计算之路-阿里云上:什么是“黑色1秒”?

为了更好地分享我们解决"黑色1秒"问题的过程,在这篇博文中我们将专门描述一下"黑色1秒"问题的表现. "黑色1秒"是我们使用阿里云以来继"黑色10秒"之后遭遇的最奇特.最诡异.最难以捉摸.最富有戏剧性的问题. 它有2个最显著的特征: 第一个是最直观的表现,在Windows性能监视器(Performace Monitor)中会出现1秒的ASP.NET Applications -> Requests/Sec(简称QPS)为