Amazon FSx for Lustre 性能

Amazon FSx for Lustre 建置於流行的高效能檔案系統 Lustre 上，可提供隨著系統大小線性提升的水平擴充效能。Lustre 檔案系統可在多個檔案伺服器和磁碟之間水平擴充。這種擴展可讓每個用戶端直接存取儲存在每個磁碟上的資料，以消除傳統檔案系統中存在的許多瓶頸。適用於 Lustre 的 Amazon FSx 建置在 Lustre 的可擴展架構上，以支援大量用戶端的高效能。

Lustre 檔案系統的 FSx 如何運作

每個 FSx for Lustre 檔案系統都包含用戶端通訊的檔案伺服器，以及一組磁碟連接到儲存資料的每個檔案伺服器上。每個檔案伺服器都採用快速的記憶體內快取，以增強最常存取資料的效能。您也可以佈建以 SSD 為基礎的讀取快取，以進一步提升最常存取資料的效能。當用戶端存取儲存在記憶體內或 SSD 快取中的資料時，檔案伺服器不需要從磁碟讀取資料，因此可減少延遲並增加您可以驅動的總輸送量。下圖說明寫入作業的路徑、從磁碟提供的讀取作業，以及從記憶體內或 SSD 快取提供的讀取作業。

當您讀取儲存在檔案伺服器的記憶體內或 SSD 快取中的資料時，檔案系統效能取決於網路輸送量。當您將資料寫入檔案系統，或讀取未儲存在記憶體內快取中的資料時，檔案系統效能取決於較低的網路輸送量和磁碟輸送量。

當您佈建具有 SSD 快取的 HDD Lustre 檔案系統時，Amazon FSx 會建立一個固態硬碟快取，該快取會自動調整大小為檔案系統硬碟儲存容量的 20%。這樣做可為經常存取的檔案提供低於一毫秒的延遲和更高的 IOPS。

彙總檔案系統效能

Lustre 檔案系統的 FSx 所支援的輸送量與其儲存容量成正比。Amazon FSx for Lustre 檔案系統可擴展到數百 GBP 的輸送量和數百萬 IOPS。Amazon FSx for Lustre 也支援從數千個運算執行個體同時存取相同的檔案或目錄。這種存取可讓您從應用程式記憶體到儲存裝置的快速資料檢查點，這是高效能運算 (HPC) 中常用的技術。您可以在建立檔案系統之後，隨時視需要增加儲存容量和輸送量容量。如需詳細資訊，請參閱 管理儲存容量。

FSx for Lustre 檔案系統使用網路 I/O 信用機制提供突發讀取輸送量，以根據平均頻寬使用率配置網路頻寬。當檔案系統的網路頻寬使用量低於其基準限制時，就會累積點數，並且可以在執行網路資料傳輸時使用這些點數。

下表顯示 FSx for Lustre 部署選項所設計的效能。

SSD 儲存選項的檔案系統效能
部署類型	網路輸送量 (已佈建儲存體的 MB/S/TIB)		網路 IOPS (已佈建的 IOPS/TIB 儲存空間)	快取儲存 (已佈建的 RAM/TIB 的儲存區)	每個檔案作業的磁碟延遲 (毫秒，P50)	磁碟輸送量 (已佈建的儲存體或 SSD 快取的 MBPS/TIB)
	基準線	爆裂				基準線	爆裂
抓點 _2	200	1300	成千上萬條基線 數十萬爆	6.7	元數據：子毫秒 數據：子毫秒	二百元 (已讀取) 一百 (寫入)	‐
持久性的同位	320	1300		3.4		125	500
持久性的同位	640	1300		6.8		250	500
持久性	1300	‐		13.7		500	‐
持久性	2600	‐		27.3		1000	‐

硬碟儲存選項的檔案系統效能
部署類型	網路輸送量 (已佈建的儲存體或 SSD 快取的 MB/S/TiB)		網路 IOPS (已佈建的 IOPS/TIB 儲存空間)	快取儲存 (已佈建的 RAM/TIB 的儲存區)	每個檔案作業的磁碟延遲 (毫秒，P50)	磁碟輸送量 (已佈建的儲存體或 SSD 快取的 MBPS/TIB)
	基準線	爆裂				基準線	爆裂
