Avamar 空间回收过程 — 第 2 部分:处理
Summary: 本文介绍了 Avamar 空间回收的“处理”部分。 处理是一个关键的后台过程,它获取现有条带并操作其中的数据,以高效地重复利用空间。
Symptoms
本文重点介绍处理,即准备垃圾数据收集的条带以供重复使用的活动。
下面列出了完整系列的“Avamar 空间回收”文章。
本文介绍:
- 在 Avamar“处理”维护过程中会发生什么情况。
- 为什么 Avamar 系统需要定期“处理”条带。
受众:
本文面向支持或管理 Avamar 系统的人员。它说明了 Avamar 的维护操作如何协同工作,以存储、保护和清除系统中过期的数据。假设读者熟悉 Avamar 维护计划、数据如何存储在 Avamar 系统上以及如何构建数据条带。它还假定读者阅读并理解了本系列中讨论 Avamar 垃圾数据收集的第一篇文章。
当处理性能不理想时,通常会遇到以下症状:
-
高检查点开销
-
备份性能较慢
本文讨论: -
- 什么是处理
- 为什么运算很重要
- 对处理工作原理的概述
- 运行运算的两种方法
- 异步处理
- 同步处理
- 可防止异步处理发生的情况
- 与处理相关的故障排除和有用的命令
- 参考资料、进一步阅读相关知识库文章
Cause
Resolution
Avamar 中的“处理”是什么?
垃圾数据收集可识别任何备份不再引用的数据。
区块标头描述符经过修改,以指示应删除哪些区块。包含这些区块的数据条带保持不变。
删除这些区块是处理操作的一个副作用。
处理是一项 Avamar 维护操作,它修改垃圾数据收集的条带,以便使这些条带中的可用空间连续存在。
通过操作条带使其可用空间连续,Avamar 可高效地为传入的备份数据重复使用空间。
想一想以类似于传统硬盘碎片整理的方式进行处理。
数据必须从一个位置移动到另一个位置,以便能够更高效地重复使用数据 容器 。
磁盘碎片整理实用程序将相关数据元素移动到旋转硬盘的相邻部分,以加快顺序访问时间。
但是,运算会将数据移到条带底部,以便为新传入区块腾出空间。
类比:
想象一下,一条总线只有一个前门,没有出口门。人员(区块)使用前门进入总线。
这是一条特殊的总线,人们只能使用星际迷航“Beam me up Scotty”技术离开。
总线将完全启动。
一旦有多人停用,总线便有空间供更多乘客使用。
在人群离开入口之前,没有其他人能适应。也就是说,朝总线后部“紧逼”,以便在前门附近腾出空间。
为什么运算很重要:
我们讨论了将备份数据写入 Avamar 时会发生什么情况。这解释了为什么处理很重要。
为准备接受备份数据,Avamar 会在具有最连续可用空间的每个数据节点上选择条带。条带标记为活动条带。
任何新传入的备份数据都添加到活动条带中。
当条带变满时,下一个最少的完整条带将标记为活动条带。
想象一下发生故障不足的系统。
“可运算”条带(垃圾收集但尚未进行处理)可能相对为空。
如果另一个条带具有更连续的可用空间,则不会选择此相对空的条带作为活动条带。
在下图中,图表中的两个条带均已收集垃圾,但仅处理了数据条带 2,
尽管数据条带 1 更空,但条带 2 具有更有用的连续空间。
Avamar 选择条带 2 作为活动条带。
随着 Avamar 存储利用率的提高,将从日益完整的条带池中选择活动条带。
如果运算过期,则条带的重复利用效率低下。
即使该数据量保持不变,平均一天也需要更多条带来捕获传入数据。
使用更多条带来捕获数据会导致比条带更高效地重复使用更高的检查点开销。
因此,请始终确保 Avamar 有机会定期执行足够的处理。
处理工作原理是什么?
当系统在条带上执行处理时,它会:-
-
将数据从 cur 目录中的条带文件读取到内存中。
-
确定区块标头引用的区块。
-
将条带文件和区块标头重写到磁盘。条带文件仅填充区块标头引用的项目。
修改条带文件会中断其硬链接,从而提高文件系统利用率。
从 Avamar 版本 5.0 及更高版本开始,条带在处理后保持全尺寸。这有助于避免随着时间的推移发生文件系统碎片。
何时会发生处理?
异步处理 — 执行处理的默认方法和首选方法。
异步运算在“中断窗口”的后半部分运行,在垃圾数据收集超时之后,仅在以下情况下运行;
-
如果 asynccrunching 参数设置为 true。
-
如果存在可处理的条带*。
-
如果我们尚未达到关键目标或每日限制*。
-
如果系统处于空闲状态*(没有正在进行备份或其他维护)。
-
如果系统可写,并且尚未达到 disknoflush。
异步运算是一种抢占性操作。
它使用专用时间和资源在备份窗口之前准备条带。
请参阅附加的图表 blackout-window.jpg ,其中说明了这一点。
运算工作能执行多少工作?
预准备条带以便在中断窗口期间使用,使 Avamar 能够在备份计划期间尽快接收数据。
处理会更改条带的内容。大量处理会导致与存储在“cur”目录中的数据存在较大差异。
这会导致检查点开销增加,并增加数据节点 数据/ 分区中的空间消耗。
Avamar 预测必须准备多少条带才能容纳第二天的预期传入数据量。
计算基于前一 N 天的移动平均值(例如,N 最多为 10 或 14)。
这种自我调整机制使 Avamar 能够处理足够的条带,以便备份能够以最佳方式执行,而不会导致不必要的检查点开销。
我们现在可以理解,如果系统更改率突然增加,Avamar 需要几天时间才能逐渐采用更高的运算限制。
如果异步处理未准备足够的条带,则通过同步处理来处理此问题。
同步处理:
如果异步运算无法预先准备足够的条带,或者如果异步运算参数设置为 false,则运算将与备份同步运行。
这种处理模式也称为 按需 运算,如果条带可处理且准备好成为节点的活动条带,则在需要时运行并在条带上运行。
允许处理与备份同步运行意味着磁盘 I/O 资源的竞争日益激烈。
在繁忙的系统上,这可能会导致备份作业需要更长时间才能完成。
我们可能会选择将 Avamar 设置为仅在系统遇到高检查点开销的情况下执行同步处理。如果这样做,请告知客户为什么我们认为有必要这样做,并解释取舍。
A 两种处理模式的摘要:
异步处理:
- Avamar Server 参数设置为 asynccrunching=true。
- 如果接收了正常一天的数据,则备份性能更高。
- 更高的检查点开销。
- 默认操作模式。
- 可能会被禁用,以帮助在高操作系统容量情况下降低检查点开销。
同步处理:
- Avamar Server 参数设置为 asynccrunching=false
- 根据需要运行
- 更低的检查点开销要求
- 备份时间可能更长
- 不是默认操作模式
什么可以防止异步处理发生?
asynccrunching config 参数为 false。
-
正在进行备份
-
已达到每日限制
-
服务器为只读服务器
-
服务器运行级别低于“admin”
-
条带转换正在进行中
-
已达到 disknoflush 限制
-
应用它的 Avamar Server 正在运行 hfscheck 实例(有时称为 CGSAN)
-
HFScheck 正在启动
Additional Information