如何用CLup管理Polardb 4008878716 services@csudata.com http://www.csudata.com 中启乘数科技 @http://www.csudata.com │中启乘数科技（杭州）有限公司 数据赋能│价值创新 关于我 《PostgreSQL修炼之道：从小工到专家》的作者，中 启乘数科技联合创始人，PostgreSQL中国用户会常委。 从 @ 专业的PostgreSQL数据库管理平台 CLup介绍CLup产品介绍 网络 clup-agent 数据库主机1 clup-agent 数据库主机2 clup-agent 数据库主机n  CLup是什么？  实现PostgreSQL/PolarDB数据库的私有云 RDS产品  PostgreSQL/PolarDB集群统一管理、统一运 维。  PostgreS 实现对PostgreSQL/PolarDB的监控管理  对PostgreSQL/PolarDB的TopSQL的管理  架构说明  有一台机器上部署的CLup管理节点，这个管 理节点提供WEB管理界面统一管理所有的 PostgreSQL/PolarDB数据库。  每台数据库主机上部署clup-agent。CLup管 理节点通过clup-agent来管理这台机器上的 PostgreSQL/PolarDB数据库。

© XXX Page 1 of 24 Curve文件系统元数据管理（已实现）© XXX Page 2 of 24 1. 2. 3. 4. Inode 1、设计一个分布式文件系统需要考虑的点： 2、其他文件系统的调研总结 3、各内存结构体 4、curve文件系统的元数据内存组织 4.1 inode定义： 4.2 dentry的定义： 4.3 内存组织 5 元数据分片 元数据持久化在单独的元数据服务器上？在磁盘上？在volume上？ inode+dentry方式？当前curve块存储的kv方式？ 是否有单独的元数据管理服务器？ 2、其他文件系统的调研总结 fs 中心化元数据 内存namespace元数据 内存空间分配元数据 元数据持久化 元数据扩展 小文件优化 空间管理单位 数据持久化 其他© XXX Page 3 of 24 moosefs（mfs） 有元数据服务器 全内存 fsnode + name) segment kv → hashtable(key inode + offset) etcd 差 块设备，最小10GB segment + chunk raft 块设备的元数据管理 cephfs 3、各内存结构体 时间复杂度 空间复杂度 特点 可用实现 Btree 一个节点上保存多条数据，减少树的层次(4~5层)，

监控——直观地展示Curve运行状态；  运维——保障Curve始终稳定高效运行。 质量 ✓ 质量管理体系（设计、开发、review、CI） ✓ 测试方法论（单元测试、集成测试、系统测试） 监控 ✓ 监控架构 ✓ 指标采集、后端处理、可视化展示 运维 ✓ 运维特性 （易部署、易升级、自治） ✓ 运维工具（部署工具、管理工具） 4/33背景 01 02 03 04 Curve质量控制 Curve监控体系 软件质量的定义是：软件与明确地和隐含地定义的需求相一致的程度。 为了确保最终交付的软件满足需求，必须将质量控制贯穿于设计、开发到测试的整个流程中。 设计  设计流程  文档规范 开发  编码规范与提交流程  版本管理 测试  测试方法论  CI与异常测试 6/33设计流程 Curve团队采用敏捷开发模式，负责人在制定迭代计划时，确认哪些任务需要设计 文档：  小需求（改动小）将实现思 小需求（改动小）将实现思路记录到任务管理系统中（JIRA），即可进行开发；  大需求（新模块、复杂功能）需要输出独立设计文档，并进行评审；对于功能或 性能影响较大的功能，还需要进行POC验证；评审和验证通过后才能启动开发 工作。 小需求 实现思路 开发 大需求 设计文档 POC 开发 7/33设计文档规范 设计文档需要具备以下内容：  修订记录  审批记录  系统介绍  相关调研  架构

