使用 MinIO Jumbo 加速数据库备份和恢复

在现代云原生架构中，对象存储是主要存储。这种转变带来的影响之一是，数据库要么运行在高性能对象存储上，要么连接到它，要么备份到它。

例如，备份可以使用传统方式进行。Veeam 和 Commvault 原生支持 S3 API。

仍然有很大一部分企业依赖其数据库供应商提供的工具进行快照/恢复。针对特定数据库，这些快照/恢复工具通常缺乏对 S3 的支持（但正在开发中）。然而，如果企业在对象存储上运行数据库工作负载，那么为什么要额外添加基于文件系统的存储来仅仅存放备份呢？这会让他们多管理一个存储部署，并且剥夺了企业将快照/备份/归档整合到同一对象存储部署中的机会，而该部署已经用作主要存储。此外，他们必须继续依赖文件系统作为其 BC/DR 策略的关键组成部分。

问题在于，现代数据库对于 SAN/NAS 架构来说过于庞大。SAN/NAS 无法扩展的能力给企业带来了重大问题。

因此，在一位财富 100 强客户的要求下，MinIO 开发了一个名为 Jumbo 的工具。Jumbo 可以通过创建并行流来上传大型对象的片段，从而处理海量数据转储。可以使用单个恢复命令读取该对象集合。

本质上，Jumbo 将大型文件（例如数据库快照）组织成单个大型对象流，并使用 S3 API 并行快速将其上传到对象存储。Jumbo 的唯一限制是网络速度（稍后详细介绍）。Jumbo 可以通过 Linux 管道读取文件，也可以从驱动器读取文件。数据库备份工具可以将备份内容通过 STDOUT 管道传输，也可以将文件写入文件系统，而 Jumbo 可以从两者中读取。备份运行后，使用 Linux 管道将文件传递给 Jumbo，然后 Jumbo 完成其余操作。Jumbo 支持任何写入 STDOUT 的备份工具。在我们的测试中，尽管对解决管道常见问题的进行了优化，但 Linux 管道的速度远低于直接从磁盘读取的速度（管道速度 <3GB/s）。

可以进一步优化 - 但这需要将 Jumbo 直接嵌入到备份工具中。如果您想讨论如何实现，请联系我们。

Jumbo 的实用性超出了备份的范围。它可以用于将任何大型文件从本地文件系统上传到 S3 存储，从而在发生此类操作的任何环境中具有潜在价值，例如基因组学、DNA 测序、太空探索、石油/天然气勘探、粒子碰撞等等。

将 Jumbo 与 MinIO 部署结合使用，可以为非常大的备份创建一个灵活、持久且高性能的存储空间。Jumbo 增强了 MinIO 的功能套件，使其非常适合用作备份存储端点。

• 高性能：MinIO 在 单个 32 节点 NVMe 集群 中能够实现 1.32 Tbps 的 PUT 吞吐量和 2.6 Tbps 的 GET 吞吐量。这意味着备份和恢复操作运行速度更快，减少了停机时间可能带来的业务影响。
• 针对各种对象大小进行了优化：MinIO 可以轻松处理任何对象大小。因为 MinIO 与对象数据一起原子地写入元数据，所以它不需要单独的元数据数据库。这大大减少了小型文件 PUT 和 GET 的响应时间。Jumbo 使大型对象上传并行化，以尽可能有效地利用网络。
• 内联且严格一致：所有 I/O 均与内联 擦除编码 同步提交。Bitrot 哈希提供完整性检查，允许 MinIO 检测和修复磁盘上的损坏，而加密则防止从磁盘窃取数据。S3 API 能够在上传或下载过程中抵御中断或重启，因此备份不会消失。最后，由于没有数据缓存或暂存，这意味着所有已完成的备份操作都保证存在于持久存储上。
• 专为商用硬件而构建：商用 现成硬件 意味着与专用设备相比，您可以节省大量成本。在当今经济环境下，随着备份数据增长到 PB 级别，您可以获得更大的投资回报。 
  

Jumbo 性能测试

