我们的土耳其客户要求我们为其数据中心正确配置备份。 我们正在俄罗斯做类似的项目，但这里的故事更多的是关于研究如何最好地做到这一点。
假设：有一个本地 S3 存储，有 Veritas NetBackup，它已经获得了将数据移动到对象存储的新扩展功能，现在支持重复数据删除，并且该本地存储中的可用空间存在问题。
任务：做好一切工作，使存储备份副本的过程既快速又便宜。
实际上，在此之前，S3中的所有内容都只是文件，这些都是数据中心关键机器的完整模型。 也就是说，它不是很优化，但一开始一切正常。 现在是时候弄清楚并正确行事了。
这张图展示了我们来到的地方：
正如您所看到的，第一次备份速度很慢（70 Mb/s），而同一系统的后续备份速度要快得多。
实际上，还有更多有关功能的详细信息。
为那些准备好阅读半页转储的人提供备份日志完整并重新扫描
18 年 2018 月 12 日 09:43:4452 PM — 信息 bpbkar (pid=14883996160) 加速器已将 14883994624 字节中的 0.0 字节发送到服务器，优化 XNUMX%
18 年 2018 月 12 日下午 10:07:23002 - 信息 NBCC (pid=3) StorageServer=PureDisk_rhceph_rawd:s14570817.cloud.ngn.com.tr； 报告 = (NBCC) 的 PDDO 统计信息（使用多线程流）：扫描：1760761 KB，发送 CR：0 KB，通过 FC 发送 CR：87.9 KB，重复数据删除：XNUMX%，禁用缓存
是
18 年 2018 月 12 日 13:18:2864 PM — 信息 bpbkar (pid=181675008) 加速器已将 14884060160 字节中的 98.8 字节发送到服务器，优化 XNUMX%
18 年 2018 月 12 日下午 13:40:23527 - 信息 NBCC (pid=3) StorageServer=PureDisk_rhceph_rawd:s14569706.cloud.ngn.com.tr； 报告 = (NBCC) 的 PDDO 统计信息：扫描：45145 KB，发送 CR：0 KB，通过 FC 发送 CR：99.7 KB，重复数据删除：XNUMX%，禁用缓存
增加的
18 年 2018 月 12 日 15:32:792 PM — 信息 bpbkar (pid=9970688) 加速器已将 14726108160 字节中的 99.9 字节发送到服务器，优化 XNUMX%
18 年 2018 月 12 日下午 15:53:23656 - 信息 NBCC (pid=3) StorageServer=PureDisk_rhceph_rawd:s14383788.cloud.ngn.com.tr； 报告 = (NBCC) 的 PDDO 统计信息：扫描：15700 KB，发送 CR：0 KB，通过 FC 发送 CR：99.9 KB，重复数据删除：XNUMX%，禁用缓存
是
18 年 2018 月 12 日 18:02:3496 PM — 信息 bpbkar (pid=171746816) 加速器已将 14884093952 字节中的 98.8 字节发送到服务器，优化 XNUMX%
18 年 2018 月 12 日下午 18:24:23878 - 信息 NBCC (pid=3) StorageServer=PureDisk_rhceph_rawd:s14569739.cloud.ngn.com.tr； 报告 = (NBCC) 的 PDDO 统计信息：扫描：34120 KB，发送 CR：0 KB，通过 FC 发送 CR：99.8 KB，重复数据删除：XNUMX%，禁用缓存
问题是什么
客户希望尽可能频繁地进行备份并尽可能便宜地存储它们。 最好将它们便宜地存储在 S3 等对象存储中，因为以每兆字节的服务成本计算，它们是最便宜的，您可以在合理的时间内回滚备份。 当有大量备份时，它就变得不是很便宜，因为大部分存储都被相同数据的副本占用。 以土耳其同事的 HaaS 为例，存储密度可以提高大约 80-90%。 很明显，这与他们的具体情况有关，但我绝对会指望至少 50% 的祖父。
为了解决这个问题，各大厂商早就做出了Amazon S3的网关。 只要支持 Amazon API，他们的所有方法都与本地 S3 兼容。 在土耳其数据中心，对我们的 S3 以及俄罗斯的 T-III“压缩机”进行了备份，因为这种工作方案对我们来说效果很好。
而且我们的S3与Amazon S3备份方法完全兼容。 也就是说，所有支持这些方法的备份工具都允许您“开箱即用”地将所有内容复制到此类存储中。
Veritas NetBackup 添加了 CloudCatalyst 功能：
也就是说，在需要备份的计算机和网关之间，有一个中间 Linux 服务器，来自 SRK 代理的备份流量会通过该服务器，并在传输到 S3 之前动态进行重复数据删除。 如果之前有 30 个 20 GB 的压缩备份，那么现在（由于机器的相似性）它们的体积已经小了 90%。 重复数据删除引擎的使用方式与使用 Netbackup 在常规磁盘上存储时相同。
这是中间服务器之前发生的事情：
我们进行了测试并得出结论，当在我们的数据中心实施时，这可以为我们和客户节省 S3 存储空间。 作为商业数据中心的所有者，我们当然是根据占用的数量收费，但这对我们来说仍然是非常有利可图的 - 因为我们开始在软件中更具可扩展性的地方赚钱，而不是租用硬件。 嗯，这是内部成本的减少。
日志228 个作业（0 已排队、0 处于活动状态、0 正在等待重试、0 已暂停、0 未完成、228 已完成 — 已选择 13 个）
（应用过滤器 [13]）
作业 ID 类型 状态 状态详细信息 状态 作业策略 作业计划 客户端媒体服务器 开始时间 已用时间 结束时间 存储单元 尝试操作 千字节 文件路径名 完成百分比（估计） 作业 PID 所有者 复制父作业 ID KB/秒 活动启动 活动 已用机器人库配置文件会话用于弹出数据移动的 ID 介质 脱离主机类型 主优先级 重复数据删除率 传输加速器 优化实例或数据库 共享主机
— 1358 快照完成 0 VMware — NGNCloudADC NBCC 18 年 2018 月 12 日 16:19:00 PM 02:18:18 2018 年 12 月 18 日 37:3:1 PM STU_DP_S100_****备份 1358 18% root 2018 12 年 16 月 27 日 00 :02:10 PM 0:XNUMX:XNUMX 即时恢复磁盘标准 WIN-************ XNUMX
1360 备份完成 0 VMware 完整 NGNCloudADC NBCC 18 年 2018 月 12 日 16:48:00 PM 01:39:18 2018 年 12 月 18 日 27:3:1 PM STU_DP_S14,535,248_****backup 149654 100 23858 1358% 335,098 root 18 2018 12 十二月 16 , 48 00:01:39 PM 0:99.8:99 即时恢复磁盘标准 WIN-************ XNUMX XNUMX% XNUMX%
1352 快照完成 0 VMware - NGNCloudADC NBCC 18 年 2018 月 12 日 14:04:00 PM 02:01:18 2018 年 12 月 16 日 05:3:1 PM STU_DP_S100_****备份 1352 18% root 2018 12 年 14 月 14 日 00： 01:51 PM 0:XNUMX:XNUMX 即时恢复磁盘标准 WIN-************ XNUMX
1354 备份完成 0 VMware 增量 NGNCloudADC NBCC 18 年 2018 月 12 日 14:34:00 PM 01:21:18 2018 年 12 月 15 日 55:3:1 PM STU_DP_S14,380,965_****备份 147 100 23617 1352% 500,817 root 18 2018 12年14月34日, 00 01:21:0 PM 99.9:100:XNUMX 即时恢复磁盘标准 WIN-************ XNUMX XNUMX% XNUMX%
1347 快照完成 0 VMware - NGNCloudADC NBCC 18 年 2018 月 12 日 11:45:00 PM 02:08:18 2018 年 12 月 13 日 53:3:1 PM STU_DP_S100_****备份 1347 18% root 2018 12 年 11 月 45 日 00： 02:08 PM 0:XNUMX:XNUMX 即时恢复磁盘标准 WIN-************ XNUMX
1349 备份完成 0 VMware 完整 NGNCloudADC NBCC 18 年 2018 月 12 日 12:02:00 PM 01:41:18 2018 年 12 月 13 日 43:3:1 PM STU_DP_S14,535,215_****backup 149653 100 23508 1347% 316,319 root 18 2018 12 十二月 12 , 02 00:01:41 PM 0:99.7:99 即时恢复磁盘标准 WIN-************ XNUMX XNUMX% XNUMX%
1341 快照完成 0 VMware - NGNCloudADC NBCC 18 年 2018 月 12 日 05:28:00 PM 04:53:18 2018 年 12 月 10 日 21:3:1 PM STU_DP_S100_****备份 1341 18% root 2018 12 年 05 月 28 日 00： 04:53 PM 0:XNUMX:XNUMX 即时恢复磁盘标准 WIN-************ XNUMX
1342 备份完成 0 VMware Full_Rescan NGNCloudADC NBCC 18 年 2018 月 12 日 05:47:00 PM 04:24:18 2018 年 12 月 10 日 11:3:1 PM STU_DP_S14,535,151_****备份 149653 100 22999 1341% 70,380 root 18 2018 12 05 十二月47 年 00 月 04 日 24:0:87.9 PM 0:XNUMX:XNUMX 即时恢复磁盘标准 WIN-************ XNUMX XNUMX% XNUMX%
1339 快照完成 150 VMware - NGNCloudADC NBCC 18 年 2018 月 11 日 05:46:00 AM 00:53:18 2018 年 11 月 06 日 39:3:1 AM STU_DP_S100_****backup 1339 18% root 2018 11 年 05 月 46 日 00： 00:53 AM 0:XNUMX:XNUMX 即时恢复磁盘标准 WIN-************ XNUMX
1327 快照完成 0 VMware - ********.********.cloud NBCC 17 年 2018 月 12 日 54:42:05 PM 51:38:17 2018 年 6 月 46 日 20:3:1 STU_DP_S100_****备份 1327 17% root 2018 12 年 54 月 42 日 05:51:38 PM 0:XNUMX:XNUMX 即时恢复磁盘标准 WIN-************ XNUMX
1328 备份完成 0 VMware 完整 ********.********.cloud NBCC 17 年 2018 月 12 日 55:10:05 PM 29:21:17 2018 年 6 月 24 日 31:3:1 STU_DP_S222,602,719_****backup 258932 100 12856 1327% 11,326 root 17 2018 12 年 55 月 10 日 05:29:21 PM 0:87.9:0 即时恢复磁盘标准 WIN-************ XNUMX XNUMX% XNUMX%
1136 快照完成 0 VMware - ********.********.cloud NBCC 14 年 2018 月 4 日 48:22:04 PM 05:16:14 2018 年 8 月 53 日 38:3:1 STU_DP_S100_****备份 1136 14% root 2018 4 年 48 月 22 日 04:05:16 PM 0:XNUMX:XNUMX 即时恢复磁盘标准 WIN-************ XNUMX
1140 备份完成 0 VMware Full_Scan ********.********.cloud NBCC 14 年 2018 月 4 日 49:14:03 PM 49:58:14 2018 年 8 月 39 日 12:3:1 PM STU_DP_S217,631,332_****backup 255465 100 26438 1136% 15,963 root 14 2018 4 年 49 月 14 日 03:49:58 PM 0:45.2:0 即时恢复磁盘标准 WIN-************ XNUMX XNUMX% XNUMX%
加速器可以让您减少来自代理的流量，因为仅传输数据变化，也就是说，即使是全量备份也不会完全上传，因为介质服务器会从增量备份中收集后续的全量备份。
中间服务器拥有自己的存储，可在其中写入数据“缓存”并维护数据库以进行重复数据删除。
完整的架构如下所示：
- 主服务器管理配置、更新等，位于云端。
- 就网络可访问性而言，媒体服务器（中间 *nix 机器）应位于距离冗余系统最近的位置。 此处，所有保留机器的备份的重复数据删除已完成。
- 在备份的计算机上，有一些代理通常仅将不在其存储中的内容发送到媒体服务器。
这一切都从完整扫描开始 - 这是一个成熟的完整备份。 此时，媒体服务器会获取所有内容，删除重复数据并将其传输到 S3。 到媒体服务器的速度较低，但从媒体服务器的速度较高。 主要限制是服务器的计算能力。
以下备份是从所有系统的角度来看的完整备份，但实际上它们类似于合成完整备份。 也就是说，仅对那些之前在VM备份中尚未遇到过的数据块进行实际传输和记录到介质服务器。 并且只有那些散列不在媒体服务器的重复数据删除数据库中的数据块才会被传输并记录在S3中。 简单来说，这是以前在单个虚拟机的备份中从未见过的情况。
在恢复过程中，媒体服务器从 S3 请求必要的重复数据删除对象，对它们进行重新水化并将它们传输到 IRB 代理，即需要考虑恢复期间的流量，该流量将等于实际恢复的数据量。
下面是它的外观：
这是另一块日志169 个作业（0 已排队、0 处于活动状态、0 正在等待重试、0 已暂停、0 未完成、169 已完成 — 已选择 1 个）
作业 ID 类型 状态 状态详细信息 状态 作业策略 作业计划 客户端媒体服务器 开始时间 已用时间 结束时间 存储单元 尝试操作 千字节 文件路径名 完成百分比（估计） 作业 PID 所有者 复制父作业 ID KB/秒 活动启动 活动 已用机器人库配置文件会话用于弹出数据移动的 ID 介质 脱离主机类型 主优先级 重复数据删除率 传输加速器 优化实例或数据库 共享主机
- 1372 恢复完成 0 NBPR01 NBCC 19年2018月1日 05:58:00 PM 04:32:19 2018年1月10日 30:1:14,380,577 PM 1 100 8548 1372% 70,567 ROOT 19 2018 1年06月00日 00:04 :30 PM 90000:XNUMX:XNUMX 胜利-************ XNUMX
数据完整性是通过 S3 本身的保护来确保的 - 那里有良好的冗余来防止硬件故障，例如硬盘驱动器主轴损坏。
媒体服务器需要 4 TB 缓存 - 这是 Veritas 建议的最小大小。 越多越好，但这就是我们所做的。
总
当合作伙伴将 3 GB 放入我们的 S20 中时，我们存储了 60 GB，因为我们提供了数据的三重地理保留。 现在流量少了很多，这对渠道和存储费率都有好处。
在这种情况下，经过“大互联网”的路由是封闭的，但您可以通过互联网上的 VPN L2 驱动流量，但最好在提供商入口之前安装媒体服务器。
如果您有兴趣了解我们俄罗斯数据中心的这些功能或对在家实施有疑问，请在评论中或通过电子邮件询问 [电子邮件保护].
来源： habr.com