Avamar：作業系統 （OS） 容量 （解決方案路徑）

Summary: 此解決方案路徑文章旨在處理或故障診斷 Avamar 上的作業系統 （OS） 容量問題。

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.
Check out other resources

Symptoms

如何處理或故障診斷 Avamar 上的作業系統容量問題。

本解決方案路徑文章旨在解決或故障診斷 Avamar 上的作業系統容量問題。


如需作業系統容量的初步概念和瞭解，請參閱訓練文章 Avamar：容量管理概念和訓練

如培訓文章所述，要繼續本文的其餘部分，應要求對以下主題有合理的理解：

  • 對檢查點 （cp）、檢查點驗證 （hfscheck)和垃圾回收 （GC） 以及每個
  • 兩者的區別 GSAN （又稱為「使用者容量」和作業系統容量）
  • 檢查點額外負荷資料
  • 如果任何資料磁碟分割超過實體作業系統總容量空間的 89%，垃圾收集便無法執行。
  • Avamar 格線距離 100% 的使用者容量越近，檢查點額外負荷可用的作業系統容量就越少。
  • 導致檢查點開銷的因素包括異步處理、存儲的檢查點數、 HFSCheck 和檢查點驗證重要性等。
  • 如何尋找作業系統容量層級
  • 減輕作業系統容量的基本動作

 

通常最簡單的做法是將作業系統容量視為 GSAN 資料 （更具體地說是分配給此資料的空間） 和 Avamar 檢查點產生的額外費用。檢查點數量越多，更改率越高，檢查點開銷就越高。


高作業系統容量的影響可能包括：

  • 垃圾收集失敗：GC 失敗並顯示MSG_ERR_DISKFULL 如果作業系統容量超過 89%
  • 備份或複寫失敗： 如果作業系統容量超過 90%，備份或傳入的複寫可能會失敗並傳MSG_ERR_STRIPECREATE。（只有在必須建立新的資料等量時才會進行此動作。如果不需要新的等量，備份和複寫仍可順利執行。）
  • 檢查點故障：如果作業系統容量超過 96%，檢查點會失敗並MSG_ERR_DISKFULL


如上所述，當其他 Avamar 容量也很高時，作業系統容量通常是第一個要處理的 Avamar 容量類型。至少當作業系統容量達到特定層級時，即便無法執行垃圾收集 GSAN 或者使用者容量也很高。

一般來說，如果作業系統容量超過 89%，當 GC 失敗並MSG_ERR_DISKFULL時，作業系統容量會被視為高容量。如果作業系統容量完全低於 89%，則不會影響任何維護工作。 

 
注意：作業系統容量預期一整天都會波動。確認日常維護作業順利執行非常重要，而且通常是盡可能避免作業系統容量問題的最佳解決方案。
 
注意：雖然上述情況被視為 Avamar 作業系統容量，但仍有可能與備份磁碟分割或檢查點沒有直接關係的作業系統容量問題。這些是安裝 Linux 作業系統的磁碟和磁碟分割。雖然這些問題不太常見，但它們可能會產生下文討論的其他影響。

Cause

由於下列任何原因的組合，Avamar OS 容量可能會增加：

  • 備份數據更改率高，添加“太多太快”
  • High GSAN 或「使用者容量」，留給作業系統容量的空間較小，有時甚至會導致更高的變更率
  • 檢查點無法成功完成，導致狀態為「MSG_ERR_DISKFULL」，如輸出所示。
  • 檢查點驗證 （hfscheck) 最近已失敗或未執行，因此最舊的檢查點無法關閉或移除
  • 檢查點因其他原因而未滾落，包括檢查點保留設置過高
 

其他磁碟分區上的高操作系統容量可能是由各種原因引起的，包括數據放置不正確、日誌檔變得太大等。

 
快速解釋「太多太快」作為高操作系統容量的原因，可以解釋如下：
  • 如需快速背景，Avamar 檢查點是唯讀快照，並連結到即時資料。由於這是使用連結創建的，因此檢查點在創建后將立即使用零額外磁碟空間。如果實時數據沒有更改，則檢查點不會使用額外的空間。
  • 當檢查點保持不變時修改實時數據時，這會發生變化。此時，檢查點中存在數據的原始副本和已修改數據的更新即時副本。這完全是設計使然。這就是保留作業系統容量空間的原因。
  • 但是，如果資料的變更量或速率突然大幅增加，可能會導致作業系統容量大小出現不常見的尖峰，並被視為「太多太快」
  • 可使用 capacity.sh 工具會在比較幾天內的輸出時，將此顯示為原因。

Resolution

如果包括垃圾收集在內的維護工作因 Avamar OS 容量過高而失敗，請遵循下列步驟：

1.收集所有 Avamar 容量資訊以描繪情況：Avamar：如何收集故障診斷容量問題所需的資訊。


2.接下來，查看操作系統容量有多高以及可能需要執行哪些操作。在資料收集文章中，可以使用下列命令找到： 

avmaint nodelist | egrep 'nodetag|fs-percent-full'
 

Avamar 的運作方式是，所顯示的 fs-full 最高值是目前作業系統容量的限制因素。根據節點類型生成和大小，存儲備份和檢查點數據的數據分區數可能會有所不同。從 Linux 作業系統可以看出，這些可能是磁碟或磁碟分割，例如「/data0*」，其中「*」可以是個數字。資料分割區的數量取決於節點類型、硬體世代和大小 （且無法變更）。


3.檢閱找到的檢查點數量，以及最近從命令進行驗證的時間：

cplist
cp.20290310080041 Mon Mar 10 08:00:41 2025   valid rol ---  nodes   4/4 stripes   5980
cp.20290310080649 Mon Mar 10 08:06:49 2025   valid --- ---  nodes   4/4 stripes   5980
 
注意： 有些檢查站必須保留。
 
 

4.執行下列命令，從「MSG_ERR_DISKFULL」確認檢查點作業是否失敗：

dumpmaintlogs --types=cp --days=4 | grep "\<430"


如果檢查點已成功完成，則會看到類似以下內容的輸出：

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> completed checkpoint maintenance
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance


如果因MSG_ERR_DISKFULL而失敗，則會顯示以下輸出：

2020/03/07-08:00:39.51323 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:01:31.49490 {0.0} <4301> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/07-08:07:47.36128 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/07-08:08:29.40139 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:00:39.93332 {0.0} <4300> failed checkpoint maintenance with error MSG_ERR_DISKFULL
2020/03/08-08:01:29.50546 {0.0} <4301> completed checkpoint maintenance
2020/03/08-08:06:45.37918 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/08-08:07:27.36749 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:00:36.57433 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:01:24.22214 {0.0} <4301> completed checkpoint maintenance
2020/03/09-08:06:40.52884 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/09-08:07:22.18463 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:00:39.83562 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:01:31.87814 {0.0} <4301> completed checkpoint maintenance
2020/03/10-08:06:48.27867 {0.0} <4300> starting scheduled checkpoint maintenance
2020/03/10-08:07:29.95640 {0.0} <4301> completed checkpoint maintenance
 
如果檢查點作業失敗並出現MSG_ERR_DISKFULL錯誤，請向 Dell Technologies Avamar 支援小組 開立服務要求 ，否則請繼續執行步驟 5。
 
 
5.檢查是否有其他檢查點問題：
 
可使用 cplist c奧曼德 顯示找到的檢查點數以及最近驗證檢查點的時間。也如資料收集文章所示，使用 Avamar - 如何瞭解 cplist 命令產生的輸出，以瞭解 cplist 產量。

應該有兩個或三個檢查點，並且過去 24 小時內至少有一個檢查點顯示為驗證 hfscheck。這將是正常行為，也是所有成功運行作業和正常檢查點保留設置的輸出。

