LVS 實驗筆記1 一些基礎概念

基礎概念

rsync 同步軟件 效率不高

inotify 通知

三種集羣：

LB: load balance 提升服務器的併發能力

HA： 高可用 high availability不會由於一臺服務器宕機致使服務不可用

HP:high perfomence  高性能計算集羣

         並行處理集羣

                   分佈式文件系統

                   將大任務切割爲小任務，分別進行處理

 

health check：健康檢查

NFS：net filesystem 共享存儲設備

DAS:直接附加存儲 塊級別交換數據 直接連到多態主機，性能好，可是要注意對同一文件的同時寫

NAS：網絡附加存儲 networkattached storage  文件級別交換數據

 

DAS:

         ULTRAscsi  320Mbps 40M/s

         SAS: 6Gbps

 

NAS: 數據交換取決於交換機以太網

 

split-brain：腦裂 兩臺服務器互相覺得對方掛了，而對統一存儲設備同時讀寫，形成崩潰

STONITH :爆頭

爲了不此狀況，集羣通常要有奇數個節點，用以仲裁。

LVS模型

負載均衡集羣：分發器接受用戶請求，根據某種策略將用戶請求分發到後端某個服務器，而且後端服務器羣可以進行健康檢查。分發到哪臺主機取決於調度算法

 

Hardware 實現

         F5bigIP

         A10

Software 實現 三款

         四層負載均衡設備

                 LVS  根據IP：端口 進行分發。只解析四層協議  Linux virtual server

         七層： 反向代理

                   nginx根據應用層協議實現負載均衡如 根據url進行分發 可能更符合生產環境須要

                   haproxy

        

 

LVS：Linux virtual server能識別IP：端口來決定是否轉發至後端主機

工做在內核空間，藉助NET Filter 內置5條鏈（鉤子）

         prerouting input  forword  output postrouting

所以，LVS工做在INPUT

lvs監控在input鏈，一旦規則發現用戶請求的是後端集羣服務，強行修改數據報文，經過postrouting 轉發。所以 iptables和LVS不能同時使用

iptables/netfilter 兩段式 iptables寫規則，在netfilter生效

lvs 也是兩段式

         ipvsadm： 管理集羣服務的命令行工具 在用戶空間寫規則而後送給ipvs

         ipvs：內核 監控input鏈

lvs 三種類型：

         Network-address-translationLVS-NAT ：地址轉換

         Direct-routingLVS-DIR：直接路由

         IP-tunneling LVS-TUN 隧道

 

NAT 模型;

最多負載均衡10個後端server，內網的網關要指向DIP，RIP和DIP必須在同一網絡中，director處於client和server之間，負責進出的全部通訊（所以director頗有可能限制集羣能力）；支持端口映射

         請求：客戶請求報文[cip|vip]àDirector（ipvs）à[cip|rip]à後端服務器

         迴應：響應報文[rip|cip]à Director (ipvs) à [vip|cip]à客戶

支持端口映射：如用戶IQ你滾球80端口服務，可是本機並無提供，而是映射到後端某服務器8080端口響應

DR 模型：

用戶請求報文[CIP|VIP] à router路由器進行ARP物理地址解析封裝MAC地址[router MAC |director MAC]à switchboardàdirecto，人後轉發請求到reserver,此時的轉發僅僅是director修改了報文的目標MAC 即[CIP|VIP][director MAC |reserver MAC] àreserver接收報文拆掉mac，發現目標是VIP，而VIP配置在eth0別名上，就是本身，就接收報文à響應報文封裝[VIP|CIP]直接送出。

所以：director只負責如站請求，而通常請求報文比較小，響應報文比較大，這樣一來director效率有了提升，能帶動百十來個server

***部分解析：

         由於客戶請求的是VIP，所以響應報文的源IP就應該是VIP，所以realsrver須要VIP。可是realserver的通訊靠的是RIP，所以這個VIP不是通訊用，僅僅做爲源IP封裝

server的eth0別名上配置VIP

