分布式存储和一致性模型
当单片系统达到它们的极限时，它们开始被扩展的分布式系统所取代。这一趋势始于20年前的计算领域，当时大型机被服务器群所取代。然后进入了存储领域(数据库、文件系统)。在数据库世界中，关系与NoSQL的争论已经激烈了一段时间。
今天，我想和大家谈谈分布式数据存储平台和一致性模型。在规划存储基础设施时，这是一个非常重要的需求。
让我们从一些基础知识开始。在分布式系统中，假设单个节点会失效。系统必须对节点故障具有弹性。因此，为了冗余，数据必须跨多个节点进行复制。
在这种情况下，让我们问以下问题:“如果我在一个节点上执行写入(或更新)操作，我是否总是能看到所有节点上更新的数据?”
这似乎是一个无关痛痒的问题。每个人都会给出肯定的回答。“咄,当然!”。但不要这么快。
这在分布式系统中实际上是一个很难解决的问题，特别是在保持性能的时候。做出这种保证的系统被称为“严格一致”。然而，许多系统采取了简单的方法，只提供最终的一致性。
最终一致性vs严格一致性
让我们定义最终一致性和严格一致性。
最终一致性
下面的视频演示了最终一致性的过程。
过程总结
- 从客户机写到节点1
- 从节点1向客户端确认
- 最终写入通过集群传播到节点2
观察
- System finally return latest write:通过添加单词“finally”来削弱一致性条件
- 如果节点失败可能导致数据丢失:添加“假设没有永久故障”的条件。
严格的一致性
下面的视频演示了严格一致性的过程。
过程总结
- 从客户机写到节点1
- 写入通过集群传播，从节点1传播到节点2
- 从节点2到节点1的内部确认
- 从节点1向客户端确认
观察
- 系统总是返回最新的写操作:对于任何传入的写操作，一旦客户端确认了写操作，从任何节点读取的更新值都是可见的。
- 有保证的数据弹性:对于任何传入的写操作，一旦向客户端确认了写操作，更新就会受到冗余节点故障的保护。
系统并不总是使用严格的一致性
显然，严格的一致性更好，因为可以保证用户总是看到最新的数据，并且数据在写入时就受到保护。下图比较了两种一致性模型。
严格与最终一致性
为什么不总是使用严格的一致性?
主要是因为实现严格的一致性会显著影响性能。具体来说，延迟和吞吐量将会受到影响。影响的程度取决于具体情况。
严格的一致性并不总是必需的，在某些用例中最终的一致性可能就足够了。例如，在购物车中，假设添加了一个项目，但数据中心失败了。对客户来说，再次添加该项目并不是一种灾难。在这种情况下，最终的一致性就足够了。
然而，你不希望你的银行账户刚刚存入的钱发生这种情况。因为节点失败而导致资金消失是不可接受的。财务交易要求严格的一致性。
为什么企业存储需要严格的一致性
在企业存储中，存在最终一致性是正确模型的情况，例如跨站点复制的例子。但在绝大多数情况下，严格的一致性是必需的。让我们看几个需要严格一致性的例子。
扩展文件存储
碰巧有一种主要的扩展文件存储系统只提供最终的一致性。数据只写入一个节点(NVRAM上)并被确认。一个企业客户曾经向我解释说，在负载过重的情况下，一个节点可能会被标记为脱机。实际上，它是关闭的，导致客户端在几秒钟前成功编写的文件出现“文件未找到”错误。这对它们的应用程序造成了严重破坏。
从备份中即时恢复
下一代扩展备份解决方案提供了从备份中即时恢复VM。这样的解决方案从备份系统上的备份映像副本引导虚拟机。备份系统在恢复期间充当主存储，直到可以使用storage vMotion将数据移动回原始数据存储为止。好处很明显:你可以尽快恢复业务。
然而，许多扩展备份解决方案只提供写操作的最终一致性。因此，如果恢复节点上发生故障，应用程序就会失败，系统就会丢失生产VM的实时数据。
数据保护
严格的一致性保证用户总是能看到最新的数据，并且数据一旦写入就受到保护。由于严格的一致性，即使基础设施出现故障，也能保证应用程序可用性/正常运行时间和没有数据丢失。
在设计备份环境时，应当首先考虑向外扩展文件存储和从备份中立即恢复的这些事项。
VM环境中的一致性模型
VMware vSphere和VMware Cloud Foundation等基础架构需要数据弹性和高可用性。对于这样的环境，严格一致性和最终一致性意味着什么?
对于任何使用传统或现代数据保护和恢复解决方案的组织来说，一致性模型都存在风险和问题。不幸的是，人们对这个话题的认识和理解非常缺乏。
供应商提供传统和现代的数据保护和恢复解决方案。它们提供VM或数据的快速恢复，并具有一种称为即时恢复的特性。其目标是最小化停机时间，即恢复时间目标(RTO)。
但是，根据供应商和客户的基础设施的不同，恢复工作流和实现是不同的。
数据保护
可以执行一系列恢复功能(手动或自动)来恢复VMware vSphere等环境。通常，数据保护和恢复解决方案(存储VM或数据的副本)提供某种形式的存储抽象。vSphere将为此提供额外的计算资源。
数据恢复
在恢复VM之后，必须将它迁移回主存储平台。在vSphere中，存储vMotion用于在网络上迁移数据。可以在几分钟内恢复并实例化一个VM。
然而，如果这意味着要在网络中移动数百gb，那么在几分钟内恢复是不可能的。根据在网络中传输的大小和容量不同，这个过程可能需要很长时间才能完成。低时间将取决于网络带宽、接口饱和等。
数据保护和恢复的最终一致性
本视频演示了vMotion使用最终一致性恢复vSphere环境的过程。
过程总结
- 准备VM并将其作为NFS卷在本地存储抽象上恢复。在最终一致性模型的基础上，从单个节点对vSphere进行了抽象。
- 从数据保护和恢复集群中的一个节点挂载NFS存储抽象。VM在vSphere上被实例化和访问。读和写I/O被定向到存储在单个节点的存储抽象(NFS)上的VM。
- 此时正在创建的新数据不受保护。它不分布在数据保护和恢复集群中的其他节点上。
- SvMotion开始将VM迁移回主存储平台。这可能需要很长时间，具体取决于环境。
- 如果数据保护和恢复集群中的某个节点在恢复到vSphere时发生故障，将会发生以下情况:
- vSphere无法访问存储抽象(NFS)
- VM不再可用或不可访问
- SvMotion失败
- 任何新创建的数据都可能丢失
当您依赖数据保护和恢复解决方案作为保险策略时，这是不可接受的结果。其结果——取决于失败的程度——可能会让一家公司倒闭，或者至少会让某些人丢掉工作。
数据保护和恢复严格一致
本视频演示了使用vMotion使用严格的一致性恢复vSphere环境的过程。
以下步骤是企业应该期待的。这是他们应该从数据保护和恢复解决方案中要求的。
- 在本地准备VM并将其恢复到一个存储抽象上，该存储抽象以NFS卷的形式呈现给vSphere。在严格一致性模型的基础上给出了该抽象。
- 自动将存储抽象从一个来自Cohesity集群的虚拟IP呈现并挂载到vSphere (NFS)。VM在vSphere上被实例化和访问。读和写I/O被定向到存储在存储抽象(NFS)上的VM, NFS来自Cohesity集群的虚拟IP。
- 创建的新数据被分发到Cohesity集群中的其他节点并得到确认。
- SvMotion启动VM迁移回主存储平台——这可能需要很长时间。
- 如果Cohesity集群中的一个节点发生故障，提供给vSphere的存储抽象(NFS)仍然可用。由于使用了虚拟ip和严格的一致性，SvMotion将持续到完成为止，这共同降低了数据丢失的风险。
上面描述的步骤产生了企业希望利用即时恢复等特性时，从数据保护和恢复解决方案中得到的预期结果和需求。
本视频总结了上面的信息，并演示了严格问题与最终一致性的对比。它将带您一步一步地经历两个场景。第一个示例是关于Oracle RMAN备份的，下一个示例是执行VMware的即时恢复。
