啟動順序是延遲，不是相依關係

停電後主機恢復運作，但應該在執行的服務有一半沒有起來。資料庫機器已經啟動，前面的應用程式卻已經放棄；或者某個容器無法掛載另一個容器仍在啟用中的儲存空間。沒有東西壞掉，也沒有值得一讀的錯誤記錄。只是各個部分以錯誤的順序啟動而已。

環境的架構，也就是哪個客體依賴哪個客體，正是在這裡從腦中的一張圖，變成機器實際執行的東西。值得確切了解這個機制到底做了什麼，因為它的範圍比多數人以為的更窄。

解釋大多數意外的一句話

啟動延遲是一段間隔，不是一個條件。

為客體設定延遲後，Proxmox VE 會啟動該客體，等待指定的秒數，然後處理下一個。它不會檢查客體內部是否已完成開機。它也不會檢查某項服務是否有回應。它只是等待，然後繼續。

因此，腦中的那種安排，也就是應用程式等待資料庫，從來不是實際寫進設定的內容。實際設定的是：應用程式在資料庫收到啟動指令的九十秒後啟動。在平靜的測試重新啟動中，兩者毫無差別。但在真正停電之後，當磁碟變慢、檔案系統檢查正在執行，或某個客體開機進入救援模式時，兩者就不一樣了。

設定數字之前值得知道的四條規則

數字小的先啟動，也最後關機。關機順序是啟動順序的反向，沒有另外的設定。順序為 1 的客體最先啟動、最後關機，通常這正是其他一切所依賴的那台機器需要的行為。

相同的數字並不是隨機的。順序相同的客體會再依 ID 由小到大排序。也就是說，同序時的結果穩定且可預測，不必為每個客體指定不同的數字，也能得到可重現的行為。

沒有設定順序的客體，一律在有順序的客體之後啟動。這比聽起來更有用。不必替所有東西編號。只要為真正必須提早啟動的三、四個項目編號，其餘維持原樣即可。

順序只適用於單一主機，不適用於叢集。它無法表達節點 A 上的這個客體必須比節點 B 上的那個客體先啟動。相依關係一旦跨越節點邊界，這個機制就完全無能為力。

之後才會出現的陷阱

由高可用性堆疊管理的客體，會同時忽略開機時啟動設定與啟動順序。啟動與關機程序會完全略過它們，因為何時執行是由 HA 管理器決定的。

這個陷阱要很久之後才會發作。一台仔細調整過順序的主機可以正常運作一整年。接著第二個節點加入，幾個客體移到 HA 底下，它們的順序就悄悄不再生效。不會有任何警告，因為沒有任何錯誤；只是責任轉移了。

真正需要的延遲，往往是另一種

會去調整客體延遲，常見的原因是外部資源：必須在任何東西掛載之前就能連線的網路儲存空間，或需要一點時間才能就緒的交換器。逐一拉開客體之間的間隔來換取這段時間，是很笨拙的做法，因為它會拉長整個啟動序列。

正好有一個針對這種情況的節點層級設定：主機完成自身開機後，到第一台自動啟動的客體之前的延遲。一個數字，只套用一次，而且正好放在真正需要等待的位置。

出事之前沒人會設定的數字

關機逾時的預設值是每個客體 180 秒。Proxmox VE 會要求客體關機並等待，逾時後客體若仍在執行，就會被強制停止。一次停止所有客體的批次作業，也有自己三分鐘的整體上限，時間到了同樣會強制停止。

對於關機時會把資料寫回磁碟的機器，這個上限值得刻意檢查，而不是在停機事故中才發現。預設值對多數客體來說很寬裕，對少數客體則太短，而那少數正是強制停止會造成損失的客體。

實務上實際看到的情況

在用來驗證本文所述行為的主機上，共設定了九台客體，其中三台設為開機時啟動。沒有任何一台設定了啟動順序。

這是常態，而且通常沒有問題。彼此不相依的機器不需要順序。寫下這件事的目的比較窄：如果曾經說出某個客體需要另一個客體先啟動，那麼這句話目前只存在記憶中，而停電不會讀取任何人的記憶。

Atlas 的做法

Atlas 不會替使用者重新排序任何東西，也不會在 Proxmox VE 既有的機制之上另創一套相依系統。它做的是把這些關係呈現在同一張圖上，而不是一次只看一個客體，讓這裡實際上什麼依賴什麼這個問題，可以在機器平穩時提出，而不是在它重新啟動的途中。

看見架構並不會替它完成設定。但沒有人能為一個從未畫出來看過的配置，訂出合理的順序。