Skip to main content
此產品有較新版本可以使用。
本繁體中文版使用機器翻譯,譯文僅供參考,若與英文版本牴觸,應以英文版本為準。

StorageGRID S3 REST API 如何平衡可用性和一致性

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

預設情況下,StorageGRID 保證新建立物件的寫入後讀取一致性。任何在 PUT 操作成功完成後執行的 GET 操作都可以讀取新寫入的資料。對現有物件的覆寫、中繼資料更新和刪除操作則最終一致。

如果要以不同的一致性執行物件操作,可以:

  • 指定 每個儲存桶 的一致性。

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

  • 若要變更預設的網格級一致性,請執行下列操作之一:

    • 在 Grid Manager 中,前往 Configuration > System > Storage settings > Default bucket consistency

    • 註 對網格整體一致性的變更僅適用於變更設定後所建立的儲存桶。若要了解變更的詳細資訊,請參閱位於 `/var/local/log`的稽核日誌(搜尋 consistencyLevel)。

一致性值

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

您可以將儲存桶或 API 作業的一致性設定為下列值之一:

  • 全部:所有節點立即接收物件中繼資料,否則要求將失敗。

  • Strong-global:保證所有站台上所有用戶端請求的寫入後讀取一致性。設定 Quorum 語意後,將套用以下行為:

    • 當網格具有三個或更多站台時,允許用戶端要求具有站台故障容許度。雙站台網格將不具備站台故障容許度。

    • 如果其中一個站台停機,以下 S3 作業將無法成功:

      • DeleteBucketEncryption

      • PutBucketBranch

      • PutBucketEncryption

      • PutBucketVersioning

      • PutObjectLegalHold

      • PutObjectLockConfiguration

      • PutObjectRetention

    如果需要,您可以 "${post_edited_translations.segment}"

  • Strong-site:物件中繼資料會立即分發至站台內的其他節點。保證站台內所有用戶端請求的寫後讀一致性。

  • Read-after-new-write:為新物件提供寫入後讀取一致性,並為物件更新提供最終一致性。提供高可用度和資料保護保證。建議在大多數情況下使用。

  • Available:為新物件和物件更新提供最終一致性。對於 S3 儲存貯體,請僅在需要時使用(例如,對於包含極少讀取之記錄值的儲存貯體,或針對不存在的金鑰進行 HEAD 或 GET 作業)。不支援 S3 FabricPool 儲存貯體。

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

當 HEAD 或 GET 操作使用「新寫後讀取」一致性時,StorageGRID 會分多個步驟執行查詢,如下所示:

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

  • 如果查詢失敗,則會在下一個一致性值處重複查詢,直到達到與 strong-global 的行為等效的一致性。

如果 HEAD 或 GET 操作使用「新寫後讀取」一致性,但物件不存在,則物件查找將一律達到與 strong-global 行為相同的一致性。由於此一致性要求每個站台都必須有物件中繼資料的多個複本,因此如果同一站台上有兩個或多個儲存節點無法使用,您可能會收到大量 500 Internal Server 錯誤。

除非您需要類似 Amazon S3 的一致性保證,否則可以透過將一致性設為「Available」來避免 HEAD 和 GET 操作出現這些錯誤。當 HEAD 或 GET 操作使用「Available」一致性時,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 操作,必須使用相同的一致性。

指定儲存桶的一致性

若要設定儲存桶的一致性,可以使用 StorageGRID "PUT Bucket 一致性" 請求。或者,也可以"變更儲存桶的一致性"從 Tenant Manager 進行設定。

設定儲存桶的一致性時,請注意以下事項:

  • 設定儲存桶的一致性,可決定對儲存桶中的物件或儲存桶組態執行的 S3 操作所使用的一致性。此設定不會影響對儲存桶本身的操作。

  • 單一 API 操作的一致性會置換儲存桶的一致性。

  • 通常情況下,儲存桶應使用預設的一致性原則「新寫入後讀取」。如果請求無法正常運作,請盡可能變更應用程式用戶端的行為。或者,設定用戶端為每個 API 請求指定一致性原則。只有在萬不得已的情況下才在儲存桶層級設定一致性原則。

一致性與 ILM 規則如何互動以影響資料保護

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

例如,物件儲存時採用的一致性策略會影響物件中繼資料的初始位置,而為 ILM 規則選擇的擷取行為則會影響物件副本的初始位置。由於 StorageGRID 需要存取物件的中繼資料和資料才能滿足用戶端請求,因此為一致性策略和擷取行為選擇相符的保護層級可以提供更好的初始資料保護和更可預測的系統回應。

以下"擷取選項"適用於 ILM 規則:

雙重承諾

StorageGRID 會立即建立物件的臨時副本,並向用戶端傳回成功。ILM 規則中指定的副本會在可能的情況下建立。

嚴格

在向用戶端返回成功之前,必須完成 ILM 規則中指定的所有副本。

均衡

StorageGRID 會在擷取時嘗試建立 ILM 規則中指定的所有副本;如果無法全部建立,則會建立臨時副本並向用戶端傳回成功資訊。ILM 規則中指定的副本會在條件允許的情況下建立。

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

假設您有一個三站台網格,具有以下 ILM 規則和以下一致性:

  • ILM 規則:建立三個物件複本,一個在本機站台,每個遠端站台各一個。使用 Strict 擷取行為。

  • 一致性:強全域性(物件中繼資料立即分發至多個站台)。

當用戶端將物件儲存到網格時,StorageGRID 會建立所有三個物件複本,並將中繼資料分發到多個站台,然後向用戶端傳回成功。

在收到擷取成功訊息時,該物件已受到完整保護,可防止遺失。例如,如果本機站台在擷取後不久發生故障,物件資料和物件中繼資料的複本仍會存在於遠端站台。您可以從其他站台完整擷取該物件。

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

一致性與 ILM 規則之間的相互關係可能非常複雜。如果您需要協助,請聯絡 NetApp。