腾讯云弹性块存储技术解密

作者介绍:Yh, 2010年加入腾讯,有12年的存储经验,在弹性块存储技术方面经验丰富,本文将其在TEG TALK上的分享内容进行整理,干货满满,内容包含腾讯云云硬盘产品(CBS)的后台系统的演进历程、核心技术以及大道至简的方法论。

什么是云硬盘?

云硬盘,Cloud Block Service,简单来讲就是云上的硬盘。

云硬盘提供硬盘所有的能力:就像大家个人电脑中的硬盘,可以创建文件系统,可以存电影,可以读写文件;甚至更多:因为云硬盘的数据存在云端,可以充分发挥云的能力,提供更丰富的功能,例如:快照,可以把云硬盘某一时刻的数据做快照,当数据发生异常是,用户可以任意的将数据回滚到这些快照时刻。

用户只需要在腾讯云上购买一台云主机,就可以方便的使用腾讯云硬盘。

如何实现云硬盘(弹性块存储)系统?

CBS云硬盘起初是依赖腾讯已有的3个分布式系统:TFS提供冷数据存储、TSSD提供热数据存储和CKV提供分布式锁,用这三个分布式系统做简化整合从而产生了CBS 存储后台。

其实最开始CBS是将这3个分布式存储系统拼凑在一起,并在前端封装一个iSCSI的块存储服务,这就是CBS1.0。

但是这个1.0的产品依赖3个庞大的分布式系统,IO链、运维支撑链太长,系统臃肿,可用性极差;所以又把这3个分布式系统在代码层面做了简化整合,从而产生了CBS2.0。

CBS2.0的架构是怎样的?

首先,CBS2.0前端是一个接入集群: Client,即客户端,让服务器呈现一块硬盘;Proxy,即块设备的后台接入层,前端的云硬盘通过它才能将数据放到云端;Client和Proxy专业名次叫iSCSI initiator和iSCSI target,就像大家比较熟悉的CS结构一样;Master,集群总控节点,控制和协调整个集群的工作。

同时后端是一个分布式存储集群: 就像经典的分布式存储系统架构,首先接入模块Access提供接入访问服务;存储模块Chunk负责数据存储;同样它也是一个分布式系统,同样也有一个总控节点,就是Master。

CBS2.0系统的运营状况怎样?

目前CBS2.0的系统在线上已经安全运行了很久;为数十万商业客户提供服务;几十万块云硬盘在线上安全运营;存储规模百PB级别。

大家可能对这个规模没有概念,打个比方,如果把存储的数据用书本记录下来的话,那将耗尽地球上的森林。这个规模还在快速增长。

腾讯云硬盘提供3种规格的产品:HDD介质的普通云硬盘、HDD+SSD混合介质的高效云硬盘和高性能的SSD云硬盘;产品可靠性达到8个9的级别,在业界处于领先地位。

CBS2.0的运营过程中的难题?

首先是成本问题:成本是永恒的主题,特别是互联网海量存储中,任何的成本优化都会带来巨大的经济收益,特别是规模快速增长阶段的腾讯云硬盘。

还有一个问题是高性能场景的使用性问题:在前边的架构图里可以看到,腾讯云硬盘的数据请求从用户到数据落地存储,经过了两个集群、四个层次,每一层的网络延时在几十个微秒级别,而这和作为高性能场景的存储介质SSD的操作时延在一个数量级,所以数据在访问路径上的耗时占比就太大了。

如何去解决这些问题?

契合文章的主体:大道至简,做减法,简化系统,去掉接入层。

具体来说:上图左边是CBS2.0,也就是当前系统上规模运营的系统。它由接入系统和存储系统两个分布式集群组成;而腾讯云硬盘是个存储系统,接入是为了支撑存储的存在而存在的。

所以最直接的想法,把接入层去掉,简化成两层架构,只保留Client客户端在主机上呈现硬盘设备,Chunk模块提供数据落地存储,Master总控节点负责整集群的管理。

