TGT 服务器的优化块设备协议 • NBD • Linux专有块设备协议 • iSCSI • 广泛支持的外部设备协议（块，磁带等）Curve云原生存储支持块设备 • 通过NBD，只支持Linux • 通过SDK API，目前只支持Linux • PFS • 扩大使用范围 • 通过iSCSI支持更多系统，例如Windows, 类UNIX系统等，使用两项基础 技术 • TCP/IP 替代SAN • 可靠性、稳定性方面有自己的的特色，使用raft副本一致性和copyset概念可以自动 修复损坏的副本，并且可扩容。无论在可靠性、稳定性还是性价比方面都很有优势， 使用廉价硬件搭建。iSCSI软件 • Client端: iscsi initiator，系统自带 • Linux open-iscsi • Windows iSCSI 发起者 • 服务器端 • 必须是Curve 必须是CurveBS原生支持的平台，因为需要curve原生接口，目前是LinuxiSCSI target服务器 • LINUX LILO • 一般用于输出内核本地块设备 • TCMU • 作为LILO支持用户态的接口 • 如何评价LILO • 输出内核块设备I/O效率高 • 不利于把复杂的存储协议代码搬进内核，例如(curve, brpc, c++, protobuf 等) • TCMU多了一层转接，配置过程复杂，业界踩的坑不够多。

https://github.com/opencurve/curve Curve 3/33为用户服务 作为一个复杂的大型分布式存储系统，Curve 需要利用科学的方法论和专业的工具，在整个 软件生命周期内更好地为用户服务：  质量——向用户交付稳定可靠的软件；  监控——直观地展示Curve运行状态；  运维——保障Curve始终稳定高效运行。 质量 ✓ 质量管理体系（设计、开发、review、CI） review才 能合入master分支，确保新合入代码 的功能、正确性、规范性等都有基本 保障；而每日运行的dailybuild测试在 CI测试基础上增加了异常自动化测试 和混沌测试，确保master分支代码的 bug尽可能早地暴露出来。 通过这种流程，curve可以在一定 程度上保证master分支的稳定性。 master 10/33版本管理 Curve版本命名规则是x.y.z{-后缀} 0-rc1 新功能 Bug修复 cherry-pick 11/33测试方法论 从测试粒度看，测试可以分为单元测试、集成测试、系统测试； 从测试角度看，测试可以分为常规测试、性能测试、异常测试、稳定性测试、混沌测试，等等  单元测试 1300+用例 行覆盖80%+，分支覆盖70%+  集成测试 Given When Then 设计方法 500+用例  异常测试 40+自动化用例

传统意义的块存储：磁盘分布式存储的要素 如何构建分布式文件系统？ 以分布式块存储为例。 •提供大容量的块设备 •可以在指定地址空间内随机读写 write(offset, len) •服务质量要求：数据不能丢、服务随时可用、弹性扩缩容 要什么 •成百上千台存储节点 •磁盘故障、机器故障、网络故障概率性发生 有什么 分布式存储系统需要满足接口需求，并且有持续监控、错误检测、容错与自动恢复的能力 数据分布 —— 无中心节点/中心节点 均 衡 地址空间的每段数据会分布在不同机器的磁盘上，如 何找到这些数据？ 可靠性 & 可用性 —— 多副本/EC 服务不可用时 间 数据一致性 —— 一致性协议 如何保证数据不丢？如何保证各种硬件故障的时候读 写都正常？ 可扩展性 —— 和数据分布的方式相关 所用容量都用完后，可以新增机器扩展容量分布式存储的要素 163342856 2 58 (4MB, 8MB) 759463473 9 3 (8MB, 16MB) 342165799 5 51 • 映射信息无需记录，直接通过计算获得 • 伪随机算法在服务器数量特别大的时候接近均衡 • 节点故障（DiskNums）变更会涉及其他数据的迁移 有中心节点：持久化对应关系 • 需要将数据分布（元数据）持久化 • 中心节点感知集群的信息，进行资源实时调度

基于Openstack构建云计算平台 • 底层存储使用Ceph块存储 • 稳定性挑战 • 算力平台kubernetes的迅速发展 • AI/大数据业务的快速增长 • 存储使用Ceph文件存储/HDFS • 成本/性能挑战 Curve块存储和文件存储均采用raft协议整体架构 • 对接OpenStack平台为云主机提供高性能块 存储服务 • 对接Kubernetes为其提供RWO、RWX等类 型的持久化存储卷 速度取决于写的较快的大多数RAFT协议简介 • Leader：负责从客户端接受日志，把日志复制到其 他服务器，当保证安全性的时候告诉其他服务器应用 日志条目到他们的状态机中。 • Candidate: 发起选举。获取大多数选票的候选人将 成为领导者。 • Follower: 响应来自其他服务器的请求，如果接受不 到消息，就变成候选人并发起一次选举。 • 时间被划分成一个个的任期，每个任期开始都是一次 leader把请求指令记录下来，写入日志，然后并⾏发 给其他的服务器，让他们复制这条⽇志。 3. 当这条⽇志条⽬被安全的复制，leader会应⽤这条⽇ 志条⽬到它的状态机中。 4. 然后把执⾏的结果返回给客户端。 • 提供命令在多个节点之间有序复制和执行，当多个节 点初始状态一致的时候，保证节点之间状态一致。 raft日志复制RAFT协议简介 raft配置变更 • 配置：加入一致性算法的服务器集合。 • 集群的配置不可避免会发生变更，比如替换宕机的机器。

