存算分离

拿快照来说，为啥我们支持快照的多链这么复杂？按道理虚拟机只需要一个卷，至于这个卷背后的链是完全不需要关心的。如果计算存储分离，快照局限于存储模块，计算只需要一个卷。 现象：快照的多链为什么这么复杂 拿快照来说，为啥我们支持快照的多链这么复杂？ 按道理虚拟机只需要一个卷，至于这个卷背后的链是完全不需要关心的。 但是放到我们代码，复杂无比，即便是单链也异常复杂，多链简直就做不下去了。 如果分开，不过多复杂的快照链，只需要在快照模块处理。 但是我们现在的代码，各种功能和存储都在一起： 开关机要管理快照链（不是调接口，而是一行一行的命令呀）； 克隆要管理快照链； 迁移对快照链的操作更多了； 回滚快照、打快照，那更复杂了（快照的管理，一行一行的命令，元数据的修改，都在各种流程中交错）。简直了！ 为什么这么难改 你可能会说，改呀，重构呀。 几十万行的屎山，牵一发动全身。不是一个人就能改的了的。 而且你改的过程中，别人还在持续扩展新功能，别人要怎么配合你的修改，都是很难的事。 这种推动，一定是自上而下的。不是说一人之力不能改，而是没人敢让你上。 得需要资源做 QA 大规模测试，还需要新扩展能力的配合，还需要领导有魄力，胆大心细。 执行人能做到心细，但是执行人胆大没用，别人怕出了问题你承担不了呀，得别人背锅。 需要决策人有魄力，自顶向下的推动。 但是如果老板或决策者离一线（售后、研发）远了，很可能不看重这些。 决策者大概率觉得，能跑就行，技术是工具，能满足客户需求即可。 但实际是，很多客户因为稳定性而流失，稳定性是因为屎山代码、架构问题、代码问题。 但是这些东西不能给财务数据带来改善，销售才能改善财务数据，所以继续怼销售提的需求，继续挖坑，继续流失客户。 根因：快照和计算绑定 就是因为我们的快照的处理、链的管理，都在计算里面。 因为我们主要用的 qcow2，qcow2 的快照性能高呀。 但是它有个问题，qcow2 的快照是和计算绑定的。 它为啥性能高，因为它需要计算层联动切换读写头。 如果要计算存储分离，就需要存储提供一种快照模式，不切换读写头，就能做快照。 lvm 是一种方式，bitmap，但是它做快照后写性能很低。 不考虑性能的因素下，计算、存储分离，极大降低快照开发的复杂性。 快照局限于存储模块，甚至是存储模块的快照子模块。计算只需要一个卷，不管其背后的链。 快照模块如何实现多链 A->B->C-> active 回滚到 A 后，A->active。 这个时候，要实现 B、C 的保留，且不被影响，也不影响别人，保留且独立。 如果是 qcow2 快照，那么天然是独立的，保留卷、保留链的数据关系即可； 如果是 lvm 这种，每个快照本身是独立的，保留即可，保留链关系元数据即可。 归根到底，链关系好处理，复杂性还是在存储端，性能和空间的取舍。 数据表的设计也简单，就是一个以原卷为根的一个树结构。 小结 边界：计算、存储、网络要分离； 按道理虚拟机只需要一个卷，至于这个卷背后的链是完全不需要关心的； 计算存储分离，极大降低快照开发的复杂性； 快照局限于存储模块，计算只需要一个卷，不管其背后的链； 几十万行的屎山，牵一发动全身，这种推动一定是自上而下的。