上图就是两层架构实现的CBS3.0的软件逻辑架构,和物理架构的三个节点对应:

Driver,对应物理架构中的Client模块,在软件实现上称为Driver。

Chunk,提供3副本存储的存储引擎。

Master,总控节点,多机互备提供高可用性。

两层架构的CBS3.0的技术难题?

一、数据组织:数据按什么样的数据结构存在后台分布式系统中。

二、数据路由:怎么确定数据存放的位置。

三、路由同步:路由信息怎么在集群节点之间同步。

四、数据多副本:作为一个高可靠性的存储系统,CBS三副本数据存储在不同机架的服务器上。

五、故障恢复:海量存储中,硬件故障是一种常态,怎么在故障中快速恢复服务和数据。

六、数据迁移:设备异常时或者集群扩容时,怎么讲数据从一个服务器迁移到另一个服务器。

这些都是分布式存储系统设计中经常碰到的难题,而和两层分布式架构关系最紧密的是前三条,所以重点介绍:数据组织、数据路由和路由同步。

数据组织:

先看看数据组织中最基础的问题:数据怎么分片,或者说数据的分片粒度应该多大。

如果数据分片粒度太小会那么路由信息太大,导致路由同步时机群的负担太大,特别是在两层分布式架构中,路由需要同步给成千上万的Client节点,过大的路由信息对总控节点崩溃。

反过来如果数据分片太大,因为每个数据分片是分配给一个用户使用的,如果用户只写入4K数据,而分配一个1M的数据分片,那会造成存储系统空间的浪费,导致空间利用率低。

为了解决这个矛盾,CBS在数据组织上引入了虚拟分区Partition的概念。在物理上硬盘被分为多了固定大小的Block,物理上每个Block属于一个硬盘,而在逻辑上又将多个Block组织为一个Partition,Block和硬盘的关系是固定的,但是Block和Partition的关系只是为了完成特定的功能需求而存在的。

数据路由:

基于Partition的数据组织方式,数据怎么路由呢?即数据怎么定位到存储的位置呢?

当前端数据访问时,它携带diskid、blockid或者说lba、snap id(快照id号),CBS系统将这3个参数通过一致性哈希,计算出对应的Partition;而Partition和物理服务器、物理硬盘的对应关系是在集群初始化的时候配置的,这样前端的数据请求就路由到了需要存储的物理位置,这就是CBS基于虚拟分区Partition的数据路由方式。

路由同步:

在两层架构中,没有接入节点,实际上会导致所有的Client节点都会成为接入节点,因为每一个Client都需要有路由信息进行数据访问;而接入节点成千上万,需要总控节点和成千上万的Client去同步巨大的信息,实际上总控节点会被压垮。

为了解决这个问题,CBS参考了一种懒汉做事的方法:尽量少做事、晚做事、非做不可的时候再去做。

在CBS架构中:Master是个懒人,当Master总控节点发生路由变更的时候,本来需要将路由信息推送到所有的Driver模块,但是因为Master是个懒人,它只简单的把路由信息推送到Chunk模块;Chunk也是个懒人,Chunk收到路由推送之后,它也只是简单的将路由信息存到了本地;Driver发起数据访问的时候,Chunik检测IO中携带的路由版本和Chunk本身的路由版本是否一致;如果不一致,Chunk通知Driver需要路由更新,Chunk虽然懒,但很负责;Driver收到存储节点的通知,它尝试从存储节点Chunk更新路由;如果Chunk因为宕机或其他异常不能及时响应Driver的更新请求,Driver就向Master发起路由更新请求,Master具有最高的权威,它将正确的路由信息反馈给你Driver,最终完成路由同步;整个路由推送处处体现懒人风格,谁都尽量少做事、晚做事、非做不可的时候再去做,当然懒人没问题,但一定要是一个负责人的懒人。

王银虎团队给这种懒人风格的路由推送算法起了个名字:lazy路由同步或者叫惰性路由同步。

