Avamar：容量管理概念和培训

有关与 Data Domain 相关的容量管理问题，请参阅《Avamar and Data Domain System Integration Guide》（Avamar 和 Data Domain 系统集成指南）中的“Reclaiming storage on a full Data Domain system”（在完整 Data Domain 系统上回收存储）部分。

您可在以下文章中找到与您的操作环境相关的指南：如何在戴尔支持站点上找到 Avamar 文档。

• 汇总在 /data* 分区中存储的数据类型。
• 介绍“操作系统 （OS） 容量”的概念，并将其与“用户容量”（有时称为”GSAN 容量。
• 解释为什么不应在接近用户容量上限的情况下运行 Avamar。
• 列出会造成检查点开销的因素。
• 描述如何监视数据分区利用率。
• 描述操作系统容量失控时出现的症状。
• 列出 MSG_ERR_DISKFULL 消息的典型原因。
• 概述在高操作系统容量影响正常系统操作时使用的恢复方法。
• 描述用户容量超过用户容量上限时出现的症状。
• 讨论如何从高用户容量情况中恢复。

本文假定读者熟悉《Avamar 操作最佳做法指南》中的“管理容量”部分。

同样，您可以在此处找到与您的操作环境相关的指南：如何在戴尔支持站点上找到 Avamar 文档。

影响高操作系统容量的常见问题或症状包括：

• 检查点验证 （hfscheck） 失败。
• 垃圾数据收集无法运行并报告 MSG_ERR_DISKFULL。
• 检查点创建失败。

• 备份失败。
• 传入复制作业失败。
• 在备份窗口期间，管理员界面以“管理员”模式显示系统。

本文提供有关 Avamar 容量管理概念和培训的概念。

数据如何存储在 Avamar 网格上？

Avamar 容量管理涉及位于所有 Avamar 数据节点的 /data* 分区中的数据。

• 已消除重复数据的备份数据
• RAIN 奇偶校验数据
• 检查点开销数据

除了 RAID 和复制之外，RAIN 奇偶校验和检查点数据都是 Avamar 可用的冗余层。

数据分区中还需要可用空间，以便执行维护任务（如垃圾数据收集 （GC） 和异步条带处理）正常运行。

下面是 Avamar 存储节点上的数据分区内可用的物理存储空间的图形表示。

数据如何存储在数据分区中？

在上图中，简单展示了如何在数据分区中使用空间。

左侧的 100% 值定义为数据分区中的操作系统可用的物理空间总量。

• 100% 用户容量标记（只读限制）表示数据分区中总空间的最多 65% 可用于存储经过重复数据消除的数据。
• 此 100% 用户容量标记下面的空间相当于管理员 UI 中可见的服务器利用率值。

如果存储在任何节点上的任何数据分区上的已消除重复数据量达到 65%，则 Avamar 变为只读状态并拒绝进一步的备份数据。

综上所述，可以理解，从 Avamar Administrator UI 中，用户可查看备份已占用的空间，但无法查看操作系统数据分区中已使用的空间。

为什么不应在接近“用户容量”上限的情况下运行 Avamar 系统：

处于高位的“用户容量”与检查点开销之间的关系是这样的：当系统变得越来越满时，即使备份数据的少量增加也会导致检查点开销的大量增长。

关于为什么会出现这种情况的完整讨论超出了本文的范围，但是要记住的重要一点是：当 Avamar 系统接近 100% 用户容量时，可用于检查点开销的操作系统容量越少。

在完整系统上，如上图所示，检查点开销限制为数据分区中总操作系统空间的 20%。

• 系统必须具有较低的每日更改数据率（不高于 1%。）
• 如《Avamar Operational Best Practices Guide》（Avamar 操作最佳实践指南）的“Managing Capacity”（管理容量）部分所述，容量必须处于稳定状态。您可在以下文章中找到与您的操作环境相关的指南：如何在戴尔支持站点上找到 Avamar 文档。
• 维护任务应每天成功完成。

如果这些语句中的任何一个从 true 变为 false，则检查点开销预计可能会逐渐增加或突然大涨，并导致严重的操作问题。

造成检查点开销的因素：

• 条带的异步处理（默认情况下已启用）
• 系统上存储的检查点的数量
• 检查点验证未每天成功完成。
• 当 Avamar Server 重新使用空条带时，空条带会怎么样（情况将会随着服务器利用率的提高而变得越来越严重）。
• 每日备份更改率

系统管理员对这些因素拥有一定程度的控制权。异步处理的配置仅用于支持，但管理员可以删除过多的检查点，调查检查点故障并影响服务器利用率和每日数据更改率。

如何监视数据分区利用率：

监视操作系统数据分区利用率的正确方法是从 Avamar 应用工具节点使用以下 Avamar 命令：

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 命令没有意义，因为条带是在文件池中预先分配的，而且许多条带可能没有在使用中。

