Skip to content

Latest commit

 

History

History
129 lines (65 loc) · 6.97 KB

concept_data_tiering.adoc

File metadata and controls

129 lines (65 loc) · 6.97 KB
sidebar permalink keywords summary
sidebar
concept_data_tiering.html
storage tiering, tier, tiering, data tiering, s3, s3 tiering, capacity, performance, s3 endpoint, fabric pool, fabricpool, s3 bucket, requirement, vpc endpoint, policy, policies, tiering policies, auto, snapshot only, backup, none, cooling period, volume tiering policies, blob, standard, infrequent access, hot, cool, tiering level, storage tier, storage class
您可以將冷資料自動分層至低成本的物件儲存設備、藉此降低儲存成本。

資料分層總覽

您可以將非作用中資料自動分層至低成本的物件儲存設備、藉此降低儲存成本。作用中資料會保留在高效能SSD或HDD(效能層)中、而非作用中資料則會分層至低成本物件儲存設備(容量層)。如此一來、您就能回收主儲存設備上的空間、並縮減二線儲存設備。

支援AWS和Microsoft Azure中的資料分層。Cloud Volumes ONTAP資料分層是 FabricPool 以不同步技術為後盾。

Note
您不需要安裝功能授權、即可啟用資料分層。

資料分層在AWS中的運作方式

當您在AWS中啟用資料分層功能時、Cloud Volumes ONTAP VMware會使用EBS做為熱資料的效能層、而AWS S3則是非作用中資料的容量層:

這是一個概念性映像、顯示要傳輸到 EBS 儲存設備的熱資料、以及要傳輸到 S3 儲存設備的非作用中資料。

AWS的效能層級

效能層可以是通用 SSD 、已配置的 IOPS SSD 或最佳化處理量的 HDD 。

AWS中的容量層

根據預設Cloud Volumes ONTAP 、將非作用中資料分層至S3 _Standard_儲存類別。Standard 適用於儲存在多個可用度區域中的常用資料。

如果您不打算存取非作用中資料、則可在部署Cloud Volumes ONTAP 完下列項目後、將系統分層層級變更為下列其中一項、藉此降低儲存成本:

智慧分層

隨著資料存取模式改變、在兩層之間移動資料、以最佳化儲存成本。其中一層用於頻繁存取、另一層用於不頻繁存取。

單一區域不常用存取

適用於儲存在單一可用度區域中的不常存取資料。

標準非常用存取

適用於儲存在多個可用度區域中的不常存取資料。

如果您確實存取資料、存取成本就會較高、因此在變更分層層級之前、您必須先將此納入考量。如需S3儲存類別的詳細資料、請參閱 "AWS文件"

當您變更分層層級時、非作用中的資料會從Standard儲存類別開始、並移至您選取的儲存類別、如果資料在30天後仍未存取。如需變更分層層級的詳細資訊、請參閱 "將非作用中資料分層至低成本物件儲存設備"

分層層級是全系統層級、並非每個Volume。

Note
這個運作環境使用S3儲存區來處理系統中的所有階層式資料。Cloud Volumes ONTAP並非每個磁碟區都使用不同的S3儲存區。這包括HA工作環境。Cloud Manager會建立S3儲存區、並將其命名為「網路資源池」、也就是叢集唯一識別碼_。

資料分層在Microsoft Azure中的運作方式

當您在Azure中啟用資料分層功能時Cloud Volumes ONTAP 、VMware會使用Azure託管磁碟做為熱資料的效能層、而Azure Blob儲存設備則是非作用中資料的容量層:

這是概念性映像、顯示要傳輸至Azure託管磁碟的熱資料、以及要傳輸至Azure Blob儲存設備的非作用中資料。

Azure的效能等級

效能層可以是優質儲存設備(SSD)或標準儲存設備(HDD)。

Azure中的容量層級

根據預設Cloud Volumes ONTAP 、將非作用中資料分層至Azure _hot_儲存層、這是經常存取資料的理想選擇。

如果您不打算存取非作用中資料、則可在部署Cloud Volumes ONTAP 完整套功能後、將系統的分層層級變更為Azure _cle__儲存層、藉此降低儲存成本。冷卻層最適合存放在該層至少30天內不常存取的資料。

如果您確實存取資料、存取成本就會較高、因此在變更分層層級之前、您必須先將此納入考量。如需Azure Blob儲存層的詳細資料、請參閱 "Azure文件"

當您變更分層層級時、非作用中的資料會從熱儲存層開始、並移至冷卻儲存層(如果30天後仍未存取資料)。如需變更分層層級的詳細資訊、請參閱 "將非作用中資料分層至低成本物件儲存設備"

分層層級是全系統層級、並非每個Volume。

Note
執行此作業的環境使用Azure Blob容器來處理系統中的所有階層式資料。Cloud Volumes ONTAP並非每個Volume都使用不同的容器。Cloud Manager會建立一個新的儲存帳戶、並為每Cloud Volumes ONTAP 個系統建立一個容器。儲存帳戶名稱為隨機。

資料分層如何影響容量限制

如果您啟用資料分層、系統的容量限制會維持不變。此限制分佈於效能層和容量層。

Volume 分層原則

若要啟用資料分層、您必須在建立、修改或複寫磁碟區時、選取磁碟區分層原則。您可以為每個 Volume 選取不同的原則。

有些分層原則具有相關的最低冷卻週期、可設定磁碟區中的使用者資料必須保持非作用中狀態的時間、以便將資料視為「冷」並移至容量層。

支援下列分層原則:Cloud Volumes ONTAP

僅適用於 Snapshot

當 Aggregate 達到 50% 容量後、 Cloud Volumes ONTAP 將不會與作用中檔案系統相關聯的 Snapshot 複本的 Cold 使用者資料分層至容量層。冷卻期約為 2 天。

如果讀取、容量層上的冷資料區塊會變熱、並移至效能層。

自動

當 Aggregate 容量達到 50% 後、 Cloud Volumes ONTAP 將 Volume 中的 Cold 資料區塊分層至容量層。Cold 資料不僅包括 Snapshot 複本、也包括來自作用中檔案系統的冷使用者資料。冷卻期約 31 天。

支援此原則、從 Cloud Volumes ONTAP 支援的功能為 2 。 9.4 。

如果以隨機讀取方式讀取、容量層中的冷資料區塊就會變熱、並移至效能層。如果以連續讀取方式讀取(例如與索引和防毒掃描相關的讀取)、則冷資料區塊會保持冷卻狀態、而不會移至效能層級。

備份

當您複寫磁碟區以進行災難恢復或長期保留時、目的地磁碟區的資料會從容量層開始。如果您啟動目的地 Volume 、資料會隨著讀取而逐漸移至效能層。

將磁碟區的資料保留在效能層中、避免移至容量層。

設定資料分層

如需相關指示及支援組態清單、請參閱 "將非作用中資料分層至低成本物件儲存設備"