LVS學習筆記 1LVS基本概念
一、
基礎概念
rsync 同步軟體 效率不高inotify 通知
三種叢集：
LB: load balance 提高伺服器的併發能力
HA： 高可用 high availability 不會因為一臺伺服器宕機導致服務不可用
HP:high perfomence 高效能運算叢集
並行處理叢集
分散式檔案系統
將大任務切割為小任務，分別進行處理
health check：健康檢查
NFS：net filesystem 共享儲存裝置
DAS:直接附加儲存 塊級別交換資料 直接連到多型主機，效能好，但是要注意對同一檔案的同時寫
NAS：網路附加儲存 network attached storage 檔案級別交換資料
DAS:
ULTRAscsi 320Mbps 40M/s
SAS : 6Gbps
NAS: 資料交換取決於交換機乙太網
split-brain：腦裂 兩臺伺服器互相以為對方掛了，而對統一儲存裝置同時讀寫，造成崩潰
STONITH :爆頭
為了避免此情況，叢集一般要有奇數個節點，用以仲裁。
LVS模型
負載均衡叢集： 分發器接受使用者請求，根據某種策略將使用者請求分發到後端某個伺服器，並且後端伺服器群能夠進行健康檢查。分發到哪臺主機取決於排程演算法
Hardware 實現
F5 bigIP
A10
Software 實現三款
四層負載均衡裝置
LVS 根據IP：埠 進行分發。只解析四層協議 Linux virtual server
七層： 反向代理
nginx 根據應用層協議實現負載均衡 如 根據url進行分發 可能更符合生產環境需要
haproxy
LVS：Linux virtual server 能識別IP：埠來決定是否轉發至後端主機
工作在核心空間，藉助NETFilter 內建5條鏈（鉤子）
prerouting input forword output postrouting
因此，LVS工作在INPUT
lvs監控在input鏈，一旦規則發現使用者請求的是後端叢集服務，強行修改資料報文，通過postrouting 轉發。因此 iptables和LVS不能同時使用
iptables/netfilter 兩段式 iptables寫規則，在netfilter生效
lvs 也是兩段式
ipvsadm ： 管理叢集服務的命令列工具 在使用者空間寫規則然後送給ipvs
ipvs：核心 監控input鏈
Network-address-translation LVS-NAT ：地址轉換
Direct-routing LVS-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
黃色部分解析：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
不支援埠對映
因為客戶請求的是VIP，因此響應報文的源IP就應該是VIP，因此realsrver需要VIP。但是realserver的通訊靠的是RIP，因此這個VIP不是通訊用，僅僅作為源IP封裝
server的eth0別名上配置VIPTUN模型：
隧道協議 雙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
當然 如果叢集裡的WEB伺服器有一個壞了，那麼這個伺服器上的session就沒了，使用者請求被定義到新的主機，但是之前的操作就沒了，所以要進行session共享，吧session資訊同步到一個共享儲存。當然如果實現了session共享，就不需要sh演算法了
DH：現在有多個cacheserver。我們知道使用者請求某物件會先查詢快取，快取沒有才會請求源伺服器，然後快取到cache本地，然後返回給使用者，所以懂了麼？同一個請求發往同一個cachesserver