本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

疑難排解 AWS PCS 叢集版本更新

本主題可協助您識別和解決在叢集上更新排程器版本時可能發生的常見問題。

運算節點在更新後無法連線

常見原因

更新叢集後，新啟動的運算節點無法向控制器註冊。節點會啟動，但永遠不會出現在sinfo輸出中，而且運算節點群組可能會重複循環執行個體。當運算節點群組的 AMI 包含位於新控制器版本相容性時段之外的排程器版本時，就會發生這種情況。

例如，如果您將叢集從 24.11 更新至 25.11，但運算節點群組仍然使用具有 Slurm 23.11 的 AMI，則新執行個體無法連線，因為 23.11 超出 25.11 的相容性時段。

如何診斷

您可以透過檢查兩個位置的日誌來確認此問題：

排程器日誌

如果您已啟用排程器記錄，請檢查 CloudWatch Logs 中的排程器日誌是否有類似下列的錯誤：

error: unpack_header: protocol_version 10240 not supported
error: slurm_unpack_received_msg: [ip-10-0-1-23] Incompatible versions of client and server code

這些錯誤表示具有不相容排程器版本的運算節點正在嘗試連線至控制器。如需設定排程器記錄的資訊，請參閱 AWS PCS 中的排程器日誌。

運算節點執行個體日誌

擷取執行個體主控台輸出或透過 Systems Manager 連線，並檢查引導日誌是否有類似以下的錯誤：

error: _fetch_child: failed to fetch remote configs: Incompatible versions of client and server
error: _establish_configuration: failed to load configs
error: slurmd initialization failed

如需擷取執行個體日誌的詳細資訊，請參閱 擷取執行個體日誌。

Resolution

更新運算節點群組以使用 AMI，其中包含新叢集版本相容性時段內的排程器版本：

aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--ami-id ami-0123456789abcdef0

若要判斷哪些排程器版本與您的叢集相容，請參閱 版本相容性。

如需使用正確排程器版本建置自訂 AMIs 的相關資訊，請參閱 AWS PCS 的 Amazon Machine Image AMIs)。

使用 ValidationException 拒絕更新請求

常見原因

UpdateCluster 請求會立即傳回 ，並ValidationException顯示不支援更新。發生下列情況時，會發生這種情況：

Resolution

如果目標版本不在相容性時段內，請以多個步驟執行更新。每個步驟都必須以相容性時段內支援的版本為目標。例如，若要從 23.11 到 25.11，請先更新至 25.05，等待叢集返回 ACTIVE，然後更新至 25.11。

如果目標版本是 EOL，請改為選擇較新的支援版本。如需支援版本的資訊，請參閱 AWS PCS 中的 Slurm 版本。

叢集保持更新狀態

常見原因

叢集保持 UPDATING 狀態的時間超過預期 （超過 20 分鐘）。這可能是因為更新程序期間的暫時性內部問題所造成。

Resolution

AWS PCS 會自動復原停滯在 UPDATING 狀態的叢集。如果叢集未在 30 分鐘內返回 ACTIVE 或 UPDATE_FAILED ，請聯絡 AWS Support 尋求協助。

叢集在更新後進入 UPDATE_FAILED 狀態

常見原因

叢集會在更新期間轉換為 UPDATE_FAILED 狀態。當暫時性服務錯誤導致更新無法成功完成時，就會發生這種情況。

Resolution

再次提交相同的UpdateCluster請求，以重試更新。UPDATE_FAILED 狀態的叢集接受新的更新請求。如果更新持續失敗，請聯絡 AWS Support。

由於組態剖析錯誤，運算節點無法啟動

常見原因

更新叢集後，運算節點無法啟動，且永遠不會出現在sinfo輸出中。運算節點執行個體日誌會顯示類似以下的錯誤：

error: _parse_next_key: Parsing error at unrecognized key: HashPlugin
error: Invalid DebugFlag: AuditRPCs
fatal: Unable to process configuration file

當執行排程器 23.11 版的運算節點從較新的叢集版本接收組態時，就會發生這種情況。23.11 之後的排程器版本引進了 23.11 無法剖析的新組態指令。與相容性視窗中的其他版本不同，23.11 運算節點無法連線至較新的叢集，因為這些節點在無法辨識的組態金鑰上嚴重發生錯誤。

如果您的自訂 AMI 使用比 v1.4.0 更舊的 AWS PCS 代理程式版本，也可能發生此問題。舊版代理程式不支援運算節點協助程式的自動版本後援。

Resolution

使用下列需求重建您的自訂 AMI：

然後更新運算節點群組以使用新的 AMI：

aws pcs update-compute-node-group \
--cluster-identifier my-cluster \
--compute-node-group-identifier my-cng \
--ami-id ami-0123456789abcdef0

如需建置自訂 AMIs的詳細資訊，請參閱 AWS PCS 的 Amazon Machine Image AMIs)。如需 AWS PCS 代理程式版本的資訊，請參閱 AWS PCS 代理程式版本。

由於 QoS 組態無效，更新後叢集無法使用

常見原因

更新至 25.11 版後，叢集會進入 UPDATE_FAILED 狀態或排程器無法使用。您無法提交任務或執行排程器命令。排程器日誌會顯示類似下列的錯誤：

error: Invalid Allow/DenyQOS value: low
fatal: Partition my-queue has an invalid DenyQOS (low), please check your configuration

當佇列 （分割區） 透過 AllowQOS、 DenyQOS或 Slurm 會計資料庫中不存在QOS的設定參考 QoS 名稱時，就會發生這種情況。Slurm 25.11 在排程器啟動時引進更嚴格的 QoS 參考驗證。舊版允許參考不存在的 QoS 名稱，而不會發生錯誤。

Resolution

更新至 25.11 版之前，請確認佇列組態中參考的所有 QoS 名稱都存在於會計資料庫中。連線至登入節點並執行下列命令，以檢查 QoS 是否存在：

sacctmgr show qos where name=low format=name

如果 QoS 不存在，請在嘗試更新之前建立它：

sacctmgr add qos low

或者，透過更新佇列的 Slurm 自訂設定，在更新叢集之前移除 AllowQOS、 或 QOS 參數DenyQOS，從佇列組態中移除 QoS 參考。