百微秒时延，腾讯云云硬盘CBS架构深度解密

1、CBS架构演进

1. CBS云硬盘

什么是云硬盘呢？腾讯云的云硬盘叫 CBS，CBS 就是 Cloud Block Storage，基于云的分布式块存储服务。
云的概念听起来很玄乎，其实我理解的云的核心技术就是分布式，云是分布式的一个商业包装，经过云这个接口把它推出去，给你们提供就像水、电同样的基础服务，这是我给云的定义。 云里边最核心的是分布式技术，云硬盘也是基于分布式去实现的一个硬盘，跟电脑里面的硬盘功能相同，可是又比我的电脑里的硬盘有更丰富的能力。
好比基于分布式实现，性能上就使得横向拓展的能力很是好。我的电脑硬盘只能提供几百兆的吞吐能力，CBS 基于云的硬盘能够提供更大的存储性能，咱们如今能够作到5GB，这是本地传统物理硬盘很难作到的。 在可靠性方面，CBS 是基于多副本的存储策略，也就是说原则上会将用户数据存多份，通常是三份，这样的策略让数据的可靠性更强。 另外是可用性方面。传统的物理硬盘坏了，上面的数据就丢了，也就影响到了用户的服务。可是云硬盘不同，它是基于分布式实现的，当这一块硬盘故障的时候能够快速进行隔离，由于是多副本存储数据的，另外的副本就能够及时的提供服务，不影响用户的可用性。 当前云硬盘服务主要的对象是你们在腾讯云上买的云主机，是给云主机提供持久化的块存储服务的。 以上这些就是我给 CBS 云硬盘下的定义，首先它是基于分布式技术实现的，就像我的电脑硬盘同样，硬盘能够提供的全部能力它均可以提供，而且在高性能、可靠性和可用性进行了加强，提供持久化的块存储服务。 

2. CBS架构演进

CBS 的演进通过了三代架构 —— CBS apllo、CBS atlas 和 HiSTOR。块存储最先是从 2011 年开始作的，当时不叫 CBS，而是叫 TBS。最先的一代架构是基于之前腾讯云架构平台部已有的存储平台打造了块存储的服务。但这个已有的存储平台一开始并非为块这个场景专门设计的，因此存在不少问题。 2013 年、2014 年是云发展比较快的阶段，当 2014 年规模到了几个 PB 的时候，发现当时的架构不能承载用户的需求，因此在 2014 年时用 CBS apllo 及时替代了更老的一代架构，适应了云快速发展的需求，快速的把块存储的规模从几 PB 增长到了上百 PB，我的认为这是很是优秀的一代架构。 可是到 2016 年，虽然之前的架构很优秀，可是成本方面会略高一些、性能上也不尽如意，因此在2016年但愿可以在成本和性能方面有所改进，性能这也是本期我要讲的主题。
在 2016 年咱们设计了新一代 CBS 架构 Atlas，2017 年 Atlas 正式上线接用户业务。 目前在腾讯云上跑的主流的架构是 CBS atlas，承载着数 EB 的数据规模。如今不少用户把数据放在云上，腾讯云上也已经衍生了几十亿、上百亿、甚至上千亿美金的独角兽公司出来，他们就是依赖于云去支撑他们的服务。 在如今这个阶段，就要全场景的看用户的需求，最主要的一块就是对性能的要求慢慢成为了矛盾的焦点。原先预计云盘很快便会取代本地盘，但在去年的时候发现取代的节奏在变缓，分析以后发现用户仍用本地盘是由于云盘某些场景没有服务好，典型的是关于 DB 的需求。 云盘是基于分布式的，中间经过网络互联，天生比本地盘的延时略高，可是到底高多少呢？若是高的程度可以在提供的优点能够覆盖住的状况下，用户就会愿意用 CBS 盘，但若是影响大于优点，那么用户就不接受了。
这时候这个矛盾就凸显出来了，要解决用户在性能上的需求，这时候“极速存储”就应运而生，它在性能上有了很大的提高。到今年上半年的时候平台侧就达到了咱们认为可以知足用户需求的能力，今年 8 月产品层面推出相关产品。
以上就是我参与的三代架构以及前面没有参与那代架构演进的历程。我列了三个时间点，其中2014年是很是重要的时间点，云快速发展推出 applo 架构，2017 年推出 atlas 架构，到去年为了解决用户全面上云对性能的要求，咱们投入精力搞了 HiSTOR 的架构。 

