上上週碼雲掛了一次，時間30分鐘左右，今天又掛了一次，時間將近30分鐘。兩次掛機的原因的是一樣的。其中兩臺配置較差的機器在高峯期大量代碼的 push 下宕機，每次掛一臺機器。讓機器重啓機器後系統就恢復了。這個過程大概是 20-30 分鐘。
爲什麼會有配置較差的機器呢？
最開始我們在準備碼雲服務器的時候，老的架構下是分爲應用服務器和存儲服務器，因此我們採購的應用服務器一般是CPU很強，存儲容量較小；而存儲服務器的存儲容量很大但是CPU只有單顆。
而去年年底我們對整個分佈式結構做了大幅度的調整，直接將 Git 倉庫拆到不同的機器上，也就是每一臺機器既充當存儲又充當計算的角色，然後每一臺機器只處理一部分的 Git 倉庫。
老的那些應用服務器我們已經增加了存儲，但是老的存儲服務器還是單個 CPU，於是在每天下班之前這段時間內，是碼雲一天中併發 Push 代碼量最高的時期，直接導致這些配置較差的存儲服務器宕機。另外一個更爲重要的原因是最近兩三個月每天 Push 代碼的項目數又翻了一倍，因此負載過重。
爲什麼分佈式單個節點宕機會導致整個倉庫無法訪問？
原因也在這兩臺配置較差的服務器上，爲了降低這兩臺機器的壓力，我們把 HTTP/HTTPS 的請求分發到其他的節點去處理，這樣的話後臺臨時需要通過 NFS 方式訪問這兩臺設備上的 Git 倉庫，因此產生了互相影響。
接下來的處理措施
也就是說最近掛機稍顯頻繁的原因在於機器的處理能力上。我們已經開始採購新的一批服務器，按照高處理性能以及大存儲的要求，用來替換這兩臺設備。完全替換之後再進行老設備的處理性能升級（增加CPU和內存），然後重新加入集羣節點中。
這個過程預計前後大約需要1個月左右的時間，在此期間我們會將這兩臺老設備的 Git 倉庫遷移一部分到其他機器上以降低壓力。
目前碼雲集羣中除了前端 Web 服務、數據庫、緩存、隊列等單獨服務器之外，共有 8 個節點，總存儲容量 80T 左右。
壓力很大，全力以赴！