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 。