Data Domain:Data Domain Restorer (DDR) 的長期保留/雲端層清理/垃圾收集簡介
摘要: 本文介紹使用雲端/長期保留 (LTR) 功能在 Data Domain Restorers (DDR) 上設定的雲端層的清理/垃圾收集相關問題
本文章適用於
本文章不適用於
本文無關於任何特定產品。
本文未識別所有產品版本。
說明
Data Domain Operating System (DDOS) 6.0 推出稱為雲端保留或長期保留 (LTR) 的新功能。此功能允許將雲端提供商隨需分配的第二層物件型儲存新增至具有相關 CLOUD_CAPACITY 授權的特定 Data Domain Restorer (DDR) 型號。
在使用由 DDR 接收的 LTR 檔案的系統上,最初會寫入作用層 (本機連接的儲存裝置)。然後會依據每個 mtree 來設定資料移動原則/期限閾值,以便稍後透過資料移動程序 (定期排程的工作) 將需要長期保留的特定檔案從作用層遷移至雲端層。
您可以正常刪除雲端層中的檔案,但是雲端/物件儲存裝置上的相關空間不會立即回收再使用。若要從雲端移除多餘的資料,則必須清理雲端層。
雲端層的結構:
雲端層會細分為「雲端裝置」。請注意:
名稱 設定檔 狀態
----------------------- ------------ ------
B-裝置 LTR-ECS-Ben 使用中 <=== ECS 供應商
cloud-unit-virtustream1 virtustream1 使用中 <=== Virtustream 供應商
----------------------- ------------ ------
雲端清理的基本概念:
很抱歉,目前無法透過 Data Domain 命令列 shell (DDSH) 取得此資訊,雲端裝置清理進行中。
此外,如果以手動方式啟動雲端清理或透過其排程進行,DDFS 記錄中會顯示下列內容:
排程雲端清理:
在 DDOS 6.0 及更新版本中,作用層清理排程的方式並未變更,依預設,作用層清理排定在每週星期二 0600 執行一次,即:
# filesys clean show schedule
檔案系統清理排定在「0600」的「Tue」執行。
根據預設,雲端清理排定在每一排定的作用階層清理的第 4 次調用之後執行。若要顯示雲端清理排程,應使用以下命令:
# cloud clean frequency show
雲端層清理頻率設為在每 4 個作用層清理週期後執行。
因此,在有預設組態的系統上,雲端清理將每 4 週啟動一次 - 如果系統有兩個雲端裝置,則每個裝置將每 8 週清理一次。
若要變更雲端清理頻率,可以使用下列命令:
# cloud clean frequency set 2
雲端層清理頻率設為在每 2 個作用層清理週期後執行。
若要將雲端清理重設為每 4 個作用層清理後的其預設排程,可以使用以下命令:
# cloud clean frequency reset
雲端層清理頻率會重設為預設值 (每 4 個作用層清理週期)。
請注意,雲端清理排程不包括手動啟動的作用層清理週期。因此,在上述系統上,即使每天手動執行作用層清理,雲端層清理也只會每 4 週啟動一次。
您也可以使用下列命令,完全停用排定的雲端清理:
# cloud clean frequency set never
雲端層清理頻率設為「永不」。
在這種情況下,雲端清理只會在手動啟動時執行。
若要停止目前執行中的雲端清理,可以使用以下命令:
# cloud clean stop
若要確定上次執行端雲清理的時間,可以使用以下命令:
# cloud clean status
雲端層清理完成時間為 2016/08/01 20:54:43。
雲端清理演算法:
雲端清理將使用為作用層設定的相同清理演算法。在 DDOS 6.0 (及更新版本) 中,這會預設為 perfect physical garbage collection (PPGC),但這可透過系統參數變更為 physical garbage collection (PGC)。
請注意,不應停用實體垃圾收集,因為使用傳統/完整清理演算法清理雲端裝置可能會導致 DDFS 錯誤/重新開機
清理開始時,用於雲端清理的演算法會顯示在 DDFS 記錄中,即:
06/28 10:51:56.960 (tid 0x7fc5bccb2d50): gc: gc_start_intern: Algorithm selected: Physical Cleaning <=== PPGC or PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): gc: gc_start_intern: Algorithm selected: Full Cleaning <=== Traditional GC
請注意,從上面的輸出中並無法區分 PPGC 或 PGC - 由於清理執行的階段數,使用的特定演算法很明顯 - 一般來說:
傳統/完整 GC:10 個階段
PGC:12 個階段
PPGC:6 個階段
如需有關變更系統上使用的清理演算法的更多資訊,請聯絡簽訂合約的支援提供者
作用層清理和雲端層清理複製階段之間的差異:
清理的複製階段是 DDR 上多餘的資料已實體移除/回收空間的階段。請注意,作用層和雲端層之間的複製階段運作方式不同:
作用層:
雲端層:
標記為刪除的壓縮區域會由雲端清理以非同步方式處理,因此即使雲端清理已完成,雲端裝置上的可用空間仍可能會持續增加
這種差異是由於在雲端儲存上讀取/寫入大量資料所涉及的固有成本,但這確實代表雲端裝置可能會變成人工填滿 (即包含大量壓縮區域,每個都包含非常少量的即時資料,造成無法將其刪除)。
如果發生這種情況,可以設定系統參數,強制雲端裝置進行「磁碟重組清理」,這會從現有的壓縮區域複製轉送即時資料,以將即時資料整合在盡可能少的壓縮區域中,以釋放空間。
有關執行「磁碟重組清理」的更多資訊,請聯絡您的簽約支援供應商。
在使用由 DDR 接收的 LTR 檔案的系統上,最初會寫入作用層 (本機連接的儲存裝置)。然後會依據每個 mtree 來設定資料移動原則/期限閾值,以便稍後透過資料移動程序 (定期排程的工作) 將需要長期保留的特定檔案從作用層遷移至雲端層。
您可以正常刪除雲端層中的檔案,但是雲端/物件儲存裝置上的相關空間不會立即回收再使用。若要從雲端移除多餘的資料,則必須清理雲端層。
雲端層的結構:
雲端層會細分為「雲端裝置」。請注意:
- 雲端層最多可包含兩個雲端裝置
- 每個雲端裝置的大小可達指定 DDR 機型支援的最大作用層大小
- 每個雲端裝置可以從不同的物件儲存供應商隨需分配
名稱 設定檔 狀態
----------------------- ------------ ------
B-裝置 LTR-ECS-Ben 使用中 <=== ECS 供應商
cloud-unit-virtustream1 virtustream1 使用中 <=== Virtustream 供應商
----------------------- ------------ ------
雲端清理的基本概念:
- 雲端清理作業僅在每次執行期間針對單一雲端裝置執行 - 若要判斷要清理的雲端裝置,可在 DDFS 記錄 (/ddr/var/log/debug/ddfs.info) 中找到下列訊息 - 在此情況下,正在清理的是 cloud-unit-virtustream1 雲端裝置:
08/12 13:25:07.551 (tid 0x7f22991eb880): gc: Physical Cleaning will run on partition: cloud-unit-virtustream1, select_flags: none, usr: SCHEDULED CLOUD-GC, asm: 是
很抱歉,目前無法透過 Data Domain 命令列 shell (DDSH) 取得此資訊,雲端裝置清理進行中。
- 如果系統已設定多個雲端裝置,則雲端清理會對這些裝置進行循環制清理,在每次執行雲端清理時,嘗試清理單一裝置
- 雲端清理可以手動啟動,或透過排程自動啟動 - 若要手動啟動,請使用下列命令:
# cloud clean start [cloud unit name]
- 作用層清理和雲端清理無法同時執行 (因為兩者在 DDFS 中使用相同的記憶體結構)
- 如果作用層清理正在執行 (手動或透過其排程啟動),且嘗試啟動雲端清理,則會發生錯誤,即:
# cloud clean start cloudunit2
Failed to start: activer tier cleaning is currently running. Use 'filesys clean watch' to monitor its progress.
Failed to start: activer tier cleaning is currently running. Use 'filesys clean watch' to monitor its progress.
- 如果雲端清理已自動啟動 (即透過其排程),且已啟動作用層清理,則會中止雲端裝置清理作業,以允許執行作用層清理。DDFS 記錄中的下列內容已對此進行說明:
08/12 13:25:24.532 (tid 0x7f2277e9d210): gc_asm_start: Abort scheduled cloud-GC
- 如果已手動啟動雲端清理,並嘗試啟動作用中,則作用層清理作業將無法啟動 - 將會等待雲端清理執行至完成,即:
# filesys clean start
**** Cleaning cannot start since Cloud tier cleaning is in progress. Use 'cloud clean watch' to monitor progress.
**** Cleaning cannot start since Cloud tier cleaning is in progress. Use 'cloud clean watch' to monitor progress.
- 雲端裝置必須已經歷至少 1% 的資料「流失」 (即 >= 目前雲端裝置上資料的 1% 必須被視為多餘,因此可移除),才能開始雲端清理。如果不是這種情況,則會在如果是手動啟動雲端清理時於命令列上顯示以下內容:
# cloud clean start cloudunit2
**** Failed to start: cloud unit "cloudunit2" does not have sufficient cleanable data.
**** Failed to start: cloud unit "cloudunit2" does not have sufficient cleanable data.
此外,如果以手動方式啟動雲端清理或透過其排程進行,DDFS 記錄中會顯示下列內容:
07/26 15:38:58.496 (tid 0x7f7a450fd340): gc: cp: cloudunit2 has 0% churn, minimum churn needed to run gc: 1%
07/26 15:38:58.496 (tid 0x7f7a450fd340): gc: cp: cloudunit2 does not have sufficient churn for GC to run
07/26 15:38:58.496 (tid 0x7f7a450fd340): gc: cp: cloudunit2 does not have sufficient churn for GC to run
- 如果系統包含兩個雲端裝置,第一個裝置的排程清理由於某些原因 (例如流失不足) 失敗,則清理作業會自動嘗試啟動第二個裝置 (即不需要等待下一次排定的雲端清理執行來清理第二個裝置)
- 雲端清理可以節流 (類似於作用層清理),以決定當系統處於顯著的其他工作負載 (即接收/修復/複寫) 時應採取的動作。
與作用層清理一樣,節流會設定為介於 0 和 100 之間的百分比:
0%:雲端清理會快速將資源釋放到其他工作負載,因此可能造成執行緩慢,但對整體系統性能的影響最小
100%:雲端清理不會將資源釋放到其他工作負載,因此會盡可能快速地執行,但可能會對整體系統效能造成重大影響
雲端清理節流預設為 50%:
# cloud clean throttle show
雲端層清理節流設為 50%
若要修改節流,可以使用以下命令 - 請注意,新的節流值會立即生效,在變更節流後不需要重新啟動 DDFS 或雲端清理:
# cloud clean throttle set 75
雲端層清理節流設為 75%
0%:雲端清理會快速將資源釋放到其他工作負載,因此可能造成執行緩慢,但對整體系統性能的影響最小
100%:雲端清理不會將資源釋放到其他工作負載,因此會盡可能快速地執行,但可能會對整體系統效能造成重大影響
雲端清理節流預設為 50%:
# cloud clean throttle show
雲端層清理節流設為 50%
若要修改節流,可以使用以下命令 - 請注意,新的節流值會立即生效,在變更節流後不需要重新啟動 DDFS 或雲端清理:
# cloud clean throttle set 75
雲端層清理節流設為 75%
排程雲端清理:
在 DDOS 6.0 及更新版本中,作用層清理排程的方式並未變更,依預設,作用層清理排定在每週星期二 0600 執行一次,即:
# filesys clean show schedule
檔案系統清理排定在「0600」的「Tue」執行。
根據預設,雲端清理排定在每一排定的作用階層清理的第 4 次調用之後執行。若要顯示雲端清理排程,應使用以下命令:
# cloud clean frequency show
雲端層清理頻率設為在每 4 個作用層清理週期後執行。
因此,在有預設組態的系統上,雲端清理將每 4 週啟動一次 - 如果系統有兩個雲端裝置,則每個裝置將每 8 週清理一次。
若要變更雲端清理頻率,可以使用下列命令:
# cloud clean frequency set 2
雲端層清理頻率設為在每 2 個作用層清理週期後執行。
若要將雲端清理重設為每 4 個作用層清理後的其預設排程,可以使用以下命令:
# cloud clean frequency reset
雲端層清理頻率會重設為預設值 (每 4 個作用層清理週期)。
請注意,雲端清理排程不包括手動啟動的作用層清理週期。因此,在上述系統上,即使每天手動執行作用層清理,雲端層清理也只會每 4 週啟動一次。
您也可以使用下列命令,完全停用排定的雲端清理:
# cloud clean frequency set never
雲端層清理頻率設為「永不」。
在這種情況下,雲端清理只會在手動啟動時執行。
若要停止目前執行中的雲端清理,可以使用以下命令:
# cloud clean stop
若要確定上次執行端雲清理的時間,可以使用以下命令:
# cloud clean status
雲端層清理完成時間為 2016/08/01 20:54:43。
雲端清理演算法:
雲端清理將使用為作用層設定的相同清理演算法。在 DDOS 6.0 (及更新版本) 中,這會預設為 perfect physical garbage collection (PPGC),但這可透過系統參數變更為 physical garbage collection (PGC)。
請注意,不應停用實體垃圾收集,因為使用傳統/完整清理演算法清理雲端裝置可能會導致 DDFS 錯誤/重新開機
清理開始時,用於雲端清理的演算法會顯示在 DDFS 記錄中,即:
06/28 10:51:56.960 (tid 0x7fc5bccb2d50): gc: gc_start_intern: Algorithm selected: Physical Cleaning <=== PPGC or PGC
07/27 12:21:18.224 (tid 0x7f92b8cfe7e0): gc: gc_start_intern: Algorithm selected: Full Cleaning <=== Traditional GC
請注意,從上面的輸出中並無法區分 PPGC 或 PGC - 由於清理執行的階段數,使用的特定演算法很明顯 - 一般來說:
傳統/完整 GC:10 個階段
PGC:12 個階段
PPGC:6 個階段
如需有關變更系統上使用的清理演算法的更多資訊,請聯絡簽訂合約的支援提供者
作用層清理和雲端層清理複製階段之間的差異:
清理的複製階段是 DDR 上多餘的資料已實體移除/回收空間的階段。請注意,作用層和雲端層之間的複製階段運作方式不同:
作用層:
- 寫入 DDR 作用層的資料包含在 4.5Mb 容器中
- 在預設情況下,僅當容器包含 <= 92% 的「即時」(即主動引用的) 資料時,清理才會考慮進行「複製」
- 即時資料將從容器中解壓縮,並在檔案系統結束時寫入新容器 (與其他複製容器中的即時資料一起)
- 磁碟上的索引已更新,以反映保存即時資料的新容器
- 接著刪除原始容器 (同時包含即時資料和失效資料),並讓基礎磁碟空間可供使用
雲端層:
- 寫入 DDR 雲端層的資料結構不同,會將個別的資料區塊 (64Kb 壓縮區域) 寫入雲端裝置,取代放入 4.5Mb 容器中 (注意:若為 DDOS 6.1.2.0 及更新版本,儲存在雲端裝置中的物件會更大,請參閱 Data Domain:雲端層的大型物件大小,以取得詳細資訊)
- 雲端清理不會從現有的壓縮區域中解壓縮即時資料並將其複製轉送,這只會考慮單純包含所要刪除失效資料的壓縮區域
因此,如果壓縮區域包含單一非常少量的即時資料 (由檔案參照),則不會將其刪除,也不會從磁碟中移除壓縮區域內的失效資料 (即,不會回收壓縮區域使用的任何空間)
標記為刪除的壓縮區域會由雲端清理以非同步方式處理,因此即使雲端清理已完成,雲端裝置上的可用空間仍可能會持續增加
這種差異是由於在雲端儲存上讀取/寫入大量資料所涉及的固有成本,但這確實代表雲端裝置可能會變成人工填滿 (即包含大量壓縮區域,每個都包含非常少量的即時資料,造成無法將其刪除)。
如果發生這種情況,可以設定系統參數,強制雲端裝置進行「磁碟重組清理」,這會從現有的壓縮區域複製轉送即時資料,以將即時資料整合在盡可能少的壓縮區域中,以釋放空間。
有關執行「磁碟重組清理」的更多資訊,請聯絡您的簽約支援供應商。
受影響的產品
Data Domain產品
Data Domain文章屬性
文章編號: 000019165
文章類型: How To
上次修改時間: 25 7月 2025
版本: 3
向其他 Dell 使用者尋求您問題的答案
支援服務
檢查您的裝置是否在支援服務的涵蓋範圍內。