持久性十二
硬碟儲存	40	375*	成千上萬條基線 數十萬爆	0.4 memory	元數據：子毫秒 資料：單位數 ms	12	80 人 (已閱讀) 50 (寫入)
SSD 讀取快取	200	1,900		200 固態硬碟快取	數據：子毫秒	200	-
持久性的 -40
硬碟儲存	150	1,300*	成千上萬條基線 數十萬爆	1.5	元數據：子毫秒 資料：單位數 ms	40	二百五十人 (已讀) 寫入
SSD 讀取快取	750	6500		200 SSD cache	數據：子毫秒	200	-

前一代 SSD 儲存選項的檔案系統效能
部署類型	網路輸送量 (每佈建儲存體 TiB 的 MB/s)		網路 IOPS (每個已佈建儲存 TiB 的 IOPS)	快取儲存 (每佈建儲存 TiB 的 GiB)	每個檔案作業的磁碟延遲 (毫秒，P50)	磁碟輸送量 (每 TiB 的儲存體或固態硬碟快取佈建的 MB/s)
	基準線	爆裂				基準線	爆裂
持久性的 -50	250	1,300*	成千上萬條基線 數十萬爆	2.2 RAM	元數據：子毫秒 數據：子毫秒	50	240
持久性 -100	500	1,300*		4.4 RAM		100	240
持久性 -200	750	1,300*		8.8 RAM		200	240

注意

* 以下的持續性檔案系統AWS 區域提供每 TiB 儲存空間高達 530 MB/s 的網路：非洲 (開普敦)、亞太區域 (香港)、亞太區域 (大阪)、亞太區域 (新加坡)、加拿大 (中部)、歐洲 (法蘭克福)、歐洲 (倫敦)、歐洲 (米蘭)、歐洲 (斯德哥爾摩)、中東 (巴林)、南美 (聖保羅)、美國西部。

注意

FSx for Lustre CH_1 的部署選項是為了支援每秒 200 MB /TIB 而設計。

範例：彙總基準和成組分解輸送量

下列範例說明儲存容量和磁碟輸送量如何影響檔案系統效能。

每單位儲存體輸送量為 4.8 TiB 和 50 MB/s 的永久性檔案系統，提供每單位儲存體輸送量的彙總基準磁碟輸送量為 240 MB/s，以及每秒 1.152 Gb/s 的高載磁碟輸送量。

無論檔案系統大小為何，Amazon FSx for Lustre 都能為檔案操作提供一致且低於一毫秒的延遲。

檔案系統儲存配置

Lustre 中的所有檔案資料都儲存在稱為物件儲存目標 (OST) 的儲存磁碟區上。所有檔案中繼資料 (包括檔案名稱、時間戳記、權限等) 都儲存在稱為中繼資料目標 (MDT) 的儲存磁碟區中。適用於 Lustre 檔案系統的 Amazon FSx 是由單一 MDT 和多個作業系統所組成。視檔案系統的部署類型而定，每個 OST 的大小約為 1 到 2 TiB。Amazon FSx for Lustre 會將您的檔案資料分散到組成檔案系統的 OST，以在儲存容量與輸送量和 IOPS 負載之間取得平衡。

若要檢視組成檔案系統之 MDT 和 OST 的儲存空間使用量，請從已掛載檔案系統的用戶端執行下列命令。

lfs df -h mount/path

此令命的輸出結果如下所示：

UUID                             bytes       Used   Available Use% Mounted on
mountname-MDT0000_UUID           68.7G       5.4M       68.7G   0% /fsx[MDT:0]
mountname-OST0000_UUID            1.1T       4.5M        1.1T   0% /fsx[OST:0]
mountname-OST0001_UUID            1.1T       4.5M        1.1T   0% /fsx[OST:1]

filesystem_summary:               2.2T       9.0M        2.2T   0% /fsx

在檔案系統中分割資料

您可以使用檔案分割來最佳化檔案系統的輸送量效能。Amazon FSx for Lustre 會自動將檔案分散到各個作業系統，以確保所有儲存伺服器都能提供資料。您可以在檔案層級套用相同的概念，方法是設定檔案在多個 OST 間分段的方式。