3. CBS存储系统

CBS 存储系统架构究竟是怎么样的呢？最新的架构能够分红三块： 

• 客户端

• 存储集群

• 控制集群

 先介绍一下存储集群，存储系统很重要的一块就是存储集群，这是后端的存储给用户提供存储服务；另外给用户提供服务确定要有个接入点，也就是前面的客户端；分布式系统要有对集群作控制的模块，也就是控制集群，固然控制模块自己也是多机的分布式系统；CBS存储系统能够分为这三块。 今天要讲的是块存储，其实如今 CBS 存储系统已经被打形成了统一的存储平台，如今腾讯云上购买的云文件也是这一套存储系统提供的服务，另外云原生的数据库，后端的存储系统也是它。 CBS 的存储系统 HiSTOR 的特色首先是极简的架构。多年前我也对外分享过一个“大道至简”的设计理念，用极简的架构知足用户的需求是最好的。
整个集群分为三部分，客户端直接访问存储，中间没有传统的存储系统的接入模块，因此是一种极简的架构。 另外一个特色是统一存储。咱们提供的不只是块存储服务，而是多种存储类型服务共享的一个平台。CBS 存储系统为何一直向前演进呢？由于要解决问题。
Atlas 取代 Applo 核心的目的是什么？首先是成本，由于架构层面足够的简单，只有两层，没有中间的接入集群、接入设备和其余的管理设备是没有的，因此在成本上是大大的下降了。 这套架构比以前的架构在成本上有优点，物理成本上节约了 50% 左右，但产品怎么可以让用户去买单呢？要让用户有买单的意愿就要作到成本足够低，成本问题是几年前解决用户上云的需求的主要矛盾。
慢慢的在用户上云了之后，包括核心的业务开始往云上切，腾讯云上已经孕育出了不少十亿、上百亿、上千亿美金的独角兽公司，这个时候如何让用户放心把业务放到云上呢？必定要让其用得放心，质量必定要过关，解决成本问题后咱们投入大量的精力在质量上。 质量要过关，可靠性、可用性和数据安全方面必定要过关。 

2、CBS新的挑战

如今不少公司已经把它的所有业务都放到云上，这时候就须要把他服务好，让他用得爽。云盘相对本地盘主要的劣势就是延时相对本地盘比较高，因此今天要讲的主题是怎么在这一点上有所突破。               性能方面有三个维度，除了一再强调的延时维度，还有吞吐维度和 IOPS 的维度。  

1. 吞吐维度

 吞吐维度指的是带宽。如今不少大数据场景、AI 训练的场景对带宽的需求很是大，SSD 云盘提供的 260 兆的带宽，跟用户需求是有落差的，因此除了在延时上须要作到极致之外，带宽方面也要知足用户的需求。 

2. IOPS

之前都是本地盘间的比较，你们以为 IOPS 不是个矛盾点，本地物理硬盘随机访问的IOPS 也就是在 200、300 的级别。而云盘产生以后，最老的一代产品可以提供的是几千的IOPS。
当时是能够知足需求，但慢慢的上云的场景愈来愈多后，云主机的母机上单个服务对 IOPS 的需求不高，可是加在一块儿需求就变得很大。 

3. 延时维度

延时维度最典型的是 DB 的业务。可能多年前放在云硬盘上的数据价值并不高，可是 DB 数据价值密度很是高，如何把 DB 应用场景服务好也是须要花很大的精力思考的问题。  

3、CBS低延时结构优化

1. CBS延时优化

那么 CBS 延时如何优化呢？不少人提出过不少具体手段，可是总结起来就是两个方面，一是怎么把并发作上去，二是怎么把延时作下来。 把并发作上去，这是分布式存储自然有的优点，只是技术实现上的难度大小而已，但跟延时比起来并非这么困难。
低延时无非是两种手段，首先用更快的硬件去解决，另外是怎么把软件 IO 栈作到尽可能的扁平化，本期的主要是基于软件的维度考虑延时优化，具体是从 CBS 的四个维度入手：分布式层面优化、接入端、存储侧和中间交互的网络的优化方面。 

