云计算之路-阿里云上-容器难容:优化自建 docker swarm 集群的部署
在上周六遭遇阿里云容器服务 swarm 版的故障之后,我们决定还是走自建 docker swarm 之路,只要不是阿里云底层的问题,我们相信会找到办法解决或避开自建 docker swarm 不稳定的问题。
以下是我们即将采用的 docker swarm 集群部署优化措施。
1)2 个 overlay 网络合并为 1 个,以减少维护多个 overlay 网络的开销
之前用了 2 个 overlay 网络 cnblogs 与 proxy ,路由容器 docker-flow-proxy 只加入 proxy 网络,所有容器加入 cnblogs 网络,需要路由的容器才加入 proxy 网络。现改为 1 个 overlay 网络,所有容器(包括 docker-flow-proxy)都加入同一个网络。
2)限制每个容器最大可以使用的 CPU 与 内存,以免有应用消耗过多 CPU 或内存而拖垮节点
以下是 docker swarm compose 文件中的配置
deploy:
resources:
limits:
cpus: "1.5"
memory: 1.5G
3)将 service 的更新顺序由 stop-first 改为 start-first ,以免更新时造成单个容器负载过高
stop-first 是 docker swarm 的默认方式,更新时先停止旧容器,然后启动新容器。我们的每个服务部署了 2 个容器,先停止 1 个容器会将负载集中到另外 1 个容器,从而增加容器所在节点的负载。改为 start-first ,先启动新容器,后停止旧容器,可避免这个问题。
deploy:
update_config:
order: start-first
4)将 docker-flow-proxy 的 proxy_proxy 服务改为全局部署
proxy_proxy 是访问的入口,所有外部访问请求都由它转发给对应的容器,全局部署(每个节点部署)可以减少跨主机网络通信。
deploy:
mode: global
5)使用阿里云弹性网卡,弹性网卡放在同一个专属的 VPC 交换机中,所有节点都绑定弹性网卡,这样每个节点有 2 块网卡,节点之间的 docker swarm 通信走弹性网卡。
docker swarm init --advertise-addr 弹性网卡IP
6)将操作系统由 ubuntu 16.04 换成 centos 7.3
本来没打算进行这个更换,更换是由于 ubuntu 16.04 不直接支持阿里云弹性网卡(需要另外手工配置),之前一直用的是 ubuntu 16.04 跑 docker swarm ,正好借此机会换上 centos 看看效果。
2018年5月15日更新
后来实际采用的部署:
1)还是用了 2 个 overlay 网络,以便于进行内外网应用之间的隔离
2)继续采用
3)继续采用
4)用基于约定的静态配置的 nginx 取代了 docker-flow-proxy ,nginx 也是全局部署
5)由于 docker swarm 对多网卡的支持有问题,放弃使用多网卡
6)继续采用
7)设置 reserve memory
7.1)借助一个容器为系统保留内存
resources:
limits:
memory: 600M
reservations:
memory: 600M
7.2)给每个应用容器设置了 reservations - memory ,以避免将太多容器部署在一个节点上
8)设置 task-history-limit 以减少 manager 解决的资源消耗
docker swarm update --task-history-limit 2
9)在服务器资源配置上由“保 manager 节点为主”改为“保 worker 节点为主”,即使 manager 节点宕机,已运行于 worker 节点上的应用容器依然可以正常工作。
云计算之路-阿里云上-容器难容:优化自建 docker swarm 集群的部署的更多相关文章
- 云计算之路-阿里云上-容器难容:自建docker swarm集群遭遇无法解决的问题
我们从今年6月开始在生产环境进行 docker 容器化部署,将已经迁移至 ASP.NET Core 的站点部署到 docker swarm 集群上.开始我们选用的阿里云容器服务,但是在使用过程中我们遭 ...
- 云计算之路-阿里云上-容器难容:容器服务故障以及自建 docker swarm 集群故障
3月21日,由于使用阿里云服务器自建 docker swarm 集群的不稳定,我们将自建 docker swarm 集群上的所有应用切换阿里云容器服务 swarm 版(非swarm mode). 3月 ...
- 云计算之路-阿里云上:从ASP.NET线程角度对“黑色30秒”问题的全新分析
在这篇博文中,我们抛开对阿里云的怀疑,完全从ASP.NET的角度进行分析,看能不能找到针对问题现象的更合理的解释. “黑色30秒”问题现象的主要特征是:排队的请求(Requests Queued)突增 ...
- 云计算之路-阿里云上:Web服务器遭遇奇怪的“黑色30秒”问题
今天下午访问高峰的时候,主站的Web服务器出现奇怪的问题,开始是2台8核8G的云服务器(ECS),后来又加了1台8核8G的云服务器,问题依旧. 而且3台服务器特地使用了不同的配置:1台是禁用了虚拟内存 ...
- 云计算之路-阿里云上-新发现:又一种与虚拟内存有关的CPU波动情况
在云上真是无奇不有,昨天偶然间发现在IIS的应用程序池回收设置中,仅仅设置了一下基于虚拟内存限制的回收,就引发了CPU有规律的波动.在这篇博文中,我们将向大家汇报一下云计算之路上的这个小发现. 在之前 ...
- 云计算之路-阿里云上:启用Windows虚拟内存引发的CPU 100%故障
今天上午11:35~11:40左右,由于负载均衡中的两台云服务器CPU占用突然飚至100%,造成网站5分钟左右不能正常访问,请大家带来了麻烦,请谅解! (上图中红色曲线表示CPU占用) 经过分析,我们 ...
- 云计算之路-阿里云上:SLB会话保持的一个坑
冒着被大家厌烦的风险,今天再发一篇“云计算之路-阿里云上”.这是在前一篇发过之后真实发生的事情,我们觉得定位问题的过程值得分享.而且估计园子里不少朋友被这个问题骚扰过,我们有责任让大家知道问题的真正原 ...
- 云计算之路-阿里云上:原来“黑色0.1秒”发生在socket读取数据时
在昨天的博文(云计算之路-阿里云上:读取缓存时的“黑色0.1秒”)中我们犯了一个很低级的错误——把13ms算成了130ms(感谢陈硕发现这个错误!),从而对问题的原因作出了错误的推断,望大家谅解! 从 ...
- 云计算之路-阿里云上:禁用Windows虚拟内存引发的重启
昨天(2013年8月6日)下午,承载www.cnblogs.com主站的两台云服务器分别自动重启了1次,由于这两台云服务器使用了负载均衡(SLB),重启并未影响网站的正常访问. 与这次重启相关的Win ...
随机推荐
- CentOS中配置NFS服务
1.服务器端安装rpcbind.nfs-utils.nfs-server包 yum install nfs-utils -y 2.修改服务器端配置文件,添加需要共享的文件夹. vim /etc/exp ...
- Java并发系列[7]----CountDownLatch源码分析
CountDownLatch(闭锁)是一个很有用的工具类,利用它我们可以拦截一个或多个线程使其在某个条件成熟后再执行.它的内部提供了一个计数器,在构造闭锁时必须指定计数器的初始值,且计数器的初始值必须 ...
- PyCharm运行报编码错误
运行报如下错误: SyntaxError: Non-ASCII character '\xe8' in file /home/ubuntu/code/201803091253-text.py on l ...
- 基于数据库的自动化生成工具,自动生成JavaBean、数据库文档、框架代码等(v5.8.8版)
TableGo v5.8.8版震撼发布,此次版本更新如下: 1.新增两个扩展字段,用于生成自定义模板时使用. 2.自定义模板新增模板目录,可以选择不同分类目录下的模 ...
- sass学习笔记--摘录
//$a: Helvetica, sans-serif //$b: #333 // //body //font: 100% $a //color: $b //$a: red //body //colo ...
- 【LightOJ1282】Leading and Trailing(数论)
[LightOJ1282]Leading and Trailing(数论) 题面 Vjudge 给定两个数n,k 求n^k的前三位和最后三位 题解 这题..真的就是搞笑的 第二问,直接输出快速幂\(m ...
- Rotational Region CNN
R2CNN 论文Rotational Region CNN for Orientation Robust Scene Text Detection与RRPN(Arbitrary-Oriented Sc ...
- C++学习-6
1.Auto无法区分常量变量,引用常量(顶层const被忽略了),不能识别引用变量,const和&都无法识别 Auto不能放在结构体内部 2.decltype()能识别引用,能获取常量属性,t ...
- Starting a Gradle Daemon, 5 busy and 1 incompatible and 1 stopped Daemons could not be reused, use --status for details FAILURE: Build failed with an exception. * What went wrong: Could not dispatch
执行gradle build出的问题,查看hs_err_pid11064.log日志文件发现,是电脑的RAM不足导致
- CucumberJS 资源
https://cucumber.io/docs/reference/javascript https://github.com/cucumber/cucumber-js