Veeam 备份和恢复的高性能对象存储

备份是一项大生意。在这个市场中，虚拟机备份占据了最大的份额。然而，虚拟机备份的世界已经发生了变化。曾经对企业来说是一个小挑战的问题，已经变成了一个巨大的挑战，规模达到了PB级，并催生了一个完整的子行业。

Veeam 是备份、恢复和复制软件的主要参与者之一，在许多企业的眼中，它是主要的参与者。对于 Veeam 客户来说，MinIO 如此有趣的原因在于它是软件定义的。由于软件希望与其他软件通信，因此在备份虚拟机方面，MinIO 和 Veeam 是绝佳的匹配。以下是原因

• 虚拟机备份需要可扩展的存储。在当今的架构圈中，这一点几乎没有争议。对象是可扩展性最高的解决方案——无论是在公有云还是私有云中。
  
• 虚拟机备份需要性能。这是一个两部分的要求。首先，备份和恢复需要快速完成，无论规模大小。传统的对象存储架构（想想设备供应商）由于多种原因无法胜任这项任务。这就是像 MinIO 这样的现代对象存储特别适合的地方。原因有很多，但以下四个尤为突出

1. 速度。凭借在单个 32 节点集群中以超过 160 GB/s 的速度读写数据的能力，MinIO 可以以对象存储过去难以想象的速度进行备份和恢复。较长的备份恢复周期会导致业务中断增加。一些速度较慢的对象存储尝试通过转向最终一致性模型来走捷径。如果在作业执行过程中拔掉插头，并且数据库损坏，这可能会产生灾难性的影响。
2. 对象大小。MinIO 可以处理任何大小的对象。Veeam 的默认值为 1MB 对象，但支持从 256K 到 4MB 的任何大小。因为 MinIO 与对象数据一起原子地写入元数据，所以它不需要数据库（大多数情况下为 Cassandra）来存储元数据。在较小的对象大小下，删除变得非常麻烦，并且实际上会取消任何采用这种方法的对象存储。在 4MB 时，重复数据删除变得无效，因此 Veeam 架构师建议不要使用它。总而言之——如果对象存储实现使用元数据数据库，则它不适合处理备份。
3. 内联和严格一致。MinIO 中的数据始终是可读且一致的，因为所有 I/O 都是与内联擦除码、比特腐烂哈希和加密同步提交的。MinIO 提供的 S3 服务能够抵御繁忙事务过程中发生的任何中断或重启。没有用于异步 I/O 的缓存或数据分段。这保证了所有备份操作都一定会成功。
4. 商用现成硬件。COTS 硬件 = 巨大节省、熟悉度和灵活性。随着数据增长到 PB 级别，这成为一项重要的需求。

这些需求的结果是，Veeam 与高性能、软件定义的对象存储是天作之合。MinIO 正是这样一种存储，这就是我们与 Veeam 如此契合的原因。

为了证明这一点，我们将 Veeam 与 MinIO 配对作为容量层，以允许 Veeam 的软件将虚拟机从 VMware ESX 卸载到 Veeam。

环境

ESX 服务器

一台运行 10 个虚拟机的 ESX 服务器，每个虚拟机使用 300GB 的稀疏磁盘，每个磁盘生成 100GB 的数据。（规格）

• 28 个物理核心 @ 2.2 GHz
• 384 GB DDR4 ECC 内存
• 3.8TB NVMe
• 10Gbps 网络*
• 6.5.0 更新 1（版本 7967591）

Veeam 服务器

• 28 个物理核心 @ 2.2 GHz
• 384 GB DDR4 ECC 内存
• 3.2 TB NVMe 驱动器
• 20Gbps 交换机绑定网卡
• Windows Server 2016，Veeam Backup and Replication 10.0.0.4461

MinIO 集群

我们部署了一个具有以下规格的四节点 MinIO 集群

• 24 个物理核心 @ 2.2 GHz
• 256 GB DDR4 ECC 内存
• 每个服务器 2.8 TB 的 SSD，每个服务器分成 4 个驱动器
• 2 个 10 GigE 绑定网卡
• Ubuntu 18.04

MinIO 配置

我们创建了一个具有 TLS 用于线路上加密和对象加密的四节点 MinIO 集群。我们在之前的 基准测试 中注意到，对象加密对 CPU 性能的影响最小。因此，我们建议始终将其打开。