2. 分布式架构

CBS 存储系统是极简的架构，客户端访问存储中间就是网络，涉及优化的也就是三个层面加一个架构，咱们按这几点来进行分解。 首先从架构层面，CBS altas 直接从客户端访问存储，是两层分布式架构，没有传统的接入点也就没有了接入瓶颈。另外是客户端直接访问存储中间访问路径能够作到最短，这就是当前架构的优点。 提及来很简单，但作成两层架构实现起来技术难度很大。首先是路由管理上如何作？CBS 的存储系统用的路由方式是一致性哈希，这就涉及到哈希路由如何推送到客户端。
自己路由的变动是由控制集群维护的，路由更新后若是直接推送客户端的话看起来很简单，但面对云上的集群规模就会发现问题。腾讯目前是上百万台的规模，若是把一个信息推送到上百万个节点根本是不可行的事情。
因此在实现上咱们想个了方式叫“惰性路由同步”，集群管理节点变动后不是直接推送客户端而是推送到存储节点，再由节点中转到客户端。 为何这样可行呢？接入节点上百万台，可是存储节点比客户端节点是数量少得多，推送到存储节点对中心控制节点的负载是能够容忍的，因此先推送到存储节点，以后对中控系统来讲工做就完成了，推送也就完成了。 惰性路由同步的惰性体如今哪里？起名字的时候咱们借鉴了内核内存分配的方式，内核去申请内存的时候只是一个虚拟的，并无把真实物理内存分配给你。 分布式架构里路由同步的策略也是相似的，先推送以后并不急于推送到客户端节点，若是有需求访问存储的时候，再同步把路由推送到客户端节点。这时候拿到最新的路由就能够访问到须要的数据了，使用的时候再去推送的策略即是“惰性路由同步”。 架构层面，原先的架构虽说是两层，但由于是多副本存储，数据到了存储节点后还有一次复制的过程，须要再复制成多份数据存到节点上去，这时候虽然架构上是极简的，但写的时候有两次的路由，就至关于数据走了两跳。 为了作到延时上的极简，咱们是根据 IO 大小作了不一样的策略，若是是小 IO 的话，走的是之前的模式，直接客户端出三份，这样对小 IO 便只须要一跳。
但为何大 IO 不这么作呢？客户端出流量的话，出三份实际上是占用计算的网络流量的，因此这样是须要跟前端计算的同事协商的。但小的 IO 这么作，不须要增长前端的计算带宽，这就是为何大小 IO 须要作不一样策略的缘由。  

3. CBS接入端

上图所示的客户端架构是一个主流的架构，接入方式是基于 iSCSI 的通用块设备接入，虚拟机经过访问存储的时候是 QEMU 访问一个主机上的块设备，往下走 SCSI 设备。
SCSI 的底层就是 iSCSI initiator，经过网络访问 CBS 的客户端，而后再访问后端存储。路径很是的长，首先要复制数据、切换访问内核，以后经过 iSCSI ，再经过网络访问 CBS 的客户端，客户端再经过网络把数据发出来，中间通过了多少次的上下文切换和数据拷贝，因此延时上很是不友好。 有没有其余的接入方式呢？第一次想这个问题的时候是在 2016 年，咱们在设计架构时，当时想直接用共享内存的方式把数据旁路出来，就不用通过这么屡次的来来回回的切换了。
后来老板们说你为何这么作呢，英特尔搞了一个更好的东西，就是能够直接在虚拟机上把数据旁路出来，也就是 SPDK。IO 设备是虚拟机的话，SPDK 能够作 IO 的后端，直接把数据同步出来，再把客户端作到 SPDK 里面，这个数据路径是要短很是多。 虚拟机里面直接用数据共享的方式跟 SPDK 交互数据，SPDK 在后端访问存储，再通过网络处理，比起刚才说的来来回回好几回要简单得多了。 可是不是这样就作到极致了呢？最初作的方式是 SPDK 跟客户端的访问没有在一个线程里面，而是两个线程，之间经过共享内存。
但这样对延时并不友好，由于通过了线程的一次切换，哪怕只是几个微秒的区别，但在一个超高性能场景中几微秒也是比较多的。因此咱们又作了优化，把客户端跟 SPDK 放在同一个线程里作，这样就没有线程上下文的切换了。 总结下来，是用 SPDK 的接入方式取代了 iSCSI 的接入方式，用零拷贝的轮询方式取代了原来两线程数据共享的方式。最后是有一个水平扩展的能力，这跟延时无关。 刚才提到老板们站的高度更高，在 2016 年便提出了用 SPDK，那 SPDK 究竟是什么呢？
这是一个英特尔用来作高性能存储的开发套件，提供一些 lib 库之类的工具，经过它作高性能存储的应用开发。具体技术实现首先是在用户态实现的，能够减小对内核的切换，用户态、内核间的上下文切换对 CPU 消耗也比较高，另外就是轮询，说白了就是 CPU 的死转。SPDK 主要就是这些方面的技术。 

