云端块存储实现分析

典型的分布式存储集群有数千块盘。确定云盘写入位置的方式，称为数据分布管理。

存储引擎负责数据的持久化。采用追加写模型，还是原地覆盖写模型，是一个非常核心的架构设计。一致性协议、IO链路、故障处理，都会完全不同。

• NBD
• Virtio
• NVMe
• iSCSI
• Cinder

• 少量节点故障，IO性能平稳，写入目标位置必须是可以动态映射的；
  • 基于元数据进行数据分布管理；
  • 基于HASH确定数据位置的方式，在拓扑变化时，会有较多数据迁移；
• 节点数量较多时，追加写的实现，在数据一致性实现，数据复制与前端IO分离上，更具备优势；
  • LSM引擎；
  • 原地写提升IO稳定性的一种选择是故障时进入M-N写，降低SLA；
  • 追加写更好实现EC、压缩等特性；
  • 缺点是，追加写后台垃圾回收，会导致IO访问问题；
• 极致性能的产品是一跳的；
  • 阿里云PL-X，AWS E8，腾讯极速云盘；

• https://patents.google.com/patent/US20180183868A1/en?oq=US-20180183868-A1
• https://patentimages.storage.googleapis.com/e6/38/1e/1bf45099e3a6f9/US20180183868A1.pdf
• https://github.com/yygcode/papers/blob/master/patent/aws-ebs-US20180183868A1.pdf

Data storage system with redundant internal networks

Abstract

A data storage system includes a rack, multiple head nodes, multiple data storage sleds, and at least two networking devices. The at least two network devices are configured to implement at least two redundant networks within the data storage system. Also, each of the head nodes is assigned at least two network addresses for communication with the data storage sleds of the data storage system via the at least two networking devices. The data storage sleds each include multiple mass storage devices and a sled controller that is configured to couple with the at least two network switches. In some embodiments, the data storage system further includes redundant power systems within a rack in which the head nodes, the data storage sleds, and the at least two networking devices are mounted.

• https://patents.google.com/patent/US20180181330A1/en?oq=US-20180181330-A1
• https://patentimages.storage.googleapis.com/a6/31/75/b89bceb1d4177b/US20180181330A1.pdf
• https://github.com/yygcode/papers/blob/master/patent/aws-ebs-US20180181330A1.pdf

Data storage system with enforced fencing

Abstract

A data storage system includes multiple head nodes and data storage sleds. The data storage sleds include multiple mass storage devices and a sled controller. Respective ones of the head nodes are configured to obtain credentials for accessing particular portions of the mass storage devices of the data storage sleds. A sled controller of a data storage sled determines whether a head node attempting to perform a write on a mass storage device of a data storage sled that includes the sled controller is presenting with the write request a valid credential for accessing the mass storage devices of the data storage sled. If the credentials are valid, the sled controller causes the write to be performed and if the credentials are invalid, the sled controller returns a message to the head node indicating that it has been fenced off from the mass storage device.

2019年7月AWS收购了E8，参见新闻：

• https://www.cnbc.com/2019/07/31/aws-acquires-storage-start-up-e8.html
• https://www.datacenterplanet.com/zh-CN/%E7%A1%AC%E4%BB%B6/aws%E6%94%B6%E8%B4%AD%E4%BB%A5%E8%89%B2%E5%88%97%E5%AD%98%E5%82%A8%E5%90%AF%E5%8A%A8e8/

E8 Client相当于AFA Controller，可实现RAID多写。Client有足够的映射信息，知道IO 应该写到后端某个服务器/盘，不需要后端进行路由。使用电池保护凑满条带写，防止 Write Hole问题。

E8与AWS Nitro集成，可以把E8 Client运行到Nitro Card上。

参考这里：https://wikibon.com/amazon-acquires-blazing-fast-e8-storage-technology/

IO2 Block Express 预期是 E8 实现。E8 延时 40 us，IO2 E2E写岩石在100us以上，有 60us应该耗费在Virtualization，Nitro，Network上了。

AWS EBS持久性比较差，只有5个9。下面是一段介绍描述：

From https://aws.amazon.com/cn/ebs/features/

Amazon EBS 的可用性与持久性 Amazon EBS 卷具有很高的可用性、可靠性和持久性。Amazon EBS 卷的数据可在可用区内多个服务器间进行复制，以防备在任一组件发生故障时丢失数据，无需额外付费。有关更多信息，请参阅 Amazon EC2 和 EBS 服务等级协议。

Amazon EBS 可提供持久性更高的卷 (io2)，以实现 99.999％ 的持久性和 0.001％ 的年度故障率 (AFR)，其中故障是指完全或部分丢失卷。例如，如果您让 100000 个 EBS io2 卷运行 1 年，则预计其中只有 1 个 io2 卷会出现故障。这使得 io2 成为业务关键型应用程序（例如 SAP HANA、Oracle、Microsoft SQL Server 和 IBM DB2）的理想之选，将延长这些应用程序的正常运行时间。相比于普通硬盘 2％ 左右的 AFR，io2 卷的可靠性提升了 2000 倍。其他所有 Amazon EBS 卷均可提供 99.8％-99.9％ 的耐久性，且 AFR 在 0.1％-0.2％ 之间。

EBS 还支持快照功能，这是对数据进行时间点备份的好方法。要了解更多有关 Amazon EBS 快照以及如何拍摄卷的时间点备份的信息，请访问此处。

问题在于，假设AWS总共售卖了500万片io2，则一年内可能出现50片坏盘。这个数据还是不小的。估计AWS通过快照恢复（容忍少量丢失）解决了这个问题。

Azure承诺了0%的失效率，阿里云则是11个9，AWS差的有点远。

