ZStack教您构建“正确的”云平台存储

ZStack教您构建“正确的”云平台存储

从2015年到现在，ZStack有一个宗旨没有变，那就是为客户交付一个稳定、可靠、高性能的云平台。这个宗旨让我们前几年把重点放在了云平台本身，包括虚拟化、云网络、云编排、存储管理等等。

在这方面，最让我们头疼的，即使不是第一位的，也是存储管理。

考虑到存储对业务的无比重要性以及我们作为初创公司的支持能力，我们从一开始就基于一些开源存储方案为客户提供服务:

1.XFS，作为RHEL默认的本地文件系统，我们一直信任XFS，但实际上，使用XFS存在很多问题。我们已经帮助我们的客户绕过许多坑，并正在考虑其他替代方案。

2.NFSNFS是一个简单的云平台解决方案，因为它屏蔽了大量的存储复杂性，以文件系统的形式提供共享存储，这样我们就可以用类似于本地文件系统的方式管理共享存储。它很简单，并支持热迁移等高级功能。这看起来很完美，但事实上NFS几乎是我们最不推荐的生产存储解决方案之一。细节将在后面讨论；

3.OCFS2，当用户只有SAN存储，无法提供NFS接口时，我们的选择并不多。此时，Oracle的OCFS2已经成为一种流行的解决方案。它的优点是小规模使用时基本稳定，部署后也可以以文件系统的形式使用。但其在性能、大规模可扩展性和部分功能(如文件锁)上的支持并不完善。

4.Ceph，基于Ceph可以提供一个很棒的存储解决方案，但是Ceph相对复杂的部署和 *** 作对于一些客户来说还是很难接受的，尤其是在私有云方面。许多客户习惯了SAN存储带来的性能和安全性，对他们来说，任何时候都不需要超大容量或灵活扩展。相反，大型制造商带来的安全性或继续使用以前在VMware上使用的SAN存储的能力才是最重要的。

考虑到前面的各种存储，NFS和OCFS2的不完善促使我们提供一个可以管理共享存储的存储方案，并且这个方案要满足以下要求:

1.部署速度要够快。ZStack的部署速度一直走在行业前列。我们的标准一直是，对Linux有基本了解的人可以在30分钟内完成部署。这个时间包括部署主存储和镜像仓库的时间。

2.可以扩展到足够大的规模。根据SAN存储的性能，单个集群应该可以接管几十到几百台服务器(因为一般来说，单个SAN存储可以支持的服务器数量是有限的)。

3.性能可以充分发挥SAN存储的性能，IO模式可以发挥SAN存储的缓存性能，我们可以通过调整OCFS2的块大小来优化OCFS2的性能。但是，如果您在分层SAN存储上进行测试，您会发现大数据块大小导致的IO模式的变化。如果测试4k小文件随机写入，性能不稳定，不能在物理机上直接将LUN测试前期的数据全部写入高速磁盘，带来测试数据不理想。

4.高稳定性。与互联网和公有云服务不同，私有云全部部署在客户端机房，甚至是一些隔离保密的机房。这就意味着我们不能像互联网环境一样实行“试错”的策略。我们无法控制用户的升级节奏，无法时刻监控运维存储状态，无法在客户环境下进行灰度测试和镜像验证。

终于在2018年，我们决定自己开发一个SharedBlock存储的存储方式，名字直接叫SharedBlock。整个方案是这样的:

1.基于块设备，虚拟云盘直接基于块设备提供给虚拟机，避免文件系统开销，可以明显提升性能和稳定性；

2.在基于Paxos的块设备上实现分布式锁，以管理块设备的分配、节点的加入、心跳和IO状态检查；

3.通过Qemu接口监控用户的磁盘读写状态；

SharedBlock推出后，已经应用于许多生产客户，特别是因为它可以利用旧的SAN存储特性，将SharedBlock快速部署到大量过去使用虚拟化的客户。

后来随着5G、物联网、云互联的发展，市场迫切需要一种价格低廉、易于部署、软硬件一体化的超融合产品。所以我们在考虑一款双节点一体机产品，通过与硬件厂商的合作设计，可以实现2U一体机包含足够用户使用的硬盘，独立模块，双冗余。我们希望通过该产品，将客户原有的单节点应用平滑升级为双节点备份，让客户运行在铁路车站、制造工厂的“端”应用享受到云的便利，而无需复杂的 *** 作和部署。这是我们的迷你储藏室。

在开发这些存储产品的过程中，我们踩过无数的坑，积累了很多经验。

先说正确做收纳有多难。今年关于这个话题有一个热点事件无法回避，就是今年FOSDEM19'上的PostgreSQL开发者在会上介绍，PostgreSQL开发者发现自己有一个十年的bug——使用fsync()调用——

1.PG使用写回机制，尤其是在过去使用机械硬盘的时代，可以大大提高速度，但是需要定期fsync来保证数据刷到磁盘；

2.PG用单独的线程执行fsync()，期望写错时返回错误；

3.但实际上 *** 作系统可能会将脏页同步到磁盘本身，也可能是其他程序调用fsync()；