分段意味著文件可以分為多個塊，然後存儲在不同的 OST 中。當檔案跨多個 OS 進行分段處理時，檔案的讀取或寫入要求會散佈在這些 OS 中，從而增加應用程式可透過它驅動的彙總輸送量或 IOPS。

以下是適用於 Lustre 檔案系統的亞馬遜 FSx 的預設配置。

• 對於在 2020 年 12 月 18 日之前建立的檔案系統，預設配置會指定條帶計數為 1。這表示除非指定不同的配置，否則使用標準 Linux 工具在 Amazon FSx for Lustre 中建立的每個檔案都會儲存在單一磁碟上。

• 對於在 2020 年 12 月 18 日之後建立的檔案系統，預設配置是漸進式檔案配置，其中 1GiB 以下的檔案會儲存在一個分段中，而較大的檔案則會指定條帶數為 5。

• 對於在 2023 年 8 月 25 日之後建立的檔案系統，預設配置是 4 組件漸進式檔案配置，如中所述。漸進式檔案配置

• 對於所有檔案系統，無論其建立日期為何，從 Amazon S3 匯入的檔案都不會使用預設配置，而是使用檔案系統ImportedFileChunkSize參數中的配置。大於 S3 匯入的檔案ImportedFileChunkSize將會儲存在多個具有分割計數的 OST 上。(FileSize / ImportedFileChunksize) + 1的預設值ImportedFileChunkSize為 1GiB。

您可以使用lfs getstripe指令檢視檔案或目錄的配置組態。

lfs getstripe path/to/filename

此命令會報告檔案的資料帶計數、資料帶大小和條帶偏移量。等量計數是檔案跨越多少個作業系統。條帶大小是 OST 上存儲多少連續數據。條紋偏移量是文件條帶跨越的第一個 OST 的索引。

修改您的分割配置

第一次建立檔案時會設定檔案的配置圖參數。使用指lfs setstripe令建立具有指定配置圖的新空檔案。

lfs setstripe filename --stripe-count number_of_OSTs

此指lfs setstripe令只會影響新檔案的配置。在創建文件之前，請使用它來指定文件的佈局。您也可以定義目錄的配置圖。一旦在目錄上設置，該佈局將應用於添加到該目錄的每個新文件，但不應用於現有文件。您建立的任何新子目錄也會繼承新的配置，然後將其套用至您在該子目錄中建立的任何新檔案或目錄。

若要修改既有檔案的配置，請使用lfs migrate指令。此指令會依需要複製檔案，以根據您在指令中指定的配置來分發其內容。例如，附加或增加大小的檔案並不會變更條紋計數，因此您必須移轉它們才能變更檔案配置。或者，您可以使用指lfs setstripe令建立新檔案來指定其配置，將原始內容複製到新檔案，然後重新命名新檔案以取代原始檔案。

在某些情況下，預設配置組態並非最適合您的工作負載。例如，具有數十個 OS 和大量多 GB 檔案的檔案系統，可能會將檔案分割到超過五個 OS 的預設分割計數值，以獲得更高的效能。建立資料分割數量較低的大型檔案可能會造成 I/O 效能瓶頸，也可能造成 OST 填滿。在這種情況下，您可以為這些文件創建具有較大條帶計數的目錄。

為大型檔案 (特別是大於 GB 的檔案) 設定分段佈局非常重要，原因如下：

• 透過允許多個 OST 及其相關伺服器在讀取和寫入大型檔案時貢獻 IOPS、網路頻寬和 CPU 資源，藉此改善輸送量。

• 降低一小部分作業系統成為會限制整體工作負載效能的熱點的可能性。

• 防止單個大文件填充 OST，從而可能導致磁盤已滿錯誤。

所有使用案例都沒有單一的最佳配置組態。如需檔案配置的詳細指引，請參閱 Lustre.org 文件中的管理檔案配置 (分割) 和可用空間。以下是一般準則：

• 條紋佈局對於大文件最重要，特別是對於通常文件大小為數百兆字節或更大的用例。基於這個原因，新檔案系統的預設配置會針對大小超過 1GiB 的檔案指派五個分段計數。