如果操作系统容量使用失控，那么会发生什么事情？

从用户的角度来看，当数据分区利用率上升到 89% 以上时，就会出现数据分区利用率失控的第一个迹象。

垃圾数据收集无法再运行并失败，并显示 MSG_ERR_DISKFULL 错误消息。

以下是经常发生误解的地方：用户经常将 MSG_ERR_DISKFULL 表示系统不再有备份空间的消息。

此解释不正确，但是，用户通常会检查 Avamar Administrator UI 中的服务器利用率值，并查找可接受的值，例如 60%。

用户可以尝试从 Avamar UI 的备份管理界面删除备份。即使用户容量级别很高，删除备份也不会缓解这种情况，因为垃圾数据收集无法运行并从系统中删除过期的数据块。

如果系统同时遇到高操作系统容量问题和高用户容量问题，请首先专注于解决高操作系统容量问题。 

在操作系统容量利用率高的情况下，系统可能会缺少空间来创建检查点。

是什么导致 MSG_ERR_DISKFULL 消息？

• 检查点验证 （hfscheck） 反复失败。
• 通过 hfscheck 失败有许多可能的根本原因（突然取消、软件故障等）。
• 系统运行太满，每日数据更改率太高。
• 系统需要更多数据节点来处理数据更改率和存储数据。
• 系统配置用于备份的数据或客户端数量超过其容量。
• 存储的检查点过多（Avamar 在默认情况下存储两个检查点，其中一个检查点已经过验证）。
• 系统管理员创建了过多的检查点。
• 最近执行过维护，但没有恢复默认的检查点保留。

请参阅以下文章以帮助解决 MSG_ERR_DISKFULL 场景：Avamar：由于一个或多个数据分区的操作系统容量超过 89%，维护任务失败并出现MSG_ERR_DISKFULL

调查和帮助缓解高操作系统容量的操作：

1.确定上次 hfscheck 完成。要执行此操作，请使用 Avamar 实用程序节点上的 Avamar 管理员或命令行。

• 在 Avamar Java Administrator UI 中：
  • 转至“服务器 > 检查点管理”选项卡
  • 检查 Checkpoint Validation 列中列出的最近日期和时间。这应该在过去 24 小时内发生。

-- 或者 --

• 使用 Avamar Utility Node 命令行：
  • 运行命令： cplist。

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 的检查点。
      • 它由紧跟在“有效”标记后面的标记标识。
      • 根据系统上设置的检查点验证类型，标记可以是 rol 或 hfs。
      • 这是 rol （滚动） hfscheck。

如果结果显示最新验证的检查点早于 24 小时，请找出原因。这可能是因为 HFScheck 未运行或因为失败而运行。

2.确认 HFScheck 运行了，或者如果失败：

在 Avamar 应用工具节点上，运行 status.dpn 命令并找到以“Last ”开头的行 hfscheck”的限制。

例如：

Last hfscheck: finished Sat Jan 15, 11:07:17 2011 after 06m 41s >> checked 528 of 528 stripes (OK)

记下其完成时间以及状态（在上面的行中，状态显示为“OK”）。

如果 hfscheck 作业已失败，应立即对此进行调查。

如果 hfscheck 最近未运行，请运行以下命令验证是否已启用维护计划程序”dpnctl status maint“（在 Avamar 应用工具节点上）：。

admin@utilitynode:~/>: dpnctl status maint

Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/admin_key)
dpnctl: INFO: Maintenance windows scheduler status: enabled.

• 如果维护 Windows 计划程序已关闭、禁用或挂起，请使用以下命令将其启用： dpnctl start maint
• （可选）获取新的检查点并运行 hfscheck，或等待下一个计划的维护窗口完成。

一旦 hfscheck 成功完成后（在解决任何问题或重新启动维护计划程序后），最旧的检查点将被“滚下”，操作系统容量应显著减少。

• 如果操作系统容量仍然过高，并且垃圾数据收集继续失败，并且 MSG_ERR_DISKFULL 消息中，然后向戴尔技术支持团队寻求帮助。
• 否则，如果操作系统容量很低，足以允许完成垃圾收集，则致力于降低“用户容量”，并使“服务器利用率”数值下降。

用于缓解高用户容量的操作：

与操作系统容量不同，用户容量级别更容易直接受 Avamar 系统管理员的影响。

1.确保垃圾收集每天都在运行，并且不会被备份中断。

这是最关键的一点，因为如果垃圾数据收集不能定期或可靠地运行，即使是足够大的系统也会遇到高用户容量。

如前所述，确认已启用维护窗口并使用 capacity.sh 和 sched.sh 用于验证垃圾收集是否正在运行以及是否正在删除数据的脚本。

在 Avamar v7.x 之前，备份无法在垃圾数据收集“限制”窗口期间运行。