4. CBS存储引擎 

2016 年在作架构的时候，首先开发了一个高性能的开发框架叫 CEDA。这是基于封装的事件驱动的框架，核心理念是基于微服务模型，是事件驱动的、事件触发的高性能的开发框架，存储引擎是基于 CEDA 框架实现的。 胶片里面有个 DATA POOl，也就是数据池，IO 过来以后从数据池中分配数据存储的内存，整个生命周期数据不作拷贝，因此能够作到数据零拷贝。
核心路径上跟其余的 SPDK 理念同样，不是用事件驱动的方式，而是用轮训方式，虽然对 CPU 消耗高了，但没有线程的唤醒和休眠，能够作到相对比较好的水平。
存储引擎访问硬盘，如今用的也是 SPDK 方式，能够尽可能的减小访问硬盘时在用户端内核进行切换的时间消耗。 但这个过程仍然有一次切换，说白了仍是没有达到极致，用户态的任务调度可让一个 IO 的处理从进存储引擎到最后落地访问存储硬件整个在一个上下文里面作，没有切换的开销，这样就能够把延时作到极致。 

5. CBS (极速型云盘) 网络

架构、客户端、存储引擎、中间是网络，咱们之因此把网络放到最后，并非说它不重要。软件作到这样是至关不错的，但它的延时和网络比起来仍是小巫见大巫，一次跳转的话大几十个 us。 那么如何在网络上作优化呢？腾讯有两款产品，CBS 极速型云盘和加强型云盘，极速云盘是网络层面用的 RDMA，远程直接内存访问，说得简单一些就是一个硬件卸载的理念，把网络的协议的处理尽可能放在硬件里面作，这样能够旁路掉操做系统内核的工做。
在硬件和用户态的应用之间直接共享数据，也就是全栈都没有了内存的拷贝，也不须要内核和用户态作协议的解析处理，这些硬件就帮你作了。经过这种操做这样能够把延时降到极至，用的是旁路内核减小切换的理念。 那咱们作得跟别人作的有什么不一样呢？总结起来，咱们作的比较好的几点，虽然是  RDMA 网络，但咱们并不单纯是 RDMA，而是 RDMA 和 TCP 并存，在故障的时候能够快速自动切换。
另外一方面拥塞控制，腾讯云的量级是百万级别的服务器规模，放眼全球 RDMA 的使用超过一万台机器规模的都不多，RDMA 集群应用规模通常并不大，RDMA 的拥塞控制是比较大的隐患，或者说是如今存在的主要问题之一。
CBS 的 RDMA 拥塞控制层面如何作的呢？除了硬件提供的拥塞控制能力，应用层也作了控制，好比存储和客户端的交互用的 RDMA_read 方式。 RDMA 有几种交互方式，一种是 send/recv 方式，一种是 read/write 的交互方式，简单而言，前一种模式交互流程是短的、少的，可是切入应用以后会有一次数据的拷贝，由于要有交互协议处理的 buff 和应用之间的 buff 拷贝，对大 IO 来讲并不友好。 另外一种方式 RDMA_read，最主要的好处是没有了刚才说的拷贝过程，因此对大 IO 比较友好，可是交互流程比前面说的方式要多几跳，这样对小 IO 并不友好。 因此从交互协议层面来讲，用了这两种相结合的方式。当须要带宽的时候用的是 read 方式，当须要短的延时时候用的是 send/recv 方式。 用 read 方式作拥塞控制，存储侧来看，好比须要去写个数据到存储的时候，先跟存储握手一次，告诉他我要写了，这时候存储向客户端发一个 read 指令，控制权彻底在存储。
由于整个集群模型是很是多的客户端访问少许的存储，存储自己是容易发生拥塞的点，存储端主动的发起数据的读写请求的话，能够根据本身的负载去作拥塞控制，这是基于应用的拥塞控制的可行性，以上是 CBS 在 RDMA 网络方面作得相对比较有特点的几个方面。 

