Linux集羣理論及技術

Linux集羣理論及技術css

1、定義分類前端

由多臺提供相同服務的Linux服務器組成的集合,稱爲Linux集羣。根據集羣做用分類爲:mysql

一、負載均衡集羣(LB)
目的是可以根據網站需求,自由擴展
二、高可用集羣(HA)
目的是保障服務長時間可用
三、高性能集羣(HP)
目的是解決大數據分析和計算

2、評估網站系統指標sql

一、可擴展性:根據網站需求,自由擴展或縮減
二、可用性:通常使用百分比來評估,95%,99%,99.9%,99.99%,99.999%即,可用性=年可用時長/一年總時長
三、性能:對整個網站訪問量和響應時間的評估指標
四、容量:網站訪問量,服務器硬件配置評估指標

3、評估運維水平的指標緩存

一、可用性:重中之重,最基礎的指標
二、標準化:對多套系統,架構的標準制定;例如:版本控制(包括系統,應用等),目錄路徑的統一;最後的效果是:提供相同服務的服務器作到只有一個指導文檔
三、自動化:作到標準化之後,能夠根據本身的需求定製開發本身的運維工具,達到自動化的目的

4、網站演化思路服務器

一、分層:接入層——>應用層——>服務層——>數據層
二、分割:化整爲零,將大業務切割成多個小業務
三、分佈式
分佈式分類舉例:
    *分佈式應用
    *分佈式靜態資源
    *分佈式數據和存儲
    *分佈式計算

5、網站演化舉例架構

一個以PHP開發的電商網站,初始只有一臺lnamp服務器。那服務器遇到瓶頸怎麼作擴展呢?負載均衡

一、換高配硬件服務器運維

wKiom1Yc1JTBkQG1AACa7HHJ_oI933.jpg

這種經過更換硬件提升服務器配置性能的擴展,稱爲縱向擴展。可是,單臺服務器的硬件配置終究會有用完的時候,而業務的增加卻能夠無限制;而且,隨着硬件配置的提升,單臺硬件服務器的價格也是呈幾何倍數增長,投入產出的性價比會愈來愈低。分佈式

二、DNS解析

wKioL1Yc1PnS6_QFAACcorass0w645.jpg

這種經過增長提供相同服務的服務器的擴展方式,稱爲橫向擴展。原理是:增長一臺提供相同服務的服務器,經過DNS將訪問請求分別解析到不一樣的ip地址,來達到分流的目的。

這種簡單的分流方式存在比較多的問題:1DNS的緩存做用會使分流效果大打折扣;2、服務器之間沒有共同的數據存取地址和通訊機制,動態網站存在數據不一樣步問題;3、鏈接的會話可能會被分配到兩臺服務器上,形成用戶看不到以前的操做,仍是同步問題

三、分割

wKiom1Yc1UriQzbGAADFfGS8gxo099.jpg

這也是橫向擴展的一種方式,將一臺服務器上佔用大量資源的服務拆分到單獨的服務器上,減輕服務器壓力。直到服務器正常,或者直接使每臺服務器專一於一件事。

四、集羣

通過3分割(分層)後,訪問鏈接數增加,依然會面臨資源問題。此時,須要增長某個資源緊張的節點服務器,組合成集羣分擔壓力。相似2中,並行的增長一臺節點服務器。例如:3中的AP節點壓力過大,資源緊張,就須要增長AP環境的節點數量。全部的AP節點集合組成一個AP集羣,其餘層次的節點是相同的道理。

wKioL1Yc1ZvCcV1sAACd7fCfTLI832.jpg

五、集羣調度

爲了解決2中的DNS緩存帶來的問題,在集羣前端添加一層,做爲集羣的調度器。調度器的做用就是替代DNS的解析分流方式,由調度器來完成。DNS解析到LB,由LB來分配具體將鏈接分發給哪一個服務器處理。

wKioL1Yc1gDBQcnOAACiX_gELYs067.jpg

六、SPOF

Single Point of Failure故障單點。問題思考:上面的架構,存在的致命問題,萬一LB服務器掛了,形成什麼後果?該怎麼辦?此時,兩臺LNAMP服務器再也不直接面對外部的用戶,鏈接所有由LB轉入這兩臺服務器的。這樣形成的結果就是「服務不可用」,儘管LNAMP兩臺服務器一點問題都沒有。這樣的LB服務器在這個架構中就被稱爲故障單點。那怎麼解決?作冗餘,下圖

wKiom1Yc1e2Ap0utAACrTdh_Ryw983.jpg

兩臺LB之間通訊,slave固定檢測master是否可用,不可用時slave生效頂替master的工做。與mysql的主備結構原理相同

七、緩存

緩存技術是加快服務響應時間的重要手段。在分層結構中每層的前面加入緩存層,能夠加快相對服務層的響應速度,CDN技術就是一種緩存手段。緩存的原理就是將靜態且訪問量最多的數據緩存到內存中,省去內存從硬盤查找讀入內存的操做時間,從而達到加速的目的。

緩存命中率:在緩存服務器上讀取到的數據所佔全部訪問數據的比重。需注意影響命中率的因素有:內存過小、數據更新頻繁,都會下降命中率。甚至,可能由於頻繁的將不一樣的數據緩存入內存,內存硬盤數據交互加重,形成沒必要要的資源開銷浪費。得不償失;

八、消息隊列

構建高可擴展性的網站架構須要遵循的基本原則:在集羣系統內部儘可能避免串行化和交互。若是沒法避免,能夠交互系統之間加入中間層,對系統進行解耦。

消息隊列在消息的傳輸過程當中保存消息的容器消息隊列是一種行之有效的解決系統交互,解耦的方法。

wKioL1Yc1jaxBBCcAAB7HVjWsEw764.jpg 

例如:B服務的運行須要用到A服務的運行結果。1AB之間沒有中間的一層(AB直接通訊),若是一段時間B的程序運行時間過長,A沒法將運行結果交付給B。就會形成A必須等待B而沒法運行新的運算,從而浪費A的資源。

2AB之間有一層中間層(例如消息隊列),A運行獲得的結果存入消息隊列,繼續下一個請求。B隨時能夠從隊列內讀取數據,從而避免上面的狀況,使A在任什麼時候間均可以接收處理任務請求。                                     

相關文章
相關標籤/搜索