MINIO_VOLUMES="https://veeam-minio0{1...4}/mnt/disk{1...4}/veeam"
MINIO_ERASURE_SET_DRIVE_COUNT=4
MINIO_ACCESS_KEY=
MINIO_SECRET_KEY=
MINIO_KMS_AUTO_ENCRYPTION=on
MINIO_KMS_MASTER_KEY=my-minio-key

规格

在运行任何测试之前，我们希望确保底层硬件是健康的，并且能够生成和维持足够的 I/O 以充分利用 MinIO 集群。在其他 性能基准测试 中，我们已经证明 CPU 和 RAM 从未成为瓶颈。

磁盘测试

作为我们测试的一部分，我们希望测量环境中各种服务器的 I/O 子系统，包括磁盘和网络。这使我们能够了解整个环境中可以预期的性能类型，并有助于识别潜在的瓶颈。这些通常按顺序出现在网络、磁盘或 PCIe 总线级别。由于 MinIO 经过高度优化且轻量级，因此它不需要大量的 CPU 或 RAM。top 命令显示大约 30% 的 CPU 利用率和 16 到 64GB 的内存消耗，具体取决于使用情况。

为了进行这些测试，我们使用了几个工具。为了测试磁盘性能，我们使用 dd 并关闭缓存。这将为我们提供磁盘能够执行顺序读写操作的“最佳情况”配置文件，并识别是否有任何磁盘的性能与其他磁盘明显不同。然后，我们使用 iozone，它将向我们显示系统上所有磁盘的聚合吞吐量，以便我们知道整个系统能够做什么。IOzone 将为我们提供一些额外的保证，因为它利用了随机读写操作。对于网络，我们使用 iperf 实用程序，它将向我们显示各种端点之间的最大速度。当我们确信没有系统级瓶颈时，我们将使用 Warp 基准测试实用程序来验证 MinIO 如何处理各种 S3 操作，例如 GET、PUT 和 DELETE。

ESX

在 ESX 服务器上，我们测试了将容纳稍后要备份的虚拟机的 VMFS 数据存储。从技术上讲，这不需要，因为我们测试中的流量将在 Veeam 服务器和 MinIO 集群之间，但测试很有趣，我们喜欢数字。首先，我们测试读取。ESX 的 dd 实现不支持 oflag 或 iflag 选项，但似乎不缓存读取或写入操作。

$ time dd if=/dev/zero of=/vmfs/volumes/veeam/dd.delme bs=1M count=10000

这在 16.25 秒内写入，约为 625MB/s。

对 9.2GB 文件进行 dd 读取测试显示读取速度略高于 500MB/s

$ time dd if=/vmfs/volumes/veeam/bigfile.delme of=/dev/null bs=1M

读取操作消耗的时间为 18.31 秒。

MinIO 服务器写入

由于我们有四个磁盘，因此我们希望独立测试每个磁盘。

for i in {1..4}; do dd if=/dev/zero of=/mnt/disk$i/dd.delme bs=1M count=10000 oflag=direct; done

我们看到每个磁盘的磁盘写入速度都略高于 350MB/s。

10485760000 字节 (10 GB, 9.8 GiB) 已复制，28.839 秒，364 MB/s

MinIO 服务器读取

在每个磁盘上，我们放置了一个大小略大于 9GB 的文件，然后运行读取测试。

for i in {1..4}; do dd if=/mnt/disk$i/bigfile.delme of=/dev/null bs=1M iflag=direct; done

每个磁盘的读取速度约为 375MB/s。

iozone

现在我们已经通过 dd 获得了磁盘读写操作的最佳情况，是时候进行更强大的测试了。我们使用以下选项运行 iozone

$ iozone -t 64 -r 1M -s 4MB -I -b iozone.xls -F /mnt/disk{1..4}/tmp{1..16}

这指定了 32 个线程，每个线程 1MB，每个磁盘写入 8 个线程，使用直接 I/O 并避免任何缓存。我们将关注以下值

初始写入 ~1.5GBs 聚合，每个磁盘 ~382MB/s

初始读取 ~1.7GB 聚合，每个磁盘 ~415MB/s

我们看到随机读写操作的结果大致相同。

Windows Server

在 Windows 中，我们可以使用 diskspd 实用程序。我们使用以下选项

diskspd.exe -b256K -d120 -h -L -o2 -t4 -w-c16G -r d:\io.out

