本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # Amazon FSx for Lustre 效能 本章提供 Amazon FSx for Lustre 效能主題，包括最佳化檔案系統效能的一些重要秘訣和建議。 **Topics** + [概觀](#performance-overview) + [FSx for Lustre 檔案系統的運作方式](#how-lustre-fs-work) + [檔案系統中繼資料效能](#dne-metadata-performance) + [個別用戶端執行個體的輸送量](#throughput-clients) + [檔案系統儲存配置](#storage-layout) + [分割檔案系統中的資料](#striping-data) + [監控效能和用量](#performance-monitoring) + [SSD 和 HDD 儲存類別的效能特性](ssd-storage.md) + [Intelligent-Tiering 儲存類別的效能特性](intelligent-tiering-file-systems.md) + [效能秘訣](performance-tips.md) ## 概觀 Amazon FSx for Lustre 以Lustre熱門的高效能檔案系統 為基礎，提供隨檔案系統大小線性增加的橫向擴展效能。 Lustre 檔案系統可水平擴展多個檔案伺服器和磁碟。此擴展可讓每個用戶端直接存取儲存在每個磁碟上的資料，以消除傳統檔案系統中存在的許多瓶頸。Amazon FSx for Lustre 以Lustre可擴展的架構為基礎，支援大量用戶端的高效能。 ## FSx for Lustre 檔案系統的運作方式 每個 FSx for Lustre 檔案系統都包含用戶端與之通訊的檔案伺服器，以及連接至儲存資料之每個檔案伺服器的一組磁碟。每個檔案伺服器都採用快速的記憶體內快取，以增強最常存取資料的效能。根據儲存類別，您的檔案伺服器可以使用選用的 SSD 讀取快取進行佈建。當用戶端存取儲存在記憶體內或 SSD 快取中的資料時，檔案伺服器不需要從磁碟讀取資料，這可減少延遲並增加您可以驅動的總輸送量。下圖說明寫入操作的路徑、從磁碟提供的讀取操作，以及從記憶體或 SSD 快取提供的讀取操作。 ![\[FSx for Lustre 效能架構。\]](http://docs.aws.amazon.com/zh_tw/fsx/latest/LustreGuide/images/LustrePerfDiagram.png) 當您讀取存放在檔案伺服器記憶體內或 SSD 快取的資料時，檔案系統效能取決於網路輸送量。當您將資料寫入檔案系統，或讀取未存放在記憶體內快取的資料時，檔案系統效能取決於較低的網路輸送量和磁碟輸送量。 若要進一步了解 SSD 和 HDD 儲存類別的網路輸送量、磁碟輸送量和 IOPS 特性，請參閱 [SSD 和 HDD 儲存類別的效能特性](ssd-storage.md)和 [Intelligent-Tiering 儲存類別的效能特性](intelligent-tiering-file-systems.md)。 ## 檔案系統中繼資料效能 每秒檔案系統中繼資料 IO 操作 (IOPS) 決定您可以每秒建立、列出、讀取和刪除的檔案和目錄數量。 持久性 2 檔案系統可讓您佈建與儲存容量無關的中繼資料 IOPS，並提高對檔案系統上中繼資料 IOPS 用戶端執行個體數量和類型的可見性。使用 SSD 檔案系統時，中繼資料 IOPS 會根據您佈建的儲存容量自動佈建。Intelligent-Tiering 檔案系統不支援自動模式。 透過 FSx for Lustre 持久性 2 檔案系統，您佈建的中繼資料 IOPS 數量和中繼資料操作類型會決定檔案系統可支援的中繼資料操作速率。您佈建的中繼資料 IOPS 層級會決定為檔案系統中繼資料磁碟佈建的 IOPS 數目。 | 操作類型 | 您可以為每個佈建中繼資料 IOPS 每秒驅動的操作 | | --- | --- | | 檔案建立、開啟和關閉 | 2 | | 檔案刪除 | 1 | | 目錄建立、重新命名 | 0.1 | | 目錄刪除 | 0.2 | 對於 SSD 檔案系統，您可以選擇使用自動模式佈建中繼資料 IOPS。在自動模式下，Amazon FSx 會根據檔案系統的儲存容量，根據下表自動佈建中繼資料 IOPS： | 檔案系統儲存容量 | 在自動模式中包含中繼資料 IOPS | | --- | --- | | 1200 GiB | 1500 | | 2400 GiB | 3000 | | 4800–9600 GiB | 6000 | | 12000–45600 GiB | 12000 | | ≥48000 GiB | 每 24000 GiB 12000 IOPS | 在使用者佈建模式中，您可以選擇指定要佈建的中繼資料 IOPS 數目。有效值如下： + 對於 SSD 檔案系統，有效值為 `1500`、`3000`、`12000`、 `6000`和 的倍數`12000`，上限為 `192000`。 + 對於 Intelligent-Tiering 檔案系統，有效值為 `6000`和 `12000`。 如需如何設定中繼資料 IOPS 的資訊，請參閱 [管理中繼資料效能](managing-metadata-performance.md)。請注意，您需要為佈建的中繼資料 IOPS 支付超過檔案系統預設中繼資料 IOPS 數量的費用。 ## 個別用戶端執行個體的輸送量 如果您要建立輸送量超過 10 GBps 的檔案系統，建議您啟用 Elastic Fabric Adapter (EFA) 來最佳化每個用戶端執行個體的輸送量。為了進一步最佳化每個用戶端執行個體的輸送量，啟用 EFA 的檔案系統也支援啟用 EFA 的 NVIDIA GPU 用戶端執行個體的 GPUDirect Storage，以及啟用 ENA Express 的用戶端執行個體的 ENA Express。 您可以驅動到單一用戶端執行個體的輸送量取決於您選擇的檔案系統類型和用戶端執行個體上的網路介面。 | 檔案系統類型。 | 用戶端執行個體網路界面 | 每個用戶端的最大輸送量，Gbps | | --- | --- | --- | | 未啟用 EFA | 任何 | 100 Gbps\$1 | | 啟用 EFA | ENA | 100 Gbps\$1 | | 啟用 EFA | ENA Express | 100 Gbps | | 啟用 EFA | EFA | 700 Gbps | | 啟用 EFA | EFA 搭配 CSV | 1200 Gbps | **注意** \$1 個別用戶端執行個體與個別 FSx for Lustre 物件儲存伺服器之間的流量限制為 5 Gbps。如需 FSx for Lustre 檔案系統的基礎物件儲存伺服器數量[檔案系統的 IP 地址](using-fsx-lustre.md#ip-addesses-for-fs)，請參閱 。 ## 檔案系統儲存配置 中的所有檔案資料Lustre都會存放在稱為*物件儲存目標 (OST) 的儲存*磁碟區上。 OSTs 所有檔案中繼資料 （包括檔案名稱、時間戳記、許可等） 都存放在稱為*中繼資料目標* (MDTs儲存磁碟區上。Amazon FSx for Lustre 檔案系統由一或多個 MDTs 和多個 OSTs 組成。Amazon FSx for Lustre 會將檔案資料分散至組成檔案系統的 OSTs，以平衡儲存容量與輸送量和 IOPS 負載。 若要檢視組成檔案系統的 MDT 和 OSTs儲存用量，請從掛載檔案系統的用戶端執行下列命令。 ``` lfs df -h mount/path ``` 此令命的輸出結果如下所示： **Example** ``` 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 會自動將檔案分散到 OSTs，以確保從所有儲存伺服器提供資料。您可以透過設定檔案在多個 OSTs 之間分割的方式，在檔案層級套用相同的概念。 分割表示檔案可以分成多個區塊，然後存放在不同的 OSTs 中。當檔案分割到多個 OSTs 時，檔案的讀取或寫入請求會分散到這些 OSTs，進而增加您的應用程式可以驅動的彙總輸送量或 IOPS。 以下是 Amazon FSx for Lustre 檔案系統的預設配置。 + 對於 2020 年 12 月 18 日之前建立的檔案系統，預設配置會指定 1 的條紋計數。這表示除非指定不同的配置，否則使用標準 Linux 工具在 Amazon FSx for Lustre 中建立的每個檔案都會儲存在單一磁碟上。 + 對於 2020 年 12 月 18 日之後建立的檔案系統，預設配置是漸進式檔案配置，其大小小於 1GiB 的檔案會儲存在一個條紋中，而較大的檔案會獲指派 5 個條紋計數。 + 對於 2023 年 8 月 25 日之後建立的檔案系統，預設配置是 4 元件漸進式檔案配置，如 中所述[漸進式檔案配置](#striping-pfl)。 + 對於所有檔案系統，無論其建立日期為何，從 Amazon S3 匯入的檔案不會使用預設配置，而是在檔案系統的 `ImportedFileChunkSize` 參數中使用配置。大於 S3-imported檔案`ImportedFileChunkSize`將存放在多個 OSTs 上，條紋計數為 `(FileSize / ImportedFileChunksize) + 1`。的預設值`ImportedFileChunkSize`為 1GiB。 您可以使用 `lfs getstripe`命令檢視檔案或目錄的配置組態。 ``` lfs getstripe path/to/filename ``` 此命令會報告檔案的條紋計數、條紋大小和條紋位移。*條紋計數*是檔案分割的 OSTs數量。*條紋大小*是 OST 上存放多少連續資料。*條紋位移*是檔案分割第一個 OST 的索引。 ### 修改您的分割組態 第一次建立檔案時，會設定檔案的配置參數。使用 `lfs setstripe`命令來建立具有指定配置的新空白檔案。 ``` lfs setstripe filename --stripe-count number_of_OSTs ``` `lfs setstripe` 命令只會影響新檔案的配置。在建立檔案之前，請使用它來指定檔案的配置。您也可以定義目錄的配置。在目錄上設定之後，該配置會套用至新增至該目錄的每個新檔案，但不會套用至現有檔案。您建立的任何新子目錄也會繼承新的配置，然後將其套用至您在該子目錄中建立的任何新檔案或目錄。 若要修改現有檔案的配置，請使用 `lfs migrate`命令。此命令會視需要複製檔案，以根據您在命令中指定的配置來分發其內容。例如，附加至 或大小增加的檔案不會變更條紋計數，因此您必須遷移它們才能變更檔案配置。或者，您可以使用 `lfs setstripe`命令建立新的檔案，以指定其配置、將原始內容複製到新檔案，然後重新命名新檔案以取代原始檔案。 在某些情況下，預設配置組態可能不適合您的工作負載。例如，具有數十個 OSTs 和大量多 GB 檔案的檔案系統可能會看到更高的效能，方法是將檔案分割到超過五個 OSTs 的預設條紋計數值。建立具有低條紋計數的大型檔案可能會導致 I/O 效能瓶頸，也可能導致 OSTs 填滿。在這種情況下，您可以為這些檔案建立具有較大條紋計數的目錄。 設定大型檔案 （特別是大於 1 GB 的檔案） 的條紋配置很重要，原因如下： + 允許多個 OSTs 及其相關聯的伺服器在讀取和寫入大型檔案時貢獻 IOPS、網路頻寬和 CPU 資源，以改善輸送量。 + 降低一小部分 OSTs 成為會限制整體工作負載效能熱點的可能性。 + 防止單一大型檔案填入 OST，這可能會導致磁碟完全錯誤。 所有使用案例都沒有單一的最佳配置組態。如需檔案配置的詳細指引，請參閱 https：//Lustre.org 文件中的[管理檔案配置 （分割） 和可用空間](https://doc.lustre.org/lustre_manual.xhtml#managingstripingfreespace)。以下是一般準則： + 條紋配置對大型檔案來說最為重要，尤其是檔案通常為數百 MB 以上的使用案例。因此，新檔案系統的預設配置會為大小超過 1GiB 的檔案指派 5 的分割計數。 + 條紋計數是您應針對支援大型檔案的系統調整的配置參數。條紋計數會指定將存放條紋檔案區塊的 OST 磁碟區數量。例如，如果條紋計數為 2 且條紋大小為 1MiB， 會將檔案的替代 1MiB 區塊Lustre寫入兩個 OSTs 中的每一個。 + 有效條紋計數是實際 OST 磁碟區數量和您指定的條紋計數值中較少的。您可以使用 的特殊條紋計數值`-1`，指出應在所有 OST 磁碟區上放置條紋。 + 為小型檔案設定大型條紋計數是次佳的，因為對於某些操作Lustre，需要網路往返到配置中的每個 OST，即使檔案太小而無法在所有 OST 磁碟區上耗用空間。 + 您可以設定漸進式檔案配置 (PFL)，允許檔案的配置隨著大小而變更。PFL 組態可以簡化管理具有大型和小型檔案組合的檔案系統，而無需明確設定每個檔案的組態。如需詳細資訊，請參閱[漸進式檔案配置](#striping-pfl)。 + 條紋大小預設為 1MiB。設定條紋位移在特殊情況下可能很有用，但通常最好保持未指定狀態並使用預設值。 ### 漸進式檔案配置 您可以為目錄指定漸進式檔案配置 (PFL) 組態，以在填入檔案之前為小型和大型檔案指定不同的條紋組態。例如，您可以在最上層目錄上設定 PFL，再將任何資料寫入新的檔案系統。 若要指定 PFL 組態，請使用 `lfs setstripe`命令搭配 `-E`選項來指定不同大小檔案的配置元件，例如下列命令： ``` 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。 + 第四個元件 (`-E -1 -c 32`) 表示大於 100GiB 的檔案的條紋計數為 32。 **重要** 將資料附加至使用 PFL 配置建立的檔案，將會填入其所有配置元件。例如，使用上面顯示的 4 元件命令，如果您建立 1MiB 檔案，然後將資料新增至該檔案的結尾，檔案的配置將擴展為 -1 的條紋計數，這表示系統中的所有 OSTs。這並不表示資料會寫入每個 OST，但讀取檔案長度等操作會將請求平行傳送至每個 OST，為檔案系統新增大量網路負載。 因此，請小心限制任何中小型檔案的條紋計數，這些檔案之後可以附加資料。由於日誌檔案通常會透過附加新記錄來增加，因此 Amazon FSx for Lustre 會將預設條紋計數 1 指派給在附加模式中建立的任何檔案，無論其父目錄指定的預設條紋組態為何。 Amazon FSx for Lustre 檔案系統上在 2023 年 8 月 25 日之後建立的預設 PFL 組態會使用此命令設定： ``` lfs setstripe -E 100M -c 1 -E 10G -c 8 -E 100G -c 16 -E -1 -c 32 /mountname ``` 具有對中型和大型檔案具有高度並行存取之工作負載的客戶，可能會受益於具有更多較小大小條紋的配置，以及針對最大檔案跨所有 OSTs 分割的配置，如四個元件範例配置所示。 ## 監控效能和用量 Amazon FSx for Lustre 每分鐘會為每個磁碟 (MDT 和 OST) 發出用量指標給 Amazon CloudWatch。 若要檢視彙總檔案系統用量詳細資訊，您可以查看每個指標的總和統計資料。例如，`DataReadBytes`統計資料的總和會報告檔案系統中所有 OSTs 所見的總讀取輸送量。同樣地，`FreeDataStorageCapacity`統計資料的總和會報告檔案系統中檔案資料的總可用儲存容量。 如需監控檔案系統效能的詳細資訊，請參閱 [監控 Amazon FSx for Lustre 檔案系統](monitoring_overview.md)。 # SSD 和 HDD 儲存類別的效能特性 FSx for Lustre 檔案系統使用 SSD 或 HDD 儲存類別佈建的輸送量與其儲存容量成正比。Amazon FSx for Lustre 檔案系統可擴展到多個 TBps 的輸送量和數百萬個 IOPS。Amazon FSx for Lustre 也支援從數千個運算執行個體同時存取相同的檔案或目錄。此存取可讓快速的資料檢查點從應用程式記憶體到儲存，這是高效能運算 (HPC) 的常見技術。您可以在建立檔案系統之後，隨時視需要增加儲存和輸送量容量。如需詳細資訊，請參閱[管理儲存容量](managing-storage-capacity.md)。 FSx for Lustre 檔案系統使用網路 I/O 額度機制提供爆量讀取輸送量，以根據平均頻寬使用率配置網路頻寬。檔案系統會在網路頻寬使用量低於基準限制時累積點數，並在執行網路資料傳輸時使用這些點數。 下表顯示使用 SSD 和 HDD 儲存類別設計之 FSx for Lustre 部署選項的效能。 **SSD 儲存選項的檔案系統效能** | 部署類型 | **網路輸送量 (MBps/TiB 的已佈建儲存體）** | **網路 IOPS （已佈建儲存體的 IOPS/TiB)** | **快取儲存 （佈建儲存的 RAM/TiB GiB) TiB ** | **每個檔案操作的磁碟延遲 （毫秒、P50)** | **磁碟輸送量 (MBps/TiB 的儲存或佈建的 SSD 快取）** | | --- |--- |--- |--- |--- |--- | | **** | **基準** | **爆量** | **** | **** | **** | **基準** | **爆量** | | --- |--- |--- |--- |--- |--- |--- |--- | | SCRATCH\$12 | 200 | 1300 | 數萬個基準數十萬次爆量 | 6.7 | 中繼資料：sub-ms 資料：sub-ms | 200 （讀取） 100 （寫入） | ‐ | | --- |--- |--- |--- |--- |--- |--- |--- | | 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 | ‐ | | --- |--- |--- |--- |--- |--- | **HDD 儲存選項的檔案系統效能** | 部署類型 | **網路輸送量 (MBps/TiB 的儲存或佈建 SSD 快取）** | **網路 IOPS （佈建儲存的 IOPS/TiB)** | **快取儲存 （佈建儲存的 RAM/TiB GiB) TiB ** | **每個檔案操作的磁碟延遲 （毫秒、P50) ** | **磁碟輸送量 (MBps/TiB 的儲存或佈建的 SSD 快取）** | | --- |--- |--- |--- |--- |--- | | **** | **基準** | **爆量** | | **基準** | **爆量** | | --- |--- |--- |--- |--- |--- | | PERSISTENT-12 | | --- | | HDD 儲存體 | 40 | 375\$1 | 數萬個基準 數十萬次爆量 | 0.4 memory | 中繼資料：sub-ms 資料：單一位數 ms | 12 | 80 （讀取） 50 （寫入） | | --- |--- |--- |--- |--- |--- |--- |--- | | SSD 讀取快取 | 200 | 1,900 | 200 SSD 快取 | 資料：sub-ms | 200 | - | | --- |--- |--- |--- |--- |--- |--- | | PERSISTENT-40 | | --- | | HDD 儲存體 | 150 | 1,300\$1 | 數萬個基準 數十萬次爆量 | 1.5 | 中繼資料：sub-ms 資料：單一位數 ms | 40 | 250 （讀取） 150 （寫入） | | --- |--- |--- |--- |--- |--- |--- |--- | | SSD 讀取快取 | 750 | 6500 | 200 SSD cache | 資料：sub-ms | 200 | - | | --- |--- |--- |--- |--- |--- |--- | **上一代 SSD 儲存選項的檔案系統效能** | 部署類型 | **網路輸送量 （每 TiB 佈建儲存體的 MBps)** | **網路 IOPS （已佈建儲存體每 TiB 的 IOPS)** | **快取儲存 （每 GiB 佈建儲存體的 GiB) TiB ** | **每個檔案操作的磁碟延遲 （毫秒、P50)** | **磁碟輸送量 （每 TiB 儲存或佈建 SSD 快取的 MBps)** | | --- |--- |--- |--- |--- |--- | | **** | **基準** | **爆量** | **** | **** | **** | **基準** | **爆量** | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTENT-50 | 250 | 1,300\$1 | 數萬個基準數十萬次爆量 | 2.2 RAM | 中繼資料：sub-ms 資料：sub-ms | 50 | 240 | | --- |--- |--- |--- |--- |--- |--- |--- | | PERSISTENT-100 | 500 | 1,300\$1 | 4.4 RAM | 100 | 240 | | --- |--- |--- |--- |--- |--- | | PERSISTENT-200 | 750 | 1,300\$1 | 8.8 RAM | 200 | 240 | | --- |--- |--- |--- |--- |--- | **注意** \$1 下列 中的持久性檔案系統 AWS 區域 提供網路每 TiB 儲存高達 530 MBps：非洲 （開普敦）、亞太區域 （香港）、亞太區域 （大阪）、亞太區域 （新加坡）、加拿大 （中部）、歐洲 （法蘭克福）、歐洲 （倫敦）、歐洲 （米蘭）、歐洲 （斯德哥爾摩）、中東 （巴林）、南美洲 （聖保羅）、中國和美國西部 （洛杉磯）。 ## 範例：彙總基準和高載輸送量 下列範例說明儲存容量和磁碟輸送量如何影響檔案系統效能。 儲存容量為每 TiB 儲存單位輸送量 4.8 TiB 和 50 MBps 的持久性檔案系統，可提供 240 MBps 的彙總基準磁碟輸送量和 1.152 GBps 的爆量磁碟輸送量。 TiB 無論檔案系統大小為何，Amazon FSx for Lustre 都會為檔案操作提供一致的次毫秒延遲。 # Intelligent-Tiering 儲存類別的效能特性 FSx for Lustre Intelligent-Tiering 儲存類別為傳統上在 HDD 型或混合式 HDD/SDD 型高效能檔案儲存檔案系統上執行的工作負載提供彈性、成本最佳化的儲存體。使用 Intelligent-Tiering 儲存類別的檔案系統會利用完全彈性、智慧分層的區域儲存，在工作負載變更時自動擴展和縮減，以符合工作負載。如需其如何分層資料的資訊，請參閱 [Intelligent-Tiering 儲存類別方案資料的方式](using-fsx-lustre.md#how-INT-tiering-works)。 FSx for Lustre 檔案系統搭配 Intelligent-Tiering 儲存類別支援的輸送量與其儲存體無關。智慧型分層檔案系統可擴展至多個 TBps 的輸送量和數百萬個 IOPS。使用 Intelligent-Tiering 儲存類別的檔案系統也提供選用的佈建 SSD 讀取快取，以低延遲存取經常存取的資料。根據預設，Amazon FSx for Lustre 會為經常存取的中繼資料佈建 SSD 讀取快取。由於大多數工作負載往往是讀取密集的，並且在任何指定時間只積極使用整體資料集的一小部分，因此智慧型分層儲存和 SSD 讀取快取的混合模型允許使用智慧型分層儲存類別的檔案系統提供與大多數工作負載的 SSD 檔案系統相當的儲存體，同時相較於 SSD 和 HDD 儲存類別節省儲存成本。 讀取和寫入資料至 Intelligent-Tiering 檔案系統時，特別是最近未存取或尚未頻繁存取到檔案伺服器記憶體內快取的資料，效能取決於 SSD 讀取快取的大小。來自 Intelligent-Tiering 儲存體的資料存取具有time-to-first-byte延遲以及每次請求成本，而來自 SSD 讀取快取的存取則會傳回，延遲低於一毫秒，而且沒有每次請求成本。 為檔案系統設定 SSD 讀取快取的大小時，您應該考慮工作負載中經常存取資料集的大小，以及工作負載對讀取較少存取資料時較高延遲的敏感度。您可以在建立檔案系統之後切換 SSD 讀取快取大小調整模式，並向上或向下擴展快取。如需如何修改 SSD 讀取快取的詳細資訊，請參閱 [管理佈建的 SSD 讀取快取](managing-ssd-read-cache.md)。 當 FSx for Lustre 將資料區塊寫入 Intelligent-Tiering 儲存體時，會發生寫入請求。當您將資料寫入檔案系統時，寫入請求會彙總並寫入至 Intelligent-Tiering 儲存體，從而提高輸送量並降低請求成本。可從檔案伺服器的記憶體內快取、SSD 讀取快取或直接從 Intelligent-Tiering 儲存提供讀取。從 Intelligent-Tiering 儲存提供讀取時，會針對擷取資料的每個區塊發出讀取請求。當您循序讀取資料時，FSx for Lustre 會預先擷取資料以改善效能。 使用 Intelligent-Tiering 儲存類別的檔案系統上記憶體內快取的資料，會直接做為*網路 I/O* 提供給請求用戶端。 當用戶端存取不在記憶體內快取中的資料時，會從 SSD 讀取快取或智慧型分層儲存做為*磁碟 I/O* 讀取，然後做為網路 I/O 提供給用戶端。 ## Intelligent-Tiering 的檔案系統效能 下表顯示 FSx for Lustre Intelligent-Tiering 檔案系統專為其設計的效能。 | 佈建輸送量容量 (MBps) | **網路輸送量 (MBps)** | **網路 IOPS** | **記憶體內快取儲存 (GB)** | **SSD 快取磁碟輸送量上限 (MBps)** | **SSD 快取磁碟 IOPS 上限** | | --- |--- |--- |--- |--- |--- | | **** | **基準** | **爆量** | **** | **** | **** | **基準** | **爆量** | | --- |--- |--- |--- |--- |--- |--- |--- | | 每 4000 個 | 12500 | ‐ | 數萬 | 76.8 | 4000 | 160000 | ‐ | | --- |--- |--- |--- |--- |--- |--- |--- | # 效能秘訣 使用 Amazon FSx for Lustre 時，請記住下列效能秘訣。如需服務限制，請參閱 [Amazon FSx for Lustre 的服務配額](limits.md)。 + **平均 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 執行個體) 和速度之間權衡折衷。 + **限制目錄大小** – 若要在持久性 2 FSx for Lustre 檔案系統上獲得最佳中繼資料效能，請將每個目錄限制在小於 100K 個檔案。限制目錄中的檔案數量可減少檔案系統在父目錄上取得鎖定所需的時間。 + **Amazon EC2 執行個體** – 執行大量讀取和寫入操作的應用程式可能需要比不需要的應用程式更多的記憶體或運算容量。為運算密集型工作負載啟動 Amazon EC2 執行個體時，請選擇具有應用程式所需資源數量的執行個體類型。Amazon FSx for Lustre 檔案系統的效能特性不取決於 Amazon EBS 最佳化執行個體的使用。 + **建議用戶端執行個體調校，以獲得最佳效能** 1. 對於記憶體超過 64 GiB 的用戶端執行個體類型，我們建議套用下列調校： ``` sudo lctl set_param ldlm.namespaces.*.lru_max_age=600000 sudo lctl set_param ldlm.namespaces.*.lru_size=<100 * number_of_CPUs> ``` 1. 對於具有超過 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 ``` 1. 若要最佳化目錄清單 (ls) 的效能，需要套用下列調校： ``` sudo lctl set_param llite.*.statahead_max=512 sudo lctl set_param llite.*.statahead_agl=1 if sudo lctl get_param llite.*.statahead_xattr > /dev/null 2>&1; then sudo lctl set_param llite.*.statahead_xattr=1 else echo "Warning: Xattr statahead is not supported on this Lustre client. Please upgrade to the latest Lustre 2.15 client to apply this tuning" fi ``` 請注意， `lctl set_param` 已知不會在重新開機時保留。由於這些參數無法從用戶端永久設定，因此建議您實作開機 Cron 任務，以使用建議的調校來設定組態。 + **跨 OSTs工作負載平衡** – 在某些情況下，您的工作負載不會驅動檔案系統可提供的彙總輸送量 （每個 TiB 儲存體 200 MBps)。若是如此，您可以使用 CloudWatch 指標來疑難排解工作負載 I/O 模式的不平衡是否會影響效能。若要識別是否為原因，請查看 Amazon FSx for Lustre 的 CloudWatch 指標上限。 在某些情況下，此統計資料會顯示輸送量達到或超過 240 MBps 的負載 （單一 1.2-TiB Amazon FSx for Lustre 磁碟的輸送量容量）。在這種情況下，您的工作負載不會平均分散到磁碟。如果是這種情況，您可以使用 `lfs setstripe`命令來修改工作負載最常存取之檔案的分割。為了獲得最佳效能，請在包含檔案系統的所有 OSTs 間分割具有高輸送量需求的檔案。 如果您的檔案是從資料儲存庫匯入，您可以採取另一種方法，將高輸送量檔案平均分割至 OSTs。若要這樣做，您可以在建立下一個 Amazon FSx for Lustre 檔案系統時修改 `ImportedFileChunkSize` 參數。 例如，假設您的工作負載使用 7.0-TiB 檔案系統 （由 6x 1.17-TiB OSTs 組成），且需要跨 2.4-GiB 檔案驅動高輸送量。在這種情況下，您可以將 `ImportedFileChunkSize`值設定為 ，`(2.4 GiB / 6 OSTs) = 400 MiB`讓您的檔案平均分散到檔案系統的 OSTs。 + **Lustre 中繼資料 IOPS 的 用戶端** – 如果您的檔案系統已指定中繼資料組態，我們建議您安裝 Lustre 2.15 用戶端或 Lustre 2.12 用戶端，其中包含下列其中一個作業系統版本：Amazon Linux 2023；Amazon Linux 2；Red Hat/Rocky Linux 8.9、8.10 或 9.x；CentOS 8.9 或 8.10；Ubuntu 22\$1 搭配 6.2、6.5 或 6.8 核心；或 Ubuntu 20。 ## Intelligent-Tiering 效能考量事項 以下是使用 Intelligent-Tiering 儲存類別處理檔案系統時的一些重要效能考量： + 由於智慧型分層儲存層的延遲較高，讀取較小 I/O 大小資料的工作負載需要更高的並行性，並會產生更多請求成本，才能達到與使用大型 I/O 大小的工作負載相同的輸送量。我們建議您設定夠大的 SSD 讀取快取，以便在使用較小的 IO 大小時支援更高的並行和輸送量。 + 用戶端可以使用 Intelligent-Tiering 檔案系統驅動的最大磁碟 IOPS，取決於工作負載的特定存取模式，以及您是否已佈建 SSD 讀取快取。對於具有隨機存取的工作負載，如果資料快取在 SSD 讀取快取中，用戶端通常會驅動比資料不在快取中高出許多的 IOPS。 + Intelligent-Tiering 儲存類別支援預先讀取，以最佳化循序讀取請求的效能。我們建議您盡可能依序設定資料存取模式，以允許預先擷取資料和提高效能。