云平台存储系统构建方案

1、技术创新，变革未来云平台存储系统构建方案目录一个云厂商的存储之路将存储做正确有多难形式化验证是银弹吗混沌工程：我想和云存储谈谈存储错误注入一个云厂商的存储之路ZStack 是一个极致产品化、高性能、智能的私有云平台在做云平台的前几年，我们一直借助开源存储：OCFS2、XFS、 NFS因为所有做过基础架构的人都会因存储诡异的报错信息、可怕的 调试难度、惊人的破坏力而敬而远之ZStack 的存储之路20152018 Ceph Community + OCFS2 + Local Storage + 2018 SharedBlock 接管 SAN Storage2019 Mini StorageZSt

2、ack 的存储之路SharedBlock完整发挥物理性能极低延迟快速部署对 SAN 厂家、品牌无要求Mini Storage性能近乎完整物理低成本快速部署高稳定性将存储做正确有多难PG 使用 writeback 的机制，这样系统可能在后台默默 writeback 时出错此时 IO layer/XFS 会对脏页做 AS_EIO 标记，调用 fsync() 时返回 EIO但 fsync() 实际上存在一个未文档化的、clear-error-and-continue 的机制也就是你下一次再调用 fsync() 时如果没有新的标记的脏页，可能就返回成功了！/2019/schedule/event/po

3、stgresql_fsync/PostgreSQL vs fsync()All File Systems Are Not Created Equal上层开发者往往认为崩溃一致性是最基础的保证实际上崩溃一致难度也是很高的从文件系统到数据库，已经被大家找出无数 Bughttps:/system/files/conference/osdi14/osdi14-paper-pillai.pdf难度一样不小：与互联网厂商解决的问题不同，但不同厂商的存储设备不同厂商的多路径配置不同的服务器硬件离散碎片的环境客户升级条件不同有的客户希望部署完再也不要升级联网条件不同一些客户机房连手机都不允许进运维水平不同客户

4、说：我觉得参差不齐的客户运维水平平台 API、Agent 下命令、DM 设备操作、分布式锁、多路径、SCSI、HBA控制平面和数据平面同样重要甚至控制面具有更可怕的破坏力漫长的路径形式化验证是银弹吗2002 年 Specifying Systems2015 年 How Amazon Web Services Uses Formal Methods2018 年 TLA Workshop被 MongoDB, Elasticsearch 等应用TLA+ 的发展之路State Space Explosion无法转换成代码，因此在翻译时可能出错Spec 的正确性如何验证外部依赖的正确性但涉及算法正确性的

5、证明，形式化证明依然是不可替代的形式化验证所不能解决的问题未来的形式化验证：可视化/will62794/tlaplus_animation未来的形式化验证：易读http:/tla2018.loria.fr/contrib/liu.pdf未来的形式化验证：可执行/UBC-NSS/pgo混沌工程：我想和云存储谈谈单机应用向集群应用基于系统编程向基于服务编程对于基础设施软件可以借鉴吗？为什么现在都在说混沌工程MTBF长时间运行，随机动作DPMO反复迭代测试Woodpecker数以万次的调用 API不谈方法说概念都是耍流氓传统方法：poweroff tc ifconfig传统方法的缺点：对复杂场景无法模拟 不够灵活注入什么错误？云厂商面临的存储路径存储错误注入用户态错误注入：libfiu.ar/p/libfiu/内核错误注入：systemtap优点相对灵活 函数级别 易于安装缺点速度慢达不到 IO 级别故障块设备模拟：device-mapperdm-flakey周期性故障dm-delay 增加延时故障块设备模拟：NBD总结设计阶段形式化验证可以减少设计的 Bug但并不是银弹，有成本，有局限开发阶段开发可测试代码注重测试注重错误注入总结手段层面便利程度灵活程度模拟特定模式libfiu用户态很方便限制