MDS 管理元数据信息 收集集群状态信息，自动调度 • 数据节点 Chunkserver 数据存储 副本一致性 • 客户端 Client 对元数据增删改查 对数据增删改查 • 快照克隆服务器MDS各个组件 MDS是中心节点，负责元数据管理、集群状态收集与调度。MDS包含以下几个部分： • Topology: 管理集群的 topo 元数据信息。 • Nameserver: 管理文件的元数据信息。 unkserver上的负载信息、 copyset信息等。 • Scheduler: 调度模块。用于自动容错和负载均衡。TOPOLOGY topology用于管理和组织机器，利用底层机器的放置、网络的规划以面向业务提供如下功能和非功能需求。 1. 故障域的隔离：比如副本的放置分布在不同机器，不同机架，或是不同的交换机下面。 2. 隔离和共享：不同用户的数据可以实现固定物理资源的隔离和共享。 用于抽象描述物理服务器上的一块物理磁盘 (SSD)，chunkserver以一块磁盘作为最小的服务单元。TOPOLOGY curve在上物理pool之上又引入逻辑pool的概念，以实现统一存储系统的需求，即在单个存储系统中多副 本PageFile支持块设备、三副本AppendFile（待开发）支持在线对象存储、AppendECFile（待开发）支持 近线对象存储可以共存。 如上所示Logic

竞技栏目: 100万/场 曝光流量 • SIG • Issue 开源代码协作 • 理事会 • 人才发展委员会 • 技术委员会 开源社区治理 • 联合解决方案|产品 • OxM发型版 • 数据库管理产品 • 数据迁移、联邦产品 生态伙伴合作 高校合作 学习、分享、比赛、贡献 服务客户 开源共建 社区运营 生态建设 获得生态 商业服务 使用开源 PolarDB 开源学习 开源共建 人才招聘 PolarDB开源生态 共建模式 国产化替代 应用软件 适配迁移 生态伙伴集成 • 云市场、云速搭 • 创新中心SaaS市场 • 云起实验室 接入云端销售 数据价值放大 • 基础设施 • 安全 • 管理维护 • 数据集成 • 开发协同 • ISV • 培训育人 • 商业服务 • ... 2022S1: 3500W曝光 150W学习人次 2万+实践体验 2K+持证人才 PolarDB开发大赛: 兼容PG&MySQL • 透明分布式 • HTAP • 企业特性(闪回、TDE、冷热分离...) 50+全链路伙伴: 韵达、莲子数据、网易数帆、 龙蜥、武汉大学 ... 等 需求 手段 需求 手段 需求 手段 需求 手段 需求 手段欢迎加入PolarDB开源生态

第一 Curve的由来 Curve的设计目标 Curve块存储 和 Curve文件存储 Curve社区Curve的由来 1. 代码复杂/代码量大 2. 运维难度高 3. 无法满足高的性能需求Curve的设计目标 1. Curve云原生软件定义存储 2. Curve块存储 3. Curve文件存储 4. 高性能，易运维，云原生Curve块存储 1. 高性能分布式共享数据库场景 3. 可扩展易运维 4. 云原生 设计目标Curve文件存储 1. 兼顾性能与容量的机器学习 场景 2. 快速跨云弹性发布的业务 3. 低成本大容量需求的业务 4. 中间件冷热数据自动分离 5. S3和POSIX统一访问需求 主要挑战和支持场景Curve Roadmap 1. 架构 1. 文件存储支持分布式缓存、完善冷热数据分层存储能力 2. 完善混合云、公有云上部署架构 性能 1. 完善RDMA/SPDK方案，发布稳定版本 2. 更高性能硬件选型、适配及性能调优 3. 大文件读写性能优化，RAFT优化，降低写放大 3. 功能 1. 文件存储支持回收站/生命周期管理/配额/用户权限等 2. 支持NFS、CIFS/SMB、HDFS等协议 3. 块存储支持按存储池创建卷Curve 社区介绍 1. Curve的成长离不开社区贡献者的支持和参与。非常欢迎广大

