當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

LVS集群应用配置详解

發布時間：2025/3/17 编程问答 17 豆豆

生活随笔收集整理的這篇文章主要介紹了 LVS集群应用配置详解小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

一. 目錄

關于集群的介紹.

什么是負載均衡以及為什么需要負載均衡.

負載均衡技術的特點.

負載均衡集群的常見解決方案.

lvs介紹及管理工具.

實現lvs集群服務的三種類型方法介紹.

LVS調度算法介紹.

ipvsadm管理工具的用法.

FWM.

LVS持久連接 ??? ? ? ? ? ???

實驗部分(包括lvs-nat和lvs-dr類型的實現、基于lvs集群的http和https,及FWM的實現).

二. 正文

1. 關于集群的介紹

? 當網站后端服務器承受不住訪問的壓力，提高服務器性能的解決方案會極大的增加成本時，于是就出現了橫向擴展的解決方案。即增加一臺或幾臺服務器，提供相同的服務，通過前端調度器將訪問請求均勻的分配到后臺服務器上。這種多臺服務器組成的數組集合就叫做集群。

? 集群按功能劃分有三種模型：?

?負載均衡集群（LB, loadBalance）
?高可用性集群（HA, High Availability）
?高性能集群（HP, High Performance）

2. 什么是負載均衡以及為什么需要負載均衡:

? 由于網站中業務量的提高，訪問量和數據流量的快速增長，其處理能力和計算強度也相應地增大，使得單一的服務器設備根本無法承擔。負載均衡解決方案，讓網站服務器輕松應對流量高峰，有效保證網站的穩定性。針對此情況而衍生出來的一種廉價有效透明的方法以擴展現有網絡設備和服務器的帶寬、增加吞吐量、加強網絡數據處理能力、提高網絡的靈活性和可用性。這種技術就是負載均衡（Load Balance）。

3. 負載均衡技術的特點:?

大量的并發訪問或數據流量分擔到多臺節點設備上分別處理，有效保證每個請求都能最快處理；
網絡接入均衡，有效解決我國電信、網通“南北互通”問題；
多種負載均衡方式，有針對性的解決不同網站的壓力分配問題；
科學的數據同步及內容分發系統；
完整的數據備份系統。
...

4. 負載均衡集群的常見解決方案:

硬件方面：

?? 1） F5: F5公司是應用交付網絡（ADN）領域的全球領先廠商，全球市場份額第一。其致力于幫助全球大型的企業和服務提供商實現虛擬化、云計算和“隨需應變”的IT的業務價值。F5公司總部設在華盛頓州的西雅圖，并在全球各地設有分部。其產品性能好但價格昂貴。?

?? 2） A10: A10 公司是應用交付網絡（ADN）領域的全球領先廠商，全球市場份額第三。其總部位于美國硅谷，連續多年被INC.500評為全球發展最快的企業之一。

?? 3）深信服: 深信服應用交付AD產品具備服務器負載均衡、鏈路負載均衡、單邊加速、智能優化技術、SSL加速、商業智能分析等優勢功能，將用戶訪問請求智能匹配到最優的鏈路，并為用戶選擇響應最快的服務器，提升用戶使用體驗，并為企業提供科學管理的決策。

?? 4）Citrix NetScaler:中文名為負載均衡，指的是對于一個三層架構web應用來說，客戶端的請求將通過NetScaler與后臺服務器建立鏈接。思杰系統公司(Citrix System)是全球領先的以及最值得信賴的應用交付基礎架構解決方案提供商。全球有超過21萬5千家機構依靠思杰產品向身處任何地點的用戶交付任何應用，其方案性能好、安全性高、成本低。

軟件方面：

??? lvs，haproxy，nginx，httpd，varnish，...??

5. lvs介紹及管理工具：

? (1) LVS全稱為Linux Virtual Server，是由國內章文嵩教授牽頭開發的開源項目，現在已經被收到linux2.6以上的內核版本中，不需要對系統打補丁就可以輕松實現。

? (2) LVS工作于IOS七層模型的第四層-傳輸層，通過對TCP, UDP, AH, EST, AH_EST, SCTP等工作在四層的協議的支持，根據目標地址和端口做出轉發與否的決策，根據調度算法做出轉發至哪一個端口的解決方案。

