分布式集群管理
阿新 • • 發佈：2017-07-16
項目 功能 參考 部署 ont toc 分布式 容量 相差 
轉載請說明出處：http://blog.csdn.net/cywosp/article/details/21259391
現在很多互聯網科技公司，還有一些傳統的it公司都在根據自身的業務發展來設計符合實情的分布式系統。雖然，已有很多優秀的開源分布式系統，但是由於需求不同，業務不同，這些只能在設計符合自身需求的分布式系統時用於參考。個人認為，設計一個分布式存儲系統並不是太難，主要困難在於如何設計並實現一個可以自動化處理各個節點狀態的分布式集群管理系統。分布式系統到現在已經發展了很多年了，有些公司已經部署並上線使用多年，但到現在也沒有關於集群管理方面的權威標準，各個公司都是根據自身的條件來處理集群中的問題。 分布式集群管理在發展的過程中會有不同的發展階段。對於公司而言，根據公司業務規模，技術水平的不同，集群管理的方式也有所不同。在最初時期，為了設計一個符合自身業務需求的分布式系統，可能會先部署一個開源系統來學習，並通過手工來管理，整個集群中沒有任何的數據監控用於運維管理，當然這一時期也用不上。隨著時間的推移，自己設計的系統從demo變成可商用，公司從成本上考慮，會將重心放在核心的業務實現上，一時無法顧及高效的運維，將集群管理工作先由運維人員或者開發人員來擔任。在這一階段，可能會使用一些零散的自動化腳本和第三方組件來管理。當然，以上敘述在大多數情況下會是一些剛剛起步，急於軟件商用公司的開發方式。對於比較成熟的大公司而言，他們會投入大量的財力，物力去研發一套自己的集群管理軟件，事實監控節點的狀態，做到自動化測試，自動化故障處理，自動化部署以及自動化發布，平滑升級等等功能。還有一些業內領先的巨頭公司，他們可能會在自動化故障處理方面做得更加出色。——個人認為集群中的故障處理是分布式管理中最為難處理的一塊，是集群管理的核心。如何做到快速，精準的故障切換，這是極其困難的。尤其是系統規模達到一定程度後，機器出故障的頻率也會顯著增加，當集群內部網絡擁塞時，故障則更加難以判斷，如果單靠人去維護話，那是不切實際的。 分布式集群管理大概可分為以下幾點：節點管理、設備的管理、集群容量管理、集群策略管理、服務管理以及節點故障處理等，一般采用一個主節點（Master），其他節點都為從節點（Slave）的設計方式。集群管理在整個架構中的位置大概如下圖所示：
- 單點問題。
- 網絡要合理劃分，避免內被網絡被“汙染”。
- 集群管理的相關操作不能影響數據流的正常傳輸以及傳輸性能。一般情況的做法是將管理網絡與數據網絡相互獨立，內外訪問網絡分離。
- 集群管理師對各個節點的管理，因此，管理的內容以及節點相關狀態由各個節點負責收集。
- 為保持各個節點之間的獨立性，不同節點的相同集群管理模塊服務間不相互通信。
- 集群中，各節點間的時間同步很重要，不能相差太多。一般做法是采用主節點（Master）使用NTP與外部標準的授時中心同步時間，然後各個從節點（Slave）去同步主節點的時間。
- 在集群中有些節點內部不需要實時監控的狀態數據可以使用各自為政的方式定時向主節點（Master） 反饋。例如：內存使用率、CPU使用率、緩存狀態等等。
- 節點內部模塊最好使用相同的機制提供服務。（thrift、protocol buffer、RESTful等）
- 主節點（Master）故障切換應遵守最下切換原則（最短時間、最少數據遷移），在集群中的從節點中選擇一個來做主接點（Master）。在一些分布式系統中會采用選舉法，就近原則等方法來完成故障的切換。
- 管理中產生的重要數據要多點多副本的本分，所有操作都需要有相應的記錄日誌。
- 集群的設計一定要切合實際。軟件設計往往會讓人陷入完美、面面俱到的陷阱裏。分布式軟件的設計和開發是一個需要長時間、多人投入的項目，做好了，可以支撐一個公司快速的業務發展，做差了，則是勞民傷財，甚至團隊成員分崩離去。如果你的客戶是一些中小企業、事業單位、政府機關、醫療機構，那麽花長時間去做一個只又三、五個節點的集群自動化管理，這是不太值得的，還不如在保證集群可管理的情況下將大量的時間放到業務的開發上，保證終端用戶對產品的友好、簡單的使用上。如果你的客戶是一些擁有幾萬人的企業，或者整個互聯網用戶，那麽集群自動化管理就尤為重要了。
好的架構是進化來的，不是設計來的 好的功能也是進化來的，不是設計來的 任何牛B的人物，都有一段苦B的經歷 在以賣軟件為生的公司裏，任何牛X的架構，沒有財力支撐，沒有優秀的程序員去實現，那麽它也僅僅是個架構而已。
分布式集群管理