Skip to main content
本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

一致性

貢獻者 netapp-lhalbert
PDF

一致性可在物件的可用度與這些物件在不同儲存節點和站台之間的一致性之間取得平衡。您可以根據應用程式的需求變更一致性。

預設情況下， StorageGRID保證新建立物件的讀寫一致性。成功完成 PUT 之後的任何 GET 都將能夠讀取新寫入的資料。現有物件的覆蓋、元資料更新和刪除最終​​是一致的。

如果您想要以不同的一致性執行物件作業、您可以：

  • 指定一致性每個貯體。

  • 指定的一致性每項 API 作業。

  • 執行下列其中一項工作、變更預設的全網格一致性：

    • 在網格管理員中，前往*配置* > 系統 > 儲存設定 > 預設儲存桶一致性。

    • 。

      註 對全網格一致性所做的變更僅適用於變更設定後所建立的貯體。若要判斷變更的詳細資料、請參閱位於的稽核記錄 /var/local/log（搜尋 * 一致性層級 * ）。

一致性值

一致性會影響StorageGRID用於追蹤物件的元資料在節點之間的分佈方式。一致性影響物件對於客戶端請求的可用性。

您可以將貯體或 API 作業的一致性設定為下列其中一個值：

  • * 全部 * ：所有節點都會立即接收物件中繼資料、否則要求將會失敗。

  • 強全域：保證所有網站上所有客戶端請求的讀寫一致性。配置 Quorum 語意時，將套用下列行為：

    • 當網格具有三個或更多站點時，允許對客戶端請求進行站點故障容忍。雙站點電網不具備站點故障容忍能力。

    • 如果一個站點發生故障，以下 S3 操作將無法成功：

      • 刪除 BucketEncryption

      • PutBucketBranch

      • PuttBucketEncryption

      • PuttBucketVersion

      • PutObjectLegalHold

      • PutObjectLockConfiguration

      • PutObjectRetention

    如果需要的話，你可以 "配置StorageGRID Quorum 語意以實現強全域一致性"。

  • Strong-site ：物件中繼資料會立即散佈到站台上的其他節點。保證站台內所有用戶端要求的寫入後讀取一致性。

  • * 新寫入後讀 * ：提供新物件的寫入後讀取一致性、以及物件更新的最終一致性。提供高可用度與資料保護保證。建議大多數情況下使用。

  • * 可用 * ：提供新物件和物件更新的最終一致性。對於 S3 貯體、請僅視需要使用（例如、包含很少讀取的記錄值之貯體、或用於對不存在的金鑰執行 head 或 Get 作業）。S3 FabricPool 儲存區不支援。

使用「讀取後新寫入」和「可用」一致性

當標頭或 GET 作業使用「讀取後新寫入」一致性時、 StorageGRID 會以多個步驟執行查詢、如下所示：

  • 它會先使用低一致性來查詢物件。

  • 如果該查詢失敗、它會在下一個一致性值重複查詢、直到達到等同於 Strong-global 行為的一致性為止。

如果 HEAD 或 GET 作業使用「讀取後新寫入」一致性、但物件不存在、則物件查詢一律會達到等同於 Strong-global 行為的一致性。由於這種一致性需要在每個站台上提供多個物件中繼資料複本、因此如果同一個站台上有兩個或多個儲存節點無法使用、您可能會收到大量 500 個內部伺服器錯誤。

除非您需要與 Amazon S3 類似的一致性保證、否則您可以將一致性設定為「可用」、以防止這些錯誤發生在 HEAD 和 GET 作業中。當前端或 GET 作業使用「可用」一致性時、 StorageGRID 僅提供最終一致性。它不會在增加一致性時重試失敗的作業、因此不需要物件中繼資料的多個複本。

[[API- 作業 - 一致性控制 ] ] 指定 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 "實現庫位一致性"要求。或者、您也可以"改變貯體的一致性"從租戶管理程式中執行。

設定貯體的一致性時、請注意下列事項：

  • 設定貯體的一致性、可決定用於在貯體或貯體組態中的物件上執行 S3 作業的一致性。它不會影響儲存庫本身的作業。

  • 個別 API 作業的一致性會覆寫貯體的一致性。

  • 一般而言、貯體應使用預設的一致性「讀取後新寫入」。如果要求無法正常運作、請盡可能變更應用程式用戶端行為。或者、設定用戶端以指定每個 API 要求的一致性。將貯體層級的一致性設為最後的方法。

一致性和 ILM 規則如何相互作用以影響資料保護

您選擇的一致性和 ILM 規則都會影響物件的保護方式。這些設定可以互動。

例如、儲存物件時所使用的一致性會影響物件中繼資料的初始放置位置、而為 ILM 規則選取的擷取行為則會影響物件複本的初始放置位置。由於 StorageGRID 需要同時存取物件的中繼資料及其資料、才能滿足用戶端要求、因此針對一致性和擷取行為選擇符合的保護層級、可以提供更好的初始資料保護、以及更可預測的系統回應。

ILM 規則適用下列"擷取選項"項目：

雙重承諾

StorageGRID 會立即製作物件的臨時複本、並將成功傳回給用戶端。在ILM規則中指定的複本會盡可能製作。

嚴格

在 ILM 規則中指定的所有複本都必須在成功傳回用戶端之前製作。

平衡

StorageGRID 會嘗試在擷取時製作 ILM 規則中指定的所有複本；如果不可能、則會製作過渡複本、並將成功傳回用戶端。ILM規則中指定的複本會盡可能製作。

一致性與 ILM 規則如何互動的範例

假設您有一個三站點網格，具有以下 ILM 規則和以下一致性：

  • ILM 規則：建立三個物件副本，一個在本機站點，另一個在每個遠端站點。使用嚴格的攝取行為。

  • 一致性：強全域（物件元資料立即分發到多個站點）。

當客戶端將物件儲存到網格時， StorageGRID會複製所有三個物件並將元資料分發到多個站點，然後再將成功返回給客戶端。

在接收成功訊息時，物件將受到完全保護，不會遺失。例如，如果本機站點在攝取後不久遺失，則物件資料和物件元資料的副本仍然存在於遠端站點。該物件可以從其他站點完全檢索。

如果您使用相同的 ILM 規則和強站點一致性，則用戶端可能會在物件資料複製到遠端站點之後但在物件元資料分發到那裡之前收到成功訊息。在這種情況下，物件元資料的保護等級與物件資料的保護等級不符。如果本地站點在攝取後不久遺失，則物件元資料就會遺失。無法檢索該物件。

一致性與 ILM 規則之間的相互關係可能很複雜。如需協助、請聯絡 NetApp 。