• 條紋計數是您應該針對支持大文件的系統進行調整的佈局參數。條帶計數指定將保存分區文件塊的 OST 卷的數量。例如，如果條帶計數為 2，條帶大小為 1MiB，Lustre 會將文件的替代 1MiB 塊寫入到兩個 OST 中的每一個。

• 有效的資料帶計數是 OST 磁碟區實際數目和您指定的資料帶計數值中較小的一個。您可以使用的特殊條帶計數值-1來表示應將條帶放置在所有 OST 卷上。

• 為小文件設置大條帶計數是次優的，因為對於某些操作，Lustre 需要對佈局中的每個 OST 進行網絡往返，即使文件太小而無法消耗所有 OST 卷上的空間。

• 您可以設定漸進式檔案版面配置 (PFL)，讓檔案的版面配置隨著大小而變更。PFL 組態可以簡化管理具有大型和小型檔案組合的檔案系統，而不必為每個檔案明確設定組態。如需詳細資訊，請參閱 漸進式檔案配置。

• 根據預設，分割大小為 1MiB。在特殊情況下，設置條紋偏移量可能是用戶的，但通常最好將其保留為未指定並使用默認值。

漸進式檔案配置

您可以為目錄指定漸進式檔案配置 (PFL) 組態，以便在填入小型和大型檔案之前指定不同的分割區組態。例如，您可以在將任何資料寫入新檔案系統之前，先在頂層目錄上設定 PFL。

若要指定 PFL 規劃，請使用具有-E選項的指lfs setstripe令來為不同大小的檔案指定配置元件，例如下列指令：

lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname/directory

此指令會設定四個配置元件：

• 第一個元件 (-E 100M -c 1) 表示大小不超過 100MiB 的檔案的分割計數值為 1。

• 第二個元件 (-E 10G -c 8) 表示檔案大小不超過 10GiB 的分段計數為 8。

• 第三個元件 (-E 100G -c 16) 表示大小不超過 100GiB 的檔案的條帶計數為 16。

• 對於大於 100GiB 的檔案，第四個元件 (-E -1 -c 32) 表示條帶計數為 32。

重要

將數據附加到使用 PFL 佈局創建的文件將填充其所有配置組件。例如，使用上面顯示的 4 組件命令，如果您創建一個 1MiB 文件，然後將數據添加到其末尾，則文件的佈局將擴展到具有 -1 的條帶計數，這意味著系統中的所有 OST。這並不意味著將數據寫入每個 OST，但是諸如讀取文件長度之類的操作將發送與每個 OST parallel 的請求，從而為文件系統增加了顯著的網絡負載。

因此，請小心限制任何隨後可以附加資料的小型或中等長度檔案的資料分割計數。由於記錄檔通常是透過附加新記錄而成長，因此 Amazon FSx for Lustre 會將預設的條帶計數指派給在附加模式下建立的任何檔案，無論其父目錄所指定的預設分割組態為何。

在 2023 年 8 月 25 日之後建立的 Lustre 檔案系統之 Amazon FSx 上的預設 PFL 組態，可使用以下指令設定：

lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname

具有高度並行存取中型檔案和大型檔案之工作負載的客戶，很可能會受益於具有較多條紋、較小尺寸、以及針對最大檔案的所有 OST 進行分割的版面配置，如四元件範例配置所示。

監控效能和使用情況

Amazon FSx for Lustre 每分鐘都會向 Amazon 發出每個磁盤（MDT 和 OST）的使用指標。 CloudWatch

若要檢視聚總檔案系統使用狀況詳細資訊，您可以查看每個測量結果的「總和」統計值。例如，DataReadBytes統計資料的總和會報告檔案系統中所有 OST 看到的總讀取輸送量。同樣地，統FreeDataStorageCapacity計資料的總和會報告檔案系統中檔案資料的可用儲存容量總計。

如需監視檔案系統效能的詳細資訊，請參閱監控 Amazon FSx for Lustre。

效能秘訣

使用 Amazon FSx for Lustre 時，請牢記以下效能提示。如需服務限制，請參閱配額。

