Data Domain：如何解决 Data Domain Restorer (DDR) 上空间利用率高或可用容量不足的问题

 

• 这是新近接收的文件/数据所在的磁盘区域，并且在大多数 DDR 上，文件将保留在此处，直到客户端备份应用程序使其过期或将其删除为止
• 在配置了延长保留 (ER) 或长期保留 (LTR) 的 DDR 上，您可以定期运行数据移动进程，将旧文件从活动层迁移到归档层或云层
• 回收活动层中被已删除/迁移的文件所使用的空间的唯一方法是运行垃圾收集/清理进程 (GC)

• 活动层的可用空间可能即将耗尽，导致显示以下方面的警报/消息：

• 如果活动层的空间已 100% 填满，则新数据无法写入 DDR，这可能会导致备份/复制失败 — 在此情况下，可能会显示以下方面的警报/消息：

• 在某些情况下，活动层空间填满可能会导致 Data Domain 文件系统 (DDFS) 变为只读，此时您无法删除现有文件

• 解释活动层空间可能已填满的原因
• 介绍一组可执行的简单检查，以确定活动层利用率高的原因及其相应的补救步骤

• 本文并非详尽无遗（即，可能有少数 DDR 活动层利用率变得很高/空间被填满的情况的相应原因未能在此文档中进行讨论），但是本文旨在介绍大多数常见的原因/问题
• 本文不涉及归档层或云层的高利用率情况

  DDR 的活动层的利用率可能高于预期，原因有很多：

• 由于保留策略或备份应用程序配置不正确，客户端备份应用程序未正确地使备份文件/存储集过期，或者未正确地将其删除
• 复制滞后导致大量旧数据保留在活动层上等待复制到副本
• 正在写入活动层的数据的总体压缩比低于预期
• 系统大小未正确规划好，即，对于试图存储在系统上的数据量来说，它太小了
• 备份由大量非常小的文件组成 — 这些文件占用的空间比最初写入时预计的要大得多，然而，此空间在清理/垃圾收集期间应该被回收
• 数据移动未在配置了 ER/LTR 的系统上定期运行，导致应迁移到归档/云层的旧文件保留在活动层上
• 清理/垃圾收集未定期运行
• DDR 上存在过多或老旧的 mtree 快照，阻止清理操作从已删除的文件/数据回收空间

步骤 1 — 确定是否需要运行活动层清理

Data Domain 操作系统 (DDOS) 尝试为活动层维护名为“Cleanable GiB”的计数器。这是对通过运行清理/垃圾收集在活动层中可能回收多少物理（压缩后）空间的估计。此计数器由“filesys show space'/'df”命令显示：
 
如果出现以下任一项：

• “Cleanable GiB”的值很大
• DDFS 已经变成 100% 填满（因此是只读的）

在继续执行本文档中的任何其他步骤之前，应执行清理并允许其运行至完成。要开始清理，应使用“filesys clean start”命令，即：
 
要确认清理是否按预期方式启动，可以使用“filesys status”命令，即：
 
请注意：

• 如果清理无法启动，请联系您的签约支持提供商，以获得进一步的帮助 — 这可能表示系统遇到“缺失段错误”，导致清理遭到禁用
• 如果清理已在运行中，那么在尝试启动它时，将会显示以下消息：

• 在清理操作到达其复制阶段（默认情况下，DDOS 5.4.x 及更低版本中的阶段 9、DDOS 5.5.x 及更高版本中的阶段 11）之前，活动层中的空间都不会被释放/回收。有关清理所使用的阶段的更多信息，请参阅：https://support.emc.com/kb/446734
• 清理可能无法回收“Cleanable GiB”指示的空间量，因为此值本质上是个估计值。有关这方面的更多信息，请参阅：https://support.emc.com/kb/485637
• 清理可能无法在一次运行中就回收所有潜在空间 — 这是因为在包含非常大的数据集的 DDR 上，清理将针对包含最为多余的数据的文件系统部分进行工作（即，在清理操作运行所花费的时间里提供最佳的可用空间回报）。在某些情况下，回收所有潜在空间之前，可能需要多次运行清理操作
• 如果“Cleanable GiB”的值非常大，这可能表示清理没有定期运行 — 检查是否设置了清理计划：

在清理完成后，使用“filesys show space'/'df”命令来确定是否已解决利用率问题。如果利用率仍然很高，请继续执行本文中的其余步骤。

步骤 2 — 针对源复制上下文检查是否存在大量的复制滞后