Schema 版本问题 • 扩缩容引起的队列增减 ? Maxwell Debezium A: PolarDB-X 全局 Binlog：完全兼容 • 与 MySQL Binlog 体验完全一致 • 保障分布式事务完整性 • 透明：下游系统或工具改造成本为零 • 实现复杂度高 Q: 分布式数据库有哪些问题要考虑Demo for Global Binlog with Flink CDCPolarDB-X

AI机器学习场景 • ⼤数据计算场景 • 中间件数据存储场景 • ⽀持POSIX兼容的⽂件API • ⽀持低延迟的⽂件数据访问Curve⽂件系统⾯临的问题 • ⽤户态实现 • 稳定性/可靠性⾼ • 容易更新及维护 • 基于FUSE提供POSIX兼容⽂件接⼝ • 问题 • 相对kernel⽂件系统的实现(ext4, xfs)性能 差异⼤，延迟⾼FUSE⽂件IO读写流程

致client端无法写入。 因此，mds需要做高可用。满足多个mds, 但同时只有一个mds节点提供服务，称该提供服务的mds节点为主，等待节点为备；主节点的服务挂掉之后，备节点能启动服务，尽量减小服务中断的时间。 需要解决的问题就是：如何确定主备节点。 2. 技术选型 提供配置共享和服务发现的系统比较多，其中最为大家熟知的就是zookeeper和etcd, 考虑当前系统中mds有两个外部依赖模块，一是mysql， --write-out=json revision: 5 3.2.2 举例说明Campagin流程 场景描述：三个mds(mds1, mds2, mds3)，希望实现一个mds作为主提供服务，另外两个mds作为备在主挂掉的时候提供服务的功能。如果利用上述的Campagin进行选举，过程如下： 正常情况： step1: 三个mds向etcdserver写入带有相同前缀的key，etcd会给每个key一个版本号(revision: 一是MDS1定期去get Leader/MDS1失败后MDS退出 [事件1] 二是MDS2收到Leader/MDS1被删除，MDS2开始提供服务 [事件2] 如果事件1先发生，那么就是MDS1退出后，MDS2再当选为leader, 如果事件2先发生，那么就是MDS2当选为leader时，MDS1还在提供服务， ，这是有问题的。 出现双主 双主出现的时间有多久呢？如下图：双主的时间为PeriodicGetTime ①

6、curve文件系统的多文件系统的设计 1、设计一个分布式文件系统需要考虑的点： 文件系统的元数据是否全缓存？ 元数据持久化在单独的元数据服务器上？在磁盘上？在volume上？ inode+dentry方式？当前curve块存储的kv方式？ 是否有单独的元数据管理服务器？ 2、其他文件系统的调研总结 fs 中心化元数据 内存namespace元数据 内存空间分配元数据 元数据持久化 元数据扩展 moosefs（mfs） 有元数据服务器 全内存 fsnode → hashtable(inode id) fsedge → hashtable (parent inode + name) 全内存 chunk → hashtable(chunk id) log + dump record 差 否 chunk 链式多副本 overwirte有数据不一致风险 chubaofs（cfs） 有元数据服务器 inode 更适合大文件顺序写 fastcfs 有元数据服务器 inode和dentry放一个结构体。 inode → hashtable（key是ino，全局） dentry → skip list （key是name，每个目录下一个） 计算出来的 binlog，随时间会越来越大 差 DG Master/Slave glusterfs 无中心化服务器 dht算法 hash 扩展时大量迁移

Curve块存储提供底层分布式共享存储 3. Polardb for PostgreSQL提供上层高性能数 据库服务 4. 性能测试 1. benchmarkSQL 每分钟事务数提升39% 2. pgbench 延迟降低21% TPS提升26% 研究现状Curve块存储 1. 分布式块存储服务 2. KVM块存储服务 3. iSCSI协议 4. 容器云块存储(CSI) 应用场景Curve块存储 1. 9. 云原生 核心设计Curve块存储 1. physical pool用于实现对机 器资源物理隔离 2. zone故障隔离的基本单元 3. server表示物理服务器 4. chunkserver物理服务器上 的服务实例 拓扑结构Curve块存储 1. Curve块存储将虚拟块设备 映射到文件 2. 每个文件包含的chunk分散 在集群的存储节点 3. chunkserver按照故障域分组 Chunkserver服务Curve块存储 性能设计Curve块存储 在线升级设计 1. 客户端分成NebdClient与 NebdServer两部分 2. NebdClient只做简单的转发 3. NebdServer实现大部分的客 户端逻辑Curve块存储 故障对I/O抖动延迟的影响 FAULTS CASE CURVE I/O 抖动Curve文件存储 1. 元数据服务 2. 高性能

inode的时候，并不知道inode id，inode id是在创建完成之后返回的，这就没有办法利用分片规则去确定到底应该由哪个copyset去服务这个inode。 。 有两种思路 思路一：client在创建inode的时候，先去mds去获取一个inodeid，然后根据这个inode id找到服务这个inode的分片。出于性能上的考虑的，client可以一次从mds获取一批inode，这批inode用完了之后，再去mds去申请。 node。采用这种思路，在create fs的时候，就为fs准备好的几个copyset，然后client把copyset缓存在本地。每个copyset管理一段inode。选定copyset，就选定了服务的3个metaserver。至于均衡上，创建inode的时候，轮流在这个fs的copyset 上进行创建。这种方式肯定不如curve块设备的方案分配的那么均衡。 结论：采用思路二，由分片管理fs 的copyset的个数一定会比非独占多。copyset对资源的占用开销大不大。 会不会因为太吃资源导致性能反而下降。chubaofs的 大量的copyset 方案里面，每一个metanode上能够服务的copyset个数是有限制的，当内存和磁盘的到达一定的限度之后，这个metanode就变成readonly的，然后也不让分配新的copyset了。每个copyset的能力*copyset的个数 =