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

一致性值

貢獻者
PDF

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

根據預設StorageGRID 、此功能可確保新建立物件的寫入後讀取一致性。任何「Get」追蹤成功完成的「PUT」、都能讀取新寫入的資料。覆寫現有物件、更新中繼資料及刪除的動作最終一致。覆寫通常需要幾秒鐘或幾分鐘才能傳播、但可能需要15天的時間。

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

  • 指定的一致性每個貯體。

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

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

    • 在 Grid Manager 中、前往 * 組態 * > * 系統 * > * 儲存設定 * > * 預設一致性 * 。

    • 。

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

一致性值

一致性會影響 StorageGRID 用來追蹤物件的中繼資料如何在節點之間散佈、進而影響用戶端要求的物件可用度。

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

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

  • Strong-globall ：保證所有網站上所有用戶端要求的寫入後讀取一致性。

  • 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 作業必須使用相同的一致性。

指定貯體的一致性

若要設定貯體的一致性、您可以使用 StorageGRID "實現庫位一致性"要求。或者、您也可以"改變貯體的一致性"從租戶管理程式中執行。

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

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

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

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

[[how － consistency － controls － and － ILM － rules － arize] 一致性和 ILM 規則如何交互以影響數據保護

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

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

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

雙重承諾

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

嚴格

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

平衡

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

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

假設您有一個雙站台網格、其中包含下列 ILM 規則及下列一致性：

  • * ILM規則*：建立兩個物件複本、一個在本機站台、一個在遠端站台。使用嚴格的擷取行為。

  • * 一致性 * ：強式全域（物件中繼資料會立即發佈至所有站台）。

當用戶端將物件儲存到網格時、StorageGRID 在成功傳回用戶端之前、功能區會同時複製物件並將中繼資料散佈到兩個站台。

在擷取最成功的訊息時、物件會受到完整保護、不會遺失。例如、如果在擷取後不久即遺失本機站台、則物件資料和物件中繼資料的複本仍存在於遠端站台。物件可完全擷取。

如果您改用相同的 ILM 規則和強大的站台一致性、則在物件資料複寫到遠端站台、但在物件中繼資料散佈到該站台之前、用戶端可能會收到成功訊息。在此情況下、物件中繼資料的保護層級與物件資料的保護層級不符。如果在擷取後不久本機站台便會遺失、則物件中繼資料將會遺失。無法擷取物件。

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