微信号:Cloudify

介绍:高可用、分布式系统研究,数据中心技术以及生产环境最佳实践,云计算前沿技术剖析

Spotify的机器管理进化之路

2016-04-19 07:12 吕宏利

背景介绍

Spotify是一家瑞典的提供流媒体音乐服务的公司,公司创建于2006年4月,在2008年10月正式对外提供服务,目前是全球最大的正版流媒体音乐服务平台。
根据统计数据显示,该公司流量进入高速增长期是在2012/2013年,这也刚好契合了文中提到的,机器管理方式的改变是从2013年开始的。公司截至2016年第一季度,一共有差不多12K服务器(物理机+虚拟机),

Spotify subscribers growth

本文是根据Spotify发布的英文文章翻译整理而成,原文在这里:https://labs.spotify.com/2016/03/25/managing-machines-at-spotify/,原文是按照时间顺序讲解的,本文并没有直接翻译原文,而是根据我的理解提取原文的精华内容并加上自己的分析注释,以飨读者。

2012年以前 - 黑暗史

在Spotify成立的开始几年中,公司有一个专门的Ops部门负责所有的Operation工作,经常处于救火的状态。有工程师头脑的Operation部门员工们不愿意手工去管理日益增长的服务器数量,于是开发了第一个管理机器相关的工具:ServerDb。该工具记录了机器的详细硬件配置、所处机房位置、机器名、网卡信息以及唯一的硬件名。每台物理服务器在ServerDb中还有对应的状态信息,比如:’in use’, ‘broken’ 或者 ‘installing’。最早ServerDb由一个简单的SQL数据库外加一对脚本构成。
机器的安装和管理还涉及以下几个系统:

  • moob(http://github.com/spotify/moob)负责带外(Out of Band)管理

  • DNS 负责服务的发现和配置管理

  • Puppet统一管理安装好的服务器

而关于服务器的安装工作,最早是Fully Automated Installer(http://fai-project.org/)负责系统安装,后来被Cobbler(http://cobbler.github.io)和debian-installer(https:/www.debian.org/devel/debian-installer)取代,再后来debian-installer被公司研发的Duck(https://github.com/spotify/duck)取代。
此时的现状是,尽管很多部署机器的过程已经自动化了,但是某些步骤是特别容易出错并需要人工介入的,即使是部署20台机器所花费的时间都是不可预期的。工程师们需要在JIRA系统里创建一个资源申请请求,然后需要等几个星期甚至几个月才能拿到所申请的机器资源。

通过这一段历史的介绍,我们知道这个时期有2大痛点:

  • 服务器安装过程很不稳定,以至于经历了多次改版。

  • 资源的申请流程自动化程度很低,以至于资源交付时间过长。

这个时期也有2个好的设计:

  • DNS做服务发现和配置管理,通过SRV记录实现服务发现,通过TXT记录一些简单的负载均衡信息。

  • ServerDb做为机器的可信数据源(Single Source of Truth),记录机器配置和所处的服务状态。

DNS的选择在当时来看是正确的选择,因为技术成熟,部署容易,基于DNS的客户端开发比较简单,虽然需要手工编辑DNS的zone文件来变更,但是得益于当时的流量增长还没有进入爆发期,推测修改频率应该不高。
类似ServerDb的机器管理系统可能很多公司都有,但是该管理系统作为什么角色就各不相同了,Spotify的选择是作为可信数据源,可以看出是和资产管理系统分离的。
ServerDb可以说是非常成功的一个内部产品,从后面的介绍中可以看出,ServerDb是个一直存在的系统,只不过一直在进行版本的迭代以支持不同时代的使用需求。

2013年底 - 转折

公司新成立的IO(Infrastructure and Operations)部门接管了最早的Ops部门,并成立的专项Agile小组负责解决Operations领域的各个问题。
其中负责机器部署管理Agile小组制定了宏伟的目标:机器管理的自助化服务,但是最终被繁忙的工作淹没,该目标并没有实现。在进行目标修正之后,采取MVP(Minimal Viable Products)原则先自动化最大的痛点来赢得时间,所以将力量集中在三个领域:

  • DNS修改

  • 机器的系统录入

  • 资源申请自动化

DNS修改

早期的操作流程是:手工修改zone文件,提交到代码库,在DNS Master上执行脚本编译和部署新的zone文件。
DNS修改的自动化是逐步实现的,首先通过工具根据ServerDb自动生成zone data,然后添加集成测试和代码review机制,最后自动化了到DNS Master的push操作。整个流程的触发是通过一个计划任务实现的。

机器的系统录入

此时的ServerDb已经变成了一个服务,对外提供REST接口。此时的机器录入是通过解析CSV文件实现的,这些CSV文件包含机架和MAC地址等信息,很容易录入错误。
指定的最终目标是当机器被安装在机架之后无人工的自动化录入。首先把提供网络安装功能的Cobbler换成了iPXE(http://ipxe.org),iPXE可以通过读取ServerDb里的机器状态引导机器到不同的环境。’In use’状态的机器会进入Production OS环境;’installing’状态的机器会被引导到Duck创建的Linux环境, 然后安装系统;如果机器对ServerDb是未知的,除了会安装系统之外,还会录入信息到ServerDb中。机器的唯一标识是机器的序列号,唯一且可以容易的通过程序访问。

资源申请自动化

此方面的改进可以简单概括为:鸟枪换炮
之前有一个自动化处理资源申请的工具叫provgun - Provision Gun,是一个脚本自动抓取JIRA上的申请生成处理请求的命令。一个资源申请包含了:需要的地点、角色、硬件配置和机器数量。比如:需要在伦敦安装10台高性能机器,角色为fancydb。provgun会在ServerDb中找到符合条件的机器,指定机器名,并且在ServerDb中指定机器状态进行系统安装。
ServerDb通过Celery(http://www.celeryproject.org)来调用ipmitool(http://linux.die.net/man/1/ipmitool),ipmitool可以控制机器网络启动到pxeimage进行系统安装,安装完毕并进入新系统后Puppet会根据机器的角色应用相关的配置。
由于provgun缺乏对执行命令返回状态的检查,不能简单的用cron来执行provgun来自动化处理资源申请。然后provcannon - Provision Cannon诞生了,一个Python版的provgun,并增加了返回值检查以及失败重试等功能,provcannon每天执行2次批量处理资源的申请。

MVP原则的实施很成功,通过将精力集中在三个方面,很快资源请求的处理时间从几个星期降低到了几个小时。DNS的更新工作从日常操作中消失了。更重要的是现在他们有更多的时间改进系统了。

2014年 - 喘息

在资源交付时间缩短到几个小时后的几个月里,工程师们对大大缩短的交付过程非常满意。但是随着新员工的入职,有过AWS和类似平台经验的工程师对几个小时的交付时间并不满意。
资源的交付时间之所以只能做到几个小时,是因为之前虽然自动化了系统安装,但是比如重启机器、机器回收等处理仍然需要人工阅读JIRA请求并执行脚本处理。这时候,之前被抛弃的宏大目标重新被提上了日程:一个自助服务平台和API。这期间上线了2个重要的系统。

Neep

Neep是一个服务,负责处理机器的安装、回收和重启,Neep在每个数据中心都有,并且可要通过OOB管理机器。Neep基于RQ(http://python-rq.org)提供轻量级的REST API。适用Pyramid(http://www.pylonsproject.org)作为Web Framework,ServerDb作为Pyramid的一个服务。

{
  "status": "finished",
  "result": null,
  "params": {
  },
  "target": "hardwarename=C0MPUT3",
  "requester": "negz",
  "action": "install",
  "ended_at": "2015-07-31 17:45:53",
  "created_at": "2015-07-31 17:36:31",
  "id": "13fd7feb-69d7-4a25-821d-9520518a31d6",
  "user": "negz"
}

An example Neep job

provcannon的大部分代码逻辑都被Neep重用了。安装、回收和重启这些动作在Neep看来都是意义的,因为它只是简单的修改ServerDb中机器的状态,比如设置为’installing’ ,则pxeimage会给机器安装新系统。

Sid

Sid是工程师进行资源请求和机器管理的主要工具,它也是一个Pyramid的REST服务,从ServerDb获取机器存货信息、从内部微服务数据库拿到角色信息,然后通过Neep来完成机器的管理任务。

Sid的UI基于Lingon(http://github.com/spotify/lingo),目前Sid已经取代了JIRA成为资源请求的首选。

A Sid provision request being made




A fullfilled Sid provision request




Managing machines in Sid

影响

除了Neep和Sid,这期间还完成了很多其他改进工作。

  • 重写了DNS zone的生成过程

  • 在安装时适用自动生成的系统镜像,而不是安装之后使用Puppet,以缩短时间

这些改进措施累加起来,效果就是资源申请和回收的请求处理时间从几个小时降到了几分钟。这使得Sid成为Spotify资源管理类工具中最受欢迎的一个。

2015年后 - 奔向光明

在2015年Spotify决定拥抱共有云,并选择了Google Cloud Platform(GCE),但是对外直到2016年2月才宣布。

原因,成本肯定是主要原因。成本的降低可以从两方面体现:

  • 公有云可以提供更高效的资源分配方式

  • 相比物理机,可以不改变系统架构就能达到更高的资源使用率

迁移策略

基本原则是需要有一个工具,能够贯彻执行Spotify的资源使用模式,并能够方便的让工程师获得计算资源。在对GCE的Developer Console进行评估之后,觉得Developer Console很强大,但是太过灵活,很难引导工程师适用最优的配置。GCE的Deployment Manager虽然功能强大,但是工程师发现不好使用。
SPM(Spotify Pool Manager)诞生了,基于GCE API之上开发的一个适配层,提供很多默认值,工程师只需要简单的指定在哪里、需要什么样的role、多少实例,SPM就会确保这些实例是存在的,底层通过调用GCE的instance groups来管理,pool的大小可以随意调整。


SPM managing pools

SPM是一个无状态的Pyramid服务,底层调用Sid和GCE来实现具体的管理功能。
尽管很多服务已经迁移到了GCE,Spotify仍然有一些物理机存在,而且短时间内不会小时,所以给Sid增加了pool的功能,这样SPM就可以同时管理GCE的实例和物理机,对工程师提供了统一的使用习惯。


结束语

Spotify的机器管理方式的变化,可以说是典型的IT公司在发展过程中都会经历的,简单概括就是业务发展驱动的底层运维方式的变革,资源申请自动化,机器安装配置自动化,在拐点来临时从物理机到共有云的迁移。

不可否认,Spotify的机器管理在经历了几个时期的改造之后,已经相当不错了,基本遵循了服务化的思想,通过一个可信数据源控制机器的目标状态,虽然他们只有1.2万台服务器/虚拟机,但是根据本人的经历,Spotify公司的这套机器管理系统管理10w+机器是没什么问题的。

Spotify分享的在机器管理系统方面的经验,是有很多可取之处的,如果你的公司还没有经历这些变革,Spotify公司的经验之谈值得参考。



转载声明:云中慢步所有文章均为作者原创文章,转载请联系作者授权,转载需标注以下信息,删减无效。


转载请标注

来自微信公众号:云中慢步(Cloudify):在硅谷原创分享分布式系统、数据中心技术、云计算前沿技术剖析以及生产环境最佳实践



看更多原创内容,扫码关注:云中慢步


 
猜您喜欢 哪个蠢蛋写的烂代码? 耐撕攻城狮们的六一礼物应该是什么样的 Hadoop 3.0新特性预览 Redis中的LRU数据淘汰算法 SuperWebView进驻Android Studio中文社区