Avamar:容量管理概念和訓練

Summary: 本文適用於 Avamar 使用者和作業系統容量管理。本文適用於 Avamar 系統管理員或監控 Avamar 格線健全狀況的人員,他們需要有效瞭解如何管理作業系統和使用者容量層級。

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Symptoms

如需瞭解與 Data Domain 相關的容量管理問題,請參閱 Avamar 和 Data Domain 系統整合指南中的「回收完整 Data Domain 系統上的儲存裝置」一節。與您作業環境相關的指南可在如何在 Dell 支援網站上找到 Avamar 說明文件中找到。

本文的目標:
 
  • 摘要列出儲存在 /data* 磁碟分割中的資料類型。
  • 介紹「作業系統容量」的概念,並將其與「使用者容量」(有時稱為「GSAN 容量」) 的概念進行比較。
  • 說明為什麼 Avamar 執行時不應接近「使用者容量」限制。
  • 列出導致檢查點負荷資料的因素。
  • 說明如何監控資料磁碟分割使用率。
  • 說明當作業系統容量失控時所出現的症狀。
  • 列出 MSG_ERR_DISKFULL 訊息的典型原因。
  • 概述高作業系統容量影響正常系統運作時所使用的復原方法。
  • 說明如果使用者容量超過使用者容量限制時所出現的症狀。
  • 討論如何從高使用者容量的情況復原。

本文假定讀者熟悉在 Avamar 作業最佳實務指南中的「管理容量」一節。

與您作業環境相關的指南可在如何在 Dell 支援網站上找到 Avamar 說明文件中找到。

「作業系統容量」過高症狀的影響或為其症狀的常見問題包括:
  • 檢查點驗證 (hfscheck) 失敗。
  • 垃圾收集無法執行並報告 MSG_ERR_DISKFULL。
  • 檢查點建立失敗。
與「使用者容量」過高密切相關的常見症狀包括:
  • 備份失敗。
  • 傳入複寫工作失敗。
  • 系統管理員介面在備份時段期間會以「Admin」模式顯示系統。

Cause

請參閱「解決方案」一節。

Resolution

Avamar 格線上的資料儲存方式為何?


Avamar 容量管理著重於所有 Avamar 資料節點的 /data* 磁碟分割中的資料。這包括:
  • 重複資料刪除的備份資料
  • RAIN 同位檢查資料
  • 檢查點額外負荷資料
除了 RAID 和複寫之外,RAIN 同位檢查和檢查點資料都是 Avamar 可用的冗餘層。

若要正確執行垃圾收集和非同步等量運算等維護作業,還需要資料磁碟分割中有可用空間。

下面是 Avamar 儲存節點上資料磁碟分割中可用的實體儲存空間的圖形表示。

Avamar 容量細項

 

資料磁碟分割中的資料儲存方式為何?


在上圖中,我們看到了如何在資料磁碟分割中使用空間的簡單表示。

左側的 100% 值定義為資料磁碟分割中作業系統可用的實體空間總量。

如果任何資料磁碟分割佔用的總空間超過 85%,則會無法執行垃圾收集。

100% 使用者容量標記 (唯讀限制) 表示資料磁碟分割中最多 65% 的總空間可用來儲存重複資料刪除的資料。此 100% 使用者容量標記下方的空間相當於 Administrator UI 中顯示的伺服器使用率值。如果儲存在任何節點上的任何資料磁碟分割重複資料刪除的資料量達到 65%,Avamar 系統將變成唯讀,並拒絕進一步的備份資料。

我們現在可瞭解,從 Avamar Administrator UI 中,使用者能看到備份佔用的空間,但無法看到作業系統資料磁碟分割中佔用的空間。

 

為什麼 Avamar 系統執行時不應接近「使用者容量」限制:


高「使用者容量」與檢查點負荷資料之間的關係如下:隨著系統漸滿,即使備份資料小幅增加也可能導致檢查點負荷資料大幅增加。

關於其原因完整的討論已超出本文的範圍,但需要記住的一個要點是:Avamar 系統逐漸接近 100% 使用者容量時,可用於檢查點額外負荷的作業系統容量也會變少。

在完整的系統上,如上圖所示,檢查點負荷資料限制為資料磁碟分割中總作業系統空間的 20%。