特色：

         集羣節點跟director必須在同一個物理IP網絡中

         RIP可以使用公網IP，實現遠程管理

         director僅負責處理入站請求，響應報文由reserver直接發往客戶端

         realserver網關不能指向director，而是前端網關

         不能端口映射

 

TUN模型：

隧道協議雙IP封裝[CIP|VIP][DIP|RIP]

各個realserver在不一樣區域，擁有本身的公網IP做爲RIP，同時網卡還有別名爲VIP

用戶訪問director主機以後在[CIP|VIP]基礎上再加一層IP封裝即 [CIP|VIP][DIP|RIP]來實現請求分發。realserver接受報文，拆掉第一層，發現RIP就是本身，拆掉第二層發現VIP是本身的別名，仍是本身因而就接受了報文。響應報文就直接[VIP|CIP]發出去

 

特色：

         集羣節點能夠跨越互聯網

         RIP必須是公網地址

         director僅處理入站請求

         只有支持隧道協議的OS才能用於realserver

         不支持端口映射

lvs調度方法

固定調度：

調度時沒有考慮服務器是否繁忙等狀態，如某時刻各有100個請求，可是1個小時後，有的空閒了，有的仍是1001個請求，可是靜態調度依舊按規則分發請求

         rr：輪詢

         wrr：加權重輪詢

         SH：sessionsharing 實現session affinity ：會話綁定

         DH：把同一個IP的請求發給同一個server

 

動態調度：考慮服務器狀態，如活動連接數，非活動連接數，他們佔用資源是不同的

         LC：lestconnection 最少連接

                   active*256+inactive誰的小選誰

         WLC:加權最少連接 權重大小由服務器性能決定  默認算法

                  （active*256+inactive）/w

         sed:最短時間望延遲  忽略靜態連接

                   (active+1)*256/w

         NQ：永不排隊  無論計算值多少，只要有空閒服務器，不管如何會發給空閒服務器一個請求

         LBLC：基於本地的最少鏈鏈接

                   基於LC，和DH目的同樣，可是會考慮服務器狀態，有可能破壞緩存命中率，所以提升命中率和負載均衡效果成反比

         LBLCR:基於本地的帶複製功能的最少連接

                   如兩個cacheserver 能夠實現共享，

 

 

SH：sessionsharing原地址哈希對用戶請求作哈希運算，在director中位置一張哈希表，記錄了上一次這個用戶訪問被分發在了哪臺realserver，當同一用戶再次訪問時，計算哈希值到表中檢索，按照記錄將用戶請求依舊發送到以前的realserver。這樣一來其實破壞了調度平衡，可是又須要這樣作

why？ 好比WEB服務器，用戶訪問以後，加入購物車什麼的操做，一刷新，被轉發到新的WEB服務器上，以前全部的操做都沒了，爽不爽？

由於http是無狀態協議，即用戶上一次訪問和下一次訪問，服務器沒法識別是否是同一人，所以藉助session和cookie來識別用戶，機制是：當用戶首次訪問server，server會生成一個該用戶的cookie發給客戶端，保存在客戶端的coocki文件中。早期的cookie機制是用戶訪問server時每發一次請求都會附加上cookie信息，server對比cookie就知道是否同一用戶，所以cookie可能包含URL、身份認證等敏感信息，太不安全，因此如今流行清理cookie，清理cookie中的敏感信息，而只保留用戶認證信息，而後在服務器裏邊對應用戶cookie在內存中維持一段區域來保留用戶的詳細信息，這段內存區域就叫session

 

session affinity ：會話綁定

 

固然若是集羣裏的WEB服務器有一個壞了，那麼這個服務器上的session就沒了，用戶請求被定義到新的主機，可是以前的操做就沒了，因此要進行session共享，吧session信息同步到一個共享存儲。固然若是實現了session共享，就不須要sh算法了

 

 

DH：如今有多個cacheserver。咱們知道用戶請求某對象會先查找緩存，緩存沒有才會請求源服務器，而後緩存到cache本地，而後返回給用戶，因此懂了麼？同一個請求發往同一個cachesserver，