随 Avamar v7.x 功能引入的哈希引用位图功能允许在 GC 维护活动期间进行备份。此功能要求这些“映射”每天必须至少有 5 分钟的“安静”时间，在此期间不会运行任何备份，以便它们可以重置。

可以使用文章 Avamar 的链接访问有关此功能的内容：从 Avamar v7 起，当数据正在使用时，垃圾数据收集会报告由于“哈希引用位图”而无法清理的“跳过的哈希”。

2.停止向网格添加新客户端。

一旦 Avamar 网格接近容量，请立即停止添加新客户端，以防止情况恶化。

如果存在另一个 Avamar 网格以较低的服务器利用率级别运行，请考虑将新客户端添加到该网格，而不是已满的服务器。

3.了解哪些客户端占用的存储空间最多。

要解决容量问题，请确定哪些客户端负责向 Avamar 系统添加最多数据。

而 capacity.sh 脚本（从 Avamar Utility Node 命令行运行）也可用于确定哪些客户端的更改率最高。

请参阅 Avamar：如何使用 管理容量 capacity.sh 有关如何使用 capacity.sh 脚本。

我们经常发现，“最饥渴的”客户端是那些备份 SQL 数据库或电子邮件服务器的客户端，因此要特别注意这些客户端。

4.重新评估保留策略。

在确定高更改率客户端之后，请重新评估保留策略，查看是否可以降低任何保留策略，以便将存储需求降低到可接受的水平。

如果系统的使用时间足以使保留时间最长的备份到期，则在减少保留策略后，预计每天通过垃圾收集删除的数据量会增加。通过以下方式监测此趋势： capacity.sh。

如果 Avamar 系统还不够老旧，无法开始使备份过期，则您可能需要更改保留策略，以便最旧的备份现在开始过期。

如果由于法规要求而无法减少保留策略，请考虑扩展 Avamar 系统或将客户端迁移到另一个较少使用的 Avamar。

5.将客户端迁移到备用 Avamar 系统。

如果有另一个 Avamar 系统可用，请考虑使用 Avamar Client Manager 界面将大型或高更改率客户端从利用率较高的系统迁移到利用率较低的系统的可能性。

6.删除旧备份。

如果用户容量级别很严重 （>90%），则可能需要通过备份管理界面使旧备份到期，或者使用 modify-snapups 工具。 

戴尔用户可以使用文章 Avamar：容量管理 — 如何使用”modify-snapups“工具

删除备份不会立即降低服务器利用率级别。它的作用是允许垃圾收集在下次运行垃圾收集时开始删除数据。删除旧备份是短期的解决方法。备份将在未来几天内替换。如果您删除备份，则还必须调整保留策略。

7.使用 监视数据更改 capacity.sh。

删除备份并更改保留策略后，请使用 密切监视系统上更改的数据量 capacity.sh 脚本。“removed”数据值应增加，“Net Change”值应变为负数。最终，随着过多的数据从系统中清除，“Removed”值开始恢复到更加正常的水平。继续监视“Removed”值。

如果净更改值未变为负数，请检查 GC 日志以查看垃圾收集运行了多长时间以及它在维护时段内实现了多少工作。

请参阅 Avamar：如何使用 管理容量 capacity.sh 脚本 ，了解有关如何使用 capacity.sh 脚本。

8.扩展 Avamar 系统：

Avamar 网格上的高利用率通常是由于自然和预期的数据增长。必须提供更多空间才能继续进行生产备份。

• 单节点网格和 Avamar Virtual Edition （AVE）：

  • 这些无法进行扩展。可采用第二个较大的 Avamar 系统，并请求戴尔专业服务人员执行从较小系统到较大系统的系统迁移。
    • 可以通过戴尔客户经理接洽专业服务。
  • 新系统可以是单节点、AVE 或多节点系统（如果它提供的存储空间比源系统多）。
• 多节点网格：

  • 最多可将这些系统扩展到 16 个数据节点。
    • 有关详细信息，请联系戴尔客户经理（常规支持通道不添加节点，因此不应打开服务请求来请求此工作。）
• 集成 Data Domain：
  • 将 Data Domain 系统集成为后端存储设备是扩展备份到 Avamar 的客户端可用容量的一种有用方法。
    • 与您的戴尔客户经理讨论选项。

有用的工具

• status.dpn
• capacity.sh
• Avalanche
• DPN Summary Report
• replcnt.sh
• Avamar Client Manager

• 尝试防止 Avamar Server 利用率（用户容量）值上升到 80% 以上。
• 较低的用户容量可提供出色抗风险能力，来应对所添加数据量的意外变化，并且可以防止系统在发生意外故障或维护任务出现短期问题时变得不可用。
• 在用户容量超过 80% 的情况下运行的 Avamar 系统需要系统管理员更加勤奋地监控，确保维护任务成功完成且系统不会变为只读状态。