您可以增加 Managed Lustre 執行個體的儲存空間容量。容量設定後即無法降低。
增加執行個體的容量時,您可以在更新作業進行期間繼續使用執行個體。
增加容量的限制
如果效能級別有兩種不同的步距,執行個體的目前容量會決定可能的最大大小。
如果執行個體的容量等於或低於步距門檻,則容量最多可增加至門檻值。無法擴充超過這個限制。
舉例來說,在每 TiB 250 MBps 的級別中,步距變更的門檻為 10,224,000 GiB。如果建立的執行個體容量等於或低於這個門檻,則最多只能擴充至 10,224,000 GiB。
計算新容量
您可以更新執行個體的容量,最高可達效能級別和步距允許的最大值。這些值如下:
| 效能級別 | 數量下限 | 數量上限 | 步距 |
|---|---|---|---|
| 每 TiB 1,000 MB/秒 | 9,000 GiB | 10,008,000 GiB (9.5 PiB) | 儲存空間容量不超過 2,556,000 GiB:9,000 GiB 儲存空間容量較大:72,000 GiB |
| 每 TiB 500 MB/秒 | 18,000 GiB | 20,016,000 GiB (19.1 PiB) | 儲存空間容量不超過 5,112,000 GiB:18,000 GiB 儲存空間容量較大:144,000 GiB |
| 每 TiB 250 MB/秒 | 36,000 GiB | 40,032,000 GiB (38.2 PiB) | 儲存空間容量不超過 10,224,000 GiB:36,000 GiB 儲存空間容量較大:288,000 GiB |
| 每 TiB 125 MB/秒 | 72,000 GiB | 20,448,000 GiB (19.5 PiB) | 72,000 GiB |
| 動態 (每 TiB 25 MB/秒) | 472,000 GiB | 84,016,000 GiB (80.1 PiB) | 472,000 GiB |
更新後的容量必須是步距的倍數,且不得超過該步距的最大值。
您的 Google Cloud 專案有處理量和容量配額,會影響每個可用區中每個虛擬私有雲 (VPC) 網路的可用容量。您可能需要先申請額外的處理量或容量配額,才能增加執行個體的容量。詳情請參閱「配額與限制」。
容量計算工具
請使用下列計算機,找出所選效能級別的有效容量。
更新執行個體容量
您可以使用 Google Cloud 控制台或 Google Cloud CLI 更新執行個體的容量。
Google Cloud 控制台
前往 Google Cloud 控制台的「Managed Lustre」頁面。
按一下要更新的執行個體執行個體名稱。系統隨即會顯示執行個體總覽頁面。
按一下 [編輯]。
輸入新的儲存空間容量值。這個值必須小於或等於容量上限,且必須是步距的倍數。如要瞭解這些值,請參閱「計算新容量」。
按一下「提交」。
gcloud
使用 gcloud lustre instances update 指令增加執行個體的儲存空間容量:
gcloud lustre instances update INSTANCE_NAME \
--location=LOCATION \
--capacity-gib=NEW_CAPACITY
其中:
- INSTANCE_NAME 是要更新的執行個體。
- LOCATION 是執行個體所在的可用區。
- NEW_CAPACITY 是這個執行個體的新儲存空間容量,以 Gibibyte (GiB) 為單位。該值不得超過允許的最大容量,且必須是步距的倍數。如要瞭解這些值,請參閱「計算新容量」。
REST
如要使用 REST API 更新執行個體,請將 PATCH 要求傳送至其特定端點:
PATCH https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/instances/INSTANCE_NAME?updateMask=capacityGib
Authorization: Bearer [YOUR_ACCESS_TOKEN]
{
"capacityGib": NEW_CAPACITY
}
其中必須指定下列值:
- PROJECT_ID 是您的 Google Cloud 專案 ID。
- ZONE 是執行個體的 Google Cloud 可用區。
- INSTANCE_NAME 是要更新的 Managed Lustre 執行個體名稱。
updateMask=capacityGib指定要更新的欄位。只有在遮罩中的欄位才會遭到覆寫。- NEW_CAPACITY 是這個執行個體的新儲存空間容量,以 Gibibyte (GiB) 為單位。該值不得超過允許的最大容量,且必須是步距的倍數。如要瞭解這些值,請參閱「計算新容量」。
詳情請參閱 instances.patch API 參考資料。
提交更新要求後,Managed Lustre 會檢查可用配額。如果配額充足,執行個體容量會在一段時間內增加,具體取決於大小變化。增加作業可能需要 20 分鐘到 1 小時以上。
更新期間,您可以繼續使用執行個體。
查看更新狀態
您可以透過下列介面查看更新要求的狀態。
Google Cloud 控制台
前往 Google Cloud 控制台的「Managed Lustre」頁面。
在清單中按一下執行個體名稱。系統會顯示「Instance Details」(執行個體詳細資料) 頁面,其中包含執行個體更新要求的目前狀態。
gcloud
根據預設,gcloud lustre instances update 指令會等待作業完成,然後傳回殼層提示:
Request issued for: [my-instance]
Waiting for operation [projects/my-project/locations/us-central1-a/operations/operation-1234567890-123] to complete...
完成後,指令列會顯示 Updated instance [my-instance] 和執行個體詳細資料,包括更新後的容量。
如果您使用 --async 旗標執行更新指令,或需要透過指令列查詢更新狀態,可以擷取作業詳細資料,查看執行個體是否已完成更新:
gcloud lustre operations describe OPERATION_ID \
--location=ZONE
執行個體更新期間,回應會顯示 done: false 值。完成後,done 會設為 true。
例如:
$ gcloud lustre operations describe operation-1234567890-123abc456-789def012-a1b2c3d4 \
--location=us-central1-a
done: false
metadata:
'@type': type.googleapis.com/google.cloud.lustre.v1.OperationMetadata
apiVersion: v1
createTime: '2025-08-27T18:13:49.771203623Z'
requestedCancellation: false
target: projects/my-project/locations/us-central1-a/instances/my-instance
verb: update
name: projects/my-project/locations/us-central1-a/operations/operation-1234567890-123abc456-789def012-a1b2c3d4
REST
如要查詢更新作業的狀態,請使用回應中的作業 ID。作業 ID 的格式如下:
operation-1234567890123-6127783ad26ea-88913969-02748053
向下列端點傳送要求:
GET https://lustre.googleapis.com/v1/projects/PROJECT_ID/locations/ZONE/operations/OPERATION_ID
Authorization: Bearer
如果成功,回應主體會包含 Operation 的執行個體。
增加容量後的效能
Managed Lustre 執行個體的處理量上限取決於儲存空間容量和效能級別。增加現有執行個體的儲存空間容量,也會提高其最大處理量。
可能要等到寫入新資料後,才會看到成效提升。 隨著新資料寫入並重新分配至額外儲存空間,處理量效能會逐漸提升。
「裝置沒有足夠的空間」錯誤
當檔案系統接近滿載 (通常使用率超過 90%) 時,即使監控工具指出仍有可用的匯總可用空間,您也可能會開始收到過早的 No space left on device 或 FILESYSTEM_NO_SPACE_ON_DEVICE (ENOSPC) 錯誤。
分散式檔案系統中的幾項基礎機制,可能會導致這種行為:
OST 不平衡:Lustre 會將檔案資料分散儲存至多個物件儲存目標 (OST)。不過,無論您的分條設定為何,某些工作負載模式都可能填滿單一 OST。常見原因包括以附加模式 (
O_APPEND) 寫入檔案,或保留大型未連結檔案。擴充後錯誤:即使為叢集新增容量,您仍可能繼續收到
ENOSPC錯誤。擴充容量會新增 OST,但不會自動將現有檔案重新平衡至新加入的目標。用戶端空間授予:Compute Engine 用戶端會動態保留部分磁碟空間,以提升效能。這個預留授權空間會減少可用的實體集區,也就是說,容量指標可能不會反映分散式用戶端已佔用的空間。
Inode 耗盡:如果工作負載產生數百萬個檔案,可能會在達到實體儲存空間限制前,耗盡檔案系統可用的 inode,導致建立新檔案時發生
ENOSPC錯誤。
建議的緩解策略:
監控容量並設定快訊:除了匯總叢集容量外,也請監控每個 OST 的容量使用率和個別 inode 指標。從掛接的用戶端執行
lfs df指令,即可查看每個目標的容量用量,使用lfs df -i則可查看每個目標的 inode 用量。如要進一步瞭解監控指標,請參閱「監控執行個體和作業」。設定自動快訊,在總容量或個別 OST 使用率超過 80% 時觸發 (請參閱「建立儲存體容量快訊」)。
增加容量:匯總容量達到 80% 至 90% 時,請考慮增加 Managed Lustre 執行個體的容量。您可能需要先申請更多配額,才能擴充。
重新平衡儲存空間:使用
lfs migrate指令 (建議在非封鎖模式-n下),手動將檔案從過度使用的 OST 轉換至較空或新加入的 OST。檢查用戶端上是否有未連結的檔案:開啟的未連結檔案是指即使與檔案系統命名空間取消連結後,仍由程序保持開啟的大型檔案。這些孤立檔案會留在磁碟上,占用空間,但不會顯示在標準目錄清單中。在這種情況下,Cloud Monitoring 容量指標和
lfs df指令回報的空間用量會高於du或lfs find。在用戶端上使用lsof指令,找出標示為(deleted)的項目,即可識別這些檔案。找出後,終止保留檔案控制代碼的程序或重新啟動應用程式,即可釋出檔案系統空間。