最佳實務：前端節點執行個體類型選取最佳實務：網路效能最佳實務：預算提醒最佳實務：將叢集移至新的 AWS ParallelCluster 次要或修補程式版本最佳實務：GPU 運作狀態檢查

最佳實務

以下各節提供使用的最佳實務 AWS ParallelCluster，其中包括網路效能和預算提醒。如果您即使遵循這些最佳實務仍遇到問題，請參閱 AWS ParallelCluster 故障診斷以取得可能的解決方案。

最佳實務：前端節點執行個體類型選取

即使前端節點未執行任務，其函數及其大小對於叢集的整體效能至關重要。當您選擇要用於前端節點的執行個體類型時，請考慮下列特性：

叢集大小：前端節點會協調叢集的擴展邏輯，並負責將新節點連接至排程器。若要擴展和縮減具有大量節點的叢集，請將額外的運算容量提供給前端節點。

共用檔案系統：當您使用共用檔案系統時，請選擇具有足夠網路頻寬和足夠 Amazon EBS 頻寬的執行個體類型來處理工作流程。確保前端節點能夠為叢集公開足夠的 NFS 伺服器目錄，並處理運算節點和前端節點之間需要共用的成品。

最佳實務：網路效能

網路效能對於高效能運算 (HPC) 應用程式至關重要。如果沒有可靠的網路效能，這些應用程式將無法如預期般執行。若要最佳化網路效能，請考慮下列最佳實務。

置放群組：如果您使用的是 Slurm，請考慮設定每個Slurm佇列以使用叢集置放群組。叢集的置放群組是單一可用區域內執行個體的邏輯分組。如需詳細資訊，請參閱《Amazon EC2 使用者指南》中的置放群組。您可以在佇列的 Networking區段PlacementGroup中指定，每個運算資源都會指派給佇列的置放群組。在運算資源的 Networking區段PlacementGroup中指定時，該特定運算資源會指派給該置放群組。運算資源置放群組規格會覆寫運算資源的佇列規格。如需詳細資訊，請參閱 SlurmQueues / Networking / PlacementGroup和 SlurmQueues / ComputeResources / Networking / PlacementGroup。
```
Networking:
  PlacementGroup:
    Enabled: true
    Id: your-placement-group-name
```
或者，請為您 AWS ParallelCluster 建立置放群組。
```
Networking:
  PlacementGroup:
    Enabled: true
```
從 3.3.0 AWS ParallelCluster 版開始，會修改置放群組的建立和管理。當您在佇列中指定要啟用的置放群組，而沒有 name或 Id時，每個運算資源都會指派自己的受管置放群組，而不是整個佇列的一個受管群組。這有助於減少容量不足的錯誤。如果您需要一個放置群組用於整個佇列，您可以使用具名放置群組。

SlurmQueues / Networking / PlacementGroup / Name 已新增為 SlurmQueues / Networking / PlacementGroup / 的偏好替代方案Id。

如需詳細資訊，請參閱Networking。
增強型聯網：考慮選擇支援增強型聯網的執行個體類型。此建議適用於所有目前世代的執行個體。如需詳細資訊，請參閱《Amazon EC2 使用者指南》中的 Linux 上的增強型聯網。
Elastic Fabric Adapter：若要支援高階可擴展執行個體與執行個體通訊，請考慮為您的網路選擇 EFA 網路介面。EFA 的自訂建置作業系統 (OS) 繞過硬體可增強執行個體與隨需彈性和彈性的執行個體通訊 AWS 雲端。您可以設定每個Slurm佇列ComputeResource使用 Efa。如需搭配使用 EFA 的詳細資訊 AWS ParallelCluster，請參閱 Elastic Fabric Adapter。
```
ComputeResources:
  - Name: your-compute-resource-name
    Efa:
      Enabled: true
```
如需 EFA 的詳細資訊，請參閱《Amazon EC2 Linux 執行個體使用者指南》中的 Elastic Fabric Adapter。
執行個體頻寬：頻寬會隨執行個體大小而擴展。如需不同執行個體類型的資訊，請參閱《Amazon EC2 使用者指南》中的 Amazon EBS 最佳化執行個體Amazon EC2 EBS 磁碟區類型。

最佳實務：預算提醒

若要管理中的資源成本 AWS ParallelCluster，建議您使用 AWS Budgets 動作來建立預算。您也可以為選取的 AWS 資源建立定義的預算閾值警示。如需詳細資訊，請參閱AWS Budgets 《使用者指南》中的設定預算動作。同樣地，您也可以使用 Amazon CloudWatch 建立帳單警示。如需詳細資訊，請參閱建立帳單警示來監控預估的 AWS 費用。

最佳實務：將叢集移至新的 AWS ParallelCluster 次要或修補程式版本

目前每個 AWS ParallelCluster 次要版本都與其 pcluster CLI 一起獨立。若要將叢集移至新的次要或修補程式版本，您必須使用新版本的 CLI 重新建立叢集。

若要將叢集移至新的次要或修補程式版本的程序最佳化，建議您執行下列動作：