本机 Data Domain 复制是围绕“复制上下文”的概念设计的。例如，当需要在系统之间复制数据时：

• 在源和目标 DDR 上创建复制上下文
• 初始化上下文
• 初始化完成后，复制会定期将更新/增量更新从源发送到目标，以使系统上的数据保持同步

如果源复制上下文滞后，则可能会导致旧数据保留在源系统的磁盘上（请注意，滞后的复制上下文不会在目标系统上导致过度使用）：

• 目录复制上下文（在系统间复制 /data/col1/backup 下的单个目录树时使用）：

•  Mtree 复制上下文（在系统间复制除 /data/col1/backup 之外的任何 mtree 时使用）：

• 集合复制上下文（在将一个 DDR 的整个内容复制到另一个系统时使用）：

 要确定复制上下文是否滞后，应执行以下步骤：

• 确定当前系统的主机名：

• 确定当前系统上的日期/时间：

• 列出系统上配置的复制上下文及其“同步截止时间”。请注意，感兴趣的上下文是“目标”不包含当前系统的主机名（这表示当前系统是源）且“同步截止时间”是非常早的时间的那些上下文：

当前系统为源且明显滞后的上下文或不再需要的上下文应该被断开。这可以通过在源系统和目标系统上运行以下命令来执行：
 
例如，为了断开上面显示的“有趣的”上下文，将在源和目标上运行以下命令：
 
请注意：

• 一旦上下文被断开，就需要执行活动层清理，以回收活动层中的潜在空间
• 如果在上下文被断开后使用 mtree 复制，则 mtree 复制快照可能会保留在磁盘上。在运行清理之前，确保执行步骤 5，以使所有多余的快照过期
• 如果源/目标 mtree 已配置为将数据迁移到归档或云层，则在断开相应的 mtree 复制上下文时应格外小心，因为这些上下文将来可能无法再次重新创建/初始化。这方面的原因是，初始化 mtree 复制上下文时，将在源系统上创建 mtree 快照，并且该快照包含 mtree 中所有文件的详细信息（与层无关）。然后此快照被完全复制到目标的活动层。结果，如果目标的活动层没有足够的可用空间接收来自源的所有 mtree 数据，初始化将无法完成。有关此问题的更多信息，请与您的签约支持提供商联系
• 如果集合复制上下文被断开，则在不首先销毁目标 DDR 上的 DDFS 实例（并丢失此系统上的所有数据）的情况下，将无法重新创建/初始化该上下文。结果，后续的初始化可能会占用大量时间/网络带宽，因为来自源的所有数据都必须再次以物理方式复制到目标

步骤 3 — 检查是否有不再需要的 mtree

DDFS 的内容在逻辑上被划分为 mtree。单个备份应用程序/客户端写入单个 mtree 是很常见的。如果备份应用程序已停用，它将不再能够向 DDR 写入数据或从中删除数据，这样可能会在系统上留下老旧/多余的 mtree。这些 mtree 中的数据将使用 DDR 上的磁盘空间无限期地继续存在。因此，您应该删除任何此类多余的 mtree。例如：

• 获取系统上的 mtree 列表：

• 应使用“mtree delete”命令删除不再需要的任何 mtree，即：

• 下次运行活动层清理/垃圾收集时，将回收已删除的 mtree 在磁盘上占用的空间。

请注意：

• 作为 mtree 复制目标的 mtree（即，在 mtree 列表的输出中具有 RO/RD 状态）应该在您删除 mtree 之前断开其相应的复制上下文
• 用作 DDBoost 逻辑存储单元 (LSU) 或虚拟磁带库 (VTL) 池的 mtree 可能无法通过“mtree delete”命令进行删除 — 有关删除此类 mtree 的更多详细信息，请参阅《Data Domain Administration Guide》（Data Domain 管理指南）
• 针对保留锁定进行配置的 mtree（即，具有 RLCE 或 RLGE 状态）不能删除 — 相反，mtree 中的单个文件必须恢复并单独删除任何保留锁定 — 有关更多详细信息，请参阅《Data Domain Administration Guide》（Data Domain 管理指南）

步骤 4 — 检查是否有老旧/多余的 mtree 快照

Data Domain 快照表示相应 mtree 的时间点快照。因此：

• 创建快照时 mtree 中存在的任何文件都将被快照引用
• 虽然快照即使在这些文件被移除/删除后仍然继续存在，但清理将无法回收它们在磁盘上使用的任何物理空间 — 这是因为数据必须留在系统中，以防将来访问快照中的文件副本

