云计算之路-阿里云上:针对 docker swarm 故障的部署调整以及应急措施

针对上周 docker swarm 集群的频繁故障(详见故障一故障二故障三),我们今天对 docker swarm 集群的部署进行了如下调整。

将 docker engine 由  “17.12.0-ce, build c97c6d6”  升级至  “17.12.1-ce, build 7390fc6” ,这是 docker 在 2 月 27 日发布的最新稳定版

~# docker -v
Docker version 17.12.1-ce, build 7390fc6

将之前的 “5 个 manager 节点 + 1 个 worker 节点” 调整为 “3 个 manager 节点 + 3 个 worker 节点”,3 个 manager 节点的阿里云服务器配置为 1 台 4 核 8 G  + 2 台 2 核 4 G ,3 个 worker 节点的配置为 3 台 4 核 8 G ,应用容器尽量部署在 worker 节点上。

使用新的部署后,昨天 18:00 左右集群又出现了宕机,当时怎么处理也无法恢复,最后实在没办法,通过阿里云控制台强制重启所有节点服务器后,竟然神奇地一切恢复正常。

在目前问题没有根本解决的情况下,我们会采取这样的应急措施:部署一个备用 docker swarm 集群,当主集群出现故障时,切换到备用集群。

另外在周末遇到一次节点服务器“死机”的情况,ssh 登录无响应,通过阿里云控制台管理终端登录也没有响应,唯有通过阿里云控制台强制重启服务器。

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

时间: 2024-08-27 10:09:20

云计算之路-阿里云上:针对 docker swarm 故障的部署调整以及应急措施的相关文章

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

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

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

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

云计算之路-阿里云上:对“黑色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)为

云计算之路-阿里云上:消灭“黑色n秒”第一招——不让CPU空闲

昨天对"黑色n秒"问题的最终猜想以失败而告终,从而让我们结束了被动猜想阶段,进入了主动进攻阶段--出招. 今天出第一招--用C#写个小程序,让其在每个CPU核上运行一个线程,不让任何一个CPU核进入空闲(idle)状态,以进一步排除CPU idle引起的"黑色n秒". 在这一招中,借助的最重要的武器是System.Diagnostics.ProcessThread.ProcessorAffinity.通过给ProcessorAffinity设置一个掩码,就可以指定当

云计算之路-阿里云上:消灭“黑色n秒”第二招——给w3wp进程指定CPU核

虽然昨天的第一招失败了,但是从失败中我们学到了与多核CPU相关的Processor Affinity(处理器关联)的知识. 既然我们可以让.NET程序的不同线程运行于指定的CPU核,那是不是也可以让IIS应用程序池的进程w3wp运行于指定的CPU核? 虽然看起来"黑色n秒"似乎与w3wp运行于哪些CPU核没有什么关系,但是我们既然把怀疑对象锁定在CPU,那么任何与CPU相关的线索都不能放过.即使失败,也会满载而归,因为如果没有"黑色n秒"这个问题的驱动,我们根本不会

云计算之路-阿里云上:排查“黑色30秒”问题-为什么请求会排队

http://www.cnblogs.com/cmt/p/3682642.html 针对Web服务器“黑色30秒”问题(详见云计算之路-阿里云上:Web服务器遭遇奇怪的“黑色30秒”问题),经过分析,我们准备从这个地方下手——为什么会出现\ASP.NET\Request Queued大于0的情况(为什么请求会排队)? 首先, 通过Windows性能监视器去观察,看能不能找到这样的线索——在什么条件下会触发请求排队? 我们在性能监视器中增加了1个监视指标——\HTTP Service Reques

云计算之路-阿里云上:超过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)在收到请求后

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

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