Avamar 系統若要在「使用者容量」很高時可靠地執行,必須符合下列條件: 如果這些陳述中有任何一項從 true 變為 false,則檢查點負荷資料可能會逐漸上升或突然飆高,並導致嚴重的作業問題。

 

導致檢查點負荷資料的因素:


以下因素可能會導致檢查點負荷資料增加。
  • 非同步運算等量 (預設為啟用)
  • 系統上儲存的檢查點數量
  • 檢查點驗證未每天成功完成。
  • 當 Avamar Server 重複使用等量時空等量的情況 (伺服器使用率變高時,情況會更嚴重)
  • 每日備份變更率<
系統管理員對這些因素有一定程度的控制。非同步運算的組態僅用於支援,但系統管理員可以移除過多的檢查點、調查檢查點故障以及影響伺服器使用率和每日資料變更率。

 

如何監控資料磁碟分割使用率:


監控作業系統資料磁碟分割使用率的正確方法是使用 Avamar Utility Node 中的下列 Avamar 命令。

例如:

admin@utilitynode:~/>: avmaint nodelist | grep fs-percent
        fs-percent-full="7.8"
        fs-percent-full="6.3"
        fs-percent-full="6.4"
        fs-percent-full="6.4"
        fs-percent-full="7.6"
        fs-percent-full="6.2"
        fs-percent-full="6.1"
        fs-percent-full="6.6"
        fs-percent-full="7.8"
        fs-percent-full="6.4"
        fs-percent-full="6.5"
        fs-percent-full="6.8"
此結果輸出可讓您確切讀取作業系統容量使用率。在資料節點使用檔案集區的格線上,Linux df 命令沒有意義,因為等量已預先分配在檔案集區中,而且許多等量可能未在使用中。

 

如果作業系統容量的用量失控,會發生什麼情況?


從使用者的角度來看,資料磁碟分割使用率上升到 85% 以上時,即是其發生失控的第一個表示。

垃圾收集已無法再執行,並會失敗,同時顯示 MSG_ERR_DISKFULL 錯誤訊息。

以下是經常發生誤解的地方:使用者通常會解釋 MSG_ERR_DISKFULL 訊息是表示系統不再有空間可儲存備份。

此解釋並不正確,但是使用者通常會檢查 Avamar Administrator UI 中的伺服器使用率值,並發現可以接受該值,例如 60%。

使用者可能會嘗試從 Avamar UI 的備份管理介面刪除備份。即使使用者容量很高,刪除備份也無法減輕這種情況,因為垃圾收集無法執行,也無法從系統移除過期的資料區塊。

如果系統同時遇到高作業系統容量和高使用者容量問題,請先著重於解決高作業系統容量問題。

在作業系統容量使用率高的情況下,系統可能空間不足,無法建立檢查點。

 

導致出現 MSG_ERR_DISKFULL 訊息的原因是什麼?


最典型的原因是檢查點負荷資料過高。高檢查點負荷資料的典型原因可能是:
  • 檢查點驗證 (hfscheck) 一再失敗。
  • hfscheck 故障有許多可能的根本原因 (突然取消、軟體故障等)。
  • 系統執行空間太滿,且每日資料變更率很高。
  • 系統需要更多資料節點來處理資料變更率並儲存資料。
  • 系統已設定為可備份超過其大小的資料或用戶端。
  • 儲存的檢查點過多 (Avamar 預設會儲存兩個檢查點,其中一個已驗證)。
  • 系統管理員建立了過多的檢查點。
  • 最近執行了維護,但未恢復預設檢查點保留。

請參閱下列文章,以協助解決 MSG_ERR_DISKFULL 情況:由於「資料」磁碟分割作業系統容量 >89%,Avamar 維護作業失敗,並傳回「MSG_ERR_DISKFULL」

 

調查並協助減輕高作業系統容量的動作。


1.確定最後一次 hfscheck 完成的時間。您可以使用 Avamar Administrator 或 Avamar Utility Node 上的命令列完成此作業:
  • 在 Avamar Administrator 中,前往「伺服器 > 檢查點管理」分頁
  • 檢查「檢查點驗證」欄中列出的最近日期和時間。這應該是在過去 24 小時內發生。

 
  • 使用 Avamar Utility Node 命令列,執行命令:cplist。
以下是 CLI 結果輸出的範例。
 
