支持八千台子机并发创建,详解腾讯云主机创建优化之路

  • 时间:
  • 浏览:19

背景

云主机创建有并都有最好的法律法律依据,并都有通过镜像下载来创建,另并都有通过快照回滚来创建, 前者是通用的传统最好的法律法律依据,后者依赖于CBS云盘能力。 随着CBS云盘使用那末广泛,腾讯云主机创建也由那末的镜像下载切换到CBS云盘快照回滚模式。

通过传统镜像下载的最好的法律法律依据来创建云主机,在云主机拉起前,须要将整个镜像文件都下载到宿主机上,有些云主机的创建时间很大程度上依赖所选泽的镜像和当时下载镜像的传输速率。当遇到比较大的镜像时,云主机创建时间老是会达到几百秒,那末的用户体验都有太好; 另外,当批量创建时,须要消耗极少量的内网传输速率资源,须要在尽量占用网络传输速率的共同做好Qos,保证不影响用户的正常使用。

使用云盘快照回滚的最好的法律法律依据来创建云主机,不须要提前下载镜像,很久在云主机拉起时,优先将要访问的数据从快照系统搬迁到CBS云盘系统中。 大伙儿观察到,云主机拉起过程中访问的数据量和镜像大小并都有严格的线性关系,即便是较大的镜像,在云主机拉起时也只会访问到很少一每项数据,搬迁流程如下:

图1. 云盘快照数据搬迁流程

当有快照回滚请求时,大伙儿首先会在后台启动有八个任务,将快照数据按顺序从COS读出写入到存储池中,共同大伙儿不要阻碍用户对回滚磁盘的正常读写。 当有用户请求过来时(步骤1),会先在driver中检查对应lba的快照数据与否后后被写入,后后写入则IO直接挂接(步骤7),后后,会阻塞IO并先给scheduler发送trigger请求(步骤3),scheduler会优先将trigger请求外理,交给搬迁模块将对应的快照数据从COS读出,写入到存储池(步骤3、4、5),等写入完毕后,scheduler先记录搬迁bitmap到zk并给driver返回trigger response和当前的快照数据回滚进度(步骤6),driver收到后则不再阻塞io, 让其正常挂接(步骤7)。

聚焦延迟和并发,云主机创建优化之路

云盘快照回滚优先搬迁关键数据你这一机制为大伙儿批量创建云主机奠定了基础,在此基础上,大伙儿还围绕着延迟和并发这两点做了一系列优化

transfer增加cache

子机批量创建时,老是是使用同有八个镜像克隆qq好友好友出几百或上千台子机,后后所有数据都从COS系统拉取,对COS的读压力会非常大,会触发COS的Qos流控。为了让批量创建时读取镜像的流量不再受限于COS的传输速率, 大伙儿在transfer中增加了cache,每个transfer中都缓存镜像的每项数据块,一旦命中transfer的cache就不再从COS拉取数据,那末每个transfer只需拉取一次镜像; 当cache流量达到瓶颈时,时会通过临时增加节点来增加传输速率,具备水平扩展能力。

在增加了cache后,大伙儿对transfer部署也做了优化,每个zone都部署了若干个节点,当有数据块搬迁请求时,任务老是会优先落到和CBS盘底层存储节点相同zone的transfer上,那末就时会实现就近搬迁。

通过cache优化,时会将单个数据块的搬迁耗时从100+ms降低到10+ms, 大大降低了IO延迟。

图2. transfer cache

scheduler性能优化

在快照回滚创建云主机过程中,核心外理逻辑在scheduler,后后client端每个IO trigger请求都有经过scheduler, 后后后后每个由trigger触发的快照数据块搬迁都有在zk里记录起来, 有些scheduler的负载以及zk写入能力会直接影响到整个快照系统的吞吐。

首先,大伙儿优化了scheduler,将请求接收、外理以及与后端交互每项的逻辑拆开来,形成流水线,尽量减少因某个请求外理慢是因为有些请求排队的情形, 每个每项都由有八个tcp连接池来并行外理,尽量将整机的计算能力利用起来;