4.无论哪种情况，PG自己的同步线程都无法接收到fsync时的错误信息；

这样PG可能会误以为数据已经同步，移动journal的指针。实际上，数据并没有同步到磁盘。如果磁盘没有连续修复，内存数据突然丢失，就会有数据丢失。

在这个环节中，PG开发者吐槽了很多内核开发和存储开发的问题。很多时候PG只是想更好的实现数据库，但是发现经常要担心SAN/NFS存储，还要为内核的无证行为买单。

说到NFS，我不得不多提两个字。在Google上搜索“nfsbug”可以显示五百万条结果，其中不乏Gitlab等知名厂商踩坑，也有Redhat等众多 *** 作系统尝试提供遇到nfs问题的建议:

从云供应商的角度来看，使用NFS的虚拟机存储遇到的问题包括但不限于以下内容:

1.部分客户的存储不支持NFS4.0，带来一系列性能问题和并发问题，4.0之前不支持加锁；

2.nfs服务本身会带来安全漏洞；

3.对于在服务器上做一些 *** 作(如unshare)导致的神秘行为；

4.使用异步挂载可能会带来一些不一致的问题，这在虚拟化中可能会被放大，一个IO栈嵌套在多层的环境，而使用同步挂载会有明显的性能损失；

5.NFS本身的Bugs

我们最后的建议是，在生产环境和大型集群的情况下，最起码应该少用NFS4.0之前的版本...

另一篇著名的文章是14年在OSDI发表的《所有的文件系统都不是生来平等的》。作者测试了几个文件系统和文件应用，在大量系统中发现了很多数据丢失的bug。之后，崩溃一致性验证变得容易了，比如FSE16，发现gmake和atom等软件的各种数据丢失或错误结果:

上面我们已经列举了许多软件和文件系统的例子。这些都是一些单点问题或者局部问题，如果放到云平台的存储系统上，复杂度会更高:

1.首先，私有云面临的是碎片化的环境。我们都知道，Android开发者的适配成本往往高于iOS开发者。这类似于私有云，因为客户拥有:

1)来自不同制造商的设备；

2)不同的多路径软件；

3)不同的服务器硬件和HBA卡；

虽然SCSI指令是通用的，但实际上不同的存储+多路径+HBA可以构成IO错误、路径切换、缓存使用的不同行为，这是最容易出现难以调试的问题。例如，某些具有特定HBA的存储会产生以下IO曲线:

2.既然我们是产品化的私有云，那么产品化就意味着整个系统无法被管理运维，也无法提供常驻运维，这显然会受到客户参差不齐的运维环境和水平的限制:

1)升级条件不同，有些用户希望一旦部署，就再也不升级，不移动。这就要求我们发布的版本必须稳定可靠，因为发出去之后可能就没有机会升级了，这和互联网场景明显不同；

2)组网条件不同。一般来说，来自生产环境的数据和日志是至关重要的，但是对于产品化的厂商来说，这些数据是弥足珍贵的，因为有些客户机房不仅不允许连接外网，就连我们的客户工程师进入机房都不允许携带手机；

3)不同级别的运维。对于一个平台系统来说，如果运维水平不同，可以发挥不同的作用。比如也是硬件故障。对于一个运维水平很高的客户团队来说，可能很快就能确认问题，找到硬件厂商解决。但是，有些客户需要我们帮助定位和分析问题，甚至与硬件制造商谈判，这将消耗大量的精力。

3.存储路径长。对于平台，我们不应该只担心IO路径——设备映射器、多路径、SCSI、HBA等。我们不得不担心虚拟化部分——虚拟驱动程序、虚拟scsi、qcow2……...以及存储控制平面—快照、热迁移、存储迁移、备份...很多存储正确性验证只涉及到选举和IO部分，而我们对存储管理不够重视。根据我们的经验，一旦控制平面出现Bug，造成的损失可能比数据平面更大。

说了这么多困难，来说说怎么解决吧。说到存储的正确性，接触过分布式系统的同学可能会说TLA+。下面给不熟悉TLA+的人简单介绍一下TLA+。

2002年兰波特写了一本书《SpecifyingSystems》，这基本上是TLA+的第一本正式书籍。了解的朋友可能知道，在此之前，Lamport在分布式系统和计算结科学方面很有名——LaTeX、Lamportclock、PAXOS等。TLA+在一开始并没有被特别重视。他的名气来自于15年AWS在ACMJournal上发表的《亚马逊Web服务如何使用形式化方法》。

从本质上讲，形式验证并不新鲜，相关概念从上个世纪就有了。TLA+的优势在于特别适合验证分布式系统的算法设计。因为对于一个可验证的算法来说，核心是确定系统此刻的状态，确定状态变化的条件和结果，这样TLA+就可以通过穷举+剪枝的方式，检查当有并发 *** 作时是否会出现违规(TLA+称之为不变量)——比如账户余额小于0，系统中有多个leader等等。

查看最近的TLA社区会议，您可以看到Elasticserach和MongoDB都有应用程序。

