如何测试 Amazon Elastic File System

Original URL: https://aws.amazon.com/cn/blogs/storage/how-to-test-drive-amazon-elastic-file-system/
许多客户对 Amazon EFS 倍加推崇，因为它使得在云中创建并运行高度可扩展、高度可用且高持久性的共享文件系统变得格外轻松。只需短短数秒，就可以创建一个符合 NFSv4 的文件系统，并将其挂载到多个（多达数千个）Amazon EC2 实例或本地服务器上。

Amazon EFS 为基于 Linux 的工作负载提供了一个简单、可扩展且有弹性的文件系统，并且可在不中断应用程序的情况下按需扩展到 PB 级。Amazon EFS 支持各种使用案例，从需要最高吞吐量的高度并行、横向扩展的工作负载到单线程、延迟敏感的工作负载，不一而足。使用案例包括迁移至云上的传统企业应用程序、大数据分析、Web 服务和内容管理、应用程序开发和测试、媒体和娱乐工作流程、数据库备份和容器存储等。

我的日常工作之一是帮助客户评估、设计和实施存储解决方案以支持不同的应用程序和工作负载。我发现，那些刚开始使用 Amazon EFS 的客户对这种高级文件系统还缺乏了解。在您开始评估和测试 Amazon EFS 之前，我希望与您分享一些最佳实践。本文将帮助您充分利用 Amazon EFS。

创建 Amazon EFS 文件系统

如果您还没有创建 Amazon EFS 文件系统，请使用 AWS 管理控制台或 AWS 命令行界面 (CLI) 创建一个。完成开始使用 Amazon Elastic File System 主题中的步骤 1、2 和 3。几分钟后，您应该会登录到挂载了 Amazon EFS 文件系统的 Amazon EC2 实例。

试用

在客户挂载文件系统之后，让我们先来检查一下文件系统的大小。在挂载了 EFS 文件系统的 EC2 实例的命令行处运行 df。应会返回与下文类似的内容，这将以1KB数据库块的数量来表示文件系统大小。

如果您和我一样，很难直接理解一个如此庞大的数值（16 位），那么您可使用 df -h 命令来获取一个便于理解的表示。上述命令的执行结果显示您拥有 8EB 以上的可用存储。但事实上， Amazon EFS 是一个弹性文件系统，可随着您添加和删除数据自动扩展和缩减，而您只需要为实际使用的存储付费（在本例中为零）。您不再需要费心考虑如何预置存储，您只需为使用的存储付费。

由于 Amazon EFS 易于上手，因此您可能希望尽快深入了解并评估 Amazon EFS 的性能，一种常见的方法是使用“touch”命令测试评估 Amazon EFS 性能。这种测试会生成大量的零字节文件。我见过用 Perl、Python、Java 和其他语言编写的这类测试。

本文将使用 bash 脚本，您会看到生成 1024 个文件的速度有多快。在 EC2 实例上运行以下命令，请确保将存储路径指向已挂载的 Amazon EFS 文件系统。

time for i in {1..1024}; do
  sudo touch /mnt/efs/deleteme.$i;
  done;

用了多长时间？ 在我的测试中，仅用了 16.808 秒便在 Amazon EFS 上生成了 1024 个文件。

如果您认为生成 1024 个零字节文件所用的时间过长，请仔细检查该命令以确保其正确无误。删除第一组 1024 个零字节文件后，再次运行该命令。结果如何呢？ 几乎一样。

如果您还是认为生成 1024 个零字节文件需要的时间太长，可以将其与其他存储平台进行比较。更改命令并针对挂载到实例的 Amazon EBS 卷运行该命令。运行以下命令，确保更改路径以使用 Amazon EBS 卷。在本例中，我将写入 ec2-user 主目录。

time for i in {1..1024}; do
  sudo touch ~/deleteme.$i;
  done;