6. CBS（加强型云盘）网络

 

极速云盘用的是 RDMA 网络，加强型云盘用的是 TCP 网络，TCP 网络是延时消耗的大头，内核协议处理占了整个网络延时的百分之八九十，若是仍是用 TCP 网络的话就看如何解决掉内核占消耗比较高的问题就能够了。
内核 TCP 方式是内核消耗高，由于上下文切换很频繁，解决这个矛盾放到用户态来看，就是协议处理放到用户态，没有上下文切换。腾讯作的 ZTCP 用户态协议栈同时也能够零拷贝，用户协议也作了用户态零拷贝以求性能的极至，这是加强型云盘的网络协议的优化。 

7. CBS网络模型对比

CBS 网络模型的交互方式有三种： 

• 传统的内核 TCP 协议栈交互；

• 极速云盘用的 RDMA 网络交互；

• 加强型云盘用的用户态 TCP 协议栈交互。

 咱们对三者进行一个对比。内核态 TCP 把 TCP 解析放到内核，主要问题是频繁的上下文的切换、太多的数据拷贝，这是它的问题。
用户态协议栈是减小数据拷贝和上下文的切换，腾讯作 ZTCP 的特色是同时支持零拷贝，RDMA 是不须要软件作而是硬件来帮助作，协议栈卸载到硬件里面以求作到旁路掉内核、数据零拷贝，达到这个技术的要求，同而将延时降到最低，这是三种网络交互形式的对比。 

4、CBS延时优化成果

1. CBS延时能力

咱们的 CBS 延时优化到底作到了什么水平呢？上图是产品化的时候开发同窗测的数据，可以作到的是 140 us 左右，百微秒级别，这还不是最新的数据，如今能够作到100 us 到 120 us 之间。 当前给到产品化的能力就是 100 us 到 150 us，研发侧能够作 100 us 到 120 us 之间。接下来要作到什么程度呢？给产品的目标是但愿年末可以作到 50 us 到 100 us 这样的水平。 

2. 产品化

 产品化层面，8 月 13 日的时候产品侧推出了一个叫加强型 SSD 云硬盘的产品，这已是正式的产品化了，能够在腾讯云官网买到，如今极速型 SSD 云硬盘也已经开始公测了。              
以上就是我和你们分享的CBS在架构演进及基于当前最新的架构打造的百微秒级别的极速云盘产品的状况，谢谢观看。

5、Q&A