用虚拟分区Partition的方式进行数据组织和路由,用lazy路由同步的算法进行路由同步,从而解决了两层架构中最关键的数据组织、数据路由、路由同步问题。

两层架构的效果怎么样?

两层架构的CBS3.0已经上线,上线后普通云硬盘的成本降低46%;两层架构的CBS3.0提供了一个统一的平台,不仅支持通用的普通云硬盘,也支持高性能场景的高效云硬盘和SSD云硬盘。

业界对比

CBS在自身发展的同时,也在紧跟业界发展动态,例如目前开源里比较流行的ceph。

CBS和ceph都是两层架构的实现。但是CBS在性能方面要远高于ceph。

CBS支持精细化运维,CBS有完善的监控告警系统,但CBS只提供了一个简单的通用运维系统,如果使用ceph,需要在运维系统方面有巨大的投入。

CBS在可控性方面也要远高于ceph,例如数据安全可控性,CBS在任何场景下都不能丢数据,数据安全是一种信仰,但是ceph在某些特定的故障场景,数据安全是没有办法保证的。

当然ceph也有很多值得我们借鉴的东西:例如CBS是块存储平台(目前已经支持文件存储),而ceph一开始就是作为统一存储平台设计的,同时支持块存储、文件存储和对象存储;CBS的是镜像多副本存储,但是ceph在支持镜像多副本的同时,还支持纠删码,特别是一些成本特别敏感的应用场景是很有优势的。

总结

CBS的发展历程就是一个“简”的过程;在最新的两层架构设计中,体会到以简致胜的真谛,不做过度设计,提供用户真正需要的功能;所谓大道至简,简化系统架构,提供高性能、高可靠性、易用的服务,和用户创造共赢。

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏EAWorld

微服务转型,雪崩效应是绕不过的一道坎

记得在三年前公司因为业务发展需要,就曾经将单体应用迁移到分布式框架上来。当时就遇到了这样一个问题:系统仅有一个控制单元,它会调用多个运算单元,如果某个运算单元(...

37812
来自专栏CSDN技术头条

如何让Hadoop支持优先级且性能可预测

让运行Hadoop的公司产品都能够确保高优先级任务按时完成。 Apache Hadoop近十年的成长证明,用开源技术处理与访问海量数据并不是什么炒作。然而,H...

19510
来自专栏用户画像

2.3 进程同步

在多道程序共同执行的条件下,进程与进程是并发执行的,不同进程之间存在着不同的相互制约的关系。为了协调进程之间的相互制约的关系,引入了进程同步的概念。

862
来自专栏Spark学习技巧

重磅发布:Kafka迎来1.0.0版本,正式告别四位数版本号

Kafka 从首次发布之日起,已经走过了七个年头。从最开始的大规模消息系统,发展成为功能完善的分布式流式处理平台,用于发布和订阅、存储及实时地处理大规模流数据。...

1946
来自专栏编程一生

系统优化设计方案3.20周一例会

892
来自专栏ImportSource

NoSQL Sharding 分片

翻译内容: NoSQL Distilled 第四章 Distribution Models 作者简介: ? 本节摘要: 各位周末好,今天我们主...

35612
来自专栏aCloudDeveloper

DPDK 全面分析

高性能网络技术 随着云计算产业的异军突起,网络技术的不断创新,越来越多的网络设备基础架构逐步向基于通用处理器平台的架构方向融合,从传统的物理网络到虚拟网络,从扁...

7204
来自专栏IT技术精选文摘

微信后台基于时间序的海量数据冷热分级架构设计实践

1836
来自专栏腾讯云技术沙龙

白瑜庆:知乎基于Kubernetes的kafka平台的设计和实现

我是知乎技术中台工程师,负责知乎存储相关的组件。我的分享主要基于三个,第一,简单介绍一下Kafka在知乎的应用,第二,为什么做基于Kubernetes的Kafk...

84111
来自专栏IT大咖说

每秒处理1000万用户请求…云上架构如何实现高性能和高可用

1861

扫码关注云+社区