本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
Amazon FSx 的光澤性能
Amazon FSx 為 Lustre 建置於流行的高效能檔案系統 Lustre 上，可提供擴充效能，隨著系統的大小線性提升。Lustre 檔案系統可在多個檔案伺服器和磁碟之間水平擴充。這種擴展可讓每個用戶端直接存取儲存在每個磁碟上的資料，以消除傳統檔案系統中存在的許多瓶頸。Amazon FSx 的 Lustre 建立在 Lustre 的可擴展架構上，以支持大量客戶的高性能。
光澤文件系FSx統如何工作
Lustre 檔案系統的每個FSx檔案系統都包含用戶端通訊的檔案伺服器，以及一組連接到儲存資料的檔案伺服器上的磁碟。每個檔案伺服器都採用快速的記憶體內快取，以增強最常存取資料的效能。HDD基於檔案系統也可以佈建SSD基於讀取快取，以進一步增強最常存取資料的效能。當用戶端存取儲存在記憶體內或SSD快取中的資料時，檔案伺服器不需要從磁碟讀取資料，這樣可以減少延遲並增加您可以驅動的總輸送量。下圖說明寫入作業的路徑、從磁碟提供的讀取作業，以及從記憶體內或SSD快取提供的讀取作業。
當您讀取儲存在檔案伺服器記憶體內或SSD快取記憶體中的資料時，檔案系統效能取決於網路輸送量。當您將資料寫入檔案系統，或讀取未儲存在記憶體內快取中的資料時，檔案系統效能取決於較低的網路輸送量和磁碟輸送量。
當您使用SSD快取佈建 HDD Lustre 檔案系統時，Amazon 會FSx建立一個自動調整大小為檔案系統HDD儲存容量 20% 的SSD快取。這樣做可提供低於一毫秒的延遲，而經常存取的檔案則提供更高IOPS的延遲。
彙總檔案系統效能
Lustre 檔案系統支援的輸送量與其儲存容量成正比。FSxAmazon FSx 的 Lustre 檔案系統可擴展到數百個輸送量和數GBps百萬個輸送量。IOPSAmazon FSx to Lustre 也支援從數千個運算執行個體同時存取相同的檔案或目錄。這種存取可讓您從應用程式記憶體到儲存裝置的快速資料檢查點，這是高效能運算中常見的技術 (HPC)。您可以在建立檔案系統之後，隨時視需要增加儲存容量和輸送量容量。如需詳細資訊，請參閱管理儲存容量。
FSxLustre 檔案系統使用網路 I/O 信用機制，根據平均頻寬使用率配置網路頻寬，提供突發讀取輸送量。當檔案系統的網路頻寬使用量低於其基準限制時，就會累積點數，並且可以在執行網路資料傳輸時使用這些點數。
下表顯示FSx針對 Lustre 部署選項所設計的效能。
| 部署類型 | 網路輸送量 (已佈建儲存體的 MB/S/TIB) | 網路 IOPS (IOPS/TIB 的已佈建儲存區) | 快取儲存 (已佈建儲存區的 RAM /TiB 的 GiB) | 每個檔案作業的磁碟延遲 (毫秒，P50) | 磁碟輸送量 (MBps/TiB 的儲存SSD體或快取已佈建) | ||
|---|---|---|---|---|---|---|---|
基準線 |
爆裂 |
基準線 |
爆裂 |
||||
| SCRATCH_2 | 200 | 1300 | 數萬條基線 數十萬爆發 |
6.7 |
元數據：子毫秒 數據：子毫秒 |
二百 (已讀取) 一百 (寫入) |
‐ |
| PERSISTENT-125 | 320 | 1300 | 3.4 |
125 |
500 | ||
| PERSISTENT-250 | 640 | 1300 | 6.8 |
250 |
500 | ||
| PERSISTENT-500 | 1300 | ‐ | 13.7 | 500 | ‐ |
||
| PERSISTENT-1000 | 2600 | ‐ | 27.3 | 1000 | ‐ | ||
| 部署類型 | 網路輸送量 (已佈建的儲存或快取記憶體的 MB/S/TIB) SSD | 網路 IOPS (IOPS/TIB 的已佈建儲存區) | 快取儲存 (已佈建儲存區的 RAM /TiB 的 GiB) | 每個檔案作業的磁碟延遲 (毫秒，P50) | 磁碟輸送量 (MBps/TiB 的儲存SSD體或快取已佈建) | ||
|---|---|---|---|---|---|---|---|
基準線 |
爆裂 |
基準線 |
爆裂 |
||||
| PERSISTENT-12 | |||||||
| HDD儲存 | 40 | 375* |
數萬條基線 數十萬爆發 |
記憶體 |
元數據：子毫秒 資料：單位數 ms |
12 |
80 人 (已閱讀) 50 (寫入) |
| SSD讀取快取 |
200 |
1,900 |
SSD快取記憶體 |
數據：子毫秒 |
200 |
- |
|
| PERSISTENT-40 | |||||||
| HDD儲存 | 150 | 一百三十 |
數萬條基線 數十萬爆發 |
1.5 |
元數據：子毫秒 資料：單位數 ms |
40 |
二百五十人 (已讀) 寫入 |
| SSD讀取快取 |
750 |
6500 |
SSD快取記憶體 |
數據：子毫秒 |
200 |
- |
|
| 部署類型 | 網路輸送量 (每佈建儲存體 TiB 的 MB/s) | 網路 IOPS (IOPS每佈建的儲存 TiB) | 快取儲存 (每佈建儲存 TiB 的 GiB) | 每個檔案作業的磁碟延遲 (毫秒，P50) | 磁碟輸送量 (每佈建的儲存或SSD快取記憶體每 TiB 的 MB/s) | ||
|---|---|---|---|---|---|---|---|
基準線 |
爆裂 |
基準線 |
爆裂 |
||||
| PERSISTENT-50 | 250 | 一百三十 | 數萬條基線 數十萬爆發 |
2.2 RAM |
元數據：子毫秒 數據：子毫秒 |
50 | 240 |
| PERSISTENT-100 | 500 | 一百三十 | 4.4 RAM | 100 | 240 | ||
| PERSISTENT-200 | 750 | 一百三十 | 8.8 RAM | 200 | 240 | ||
注意
* 以下的持續性檔案系統 AWS 區域 提供每 TiB 儲存空間高達 530 MB/s 的網路：非洲 (開普敦)、亞太區域 (香港)、亞太區域 (大阪)、亞太區域 (新加坡)、加拿大 (中部)、歐洲 (法蘭克福)、歐洲 (倫敦)、歐洲 (米蘭)、歐洲 (斯德哥爾摩)、中東 (巴林)、南美 (聖保羅)、美國西部。
範例：彙總基準和成組分解輸送量
下列範例說明儲存容量和磁碟輸送量如何影響檔案系統效能。
每單位儲存體輸送量為 4.8 TiB 和 50 MB/s 的永久性檔案系統，提供每單位儲存體輸送量的彙總基準磁碟輸送量為 240 MB/s，以及每秒 1.152 Gb/s 的高載磁碟輸送量。
無論檔案系統大小為何，Amazon of Lustre 都能FSx為檔案操作提供一致且低於一毫秒的延遲。
文件系統元數據性能
檔案系統中繼資料 IO 作業每秒 (IOPS) 決定每秒可建立、列出、讀取和刪除的檔案和目錄數目。系統會根據您佈建FSx的儲存容量，為 Lustre 檔案系統自動佈建中IOPS繼資料。
Persistent_2 檔案系統可讓您IOPS獨立於儲存容量佈建中繼資料，並提供更深入的瞭解檔案系統上驅動的中繼資料IOPS用戶端執行個體數量和類型。
FSx對於 Lustre Persistent_2 檔案系統，IOPS您佈建的中繼資料數目和中繼資料作業類型會決定檔案系統可支援的中繼資料作業速率。IOPS您佈建的中繼資料層級會決定為檔案系統的中繼資料磁碟IOPS佈建的數目。
| 操作類型 | 您可以為每個佈建的中繼資料每秒磁碟機的作業 IOPS |
|---|---|
|
檔案建立、開啟和關閉 |
2 |
|
檔案刪除 |
1 |
|
目錄建立, 重新命名 |
0.1 |
|
目錄刪除 |
0.2 |
您可以選擇IOPS使用自動模式或使用者佈建模式佈建中繼資料。在自動模式下，Amazon FSx 會IOPS根據下表自動根據檔案系統的儲存容量佈建中繼資料：
| 檔案系統儲存容量 | 自動模式IOPS中包含的元數據 |
|---|---|
|
1200 GiB |
1500 |
|
2400 GiB |
3000 |
|
4800—9600 GiB |
6000 |
|
千斤 GiB |
12000 |
|
≥48000 GiB |
IOPS每 24000 GiB |
在使用者佈建模式中，您可以選擇性地選擇指定要佈建的中IOPS繼資料數目。您需要支付高於檔案系統預設中繼資料數目IOPS佈建IOPS的中繼資料費用。
檔案系統儲存配置
Lustre 中的所有檔案資料都儲存在稱為物件儲存目標 () OSTs 的儲存磁碟區上。所有檔案中繼資料 (包括檔案名稱、時間戳記、權限等) 都儲存在稱為中繼資料目標 (MDTs) 的儲存磁碟區中。Amazon FSx 的 Lustre 文件系統由一個或多個MDTs和多個組成。OSTs每OST個大小約為 1 到 2 TiB，視檔案系統的部署類型而定。Amazon FSx to Lustre 會將您的檔案資料分散到組成檔案系統OSTs的各個位置，以平衡儲存容量與輸送量和IOPS負載。
若要檢視MDT和OSTs組成您檔案系統的儲存空間使用情況，請從已掛載檔案系統的用戶端執行下列命令。
lfs df -hmount/path
此令命的輸出結果如下所示：
UUID bytes Used Available Use% Mounted onmountname-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 to Lustre 會自動將檔案分散到各OSTs處，以確保所有儲存伺服器都能提供資料。您可以在檔案層級套用相同的概念，方法是設定檔案跨多個分段的方式OSTs。
分段意味著文件可以分為多個塊，然後存儲在不同OSTs的塊中。當檔案跨多個分段時OSTs，對檔案的讀取或寫入請求會分散在這些請求之間，從而增加彙總輸送量OSTs，或者IOPS您的應用程式可以透過該檔案進行驅動。
以下是 Amazon FSx Lustre 文件系統的默認佈局。
對於在 2020 年 12 月 18 日之前建立的檔案系統，預設配置會指定條帶計數為 1。這意味著除非指定了不同的佈局，否則使用標準 Linux 工具在 Amazon FSx 為 Lustre 中創建的每個文件都存儲在單個磁盤上。
對於在 2020 年 12 月 18 日之後建立的檔案系統，預設配置是漸進式檔案配置，其中 1GiB 以下的檔案會儲存在一個分段中，而較大的檔案則會指定條帶數為 5。
對於在 2023 年 8 月 25 日之後建立的檔案系統，預設配置是 4 組件漸進式檔案配置，如中所述。漸進式檔案配置
對於所有檔案系統，無論其建立日期為何，從 Amazon S3 匯入的檔案都不會使用預設配置，而是使用檔案系統
ImportedFileChunkSize參數中的配置。S3-匯入的檔案大於，ImportedFileChunkSize將儲存在多個檔案上，且條OSTs帶計數為。(FileSize / ImportedFileChunksize) + 1的預設值ImportedFileChunkSize為 1GiB。
您可以使用lfs getstripe指令檢視檔案或目錄的配置組態。
lfs getstripepath/to/filename
此命令會報告檔案的資料帶計數、資料帶大小和條帶偏移量。條帶計數是文OSTs件跨多少條帶。條帶大小是多少連續數據存儲在OST. 條帶偏移量是文件跨越的第OST一個文件的索引。
修改您的分割配置
首次建立檔案時會設定檔案的配置圖參數。使用指lfs setstripe令建立具有指定配置圖的新空檔案。
lfs setstripefilename--stripe-countnumber_of_OSTs
此指lfs setstripe令只會影響新檔案的配置。在創建文件之前，請使用它來指定文件的佈局。您也可以定義目錄的配置圖。一旦在目錄上設置，該佈局將應用於添加到該目錄的每個新文件，但不應用於現有文件。您建立的任何新子目錄也會繼承新配置，然後將其套用至您在該子目錄中建立的任何新檔案或目錄。
若要修改既有檔案的配置，請使用lfs migrate指令。此指令會依需要複製檔案，以根據您在指令中指定的配置來分發其內容。例如，附加或增加大小的檔案並不會變更條紋計數，因此您必須移轉它們才能變更檔案配置。或者，您可以使用指lfs setstripe令建立新檔案來指定其配置，將原始內容複製到新檔案，然後重新命名新檔案以取代原始檔案。
在某些情況下，預設配置組態不適合您的工作負載。例如，具有數十個OSTs和大量多 GB 檔案的檔案系統，可能會將檔案分割到超過預設分割計數值 5 以上，以獲得更高的效能。OSTs建立資料分割數量較低的大型檔案可能會造成 I/O 效能瓶頸，也可能造OSTs成填滿。在這種情況下，您可以為這些文件創建具有較大條帶計數的目錄。
為大型檔案 (特別是大於 GB 的檔案) 設定分段佈局非常重要，原因如下：
在讀取和寫入大型檔案時，允許多個OSTs及其關聯的伺服器貢獻IOPS、網路頻寬和CPU資源，藉此改善輸送量。
降低一小部分OSTs成為限制整體工作負載效能的熱點的可能性。
防止單個大文件填充OST，從而可能導致磁盤已滿錯誤。
所有使用案例都沒有單一的最佳配置組態。如需檔案配置的詳細指引，請參閱 Lustre.org 文件中的管理檔案配置 (分割) 和可用空間
條紋佈局對於大文件最重要，特別是對於通常文件大小為數百兆字節或更大的用例。基於這個原因，新檔案系統的預設配置會針對大小超過 1GiB 的檔案指派五個分段計數。
條紋計數是您應該針對支持大文件的系統進行調整的佈局參數。條帶計數指定將保存分區文件塊的OST卷的數量。例如，如果條帶計數為 2，條帶大小為 1MiB，Lustre 會將檔案的替代 1MiB 區塊寫入兩個區塊中的每個區塊。OSTs
有效分割計數是您指定的磁碟區實際數目和OST磁碟區計數值中較小的一個。您可以使用的特殊分割計數值
-1來表示應將磁帶放置在所有OST磁碟區上。為小型檔案設定較大的分割計數是次最佳狀態，因為對於某些作業，Lustre 需要網路往返配置OST中的每個檔案，即使檔案太小而無法佔用所有磁碟區上的空間也是如此。OST
您可以設置漸進式文件佈局（PFL），允許文件的佈局隨大小而變化。PFL配置可以簡化管理具有大型和小型檔案組合的檔案系統，而不必為每個檔案明確設定組態。如需詳細資訊，請參閱漸進式檔案配置。
根據預設，分割大小為 1MiB。在特殊情況下，設置條紋偏移量可能是用戶的，但通常最好將其保留為未指定並使用默認值。
漸進式檔案配置
您可以為目錄指定漸進式檔案配置 (PFL) 組態，以便在填入之前為小型和大型檔案指定不同的分割組態。例如，您可以PFL在將任何資料寫入新檔案系統之前，在頂層目錄上設定 a。
若要指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 的條帶計數，這意味著系統OSTs中的所有文件。這並不意味著數據將寫入到每一個OST，但是像讀取文件長度這樣的操作會 parallel 地發送一個請求OST，從而增加了文件系統的顯著網絡負載。
因此，請小心限制任何隨後可以附加資料的小型或中等長度檔案的資料分割計數。由FSx於記錄檔通常是透過附加新記錄而成長，因此 Amazon to Lustre 會將預設的分段計數指派給在附加模式下建立的任何檔案，而不論其父目錄所指定的預設分割組態為何。
在 2023 年 8 月 25 日之後建立FSx的 Lustre 檔案系統的 Amazon 預PFL設設定是使用以下指令設定：
lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32/mountname
具有高度並行存取中型檔案和大型檔案之工作負載的客戶，很可能會受益於具有較大尺寸條紋較多的版面配置，以及OSTs針對最大檔案進行分割，如四個元件範例配置所示。
監控效能和使用情況
Amazon FSx 的 Lustre 每分鐘都會向 Amazon 發出每個磁盤（MDT和OST）的使用指標。 CloudWatch
若要檢視聚總檔案系統使用狀況詳細資訊，您可以查看每個測量結果的「總和」統計值。例如，統DataReadBytes計資料的總和會報告檔案系統OSTs中所有人看到的總讀取輸送量。同樣地，統FreeDataStorageCapacity計資料的總和會報告檔案系統中檔案資料的可用儲存容量總計。
如需監視檔案系統效能的詳細資訊，請參閱監控 Amazon FSx for Lustre。
效能秘訣
使用 Amazon FSx 進行 Lustre 時，請記住以下性能提示。如需服務限制，請參閱適用於 Amazon FSx for Lustre 配額。
-
平均 I/O 大小 — 由FSx於 Amazon to Lustre 是一個網路檔案系統，因此每個檔案作業都會在用戶端和 Amazon (FSx針對 Lustre) 之間進行往返，因此會產生較小的延遲負荷。由於每個作業的低延遲，因此整體傳輸量通常會隨著平均 I/O 大小的增加而提高，因為延遲負擔會由大量的資料分攤。
-
請求模型 — 透過啟用對檔案系統的非同步寫入，擱置的寫入操作會在 Amazon EC2 執行個體上緩衝，然後再以非同步方式寫入 Amazon FSx 進行 Lustre。非同步寫入作業的延遲通常較低。執行非同步寫入時，核心會使用額外的記憶體來進行快取。啟用同步寫入的檔案系統會向 Amazon 發出 Lustre FSx 的同步請求。每個操作都經過客戶端和 Amazon 的 Lustre 之間FSx的往返。
注意
您選擇的請求模型具有一致性的權衡 (如果您使用多個 Amazon EC2 執行個體) 和速度。
-
限制目錄大小 — 若要在 Lustre 檔案系統的永久性 _2 上達到最佳的中繼資料效能，FSx請將每個目錄限制為少於 10 萬個檔案。限制目錄中的檔案數可減少檔案系統在父目錄上取得鎖定所需的時間。
-
Amazon EC2 執行個體 — 執行大量讀取和寫入作業的應用程式可能需要的記憶體或運算容量比不需要的應用程式更多。為運算密集型工作負載啟動 Amazon EC2 執行個體時，請選擇具有應用程式所需資源數量的執行個體類型。適用於 Lustre 檔案系統FSx的 Amazon 效能特性不取決於 Amazon EBS 優化執行個體的使用情況。
-
建議的用戶端執行個體調整以獲得
對於所有用戶端執行個體類型和大小，我們建議您套用下列調整：
sudo lctl set_param osc.*.max_dirty_mb=64對於記憶體超過 64 GiB 的用戶端執行個體類型，建議您套用下列調整：
sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000 sudo lctl set_param ldlm.namespaces.*.lru_size=<100 *number_of_CPUs>對於具有 64 v CPU 核心以上的用戶端執行個體類型，建議您套用下列調整：
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 工作，以使用建議的調整來設定組態。 -
工作負載平衡 OSTs — 在某些情況下，您的工作負載無法驅動檔案系統可提供的彙總輸送量 (每 TiB 儲存 200 MB/s)。如果是這樣，您可以使用 CloudWatch 指標來疑難排解效能是否受到工作負載 I/O 模式不平衡的影響。要確定這是否是原因，請查看 Amazon FSx Lustre 的最大 CloudWatch 指標。
在某些情況下，此統計資料顯示輸送量達到 240 或以上MBps的負載 (Lustre 磁碟的單一 1.2-TiB Amazon FSx 輸送量容量)。在這種情況下，您的工作負載不會平均分散到磁碟上。在這種情況下，您可以使用命
lfs setstripe令來修改工作負載最常存取的檔案的分割。為了獲得最佳效能，請將具有高輸送量需求的檔案分割到所有OSTs組成的檔案系統中。如果您的檔案是從資料儲存庫匯入的，您可以採用另一種方法，將高輸送量檔案平均分割到您OSTs的. FSx為此，您可以在創建下一個 Amazon 的 Lustre 文件系統時修改
ImportedFileChunkSize參數。例如，假設您的工作負載使用 7.0-TiB 檔案系統 (由 6 x 1.17-TiB 組成OSTs)，並且需要在 2.4-GiB 檔案之間驅動高輸送量。在此情況下，您可以將
ImportedFileChunkSize值設定為，(2.4 GiB / 6 OSTs) = 400 MiB讓檔案平均分散在檔案系統中OSTs。 -
中繼資料的光澤用戶端 IOPS — 如果你的檔案系統有指定的中繼資料配置，我們建議你安裝一個 Lustre 2.15 用戶端或光譜 2.12 用戶端，其中一個作業系統版本：Amazon Linux 2；紅帽子 8.9、8.10 或 9.x；CentOS 8.9 或 8.10；
