【Container容器技术】3-1 浙江移动数据中心操作系统（DCOS）实践分享.ppt

18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 数据中心容器视图 生产实践 注册用户3000万，日活跃用户数300万 “双十一”抢购，并发数峰值近6万次/秒 手机营业厅试点 B域核心--CRM系统全省迁移完成 截至16年5月，已有15套应用系统平稳运行在DCOS平台上 多核心系统推广 自主开发DCOS管理平台，集快速部署、持续集成、日志、告警和弹性伸缩于一身 管理平台 建设 DCOS优势分析 DCOS优势 高资源利用率 高效的跨数据中心的资源调度 DCOS相较于虚拟机有着基于CPU、内存、IO的更细粒度的资源调度，多个计算框架或应用程序可共享资源和数据，提高了资源利用率。 高可用性、容灾 DCOS平台展现了其在线性扩展、异地资源调度等方面的优异性能，无需大二层网络实现跨机房的资源调度。 ， 弹性扩缩容 DCOS平台所有组件采用分布式架构，应用跨机房分布式调度。自动为宕机服务器上运行的节点重新分配资源并调度，保障业务不掉线，做到故障自愈。 彻底解决应用的扩缩容问题，容量管理从“给多少用多少”向“用多少给多少”转变，被动变主动。应用的扩缩容时间从传统集成方式的2-3天缩短到秒级，可以根据业务负载自动弹性扩缩容。 第一部分 走向DCOS之路 第二部分 中国移动DCOS实践 第三部分 经验与分享 应用改造 接入层的无状态化改造 去 session 交互用 +json短连接 Session信息放缓存 Client HAProxy WEB1 WEB2 WEB3 Redis sessionId 应用改造 内部服务调用的改造 接口：同接入层一样使用负载均衡方案HAProxy+Confd+Etcd； 服务化框架：使用服务化框架服务的注册发现功能，注意需要将容器外的IP和端口上报给配置中心。 WEB1 APP1 Marathon WEB2 APP2 APP3 Zookeeper 弹性扩缩 Marathon的扩缩容默认只能根据用户需要进行手动调整，我们结合多年的系统运维经验，实现基于并发数、响应时间、CPU和内存使用率等容量指标进行自动弹性扩缩容调度的算法。 数据中心切换 踩过的坑 网络中断引起服务注册发现异常 2.WEB获取APP路由信息 1.APP启动注册路由信息 3.WEB访问APP 问题描述 应用前台大范围报错：no available app found。 问题分析 网络一直波动导致zk频繁选举，web从zk中获取的app信息未及时更新。 解决方案 增加APP节点信息定期对比校验机制。 踩过的坑 容器分布不均衡 问题描述 生产过程中，发现个别计算节点CPU使用率较高，其上的应用访问速度慢甚至异常的情况。 问题分析 发现该服务器上的容器数量过多，导致资源紧张。 解决方案 设置Marahon constrains策略为hostname:GROUP_BY 踩过的坑 F5-HAProxy健康检查异常 问题描述 测试过程中，发现基于TCP健康检测策略的F5设备出现HAProxy健康检测失败的情况。 问题分析 F5 TCP健康检查时需要HAProxy进行回包才能认为健康检测正常，而HAProxy只是代理功能，无回包功能。 解决方案 修改haproxy.cfg配置文件。 踩过的坑 容器CPU资源超卖 问题描述 生产过程中，发现个别应用CPU使用率过高，出现CPU争抢情况，影响其他应用正常运行 问题分析 通过Marathon设置的CPU大小无法限定容器CPU实际使用大小，出现超卖情况。 解决方案 通过marathon设置Docker的cpu-quota参数，限制单容器CPU使用率。 踩过的坑 问题描述 压力测试过程中，发现无论如何调整集群容器数量，TPS一直上不去。 问题分析 通过对负载均衡HAProxy的路由分析，发现请求分发并不均衡。 解决方案 修改haproxy.cfg配置文件，将balance负载均衡策略由roundrobin（轮询策略）修改为leastconn（最小连接）策略。 HAProxy负载不均衡 经验总结 联合研发的工作模式 依托开源社区，联合合作伙伴攻关，中国移动在运营商中率先完成DCOS试点建设，为中国移动的IT技术自主化推广实践积累了宝贵经验。 自动化弹性伸缩的技术架构 选择合适的开源技术路线，结合运维实践经验，实现应用根据业务压力变化而自动弹性扩缩容，成为运营商内首个实际案例。为IT私有云发展和IT架构转型工作奠定了坚实的基础。 传统应用改造的实践经验 对传统应用进行改造，实现了应用的无状态化，与DCOS平台上动态的扩展和伸缩无缝适配，积累了核心系统DCOS化改造的工作经验 自主开发的持续集成平台