微博DCP弹性调度的需求是快速迭代实现内网私有云计算资源统一管理调配,公有云上获得计算资源,实现快速自动化资源调度与应用部署。我们要解决的问题主要有服务池动态伸缩、单机容器灰度、多实例部署、故障自动恢复、定制的调度算法与策略、容量评估、跨IDC调度等。
如上图所示,不可避免的问题是,业界任一调度框架Mesos、kubernetes、Swarm都不能是解决微博业务现状面临的资源调度问题的“银弹”。所以我们设计了一个调度适配层生态圈系统Roam。封装调度框架提供通用Rest API,适配不同资源管理框架。同时自实现特定的调度伸缩策略等。本文将主要介绍新浪微博混合云架构上的可扩展、可插拔式统一弹性调度平台的建设。
弹性调度系统架构演进
微博混合云刚开始阶段直接使用Swarm。Swarm是Docker官方推出容器集群管理工具,属Docker原生体系,提供标准标准Docker API对Docker Container cluster进行管理,接入成本低,基于标签的分组调度,满足微博业务现状需求。Swarm管理Docker容器集群很简单:
docker run swarm-manage
启动依赖服务发现swarm join consul
各节点docker run swarm-agent
这样你便可通过Swarm API进行容器集群管理。由于微博开始用Swarm比较早,当时基本在官方还是beta版本,面对微博现实复杂业务场景以下几点无法满足:
大规模集群调度性能问题;
单机灰度需求;
特定调度策略无法支持;
高可用需求。
Swarm在最开始版本发起调度有全局锁,这样整个过程就变为串行,影响调度性能。排查发现调度慢主要集中在拉镜像比较慢,改进优化为预拉镜像,提升性能。Swarm1.0版本后改为分布锁,同步也大大提升性能。
针对以上问题我们对Swarm进行了二次封装,研发出调度适配层系统Roam。Roam对外提供Rest API,通过Swarm获取Docker容器信息,外层自适配调度策略后下发Swarm集群,同时支持Docker Deamon直接下发。
对Swarm集群按照机房进行拆分,实现高可用、动态扩展。
Swarm Manage、Client节点向Consul服务发现注册,当前Manage在Consul处于加锁状态;
Roam根据IDC参数从Consul获取需要调度机房 Manage信息;
Roam弹性调度策略,访问当前Manage,选择资源动态扩缩容;
Swarm Mange从Consul获取节点信息,30s缓存Node节点信息。
当其中一组Master节点宕掉,Standby Master注册进入Consul成为新主节点。
自定义调度策略
简单介绍下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规划、定时调度、多实例调度等。
离线计算资源调度
微博备战元旦峰值时,需要整合离线技术资源及公司其他业务线带来了新的挑战。离线Hadoop计算资源服务器大多操作系统为CentOS6.*,CentOS6.* 支持Docker 1.6.2版本存在bug,而Swarm调度获取内存、CPU资源信息依赖Docker版本必须大于Docker 1.6.2。以此为契机Roam扩展支持Mesos + Marathon、直接Docker Demon下发两种调度方式。
弹性调度系统
不同调度框架按照集群进行划分,统一由Roam提供Rest API管理。完整的调度系统也依赖周报体系建设:服务编排、服务发下、容量评估等构成弹性调度生态圈,其它模块后续将由微博平台其它同学来给大家介绍,敬请关注InfoQ专栏。
业务跨云弹性调度
如何将业务合理调度到计算节点上?
跨云业务部署时,应该使得业务以最小规模部署,在公有云上通过预付费方式,常态化部署业务的最小规模,并提供在线服务。另外应该尽量减少跨云专线的调用,保持带宽在可控范围之内,需要将业务后端资源Memory Cache等本地化,减少跨专线请求;一旦发生跨专线请求时,需要开启一些流量压缩的协议。同时,微博内部通过WMB缓存数据双向同步机制,基于消息分发策略,在专有云内部对缓存的读写以消息的方式同步到公有云的缓存上,延迟一般在毫秒级,同时在专线出现异常时,消息不会丢失,保证高可用。
微博弹性调度离不开微博高可用多机房架构。上图是2016年春晚时微博的业务混合云部署形态。内部是典型的后端互联网服务技术站,通过四层的负载,用Nginx实现七层负载,再往后是一些Web层的计算和RPC服务,最下面是缓存层的资源、数据库。由于数据库的请求量和数据安全要求比较高,因此暂时没有将DB层放到公有云上。架构的中间是采用了SLB服务、之下的RPC、Web、Nginx都是部署在ECS上的。
春晚峰值流量来临优先弹性内网资源。阿里云常备部署不需要弹性资源如缓存Memcache、队列处理机等依赖。Web前端机常规30台机器,春晚主体弹性扩容Web前端机至1000+,很好完成备战三节。
综上所述弹性调度系统采用了开源的解决方案,例如Swarm、Mesos等。在它们的基础上封装了统一调度的API,将原来专有云内分散的各个应用平台统一到一起,大大节省在基础运维上的时间成本。
总结
弹性调度作为新浪微博混合云架构的重要组件,其框架选型要从业务需求出发来设计系统架构。而业务落地要考虑资源调度框架对周边技术体系建设的依赖,考虑通用性设计实现,以及技术架构的迭代升级。弹性调度后续发展方向为数据中心操作系统,整合在线、离线资源,以更大程度地提高资源利用率。
▽
延展阅读(点击标题):
日活1亿+:看新浪微博混合云DCP的架构实战
微博混合云架构实践之不可变基础设施
本文系InfoQ原创首发,未经授权谢绝转载。