用了多长时间？ 在我的测试中，仅用了 5.112 秒便在 EBS 上生成了 1024 个零字节文件。这是 root 卷，即一个 10-GB gp2 EBS 卷。在本例中，与 EFS 相比，写入 EBS 的操作要快 3.28 倍。

在这类情况下，我会多假设几种场景。如果重新编写命令以使用多个线程会怎样？ 这将允许您并行生成文件。进入 GNU Parallel，这是一个用于并行执行串行操作的开源 shell 工具。该工具已添加到 Amazon Linux 存储库中，因此在安装并启用 EPEL rpm 软件包后，可以使用 sudo yum install parallel -y 命令将其安装到 Amazon Linux 2 上。有关更多信息，请参阅 GNU Parallel。

运行以下命令，安装 GNU Parallel 并使用多个线程生成 1024 个零字节文件。

time seq 1 1024 | sudo parallel --will-cite -j 32 touch 
/mnt/efs/deleteme2.{};

将该命令重新编写为使用 32 个作业（或 32 个线程）后，仅仅在 8.647 秒内便生成了相同的 1024 个零字节文件，速度提高了 94%。

如果将多线程命令重新编写为写入多个目录会怎样？ 每个线程写入一个单独的目录。这会将写入操作分布在多个 inode 上。

如果您不熟悉 inode，请注意 inode 是一种 Unix 风格的数据结构，用于描述文件系统对象，例如文件和目录。当多个线程尝试更新同一个 inode 时，会发生 inode 争用，由于存在网络延迟，这种情况在网络文件系统中更为明显。运行以下命令，使用 32 个线程生成 1024 个零字节文件，每个线程在自己的目录中生成 32 个文件。32 个目录，每个目录中包含 32 个文件，共 1024 个文件。

sudo mkdir -p /mnt/efs/{1..32}
time seq 1 32 | sudo parallel --will-cite -j 32 touch 
/mnt/efs/{}/deleteme3.{1..32};

将命令重新编写为使用 32 个作业（或 32 个线程），并让每个线程在自己的目录中生成文件后，仅在短短 0.776 秒内便生成了 1024 个零字节文件。这比第一个单线程单目录测试快了 21 倍。

如果将同一文件系统挂载到 2、10、100 或1000 个 Amazon EC2 实例，又会怎样？ 如果文件系统支持关后开一致性、跨多个存储服务器和多个可用区的数据持久性以及没有单点故障的高可用性，则会生成多少个文件？

后续步骤

这只是用来有效评估和试用 Amazon EFS 的一个测试。要详细了解其性能特性，我建议您浏览一下 GitHub 上的 Amazon EFS 教程。该教程不仅包含我刚刚进行的试用，还通过更多例子说明了并行性的优势。此外，还说明了 I/O 大小、EC2 实例类型和不同的文件传输工具对性能造成的显著影响。AWS DataSync 也使用这些技术改进 EFS 文件系统往来传输数据的性能。

有关 GNU Parallel 的更多信息，请参阅 USENIX 杂志 2011 年 2 月刊上的“GNU Parallel – 强大的命令行工具”。

小结

Amazon EFS 文件系统可分布在无限量的存储服务器上，从而允许对文件系统对象进行大规模并行访问。这种分布式设计避免了传统文件服务器固有的瓶颈和约束。

在本次试用中，我利用了 Amazon EFS 的这些优势，将生成 1024 个零字节文件的时间从 16.808 秒减少到了 0.776 秒，速度提高了 2100%。

在本文中，我只展示了两条建议。您可以根据这些建议更好地利用 Amazon EFS 的分布式数据存储设计，并实现对文件系统数据的大规模并行访问。

第一条建议是使用多个线程并行访问 EFS。第二条建议是使用多个线程并行访问多个目录或 inode。要了解有助于您更好地理解和利用 EFS 的分布式设计的其他建议，请查看 Amazon EFS 教程。

本篇作者

本篇译者