Avamar：複寫配對顯示不同的容量用量層級。如何調查原因。

「伺服器使用率」值之間差異的起因和可能的原因：

格線之間的邏輯或實體差異：

• 來源格線和目標格線上的資料節點數量不同。
• 每個格線的資料節點有不同的磁碟組態。
• 在每個系統內的資料節點之間充分地平均分配等量 (至 2% 以內)
• Avamar 版本之間的儲存和同位需求有所不同。如果來源和目標軟體版本不同，可能會發現用量有所不同。
• 兩個格線之間的 Avamar Server 磁碟唯讀層級可能會有所不同。   
• 一個格線可能針對 RAIN 同位設定，另一個則可能沒有。

複寫組態：

• 複寫到目標系統的備份與來源相較下可能具有不同的保留原則。如需詳細資訊，請查看 expiredelta 旗標。或者，複寫的備份只能涵蓋特定的時間間隔。例如，來源的前 4 週備份。
• 可以將複寫設定為僅將一個用戶端子集從來源系統複寫到目標系統。檢查是否使用了「包含」或「排除」設定。
• 用戶端及其關聯的備份可能已從來源系統中刪除。刪除用戶端或來源上的備份不會從目標系統中移除相同的備份。備份將保留在目標上，直到這些根據其保留設定過期為止。
• 可以在來源系統上更改備份或用戶端的保留原則。保留原則的變更只會影響新的備份。新的備份會複寫至目標，並遵守更新的保留原則。目標上已經存在的備份會保留在複寫時套用到其上的保留原則。

先前的容量管理活動：

• 客戶常會注意到其中一個 Avamar 複寫配對系統即將達到容量上限，然後需要採取行動以減少容量的情況。請記住 - Avamar 複寫配對由兩個獨立管理的系統組成。如果在一個系統上執行操作，則必須也在另一個系統上執行該操作。 
• 如果刪除來源系統上的備份或減少保留，則必須在目標上進行相同的變更。以這種方式管理容量的最佳方式是使用 modify-snapups 指令檔。這可以在兩個具有相同備份修改或刪除選項的 Avamar Server 上執行。  

不同的等量結構 (例如，一個系統上的同位等量較多)：

• 兩個獨立的 Avamar 系統最終可能會有不同的等量結構。多節點系統可能會因為使用了同位等量來保護資料而出現差異。根據其容量歷程記錄而定，兩個多節點系統包含相同的備份，但其中一個系統的同位等量數量可能比另一個多。
• 與一般等量一樣，一旦建立後，同位等量一律會保留在系統上。與一般等量不同的是，它在 Avamar Server 中一律會耗用固定的空間量。即使其同位群組安全等量不包含任何資料，情況也是如此。垃圾收集對此行為沒有影響。
• 複寫目標系統會間接受到保護，免受複寫來源上的重大容量問題影響。但是，如果從容量的角度來看，若是其中一台機器管理不善，則任一台機器上都可能發生這種情況。
• 相關的文章：即使在刪除所有備份並收集垃圾之後，Avamar 系統仍會顯示高達約 30% 的使用率

備份仍在 MC_DELETED 中：

• 需要注意的一種罕見情況是，已刪除在來源上的用戶端，但其備份卻保留下來。這可能會導致來源的使用率高於備份預期會自然到期的目標。使用具有 backupcompare 選項的 dump_root_hashes.rb 指令檔有助於檢查此情況。

目標系統上來自非複製備份的資料：

• 如果系統 *僅單向* 複寫，請檢查目標上在 /REPLICATE 和 MC_SYSTEM 之外不存在任何用戶端。

其他行為：

• 複寫工作可能並不完全可靠。傳送到目標的資料可能會「落後」來源數天。
• 兩個系統包含相同重複資料刪除的資料數量，但每個系統的同位負擔量不同。此狀況會在下列情況下發生： 
  • Avamar 來源系統幾乎已滿。 
  • 會從來源系統刪除許多備份，以降低其容量層級。 
  • 然後，重複資料刪除的資料即會從來源複寫到目標。 
  • 兩個系統上重複資料刪除的資料數量相同。
  • 來源系統最初儲存的同位負擔會多於目標。
• 複寫不會將實體等量從來源複製到目標格線。目標格線反而可以自行決定儲存等量和資料塊的位置。
• 有時候，目標 Avamar 系統儲存資料的效率會高於原始備份資料的來源格線。

瞭解複寫環境：

• 記下來源 Avamar 格線的完整主機名稱。
• 檢查受影響系統的複寫組態，以瞭解哪些系統複寫什麼資料以及複寫到何處。 
  • 如果環境比從一個 Avamar Server 複寫到另一個伺服器更複雜，繪製示意圖可能會有所幫助。
• 如果來源與 Data Domain (DD) 整合，請瞭解客戶的顧慮是否與在 DD 裝置之間複寫的備份有關。
• 請記下目標 Avamar 格線的完整主機名稱，以及接收複寫備份的任何相關 DD 裝置。

檢查格線的整體健全狀況和情況：

• 在兩個格線上執行主動式檢查指令檔，取得 hc_results.txt 的複本並檢閱，以瞭解系統的整體情況。 

容量差異有多嚴重？

