設定變成唯讀：為什麼存放設定的位置與眾不同

試著編輯一個檔案，卻被拒絕存取。身分是 root。磁碟還有空間。仍然無法寫入。

這裡沒有任何東西壞掉。眼前這個位置並不是一般的目錄，它是刻意拒絕寫入的。

存放設定的位置不是一個目錄

Proxmox 把機器設定、儲存區定義、防火牆規則和備份工作都放在同一個地方。它看起來像檔案系統，有資料夾也有檔案，但背後其實是一個小型資料庫，而這個資料庫會複寫到叢集中的每個節點。

原因很簡單：叢集中的每台伺服器都必須看到相同的機器定義。若要把一台機器從一台伺服器遷移到另一台，另一端必須事先知道這台機器是如何定義的。如果設定只是某台伺服器磁碟上的普通檔案，其他伺服器就不會知道它的存在。

這種設計帶來三個後果，而且三個都會在日常中遇到。

後果一：沒有多數時，寫入會被拒絕

如果一台伺服器看不到叢集中的多數成員，寫入就會關閉。讀取仍可運作，寫入則停止。

這不是故障，而是一種決策。如果網路一分為二，而兩半都能寫入，同一台機器最後就會有兩份不同的定義。網路恢復時，沒有人能判斷哪一份才正確，也無法將它們合併。因此系統選擇這樣做：落入少數的一方停止寫入。

叢集中如何計算多數，以及為什麼兩台伺服器的架構很尷尬，另有一篇文章說明。這裡只需補充一點：突然無法寫入，正是這條多數規則在實務上的樣子。

後果二：即使只有單台伺服器，同樣的結構也在運作

即使沒有叢集，這個結構也在運作。單台伺服器本身就構成多數，所以平常不會出問題。

但如果提供這個結構的服務狀態不正常，單台伺服器上也會出現同樣的症狀。所以沒有叢集就不會遇到這種事的想法並不正確。

還有一條較少人知道的路徑：這個結構背後的資料庫位於本機磁碟上。本機磁碟寫滿時，寫入會失敗，看起來就像無法變更設定。症狀出在設定這一側，原因卻在儲存空間那一側。

後果三：寫在那裡的東西會送到所有節點

不存在只在這台機器上變更這種選項。寫在那裡的內容會傳送到叢集中的每個節點。

不了解這一點時最典型的錯誤，就是在一個節點上做實驗性變更，並以為它不會影響其他節點。

還有一點：那個位置是為設定而設計的，不是為資料。小型文字檔屬於那裡；指令碼、封存檔和備份則不屬於。不要養成把檔案留在那裡的習慣。

無法寫入時，依序檢查

先檢查多數：這台伺服器看得到叢集的其他成員嗎？如果看不到，真正的問題在網路，設定檔是無辜的。

接著檢查服務：提供這個結構的服務是否正在執行？

接著檢查本機磁碟：如果已經寫滿，就是上面提到的那條路徑。

最後一項，也是最常被跳過的：某個節點可能已經離開叢集。網路中斷、鄰近的節點被關機、防火牆規則設定錯誤。症狀總是看起來一樣，原因卻每次都在不同的地方。

Atlas 的做法

Atlas 直接以檔案的形式讀取這個結構，而不是每次都執行系統的查詢工具。

我們量測過原因。每次呼叫那個工具，都要花費 100 到 200 毫秒的處理器時間，以及約 100 MB 的暫存記憶體。面板開著時每 10 秒重新整理一次，每次重新整理需要 8 到 10 次呼叫。換句話說，監控本身正在它所監控的那台伺服器上製造持續的波動。

從檔案讀取相同的資訊只需要幾微秒。差距高達數千倍，而這個差距在使用者的機器上就表現為穩定。

第二個細節更為巧妙：這個結構裡有一個變更計數器，每當設定變更時就會遞增。Atlas 會監看它。因此只要有人從面板變更了某項設定，快取就會自行重新整理；很少查詢與從不顯示過時資訊，得以同時成立。

這是本 wiki 其他地方寫過的一項原則的另一面：負責監看的東西不應該成為負擔。監控工具最容易犯的錯誤，就是拖慢它所監看的系統，並因此扭曲它正在量測的那個數字。