參考網站：[http://www.linuxvirtualserver.org](http://www.linuxvirtualserver.org/) #### 一，部分概念[#](https://www.cnblogs.com/g2thend/p/10858270.html#%E4%B8%80%EF%BC%8C%E9%83%A8%E5%88%86%E6%A6%82%E5%BF%B5) 服務器集群系統： 通過高性能網絡或局域網互聯的服務器集群正成為實現高可伸縮的、高可用網絡服務的有效結構，這種松耦合結構的服務器集群系統有下列優點： * 性能網絡服務的工作負載通常是大量相互獨立的任務，通過一組服務器分而治之，可以獲得很高的整體性能。 * 性能/價格比組成集群系統的PC服務器或RISC服務器和標準網絡設備因為大規模生產降低成本，價格低，具有最高的性能/價格比。若整體性能隨著結點數的增長而接近線性增加，該系統的性能/價格比接近于PC服務器。所以，這種松耦合結構比緊耦合的多處理器系統具有更好的性能/價格比。 * 可伸縮性集群系統中的結點數目可以增長到幾千個，乃至上萬個，其伸縮性遠超過單臺超級計算機。 * 高可用性在硬件和軟件上都有冗余，通過檢測軟硬件的故障，將故障屏蔽，由存活結點提供服務，可實現高可用性 用服務器集群系統實現可伸縮網絡服務也存在很多挑戰性的工作： * 透明性（Transparency）如何高效地使得由多個獨立計算機組成的松藕合的集群系統構成一個虛擬服務器；客戶端應用程序與集群系統交互時，就像與一臺高性能、高可用的服務器交互一樣，客戶端無須作任何修改。部分服務器的切入和切出不會中斷服務，這對用戶也是透明的。 * 性能（Performance）性能要接近線性加速，這需要設計很好的軟硬件的體系結構，消除系統可能存在的瓶頸。將負載較均衡地調度到各臺服務器上。 * 高可用性（Availability）需要設計和實現很好的系統資源和故障的監測和處理系統。當發現一個模塊失敗時，要這模塊上提供的服務遷移到其他模塊上。在理想狀況下，這種遷移是即時的、自動的。 * 可管理性（Manageability）要使集群系統變得易管理，就像管理一個單一映像系統一樣。在理想狀況下，軟硬件模塊的插入能做到即插即用（Plug & Play）。 * 可編程性（Programmability）在集群系統上，容易開發應用程序 #### 二，linux virtual server[#](https://www.cnblogs.com/g2thend/p/10858270.html#%E4%BA%8C%EF%BC%8Clinux-virtual-server) lvs:基于IP層和基于內容請求分發的負載平衡調度解決方法，并在Linux內核中實現了這些方法，將一組服務器構成一個實現可伸縮的、高可用網絡服務的虛擬服務器. ##### 體系結構： 一組服務器通過高速的局域網或者地理分布的廣域網相互連接，在它們的前端有一個負載調度器（Load Balancer）。負載調度器能無縫地將網絡請求調度到真實服務器上，從而使得服務器集群的結構對客戶是透明的，客戶訪問集群系統提供的網絡服務就像訪 問一臺高性能、高可用的服務器一樣。客戶程序不受服務器集群的影響不需作任何修改。系統的伸縮性通過在服務機群中透明地加入和刪除一個節點來達到，通過檢 測節點或服務進程故障和正確地重置系統達到高可用性。由于我們的負載調度技術是在Linux內核中實現的，我們稱之為Linux虛擬服務器（Linux Virtual Server）。 ##### 1,IP虛擬服務器軟件IPVS 在調度器的實現技術中，IP負載均衡技術是效率最高的. IPVS 實現三種負載均衡技術： 1. **Virtual Server via Network Address Translation（VS/NAT）**通過網絡地址轉換，調度器重寫請求報文的目標地址，根據預設的調度算法，將請求分派給后端的真實服務器；真實服務器的響應報文通過調度器時，報文的源地址被重寫，再返回給客戶，完成整個負載調度過程。 2. **Virtual Server via IP Tunneling（VS/TUN）**采用NAT技術時，由于請求和響應報文都必須經過調度器地址重寫，當客戶請求越來越多時，調度器的處理能力將成為瓶頸。為了解決這個問題，調度器把請求報 文通過IP隧道轉發至真實服務器，而真實服務器將響應直接返回給客戶，所以調度器只處理請求報文。由于一般網絡服務應答比請求報文大許多，采用 VS/TUN技術后，集群系統的最大吞吐量可以提高10倍。 3. **Virtual Server via Direct Routing（VS/DR）**VS/DR通過改寫請求報文的MAC地址，將請求發送到真實服務器，而真實服務器將響應直接返回給客戶。同VS/TUN技術一樣，VS/DR技術可極大地 提高集群系統的伸縮性。這種方法沒有IP隧道的開銷，對集群中的真實服務器也沒有必須支持IP隧道協議的要求，但是要求調度器與真實服務器都有一塊網卡連 在同一物理網段上。 ##### 調度算法： 1. **輪叫（Round Robin）**rr? ??調度器通過"輪叫"調度算法將外部請求按順序輪流分配到集群中的真實服務器上，它均等地對待每一臺服務器，而不管服務器上實際的連接數和系統負載。 2. **加權輪叫（Weighted Round Robin）**wrr? ??調度器通過"加權輪叫"調度算法根據真實服務器的不同處理能力來調度訪問請求。這樣可以保證處理能力強的服務器處理更多的訪問流量。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。 3. **最少鏈接（Least Connections）**lc? ? ?調度器通過"最少連接"調度算法動態地將網絡請求調度到已建立的鏈接數最少的服務器上。如果集群系統的真實服務器具有相近的系統性能，采用"最小連接"調度算法可以較好地均衡負載。 4. **加權最少鏈接（Weighted Least Connections）**wlc? ??在集群系統中的服務器性能差異較大的情況下，調度器采用"加權最少鏈接"調度算法優化負載均衡性能，具有較高權值的服務器將承受較大比例的活動連接負載。調度器可以自動問詢真實服務器的負載情況，并動態地調整其權值。 5. **基于局部性的最少鏈接（Locality-Based Least Connections）**lblc? ?"基于局部性的最少鏈接" 調度算法是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。該算法根據請求的目標IP地址找出該目標IP地址最近使用的服務器，若該服務器 是可用的且沒有超載，將請求發送到該服務器；若服務器不存在，或者該服務器超載且有服務器處于一半的工作負載，則用"最少鏈接"的原則選出一個可用的服務 器，將請求發送到該服務器。 6. **帶復制的基于局部性最少鏈接（Locality-Based Least Connections with Replication）**lblcr? ? ?"帶復制的基于局部性最少鏈接"調度算法也是針對目標IP地址的負載均衡，目前主要用于Cache集群系統。它與LBLC算法的不同之處是它要維護從一個 目標IP地址到一組服務器的映射，而LBLC算法維護從一個目標IP地址到一臺服務器的映射。該算法根據請求的目標IP地址找出該目標IP地址對應的服務 器組，按"最小連接"原則從服務器組中選出一臺服務器，若服務器沒有超載，將請求發送到該服務器，若服務器超載；則按"最小連接"原則從這個集群中選出一 臺服務器，將該服務器加入到服務器組中，將請求發送到該服務器。同時，當該服務器組有一段時間沒有被修改，將最忙的服務器從服務器組中刪除，以降低復制的 程度。 7. **目標地址散列（Destination Hashing）**dh? ? ?"目標地址散列"調度算法根據請求的目標IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。 8. **源地址散列（Source Hashing）**sh? ? ? ?"源地址散列"調度算法根據請求的源IP地址，作為散列鍵（Hash Key）從靜態分配的散列表找出對應的服務器，若該服務器是可用的且未超載，將請求發送到該服務器，否則返回空。 ##### 2，體系結構 采用三層結構： * **負載調度器（load balancer）**，它是整個集群對外面的前端機，負責將客戶的請求發送到一組服務器上執行，而客戶認為服務是來自一個IP地址（我們可稱之為虛擬IP地址）上的。 > 當主調度器失效時，主調度器上所有已建立連接的狀態信息將丟失，已有的連接會中斷。客戶需要向重新連接，從調度器才會將新連接調 度到各個服務器上，這對客戶會造成一定的不便。 > > 為此，IPVS調度器在Linux 內核中實現一種高效狀態同步機制，將主調度器的狀態信息及時地同步到從調度器。當從調度器接管時，絕大部分已建立的連接會持續下去。 * **服務器池（server pool）**，是一組真正執行客戶請求的服務器，執行的服務有WEB、MAIL、FTP和DNS等。 * **共享存儲（shared storage）**，它為服務器池提供一個共享的存儲區，這樣很容易使得服務器池擁有相同的內容，提供相同的服務。 ##### 3，負載均衡技術 基于RR-DNS 基于IP層負載均衡調度 NAT實現虛擬服務器（VS/NAT） > NAT的工作原理是報文頭（目標地址、源地址和端口等）被正確改寫后，客戶相信 它們連接一個IP地址，而不同IP地址的服務器組也認為它們是與客戶直接相連的。由此，可以用NAT方法將不同IP地址的并行網絡服務變成在一個IP地址 上的一個虛擬服務(內部網絡地址訪問Internet 或被Internet訪問) 通過IP隧道實現虛擬服務器（VS/TUN） > IP隧道（IP tunneling）是將一個IP報文封裝在另一個IP報文的技術，這可以使得目標為一個IP地址的數據報文能被封裝和轉發到另一個IP地址。IP隧道技 術亦稱為IP封裝技術（IP encapsulation）。IP隧道主要用于移動主機和虛擬私有網絡（Virtual Private Network），在其中隧道都是靜態建立的，隧道一端有一個IP地址，另一端也有唯一的IP地址。 > VS/TUN 的工作流程：它的連接調度和管理與VS/NAT中的一樣，只是它的報文轉發方法不同。調度器根據各個服務器的負載情況，動態地選擇一臺服務器， 將請求報文封裝在另一個IP報文中，再將封裝后的IP報文轉發給選出的服務器；服務器收到報文后，先將報文解封獲得原來目標地址為VIP的報文，服務器發 現VIP地址被配置在本地的IP隧道設備上，所以就處理這個請求，然后根據路由表將響應報文直接返回給客戶。 > > 根據缺省的TCP/IP協議棧處理，請求報文的目標地址為VIP，響應報文的源地址肯定也為VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認為得到正常的服務，而不會知道究竟是哪一臺服務器處理的。 直接路由實現虛擬服務器（VS/DR） > VS/DR的體系結構：調度器和服務器組都必須在物理上有一個網卡通過不分斷的局域網相連，如通過高速的交換機或者HUB相連。VIP地址為調度器和服務器組共享，調度 器配置的VIP地址是對外可見的，用于接收虛擬服務的請求報文；所有的服務器把VIP地址配置在各自的Non-ARP網絡設備上，它對外面是不可見的，只 是用于處理目標地址為VIP的網絡請求 > > VS/DR 的工作流程：它的連接調度和管理與VS/NAT和VS/TUN中的一樣，它的報文轉發方法又有不同，將報文直接路由給目標服務器。在VS/DR 中，調度器根據各個服務器的負載情況，動態地選擇一臺服務器，不修改也不封裝IP報文，而是將數據幀的MAC地址改為選出服務器的MAC地址，再將修改后 的數據幀在與服務器組的局域網上發送。因為數據幀的MAC地址是選出的服務器，所以服務器肯定可以收到這個數據幀，從中可以獲得該IP報文。當服務器發現 報文的目標地址VIP是在本地的網絡設備上，服務器處理這個報文，然后根據路由表將響應報文直接返回給客戶。 > > 在VS/DR中，根據缺省的TCP/IP協議棧處理，請求報文的目標地址為VIP，響應報文的源地址肯定也為VIP，所以響應報文不需要作任何修改，可以直接返回給客戶，客戶認為得到正常的服務，而不會知道是哪一臺服務器處理的。 > > VS/DR負載調度器跟VS/TUN一樣只處于從客戶到服務器的半連接中，按照半連接的TCP有限狀態機進行狀態遷移 三種方法優缺點： **Virtual Server via NAT** 優點:運行在任何tcp/ip 系統，服務器可以使用私有ip地址。 缺點：伸縮能力有限，負載調度器本身會成為系統瓶頸， 解決方法： > 混合方法、VS/TUN和 VS/DR。在DNS混合集群系統中，有若干個VS/NAT負載調度器，每個負載調度器帶自己的服務器集群，同時這些負載調度器又通過RR-DNS組成簡 單的域名。但VS/TUN和VS/DR是提高系統吞吐量的更好方法。 NAT模式： > 集群節點跟Direcator 必須在同一個IP網絡中; > > RIP通常是私有地址，僅僅用于個集群之間通信; > > director位于Client和real server之間，并負責處理進出的所有通信;realservet必須將網關指向DIP,同時也支持端口影射;Realserver可以使用任意OS;在較大應用規模當中，單個Director會出現瓶頸;大概可以帶10個左右的SERVER就會出現瓶頸 **Virtual Server via IP Tunneling** 只會處理大量請求，不會成為系統瓶頸，極大增加負載調度器調度的服務器數量。 要求：服務器支持“IP tunneling”或“IP encapsulation” **Virtual Server via Direct Routing** > VS/DR調度器只處理客戶到服務器端的連接，響應數據可以直接從獨立的網絡路由返回給客戶。這可以極大地提高LVS集群系統的伸縮性。 > > 跟VS/TUN相比，這種方法沒有IP隧道的開銷，但是要求負載調度器與實際服務器都有一塊網卡連在同一物理網段上，**服務器網絡設備（或者設備別名）不作ARP響應，或者能將報文重定向（Redirect）到本地的Socket端口上** 工作模式： > NAT和TUN種模式基本上都是工作在網絡層上(三層)，直接路由模式則應該是工作在數據鏈路 > > 原理 ：DR和REALSERVER都使用同一個IP對外服務?但只有DR對ARP請求進行響應,所有REALSERVER對本身這個IP的ARP請求保持靜 默，網關會把對這個服務IP的請求全部定向給DR,而DR收到數據包后根據調度算法,找出對應的REALSERVER,把目的MAC地址改為 REALSERVER的MAC并發給這臺REALSERVER，REALSERVER收到這個數據包,則等于直接從客戶端收到這個數據包無異,處理后 直接返回給客戶端。DR要對二層包頭進行改換,所以DR和REALSERVER之間必須在一個廣播域 ##### 4，持久連接 [參考博客](https://www.cnblogs.com/wajika/p/6627629.html)： 持久連接是指無論使用什么算法，LVS持久都能實現在一定時間內，將來自同一個客戶端請求派發至此前選定的RS。 > 當使用LVS持久性的時候，Director在內部使用一個連接根據記錄稱之為“持久連接模板”來確保所有來自同一個客戶端的請求被分發到同一臺Real Server上。 > > 說明：持久連接模板是指每一個客戶端 及分配給它的RS的映射關系； 1）PPC（Persistent Port Connections）將來自于同一個客戶端對同一個集群服務的請求，始終定向至此前選定的RS；（持久端口連接） > client---->LVS(80)---->RS1 或 client---->LVS(23)---->RS2 > > 缺陷：期望訪問不同的端口到同一臺RS上，無法實現。 > > 配置： > > ~~~ > ipvsadm -A -t 172.16.100.1:80 -s rr -p 3600 > ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.10 -g -w 2 > ipvsadm -a -t 172.16.100.1:80 -r 172.16.100.11 -g -w 2 > ~~~ 2）PCC（Persistent Client Connections）：將來自于同一個客戶端對所有端口的請求，始終定向至此前選定的RS；（持久客戶端連接） > 說明：PCC是一個虛擬服務沒有端口號（或者端口號為0），以"-p" 來標識服務。 > > 缺陷：定向所有服務，期望訪問不同的Real Server無法實現。 > > 配置： > > ~~~ > ipvsadm -A -t 172.16.100.1:0 -s rr -p 3600 > ipvsadm -a -t 172.16.100.1:0 -r 172.16.100.10 -g -w 2 > ipvsadm -a -t 172.16.100.1:0 -r 172.16.100.11 -g -w 2 > ~~~ 3）PNMPP（Persistent Netfilter Marked Packet Persistence）：持久防火墻標記連接，根據iptables 的規則，將對于某類服務幾個不同端口的訪問定義為一類。 先對某一特定類型的數據包打上標記，然后再將基于某一類標記的服務送到后臺的Real Server上去，后臺的Real Server 并不識別這些標記。將持久和防火墻標記結合起來就能夠實現端口姻親功能，只要是來自某一客戶端的對某一特定服務（需要不同的端口）的訪問都定義到同一臺 Real Server上去。 > 案例：一個用戶在訪問購物網站時同時使用HTTP（80）和HTTPS（443）兩種協議，我們需要將其定義到同一臺Real Server上，而其他的服務不受限制。 > > 配置： > > ~~~ > iptables -t mangle -A PREROUTING -d 172.16.100.1 -i eth0 -p tcp --dport 80 -j MARK --set-mark 8 > iptables -t mangle -A PREROUTING -d 172.16.100.1 -i eth0 -p tcp --dport 443 -j MARK --set-mark 8 > ipvsadm -A -f 8 -s rr -p 600 > ipvsadm -a -f 8 -r 172.16.100.10 -g -w 2 > ipvsadm -a -f 8 -r 172.16.100.11 -g -w 1 > ~~~ #### 三，知識點[#](https://www.cnblogs.com/g2thend/p/10858270.html#%E4%B8%89%EF%BC%8C%E7%9F%A5%E8%AF%86%E7%82%B9) ##### 1,考察點 > lvs-nat 與lvs-fullnat ：請求和響應報文都經由Director > > lvs-nat ：RIP 的網關要指向DIP > > lvs-fullnat ：RIP 和DIP 未必在同一IP 網絡，但要能通信 > > lvs-dr 與lvs-tun ：請求報文要經由Director，但響應報文由RS直接發往Client > > lvs-dr ：通過封裝新的MAC 首部實現，通過MAC 網絡轉發 > > lvs-tun ：通過在原IP 報文外封裝新IP頭實現轉發，支持遠距離通信 > > lvs-nat ：修改請求報文的目標IP, 多目標IP的DNAT（目標地址轉換） > > lvs-dr ：操縱封裝新的MAC地址lvs-tun ：在原請求IP報文之外新加一個IP首部 > > lvs-fullnat ：修改請求報文的源和目標IP lvs-nat > 1）RIP 和DIP可以在也可以不在同一個IP網絡，且應該使用私網地址，RS的網關要指向DIP > > 2）請求報文和響應報文都必須經由Director 轉發，Director易于成為系統瓶頸 > > 3）支持端口映射，可修改請求報文的目標PORT > > 4）VS 必須是Linux系統，RS可以是任意OS > > 5）nat工作模式的Director有兩個ip是vip和dip，vip用戶客戶端通信提供服務，dip用于真實服務器通信。 lvs-tun > 轉發方式：不修改請求報文的IP首部（源IP為CIP，目標IP為VIP），而在源IP報文之外再封裝一個IP首部（源IP是DIP，目標IP是RIP），將報文發往挑選出的目標RS ，RS直接響應給客戶端（源IP是VIP ，目標IP是CIP） > > 1）DIP, VIP, RIP 都應該是公網地址 > > 2）RS的網關不能也不可能指向DIP > > 3）請求報文要經由Director ，但響應不能經由Director > > 4）不支持端口映射 > > 5）RS的OS須支持隧道功能 lvs-dr > lvs-dr > > 注意：Director和各RS都配置有VIP > > 1）確保前端路由器將目標IP 為VIP 的請求報文發往Director > > 在前端網關做靜態綁定VIP 和Director的MAC 地址 > > 在RS上使用arptables工具 > > arptables -A IN -d $VIP -j DROP > > arptables -A OUT -s $VIP -j mangle --mangle-ip-s $RIP > > 在RS上修改內核參數以限制arp通告及應答級別 > > arp\_announce > > arp\_ignore > > 2）RS的RIP可以使用私網地址，也可以是公網地址，RIP與DIP在同一IP網絡，RIP的網關不能指向DIP，以確保響應報文不會經由Director > > 3）RS和Director要在同一個物理網絡 > > 4）請求報文要經由Director，但響應報文不經由Director，而由RS直接發往Client > > 5）不支持端口映射（端口不能修敗） > > 6）RS可使用大多數OS 負載均衡實現： > 負載均衡集群設計時要注意的問題 > > (1)是否需要會話保持 > > (2)是否需要共享存儲 > > 共享存儲：NAS，SAN，DS （分布式存儲） > > 數據同步： > > lvs-nat： > > 設計要點： > > (1) RIP 與DIP 在同一IP 網絡, RIP 的網關要指向DIP > > (2) 支持端口映射 > > (3) Director要打開核心轉發功能 > > lvs-dr： > > dr模型中，各主機上均需要配置VIP，解決地址沖突的方式有三種： > > (1)在前端網關做靜態綁定 > > (2)在各RS 使用arptables > > (3)在各RS 修改內核參數，來限制arp響應和通告的級別 > > 三種方法中只有第三種方法修改RS的內核參數最實用 > > 限制響應級別：arp\_ignore > > 0：默認值，表示可使用本地任意接口上配置的任意地址進行響應 > > 1: 僅在請求的目標IP 配置在本地主機的接收到請求報文的接口上時，才給予響應 > > 限制通告級別：arp\_announce > > 0 ：默認值，把本機所有接口的所有信息向每個接口的網絡進行通告 > > 1 ：盡量避免將接口信息向非直接連接網絡進行通告 > > 2 ：必須避免將接口信息向非本網絡進行通告 > > [](javascript:void(0); "復制代碼") > > ~~~ > 實現LVS-DR的配置腳本（未測試） > RS 的預配置腳本 > #!/bin/bash > vip=192.168.0.100 > mask='255.255.255.255‘ > dev=lo:1 > case $1 in > start) > echo 1 > /proc/sys/net/ipv4/conf/all/arp_ignore > echo 1 > /proc/sys/net/ipv4/conf/lo/arp_ignore > echo 2 > /proc/sys/net/ipv4/conf/all/arp_announce > echo 2 > /proc/sys/net/ipv4/conf/lo/arp_announce > ifconfig $dev $vip netmask $mask broadcast $vip up > route add -host $vip dev $dev > ;; > stop) > ifconfig $dev down > echo 0 > /proc/sys/net/ipv4/conf/all/arp_ignore > echo 0 > /proc/sys/net/ipv4/conf/lo/arp_ignore > echo 0 > /proc/sys/net/ipv4/conf/all/arp_announce > echo 0 > /proc/sys/net/ipv4/conf/lo/arp_announce > ;; > *) > echo "Usage: $(basename $0) start|stop" > exit 1 > ;; > esac > VS的配置腳本 > #!/bin/bash > vip='192.168.0.100' > iface='eth0:1' > mask='255.255.255.255' > port='80' > rs1='192.168.0.101' > rs2='192.168.0.102' > scheduler='wrr' > type='-g' > case $1 in > start) > ifconfig $iface $vip netmask $mask broadcast $vip up > iptables -F > ipvsadm -A -t ${vip}:${port} -s $scheduler > ipvsadm -a -t ${vip}:${port} -r ${rs1} $type -w 1 > ipvsadm -a -t ${vip}:${port} -r ${rs2} $type -w 1 > ;; > stop) > ipvsadm -C > ifconfig $iface down > ;; > *) > echo "Usage $(basename $0) start|stop“;exit 1 > ;; > esac > ~~~ > > [](javascript:void(0); "復制代碼") ##### 2，安裝 是否支持ipvs modprobe -l | grep ipvs 或 lsmod | grep ipvs 安裝 yum -y install ipvsadm 命令 > ipvs -A -t|u|f service-address \[-s scheduler\] > > \-t: TCP協議的集群\-u: UDP協議的集群service-address: IP:PORT\-f: FWM: 防火墻標記service-address: Mark Number > > 例： ipvsadm -A -t 172.16.1.253:80 -s wlc > > 修改集群 > > ipvs -E -t|u|f service-address \[-s scheduler\] > > 例：ipvsadm -E -t 172.16.1.253:80**\-s wrr** > > 刪除集群： > > ipvsadm -D -t|u|f service-address > > 例： ipvsadm -D -t 172.16.1.253:80 > > 管理集群中RealServer > > 添加RS :ipvsadm -a -t|u|f service-address -r server-address \[-g|i|m\] \[-w weight\] > > \-t|u|f service-address：事先定義好的某集群服務\-r server-address: 某RS的地址，在NAT模型中，可使用IP：PORT實現端口映射； > > \[\-g|i|m\]?LVS類型 > > \-g: DR? -i: TUN? -m: NAT > > \[\-w weight\]?定義服務器權 > > 例： > > \[root@lvs ~\]# ipvsadm -a -t 172.16.1.253:80 -r 172.16.1.101 –g -w 5 > > \[root@lvs ~\]# ipvsadm -a -t 172.16.1.253:80 -r 172.16.1.102 –g -w 10 > > 修改RS： > > ipvsadm -e -t|u|f service-address -r server-address \[-g|i|m\] \[-w weight\] > > 例： > > ipvsadm**\-e**\-t 172.16.1.253:80 -r 172.16.1.101 –g -w**3** > > 刪除： > > ipvsadm -d -t|u|f service-address -r server-address > > 例： > > ipvsadm -d -t 172.16.1.253:80 -r 172.16.1.101 > > 查看： ipvsadm -L|l \[options\] > > \-n: 數字格式顯示主機地址和端口\--stats：統計數據\--rate: 速率\--timeout: 顯示tcp、tcpfin和udp的會話超時時長\-c: 顯示當前的ipvs連接狀況 > > 刪除所有集群服務： ipvsadm -C > > 保存規則至默認配置文件：service ipvsadm save > > 至指定文件：ipvsadm -S > /path/to/somefile > > 載入保存的文件： ipvsadm -R < /path/form/somefile > > 注意項： > > 關于時間同步：各節點間的時間偏差不大于1s，建議使用統一的ntp服務器進行更新時間 > > DR模型中的VIP的MAC廣播問題： > > ~~~ > 在DR模型中，由于每個節點均要配置VIP，因此存在VIP的MAC廣播問題，在現在的linux內核中，都提供了相應kernel 參數對MAC廣播進行管理，具體如下： > ? > arp_ignore: 定義接收到ARP請求時的響應級別； > ? ?0：只要本地配置的有相應地址，就給予響應； > ? ?1：僅在請求的目標地址配置在到達的接口上的時候，才給予響應；DR模型使用 > ? > arp_announce：定義將自己地址向外通告時的通告級別； > ? ?0：將本地任何接口上的任何地址向外通告； > ? ?1：試圖僅向目標網絡通告與其網絡匹配的地址； > ? ?2：僅向與本地接口上地址匹配的網絡進行通告；DR模型使用 > ~~~ #### 四，配置測試[#](https://www.cnblogs.com/g2thend/p/10858270.html#%E5%9B%9B%EF%BC%8C%E9%85%8D%E7%BD%AE%E6%B5%8B%E8%AF%95) 1,LVS-NAT > * DS配置: > > > VIP: 172.22.144.164 > > DIP: 192.168.36.74 > > 1，開啟路由轉發功能，清除所有的iptables限制 > > echo 1 > /proc/sys/net/ipv4/ip\_forward > > iptables -F > > 2,配置ipvsadm > > ipvsadm -A -t 172.22.144.164:80 -s rr > > ipvsadm -a -t 172.22.144.164:80 -r 192.168.36.72 -m > > ipvsadm -a -t 172.22.144.164:80 -r 192.168.36.73 -m > > #ipvsadm -L -n > > IP Virtual Server version 1.2.1 (size=4096) > > Prot LocalAddress:Port Scheduler Flags > > \-> RemoteAddress:Port Forward Weight ActiveConn InActConn > > TCP 172.22.144.164:80 rr > > \-> 192.168.36.72:80 Masq 1 0 0 > > \-> 192.168.36.73:80 Masq 1 0 0 > > * RS配置： > > > RIP1:192.168.36.72 > > RIP2:192.168.36.73 > > 1,配置RS的網關指向DS的DIP > > \[root@test73 ~\] $ route -n > > Kernel IP routing tableDestination Gateway Genmask Flags Metric Ref Use Iface > > 0.0.0.0 192.168.36.74 0.0.0.0 UG 100 0 0 eth1 > > 2，配置httpd,并生成網頁 > > * 測試（一定要檢測是否iptables限制了訪問）： > > > \[root@74 ~\] $ curl[http://172.22.144.164/index.html](http://172.22.144.164/index.html) > > test72.example.com > > \[root@74 ~\] $ curl[http://172.22.144.164/index.html](http://172.22.144.164/index.html) > > test73.example.com > > ?操，復制過來亂碼了