流程解釋:
當使用者向負載均衡排程器（director server）發起請求，排程器將請求發往至核心空間
prerouting 鏈首先會接收到使用者請求，判斷目標 ip 確定是本機 ip，將資料報發往 input 鏈
ipvs 是工作在 input 鏈上的，當使用者請求到達 input 時，ipvs 會將使用者請求和自己已定義好的集群服務進行比對，如果使用者請求的就是定義的集群服務，那麼此時 ipvs 會強行修改資料報裡的目標 ip 位址及埠，並將新的資料報發往 postrouting 鏈
對lvs基本概念不太了解的,先維基百科或者參考:linux負載均衡lvs理論以及演算法概要
lvs 由 2 部分程式組成，包括 ipvs 和 ipvsadm。ipvs(ip virtual server)：一段**工作在核心空間，叫 ipvs，是真正生效實現排程的**。
ipvsadm：另外一段是工作在使用者空間，叫 ipvsadm，負責為 ipvs 核心框架編寫規則，定義誰是集群服務，而誰是後端真實的伺服器 (real server)
在 lvs+keepalived 環境裡面，lvs 主要的工作是提供排程演算法，把客戶端請求按照需求排程在 real 伺服器，keepalived 主要的工作是提供 lvs 控制器的乙個冗餘，並且對 real 伺服器做健康檢查(是不是還能提供服務?)，發現不健康的 real 伺服器，就把它從 lvs 集群中剔除，real 伺服器只負責提供服務。具體操作是存活訊號通常以一定的時間間隔發出,若一端在訊號發出後未收到回覆，則可判定資料鏈路離線並將之後的資料報重新路由到其他鏈路，直到舊鏈路重新上線為止。存活訊號也可表示保留連線狀態。若無存活訊號，啟用網路位址轉換的路由器將於超時後中斷連線。
keepalived 通過選舉（看伺服器設定的權重）挑選出一台熱備伺服器做 master 機器，master 機器會被分配到乙個指定的虛擬 ip，外部程式可通過該 ip 訪問這台伺服器，如果這台伺服器出現故障（斷網，重啟，或者本機器上的 keepalived crash 等），keepalived 會從其他的備份機器上重選（還是看伺服器設定的權重）一台機器做 master 並分配同樣的虛擬 ip，充當前一台 master 的角色。
選舉策略是根據 vrrp 協議，完全按照權重大小，權重最大（0～255）的是 master 機器，下面幾種情況會觸發選舉
keepalived 啟動的時候
master 伺服器出現故障（斷網，重啟，或者本機器上的 keepalived crash 等，而本機器上其他應用程式 crash 不算）
有新的備份伺服器加入且權重最大
keepalived 是執行在 lvs 之上, 它的主要功能是實現 realserver(真實伺服器)的故障隔離及 director(負載均衡器)間的 failover(失敗切換).
dr模式示意圖:
流程解釋:
重點將請求報文的目標 mac 位址設定為挑選出的 rs 的 mac 位址,當rs接收到這個資料報之後,將源mac替換成自己的mac,目標mac位址為客戶端位址。(1) 當使用者請求到達 director server，此時請求的資料報文會先到核心空間的 prerouting 鏈。 此時報文的源 ip 為 cip，目標 ip 為 vip,mac位址一次為各自的mac位址。
(2) prerouting 檢查發現資料報的目標 ip 是本機，將資料報送至 input 鏈。
(3) ipvs 比對資料報請求的服務是否為集群服務，若是，將請求報文中的源 mac 位址修改為 dip 的 mac 位址，將目標 mac 位址修改 rip 的 mac 位址，然後將資料報發至 postrouting 鏈。 此時的源 ip 和目的 ip 均未修改，僅修改了源 mac 位址為 dip 的 mac 位址，目標 mac 位址為 rip 的 mac 位址。
(4) 由於 ds 和 rs 在同乙個網路中，所以是通過二層來傳輸。postrouting 鏈檢查目標 mac 位址為 rip 的 mac 位址，那麼此時資料報將會發至 real server。
(5) rs 發現請求報文的 mac 位址是自己的 mac 位址，就接收此報文。處理完成之後，將響應報文通過 lo 介面傳送給 eth0 網絡卡然後向外發出。 此時的源 ip 位址為 vip，目標 ip 為 cip,並且將源mac位址改為自己的mac,目標mac改為客戶端mac。
(6) 響應報文最終送達至客戶端
rs 可以使用私有位址；也可以是公網位址，如果使用公網位址，此時可以通過網際網路對 rip 進行直接訪問
rs 跟 director server 必須在同乙個物理網路中
所有的請求報文經由 director server，但響應報文必須不能進過 director server
不支援位址轉換，也不支援埠對映
rs 可以是大多數常見的作業系統
rs 的閘道器絕不允許指向 dip(因為我們不允許他經過 director)
rs 上的 lo 介面配置 vip 的 ip 位址
缺陷：rs 和 ds 必須在同一機房中
特點 1 的解決方案：dr（direct routing 直接路由模式）此模式時 lvs 排程器只接收客戶發來的請求並將請求**給後端伺服器，後端伺服器處理請求後直接把內容直接響應給客戶，而不用再次經過 lvs 排程器。lvs 只需要將網路幀的 mac 位址修改為某一台後端伺服器 rs 的 mac，該包就會被**到相應的 rs 處理，注意此時的源 ip 和目標 ip 都沒變。rs 收到 lvs **來的包時，鏈路層發現 mac 是自己的，到上面的網路層，發現 ip 也是自己的，於是這個包被合法地接受，rs 感知不到前面有 lvs 的存在。而當 rs 返回響應時，只要直接向源 ip（即使用者的 ip）返回即可，不再經過 lvs。
(1) 確保前端路由器將目標 ip 為 vip 的請求報文發往 director：
(a) 在前端閘道器做靜態繫結；
(b) 在 rs 上使用 arptables；
(c) 在 rs 上修改核心引數以限制 arp 通告及應答級別；
arp_announce
arp_ignore
(2) rs 的 rip 可以使用私網位址，也可以是公網位址；rip 與 dip 在同一 ip 網路；rip 的閘道器不能指向 dip，以確保響應報文不會經由 director；
(3) rs 跟 director 要在同乙個物理網路；
(4) 請求報文要經由 director，但響應不能經由 director，而是由 rs 直接發往 client；
(5) 此模式不支援埠對映；
唯一的缺陷在於它要求 lvs 排程器及所有應用伺服器在同乙個網段中，因此不能實現集群的跨網段應用。
可見在處理過程中 lvs route 只處理請求的直接路由**，所有響應結果由各個應用伺服器自行處理，並對使用者進行回覆，網路流量將集中在 lvs 排程器之上。
DR模式搭建LVS負載均衡
排程器dir 192.168.8.154 真實伺服器rs1 192.168.8.120 真實伺服器rs2 192.168.8.100 vip 192.168.8.180 閘道器設定成自己的閘道器，跟nat模式有區別 編輯dir vim usr local sbin lvs dr.sh bin bas...
LVS 負載均衡 DR模式環境搭建
簡單記錄一下搭建lvs負載均衡集群的過程。具體原理請看 lvs負載均衡原理和模式 排程器.centos7.5，ip 10.0.0.10 ens33 ip 10.0.0.100 ens33 0 rs1.centos7.5，ip 10.0.0.11 lo ip 10.0.0.100 lo 0 rs2.c...
LVS負載均衡DR工作流程
a 當使用者請求到達director server，此時請求的資料報文會先到核心空間的prerouting鏈。此時報文的源ip為cip，目標ip為vip b prerouting檢查發現資料報的目標ip是本機，將資料報送至input鏈 c ipvs比對資料報請求的服務是否為集群服務，若是，將請求報文...