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

本文假定读者熟悉《Avamar Operational Best Practices Guide》（Avamar 操作最佳实践指南）中的“Managing Capacity”（管理容量）部分。

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

影响“操作系统容量”过高或是“操作系统容量”过高症状的常见问题是：

• 检查点验证 (hfscheck) 失败。
• 垃圾收集无法运行，并报告 MSG_ERR_DISKFULL。
• 检查点创建失败。

与“用户容量”过高密切相关的常见症状是：

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

请参阅“解决方案”部分。

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

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

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

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

为了使垃圾数据收集和异步条带处理等维护任务能够正确运行，数据分区中还需要具有可用空间。

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

 

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

在上图中，我们看到数据分区中的空间使用情况的简要图形表示。

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

如果任何数据分区占用的空间超过总空间的 85%，则垃圾数据收集无法运行。

100% 用户容量标记（只读限制）指示数据分区中多达 65% 的总空间可用于存储已消除重复数据的数据。此 100% 用户容量标记下面的空间相当于管理员 UI 中可见的服务器利用率值。如果存储在任何节点的任何数据分区上的已消除重复数据的数据量达到 65%，则 Avamar 系统将变为只读，并拒绝进一步备份数据。

现在我们可以了解到，通过 Avamar 管理员 UI，用户能够看到备份所占用的空间，但无法看到操作系统数据分区中已占用的空间。

 

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

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

关于为什么会这样的全面讨论超出了本文的范围，但是要记住的重要事情是：Avamar 系统的用户容量越接近 100%，可用于检查点开销的操作系统容量就越少。

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

要使 Avamar 系统在“用户容量”处于高位时可靠地运行，它必须满足以下标准：

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

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

 

造成检查点开销的因素：

以下因素可能会导致检查点开销增加。

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

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

 

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

监视操作系统数据分区利用率的正确方法是从 Avamar 实用程序节点使用以下 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 管理员 GUI 中检查服务器利用率值，并发现该值是可接受的，例如 60%。

用户可以尝试从 Avamar GUI 的备份管理界面中删除备份。即使用户容量处于高位，删除备份也不会使情况得到缓解，因为垃圾收集无法运行，也无法从系统中删除过期的数据块。

如果系统同时遇到操作系统容量处于高位的问题以及用户容量处于高位的问题，请首先集中精力解决操作系统容量处于高位的问题。

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

 

是什么导致 MSG_ERR_DISKFULL 消息？

最典型的原因是检查点开销过高。检查点开销高的典型原因可能是：

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

请参阅以下文章，以帮助解决 MSG_ERR_DISKFULL 情况：由于数据分区操作系统容量超过 89%，Avamar 维护任务失败并显示“MSG_ERR_DISKFULL”>。

 

用于对操作系统容量处于高位的情况进行调查并帮助使其得到缓解的操作。

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

• 在 Avamar 管理员界面中，转至 Server > Checkpoint Management 选项卡
• 检查 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

 

2.确认 HFScheck 是否已运行或是否已失败。

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

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 消息，则需要向戴尔技术支持团队寻求帮助。
• 否则，如果操作系统容量很低，足以允许完成垃圾收集，则致力于降低“用户容量”，并使“服务器利用率”数值下降。

 

 

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

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

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

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

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

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

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

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

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

一旦 Avamar 系统接近容量上限，我们应该立即停止添加新客户端，以防止情况恶化。

如果您的另一个 Avamar 网格的服务器利用率较低，请考虑向该网格（而不是将要填满的服务器）添加新的客户端。


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

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

capacity.sh 脚本（从 Avamar 实用程序节点命令行运行）也可用于确定具有最高更改率的客户端。

注册的戴尔客户可以使用链接访问文章 Avamar 中的内容：如何使用 capacity.sh 脚本管理容量 了解有关如何使用 capacity.sh 脚本的更多详细信息。

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

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

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

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

戴尔用户可以使用以下文章的链接来访问该内容：Avamar 容量管理：如何使用“modify-snapups”工具批量删除备份或使备份过期。

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

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

如果“Net Change”值没有变为负数，请检查垃圾收集日志，查看垃圾收集的实际运行时间以及在维护窗口中完成的工作量。

注册的戴尔客户可以使用链接访问文章 Avamar 中的内容：如何使用 capacity.sh 脚本管理容量了解有关如何使用 capacity.sh 脚本的更多详细信息。

Avamar 系统的高利用率通常是由于数据的自然增长和预期增长造成的。要继续进行生产备份，必须提供更多空间。

如何完成此操作取决于 Avamar 系统的类型。

• 单节点系统和 Avamar Virtual Edition (AVE) 系统

这些无法进行扩展。可采用第二个较大的 Avamar 系统，并请求戴尔专业服务人员执行从较小系统到较大系统的系统迁移。您可以通过戴尔客户经理联系专业服务人员。

新系统可以是单节点、AVE 或多节点系统，只要它提供比源更多的存储空间即可。

• 多节点系统

最多可将这些系统扩展到 16 个数据节点。有关详细信息，请联系戴尔客户经理。常规支持渠道无法进行节点添加，因此您不应该开出服务请求工单来请求此项工作。

• 集成 Data Domain

将 Data Domain 系统集成为后端存储设备是扩展备份到 Avamar 的客户端可用容量的一种有用方法。与您的戴尔客户经理讨论选项。

有用的工具

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

最佳实践：

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