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

作者介绍: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 删除。

编辑于

我来说两句

1 条评论
登录 后参与评论

相关文章

来自专栏企鹅号快讯

分布式事务的总结与思考

思来想去,个人觉得要理解「分布式事务」,必须先知道什么是“事务(Transaction)”。 当然,这里提到的“事务”是在事务型数据库(Transactiona...

1819
来自专栏云计算D1net

云服务存在局限性,你如何找到最合适的解决方案

云计算不仅仅代表着近乎无限的资源,我们也需要了解其中可能存在的种种性能问题。 以Amazon AWS与微软Azure为代表的公有云服务属于基于控制台的编排方案,...

2973
来自专栏云计算D1net

横向扩展的NAS:混合云存储的关键

目前,世界上大多数的数据中心仍然使用垂直缩放的存储解决方案,这是一个困扰人们的问题。这种传统的存储方法在设计时并没有考虑到现在达到泽字节的庞大数据。企业以往任何...

3488
来自专栏CSDN技术头条

OpenStack高可用核心架构分析

【编者按】本文从OpenStack架构入手,剖析了IaaS的云平台最核心的主要是这三部分:计算、网络、存储,作者指出OpenStack这样一个复杂系统,高可用更...

2206
来自专栏美团技术团队

大众点评订单系统分库分表实践

背景 原大众点评的订单单表早就已经突破两百G,由于查询维度较多,即使加了两个从库,优化索引,仍然存在很多查询不理想的情况。去年大量抢购活动的开展,使数据库达到瓶...

4846
来自专栏IT大咖说

华为资深架构师:Cloud Native架构一致性问题及解决方案

1413
来自专栏进击的程序猿

raft 解读系列(1) 之 原理一致性的来龙去脉Leader ElectionLog Replication参考

首先我们知道在单机系统中不存在数据的一致性问题,在分布式系统中,由于采用多机器进行分布式部署,必然带来数据的复制,那为什么引入数据的复制呢?主要试图解决的两个问...

753
来自专栏沃趣科技

容器化RDS|计算存储分离 or 本地存储

随着交流机会的增多(集中在金融行业, 规模都在各自领域数一数二), 发现大家对 Docker + Kubernetes 的接受程度超乎想象, 并极有兴趣将这套架...

4288
来自专栏苏强的专栏

腾讯云分布式数据库(DCDB)

DCDB 是部署在腾讯云公有云上的一种兼容MySQL协议和语法,支持自动水平拆分的share nothing架构的分布式数据库。分布式数据库即业务获取是完整的逻...

4870
来自专栏SDNLAB

混合虚拟化网络,网络性能优化之辩

网络设备在虚拟化后是否依旧可以快速提供良好的性能?这是目前大家最为关注的问题之一。下面就讨论一下传统网络设备和虚拟化后面临的问题以及怎样使用网络设备才能提供实时...

3957

扫码关注云+社区