? (3) LVS將其控制程序ipvs嵌套至傳輸層數據流的Input鉤子函數上，ipvs將發送至本調度器主機（director）上的數據流在input鏈上進行截流，通過對數據報文的分析根據自身的算法將數據流轉發至后臺真正提供服務的主機（Real Server）上，達到根據后端服務器負載能力均衡分配處理任務的效果。許多商業的集群產品，如RedHat的Piranha，Turbolinux公司的Turbo Cluster等都是基于LVS的核心代碼實現的。

? (4) LVS集群采用IP負載均衡技術和基于內容請求分發技術。調度器(Director)具有很好的吞吐率，將請求均衡地轉移到不同的服務器上執行，且調度器自動屏蔽掉服務器的故障，從而將一組服務器構成一個高性能的、高可用的虛擬服務器。整個服務器集群的結構對客戶是透明的，而且無需修改客戶端和服務器端的程序。為此，在設計時需要考慮系統的透明性、可伸縮性、高可用性和易管理性。??

? (5) IPVS: 稱之為IP虛擬服務器(IP Virtual Server，簡寫為IPVS),是運行在LVS下的提供負載均衡功能的一種技術。當一個TCP連接的初始SYN報文到達時，IPVS就選擇一臺服務器，將報文轉發給這臺服務器。此后通過檢查發報文的IP和TCP報文頭地址，保證此連接的后繼報文被轉發到相同的服務器。這樣，當IPVS無法檢查到請求的內容而需要再選擇服務器時，這就要求后端的服務器組提供相同的服務，不管請求被送到哪一臺服務器，返回結果都應該是一樣的。但是在有一些應用中后端的服務器可能功能不一，有的是提供HTML文檔的Web服務器，有的是提供圖片的Web服務器，有的是提供CGI的Web服務器。這時，就需要基于內容進行請求分發 (Content-Based Request Distribution)，同時基于內容請求分發可以提高后端服務器上訪問的局部性。

? (6) ipvsadm: 用戶空間的命令行工具, 用于管理集群服務;

? (7) 查看系統內核中的lvs支持的協議:

   [root@CentOS7?~]#?cat?/etc/redhat-release?  CentOS?Linux?release?7.3.1611?(Core)?  [root@CentOS7?~]#?   [root@CentOS7?~]#?grep?-i?-A?10?"IPVS"?/boot/config-3.10.0-514.el7.x86_64?  CONFIG_NETFILTER_XT_MATCH_IPVS=m CONFIG_NETFILTER_XT_MATCH_LENGTH=m CONFIG_NETFILTER_XT_MATCH_LIMIT=m CONFIG_NETFILTER_XT_MATCH_MAC=m CONFIG_NETFILTER_XT_MATCH_MARK=m CONFIG_NETFILTER_XT_MATCH_MULTIPORT=m CONFIG_NETFILTER_XT_MATCH_NFACCT=m CONFIG_NETFILTER_XT_MATCH_OSF=m CONFIG_NETFILTER_XT_MATCH_OWNER=m CONFIG_NETFILTER_XT_MATCH_POLICY=m CONFIG_NETFILTER_XT_MATCH_PHYSDEV=m -- #?IPVS?transport?protocol?load?balancing?support # CONFIG_IP_VS_PROTO_TCP=y CONFIG_IP_VS_PROTO_UDP=y CONFIG_IP_VS_PROTO_AH_ESP=y CONFIG_IP_VS_PROTO_ESP=y CONFIG_IP_VS_PROTO_AH=y CONFIG_IP_VS_PROTO_SCTP=y  # #?IPVS?scheduler # CONFIG_IP_VS_RR=m CONFIG_IP_VS_WRR=m CONFIG_IP_VS_LC=m CONFIG_IP_VS_WLC=m CONFIG_IP_VS_LBLC=m CONFIG_IP_VS_LBLCR=m CONFIG_IP_VS_DH=m CONFIG_IP_VS_SH=m CONFIG_IP_VS_SED=m -- #?IPVS?SH?scheduler # CONFIG_IP_VS_SH_TAB_BITS=8  # #?IPVS?application?helper # CONFIG_IP_VS_FTP=m CONFIG_IP_VS_NFCT=y CONFIG_IP_VS_PE_SIP=m  # #?IP:?Netfilter?Configuration # CONFIG_NF_DEFRAG_IPV4=m CONFIG_NF_CONNTRACK_IPV4=m  [root@CentOS7?~]#   