要确定任何 mtree 是否有老旧/多余的快照，应执行以下步骤：

• 使用“mtree list”命令获取系统上的 mtree 列表，如步骤 3 所示
• 使用“snapshot list”命令列出对于每个 mtree 来说都存在的快照：

• 在快照存在的情况下，使用出自“snapshot list mtree [mtree name]”的输出来确定以下方面的快照：

• 如果您再次运行 snapshot list 命令，则这些快照现在将列示为“expired”：

请注意：

• 无法确定单个快照或一组快照在磁盘上保留多少物理数据 — 与快照关联的“空间”的唯一值是创建快照时 mtree 的压缩前（逻辑）大小的指示（如以上输出所示）
• 名为“REPL-MTREE-AUTO-YYYY-MM-DD-HH-MM-SS”的快照由 mtree 复制管理，在正常情况下应该不需要手动过期（当不再需要这些快照时，复制将自动使它们过期）。如果此类快照极其老旧，则表示相应的复制上下文可能会显示出明显的滞后（如步骤 2 中所述）
• 当 mtree 复制上下文断开时，mtree 复制将创建名为“REPL-MTREE-RESYNC-RESERVE-YYYY-MM-DD-HH-MM-SS”的快照。它们的意图是，如果您以后重新创建断开的上下文（例如，如果该上下文错误地断开），则可以使用它们来避免复制数据的完全重新同步。如果您不重新建立复制，则可以如上所述手动地使这些上下文过期
• 过期的快照将继续存在于系统上，直到下次运行清理/垃圾收集为止 — 此时，它们将被物理删除，并将从“snapshot list mtree [mtree name]”的输出中删除 — 然后，清理可以回收这些快照在磁盘上使用的任何空间

步骤 5 — 检查系统上是否存在意外数量的旧文件

来自 DDR 的自动支持包含直方图，显示了 DDR 上按保留期限排列的文件的细分 — 例如：
 
对于确定系统上是否存在未如预期那样由客户端备份应用程序使之过期或将其删除的文件，这很有用。例如，如果上述系统由备份应用程序写入，其中任何一个文件的最长保留期为 6 个月，那么很明显，备份应用程序没有如预期的那样使文件过期或删除文件，因为 DDR 上大约有 80,000 个文件的保留期超过 6 个月。

请注意：

• 备份应用程序负责执行所有文件过期/删除操作
• DDR 永远不会自动使文件过期或删除文件 — 除非备份应用程序指示显式删除文件，否则文件将继续存在于 DDR 上，并无限期地使用空间

因此，此类问题应首先由备份应用程序供应商支持团队进行调查。

如果需要，Data Domain 支持人员可以提供额外的报告，以便进行下列操作：

• 提供 DDR 上按保留期限排序的所有文件的名称/修改时间（这样就可以确定任何旧数据的名称/位置）
• 为活动/归档/云层（在其中启用了 ER/LTR 功能）将文件保留期限的直方图拆分为单独的报告

要执行此操作：

• 按照本文档注释部分的“Collecting sfs_dump”段落中的说明收集证据
• 向您的签约支持提供商提出服务请求

删除老旧/多余的文件后，需要运行活动层清理/垃圾收集，以物理回收活动层中的空间

步骤 6 — 检查是否存在包含大量小文件的备份

由于 DDFS 设计的缘故，小文件（基本上是小于大约 10Mb 大小的文件）在最初写入 DDR 时会占用过多的空间。这是由“SISL”(Stream Informed Segment Layout) 体系结构造成的，它导致小文件占用磁盘上多个单独的 4.5Mb 空间块。例如，4Kb 文件在最初写入时实际上可能会占用高达 9Mb 的物理磁盘空间。

随后，在运行清理/垃圾收集时，将会回收这类被过多占用的空间（因为来自小文件的数据接着会聚合到数量较少的 4.5Mb 块中），但在运行此类备份时，可能会导致较小型号的 DDR 显示出过度使用和填充情况。

自动支持包含按大小细分的文件的直方图，例如：
 
如果有证据表明备份写入大量的小文件，那么在每次调用清理/垃圾收集之间，系统可能会受到显著临时增加的利用率的影响。在此情况下，最好更改备份方法，将所有小文件纳入到一个较大的归档（例如，tar 文件），然后才将它们写入 DDR。请注意，任何此类归档都不应该进行压缩或加密（因为这将损害该数据的压缩比/重复数据消除率）。

步骤 7 — 检查是否有低于预期的重复数据消除率