Q：支持几PB到上百PB的瓶颈是什么呢？ A： 从成本层面来看，就是在合理成本的状况提供让客户接受的产品。从质量层面看，就是怎么可以提供用户能够接受的可靠性和可用性的一个产品。我认为主要的瓶颈就是成本和质量，这个作大规模主要的两个瓶颈点。
Q：一致性哈希未来迁移时怎么避免数据迁移？   A： 数据迁移不能避免，但能够考虑如何减小。在实现上有一些尽可能减小数据迁移的方式，好比去作路由分裂的时候，最粗暴的方式是把一个哈希分区的数据迁到两个里面去，避免的方式我只迁移分裂的一个新分区的数据，另外一个分区还继承老的分区属性，这样剩余通常数据就不用迁移。
Q：高并发小 IO 高的话，client 会不会占计算节点的 CPU 和内存很高？ A： 在 RDMA 协议层面咱们是用了两种相结合的方式，对于小 IO 用的 send/recv 的方式，对大 IO 用的是 read/write 的方式。这么作的缘由，是在大 IO 的状况下尽可能减小对 CPU 的消耗，提高它的吞吐性能。对于小 IO 来讲只能针对一部分特征来减小 CPU 的消耗，不能避免 CPU 的消 耗。client 占用的资源已和客户购买云主机的 CPU/内存作了隔离，不会影响到客户的云主机使用。   Q：云硬盘将来会逐步替代物理硬盘吗？ A： 只要用户把它的业务逐步的放在云上，我认为云硬盘取代物理硬盘是一个大趋势。云硬盘相对于物理硬盘它的劣势主要就在于延时层面，其余层面云硬盘相对于物理硬盘都是有优点的。只要能解决延时的问题，云硬盘取代物理硬盘是必然趋势。   Q：不一样大小 IO 经过不一样方式复制，大 IO 经过 raft 之类的算法么？小 IO 直接复制到三个 store，是本身实现的复制算法么？ A： CBS 没有使用raft 算法，数据复制部分是使用自研的算法。   Q：新的架构在容灾层面怎么考虑的？ A： 分为两个层面，一个是元数据层面，一个是数据层面。元数据层面分为集群元数据和存储原数据。集群元数据也是三副本，咱们会把原数据的变动，操做的流水，包括元数据自己记录下来，因此原则上你的集群元数据是能够恢复到任何一个时间点的。   存储的元数据怎么去解决？存储的元数据跟集群原数据同样，咱们会把全部变动记录到硬盘上，包括变动流程也会记录下来。另一层面，会像集群元数据同样会把它弄到异构系统里面。
还有一个层面，可能有些元数据只是记载了硬盘的一个位置，准确的说它是记在两副本，可是记在一块儿的，物理位置是连续的。   在最新的架构里面，两个元数据的备份是放在硬盘的不一样的位置，但无论你放几份，放到哪里，若是有人恶意破坏，那你仍是会把数据搞丢。   怎么去避免这种状况？咱们如今最新的架构里面作了一个离散元数据，就把全部的元数据的数据记在一块儿，去落地到硬盘上，每个数据它都带了自身的元数据，即便你把元数据集中区给抹掉了，我同样能够从经过存在的数据把元数据恢复出来。从而保证元数据的安全。由于元数据是描述数据的数据，是最重要的数据。若是它丢了即便数据存在那也等同于丢失，因此元数据就显得异常重要，这几个能力都是在元数据层面的安全加固。   容灾还涉及到数据的容灾，这方面咱们是有快照能力的，将来几天的直播中也会有其余小伙伴介绍这点，在这我就不深刻讲解了。   Q：云盘的带宽是否会占用母机带宽，拥塞时如何抉择？ A： 如今数据多副本复制，我是有两种策略，一种是先把那个数据路由到一个主节点处，主节点再把它复制成多份，这是一种策略。还有一种策略就是直接从客户端分三份出来去作存储，后面这种方式会占用计算带宽，因此我会根据 IO 的大小作不一样的策略。无论怎样，CBS使用带宽是不占用客户购买云主机的带宽，也不会影响到客户的云主机使用。
Q：云硬盘和对象存储的差异是什么？若是是把硬盘云化，请问是支持多少种文件系统格式？   A： 云硬盘相对比较「热」，也就是延时比较敏感。 云硬盘和本地的物理硬盘实际上是同样的，你就跟普通物理硬盘同样用它就好了，能够根据须要格式化为本身须要的文件系统   Q：不少时候，网络 rtt 有十几 ms，云硬盘延迟会很高？ A： 腾讯云的网络没有这么差，应该是在百微秒级别。   Q：老师，请问大IO/小IO的分界点是多少？ A：这个大小断定方式是不同，客户端是 4K，存储集群内部 IO 是 32K。   Q：存量的云主机支持极速型云盘吗？ A： 极速型云盘目前公测中，若是有须要，能够官网页面提交申请，会有专人联系，感谢！   Q：云硬盘能实现一盘多机挂载吗？多机同时操做，怎么保障一致性？ A： 支持。云硬盘是块存储，块存储级别不能保障读写冲突的一致性问题。须要文件系统或应用层面保证，因此适用于oracle rac这些已经实现分布式锁的场景。