admin@utilitynode:~/>: cplist
cp.20110114111419 Fri Jan 14 11:14:19 2011   valid rol ---  nodes   3/3 stripes   1131
cp.20110114194457 Fri Jan 14 19:44:57 2011   valid --- ---  nodes   3/3 stripes   1131
 
此處列出的最新驗證檢查點日期為 1 月 14 日的 11:14。我們可以透過「valid」標記之後緊接的旗標來識別。根據系統上設定的 hfscheck 類型,旗標可能是 rol 或 hfs。此例為 rol (rolling hfscheck)。

如果結果顯示最新驗證的檢查點超過 24 小時,請找出原因。這可能是因為 HFScheck 未執行或已失敗。


2.確認 HFScheck 是否已執行或是否已失敗。
 
在 Avamar Utility Node 上,執行 status.dpn,並找到包含最後執行 hfscheck 的行。

例如:
 
Last hfscheck: finished Sat Jan 15, 11:07:17 2011 after 06m 41s >> checked 528 of 528 stripes (OK)
記下其完成時間和狀態 (在狀態上面的行中會顯示為「OK」)。
 
注意:sched.sh 指令檔也可用來識別 HFScheck 上次執行的時間,以及是否成功。
 
如果 hfscheck 工作一直失敗,則應立即進行調查。
 
如果 hfscheck 最近未執行,請在 Avamar Utility Node 上執行下列命令,確認是否已啟用維護排程器:dpnctl status maint
admin@utilitynode:~/>: dpnctl status maint
Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/admin_key)
dpnctl: INFO: Maintenance windows scheduler status: enabled.

  • 如果維護時段排程器已關閉、停用或暫停,請使用以下命令啟用:dpnctl start maint
  • 或者,請使用新的檢查點並執行 hfscheck,或等待下一個排定的維護時段以將其完成。


一旦 hfscheck 成功完成 (在解決任何問題或重新啟動維護排程器後),即會「淘汰」最舊的檢查點,作業系統容量應會大幅降低。

  • 如果作業系統容量仍然過高,且垃圾收集依舊失敗並出現 MSG_ERR_DISKFULL 訊息,請向 Dell 技術支援團隊尋求協助。
  • 否則,如果作業系統容量低到足以讓垃圾收集完成,則可進一步降低「使用者容量」並縮小「伺服器使用率」數字。

 

 

減輕高使用者容量的動作:


與作業系統容量不同,使用者容量層級更容易直接受到 Avamar 系統管理員的影響。

1.確保垃圾收集每天都在執行,並且不會因備份而中斷。


這是最關鍵的一點,因為如果垃圾收集不能定期或可靠地執行,即使是夠大的系統也很快會出現高使用者容量問題。

如前所述,確認維護時段已啟用,並使用 capacity.shsched.sh 指令檔來驗證垃圾收集是否正在執行,以及是否正在移除資料。

在 Avamar v7.x 之前,無法在垃圾收集「限制」時段期間執行備份。

Avamar v7.x 功能中推出的雜湊參考位元對應功能,可讓備份在垃圾收集維護活動期間進行。此功能要求這些「對應」每天必須至少有 5 分鐘的「安靜」時間,在此期間不會執行任何備份,以便他們可以進行重設。

如需存取此功能相關內容,您可以使用此文章連結Avamar:從 Avamar v7 開始,垃圾收集會因為「雜湊參照位元對應」於資料使用中時報告無法清理「略過的雜湊」。


2.停止將新用戶端新增至格線。
 


當 Avamar 格線接近容量時,我們應立即停止加入新用戶端,以防止情況惡化。

如果您有另一個 Avamar 格線是以較低的伺服器使用率層級執行,請考慮將新用戶端新增至該格線,而非即將滿載的伺服器。


3.瞭解哪些用戶端佔用的儲存空間最多。

若要解決容量問題,我們應確定哪些用戶端負責向 Avamar 系統新增最多資料。

capacity.sh 指令檔 (從 Avamar Utility Node 命令列執行) 也可用來識別哪些用戶端的變更率最高。

Dell 註冊使用者可以使用連結存取下列文章的內容:Avamar:如何使用 capacity.sh 指令檔管理容量,以瞭解有關如何使用 capacity.sh 指令檔的更多詳細資訊。

一般會發現「耗用量最大」的用戶端是備份 SQL 資料庫或電子郵件伺服器的用戶端,因此請對此特別留意。


4.重新評估保留原則。
 