• 客戶應提供螢幕擷取畫面，顯示他們看到使其認為來源和目標之間存在容量耗用差異的內容。
• 我們不會考慮容量差異小於 5% 的警示原因。
• 請檢查 Avamar Administrator UI，以瞭解 Avamar Server 容量層級和 (如果已整合 Data Domain) 中繼資料容量。
• 請注意 UI 容量顯示的運作方式 (在 7.2 版及更新版本的 Avamar UI 儀表板中會顯示「中繼資料使用率」而非「Avamar 使用率」中討論)。
• 在兩個系統上執行下列命令。伺服器使用率值提供的是 Avamar Server (而非 Data Domain) 容量層級的整體值：

admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

檢查兩個格線上的硬體是否相同：

• 只有比較「類似」系統的容量差異才有意義。 
• 使用主動式檢查輸出，記下系統中存在的節點類型。
• 以下命令顯示實體節點上的整體數量、大小和空間消耗：

admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3

• 此輸出使判定系統中節點的數量和大小變得容易。它們是 (23.3 / 3 = ~7.8 TB)。 
• 每個節點上的硬碟分割區數量和大小都必須確認這一點。

admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06

• 使用此資訊，請檢查以下各項：

檢查軟體版本和組態：

• 使用 status.dpn 命令的輸出，比較每個系統上執行的 Avamar 版本。
• 若為多節點系統，請確認兩者皆使用 RAIN 同位進行設定，依 Avamar - 如何判斷伺服器為 RAIN 或非 RAIN
• 檢查並比較兩個系統容量相關的 Avamar Server 組態參數。例如：

admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"

檢查等量平衡：

• 檢查 status.dpn 輸出，並請注意每個資料節點上的等量總數。等量的數字會顯示在括號中 (例如 onl：xxx)。 
• 每個資料節點上的等量總數之間的差異應小於 2%。  

檢查兩個系統上的垃圾收集是否已正確執行：

• 如果垃圾收集未能一致且有效地執行，則不會刪除過期的資料。系統報告的容量用量高於預期。 
  • 如需相關資訊，請參閱限制備註中的 GC 解決方案路徑文章。  

確認複寫已成功完成：

• 確保從來源到目標的所有複寫工作都已成功完成。如果沒有發生這種情況，則可能是仍有資料需要從來源複製到目標。  

檢查複寫組態：

• 檢查複寫組態 (在 UI、CLI 或記錄中) 是否有下列任何旗標：  

--before
--after
--include
--exclude

--expiredelta

--retention-types

--retention-types=none,daily,weekly,monthly,yearly

檢查兩個系統的消化和資料移除率：

• 在兩個系統上執行 proactive_check.pl --capacity，並比較來源系統和目標系統的消化率。
• 如果目標純粹是目標系統，並且從來源接收「所有」備份，則其消化率應會緊跟來源的消化率。
• Avamar NEW 或 DDR NEW 欄會顯示有多少新資料新增至這些系統。
• 此外，請密切留意「removed」、「mins」和「pass」欄，以瞭解這兩個系統上的垃圾收集行為。
• 此資訊可讓您清楚瞭解兩個系統上發生的情況。
• 如需解譯輸出的詳細資訊，請參閱 Avamar：如何使用 capacity.sh 指令檔管理容量  

傾印每個系統上存在的備份清單：

• 這個 dump_root_hashes.rb 指令檔是一個公用程式，可協助比較儲存在 Avamar 來源和目標系統之間的備份差異。即使將備份託管在 Data Domain 儲存裝置上也是如此。   
• 請參閱 Avamar：Avamar：如何使用 dump_root_hashes.rb 指令檔產生用戶端和備份清單，取得下載公用程式和使用案例的相關資訊，包括比較兩個 Avamar 系統的內容。
  • 執行此工具。檢查所有用戶端上的備份計數是否有不一致之處。注意 +/-2 的差異)。  
• 如原因區段所述，非對稱容量管理會導致兩個系統之間的差異。查看輸出以確定這是否為此情況。
• 此外：
  • 從非複寫備份中，檢查目標系統上的資料目標。
  • 檢查來源中是否有未複寫到目標的資料。  

檢查是否有不同的等量結構 (例如，一個系統上的同位等量較多)：

• 兩個獨立的 Avamar 系統可能會有不同的等量結構。多節點系統可能會因為使用了同位等量來保護資料而出現差異。根據其容量歷程記錄而定，兩個多節點系統包含相同的備份，但其中一個系統的同位等量數量可能比另一個多。  
• 與一般等量一樣，一旦建立後，同位等量會保留在系統上。與一般等量不同，即使其同位群組安全等量不包含任何資料，它也一律會在 Avamar 內佔用固定的空間量。垃圾收集對此行為沒有影響。
• 複寫目標系統會間接受到保護，免受複寫來源上的重大容量問題影響。但是，如果從容量的角度來看，若是其中一台機器管理不善，則任一台機器上都可能發生這種情況。
• 相關的文章：  即使在刪除所有備份並收集垃圾之後，Avamar 系統仍會顯示高達約 30% 的使用率  

備份仍在 MC_DELETED 中：

• 需要注意的一種罕見情況是，已刪除在來源上的用戶端，但其備份卻保留下來。這會導致來源的使用率高於備份預期會自然到期的目標。使用具有 backupcompare 選項的 dump_root_hashes.rb 指令檔應有助於檢查此情況。