啟動、停止與銷毀

三個動作

動作	執行個體在什麼狀態時會提供	它會做什麼	通常要花	可逆
停止	`running`	關掉容器，保留硬碟，保住 GPU 名額	幾秒鐘	是，用「啟動」
啟動	`stopped`	在同一台機器與同一顆硬碟上把同一個容器叫回來	幾秒鐘	是，用「停止」
銷毀	`destroyed` 以外的任何狀態 — 包括 `creating`、`starting` 與 `stopping`	移除容器、刪除硬碟，把 GPU 還給市集	幾秒鐘	否

在你動用第三個之前，請先讀停止與銷毀的差別。那是決定你會不會保住資料、會不會繼續付錢的選擇，這裡不再重複。

按鈕在哪裡

執行個體 中的每一列都帶著適用於該執行個體目前狀態的動作，執行個體詳細頁面的標頭也會出現同一組。不適用的按鈕不會顯示 — 執行中的執行個體沒有「啟動」，已停止的沒有「停止」。執行個體還在建立中、啟動中或停止中時，「銷毀」依然可用，所以卡在這些狀態的執行個體永遠不會脫離你的掌握。主控台的這份清單取自 API 的 allowed_actions。

停止與銷毀都會先要求確認。停止對話框會寫明這次停止的花費：GPU 會繼續為你保留，執行個體隨時可以重新啟動，停止期間只收取儲存費。它也會說明餘額用完時 GPU 會怎樣。如果一筆付款爭議凍結了組織的付款，它會改為說明這次停止會在機器支援的情況下釋放 GPU。銷毀對話框會明白寫出即將被刪除的東西。啟動不會詢問。

按下之後會發生什麼

三個都不是瞬間完成的。執行個體會進入過渡狀態，狀態徽章會閃動，主控台會持續輪詢，直到機器回報：

你按下	進行中的狀態	完成後的狀態
停止	`stopping`	`stopped`
啟動	`starting`	`running`
銷毀	`destroying`	`destroyed`

執行個體處於過渡狀態時，除了「銷毀」之外不接受任何動作。硬要下別的會拿到 409 INVALID_STATE，訊息中會指出擋下它的狀態，例如 Cannot stop an instance while it is creating。等過渡完成再試一次。哪個狀態能走到哪裡的完整對照，在執行個體狀態。

主機始終沒有確認的轉換，不會讓執行個體卡住。30 分鐘後，還沒落定的停止會把執行個體放回 running — 容器還在執行，所以又開始計費 GPU — 並持續重試停止。還沒落定的啟動則會把它放回 stopped。這時執行個體頁面會顯示 上一個操作沒有完成 與原因，透過 API，執行個體的 error_code 會是 stop_timed_out 或 start_timed_out。

再次啟動

啟動需要餘額：你組織的餘額必須足以支付屆時所有執行項目一小時的費用 — 這個執行個體的 GPU 與硬碟，加上其他每個執行中、啟動中或建立中執行個體的 GPU 與硬碟，以及每個已停止執行個體的硬碟 — 而不只是大於零。不夠的話，啟動會被 402 INSUFFICIENT_BALANCE 拒絕，執行個體不會有任何變化 — 請先增加餘額。執行個體停著的期間累積的儲存費用，會在你啟動的那一刻結算，所以你之後看到的餘額已經把整段停止期間算進去了。

主機也必須接得下這次啟動。如果接不下，執行個體會連同硬碟維持 stopped，而啟動會被拒絕：

回應	發生了什麼	該怎麼做
`409 CAPACITY_UNAVAILABLE`	執行個體的 GPU 已被釋放 — 你的餘額到了零，或一筆付款爭議凍結了付款 — 而另一位租用者現在正在使用其中一張。你按下啟動之前，執行個體頁面已顯示 GPU 已釋放	稍後再試。如果等不及，就先把資料複製出來，再銷毀執行個體
`409 HOST_UNREACHABLE`	你的執行個體所在的機器目前沒有連線	稍後再啟動一次
`409 START_REFUSED`	主機拒絕恢復這個執行個體，或已不再持有它的工作負載	稍後再試。如果一直發生 — 或 API 的訊息表示主機已不再持有工作負載 — 就銷毀執行個體並重新部署
`503 START_UNAVAILABLE`	目前無法完成恢復	稍候再試。如果恢復最後還是落地了，執行個體會自己進入 `running`

啟動也可能先被接受，然後在機器上失敗。執行個體會自己回到 stopped，硬碟還在，執行個體頁面會在 上一個操作沒有完成 下說明原因 — 如果它被釋放的 GPU 原來已被占用，就是 gpus_unavailable。

啟動會讓你回到同一台機器、同一顆硬碟上。不過連線資訊會重新簽發，所以請重新複製 SSH 指令，不要沿用舊的。請見透過 SSH 連線。

處於 error 的執行個體

沒能成功起來、工作負載失敗或遺失，或工作已經跑完的執行個體會落入 error。它無法被啟動，也無法被停止。唯一可用的動作是「銷毀」。讀執行個體頁面上的 發生了什麼問題（它說明了執行個體的 error_code）與日誌，找出哪裡出錯，然後銷毀它並重新部署。如果平台之後發現工作負載其實在執行中或仍被保留，它會自己把執行個體移回 running 或 stopped。

透過 API

以下範例使用 $SUPERHEAT_API 與 $SUPERHEAT_KEY，請依 API 總覽的說明設定。

curl -X POST -H "Authorization: Bearer $SUPERHEAT_KEY" \
  $SUPERHEAT_API/v1/instances/$INSTANCE_ID/stop

curl -X POST -H "Authorization: Bearer $SUPERHEAT_KEY" \
  $SUPERHEAT_API/v1/instances/$INSTANCE_ID/start

curl -X DELETE -H "Authorization: Bearer $SUPERHEAT_KEY" \
  $SUPERHEAT_API/v1/instances/$INSTANCE_ID

每一個都會回傳處於新過渡狀態的執行個體。輪詢 GET /v1/instances/{id} 就能看它落定。請見執行個體。

平台替你執行的動作

當組織的錢用完時，這三個動作中有兩個會自己執行：

餘額	會發生什麼
到達 $0	執行中的執行個體會被停止，已停止執行個體的 GPU 會在機器支援的情況下被釋放；硬碟保留
在 $0 或以下持續 24 小時，且在 −$5 或以下	已停止與出錯的執行個體會被銷毀；硬碟被刪除

請見自動停止與自動銷毀。

三個動作​

按鈕在哪裡​

按下之後會發生什麼​

再次啟動​

處於 error 的執行個體​

透過 API​

平台替你執行的動作​

相關內容​