这将 256k 块写入 120 秒，使用 4 个线程，无缓存且随机 I/O 写入 16GB 文件。-w 标志允许我们定义每个测试将执行的写入百分比。我们将使用 -w100、-w0 和 -w50 分别进行写入、读取和等量混合的读写操作。

写入

读取

iperf 测试

使用iperf工具，我们可以测量每个服务器的预期最大传输速度。 iperf服务器运行后，我们从每个客户端到MinIO服务器观察到以下数据。 请注意，我们还在所有MinIO节点之间运行了测试（此处仅显示一个结果，但所有结果都类似）。 我们使用的一个示例命令是iperf -c veeam-minio01 -P20，它使用20个并发客户端连接来饱和入站网络。

ESX

9.33 Gbit/秒

MinIO服务器

18.7 Gbit/秒

Windows到MinIO服务器

18.9 Gbit/秒

从这些数据可以看出，所有服务器都获得了预期的网络带宽。

Warp测试

Warp是由MinIO开发团队创建的实用程序，用于测量与S3兼容的对象存储的性能。 在这些测试中，我们部署了许多客户端机器，这些机器具有足够的网络带宽来饱和MinIO集群。

GET数据

首先，我们运行一个测试来评估整个集群的GET性能。

$ warp get --access-key--secret-key--tls --host veeam-minio0{1...4}:9000 --warp-client warp-client{1...4} --duration 5m --objects 2500 --obj.size 1MB --concurrent 32

此测试运行5分钟，对象大小为1MB，每个服务器并发32个线程，整个集群总共128个线程。 我们看到集群读取速度约为3.3GB/秒。

操作：GET。并发：128。主机：4。

* 平均：3316.29 MiB/s，3477.39 obj/s（4m59.873s）

PUT数据

接下来，我们使用PUT操作运行相同的测试。

$ warp put --access-key <access-key> --secret-key <secret key> --tls  --host veeam-minio0{1...4}:9000 --warp-client warp-client{1...4} --duration 5m --obj.size 1MB --concurrent 32

在这里，我们看到集群写入速度约为1.6GB/秒。 值得注意的是，由于写入放大，使用n/2擦除集的写入速度将小于读取速度，因此这些是预期的结果。

操作：PUT。并发：128。主机：4。

* 平均：1604.49 MiB/s，1682.43 obj/s（5.596s）

删除

最后，我们测试删除性能。

$ warp delete --access-key--secret-key--tls --host veeam-minio0{1...4}:9000 --warp-client warp-client{1...4} --duration 5m

操作：DELETE。每个操作的对象数：100。并发：192。主机：4。

* 平均：6738.25 obj/s（7.585s，开始时间：18:32:15 UTC）

Veeam设置

将MinIO配置为s3目标

1. 为容量层创建对象存储

首先，我们创建一个新的与S3兼容的对象存储作为容量层。 选择一个与S3兼容的对象存储，并配置为使用您的MinIO部署作为自定义端点。

1e. 使用minio客户端命令行实用程序（mc）查看Veeam是否已在存储桶下创建了前缀结构。

运行备份到容量层

接下来，我们创建一个备份作业，将VM从Veeam卸载到MinIO。 我们将使用十个测试VM，每个VM包含100GB的随机测试数据，每个VM都具有唯一的数据集，以避免任何重复数据删除。

在“存储”屏幕上，我们选择为此测试配置的横向扩展备份存储库。 备份到Veeam服务器后，VM也将备份到容量层，即MinIO。

总结

对于备份和恢复，性能至关重要。 Veeam的软件架构非常出色，但当它指向与S3兼容的对象存储时，它需要该对象存储能够相应地提供服务——否则，整体解决方案的效用将受到限制。

MinIO和Veeam是彼此绝佳的补充。 两者都在软件定义的解决方案中提供了可扩展性、速度和简单性。

我们鼓励Veeam用户尝试此架构，因为它将使他们能够现代化其堆栈，提高性能，提供更大的扩展性，并最终为这种关键的软件工作流程提供大大优越的经济效益。

要开始使用MinIO，只需下载代码即可。 如果您有任何疑问，我们有优秀的文档和Github上的集成文档，以及业界最佳的社区Slack频道。 如果您希望建立更深入的关系，请查看我们的定价页面，了解哪些选项可能适合您的需求。