? (8) lvs中常用的的術語：??

??? DIP（Director IP）: 調度器連接后臺服務器的IP

??? CIP（Client IP）: 客戶端IP

??? VIP（Director Virtual IP）: 調度器對外開放的IP

??? RIP（Real Server IP）: 后臺服務器IP

? ? RS（Real Server）: 后臺提供服務的主機

? ? Director: 調度器或控制器

6. 實現lvs集群服務的四種類型方法介紹.?

? (1) lvs-nat

??? 多目標的DNAT(iptables),它通過修改請求報文的目標IP地址(同時可能會修改目標端口)至挑選出某RS的RIP地址實現轉發;

?圖示：

?注：

? 1)?LVS（Director）上面需要雙網卡：DIP(內網)和VIP（外網）.?

? 2) RS應該和DIP使用私網地址, 且RS的網關要指向DIP;RIP僅用于各個節點之間的通信?

? 3) 請求和響應報文都要經由director轉發, 極高負載的場景中, director可能會成為系統瓶頸;
? 4) 支持端口映射;
? 5) RS可以使用任意OS;
? 6) RS的RIP和Director的DIP必須在同一IP網絡;?
? ??

(2) lvs-dr

? 通過修改請求報文的目標MAC地址進行轉發。

? 圖示：

?注：

? 1) 保證前端路由器將目標IP為VIP的請求報文發送給director;

??? 解決方案:
????? 靜態綁定.
????? arp tables.?
?? ?? 修改RS主機內核的參數.?

? 2) RS的RIP可以使用私有地址, 但也可以使用公網地址;

? 3) RS跟Director必須在同一物理網絡中;

? 4) 請求報文經由Director調度, 但響應報文一定不能經由Director;

? 5) Director僅僅負責處理入站請求，響應報文則由Real Server直接發往客戶端;

? 6) 不支持端口映射;?

? 7) RS可以是大多數OS;?

? 8) RS的網關不能指向DIP，而是指向外部路由;

? 9) Director能夠支持比NAT多很多的Real Server;

在DR模型中，由于每個節點均要配置VIP，因此存在VIP的MAC廣播問題，在現在的linux內核中，都提供了相應kernel 參數對MAC廣播進行管理，具體如下：

? 兩個內核參數：

??? 1) arp_ignore：定義接收到ARP請求時的響應級別;

???? ? 0：只要本地配置的有相應地址，就給予響應； ??
???? ? 1：僅在請求的目標地址配置在到達的接口上的時候，才給予響應；DR模型使用

??? 2) arp_announce:定義將自己地址向外通告時的通告級別;

?????? 0：將本地任何接口上的任何地址向外通告； ??
? ? ?? 1：試圖僅向目標網絡通告與其網絡匹配的地址； ? ?
???? ? 2：僅向與本地接口上地址匹配的網絡進行通告；DR模型使用

??? 兩內核參數所在位置：/proc/sys/net/ipv4/conf/
?

(3) lvs-tun

? tun模型的數據轉發原理和上面的dr模式是一樣的，不過這個的應用場景主要是不同位置（不同機房）；LB是通過隧道進行了信息傳輸，雖然增加了負載，可是因為地理位置不同的優勢，還是可以參考的一種方案；
? 優點：負載均衡器只負責將請求包分發給物理服務器，而物理服務器將應答包直接發給用戶。所以，負載均衡器能處理很大的請求量，這種方式，一臺負載均衡能為超過100臺的物理服務器提供服務，負載均衡器不再是系統的瓶頸。使用LVS-TUN方式，如果你的負載均衡器擁有100M的全雙工網卡的話，就能使得整個Virtual Server能達到1G的吞吐量。
? 不足：這種方式需要所有的服務器支持”IP Tunneling”(IP Encapsulation)協議；

?注：

? 1） RIP,DIP,VIP都是公網地址;

? 2） RS的網關不能，也不可能指向DIP;

? 3）請求報文由Director分發，但響應報文直接由RS響應給Client;

? 4）不支持端口映射；

? 5） RS的OS必須得支持IP隧道，目前只有linux系統支持，windows，bsfdb等不支持；

(4) lvs-fullnat（雙向轉換）

? 通過請求報文的源地址為DIP，目標為RIP來實現轉發：對于響應報文而言，修改源地址為VIP，目標地址為CIP來實現轉發：

