阿里数据库的极致弹性之路
副标题[/!--empirenews.page--]
数据库从IOE(IBM小机、Oracle商业DB、EMC存储)一路走来,大家都知道数据库是资源重依赖的软件,对服务器的三大件CPU、内存、磁盘几乎都有要求。数据库作为广泛使用的数据存储系统,其SQL请求背后涉及的物理读、逻辑读、排序过滤等消耗了IO和CPU资源,业务SQL不同,执行计划不同,资源消耗就不同,因而不同业务对资源规格的需求也不一样。正因如此,我们更需要抽象规格,更好地让不同资源诉求的数据库实例混跑在相同的物理机上,提升整体利用率。今天,阿里资深技术专家天羽为我们讲述阿里数据库的极致弹性之路。 除了日常业务需求,阿里的双11场景,让我们持续思考如何低成本高效率地支持峰值流量,把这些思考变成现实,变成技术竞争力。在大促资源弹性上有这么几个思路:
大促的成本=持有资源X持有周期,更通用的资源(云)、更快的部署(容器化)是缩短持有周期的关键,如何更少地使用资源(使用离线或只扩计算资源),就依赖存储计算分离架构的实施。沿着极致弹性的目标,数据库经历了混合云弹性、容器化弹性、计算存储分离弹性三个阶段,基础架构从高性能ECS混合云、容器化混合云、存储计算分离的公共云和离线混部一步步升级。 基本上架构演进就是每年验证一个单元,第二年全网铺开,每年挖个坑然后和团队一起努力爬出来,每次演进需要跨团队背靠背紧密合作,快速拿下目标,这也是阿里最神奇的力量。借助于底层软硬件技术发展,一步步的架构升级使得弹性混部越来越灵活和快速。 一、混合云弹性,高性能ECS应运而生 2015年之前,我们的大促弹性叫人肉弹性,也就是大促要搬机器,比如集团用云的机型支撑大促,大促结束后搬机器归还给云。但就在2015年底的一次会议上,李津问能否把数据库跑到ECS上,如果可以,就真正帮助了云产品成熟,当时张瑞和我讨论了一下,在会议上就答复了:我们决定试一下。这个合作非常契合会议主题“挑战不可能——集团技术云计算战区12月月会召集令”。 对于数据库跑在虚拟机上,我们判断最大的消耗在IO和网络的虚拟化上,因此如何做到接近本机性能,怎么穿透虚拟化就是一个问题。网络的用户态技术DPDK已经比较成熟,但如何做到足够高的效率,是否offload到硬件来做计算是个问题。文件系统IO的用户态链路有个Intel的SPDK方案,Intel推出后各大厂商还在验证中,还没有规模的应用。我们就在这个时候启动的这个项目,叫高性能ECS。通过和ECS团队紧密合作,最终我们做到了最差场景高性能ECS相比本地盘性能损耗低于10%。 2016年在集团通过了日常验证,2017年大促开始大规模用云资源直接弹性。这个项目除了打造高性能ECS产品,更重要的是沉淀了网络和文件IO的纯用户态链路技术,这是一个技术拐点的产生,为阿里后续存储计算分离相关产品的高性能突破打下了基础。 二、容器化弹性,提升资源效率 随着单机服务器的能力提升,阿里数据库在2011年就开始使用单机多实例的方案,通过Cgroup和文件系统目录、端口的部署隔离,支持单机多实例,把单机资源利用起来。但依然存在如下问题:
随着单机部署密度越来越高,社区Docker也开始发展起来,尽管还不成熟,Docker本身依赖Cgroup做资源隔离,解决不了Cgroup的IO争抢或OOM问题,但它通过资源隔离和namespace隔离的结合,尝试对资源规格以及部署做新的定义,因此我们看到了容器化更多的优势:
2015年数据库开始验证容器化技术,2016年在日常环境中大量使用。因此在集团统一调度的项目启动后,我们就定下了2016年电商一个交易单元全部容器化支撑大促的目标,承载交易大盘约30%,并顺利完成。2017年数据库就是全网容器化的目标,目前数据库全网容器化比例已经接近100%。 容器化除了提升部署弹性效率,更重要的是透明底层资源差异,在没有启动智能调度(通过自动迁移提升利用率)前,仅仅从容器化带来的机器复用和多版本混部,就提升了10个点的利用率,资源池的统一和标准部署模板也加快了资源交付效率。容器化完成了底层各种资源的抽象,标准化了规格,而镜像部署带来了部署上的便利,基于数据库PaaS和统一调度层的通力合作,数据库的弹性变得更加快速灵活,哪里有资源,,哪里就能跑起数据库。 三、计算资源极致弹性,存储计算分离架构升级 实现了容器化混合云,是不是每年大促使用高性能ECS,容器化部署就可以了呢?其实还是有不足的:
(编辑:晋中站长网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |