Avamar：作系统 （OS） 容量（解决方案路径）

摘要: 此解决方案路径文章用于处理 Avamar 上的作系统 （OS） 容量问题或对其进行故障处理。

本文适用于 本文不适用于 本文并非针对某种特定的产品。 本文并非包含所有产品版本。
查看其他资源

症状

如何处理 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 或者用户容量也很高。

通常，当 GC 失败且 OS 容量超过 89% 时，MSG_ERR_DISKFULL 将 OS 容量视为较高。如果作系统容量完全低于 89%，则不会影响任何维护作业。 

 
提醒：预计作系统容量全天都在波动。验证日常维护作业是否顺利运行非常重要，通常是尽可能避免作系统容量问题的最佳解决方案。
 
提醒：虽然以上内容被视为 Avamar作系统容量，但可能存在与备份分区或检查点不直接相关的作系统容量问题。这些是安装了 Linux作系统的磁盘和分区。虽然这些问题不太常见，但它们可能会产生其他影响，下面将对此进行讨论。

原因

由于以下原因的任意组合，Avamar作系统容量可能会增加：

  • 备份数据更改率高，添加“太多太快”
  • 高 GSAN 或“用户容量”，它为作系统容量留出的空间较小，有时甚至会导致更高的更改率
  • 检查点未能成功完成，这会导致输出中显示的“MSG_ERR_DISKFULL”状态。
  • 检查点验证 （hfscheck) 失败或最近未运行，因此最旧的检查点无法滚出或删除
  • 由于其他原因（包括检查点保留设置过高），检查点未滚存
 

其他磁盘分区上的高作系统容量可能由多种原因引起，包括数据放置不正确、日志文件变得过大等。

 
将短语“太多太快”作为高作系统容量的原因的快速解释可按如下方式解释：
  • 简单介绍一下背景信息，Avamar 检查点是只读快照和实时数据链接。由于这是使用链接创建的，因此检查点在创建后会立即使用零额外的磁盘空间。如果实时数据没有更改，则检查点不会使用额外的空间。
  • 当修改实时数据而检查点保持不变时，这种情况会发生变化。此时，检查点中有数据的原始副本和已修改数据的更新实时副本。这完全是故意的。这就是保留作系统容量空间的原因。
  • 但是，如果更改数据的数量或速率突然大幅增加，这可能会导致作系统容量大小出现罕见的峰值，并被视为“太多太快”
  • 而 capacity.sh 在比较几天的输出时，工具会将此显示为原因。

解决方案

如果维护作业（包括垃圾数据收集）因 Avamar OS 容量高而失败，请执行以下步骤：

1.收集所有 Avamar 容量信息以描绘情况：Avamar：如何收集对容量问题进行故障处理所需的信息。


2.接下来，查看作系统容量有多高以及可能需要执行哪些作。在数据收集文章中，可以使用以下命令找到此信息： 

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

Avamar 的工作原理是，显示的 fs-percent-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 容量故障处理、问题和疑问 — 所有容量（解决方案路径）

 

受影响的产品

Avamar, Avamar Server
文章属性
文章编号: 000169014
文章类型: Solution
上次修改时间: 12 3月 2025
版本:  7
从其他戴尔用户那里查找问题的答案
支持服务
检查您的设备是否在支持服务涵盖的范围内。