如何构建正确的云平台存储系统
2020-03-01 221浏览
- 1.如何构建“正确”的云平台存储系统 • 王为 • wei.wang@zstack.io
- 2.目录
- 3.自我介绍 • 上海云轴(ZStack)核心架构师。负责 ZStack 私有云的网络、存储 领域多个产品特性的研发。 • 在 ArchSummit、PyCon 等大会中做过技术分享。 • 向 OpenStack、MidoNet、Buildbot 等多个开源项目做过贡献。 在 Linux 的网络、存储领域有着丰富的经验。
- 4.目录 • 一个云厂商的存储之路 • 将存储做正确有多难 • 形式化验证是银弹吗 • 混沌工程：我想和云存储谈谈 • 存储错误注入
- 5.一个云厂商的存储之路
- 6.ZStack 的存储之路 • ZStack 是一个极致产品化、高性能、智能的私有云平台 • 在做云平台的前几年，我们一直借助开源存储：OCFS2、XFS、 NFS…… • 因为所有做过基础架构的人都会因存储诡异的报错信息、可怕的 调试难度、惊人的破坏力而敬而远之
- 7.ZStack 的存储之路 • 2015~2018 Ceph Community + OCFS2 + Local Storage + … • 2018 SharedBlock 接管 SAN Storage • 2019 Mini Storage
- 8.SharedBlock • 完整发挥物理性能 • 极低延迟 • 快速部署 • 对 SAN 厂家、品牌无要 求
- 9.Mini Storage • 近乎完整物理性能 • 低成本 • 快速部署 • 高稳定性
- 10.将存储做正确有多难
- 11.PostgreSQL vs fsync() • PG 使用 writeback 的机制，这样系统可能在后台默默 writeback 时出错 • 此时 IO layer/XFS 会对脏页做 AS_EIO 标记，调用 fsync() 时返回 EIO • 但 fsync() 实际上存在一个未文档化的、clear-error-and-continue 的机制 • 也就是你下一次再调用 fsync() 时如果没有新的标记的脏页，可能就返回成功了！ •https://archive.fosdem.org/2019/schedule/event/postgresql_fsync/
- 12.All File Systems Are Not Created Equal • 上层开发者往往认为崩溃一致性是最基础的保证 • 实际上崩溃一致难度也是很高的 • 从文件系统到数据库，已经被大家找出无数 Bug •https://www.usenix.org/system/files/conference/osdi14/osdi14-paper-pillai.pdf
- 13.离散碎片的环境 • 与互联网厂商解决的问题不同，但难度一样不小： • 不同厂商的存储设备 • 不同厂商的多路径配置 • 不同的服务器硬件
- 14.参差不齐的客户运维水平 • 客户升级条件不同 • 有的客户希望部署完再也不要升级…… • 联网条件不同 • 一些客户机房连手机都不允许进 • 运维水平不同 • 客户说：我觉得……
- 15.漫长的路径 • 平台 API、Agent 下命令、DM 设备操作、分布式锁、多路径、SCSI、HBA…… • 控制平面和数据平面同样重要 • 甚至控制面具有更可怕的破坏力
- 16.形式化验证是银弹吗
- 17.TLA+ 的发展之路 • 2002 年 Specifying Systems • 2015 年 How Amazon Web Services Uses Formal Methods • 2018 年 TLA Workshop • 被 MongoDB, Elasticsearch 等应用
- 18.形式化验证所不能解决的问题 • State Space Explosion • 无法转换成代码，因此在翻译时可能出错 • Spec 的正确性如何验证 • 外部依赖的正确性 • 但涉及算法正确性的证明，形式化证明依然是不可替代的
- 19.未来的形式化验证：可视化https://github.com/will62794/tlaplus_animation
- 20.未来的形式化验证：易读http://tla2018.loria.fr/contrib/liu.pdf
- 21.未来的形式化验证：可执行https://github.com/UBC-NSS/pgo
- 22.混沌工程：我想和云存储谈谈
- 23.为什么现在都在说混沌工程 • 单机应用向集群应用 • 基于系统编程向基于服务编程 • 对于基础设施软件可以借鉴吗？
- 24.不谈方法说概念都是耍流氓 • MTBF 长时间运行，随机动作 • DPMO 反复迭代测试 • Woodpecker 数以万次的调用 API
- 25.注入什么错误？ • 传统方法： poweroff tc ifconfig • 传统方法的缺点： 对复杂场景无法模拟 不够灵活
- 26.云厂商面临的存储路径
- 27.存储错误注入
- 28.用户态错误注入：libfiuhttps://blitiri.com.ar/p/libfiu/
- 29.内核错误注入：systemtap • 优点 相对灵活 函数级别 易于安装 • 缺点 速度慢 达不到 IO 级别
- 30.故障块设备模拟：device-mapper • dm-flakey 周期性故障 • dm-delay 增加延时
- 31.故障块设备模拟：NBD
- 32.总结 • 设计阶段 • 形式化验证可以减少设计的 Bug • 但并不是银弹，有成本，有局限 • 开发阶段 • 开发可测试代码 • 注重测试 • 注重错误注入
- 33.总结 ⼿手段 层⾯面 便便利利程度 灵活程度 模拟特定模式 libfiu ⽤用户态 很⽅方便便 限制较多 不可以 scsi_debug 内核态 比较⽅方便便 限制较多 不可以 systemtap 内核态 比较复杂 比较灵活 可以 device mapper 内核态 比较⽅方便便 限制较多 不可以 nbd - 复杂 非常灵活 可以
- 34.总结
- 35.
- 36.
