值得注意的七条有关AWS EFS性能

当然，有过实际项目经验的小伙伴都知道：在大多数情况下，性能并不是一门精确的科学，而且会涉及到应用的各个真实环境与使用状态。因此，在优化性能时，我们往往无法一蹴而就，需要持续、甚至反正地进行自动化或人工等方面的设置和尝试。

在本文中，您将学习到AWS EFS的基本概念，如何对其进行配置和试用，以及如何通过七个重要方面，来保持EFS的应用负载能够平稳高效地持续运行。

弹性文件系统（Elastic File System，EFS）是AWS中的一种存储服务，可被用于在云端重新创建网络文件系统。基于网络文件系统v4（NFSv4）的EFS，主要是针对基于Linux的应用负载和程序而设计的。您可以顺畅地将其与AWS的其他服务、以及本地资源整合使用。

与其他存储服务相比，AWS EFS能够提供的功能最接近本地现有的文件存储（具体请参见–https://cloud.netapp.com/blog/ebs-efs-amazons3-best-cloud-storage-system）。通过它，您可以轻松地将本地现有的文件结构转移到云端，并享有如同访问本地文件那些进行各种流畅操作的体验。为了达到该目的，您既可以通过在EC2（Elastic Compute Cloud）中托管应用程序，然后将实例附加到EFS上，也可以将EFS用作独立的文件系统。

在EFS中，您可以选择如下两种访问方式：

· 标准访问（Standard Access）是针对您的基本应用负载而设计的。其特点是以较高的成本换取较低的访问延迟。

· 不频繁访问（Infrequent Access）专为需要长时间存放，却鲜少使用的文件而设计。其特点是：以较低的成本换取较高的访问延迟。

当然，无论您选用哪一种访问方式，EFS都是按照使用收费的。也就是说，它仅收取您实际使用的存储和传输带宽的费用。

在将文件传输到EFS之前，您往往需要试用该服务。据此，您不但可以熟悉其相关的配置，评估其运行的性能，而且能够通过与当前的本地系统作比较，更全面地预估在使用EFS时所需要的资源配置水平。下面，让我们从EFS提供的“免费套餐（free tier）”开始吧。

免费的EFS tier提供了可以使用12个月的5 GB存储空间。如果您手头已经具有了可以将文件系统挂载到的EC2中的实例，那么EFS的试用并不困难。当然，如果您不喜欢该“套餐”的话，也可以选用一种适用于EC2的免费tier，它提供的750小时使用时长，足够让您从容地完成各项测试。

为了建立自己的demo，您可以通过命令行界面（CLI）、或管理控制台（Management Console）来创建各种资源。具体有关如何使用管理控制台来设置和连接相应的服务，我们在此就不赘述了。如果您感兴趣的话，可以通过链接– https://docs.aws.amazon.com/efs/latest/ug/getting-started.html，去参考AWS的相关文档。

值得一提的是，请您在试用过程中，尽可能实际地去模拟对于目标文件系统的各种使用操作。例如：您可以添加多个实例，使用单线程和多线程两种方式去编写文件，以及采用标准和不频繁两种访问方式去访问各类数据。

一旦您决定了采用EFS服务，那么就需要将自己的关注点转移到确保能够获得最大投资回报上。以下是我为您总结的七条有关优化和提升AWS EFS性能的重要提示。并且您无需为那些不需要的资源支付额外的费用。

Burst credits是EFS最容易被忽视的方面之一。这些credits被设计为在流量较高的时候，暂时提高您的应用性能。但是，它们只会持续较短的时间，并且需要一段时间才能够恢复。因此，这就意味着如果credits被用完了，那么应用的性能就可能会突降。

每个EFS卷通常是以0.5 MB/s的传输速率开始的。Burst credits可以将吞吐量补充并拉升到100 MB/s，且持续7.2分钟。而增加此类指标的唯一方法是：增加EFS卷中存储的数据量。也就是说，在最高可达到10 GB的数据量时，您可以持续获得良好的性能

异步写入操作可以让您通过消减数据传输的部分路径，来减少写入操作所产生的延迟。在启用异步写入之后，数据会先被缓冲到某个EC2的实例中，再写入EFS。

不过，值得注意的是，此项操作可能会影响数据的一致性。因此，如果您要求文件系统保持实时同步的话，最好不要采用该操作方法。

如果您直接尝试着在EFS中运行应用程序的话，则可能会碰到性能不佳状况。毕竟，EFS并非被设计为运行或托管应用程序。它既无法执行针对大文件的读取，又无法为管理代码库、或部署应用程序提供所需的速度。

相反，您应该从EBS（Elastic Block Store）和EC2处托管或运行应用程序（请参见– https://dzone.com/articles/confused-by-aws-storage-options-s3-ebs-amp-efs-explained），并为附件文件重新存储EFS。例如，您可以让EFS只提供的内容，而将其对应的服务限制在EC2中，以确保应用能够获得预期的性能。

跟踪平均I/O吞吐量，可以帮助我们确定现有应用的瓶颈，进而设法压缩存储的区域。例如：如果某一个应用程序需要用到多个文件，那么我们就可以将这些文件组合为一个，进而减少对于吞吐量的需求。相反，针对那些频繁请求多个小文件的操作，很可能会在较短的时间内迅速达到并超出预先设定的吞吐量限制。

可见，通过减少可能的文件请求数量，我们可以降低每秒钟的I/O操作。这不但有助于减少延迟的开销，而且能够保持一定的性能区间。

由于没有可用的快照功能，因此如果您想在EFS中创建备份的话，则可能会遇到困难。通常，您必须使用AWS Backup服务，或是执行EFS-to-EFS来进行备份。不过，无论采用哪种方法，您都需要保存好各种备份的副本，并严密监控备份所需要的存储空间。

此外，在创建备份时，您最好安排在非工作时间，并以限速复制的方式进行创建。这样不但可以避免影响到各项标准操作的性能，而且可以防止意外burst credits的发生。

在使用EFS时，您可以选择两种性能模式：

· 通用意图（General Purpose） – 提供较低的吞吐量，以换取较低的延迟操作。它被设计为用于标准化的任务，例如：web主机或内容管理。而且，这是EFS的默认性能设置。

· 最大I/O（Max I/O） — 提供较高的吞吐量，以换取较高的延迟。它被设计为用于处理繁琐的计算任务，例如：媒体处理或大数据分析（请参见–https://dzone.com/articles/a-beginners-guide-to-big-data）。

EFS被设计为允许大规模的并发连接，并且可以同时附加多达上千个EC2实例。据此，您可以通过分担不同的应用程序与负载，来显著地提高整体性能。当然，在配置这些连接时，您仍然会受到各个卷的总吞吐量、以及传输速度的限制。

Amazon EFS虽然是一个功能强大的工具，但是与许多其他自配置（self-configured）的服务一样，它仍然需要您定期进行优化。为了避免不必要的开销，您应该定期监视EFS的burst credits和平均I/O吞吐量。同时，为了确保具有最佳的性能，您既可以使用异步写入操作，又应当避免从EFS上直接运行应用程序。此外，为了避免产生额外的计费，您不但需要管理好各种备份，而且要为应用负载选择正确的性能模式。最后，您还可以利用并发连接来提高整体性能。