值得注意的七條有關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上直接運行應用程序。此外，為了避免產生額外的計費，您不但需要管理好各種備份，而且要為應用負載選擇正確的性能模式。最后，您還可以利用并發連接來提高整體性能。

原文地址： https://www.linuxprobe.com/notice-aws-efs-performence.html