?注：

? 1） fullnat是對nat模型的改進，是一個擴展，使得RS與Director可以處于不同網絡中。

? 2） VIP是公網地址，RIP和DIP是私網地址，二者無需在同一網絡中;

? 3） RIP和DIP可以不再同一個網絡中，且RIP的網關未必需要指向DIP；

? 4）支持端口映射；

? 5） RS可以使用任意OS;

? 6）請求報文經由Director，響應報文也經由Director；

對DR/TUN/NAT模型的優缺點總結如下：

7. LVS調度算法介紹.

?四種靜態算法，不考慮后端服務器實際負載情況：

?1) RR

? 根據規則依次論調,不考慮RS的性能。輪到誰就轉發給誰。

?2) WRR

? 加權輪詢，加入了weight（權重），可以根據RS的性能為其設置權重值，權重越大功能越強，但是無法發現當前的服務器的運行情況如何。

?3) DH

? 目標地址hash，適用于前端是一個director后端是幾個緩存服務器的情況，當客戶端第一次訪問到的是RS1的時候，DH這種算法能保證在客戶端刷新后還是訪問的RS1。

?4) SH

? 源地址hash，用于保證響應的報文和請求的報文是同一個路徑。

?六種動態算法，考慮后端服務器當前負載后再進行分配：

?1) LC

? least connection，當一個用戶請求過來的時候，Director會計算一下哪臺RS的連接數最小，那么這臺RS就獲得了下次響應客戶端請求的機會，計算的方法Overhead=active*256+inactive,如果兩者的結果是相同的則從LVS中的規則依次往下選擇RS。這種算法也是不考慮服務器的性能的。

?2) WLC

? 這個就是加了權重的LC，考慮了RS的性能，即性能好的就給的權重值大一些，性能差的給的權重值小一些。缺點就是如果Overhead相同，則會按規則表中的順序，由上而下選擇RS，Overhead=(active*256+inactive)/weight

?3) SED

? 就是對WLC的情況的補充，Overhead=(active+1)*256/weight，加1，就是為了讓其能夠比較出大小。

?4) NQ

? 即never queue，基本和SED相同，避免了SED當中的性能差的服務器長時間被空閑的弊端，它是將第一個請求給性能好的服務器，第二個請求一定是給空閑的服務器不論它的性能的好與壞。之后還是會把請求給性能好的服務器。

?5) LBLC

? 它就是動態DH和LC的組合，適用于cache集群，對于從來沒有來過的那些新的請求會分給當前連接數較少的那臺服務器。

?6) LBLCR

? 帶有復制功能的LBLC，它的適用場景這里舉例說明一下，比如說現在有RS1和RS2,第一次訪問RS1的5個請求第二次又來了，理所應到Director將會將其交給RS1，而此時在RS2是非常閑的，所以此時最好的處理方法就是可以將后來的這5個請求分別交給RS1和RS2，所以此時就需要把客戶端第一次請求的資源復制下來。（特殊情況）

8. ipvsadm管理工具的用法:
?管理集群服務:
? # ipvsadm -A|E -t|u|f service-address [-s scheduler]?
? # ipvsadm -D -t|u|f service-address
????? service-address:
?? ????? tcp: -t ip:port?
?? ????? udp: -u ip:port?
?? ????? fwm: -f MARK
?? ?? ?? -s scheduler:
?? ??? ???? 默認為wlc.
?管理集群服務中的RS:
? # ipvsadm -a|e -t|u|f service-address -r server-address [-g|i|m] [-w weight] [-x upper] [-y lower]
? # ipvsadm -d -t|u|f service-address -r server-address
?? ?? server-address:
?? ??? ??? ip[:port]?
?? ?? lvs-type:
?? ??? ??? -g: gateway, dr?
?? ??? ??? -i: ipip, tun?
?? ??? ??? -m: masquerade, nat?
?權重：
??? -w NUM , -w表示權重，為0時就不會調度，數字越小，能力越小，性能越差;????
?清空和查看：
??? # ipvsadm -C
??? # ipvsadm -L|l [options]
?? ??? ??? ? -n: numeric,基于數字格式顯示地址和端口;
?? ??? ??? ? -c: connection, 顯示ipvs連接;
?? ??? ??? ? --stats: 統計數據
?? ??? ??? ? --rate: 速率
?? ??? ??? ? --exact: 精確值
?? ??? ??? ??? ?
?保存和重載：
?? ? # ipvsadm -R
???? # ipvsadm -S [-n]???? ??? ?????
?置零計數器：
?? ? # ipvsadm -Z [-t|u|f service-address]

