Linux之FineBI集羣部署

在企業應用中，一般單個計算機的配置是有限的，而企業應用又是高併發的需求，這個時候會經過計算機集羣的方式來提升併發數，從而提升總體應用服務的性能。集羣是將多臺計算機做爲一個總體來提供相關應用的服務。FineBI支持多計算機服務的集羣部署，經過集羣部署利用有限的計算機資源來有效提升總體應用的併發性能。本文主要介紹總體FineBI集羣的思路。
FineBI採用負載均衡集羣的模式，將多臺服務器建立爲一個集羣服務器。這裏碰到這幾個問題：1）web工程的存儲問題：FineBI在集羣中，因爲自身的問題須要多臺服務器讀取同一個web工程。所以要實現web工程分享。2）系統數據一致性：在FineBI的運行過程當中，存在讀寫的操做，同時有部分的數據的配置文件要寫入數據庫。須要保證集羣的狀況下，系統數據的一致性。3）負載均衡：一方面經過負載均衡來處理session的問題，另外一方面達成負載均衡的集羣環境，使用代理服務器能夠將請求轉發給集羣內部的服務器，能夠將負載均衡和代理服務器的高速緩存技術結合在一塊兒，提供有益的性能。4）FS平臺集羣：如FineBI使用FS平臺，則FS平臺的各類配置也須要進行集羣配置。
以下圖是一個FineBI進去的架構的案例示意圖，這種方式經過NFS文件共享來處理web工程。

Web工程存儲問題
Web工程的存儲，咱們要解決的是多個服務器保證讀取同一個web工程。咱們能夠經過ceph作到多塊物理硬盤組件一塊邏輯硬盤，從而實現全部節點都是在訪問同一地址；也能夠經過linux自己帶有的nfs共享文件服務來達成訪問同一web工程。不管使用哪種方式，咱們要保證：
1）訪問同一web工程
2）存儲地址是一致的
由於同一個web工程下，要求cube的存儲地址是一致的，所以要求cube存儲地址必定要同樣。
而真正使用的時候，ceph的實現須要至少三臺計算機來實現，而實際企業應用中，比較少使用三臺；而nfs都可以且是linux自己的，所以使用「nfs」方案。
系統數據配置
單節點的狀況下，利用緩存和經過操做系統的文件系統來保存數據的方式，在集羣模式下再也不合適。主要緣由在於數據的一致性問題，多個節點可能進行同時讀寫，更改系統數據，最終勢必會形成總體數據不一致。最好的解決方案是系統配置數據所有交給MySQL等關係型數據庫來管理。但因爲這樣工程量好大，更主要的緣由爲許多代碼缺乏維護，貿然更改可能帶來意想不到的bug。因而咱們採用一種折中的作法。在集羣中選出一臺幾點做爲主節點，簡稱M。其他節點擔當子節點，簡稱S。當S上全部與更改系統配置相關的操做，所有發送到M上進行處理。M負責來更改系統狀態，維護整個系統到底一致的狀態。S節點放棄所有的緩存數據，讀取狀態的時候，再也不經過讀取自身數據，而是經過向M發送讀取請求，得到M上的數據。M節點自身能夠存在緩存數據。其餘數據S節點與M節點時等同的，不存在從屬關係。

所以按上述起因咱們提供以下解決方案：
1）數據庫：原web工程中存在finedb的配置信息轉存到mysql數據庫中。由於finedb數據庫只能有一個鏈接，沒法多節點同時讀取，而mysql數據庫則不存在。Logdb也需遷移；
2）主子節點：咱們使用主子節點的方式來配置集羣，系統數據的更改均在主節點上進行，子節點只讀取主節點上的數據；
3）Zookeeper：爲了保證讀寫狀況下，主子節點保證數據一致性，還須要zookeeper進行通訊，充當文件鎖的功能。
負載均衡
在FineBI的集羣環境中，咱們可使用任何支持負載均衡的服務器來完成輪發的任務，並保證session粘滯。此處咱們使用的是nginx反向代理，使用IP標識輪發，保證同一個用戶在同一個session。（在一個服務器一個節點的狀況下，同一個IP就保證session粘滯）。
FS平臺集羣
使用FS平臺集羣插件，將FS平臺配置可以知足集羣需求。在FS平臺集羣中，FS平臺的全部操做都是發到主節點上來操做；子節點只是做計算服務器。