在叢集外部建立的外部磁碟區中儲存個人資料，例如 Amazon EFS 和 FSx for Lustre。透過這樣做，您可以在未來輕鬆地將資料從一個叢集移至另一個叢集。
使用下列類型建立共用儲存系統。您可以使用 AWS CLI 或建立這些系統 AWS 管理主控台。
- SharedStorage / EbsSettings / VolumeId
- SharedStorage / EfsSettings / FileSystemId
- SharedStorage / FsxLustreSettings / FileSystemId
將叢集組態中的檔案系統或磁碟區定義為現有的檔案系統或磁碟區。如此一來，它們會在您刪除叢集時保留，並且可以連接到新的叢集。

我們建議您使用 Amazon EFS 或 FSx for Lustre 檔案系統。這兩個系統可以同時連接到多個叢集。此外，您可以在刪除現有叢集之前，將這些系統連接到新的叢集。
使用自訂引導操作來自訂執行個體，而不是使用自訂 AMI。如果改為使用自訂 AMI，則需要為每個新版本版本刪除並重新建立該 AMI。
我們建議您以下列順序套用上述建議：
1. 更新現有的叢集組態，以使用現有的檔案系統定義。
2. 驗證pcluster版本並視需要更新。
3. 建立和測試新叢集。當您測試新叢集時，請檢查下列項目：
  - 請確定您的資料可在新叢集中使用。
  - 請確定您的應用程式可在新叢集中運作。
4. 新叢集經過完整測試並運作，且不再需要現有的叢集後，請將其刪除。

最佳實務：GPU 運作狀態檢查

內建 GPU 運作狀態檢查

除非您啟用，否則內建 GPU 運作狀態檢查 (HealthChecks/Gpu/Enabled) 會關閉。啟用時，它會在節點的 GPUs 上執行 NVIDIA DCGM 層級 2 診斷，做為 Slurm prolog 的一部分。由於診斷會在 prolog 中執行，而且在 prolog 完成之前，任務無法啟動，因此此設計適合診斷快速完成的執行個體類型。

內建檢查只有在任務獨佔配置（每個節點一個任務）時才可靠。在多個任務共用的節點上，它可能會干擾執行中的任務並耗盡運作狀態良好的節點，因此只能在具有的佇列上啟用它JobExclusiveAllocation: true。

此外，在 P6 和 P6e GPU 執行個體系列（例如 p6-b200和 p6-b300) 及更新版本的 P-family GPU 執行個體上，診斷需要足夠長的時間，才不應在 prolog 中執行：它通常超過 Slurm prolog 的時間限制，並導致運作狀態良好的節點耗盡和任務重新排入佇列。在這些執行個體類型上，請停用 GPU 運作狀態檢查 (HealthChecks/Gpu/Enabled: false)。

執行自有 GPU 運作狀態檢查的選項

若要在這些執行個體上執行 GPU 運作狀態檢查，請選擇下列方法，在節點啟動時、任務之前或任務之後，比對每個檢查與。這遵循 NVIDIA 的 GPU 運作狀態和診斷模型（請參閱 NVIDIA DCGM 運作狀態和診斷)；dcgmi diag診斷會逐級成長深度和持續時間（請參閱 DCGM 診斷)。

重要

在多個任務共用的節點上，只有在沒有其他任務正在使用節點時，才執行任何dcgmi diag診斷（從第 1 級到第 4 級）。否則，可能會失敗並耗盡節點。

在節點啟動時檢查。當節點加入叢集時，在節點接受工作之前，使用此節點驗證一次。由於尚未執行任何任務，因此它可以執行深度 dcgmi diag；請注意，它只會擷取啟動時出現的故障，而不是稍後出現的降級。使用OnNodeConfigured自訂動作安裝和叫用您的檢查。請參閱自訂引導操作。
檢查 prolog 中的。在每個任務之前，將此用於快速整備閘道。由於 prolog 會在每個任務上執行，並封鎖任務從開始直到完成為止，因此請將檢查保持在幾秒鐘。例如， nvidia-smi （選擇性使用 NVIDIA Xid 錯誤的核心日誌掃描）或第 1 級dcgmi diag。請參閱 Slurm 與 prologepilog。
檢查 epilog 中的。使用此選項可在任務完成後驗證節點。例如，在任務失敗時執行更深入的檢查，或在排程下一個任務之前，擷取在執行期間降級的 GPU。它可以執行更深層的 dcgmi diag。為了避免在每個任務之後檢查，您可能只想在任務失敗時執行 Level-2 診斷。請參閱 Slurm 與 prologepilog。

注意

AWS ParallelCluster 取代耗盡或失敗的靜態節點（並終止動態節點），因此使用已確認的故障耗盡節點會導致取代節點。

您的瀏覽器已停用或無法使用 Javascript。

您必須啟用 Javascript，才能使用 AWS 文件。請參閱您的瀏覽器說明頁以取得說明。

文件慣用形式

AWS Managed Microsoft AD 透過 LDAP(S) 叢集組態的範例

從 AWS ParallelCluster 2.x 移至 3.x