9. FWM

復習netfilter知識：

? netfilter:
?? ?PREROUTING --> INPUT?
?? ?PREROUTING --> FORWARD --> POSTROUTING?
?? ?OUTPUT --> POSTROUTING??

FWM(FireWall MARK): 防火墻標記語言

為什么使用防火墻標記？

? 將來自于同一個客戶端的所有請求都定義到同一個RS上；如使用防火墻標記將443和80定義為同一個集群服務，這樣就可以實現統一調度到后端的RS。

? 比如在電商站點中，往購物車中添加商品之后需要付款,這個時候就需要訪問director，發起的連接就不是http，而是https;但director會認為這是一個新的連接，很可能會被分配到其他RS服務器，這個時候購物車中就沒有了商品。為了解決這種問題，就需要把用戶的http請求和https請求，都調度到同一臺服務器。

防火墻標記在什么時候打？

? 當用戶請求報文到防火墻（PREROUTING鏈）,防火墻就將特定報文（如：443和80），打上標記，假設標記為“10”；LVS調度的時候，就可以根據標記進行，只要請求帶有標記10，就會將請求調度到同一個RS服務器。

定義方法：

(1)打標：在director上的mangle表的PREROUTING鏈上實現：

?語法：

? # iptables -t mangle -A PREROUTING -d $vip -p $protocol --dport $port -j MARK --set-mark n

? $vip: vip地址?
? $protocol: 協議?
? $port: 協議端口?

? n:?[1-99]

(2)基于FWM定義集群服務:?

? # ipvsadm -A -f FWM -s SCHEDULER

? # ipvsadm -a -f FWM -rserver-address -g|-i|-m -w #

?????PREROUTING:
?? ??? ??? ?-j MARK --set-mark 10

?????ipvs:
?? ??? ?? -A -f 10

10. LVS持久連接

lvs persistence: lvs的持久連接;???

功能：無論ipvs使用何種調度方法，其都能實現將來自于同一個Client的請求始終定向至第一次調度時挑選出的RS;

和sh調度算法比較優點：??

?sh：會一直將一個用戶請求定義到一個后端server，不會考慮后端服務器狀態;對多個共享的同一組RS的服務器,需要統一進行綁定，sh算法無法實現;

?持久連接：第一次會根據設置的調度算法（rr，wlc……）調度到后端，在指定的會話存活時間使用持久連接，會話存活時間到期之后，還是根據調度算法進行調度。

persistence template(持久連接模板)：將多個集群服務歸并到一起統一調度;

持久連接的實現方式：

?? PPC：每端口持久；持久連接生效范圍僅為單個集群服務；如果有多個集群服務，每服務被單獨持久調度；

?? PFWM：每FWM持久：持久連接生效范圍為定義為同一個FWM下的所有服務；

?? PCC：每客戶端持久；持久連接生效范圍為所有服務；定義集群服務時，其TCP或UDP協議的目標端口要使用0；

?? ? director會將用戶的任何請求都識別為集群服務,并向RS進行調度;
?? ? TCP: 1-65535; UDP: 1-65535?

lvs persistence語法：

? ipvsadm-A -t|-u|-f service-address -s $schedular -p [n]

????? 無-p選項：不啟用持久連接

????? -p n：指定持久時長，省略時長，默認為360秒?

其他注意事項：

?? 關于時間同步：各節點間的時間偏差不大于1s，建議使用統一的ntp服務器進行更新時間；

?? DR模型中的VIP的MAC廣播問題：

11. 實驗部分:???

實驗一：部署lvs-nat集群

實驗環境：

? 實驗軟件:vmware workstation?

? 系統：

???? Director：CentOS7.3?

???? Real Server(2臺)：CentOS6.7

? 網絡拓撲圖：

本文轉自羽豐1995 51CTO博客，原文鏈接:http://blog.51cto.com/13683137989/1888491

總結

以上是生活随笔為你收集整理的LVS集群应用配置详解的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。

上一篇： Dubbo 新编程模型之外部化配置
下一篇：应用虚拟化IT：需要决策支持做后盾