那么这个东西既然这么好，为什么在国内开发界好像不是特别受欢迎呢？我们也尝试了一段时间在内部应用，并在迷你存储上做了一些验证。我们觉得TLA+要想得到更广泛的应用，可能还有几个问题需要优化:

1.状态爆炸，因为TLA+的验证模式决定了要仔细抽象和仔细检查状态的数量，如果盲目增加状态，可能会遇到状态爆炸的问题；

2.TLA+Spec不能直接转换成代码，反过来，代码也不能直接转换成Spec。换句话说，无论是从代码到规范还是从规范到代码，都有可能出错。往轻里说，有bug，往重里说，可能导致你自信的算法，其实和你的实现有本质的不同；

3.外部依赖的正确性，可能有点要求过高，但也是可靠系统的重要组成部分，因为无论产品中是否使用开源组件，无论是qemu还是Linux内核，用户都只会认为是你的问题，我们不太可能去分析验证每一个依赖；

当然，说到证明算法的正确性，形式证明仍然是不可替代的，但不得不说，目前在云平台存储上的应用还没有完全覆盖。当然，我们也看到TLA+在不断进步——

1.可视化；

2.增强可读性；

3.规范的可执行文件；

尤其是这里的第三点，如果我们的Spec可以转换成代码，那么我们就可以把核心代码的算法部分抽象出来，做成一个单独的库，直接使用已经被Spec证明过的代码。

近年来，有一个非常流行的测试和验证分布式系统的术语，就是混沌工程。

混沌工程对于大多数人来说并不是一个新词。可以说是单机应用向集群应用转变、面向系统编程向面向服务编程转变的必然结果。我们看到有多少互联网应用声称借助混沌工程提高了系统的稳定性。基础设施软件呢？

从某种程度上来说，ZStack长期以来一直在用混沌工程的思想测试系统的稳定性。首先，我们有三个关键的外部整体测试:

1.MTBF是硬件设备中常见的概念，指系统正常运行的时间。对于我们来说，会反复 *** 作存储(创建和删除虚拟机，创建和删除快照，写入和删除数据等。)对系统根据用户场景，引入错误检查的正确性；

2.DPMO，这个在测试界很老的概念，偏向于单个 *** 作的重复 *** 作，比如重启物理机1000次，增删镜像10000次等等。在此基础上，考虑同时引入故障来检查函数的正确性；

3.啄木鸟，这是ZStack从一开始就实现的一个测试框架。它的代码和原理是开源的。它会智能组合ZStack的上千个API，自动寻找一条可以持续的路径，并根据资源的当前状态判断哪些API资源可以执行，从而在一天结束时组合执行上万次甚至上百万次。同时考虑引入误差；

以上方法，除了大量调用API和测试IO，重要的是注入错误，比如强制关闭虚拟机和物理机，通过可编程PDU模拟掉电等。，但这些方法都有一些缺陷:

1.复杂场景的模拟能力有限。比如有些客户的存储在IO中并不总是很慢，而是呈现出波峰波谷的波浪形。这种情况与总是有明显延迟的IO截然不同；

2.不够灵活。比如有的客户随机IO存储很差，但是顺序IO性能还可以，不能简单通过降低IO性能来模拟；

总之，大部分混沌工程提供的手段(随机关闭节点，随机杀死进程，通过tc增加延迟，通过iproute2，iptables等改变网络。)无法满足ZStack完全模拟用户场景的要求。

在这种情况下，我们把扩展手段放在几个方向上:

Libfiu，libfiu可以通过LD_PRELOAD控制应用程序调用POSIXAPI的结果，可以使应用程序无法申请内存、打开文件或执行open。

需要的时候用fiurun+fiuctl控制一个应用的系统调用；

Fiu不直接支持libaio注入，但好在fio扩展和编译都极其简单，我们可以根据自己的需求轻松添加模块；

2.systemtap是系统界的经典武器，可以根据需求修改内核函数的返回值。如果你了解清楚内核，systemtap会非常好用。如果是错误注入存储，可以重点搜索scsi相关函数，参考这里:使用systemtap的内核错误注入框架；

3.设备映射器，提供dm-flakey、dm-dust和dm-delay。当然你也可以自己写目标，然后用lio之类的工具模拟一个有故障的共享存储。由于device-mapper的动态加载，我们可以动态修改目标和参数，从而更真实地模拟用户场景中的状态；

4.nbd，nbd的插件机制非常方便，我们可以用这个来修改各个IO的行为，从而实现一些特殊的IO模式。例如，我们已经使用nbd来模拟具有快速顺序写入但异常缓慢的用户随机写入的存储设备；

5.另外还有scsi_debug等调试工具，不过这些比较都是针对具体问题的，我就不细说了；

上面两张图总结了这些错误注入方法。从系统的角度来说，如果能在设计阶段验证算法的正确性，在开发时注意开发可测试的代码，通过海量测试和错误注入完全覆盖路径，通过测试用例治愈遇到的各种IO异常，我们的存储系统会越来越稳定，保持在“正确”的道路上。