其次,针对zk写入压力大的疑问,大伙儿将写入zk的数据做了分类,变化不频繁的有些元数据还是写入zk; 而记录trigger搬迁情形的哪些地方地方元数据,须要频繁修改,这每项数据不适合存zk,大伙儿将其offload到有八个qps更高的存储系统上,那末一来,scheduler的外理能力得到了成倍的增长。

另外,为外理回滚的流量影响到有些用户对磁盘的正常使用,大伙儿在scheduler做了必要的Qos。 首先限制落到同有八个副本组的回滚传输速率, 在整个副本组传输速率空闲时,回滚流量那末超过限制; 而当整个副本组的传输速率达到上限时,回滚传输速率会自动回退,优先保证用户的正常IO延迟。其次,当共同有顺序搬迁任务和trigger请求任务时,优先外理trigger请求任务,保证用户体验。

最后,大伙儿通过对scheduler改造,做到水平可扩展, 使其不再成为性能瓶颈。

图3. scheduler 拆分

买盘调度

当用快照回滚的最好的法律法律依据批量创建云主机时, 会将快照数据写入新创建的所有CBS云盘。 后后极少量的云盘落在同有八个副本组,则会造成你这一副本组写入流量过大,触发前一节提到的副本组回滚传输速率限制。为外理你这一疑问,大伙儿加入有八个调度系统,在批量购买云盘时,从副本组剩余容量、已创建的volume数、回滚传输速率、副本组写入传输速率八个纬度综合考量,把同一批次创建的CBS云盘尽量打散到多个副本组。那末一来,首先时会保证在创建时,单个副本组不要成为流量热点;其次时会在一定程度上保证所有的副本组在创建时流量均衡,将整个存储池的传输速率充分利用起来;最后,同一批次购买的CBS云盘打散,时会将用户后后某个副本组出故障受到的影响降到最低。

减少子机拉起时的数据量

前面主要从降低延迟和增大回滚传输速率传输速率去考虑咋样优化,目的是让后端系统不能承载更大的回滚传输速率,提升快照数据搬迁传输速率。后后在快照数据搬迁过程中,CBS云盘有IO访问到还未搬迁的数据块,就会产生有八个trigger请求,后台系统须要优先搬迁trigger请求对应位置的快照数据,这对scheduler会造成额外的负担,有些咋样减少子机拉起时产生的IO trigger,减少对后端系统的压力,对云主机并发创建很有意义。

对子机拉起过程进行分析,大伙儿发现,在子机拉起过程中,文件系统扩容和配置文件修改都会在后端产生不少io trigger。 文件系统扩容一般发生在快照里的文件系统size小于要回滚的CBS云盘size,在你这一场景下,须要先将原文件系统的元数据全版读到内存中,修改后再写入。像ext系列文件系统的元数据是散落在每个块组中的,有些读元数据会变成随机读操作,几乎每个随机读都会产生有八个trigger,触发后端快照数据块搬迁,而文件系统的block大小远小于快照粒度,这里大约发生了读写放大; 为此,大伙儿通过修改文件系统配置,让所有元数据集中,那末读元数据就变成了顺序读写,那末就时会将请求合并,从而减少后端压力。 经过优化后,文件系统扩容时,后端IO压力时会降低到那末的五分之一,耗时降低到那末的四分之一。

其次,对于配置文件修改,后后直接在原文件上修改,既要读写文件元数据,又要读写文件数据,开销比较大;有些改成删除+写新文件的最好的法律法律依据,那末不须要读文件数据,时会是效减少IO。

总结:

通过上述哪几只层面的技术优化,目前,腾讯云后后时会做到八千台子机并发创建,为客户提供更好的服务体验。后续,大伙儿的优化都会老是进行下去,欢迎大伙儿给大伙儿提出宝贵意见。