UDN-企业互联网技术人气社区

板块导航

浏览  : 1227
回复  : 0

[技术交流] 新浪公有云Docker编排实践(下)

[复制链接]
htmlman的头像 楼主
发表于 2016-7-14 10:58:48 | 显示全部楼层 |阅读模式
本帖最后由 htmlman 于 2016-7-14 10:58 编辑

2.png

2.png

  谈到调度都离不开Swarm、Mesos、Kubernetes,大家讲的比较多的都是Mesos、Kubernetes,先说一下结论,今年年初的时候我们选用了Swarm,我们认为最适合业务的才是最好的。为什么选择Swarm?,因为它是Docker体系原生的,整个体系比较简单,也能支持我们的内存隔离,支持我们的分组调度,当然它是以标签的形式实现的分组隔离。微博备战元旦峰值时,需要整合离线技术资源及公司其他业务线带来了新的挑战。离线Hadoop计算资源服务器大多操作系统为CentOS 6,CentOS 6支持Docker 1.6.2版本存在bug,而Swarm调度获取内存、CPU资源信息依赖Docker版本必须大于Docker 1.6.2。以此为契机Roam扩展支持Mesos + Marathon、直接Docker Demon下发两种调度方式。考虑后续整合公司的离线资源,Kubernetes现在在非容器方面还有瓶颈,所以暂没有考虑。
2.png

 其实我们的需求是实现内网计算资源的统一调配,公有云上获得计算资源,快速自动化部署。上图有一个接口层,我们提供了通用进行调度来满足以下的功能。任何一个调度框架都不能完全满足我们的需求,拿到的任何一个框架也不能直接用,因为可能要有一些特性化的需求,比如服务池的动态扩增容,跨服务池、跨租户来调度,以及单机业务的灰度、多实例的部署、故障自动恢复、容量评估、跨IDC的高可用,所以我们做了二次开发,对外提供统一的Rest API
2.png

  Swarm集群规模估计是国内相对比较大规模。重点讲一下Swarm,Swarm属于轻模式。首先我们做了它的高可用,就是双主策略,多机房的调度,还有对它的调度性能、调度算法做了一个优化,包括一些分组的调度和一个调度策略的设计。Swarm在最开始版本发起调度有全局锁,这样整个过程就变为串行,影响调度性能。排查发下调度慢主要集中在拉镜像慢,改进优化为预拉镜像,提升性能。Swarm 1.0版本后改为分布锁,同步也大大提升性能,内部测试单机房Swarm支持千节点是没有问题的。针对以上问题针对Swarm进行二次封装,研发出调度适配层系统Roam。Roam对外提供Rest API,通过Swarm获取Docker容器信息,外层自适配调度策略后下发Swarm集群,同时支持Docker Deamon直接下发。
2.png

  现在简单说一下我们怎么做的高可用,动态调度的多IDC、高可用、可扩展。Swarm集群按照机房进行拆分,高可用、动态扩展:

  • Swarm Manage、Client节点向Consul服务发现注册,当前Manage在Consul处于加锁状态;
  • Roam根据IDC参数从Consul获取需要调度机房 Manage信息;
  • Roam弹性调度策略,访问当前Manage,选择资源动态扩缩容;
  • Swarm Mange从Consul获取节点信息,30s缓存Node节点信息。

  当其中一组Master节点Down掉,Standby Master注册进入Consul成为新主
2.png

  简单介绍下Swarm调度策略(如上图):

  调度=主机 or 容器过滤 + 策略选择。

  • 主机/容器过滤通过过滤器(标签)实现 Docker run –label idc=”tc”。
  • 主机/容器过滤后,根据各个节点的可用的CPU、Mem及正在运行的容器的数量来计算应该运行容器的节点进行打分,剔除掉资源不足的主机。

  调度颗粒度:

  • Memory:Docker run –m 1g …
  • CPU:Docker run –c 1 …

  基本所有的调度框架分组调度都是标签,Swarm基于Docker Deamon Label标签(Docker Label标签修改必须重启Docker Deamon,在最近官方Docker 1.10.0版本已支持Docker Engine配置热更新,使容器与Docker Deamon的耦合性大大降低)。在Docker Label标签基础上,对标签进行扩展进行落地存储,记录执行不同调度策略,集成Swarm调度算法,支持跨集群/服务池调度、指定IP规划、定时调度、多实例调度等。
2.png

  Swarm的调度算法并不是太神秘,最核心的调度算法,最简单来看就是使用的CPU或内存除以物理机的内存,就是物理机所用资源占比。再看一下CPU的分数,如果内存的分数同时满足的话,总分数为CPU加内存的分数,并非很复杂。如果大家需要定制自己算法策略,可以去修改源码或者使用其他算法,但是目前这种条件下满足我们的需求,比如把这些策略选择出来之后,有一个80分,有一个90分,我们肯定选择用90分的。因为我们是尽量保证主机资源均摊使用。在调度算法中大家需要注意一点,就是Swarm资源只与容器Create时配置设定资源参数有关,与运行时实际使用资源情况无关。无论容器是否由Swarm创建,无论容器处在何种状态,只要配置了资源限额,调度时均会计算在内。
2.png

  我们跨云端调度还面临其他挑战。千台节点服务同时拉取镜像,还是跨IDC情况,镜像仓库是扛不住的,很容易因为拉镜像时间过长导致调度失败。在内网的情况下我们的Docker不会遇到这个问题,因为大家机器上都用Docker,基础镜像都已在上面,阿里云端为新装机ECS,没有基础镜像。我们在内网做了自己的私有仓库,在阿里云上做了自动同步私有仓库的镜像缓存集群,后续云端扩展到了多级镜像缓存。
2.png

  跨云端服务发现的时候,七层流量的频繁变更会影响业务性能。微博Nginx Plus的开源版,支持基于Consul的自动服务发现,Docker容器启动会自动向Consul服务注册中心进行注册,Nginx的模块我们开发了自己的一个Core Module,作用就是去Consul拉刚才注册的容器节点信息,然后同步更新,实现平滑流量变更。可以看下上图,这是我们使用Nginx Plus之后,服务变更耗时基本无波动。同时我们设计了动态修改线上云端节点的权重动态适配后端的处理能力,公有云同等配置存在20%的性能损耗,建议权重调低。微博内部用的是Motan RPC的服务发现,它支持跨IDC流量切换,支持按流量权重配制定向路由。DNS服务发现,我们在阿里云上构建DNSServer与内网保持同步。
2.png

2.png

  还有最重要的是监控体系,服务真正跑起来,怎么知道健康状况?我们的监控分四个级别,系统级监控、业务级监控、资源级监控和专线网络监控。业务级监控是全网监控到单机容器监控。我们的容量评估系统在线压测确定服务指标,根据单机的平均系统指标(CPU idie Mem Load)带宽、业务SLA综合指标容量评估,来决策服务的扩容或者缩容。
2.png

  当上面所有的都做完之后,主机创建,初始化完,动态调度完毕之后,然后简单来看三节保障与阿里云部署。在春晚时主要扩容无状态Web服务,可以做到10分钟扩容到千节点容器规模,抵抗峰值流量。在这里大家要了解一个情况,阿里云产品会有PPS的限制,可能在内网的时候PPS达到几十万没问题,云产品上限是10万+左右, 会影响业务单机承载能力。
2.png

  跨IDC混合云架构离不开基础网络,微博本身在北京核心两个机房。阿里云在北京有三个可用区,最大的是A和C,它是BGP多线接入的,微博电信、联通两根专线分别于阿里云A、C机房微博私有VPC网络互通,专线保证高可用,任何一条专线断了之后,另外一条路由自动进行切换。中间还搭了一个VPN网络,这个是走公网的,有一些需要推日志或者一些业务因为数据需要交互就走公网,因为它没有实时性的要求,我们就走这条线路。
2.png

  总结一下,其实2014年我们做了容器化,混合云DCP项目是在2015年10月份上线的,所有集群按三个IDC来拆分,峰值2500+的容器,包括业界前一段也有测试,一秒钟创建3000个容器乃至1万个容器是没问题的。双十一微博内网实现单日10多次扩缩容,单次扩容小于5分钟。元旦的时候实现的跨云扩容,微博混合云架构小规模试用。春晚动态扩缩容阿里云ECS千台+规模,承载微博核心Feed流及红包飞流量。
2.png

2.png

  这次分享偏向项目应用实践,最大感触就是从业务需求出发去设计系统架构,没有最好的架构和技术,目标是业务需求完成。比如我们现在真正实现了10分钟创建1000个节点的能力,解决了这种峰值流量的问题,Swarm其实满足业务目标应用场景,所以就选择了Swarm做容器调度。在用Swarm的过程中,包括一些单机灰度、分组调度问题,我们通过二次开发来解决。Swarm使用遇到的问题在其他资源调度框架都会遇到,没有任何框架都是拿来即用,最重要就是去实践,总结共性,设计通用性架构,所以就有了Roam的适配层适配不同调度框架。混合云项目周边体系比如监控、服务发现、在线容量评估等也是非常重要,这也是任何云平台不可缺的组件。

原文作者: 付稳 来源:Docker


  新浪公有云Docker编排实践(上)

相关帖子

您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部