DDR 的主要用途是对设备接收的数据进行消除重复和压缩。重复数据消除率/压缩比在很大程度上取决于系统的应用场景和它所保存的数据类型，但是在许多情况下，根据通过概念验证测试或类似测试获得的结果，将会有一个“预期的”总体压缩比。要确定系统的当前总体压缩比（以及它是否符合预期），您可以使用“filesys show compression”命令。例如：
 
在上面的示例中，系统正在为活动层实现 65.3x 的总体压缩比（这是非常好的结果）。但是，如果此值表明总体压缩比未达到预期，则可能需要进一步调查。请注意，调查低于预期的压缩比是复杂的课题，该问题可能有许多根本原因。有关进一步调查的更多信息，请参阅以下文章：https://support.emc.com/kb/487055

步骤 8 — 检查系统是否是集合复制的源

使用集合复制时，如果源系统在物理规格方面大于目标系统，则源系统的大小将被人为地限制为与目标系统的大小相匹配（即，源系统上有磁盘区域将被标记为不可用）。此问题的原因是：在使用集合复制时，目标需要是源的块级副本，但是，如果源在物理规格方面大于目标，则有可能会将过多的数据写入源，然后又无法将其复制到目标（因为它的空间已填满）。通过将源的大小限制为与目标大小相匹配，您可以避免这种情况。

• 使用步骤 2 中的命令，检查系统是否是集合复制的源。要执行此操作，请运行“replication status”，并确定是否存在以“col://”（表示集合复制）开头的复制上下文，这类上下文在目标中不包含本地系统的主机名（表示此系统一定是复制上下文的源）
• 如果系统是集合复制的源，请登录到两个系统并运行“filesys show space”命令，检查每个系统活动层的大小 — 比较每个系统上活动层的“压缩后”大小
• 如果源明显大于目标，则其活动层大小将受到人为限制
• 要使源上的所有空间可用于数据，您应该执行以下操作：

步骤 9 — 检查数据移动是否定期运行

如果 DDR 已配置了延长保留 (ER) 或长期保留 (LTR)，则它将连接有第二个存储层（对于 ER，此层是归档层；对于 LTR，此层是云层）。在此情况下，可能会针对 mtree 配置数据移动策略，以将需要长期保留的较旧/未修改数据从活动层迁移到备用存储层，以便活动层中这些文件所使用的空间可以通过清理/垃圾收集进行物理回收。如果数据移动策略配置不正确，或者数据移动过程没有定期运行，则旧数据在活动层中的保留时间将超出预期，并且会继续使用磁盘上的物理空间。

• 首先，通过运行“filesys show space”并检查归档层或云层是否存在，确认系统是否已针对 ER 或 LTR 进行配置 — 请注意，要使这些备用存储层可用，其压缩后大小必须超过 >0Gb：

• 如果系统配置了 ER/LTR，请对照 mtree 检查数据移动策略，确保这些策略如预期那样工作，并进行相应设置，以便将旧数据推送到备用存储层：

• 如果系统配置了 ER/LTR，请检查是否已安排定期运行数据移动，以便以物理方式将文件/数据从活动层迁移到备用存储：

• 如果系统已针对 ER/LTR 进行配置，请检查上次运行数据移动的时间：

• 数据移动完成后，您应该运行活动层清理（请注意，它可能已配置为在数据移动完成时自动启动），以确保我的已迁移文件在活动层中使用的空间被物理释放：

步骤 10 — 向活动层添加更多存储空间

如果前面的所有步骤都已执行，则活动层清理会运行到完成为止，但是活动层上的可用空间仍然不足，系统可能没有针对将要接收的工作负载正确规划其存储空间大小。在此情况下，您应执行以下操作之一：

• 减少会影响系统的工作负载 — 例如：

• 向系统的活动层添加更多存储空间并扩展其大小：

Data Domain 支持人员可以生成许多报告，这些报告显示以下信息，例如：

• 按保留期限排序的特定层（即，活动/归档/云）中所有文件的列表
• 按 mtree/主要目录树列出的估计大小和压缩比
• 按保留期限排序的特定 mtree 中所有文件的列表
• 等等

为此，应收集以下信息：

• 来自 DDR 的全新支持包 — 有关更多信息，请参阅以下内容：https://support.emc.com/kb/323283
• “sfs_dump”或“sfs_dump -c”的输出：

• 文件位置报告（如果系统已针对 ER 或 LTR 进行配置，则此项是必需的）：

要在收集上述内容或执行此归档清理的任何步骤时获得帮助，请联系您的签约支持提供商。