副本如何用CLup管理PolarDBclup-server 数据中心1 CLup管理节点1 clup-server 数据中心2 CLup管理节点2 clup-server 数据中心1 CLup管理节点2 高可用机制自动切换 数据一致性保证 数据可用性 提供读写VIP 读写高可用 读写分离 多个读库之间负载均衡 负载均衡 读线性扩展 支持分库分表 高扩展性 写 VIP 读 VIP PG0 码力 | 34 页 | 3.59 MB | 6 月前3
新一代云原生分布式存储数据分布 —— 无中心节点/中心节点 均 衡 地址空间的每段数据会分布在不同机器的磁盘上,如 何找到这些数据? 可靠性 & 可用性 —— 多副本/EC 服务不可用时 间 数据一致性 —— 一致性协议 如何保证数据不丢?如何保证各种硬件故障的时候读 写都正常? 可扩展性 —— 和数据分布的方式相关 所用容量都用完后,可以新增机器扩展容量分布式存储的要素 — 8MB) 60 (8MB, 16MB) 50分布式存储的要素 — 一致性协议 多副本: 写三次? 一致性协议 一致性:WARO(Write-all-read-one)、Quorum WARO • 所有副本写成功 • 读可用性高:可以读任一副本 • 写可用性较低,任一副本异常写失败 Quorum • 大多数副本写成功 • 读写服务可用性做一个折中 • 写性能提升,速度取决于写的较快的大多数 object:存储单元 PG:Placement Groups 归置组 归置组中的成员为副本 OSD:Object Storage Device, 管理一个磁盘的进程架构简介 — 数据放置 使用多级哈希的方式 使用CRUSH算法根据pgid获得指定的副本个数的id osd.1, osd.2, osd.3 对ObjectID进行哈希并取模(复制组数量)得到pgid0 码力 | 29 页 | 2.46 MB | 6 月前3
Raft在Curve存储中的工程实践raft和braft 03 raft在Curve中的应用 05 Q&A 04 Curve对raft的优化RAFT协议简介 什么是raft • raft 是一种新型易于理解的分布式一致性复制协议,由斯坦福大学的Diego Ongaro和John Ousterhout提出,《In Search of an Understandable Consensus Algorithm(Extended Version)》 • raft 是一种Leader-Based的Multi-Paxos变种,提供了更完整更清晰的协议描述,更容易理解和实现。 • raft可以解决分布式理论中的CP,即一致性和分区容忍性 • 大多数副本成功即可返回成功 • 速度取决于写的较快的大多数RAFT协议简介 • Leader:负责从客户端接受日志,把日志复制到其 他服务器,当保证安全性的时候告诉其他服务器应用 日志条目到他们的状态机中。 然后把执⾏的结果返回给客户端。 • 提供命令在多个节点之间有序复制和执行,当多个节 点初始状态一致的时候,保证节点之间状态一致。 raft日志复制RAFT协议简介 raft配置变更 • 配置:加入一致性算法的服务器集合。 • 集群的配置不可避免会发生变更,比如替换宕机的机器。 直接配置变更可能出现双主问题 • 共同一致(joint consensus) • 集群先切换到一个过渡的配置(old0 码力 | 29 页 | 2.20 MB | 6 月前3
Curve设计要点• 元数据节点 MDS 管理元数据信息 收集集群状态信息,自动调度 • 数据节点 Chunkserver 数据存储 数据一致性基本架构 • 元数据节点 MDS 管理元数据信息 收集集群状态信息,自动调度 • 数据节点 Chunkserver 数据存储 副本一致性 • 客户端 Client 对元数据增删改查 对数据增删改查基本架构 • 快照克隆服务器 独立于核心服务 储到支持S3接口的 • 支撑多副本对象存储 通过文件/特殊目录隔离 挖洞即时回收 单独的元信息的存储方案数据组织形式 • AppendECFile • 地址空间到—>chunk: 1 : 1 • 数据chunk + 校验chunk数据组织形式 • AppendECFile • 地址空间到—>chunk: 1 : 1 • 数据chunk + 校验chunk • 支撑EC存储场景 多个单副本的 chunk 4K随机读 61.12 % 67.8% 测试环境:6台服务器*20块SATA SSD,E5-2660 v4,256G,3副本场景 高性能高性能 • quorum机制:raft • 轻量级快照 • io路径上的优化 • filepool落盘零放大 • 轻量级线性一致性读 • io路径上用户空间零拷贝 10卷4K随机读写IOPS 294k 185k 330k 565k 4K随机写0 码力 | 35 页 | 2.03 MB | 6 月前3
CurveFS Copyset与FS对应关系1 一台机器上能存放多少个inode和dentry 8.2 一台机器上建议的copyset数量 8.3 每个copyset建议管理存储容量的大小 1、背景 curvefs使用raft作为元数据一致性的保证。为了提高元数据的可扩展性和并发处理能力,采用元数据分片的方式管理inode和dentry的元数据。inode的分片依据是fsid + inodeid,dentry的分片依据是fsid + p r变更任务; ReplicaScheduler: 副本数量调度器。根据当前copyset的副本数生成副本增删任务; RecoverScheduler: 恢复调度器。根据当前copyset副本的存活状态生成迁移任务。 结论:心跳参考curve。目前这些调度器在curvefs第一阶段不用全部实现。所有和均衡相关的,暂时不做。只做和故障处理相关的副本补全恢复的调度。 6、详细设计 6.1 创建fs curve在创建logic pool的时候去创建copyset。现在集群的topo信息在mds创建好了之后,topo中并没有coypset,而是提供接口,随用随创建。copyset选择哪些metaserver的作为3副本的过程,暂时先复用的原来curve块存储创建co pyset的流程,将来再做优化。 文件系统的分片,用 partition表示,每个partition由一个copyset管理。每个copyset管0 码力 | 19 页 | 383.29 KB | 6 月前3
CurveFS方案设计slave,slave 在内存中也缓存了全部元数据信息 master-slave 多副本数据 CurveFS 分布式元数据设计 类似 chubaofs 的元数据设计方式,同样是采用 dentry,inode 两层映射关系,所有的元数据都缓存在内存中。元数据是分片的,使用 multi-raft 持久化元数据以及保证多副本数据一致性。基于这种方式开发: a. 性能 由于元数据分片,获取元数据需要跟多 2. 3. 1. 1. 2. 3. metaserver: 元数据服务进程。一个进程管理多个复制组 copyset: 复制组,使用 raft 保证数据一致性。复制组中保存文件系统的部分元数据信息 文件系统元数据和复制组是多对多的关系 一个复制组可以包含多个文件的元数据信息 复制组 wal 记录元数据操作 定期 snapshot 对 wal 进行清理。snapshot 创建新的inode节点,dentry中标明符号链接 实际数据保存链接到的路径 Link 创建新的dentry, 指向同一个inode 文件系统快照 方案一:文件/目录级别快照 快照是文件系统或卷的只读副本,快照要求可以即时创建。类似 moosefs,curvefs 可以计划支持目录及文件级别的快照,目录级别和文件级别的快照可以认为就是cp的实现。 对于文件/目录级别的快照: 检查目的节点的父节点中是否有同名文件存在:0 码力 | 14 页 | 619.32 KB | 6 月前3
CurveFS rename 接口实现方案冲突问题,利用该机制在读写时候可以去除锁机制 Multi-version Concurrency Controller (备注:我认为利用 MVCC 可以保证事务 ACID 中的 C(一致性) 和 I(隔离性)) 方案主要借鉴 leveldb 与 etcd(boltdb) 中事务的实现(主要利用 mvcc),方案设计如下:© XXX Page 7 of 15 整体思路如下: 顺序递增,事务每成功一次则加一) 每次 rename 开始时, (其实就是创建副本,不管是删除/创建/更改都是创建相应 将 srcDentry, dstDentry 所在 copyset 对应的 txid 分别加 1 (copyset_txid+1) 去删除/创建/修改 dentry copyset_txid+1 为 key 的副本,原始 dentry 不动),并设置 PendingTx 为本次事务 如果上一步骤成功了,就提交事务,将 对应事务刚好操作的是请求的 dentry,则返回 PendingTxKey + PendingTxId 对应的副本 dentry,否则返回原始 dentry PendingTx 与 dentry 副本是一一对应的,下面有机制确保,每个 copyset 只需要一个 PendingTx(即整个 copyset 中最多只会存留一个副本 dentry) 下面是图中流程说明: (1) mount 的时候将 MDS 中所有 copyset0 码力 | 15 页 | 555.93 KB | 6 月前3
Curve核心组件之mds – 网易数帆Chunkserver 数据存储 副本一致性 • 客户端 Client 对元数据增删改查 对数据增删改查 • 快照克隆服务器MDS各个组件 MDS是中心节点,负责元数据管理、集群状态收集与调度。MDS包含以下几个部分: • Topology: 管理集群的 topo 元数据信息。 • Nameserver: 管理文件的元数据信息。 • Copyset: 副本放置策略。 • Heartbeat: Scheduler: 调度模块。用于自动容错和负载均衡。TOPOLOGY topology用于管理和组织机器,利用底层机器的放置、网络的规划以面向业务提供如下功能和非功能需求。 1. 故障域的隔离:比如副本的放置分布在不同机器,不同机架,或是不同的交换机下面。 2. 隔离和共享:不同用户的数据可以实现固定物理资源的隔离和共享。 • pool: 用于实现对机器资源进行物理隔离,server不能跨 (SSD),chunkserver以一块磁盘作为最小的服务单元。TOPOLOGY curve在上物理pool之上又引入逻辑pool的概念,以实现统一存储系统的需求,即在单个存储系统中多副 本PageFile支持块设备、三副本AppendFile(待开发)支持在线对象存储、AppendECFile(待开发)支持 近线对象存储可以共存。 如上所示LogicalPool与pool为多对一的关系,一个物理pool可以存放各0 码力 | 23 页 | 1.74 MB | 6 月前3
Curve核心组件之chunkserver新版本ChunkServer性能优化CURVE基本架构 • 元数据节点 MDS • 管理和存储元数据信息 • 感知集群状态,合理调度 • 数据节点 Chunkserver • 数据存储 • 副本一致性,raft • 客户端 Client • 对元数据增删改查 • 对数据增删改查 • 快照克隆服务器CURVE基本架构 01 02 03 04 ChunkServer架构 ChunkServer核心模块 初始状态,copyset1,copyset2,copyset3的三个副本分别在 CS1,CS3,CS4上,完成迁移后,CS1上的副本迁移到CS2上 ① CS1超时未向MDS上报心跳(默认半小时) ② MDS标记CS1状态为offline ③ MDS的recover scheduler发现copyset1, 2, 3的副本CS1 offline, 生成change peer from CS1 retired,CS1下线完毕。ChunkServer核心模块-CopysetNode 换盘(CS1对应的盘)后重新上线的流程 初始状态,copyset1,copyset2,copyset3的三个副本分别在 CS2,CS3,CS4上,完成恢复后,CS2上的copyset1,2,3迁移到CS1上 ① CS1换了新盘,并重新格式化后启动chunkserver ② CS1重新向MDS注册 ③ MDS生成新的chunkserver0 码力 | 29 页 | 1.61 MB | 6 月前3
TGT服务器的优化通过iSCSI支持更多系统,例如Windows, 类UNIX系统等,使用两项基础 技术 • TCP/IP • SCSI • 替代SAN • 可靠性、稳定性方面有自己的的特色,使用raft副本一致性和copyset概念可以自动 修复损坏的副本,并且可扩容。无论在可靠性、稳定性还是性价比方面都很有优势, 使用廉价硬件搭建。iSCSI软件 • Client端: iscsi initiator,系统自带 • Linux0 码力 | 15 页 | 637.11 KB | 6 月前3
共 63 条
- 1
- 2
- 3
- 4
- 5
- 6
- 7