如上所述，我们为大型客户完成了这项工作。这不仅仅是一般的数据库备份作业，而是备份作业中的巨无霸。它涉及大型数据库备份文件，每个作业通常为 15TiB 到 30TiB。该公司现在面临着超过 24 小时的备份窗口（16TiB 备份需要超过 28 小时才能完成），并且端到端时间过长阻碍了创建备份和克隆的能力，从而威胁到运营。

在构建解决方案时，客户使用最新的基于英特尔 Sapphire Rapids 的 Supermicro 服务器平台进行了测试。

MinIO 客户端：使用 1 个节点，每个节点有 6 个 15.36TB NVMe 驱动器，来执行 50TiB 和 64TiB 的 Blob 备份。这些文件被分片到 6 个驱动器上。

MinIO客户端：使用1个节点，每个节点配备6块7.6TB NVMe驱动器，执行了1TiB、16TiB和32TiB的Blob备份。这些文件被分片到6个驱动器上。

MinIO服务器：12个节点，每个节点配备6块7.68TB NVMe驱动器。

• 网络：双100GbE QSFP28，Mellanox CX-6
• 存储 - 6 x Kioxia CD6-R 7.68TB NVMe
• 1个CPU，48个物理核心（每个节点96个总线程） - 英特尔至强（Sapphire Rapids） - Q16Z/E3 SPR 8461V 48C 2.2G 97.5MB FC-LGA16A 300W XCC
• 内存：512GB DDR5-4800（8 x 64GB）
• 启动存储 - Kioxia XG6 2TB NVMe（4 x 512GB）
• 操作系统：RHEL 9.1
  

每个SYS-211GT-HNTR 2U服务器机箱都是一个四服务器（2U 4节点）配置。

此配置也用于小型文件基准测试，可在速度与激情2 - 超微GrandTwin™超级服务器基准测试中找到。

我们在一个数据节点上运行Jumbo，数据分片到6个NVMe磁盘上。Jumbo并行读取磁盘上的数据，并利用数据节点上存在的2个网卡（每个100 Gbps）将数据推送到12节点MinIO集群。

MinIO对象存储基准测试

在测试实际的大文件备份性能之前，MinIO使用其基准测试工具对12节点MinIO集群进行了性能测试。

通常，MinIO性能受网络限制或磁盘限制。在此特定测试中，MinIO提供了以下服务器端性能

大文件备份基准测试

此基准测试的目标是在客户端（存储DB备份文件的位置）实现至少20 GiB/s的吞吐量。作为这些测试的一部分，我们能够优化Jumbo代码以利用高性能NVMe磁盘的O_DIRECT读取模式。

O_DIRECT读取模式确保我们避免将数据复制到操作系统页面缓存，然后再复制到应用程序内存；启用此模式后，我们看到性能提高了3倍。基准测试（见下表）使网络饱和，而CPU和内存仍然可用，这表明此测试中的瓶颈实际上是网络。我们能够在不同DB大小下持续实现20到21 GiB/s的吞吐量。

在实践中，数据库和备份工具也会限制整体吞吐量，因为它们无法以线速驱动流量，但如果我们回到这些测试的最初原因，那么Jumbo的价值就得到了清晰的说明。我们最初进行了一个16TiB的备份，完成需要超过28个小时。相同大小的备份，直接从DB备份工具写入STDOUT，通过管道传输到Jumbo并上传到MinIO集群，仅需1小时51分钟，与公司现有的备份解决方案相比，性能提升了15倍。

与Jumbo一起加速

Jumbo通过快速上传到MinIO来缩短备份窗口。它通过并行化上传来实现这一点。Jumbo利用所有可用带宽将备份文件写入MinIO。鉴于MinIO是可用的最快对象存储，并且Jumbo最大限度地利用了网络，这意味着备份速度的唯一限制是源系统本身。

这是现代架构的趋势。解耦的数据库应该运行在解耦的存储上，它消除了数据库本身管理存储的需要。现代参考架构将数据湖与云原生数据库、分析和AI应用程序相结合。所有这些都在Kubernetes上运行，并根据需要复制数据到多云环境中。

不要相信我们的说法，立即下载MinIO并试用一下。如果您想讨论Jumbo或有任何疑问，请在我们的Slack频道上提问。