Skip to main content
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

一致性值

PDF

一致性在对象的可用性和不同存储节点和站点之间的对象的一致性之间提供了平衡。您可以根据应用程序的需要更改一致性。

默认情况下， StorageGRID保证新创建对象的读写一致性。成功完成 PUT 之后的任何 GET 都将能够读取新写入的数据。现有对象的覆盖、元数据更新和删除最终是一致的。覆盖通常需要几秒或几分钟才能传播，但最多可能需要 15 天。

如果要以不同的一致性执行对象操作，您可以：

  • 指定一致性每个桶。

  • 指定一致性每个 API 操作。

  • 通过执行以下任务之一来更改默认的网格范围一致性：

    • 在网格管理器中，转到*配置* > 系统 > 存储设置 > 默认一致性。

    • 。

      备注 对网格范围一致性的更改仅适用于更改设置后创建的存储桶。要确定更改的详细信息，请参阅位于 /var/local/log（搜索*consistencyLevel*）。

一致性值

一致性会影响StorageGRID用于跟踪对象的元数据在节点之间的分布方式，从而影响对象对于客户端请求的可用性。

您可以将存储桶或 API 操作的一致性设置为以下值之一：

  • 全部：所有节点立即接收数据，否则请求失败。

  • 强全局：保证所有站点上所有客户端请求的读写一致性。

  • 强站点：保证站点内所有客户端请求的读写一致性。

  • Read-after-new-write：（默认）为新对象提供读后写一致性，并为对象更新提供最终一致性。提供高可用性和数据保护保证。在大多数情况下推荐使用。

  • 可用：为新对象和对象更新提供最终一致性。对于 S3 存储桶，仅在需要时使用（例如，对于包含很少读取的日志值的存储桶，或者对于不存在的键的 HEAD 或 GET 操作）。不支持 S3 FabricPool存储桶。

使用“新写后读”和“可用”一致性

当 HEAD 或 GET 操作使用“新写后读取”一致性时， StorageGRID会分多个步骤执行查找，如下所示：

  • 它首先使用低一致性来查找对象。

  • 如果查找失败，它会在下一个一致性值处重复查找，直到达到与强全局行为相当的一致性。

如果 HEAD 或 GET 操作使用“Read-after-new-write”一致性但对象不存在，则对象查找将始终达到与强全局行为等效的一致性。由于这种一致性要求每个站点都有对象元数据的多个副本，因此如果同一站点上有两个或多个存储节点不可用，您可能会收到大量 500 内部服务器错误。

除非您需要类似于 Amazon S3 的一致性保证，否则您可以通过将一致性设置为“可用”来防止 HEAD 和 GET 操作出现这些错误。当 HEAD 或 GET 操作使用“可用”一致性时， StorageGRID仅提供最终一致性。它不会在增加一致性时重试失败的操作，因此它不需要提供对象元数据的多个副本。

指定 API 操作的一致性

要为单个 API 操作设置一致性，该操作必须支持一致性值，并且必须在请求标头中指定一致性。此示例将 GetObject 操作的一致性设置为“Strong-site”。

GET /bucket/object HTTP/1.1
Date: date
Authorization: authorization name
Host: host
Consistency-Control: strong-site
备注 您必须对 PutObject 和 GetObject 操作使用相同的一致性。

指定 bucket 的一致性

要设置存储桶的一致性，您可以使用StorageGRID"PUT桶一致性"要求。或者你可以"改变桶的一致性"来自租户经理。

设置存储桶的一致性时，请注意以下事项：

  • 设置存储桶的一致性决定了对存储桶中的对象或存储桶配置执行的 S3 操作使用哪种一致性。它不会影响存储桶本身的操作。

  • 单个 API 操作的一致性会覆盖存储桶的一致性。

  • 一般来说，存储桶应该使用默认一致性“新写后读取”。如果请求无法正常工作，请尽可能更改应用程序客户端行为。或者，配置客户端以指定每个 API 请求的一致性。仅在万不得已的情况下才在存储桶级别设置一致性。

一致性控制和 ILM 规则如何相互作用以影响数据保护

您的一致性选择和 ILM 规则都会影响对象的保护方式。这些设置可以相互作用。

例如，存储对象时使用的一致性会影响对象元数据的初始位置，而为 ILM 规则选择的摄取行为会影响对象副本的初始位置。由于StorageGRID需要访问对象的元数据及其数据来满足客户端请求，因此为一致性和摄取行为选择匹配的保护级别可以提供更好的初始数据保护和更可预测的系统响应。

下列"摄取选项"适用于 ILM 规则：

双提交

StorageGRID立即制作对象的临时副本并将成功返回给客户端。在可能的情况下，将制作 ILM 规则中指定的副本。

严格

在向客户端返回成功之前，必须完成 ILM 规则中指定的所有复制。

平衡

StorageGRID尝试在摄取时制作 ILM 规则中指定的所有副本；如果无法做到这一点，则会制作临时副本并将成功返回给客户端。在可能的情况下，将进行 ILM 规则中指定的复制。

一致性和 ILM 规则如何交互的示例

假设您有一个双站点网格，具有以下 ILM 规则和以下一致性：

  • ILM 规则：创建两个对象副本，一个在本地站点，一个在远程站点。使用严格的摄取行为。

  • 一致性：强全局（对象元数据立即分发到所有站点）。

当客户端将对象存储到网格时， StorageGRID会复制两个对象并将元数据分发到两个站点，然后再将成功返回给客户端。

在接收成功消息时，对象将受到完全保护，不会丢失。例如，如果本地站点在摄取后不久丢失，对象数据和对象元数据的副本仍然存在于远程站点。该对象完全可检索。

如果您使用相同的 ILM 规则和强站点一致性，则客户端可能会在对象数据复制到远程站点之后但在对象元数据分发到那里之前收到成功消息。在这种情况下，对象元数据的保护级别与对象数据的保护级别不匹配。如果本地站点在摄取后不久丢失，对象元数据就会丢失。无法检索该对象。

一致性和 ILM 规则之间的相互关系可能很复杂。如果您需要帮助，请联系NetApp 。