【3.工程開發】-四層負載均衡LVS

高可用的工程系統必定要作流量的負載均衡，軟件可作負載均衡位置：DNS，代碼中，應用層。DNS受緩存影響；代碼中二次轉發；基於應用層負載均衡調度的多服務器解決方法也存在一些問題。第一，系統處理開銷特別大，導致系統的伸縮性有限。當請求到達負載均衡調度器至處理結束時，調度器須要進行四次從核心到用戶空間或從用戶空間到核心空間的上下文切換和內存複製；須要進行二次TCP鏈接，一次是 從用戶到調度器，另外一次是從調度器到真實服務器；須要對請求進行分析和重寫。這些處理都須要不小的ＣＰＵ、內存和網絡等資源開銷，且處理時間長。所構成系 統的性能不能接近線性增長的，通常服務器組增至3或4臺時，調度器自己可能會成爲新的瓶頸。因此，這種基於應用層負載均衡調度的方法的伸縮性極其有限。第 二，基於應用層的負載均衡調度器對於不一樣的應用，須要寫不一樣的調度器。nginx主要是基於HTTP協議，若對於FTP、Mail、POP3等應用，都須要重寫調度器。固然四層也沒法作業務相關的負載均衡。
IP層

LVS

針對高可伸縮、高可用網絡服務的需求，咱們給出了基於IP層和基於內容請求分發的負載平衡調度解決方法，並在Linux內核中實現了這些方法，將一組服務器構成一個實現可伸縮的、高可用網絡服務的虛擬服務器。
官方：http://www.linuxvirtualserver...
邏輯架構

三種IP轉發實現方式

1.NAT 換目標地址，回來再換一次

2.IP管道。在VIP前加真實IP。回去直接去掉真實IP

3.直接路由。加MAC地址找到對應機器。回去直接去掉MAC地址（局域網中）

4.fullnat
所有轉爲內網（內網負載均衡只能是fullnat，https://ieevee.com/tech/2015/...）

cip 客戶端地址 rip 真實服務器地址 lip本地地址 SNAT來源地址轉換

部署

vip這個是提早申請好放到池子裏面的，業務現申請直接使用某個vip，外網lvs通常一個集羣是250個vip，內網lvs是520個
每臺LVS機器都有全部的VIP配置（經過OSPF一個VIP能夠有8臺副本），把全部VIP的IP都配在機器上。採用了 LVS ospf 方案，利用開源的軟路由軟件 quagga（linux設置主機當路由使用），對 IDC 接入交換機宣告 VIP 的主機路由信息，經過 OSPF 等價路由的特性能夠提供最多八臺 LVS All-active 的集羣服務

負載均衡算法

輪叫調度（Round-Robin Scheduling）
加權輪叫調度（Weighted Round-Robin Scheduling）
最小鏈接調度（Least-Connection Scheduling）記錄服務器鏈接數。會有一段時長的TCP_WAIT
加權最小鏈接調度（Weighted Least-Connection Scheduling）
基於局部性的最少連接（Locality-Based Least Connections Scheduling）請求IP最近使用服務器+服務器未超載，用於cache
帶複製的基於局部性最少連接（Locality-Based Least Connections with Replication Scheduling） LBLC+LCS.性能和cache的折中
目標地址散列調度（Destination Hashing Scheduling）
源地址散列調度（Source Hashing Scheduling）

DGW

dpdk+fullnat的LVS
dpdk:加速數據包處理軟件，取代傳統的Linux內核態驅動 （https://blog.csdn.net/zhaoxin...）