跳转到主要内容

分布式存储和一致性模型

当单片系统达到它们的极限时,它们开始被扩展的分布式系统所取代。这一趋势始于20年前的计算领域,当时大型机被服务器群所取代。然后进入了存储领域(数据库、文件系统)。在数据库世界中,关系与NoSQL的争论已经激烈了一段时间。

今天,我想和大家谈谈分布式数据存储平台和一致性模型。在规划存储基础设施时,这是一个非常重要的需求。

让我们从一些基础知识开始。在分布式系统中,假设单个节点会失效。系统必须对节点故障具有弹性。因此,为了冗余,数据必须跨多个节点进行复制。

在这种情况下,让我们问以下问题:“如果我在一个节点上执行写入(或更新)操作,我是否总是能看到所有节点上更新的数据?”

这似乎是一个无关痛痒的问题。每个人都会给出肯定的回答。“咄,当然!”。但不要这么快。

这在分布式系统中实际上是一个很难解决的问题,特别是在保持性能的时候。做出这种保证的系统被称为“严格一致”。然而,许多系统采取了简单的方法,只提供最终的一致性。

最终一致性vs严格一致性

让我们定义最终一致性和严格一致性。

最终一致性

下面的视频演示了最终一致性的过程。

过程总结

  1. 从客户机写到节点1
  2. 从节点1向客户端确认
  3. 最终写入通过集群传播到节点2

观察

  • System finally return latest write:通过添加单词“finally”来削弱一致性条件
  • 如果节点失败可能导致数据丢失:添加“假设没有永久故障”的条件。

严格的一致性

下面的视频演示了严格一致性的过程。

过程总结

  1. 从客户机写到节点1
  2. 写入通过集群传播,从节点1传播到节点2
  3. 从节点2到节点1的内部确认
  4. 从节点1向客户端确认

观察

  • 系统总是返回最新的写操作:对于任何传入的写操作,一旦客户端确认了写操作,从任何节点读取的更新值都是可见的。
  • 有保证的数据弹性:对于任何传入的写操作,一旦向客户端确认了写操作,更新就会受到冗余节点故障的保护。

系统并不总是使用严格的一致性

显然,严格的一致性更好,因为可以保证用户总是看到最新的数据,并且数据在写入时就受到保护。下图比较了两种一致性模型。

Strict vs Eventual Consistency

严格与最终一致性

为什么不总是使用严格的一致性?

主要是因为实现严格的一致性会显著影响性能。具体来说,延迟和吞吐量将会受到影响。影响的程度取决于具体情况。

严格的一致性并不总是必需的,在某些用例中最终的一致性可能就足够了。例如,在购物车中,假设添加了一个项目,但数据中心失败了。对客户来说,再次添加该项目并不是一种灾难。在这种情况下,最终的一致性就足够了。

然而,你不希望你的银行账户刚刚存入的钱发生这种情况。因为节点失败而导致资金消失是不可接受的。财务交易要求严格的一致性。

为什么企业存储需要严格的一致性

在企业存储中,存在最终一致性是正确模型的情况,例如跨站点复制的例子。但在绝大多数情况下,严格的一致性是必需的。让我们看几个需要严格一致性的例子。

扩展文件存储

碰巧有一种主要的扩展文件存储系统只提供最终的一致性。数据只写入一个节点(NVRAM上)并被确认。一个企业客户曾经向我解释说,在负载过重的情况下,一个节点可能会被标记为脱机。实际上,它是关闭的,导致客户端在几秒钟前成功编写的文件出现“文件未找到”错误。这对它们的应用程序造成了严重破坏。

从备份中即时恢复

下一代扩展备份解决方案提供了从备份中即时恢复VM。这样的解决方案从备份系统上的备份映像副本引导虚拟机。备份系统在恢复期间充当主存储,直到可以使用storage vMotion将数据移动回原始数据存储为止。好处很明显:你可以尽快恢复业务。

然而,许多扩展备份解决方案只提供写操作的最终一致性。因此,如果恢复节点上发生故障,应用程序就会失败,系统就会丢失生产VM的实时数据。

数据保护

严格的一致性保证用户总是能看到最新的数据,并且数据一旦写入就受到保护。由于严格的一致性,即使基础设施出现故障,也能保证应用程序可用性/正常运行时间和没有数据丢失。