1个 UcpContext: N个 UcpWorker42 连接管理器UcpCm ●连接管理类 –全局唯一对象 –通过UcpCm * get_or_create_ucp_cm(void)获取 –完成连接的接受 –完成连接的创建 ●监视brpc::Socket类关闭文件句柄 ●连接以文件句柄表示43 连接管理器UcpCm ● 连接以文件句柄返回 –int Accept(ucp_conn_request_h req); –int Connect(const butil::EndPoint &peer); –UcpConnectionRef GetConnection(int fd1);44 连接管理器UcpCm ●Brpc socket代码不少地方需要文件句柄表示连接，使用句柄可以减少代码修改。例如 SocketOptions.fd为-1表示尚未连接。 ●UcpCm返回的文件句柄实际上是pipe的写端句柄 改。UcpCm检测到pipe读端可读，关闭UcpConnection。 ●以上修改实际上绕过了BRPC的Event dispatcher触发读写机制，UCX自己完成发送接收45 连接管理器UcpCm ●连接管理类 –全局唯一对象 –通过UcpCm * get_or_create_ucp_cm(void)获取 –完成连接的接受 –完成连接的创建 ●监视brpc::Socket类关闭文件句柄

write(offset, len) •服务质量要求：数据不能丢、服务随时可用、弹性扩缩容 要什么 •成百上千台存储节点 •磁盘故障、机器故障、网络故障概率性发生 有什么 分布式存储系统需要满足接口需求，并且有持续监控、错误检测、容错与自动恢复的能力 以达到高可靠、高可用、高可扩分布式存储的要素 要 素 拆 解 数据分布 —— 无中心节点/中心节点 均 衡 object：存储单元 PG：Placement Groups 归置组 归置组中的成员为副本 OSD：Object Storage Device, 管理一个磁盘的进程架构简介 — 数据放置 使用多级哈希的方式 使用CRUSH算法根据pgid获得指定的副本个数的id osd.1, osd.2, osd.3 对ObjectID进行哈希并取模（复制组数量）得到pgid — 总体架构 支持块存储、文件存储（多种存储后端）架构简介 — 概念介绍 Segment: 空间分配的基本单元 Chunk: 数据分片 Copyset: 复制组 ChunkServer: 管理一个磁盘进程架构简介 — 数据放置 Copyset的放置 Chunk的分配 • 由中心节点MDS以Scatter-width 均衡为目标进行创建 • 由中心节点MDS在各Copyset中 根据权重进行选择架构简介

如果自己实现，只是一个简单的 sava/load 逻辑，比较清晰 redis 中有许多数据结构可供使用，如 (哈希、列表、set、sort_set)，但对于目前的需求来说，我们内存数据结构使用的是 C++ STL 中的哈希表（unsorted_map），之后有可能根据需求换成 B+ 树或跳表，但是 redis 中的这些数据结构我们是不需要的 另外，如果 C++ 中的哈希表在后期使用中发现性能不达标的话（特别是在 rehash

© XXX Page 1 of 30 Curve元数据节点高可用© XXX Page 2 of 30 1. 需求 2. 技术选型 3. etcd clientv3的concurrency介绍 3.1 etcd clientV3的concurrency模块构成 3.2 Campaign的流程 3.2.1 代码流程说明 3.2.2 举例说明Campagin流程 3.3 Observe的流程 Etcd集群与MDS1(当前leader)出现网络分区 4.2.5.1 事件一先发生 4.2.5.2 事件二先发生 4.2.6 异常情况4：Etcd集群的follower节点异常 4.2.7 各情况汇总 1. 需求 mds是元数据节点，负责空间分配，集群状态监控，集群节点间的资源均衡等，mds故障可能会导致client端无法写入。 因此，mds需要做高可用。满足多个mds, 但同时只有一个mds节点提供服