確定高變更率用戶端後,重新評估保留原則,看看是否可以降低其中任何項目,以便將儲存要求降低到可接受的層級。

注意:建議將保留原則設為至少 14 天。

如果系統夠舊,足以開始將保留時間最長的備份到期,那麼在減少保留原則後,我們預計每天垃圾收集移除的資料量會增加。使用 capacity.sh 監控此趨勢。

如果 Avamar 系統不夠舊到可以開始到期備份的程度,則可能需要變更保留原則,以使最舊的備份現在開始到期。

如果由於法規要求而無法減少保留原則,則應考慮擴展 Avamar 系統或將用戶端遷移到另一個較少使用的 Avamar 系統。


5.將用戶端遷移至替代的 Avamar 系統。


如果有另一個 Avamar 系統可用,請考慮使用 Avamar Client Manager 介面,將大型或高變更率用戶端從較高使用率系統遷移到較低使用率系統的可能性。

注意:
  • 新的 Avamar Server 需要足夠的儲存空間以供您要遷移的 Avamar 用戶端使用。
  • 將具有相似資料類型的用戶端保留在同一個 Avamar 系統上,以善用重複資料刪除的效率。
  • 當 Avamar 系統位於相同的區域網路上時,最適合使用此策略。


6.刪除舊備份。
 

如果使用者容量層級為嚴重 (>90%),則可能需要透過備份管理介面或使用 modify-snapups 工具將舊備份到期。

Dell 使用者可以使用以下文章的連結存取內容:Avamar 容量管理如何使用「modify-snapups」工具,大量刪除或使備份到期

刪除備份不會立即降低伺服器使用率層級。它的作用是允許垃圾收集在下次執行垃圾收集時開始移除資料。刪除舊備份是短期的因應措施。未來幾天內會取代備份。如果備份已刪除,則必須同時調整保留原則。


7.使用 capacity.sh 監控資料變更。
 

刪除備份並變更保留原則後,請使用 capacity.sh 指令檔密切監控系統上變更的資料量。您應該會開始看到「已移除」資料值增加,「淨變更」值應變為負數。最後,將過多的資料從系統中清除後,「已移除」值會開始回到更正常的層級。繼續監控「已移除」值。

如果淨變更值未變為負數,請檢查垃圾收集記錄以查看垃圾收集執行的時間長度以及在維護時段內完成的工作量。

Dell 使用者可以使用以下文章的連結存取內容:Avamar:如何使用 capacity.sh 指令檔管理容量,瞭解有關如何使用 capacity.sh 指令檔的更多詳細資訊。


8.擴充 Avamar 系統:


Avamar 系統的高使用率通常是由於自然和預期的資料成長所造成。若要繼續生產備份,則必須提供更多空間。

如何執行此操作取決於 Avamar 系統的類型。

  • 單一節點系統和 Avamar Virtual Edition (AVE) 系統

這些無法擴展。委託第二個較大的 Avamar 系統,並要求 Dell Professional Services 執行系統遷移,以從較小系統遷移到較大系統。可透過 Dell 業務經理聯絡執行 Professional Services。

如果新系統提供的儲存空間多於來源系統,則它可以是單一節點、AVE 或多節點系統。

  • 多節點系統

這些系統可以擴展到多達 16 個資料節點。請聯絡 Dell 業務經理瞭解詳情。一般支援通路不會執行節點新增,因此不應開立要求此工作的服務要求。

  • 整合 Data Domain

將 Data Domain 系統整合為後端儲存裝置,是擴充用戶端可用容量實用的方式,以供備份至 Avamar。請與您的 Dell 業務經理討論選項。

 

Additional Information

實用的工具

  • status.dpn
  • capacity.sh
  • Avalanche
  • DPN 摘要報告
  • replcnt.sh
  • Avamar Client Manager


最佳實務:

  • 嘗試防止 Avamar Server 使用率 (使用者容量) 值上升超過 80%。
  • 較低的使用者容量可針對所新增資料量未預期的變更提供復原能力,並可防止系統在維護作業發生未預期的故障或短期問題時無法使用。
  • 若 Avamar 系統以超過 80% 的使用者容量執行,系統管理員需要更積極地監控,以確保維護作業已成功完成,且系統不會變成唯讀狀態。

Affected Products

Avamar

Products

Avamar
Article Properties
Article Number: 000079977
Article Type: Solution
Last Modified: 07 Jun 2024
Version:  18
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.