如果過去 24 小時內有三個以上的檢查點，或沒有任何經過驗證的檢查點，則必須先解決此問題，因為這可能是降低作業系統容量的唯一方法。如果遇到這種情況，請向 Dell Technologies 開立服務要求 ，否則請從步驟 6 繼續。
 
 

6.確定變更率：

capacity.sh

 

範例輸出：

  DATE     AVAMAR NEW     #BU    SCANNED       REMOVED     MINS PASS AVAMAR NET      CHG RATE
========== ============= ==== ============= =============  ==== ==== ============= ==========
2020-02-25       1066 mb    8     302746 mb       -641 mb     0   23        425 mb      0.35%
2020-02-26       1708 mb    8     303063 mb       -518 mb     0   23       1189 mb      0.56%
2020-02-27       3592 mb    8     304360 mb       -413 mb     0   23       3178 mb      1.18%
2020-02-28       1086 mb    8     304892 mb       -372 mb     0   23        713 mb      0.36%
2020-03-01       1002 mb    8     305007 mb      -7469 mb     0   25      -6467 mb      0.33%
2020-03-02        585 mb    7     197874 mb          0 mb     0    9        585 mb      0.30%
2020-03-03        348 mb    7     199305 mb          0 mb     0   10        348 mb      0.17%
2020-03-04        775 mb    7     198834 mb         -2 mb     0   10        773 mb      0.39%
2020-03-05        380 mb    4     196394 mb         -5 mb     0   10        375 mb      0.19%
2020-03-06       1068 mb    4     159960 mb          0 mb     0    9       1067 mb      0.67%
2020-03-07        443 mb    4     197132 mb        -18 mb     0   17        424 mb      0.23%
2020-03-08        348 mb    4     197231 mb        -48 mb     0   20        300 mb      0.18%
2020-03-09        370 mb    4     196506 mb          0 mb     0    9        370 mb      0.19%
2020-03-10        349 mb    4     197292 mb        -17 mb     0   20        332 mb      0.18%
2020-03-11        974 mb    2      77159 mb          0 mb     0    0        974 mb      1.26%
=============================================================================================
 14 DAY AVG       940 mb    5     222517 mb       -634 mb     0   15        306 mb      0.42%
 30 DAY AVG      1121 mb    5     195658 mb       -771 mb     0   14        349 mb      0.59%
 60 DAY AVG       994 mb    4     128657 mb      -1165 mb     0   17       -170 mb      0.98%

Top Change Rate Clients.  Total Data Added 14103mb

     NEW DATA % OF TOTAL CHGRATE TYPE CLIENT
============= ========== ======= ====
      6803 mb     48.24   0.91%  AVA /Windows/testing/Hyper-V/hyperv1
      3218 mb     22.82   0.61%  AVA /clients/exchange1
      2932 mb     20.80   0.44%  AVA /BMR/server1
       983 mb      6.97   0.10%  AVA /Windows/testing/SQL/sql1
        97 mb      0.69   1.13%  AVA /REPLICATE/grid2.company.com/MC_BACKUPS

 


有時，如果高變化率或「太多太快」的情況再次出現，可以通過降低整體 GSAN 或使用者容量。用較低的 GSAN 容量，操作系統容量開銷空間更大一些，也會導致數據存儲容器更改更少。如需此情況的協助，請向 Dell Technologies Avamar 支援小組 開立服務要求 ，否則請從步驟 7 繼續。

 

7.其他磁碟分割區上的作業系統容量過高的問題有多種原因，但解決方案需要技術支援。請向 Dell Technologies Avamar 支援團隊開立服務要求，否則請從步驟 7 繼續。

 
 

解決作業系統容量問題後， GSAN 可檢閱容量或其他 Avamar 容量。請參閱 Avamar 容量故障診斷、問題及疑問 - 所有容量 （解決方案路徑）

 

Affected Products

Avamar, Avamar Server
Article Properties
Article Number: 000169014
Article Type: Solution
Last Modified: 12 Mar 2025
Version:  7
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.