TDDL首次双十一 “去IOE完成” 天价账单 上云 2009 2011 2012 2013 2013 2015 TDDL 以中间件形态在阿里云上 发布: DRDS Oracle根据双十一350的交易量， 反推出了天价账单也谈所谓的“中间件” 中间件只是起点，PolarDB-X 可能是离终点最近的那个 对近十年的探索以及五年的上云 经验进行重新思考，面向未来设 从运维视角实现计算存储一体化 计新架构

1 Curve中MDS的选举过程 4.2 图示说明选举流程 4.2.1 正常流程 4.2.2 异常情况1：MDS1退出，可以正常处理 4.2.3 异常情况2：Etcd集群的leader发生重新选举，MDS1未受影响，可以正常处理 4.2.4 异常情况3：Etcd的leader发生重新选举，MDS1受到影响退出，不一定可以正常处理。 4.2.4.1 LeaseTIme < ElectionTime的情况 场景描述：三个mds(mds1, mds2, mds3)，希望实现一个mds作为主提供服务，另外两个mds作为备在主挂掉的时候提供服务的功能。如果利用上述的Campagin进行选举，过程如下： 正常情况： step1: 三个mds向etcdserver写入带有相同前缀的key，etcd会给每个key一个版本号(revision: 是全局递增的)© XXX Page 12 of 30 1. 18 of 30 1. return C.ObserverLeaderChange } } 4.2 图示说明选举流程 4.2.1 正常流程 MDS1当选leader, MDS2和MDS3处于watch状态 MDS1当选leader之后，与EtcdServer建立的交互如下： ①与etcd server维持租约。这里涉及到租约的时间

站在使用者的角度，对模块提供的功能进行完备 的测试。  异常测试 制造或模拟系统异常(磁盘错误、网络错误、资源 冲突等)、依赖服务异常、应用本身异常等非正常 情况，测试软件的性能和稳定性是否符合预期。  规模测试 测试模块在一定规模下是否能够正常工作，是否 会出现异常或者崩溃， 14/33系统测试 系统测试是对整个系统的测试，将硬件、软件、操作人员看作一个整体，检验它是否有不符 合系统 Curve的系统测试一般是由QA来完成，包含：  常规测试，主要是新增功能的手工测试；  性能测试，将性能数据与基准对照，确定性能没有出现预期外的下降或提升；  稳定性测试，在正常压力下运行足够长的时间；  异常测试，在正常流程中注入一种软硬件异常；  混沌测试，大压力多级故障（随机组合软硬件异常）。 在系统测试过程中，我们尽可能将所有用例自动化，其优点是：  大幅降低了测试回归成本，加快了测试进度；

Order ConfigChange: 将 MDS 下发的任务提交给对应的 对应 模块执行。HEARTBEAT Chunk server的状态更新： • Online: chunk server在线，正常服务。 • Unstable: chunk server一段时间没收到心跳（默认 30s），但是还没有到达offline的时间（默认 30min），chunkserver状态改为unstable状态，打 跳（默认30min）， chunkserver状态改为offline， 打印一条error日志。调度模块感知到offline状态， 触发chunk server的recover修复。 心跳正常 心跳正常 超过miss时间 未超过offline时间 UNSTABLE ONLINE OFFLINESCHEDULE Schedule（系统调度）是为了实现系统的自动容错和负载均衡，这两个功能是分布式

基于rocksdb的存储引擎 • 要求存储的元数据的大小不超过内存的大小 • raft apply的请求，数据都在内存，直接修改 内存中的数据 • raft snapshot，为避免快照对正常操作的影 响，利用操作系统的内存写时复制技术， fork一个进程创建完整的状态机的内存快照， 后台遍历内存，把内存的数据持久化到本地 磁盘 基于memory的存储引擎 • 存储元数据量不受内存大小限制 1. 每次快照，空间上要多出1倍，空间浪费严重。 2. Curve块存储快照间隔默认30 分钟一次，每次快照会产生大量的数据拷贝，占用chunkserver的 处理能力，对磁盘造成很大压力，影响正常IO。 解决思路： chunk支持覆盖写，覆盖写天然是幂等的，写一次和写多次结果一致。 打快照只记录chunk文件的列表，不拷贝chunk的内容。从快照+日志加载数据时，下载的chunk文 件不

地址空间的每段数据会分布在不同机器的磁盘上，如 何找到这些数据？ 可靠性 & 可用性 —— 多副本/EC 服务不可用时 间 数据一致性 —— 一致性协议 如何保证数据不丢？如何保证各种硬件故障的时候读 写都正常？ 可扩展性 —— 和数据分布的方式相关 所用容量都用完后，可以新增机器扩展容量分布式存储的要素 — 数据分布 无中心节点：哈希算法 INPUT (Offset, Len) HASH HASH

较少，文件很大。这种情况inode比较聚集，一般分布在几个复制组上。inode数量少。 以上这两种情况，以20TB为例，数据量在MB级别，client获取数据可以使用stream类型的rpc？ ③ 正常使用场景，有一定的目录层级，文件分配数量较多，文件较小。这种情况inode比较分散，一般分布在多个复制组上，inode数量较多。 client获取数据可以并发从多个复制组中获取。 数据结构的选取？

er’）启用内核基于mode的权限控制。 2：新建rootinode mode = 1777（原因是设置STICKY，避免普通用户对非自己所属文件的删除） 3：这样达到的效果除了不支持ACL外与正常本地文件系统权限管理一致（一般情况下使用ACL极少，且从抓取的传媒接口调用发现并未涉及相关接口的调用）。 参考文献： https://www.huaweicloud.com/article