• CBS1.0
  • 通过iSCSI接入；
  • 持久化用已有组件TFS, TSSD, CKV；
  • Proxy应该实现iSCSI Target，并转发对应IO到后端持久化组件；
  • 预期Master管理云盘创建/删除/加载等；
• CBS2.0
  • 实现了一个统一的持久化层Chunk(Cell)；Chunk预期是Y型写入；
  • Proxy依然是iSCSI Target；
  • Master控制和协调整个集群，预期依然是创建/删除/加载等；
  • Master如何实现高可用，没有看到材料；
• CBS3.0(HCBS)
  • 去掉Proxy，直接从Client写入到Chunk，公开资料中称为CellPair或DiskPair;
  • Master记录元数据到ZK，这样可基于AS架构实现高可用；
    • 呈现给用户的逻辑卷信息；
    • IO路由信息；
    • 集群监控：流量，流控，报警，topo管理，故障恢复；
  • Driver运行在云主机母机上，向用户呈现块设备，向后端转发IO；
    • Driver分为Client和Agent两部分；
    • Agent负责逻辑卷和路由信息管理，与Master交互；
    • Client处理IO，与后端CellPair交互；
    • Agent与Client通过共享内存交互；
  • IO路由
    • 采用一致性Hash实现；
    • \(TabletPairIndex=Hash(DiskId, Lba) % N\)
    • 一块盘分为M个Tablet（预期数GB，千量级）；
    • 一个CellPair内的所有Tablet，组成一系列TabletPair；
    • 通过DiskId和Lba，唯一确定TablePairIndex；
    • IO下发给TablePair的Primary，由Primary发给两个Slave；
  • 故障检测与恢复
    • Cell向Master发送心跳，心跳异常则判定故障，TabletPair Slave提升为Primary；
    • Cell出现扇区故障，向Master发送自身错误；
    • Driver可能向Master上报IO异常；
    • 故障时，会提升Slave为Master；
    • 故障时，以TabletPair为单位，进行Recovery或Move，无法更换Tablet，而是整个从 srcTabletPair搬到destTabletPair；
  • 进行Driver Version 与 TB Version 比较；
    • 只有Global/TabletPair Version，没有IO Version，异常场景IO一致性问题比较难处理；
    • BinLog + 覆盖写，故障场景下，多副本一致性比较难处理；
• CBS3.0 缺点分析
  • 覆盖写实现，分布式场景下数据一致性corner case很多，做正确比较难；
  • 缺少IO Version，发生多个节点重启，Failover时，预期存在IO无法定序，以及数据不稳定问题；
  • EC/架构是保证可靠性，减小放大比的有效手段，这个架构下不太好实现；
  • 总是先写BinLog后写数据，IO放大六倍（三副本写2次）；

参考 https://m.e-works.net.cn/articles/article136779.htm

如何实现云硬盘（弹性块存储）系统？

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。

参考 https://cloud.tencent.com/developer/article/1005657

三个对等的Cell进程组成一组cp（cellpair也称diskpair，Cell进程对应管理一块物理盘disk）结对，以cpid标识每个cp；同时给每个Cell进程分配相同数量M的小表 tb（tablet），以tbid标识每个tb；cp上对等的三个小表组成小表对tp（tabletpair），以tpid标识且全局唯一，tp上的三个tb同样也有主副本之分。如图所示相同色块tb表示属于同一个tp对。

HCBS对于腾讯云分布式存储具有里程碑式意义，其无论是在性能还是成本在云市场都具有很大优势，以HCBS为基础衍生出了许多云产品如NCBS、FCBS、NAS等，HCBS同样支持快照功能。其的优势在于两层架构不仅降低了成本与网络通信，运营也同样变得灵活；同时惰性路由同步策略使得管理数据不需要强一致特性（分布式系统的一大难点在于如何保证各节点数据一致）。扇形多副本写（相比于Driver直接写三副本）不仅降低了Driver端压力，同时也起到了IO封装效果（外部IO转换为存储池内部IO），减少IO 失败概率。但同样也存在不足，从之前描述可以知道HCBS存在结对概念，即副本之间并没有做到完全离散，这使得一个副本故障必须同时换掉其他两个正常副本，代价稍高，这是后续优化的重点。

如同总体介绍中描述的，都已经具备元数据了，稍微增加一点元数据就能在维持现有2副本的前提下，复制一份数据，重回三副本，。HCBS选择了另外挑选一个CellPair复制三份数据，这个实现有点摸不着逻辑。

• https://new.qq.com/omn/20210701/20210701A03F0000.html
• https://www.intel.cn/content/dam/www/central-libraries/us/en/documents/tencent-cloud-cloud-disk-cbs-cloud-storage.pdf

40us Latency, 200W IOPS，让大家眼前一亮。随后阿里云发布对标产品PL-X： https://www.aliyun.com/daily-act/ecs/ebs-plx

SmartX在专有云/超融合领域市场反馈比较好。在看到的资料里，SmartX在分析KernelSpace， LSM的缺点后，提出了自己Journal+PerformanceTier/CapacityTier的框图。SmartX明确表示自己不是AppendOnly架构。推测这里应该是Journal SSD + HDD分层实现。SSD作为 Journal使用，数据Dump到HDD后即可回收。HDD是原地写。这种架构下，用SSD再实现一个加速缓存是常见策略。

• https://zhuanlan.zhihu.com/p/44250377

元数据服务使用LevelDB/RocksDB持久化元数据。使用ZooKeeper同步修改日志。

元数据服务包含了ChunkManager, NFS Manager, iSCSI Manager, Extent Manager。没有看到资料表示Chunk和Extent的相互关系。

• https://zhuanlan.zhihu.com/p/36138609