Data Domain：目录复制和池复制的最佳做法

目录复制的最佳实践

目的

本文定义了配置目录复制的最佳实践。

适用对象

• 所有 Data Domain 系统
• 所有软件版本

建议

1. 将工作负载分布在尽可能多的上下文中。
   理想的单上下文预压缩吞吐量在 200-300MB/秒的范围内。在多流可用的配置中，理想的单上下文性能类似于理想的多上下文性能;但是，有几个变量限制了多流的有效性：

   • 如果源 DDR 具有许多复制上下文，则在上下文之间划分多流流的逻辑会限制可用的流数量。
   • 在基于快照的初始化/恢复期间，多流处于非活动状态。默认情况下，如果源上下文包含超过 100 万个条目，则基于快照的初始化将生效。
   • 从 5.0 开始，引入了多流来复制 CIFS 数据。

   按型号划分的理想多上下文预压缩吞吐量从大约 200MB/秒到 500MB/秒或更高不等。

2. 使用中等大小的文件设计工作负载。
   文件大小可能会对任何复制上下文的整体性能产生重大影响。通常，大小小于 10 MB 的文件无法高效复制。

   此外，当复制对在意外断开连接后重新连接时，源必须从断开连接期间复制的文件的开头重新启动。如果文件非常大，并且频繁断开连接（例如，由于网络不可靠），复制可能会有效地卡住？尝试一遍又一遍地复制同一个文件。这种情况最常见于大小超过 100GB 的文件。文件大小本身不会对性能造成影响。

3. 设计工作负载以利用复制计划。
   文件在内部关闭时会排队等待复制。文件关闭的时间如下所示：

   关闭修改后的文件时，会为该文件生成复制日志“close”记录。复制会将文件中的新数据排入队列以等待发送。如果队列中没有其他复制作（即未处理的日志记录），则会立即发送新数据。否则，将在处理以前的日志记录后复制该文件。

   • 最后一次访问 10 分钟后，NFS 将关闭该文件。
   • 所有文件每小时关闭一次，无论它们最近写入的时间有多近。
   • 如果正在访问或写入许多文件，则文件的关闭时间可能会比上述规则规定的要早。备份软件以较小片段（例如 1 MB）写入文件可能会导致由于生成的文件数量较多而更快地启动复制。

4. 如果可能，请使用专用网络。
   低至 0.1% 的丢包率会严重降低网络吞吐量，特别是对于高带宽延迟网络。对于带宽 <= T2 的网络，最高一秒的 RTT（往返时间）可提供良好的吞吐量。对于 = T3 的 >网络，从 300-500 毫秒的 RTT 开始，吞吐量会显著下降。

   更一般地说，数据包丢失下的吞吐量约为
   Throughput = MSS /（RTT * sqrt（p）），其中 MSS ：= 最小段大小（通常为 1460 字节） RTT ：= 往返时间 p ：= 数据包丢失概率

5. 评估增量复制（低带宽优化）。
   在 DD OS4.8 及更高版本中，增量复制（也称为“低带宽优化”）可以提高可用带宽低于 600 兆位/秒 （Mbps） 的链路中目录或池复制的虚拟吞吐量。增量复制会在源和目标 Data Domain 系统上产生大量额外的 CPU 和 I/O 开销。如果在带宽大于 6 Mbps 的链路上启用低带宽优化，则不太可能实现虚拟吞吐量的任何增益。一般而言，如果：

   • 要复制的数据与目标系统上已存在的数据的相同程度小于 96%
   • 可用带宽低于 6 Mbps
   • 两个系统都有备用 CPU 和 I/O 容量

     应启用低带宽优化。在数周内监视“replication show history”的输出。“Low-bw-optim”比率应平均值为 2.00 或更高，并且网络吞吐量（网络字节数除以时间间隔）不应远低于可用带宽。如果“Low-bw-optim”比率不是平均值 2.00 或更高，则增量压缩可能对数据集无效，应禁用。如果网络吞吐量远低于可用带宽，则很可能一个或两个 Data Domain 系统没有足够的备用 CPU 或 I/O 容量来支持增量复制，应将其禁用。

6. 遵循其他组件和第三方备份应用程序的最佳实践。
   我们的最佳实践指南在编写时充分考虑了整体性能。与 Data Domain 的偏差表明，最佳实践可能会在多个领域产生重大的性能影响，尽管这可能不会立即显现出来。

参考

对复制滞后进行故障处理 180482