在设计备份环境时,应当首先考虑向外扩展文件存储和从备份中立即恢复的这些事项。

VM环境中的一致性模型

VMware vSphere和VMware Cloud Foundation等基础架构需要数据弹性和高可用性。对于这样的环境,严格一致性和最终一致性意味着什么?

对于任何使用传统或现代数据保护和恢复解决方案的组织来说,一致性模型都存在风险和问题。不幸的是,人们对这个话题的认识和理解非常缺乏。

供应商提供传统和现代的数据保护和恢复解决方案。它们提供VM或数据的快速恢复,并具有一种称为即时恢复的特性。其目标是最小化停机时间,即恢复时间目标(RTO)。

但是,根据供应商和客户的基础设施的不同,恢复工作流和实现是不同的。

数据保护

可以执行一系列恢复功能(手动或自动)来恢复VMware vSphere等环境。通常,数据保护和恢复解决方案(存储VM或数据的副本)提供某种形式的存储抽象。vSphere将为此提供额外的计算资源。

数据恢复

在恢复VM之后,必须将它迁移回主存储平台。在vSphere中,存储vMotion用于在网络上迁移数据。可以在几分钟内恢复并实例化一个VM。

然而,如果这意味着要在网络中移动数百gb,那么在几分钟内恢复是不可能的。根据在网络中传输的大小和容量不同,这个过程可能需要很长时间才能完成。低时间将取决于网络带宽、接口饱和等。

数据保护和恢复的最终一致性

本视频演示了vMotion使用最终一致性恢复vSphere环境的过程。

过程总结

  1. 准备VM并将其作为NFS卷在本地存储抽象上恢复。在最终一致性模型的基础上,从单个节点对vSphere进行了抽象。
  2. 从数据保护和恢复集群中的一个节点挂载NFS存储抽象。VM在vSphere上被实例化和访问。读和写I/O被定向到存储在单个节点的存储抽象(NFS)上的VM。
  3. 此时正在创建的新数据不受保护。它不分布在数据保护和恢复集群中的其他节点上。
  4. SvMotion开始将VM迁移回主存储平台。这可能需要很长时间,具体取决于环境。
  5. 如果数据保护和恢复集群中的某个节点在恢复到vSphere时发生故障,将会发生以下情况:
  • vSphere无法访问存储抽象(NFS)
  • VM不再可用或不可访问
  • SvMotion失败
  • 任何新创建的数据都可能丢失

当您依赖数据保护和恢复解决方案作为保险策略时,这是不可接受的结果。其结果——取决于失败的程度——可能会让一家公司倒闭,或者至少会让某些人丢掉工作。

数据保护和恢复严格一致

本视频演示了使用vMotion使用严格的一致性恢复vSphere环境的过程。

以下步骤是企业应该期待的。这是他们应该从数据保护和恢复解决方案中要求的。

  1. 在本地准备VM并将其恢复到一个存储抽象上,该存储抽象以NFS卷的形式呈现给vSphere。在严格一致性模型的基础上给出了该抽象。
  2. 自动将存储抽象从一个来自Cohesity集群的虚拟IP呈现并挂载到vSphere (NFS)。VM在vSphere上被实例化和访问。读和写I/O被定向到存储在存储抽象(NFS)上的VM, NFS来自Cohesity集群的虚拟IP。
  3. 创建的新数据被分发到Cohesity集群中的其他节点并得到确认。
  4. SvMotion启动VM迁移回主存储平台——这可能需要很长时间。
  5. 如果Cohesity集群中的一个节点发生故障,提供给vSphere的存储抽象(NFS)仍然可用。由于使用了虚拟ip和严格的一致性,SvMotion将持续到完成为止,这共同降低了数据丢失的风险。

上面描述的步骤产生了企业希望利用即时恢复等特性时,从数据保护和恢复解决方案中得到的预期结果和需求。

本视频总结了上面的信息,并演示了严格问题与最终一致性的对比。它将带您一步一步地经历两个场景。第一个示例是关于Oracle RMAN备份的,下一个示例是执行VMware的即时恢复。

 

原文:https://www.cohesity.com/blogs/strict-vs-eventual-consistency/

本文:http://jiagoushi.pro/node/1386

讨论:请加入知识星球【首席架构师圈】或者小号【jiagoushi_pro】或者QQ群【11107777】

Tags
 
知识星球
 
微信公众号
 
视频号