• 平均 I/O 大小 — 由 Amazon FSx for Lustre 是網路檔案系統，因此每個檔案作業都會在用戶端和 Amazon FSx for Lustre) 之間進行往返，因此會產生較小的延遲開銷。由於每個作業的低延遲，因此整體傳輸量通常會隨著平均 I/O 大小的增加而提高，因為延遲負擔會由大量的資料分攤。

• 請求模型 — 透過啟用對檔案系統的非同步寫入，擱置中的寫入操作會在 Amazon EC2 執行個體上緩衝，然後再以非同步方式寫入 Amazon FSx for Lustre。非同步寫入作業的延遲通常較低。執行非同步寫入時，核心會使用額外的記憶體來進行快取。已啟用同步寫入的檔案系統會向 Amazon FSx for Lustre 同步請求。每個操作都經過客戶端和 Amazon FSx for Lustre 之間的往返。

  注意

  您所選擇的請求模型，必須在一致性 (如果使用多個 Amazon EC2 執行個體) 和速度之間權衡折衷。

• Amazon EC2 執行個體 — 執行大量讀取和寫入作業的應用程式可能需要比沒有執行的應用程式更多的記憶體或運算容量。為運算密集型工作負載啟動 Amazon EC2 執行個體時，請選擇具有應用程式所需資源數量的執行個體類型。適用於 Lustre 檔案系統的 Amazon FSx 效能特性不取決於 Amazon EBs 優化執行個體的使用情況。

• 建議的用戶端執行個體調整以獲得

  1. 對於所有用戶端執行個體類型和大小，我們建議您套用下列調整：

     sudo lctl set_param osc.*.max_dirty_mb=64

  2. 對於記憶體超過 64 GiB 的用戶端執行個體類型，建議您套用下列調整：

     lctl set_param ldlm.namespaces.*.lru_max_age=600000

  3. 對於具有 64 個 vCPU 核心以上的用戶端執行個體類型，建議您套用下列調整：

     echo "options ptlrpc ptlrpcd_per_cpt_max=32" >> /etc/modprobe.d/modprobe.conf
     echo "options ksocklnd credits=2560" >> /etc/modprobe.d/modprobe.conf
                 
     # reload all kernel modules to apply the above two settings
     sudo reboot

     掛載用戶端之後，需要套用下列調整：

     sudo lctl set_param osc.*OST*.max_rpcs_in_flight=32
     sudo lctl set_param mdc.*.max_rpcs_in_flight=64
     sudo lctl set_param mdc.*.max_mod_rpcs_in_flight=50

  請注意，lctl set_param已知不會在重新啟動後持續存在。由於無法從用戶端永久設定這些參數，因此建議您實作開機 cron 工作，以使用建議的調整來設定組態。

• 不同作業系統的工作負載平衡 — 在某些情況下，您的工作負載無法驅動檔案系統可提供的彙總輸送量 (每 TiB 儲存 200 MB/s)。如果是這樣，您可以使用 CloudWatch 指標來疑難排解效能是否受到工作負載 I/O 模式不平衡的影響。若要確定這是否為原因，請查看適用於 Amazon FSx for Lustre 最大 CloudWatch 指標。

  在某些情況下，此統計資料顯示輸送量達到或高於 240 MBps 的負載 (Lustre 磁碟的單一 1.2-TiB Amazon FSx 的輸送量容量)。在這種情況下，您的工作負載不會平均分散到磁碟上。在這種情況下，您可以使用命lfs setstripe令來修改工作負載最常存取的檔案的分割。為了獲得最佳效能，請將具有高輸送量需求的檔案分割到包含您檔案系統的所有 OST。

  如果您的檔案是從資料儲存庫匯入的，您可以採用另一種方法，將高輸送量檔案平均分割到您的 OST 上。若要這麼做，您可以在建立下一個適用於 Lustre 檔案系統的 Amazon FSx 時修改ImportedFileChunkSize參數。

  例如，假設您的工作負載使用 7.0-TiB 檔案系統 (由 6 x 1.17 TiB 作業系統組成)，而且需要在 2.4-GiB 檔案之間驅動高輸送量。在這種情況下，您可以將ImportedFileChunkSize值設定為，(2.4 GiB / 6 OSTs) = 400 MiB讓檔案平均分散到檔案系統的 OST。